一、大數(shù)據(jù)開發(fā)治理平臺(tái)介紹

首先和大家介紹下大數(shù)據(jù)開發(fā)治理平臺(tái)。

1、數(shù)據(jù)驅(qū)動(dòng)企業(yè)中均有建設(shè)

在各個(gè)企業(yè)中，對(duì)于大數(shù)據(jù)開發(fā)治理平臺(tái)的認(rèn)知包括數(shù)據(jù)中臺(tái)工具、大數(shù)據(jù)平臺(tái)工具和數(shù)據(jù)治理工具。

2、日常認(rèn)知

日常的認(rèn)知，包括：

（1）大數(shù)據(jù)生態(tài)組件的“拼接”。平臺(tái)建設(shè)中往往會(huì)接觸到很多的生態(tài)組件，例如 Hadoop、HDFS、Yarn、Spark、Hive、Flink 等等。對(duì)于平臺(tái)來(lái)說(shuō)，在業(yè)務(wù)發(fā)展到一定階段之后，各個(gè)組件在大規(guī)模運(yùn)轉(zhuǎn)下的易用性和效能都會(huì)有所影響，所以需要大數(shù)據(jù)平臺(tái)整合這些生態(tài)組件。

（2）開發(fā)代碼的 IDE。企業(yè)當(dāng)中數(shù)據(jù) RD 同學(xué)是數(shù)據(jù)生產(chǎn)的主要開發(fā)者，他們對(duì)開發(fā)工具有提效的要求。

（3）查詢 SQL 工具。也稱之為 adhoc 工具。能給企業(yè)內(nèi)大量的分析師、算法以及開發(fā)同學(xué)更快速進(jìn)行 SQL 查詢分析工作。

（4）作業(yè)調(diào)度平臺(tái)。一般企業(yè)最初最早開發(fā)的平臺(tái)工具，并以此為基礎(chǔ)，將線下 Pipline 遷移到線上，圍繞開發(fā)運(yùn)維提效以及數(shù)據(jù)降本治理，迭代發(fā)展為大數(shù)據(jù)開發(fā)治理平臺(tái)。

（5）數(shù)據(jù)管理工具。如提供數(shù)據(jù)地圖便于大家找數(shù)，定位問題，做影響評(píng)估等。

3、產(chǎn)品平臺(tái)解讀

下面以全局視角，解讀大數(shù)據(jù)開發(fā)治理平臺(tái)?？煞譃閮纱竽K、三種場(chǎng)景和四類用戶。

?（1）兩大模塊包括開發(fā)和治理模塊。開發(fā)即日常在開發(fā)中所需的調(diào)度系統(tǒng)和代碼IDE。治理包括數(shù)據(jù)管理以及和安全、成本、質(zhì)量相關(guān)的提效和治理工具。

（2）三種場(chǎng)景包括數(shù)據(jù)生產(chǎn)場(chǎng)景、數(shù)據(jù)消費(fèi)場(chǎng)景和數(shù)據(jù)治理場(chǎng)景。

開發(fā)模塊主要是數(shù)據(jù)生產(chǎn)場(chǎng)景中將代碼快速開發(fā)、上線、測(cè)試和發(fā)布審批、運(yùn)維等等，同時(shí)也有一些開發(fā)過程中規(guī)范的落地。

在生產(chǎn)完數(shù)據(jù)之后，在數(shù)據(jù)消費(fèi)場(chǎng)景中，數(shù)據(jù)需要提供給前臺(tái)，賦能前臺(tái)使用，比如：報(bào)表，數(shù)據(jù)應(yīng)用產(chǎn)品，在線服務(wù)，交互式分析，啟發(fā)式探索分析，需要提供更靈活的數(shù)據(jù)的消費(fèi)形式，如：adhoc 查詢分析，API 接口，湖倉(cāng)一體查詢加速等。

治理模塊主要面向公司級(jí)數(shù)據(jù)治理場(chǎng)景，需要看到治理相關(guān)的具體大盤、治理項(xiàng)，以及針對(duì)治理項(xiàng)引導(dǎo)用戶或治理團(tuán)隊(duì)進(jìn)行治理的快速操作，打通下游的存儲(chǔ)和計(jì)算系統(tǒng)。

（3）四類用戶包括數(shù)據(jù)分析師、數(shù)據(jù) RD、算法 RD 和數(shù)據(jù)運(yùn)營(yíng)。

分析師主要是啟發(fā)式的探索工作，用到我們的平臺(tái)工具找到分析所需的數(shù)倉(cāng)表，在此基礎(chǔ)之上進(jìn)行 adhoc 查詢分析。

這里我們將數(shù)倉(cāng)開發(fā)、數(shù)據(jù)治理、業(yè)務(wù)開發(fā) RD、后端、前端同學(xué)統(tǒng)稱為數(shù)據(jù) RD，在平臺(tái)上基于監(jiān)控、查 Bug 以及對(duì)業(yè)務(wù)的理解等都需要使用平臺(tái)的計(jì)算能力查數(shù)。

算法 RD 大量工作基于平臺(tái)進(jìn)行數(shù)據(jù)生成以及最終效果數(shù)據(jù)的校驗(yàn)，以及一些常規(guī)的異動(dòng)分析。

實(shí)際上在做數(shù)據(jù)內(nèi)容的時(shí)候也會(huì)有大量的運(yùn)營(yíng)工作，由誰(shuí)發(fā)起，最終如何使用工具做好，這些都是數(shù)據(jù)運(yùn)營(yíng)同學(xué)需要使用大數(shù)據(jù)開發(fā)治理平臺(tái)完成的事情。

什么時(shí)候開始做工具建設(shè)，建數(shù)倉(cāng)？

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

4、大數(shù)據(jù)浪潮下的開發(fā)治理平臺(tái)

進(jìn)入大數(shù)據(jù)浪潮下，平臺(tái)有很多特點(diǎn)，主要包括以下幾點(diǎn)：

（1）大數(shù)據(jù)技術(shù)更新迭代快：如現(xiàn)在新興的湖倉(cāng)一體技術(shù)，從前年已經(jīng)開始在整個(gè)社區(qū)當(dāng)中流行，同時(shí)在各個(gè)企業(yè)當(dāng)中也在逐步落地使用。對(duì)于平臺(tái)的挑戰(zhàn)在于開發(fā)同學(xué)會(huì)開始對(duì)新的生產(chǎn)力有所要求，需要立刻響應(yīng)這些新的技術(shù)。

（2）前臺(tái)業(yè)務(wù)多元化：對(duì)于快速增長(zhǎng)的業(yè)務(wù)，唯一關(guān)注點(diǎn)是平臺(tái)是否能夠提供足夠多的資源，無(wú)論是計(jì)算資源還是存儲(chǔ)資源，以及在平臺(tái)上的穩(wěn)定性是否能夠得到保障。而對(duì)于增長(zhǎng)進(jìn)入需要用數(shù)據(jù)驅(qū)動(dòng)解決問題階段的業(yè)務(wù)，目前的訴求主要在于數(shù)據(jù)質(zhì)量問題，同時(shí)對(duì)于大量人員結(jié)構(gòu)的增長(zhǎng)，需要有組織上的管理要求，管理數(shù)據(jù)安全問題。

（3）企業(yè)組織形態(tài)復(fù)雜：有些部門是產(chǎn)研一體，在一個(gè)事業(yè)部當(dāng)中形成閉環(huán)從而進(jìn)行數(shù)據(jù)驅(qū)動(dòng)工作；有些部門研發(fā)組織內(nèi)部已經(jīng)分化形成多個(gè)開發(fā)單元，組織形態(tài)包含橫向和縱向，非常復(fù)雜，對(duì)于平臺(tái)管理資產(chǎn)有非常大的挑戰(zhàn)。

（4）數(shù)據(jù)指數(shù)級(jí)增長(zhǎng)：數(shù)據(jù)指數(shù)級(jí)的挑戰(zhàn)，對(duì)于平臺(tái)產(chǎn)品經(jīng)理的要求是在與各種業(yè)務(wù)溝通過程中需要了解大數(shù)據(jù)技術(shù)穩(wěn)定性的基礎(chǔ)知識(shí)，以及對(duì)應(yīng)最佳的時(shí)間場(chǎng)景。

5、B 站選擇的解決方案

B 站對(duì)市面上第三方方案進(jìn)行了簡(jiǎn)單的調(diào)研，如果企業(yè)內(nèi)部開發(fā)資源相對(duì)較少、業(yè)務(wù)迭代比較快速的情況下，沒有更多的資源進(jìn)行自研，可以考慮選擇第三方的解決方案，B 站最終選擇自研的解決方案，有幾點(diǎn)原因如下：

（1）成本控制：不僅考慮到開發(fā)成本，更多在于和公司的大數(shù)據(jù)基礎(chǔ)架構(gòu)基建有關(guān)，因?yàn)檎w規(guī)模量級(jí)較大，對(duì)于基建的要求以及基建穩(wěn)固的成本控制會(huì)更加靈活一些。

（2）集成能力：因?yàn)槠脚_(tái)不是僅有自己的功能開發(fā)，還依賴大量周邊的系統(tǒng)，例如域賬號(hào)系統(tǒng)、OA 組織架構(gòu)系統(tǒng)，這些能快速集成必須是在平臺(tái)自研能力的控制之下。

（3）性能要求：大數(shù)據(jù)基礎(chǔ)架構(gòu)做了很多性能層面的優(yōu)化，有些優(yōu)化和平臺(tái)的集成能力存在相關(guān)性，需要平臺(tái)做定制化的操作，如隊(duì)列提交，調(diào)度上需要平臺(tái)和基礎(chǔ)架構(gòu)之間完成較多的合作和聯(lián)動(dòng)。

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

6、業(yè)務(wù)產(chǎn)品架構(gòu)

?B 站整體產(chǎn)品架構(gòu)主要包括業(yè)務(wù)前臺(tái)，所有開發(fā)工具都最終賦能于業(yè)務(wù)前臺(tái)。其中包含報(bào)表工具，埋點(diǎn)用戶行為分析，AB 實(shí)驗(yàn)平臺(tái)以及標(biāo)簽系統(tǒng)、用戶增長(zhǎng)看板等等。

數(shù)據(jù)治理模塊包含找數(shù)、查數(shù)、數(shù)據(jù)地圖和數(shù)據(jù)管理，偏內(nèi)容型的平臺(tái)工具，還包含歸因影響分析、血緣分析等與數(shù)據(jù)治理相關(guān)的基礎(chǔ)模塊內(nèi)容。數(shù)據(jù)建模模塊保證整個(gè)數(shù)倉(cāng)建設(shè)當(dāng)中能夠?qū)ν庑纬蓴?shù)據(jù)管理、組織域管理標(biāo)準(zhǔn)等元數(shù)據(jù)流入管理工具。同時(shí)在安全和資產(chǎn)方面將賬單、資產(chǎn)以及安全保護(hù)傘等與安全運(yùn)營(yíng)工作相關(guān)的工具提供給相關(guān)負(fù)責(zé)數(shù)據(jù)治理的同學(xué)使用。

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

底層服務(wù)相對(duì)基礎(chǔ)，例如離線任務(wù)調(diào)度服務(wù)、數(shù)據(jù)傳輸服務(wù)、元數(shù)據(jù)服務(wù)、權(quán)限服務(wù)、審批流服務(wù)，做橫向的建設(shè)。

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

二、平臺(tái)建設(shè)之痛

簡(jiǎn)單談?wù)劥蠹以谄脚_(tái)建設(shè)過程中可能會(huì)遇到的痛點(diǎn)，以及 B 站在五年的平臺(tái)建設(shè)當(dāng)中遇到的痛點(diǎn)。

1、平臺(tái)建設(shè)是公司級(jí)的問題

首先有如下幾點(diǎn)認(rèn)知和大家對(duì)齊：

（1）平臺(tái)建設(shè)是先進(jìn)數(shù)據(jù)生產(chǎn)力的提升：在建設(shè)過程中更多站在公司視角，從組織上和基礎(chǔ)架構(gòu)合作，推動(dòng)生產(chǎn)力的提升。

（2）數(shù)據(jù)治理方法論的落地：公司當(dāng)中對(duì)治理有要求和目標(biāo)的同學(xué)，基本存在于公司級(jí)的數(shù)據(jù)治理團(tuán)隊(duì)，治理委員會(huì)，抑或是具體的 1-2 個(gè) owner 同學(xué)，做治理驅(qū)動(dòng)的工作，其目標(biāo)主要是成本、質(zhì)量、安全等。

（3）數(shù)據(jù)驅(qū)動(dòng)成熟度的完善：在和很多業(yè)務(wù)對(duì)接的過程中會(huì)發(fā)現(xiàn)業(yè)務(wù)需求都是點(diǎn)和面的，最終希望將數(shù)據(jù)賦能于業(yè)務(wù)當(dāng)中，但很多時(shí)候業(yè)務(wù)同學(xué)并不了解數(shù)據(jù)及時(shí)性和數(shù)據(jù)鏈路上的優(yōu)化對(duì)于業(yè)務(wù)的影響，以及如何監(jiān)管治理已經(jīng)開發(fā)的工具。實(shí)際對(duì)于平臺(tái)建設(shè)除了做好工具之外，還需要不斷提高公司中數(shù)據(jù)驅(qū)動(dòng)的成熟度。

2、數(shù)據(jù)自閉環(huán)多

具體的現(xiàn)象包括以下幾個(gè)方面：

（1）平臺(tái)不夠穩(wěn)定業(yè)務(wù)自建集群；

（2）任務(wù)運(yùn)行在線下迭代更快：開發(fā)同學(xué)在線下使用自己的調(diào)度系統(tǒng)，或者設(shè)置定時(shí)任務(wù)用腳本實(shí)現(xiàn)，這樣迭代更快，不需要平臺(tái)的接入；

（3）對(duì)于平臺(tái)的要求只分發(fā)數(shù)據(jù)就夠：埋點(diǎn)正常上報(bào)，數(shù)據(jù)能夠正常使用即可，正所謂平臺(tái)不生產(chǎn)數(shù)據(jù)，只做數(shù)據(jù)的搬運(yùn)工，從而導(dǎo)致平臺(tái)建設(shè)處于非常被動(dòng)的狀態(tài)。

3、人少事多短期收益難

（1）業(yè)務(wù)投訴多，鍋從天上來(lái)：很多時(shí)候工具本身不存在 Bug，按照正常周期迭代，但完成之后用戶沒有滿意度的認(rèn)知，僅僅只有不滿的時(shí)候才會(huì)提出訴求，這樣整體就會(huì)相對(duì)比較被動(dòng)，老板收到投訴的時(shí)候，自己也無(wú)從解釋。

（2）不敢承接推廣新功能模塊：對(duì)于新功能模塊的需求處于“警覺”的狀態(tài)，剛開始對(duì)于新事物往往會(huì)比較興奮，但長(zhǎng)時(shí)間由于人少導(dǎo)致在業(yè)務(wù)中的預(yù)期無(wú)法管理，不知道承接的意義是什么。

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

4、數(shù)據(jù)治理配合度低

（1）業(yè)務(wù)不考慮成本問題：站在業(yè)務(wù)立場(chǎng)，更多希望快速迭代保證數(shù)據(jù)質(zhì)量

（2）業(yè)務(wù)迭代人力不夠沒精力治理：業(yè)務(wù)本身迭代老板層面的需求已經(jīng)人力不足，無(wú)暇顧及這部分的工作。

（3）數(shù)據(jù)治理功能推進(jìn)難：對(duì)于我們上線的功能，比較好的業(yè)務(wù)部門會(huì)提出意見，明確自己的需求，有些業(yè)務(wù)部門則根本未使用功能，當(dāng)出現(xiàn)線上問題，老板怪罪下來(lái)，最終將原因歸咎于治理功能不好用，導(dǎo)致治理推進(jìn)不下去，和治理工作處于“癱瘓”狀態(tài)。

5、如何破局

如何解決問題，總結(jié)為組織、方法論和工具三個(gè)方向：

（1）組織方面：首先治理工作包括治理平臺(tái)的建設(shè)，是一體化的，所以前提必須是一個(gè)平臺(tái)集中式的組織，無(wú)論是屬于虛擬團(tuán)隊(duì)，還是實(shí)線團(tuán)隊(duì)。整個(gè)平臺(tái)有自身負(fù)責(zé)平臺(tái)工具建設(shè)的同學(xué)，業(yè)務(wù)需要有業(yè)務(wù)的代表，例如各個(gè)業(yè)務(wù)線的數(shù)據(jù)代表者，平臺(tái)當(dāng)中以 BP 的形式提供相同業(yè)務(wù)線的支持，因?yàn)樗麄兯袠I(yè)務(wù)目標(biāo)、看數(shù)邏輯和目前業(yè)務(wù)階段所需要求都基本類似，所以這里采取“BP 制”合作模式可以做到相同業(yè)務(wù)的歸因，無(wú)論是在數(shù)據(jù)口徑一致性，還是在整體細(xì)節(jié)對(duì)齊都有特別大的好處。

（2）方法論方面：作為數(shù)據(jù)驅(qū)動(dòng)需要有四個(gè)方向的方法論，包含數(shù)據(jù)模型規(guī)范、數(shù)據(jù)質(zhì)量治理、數(shù)據(jù)成本治理和數(shù)據(jù)安全治理。

（3）工具方面：完善對(duì)應(yīng)工具的建設(shè)，包括數(shù)據(jù)集成傳輸、數(shù)據(jù)開發(fā)運(yùn)維、數(shù)據(jù)治理工具和數(shù)據(jù)服務(wù)平臺(tái)。

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

三、數(shù)據(jù)治理驅(qū)動(dòng)平臺(tái)建設(shè)

接下來(lái)重點(diǎn)展開介紹如何使用數(shù)據(jù)治理的方法論驅(qū)動(dòng)平臺(tái)建設(shè)。

1、B 站平臺(tái)規(guī)模

B 站目前整體集群規(guī)模至少 10000 臺(tái)以上物理級(jí)節(jié)點(diǎn)；日均新增數(shù)據(jù)量級(jí)在 1000 億級(jí)別以上，日均作業(yè)量，離線調(diào)度系統(tǒng)的 Pipeline 量級(jí)在 15 萬(wàn)以上，平臺(tái)大約每天有 3000多的 DAU。

2、演進(jìn)里程碑

從 2017 年開始逐步做平臺(tái)建設(shè)，剛開始 2017-2018 年期間，主要方向是存通用賦能，各個(gè)業(yè)務(wù)方的訴求在于其在存儲(chǔ)和計(jì)算上特別痛苦，基本上穩(wěn)定性和算例無(wú)法保障，自己計(jì)算有了集群也沒有辦法維護(hù)，需要組織大量的人力和精力完成，數(shù)據(jù)量到了一定階段實(shí)在是維護(hù)不動(dòng)了，所以我們當(dāng)時(shí)從通用的角度出發(fā)整合資源，做到集群統(tǒng)一，數(shù)據(jù)存儲(chǔ)統(tǒng)一，同時(shí)需要平臺(tái)有對(duì)應(yīng)的產(chǎn)品和技術(shù)能力。

2019-2020 年期間，完善了對(duì)應(yīng)功能之后，雖然底層系統(tǒng)已經(jīng)形成統(tǒng)一，但數(shù)據(jù)穩(wěn)定性問題依然存在，業(yè)務(wù)對(duì)于平臺(tái)非常大的訴求變成如何保證數(shù)據(jù)質(zhì)量，過程當(dāng)中早期我們認(rèn)為質(zhì)量問題牽扯到的上下游、對(duì)應(yīng)邊界有時(shí)很難劃分，但其實(shí)我們?cè)谶壿嬎伎贾懈嗍窃跇I(yè)務(wù)當(dāng)中一旦有事故發(fā)生，我們會(huì)同業(yè)務(wù)一起討論如何解決問題，最多的事故往往只會(huì)涉及基建方面出現(xiàn)存儲(chǔ)系統(tǒng)，調(diào)度系統(tǒng)或者是計(jì)算資源有問題從而導(dǎo)致的數(shù)據(jù)質(zhì)量問題。這塊我們當(dāng)時(shí)開發(fā)了較多的產(chǎn)品功能和提供了對(duì)應(yīng)的技術(shù)服務(wù)，對(duì)生產(chǎn)力也有所提升。

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

3、存通用賦能

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

大量的業(yè)務(wù)無(wú)法實(shí)現(xiàn)傳輸計(jì)算的及時(shí)性和穩(wěn)定性，這塊是業(yè)務(wù)比較大的痛點(diǎn)，而平臺(tái)是有這塊領(lǐng)域的能力，在業(yè)務(wù)當(dāng)中能夠以這樣的能力吸引業(yè)務(wù)配合我們完成工作，例如我們?cè)诤蜆I(yè)務(wù)溝通過程中更多情況往往是如果業(yè)務(wù)自己去做，比較簡(jiǎn)單，但需要考慮的問題是如果 Pipeline 到十萬(wàn)、二十萬(wàn)甚至千億級(jí)別的時(shí)候，如果有一個(gè)數(shù)據(jù)出現(xiàn)問題，其他數(shù)據(jù)怎么去修護(hù)，我們可以提供對(duì)應(yīng)的能力，在數(shù)據(jù)傳輸過程中，我們會(huì)有管道隔離、數(shù)據(jù)傳輸結(jié)構(gòu)化的優(yōu)化等等，這些優(yōu)勢(shì)業(yè)務(wù)自己是無(wú)法操作的。

圍繞數(shù)據(jù)集成功能我們會(huì)做各個(gè)場(chǎng)景核心鏈路功能，不斷迭代，無(wú)論是集成?還是開發(fā)方面。

4、數(shù)據(jù)集成能力

在數(shù)據(jù)集成能力方面，我們長(zhǎng)期推進(jìn)的功能，也在公司內(nèi)部得到了較好的評(píng)價(jià)：

（1）支持大量業(yè)務(wù)數(shù)據(jù)庫(kù)接入：將業(yè)務(wù)的 MySQL、SQL Server、Oracle 的數(shù)據(jù)快速接入到 Hive；

（2）流式數(shù)據(jù)匯聚：日志更多以實(shí)時(shí)傳輸方式為主，將客戶端、服務(wù)端和數(shù)據(jù)庫(kù)變更日志數(shù)據(jù)匯總進(jìn)行分析；

（3）Hive 數(shù)據(jù)出倉(cāng)：數(shù)據(jù)最終只能從數(shù)倉(cāng)出倉(cāng)到各個(gè)不同的存儲(chǔ)板塊當(dāng)中，提供給業(yè)務(wù)線上服務(wù)的使用，支持從 Hive 數(shù)據(jù)以類似 bulkload 的方式到 MySQL，ClickHouse，TiDB，Kafka，Redis，MongoDB，ES 等不同組件；

（4）與作業(yè)調(diào)度，元數(shù)據(jù)系統(tǒng)集成：業(yè)務(wù)在日常很難解決數(shù)據(jù)傳輸結(jié)束后能夠立刻將作業(yè)計(jì)算調(diào)度起來(lái)，業(yè)務(wù)一般實(shí)現(xiàn)的方式只能打時(shí)間差，這樣會(huì)導(dǎo)致很多時(shí)候任務(wù)是空跑的狀態(tài)，數(shù)據(jù)還沒有 ready 好，任務(wù)就已經(jīng)開始運(yùn)行，但在平臺(tái)中是不會(huì)存在這樣的問題。

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

5、開發(fā)運(yùn)維能力

開發(fā)前，數(shù)據(jù)需要從端到端落地到系統(tǒng)當(dāng)中，通過 adhoc 功能對(duì)數(shù)據(jù)進(jìn)行探查；開發(fā)中開發(fā)任務(wù) SQL 和 UDF 代碼，代碼的自動(dòng)完成，表推薦，調(diào)試編譯測(cè)試診斷攔截，配置調(diào)度周期與依賴推薦，將所需要依賴的下游任務(wù)給到，通過配置，從而不會(huì)產(chǎn)生空跑，配置任務(wù)告警，創(chuàng)建修改表。

運(yùn)維模塊最核心的功能在于事后如何回刷數(shù)據(jù)，更快的發(fā)現(xiàn)問題。

6、任務(wù)調(diào)度系統(tǒng)

整體調(diào)度系統(tǒng)大家更多關(guān)注的要求在于功能，即有靈活的依賴觸發(fā)機(jī)制。

我們通過調(diào)研開源的系統(tǒng)例如 airflow，實(shí)際上業(yè)務(wù)的調(diào)度時(shí)機(jī)是較為豐富的，比如第一種時(shí)間觸發(fā)，需要定時(shí)定點(diǎn)某個(gè)時(shí)間起來(lái)；第二種依賴觸發(fā)，上游 ready 之后必須馬上觸發(fā)，第三種混合觸發(fā)任務(wù)，例如小時(shí)和天之間的依賴，天和天之間的依賴以及依賴自己上游上次跑成功的時(shí)間。

7、依賴策略支持

（1）時(shí)間調(diào)度：用于時(shí)間調(diào)度的一種是數(shù)據(jù)同步任務(wù)，批量抽取業(yè)務(wù)數(shù)據(jù)庫(kù)，在凌晨 0點(diǎn) 15 分開始；一種是虛擬節(jié)點(diǎn)任務(wù)，需要在 0 點(diǎn) 15 分同時(shí)啟動(dòng)多個(gè)數(shù)據(jù)同步任務(wù)以及關(guān)聯(lián)的 ETL JOB 任務(wù)；

（2）依賴上游：同周期依賴，最常見于兩個(gè)天任務(wù)之間依賴，小周期依賴大周期，小時(shí)依賴天，日依賴周，以及大周期依賴小周期，以及月任務(wù)跑完成之后，有些當(dāng)天的報(bào)表需要將月維度數(shù)據(jù)補(bǔ)充進(jìn)去等場(chǎng)景；

（3）自依賴：最典型的是新增留存的統(tǒng)計(jì)場(chǎng)景，基于昨天或者是歷史上所有任務(wù)完成之后，才能完成今天的任務(wù)，需要和昨天的數(shù)據(jù)做交集。這時(shí)候需要用到自依賴屬于，依賴自身上一周期調(diào)度完成后才能執(zhí)行。

8、質(zhì)量治理驅(qū)動(dòng)-SLA

在完善生產(chǎn)力提升之后，這時(shí)公司以及有治理意識(shí)的業(yè)務(wù)關(guān)注更多的是治理工作。這時(shí)候需要思考業(yè)務(wù)最關(guān)注的是什么，實(shí)際上在任何階段業(yè)務(wù)關(guān)注的都是數(shù)據(jù)質(zhì)量問題。當(dāng)時(shí) B 站在做工具的過程中更多考慮在有限的人力之下優(yōu)先將質(zhì)量治理工作做好。

首先談?wù)勝|(zhì)量的 SLA，數(shù)據(jù)及時(shí)性的 SLA 是大家所關(guān)注的，拆解分成為兩種時(shí)間，第一是 MTTD，即事故平均檢測(cè)時(shí)間，越早發(fā)現(xiàn)事故越好，第二種是 MTTR，即事故平均修復(fù)時(shí)間，事故修復(fù)的越快越好。同時(shí)有一些術(shù)語(yǔ)需要和業(yè)務(wù)共同定義，例如破線，一般來(lái)說(shuō)數(shù)據(jù)最終產(chǎn)出是有一個(gè)固定時(shí)間的，叫做數(shù)據(jù)預(yù)期產(chǎn)出時(shí)間，如果實(shí)際產(chǎn)出時(shí)間晚于預(yù)期產(chǎn)出時(shí)間，則視為破線，破線不達(dá)標(biāo)的情況下，則開始計(jì)算故障時(shí)間，通常情況下，天例行任務(wù)數(shù)據(jù)及時(shí)性 SLA 一般在 95%，換句話說(shuō)故障時(shí)間只能占一年的 5%。

9、質(zhì)量治理驅(qū)動(dòng)-智能基線

在和自身上以及公司各個(gè)部門聊清楚基線及時(shí)性目標(biāo)之后，接下來(lái)需要去解決如何更快發(fā)現(xiàn)問題的能力。

（1）監(jiān)控報(bào)警痛點(diǎn)：調(diào)度系統(tǒng)當(dāng)中有成千上萬(wàn)甚至十萬(wàn)任務(wù)時(shí)，我們有很多種方法，第一種方法是給每個(gè)任務(wù)配置告警。

（2）配置難度：不可能為所有的任務(wù)配置告警，首先配置量非常大，而且規(guī)則較為復(fù)雜，每次配置需要知道任務(wù)什么時(shí)候開始和結(jié)束，執(zhí)行時(shí)間多長(zhǎng)，從而造成為每個(gè)任務(wù)配置監(jiān)控規(guī)則極為繁瑣。

（3）報(bào)警時(shí)間：每個(gè)任務(wù)所需報(bào)警的時(shí)間都不同，配置錯(cuò)誤的話會(huì)造成大量的誤報(bào)。

（4）監(jiān)控?cái)?shù)量：監(jiān)控任務(wù)除了難配置之外，一旦下游出現(xiàn)問題，上游所有節(jié)點(diǎn)都會(huì)報(bào)警，造成大家由于告警太多從而無(wú)法處理真正有問題的事情。

（5）在做基線時(shí)只需要關(guān)注最終產(chǎn)出數(shù)據(jù)的任務(wù)，在最小任務(wù)當(dāng)中配置一條基線，基線必須配置在任務(wù)的葉子節(jié)點(diǎn)當(dāng)中；配置完成之后，通過葉子節(jié)點(diǎn)，自動(dòng)識(shí)別關(guān)聯(lián)路徑；當(dāng)關(guān)鍵鏈路上有節(jié)點(diǎn)出現(xiàn)各種異常，出現(xiàn)延遲后，系統(tǒng)將通過歷史執(zhí)行時(shí)間進(jìn)行預(yù)測(cè)，計(jì)算所有節(jié)點(diǎn)執(zhí)行時(shí)間結(jié)束之后，是否能夠達(dá)到預(yù)期時(shí)間，這樣無(wú)論中間任務(wù)有所改變，對(duì)于基線的影響都可以做出較為準(zhǔn)確的判斷，一旦基線報(bào)警，勢(shì)必只會(huì)是最后一個(gè)或者是中間的任務(wù)有所影響，再對(duì)應(yīng)通知到基線相關(guān)人員，而不是整個(gè)鏈路當(dāng)中的所有人，從而能夠更快發(fā)現(xiàn)問題，運(yùn)維成本也會(huì)相對(duì)減少。

（6）具體配置內(nèi)容相對(duì)于告警配置減少很多，只需要配置好基線名稱、責(zé)任人、保障任務(wù)、基線類型（包含天和小時(shí)）、預(yù)計(jì)完成時(shí)間（系統(tǒng)自動(dòng)計(jì)算）、承諾完成時(shí)間、預(yù)警時(shí)間、告警方式和告警接收人。

功能上線之初，獲得了很多 RD 同學(xué)的青睞，解決了大量運(yùn)維成本帶來(lái)的問題。 

10、質(zhì)量治理驅(qū)動(dòng)-DQC

數(shù)據(jù)準(zhǔn)確性的監(jiān)控，本質(zhì)上等同于一個(gè)監(jiān)控系統(tǒng)。

?在數(shù)據(jù)表上，配置一些具體的字段級(jí)、行級(jí)數(shù)據(jù)波動(dòng)的監(jiān)測(cè)，對(duì)應(yīng)的閾值。如果數(shù)據(jù)發(fā)生錯(cuò)誤，例如上游任務(wù)出現(xiàn)空跑，對(duì)于下游產(chǎn)生影響，此時(shí)會(huì)觸發(fā)紅色預(yù)警，阻塞下游。

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

（1）分級(jí)治理 P0 全部覆蓋：和業(yè)務(wù)共同梳理，通過反問業(yè)務(wù)如果 Pipeline 出現(xiàn)問題，哪些是涉及資損和輿情層面。

（2）對(duì)于未處理告警優(yōu)化，定期優(yōu)化閾值。

（3）指標(biāo)監(jiān)控閾值：通過對(duì)比業(yè)界標(biāo)準(zhǔn)，給到業(yè)務(wù)最佳實(shí)踐，例如推薦 CTR 一般為 5%。

（4）源監(jiān)控閾值：業(yè)界標(biāo)準(zhǔn)，計(jì)算過去統(tǒng)計(jì)周期內(nèi)的異常率，重復(fù)率，離散值個(gè)數(shù)，離散值條數(shù)分布等值，一方面根據(jù)業(yè)務(wù)形態(tài)自己控制，另一方面屬于行業(yè)內(nèi)部必然會(huì)出現(xiàn)的問題，例如設(shè)備 ID 獲取率通常為 10%。

通過相關(guān)的方法論和組織形態(tài)推動(dòng) DQC 工具的迭代。

11、質(zhì)量治理驅(qū)動(dòng)-回刷工具

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

衡量指標(biāo)一方面是用戶的反饋，另一方面是對(duì)應(yīng)的 ?MTTR 時(shí)間，每次事故產(chǎn)品同學(xué)都會(huì)記錄對(duì)應(yīng)的故障時(shí)間以及修復(fù)時(shí)間，能夠看到明顯優(yōu)化的過程。

12、成本治理驅(qū)動(dòng)

順應(yīng)公司降本增效的要求，我們需要做較多的成本治理驅(qū)動(dòng)。主要從三個(gè)方向著手，如今處于降本增效的環(huán)境下，作為公司級(jí)別的部門，更多為老板考慮的是如何省錢，首先需要明確資產(chǎn)歸屬，如果連資產(chǎn)都不知道屬于誰(shuí)，都統(tǒng)一歸屬平臺(tái)，是沒有辦法做出優(yōu)化或者是找到需要優(yōu)化的人。第二是完善用量賬單，因?yàn)槔习?、業(yè)務(wù)方對(duì)于任務(wù)量級(jí)、存儲(chǔ)大小是無(wú)感知的，更多時(shí)候需要算錢。最后通過治理標(biāo)準(zhǔn)拉出成本優(yōu)化大頭。

13、成本治理驅(qū)動(dòng)-工作空間

在資產(chǎn)歸屬方面，公司當(dāng)中變更頻繁，部門業(yè)務(wù)存在整合與拆分，一個(gè)部門會(huì)因?yàn)闃I(yè)務(wù)調(diào)整，拆分為多個(gè)部門，組織形式多元化，資產(chǎn)資源難以區(qū)分處理，從而導(dǎo)致整體資產(chǎn)不好交接，以及在整體拆分之后資產(chǎn)應(yīng)該交接給誰(shuí)。管理粒度粗，一些部門巨大，職能線多，人數(shù)太多，數(shù)據(jù)管理員難以指定，導(dǎo)致資產(chǎn)管理效率低下。資源隔離難：容易形成數(shù)據(jù)煙囪，數(shù)據(jù)重復(fù)計(jì)算、重復(fù)存儲(chǔ)，因?yàn)槲覀兊牟块T是一個(gè)資源管理單元，會(huì)和隊(duì)列、庫(kù)以及資源存儲(chǔ)的 quota 綁定，容易造成跨業(yè)務(wù)資源容易爭(zhēng)搶，無(wú)法說(shuō)清楚具體每個(gè)業(yè)務(wù)應(yīng)該使用多少資源，依賴復(fù)雜。

于是我們加入了工作空間 workspace，在開發(fā)治理平臺(tái)當(dāng)中，讓所有的資產(chǎn)例如任務(wù)、表、報(bào)表、數(shù)據(jù)源等等歸屬到空間之上，工作空間再歸屬到分管的部門，再?zèng)Q定每個(gè)空間應(yīng)該執(zhí)行哪些對(duì)應(yīng)的隊(duì)列、庫(kù)和存儲(chǔ)，增加了空間之后，可以對(duì)其做很多的治理操作，整個(gè)治理單元更加縱向化，更好的做組織上的溝通。

14、成本治理驅(qū)動(dòng)-用量賬單

這里比較難做的事情在于如何將最終的成本換算成錢給老板看，首先在平臺(tái)上更多通過采購(gòu)服務(wù)器，按照采購(gòu)價(jià)格拆分成單價(jià)，以及通過采集 SDK 獲取用量，而最終的賬單=單價(jià)*用量。整個(gè)數(shù)據(jù)生產(chǎn)當(dāng)中使用到的資源包括 CPU、內(nèi)存和磁盤，單價(jià)如何拆分？

服務(wù)器有對(duì)應(yīng)的采購(gòu)價(jià)格，將整體采購(gòu)價(jià)格分?jǐn)偟矫總€(gè)月，折算出折舊成本，可以和相關(guān)采購(gòu)和財(cái)務(wù)部門確認(rèn)，大概可以估算出一個(gè)服務(wù)器在當(dāng)月對(duì)應(yīng)多少錢，將一次性采購(gòu)的錢拆分成多個(gè)時(shí)間段的錢，在多個(gè)時(shí)間段當(dāng)中按照服務(wù)器的 CPU、內(nèi)存和磁盤的占比，計(jì)算出具體 CPU、內(nèi)存和磁盤對(duì)應(yīng)多少錢，這就是所謂的成本比例。同時(shí)再根據(jù)水位線，由于每個(gè)服務(wù)器不可能所有的資源都給用戶使用，會(huì)有公攤的部分，比如調(diào)度系統(tǒng)當(dāng)中處于等待狀態(tài)的任務(wù)是需要占用公共內(nèi)存的，磁盤也不能全部用滿，否則整個(gè)集群就會(huì)掛掉，所以整體磁盤的水位線一般設(shè)定為 75%，CPU 利用率能夠達(dá)到 80%-90% 之間。水位線數(shù)值一般是基礎(chǔ)架構(gòu)同學(xué)給出的，是一個(gè)較為科學(xué)的數(shù)值，平臺(tái)會(huì)將水位線成本分?jǐn)偟礁鱾€(gè)業(yè)務(wù)線當(dāng)中，這樣我們能夠通過對(duì)應(yīng)的公式：

服務(wù)器拆分成時(shí)間的總價(jià)，各個(gè)使用量單元的占比*水位線即可獲得對(duì)應(yīng)的單價(jià)。

通過采集的工作將每個(gè)執(zhí)行任務(wù)，存儲(chǔ)的表都對(duì)應(yīng)采集到，同時(shí)把他們當(dāng)前使用的 CPU、內(nèi)存和磁盤用量計(jì)算出來(lái)，這樣最終將所有任務(wù)和資產(chǎn)對(duì)應(yīng)的用量乘以單價(jià)得到最終的賬單。

通過上述計(jì)算方式給業(yè)務(wù)和老板最直觀的感受，到底我們用的東西對(duì)應(yīng)消費(fèi)了多少數(shù)值的人民幣。隨之產(chǎn)生的是各部門級(jí)別的資產(chǎn)大盤，以及用戶維度的消費(fèi)資產(chǎn)數(shù)據(jù)。

15、數(shù)據(jù)治理驅(qū)動(dòng)-治理標(biāo)準(zhǔn)

完成上述工作之后，我們可以進(jìn)行數(shù)據(jù)治理相關(guān)全局性的工作。因?yàn)閺馁|(zhì)量成本出發(fā)業(yè)務(wù)側(cè)和老板側(cè)都有了較大的認(rèn)知，方法論上沒有較大的問題，此時(shí)各個(gè)部門如何全局去看，做出建設(shè)，需要我們平臺(tái)推出治理標(biāo)準(zhǔn)。我們的標(biāo)準(zhǔn)是同數(shù)據(jù)治理團(tuán)隊(duì)共同定制的，包括模型建設(shè)、數(shù)據(jù)規(guī)范、數(shù)據(jù)質(zhì)量、任務(wù)優(yōu)化和資源使用五個(gè)維度，各自的評(píng)判標(biāo)準(zhǔn)主要圍繞數(shù)據(jù)一致性、數(shù)據(jù)的及時(shí)性和準(zhǔn)確性、任務(wù)是否存在浪費(fèi)資源、任務(wù)優(yōu)化成本如何以及運(yùn)行資源使用的合理性、水位線是否符合要求。

16、數(shù)據(jù)治理驅(qū)動(dòng)-治理指標(biāo)與功能

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

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

對(duì)應(yīng)產(chǎn)生出來(lái)評(píng)分、榜單、具體的治理項(xiàng)內(nèi)容，換算成錢推送給各個(gè)部門做相對(duì)應(yīng)的治理工作，有了標(biāo)準(zhǔn)之后，對(duì)應(yīng)的工作變得更加容易推進(jìn)，因?yàn)闃I(yè)務(wù)和老板是能夠感受到錢的變化，產(chǎn)生壓力的。

四、產(chǎn)品策略思考

最后總結(jié)一下，在整體平臺(tái)建設(shè)過程中沉淀的一些產(chǎn)品策略思考。

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

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

（3）組織形態(tài)：很多時(shí)候平臺(tái)建設(shè)往往是工具+業(yè)務(wù)，存在通用業(yè)務(wù)的，理應(yīng)上由平臺(tái)做統(tǒng)一出口，更加能夠保證數(shù)據(jù)一致性，所以當(dāng)有了這些業(yè)務(wù)，就會(huì)擁有自己的 Pipeline、開發(fā)同學(xué)，和對(duì)應(yīng)的業(yè)務(wù)要求，形成了自身閉環(huán)，有了業(yè)務(wù)就會(huì)離業(yè)務(wù)更近，這樣就方便后續(xù)做更多的嘗試，包括 Demo 的嘗試。

（4）優(yōu)先級(jí)：如果需求太多，盡量按照質(zhì)量>成本>安全三塊內(nèi)容做出優(yōu)先級(jí)評(píng)估，這只是一個(gè)參考，有些公司老板更注重安全。安全方面更多以做好事后的工作為主，大量的數(shù)據(jù)需要先流轉(zhuǎn)起來(lái)，把業(yè)務(wù)先生產(chǎn)起來(lái)，然后將小批量數(shù)據(jù)做一些安全，對(duì)我們的工具要求反而不是特別高，更多是愿意做安全工作和對(duì)應(yīng)的監(jiān)控。但是質(zhì)量和成本永遠(yuǎn)是業(yè)務(wù)方和老板會(huì)優(yōu)先考慮的問題。

（5）意識(shí)形態(tài)：一定要運(yùn)營(yíng)數(shù)據(jù)而不是只做工具，如果只是照搬行業(yè)內(nèi)的工具去做，甚至抄一遍，不一定能夠達(dá)到目標(biāo)，很多時(shí)候我們開發(fā)的工具是承載了數(shù)據(jù)的。我們需要理解數(shù)據(jù)、任務(wù)是什么樣的，有什么特征，業(yè)務(wù)在使用數(shù)據(jù)當(dāng)中遇到的痛點(diǎn)，再完善工具是一個(gè)較為正向的流程和解決方法。

五、問答環(huán)節(jié)

Q1：如何做平臺(tái)的工具推廣以及使用率，因?yàn)樽銎脚_(tái)更多希望讓平臺(tái)能夠被用起來(lái)，以及我們?cè)谄脚_(tái)的工具建設(shè)初期，最早要做哪些開發(fā)以及對(duì)應(yīng)的優(yōu)先級(jí)是如何規(guī)劃的？

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

Q2： 關(guān)于開源相關(guān)的，如果想要做一個(gè)像樣的治理平臺(tái)或者大數(shù)據(jù)平臺(tái)，有沒有開源的組件進(jìn)行參考或者推薦，這樣能夠直接進(jìn)行快速使用它搭建自己的平臺(tái)？

A2：傳輸模塊的組件業(yè)界比較多，例如 Flume（日志傳輸）、Flink（日志傳輸?shù)挠?jì)算引擎和傳輸引擎）

傳輸過程當(dāng)中會(huì)使用到 Kafka 隊(duì)列對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行削峰填谷和分發(fā)，分發(fā)側(cè)基本也是以 Flink 為主。

離線數(shù)據(jù)傳輸主要是在數(shù)據(jù)庫(kù)傳輸當(dāng)中，有些數(shù)據(jù)對(duì)于數(shù)據(jù)準(zhǔn)確性和一致性要求是非常高的，此時(shí)對(duì)于數(shù)據(jù)庫(kù)傳輸?shù)囊笫遣荒艹霈F(xiàn)丟失或者重復(fù)的，目前在實(shí)時(shí)傳輸中很難解決 SLA 在 100% 的問題，還是需要采用到 DataX 的開源組件以及 Waterdrop 組件做批量數(shù)據(jù)的傳輸，Waterdrop 是基于整個(gè) flink-batch、Spark 計(jì)算引擎做的。

作業(yè)調(diào)度模塊業(yè)界較多的組件是 airflow、易觀開源項(xiàng)目 DolphinScheduler 等比較好的設(shè)計(jì)，大家可以直接進(jìn)行使用或者是二次開發(fā)。

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

Q3： 對(duì)于開放平臺(tái)多租戶的資源管理問題，這塊如何進(jìn)行設(shè)計(jì)，尤其是對(duì)于計(jì)算密集型和資源共享型用戶如何合理的分配資源？

A3：首先可以對(duì)大數(shù)據(jù)資源調(diào)度做一些了解，一般是如何進(jìn)行隔離的，隔離實(shí)際上是按照隊(duì)列進(jìn)行隔離，如果認(rèn)定一個(gè)業(yè)務(wù)單元或者是生產(chǎn)單元屬于是需要被隔離的類型，比如對(duì)于一張報(bào)表，它是給老板看的，我們對(duì)其的要求是一定要做到較好的隔離，首先在平臺(tái)上需要對(duì)其做出標(biāo)識(shí)，標(biāo)識(shí)這個(gè)任務(wù)屬于高優(yōu)任務(wù)，標(biāo)識(shí)完成之后內(nèi)部對(duì)應(yīng)兩種方式做調(diào)度優(yōu)化，一種是調(diào)度系統(tǒng)在任務(wù)執(zhí)行的排隊(duì)過程當(dāng)中會(huì)優(yōu)先在執(zhí)行節(jié)點(diǎn)當(dāng)中執(zhí)行，因?yàn)檎{(diào)度系統(tǒng)屬于中心節(jié)點(diǎn)分發(fā)的過程，分發(fā)到了執(zhí)行節(jié)點(diǎn)，就要看對(duì)應(yīng)任務(wù)的優(yōu)先級(jí)，這時(shí)有了優(yōu)先級(jí)之后就會(huì)把任務(wù)單獨(dú)提高到執(zhí)行節(jié)點(diǎn)當(dāng)中進(jìn)行插隊(duì)執(zhí)行，另一方面執(zhí)行時(shí)候會(huì)有一些計(jì)算任務(wù)，計(jì)算任務(wù)在集群當(dāng)中按照隊(duì)列做的，我們可以要求或者告訴用戶，通過銜接用戶和基礎(chǔ)架構(gòu)之間，在平臺(tái)上支持新建一個(gè)隊(duì)列，在對(duì)應(yīng)任務(wù)當(dāng)中設(shè)置提交隊(duì)列，提交到單獨(dú)的隔離隊(duì)列當(dāng)中，其中的 CPU 和內(nèi)存都是物理隔離的，實(shí)際上這個(gè)任務(wù)就可以完成沒有影響的執(zhí)行。

從全界管理的角度，我們一般會(huì)將整個(gè)隊(duì)列在一個(gè)部門或者工作空間當(dāng)中做出分配，每個(gè)部門或者工作空間擁有一個(gè)單獨(dú)的隊(duì)列，在隊(duì)列當(dāng)中分成 P0、P1、P2 三塊的級(jí)別或者 label。P0 任務(wù)是提供給業(yè)務(wù)方做類似給老板看的任務(wù)，或者是有資損和輿情情況任務(wù)的執(zhí)行，所有調(diào)度優(yōu)先級(jí)最高，且能搶占 P1 和 P2 任務(wù)的資源；P1 主要用于一般任務(wù)、非 P0 任務(wù)的執(zhí)行，P1 可以搶占 P2 任務(wù)資源，但無(wú)法搶占 P0 任務(wù)的資源；P2 資源主要提供給業(yè)務(wù)在平臺(tái)做一些日常 adhoc 查詢，以及常規(guī)補(bǔ)數(shù)據(jù)的查詢，這樣基本上將場(chǎng)景、最終資源以及搶占方式做了對(duì)應(yīng)的設(shè)定，并且在平臺(tái)上有相應(yīng)的調(diào)度算法以及任務(wù)提交隊(duì)列的綁定，實(shí)現(xiàn)對(duì)應(yīng)的隔離方式。