重构知识的供给模式 ——《数据平台》从思考到落地
簡介：如何去建立一套 “高度自動化&體系化的知識管理系統，重構知識的供給模式”。是不是看不懂？而且有點沖？是不是謎語人附體？別急，本文作者將會做詳細的說明。
作者 | 七惜
來源 | 阿里技術公眾號
一 前言
我們想嘗試去建立一套 “高度自動化&體系化的知識管理系統，重構知識的供給模式”。
是不是看不懂？而且有點沖？是不是謎語人附體？別急，下面我會詳細的說明我想做啥和已經做了啥。
1 平臺現狀
階段分析
孵化一個Idea，到產品最終簡單易用，通常會經歷三個階段。
階段一：做通做對
階段意義：對idea和方案的有效性與合理性進行驗證探索。這個階段一般資源很少，也比較孤獨。不過如果順利解決了核心問題，那系統將初具業務價值。
階段產品：小程序數據平臺 （DONE 交付500+指標）
階段二：做大做深
階段意義：開始在初版的基礎上，去做邊界的探索。通過接入更多的場景，更大范圍的解決業務問題，來打磨方案，拓寬能力邊界并摸索沉淀下最優實踐。
階段產品：Foundry基礎數據平臺 ING
階段三：做精做好
階段意義：這是做減法和重構的過程，通過前面的探索，清晰的定義下系統的邊界，并對交互和性能等方面做更深的耕耘。
階段產品：業務數據平臺 Prepare
階段成果
目前Idea正經歷第二階段，在手淘進行更大范圍的探索與落地。
業務支撐：支撐手淘4個域9個模塊的229個指標的數據產出（全鏈路AB實驗，apm啟動性能，廣告大盤，購物車，首頁坑位，搜索結果頁，手淘穩定性等）。同時也遷移生產了生態開放小程序，小部件相關的數據。
能力建設：在《小程序數據平臺》的基礎上，進一步針對自動化構建能力進行了補強；數據資產管理方面擴充了多租戶，資產隔離，文件管理等能力，方便我們更好的管理指標； 同時也進行了一些數據應用的探索，如數據開發服務，即席查詢能力等。
2 整體架構
3 頁面概覽
二 數據平臺到底要做個啥？
所以建設高度自動化&體系化的知識管理系統，重構知識的供給模式，到底是啥意思？
解釋清楚這個目標，只需要解釋清楚如下兩個問題：
問題一：“數據”如何影響“業務決策” ？
數據生產消費生命周期
現實世界中，我們可以把數據的生命周期抽象成5個部分：“事實->信息->知識->智慧->決策&行動->回到 事實”。下面給出我個人理解的每個部分的含義：
舉個例子
吾有一友，名叫老王，不住隔壁。
老王有座山，山上有野花，野草，雞，蘋果等各種動植物（事實）。 其中雞和蘋果比較有價值，于是老王就把他們圈起來養殖（從事實中梳理出有價值的信息）。并定時喂食施肥除蟲，后來雞和蘋果都順利長大成熟，成為了能吃，能賣的農產品（信息加工成了有用的知識）。 后來老王又發現雞比蘋果利潤高很多，如果只養雞能多賺50%（知識推演出可預測未來的智慧）。于是第二年他決定只養雞（決策/行動）。后來禽流感來襲，山頭只剩野花了，老王血本無歸，一盤算還是出租穩當，于是老王把山一租，又回來寫代碼了。（第二輪數據的生產消費閉環）
這個故事中：
- 老王山頭上的各種動植物就是事實：事實的核心要求是全面真實，而核心行為是采集記錄。
- 動植物中的雞和蘋果就是信息：信息的核心要求是有意義，而核心行為上是梳理和清洗。
- 把雞和蘋果養殖大就是知識：知識的核心要求是有價值有用，而核心行為上是加工和提煉。可以自己吃轉化成身體的養分，也可以賣錢投資再生產。這是對老王有用的。 在數據中就是指標了。
- 老王發現養雞更賺錢就是智慧：智慧的核心要求是可預測未知，而核心行為是使用知識進行演繹推導。
- 最終只養雞就是決策/行動：決策和行動將產生新的事實，進入下一輪循環。
那我們來試著回答一下第一個問題：“數據”如何影響“業務決策” ？
答：首先我們通過埋點采集得到原始的事實（實時數據），從事實中梳理清洗得到信息（明細），隨后通過定義和加工融合各類維度（維度），能得到對應的知識（業務指標）。而用戶通過各類途徑獲得到指標后，通過演繹推導等方法，預測業務的發展，然后并做出下一步的決策。
問題二：“數據”影響“決策”的過程中，有哪些問題和機會？
我們簡化一下：
我們把事實梳理成信息，信息加工成知識的整個過程，稱為知識生產。
通過智慧預測未來，影響業務決策的過程，稱為業務決策。
而知識管理，沉淀，運輸，供給等中間環節，稱之為知識供給和知識獲取。
這里面的每個部分，其實都存在問題，也包含了很多的機會。
知識生產：缺乏標準化&自動化的工程體系來生產指標
問題：
1、缺乏標準化協議
- 需求流程標準
- 數倉分層標準
- 計算模型標準
2、缺乏自動化能力
- 需求吞吐瓶頸：純研發人肉開發，存在研發資源瓶頸，需求吞吐量跟不上業務發展速度，業務訴求無法得到及時滿足。我們希望80%的以上指標自動化生產。
- 計算存儲資源浪費：每個Project都存在非常多相同指標重復開發的情況。 這就導致了指標的重復計算，重復存儲，浪費資源，浪費錢。
解法：建立一套標準化自動化的工程體系去自動化的生產指標。并以此為基礎拓展進行知識的供給。
知識供給：缺少體系化的數據資產管理能力。
問題：
解法：需要體系化的管理指標并保證指標的準確性。當然這個重度依賴標準化&自動化的知識生產能力。
知識獲取：知識獲取效率低下
問題：
解法：提供統一的獲取指標與口徑的門戶，進一步可以初步實現自動化的需求分析。
業務決策：缺乏有效的工具和方法論支撐。
問題：
解法：需要提供豐富的數據應用，與有效數據方法論。
可以看到大部分溝通無非兩件事
通過平臺自動化生成后，可以通過如下方式自行獲取：
除了Sql表達式直觀明了外，還能在元數據管理中查看每個配置的含義（當然目前交互聯動還做的不夠好，人不夠呀）。因為指標是通過各配置直接生成的，所以也可以保證口徑與數據是強一致的。
至此可以回答一下數據平臺到底要做個啥？： 核心是通過標準化的數倉分層建設，利用平臺自動化的生產，管理和交付數據（知識)。并沉淀算子，統計范圍，維度等數據資產。
業務視角上：將統一通過基礎數據平臺生產和獲取指標，查詢口徑，并與其他系統進行聯動。只要有一點Sql基礎的運營/PD等都能自助配置出新的指標，打破純研發純人肉生產指標的瓶頸。這就是所謂的“高度自動化&體系化的知識管理系統，重構知識的供給模式”。
不知道各位理解了沒有。對于要做什么，我就介紹這么多了......下面來大致介紹一下核心能力的具體落地方案。
三 數據平臺核心技術簡介
回到技術上，我們的能力建設也是圍繞這4點去搞。
1 知識生產—數據自動化生產能力建設
核心流程概覽：
指標的生成（5步）
1）數倉分層建設（kimball維度建模-星型模型）：
- 事實：以明細為粒度進行數據域拆分，如2001瀏覽域，2101點擊域，2201曝光域，交易域，來源去向域，業務統計域，其他業務域等等。
- 維度：錄入相關的Dim維表
2）關系染色RelationColoring
- 明細事實表和維表的主鍵關系。
3）維度染色DimensionColoring
- 動態填充需要的維度字段（非全量冗余，可以靈活適應維表的變更）
- 通過RelationColoring & DimensionColoring可以完全屏蔽了復雜的關聯操作Join。
4）結果組裝AssembleIndicator
- 標準Sql生產：CREATE VIEW AS SELECT “Operate算子，stat統計包” FROM “ColoringView染色視圖” WHERE "Scope統計范圍" GROUP BY "PeriodDim周期維度 & Dim業務維度"。
5）數據探查IndicatorResult
- 起Odps任務 SELECT * FROM Indicator WHERE dim LIMIT xxx; 得到結果后存入緩存，便于用戶進行數據探查。
復合指標生成（3步，將多個單指標融合成單一報表）
1）指標圈選
2）復合指標生成
可以理解成將多張表合并為1張。這一直是難題，因為普通報表在生成之時就丟失了所有的過程邏輯，即使存下來的也只是工程端無法規模化解析的非結構化信息。 而平臺自動化生成的指標就剛好解決了這個問題。這也讓指標合并成為了可能。
維度能力：
-
多指標交&并集處理
- 維度圈選能力（黑白名單）
- 多維cube：
- 精確維度組合：
-
維度缺省值處理（處理cube后數據異常膨脹和整體維度統計值因null失準的問題）
- 事實字段為Null處理
- 各類型字段的默認缺省值設置。
- 維表字段為Null處理
- Left Join 維度缺值導致的Null處理。
指標拼接：
- 行 -> 列 -> 行 （行存轉列存，分離出算子詳細Name與Value. 再列存轉行存生成可用的大寬表）
3）數據探查
指標物化&服務（依賴OpenDataworks的開放能力，注意申請流程和QPS）
核心挑戰：性能
性能是自動化指標產出的難點，也會是之后的亮點。我們希望通過平臺生成指標的效率能最大程度的接近開發人員手動優化的性能。當然這往深了做，是一個可以無限探索下去的領域。 拿平臺來講，目前最大的瓶頸在多維分析的支持，我們支持了維度的全量Cube，而想要更好的性能則需要去配置精準的Grouping Sets，而這又會大大增加前臺頁面的配置成本，如何權衡呢？是用針對高級用戶提供獨立的高級配置還是什么方法？ 我們也還在進一步探索。
2 知識供給—資產管理能力建設
7大資產管理：
1）指標2個：
- CompositeIndicator 復合指標 ：
- Indicator 原子指標
2）元數據5個：
-
Operate 算子
- 基礎算子
- stat統計包（均值，標準差，方差）
-
Dim維度
- Dim（業務維度）
- PeriodDim（周期維度）
- Scope 統計范圍
- Domain 數據域/數據模型
- Table 基礎表
多租戶管理：
-
空間管理
- 工程配置
- Odps配置
- Dataworks配置
- Holo配置等
- 人員管理
- 資產隔離 （開發中）
-
權限管控
- 元數據權限
- 文件權限
- 視圖權限
- 表權限等
數據能力管理：
- 即席查詢
-
數據開放
- 開放接口
- 指標與其口徑詳情查詢
- 指標變更消息
3 知識獲取：統一的知識獲取門戶（設計中）
這塊我認為非常非常重要，是可以用小成本撬動平使用體驗的大幅提升，也有可能成為平臺核心入口。應該在能力建設的同時，重點開發的方向。但是吧！這塊目前還沒有具體的產品形態，我有一些初步的設想和方案，后續和產品一起設計后最終方案再具體補充：
我希望設計一個統一的門戶頁面，當任何用戶有口徑問題和數據需求時，可以先到該頁面進行對應的關鍵詞的搜索。平臺通過智能識別，返回給用戶具體指標，算子，統計范圍和維度的推薦信息。有指標能直接用最好，沒有也可以根據口徑信息自行配置所需的指標。
技術側：平臺數據資產同步到至搜索引擎，當然還有三個核心處理技術點處理一下1：關鍵字提取與分詞規則 2：搜索結果FunctionScore加權 3:結果分類引導。
4 業務決策：有效的工具和知識使用方法的方法論支撐
說實話，優先級上，還沒到這塊的輪次。 因為業務千變萬化，也許這就是個偽命題。 不過從技術側來看，業務決策功能是屬于應用層的范疇，搭建好了底層基礎，上層的千變萬化都是能靈活快速的進行支持的，我們將一邊夯實基礎，一邊與業務方一起探索具體等場景。
5 其他：
關于優化：我認為幾個比較核心的優化方向
1、知識門戶
2、指標管理與元數據的聯動
3、核心鏈路運維與逆向流程
4、性能。
關于能力供給：平臺本身目前只針對內部白名單進行使用，等我們打磨到自己滿意了會進一步開放。 當然設計之初核心能力與應用層就是解耦的，所以也有可能之后會將核心能力以SDK的形式進行開放，各業務方按需進行形態的建設。敬請期待～
四 小結
技術細節還有很多很多，篇幅限制，這里就大致介紹一下核心要做的事情。能完成一個Idea的探索，并有機會和大家分享進一步思考探索優化落地，還是挺有成就感的，也收獲頗豐，起碼從一個純JAVA工程同學成為了數據Project的獨立Owner。當然平臺目前仍處于做大做深的階段，距離能力健全，體驗優秀還有很長很長的路要走（需要很多的人力去堆）。
都說數據越開放，產生的價值越高。所以平臺雖然還稚嫩，但我對平臺的價值堅信不疑，大家一起繼續打磨，繼續加油。
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的重构知识的供给模式 ——《数据平台》从思考到落地的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 全员学习低代码，一汽大众领跑数智化转型背
- 下一篇： 基于 MaxCompute 的实时数据处