華為云數(shù)智融合驅(qū)動智慧出行：T3出行的Lakehouse實踐

T3 出行是一家致力于成為能夠為用戶提供“安全、便捷、品質(zhì)”出行服務(wù)的科技創(chuàng)新型企業(yè)。截止 2022 年 8 月，T3 出行登陸全國 92 個城市，累計注冊用戶超 1.1 億，單日訂單峰值破 300 萬單。國內(nèi)權(quán)威第三方數(shù)據(jù)機構(gòu) QuestMobile 發(fā)布的 2021 中國移動互聯(lián)網(wǎng)秋季大報告顯示，T3出行月度活躍用戶（MAU）已經(jīng)突破 1200 萬。

然而隨著業(yè)務(wù)規(guī)?？焖僭鲩L，T3 出行在支撐海量的數(shù)據(jù)存儲與計算時面臨著：傳統(tǒng)數(shù)倉難以解決出行場景的“長尾支付”、TCO（Total Cost of Ownership，總體擁有成本）居高不下、運維成本高且擴展性受限等問題。

為滿足業(yè)務(wù)發(fā)展，T3 出行將最初的傳統(tǒng)數(shù)倉架構(gòu)改造成業(yè)界新興的 Lakehouse 架構(gòu)，他們的研發(fā)團(tuán)隊在這個過程中走了不少“捷徑”，像華為云數(shù)智融合產(chǎn)品就為其構(gòu)建 Lakehouse 提供了不少助力。

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

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

在過去的兩年里，圍繞這三個數(shù)據(jù)湖框架構(gòu)建的 Lakehouse 架構(gòu)正在被越來越多的企業(yè)接受并付諸實踐。 Lakehouse（國內(nèi)常稱之為“湖倉一體”） 是一個存算分離的架構(gòu)，存儲與計算解耦，各自 scale-out。從存儲層來看，借助于糾刪碼技術(shù)，對象存儲使得數(shù)據(jù)的 TCO 與成本得到進(jìn)一步的降低。從計算層來看，借助于彈性算力，計算資源從以前的長期租賃，變成了按需使用、按需計費的方式。

T3 出行由于從早期就參與 Apache Hudi 社區(qū)的源碼貢獻(xiàn)，因此很早就看到了新興的這些 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 查詢、離線與準(zhǔn)實時的數(shù)據(jù)加工、機器學(xué)習(xí)訓(xùn)練等BI、AI的典型場景，有效地支撐了“數(shù)智融合”。

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

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

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

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

· 三層分離：通過存儲 - 緩存 - 內(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ù)清洗、特征工程、模型訓(xùn)練，幾行代碼就能直接調(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ù)進(jìn)行 ETL 的能力。在更上層，可以基于 Hudi 框架所映射的表來進(jìn)行查詢與構(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，并在此之上進(jìn)行了一些能力擴展。在引擎層，為了支持多樣化的查詢分析需求，除 Spark 之外，又引入了 Presto、Doris 等查詢引擎。Kyuubi 除了對不同租戶的資源進(jìn)行了有效的隔離外，對于同一租戶內(nèi)的不同用戶，又可以很好地 share 上下文，從而避免了重復(fù)創(chuàng)建的時間與資源開銷。

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

在計算資源管理方面，借助 Kuberentes 面向不同的訓(xùn)練場景，抽象出了 CPU 集群、GPU 集群，在上層使用微眾開源的 Prophecis 的機器學(xué)習(xí)平臺來做資源及機器學(xué)習(xí)環(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ù)，采用基于目錄的形式進(jìn)行管理；

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

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

由于絕大部分的數(shù)據(jù)都可以抽象為“表”來進(jìn)行管理，而他們都基于 Hudi 這一“表格式”。T3 出行在機器學(xué)習(xí)平臺中引入了 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)很好地支撐了當(dāng)下業(yè)務(wù)的發(fā)展，但其實還有很多需要繼續(xù)調(diào)優(yōu)的地方。比如，在計算層追求更好的彈性往云原生的方向快速前進(jìn)、在計算與存儲層之間引入高效的緩存機制來降低存算分離帶來的性能衰減、統(tǒng)一元數(shù)據(jù)體系等。

而華為云已經(jīng)在這些方面做了許多技術(shù)探索并形成了能力層與產(chǎn)品化的沉淀。T3出行將持續(xù)與華為云一同合作與探索，通過華為云數(shù)智融合平臺，更好地實現(xiàn)數(shù)據(jù)與智能的融合與統(tǒng)一，共同賦能智慧出行。 我們有理由相信，在華為云數(shù)智融合平臺的加持下，會有越來越多的企業(yè)能夠通過 AI 重新定義數(shù)據(jù)治理，讓數(shù)據(jù)高效激發(fā)出更多 AI 創(chuàng)新能力。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。