摘要：本文整理自餓了么大數(shù)據(jù)架構(gòu)師俊性、Apache Flink Contributor 王沛斌老師在8月3日 Streaming Lakehouse Meetup Online（Paimon x StarRocks，共話實時湖倉架構(gòu)）上的分享酱酬。主要分為以下三個內(nèi)容：
- 餓了么實時數(shù)倉演進之路
- 實時湖倉方案選型與探
- 實時湖倉規(guī)劃及展望
一派昧、餓了么實時數(shù)倉演進之路
1. 餓了么典型實時應用場景
以上是餓了么在實時應用中的一些典型場景傻丝，和許多公司有相似之處赖晶。具體分為以下幾個部分：
（1）實時 ETL：包括實時數(shù)據(jù)入湖入倉、實時數(shù)據(jù)建模腔长、實時流量歸因等袭祟。
（2）實時報表應用：包括營銷活動直播、商家生意參謀捞附、實時流量大盤巾乳、大促實時大屏、實時AB實驗等鸟召。
（3）實時與在線應用的聯(lián)動：包括商物流實時聯(lián)動想鹰、實時人群特征及投放、個性化推薦药版、IOT信息同步辑舷、風控實時攔截等。
（4）實時監(jiān)控與補償：包括實時數(shù)據(jù)核對與訂正槽片、業(yè)務診斷預警何缓、服務器異常監(jiān)控等肢础。
2. 餓了么數(shù)據(jù)架構(gòu)大圖
餓了么整體數(shù)據(jù)架構(gòu)大圖主要由三個層面組成，分別為數(shù)據(jù)采集層碌廓，數(shù)據(jù)加工層传轰，數(shù)據(jù)服務層。相關(guān)的數(shù)據(jù)組件依托阿里云組件谷婆。整體數(shù)據(jù)采集使用 DataX 和 DRC 鏈路來進行數(shù)據(jù)庫 Binlog 的采集慨蛙。日志采集主要使用內(nèi)部的 Omni 平臺來收集用戶行為數(shù)據(jù)，而應用層的日志通過 SLS 和 TT 來進行相應的日志接入纪挎。
數(shù)據(jù)倉庫這一層是一個重點期贫。一個是存儲方面可以分為兩塊：一塊是近實時的湖倉，采用 Paimon On OSS 方案來進行存儲异袄；而對于實時性要求更高的數(shù)據(jù)通砍，使用的是 TT 和 SLS。在數(shù)倉計算層烤蜕，使用的是 Dataphin封孙、VVP（實時計算 Flink） 和 Flink 三件套。在數(shù)據(jù)服務層讽营，主要的數(shù)據(jù)存儲使用 ADB 和 Hologres虎忌，最近引入了 StarRocks 來結(jié)合湖倉進行落地。在這個存儲基礎(chǔ)上橱鹏，通過內(nèi)部的數(shù)據(jù)服務應用（包括繁星膜蠢、方舟、FBI蚀瘸、量子等組件）來提供相應的數(shù)據(jù)服務狡蝶。通過以上數(shù)據(jù)服務庶橱，構(gòu)建了整體的數(shù)據(jù)產(chǎn)品和數(shù)據(jù)解決方案贮勃。
最核心的兩個點是計算和存儲。上圖右邊展示了整體計算變化的情況苏章。右邊第一張圖顯示了我們內(nèi)部 Blink 和 Flink 的用量曲線寂嘉。可以觀察到枫绅，早期更多使用的是 Blink泉孩，隨著 Flink 的進一步拓展，到2023年左右并淋，開始大規(guī)模切換到 Flink寓搬。計劃在今年將所有 Blink 下線，全部統(tǒng)一切換到 Flink县耽。第二張圖顯示的是存儲層的情況句喷。存儲層早期更多使用的是 ADB镣典，現(xiàn)階段更多使用 Hologres 來支持。未來 Hologres 的用量也會逐步擴大唾琼，并引入類似 StarRocks 這樣的 OLAP 引擎兄春，以提升團隊整體研發(fā)效率。
3. 實時數(shù)倉1.0
基于上述的兩個背景锡溯，接下來介紹一下我們內(nèi)部當前實時數(shù)倉建設(shè)的情況赶舆。
實時數(shù)倉的1.0版本中，這是大多數(shù)公司早期版本的典型樣子祭饭。我們通過日志和數(shù)據(jù)庫的 Binlog 進行數(shù)據(jù)采集芜茵，這些數(shù)據(jù)最終進入 ODS 層。在 1.0 版本的早期階段甜癞，我們投入了大量工作來建設(shè) DWD 層夕晓。在 DWD 層，我們對一些共性的維度和邏輯進行了擴展悠咱，并屏蔽了多余的場景蒸辆，建設(shè)了完善的 DWD 層群以供下游消費使用。
對于不同的應用場景析既，我們開發(fā)了相對獨立的 ADS 層躬贡，這一層并未進行公共層的建設(shè)。而對于核心業(yè)務場景眼坏，我們采用了 Lambda 架構(gòu)將歷史數(shù)據(jù)通過 T+1 的方式導入到 OLAP 引擎中拂玻，以保證數(shù)據(jù)的穩(wěn)定性。在此過程中會出現(xiàn)幾個問題：首先是研發(fā)效率較低的問題宰译，會產(chǎn)生較多的重復開發(fā)工作檐蚜。其次，隨著業(yè)務的變化沿侈，這些邏輯往往無法及時同步更新闯第，導致數(shù)據(jù)一致性缺乏保障。這不僅增加了整體的運維成本缀拭，也增加了計存成本咳短。
基于上述情況，我們期望達成以下兩個目標：首先是確保數(shù)據(jù)能夠更快蛛淋、更準咙好、更穩(wěn)、更一致褐荷；其次是提升整體的開發(fā)效率和運維效率勾效。具體的解決方案總結(jié)為四個要點：
（1）數(shù)據(jù)產(chǎn)品能力升級，收斂實時需求。
（2）夯實實時的 CDM 資產(chǎn)层宫，收口指標加工邏輯绘迁。
（3）實時數(shù)倉架構(gòu)方案升級，獲取技術(shù)紅利卒密，降低研發(fā)復雜度缀台。
（4）研發(fā)規(guī)范化及工具沉淀（流程卡點&實時基線等）。
4. 實時數(shù)倉2.0
上述第二點對應的是實時數(shù)倉 2.0 的具體方案哮奇。具體方案是建設(shè)核心的 CDM 層膛腐，將常見的共性維度和指標加工成 DWS 資產(chǎn)。這個方案是在去年年初提出的鼎俘，整體方式是借助 Dataphin 來構(gòu)建一個流批一體化的系統(tǒng)哲身。
實時的 DWD 和離線的 DWD 通過 Dataphin 的邏輯表進行映射，在 Dataphin 上開發(fā)具體的 SQL 任務后贸伐， Dataphin 會將其翻譯成 Flink 的流任務和批任務勘天。在此基礎(chǔ)上，結(jié)合 D2 的 Dataworks捉邢，根據(jù)每一個調(diào)度將每天的 T+1 任務觸發(fā)脯丝，最終將數(shù)據(jù)回寫到 OLAP 集群中。通過 OLAP 集群的 Binlog 來驅(qū)動下游的實時消費伏伐。這樣下游的 ADS 層只需進行現(xiàn)有指標的簡單統(tǒng)計或行列轉(zhuǎn)化后將數(shù)據(jù)寫入各自的存儲以滿足不同查詢場景的使用和需求宠进。
完成這條鏈路后，整體的核心資產(chǎn)消費鏈路和研發(fā)效率得到了提升藐翎，數(shù)據(jù)一致性也得到了保障材蹬。然而，仍然存在一些問題吝镣。例如它主要支持存量的重要業(yè)務堤器，對于一些新興業(yè)務這條鏈路并不適用。另外這鏈路并未完全實現(xiàn)流批一體化的目標末贾。在 DWD 層數(shù)據(jù)實際上還是有兩份存儲闸溃，一份在 TT，一份在 ODPS未舟。
此外圈暗，實時中間層更多使用的是 TT掂为，但 TT 不支持檢索和更新裕膀。在研發(fā)或數(shù)據(jù)訂正的過程中，這會帶來較高的成本勇哗。同時昼扛，TT 也不支持列裁剪。以流量中間層為例每次消費都會產(chǎn)生大量的帶寬費用。再者抄谐，OLAP 集群內(nèi)表存儲成本往往比較高渺鹦。因此，無論是從降低成本還是提升效率的角度來看蛹含，我們都希望引入更好的數(shù)據(jù)架構(gòu)毅厚。因此，我們找到了當前比較熱門的解決方案 —— Streaming Lakehouse浦箱。
二吸耿、實時湖倉方案選型與探索
那么我們想引入 Streaming Lakehouse 要如何實施呢？首先要做的就是具體的選型和探索落地的實踐酷窥。
1咽安、選型與測評方案
在整個選型過程中，使用了餓了么最核心的交易蓬推、營銷和流量三個域的明細數(shù)據(jù)作為測試數(shù)據(jù)妆棒，并將數(shù)據(jù)寫入對應的湖存儲格式中。我們當時評測選擇了 Paimon + Hudi 這兩種湖格式沸伏。為了方便整體驗證還與現(xiàn)有的 OLAP 集群的內(nèi)表方案進行對比糕珊。
在 OLAP 引擎方面，主要引入了 StarRocks毅糟、Trino 引擎進行對比放接。在存儲層，我們主要關(guān)注數(shù)據(jù)寫入后的膨脹系數(shù)留特、流讀和流寫的性能纠脾，以及端到端的寫入延遲。在 OLAP 部分蜕青，我們重點關(guān)注查詢的耗時和單次查詢的開銷苟蹈。
上圖左邊展示了我們在整個評測中所使用的版本。整體使用的集群規(guī)模大約為 200CU右核。由于規(guī)格的原因慧脱， StarRocks 的集群總共是 192CU。在這些組件中贺喝，大家比較關(guān)注的 StarRocks 和 Trino 我們是直接采用了阿里云的 EMR 5.15.1 版本進行部署的菱鸥。
2、Paimon VS Hudi
Paimon 和 Hudi 哪個更優(yōu)呢躏鱼？
圖中左上角展示了經(jīng)過多輪測試后得出的結(jié)果氮采，整體排名基本上都是 Paimon 優(yōu)于 Hudi。同時染苛，Paimon 的性能也接近 OLAP 集群內(nèi)表方案的查詢性能鹊漠。但是在端到端的時效性方面，OLAP 集群內(nèi)表方案仍然是最快，可以達到秒級別躯概。Paimon 的時效性測試結(jié)果大約在1到5分鐘登钥，平均約為3分鐘。Hudi 在這一塊的延遲一般在10分鐘左右娶靡。
基于上述測評結(jié)果牧牢，選擇 Paimon 作為后續(xù)的湖存儲格式。結(jié)合前面提到的三個月具體場景姿锭，上圖可以看到對應的 Paimon 表的創(chuàng)建方式结执。對于交易和營銷數(shù)據(jù)，由于需要實時更新艾凯，因此我們使用了一個PK表献幔，指定了 Bucket 并同時開啟了 ZSTD 壓縮。在這個過程中趾诗，還需要通過 Sequence Field 進行版本控制蜡感。流量表則是一個 Append Only 表，基本上設(shè)置為 Bucket=-1恃泪，以支持自動化擴展郑兴。同時為了保障讀寫的性能平衡，所以每一個文件大概需要控制在一個 GB 范圍內(nèi)贝乎。
3情连、StarRocks VS Trino
在對比 StarRocks、Trino 的性能時览效，StarRocks 在各個方面都表現(xiàn)比較出色却舀。是什么原因使得 StarRocks 的性能如此出色呢？首先锤灿，StarRocks 的 JNI Connector 對 Paimon 進行了良好的適配挽拔。其次，StarRocks 支持過濾下推但校。上圖右下展示了餓了么基于 StarRocks 的一個 profile 截圖螃诅，可以看到 “city_id” 和 “is_valid_order” 這兩個字段實現(xiàn)了有效的下推。此外状囱，StarRocks 還具備高效的向量化執(zhí)行引擎术裸，并且可支持對 Paimon 的 RO 表進行查詢。最后亭枷，雖然我們目前還沒有正式使用物化視圖 +SQL 透明改寫和 Data Cache 這兩個功能袭艺，但可以預見一旦投入使用性能將會進一步提升。在這樣的背景下奶栖，餓了么最終選擇使用 StarRocks 和 Paimon 作為湖倉解決方案匹表。
4、實時湖倉落地探索
經(jīng)過多次探索宣鄙，我們確定了如上圖所示的湖倉建設(shè)架構(gòu)袍镀。主要的數(shù)據(jù)處理鏈路使用 Flink 進行 Paimon 的流讀流寫，Paimon 的數(shù)據(jù)存儲在內(nèi)部 OSS 集群上冻晤，并通過 DLF（Data Lake Formation）進行元數(shù)據(jù)管理苇羡。通過 Paimon 的流讀流寫功能，支持實時數(shù)倉的分層建模鼻弧。在特定場景下设江，利用 StarRocks 的物化視圖進行應用層或匯總層的計算。同時基于明細數(shù)據(jù)通過 StarRocks 和 Hologres 的數(shù)據(jù)湖外表查詢能力支持自助洞察分析的需求攘轩。具體應用場景包括：流量寶洞察分析叉存、實時交易補貼自助分析以及客滿的服務大屏等。
5度帮、落地探索-DWD自助分析
接下來主要介紹基于交易和補貼的自助分析場景歼捏。首先，數(shù)據(jù)源提供訂單流和補貼流兩個實時流笨篷。在傳統(tǒng)方案中瞳秽，這兩個流在Flink任務中進行雙流 Join 處理后寫入 OLAP 集群內(nèi)表，再基于 OLAP 集群內(nèi)表提供自助分析服務率翅。引入 Paimon 之后练俐，兩條流直接寫 Paimon 的 Partial-update 表，指定不同流中的 Sequence Group 來進行對應字段的版本控制冕臭。在這種情場景下腺晾，整體 Flink 的資源開銷相比原來的雙流 Join 方案減少了大約50%，同時系統(tǒng)的整體穩(wěn)定性也顯著提升辜贵。
然后在 StarRocks 這一層丘喻，通過 StarRocks 來讀 Paimon 外表這塊來支持的。上圖右上角是整體的 Profile 的結(jié)果念颈，可以看到大部分的瓶頸其實還是在 IO 這一層的泉粉。所以后續(xù)如果做數(shù)據(jù)湖的加速分析的話，IO 這一層還是優(yōu)化的重點榴芳。
上圖右下角展示了整個自助分析的結(jié)果示意圖嗡靡。與之前基于 OLAP 集群內(nèi)表的實時數(shù)倉方案相比，這個方案在寫入時效性上犧牲了1到5分鐘窟感，同時單次查詢的耗時增加了約5%讨彼。然而，整體存儲成本較原有的 OLAP 集群內(nèi)表減少了約90%柿祈，F(xiàn)link 任務的資源開銷也減少了大約50%哈误。
三哩至、實時湖倉規(guī)劃及展望
1、實時數(shù)倉3.0 展望
如果建設(shè)了實時湖倉蜜自，后續(xù)的加工鏈路可以進一步豐富菩貌，從而構(gòu)建不同場景下的數(shù)據(jù)解決方案。相比之前的實時數(shù)倉2.0版本重荠，DWD 層和 TT 層將逐步替換為數(shù)據(jù)湖箭阶。使用數(shù)據(jù)湖后，可以針對低頻場景構(gòu)建準實時或?qū)崟r的物化視圖戈鲁，通過物化視圖進行分層建模仇参。同時，還可以利用 Paimon + Flink 的流讀流寫能力進行分層建模婆殿。在數(shù)據(jù)服務層诈乒，可以根據(jù)業(yè)務需求按需查詢對應的 DWD、DWS 或 ADS 層婆芦，從而構(gòu)建多元化的數(shù)據(jù)交付方案抓谴。
具體的交付方案如上圖左下角所示，不同場景可以選擇不同的交付方案寞缝，利用現(xiàn)有的實時數(shù)據(jù)資產(chǎn)癌压，提升研發(fā)效率。然而這邊仍會遇到一些問題：OSS 帶寬瓶頸在壓測過程中已經(jīng)顯現(xiàn)出來需要解決荆陆，同時 OSS 上的小文件問題也是亟需解決的滩届。Paimon 的時效性目前為1到5分鐘，對于強時效性訴求的業(yè)務仍需要保留 TT 鏈路被啼。雖然 Paimon 和 StarRocks 現(xiàn)有的元數(shù)據(jù)可以通過 DLF 管理帜消，但與內(nèi)部原有的元數(shù)據(jù)管理缺乏打通，需要進一步拓展浓体。此外泡挺，目前集群的權(quán)限控制相對較弱的，需要進行強化命浴。
右邊展示了后續(xù)希望重點推進的幾個方面娄猫。首先是 StarRocks 物化視圖，之前進行了輕度測試生闲，因遇到一些問題媳溺，暫時未能顯著提升研發(fā)效率，未來希望重點完善這一方案碍讯。此外悬蔽，在 Flink 寫入 Paimon 時，常因 Compaction 問題導致顯著抖動捉兴，計劃采用異步 Compaction 機制蝎困，以保障整個實施鏈路的穩(wěn)定性录语。此外，諸如期望引入 Deletion Vector禾乘，顯著提升查詢效率澎埠。
目前，Paimon 實時中間層已應用于一些核心鏈路盖袭，未來希望將其推廣到更多數(shù)據(jù)場景失暂。還計劃與 DataWorks 和 MaxCompute 進行集成彼宠，這屬于生態(tài)系統(tǒng)建設(shè)的一部分鳄虱。在 OSS 方面，我們希望通過冷熱分層能力進一步降低成本凭峡。之前嘗試結(jié)合 Paimon 的 Tag 機制來實現(xiàn)這一目標拙已，但暫時還未找到理想的解決方案。
2摧冀、回顧
最后回顧一下餓了么整體實時數(shù)倉的建設(shè)歷程倍踪，大致可以分為幾個階段。首先是相對原始的開發(fā)階段索昂，這一階段主要建設(shè)實時的 DWD 層建车，各個應用層通過 Flink 任務各自生成自己的 ADS 數(shù)據(jù)。在這一過程中椒惨，ADS 層出現(xiàn)了大量數(shù)據(jù)一致性問題和重復開發(fā)的問題缤至。為了解決這些問題，我們構(gòu)建了實時的 CDM 層康谆，從而解決了共性問題领斥。然而，對于新增業(yè)務和場景的支持仍顯不足沃暗。因此月洛，我們引入了實時湖倉方案。雖然該方案目前仍在探索階段孽锥，但已經(jīng)在一些具體場景中實現(xiàn)了落地嚼黔。未來，我們希望在 Paimon 和 StarRocks 上進行更多的探索和應用惜辑。
