揭秘 Uber 跨區域數據湖與災難恢復機制：350PB 數據、數百萬事件、單一系統

作者 | Leela Kumili

譯者 | 平川

Uber 構建了 HiveSync，這是一個分片式批量復制系統，能夠使 Hive 和 HDFS 數據在多個區域之間保持同步，它每天處理數百萬個 Hive 事件。HiveSync 確保了跨區域數據的一致性，實現了 Uber 的災難恢復策略，并消除了由次要區域閑置而導致的低效問題——此前次要區域需承擔與主區域一樣的硬件成本，而 HiveSync 在維持高可用性的同時徹底解決了這一問題

HiveSync 基于開源項目 Airbnb ReAir 構建并做了一些擴展，包括實現了分片、基于 DAG 的編排以及控制平面和數據平面的分離。ETL 作業現在只在主數據中心執行，而 HiveSync 處理跨區域復制，實現了近乎實時的一致性，保持了災難應對能力和分析訪問權限。分片功能允許將表和分區劃分為獨立的單元，從而實現并行復制和細粒度容錯。

HiveSync 將控制平面（負責編排作業和管理關系元數據存儲中的狀態）與數據平面（執行 HDFS 和 Hive 文件操作）分離。Hive Metastore 事件監聽器負責捕獲 DDL 和 DML 變更，將它們記錄到 MySQL 中，并觸發復制工作流。任務以有限狀態機的形式呈現，支持任務重啟與健壯的故障恢復機制。

HiveSync 架構：控制平面和數據平面分離（來源：Uber 博文）

HiveSync 有兩個主要組件：HiveSync 復制服務和數據修復服務。復制服務使用 Hive Metastore 事件監聽器實時捕獲表和分區變更，將它們異步記錄到 MySQL 中。這些審計條目被轉換為異步復制作業，以有限狀態機的形式執行，為確保可靠性，狀態會被持久化。Uber 使用了混合策略：規模比較小的作業使用 RPC 以提高效率，而規模比較大的作業則利用 YARN 上的 DistCp。DAG 管理器強制執行分片級的排序和鎖定，而靜態和動態分片技術則實現了水平擴展，確保復制過程一致且無沖突。

HiveSync 復制服務（來源：Uber 博文）

數據修復是一個持續檢測異常的服務，如缺失的分區或非預期的 HDFS 更新，恢復數據中心 1（DC1）和數據中心 2（DC2）之間的一致性，從而保證數據的正確性。HiveSync 保證了每四小時一次的復制 SLA，99百分位 的延遲大約為 20 分鐘，并支持一次性復制，用于在切換到增量復制之前，一次性地將歷史數據集導入新區域或集群。Uber 的數據修復服務會掃描 DC1 和 DC2，檢測異常（如缺失或多余的分區），并修復任何不匹配的情況，從而確保跨區域的一致性，目標是準確性超過 99.99%。

數據修復服務分析和解決數據中心之間的不一致性（來源：Uber 博文）

HiveSync 的規模很大，管理著 80 萬個 Hive 表，總計約 300PB 的數據，單表數據量從幾 GB 到數十 PB 不等，單表分區數從幾百到一百萬多不等。每天，HiveSync 處理超過 500 萬個 Hive DDL 和 DML 事件，跨區域復制約 8PB 的數據。

展望未來，隨著批量分析和 ML 管道遷移到谷歌云平臺，Uber 計劃將 HiveSync 擴展到云端復制場景，進一步利用 分片)、編排和數據一致性技術來高效地維護其 PB 級數據的完整性。

https://www.infoq.com/news/2026/01/uber-hivesync-data-lake/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。