導讀 大資料開發治理平台是在大資料生态元件之上，提供海量資料的傳輸、存儲、查詢分析、開發測試釋出、管理、運維的一站式開發分析治理平台，服務于公司内部對資料有需求的各種角色成員。
今天的分享主要圍繞以下四個部分展開：
1. 大資料開發治理平台介紹
2. 平台建設之痛
3. 資料治理驅動平台建設方法論
4. 産品推進政策思考
分享嘉賓｜張靖 哔哩哔哩 進階技術總監
編輯整理｜依依 哔哩哔哩
出品社群｜DataFun
01
大資料開發治理平台介紹
首先和大家介紹下大資料開發治理平台。
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 等日常使用的生态元件，更多和底層服務結合。
--
02
平台建設之痛
簡單談談大家在平台建設過程中可能會遇到的痛點，以及 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）工具方面：完善對應工具的建設，包括資料內建傳輸、資料開發運維、資料治理工具和資料服務平台。
在這三個方向，需要做好相關的建設工作，任何一環都不可遺漏。工具的建設往往是一個非常長期的過程，是不可能一蹴而就的，每個業務不同的階段要求不一樣的情況下，還是需要一些組織形态的營運工作在其中，同時有些工具上線之後，如果沒有方法論的驅動，大家也不知道如何使用，是以如果隻是把一些行業内的工具做好抄好，不一定能解決問題本身。
--
03
資料治理驅動平台建設
接下來重點展開介紹如何使用資料治理的方法論驅動平台建設。
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 的當時，和老闆做彙報的時候，更多的将成本浪費的部分彙報上去，因為有些業務本身雖然的确存在浪費，從規則層面是屬于浪費的情況，例如重複建設，但其占用的資料量級本身并不大，且業務本身處于一個快速發展的階段，對于整個業務疊代速度其實是可以接受“先污染後治理”的，我們就可以有一個比較好的尺子和方向去推進治理工作。
對應産生出來評分、榜單、具體的治理項内容，換算成錢推送給各個部門做相對應的治理工作，有了标準之後，對應的工作變得更加容易推進，因為業務和老闆是能夠感受到錢的變化，産生壓力的。
--
04
産品政策思考
最後總結一下，在整體平台建設過程中沉澱的一些産品政策思考。
（1）業務合作：需要思考 BU 目前階段的痛點，整體治理平台或者是工具建設能夠做的事情很多，但實際在公司内部真正落地時候，如果隻是和業務方空談目前的痛點，規範，收益以及完整的讓人興奮的産品架構，業務是不太感冒的。和業務的合作不是告訴對方行業如何做，我們應該如何做，而是了解業務目前的痛點，業務無非關注的就是資料及時性和資料品質問題，如果這些問題能夠比對的話，目前治理工作就能夠得到較好的推進。
（2）新技術：大家經常會被新技術所誤導，一些開發，基礎架構或者是業務同學拼命想要使用，業界反響很不錯為什麼不用呢？例如資料湖技術，是做增量計算和查詢加速的，但是我們忽略了幾個點，第一資料湖在整個傳輸鍊路上做了較大的變更，實際上可能會造成資料的丢失，增量主要還是以日志傳輸方式為主；第二和全量的同步中會存在資料的差異性；第三最嚴重的點在于資料回刷方式極為複雜，畢竟還是實時鍊路，有時需要批或者流式回刷。這些是産品經理考慮之外的，産品經理能做的地方在于面向的場景和功能上保持敬畏之心，通過反問技術或業務如果遇到對應的問題，對方希望通過什麼功能層面解決，不是先做新技術的覆寫，而是先考慮新技術覆寫當中最小化需要什麼，進而需要對 Demo 鍊路進行調研決策，這是 pm 需要關注的内容，最終不至于因為上線了新技術導緻一方面推不動，另一方面上線之後發現存在很多潛在的問題，内部研發和業務同學意見很大的困局。
（3）組織形态：很多時候平台建設往往是工具+業務，存在通用業務的，理應上由平台做統一出口，更加能夠保證資料一緻性，是以當有了這些業務，就會擁有自己的 Pipeline、開發同學，和對應的業務要求，形成了自身閉環，有了業務就會離業務更近，這樣就友善後續做更多的嘗試，包括 Demo 的嘗試。
（4）優先級：如果需求太多，盡量按照品質>成本>安全三塊内容做出優先級評估，這隻是一個參考，有些公司老闆更注重安全。安全方面更多以做好事後的工作為主，大量的資料需要先流轉起來，把業務先生産起來，然後将小批量資料做一些安全，對我們的工具要求反而不是特别高，更多是願意做安全工作和對應的監控。但是品質和成本永遠是業務方和老闆會優先考慮的問題。
（5）意識形态：一定要營運資料而不是隻做工具，如果隻是照搬行業内的工具去做，甚至抄一遍，不一定能夠達到目标，很多時候我們開發的工具是承載了資料的。我們需要了解資料、任務是什麼樣的，有什麼特征，業務在使用資料當中遇到的痛點，再完善工具是一個較為正向的流程和解決方法。
--
05
問答環節
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 查詢，以及正常補資料的查詢，這樣基本上将場景、最終資源以及搶占方式做了對應的設定，并且在平台上有相應的排程算法以及任務送出隊列的綁定，實作對應的隔離方式。
以上即為本次分享的全部内容，謝謝大家。
▌DataFun2023線下大會火熱報名中
第四屆DataFunCon資料智能創新與實踐大會将于⏰ 7月21-22日在北京召開，會議主題為新基建·新征程，聚焦資料智能四大體系：資料架構、資料效能、算法創新、智能應用。你将領略到資料智能技術實踐最前沿的景觀。
點選圖檔可檢視大會詳情，歡迎大家點選下方連結擷取門票
DataFunCon2023（北京站）：資料智能創新與實踐大會 �-�百格活動