經過Apache Hudi和Alluxio建設高性能數據湖

T3出行的楊華和張永旭描述了他們數據湖架構的發展。該架構使用了衆多開源技術，包括Apache Hudi和Alluxio。在本文中，您將看到咱們如何使用Hudi和Alluxio將數據攝取時間縮短一半。此外，數據分析人員如何使用Presto、Hudi和Alluxio讓查詢速度提升了10倍。咱們基於數據編排爲數據管道的多個階段（包括提取和分析）構建了數據湖。

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互聯，提高數據湖以及圍湖生態的讀寫效率。

5.結論

正如前面所講，Alluxio覆蓋了Hudi近實時攝取，近實時分析，增量處理，DFS上數據分發等全部場景，在數據入湖和湖上數據分析鏈路上都扮演了強力加速器的角色，二者可謂強強聯手。落地到具體場景上，研發工程師將數據入湖時間縮短了1-2倍。數據分析人員使用Presto+Hudi+Alluxio查詢湖上數據的速度提升了10倍以上。Alluxio是T3出行成爲中國領先的企業級數據湖計劃中重要組成部分，咱們期待在T3出行的數據湖生態系統中與Alluxio進一步集成。