我一直覺得很多團(tuán)隊(duì)把數(shù)據(jù)清洗這件事做小了。一說數(shù)據(jù)清洗第一反應(yīng)就是寫幾個SQL把空值填上、把重復(fù)行去掉。但在數(shù)據(jù)倉庫這個場景里數(shù)據(jù)清洗根本沒有這么簡單——它是建模的一部分是數(shù)據(jù)質(zhì)量的防線是后面所有報(bào)表、算法、決策能不能站住腳的地基。數(shù)據(jù)倉庫里的數(shù)據(jù)清洗方法本質(zhì)上解決的是一堆雜亂無章的原始數(shù)據(jù)如何變成可信、可用、可追溯的分析底座這件事。這篇文章我從數(shù)倉的分層架構(gòu)出發(fā)聊清楚清洗規(guī)則應(yīng)該釘在哪一層、用什么工具做、真實(shí)臟數(shù)據(jù)場景下怎么排查末尾附一段網(wǎng)約車訂單清洗的完整實(shí)戰(zhàn)鏈路。適合正在搭數(shù)倉、做離線數(shù)倉開發(fā)、或者被數(shù)據(jù)怎么這么臟困擾的朋友收藏起來下次直接照著做。1. 數(shù)倉里的數(shù)據(jù)清洗不是修數(shù)據(jù)是建模的一部分先做一個認(rèn)知上的正本清源。很多從業(yè)務(wù)系統(tǒng)轉(zhuǎn)過來的人會把數(shù)據(jù)清洗想成把這些臟值修好。但你仔細(xì)想業(yè)務(wù)系統(tǒng)里的數(shù)據(jù)清理和數(shù)倉里的數(shù)據(jù)清洗面對的對象、約束和目標(biāo)都完全不同。1.1 業(yè)務(wù)庫清洗 vs 數(shù)倉清洗的分工差異業(yè)務(wù)庫里的數(shù)據(jù)是給系統(tǒng)用的事務(wù)型數(shù)據(jù)庫講究的是當(dāng)前狀態(tài)正確、寫入性能高。你很少會在業(yè)務(wù)庫里做大規(guī)模的歷史數(shù)據(jù)回溯修正因?yàn)槟菚绊懢€上交易。而數(shù)倉里的數(shù)據(jù)是給分析用的它的特點(diǎn)是海量、多源、歷史累計(jì)而且洗完之后要能被反復(fù)讀取、追溯和重算。這意味著數(shù)倉里的數(shù)據(jù)清洗至少要滿足三個額外要求可重放清洗邏輯必須是確定性的同一份輸入無論跑多少次輸出必須一致。不能像修線上數(shù)據(jù)那樣手工改幾條記錄就完事因?yàn)閿?shù)倉要應(yīng)對的是TB級乃至PB級的批量加工?？勺匪菝恳粭l被清洗過的數(shù)據(jù)最好能知道它原來長什么樣、被什么規(guī)則變成了什么樣。這不僅僅是審計(jì)需求也是排查下游指標(biāo)異常時的救命稻草?？煞謱忧逑磩幼饕坏┗煸跇I(yè)務(wù)邏輯里后面維護(hù)的人會非常痛苦。所以清洗規(guī)則必須跟著數(shù)倉的分層架構(gòu)走哪一層做什么邊界必須清晰。1.2 清洗規(guī)則的本質(zhì)對業(yè)務(wù)語義的數(shù)字化約束我打個比方。業(yè)務(wù)庫里的一條記錄就像一個剛跑完現(xiàn)場回來的銷售人員的草稿本字跡潦草、縮寫隨意、甚至有些數(shù)字明顯抄錯了。數(shù)倉的清洗環(huán)節(jié)相當(dāng)于把草稿本重新謄寫成一份標(biāo)準(zhǔn)化的臺賬——但不是你想怎么謄就怎么謄而是按一套明確的規(guī)范來謄。這套規(guī)范就是業(yè)務(wù)語義的數(shù)字化表達(dá)。什么算一個有效訂單訂單狀態(tài)為已完成且支付金額大于0就是一條業(yè)務(wù)語義規(guī)則它同時約束了狀態(tài)字段的取值范圍和金額字段的有效性。什么算一個正常的用戶注冊時間不為空、手機(jī)號為11位數(shù)字也是一條規(guī)則。所以數(shù)據(jù)清洗方法的設(shè)計(jì)第一步根本不是寫代碼而是把業(yè)務(wù)規(guī)則顯式化。你在清洗之前得能回答這些數(shù)據(jù)里哪些字段是主鍵哪些字段的取值范圍是什么哪些字段之間的邏輯關(guān)系必須成立。規(guī)則列不出來代碼寫得再漂亮都是在碰運(yùn)氣。2. ODS與DWD的分層清洗策略先收斂再深加工數(shù)倉領(lǐng)域有個成熟的分層習(xí)慣ODS操作數(shù)據(jù)存儲層、DWD明細(xì)數(shù)據(jù)層、DWS匯總數(shù)據(jù)層、ADS應(yīng)用數(shù)據(jù)層。清洗動作主要發(fā)生在ODS到DWD這一段但很多人會把ODS環(huán)節(jié)的收斂和DWD環(huán)節(jié)的清洗混在一起做最后導(dǎo)致規(guī)則散落、血緣混亂。我的經(jīng)驗(yàn)是ODS只做必做之事真正的清洗要釘在DWD層并且跟著維度建模的設(shè)計(jì)走。2.1 ODS層只做最小必要處理ODS層的定位是原始數(shù)據(jù)的鏡像。它存在的意義是保留數(shù)據(jù)的原始性讓上游來的數(shù)據(jù)在數(shù)倉里有一個忠實(shí)的落地點(diǎn)。在這個層面上我堅(jiān)持只做三種處理增量/全量落地按業(yè)務(wù)系統(tǒng)同步過來的頻率做分區(qū)落地。技術(shù)字段補(bǔ)充比如etl_time抽取時間、source_system來源系統(tǒng)、data_version數(shù)據(jù)版本這些字段服務(wù)于后續(xù)的追溯和重算不改變業(yè)務(wù)語義?；A(chǔ)編碼統(tǒng)一比如把不同來源的字符集統(tǒng)一成UTF-8把BOM頭去掉把不可見字符做trim處理。這些是技術(shù)層面的收斂不涉及業(yè)務(wù)判斷。一旦在ODS層做了業(yè)務(wù)規(guī)則的判斷比如過濾掉狀態(tài)為取消的訂單就出問題了。因?yàn)閷砼挪閿?shù)據(jù)問題時你很難說清楚ODS里的原始數(shù)據(jù)到底是上游就缺了還是被我們洗掉了。所以O(shè)DS的守則就一句話原樣接入只動技術(shù)不動業(yè)務(wù)。2.2 DWD層清洗規(guī)則要跟著維度和事實(shí)的設(shè)計(jì)走DWD層是數(shù)據(jù)清洗的主戰(zhàn)場。這一層要做的是把ODS里多個來源的數(shù)據(jù)按統(tǒng)一的業(yè)務(wù)定義組裝成明細(xì)事實(shí)表和維度表。清洗在這里不是孤立動作而是建模過程的一部分。舉例來說做訂單事實(shí)表時訂單狀態(tài)枚舉值必須統(tǒng)一。上游業(yè)務(wù)系統(tǒng)可能用0/1/2表示待支付/已支付/已取消另一個系統(tǒng)可能用P/PAID/CANCEL表示同一件事。DWD層必須把這些映射成統(tǒng)一的維度外鍵。做用戶維度表時性別、年齡、城市這些屬性的取值異常和缺失處理跟著SCD策略走緩慢變化維而不是簡單填個未知了事。做事實(shí)表的外鍵關(guān)聯(lián)時要處理孤兒數(shù)據(jù)——比如訂單表里關(guān)聯(lián)不到用戶表的user_id。這種問題用SQL的inner join是直接消失的但真實(shí)情況是這些訂單不能隨意丟棄得落進(jìn)專門的待確認(rèn)表里?？梢园盐页Ｓ玫腄WD層清洗動作按類別拆一下清洗類別典型動作數(shù)倉側(cè)的落地方式格式標(biāo)準(zhǔn)化日期統(tǒng)一成yyyy-MM-dd、金額統(tǒng)一成decimal(18,4)用CAST或regexp處理規(guī)則固化到ETL代碼里缺失值處理可推導(dǎo)的用業(yè)務(wù)邏輯推導(dǎo)不可推導(dǎo)的給業(yè)務(wù)默認(rèn)值或用未知維度替代用COALESCE或CASE WHEN值要可解釋重復(fù)數(shù)據(jù)剔除按業(yè)務(wù)主鍵去重保留最新或質(zhì)量最高的一條用ROW_NUMBER() OVER (PARTITION BY ...)邏輯矛盾修正比如支付時間早于下單時間這種矛盾記錄按規(guī)則重算或過濾并在明細(xì)表里打標(biāo)異常值鉗制超出物理上下限的數(shù)值如負(fù)的行駛里程區(qū)間判斷必要時置NULL并記錄2.3 數(shù)據(jù)質(zhì)量的六性檢查清單在DWD層設(shè)計(jì)清洗規(guī)則時我習(xí)慣用一個六維清單去自檢這六個維度分別是完整性、唯一性、準(zhǔn)確性、一致性、有效性、時效性。每次新的清洗邏輯加進(jìn)來就對著這六個詞過一遍缺哪個補(bǔ)哪個。完整性該有的字段有沒有。比如訂單表必須有下單時間和訂單號。唯一性主鍵不能重復(fù)重復(fù)了怎么處理、保留哪條。準(zhǔn)確性字段值和真實(shí)業(yè)務(wù)是否一致比如金額不能是負(fù)數(shù)。一致性同一個維度的編碼在不同表里必須統(tǒng)一。有效性字段值是否符合定義的取值范圍比如周幾只能是1到7。時效性數(shù)據(jù)是否在預(yù)期時間內(nèi)到達(dá)遲到的數(shù)據(jù)不能污染當(dāng)天的統(tǒng)計(jì)。這套清單不是給別人看的文檔而是你寫清洗代碼時的一個心智框架。比如你正在寫一段用戶地址清洗邏輯發(fā)現(xiàn)地址字段有的帶省市區(qū)有的只有一個市有的完全是空——這時候你如果不把六個維度過一遍很容易只想著填個空值而忘了校驗(yàn)非空地址里的省市區(qū)在行政區(qū)劃表里到底存不存在這個有效性問題。3. 三個實(shí)戰(zhàn)工具的正確用法Hive SQL、pandas、Spark DataFrame清洗方法有了工具層面的選型也得聊清楚。數(shù)倉里最常碰到的三個工具Hive SQL、pandas、Spark DataFrame它們各有擅長的戰(zhàn)場用錯了地方就會事倍功半。3.1 Hive SQL大規(guī)模批處理的基本盤數(shù)倉里的絕大多數(shù)清洗工作最后還是落到Hive SQL上。原因很簡單數(shù)據(jù)量大而且數(shù)倉本身就是以Hive表為核心組織的。用SQL做清洗等于直接在數(shù)據(jù)所在的位置干活不用搞什么導(dǎo)出導(dǎo)入。SQL清洗的典型打法就是嵌套子查詢先做字段解析和格式標(biāo)準(zhǔn)化再做去重和過濾最后落表。拿一個比較常見的場景舉例——清洗用戶手機(jī)號字段WITH cleaned AS ( SELECT user_id, -- 去掉手機(jī)號里的空格、橫線、括號只留數(shù)字 REGEXP_REPLACE(phone, [^0-9], ) AS phone_raw, LOWER(email) AS email_lower, COALESCE(gender, unknown) AS gender_filled FROM ods_user_info WHERE dt ${bizdate} ), valid_check AS ( SELECT user_id, phone_raw, -- 合法性校驗(yàn)只保留11位且以1開頭的號碼其余置NULL CASE WHEN phone_raw RLIKE ^1[0-9]{10}$ THEN phone_raw END AS phone_valid, email_lower, gender_filled FROM cleaned ) INSERT OVERWRITE TABLE dwd_user_info SELECT * FROM valid_check;這個模式好在哪每一步邏輯都體現(xiàn)在子查詢里后面的人看代碼能順著結(jié)構(gòu)反推你的清洗思路。同時Hive SQL里的REGEXP_REPLACE、RLIKE、ROW_NUMBER()、LATERAL VIEW這四板斧可以說覆蓋了80%的格式清洗和去重需求。剩下20%計(jì)算特別復(fù)雜的才需要交給下面的工具。3.2 pandas小規(guī)模探索和規(guī)則原型驗(yàn)證pandas在數(shù)倉體系里處于一個微妙的位置。它不適合處理億級數(shù)據(jù)但在清洗規(guī)則還不明確、你需要快速看數(shù)據(jù)畫像的階段pandas是效率最高的工具。我自己做數(shù)倉開發(fā)時遇到新的數(shù)據(jù)源永遠(yuǎn)是先拉一份抽樣數(shù)據(jù)到本地用pandas做探索性分析把清洗規(guī)則的原型先跑出來驗(yàn)證邏輯沒問題再翻譯成Hive SQL投到生產(chǎn)環(huán)境。這個過程能幫你省大量時間因?yàn)橹苯釉贖ive上反復(fù)調(diào)試一個查詢可能就要等幾分鐘本地用pandas幾秒鐘就出結(jié)果了。pandas最常用的五個清洗操作可以記一下import pandas as pd df pd.read_csv(sample_data.csv, encodingutf-8) # 1. 去掉重復(fù)行保留第一次出現(xiàn)的一條 df df.drop_duplicates(subset[order_id], keepfirst) # 2. 缺失值處理按業(yè)務(wù)規(guī)則填充 df[pay_time] df[pay_time].fillna(1970-01-01 00:00:00) # 3. 異常值替換把不在合法區(qū)間內(nèi)的值替換掉 df.loc[df[mileage] 0, mileage] None # 4. 數(shù)據(jù)類型收斂統(tǒng)一日期格式 df[order_date] pd.to_datetime(df[create_time]).dt.date # 5. 自定義規(guī)則函數(shù)映射 df[order_status_std] df[order_status].map({0: pending, 1: paid, 2: cancelled})這個階段的核心產(chǎn)出不是清洗后的數(shù)據(jù)而是一套已驗(yàn)證過的清洗邏輯文檔。很多人跳過這一步直接上SQL結(jié)果規(guī)則在數(shù)據(jù)量大了之后才發(fā)現(xiàn)有問題返工成本特別高。3.3 Spark DataFrame中大規(guī)模復(fù)雜清洗的折中方案當(dāng)數(shù)據(jù)量在千萬到億級別而且清洗邏輯涉及復(fù)雜計(jì)算、多階段狀態(tài)處理時純SQL寫起來會很別扭本地pandas又跑不動這時Spark DataFrame是一個很好的折中。典型場景比如用Geohash做軌跡數(shù)據(jù)清洗、基于用戶行為序列做狀態(tài)推演、多張表關(guān)聯(lián)后做復(fù)雜的窗口計(jì)算。這幾個場景在Spark里寫起來更接近編程思維比堆一大坨SQL直觀得多。from pyspark.sql import functions as F from pyspark.sql.window import Window # 按訂單分組按打點(diǎn)時間排序用于亂序軌跡修正 w Window.partitionBy(order_id).orderBy(F.col(point_time).asc()) df_cleaned df_raw.withColumn( is_duplicate, F.row_number().over(w) ).filter( F.col(is_duplicate) 1 ).withColumn( speed_kmh, F.lit(120) ).filter( F.col(distance_km) / F.greatest(F.col(interval_hour), F.lit(0.001)) F.col(speed_kmh) )Spark的調(diào)試成本比pandas高所以我的原則是先pandas出原型再Spark上生產(chǎn)。兩個工具使用同一套規(guī)則定義能最大程度減少翻譯過程中引入的偏差。工具選型小結(jié)用一張表說人話工具數(shù)據(jù)量級最佳使用場景主要劣勢Hive SQL億級以上離線批處理、標(biāo)準(zhǔn)化清洗、去重過濾復(fù)雜計(jì)算寫起來費(fèi)勁調(diào)試慢pandas百萬級以下探索性分析、規(guī)則原型驗(yàn)證、一次性修正內(nèi)存瓶頸不適合生產(chǎn)大規(guī)模任務(wù)Spark DataFrame千萬到十億級復(fù)雜清洗邏輯、軌跡/行為序列處理集群資源開銷大原型階段成本高4. 一次網(wǎng)約車訂單清洗實(shí)戰(zhàn)從臟數(shù)據(jù)發(fā)現(xiàn)到規(guī)則落地的完整鏈路理論講再多不如跑一遍真實(shí)案例。這里用我之前做過的網(wǎng)約車訂單數(shù)據(jù)清洗項(xiàng)目來走一遍完整鏈路。這個項(xiàng)目的數(shù)據(jù)源包括訂單表、司機(jī)軌跡表、計(jì)價(jià)表三張ODS表接進(jìn)來以后問題非常多。4.1 臟數(shù)據(jù)初檢先看數(shù)據(jù)畫像拿到數(shù)據(jù)第一天我不會立刻寫清洗規(guī)則而是先做數(shù)據(jù)畫像。所謂畫像就是看每一列的空值率、去重率、枚舉值分布、最大最小值、數(shù)值范圍。這一步用pandas跑特別快。當(dāng)時發(fā)現(xiàn)的核心問題有這么幾類訂單表的finish_time字段缺失率高達(dá)23%。這不可能是正常的反手去查上游原來是司機(jī)端APP在部分場景下沒有回傳完成時間。軌跡表里有大量打點(diǎn)時間早于訂單創(chuàng)建時間的記錄。也就是說軌跡的時間戳亂序了。存在同一訂單號出現(xiàn)兩次的情況而且兩次的金額還不一樣。有個別訂單的行駛里程是負(fù)數(shù)。這些單看一條都會覺得這數(shù)據(jù)怎么回事但放在一起說明清洗規(guī)則不能只做一個填缺失值得設(shè)計(jì)一整套基于業(yè)務(wù)約束的校驗(yàn)邏輯。4.2 異常軌跡點(diǎn)排查用物理規(guī)則過濾軌跡數(shù)據(jù)的清洗是網(wǎng)約車場景里最有代表性的。它的臟數(shù)據(jù)主要來自GPS漂移——某個打點(diǎn)位置突然跳到幾十公里外的另一個城市或者速度計(jì)算出來遠(yuǎn)超物理上限。處理邏輯是這樣的軌跡點(diǎn)按時間排序后計(jì)算相鄰打點(diǎn)之間的距離和時間差然后算出平均速度。如果速度超過一個物理上限比如120km/h這個點(diǎn)就很可能是漂移點(diǎn)需要剔除。這個邏輯在Hive里可以用lag窗口函數(shù)實(shí)現(xiàn)WITH trajectory_sorted AS ( SELECT order_id, lng, lat, point_time, LAG(point_time) OVER (PARTITION BY order_id ORDER BY point_time) AS prev_time, LAG(lng) OVER (PARTITION BY order_id ORDER BY point_time) AS prev_lng, LAG(lat) OVER (PARTITION BY order_id ORDER BY point_time) AS prev_lat FROM ods_trajectory ) SELECT order_id, lng, lat, point_time FROM trajectory_sorted WHERE prev_time IS NULL OR ST_DISTANCE( ST_POINT(prev_lng, prev_lat), ST_POINT(lng, lat) ) / (UNIX_TIMESTAMP(point_time) - UNIX_TIMESTAMP(prev_time)) 120這里有個細(xì)節(jié)值得說剔除漂移點(diǎn)的時候不能只算這個點(diǎn)本身合不合理要看它和前后點(diǎn)的關(guān)系。一個點(diǎn)本身在正常城市范圍內(nèi)但和上一個點(diǎn)之間隔了300公里這就是明顯的漂移。物理速度約束比單純的范圍約束更有效。4.3 時間亂序與重復(fù)訂單的處理思路時間戳亂序在物聯(lián)網(wǎng)和APP上報(bào)場景里經(jīng)常出現(xiàn)。網(wǎng)約車軌跡表的打點(diǎn)時間理論上必須大于等于訂單創(chuàng)建時間、小于等于訂單完成時間但實(shí)際數(shù)據(jù)里會出現(xiàn)亂序、重復(fù)打點(diǎn)、時間超前等情況。我的處理方式是分層解決完全亂序的記錄按order_id分組用row_number按point_time重新排序亂序但不丟失修正為正確順序。重復(fù)打點(diǎn)同一秒內(nèi)重復(fù)上報(bào)的軌跡點(diǎn)保留第一個其余剔除。時間超前point_time早于訂單創(chuàng)建時間這類記錄要么是設(shè)備時鐘問題要么是緩存上報(bào)問題直接剔除。訂單表的重復(fù)問題更有意思。當(dāng)時發(fā)現(xiàn)的重復(fù)訂單號第一次出現(xiàn)的金額是80元第二次是85元。這說明上游系統(tǒng)對同一訂單做了多次修改并生成了新的快照記錄而不是真正的一單兩用。去重策略就不是簡單保留任意一條而是要根據(jù)業(yè)務(wù)規(guī)則保留最后修改時間最晚的那條同時把兩條金額存進(jìn)一個數(shù)組字段方便后續(xù)排查。WITH deduped AS ( SELECT order_id, order_amount, create_time, ROW_NUMBER() OVER ( PARTITION BY order_id ORDER BY update_time DESC ) AS rn FROM ods_order ) SELECT * FROM deduped WHERE rn 1;這類去重最大的坑在于如果上游系統(tǒng)的更新邏輯本身有bug光靠數(shù)倉去重是堵不住的。所以跑完清洗之后一定要回傳一個數(shù)據(jù)質(zhì)量異常報(bào)告給業(yè)務(wù)系統(tǒng)讓他們知道這里有重復(fù)產(chǎn)生的問題。4.4 清洗規(guī)則發(fā)布與驗(yàn)證規(guī)則寫完之后不能直接替換線上表。我習(xí)慣的發(fā)布流程是先做并行試跑把清洗后的數(shù)據(jù)落到一張新表dwd_order_clean_test和線上正在用的舊表做一次全量對比主鍵是否完全一致、關(guān)鍵指標(biāo)的差異量級是否在可接受范圍內(nèi)差異超過閾值比如訂單總額偏差超過5%就必須回頭查規(guī)則不能強(qiáng)行切換這一步非常關(guān)鍵。清洗規(guī)則本身有主觀判斷的成分這個字段置NULL還是填默認(rèn)值直接影響下游指標(biāo)。如果規(guī)則設(shè)計(jì)錯了發(fā)布后報(bào)表異常半天時間就搭進(jìn)去了。那次項(xiàng)目的最終結(jié)果是訂單表的有效數(shù)據(jù)率從82%提升到了97%軌跡點(diǎn)漂移率從3.7%降到0.4%以下用戶次日留存指標(biāo)修正了將近1.2個百分點(diǎn)——這個修正幅度說明之前的臟數(shù)據(jù)確實(shí)嚴(yán)重影響了業(yè)務(wù)判斷。5. 清洗后的質(zhì)量監(jiān)控規(guī)則老化、血緣追溯與回歸保障清洗規(guī)則上線不等于一勞永逸。數(shù)據(jù)是動態(tài)的上游系統(tǒng)一改接口、產(chǎn)品一改邏輯你精心設(shè)計(jì)的清洗規(guī)則就可能失效。所以最后一塊內(nèi)容聊清洗后的質(zhì)量監(jiān)控問題。5.1 監(jiān)控規(guī)則本身而不是監(jiān)控結(jié)果很多團(tuán)隊(duì)做數(shù)倉質(zhì)量監(jiān)控光盯著今天的訂單量是否波動超過10%這種做法太滯后。我習(xí)慣在DWD層直接埋規(guī)則校驗(yàn)點(diǎn)比如訂單表里status字段不在枚舉值范圍內(nèi)的記錄數(shù)必須為0手機(jī)號非法率不能超過0.1%訂單金額為負(fù)的記錄數(shù)必須為0當(dāng)日新增訂單的支付時間不能晚于次日0點(diǎn)這些校驗(yàn)點(diǎn)本質(zhì)上就是你清洗規(guī)則的鏡像。規(guī)則說金額必須大于0那監(jiān)控就查金額小于等于0的記錄數(shù)。如果這個校驗(yàn)點(diǎn)爆了說明上游出了問題或者規(guī)則需要調(diào)整。5.2 血緣倒查規(guī)則變更影響面有多廣數(shù)倉的血緣追溯在數(shù)據(jù)清洗這個語境下特別重要。當(dāng)你準(zhǔn)備改一條清洗規(guī)則時比如手機(jī)號非法時從置NULL改為填默認(rèn)值00000000000你必須立刻知道下游哪些表、哪些指標(biāo)會受影響。如果血緣關(guān)系不清晰你改了一條規(guī)則第二天一堆報(bào)表出問題都不知道該找誰。所以在設(shè)計(jì)數(shù)倉時每個清洗任務(wù)我都要求必須有輸入表、輸出表、規(guī)則版本號三個元數(shù)據(jù)字段。出問題的時候先查規(guī)則版本最近有沒有變過再倒查引用這張表的任務(wù)有哪些。這個習(xí)慣救過我很多次。5.3 定期回歸清洗邏輯也要做自動化回歸最后是回歸保障。建議每隔一段時間我是按季度拉一批歷史數(shù)據(jù)用當(dāng)前版本的清洗規(guī)則重新跑一遍和上一版本的結(jié)果做對比。重點(diǎn)看兩件事有沒有規(guī)則改動導(dǎo)致歷史數(shù)據(jù)結(jié)果漂移有沒有上游數(shù)據(jù)格式悄悄變化導(dǎo)致清洗命中率下降回歸通過之后清洗規(guī)則才算真正穩(wěn)定可靠。這個過程就像給數(shù)據(jù)質(zhì)量上了個保險(xiǎn)平時不起眼出了問題才知道它的價(jià)值。做數(shù)據(jù)清洗這些年我最大的體會就是別把清洗當(dāng)成一個可以一步到位的動作它和建模、監(jiān)控、血緣、元數(shù)據(jù)管理是糾纏在一起的。如果你只是按臨時需求東改一條西補(bǔ)一條那數(shù)據(jù)質(zhì)量永遠(yuǎn)在救火只有當(dāng)清洗規(guī)則變成數(shù)倉建設(shè)的一等公民數(shù)據(jù)倉庫才能真正成為值得信賴的分析底座。希望這篇文章能把你在數(shù)據(jù)清洗這件事上的思路捋順少踩幾個我踩過的坑。