數(shù)據(jù)湖架構(gòu)解析：華為云數(shù)智融合驅(qū)動下的T3 出行

　　在 8 月 16 日主題為“數(shù)智融合，云上創(chuàng)新”的華為云大咖說數(shù)智融合專場中，T3 出行大數(shù)據(jù)平臺研發(fā)負責人楊華分享了 T3 出行的 Lakehouse 架構(gòu)與實踐：

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

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

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

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

　　從上面的整體架構(gòu)圖中，我們可以看到：

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在 AI 方向，T3 出行的很多業(yè)務(wù)早就實現(xiàn)了算法驅(qū)動決策，而這些能力都構(gòu)建在以 Lakehouse 為基礎(chǔ)的機器學習平臺上，因此也積累了不少實踐。

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

　　在數(shù)據(jù)管理方面，構(gòu)建了面向數(shù)據(jù)與AI的一體化的數(shù)據(jù)管理體系。整體上，將數(shù)據(jù)劃分為非結(jié)構(gòu)化的數(shù)據(jù)與結(jié)構(gòu)化的數(shù)據(jù)兩大類：

　　●對于非結(jié)構(gòu)化的數(shù)據(jù)，如車載終端的音視頻數(shù)據(jù)，采用基于目錄的形式進行管理;

　　●對于結(jié)構(gòu)化的數(shù)據(jù)(含部分半結(jié)構(gòu)化)，統(tǒng)一以“表”的形式定義 Schema 來進行管理。

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

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

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