摘要：本文由 T3 出行大數(shù)據(jù)平臺負(fù)責(zé)人楊華和資深大數(shù)據(jù)平臺開發(fā)工程師王祥虎介紹 Flink、Kylin 和 Hudi 湖倉一體的大數(shù)據(jù)生態(tài)體系以及在 T3 的相關(guān)應(yīng)用場景，內(nèi)容包括：

1. 湖倉一體的架構(gòu)
   

2. Flink/Hudi/Kylin 介紹與融合

3. T3 出行結(jié)合湖倉一體的實踐
   

Tips：點擊文末「閱讀原文」即可回顧作者原版分享視頻～

這個分享有三個部分，首先探討湖倉一體的架構(gòu)，然后交流如何融合三個框架以及  T3 如何實踐湖倉一體這個架構(gòu)。

一、湖倉一體的架構(gòu)

數(shù)據(jù)湖和數(shù)據(jù)倉庫

既然聊湖倉一體，我們先了解一下什么是湖，什么是倉。數(shù)據(jù)湖是一個很老的概念，在近些年又被熱炒。業(yè)界對于數(shù)據(jù)湖到現(xiàn)在也沒有一個統(tǒng)一的定義。AWS 是最早在云上推出數(shù)據(jù)湖解決方案的云服務(wù)提供商，在這里我們便引用 AWS 對數(shù)據(jù)湖的定義：“數(shù)據(jù)湖是一個集中式的存儲庫，允許存儲任意結(jié)構(gòu)的數(shù)據(jù)并且能將它應(yīng)用于大數(shù)據(jù)處理，以及進(jìn)行實時分析和機(jī)器學(xué)習(xí)等相關(guān)的應(yīng)用場景?！?同樣我們也借助于 AWS 對數(shù)據(jù)倉庫做這樣的定義：“數(shù)據(jù)倉庫是信息的一個中央存儲庫?！?這里的信息是可對其進(jìn)行分析，并且可做出更明智的決策。

這個定義還有詳細(xì)的展開。AWS 這張圖通過展示了從湖到倉的數(shù)據(jù)流向的關(guān)系，來演示數(shù)據(jù)湖與數(shù)據(jù)倉庫之間的區(qū)別和聯(lián)系。首先數(shù)據(jù)最初是存在于數(shù)據(jù)湖或是數(shù)據(jù)庫中，然后經(jīng)過數(shù)據(jù)篩選和準(zhǔn)備之后，就會流向數(shù)據(jù)倉庫來進(jìn)行一些高價值的分析。這個對比表格很直觀的從數(shù)據(jù)、Schema、性價比、數(shù)據(jù)質(zhì)量、用戶和分析這 6 個維度給出數(shù)據(jù)湖和倉的對比。

湖倉一體的先例

今年我們聽說阿里巴巴提及的“湖倉一體”的概念。不知道大家有沒有想過湖倉一體在業(yè)界是否有成功的先例？我個人認(rèn)為是有的。今年 （2020年）9 月份，一家叫 Snowflake 的公司在紐交所上市。Snowflake 是一家做云數(shù)倉的公司，基于云廠商提供的基礎(chǔ)設(shè)施提供 SaaS 平臺，面向中小企業(yè)提供數(shù)據(jù)的托管和分析服務(wù)。Snowflake 自稱自己是一家云數(shù)倉公司，并且在 16 年的數(shù)據(jù)頂會上發(fā)表了一篇論文來介紹他們彈性數(shù)倉的架構(gòu)以及一些技術(shù)的細(xì)節(jié)。

Snowflake 其實是基于云上的對象存儲，一份存儲多份計算，并且計算與存儲分離的這樣一套架構(gòu)。其實這就是 AWS 以及現(xiàn)在主流云廠商所主推的這個數(shù)據(jù)湖的架構(gòu)。Snowflake上市的首日，他的市值就飆升到了 700 億美元的規(guī)模。所以我個人認(rèn)為 Snowflake 可以算是實行湖倉一體的一個最成功的先例。大家可以去了解一下剛談到的這篇論文。我摘出了這 5 個點來和大家做簡單的分享：

• 首先第一點，是沒有走現(xiàn)在傳統(tǒng)數(shù)倉所廣泛應(yīng)用的 Shared-Nothing 這個架構(gòu)，而是轉(zhuǎn)向 Shared-Data 這個架構(gòu)。

  
  

• 其次，論文中重點提及的存儲和計算分離，是文中我覺得最有價值的一個觀點。他提出了統(tǒng)一存儲然后彈性計算的這樣一個觀念。

  
  

• 第三，數(shù)倉及服務(wù)是我認(rèn)為他們商業(yè)化最成功的點。它將數(shù)倉提供了一個 SaaS 化的體驗，并且摒棄傳統(tǒng)上大家認(rèn)為的數(shù)倉是大而重的偏見。

  
  

• 第四，高可用這一塊是提高用戶體驗和容錯的很關(guān)鍵的一個點。

  
  

• 最后，結(jié)構(gòu)化延伸到半結(jié)構(gòu)化這一塊已經(jīng)體現(xiàn)當(dāng)時他們能夠探索湖上通用數(shù)據(jù)的能力。

 

這雖然是 16 年的一篇論文，但里面的觀念并不算陳舊并且仍然值得我們?nèi)W(xué)習(xí)。后續(xù)我們會簡單介紹幾個被我們吸收并且將會去實踐的一些點，而且這些點也是 T3 出行在實現(xiàn)湖倉一體上很關(guān)鍵的地方。

Shared - Nothing 架構(gòu)的優(yōu)勢

首先，作為一個被很多傳統(tǒng)的數(shù)倉廣泛應(yīng)用的一個架構(gòu)，Shared-Nothing 還是有一些架構(gòu)上的優(yōu)勢：

• 第一點，Table 上的數(shù)據(jù)可以進(jìn)行跨節(jié)點的水平分區(qū)，并且每個節(jié)點有自己的本地存儲。每個節(jié)點的計算資源，只關(guān)注處理每個節(jié)點自己存儲的數(shù)據(jù)。

  
  

• 所以它的另一個優(yōu)點就是它的處理機(jī)制相對簡單，是數(shù)倉領(lǐng)域很典型的一個架構(gòu)。

 

Shared - Nothing 架構(gòu)的劣勢

這套架構(gòu)其實也有一些不足的地方：

• 最大的一點就是他耦合了計算與存儲資源，

  
  

• 同時也帶來第二個問題，就是彈性不足。具體可以體現(xiàn)在 2 個方面。




• 集群在擴(kuò)縮容的時候，數(shù)據(jù)需要被大量重分布

  
  

• 沒有辦法簡單地卸載不用的計算資源。

  
  

• 第三個問題是，耦合計算和存儲資源同時也就造成了它的可用性是相當(dāng)有限的。由于這些稱之為有狀態(tài)的計算，所以在失敗或者是升級的時候會顯著影響性能，并會導(dǎo)致服務(wù)整體不可用的狀態(tài)。

  
  

• 最后是同構(gòu)的資源與異構(gòu)的負(fù)載的問題。因為在數(shù)倉的場景中，我們有很多異構(gòu)的負(fù)載，比如說批量的加載，查詢，報表的大規(guī)模計算分析等等。但 Shared-Nothing 架構(gòu)的資源是同構(gòu)的，所以這帶來兩者之間的碰撞。

Shared - Data 架構(gòu)

基于這些問題，Snowflake 提出了一個叫做 Multi-Cluster Shared-Data 架構(gòu)。這里我們對官方的圖做了一個簡單的微調(diào)。

• 這個架構(gòu)的第一個優(yōu)勢是它沒有數(shù)據(jù)孤島，是一個統(tǒng)一的存儲。這也就能夠?qū)⒋鎯挠嬎阒羞M(jìn)行解耦。

  
  

• 第二個優(yōu)勢是基于現(xiàn)在的對象存儲去容納結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

  
  

• 第三，它的集群規(guī)模是可以彈性作用的。

  
  

• 第四，上述特征同時也帶來了按需計算這個低成本優(yōu)點。

接下來我們以分層的形式來 review 這個架構(gòu)。從整體上來看，它的結(jié)構(gòu)大致分為三個層次。

• 最底層是云廠商提供的對象存儲，也就是用戶的存儲。

  
  

• 中間層是多用途多份的計算集群。

  
  

• 再往上是數(shù)據(jù)湖的管理服務(wù)，它存載的是一個大的 SaaS 化的平臺，是對整個底層存儲以及計算集群的管理的角色。

Shared - Data 的持續(xù)高可用

接下來一個點是這個架構(gòu)的高可用。這里可以簡單分解為 2 個方面。第一個是失敗容錯，第二個是在線升級。

• 首先，作為一個 SaaS 化的應(yīng)用，它的容錯性是需要體現(xiàn)在整體架構(gòu)上。這里我們同樣分層來回顧一下。




• 最底層的存儲層利用了云廠商的對象存儲能力，他本身是一個跨中心復(fù)制以及接近無限擴(kuò)容的一個機(jī)制，所以用戶基本無需關(guān)心。

  
  

• 再往上是多元的計算集群。每個計算集群是在同一個數(shù)據(jù)中心內(nèi)，來保證它網(wǎng)絡(luò)傳輸?shù)男阅堋＿@里就提到一個問題，有可能某一個計算集群會有節(jié)點失敗的問題。假如在一次查詢中有一個節(jié)點失敗，這些計算節(jié)點會將這個狀態(tài)返回上面的服務(wù)層。服務(wù)層在接受這個失敗后，會將這個計算再次傳遞到可用的節(jié)點中進(jìn)行二次查詢。所以 Shared-Data 存儲和計算分離的這種架構(gòu)上節(jié)點近乎是無狀態(tài)的計算。這種架構(gòu)的一個節(jié)點失敗就不是一個非常大的問題。

  
  

• 再往上服務(wù)層對于元數(shù)據(jù)的存儲也是利用了對象存儲的這個能力。所以這個服務(wù)層基本上可以看做是無狀態(tài)的服務(wù)。

  
  

• 最上層是一個負(fù)載均衡器，可以進(jìn)行服務(wù)的冗余和負(fù)載的均攤。

 

• 第二點在線升級這一塊主要利用兩個設(shè)計，其實這也并不是很新穎的做法。一個是在計算層和服務(wù)層的多方面的映射，然后灰度的切換。這里可以看到在計算層是分多版本的，并且這些版本之間會共享本地的 Cache。服務(wù)層的元數(shù)據(jù)管理也是在多方面共享。這其實也是架構(gòu)內(nèi)的子 Shared-Data，對于多版本之間的數(shù)據(jù)共享能做到再升級和平滑灰度的能力。

接下來我的同事（王祥虎）會跟大家介紹這 3 個框架以及它們是如何融合并最終支撐 T3 湖倉一體的實踐。在介紹第二個議題前他會先介紹我們的主框架，Hudi 和 Kylin 框架，然后再介紹他們?nèi)咧g是如何兩兩融合。最后再介紹T3是如何構(gòu)建湖倉一體的。

二、Flink/Hudi/Kylin 介紹與融合

Hudi 

首先來了解一下 Hudi 是什么。Hudi 最初是由 Uber 的工程師為了滿足他們的數(shù)據(jù)分析需求設(shè)計開發(fā)的一個數(shù)據(jù)湖框架。它于 2019 年 1 月份加入到 Apache 孵化器，并于 2020 年 5 月順利畢業(yè)，成為 Apache 的頂級項目。Hudi 的名字來源于 Hadoop Upserts Deletes and Incrementals 的縮寫。也就是說，Hudi 是一個支持插入、更新、刪除、以及增量處理的數(shù)據(jù)湖框架。除此之外，它還支持事務(wù)性 ACID 增量處理、存儲管理和時間管理。Hudi 能夠管理云上超大規(guī)模上百 PB 的分析型數(shù)據(jù)集，對于所有的云服務(wù)都開箱即用，非常的方便，而且已經(jīng)在 Uber 內(nèi)部穩(wěn)定運行了接近  4 年。

 

下圖是 Hudi 的插件化架構(gòu)。我們可以看到，Hudi 在存儲、數(shù)據(jù)處理引擎、表類型、索引類型、查詢視圖和查詢引擎方面都有比較寬松的支持。也就是說，他不與某一個組件綁定。

• 在存儲方面，Hudi 可以支持 HDFS，OSS 和 S3。

  
  

• 在數(shù)據(jù)處理引擎方面，Hudi 支持 Flink 和  Spark。Java 和 Python 客戶端已經(jīng)在社區(qū)支持中。Hudi 支持兩種表，COW 和 MOR，這兩種表分別對應(yīng)低延遲的查詢和快速攝入兩種場景。

  
  

• 在索引方面，Hudi 支持  Bloom 和 HBase 等 4 種索引類型。底層用了 Parquet 和 Avro 存儲數(shù)據(jù)，社區(qū)還正在做 ORC 格式的支持以及 SQL支持，相信不久的將來會跟大家見面。

Hudi 支持 3 種查詢，讀優(yōu)化查詢，增量查詢和快照查詢。而在查詢引擎方面，有 Spark 、Presto、Hive 和 Impala，實際上一些其他的組件已經(jīng)支持了。

下面詳細(xì)的介紹一下存儲模式和視圖。

• 第一個是 Copy On Write 模式，對應(yīng)到 Hudi 的 COW 表。它是一種側(cè)重低延時的數(shù)據(jù)查詢場景的表，底層使用 Parquet 數(shù)據(jù)文件存儲數(shù)據(jù)，能夠支持快照查詢和增量查詢兩種查詢方式。在查詢引擎方面，大家可以看到上面有 5 個引擎，他們對快照查詢、增量查詢和讀優(yōu)化 3 種視圖都有不同程度的支持。

  
  

• Merge On Read 表對 Copy On Write 有不同層面的互補，可以看到它側(cè)重于快速的數(shù)據(jù)攝入場景。使用 Parquet 文件來存儲具體的數(shù)據(jù)，使用行式 Avro 增量文件來存儲操作日志，類似于 HBase WAL。它支持 Hudi 所有 3 種視圖，可以看到  Hive，Spark SQL，Spark Datasource, Presto 和 Impala 對于讀優(yōu)化查詢都是支持的。而 Hive, Spark SQL 只支持到了快照查詢。這種組件支持的信息大家以后可以到官網(wǎng)上查詢。

 

在出行業(yè)務(wù)中，訂單會有支付長尾的屬性。也就是說一個訂單開始之后，它的支付環(huán)節(jié)可能會拖的比較久。換言之，它可能會在這個用戶下一次出行前才進(jìn)行支付（也或許會更久，甚至永遠(yuǎn)不支付）。這種長尾屬性將會導(dǎo)致一個超長的業(yè)務(wù)閉環(huán)窗口，會導(dǎo)致我們無法準(zhǔn)確預(yù)測數(shù)據(jù)的更新時機(jī)。如果存在多級更新的話，鏈路會比較長，更新成本也非常的高。

下圖是我們的長尾更新引發(fā)的冷數(shù)據(jù)頻繁更新示意圖。左側(cè)是業(yè)務(wù)庫，右側(cè)是有依賴關(guān)系的 3 張示意表。當(dāng)業(yè)務(wù)庫有數(shù)據(jù)更新時，右側(cè)需要更新的數(shù)據(jù)可能已經(jīng)歸檔到性能相對較差的設(shè)備上，增加數(shù)據(jù)更新成本。而且如果這次數(shù)據(jù)更新會引發(fā)長鏈路級聯(lián)更新的話，這種慢速的 I/O 還會被進(jìn)一步放大。

數(shù)據(jù)的可靠性也是數(shù)據(jù) ETL 中不可避免的問題?？赡苡捎跈C(jī)器故障或者計算邏輯導(dǎo)致加工處理的數(shù)據(jù)失真或者完全不對，就會給運營的決策造成很大的影響。數(shù)字延遲性方面，在基于 Hive 構(gòu)件的傳統(tǒng)架構(gòu)中，由于 Hive 缺少索引機(jī)制，所以數(shù)據(jù)更新大都會導(dǎo)致數(shù)據(jù)分區(qū)重寫，且沒有辦法原地刪除。其次小文件問題會增加 NameNode 存儲和查詢的負(fù)擔(dān)，拖慢進(jìn)程，在一定程度上增加數(shù)據(jù)延遲性。

 Kylin 框架

我們再來介紹一下這個 Kylin 框架。相比較 Hudi，大家應(yīng)該會對 Kylin 相對熟悉一些，它是一個開源的分布式分析型數(shù)據(jù)倉庫，能夠提供  Hadoop/Spark SQL 之上的數(shù)據(jù)查詢窗口。最初是由 eBay 開放并貢獻(xiàn)到開源社區(qū)，能夠在亞秒內(nèi)查詢巨大的表。它的秘訣其實就是做預(yù)計算，針對一個星型拓?fù)浣Y(jié)構(gòu)數(shù)據(jù)立方體，預(yù)算多個維度組合的度量把結(jié)果寫出到輸出表，對外暴露查詢接口實現(xiàn)實時查詢，也就是用空間來換取存取時間。

Kylin 在今年的 9 月份發(fā)布了 4.0 alpha 版本，這是在 Kylin3 之后一個重大架構(gòu)升級。使用 Parquet 代替 Hbase 存儲，從而提升了文件的掃描性能，也減輕甚至消除了 Hbase 的維護(hù)負(fù)擔(dān)。Kylin4 重新實現(xiàn)  Spark 構(gòu)建引擎和查詢引擎，使得計算和存儲分離，也更加適用云原生的技術(shù)趨勢。

 Flink/Hudi/Kylin 框架之間的融合

伴隨 Kylin3.1 發(fā)布，Kylin 與 Flink 就融合已經(jīng)完成。這個特性是在 2019 年完成的，Kylin 與 Flink 的集成開始于去年 1 月，通過 Flink Batch 實現(xiàn)。關(guān)于 Hudi 融合，可以說 Kylin 和 Hudi 天生就是兼容的，因為 Hudi 可以將自己暴露成一張 Hive 表，用戶可以像讀取 Hive 一樣使用 Hudi 的數(shù)據(jù)，這樣對Kylin會非常友好。因為 Kylin 可以把 Hudi 當(dāng)成一張 Hive 表無縫使用數(shù)據(jù)。Hudi 和 Flink 融合這個特性是我今年對社區(qū)的主要貢獻(xiàn)。這個兩張截圖對應(yīng) Hudi 和 Flink 融合路上的2個里程碑式的PR。

• 第一個 Hudi client 支持多引擎，將 Hudi 與 Spark 解耦，讓 Hudi 支持多引擎成為可能。

  
  

• 第二個是 Flink 客戶端基本實現(xiàn)貢獻(xiàn)到社區(qū)，讓 Hudi 可以真正意義上寫入 Flink 數(shù)據(jù)表。這 2 個改動非常大，加在一起已經(jīng)超過了 1 萬行的代碼，也可以說是今年 Hudi 社區(qū)比較亮眼的一個特性。

Hudi 和 Flink 的融合過程

下面來詳細(xì)介紹下 Hudi 和 Flink 融合過程。Hudi 原本只支持 Spark 引擎，所以第一步是將 Hudi 與 Spark 解耦之后再去集成我們想要的引擎。

解耦的難點在于 Hudi 最初沒有考慮多引擎的支持，所以從數(shù)據(jù)源讀取數(shù)據(jù)到最終將數(shù)據(jù)寫出到 Hudi 表，RDD 無處不在。連普通的工具類都會使用 RDD 作為基本的操作單元。與 Spark 解耦，我們評估到他的改動非常的大。其次是 Flink 與 Spark 核心抽象上的差異。Spark 認(rèn)為數(shù)據(jù)是有限的數(shù)據(jù)集，而 Flink 認(rèn)為數(shù)據(jù)是無界的，是一種數(shù)據(jù)流。這種抽象上的差異導(dǎo)致我們很難統(tǒng)一出一個通用的抽象。

這次改動對于 Hudi 來說是傷筋動骨的，因此我們決定要優(yōu)先保證原版 Hudi 的功能和性能，當(dāng)然也犧牲了部分 Flink Stream API。讓 Flink 來操作 list，而用Spark 操作 RDD。這樣就可以抽取一個泛型<I>出來形成一個統(tǒng)一的抽象層。

抽象原則：

1. 統(tǒng)一使用泛型 I、K、O 代替。

   
   

2. 去 Spark 化，抽象層 API 都是引擎無關(guān)的，難以在抽象層實現(xiàn)的，我們會把它改為抽象方法下推到 Spark 子類實現(xiàn)。

   
   

3. 不影響原版，抽象層盡量的減少改動，以保證固定的功能性。

   
   

4. 引入 HoodieEngineContext 代替 JavaSparkContext, 提供運行時的上下文。

下面說 Flink Client DAG，這里主要分了 5 部分，

• 第一部分是 Kafka Streaming Source，主要用來接收Kafka數(shù)據(jù)并轉(zhuǎn)換成 List<HoodieRecord>。

  
  

• 第二個是   InstantGeneratorOperator,一個 Flink 算子, 用來生成全局唯一的 instant。

  
  

• 第三是 KeyBy 分區(qū)操作，根據(jù) partitionPath 分區(qū)避免多個子任務(wù)將數(shù)據(jù)寫入同一個分區(qū)造成沖突。

  
  

• 第四個是 WriteProcessOperator，這也是我們自定義的一個算子。這個算子是寫操作實際發(fā)生的地方。

  
  

• 第五個是 CommitSink，他會接受上游 WriteProcessOperator 發(fā)來的數(shù)據(jù)，根據(jù)上游數(shù)據(jù)判斷是否提交事務(wù)。
  

 

下面是 Flink 更新的代碼示例。左側(cè)是原版里面 HoodieWriteClient 簡化的版本，

可以看到 insert 函數(shù)的入?yún)⑹?RDD，返回值也是 RDD。右側(cè)抽象之后的 abstract 可以看到它的入?yún)⒆兂闪朔盒虸，返回值變成了 O，有興趣的話大家可以去了解一下。

下面是我們對 Flink 如何融合的另外一個想法，就是希望做出一個 streaming source，使用 Flink 構(gòu)建一個完整的從 Hudi 表讀數(shù)據(jù)，再寫出到 Hudi 表的 ETL 管道。

然后是我們初步的設(shè)想。左側(cè)灰色的圖里面有 5 列的 Hudi 元數(shù)據(jù)。最左側(cè)是  hoodie_commit_time 事務(wù)列表。每一個 hoodie_commit_time 對應(yīng)一個事務(wù)，每一個事務(wù)對應(yīng)一批的數(shù)據(jù)。每一批數(shù)據(jù)中的每一條記錄都會有一個提交的序列號，就是第 2 列 hoodie_commit_seqno 序列號。hoodie_commit_time 和  hoodie_commit_seqno 這種映射關(guān)系跟 Kafka 中的分區(qū)和 offset 的這種映射關(guān)系非常類似。后期我們可能會基于這種特點實現(xiàn)一個 Hoodie Streaming Source。

 

基于這 3 個框架之間的融合關(guān)系，我們發(fā)現(xiàn)分別用于計算、分析、存儲的這 3 個引擎之間是相互兼容的。并且他們能夠支持湖倉一體，向云原生體系靠攏。

三、T3 出行結(jié)構(gòu)湖倉一體的實踐

最后我們來看一看 T3 出行是如何構(gòu)建湖倉一體的。這是我們 T3 出行車聯(lián)網(wǎng)的架構(gòu)，可以看到是從底向上，從基礎(chǔ)支持到上層不停的賦能，并與車企的信息系統(tǒng)、國家信息平臺做交互。作為一家車聯(lián)網(wǎng)驅(qū)動的出行公司，我們收集到了人、車、路等相關(guān)的數(shù)據(jù)，每一種數(shù)據(jù)都有它自己的應(yīng)用場景， 數(shù)據(jù)之間并不孤立，相互賦能，共同支持 T3 智慧出行。

 

 

這是我們的存儲和計算分離的數(shù)據(jù)庫架構(gòu)，整個架構(gòu)分為了兩層，一層是計算層，一層是存儲層。

• 計算層我們用到了 Flink、Spark、Kylin 和 Presto 并且搭配 ES 做任務(wù)調(diào)度。數(shù)據(jù)分析和展示方面用到了達(dá)芬奇和 Zeppelin。

• 在存儲層，我們使用了阿里云 OSS 并搭配 HDFS 做數(shù)據(jù)存儲。數(shù)據(jù)格式方面使用 Hudi 作為主要的存儲格式，并配合 Parquet、ORC 和 Json 文件。在計算和存儲之前，我們加了一個 Alluxio 來加速提升數(shù)據(jù)處理性能。資源管理方面我用到了 Yarn，在后期時機(jī)成熟的時候也會轉(zhuǎn)向 K8s。

在當(dāng)前存儲計算分離的趨勢下，我們也是以湖存儲為核心，在它周圍構(gòu)建了湖加速湖計算、OLAP 分析、交互式查詢、可視化等等一整套的大數(shù)據(jù)生態(tài)體系。

T3對 Hudi 的應(yīng)用場景

下面是我們 T3 內(nèi)部對 Hudi 的幾個應(yīng)用場景。

• 一個是近實時的流數(shù)據(jù)管道。我們可以從左側(cè)通過 Log、MySQL 或者直接讀取業(yè)務(wù)數(shù)據(jù)的 Kafka，把數(shù)據(jù)導(dǎo)入到數(shù)據(jù)管道中，再使用 Flink 或者原版的 DeltaStreamer 將流式數(shù)據(jù)輸入到列表中。

近實時的流式數(shù)據(jù)處理的 Flink UI 界面上可以看到之前介紹的 DAG 的幾個算子都在里面，比如 source、instant_generator 等。

 

• 另一個是近實時的數(shù)據(jù)分析場景。我們使用 Hive、Spark 或 Presto 查詢數(shù)據(jù)，并最終用達(dá)芬奇或者 Zeppelin 做最終的數(shù)據(jù)報表。

這是我們用 Hudi 構(gòu)建的增量數(shù)據(jù)管道。最左側(cè) CDC 數(shù)據(jù)捕獲之后要更新到后面的一系列的表。有了 Hudi 之后，因為 Hudi 支持索引和增量數(shù)據(jù)處理，我們只需要去更新需要更新的數(shù)據(jù)就可以了，不需要再像以前那樣去更新整個分區(qū)或者更新整個表。

• 最后的一個場景是將前面介紹的用 Flink 將線上或者業(yè)務(wù)數(shù)據(jù)訂閱 ETL 到 Hudi 表中供機(jī)器學(xué)習(xí)使用。但是機(jī)器學(xué)習(xí)是需要有數(shù)據(jù)基礎(chǔ)的，所以我們利用 Hudi 將線上的數(shù)據(jù)增量發(fā)布到線下環(huán)境，進(jìn)行模型訓(xùn)練或者調(diào)參。之后再將模型發(fā)布到線上為我們的業(yè)務(wù)提供服務(wù)。

更多 Flink 相關(guān)技術(shù)問題，可掃碼加入社區(qū)釘釘交流群～

---

▼ 關(guān)注「Flink 中文社區(qū)」，獲取更多技術(shù)干貨 ▼

戳我，回顧作者分享視頻！