導讀 本文將分享現代資料棧中的消費層 BI+AI 產品的演進，從資料棧整體的起源開始，介紹一些資料棧當中的消費層，並展望 BI+AI 的發展趨勢。
全文目錄：
1. 什麼是現代資料棧
2. 現代資料棧中的自助分析
3. Analytics AS Software
4. 增強分析與決策智慧
分享嘉賓｜周遠 觀遠資料 首席科學家
編輯整理｜張了了 聚水潭
出品社群｜DataFun
01
什麼是現代資料棧
1. 傳統資料棧的問題
傳統資料棧的典型架構如上圖所示，企業中會有各種的資料來源，如檔案、資料庫、業務應用等，這些資料透過 ETL 軟體進行處理後漏斗到資料倉儲中，最後再提供給報表或者 BI 等應用。傳統資料棧中最大的一個問題是效能受限、成本很高；在上世紀 90 年代左右，大多數企業都使用類似 MySQL 或 PostgreSQL 這種 OLTP 資料架構做為資料倉儲，當資料量特別大時效能就會出現瓶頸，這時就需要去做一些橫向擴充；也可以去採購一些類似 Teradata 的商用資料庫。因此在當時來看，資料倉儲的軟體及硬體都非常貴，而且效能也不夠好。在這種情況下，資料應用的輸入及輸出都需要做最佳化。輸入需要用 ETL 工具將資料做一些清洗轉換聚合等操作，來減少無效資料；對於報表等輸出層如果併發過大的話也會有效能瓶頸，同時一些自主分析也可能會產生慢 SQL，因此在 BI 層會做快取、查詢最佳化或者建立一些 cube 預計算等最佳化。間接導致了在 ETL 層還是 BI 層使用門檻都很高，軟體需要做的非常複雜才可以支撐某些場景的分析，所以分析人員需要向 IT 部門提申請來滿足自己的分析需求，經過排期處理後才能看到想要的資料，整體流程也很長。從場景來看擴充也比較困難，當資料來源新增加了業務應用時，在數倉既想做視覺化分析、同時也想做資料科學的分析時，在當時這些商用軟體都是一體式的解決方案，因此導致了擴充的侷限性。
資料作為企業競爭力的核心，只有將資料的核心價值發揮出來才能做更好的決策。正是因為之前數倉有諸多侷限，後面出現了大資料、雲原生、AI 等技術來推動數倉向前發展。從 90 年代的 OLTP 到 MPP 架構，到 2010 年代的資料湖、hadoop，這些概念及技術的變化已經可以支撐很大的資料量了。但當時的資料湖儲存的資料還需要做 MapReduce ETL 的工作來將資料導到數倉中去，處理起來比較麻煩，當後面出現了類似 hive 這種框架時，就可以使用 SQL 來做一些批處理。對於實時的互動式查詢還沒法支援，同時消費層做的也不是特別好。到 2016 年左右 Snowflake、Redshift 等雲數倉開始成熟後，效能、擴充性都有了很大的提升後，就可以基於雲數倉架構做一些自助查詢操作，包括後面 Databricks 提出的 Data Lakehouse（湖倉一體）概念，本質上也是想將數倉和資料湖的優勢結合起來。
因為雲數倉的逐漸成熟，在 2020 年左右現代資料棧概念開始興起。當傳統數倉的瓶頸被去掉之後，就可以進行一些模組的拆分；基於雲數倉存算分離的架構，當儲存不夠時就可以只購買 S3 這種的物件儲存，當計算不夠時就可以只買計算資源；同時 ETL 過程可以拆分，E主要是對接各種資料來源，當 API 變更後跟著做一些變更即可，L 是將處理後的資料 load 到數倉中，這兩個過程相對固定，而 Transform 因為後面的應用場景不確定，導致了 T 的不確定性。因此後面提出了可以先將 EL 這兩塊完成，T 這塊分析師在需要做分析的時候再完成。從 ETL 變成了 ELT，這個拆分對後面的敏捷迭代有很大提升。
上圖是 a16z 公司目前的資料棧的架構，中間的 storage 和 Query And Processing 就是提到的存算分離，前面的 Ingestion and Transport 是 EL 層，而 transform 就是在後面一層。當這些元件都拆開後，就類似微服務的概念了，單體應用拆分成多體應用後就會出現很多需求。在我們的資料棧中，EL 和 T 拆開後，當編排也被拆開後，就需要另外的元件來跨元件去協調這些工作，因此源資料就分散在各處，就需要有專門的元件去做監測，裡面有各種元件，就變成了棧。其中圖中一些高亮和灰的部分是為了區分企業在不同的階段的需求不同；在前期只有 BI 需求的時候很多棧的東西就不用放進來，如果都是結構化的資料表只有個 warehouse 就可以了；隨著產品的迭代演進，元件就可以不斷去加，而且元件也可以替換，靈活適配性更強。
從上圖可以看出每個細分的小塊裡面都有大量的創業公司和產品在裡面，也體現了資料發展的趨勢有以下幾點：- 以業務為中心，透過資料的處理去更好的服務業務產生價值；
- 透過 DevOPS 的實踐，DataOps 成為”第一公民”。
現代資料棧中的自助分析
傳統的資料分析流程是業務部門提出問題->向IT部門提出取數需求->資料返回->BI工具製作報表、看板->匯出形成報告->展示給決策者，整個流程鏈路比較長，而且最後如果決策者對資料提出疑問後，可能迭代數月才能解決業務問題，因此傳統資料分析的痛點是：
當前理想情況下的資料分析流程是提出業務問題後->在資料分析產品中搜尋相應關鍵詞->選擇經過認證的相關資料->自助式分析->開發“資料故事”，嵌入業務系統->與決策者會面討論，會上即時分析->快速形成決策；整體流程可能在數小時就能完成，為了達到這樣理想的狀態，需要實現以下幾點：- 基礎能力：融入現代技術棧，基於雲原生架構發揮雲端計算的優勢
- 資料管控：合理的資料治理及資料管控，業務可以信任資料
決策閉環：從分析為主到資料驅動決策全流程支援
Analytics as Software
人們收集到的資料核心還是希望資料能發揮價值，從生活中的很多例子可以看出人們已經用資料在做決策了；上圖左邊的場景看人們吃飯的時候可能會先開啟大眾點評，然後根據附近餐廳各個維度的評分來進行篩選，當根據評分產生判斷後，就會產生去哪家餐廳的決策，並直接可以在 APP 裡完成直接訂座並叫車。從上圖右邊的場景來看，如果是想開飯店的話，用 APP 做分析就比較困難了，這時就需要像 dashboard 這種視覺化的東西來展示出附件的餐廳數、消費水平、服務指標等來滿足決策的目的。因此 IT 部門就可以主動的去打造這種一體化的資料產品，從而最佳化使用者體驗，同時可以完成決策流程的閉環。
資料產品的典型使用者一般分為 4 種，最上面的業務決策者和業務分析師只要做業務監控和決策；到更復雜的業務問題時，需要業務分析師來進行互動式探索分析；最下面的兩類人偏向做開發，完成資料和演算法的建模。
對於開發者而言，從原來的瀑布式開發要轉換為敏捷開發，需要讓整個開發流程更高效起來；同時 API-first 設計的時候，需要有非常好的開放性和可組合性來滿足可以在各種場景把同一份資料提供出去；基於程式碼開發還是 GUI 操作也是值得討論的話題，傳統的 ETL 開發工具為了更加易用會做成視覺化，而有的則提倡程式碼為中心完成 Transform，兩種方式各有優劣；如果把看板當做是分析軟體來看的話，外掛化的架構來形成資料的應用市場，可以讓整個生態做的非常豐富。
從程式碼來看，不同開發者在不同的場景下使用的程式語言也是不同的，類似data transform 相對固定的場景，可以直接使用 DSL 語言來完成；而資料科學的開發，則需要使用像 python 這種更通用的程式語言。而在資料產品中，目前大多數使用的還是 DSL 形式為主。至於程式碼和低程式碼的區別是程式碼有很高的靈活度和表達能力，可以做很多軟體工程上的實踐，可以實現包括版本控制、自動化測試、code review 等；而低程式碼入門門檻很低，但是擴充性和靈活性就差很多。兩者並不衝突，相反可以互相補充，如上圖是產品名為 looker 的 BI 軟體，透過視覺化的拖拉拽就可以實現對應的效果，而底層透過程式碼來實現，並透過程式碼的版本控制來實現敏捷迭代，最終提高使用者的使用體驗。增強分析與決策智慧
對於上層使用者體驗來說，會涉及到增強分析和決策智慧。而看板和大屏這種對於使用者的體驗來說是有門檻的，使用者怎麼理解資料，怎麼操縱資料需要有一個複雜的流程，可能需要很長時間的培訓才能看懂。使使用者理解資料最自然的方式是不斷提升企業裡面資料分析的滲透率，從開始 10% 的分析師用，要提升到 35% 包括更多業務人員用的時候就需要往 TOC 的體驗去演進，演進最直接的方式就是有互動，可以在看板上搜尋和推薦。類似在看板上問一個問題，就可以直接展示對應的圖表，或者說軟體對已經使用了一段時間的使用者應該看什麼資料可以直接進行推送，告訴使用者要基於這些資料做什麼處理，同時支援場景化和個性化配置，可以定時定製化推送報告，這樣不僅能很好的提升使用者體驗，而且還能降低使用者使用門檻。
當使用傳統的方式判斷商品的銷量變化時，一開始只有門店和商品兩個影響因子，則需要根據這兩個影響因子交叉組合生成各種報表來進行分析；當影響因子有三個、四個的時候，這時候各種組合的報表的數量是巨大的，需要根據這些報表來找到影響業務變化的因素所花的時間也是很多的。而目前的產品則可以透過一些演算法找到報表中最關注的點並進行推送，這樣就可以大大降低使用者的門檻，同時可以節省很多時間。推送的內容可以是有趣的資料故事，透過讀故事可以很直觀的瞭解整個發生的事情，關注到需要在哪些方面做改進，極大的提升了使用者的使用體驗。
對於分析能力來說，也可以做各種進階，從原先的基於歷史資料的分析，到後面的未來預測類分析。而這種能力的擴充，則需要 AI 技術的加持來實現。我們經常提到的決策智慧也分為兩個維度來看，從上面大眾點評的例子來看，選中了餐廳後提供了叫車的按鈕可以直接去叫車，就是分析和決策結合在一起了，流程更加自動化；而目前出現的反向 ETL，將分析完的資料再反向寫回到業務系統中來對業務產生價值，對決策也會起到很大的幫助；而推薦系統不需要人工干預就會根據不同的使用者生成個性化的推薦也體現了決策智慧。對於這種增強分析的產品，需要具備模型開發能力、模型解釋能力及模型運維的能力，而機器學習更多的是從資料出發去做一些統計，當需要更多的和決策結合的時候則需要具備因果推理、模擬最佳化、知識圖譜等能力，需要更實時的資料分析時 OPEN API 和 Reverse ETL 能力要提升。廣告與提問環節
觀遠在實踐過程中也做了很多探索，一步一步的把產品的分析成熟度提升。- 支援雲原生，並且開發出雲巡檢來檢查各種資料的處理、運算所消耗的計算資源，來節省最佳化企業雲資源的開銷
- 多使用者角色的支援，同時支援 no-code 和 full-code
- 開放資料應用市場能力，使用者可以搭建各種資料應用，做到開箱即用；
- 開放API，提供API能力支援業務系統中涉及到的決策場景；
- 增強分析，透過資料洞察可以發現資料異常點並推送，產生決策建議；
資料安全、資料質量及資料管控。
A1：透過可觀測性來進行資料質量的校驗，可觀測性體現在業務中的資料的使用者隔離、資料表的總覽及資料的血緣，對剛載入進來的資料進行檢查，如果發現有大的波動變化，結合資料血緣就可以提早介入。A2：借鑑 The Self-Service Data Roadmap 這本書中來說，資料整個應用的流程分成了四個步驟，然後每個步驟裡面它都做了一些評分卡的設定，你可以根據企業的現狀去做一個打分，打完分之後，接下來再基於這個這現狀基礎上做一些提升，這樣的話整體可以去評估對企業資料產生的價值、鏈路的時效性、以及人工成本的效率等。Q3：產品介面問答返回結果是透過 NLP 實現的嗎？A3：目前 ThoughtSpot 這塊做的比較好，我們直觀的理解返回結果是透過 NLP 實現的，但是 ThoughtSpot 底層使用的是偏編譯器的技術，去解析自然語言中的某些關鍵詞，透過對映到實體領域上然後做編譯的轉換再形成具體的查詢。，而在資料分析領域中的問答問題相當複雜，感興趣的同學可以去看下分享。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2933399/，如需轉載，請註明出處，否則將追究法律責任。