在數字經濟時代，數據的重要性堪比石油。大數據的四個特點：Volume（數據體量大）、Variety（數據類型繁多）、Velocity（處理速度快）、Value（商業價值高），只要合理利用數據並對其進行準確的分析，將會給企業帶來很高的價值回報。
在數據建設側，阿里巴巴數據體驗技術團隊完成了大型 Web 應用架構，TypeScript 方案的 Iron-Redux，加 API 服務 Pont。上層特色的服務編排引擎和 SQL 編輯器的深挖，在工具層體驗能力增色不少。在數據消費側，我們致力於構建以 BI 為搭建數據報表等核心能力，上層特色的數據可視化，數據藝術和數據安全都在各領域有深度貢獻。
SQL 編輯器
在數據採集，加工，管理，應用的鏈路中，編輯器都充當著開發者最重要的夥伴。在前端領域，編輯器是高複雜度的領域，而 SQL 編輯器在這個領域中又是垂直領域的建設。我們在設計編輯器的過程針對理解語法和理解語境這兩個點作了深入分析和優化。
理解語法
回顧人學習一門新語言的過程，無外乎兩種方式，要麼翻閱百科字典，從 a 到 z，無論常用字還是生僻字，可以組成哪些詞語，悉數記於腦中；要麼與人交談，記下其他人遣詞造句的習慣，轉為己用，與人交談的次數越多，交談的人群範圍越廣，積累下的話術也越為豐富，面對同一個問題，心中可供選擇的答案也越多。
編輯器理解語法的過程亦是如此，基於產生式進行分析或是基於樣本進行模型訓練與識別。一門語言的產生式定義可以視為這門語言的百科字典，詳盡的枚舉出詞法和語法的所有場景，清晰的描摹出邊界。SQL 語言的語法相對簡單，結構性較強就比較適合採用基於產生式分析的方案。而對於 Python，Shell 這類語法複雜，或靈活度高的語言，基於產生式分析提供的關鍵詞提示，在實際應用中難以真正起到提高開發效率的目的，基於業務場景的歷史數據進行模型訓練，提供包含業務含義的代碼片段的提示顯得更有意義。
理解語法可以說是編輯器最為基礎的能力，不同的編輯器方案均有不同程度的實現，在我們的方案設計與實現的過程中，最為關注的三個方面分別是可擴展，易維護，高性能三個方面。
可擴展性
編輯器的載體產品經常提出一些定製化的需求，譬如支持變量語法，注入全局變量，或者是調整提示內容優先級，新增一些快捷鍵操作。儘管最終效果的呈現都是在界面上，實際解決這些問題的原點卻不盡相同。因此，對編輯器作了三層架構設計，產生式層，解析層，組件 UI 層，各層級間明確 API 規範來保證能力的解耦與擴展性。
易維護
在需求支持的過程中，我們無可避免的要對語言的產生式進行修改，在這個過程中任何思考上的疏忽都有可能引入二義性語法，或者左遞歸語法，導致解析異常，無法提示出正確的信息或是陷入死循環。於是，產生式調試是語法拓展的核心工作之一，我們需要追蹤用戶輸入的解析過程，在哪一個子句處沒有匹配到目標產生式，從而去檢查相應的產生式定義是否存在問題。
高性能
高性能的保證和提示精度的調控，提示規則的設計是相輔相成的。總能找到一處語法定義是 LL(k) 識別不了，但是 LL(k+1) 可以識別的。性能的要求導致我們不能無限的提高回溯的步長，但是同時還要達到一定精度的要求。
由於 SQL 本身流程控制能力上的侷限，在實際開發中往往需要藉助 transform 或 udf 的方案，結合 Python，Shell 一起開發。未來，我們也會用機器學習的方案，來支持 Python，Shell 的語法提示能力。
理解語境
為了做到理解語境，在充分理解語法的基礎上，還要進一步對語法所在的上下文進行分析，才能得出最終的結論。語法解析的過程實際上就是將用戶輸入轉化為抽象語法樹的過程，因此理解語境所需的上下文盡在樹中。但是在為編輯器賦予理解語境能力的過程中，我們發現最大的挑戰並不在於分析邏輯的實現本身，而是在於它的複製量產。由於業務上要求支持的方言眾多，方言彼此間有著或多或少的語法差異，既要保持不同方言間語境理解能力的齊平，又要避免冒煙囪式開發。經過分析我們發現針對每一種語境理解的實現，關注點都集中在幾個關鍵的終結符與非終結符定義上，圍繞這些關鍵節點，建立一個有限狀態機，新的方言接入時提供一個映射關係來說明關鍵節點之間的映射，語境理解能力就完成複製量產。這套機制的建立也意味著編輯器能力開放的議題中，語境理解能力的開放已經初具雛形。
理解語境的另一方面體現在與數據分析能力的結合。結合數據探查的能力，對於數據研發中一些常見的數據質量問題可以做到前置檢測，在開發過程中予以提示並引導解決，從而改變傳統數據治理方案流程滯後，導致計算資源浪費的問題。以數據傾斜治理為例，當用戶任務執行失敗，經過探查分析發現是由於數據傾斜所致，由於數據傾斜存在一個持續期，因此在持續期內，用戶開發中再次操作引發傾斜的字段時，會將熱值信息予以提示，引導用戶進行改寫。除去這個例子，其他類型的數據質量問題，諸如暴力掃描，join 兩側字段類型不一致，以及其他 map join 優化場景都可以通過開發時的檢測與提示進行規避。
語法提示
別名識別
關鍵詞修正
BI 平臺
BI 平臺是幫助我們更好地利用數據提高決策質量的中後臺應用架構。它是從大量數據前端應用中沉澱出來的，上層支撐了 Quick BI，Quick A+ 等數據產品，彙集並沉澱了數據分析的核心能力。
Quick BI 是 BI 平臺支持的核心，也是數據中臺拳頭級產品。2019 年，成為中國首個且惟一入選 Gartner BI 魔力象限的產品。BI 是一個典型的重交互場景，整個 BI 的分析鏈路包括數據引入、數據建模加工、報表搭建、交互分析、訪問分享和集成。
BI 是非常有挑戰的搭建場景，搭建能力對阿里數據中臺來說，就像水和空氣一樣重要，搭建能力很大程度決定了數據中臺競爭力。大量的產品需要搭建的方式來賦能業務人員，類似 Powerpoint 一樣富客戶端的交互方式；動輒百萬條數據的加載對性能的挑戰，單頁面項目、ISV 開放生態對接等對工程化充滿挑戰。因此，我們抽象出渲染引擎內核 bi-designer 同時支持了兩個 BI 的快速迭代。
目前，我們攜 bi-designer 加入到阿里集團低代碼引擎組織，成為核心架構組的一員，專注於數據領域搭建方向，正在積極的遞交提案拓展阿里低代碼引擎協議，並進行 bi-designer 規範化改造，與 AliLowCodeEngine 引擎進行代碼融合。
bi-designer 數據搭建引擎有如下幾個特色：
三合一佈局
我們三種業務場景天然需要三套佈局的能力：
- 數據搭建 - 流式佈局
- BI 報表 - 磁貼布局
- 大屏 - 自由佈局
bi-designer 通過插件機制內置了這三種佈局能力，使流式、磁貼、自由佈局間可無縫切換，在不同的產品透出不同佈局能力。自由佈局採用 Keynote 高仿真方案，支持吸附、對齊、組合、鎖定等功能；磁貼布局也做了高度自使用、寬高智能拖拽等體驗優化。
數據模型驅動
BI 搭建擁有強大運行時分析能力，比如基於 OLAP 數據模型的同數據集自動關聯功能，在圖表內點擊、框選操作觸發其他組件查詢並自動過濾篩選。
簡單的聯動配置背後需要一套運行時解析能力，bi-designer 提供了一套運行時事件機制 runtimeConfig ，將任意組件配置映射成複雜事件關聯效果，比如點擊控制圖表屬性變化、點擊控制取數參數變化、點擊控制篩選條件值的變化。在取數上也內置了數據模型處理，針對篩選條件多對多關聯、聯動、值同步，以及任意組件（如線圖）具有展示與篩選雙重功能的能力。
懶渲染
由於 BI 場景數據量動輒上百萬條，我們在做了大量組件優化的同時（虛擬滾動、數據抽樣等），bi-designer 渲染引擎也內置了組件按需渲染的能力。
對於數據取數場景，我們也做了特別優化，懶加載的組件不會阻塞取數，而只阻塞組件本身渲染，這樣可以在組件出現的瞬間直接加載數據，而不是重新取數。
被集成能力
BI 報表在阿里內部和雲上市場都有強烈被集成訴求，若干張報表或者設計器集成到已有系統逐漸成為一種趨勢，我們開發了 bi-open-embed 並集成 bi-designer 能力，讓渲染引擎可以被輕鬆集成到任意平臺。我們對 Client、Server 端抽象了三層通用中間層 - PostMessageProxy、Router、EmbedAPI，分別定義了消息派發、指令接收以及指令執行，Server 端底層對接 bi-designer 引擎，Client 端對接接入方應用。
被集成領域中，組件安全隔離我們也下了功夫，從組件打包階段開始，就利用構建工具進行樣式隔離，組件腳本加載時進行 JS 環境變量隔離。在集成 API 上我們也從權限體系開始設計，到報表區塊、篩選、主題等模塊的控制，還可支持動態傳入取數參數影響報表取數結果等等。
低代碼
低代碼能力也是我們數據搭建平臺今年重點建設方向之一。低代碼包括 NoCode 與 LowCode，NoCode 就是基於模型或者標準化模版，不需要寫代碼即可支持通用場景搭建，LowCode 則是在 NoCode 的基礎上，輔助少量業務邏輯代碼，比如變量綁定或者或者動作，實現更多定製業務邏輯的覆蓋，其適用範圍更廣。
集團中後臺搭建採用 LCDL（Low-Code Definition Language）描述低代碼業務協議，主要包括應用低代碼定義語言、頁面低代碼定義語言、組件低代碼定義語言。圍繞這三個核心協議，拓展出四個可插拔的核心模塊：
- 入料模塊：讓渲染引擎可接入任何物料，並識別物料特徵，自動完成對接。
- 編排模塊：設計器核心功能，包括組件編排、邏輯編排、事件編排等，是搭建的核心。
- 渲染模塊：搭建產物需要被分發到不同端，甚至小程序，從安全性到兼容性都是渲染模塊要解決的問題。
- 出碼模塊：所有低代碼搭建產物都可出碼，使產物可二次開發，FY21 還會持續探索 Pro-Code 與 Low-Code 完全互轉。
數據搭建場景較為垂直化，且可依賴數據模型驅動，所以很久以來都沒有強烈低代碼訴求。但隨著數據中臺業務越做越大，盒馬、菜鳥、本地生活、餓了麼等等經濟體 BU 數據團隊的加入，具有低代碼能力的數據產品搭建訴求越來越強烈，所以我們今年加入了集團低代碼引擎組織核心團隊共建，向組織輸出數據場景搭建能力，從組織獲取低代碼引擎能力。
數據可視化
人類在處理信息的能力，視覺遠超其它五感處理能力，在《Information is Beautiful》一書中，作者將視覺類比成計算機網絡的帶寬，達到 1250MB/s，觸覺排在第二類比成 USB 接口，有 125MB/s，聽覺和嗅覺類比成硬盤只有 12.5MB/s，而味覺就忽略不計了。數據可視化，就是在我們清洗關鍵數據之後，將數據呈現給用戶，就像一道菜品精美的擺放，給你帶來更多想象。
可視化一直是數據分析重點一環，工業界和學術界在可視化的研究也有高度重合的部分，脫離了分析的可視化是缺少靈魂的。上圖來自於一家調研公司，可以看到數據分析有一個發展階段，描述分析，解釋分析，探索分析，預測分析，規範分析。規範分析是數據分析的最終階段，它已經可以解決我們怎麼做的問題，類同於人工智能的終極階段。
而可視化在之前的幾個階段都有一一匹配的能力，這也是可視化與大部分認知不同的地方，可視化遠遠不只是解決數據如何展示的問題，更重要的是如何傳遞信息，甚至解決的是如何傳遞更多的有效信息。
基礎架構
我們團隊在這四個階段都有佈局，在可視化圖表上，也是我們立身之本。我們在 BI 工具發展上構建了整體數據團隊可視化能力，基於 D3，G2 構建了完善的基礎層。結合業務能力在工具層，擁有完善的交互式分析能力。通過上層圖形語法和數據模型標準的映射，我們得以用一套架構來實現可視化內核，在內核層大量增強了基礎庫的能力。
BI 場景有極其豐富的可視化場景，目前 Quick BI 支持 40+ 種圖表，包括用戶最常用的折線圖、柱狀圖、堆積面積圖、條形圖、餅圖和桑基圖、排行榜、指標卡趨勢圖這些業務場景化圖表。
如何讓這些圖表更快速的開發和擴展一直是我們要解決的問題。因此，我們抽象出了 charts-bi 圖表公共層，它包括統一的數據處理層、圖表默認配置管理、圖表極限情況處理、子圖表、子組件包括圖例和 Tooltip 等原生的渲染。儘管，我們圖表渲染底層基於 G2，但可以說我們的 BI 場景圖表是 G2 在集團應用最豐富的場景之一，同時我們也深度參與了可視化基建的共建。
經過一年多的努力，2019 Quick BI 在 Gartner 象限報告中在數據可視化上在滿分 5 分的情況下達到了 4.7 高分，超越微軟 PowerBI，僅次於以可視化著稱的 Tableau。報告稱 Quick BI 在數據可視化功能方面被評為傑出。它支持豐富的圖表類型和類似 Excel 的報告。它還為參數化數據獲取和基於表單的回寫提供了專用功能。
智能可視化
智能可視化是一個跨界領域，諸如自動洞察，可視化設計，可視化配置推薦都是智能可視化的方向。Gartner 預測，未來數據分析是增強分析時代。普通用戶發現數據洞察的成本很高，用戶需要嘗試找到有規律的一些指標，通過可視化的方式來驗證甚至是發現規律，這種反覆試錯的成本非常高。因此，自動洞察可以說是對用戶在基本業務洞察之外的補充。
自動洞察能夠在用戶提供的數據集上，自動進行特徵的分析，數據清洗，根據梳理的 insight 類型進行自動的匹配，找到隱藏在數據集中的知識，提供給用戶。這條鏈路的不斷優化，最終手工分析的時代也會被自動洞察所替代，只有一個按鍵就可以讓用戶找到最有效的信息。
近幾年，產學研一體趨勢顯著，微軟的 Power BI 在這個領域頗有建樹，推出了 Quick Insight 就是與 MSRA 合作，是自動洞察方向的開荒者之一。今年，團隊在對內側的 BI 工具上已經落地了自動洞察功能，提供給小二更智能的數據決策工具而為之努力。
在未來佈局上，數據世界真實的描繪不應該是靜態的，它是真實在變化的，我們在變化中需要呈現一個變化的規律，這是現代數據分析上比較缺失的。未來，在數據故事和自動洞察上發力。將數據可視化能力從靜態交互分析，發展到動態交互分析上。進一步，挖掘數據中更多有效信息，輔助人作決策。
數字藝術
如果說 BI 和數據可視化是幫你從數據中發現信息的工具，數字藝術則是展示和傳播你的數據故事的媒介。無論是一個大屏，還是一個可交互裝置、Web 頁面、富媒體，作為數據可視化的延伸，我們始終在探索更新穎的形式，更前瞻的技術，來讓你的故事擁有怦然心動的力量，在從紛繁的信息中脫穎而出，無須多言，便能打動聽眾。
團隊與 UED 緊密合作，負責了集團多年的雙十一和九號館的大屏和互動展區設計開發，支持了集團 PR、GR 部門眾多的高級接待和對外訪問活動，同時以技術支持和平臺支持的形式，協助集團各個BU團隊開發數據可視化、BI、大屏、展示型內容和傳播內容。
在這個過程中，積累了一套從數據處理算法、到渲染引擎、可視化框架，以及搭建平臺的解決方案。
異構渲染
為了滿足不同場景和內容的展示需求，充分發揮不同渲染平臺的優勢，我們在渲染框架中原生支持了跨平臺渲染。
通過一套統一的數據源/數據算法，統一的地理空間規範，和統一的相機狀態定義，來保證不同渲染架構輸出的渲染結果空間對齊，然後通過實時推流和 WebView 對不同渲染架構的內容進行融合，實現多種平臺渲染內容的合併輸出。
通過異構渲染，我們得以在一個場景中，融合來自 Polaris 的實時數據可視化能力、UE4 的細節制作和渲染能力、G2 豐富的可視化圖表、高德龐大的地圖數據，各取所長，融合為一個可交互的實時渲染內容。
Web3D 渲染引擎
無論技術流行趨勢如何變化，Web 平臺依然承載著我們和核心技術和產品形式。我們始終相信，Web 平臺有著未被髮掘的強大表現力。受限於設備性能和兼容性的妥協，大家已經習慣將 3D on Web 視為一種能用即可的“降級方案”，然而 Web 技術的應用領域已經發生了巨大的變化，基礎設施和硬件設備也不斷的更新換代，現代 Web3D 渲染引擎，不應該總向十年前的遊戲引擎看齊。
我們的渲染技術始終以 three.js 為根基，作為標杆級的 WebGL 引擎，three 無可匹及的強大社區支持著我們的快速發展，當我們試圖擺脫 webgl 的限制時，選擇保留了 three 所有的上層設計和場景定義，兼容多數 three 接口和社區插件的情況下，重寫渲染層，實現了（當時）功能最完整的 WebGL2 引擎，顯著提升性能效果，實現在瀏覽器中實時渲染上億頂點的大型場景。同時引入了高效的 GPGPU，來實現更加複雜的粒子動畫。
從 WebGL2 到未成行的 WebGPU ，限制 Web 3D 渲染能力的已經不再是圖形 API，而是渲染流水線和圖形算法，渲染管線不升級，圖形 API 再怎麼升級也不會帶來質的變化。
在 2019 年，我們作出了一個大膽的嘗試，直接將桌面遊戲引擎的高清渲染管線，實現在 WebGL2 之上，並在雙十一項目中使用。
參照成熟遊戲引擎的渲染管線設計，我們使用多種渲染路徑來渲染場景的不同成分，對不能完整支持 Deferred Shading 的材質，或者需要兼容的現有入庫組件，使用前置渲染或者不完整的延遲渲染，其中基礎場景使用完整的Deferred Shading 管線。Deferred Shading 管線中，除了獲得在 shading 階段強大的性能控制，完整的 GBuffer 更是解鎖了眾多屏幕空間算法，讓我們可以高效的進行 SSAO 和 SSR 等複雜計算，甚至能在筆記本上流暢運行。
高清渲染管線為 Web 端的渲染能力邁上了一個新的平臺，使得眾多新技術的引入成為可能，我們能從學術、遊戲、影視領域的最新成果中汲取養分，而不用再受限於實時渲染技術發展初期的古老算法。這也將是唯一一個有能力發揮 未來 WebGPU 潛力的渲染管線。
3D 地理系統
3D 數據可視化的場景雖然複雜而零散，但是多數和地理數據強相關，為了提高開發效率和服用能力，我們在 three 的通用場景定義之上，設計了一個輕量級的地理信息系統 — Polaris。將視覺效果的開發和業務邏輯的開發，全部簡化為 Layer 開發，符合 schema 的 Layer 可以自由疊加、組合、繼承，然後交由 Polaris 渲染器渲染。同時積累了一套上百種 3D 組件的 Layer 組建庫。
在 Polaris 中，我們按照真實比例和地理位置構建世界，可以向 Google Earth 一樣，在一個三維場景中繪製從星系到地球、國家、一直到某個城市的某個樓宇內部，通過一個長鏡頭，將所有的場景貫穿起來，形成一個連貫的數據故事，而非 PPT 一般的分離圖表。
算法服務
一個 3D 空間的構建，是對大量原始地理數據的層層處理，處理的過程往往從高德的原始地理數據開始，經過過濾、簡化、拔高，變為3維模型，然後通過算法進行細化、匹配，生成建築細節，然後根據 DEM 生成地形和山脈，對於特寫區域，需要通過人工製作高精模型，再通過算法對齊地理空間，如果是城市景觀，還可以通過算法生成車水馬龍、廣告牌、霓虹燈等裝飾內容。
所有這些過程都涉及到龐大的數據輸入和複雜的計算邏輯，我們已經在不同業務場景中生成過 30 多個城市和所有省份的場景數據，並且數據源和場景構建的需求在不停的更新著，手工管理將是一筆巨大的負擔。因此我們構建了一個地理數據算法服務，來為 UE4 和 Web 端渲染平臺提供等效的服務。
數據安全
數據產品中有表現力豐富的數據可視化能力、有高效的數據解讀能力，但背後也隱藏著各種各樣的數據安全風險，這些數據可能涉及到交易數據，也可能是行業趨勢數據，這些數據如果發生洩漏被不法分子利用極有可能對集團和客戶造成嚴重的損失，所以數據產品的各個生產環節都需要具備安全防禦方案。
對於整個數據安全體系，從數據生產到數據查詢的鏈路需要做數據脫敏和差分隱私，前端是數據產品向用戶展示和交互的最後一環，也是整個生產鏈路中數據安全保障的最後一環。我們也需要配合全鏈路的數據安全建設，做到事前，事中和事後的保障。
數字水印
數字水印是在事前環節，起到警示、震懾的作用，提醒產品的訪問者產品中展現的數據屬於祕密信息，不可傳播；以及在事後環境，幫助案件追查，當訪問者對頁面進行截圖和傳播後，可以準確的定位到案件的當事人，協助案件偵破。傳統的網頁水印方案是在端上直接繪製水印信息覆蓋在文檔流上或作為背景圖片，但只要是具備一點前端知識的人都可以通過瀏覽器的調試器對水印信息進行刪除甚至是篡改，所以我們要確保水印的真實性和水印的穩固性。
水印生產主要分兩類。明文水印，它是指將可讀的信息（用戶姓名或其他警示信息）生成水印圖片，主要目的是起到警示作用；加密水印，我們團隊和安全專家一同共建的，將水印信息加密為不同形式的圖片方案，比較有代表性的是結合了文件數字水印的理論：點陣水印、隱祕水印、浮雕水印，此類水印的特點是信息無法被篡改，主要用於案件追蹤。
水印在生產環節進行了加密，由於無法解密，解決了水印的篡改問題。在水印部署過程中需要克服水印被刪除的問題，我們針對常見的水印刪除手段進行防禦：
1）網絡干預，阻止頁面獲取水印資源（圖片和 SDK），對圖片二進制流和sdk資源下發均採用與業務代碼進行混淆，確保水印部署和業務邏輯執行過程交叉執行，無法單獨中斷。
2）環境及 DOM 干預，通過修改和刪除 DOM，對瀏覽器的 DOM 和關鍵原生 API進行劫持驗證，確保 DOM 的修改可被監聽和復原，無法復原的情況將中斷業務邏輯。
3）融合部署：對於重要的數據信息，通過 canvas 或圖片方式渲染替代原有的DOM渲染，此時數據信息和水印信息融合為一個原子節點，無法單獨刪除。
4）信息差手段：每個數據產品的頁面均混合部署多套水印方案，通過虛實結合（可見水印、不可見水印）的方式確保不法分子無法完全刪除掉頁面中的水印。
除了以上攻防手段，我們還在進行一些新型水印生產及部署方向的研究，目的是從更本質的方面對水印進行加固同時降低水印對產品的視覺侵入，目前具備可行性的是邊緣水印（將水印的生產和部署在客戶端進行，強化水印和頁面內容的融合）和血緣水印。
數據監控
監控在數據產品中不僅是生產安全的重要部分，同時也是數據安全的重要保障，通常的監控主要關注 JS 報錯和 API 接口報錯，但數據產品需要對數據邏輯進行監控，例如用戶正在分析自己商業數據，突然實時數據顯示利潤劇烈下跌，這很容易造成用戶的恐慌。
我們在完成了監控平臺 Clue 的基礎建設上同時也在做很多數據場景的垂直建設：
**非法環境識別
**
因為有數據透出，總是有黑灰產不斷生長。他們通過第三方插件爬取數據接口，對數據進行非法彙總和反推，這時就需要對用戶使用產品的瀏覽器環境進行檢查，為打擊黑產提供法律依據。針對這種場景我們會對部分原生 API 進行數字指紋加持，通過特徵匹配，定位非法插件。
診斷報警
監控平臺中報警的及時性和準確性是重中之重。對於數據展現來說，某些數據趨勢跌 0 對於大客戶和來說一定是出現了問題，但對一些小眾客戶或行業來說，部分指標的跌 0 可能是正常表現。因此，我們需要抽取指標信息、行業信息、大促信息等在內的多種特徵對報警模型優化，通過報警信息的反饋機制不斷的對報警模型持續優化，通過模型預測的方式對報警閾值進行動態調整，促使報警逐漸趨於準確。
寫在最後
未來，數據與智能佔據了風口。依靠著雲上計算能力，提供強大的渲染與數據分析能力。在流程研發，分析洞察，科學決策等方面都是體驗技術發揮至關重要力量之處。倚靠業界和學界前沿方向探索，數據體驗技術圍繞數據應用的全生命週期進行建設和打造，數據的未來是星辰大海，望有志之士一同前來創造未來！
你99%的儲存實力，只差這1%的簡歷投遞——數據技術及產品部【數據平臺技術與設計-體驗技術團隊】招人進行中，期待與你一起用創意與代碼為世界做出些許改變。郵箱 [email protected]