導讀：快看在過去經歷了業務線以及每個業務線數據體量的極速擴張，我們的數據部門也因此在數據建設和治理方面面臨了很多的問題和挑戰，過去一年我們進行了閉環的數據治理實踐，總結了一些經驗，這次很高興有機會在 DataFun 和大家進行分享。本次分享的重點：

治理背景

邏輯閉環

實踐經驗

總結與展望

01治理背景

1. 公司介紹

快看成立于2014年，原名快看漫畫，是一款面向95后的漫畫和漫劇短視頻內容的消費平臺，現在正在打造 Z 時代的興趣社區，目前快看總用戶量超過了3.4億，產品各個平臺的總月活近5000萬，這樣的業務規模還是比較大的。

我們的業務線比較多，從時間線來看，包括了2014年做漫畫，2016年開始做社區，從 2017 年到現在，商業化又是我們重點發力的一個方向，包括了2019年廣告商業化， 2021年快看又宣布品牌升級，從一個漫畫平臺升級成了漫畫加短視頻加興趣社區這樣一個綜合性的一站式內容消費平臺，這是在兩個月前進行的產品升級，引入了更多的漫劇短視頻形態。

2. 治理背景

公司的發展會帶動業務的快速發展，同時也會帶來數據建設方面的一些問題，這也是我們進行數據治理的背景。

第一個方面，老業務體量的持續膨脹變大和新業務線擴張帶來業務過程與指標維度的急劇增長，給數據的建設和開發帶來了很大壓力。面對這種情況，我相信大部分公司很難避免煙囪式的開發，需要什么數據就去抽取和統計什么數據，沒有去規劃長期的數據治理工作。這導致我們的數據十分零散，分布在數倉和大數據平臺中，形式上也沒有做標準化，質量很差，數據建模沒有形成一個規范，導致業務上的開發人效非常低。

第二個方面，我們在一開始很難有足夠的人力全面地開展數據治理的工作，數據治理的啟動需要一定的動力以及相應的規劃，我們需要考慮在現有的數據質量差的情況下，如何既能夠支持業務需求，也能夠把治理工作開展起來，并且保持邊污染邊治理的平衡，最終實現數據的治理。

第三個方面，大家都知道數據建設的鏈路是非常長的，從多源頭的數據采集，再對數據進行 ETL 清洗，然后進行數倉建模，以及最后我們對數據應用的管理，因此進行數據治理需要縱觀全鏈路去管理，僅從單點去做，可能收益非常有限，甚至看不到收益。而且，我們業務線多，還會面臨跨業務域進行依賴。跨業務域的數據依賴在我們的日常工作中經常遇到，比如我們的漫畫商業化業務會依賴漫畫內容數據，這樣的依賴網絡里面，我們切入點可能會比較難尋找，所以治理難度也比較大。

3. 治理路徑規劃

針對以上問題，我們經過討論之后認為快看業務線繁多，很難保證足夠的人力全部在各個業務線同時開展，我們的思路是：

第一步，先從單個業務進行突破，重點支持專項開發當前最核心業務，當然也是我們認為數據質量問題比較大，投入后取得收益會比較大的業務線。

通過第一個業務線的重點突破，第二步，我們期望能夠沉淀適合快看數據場景的治理策略，之后進行跨業務的遷移和應用。

第三步，在沉淀完一個MVP的方案基礎上，在其他業務上借鑒復用開展數據治理，這樣就能夠減少在其他業務上從零開始的情況。

這三步就是我們進行數據治理的路徑規劃。

02治理邏輯閉環

在這樣的治理路徑規劃下，我們沉淀了一個適合快看各個業務場景治理的框架，也就是治理的邏輯閉環，在實際的方案中主要分為三大塊：第一是我們要進行業務范圍的管理，第二部分是進行數據資產的治理過程，第三部分就是數據的應用反饋。

閉環是如何形成的一個環的？

數據治理是一個長期過程，如何保證持續性？我們通過一個治理的閉環，建立治理、反饋以及反饋完之后再治理的持續性優化機制。在這個機制中，我們分配相應的人力去重點跟進各個過程，以保證我們剛才提到的對數據進行持續的治理。

為了介紹我們的整體的邏輯閉環，先拋一個問題，如何排空一個蓄水池里的水？這個是大家小學經常做的一道應用題，一個蓄水池有一個進水口一個排水口，進水口以一定的速度進水，排水口以一定速度排水，怎樣能夠排空它？

首先前提是排水口一定要比進水口的速度快。剛才也提到我們現在是邊污染邊治理，我們需要保證數據污染的速度是要小于數據治理的速度的。對于蓄水池這個例子來說，就需要對于入水口進行限流限速，對排水口進行提速，其實這樣就引出來了我們的邏輯閉環的一個基本數學原理，也就是在數據治理的過程中，要保證數據污染的速度在經過治理之后是越來越小的，而數據治理的速度是越來越高的，這樣才能保證數據治理的越來越好。

第一部分是業務范圍管理，也就是跟進各個業務的迭代變更，業務有哪些變化？增加了什么功能？刪除了什么功能？或者功能有什么變化？第二部分是管理業務指標和等級，第三部分對業務過程進行優先級排序。

為什么要做業務范圍的管理？

拿我們的一個商業化業務來舉例，我們會做很多商業化模式的探索，會有很多子模塊的嘗試，比如分銷、IP拓展和變現。進行這種嘗試，對于我們數據這邊來說，往往會有滯后性，進行業務過程的探索和我們數據建設和治理的過程不是同期進行的，往往存在的情況是優先探索功能，當 MVP 探索出來，發現 ROI 為正之后，會進行業務過程的放大，同時會對我們的數據指標和數據提很多需求。如果前期我們沒有跟進，后期一旦接到這種需求，對于數據來說是比較被動的。

所以我們認為，在治理的第一個階段，我們需要能夠把業務過程的范圍跟起來，把業務過程跟起來之后及時同步給數據建設、數據治理團隊，尤其數據建設團隊，讓他們能夠及早地跟進業務過程，以及底層數據源，比如業務數據庫的一些變化，提早進行籌備。另外，我們也要對新業務過程和老業務過程的業務指標進行管理，因為在業務探索過程中，一旦有變化，可能會提出一些重復的業務指標，或者一些非核心非必要的指標。對應到前面例子中的進水口，我們要對進水口進行限流，限流就依賴于我們對業務范圍、業務指標進行管理和等級的排序，這部分工作由數據產品和數據分析師團隊共同去做。

第二部分是數據資產管理，就是建立數據治理的一個規范，開發數據治理的一些工具，最后基于規范和工具，對各個業務的數據，尤其是核心業務去進行高效的治理。

為什么要加一個反饋管理機制？

數據治理是一個長期的過程，而且數據很容易被污染，在數據同步采集的過程中，對這些臟數據缺乏鑒別和篩選，后續可能就會產生問題，所以需要一個反饋管理，這也是治理邏輯閉環進行持續性迭代的一種問題收集方式。我們治理了數據，希望用戶能夠把它用起來。我們的用戶包括業務開發同學、分析師、數據產品，以及業務產品等。對于他們的滿意度、使用中遇到的問題，我們要建立一個溝通反饋的機制，保障這些問題能反饋提給我們，這就是一個閉環。

閉環總結：

在業務上把源頭跟起來，尤其做業務過程、指標優先級方面的管理，根據管理好的這些業務過程和指標的優先級，借助工具和規范，有序、有規劃地去做好數據業務的治理，這個規范是需要沉淀的。最后治理完了，數據使用中會有持續的反饋，根據反饋，再去做持續的治理。

03實踐經驗

我們花了半年多的時間整理出來這個閉環，同時使各個崗位角色配合起來，去進行閉環的落地。在落地的過程中遇到很多問題。這部分將介紹閉環落地過程中，我們都采用了什么樣的方式。

1. 業務管理范圍

先看業務范圍管理這一塊的架構。

首先業務范圍管理的目標，是保證數據側能夠緊跟業務過程的變化。然后根據指標體系的指標等級，明確這些業務過程、數據資產的等級是什么，我們還可以根據指標的優先級去判定業務需求的優先級。

我們的業務過程模型思路是：

首先在業務范圍管理的過程中，建立業務過程的模型，業務過程模型包括了業務關系模型以及數據源模型。我們內部落地了一些規范機制去跟進業務過程的變化，比如數據產品分析師，以及個別開發同學，有職責在業務需求的評審過程中去了解需求的變化、業務的變化，然后我們把變化整理到業務關系模型中（其實就是整理到內部的知識庫文檔中）。業務變化有可能是底層數據源的變化，數據庫的庫表結構的變化，甚至取值的變化，我們也都實時地收集到，這是我們業務范圍管理的第一步。

下一步是指標模型的管理。首先是對新業務和老業務指標的定義和維護，然后對指標進行管理，包括指標的合理性、有效性、優先級、是否重復，我們不希望業務的指標庫無限擴大，而是希望它是有序有意義的，同時指標管理還會進行等級管理，不同業務的不同指標的等級肯定是不一樣的，我們需要和業務方一同去維護，確定下來。我們把業務過程維護好，然后把業務過程對應的指標庫、指標模型也建設起來，這其實就可以了解業務所有模塊數據資產的等級，一般可以根據指標等級去推測。另外我們也能夠知道業務過程各種需求的優先級分別是什么。

這就是我們業務范圍管理這一塊的框架和思路。這個過程目前是以團隊知識庫的形式去維護的，指標管理是通過數倉管理后臺系統進行管理，業務過程和資產等級等以 WiKi 形式去維護。

2. 數據治理規范和架構

邏輯閉環的第二步，數據治理。數據治理非常依賴全鏈路關鍵路徑節點上進行的規范化，因為我們的數據鏈路非常長，需要把全鏈路上比較關鍵的節點進行規范化建設，包括治理各個階段的規范、流程、要求等，同時我們還會需要建設數據平臺的工具，來對整個過程進行提效。

上圖中藍色部分是我們各個鏈路節點規范化的建設，綠色部分是平臺提效工具的建設。數據源是我們的基礎，它的準確性決定了數據治理的有效性。第一部分是 DB 數據變更的同步機制，在我們工作中經常遇到業務數據變更了，但是沒有通知到我們，采集到的數據可能只是歷史的某一部分數據，如果沒有及時更新，出的數據會有質量問題。

另外，對于埋點數據進行管理也非常有必要。快看做了一個埋點數據的管理系統，對數據進行統一的采集上報，對它的格式規范、數據質量，進行了各種監測，保證了我們的埋點數據的質量。

再往上就是采集完數據之后，數據建設和治理的階段，我們要了解業務，要對業務進行建模，因此需要業務建模規范、數據源信息管理規范。另外，指標體系也需要進行管理，這是我們的業務理解部分。

再往右看，是數據建設和數據治理實施的流程。

按照流程來，再往右就是數倉建模的規范，數倉建模的基礎規范、分層規范、分層依賴規范，這個是我們去共創落地的。另外就是數倉邏輯設計和物理開發階段的規范，我們如何根據業務過程、指標、業務需求，去設計不同分層更高效的表結構，包括維表、事實表、匯總表，去支撐更多的業務訴求。

再往后就是開發階段，對于業務需求、業務指標以及業務數據的建設，需要有相應的數倉開發測試規范，以及任務調度管理的規范，對于任務的監控報警機制以及數據質量的監控，都要規范化。

數據開發完后，是應用階段，我們需要評估數據的復用性，這塊有相應的機制去保障，比如故障響應機制，這是保障用戶體驗非常重要的一個點。另外就是給業務方提供原生數據源信息的查詢時還要做好數據安全的管理。

最后是平臺工具，平臺工具是我們根據實際需求做的 MVP 模型，比如指標管理工具、數據采集工具、元數據管理工具以及自助數倉建設的系統，通過可視化的方式去建設我們的數倉，還有血緣管理工具，質量監控工具和資源治理工具，這些都是根據實際需求去做的，盡可能對我們的開發、數據治理進行提效。

3. 協作技巧

數據治理的鏈路很長，它需要數據產品分析師、開發同學，以及業務同學進行很好的協作。在這個過程中，需要我們能夠從更高的視角，把這些團隊協作起來，我觀測到這是數據治理工作成敗非常核心的一個點，而且從行業交流里面也發現這是很多公司的數據治理沒法開展的一個原因。產品側沒有意識到這一點，不去配合，沒有拉齊這方面的認知，數據開發同學就沒有辦法全力投入。因此需要覆蓋全流程的關鍵節點，需要各個崗位角色拉齊認知、分工協作。在各個團隊各個角色拉齊認知之后，我們要用一個閉環思路持續的去跟進，需要找一個切入點，在人力有限的情況下，建議從核心業務切入，建立MVP的流程規范，從重要性高、開發效率低的業務開展，能夠讓各個團隊參與進去之后，快速地看到效果。最后明確我們各個崗位角色產出的一個標準，統一標準，保證效率，然后大家定期復盤，最后建立明確的應用反饋機制，去進行治理效果的評估和量化。

這就是我們的協作技巧。

04總結與展望

1. 治理效果評估

快看這邊根據我們面臨的問題，從三個維度進行效果評估：

業務指標的重復度：這在過去是非常嚴重的問題，指標非常多重復度也很高。

數倉數據的復用度：各種寬表的復用性，它對需求的cover程度有多高。

開發應用的周期：在上圖大家可以看到，業務指標通過治理，持續削減，并且最后相對穩定。當然隨著業務變化、業務過程的變化，它可能還會增，但是管理起來之后就能減少很多不必要的指標。我們數倉的各層數據和維表相關的數量，以及它的復用性，也能夠得到明顯改善。最后需求開發的人天和數據應用的調研時長，也持續下降。因為我們的數據地圖更清晰了，大家使用數據、查數據、對數據口徑確認也更快速。

2. 不足與規劃

因為人力原因，我們的平臺工具迭代較慢，平臺工具都是MVP最小的模型，比如數據地圖、調度管理，目前還存在一些不便性，需要我們投入更多人力去做。

第二點，我們多業務的綜合治理，也就是跨業務域依賴治理，雖然有了一些規范和機制，但并沒有在所有業務開展，需要后續去推進。

另外是持續優化，我們的策略是小步快跑，迭代補齊，剛才提到的三個步驟中的各個規范，它的框架都在不斷完善中。最后是一個細節點，我們提到的數據源里面，埋點數據質量的管理，它的流程規范和落地機制，我們也在大力的去跟進完善，這畢竟是我們數據質量的一個源頭，目前取得了一定效果，但仍需要去進行業務側的推進和落地。

05問題

Q：血緣節點規模現在是多大？用的是圖數據庫嗎？

A：我們血緣關系這一塊做了一些建設，但是還沒有到一個非常完善的地步，我們用的存儲結構也沒有用圖數據庫，現在主要還是存儲在 mysql 里面，規模基本上是每天有幾千個任務，會進行任務血緣的關聯，對于它的存儲和使用性能目前沒有遇到什么問題。