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進一步整合。