鑽石舞台

‍一 前言

3 頁面概覽

二 數據平台到底要做個啥？

所以建設高度自動化&體系化的知識管理系統，重構知識的供給模式，到底是啥意思？

解釋清楚這個目標，只需要解釋清楚如下兩個問題：

「數據」是如何影響「業務決策」的？

數據」影響「決策」的過程中，有哪些問題和機會？

問題一：「數據」如何影響「業務決策」？數據生產消費生命周期

現實世界中，我們可以把數據的生命周期抽象成5個部分：「事實->信息->知識->智慧->決策&行動->回到事實」。下面給出我個人理解的每個部分的含義：

事實：代表數據被如實的記錄（ODS），事實是龐雜冗餘無意義的。只有通過分類和清洗才能得到對人有意義的信息。

信息：代表事實中是有意義的部分（DWD + DIM），信息是對一類事實情況的描述。而當信息通過業務的定義與提煉加工，就能生產出有用的知識。

知識：代表信息加工出的有用的部分我稱之為知識（ADS）。比如巴菲特是股神這是信息。而買qqq對與普通人來說整體收益不從不錯，可以考慮月供qqq，這是知識。

智慧：不同的知識相互碰撞，演繹，推導能產生新的知識，我們稱這種為智慧，智慧是能預測未來的。借用我的好友@骨玉(zherui.lzr)的總結：知識是有用的，而智慧是能預測未來的！

決策/行動：通過智慧，了解未知，研判未來，做出決策，行動落地，從而產生新的事實結果，進入下一輪循環。

舉個例子

吾有一友，名叫老王，不住隔壁。

老王有座山，山上有野花，野草，雞，蘋果等各種動植物（事實）。其中雞和蘋果比較有價值，於是老王就把他們圈起來養殖（從事實中梳理出有價值的信息）。並定時餵食施肥除蟲，後來雞和蘋果都順利長大成熟，成為了能吃，能賣的農產品（信息加工成了有用的知識）。後來老王又發現雞比蘋果利潤高很多，如果只養雞能多賺50%（知識推演出可預測未來的智慧）。於是第二年他決定只養雞（決策/行動）。後來禽流感來襲，山頭只剩野花了，老王血本無歸，一盤算還是出租穩當，於是老王把山一租，又回來寫代碼了。（第二輪數據的生產消費閉環）

這個故事中：

老王山頭上的各種動植物就是事實：事實的核心要求是全面真實，而核心行為是採集記錄。

動植物中的雞和蘋果就是信息：信息的核心要求是有意義，而核心行為上是梳理和清洗。

把雞和蘋果養殖大就是知識：知識的核心要求是有價值有用，而核心行為上是加工和提煉。可以自己吃轉化成身體的養分，也可以賣錢投資再生產。這是對老王有用的。在數據中就是指標了。

老王發現養雞更賺錢就是智慧：智慧的核心要求是可預測未知，而核心行為是使用知識進行演繹推導。

最終只養雞就是決策/行動：決策和行動將產生新的事實，進入下一輪循環。

老王的故事

數據生命周期

核心要求

核心行為

對應數據開發

山頭上的各種動植物

事實

全面真實

採集記錄（養數據）

埋點採集

動植物中的雞和蘋果

信息

有意義

梳理清洗（理數據）

數據清洗

把雞和蘋果養殖成能吃，能賣的農產品

知識

有用有價值

提煉加工（生產指標）

指標生產

老王發現養雞更賺錢

智慧

能推演未來

演繹推導（用數據）

業務決策

最終決定只養雞

決策/行動

執行落地

那我們來試着回答一下第一個問題：「數據」如何影響「業務決策」？

答：首先我們通過埋點採集得到原始的事實（實時數據），從事實中梳理清洗得到信息（明細），隨後通過定義和加工融合各類維度（維度），能得到對應的知識（業務指標）。而用戶通過各類途徑獲得到指標後，通過演繹推導等方法，預測業務的發展，然後並做出下一步的決策。

問題二：「數據」影響「決策」的過程中，有哪些問題和機會？

我們簡化一下：

我們把事實梳理成信息，信息加工成知識的整個過程，稱為知識生產。

通過智慧預測未來，影響業務決策的過程，稱為業務決策。

而知識管理，沉澱，運輸，供給等中間環節，稱之為知識供給和知識獲取。

這裡面的每個部分，其實都存在問題，也包含了很多的機會。

知識生產：缺乏標準化&自動化的工程體系來生產指標

問題：

缺乏標準化協議

需求流程標準

數倉分層標準

計算模型標準

缺乏自動化能力

需求吞吐瓶頸：純研發人肉開發，存在研發資源瓶頸，需求吞吐量跟不上業務發展速度，業務訴求無法得到及時滿足。我們希望80%的以上指標自動化生產。

計算存儲資源浪費：每個Project都存在非常多相同指標重複開發的情況。這就導致了指標的重複計算，重複存儲，浪費資源，浪費錢。

解法：建立一套標準化自動化的工程體系去自動化的生產指標。並以此為基礎拓展進行知識的供給。

知識供給：缺少體系化的數據資產管理能力。

問題：

數據指標失真：業務常常會發現指標不對，或者之前對，最近突然不對了。更有甚者根本不知道指標對不對。導致大家對指標失去信賴，徒增非常多的溝通成本。

數據資產管理混亂：一個指標好多人在生產，指標的信息存放在各種地方，信哪個？SQL是腳本語言，代碼可謂千人千面，沒有標準注釋，同事離職交接時的體驗尤為酸爽。

數據資產不透明：DAU，研發效能如何定義？知道定義後，那對應的表和字段是什麼？哪裡可以查嘛？同時算子，維度，範圍等配置明明都是一樣的，但生產時卻無法復用。

解法：需要體系化的管理指標並保證指標的準確性。當然這個重度依賴標準化&自動化的知識生產能力。

知識獲取：知識獲取效率低下

問題：

指標獲取效率低下：運營有數據訴求，不知道去哪裡獲取。知道哪裡獲取後常常也要等待研發處理，獲取的效率低下。

口徑獲取效率低下：研發同學常常有了解口徑的訴求，一樣不知道去哪裡查看。

解法：提供統一的獲取指標與口徑的門戶，進一步可以初步實現自動化的需求分析。

業務決策：缺乏有效的工具和方法論支撐。

問題：

不知該用哪些指標：不知如何使用指標，不知哪個指標能反應真實的業務效果，不知如何分析業務的北極星指標是啥？

不知如何影響指標：不知道有哪些措施和行為能影響指標。

解法：需要提供豐富的數據應用，與有效數據方法論。

可以看到大部分溝通無非兩件事

告訴我口徑！：PHA輕應用是什麼？應用數，DAU，可交互時長和研發效率數據都是怎麼定義的？來源UV怎麼計算？？

把指標給我！：指標在哪裡？具體Sql邏輯是啥？

通過平台自動化生成後，可以通過如下方式自行獲取：

除了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）

文件創建

視圖轉表Sql生成

配置+提交+部署

調度運維

外表同步

核心挑戰：性能

性能是自動化指標產出的難點，也會是之後的亮點。我們希望通過平台生成指標的效率能最大程度的接近開發人員手動優化的性能。當然這往深了做，是一個可以無限探索下去的領域。拿平台來講，目前最大的瓶頸在多維分析的支持，我們支持了維度的全量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。當然平台目前仍處於做大做深的階段，距離能力健全，體驗優秀還有很長很長的路要走（需要很多的人力去堆）。

都說數據越開放，產生的價值越高。所以平台雖然還稚嫩，但我對平台的價值堅信不疑，大家一起繼續打磨，繼續加油。

參考資料

《泛化建模&維度建模》：https://www.aisoutu.com/a/919936

《數據，信息，知識，智慧分析與對比》：https://blog.sciencenet.cn/blog-39263-703361.html

《阿里雲各類開放文檔》：https://help.aliyun.com/document_detail/175553.html?spm=a2c4g.11174283.6.1296.386f2b65FoogOr#title-1sy-s0n-5f9

‍

‍

業務&用戶體驗可觀測場景解讀

點擊閱讀原文查看詳情