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