導讀 “資料服務+自助”產品是基於資料標準化去實現系統自動化生成程式碼，完成資料的落地生產。透過以上自動化的方式，降低資料使用和生產的門檻，讓普通使用者資料消費更簡單。基於以上分享下虎牙在這方面的一些探索和實踐，探討企業未來資料服務的方向。
今天的介紹會圍繞下面五點展開：
1. 資料服務面臨問題
2. 怎樣才是好的資料服務
3. 資料自助產品
4. 產品實踐成果
5. 後續演進
分享嘉賓｜邱智敏 虎牙 資料產品經理
編輯整理｜王凱慧 貝殼
出品社群｜DataFun
資料服務面臨問題
我們的資料服務主要是以人和平臺的服務為主。人的服務是直接面向業務同學，為其完成報表建設、資料提取等業務需求。平臺服務面向的是業務側，為其提供分析型的資料產品，如 DAU、留存、使用者畫像以及競品分析的平臺型產品。在當前的資料服務中主要會有 3 個問題：（1）及時性方面。資料需求難高效響應，資料獲取週期長，業務無法快速獲取資料決策；（2）靈活性方面。資料分析門檻高且分析維度不靈活，一旦分析維度、指標發生變更，要重新提出需求；（3）一致性方面。相同指標名口徑不一，業務難甄別口徑對錯，資料可信度不高。
規範化定義指標。指標口徑是一致的，規範定義的，可被複用的，是規範定義指標的基石。自助式資料生產。內容靈活多變的資料需求是能被快速響應的，資料生產使用門檻是比較低的。大多時候使用者的資料需求在數倉中都有覆蓋，但實際生產過程中，週期是較長的。可以說在資料生產的“最後一公里”，現有的資料方案仍是強依賴開發做資料搬運的工作，無法做到快速響應。自助服務多樣化。資料服務方式是多樣的，能滿足不同型別資料服務需求，比如報告、提數、資料對接等。產品化自助化是資料服務好壞的衡量標準。
基於以上的思考，將過往對人和平臺的服務，轉變成圍繞資料的服務。面向使用者提供現有的維度和指標，讓使用者透過自助的方式去解決他的用數需求。進而推出了資料自助- MVP 版本，讓零資料經驗的使用者可以輕鬆的查閱自己需要的維度和指標的資料。對於那些業務發展快速，資料訴求多變的情況，可以直接透過在平臺上進行資料獲取，減少資料排期的過程。縮短資料定義到資料生產到具體資料服務的時間。資料自助產品主流程共計 3 塊：（1）自定義指標。為使用者提供標準化的指標定義模型；（2）指標訂閱。使用者透過在產品上選擇需要的指標和維度，即可生成一個訂閱，系統自動構建排程任務完成資料生產；（3）製作報表。針對具體的資料場景，透過現有的 BI 工具完成報表製作。① 面向零程式碼能力的產品運營人群，如何才能降低資料使用門檻？
在產品的搭建過程中，我們遇到了一些挑戰，這裡和大家分享下。首先就是如何做到低門檻。面對使用者 SQL 能力低和資料表許可權敏感等問題，將資料資訊輕量化，轉化為維度和指標。使用者透過選擇自己需要的維護和指標，即可獲取資料內容，對應的底層就是資料表的表頭。
針對如上場景，最核心的問題就是資料如何獲取。常規的做法是透過建設主題寬表、並搭配視覺化工具來解決。但常規做法通常會遇到如下問題：a. 使用者分析維度指標多變，導致寬表粒度變更，需新建寬表來滿足新需求；b. 跨主題寬表的資料需求定製化強，強關聯業務場景，且資料量大；綜上仍是強依賴於人的工作。所以我們提出一個設想，基於此去嘗試自動化的資料生產是否可行？
透過盤點近 200 個資料需求，在 5 個維度對需求進行分析：資料來源、應用場景、資料內容、指標定義、維度來源。基於分析我們發現以下 3 點：指標個性化程度高、指標定義邏輯固定、維度相對明確固定。如很多使用者需要的就是某個端的 PV、UV 的資料，在客戶端資料具備的情況下，使用者事件模型會是比較好標準化定義指標的模型，能標準化格式化指標口徑定義，讓系統可識別。
首先是對需求的拆解：提出需求、維度指標定義、定製資料 ETL 和個性資料服務。在維度指標定義環節，抽象出後設資料中心和指標系統模組；在定製資料 ETL 環節，抽象出指標訂閱模組；在個性資料服務環節，抽象出自助服務模組。
如上是產品的全景和流程。自下而上是後設資料中心、指標系統、指標訂閱和自助服務。在後設資料中心環節，透過對事件和維度的管理，實現對不同場景資料在同維度上的分析。同時提供衍生維度，使用者可以透過正則解析的形式，將衍生維度解析出來。並支援多事件合併等場景。在指標系統和訂閱環節，透過規範化定義指標，實現使用者自助篩選指標，並完成訂閱的過程。在自助服務環節，和公司內部系統打通，使用者直接進行視覺化資料操作。
如上是客戶端採集的事件明細資料。透過記錄事件出發的時間、誰觸發、在哪裡觸發、觸發了什麼、以及如何觸發的資訊。
如上是標準化指標定義模型。以事件事實表為核心，透過不斷補充主體維表擴充套件資料覆蓋範圍。進而在聚合指標、留存指標、二次聚合指標和指標四則運算角度完成標準化指標定義。
如上是指標定義過程拆解概覽。根據指標型別分為 4 部分。a. 聚合指標定義。明確使用的事件、物件、方式和業務限定，即可生成對應的 SQL 邏輯，進而產出資料；b. 留存指標定義。明確起始事件、留存事件和留存週期，即完成對留存指標的定義；c. 二次聚合定義。是聚合指標的衍生指標，透過對聚合物件和方式的確認，完成二次聚合定義。d. 指標四則運算。以 a/b 指標為例，去統計如事件的點選、曝光等資料。
指標定義後，如果進行資料生產任務構建。核心是統一維度和指標，並透過後設資料驅動資料生產進行任務構建。Cube 後設資料由四部分組成：基礎資訊、維度資訊組合、指標資訊組合、全域性過濾條件限定組合，並支援資料訪問許可權控制。Cube 後設資料在系統校驗後，會生成實體表，例行構建任務作業、查閱資料集等。
在當前業內，此類產品眾多，虎牙自設計的資料自助產品效果如何呢？在業務層面，虎牙已經覆蓋了 48% 的自助取數需求，且平均需求耗時控制在 16 分鐘內。相較於傳統的資料需求開發週期，極大的縮短了業務獲取資料決策的時間。同時累計服務了 76 個使用者，其中 90% 為產品運營人員，產品的使用門檻低。截止當前，自助產品累計建立指標量超過 2400 個，全自動化完成了 818 個資料集，並支援了 117 個報表資料消費。在業務使用者層面收到了一致的好評！
在行業層面，資料自助產品開拓了一個新的方向。它在現有資料的基礎上，藉助工具在邏輯層面實現了維度和指標的統一。並圍繞應用場景，簡化資料建模過程，具備輕治理、短週期、低門檻的特性。同時產品加強了對後設資料的約束管理，將指標定義標準化，實現了系統自動生成程式碼落地生產，擺脫手動作坊式的資料生產模式。最後是真正意義上讓零資料開發經驗的同學，可以透過簡單的介面操作就可以獨立完成“資料定義-資料生產-具體資料服務”，大大縮短業務獲取資料的決策時間。
虎牙的自助資料產品是 21 年建設的，為跑通產品流程，我們在很多方面做了取捨，下面幾點是健全產品的設計方向：（1）成本方面對算力的消耗。產品主要針對明細資料的掃描計算，面對直播行業本身資料體量龐大的特性。未來計劃透過系統構建指標中間層，提高指標複用率，降低明細資料的重複運算。
（2）在效率方面，目前對複雜維度指標是很難覆蓋的，產品層面支援該類指標定義投入產出不高，計劃透過數倉開播中間表維度指標接入模型，助力複雜維度指標納入自助範圍。
（3）對資料質量監控上，在當前 MVP 版本產品中，已經完成了指標和維度的統一。從源頭層對資料質量監控治理，無需在眾多應用層設定質量監控。
（4）安全層面上，已經完成了統一的資料許可權管理。在“資料生產”和“資料應用”的環節，整合統一資料許可權卡控，實現一處定義，全域性應用。
綜上，即是虎牙在資料自助產品建設過程中的實踐和總結。Q1：自定義指標讓資料易用性很高，但現在很多業務和部門，針對同一個指標定義了不同的口徑，這會導致多部門針對同一指標的看數結果不同，這類場景如何處理？
A1：這個問題在設計產品時也有考慮，在指標系統的層面會有一個強的系統校驗。首先是對指標定義內容的強校驗，如 A 使用者和 B 使用者針對同一個指標都進行定義，系統會彈窗提示已經存在相同定義的某指標，請勿重複建立，確保指標不會被重複定義。第二點是相同的指標名如果已經存在，是無法在系統上完成建立的。從而規避相同的指標不同的口徑。Q2：針對新的數字化轉型的傳統行業，資料自助這個模式能否適用？A2：數字化轉型的傳統行業，相較於網際網路企業，資料分散且資料規範標準不一。按傳統模式治理轉型，需要投入的人力及專案耗時都很長，往往是以年為單位。而資料自助這種模式，不侷限於現有的資料質量，而是現有資料基礎上進行後設資料邏輯治理，並不改變原有的資料格式。比如 gid 和 gameid 是含義一樣的，不需改動表物理層面的定義，而是在產品層面上標識邏輯一致，使系統可識別。同時藉助資料自助這種生產模式，使用者不用瞭解背後用的是什麼表哪個欄位，只需定義選擇自己所需的維度指標並訂閱，就可以解決自己的訴求。相對傳統治理方式耗時長、人員要求高的缺點，會更加低門檻且見效快，企業自己的業務開發就可以完成這項工作。Q3：超出我們產品之外的維度和指標，團隊是如何進行高效的開發？A3：這個問題主要涉及到我們的後續演進，對中間表的建設。在資料自助釋放數倉很多面嚮應用資料需求的同時，數倉會更專注在中間模型上的開發，這類超出範圍的複雜維度和指標將由數倉統一通用模型設計開發，降低開發複雜度。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2938050/，如需轉載，請註明出處，否則將追究法律責任。