一、大數據開發治理平臺介紹

首先和大家介紹下大數據開發治理平臺。

1、數據驅動企業中均有建設

在各個企業中，對于大數據開發治理平臺的認知包括數據中臺工具、大數據平臺工具和數據治理工具。

2、日常認知

日常的認知，包括：

（1）大數據生態組件的“拼接”。平臺建設中往往會接觸到很多的生態組件，例如 Hadoop、HDFS、Yarn、Spark、Hive、Flink 等等。對于平臺來說，在業務發展到一定階段之后，各個組件在大規模運轉下的易用性和效能都會有所影響，所以需要大數據平臺整合這些生態組件。

（2）開發代碼的 IDE。企業當中數據 RD 同學是數據生產的主要開發者，他們對開發工具有提效的要求。

（3）查詢 SQL 工具。也稱之為 adhoc 工具。能給企業內大量的分析師、算法以及開發同學更快速進行 SQL 查詢分析工作。

（4）作業調度平臺。一般企業最初最早開發的平臺工具，并以此為基礎，將線下 Pipline 遷移到線上，圍繞開發運維提效以及數據降本治理，迭代發展為大數據開發治理平臺。

（5）數據管理工具。如提供數據地圖便于大家找數，定位問題，做影響評估等。

3、產品平臺解讀

下面以全局視角，解讀大數據開發治理平臺。可分為兩大模塊、三種場景和四類用戶。

?（1）兩大模塊包括開發和治理模塊。開發即日常在開發中所需的調度系統和代碼IDE。治理包括數據管理以及和安全、成本、質量相關的提效和治理工具。

（2）三種場景包括數據生產場景、數據消費場景和數據治理場景。

開發模塊主要是數據生產場景中將代碼快速開發、上線、測試和發布審批、運維等等，同時也有一些開發過程中規范的落地。

在生產完數據之后，在數據消費場景中，數據需要提供給前臺，賦能前臺使用，比如：報表，數據應用產品，在線服務，交互式分析，啟發式探索分析，需要提供更靈活的數據的消費形式，如：adhoc 查詢分析，API 接口，湖倉一體查詢加速等。

治理模塊主要面向公司級數據治理場景，需要看到治理相關的具體大盤、治理項，以及針對治理項引導用戶或治理團隊進行治理的快速操作，打通下游的存儲和計算系統。

（3）四類用戶包括數據分析師、數據 RD、算法 RD 和數據運營。

分析師主要是啟發式的探索工作，用到我們的平臺工具找到分析所需的數倉表，在此基礎之上進行 adhoc 查詢分析。

這里我們將數倉開發、數據治理、業務開發 RD、后端、前端同學統稱為數據 RD，在平臺上基于監控、查 Bug 以及對業務的理解等都需要使用平臺的計算能力查數。

算法 RD 大量工作基于平臺進行數據生成以及最終效果數據的校驗，以及一些常規的異動分析。

實際上在做數據內容的時候也會有大量的運營工作，由誰發起，最終如何使用工具做好，這些都是數據運營同學需要使用大數據開發治理平臺完成的事情。

什么時候開始做工具建設，建數倉？

這更多是爆炸式數據增長催生的產物。在早期數據較少，業務相對簡單的情況下，從整個生產方式上來看，由業務 RD 同學同時兼顧數據 RD，將這些數據快速迭代上線，讓老板快速看到數據，此時是不需要有平臺存在的，靠人力就能解決當前的問題。但在整個企業內部業務分化和工作分工更加精細化之后?，實際上會考慮到例如大量的數據 Pipeline 如何管理、如何在大量的表和數據中精準找到想要的數據，以及大量的數據是否有價值，成本多少，需要有這樣的組織去完成這些事情，這個組織催生出來提效的需求，偏橫向的工作，需要有平臺工具的支持。

4、大數據浪潮下的開發治理平臺

進入大數據浪潮下，平臺有很多特點，主要包括以下幾點：

（1）大數據技術更新迭代快：如現在新興的湖倉一體技術，從前年已經開始在整個社區當中流行，同時在各個企業當中也在逐步落地使用。對于平臺的挑戰在于開發同學會開始對新的生產力有所要求，需要立刻響應這些新的技術。

（2）前臺業務多元化：對于快速增長的業務，唯一關注點是平臺是否能夠提供足夠多的資源，無論是計算資源還是存儲資源，以及在平臺上的穩定性是否能夠得到保障。而對于增長進入需要用數據驅動解決問題階段的業務，目前的訴求主要在于數據質量問題，同時對于大量人員結構的增長，需要有組織上的管理要求，管理數據安全問題。

（3）企業組織形態復雜：有些部門是產研一體，在一個事業部當中形成閉環從而進行數據驅動工作；有些部門研發組織內部已經分化形成多個開發單元，組織形態包含橫向和縱向，非常復雜，對于平臺管理資產有非常大的挑戰。

（4）數據指數級增長：數據指數級的挑戰，對于平臺產品經理的要求是在與各種業務溝通過程中需要了解大數據技術穩定性的基礎知識，以及對應最佳的時間場景。

5、B 站選擇的解決方案

B 站對市面上第三方方案進行了簡單的調研，如果企業內部開發資源相對較少、業務迭代比較快速的情況下，沒有更多的資源進行自研，可以考慮選擇第三方的解決方案，B 站最終選擇自研的解決方案，有幾點原因如下：

（1）成本控制：不僅考慮到開發成本，更多在于和公司的大數據基礎架構基建有關，因為整體規模量級較大，對于基建的要求以及基建穩固的成本控制會更加靈活一些。

（2）集成能力：因為平臺不是僅有自己的功能開發，還依賴大量周邊的系統，例如域賬號系統、OA 組織架構系統，這些能快速集成必須是在平臺自研能力的控制之下。

（3）性能要求：大數據基礎架構做了很多性能層面的優化，有些優化和平臺的集成能力存在相關性，需要平臺做定制化的操作，如隊列提交，調度上需要平臺和基礎架構之間完成較多的合作和聯動。

基于如上考慮，B 站通過自建，完成了 “berserker” 平臺。

6、業務產品架構

?B 站整體產品架構主要包括業務前臺，所有開發工具都最終賦能于業務前臺。其中包含報表工具，埋點用戶行為分析，AB 實驗平臺以及標簽系統、用戶增長看板等等。

數據治理模塊包含找數、查數、數據地圖和數據管理，偏內容型的平臺工具，還包含歸因影響分析、血緣分析等與數據治理相關的基礎模塊內容。數據建模模塊保證整個數倉建設當中能夠對外形成數據管理、組織域管理標準等元數據流入管理工具。同時在安全和資產方面將賬單、資產以及安全保護傘等與安全運營工作相關的工具提供給相關負責數據治理的同學使用。

數據開發運維模塊包含數據集成，有實時和離線，大量的數據從端到端落地到平臺中做統一的計算，以及日志上報的傳輸通道。數據開發包括批處理、流計算、即席查詢以及類似數據 API 接口等數據消費服務內容。由于平臺整個數據鏈路復雜，線上每天同時運行的 Pipeline 繁多，需要有數據運維的工具支持，對任務運維，以及數據出現異常時的回刷操作，發布審計和版本管理。數據質量模塊更多賦能業務側進行質量效率側的提升，對應提供智能基線、監控告警、DQC 功能服務。

底層服務相對基礎，例如離線任務調度服務、數據傳輸服務、元數據服務、權限服務、審批流服務，做橫向的建設。

底層引擎模塊，由于整個 B 站技術生態起步階段偏向于基礎建設為主，大量引入新?技術，除了傳統的 Hive、HDFS，還包括 ClickHouse、Iceberg、Hudi、Flink 等日常使用的生態組件，更多和底層服務結合。

二、平臺建設之痛

簡單談談大家在平臺建設過程中可能會遇到的痛點，以及 B 站在五年的平臺建設當中遇到的痛點。

1、平臺建設是公司級的問題

首先有如下幾點認知和大家對齊：

（1）平臺建設是先進數據生產力的提升：在建設過程中更多站在公司視角，從組織上和基礎架構合作，推動生產力的提升。

（2）數據治理方法論的落地：公司當中對治理有要求和目標的同學，基本存在于公司級的數據治理團隊，治理委員會，抑或是具體的 1-2 個 owner 同學，做治理驅動的工作，其目標主要是成本、質量、安全等。

（3）數據驅動成熟度的完善：在和很多業務對接的過程中會發現業務需求都是點和面的，最終希望將數據賦能于業務當中，但很多時候業務同學并不了解數據及時性和數據鏈路上的優化對于業務的影響，以及如何監管治理已經開發的工具。實際對于平臺建設除了做好工具之外，還需要不斷提高公司中數據驅動的成熟度。

2、數據自閉環多

具體的現象包括以下幾個方面：

（1）平臺不夠穩定業務自建集群；

（2）任務運行在線下迭代更快：開發同學在線下使用自己的調度系統，或者設置定時任務用腳本實現，這樣迭代更快，不需要平臺的接入；

（3）對于平臺的要求只分發數據就夠：埋點正常上報，數據能夠正常使用即可，正所謂平臺不生產數據，只做數據的搬運工，從而導致平臺建設處于非常被動的狀態。

3、人少事多短期收益難

（1）業務投訴多，鍋從天上來：很多時候工具本身不存在 Bug，按照正常周期迭代，但完成之后用戶沒有滿意度的認知，僅僅只有不滿的時候才會提出訴求，這樣整體就會相對比較被動，老板收到投訴的時候，自己也無從解釋。

（2）不敢承接推廣新功能模塊：對于新功能模塊的需求處于“警覺”的狀態，剛開始對于新事物往往會比較興奮，但長時間由于人少導致在業務中的預期無法管理，不知道承接的意義是什么。

（3）爆炸式個性化需求永遠做不完：業務提出的需求往往非常個性化，且很多時候需求本身是矛盾的。比如在開發規范方面，有一些聲音認為在開發流程中應該進行阻斷式流程，希望審批不能讓有問題的任務上線，有些部門則認為上線之后事后可以進行處理，不需要做事前的預處理。

4、數據治理配合度低

（1）業務不考慮成本問題：站在業務立場，更多希望快速迭代保證數據質量

（2）業務迭代人力不夠沒精力治理：業務本身迭代老板層面的需求已經人力不足，無暇顧及這部分的工作。

（3）數據治理功能推進難：對于我們上線的功能，比較好的業務部門會提出意見，明確自己的需求，有些業務部門則根本未使用功能，當出現線上問題，老板怪罪下來，最終將原因歸咎于治理功能不好用，導致治理推進不下去，和治理工作處于“癱瘓”狀態。

5、如何破局

如何解決問題，總結為組織、方法論和工具三個方向：

（1）組織方面：首先治理工作包括治理平臺的建設，是一體化的，所以前提必須是一個平臺集中式的組織，無論是屬于虛擬團隊，還是實線團隊。整個平臺有自身負責平臺工具建設的同學，業務需要有業務的代表，例如各個業務線的數據代表者，平臺當中以 BP 的形式提供相同業務線的支持，因為他們所有業務目標、看數邏輯和目前業務階段所需要求都基本類似，所以這里采取“BP 制”合作模式可以做到相同業務的歸因，無論是在數據口徑一致性，還是在整體細節對齊都有特別大的好處。

（2）方法論方面：作為數據驅動需要有四個方向的方法論，包含數據模型規范、數據質量治理、數據成本治理和數據安全治理。

（3）工具方面：完善對應工具的建設，包括數據集成傳輸、數據開發運維、數據治理工具和數據服務平臺。

在這三個方向，需要做好相關的建設工作，任何一環都不可遺漏。工具的建設往往是一個非常長期的過程，是不可能一蹴而就的，每個業務不同的階段要求不一樣的情況下，還是需要一些組織形態的營運工作在其中，同時有些工具上線之后，如果沒有方法論的驅動，大家也不知道如何使用，所以如果只是把一些行業內的工具做好抄好，不一定能解決問題本身。

三、數據治理驅動平臺建設

接下來重點展開介紹如何使用數據治理的方法論驅動平臺建設。

1、B 站平臺規模

B 站目前整體集群規模至少 10000 臺以上物理級節點；日均新增數據量級在 1000 億級別以上，日均作業量，離線調度系統的 Pipeline 量級在 15 萬以上，平臺大約每天有 3000多的 DAU。

2、演進里程碑

從 2017 年開始逐步做平臺建設，剛開始 2017-2018 年期間，主要方向是存通用賦能，各個業務方的訴求在于其在存儲和計算上特別痛苦，基本上穩定性和算例無法保障，自己計算有了集群也沒有辦法維護，需要組織大量的人力和精力完成，數據量到了一定階段實在是維護不動了，所以我們當時從通用的角度出發整合資源，做到集群統一，數據存儲統一，同時需要平臺有對應的產品和技術能力。

2019-2020 年期間，完善了對應功能之后，雖然底層系統已經形成統一，但數據穩定性問題依然存在，業務對于平臺非常大的訴求變成如何保證數據質量，過程當中早期我們認為質量問題牽扯到的上下游、對應邊界有時很難劃分，但其實我們在邏輯思考中更多是在業務當中一旦有事故發生，我們會同業務一起討論如何解決問題，最多的事故往往只會涉及基建方面出現存儲系統，調度系統或者是計算資源有問題從而導致的數據質量問題。這塊我們當時開發了較多的產品功能和提供了對應的技術服務，對生產力也有所提升。

到了 2021-2022 年期間，業務已經?在很多工具使用當中沒有太大層面的問題，只是日常的修補和迭代，此時更多在公司級別會有對應的要求，在于我們需要做好成本的治理驅動，此時催生出的對應產品包括數據治理工具、數據治理榜單、做一些組織形式的劃分，按照工作空間，還包括資產管理、以及通過賬單管理清算清楚成本。

3、存通用賦能

?涉及的主要模塊包括數據傳輸和數據集成。解決的問題本質上是治理數據及時性的問題，在推進這部分功能過程當中業務有時是無法理解功能的必要性，有時在功能上無法避免真正做到無感知，需要業務做一些配合工作，比如傳輸全部是百億級別數據，做天維度的全量傳輸，是對存儲資源的浪費，我們和業務的溝通方式更多的在于我們是有更先進的生產力，我們的數據湖技術可以實現增量集成，通過 binlog 做數據更新集成，省去大量的計算工作，對數據任務的及時性有提升。

大量的業務無法實現傳輸計算的及時性和穩定性，這塊是業務比較大的痛點，而平臺是有這塊領域的能力，在業務當中能夠以這樣的能力吸引業務配合我們完成工作，例如我們在和業務溝通過程中更多情況往往是如果業務自己去做，比較簡單，但需要考慮的問題是如果 Pipeline 到十萬、二十萬甚至千億級別的時候，如果有一個數據出現問題，其他數據怎么去修護，我們可以提供對應的能力，在數據傳輸過程中，我們會有管道隔離、數據傳輸結構化的優化等等，這些優勢業務自己是無法操作的。

圍繞數據集成功能我們會做各個場景核心鏈路功能，不斷迭代，無論是集成?還是開發方面。

4、數據集成能力

在數據集成能力方面，我們長期推進的功能，也在公司內部得到了較好的評價：

（1）支持大量業務數據庫接入：將業務的 MySQL、SQL Server、Oracle 的數據快速接入到 Hive；

（2）流式數據匯聚：日志更多以實時傳輸方式為主，將客戶端、服務端和數據庫變更日志數據匯總進行分析；

（3）Hive 數據出倉：數據最終只能從數倉出倉到各個不同的存儲板塊當中，提供給業務線上服務的使用，支持從 Hive 數據以類似 bulkload 的方式到 MySQL，ClickHouse，TiDB，Kafka，Redis，MongoDB，ES 等不同組件；

（4）與作業調度，元數據系統集成：業務在日常很難解決數據傳輸結束后能夠立刻將作業計算調度起來，業務一般實現的方式只能打時間差，這樣會導致很多時候任務是空跑的狀態，數據還沒有 ready 好，任務就已經開始運行，但在平臺中是不會存在這樣的問題。

整體演進過程主要是從全量到增量，從批處理到流處理，實現了將數據，從早期的 Flume+DataX，到中間態通過 Flink+Kafka+Waterdrop，目前核心通過Flink+CDC+Kafka，最終能夠給到的業務承諾是數倉整體 ODS 層數據就緒時間，即保證在 0:30 分所有數據都會整合到平臺當中，作業就開始跑起來，意味著整個數據后續跑任務時間能夠節省出來。平臺通過增量和流式處理能夠做到提升，整體功能的推進也會更加有效果，業務也會愿意將核心數據遷移到平臺當中。

5、開發運維能力

開發前，數據需要從端到端落地到系統當中，通過 adhoc 功能對數據進行探查；開發中開發任務 SQL 和 UDF 代碼，代碼的自動完成，表推薦，調試編譯測試診斷攔截，配置調度周期與依賴推薦，將所需要依賴的下游任務給到，通過配置，從而不會產生空跑，配置任務告警，創建修改表。

運維模塊最核心的功能在于事后如何回刷數據，更快的發現問題。

6、任務調度系統

整體調度系統大家更多關注的要求在于功能，即有靈活的依賴觸發機制。

我們通過調研開源的系統例如 airflow，實際上業務的調度時機是較為豐富的，比如第一種時間觸發，需要定時定點某個時間起來；第二種依賴觸發，上游 ready 之后必須馬上觸發，第三種混合觸發任務，例如小時和天之間的依賴，天和天之間的依賴以及依賴自己上游上次跑成功的時間。

7、依賴策略支持

（1）時間調度：用于時間調度的一種是數據同步任務，批量抽取業務數據庫，在凌晨 0點 15 分開始；一種是虛擬節點任務，需要在 0 點 15 分同時啟動多個數據同步任務以及關聯的 ETL JOB 任務；

（2）依賴上游：同周期依賴，最常見于兩個天任務之間依賴，小周期依賴大周期，小時依賴天，日依賴周，以及大周期依賴小周期，以及月任務跑完成之后，有些當天的報表需要將月維度數據補充進去等場景；

（3）自依賴：最典型的是新增留存的統計場景，基于昨天或者是歷史上所有任務完成之后，才能完成今天的任務，需要和昨天的數據做交集。這時候需要用到自依賴屬于，依賴自身上一周期調度完成后才能執行。

8、質量治理驅動-SLA

在完善生產力提升之后，這時公司以及有治理意識的業務關注更多的是治理工作。這時候需要思考業務最關注的是什么，實際上在任何階段業務關注的都是數據質量問題。當時 B 站在做工具的過程中更多考慮在有限的人力之下優先將質量治理工作做好。

首先談談質量的 SLA，數據及時性的 SLA 是大家所關注的，拆解分成為兩種時間，第一是 MTTD，即事故平均檢測時間，越早發現事故越好，第二種是 MTTR，即事故平均修復時間，事故修復的越快越好。同時有一些術語需要和業務共同定義，例如破線，一般來說數據最終產出是有一個固定時間的，叫做數據預期產出時間，如果實際產出時間晚于預期產出時間，則視為破線，破線不達標的情況下，則開始計算故障時間，通常情況下，天例行任務數據及時性 SLA 一般在 95%，換句話說故障時間只能占一年的 5%。

9、質量治理驅動-智能基線

在和自身上以及公司各個部門聊清楚基線及時性目標之后，接下來需要去解決如何更快發現問題的能力。

（1）監控報警痛點：調度系統當中有成千上萬甚至十萬任務時，我們有很多種方法，第一種方法是給每個任務配置告警。

（2）配置難度：不可能為所有的任務配置告警，首先配置量非常大，而且規則較為復雜，每次配置需要知道任務什么時候開始和結束，執行時間多長，從而造成為每個任務配置監控規則極為繁瑣。

（3）報警時間：每個任務所需報警的時間都不同，配置錯誤的話會造成大量的誤報。

（4）監控數量：監控任務除了難配置之外，一旦下游出現問題，上游所有節點都會報警，造成大家由于告警太多從而無法處理真正有問題的事情。

（5）在做基線時只需要關注最終產出數據的任務，在最小任務當中配置一條基線，基線必須配置在任務的葉子節點當中；配置完成之后，通過葉子節點，自動識別關聯路徑；當關鍵鏈路上有節點出現各種異常，出現延遲后，系統將通過歷史執行時間進行預測，計算所有節點執行時間結束之后，是否能夠達到預期時間，這樣無論中間任務有所改變，對于基線的影響都可以做出較為準確的判斷，一旦基線報警，勢必只會是最后一個或者是中間的任務有所影響，再對應通知到基線相關人員，而不是整個鏈路當中的所有人，從而能夠更快發現問題，運維成本也會相對減少。

（6）具體配置內容相對于告警配置減少很多，只需要配置好基線名稱、責任人、保障任務、基線類型（包含天和小時）、預計完成時間（系統自動計算）、承諾完成時間、預警時間、告警方式和告警接收人。

功能上線之初，獲得了很多 RD 同學的青睞，解決了大量運維成本帶來的問題。 

10、質量治理驅動-DQC

數據準確性的監控，本質上等同于一個監控系統。

?在數據表上，配置一些具體的字段級、行級數據波動的監測，對應的閾值。如果數據發生錯誤，例如上游任務出現空跑，對于下游產生影響，此時會觸發紅色預警，阻塞下游。

功能本身難點在于規則配置，業界其實有很多參考，同時業務也能夠提出很多規則相關配置，字段級觀察波動，離散型觀察分布，系統只需要支持配置閾值即可。推進過程當中業務經常會提出數據質量問題是由于 DQC 工具的不完善造成的，配置告警的誤告太多，規則相對較少，無法解決當前問題，希望規則推薦閾值，提高配置效率。但工具層面只能提高效率，不能根治數據質量問題。質量問題本身是一個鏈路很長且很大的問題，且并不是靠工具本身就能解決，更多在于數據質量運營治理：?

（1）分級治理 P0 全部覆蓋：和業務共同梳理，通過反問業務如果 Pipeline 出現問題，哪些是涉及資損和輿情層面。

（2）對于未處理告警優化，定期優化閾值。

（3）指標監控閾值：通過對比業界標準，給到業務最佳實踐，例如推薦 CTR 一般為 5%。

（4）源監控閾值：業界標準，計算過去統計周期內的異常率，重復率，離散值個數，離散值條數分布等值，一方面根據業務形態自己控制，另一方面屬于行業內部必然會出現的問題，例如設備 ID 獲取率通常為 10%。

通過相關的方法論和組織形態推動 DQC 工具的迭代。

11、質量治理驅動-回刷工具

?另外大家反響較好的是回刷工具。有時候事故是非常巨大的，像根任務，傳輸任務出現問題導致傳錯了數據，遇到最多的情況是日志數據有問題，此時需要將對下游影響巨大的根任務進行修復。系統當中需要提供的工具在于根據 P0 基線做優先調度執行，一般出現事故時候首先在工具當中將出現故障任務的下游拉取出來，之后進行過濾，因為有些任務不一定是能夠重跑的，其不具備冪等性，如果重跑會造成較大的問題，對線上數據造成污染，甚至有些數據已經交付出去，此時再重跑，被客戶看到數據發生了變化反而會造成較多的輿情問題，對于這些情況的任務是需要過濾掉的。批量停止，黑名單，鏈路選擇，批量執行等功能，調度系統會根據 P0 基線鏈路選擇優先執行，并且站在數據開發的角度如果作為數據產出的 owner，下游存在大量數據依賴方，通過一鍵拉群或者通知 owner 等功能打開內部 im 工具做出較大的通知，從而提升效率。

衡量指標一方面是用戶的反饋，另一方面是對應的 ?MTTR 時間，每次事故產品同學都會記錄對應的故障時間以及修復時間，能夠看到明顯優化的過程。

12、成本治理驅動

順應公司降本增效的要求，我們需要做較多的成本治理驅動。主要從三個方向著手，如今處于降本增效的環境下，作為公司級別的部門，更多為老板考慮的是如何省錢，首先需要明確資產歸屬，如果連資產都不知道屬于誰，都統一歸屬平臺，是沒有辦法做出優化或者是找到需要優化的人。第二是完善用量賬單，因為老板、業務方對于任務量級、存儲大小是無感知的，更多時候需要算錢。最后通過治理標準拉出成本優化大頭。

13、成本治理驅動-工作空間

在資產歸屬方面，公司當中變更頻繁，部門業務存在整合與拆分，一個部門會因為業務調整，拆分為多個部門，組織形式多元化，資產資源難以區分處理，從而導致整體資產不好交接，以及在整體拆分之后資產應該交接給誰。管理粒度粗，一些部門巨大，職能線多，人數太多，數據管理員難以指定，導致資產管理效率低下。資源隔離難：容易形成數據煙囪，數據重復計算、重復存儲，因為我們的部門是一個資源管理單元，會和隊列、庫以及資源存儲的 quota 綁定，容易造成跨業務資源容易爭搶，無法說清楚具體每個業務應該使用多少資源，依賴復雜。

于是我們加入了工作空間 workspace，在開發治理平臺當中，讓所有的資產例如任務、表、報表、數據源等等歸屬到空間之上，工作空間再歸屬到分管的部門，再決定每個空間應該執行哪些對應的隊列、庫和存儲，增加了空間之后，可以對其做很多的治理操作，整個治理單元更加縱向化，更好的做組織上的溝通。

14、成本治理驅動-用量賬單

這里比較難做的事情在于如何將最終的成本換算成錢給老板看，首先在平臺上更多通過采購服務器，按照采購價格拆分成單價，以及通過采集 SDK 獲取用量，而最終的賬單=單價*用量。整個數據生產當中使用到的資源包括 CPU、內存和磁盤，單價如何拆分？

服務器有對應的采購價格，將整體采購價格分攤到每個月，折算出折舊成本，可以和相關采購和財務部門確認，大概可以估算出一個服務器在當月對應多少錢，將一次性采購的錢拆分成多個時間段的錢，在多個時間段當中按照服務器的 CPU、內存和磁盤的占比，計算出具體 CPU、內存和磁盤對應多少錢，這就是所謂的成本比例。同時再根據水位線，由于每個服務器不可能所有的資源都給用戶使用，會有公攤的部分，比如調度系統當中處于等待狀態的任務是需要占用公共內存的，磁盤也不能全部用滿，否則整個集群就會掛掉，所以整體磁盤的水位線一般設定為 75%，CPU 利用率能夠達到 80%-90% 之間。水位線數值一般是基礎架構同學給出的，是一個較為科學的數值，平臺會將水位線成本分攤到各個業務線當中，這樣我們能夠通過對應的公式：

服務器拆分成時間的總價，各個使用量單元的占比*水位線即可獲得對應的單價。

通過采集的工作將每個執行任務，存儲的表都對應采集到，同時把他們當前使用的 CPU、內存和磁盤用量計算出來，這樣最終將所有任務和資產對應的用量乘以單價得到最終的賬單。

通過上述計算方式給業務和老板最直觀的感受，到底我們用的東西對應消費了多少數值的人民幣。隨之產生的是各部門級別的資產大盤，以及用戶維度的消費資產數據。

15、數據治理驅動-治理標準

完成上述工作之后，我們可以進行數據治理相關全局性的工作。因為從質量成本出發業務側和老板側都有了較大的認知，方法論上沒有較大的問題，此時各個部門如何全局去看，做出建設，需要我們平臺推出治理標準。我們的標準是同數據治理團隊共同定制的，包括模型建設、數據規范、數據質量、任務優化和資源使用五個維度，各自的評判標準主要圍繞數據一致性、數據的及時性和準確性、任務是否存在浪費資源、任務優化成本如何以及運行資源使用的合理性、水位線是否符合要求。

16、數據治理驅動-治理指標與功能

基于數據治理標準，列出了較多的細項。包括錯層依賴比率；以及模型信息完整率，涉及數據是否能提供給他人使用。ODS 模型建設率，不可以總是將 ODS 層數據提供出去。數據質量方面主要關注基線運營，通過觀察基線 SLA 達標率，沒有達標破線的情況，視為數據質量不好，存在對應的扣分機制。另一方面是準確性的保障，觀測 DQC 在 P0 基線層面的覆蓋率，P0 基線表都需要被監控到，以及 DQC 達標率，DQC 是否達標以及對應告警是否有較好的處理。任務優化方面，涉及到錢，可以計算出對應哪些任務花費的錢較多，運行時間太長的任務一般都是存在問題的。資源使用方面，存儲當中由于先后基礎架構的引進，存在很多問題，例如生命周期沒有配置，沒有使用壓縮格式的配置和遷移，ODS 層重復的清洗和建設，數據同步的重復等等。

標準當中進行不斷地迭代和演進，最終目標是為了把治理項整合出來，有了治理項和錢，我們可以進行兩個方面的 Todo。一方面在公司做總體預算的時候，由于歸屬已經明確，可以將各個部門浪費資源和對應治理的情況拉取出來，首先客觀的去看它的預算是否科學合理，是否符合自然增長規律和新項目的要求，如果符合，我們會將治理項的浪費算上去，相當于必須基于治理能夠完成的情況下做采購，必須給出一個對應的治理目標，否則預算是會被打回的；另一方面更多是采用 top-down 的當時，和老板做匯報的時候，更多的將成本浪費的部分匯報上去，因為有些業務本身雖然的確存在浪費，從規則層面是屬于浪費的情況，例如重復建設，但其占用的數據量級本身并不大，且業務本身處于一個快速發展的階段，對于整個業務迭代速度其實是可以接受“先污染后治理”的，我們就可以有一個比較好的尺子和方向去推進治理工作。

對應產生出來評分、榜單、具體的治理項內容，換算成錢推送給各個部門做相對應的治理工作，有了標準之后，對應的工作變得更加容易推進，因為業務和老板是能夠感受到錢的變化，產生壓力的。

四、產品策略思考

最后總結一下，在整體平臺建設過程中沉淀的一些產品策略思考。

（1）業務合作：需要思考 BU 當前階段的痛點，整體治理平臺或者是工具建設能夠做的事情很多，但實際在公司內部真正落地時候，如果只是和業務方空談當前的痛點，規范，收益以及完整的讓人興奮的產品架構，業務是不太感冒的。和業務的合作不是告訴對方行業如何做，我們應該如何做，而是了解業務當前的痛點，業務無非關注的就是數據及時性和數據質量問題，如果這些問題能夠匹配的話，當前治理工作就能夠得到較好的推進。

（2）新技術：大家經常會被新技術所誤導，一些開發，基礎架構或者是業務同學拼命想要使用，業界反響很不錯為什么不用呢？例如數據湖技術，是做增量計算和查詢加速的，但是我們忽略了幾個點，第一數據湖在整個傳輸鏈路上做了較大的變更，實際上可能會造成數據的丟失，增量主要還是以日志傳輸方式為主；第二和全量的同步中會存在數據的差異性；第三最嚴重的點在于數據回刷方式極為復雜，畢竟還是實時鏈路，有時需要批或者流式回刷。這些是產品經理考慮之外的，產品經理能做的地方在于面向的場景和功能上保持敬畏之心，通過反問技術或業務如果遇到對應的問題，對方希望通過什么功能層面解決，不是先做新技術的覆蓋，而是先考慮新技術覆蓋當中最小化需要什么，從而需要對 Demo 鏈路進行調研決策，這是 pm 需要關注的內容，最終不至于因為上線了新技術導致一方面推不動，另一方面上線之后發現存在很多潛在的問題，內部研發和業務同學意見很大的困局。

（3）組織形態：很多時候平臺建設往往是工具+業務，存在通用業務的，理應上由平臺做統一出口，更加能夠保證數據一致性，所以當有了這些業務，就會擁有自己的 Pipeline、開發同學，和對應的業務要求，形成了自身閉環，有了業務就會離業務更近，這樣就方便后續做更多的嘗試，包括 Demo 的嘗試。

（4）優先級：如果需求太多，盡量按照質量>成本>安全三塊內容做出優先級評估，這只是一個參考，有些公司老板更注重安全。安全方面更多以做好事后的工作為主，大量的數據需要先流轉起來，把業務先生產起來，然后將小批量數據做一些安全，對我們的工具要求反而不是特別高，更多是愿意做安全工作和對應的監控。但是質量和成本永遠是業務方和老板會優先考慮的問題。

（5）意識形態：一定要運營數據而不是只做工具，如果只是照搬行業內的工具去做，甚至抄一遍，不一定能夠達到目標，很多時候我們開發的工具是承載了數據的。我們需要理解數據、任務是什么樣的，有什么特征，業務在使用數據當中遇到的痛點，再完善工具是一個較為正向的流程和解決方法。

五、問答環節

Q1：如何做平臺的工具推廣以及使用率，因為做平臺更多希望讓平臺能夠被用起來，以及我們在平臺的工具建設初期，最早要做哪些開發以及對應的優先級是如何規劃的？

A1：對于開發規劃模塊，實際上在開發初期當中，還是根據業務方本身的發展階段，質量還是業務最關注的，先深入到業務本身看業務遇到了哪些質量問題，比如是性能上存在問題，還是 Pipeline 太多監控無法管理，還是不知道如何管理，還是不知道如何進行修復等問題，在整個鏈路當中，每個點都可以做相應的了解，并且找到一個能夠給到業務最大收益的地方。如果是業務希望事前完成，出現最多的故障屬于 SQL 寫錯、變更存在問題，我們優先做出 SQL 攔截，SQL scan 相關模塊，制定基礎規則，規則本身其實并不難，但對應收益會特別明顯，且在很多業務部門當中會產生共性的問題，這時可以做一些推廣工作。在此過程當中同時需要和研發不斷溝通成本的問題，有些需求迭代成本特別快速，例如數據湖技術本身是一個非常長期的過程，投入產出并非一蹴而就的，但有些功能對應的實現成本則非常低，對于產品經理而言在推進需求優先級本身需要考慮這幾方面的因素最終決定做哪些事情。

Q2： 關于開源相關的，如果想要做一個像樣的治理平臺或者大數據平臺，有沒有開源的組件進行參考或者推薦，這樣能夠直接進行快速使用它搭建自己的平臺？

A2：傳輸模塊的組件業界比較多，例如 Flume（日志傳輸）、Flink（日志傳輸的計算引擎和傳輸引擎）

傳輸過程當中會使用到 Kafka 隊列對傳輸的數據進行削峰填谷和分發，分發側基本也是以 Flink 為主。

離線數據傳輸主要是在數據庫傳輸當中，有些數據對于數據準確性和一致性要求是非常高的，此時對于數據庫傳輸的要求是不能出現丟失或者重復的，目前在實時傳輸中很難解決 SLA 在 100% 的問題，還是需要采用到 DataX 的開源組件以及 Waterdrop 組件做批量數據的傳輸，Waterdrop 是基于整個 flink-batch、Spark 計算引擎做的。

作業調度模塊業界較多的組件是 airflow、易觀開源項目 DolphinScheduler 等比較好的設計，大家可以直接進行使用或者是二次開發。

Olap 模塊更多使用的是 ClickHouse、Iceberg，Iceberg 主要是做數據湖查詢加速的，一定程度上能夠解決數據出倉、數據查詢性能秒級查詢的問題，ClickHouse 更加針對的是亞秒級數據查詢，在數據湖加速場景，集成加速、傳輸加速以及 upsert 加速場景，更多使用 Hudi。

Q3： 對于開放平臺多租戶的資源管理問題，這塊如何進行設計，尤其是對于計算密集型和資源共享型用戶如何合理的分配資源？

A3：首先可以對大數據資源調度做一些了解，一般是如何進行隔離的，隔離實際上是按照隊列進行隔離，如果認定一個業務單元或者是生產單元屬于是需要被隔離的類型，比如對于一張報表，它是給老板看的，我們對其的要求是一定要做到較好的隔離，首先在平臺上需要對其做出標識，標識這個任務屬于高優任務，標識完成之后內部對應兩種方式做調度優化，一種是調度系統在任務執行的排隊過程當中會優先在執行節點當中執行，因為調度系統屬于中心節點分發的過程，分發到了執行節點，就要看對應任務的優先級，這時有了優先級之后就會把任務單獨提高到執行節點當中進行插隊執行，另一方面執行時候會有一些計算任務，計算任務在集群當中按照隊列做的，我們可以要求或者告訴用戶，通過銜接用戶和基礎架構之間，在平臺上支持新建一個隊列，在對應任務當中設置提交隊列，提交到單獨的隔離隊列當中，其中的 CPU 和內存都是物理隔離的，實際上這個任務就可以完成沒有影響的執行。

從全界管理的角度，我們一般會將整個隊列在一個部門或者工作空間當中做出分配，每個部門或者工作空間擁有一個單獨的隊列，在隊列當中分成 P0、P1、P2 三塊的級別或者 label。P0 任務是提供給業務方做類似給老板看的任務，或者是有資損和輿情情況任務的執行，所有調度優先級最高，且能搶占 P1 和 P2 任務的資源；P1 主要用于一般任務、非 P0 任務的執行，P1 可以搶占 P2 任務資源，但無法搶占 P0 任務的資源；P2 資源主要提供給業務在平臺做一些日常 adhoc 查詢，以及常規補數據的查詢，這樣基本上將場景、最終資源以及搶占方式做了對應的設定，并且在平臺上有相應的調度算法以及任務提交隊列的綁定，實現對應的隔離方式。