共計 2974 個字符，預計需要花費 8 分鐘才能閱讀完成。
怎么通過 Apache Hudi 和 Alluxio 建設高性能數據湖，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
1.T3 出行數據湖總覽
T3 出行當前還處于業務擴張期，在構建數據湖之前不同的業務線，會選擇不同的存儲系統、傳輸工具以及處理框架，從而出現了嚴重的數據孤島使得挖掘數據價值的復雜度變得非常高。由于業務的迅速發展，這種低效率成為了我們的工程瓶頸。
我們轉向了基于阿里巴巴 OSS（類似于 AWS S3 的對象存儲）的統一數據湖解決方案，以遵循多集群、共享數據架構 (Multi-cluster,Shared-data Architecture) 的設計原則提供集中位置來存儲結構化和非結構化數據。與不同的數據孤島相反，所有應用程序都將 OSS 存儲作為事實的來源來訪問。這種體系結構使我們能夠按原樣存儲數據，而不必先對數據進行結構化，并運行不同類型的分析以指導更好的決策，通過大數據處理，實時分析和機器學習來構建儀表板和可視化。
2. 使用 Hudi 進行高效的近實時分析
T3 出行的智能出行業務推動了對近實時處理和分析數據的需求。使用傳統的數據倉庫，我們面臨以下挑戰：
長尾更新引發冷數據頻繁與級聯更新超長的業務窗口導致訂單分析回溯成本高隨機更新及遲到數據無法預判數據攝取 Pipeline 無法保證可靠性分布式數據 Pipeline 中丟數據無法對賬數倉數據攝取的延遲性很高
因此，我們在 OSS 之上采用了 Apache Hudi 來解決這些問題。下圖展示了 Hudi 的體系結構：
2.1 啟用近實時數據攝取和分析
T3 出行數據湖支持 Kafka 消息、Mysql binlog、GIS、業務日志等多種數據源近實時入湖，全公司 60% 以上的數據已經存入數據湖，并且這個比例還在不斷擴大。T3 出行通過在數據管道中引入 Hudi 將數據的攝取時間縮短至幾分鐘，再結合大數據交互式查詢與分析框架（如 Presto 和 SparkSQL），可以實現更實時地對數據進行洞察、分析。
2.2 啟用增量處理管道
T3 出行借助于 Hudi 提供的增量查詢的能力，對于頻繁變更場景中的多層數據加工的場景，可以只將增量的變更反饋給下游的派生表，下游的派生表只需要應用這些變更數據，就可以快速完成多層鏈路的局部數據更新，從而極大地降低了頻繁變更場景下的數據更新的效率。有效地避免了傳統 Hive 數倉中的全分區、冷數據更新。
2.3 使用 Hudi 作為統一數據格式
傳統的數據倉庫通常部署 Hadoop 來存儲數據并提供批處理分析，Kafka 單獨用于將數據分發到其他數據處理框架，從而導致數據重復。Hudi 有效解決了這個問題, 我們始終使用 Spark-kafka 管道將最新更新的數據插入到 Hudi 表中，然后以增量方式讀取 Hudi 表的更新。換句話說，Hudi 統一了存儲。
3. 使用 Alluxio 進行高效的數據緩存
在早期版本的數據湖中并沒有使用 Alluxio，Spark 實時處理從 Kafka 接收的數據，然后使用 Hudi DeltaStreamer 任務將其寫入 OSS。執行這個流程時，Spark 在直接寫入 OSS 時網絡延遲通常非常高。因為所有數據都存儲在 OSS 中，導致數據缺失本地性，所以對 Hudi 數據的 OLAP 查詢也非常慢。為了解決延遲問題，我們將 Alluxio 部署為數據編排層，與 Spark 和 Presto 等計算引擎共置一處，并使用 Alluxio 加速了對數據湖的讀寫，如下圖所示：
Hudi，Parquet，ORC 和 JSON 等格式的數據大部分存儲在 OSS 上，占 95%的數據。Flink，Spark，Kylin 和 Presto 等計算引擎分別部署在隔離的群集中。當每個引擎訪問 OSS 時，Alluxio 充當虛擬分布式存儲系統來加速數據，并與每個計算群集共存。下面介紹一下 T3 出行數據湖中使用 Alluxio 的案例。
3.1 數據入湖
我們將 Alluxio 與計算集群共置部署。在數據入湖前，將對應的 OSS 路徑掛載至 alluxio 文件系統中，然后設置 Hudi 的 –target-base-path 參數 從 oss://… 改為 alluxio://…。在數據入湖時，我們使用 Spark 引擎拉起 Hudi 程序不斷攝入數據，數據此時在 alluxio 中流轉。Hudi 程序拉起后，設置每分鐘將數據從 Allxuio 緩存中異步同步至遠程 OSS。這樣 Spark 從之前的寫遠程 OSS 轉變為寫本地的 Alluxio，縮短了數據入湖的時長。
3.2 湖上數據分析
我們使用 Presto 作為自助查詢引擎，分析湖上的 Hudi 表。在每一個 Presto worker 節點共置 Alluxio。當 Presto 與 Alluxio 服務共置運行時，Alluxio 可能會將輸入數據緩存到 Presto worker 的本地，并以內存速度提供下次檢索。在這種情況下，Presto 可以利用 Alluxio 從本地的 Alluxio worker 存儲讀取數據（稱之為短路讀取），無需任何額外的網絡傳輸。
3.3 跨多個存儲系統的并發訪問
為了確保訓練樣本的準確性，我們的機器學習團隊經常將生產中的脫敏數據同步到離線機器學習環境。在同步期間，數據跨多個文件系統流動，從生產 OSS 到線下數據湖集群 HDFS，最后同步到機器學習集群的 HDFS。對于數據建模人員來說，數據遷移過程不僅效率低下，而且會因錯誤配置而導致出錯，因為其中涉及多個不同配置的文件系統。于是我們引入 Alluxio, 將多個文件系統都掛載到同一個 Alluxio 下，統一了命名空間。端到端對接時，使用各自的 Alluxio 路徑，這保證了具有不同 API 的應用程序無縫訪問和傳輸數據。這種數據訪問布局還可以提高性能。
3.4 基準測試
總體而言，我們觀察到了 Alluxio 的以下優勢：
Alluxio 支持層次化且透明的緩存機制；Alluxio 支持讀取時緩存 promote 模式；Alluxio 支持異步寫模式；Alluxio 支持 LRU 回收策略；Alluxio 擁有 pin 以及 TTL 特性；
經過比較和驗證后，我們選擇使用 Spark SQL 作為查詢引擎，查詢了 Hudi 表，存儲層分別是 Alluxio + OSS、OSS、HDFS 這三組不同文件系統。壓測時發現，數據量大于一定量級（2400W）后，使用 alluxio+oss 的查詢速度超越了混合部署的 HDFS 查詢速度，數據量大于 1E 后，查詢速度開始成倍提升。到達 6E 數據后，相對于查詢原生 oss 達到 12 倍提升，相對于查詢原生 HDFS 達到 8 倍提升。數據規模越大，性能提升越顯著，提升的倍數取決于機器配置。
4. 展望
隨著 T3 出行的數據湖生態系統的擴展，我們將繼續面對計算和存儲隔離的關鍵場景隨著 T 對數據處理需求的增長，我們的團隊計劃大規模部署 Alluxio，以加強數據湖查詢能力。所以除了數據湖計算引擎（主要是 Spark SQL）上會部署 Alluxio 外，后續在 OLAP 集群（Apache Kylin）和 ad_hoc 集群 (Presto) 上架一層 Alluxio。Alluxio 將覆蓋全場景，每個場景間 Alluxio 互聯，提升數據湖以及圍湖生態的讀寫效率。
看完上述內容，你們掌握怎么通過 Apache Hudi 和 Alluxio 建設高性能數據湖的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
