重構知識的供給模式——《資料平臺》從思考到落地

一  前言

我們想嘗試去建立一套 “高度自動化&體系化的知識管理系統,重構知識的供給模式”。
是不是看不懂?而且有點衝?是不是謎語人附體?別急,下面我會詳細的說明我想做啥和已經做了啥。

1  平臺現狀

階段分析

孵化一個Idea,到產品最終簡單易用,通常會經歷三個階段。
階段一:做通做對
階段意義:對idea和方案的有效性與合理性進行驗證探索。這個階段一般資源很少,也比較孤獨。不過如果順利解決了核心問題,那系統將初具業務價值。
階段產品:小程式資料平臺 (DONE 交付500+指標)
階段二:做大做深
階段意義:開始在初版的基礎上,去做邊界的探索。透過接入更多的場景,更大範圍的解決業務問題,來打磨方案,拓寬能力邊界並摸索沉澱下最優實踐。
階段產品:Foundry基礎資料平臺 ING
階段三:做精做好
階段意義:這是做減法和重構的過程,透過前面的探索,清晰的定義下系統的邊界,並對互動和效能等方面做更深的耕耘。
階段產品:業務資料平臺 Prepare

階段成果

目前Idea正經歷第二階段,在手淘進行更大範圍的探索與落地。
業務支撐:支撐手淘4個域9個模組的229個指標的資料產出(全鏈路AB實驗,apm啟動效能,廣告大盤,購物車,首頁坑位,搜尋結果頁,手淘穩定性等)。同時也遷移生產了生態開放小程式,小部件相關的資料。
能力建設:在《小程式資料平臺》的基礎上,進一步針對自動化構建能力進行了補強;資料資產管理方面擴充了多租戶,資產隔離,檔案管理等能力,方便我們更好的管理指標; 同時也進行了一些資料應用的探索,如資料開發服務,即席查詢能力等。

2  整體架構

3  頁面概覽

二  資料平臺到底要做個啥?

所以建設高度自動化&體系化的知識管理系統,重構知識的供給模式,到底是啥意思?
解釋清楚這個目標,只需要解釋清楚如下兩個問題:
  1. “資料”是如何影響“業務決策”的?
  2. 資料”影響“決策”的過程中,有哪些問題和機會?

問題一:“資料”如何影響“業務決策” ?

資料生產消費生命週期

現實世界中,我們可以把資料的生命週期抽象成5個部分:“事實->資訊->知識->智慧->決策&行動->回到 事實”。下面給出我個人理解的每個部分的含義:
  1. 事實:代表資料被如實的記錄(ODS),事實是龐雜冗餘無意義的。只有透過分類和清洗才能得到對人有意義的資訊。 
  2. 資訊:代表事實中是有意義的部分(DWD + DIM),資訊是對一類事實情況的描述。而當資訊透過業務的定義與提煉加工,就能生產出有用的知識。 
  3. 知識:代表資訊加工出的有用的部分我稱之為知識(ADS)。比如巴菲特是股神這是資訊。而買qqq對與普通人來說整體收益不從不錯,可以考慮月供qqq,這是知識。
  4. 智慧:不同的知識相互碰撞,演繹,推導能產生新的知識,我們稱這種為智慧,智慧是能預測未來的。借用我的好友@骨玉(zherui.lzr)的總結:知識是有用的,而智慧是能預測未來的!
  5. 決策/行動:透過智慧,瞭解未知,研判未來,做出決策,行動落地,從而產生新的事實結果,進入下一輪迴圈。

舉個例子

吾有一友,名叫老王,不住隔壁。
老王有座山,山上有野花,野草,雞,蘋果等各種動植物(事實)。 其中雞和蘋果比較有價值,於是老王就把他們圈起來養殖(從事實中梳理出有價值的資訊)。並定時餵食施肥除蟲,後來雞和蘋果都順利長大成熟,成為了能吃,能賣的農產品(資訊加工成了有用的知識)。 後來老王又發現雞比蘋果利潤高很多,如果只養雞能多賺50%(知識推演出可預測未來的智慧)。於是第二年他決定只養雞(決策/行動)。後來禽流感來襲,山頭只剩野花了,老王血本無歸,一盤算還是出租穩當,於是老王把山一租,又回來寫程式碼了。(第二輪資料的生產消費閉環)
這個故事中:
  • 老王山頭上的各種動植物就是事實:事實的核心要求是全面真實,而核心行為是採集記錄。
  • 動植物中的雞和蘋果就是資訊:資訊的核心要求是有意義,而核心行為上是梳理和清洗。
  • 把雞和蘋果養殖大就是知識:知識的核心要求是有價值有用,而核心行為上是加工和提煉。可以自己吃轉化成身體的養分,也可以賣錢投資再生產。這是對老王有用的。 在資料中就是指標了。
  • 老王發現養雞更賺錢就是智慧:智慧的核心要求是可預測未知,而核心行為是使用知識進行演繹推導。
  • 最終只養雞就是決策/行動:決策和行動將產生新的事實,進入下一輪迴圈。
老王的故事
資料生命週期
核心要求
核心行為
對應資料開發
山頭上的各種動植物
事實
全面真實
採集記錄(養資料)
埋點採集
動植物中的雞和蘋果
資訊
有意義
梳理清洗(理資料)
資料清洗
把雞和蘋果養殖成能吃,能賣的農產品
知識
有用有價值
提煉加工(生產指標)
指標生產
老王發現養雞更賺錢
智慧
能推演未來
演繹推導(用資料)
業務決策
最終決定只養雞
決策/行動
執行落地
那我們來試著回答一下第一個問題:“資料”如何影響“業務決策” ?
 答:首先我們透過埋點採集得到原始的事實(即時資料),從事實中梳理清洗得到資訊(明細),隨後透過定義和加工融合各類維度(維度),能得到對應的知識(業務指標)。而使用者透過各類途徑獲得到指標後,透過演繹推導等方法,預測業務的發展,然後並做出下一步的決策。

問題二:“資料”影響“決策”的過程中,有哪些問題和機會?

我們簡化一下:
我們把事實梳理成資訊,資訊加工成知識的整個過程,稱為知識生產。   
透過智慧預測未來,影響業務決策的過程,稱為業務決策。   
而知識管理,沉澱,運輸,供給等中間環節,稱之為知識供給和知識獲取。
這裡面的每個部分,其實都存在問題,也包含了很多的機會。

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

問題:
  1. 缺乏標準化協議
    1. 需求流程標準
    2. 數倉分層標準
    3. 計算模型標準
  2. 缺乏自動化能力
    1. 需求吞吐瓶頸:純研發人肉開發,存在研發資源瓶頸,需求吞吐量跟不上業務發展速度,業務訴求無法得到及時滿足。我們希望80%的以上指標自動化生產。
    2. 計算儲存資源浪費:每個Project都存在非常多相同指標重複開發的情況。 這就導致了指標的重複計算,重複儲存,浪費資源,浪費錢。

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

知識供給:缺少體系化的資料資產管理能力。

問題:
  1. 資料指標失真:業務常常會發現指標不對,或者之前對,最近突然不對了。更有甚者根本不知道指標對不對。導致大家對指標失去信賴,徒增非常多的溝通成本。
  2. 資料資產管理混亂:一個指標好多人在生產,指標的資訊存放在各種地方,信哪個?SQL是指令碼語言,程式碼可謂千人千面,沒有標準註釋,同事離職交接時的體驗尤為酸爽。
  3. 資料資產不透明:DAU,研發效能如何定義? 知道定義後,那對應的表和欄位是什麼?哪裡可以查嘛? 同時運算元,維度,範圍等配置明明都是一樣的,但生產時卻無法複用。
解法:需要體系化的管理指標並保證指標的準確性。當然這個重度依賴標準化&自動化的知識生產能力。

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

問題:
  1. 指標獲取效率低下:運營有資料訴求,不知道去哪裡獲取。知道哪裡獲取後常常也要等待研發處理,獲取的效率低下。
  2. 口徑獲取效率低下:研發同學常常有了解口徑的訴求,一樣不知道去哪裡檢視。
解法:提供統一的獲取指標與口徑的門戶,進一步可以初步實現自動化的需求分析。

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

問題:
  1. 不知該用哪些指標:不知如何使用指標,不知哪個指標能反應真實的業務效果,不知如何分析業務的北極星指標是啥?
  2. 不知如何影響指標:不知道有哪些措施和行為能影響指標。
解法:需要提供豐富的資料應用,與有效資料方法論。
可以看到大部分溝通無非兩件事
  • 告訴我口徑!:PHA輕應用是什麼?應用數,DAU,可互動時長和研發效率資料都是怎麼定義的?來源UV怎麼計算??
  • 把指標給我!:指標在哪裡?具體Sql邏輯是啥?
透過平臺自動化生成後,可以透過如下方式自行獲取:
除了Sql表示式直觀明瞭外,還能在元資料管理中檢視每個配置的含義(當然目前互動聯動還做的不夠好,人不夠呀)。因為指標是透過各配置直接生成的,所以也可以保證口徑與資料是強一致的。
至此可以回答一下資料平臺到底要做個啥?: 核心是透過標準化的數倉分層建設,利用平臺自動化的生產,管理和交付資料(知識)。並沉澱運算元,統計範圍,維度等資料資產。
業務視角上:將統一透過基礎資料平臺生產和獲取指標,查詢口徑,並與其他系統進行聯動。只要有一點Sql基礎的運營/PD等都能自助配置出新的指標,打破純研發純人肉生產指標的瓶頸。這就是所謂的“高度自動化&體系化的知識管理系統,重構知識的供給模式”。
不知道各位理解了沒有。對於要做什麼,我就介紹這麼多了……下面來大致介紹一下核心能力的具體落地方案。
三  資料平臺核心技術簡介
回到技術上,我們的能力建設也是圍繞這4點去搞。

1  知識生產—資料自動化生產能力建設

核心流程概覽:

指標的生成(5步)

1)數倉分層建設(kimball維度建模-星型模型):
  1. 事實:以明細為粒度進行資料域拆分,如2001瀏覽域,2101點選域,2201曝光域,交易域,來源去向域,業務統計域,其他業務域等等。
  2. 維度:錄入相關的Dim維表
2)關係染色RelationColoring
  1. 明細事實表和維表的主鍵關係。
3)維度染色DimensionColoring
  1. 動態填充需要的維度欄位(非全量冗餘,可以靈活適應維表的變更)
  2. 透過RelationColoring & DimensionColoring可以完全遮蔽了複雜的關聯操作Join。
4)結果組裝AssembleIndicator
  1. 標準Sql生產:CREATE VIEW AS SELECT “Operate運算元,stat統計包” FROM “ColoringView染色檢視” WHERE "Scope統計範圍" GROUP BY "PeriodDim週期維度 & Dim業務維度"。 
5)資料探查IndicatorResult
  1. 起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)

  1. 檔案建立
  2. 檢視轉表Sql生成
  3. 配置+提交+部署
  4. 排程運維
  5. 外表同步

核心挑戰:效能

效能是自動化指標產出的難點,也會是之後的亮點。我們希望透過平臺生成指標的效率能最大程度的接近開發人員手動最佳化的效能。當然這往深了做,是一個可以無限探索下去的領域。 拿平臺來講,目前最大的瓶頸在多維分析的支援,我們支援了維度的全量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

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

點選閱讀原文檢視詳情


相關文章