作者 | 流形
作者陳屹，花名流形，2010 年加入阿裡，《深入 React 技術棧》作者，目前帶領阿裡巴巴資料技術與産品部體驗技術團隊。
在數字經濟時代，資料的重要性堪比石油。大資料的四個特點：Volume（資料體量大）、Variety（資料類型繁多）、Velocity（處理速度快）、Value（商業價值高），隻要合理利用資料并對其進行準确的分析，将會給企業帶來很高的價值回報。
資料體驗技術團隊從一開始建立就緻力于打造資料領域體驗技術的标杆。經過多年的深耕，形成了一整套面向兩個階段的使用者産品的體驗技術架構。
在資料建設側，完成大型 Web 應用架構，TypeScript 方案的 Iron-Redux，加 API 服務 Pont。上層特色的服務編排引擎和 SQL 編輯器的深挖，在工具層體驗能力增色不少。在資料消費側，我們緻力于建構以 BI 為搭建資料報表等核心能力，上層特色的資料可視化，資料藝術和資料安全都在各領域有深度貢獻。
下文會重點介紹 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 端渲染平台提供等效的服務。
資料安全
資料産品中有表現力豐富的資料可視化能力、有高效的資料解讀能力，但背後也隐藏着各種各樣的資料安全風險，這些資料可能涉及到交易資料，也可能是行業趨勢資料，這些資料如果發生洩漏被不法分子利用極有可能對集團和客戶造成嚴重的損失，是以資料産品的各個生産環節都需要具備安全防禦方案。
對于整個資料安全體系，從資料生産到資料查詢的鍊路需要做資料脫敏和差分隐私，前端是資料産品向使用者展示和互動的最後一環，也是整個生産鍊路中資料安全保障的最後一環。我們也需要配合全鍊路的資料安全建設，做到事前，事中和事後的保障。
數字水印
數字水印是在事前環節，起到警示、震懾的作用，提醒産品的通路者産品中展現的資料屬于秘密資訊，不可傳播；以及在事後環境，幫助案件追查，當通路者對頁面進行截圖和傳播後，可以準确的定位到案件的當事人，協助案件偵破。傳統的網頁水印方案是在端上直接繪制水印資訊覆寫在文檔流上或作為背景圖檔，但隻要是具備一點前端知識的人都可以通過浏覽器的調試器對水印資訊進行删除甚至是篡改，是以我們要確定水印的真實性和水印的穩固性。
水印生産主要分兩類。明文水印，它是指将可讀的資訊（使用者姓名或其他警示資訊）生成水印圖檔，主要目的是起到警示作用；加密水印，我們團隊和安全專家一同共建的，将水印資訊加密為不同形式的圖檔方案，比較有代表性的是結合了檔案數字水印的理論：點陣水印、隐秘水印、浮雕水印，此類水印的特點是資訊無法被篡改，主要用于案件追蹤。
水印在生産環節進行了加密，由于無法解密，解決了水印的篡改問題。在水印部署過程中需要克服水印被删除的問題，我們針對常見的水印删除手段進行防禦：
- 網絡幹預，阻止頁面擷取水印資源（圖檔和 SDK），對圖檔二進制流和sdk資源下發均采用與業務代碼進行混淆，確定水印部署和業務邏輯執行過程交叉執行，無法單獨中斷
- 環境及 DOM 幹預，通過修改和删除 DOM，對浏覽器的 DOM 和關鍵原生 API進行劫持驗證，確定 DOM 的修改可被監聽和複原，無法複原的情況将中斷業務邏輯
- 融合部署：對于重要的資料資訊，通過 canvas 或圖檔方式渲染替代原有的DOM渲染，此時資料資訊和水印資訊融合為一個原子節點，無法單獨删除
- 資訊差手段：每個資料産品的頁面均混合部署多套水印方案，通過虛實結合（可見水印、不可見水印）的方式確定不法分子無法完全删除掉頁面中的水印
除了以上攻防手段，我們還在進行一些新型水印生産及部署方向的研究，目的是從更本質的方面對水印進行加強同時降低水印對産品的視覺侵入，目前具備可行性的是邊緣水印（将水印的生産和部署在用戶端進行，強化水印和頁面内容的融合）和血緣水印。
資料監控
監控在資料産品中不僅是生産安全的重要部分，同時也是資料安全的重要保障，通常的監控主要關注 JS 報錯和 API 接口報錯，但資料産品需要對資料邏輯進行監控，例如使用者正在分析自己商業資料，突然實時資料顯示利潤劇烈下跌，這很容易造成使用者的恐慌。
我們在完成了監控平台 Clue 的基礎建設上同時也在做很多資料場景的垂直建設：
- 非法環境識别。因為有資料透出，總是有黑灰産不斷生長。他們通過第三方插件爬取資料接口，對資料進行非法彙總和反推，這時就需要對使用者使用産品的浏覽器環境進行檢查，為打擊黑産提供法律依據。針對這種場景我們會對部分原生 API 進行數字指紋加持，通過特征比對，定位非法插件。
- 診斷報警。監控平台中報警的及時性和準确性是重中之重。對于資料展現來說，某些資料趨勢跌 0 對于大客戶和來說一定是出現了問題，但對一些小衆客戶或行業來說，部分名額的跌 0 可能是正常表現。是以，我們需要抽取名額資訊、行業資訊、大促資訊等在内的多種特征對報警模型優化，通過報警資訊的回報機制不斷的對報警模型持續優化，通過模型預測的方式對報警門檻值進行動态調整，促使報警逐漸趨于準确。
寫在最後
未來，資料與智能占據了風口。依靠着雲上計算能力，提供強大的渲染與資料分析能力。在流程研發，分析洞察，科學決策等方面都是體驗技術發揮至關重要力量之處。
倚靠業界和學界前沿方向探索，資料體驗技術圍繞資料應用的全生命周期進行建設和打造，資料的未來是星辰大海，望有志之士一同前來創造未來！期待與你一起用創意與代碼為世界做出些許改變。歡迎交流：[email protected]。
關注「Alibaba F2E」
把握阿裡巴巴前端新動向