在 8 月 16 日主題為“數智融合，云上創新”的華為云大咖說數智融合專場中，T3 出行大數據平臺研發負責人楊華分享了 T3 出行的 Lakehouse 架構與實踐：

　　2020年初 Databricks 在一篇論文中正式提出了“Lakehouse”的概念，同期三大開源數據湖框架(Apache Hudi/Iceberg/DletaLake OS版)逐步進入大家的視野。由于 Databricks 的 Lakehouse 是以DeltaLake作為核心 Table Format，因此，在做 Lakehouse 架構構建選型時，這三個框架便成為了優先選項。

　　Lakehouse(國內常稱之為“湖倉一體”) 是一個存算分離的架構，存儲與計算解耦，各自 scale-out。從存儲層來看，借助于糾刪碼技術，對象存儲使得數據的 TCO 與成本得到進一步的降低。從計算層來看，借助于彈性算力，計算資源從以前的長期租賃，變成了按需使用、按需計費的方式。

　　T3 出行由于從早期就參與 Apache Hudi 社區的源碼貢獻，因此很早就看到了新興的這些 Table Format 的優勢并開始探索、實踐 Lakehouse 架構。借助于華為云 FusionInsight 整體托管能力及其 OBS 對象存儲，T3 出行的 Lakehouse 得以穩健地支撐業務的快速增長。

　　T3 出行的 Lakehouse 架構同時支撐了面向數據分析的 BI 場景以及面向數據智能的 AI 場景，不僅使 TCO 相比技改前降低 20% 以上，更解決了傳統數倉難以支持分鐘級數據攝取等難題。以一套架構體系支撐了OLAP、AD-Hoc 查詢、離線與準實時的數據加工、機器學習訓練等BI、AI的典型場景，有效地支撐了“數智融合”。

　　從上面的整體架構圖中，我們可以看到：

　　●數據層：是一個以對象存儲為核心的中心化的存儲層，借助于低成本、接近無限橫向擴展且支持冷熱溫分層存儲等諸多優勢，再結合 Hudi Table Format 在事務語義、文件布局智能管理、多模索引能力、版本化的數據查詢等諸多特性的加持，讓它成為了 T3 海量數據存儲的基礎設施;

　　●計算層：在 BI、AI 方向下各細分的場景有很多的框架/引擎選型來滿足需要。而不同的引擎擁有異構的計算模式與負載，基于數據層中心化的存儲，計算層得以跟數據層完全解耦，在此基礎上，可以依據不同的計算模式與負載，將他們在物理上拆分為一個個獨立的小集群，從而使得計算層各種場景擁有絕對的獨立性。

　　在計算與存儲之間引入的 Hudi Table Format，是 Lakehouse 架構的核心，起到“承上啟下”的作用。目前國內的主流云廠商都在圍繞它封裝一些開箱即用的能力，如華為云數智融合平臺就是其中之一，除此之外，華為云數智融合平臺還提供了更進一步的“融合”能力：

　　●三層分離：通過存儲 - 緩存 - 內存三層分離，兼顧存儲成本和計算性能，讓性價比更高，計算更靈活。

　　●統一元數據：打破原有大數據、數倉、AI 的數據孤島，將數據目錄、數據權限、事務一致性等能力統一到一個中心點，實現一數多用，讓一份數據在多個引擎間自由流動共享，避免數據來回遷移。

　　●DataOps 和 MLOps 融合：企業不同部門、不同角色可以以擅長的方式敏捷用數。數據工程師可以使用熟悉的工具來調用 AI 能力，使大數據開發和 AI 開發協同起來。例如，讓數據工程師用 SQL、Python 交互式 Notebook 做數據清洗、特征工程、模型訓練，幾行代碼就能直接調用平臺內預置的 AI 算法，使數據和模型開發周期從天級降為分鐘級。

　　●全流程的自動化和智能化：華為云數智融合平臺將人工智能算法模型應用到數據集成、數據質量、數據建模、數據安全、數據訪問控制、數據關聯、數據關系和數據洞察的數據全生命周期治理。讓繁重的數據治理變得簡單。

　　而這一切都是因為Apache Hudi 的生態很豐富(見下圖)，(左側)不僅能夠支持多種多樣的Data Sources 并將數據從其中攝取到 Hudi 表中來。(右側)而且最底層能夠支持主流的、開源的及兼容 HDFS 接口的商業化存儲系統。而在存儲系統之上的是 Hudi 數據湖框架內核，它支持基于主流計算引擎如 Spark/Flink 以對數據進行 ETL 的能力。在更上層，可以基于 Hudi 框架所映射的表來進行查詢與構建數據處理 Pipeline。

　　下面介紹一下，T3 出行在 Lakehouse 架構下 BI 方向的幾個實踐。

　　第一個實踐是數據入湖。即將業務的關鍵數據(尤其指核心關系型數據庫中“會產生”增量變更的數據)攝取到數據湖中。全量入湖階段采用Spark將業務庫表中的存量數據一次性攝取到 Hudi 表中。增量入湖則主要將業務庫的變更數據，借助于 Binlog CDC 的能力，先將 Binlog 采集到 Kafka，然后通過 Flink對分庫分表的數據做一層輕粒度的匯聚后通過 Spark 或者 Flink 再將數據增量地回放到數據湖中。

　　全量與增量在實際操作過程中沒辦法無縫銜接，而Hudi支持的 Upserts 能力便解決了這個問題，它允許全量與增量銜接過程中的部分重復數據可以被正確地回放到 Hudi 表中并保證了“最終一致性”的語義。

　　第二個實踐是在湖倉中的 ETL。(見下圖)最下面的存儲層是一些 Hudi 表，這里由于 Hudi 表支持增量查詢，因此很多派生表都可以基于原始表來驅動增量 ETL。而在計算層，主要的引擎是 Spark SQL，考慮到湖倉中的表被分層分域，因此 ETL 的資源與作業也需要相應的隔離。經過充分地選型，T3 出行使用了 Apache Kyuubi(Incubating) 框架來解決多租戶間的資源隔離問題。

　　第三個實踐是關于湖倉中的 OLAP 以及 AD Hoc 查詢。從下圖我們看到，整體的分層與上圖中的ETL 類似。T3 出行仍然選擇將 Apache Kyuubi(Incubating) 作為引擎層之上的 SQL Gateway，并在此之上進行了一些能力擴展。在引擎層，為了支持多樣化的查詢分析需求，除 Spark 之外，又引入了 Presto、Doris 等查詢引擎。Kyuubi 除了對不同租戶的資源進行了有效的隔離外，對于同一租戶內的不同用戶，又可以很好地 share 上下文，從而避免了重復創建的時間與資源開銷。

　　在 AI 方向，T3 出行的很多業務早就實現了算法驅動決策，而這些能力都構建在以 Lakehouse 為基礎的機器學習平臺上，因此也積累了不少實踐。

　　在計算資源管理方面，借助 Kuberentes 面向不同的訓練場景，抽象出了 CPU 集群、GPU 集群，在上層使用微眾開源的 Prophecis 的機器學習平臺來做資源及機器學習環境的管理，內置了一些開箱即用的算法庫及相關環境。最上層提供了 Jupyter 集成開發環境，將算法與數據分析師從環境等問題中解脫出來，從而專注于業務開發。

　　在數據管理方面，構建了面向數據與AI的一體化的數據管理體系。整體上，將數據劃分為非結構化的數據與結構化的數據兩大類：

　　●對于非結構化的數據，如車載終端的音視頻數據，采用基于目錄的形式進行管理;

　　●對于結構化的數據(含部分半結構化)，統一以“表”的形式定義 Schema 來進行管理。

　　T3 出行在這兩大類數據基礎上，采集描述信息以形成一體化的元數據。之后再對數據統一進行標注、打標簽等治理工作，從而形成有價值的數據資產。

　　由于絕大部分的數據都可以抽象為“表”來進行管理，而他們都基于 Hudi 這一“表格式”。T3 出行在機器學習平臺中引入了 Feature Store，Feature Store 的 offline store 的表格式即為 Hudi。借助于 Hudi 一次“提交”可以看作一個“版本”的機制，使特征數據得以被版本化地管理起來。在這樣的 Feature Store 基礎上結合 CI/CD 體系可以很好地實現業界流行的 MLOps，目前 T3 出行正在這個方向上深度探索。

　　T3 出行構建的 Lakehouse 架構很好地支撐了當下業務的發展，但其實還有很多需要繼續調優的地方。比如，在計算層追求更好的彈性往云原生的方向快速前進、在計算與存儲層之間引入高效的緩存機制來降低存算分離帶來的性能衰減、統一元數據體系等。