1. 從被數(shù)據(jù)管道淹沒到認(rèn)真寫一個(gè)DataOps博客做了快十年數(shù)據(jù)平臺(tái)相關(guān)的工作一個(gè)非?，F(xiàn)實(shí)的問題是身邊真正把DataOps講清楚的人遠(yuǎn)比真正把DataOps落地的人少。這個(gè)詞被引進(jìn)來之后很多團(tuán)隊(duì)第一反應(yīng)是“這不就是DevOps套到數(shù)據(jù)上嗎”然后買了一堆調(diào)度工具把Airflow裝起來開幾個(gè)自動(dòng)化任務(wù)的會(huì)就覺得DataOps已經(jīng)做完了。我見過太多團(tuán)隊(duì)在半年后回到原點(diǎn)管道照樣掛口徑照樣亂數(shù)據(jù)延遲照樣沒人說得清楚什么時(shí)候能修好。我自己的情況也差不多。早幾年負(fù)責(zé)一個(gè)數(shù)據(jù)平臺(tái)每天早上的第一個(gè)動(dòng)作不是看業(yè)務(wù)報(bào)表而是打開任務(wù)監(jiān)控列表看昨晚的批處理有沒有掛掛在了哪一步誰(shuí)的數(shù)據(jù)沒跑出來。那種每天從“滅火”開始的體驗(yàn)持續(xù)了很長(zhǎng)一段時(shí)間。后來我意識(shí)到問題不在于某一條任務(wù)寫得不好而在于整個(gè)數(shù)據(jù)交付的過程缺少工程化的約束。數(shù)據(jù)管道本質(zhì)上是一套軟件系統(tǒng)但它長(zhǎng)期被當(dāng)作“寫完SQL能出數(shù)就行”的野生產(chǎn)物來維護(hù)這本身就是最大的隱患。這就是我決定認(rèn)真寫Liking‘s DataOps Blog的原因。這個(gè)博客不是列名詞解釋也不是給某家廠商的產(chǎn)品寫軟文而是把我自己從“每天撈數(shù)據(jù)、修任務(wù)、對(duì)口徑”的泥潭里爬出來的過程以及過程中沉淀下來的方法、工具和教訓(xùn)一件件記錄下來。這篇內(nèi)容算是博客的第一篇正式文章我會(huì)把DataOps在真實(shí)工程環(huán)境里到底解決什么問題、哪些概念被過度包裝、落地時(shí)真正要?jiǎng)拥牡胤绞鞘裁匆晃逡皇f清楚。如果你是被“數(shù)據(jù)管道頻繁失敗”“業(yè)務(wù)口徑對(duì)不上”“數(shù)據(jù)交付沒有節(jié)奏感”這些問題困擾的數(shù)據(jù)工程師、數(shù)據(jù)平臺(tái)負(fù)責(zé)人或者你的團(tuán)隊(duì)已經(jīng)在用一些數(shù)據(jù)工具但總覺得差一口氣那這篇文章應(yīng)該對(duì)你有用。沒有PPT式的框架圖只講落地過程中真正起作用的細(xì)節(jié)。2. 關(guān)于DataOps先撕掉幾層認(rèn)知偏差2.1 DataOps不是DevOps的數(shù)據(jù)專用版很多文章喜歡用一個(gè)簡(jiǎn)單的類比DevOps管代碼DataOps管數(shù)據(jù)。這個(gè)類比方向沒錯(cuò)但如果照搬DevOps的實(shí)踐到數(shù)據(jù)領(lǐng)域很快就會(huì)發(fā)現(xiàn)不對(duì)勁。代碼的構(gòu)建和發(fā)布有一個(gè)非常清晰的分界代碼在測(cè)試環(huán)境驗(yàn)證通過合并到主干打包發(fā)布到生產(chǎn)整個(gè)過程可以做到高度標(biāo)準(zhǔn)化回滾也相對(duì)干凈——上一個(gè)版本就是上一個(gè)版本直接切換即可。數(shù)據(jù)的構(gòu)建則完全不同。一個(gè)數(shù)據(jù)任務(wù)跑完產(chǎn)出的不是可以發(fā)布的“交付物”而是一份狀態(tài)。這份狀態(tài)一旦被下游消費(fèi)想回滾就不是把任務(wù)切回上一個(gè)版本就能解決的你還要考慮下游已經(jīng)基于錯(cuò)誤數(shù)據(jù)做了哪些決策、哪些報(bào)表已經(jīng)被導(dǎo)出、哪些模型已經(jīng)被訓(xùn)練。數(shù)據(jù)回滾從來不是“切版本”而是“修正真相”。另一個(gè)關(guān)鍵差異是測(cè)試的語(yǔ)義。DevOps里的單測(cè)是針對(duì)某個(gè)函數(shù)、某個(gè)模塊的確定性斷言輸入固定輸出可預(yù)期。數(shù)據(jù)任務(wù)里經(jīng)常面對(duì)的是“數(shù)據(jù)分布漂移”上游業(yè)務(wù)系統(tǒng)改了訂單狀態(tài)碼下游清洗邏輯沒有跟上結(jié)果某一天產(chǎn)出數(shù)據(jù)的值域范圍變了但任務(wù)本身沒有報(bào)錯(cuò)。單測(cè)能發(fā)現(xiàn)的往往只是表結(jié)構(gòu)對(duì)沒對(duì)上、非空約束有沒有被滿足很難發(fā)現(xiàn)“單量的環(huán)比暴漲了20倍但其實(shí)是因?yàn)樯嫌伟讶∠唵我菜氵M(jìn)去了”。這種情況測(cè)試通過數(shù)據(jù)卻是壞的。我見過不少團(tuán)隊(duì)用DevOps的思路上來就給數(shù)據(jù)任務(wù)加了嚴(yán)苛的CI流程結(jié)果大量時(shí)間耗在讓“任務(wù)能跑過檢查”上真正該關(guān)注的數(shù)據(jù)質(zhì)量反而被忽略了。DataOps一定需要借鑒DevOps的工程化手段但不能把手段當(dāng)目的數(shù)據(jù)和代碼在本質(zhì)上的差異決定了做法必須有自己的邏輯。2.2 工具堆出來了不等于DataOps就落地了2020年前后數(shù)據(jù)工具開始爆發(fā)編排、血緣、質(zhì)量、元數(shù)據(jù)、數(shù)據(jù)資產(chǎn)每個(gè)賽道都有一堆產(chǎn)品。這時(shí)候出現(xiàn)了一種很典型的“工具幻覺”把市面上所有熱門的東西都集成一遍數(shù)據(jù)質(zhì)量平臺(tái)、數(shù)據(jù)目錄、數(shù)據(jù)血緣、任務(wù)編排加起來十幾個(gè)系統(tǒng)看起來什么都有但數(shù)據(jù)平臺(tái)的現(xiàn)狀沒有任何改善。為什么因?yàn)檫@些工具彼此獨(dú)立數(shù)據(jù)孤島變成了“工具孤島”。血緣系統(tǒng)畫出來的鏈路圖和實(shí)際的調(diào)度依賴對(duì)不上質(zhì)量平臺(tái)每天出了一堆告警但沒人處理編排平臺(tái)的DAG越畫越復(fù)雜核心的靠人工維護(hù)的定時(shí)任務(wù)還是照舊。每一個(gè)工具都在“運(yùn)行”但它們沒有連成一條真正的流水線。DataOps的核心價(jià)值在于“端到端地看數(shù)據(jù)交付這件事”。從業(yè)務(wù)系統(tǒng)的數(shù)據(jù)產(chǎn)生到加工清洗到進(jìn)入數(shù)倉(cāng)/數(shù)據(jù)湖再到提供給分析、報(bào)表、模型消費(fèi)這中間的所有環(huán)節(jié)要當(dāng)成一條流水線來設(shè)計(jì)。如果買了工具但不去動(dòng)流程本身工具再多也只是給原本混亂的過程增加了一層新的混亂。2.3 DataOps與數(shù)據(jù)治理、Data Fabric不是一回事這個(gè)認(rèn)知偏差在行業(yè)里很常見有人把DataOps理解為數(shù)據(jù)治理的工程化升級(jí)也有人把DataFabric和DataOps當(dāng)成同義詞互換著用。從我自己的實(shí)踐感受來說這三者的邊界其實(shí)很清晰它們的關(guān)注點(diǎn)完全不在一個(gè)層面。數(shù)據(jù)治理的核心是“定規(guī)則”誰(shuí)來負(fù)責(zé)這個(gè)數(shù)據(jù)域、這個(gè)字段的業(yè)務(wù)定義是什么、哪些數(shù)據(jù)涉及隱私需要脫敏、數(shù)據(jù)的保留周期是多長(zhǎng)。治理的產(chǎn)出物是規(guī)范、流程、職責(zé)本質(zhì)上偏“管理”。DataFabric的核心是“織一層智能的數(shù)據(jù)訪問層”讓用戶能通過統(tǒng)一的接口拿到分布式環(huán)境中合適的數(shù)據(jù)它強(qiáng)調(diào)的是架構(gòu)形態(tài)試圖通過虛擬化、知識(shí)圖譜、主動(dòng)元數(shù)據(jù)等技術(shù)讓“找數(shù)”和“用數(shù)”更順滑偏“架構(gòu)”。DataOps的核心是“把這些事情放到工程化流水線里持續(xù)運(yùn)作”。一個(gè)數(shù)據(jù)平臺(tái)可以沒有嚴(yán)格意義上的DataFabric架構(gòu)但DataOps的原則依然適用數(shù)據(jù)治理的規(guī)范最終一定要落到具體的任務(wù)和流水線里去執(zhí)行否則治理落地就是一句空話。我自己的理解是治理負(fù)責(zé)定義“正確”是什么DataFabric負(fù)責(zé)讓數(shù)據(jù)更好被找到DataOps負(fù)責(zé)讓數(shù)據(jù)以可靠、敏捷的方式持續(xù)交付出來。三者需要協(xié)作但不能混為一談。3. 我在項(xiàng)目中推DataOps的實(shí)際動(dòng)作從編排到契約3.1 第一件事盤點(diǎn)存量數(shù)據(jù)管道建立“失敗清單”真正動(dòng)手做DataOps改進(jìn)第一步不是選工具而是先把現(xiàn)狀摸清楚。我習(xí)慣的做法是把當(dāng)前生產(chǎn)環(huán)境所有定時(shí)數(shù)據(jù)任務(wù)拉出來按以下維度清單化任務(wù)的所有人owner調(diào)度頻率與依賴上游近30天失敗次數(shù)與最頻繁的失敗原因是否有監(jiān)控、是否有重試機(jī)制、告警是否真的有效下游消費(fèi)方報(bào)表、接口、算法、下游任務(wù)產(chǎn)出數(shù)據(jù)的關(guān)鍵質(zhì)量維度行數(shù)、主鍵唯一性、異常率等這張清單的價(jià)值在于把“數(shù)據(jù)管道很亂”這種模糊的感受變成了可以量化的“失敗任務(wù)Top 10”“無人認(rèn)領(lǐng)任務(wù)Top 20”“下游鏈路不清晰任務(wù)Top 10”。沒有這份清單前很多人開會(huì)討論的是感受有了這份清單討論的是具體問題。我見過最多的“隱性炸彈”是無人認(rèn)領(lǐng)的任務(wù)任務(wù)掛在某臺(tái)服務(wù)器上每天跑但沒人說得清它是誰(shuí)建的、產(chǎn)出給誰(shuí)用。直到某一天下游的人來找你說“這個(gè)數(shù)據(jù)停了三天了為什么沒人修”你才發(fā)現(xiàn)這臺(tái)機(jī)器上掛著一個(gè)沒有任何負(fù)責(zé)人、沒有任何監(jiān)控的任務(wù)。這種任務(wù)DataOps改造的第一步就該下線或者明確歸屬。3.2 把數(shù)據(jù)流水線的CI/CD落到實(shí)處很多團(tuán)隊(duì)說自己在做“DataOps”但每天的流程還是有人把SQL改了一版直接在生產(chǎn)環(huán)境跑跑出問題了再回滾。這個(gè)流程缺少最基本的工程約束。我在自己的項(xiàng)目里把數(shù)據(jù)流水線的CI/CD拆成了四層每一層都做了對(duì)應(yīng)的檢查。第一層是“代碼入庫(kù)”所有用于數(shù)據(jù)加工的任務(wù)定義、SQL腳本、配置文件必須統(tǒng)一放到Git倉(cāng)庫(kù)管理不能只存留在調(diào)度平臺(tái)里。這一步看似基礎(chǔ)但能解決大量實(shí)際問題比如“上個(gè)月誰(shuí)改了什么任務(wù)說不清楚”“這個(gè)版本的邏輯為什么要改”“事故出在哪個(gè)版本”。很多數(shù)據(jù)團(tuán)隊(duì)管不好任務(wù)版本根本原因就是沒把任務(wù)當(dāng)代碼管理。第二層是“構(gòu)建與測(cè)試”語(yǔ)法檢查與字段級(jí)校驗(yàn)在任務(wù)提交后用腳本檢查SQL語(yǔ)法是否合法目標(biāo)表字段是否存在字段類型映射是否匹配。單元測(cè)試對(duì)每個(gè)核心清洗邏輯構(gòu)建“最小用例”用樣本數(shù)據(jù)驗(yàn)證邏輯正確性。比如“訂單狀態(tài)碼999的臟數(shù)據(jù)應(yīng)該被過濾”“金額字段為負(fù)的記錄應(yīng)該被打標(biāo)而不是丟棄”。數(shù)據(jù)質(zhì)量測(cè)試嵌入用數(shù)據(jù)質(zhì)量工具我在第四部分會(huì)細(xì)說在數(shù)據(jù)產(chǎn)出后自動(dòng)運(yùn)行校驗(yàn)比如“訂單明細(xì)表主鍵唯一性”“核心業(yè)務(wù)表行數(shù)與昨日變化不超過10%”“字段空值率不超過5%”。校驗(yàn)不通過的任務(wù)不允許進(jìn)入下一環(huán)節(jié)。第三層是“部署與發(fā)布”數(shù)據(jù)任務(wù)的發(fā)布不能簡(jiǎn)單等同于“把代碼提交到生產(chǎn)”。我習(xí)慣把生產(chǎn)數(shù)據(jù)任務(wù)分成兩套環(huán)境的概念——雖然大多數(shù)情況下數(shù)據(jù)環(huán)境和計(jì)算資源是同一套但“預(yù)發(fā)布階段”和“正式發(fā)布階段”要分開。預(yù)發(fā)布階段先跑一個(gè)簡(jiǎn)化版本只處理小分區(qū)比如只處理最近1小時(shí)或最近100MB的數(shù)據(jù)驗(yàn)證新邏輯在實(shí)際生產(chǎn)數(shù)據(jù)上不會(huì)出問題確認(rèn)無誤后再切換到全量分區(qū)跑正式發(fā)布。這有點(diǎn)類似灰度發(fā)布的概念在實(shí)際操作中可以極大降低大改動(dòng)的風(fēng)險(xiǎn)。第四層是“監(jiān)控與告警閉環(huán)”任務(wù)失敗要有告警告警要有認(rèn)領(lǐng)認(rèn)領(lǐng)要有處理記錄。很多團(tuán)隊(duì)做到“有告警”就停住了結(jié)果告警過多變成“狼來了”每天幾百條告警習(xí)慣了之后連真正的故障都會(huì)被忽略。我后來的做法是告警分級(jí)、認(rèn)領(lǐng)制度和每周失敗原因復(fù)盤。P0級(jí)告警意味著核心業(yè)務(wù)數(shù)據(jù)鏈路中斷要在15分鐘內(nèi)響應(yīng)P1級(jí)是數(shù)據(jù)質(zhì)量異常但鏈路未斷4小時(shí)內(nèi)處理P2級(jí)是可延后處理的告警。每周固定時(shí)間把一周的失敗任務(wù)清單過一遍找出共性問題而不是每天疲于奔命。3.3 真正關(guān)鍵的是“數(shù)據(jù)契約”不是血緣血緣lineage確實(shí)是DataOps里的重要信息但依賴血緣系統(tǒng)解決所有問題是很多團(tuán)隊(duì)的誤區(qū)。血緣工具畫出來的鏈路圖再漂亮如果它展示的是“字段從哪里來”而不是“實(shí)際運(yùn)行中數(shù)據(jù)是怎么流轉(zhuǎn)的”那它對(duì)排查問題的作用有限。我在實(shí)際項(xiàng)目里更看重“數(shù)據(jù)契約”——數(shù)據(jù)生產(chǎn)者與數(shù)據(jù)消費(fèi)者之間的一份明確約定。契約的內(nèi)容包括表/字段命名規(guī)范字段的業(yè)務(wù)口徑定義字段的數(shù)據(jù)類型、取值范圍、編碼標(biāo)準(zhǔn)數(shù)據(jù)產(chǎn)出的時(shí)限SLA比如“每日凌晨6點(diǎn)前必須產(chǎn)出”數(shù)據(jù)質(zhì)量的最低標(biāo)準(zhǔn)非空率、唯一性、變更率容忍范圍有了契約數(shù)據(jù)管道之間就不再是“你產(chǎn)出、我用”這種模糊關(guān)系而是有明確檢查點(diǎn)的協(xié)作關(guān)系。上游要保證產(chǎn)出符合契約下游消費(fèi)前可以自動(dòng)校驗(yàn)契約是否符合要求。這份契約甚至可以用機(jī)器可讀的方式維護(hù)比如用YAML文件定義在倉(cāng)庫(kù)里在數(shù)據(jù)發(fā)布時(shí)自動(dòng)校驗(yàn)。我印象很深的一個(gè)案例業(yè)務(wù)團(tuán)隊(duì)要上線一個(gè)新功能改了訂單表里的一個(gè)字段含義從“下單時(shí)間”改成“支付完成時(shí)間”。這個(gè)改動(dòng)在業(yè)務(wù)代碼里只影響一個(gè)頁(yè)面展示但在數(shù)據(jù)鏈路里影響的是無數(shù)下游報(bào)表和模型。沒有數(shù)據(jù)契約這個(gè)改動(dòng)可能要過兩三周才會(huì)以“報(bào)表數(shù)據(jù)對(duì)不上”的方式爆發(fā)出來有了契約發(fā)布前就能被自動(dòng)檢查攔截上游字段口徑變更了舊契約校驗(yàn)失敗下游負(fù)責(zé)人提前收到變更通知該調(diào)整的調(diào)整該確認(rèn)的確認(rèn)。這才是DataOps要解決的核心問題——不是讓所有數(shù)據(jù)任務(wù)永遠(yuǎn)不失敗而是讓變更、失敗、恢復(fù)都是可控和可預(yù)期的。4. 支撐這套流程的工具鏈選型不翻車的幾條經(jīng)驗(yàn)4.1 調(diào)度與編排別只盯著Airflow編排工具是數(shù)據(jù)流水線的骨架Airflow因?yàn)樯鷳B(tài)成熟、社區(qū)樣本多確實(shí)是最多人上手的方案。但Airflow的坑也明顯——它本質(zhì)上是一個(gè)“調(diào)度平臺(tái)”性質(zhì)的系統(tǒng)DAG寫起來靈活但復(fù)雜依賴一多多層依賴關(guān)系和動(dòng)態(tài)任務(wù)生成會(huì)讓DAG的可讀性迅速惡化。我自己維護(hù)過一個(gè)幾百個(gè)任務(wù)的大規(guī)模Airflow集群到了后期出問題最多的已經(jīng)不是任務(wù)邏輯本身而是DAG之間的依賴關(guān)系被隱式邏輯搞亂。如果你在選型我給一個(gè)比較務(wù)實(shí)的判斷維度需求特征推薦方向理由團(tuán)隊(duì)有Python基礎(chǔ)任務(wù)類型以SQL/Spark為主需要高度定制Airflow生態(tài)最全、踩坑資料最多、定制度高數(shù)據(jù)資產(chǎn)豐富任務(wù)間依賴復(fù)雜想把數(shù)據(jù)資產(chǎn)和任務(wù)放在一起管理Dagster軟件定義資產(chǎn)模型資產(chǎn)與任務(wù)綁定關(guān)系清晰可觀測(cè)性強(qiáng)團(tuán)隊(duì)規(guī)模小任務(wù)量不大希望上手快、開發(fā)體驗(yàn)現(xiàn)代化PrefectAPI設(shè)計(jì)友好本地開發(fā)和云端執(zhí)行分離做得好深度綁定云廠商不想自己運(yùn)維調(diào)度平臺(tái)云廠商托管調(diào)度服務(wù)如AWS MWAA、阿里云DataWorks等運(yùn)維成本最低但廠商鎖定要提前評(píng)估我自己現(xiàn)在的項(xiàng)目用的是Dagster。原因是我們的業(yè)務(wù)已經(jīng)不缺任務(wù)缺的是“看清任務(wù)和資產(chǎn)的關(guān)系”。Dagster的Asset模型讓我可以像聲明變量一樣把數(shù)據(jù)資產(chǎn)聲明出來任務(wù)之間的關(guān)系通過資產(chǎn)依賴自然表達(dá)調(diào)度、血緣、日志都圍繞資產(chǎn)展開排障路徑清晰很多。但這不意味著Airflow不好——如果你的團(tuán)隊(duì)已經(jīng)熟練使用Airflow遷移成本是需要認(rèn)真衡量的工具永遠(yuǎn)是為流程服務(wù)的不是反過來。4.2 數(shù)據(jù)質(zhì)量測(cè)試不是裝一個(gè)平臺(tái)就完事數(shù)據(jù)質(zhì)量是DataOps里最容易被“形式化”的部分。很多團(tuán)隊(duì)選型了商業(yè)數(shù)據(jù)質(zhì)量平臺(tái)配置了一堆質(zhì)量規(guī)則但告警一封封發(fā)出來處理率卻趨近于零。原因不外乎兩個(gè)規(guī)則閾值設(shè)得過于敏感或者質(zhì)量規(guī)則和具體任務(wù)脫節(jié)告警發(fā)出去了沒人知道要找誰(shuí)。我的經(jīng)驗(yàn)是先用輕量級(jí)工具把流程跑通再考慮要不要上重平臺(tái)。開源領(lǐng)域比較典型的兩個(gè)選項(xiàng)是Great Expectations以下簡(jiǎn)稱GE和Soda Core。GE適合做“數(shù)據(jù)文檔式”的驗(yàn)證通過Expectation Suite描述“我期望這份數(shù)據(jù)長(zhǎng)什么樣”然后對(duì)DataFrame或數(shù)據(jù)庫(kù)表執(zhí)行驗(yàn)證。它和Notebook、Python生態(tài)結(jié)合得很好適合數(shù)據(jù)探索階段快速做質(zhì)量斷言。Soda Core對(duì)“數(shù)據(jù)管道里的自動(dòng)監(jiān)控”更友好可以直接在配置里聲明數(shù)據(jù)源的檢查規(guī)則比如“昨日訂單表行數(shù)不能少于100萬(wàn)”“customer_id列唯一值數(shù)量偏差不能超過5%”和CI/CD集成很順滑。它生成的告警信息也更貼近工程側(cè)需要。我自己現(xiàn)在的做法是GE負(fù)責(zé)開發(fā)和測(cè)試階段的數(shù)據(jù)驗(yàn)證Soda Core負(fù)責(zé)生產(chǎn)環(huán)境的監(jiān)控。測(cè)試階段把關(guān)的是“邏輯寫對(duì)了沒”生產(chǎn)監(jiān)控管的是“今天的真實(shí)數(shù)據(jù)出了什么幺蛾子”。兩件事的語(yǔ)義不同用兩種工具各管一段反而比一個(gè)“萬(wàn)能平臺(tái)”更順手。4.3 元數(shù)據(jù)與血緣先明確要解決什么問題再選工具血緣工具的選型也是很多團(tuán)隊(duì)會(huì)糾結(jié)的地方。我的建議是先想清楚你要血緣解決什么問題再選工具。如果要解決的是“合規(guī)審計(jì)”場(chǎng)景——某個(gè)字段的數(shù)據(jù)來自哪些系統(tǒng)誰(shuí)加工過展示給誰(shuí)看過那需要的是能夠從SQL解析出溯源關(guān)系的血緣工具OpenMetadata或者DataHub都可行但關(guān)鍵是你的SQL和任務(wù)是不是都規(guī)范化管理了。如果SQL本身就散落在各個(gè)臨時(shí)腳本里血緣工具再?gòu)?qiáng)也畫不出完整的依賴圖。如果要解決的是“排障場(chǎng)景”——某個(gè)表的數(shù)據(jù)怎么變了影響了下游哪些表和報(bào)表那血緣必須和實(shí)際調(diào)度運(yùn)行記錄結(jié)合起來。靜態(tài)SQL解析出的血緣經(jīng)常漏掉動(dòng)態(tài)生成SQL的場(chǎng)景比如通過配置文件拼接出來的表名。排障的時(shí)候指著血緣圖說“這條鏈路有影響”結(jié)果實(shí)際動(dòng)態(tài)運(yùn)行時(shí)走了另一條鏈路反而誤導(dǎo)排查方向。我踩過的一個(gè)具體坑是早期我們實(shí)現(xiàn)血緣是拿SQL文本做正則解析覆蓋率看起來還行但后來發(fā)現(xiàn)有一個(gè)核心表的血緣關(guān)系解析錯(cuò)了——因?yàn)橄到y(tǒng)在SQL里用了變量替換表名靜態(tài)解析識(shí)別出來的上下游全錯(cuò)了排障時(shí)沿著錯(cuò)誤血緣查了半天才發(fā)現(xiàn)問題出在真正的上游。后來我把血緣的維護(hù)方式改成了基于實(shí)際運(yùn)行記錄的采集從任務(wù)調(diào)度系統(tǒng)的執(zhí)行日志反推真實(shí)的上下游關(guān)系正確率才真正上來。這個(gè)經(jīng)驗(yàn)一句話總結(jié)就是血緣要吃“實(shí)際運(yùn)行記錄”不能只吃“聲明式依賴”。4.4 數(shù)據(jù)版本的哲學(xué)區(qū)分“臨時(shí)彈性”和“長(zhǎng)期可復(fù)現(xiàn)”在DataOps里有一個(gè)被低估的問題數(shù)據(jù)管道跑出來的結(jié)果能不能復(fù)現(xiàn)。代碼有版本號(hào)數(shù)據(jù)同樣應(yīng)該有可追溯的信息——這份數(shù)據(jù)是哪個(gè)任務(wù)、哪個(gè)版本、哪個(gè)時(shí)間窗口跑出來的。我在設(shè)計(jì)數(shù)據(jù)任務(wù)時(shí)堅(jiān)持一個(gè)原則核心業(yè)務(wù)數(shù)據(jù)表的產(chǎn)出信息必須自描述。最簡(jiǎn)單的方式是給表增加一套“元數(shù)據(jù)字段”不管叫_snapshot_time_job_version還是_sql_commit_id關(guān)鍵是讓每一個(gè)下游消費(fèi)者能回答“這份數(shù)據(jù)是什么時(shí)候生成的、由哪個(gè)版本的任務(wù)加工出來的”。這個(gè)原則在排查歷史數(shù)據(jù)質(zhì)量問題時(shí)特別管用。比如業(yè)務(wù)方某天來問“為什么上周三的報(bào)表數(shù)據(jù)和今天重刷的數(shù)據(jù)對(duì)不上”如果你有版本信息很快可以定位是“上周三跑的是舊版任務(wù)今天跑的是新邏輯”從而快速判斷差異原因。如果沒有這些字段就只能靠猜而數(shù)據(jù)領(lǐng)域最怕的就是靠猜。數(shù)據(jù)版本還有一個(gè)維度是回放/重放。數(shù)據(jù)管道重跑一個(gè)歷史分區(qū)應(yīng)該像代碼回滾一樣可預(yù)期。我建議每個(gè)調(diào)度任務(wù)都支持“指定業(yè)務(wù)日期范圍重跑”的能力且重跑時(shí)必須校驗(yàn)已有分區(qū)是否會(huì)被覆蓋、下游是否感知到數(shù)據(jù)已變更。這一點(diǎn)看起來基礎(chǔ)但在真實(shí)項(xiàng)目里因?yàn)橹嘏軐?dǎo)致下游重復(fù)計(jì)算、重復(fù)入數(shù)的案例比比皆是。5. 最容易翻車的三個(gè)環(huán)節(jié)修復(fù)記錄5.1 數(shù)據(jù)回滾為什么“回滾”這個(gè)詞在數(shù)據(jù)領(lǐng)域是偽命題做DataOps的過程中我遇到過最棘手的一次事故上游業(yè)務(wù)系統(tǒng)的庫(kù)表結(jié)構(gòu)變更導(dǎo)致當(dāng)天清洗任務(wù)產(chǎn)出的訂單數(shù)據(jù)出現(xiàn)了大面積亂碼和字段錯(cuò)位。事故發(fā)現(xiàn)已經(jīng)是業(yè)務(wù)部門下午看報(bào)表的時(shí)候了。第一反應(yīng)是“回滾”——把任務(wù)切回昨天的版本重新跑。但緊接著問題來了今天的表已經(jīng)被昨天的版本覆蓋但下游的報(bào)表已經(jīng)在早上讀了新數(shù)據(jù)算法團(tuán)隊(duì)已經(jīng)用今天的錯(cuò)誤數(shù)據(jù)跑了一版模型?；貪L任務(wù)能修復(fù)表但修復(fù)不了已經(jīng)發(fā)生的消費(fèi)行為。那次之后我把數(shù)據(jù)任務(wù)事故響應(yīng)流程改成了三步走止損第一時(shí)間停掉下游所有依賴這條鏈路的任務(wù)防止錯(cuò)誤數(shù)據(jù)擴(kuò)散。修復(fù)數(shù)據(jù)用正確的邏輯重新生成受影響分區(qū)同時(shí)把數(shù)據(jù)變更事件主動(dòng)通知給所有下游消費(fèi)者附上“數(shù)據(jù)已修正請(qǐng)基于新數(shù)據(jù)重新消費(fèi)”的說明。復(fù)盤根因?yàn)槭裁瓷嫌巫兏鼪]有被及時(shí)發(fā)現(xiàn)是測(cè)試數(shù)據(jù)集沒有覆蓋到這個(gè)變更場(chǎng)景還是監(jiān)控閾值沒有覆蓋范圍校驗(yàn)values beyond expected range)數(shù)據(jù)回滾的真相是你無法讓所有消費(fèi)方回到事故發(fā)生之前你能做的是快速縮短“錯(cuò)誤數(shù)據(jù)的生命周期”并讓錯(cuò)誤數(shù)據(jù)的擴(kuò)散范圍盡可能小。這種思路應(yīng)該被設(shè)計(jì)進(jìn)系統(tǒng)里而不是等事故發(fā)生時(shí)靠人工臨時(shí)抱佛腳。5.2 測(cè)試的“數(shù)據(jù)保鮮”離線驗(yàn)證通過上線就掛做數(shù)據(jù)管道自動(dòng)化測(cè)試時(shí)另一個(gè)高頻翻車點(diǎn)開發(fā)和測(cè)試階段用的是歷史樣本數(shù)據(jù)驗(yàn)證全過一上線跑真實(shí)數(shù)據(jù)直接掛掉。原因基本都是測(cè)試數(shù)據(jù)和真實(shí)數(shù)據(jù)分布差異過大。比如開發(fā)環(huán)境里的測(cè)試表數(shù)據(jù)量是幾千行生產(chǎn)環(huán)境每天產(chǎn)出上億行測(cè)試數(shù)據(jù)里的枚舉值只有兩三個(gè)生產(chǎn)環(huán)境里能冒出十幾種異常編碼。我的修復(fù)方案是“影子測(cè)試數(shù)據(jù)子集”的組合打法影子測(cè)試在測(cè)試環(huán)境里用一份脫敏后的生產(chǎn)數(shù)據(jù)子集按核心維度抽樣來運(yùn)行任務(wù)。這樣測(cè)試的輸入和生產(chǎn)的輸入分布基本一致跑出來的結(jié)果才有說服力。數(shù)據(jù)子集從生產(chǎn)數(shù)據(jù)中按規(guī)則抽取一個(gè)“小而全”的分區(qū)集。抽取規(guī)則不是隨機(jī)抽樣而是“每個(gè)分支機(jī)構(gòu)取一天數(shù)據(jù)、每個(gè)業(yè)務(wù)類型取一條極端值記錄、每種異常碼保留一條”確保測(cè)試集能覆蓋生產(chǎn)數(shù)據(jù)的主要分布特征。另外質(zhì)量測(cè)試?yán)镆欢ㄒ胺植甲兓瘷z測(cè)”這一項(xiàng)。不一定用太重型的統(tǒng)計(jì)檢驗(yàn)一個(gè)簡(jiǎn)單的移動(dòng)窗口均值/方差對(duì)比就很有用計(jì)算昨日核心指標(biāo)均值與近7日均值的偏離度超過閾值就告警。這種檢測(cè)對(duì)“數(shù)據(jù)突然漂移”類問題極其有效。5.3 血緣優(yōu)先級(jí)的教訓(xùn)靜態(tài)解析必須讓位于運(yùn)行時(shí)信息我在4.3里提過靜態(tài)血緣解析的坑這里把排查鏈路完整記錄一遍。當(dāng)時(shí)的情況是業(yè)務(wù)方反饋“某核心報(bào)表的今日數(shù)據(jù)比昨日少了30%”我們需要快速定位“少的數(shù)據(jù)源頭在哪”。第一輪排查我們打開血緣系統(tǒng)看到“報(bào)表→DW層某匯總表→ODS層訂單表”這條依賴鏈檢查了鏈路里的每一個(gè)任務(wù)都沒發(fā)現(xiàn)問題任務(wù)全部成功、調(diào)度全部正常。數(shù)據(jù)為什么還少第二輪排查我們把視角從“血緣圖”切到“實(shí)際運(yùn)行日志”去調(diào)度系統(tǒng)里查這個(gè)報(bào)表任務(wù)真正依賴的上游節(jié)點(diǎn)。結(jié)果發(fā)現(xiàn)該報(bào)表任務(wù)在調(diào)度配置里除了血緣圖上顯示的那張匯總表還依賴一個(gè)“手工同步任務(wù)”產(chǎn)出的外部表這張外部表是另一個(gè)團(tuán)隊(duì)通過一個(gè)臨時(shí)腳本同步的血緣系統(tǒng)完全沒有采到。昨天這個(gè)手工任務(wù)因?yàn)樵炊藱?quán)限變更跑失敗了沒人注意到。那一刻我徹底明白了血緣工具只是一個(gè)輔助真正給出事實(shí)的是系統(tǒng)的運(yùn)行記錄和任務(wù)依賴關(guān)系。血緣圖可以幫你做信息檢索和審計(jì)但排障時(shí)必須把“實(shí)際執(zhí)行鏈路”作為第一依據(jù)血緣可視化只能作為輔助理解。后來我們強(qiáng)制要求所有任務(wù)在調(diào)度系統(tǒng)中的依賴都必須顯式聲明任何隱式依賴比如任務(wù)里面用代碼讀取另一張表但沒有在調(diào)度層聲明都要被消滅同時(shí)血緣展示的優(yōu)先級(jí)改為“運(yùn)行記錄優(yōu)先、靜態(tài)解析兜底”。這套調(diào)整之后同類排障的時(shí)間縮短了很多。6. 如果你也想從0開始跑DataOps第一步應(yīng)該這么做每次有人問我“我們團(tuán)隊(duì)也想做DataOps應(yīng)該從哪里開始”我的回答都不是“買工具”而是“先選一條具體的數(shù)據(jù)鏈路把它當(dāng)樣板間來做”。不要一開始就試圖做全平臺(tái)改造那樣會(huì)陷入第二章節(jié)說過的“工具幻覺”。我的建議是選擇一個(gè)“高頻使用、常出問題、影響面可控”的核心業(yè)務(wù)數(shù)據(jù)域比如訂單域或者用戶域把這一條鏈路的端到端流程徹底理一遍。具體路徑可以按四步走找出這條鏈路的所有數(shù)據(jù)任務(wù)、責(zé)任人、依賴關(guān)系和消費(fèi)方壓縮成一張真實(shí)的鏈路清單。在任務(wù)的上游與下游之間建立明確的數(shù)據(jù)契約把字段口徑、SLA、質(zhì)量預(yù)期都白紙黑字定下來。給這條鏈路套上自動(dòng)化質(zhì)量檢測(cè)和告警閉環(huán)數(shù)據(jù)產(chǎn)出后立即跑質(zhì)量檢查失敗立即告警并自動(dòng)暫停下游。用一周的時(shí)間把這條鏈路的失敗任務(wù)和告警做一次復(fù)盤找到最高頻的問題根因。這個(gè)“樣板間”做好之后你會(huì)得到三個(gè)可以量化的收益管道失敗率明顯下降因?yàn)槭”桓彀l(fā)現(xiàn)、更快處理數(shù)據(jù)交付時(shí)間變得可預(yù)期因?yàn)橛辛薙LA和數(shù)據(jù)契約團(tuán)隊(duì)積累了完整的DataOps實(shí)踐方法而不是一堆工具的說明書再把樣板間的經(jīng)驗(yàn)復(fù)制到其他數(shù)據(jù)域推進(jìn)阻力會(huì)小很多因?yàn)槟贸鰜淼亩际钦鎸?shí)的成功案例而不是一套紙面方法論。我在自己的項(xiàng)目里就是這么起步的。最初只是選了訂單域的一條核心鏈路做了改造用了大概三周時(shí)間把鏈路理清楚、加了契約和質(zhì)量檢測(cè)、砍掉了兩個(gè)無人認(rèn)領(lǐng)的下游任務(wù)。三周之后的效果是這條鏈路的平均失敗恢復(fù)時(shí)間從“小時(shí)級(jí)”降到了“分鐘級(jí)”因?yàn)楦婢苤苯佣ㄎ坏骄唧w的任務(wù)和環(huán)節(jié)不再需要人肉翻日志。后面再往其他域擴(kuò)展時(shí)團(tuán)隊(duì)里沒有人再質(zhì)疑DataOps是不是一個(gè)空洞的概念因?yàn)榇蠹乙呀?jīng)看到了它帶來的實(shí)實(shí)在在的變化。