介紹
資料為 Uber 幾乎所有面向客戶的關鍵流程提供支援。糟糕的資料品質會影響我們的 ML 模型，導緻糟糕的使用者體驗（錯誤的票價、ETA、産品等）和收入損失。
盡管如此，許多資料問題是在問題開始幾周甚至幾個月後由使用者手動檢測到的。資料回歸很難捕捉到，因為最具影響力的回歸通常是沉默的。它們不會以明顯的方式影響名額和 ML 模型，直到有人注意到出現問題，最終發現資料問題。但到那時，錯誤的決定已經做出，機器學習模型已經表現不佳。
這使得徹底監控資料品質變得至關重要，以便主動發現問題。
資料問題示例
讓我們舉個例子來了解資料事件的影響。
事件
優步票價由不同的組成部分組成，例如漲價、通行費等。乘客對這些不同組成部分的反應和行程轉化率對于建構票價 ML 模型至關重要。我們遇到過一個事件，即美國主要城市 10% 的會話的關鍵票價資料集中缺少票價部分“X”。
根本原因
根本原因是應用程式實驗開始以不同方式記錄票價。
它是如何被發現的？
一位資料科學家在 45 天後手動檢測到此事件。
影響
- 此資料集用于訓練關鍵票價 ML 模型。票價成分是用于訓練該模型的重要特征。為了量化此類資料事件的影響，Fares 資料科學團隊建構了一個模拟架構，該架構可以從實際生産事件中複制損壞的資料，并評估對票價資料模型性能的影響。30% 的會話中損壞的票價部分嚴重影響模型性能，導緻增量總預訂量下降 0.23%。在美國主要城市 10% 的會話中，票價組成資料損壞的事件持續 45 天，将轉化為數百萬美元的收入損失。
- 具有特定票價組成部分的會話百分比是上司層和全球營運人員用來做出重要決策和了解市場健康狀況的關鍵名額。
- 此外，當發生資料事件時，跨資料科學、資料工程和産品工程的多個團隊在試圖确定資料事件的根本原因時會失去生産力。
資料事件類别
深入研究這些事件以制定更快地發現這些問題的政策非常重要。我們分析了 2022 年 Uber 的資料事件，并将它們分為不同的類别。我們過濾掉了與資料集中的資料品質無關的事件（例如，通路控制和查詢層問題）。
我們進一步将剩餘的事件分為導緻部分資料丢失的事件和導緻完整資料丢失的事件。後者通常是由 ETL 管道故障或基礎設施故障（例如，Spark、Yarn、Hive 中斷）引起的；這些問題更容易檢測和緩解。但是導緻部分/不完整資料的事件通常是無聲的，并且更難被發現。
圖 1：按類别劃分的資料事件分布
監控和檢測部分資料事件的難度展現在這些事件的平均 TTD（檢測時間）比ETL/基礎設施故障引起的資料事件多 5 倍。
我們設計的架構的目标是将部分資料事件的 TTD 降低到與基礎設施/ETL 中斷相同的水準。
檢測政策
資料不完整的原因很多，并且遍布整個堆棧：
新功能和實驗
新功能可能會改變日志，使後端資料集不準确（例如，由于架構更改，可能會省略某個字段，或者可能會更改某個字段的含義）。
ETL 邏輯變化
上遊 ETL 更改可能會破壞資料，進而在資料集中引入不準确性（例如，連接配接實作中的錯誤更改，是以資料可能開始丢失）。
上遊中斷和遷移
由于錯誤或大規模遷移，上遊服務可能會停止記錄記錄。
第三方資料源品質問題
通常，資料集會從品質不受我們控制的第三方資料源擷取日志。這些第三方資料源可能會産生資料不一緻的情況。
我們研究了各種方法來監控和檢測這些問題。以下是按該方法可能捕獲的事件數量分布的監控方法：
圖 2：檢測資料漂移的測試類型
我們發現，檢查列值漂移的列級測試套件可能已經檢測到許多（将近 50%）事件。
什麼是螢幕？
監控器是本部落格中經常使用的一個術語，表示基于某種聚合類型計算的統計值，用于識别列值的漂移。
螢幕示例
- 空百分比
- 錯誤百分比
- 百分位數（P50、P75、P99、P1）
- 标準差、平均值、中位數
- 不同計數
我們需要什麼顯示器？
根據我們管理關鍵資料集和處理資料事件的經驗，我們發現以下螢幕很有用：
空檢查
檢查具有空列值的行百分比的漂移。
外鍵 (FK) 測試（跨資料集列比較）
外鍵測試檢查資料集之間實體計數的一緻性（例如，将表 X 中的行程與行程的真實來源 (SOT) 表進行比較）。
使用百分位數檢查檢查數字列中的漂移
數字列值的劇烈變化表明該列的含義已經改變。
分類列中的分布
檢查枚舉列值分布的漂移，例如，值 X、Y 和 Z 均勻出現的列具有不成比例的高 X 計數。
其他需求
次元監控
資料問題通常始于城市或新釋出的應用程式版本。按次元監控可以更快地發現這些問題。
為什麼手動應用列級螢幕無法擴充
- 它需要數千人-周的努力
- 手動設定的靜态門檻值不适合我們在 Uber 擁有的動态和趨勢資料
- 跨資料集的不同測試無法擴充 PB 級資料
- 很難跟上架構更新（新列）
- 為數百個城市設定基于次元的監控器是不可行的
介紹 D3（資料集漂移檢測器）
從以上部分可以清楚地看出，我們需要一個強大的自動化系統來衡量和監控列級資料品質。D3 或資料集漂移檢測器就是為了這個目标而建構的。
D3 特點
自動入職。該架構根據離線使用情況确定資料集中的重要列，并對這些列應用螢幕。從資料集所有者到闆載它幾乎不需要配置。
跨次元的自動化監控。該架構自行按次元（如應用程式版本和 city_id）進行監控。這有助于更快地檢測資料問題。這也可以更準确地了解資料品質，因為即使整體資料品質沒有太大變化，嚴重影響少數城市的資料問題仍會影響資料消費者。
自動異常檢測。無需手動設定門檻值。
建築學
下圖表示 D3 架構中的進階元件視圖：
圖 3：D3 總體高層架構
Uber Data Platform 管理的架構中有一些核心系統與我們相關。我們偶爾會在本部落格中提及這些系統：
- Databook：這是 Uber 内部的一個内部門戶，用于探索資料集、它們的列、沿襲、資料品質測試、名額、SLA、資料一緻性、重複項等。
- UDQ： UDQ 代表統一資料品質。它是 Uber 的一個集中式系統，負責如何定義、執行和維護資料集的資料品質測試以及這些測試的大規模警報機制。資料集所有者可以通過 Databook 建立 UDQ 測試。
- Michelangelo：這是一個部署 ML 模型的平台，用于跨 Uber 内部資料集進行實時預測。
D3 架構由 3 個主要元件組成，我們将詳細介紹：
- 計算層
- 異常檢測
- 協調器
計算層
圖 4：計算層進階架構
計算層構成了 D3 架構的關鍵。任何載入的 D3 資料集生命周期都将有兩種類型的作業作為計算層的一部分執行：
- 一項一次性資料探查器作業，用于計算過去 90 天資料集的曆史列螢幕統計資訊。這形成了異常檢測模型的訓練資料。
- 計算最近一天的列螢幕統計資訊并使用異常檢測算法預測統計門檻值并識别當天的列漂移的每日計劃作業。
這些計算作業是針對每個資料集執行的通用Spark作業。螢幕是表示為 Jinja 模闆的 SQL 語句。D3 資料集配置用于将模闆轉換為在 Spark 應用程式中執行的真實 SQL 查詢。來自資料分析器和每日計劃作業的計算統計資料持久儲存在 Hive D3 統計資料表中。在此表之上設定警報和監視。
可插拔螢幕
每個資料集的 D3 配置都包含需要成為監控一部分的列清單以及要配置這些列的螢幕類型。螢幕類型的一些示例是 Null 百分比、錯誤百分比、零百分比、百分位數檢查（第 25 個百分位數、第 50 個百分位數和第 75 個百分位數值）、平均值、标準偏差等。
D3 架構和計算層中新增的螢幕是使用 jinja 模闆的可插入元件。一旦新的螢幕被添加到架構中，任何資料集都可以配置自己的一組 D3 支援的列螢幕螢幕類型。
動态過濾器
還有一個配置選項，用于為每個列螢幕提供動态過濾。過濾器可以是在 where 子句語句中應用的任何有效的配置單元 SQL 表達式。
方面
具有基于次元的統計計算是架構中的另一個關鍵要求。每當釋出新版本的應用程式或在特定城市釋出時出現錯誤時，我們經常會在所有上遊資料中發現問題。在這種情況下，資料集列在整體水準上不會有任何漂移，但我們可以看到針對這些次元削減（例如城市級别或應用程式版本和裝置作業系統級别）的計算統計資料出現顯着峰值。
但是在架構中提供基于次元的統計計算支援存在一些挑戰：
- 首先是次元具有高基數時出現的可擴充性挑戰，進而導緻計算的高資源消耗。
- 其次，由于可用于了解趨勢的抽樣資料較少，導緻誤報率較高的風險。
目前，我們支援一些固定的次元集。一個是針對 city_id 的單一次元支援，另一個是針對應用程式版本和裝置作業系統的二維支援，因為這些次元用例在識别資料漂移方面很常見。但我們計劃在未來的版本中支援任何臨時次元，并在架構中支援多達 5 個次元的列組合。
異常檢測
截至目前，Uber 的資料可觀察性是基于手動策劃的基于 SQL 的測試和靜态警報門檻值。這需要持續關注和重新校準以适應不斷變化的資料趨勢。有了異常檢測，我們可以有更靈活和動态的警報。對于 D3 用例，我們正在調整模型以獲得高精度，以減少誤報。
異常檢測內建
将任何異常檢測模型內建到 D3 架構中都是即插即用的。它基于通用 UDF 接口，任何模型都可以定義自己的實作。在配置時，使用者可以選擇他們選擇的異常檢測，而不必擔心幕後發生的事情。
對于任何異常檢測模型，輸入是時間序列資料，預期輸出是監控值應落入的預測限值。基準限值有時會更激進，并會産生許多誤報。由于我們想要一個高精度模型，通常我們會在基本警報限制之上定義保守的警報限制。這些警報限制是基本限制的函數并且動态變化。
圖 5：即插即用異常檢測
預言家
我們已将 Prophet 內建為 D3 的預設異常檢測。Prophet 是一種非線性回歸模型，比移動平均線等直覺技術有了一步改進。它是完全自動化的，可以很好地适應不斷變化的趨勢和季節性。與其他一些異常檢測模型相比，即使訓練資料較少，它也能很好地工作。
處理異常值（回報）
真實資料通常包含離群的觀察結果。與他們打交道有時會很麻煩，而且會搞亂預測。離群值是與時間序列中的大多數觀察值非常不同的觀察值。如果出現任何故障或錯誤，它們可能是錯誤或問題。為了盡量減少這些觀察傳播到預測中的長期影響，回報機制已經到位。在這裡，使用者可以啟用選項來手動将異常值标記為真或假。這些輸入被饋送到異常檢測模型，其中與真實警報相對應的資料點從未來預測的考慮中删除。
處理噪音（診斷）
我們已經看到許多自然嘈雜（下降和尖峰）并導緻大量警報的時間序列。為了解決這個問題，我們有一個明确的診斷工作，可以幫助識别和過濾預測錯誤百分比很高的嘈雜時間序列。與這些時間序列對應的螢幕已禁用警報。
協調器
Orchestrator 是一個服務元件，通過它對外暴露 D3 的能力。它充當優步資料平台和 D3 之間的中介。
圖 6：Orchestrator 架構
協調者的角色
資源管理
編排器管理兩個重要資源：
中繼資料：每個資料集都有一些中繼資料：次元、聚合器、支援的螢幕類型、排除的列、資料集分區相關資訊等。中繼資料決定了可以在資料集上定義哪些螢幕。它還有助于一鍵自動加載資料集。
Monitor：編排器公開 gRPC 端點以擷取和更新給定資料集的螢幕級資訊。
生命周期管理
協調器：
- 管理 D3 螢幕生命周期——分析資料、統計計算、異常檢測、Uber 資料平台元件的狀态更新
- 使 D3 與資料集模式更改保持同步
- 支援計劃的和臨時的基于觸發器的統計計算
- 設施螢幕更新：如果有一些中繼資料變化（例如，次元或聚合器變化）或螢幕級别屬性更新（例如，門檻值或螢幕類型更新等），則必須更新相應的螢幕，并且應該更新統計資訊。
協調器內建
由于 D3 的目标是盡可能快地大規模發現資料品質問題，是以利用 D3 的一種有效方法是通過 Databook UI 建立支援 D3 的測試。為此，編排器已與 Uber 資料平台內建。
通用資料平台合同
Uber 資料平台（更具體地說，UDQ）有一個通用的 API 合同，任何系統都可以使用它來內建、建立和維護資料品質測試及其生命周期。編排器實作這些功能以滿足資料消費者的需求：
- 建議測試：推薦顯示器到闆載
- 增删改查 API
- 回填測試：重新計算過去幾天的統計資料
挑戰
規模
簡單描述一下擴充複雜度，Uber 有超過 1000+ 層級資料集，平均每個資料集有 50+ 列。考慮到至少有兩種監控器類型（例如 Null Percentage 和 P75）被添加到監控列中，并且如果資料集至少有 1 個次元和 1 個聚合器，這可以很容易地轉化為每個資料集 100 多個監控器和 100k 多個監控器用于 Uber-wide資料集。
圖 7：D3 的目前規模
這導緻需要解決以下一些複雜性：
- 資料探查器和日常計劃作業的高資源使用率
- 資料集的入職螢幕中繁瑣的手動過程
- 資料分析作業觸發不同場景的重複資料删除，例如在回填、模式演變和臨時觸發器期間
計算層優化
圖 8：查詢優化
鑒于計算作業是針對 Uber 中的任何資料集應用的通用 Spark 作業，并且具有上述規模，這可能導緻每個資料集至少有 100 多個螢幕，每個 Spark 作業有 100 多個查詢。這轉化為對 Uber 範圍内資料集的數百萬次查詢。資料探查器和每日計劃的 Spark 作業都經過優化和微調，以根據投影、分組和過濾表達式的類型将這些多個 SQL 查詢組合成一組固定的邏輯模闆，進而最大限度地減少混洗和資料傳輸（示例示例顯示在上圖中）。這種優化導緻每個資料集的查詢數量從200 多個減少到 8 個查詢，進而減少了顯着的混洗和資料解析，進而使資源消耗提高了 100 倍. 每個資料集的平均計算成本從1.5 美元減少到 0.01 美元。
此計算層的另一個主要瓶頸是資料分析器作業或大容量資料集的曆史資料計算。我們需要調整資料探查器作業以支援每天資料量 >1TB 的資料集，用于 90 天以上的曆史計算。對于此類資料集，作業以較小的塊并行執行，以減少每個階段傳輸的混洗量。連同其他一些 Spark 參數調整，我們可以支援任何具有最佳資源使用率的大容量資料集資料分析器作業。
自動化入職
當我們開始加載資料集時，我們注意到為每個資料集加載 100 多個螢幕是一個乏味的過程。這需要大量手動使用者輸入，例如聯系所有者以找出應實施哪些螢幕。這需要幾天時間。我們希望 D3 以最少的使用者幹預支援單擊入職。
我們目前支援所有按日期以 YYYY-MM-DD 格式分區并至少每天更新的資料集。我們通過以下方式開始入職：
- 根據使用情況擷取前 X% 的重要列
- 根據列資料類型配置螢幕
- 為資料集配置預設螢幕類型和次元映射
- 通過在 T – X 分區上運作 D3 來處理由于資料延遲到達而導緻的資料/分區延遲
通過這種方法，我們将入職時間從幾天縮短到幾秒鐘，并使其成為完全自動化的單擊操作。
處理統計重新計算
多個場景會導緻統計資料重新計算。這可能是由于添加了新的螢幕或更新了現有的螢幕或自定義重新運作，或者使用者請求的事件回填以擷取真正的肯定警報。使用者需要進行源回填并請求重新計算統計資料和門檻值。
這裡的主要挑戰之一是多個重新計算請求可能導緻多個作業重複處理相同的資料。這可能是非常低效的，因為螢幕的數量可能會非常多。為了解決這個問題，我們設計了一個基于批處理的解決方案，該解決方案異步處理重新計算請求（觸發器）。
圖 9：進階觸發器處理程式
定期的 Piper 任務計劃每兩小時命中一次 Orchestrator 觸發器處理程式端點并異步處理觸發器。觸發器處理程式在内部擷取所有待處理的請求并将它們一起批處理為每個資料集的單個觸發器請求。如果尚未為資料集運作，它會進一步啟動統計計算管道。
資料品質警報和監控
從資料分析器和每日計劃作業生成的計算統計值和動态門檻值持久儲存在基于 Hive 的統計表中。統計表用于驗證資料品質并用于标記資料集的完整性正常運作時間。與任何其他優步服務一樣，警報與資料簿監控服務和尋呼機值班內建在一起。隻要持久化統計表中發生門檻值違規，就會觸發警報。統計表還用于配置 tableau 儀表闆以實作可視化，它與資料手冊內建在一起。
警報視圖
圖 10：資料消費者 UI 上的警報
儀表闆視圖
資料集螢幕中的樣本時間序列趨勢
圖 11：可視化資料漂移的儀表闆
資料集中的示例警報趨勢
圖 12：給定資料集随時間變化的警報趨勢
到目前為止我們的進展
開頭提到的票價資料事件是在 45 天後手動檢測到的。在 D3 架構釋出後，我們已經監測了300 多個 Tier 1 資料集。TTD 大幅減少了 20 倍以上，平均為 2 天。我們在事實表上以高精度 ( 95.23% ) 檢測到超過 6 個關于市場/票價資料集的生産問題。我們所看到的那種事件——
- 由于上遊更改或錯誤釋出，關鍵列為空
- 由于源資料損壞，關鍵列為空
- 數字列中的意外值激增
- 缺少資料的大量查詢資料集（每周約 13K 次查詢）
這些列用于導出關鍵名額、分析乘客行為以及計算乘客在應用程式上看到的票價。根據部落格開頭描述的模拟，及早發現這些資料問題為我們節省了數千萬美元的增量收入。
圖 13：在市場資料集上釋出 D3 之前和之後檢測事件所花費的時間
下一步是什麼
出于對更好資料品質的需求，我們建構了 D3 架構作為監控和測量列級資料品質的一站式解決方案。增強此架構并将其應用于新場景的空間很大。
機器學習模型品質
用于訓練機器學習模型的特征必須是高品質的。檢測值漂移的不良特征并将其過濾掉非常重要。此外，用于訓練 ML 模型的資料不得與提供服務時使用的線上資料有很大不同。通過監控資料漂移來維護高品質的 ML 模型正迅速成為籌碼。我們計劃将這些用例加入到 D3 架構中。
自定義次元
如前所述，基于次元的監控是加快檢測速度的關鍵。我們計劃在 D3 名額上支援自定義的、特定于資料集的次元。
支援未分區或不同分區的資料集
D3 僅支援日期分區資料集。這是因為我們可以很容易地從這些資料集中提取時間序列進行監控。但是有許多關鍵資料集，例如未分區的次元表。我們計劃在未來将此類資料集加入 D3 架構。
新的異常檢測算法
如上所述，D3 目前僅支援 Prophet 的異常檢測庫，但在未來，我們可以內建新的異常檢測庫，如 ARIMA 和内部建構的其他庫。
新的螢幕和分析方法
我們将逐漸添加新的螢幕，使 D3 架構更有效地檢測異常。我們還将采用新的方法來分析資料（如資料草圖）而不是原始螢幕。資料消費者可以合并多個資料草圖來回答比原始名額更廣泛的問題。
作者:
安沙爾舒克拉
Anshal Shukla 是資料智能團隊的一名進階工程師。他專注于提高資料可靠性并簡化 Uber 資料使用和生産的系統。
Vineeth Tatipathri
Vineeth Tatipathri 是資料智能團隊的一名工程師。他是最早從頭開始開發 D3 的開發人員之一，将其發展到一定規模并産生了 Uber 廣泛的影響。
Nipun大桶
Nipun Vats 是 Uber 資料智能團隊的一名工程師。他是 Dataset Drift Detector 架構的主要貢獻者。他目前正緻力于增強和擴充該架構以節省數百萬美元。
迪内什·賈甘納森
Dinesh Jagannathan 是資料智能團隊的進階軟體工程師。他專注于建構資料架構和系統，以提高資料品質、标準化最佳實踐并提高開發人員的工作效率。
庫西克·納特
Kousik Nath 是資料智能團隊的進階工程師。他是 D3 架構的貢獻者之一。除了 D3，他還為票價相關系統做出貢獻。
出處:https://www.uber.com/en-US/blog/d3-an-automated-system-to-detect-data-drifts/