摘要：本文整理自阿里云高級產(chǎn)品解決方案架構(gòu)師王啟華（敖北）老師在 Flink Forward Asia 2023 中閉門會的分享炸裆。內(nèi)容分為以下四個部分：
- 業(yè)務(wù)需求變化推動架構(gòu)演進(jìn)
- 實時計算對于企業(yè)生產(chǎn)的意義
- 從技術(shù)架構(gòu)和技術(shù)場景來看發(fā)展和迭代
- 客戶做技術(shù)架構(gòu)的痛點导狡、邏輯和收益逾雄。
一、實時計算在大數(shù)據(jù)計算發(fā)展中的趨勢
阿里云計算平臺事業(yè)部在過去十年中，通過與百余家企業(yè)合作，積累了豐富的大數(shù)據(jù)應(yīng)用經(jīng)驗。這些企業(yè)在使用大數(shù)據(jù)產(chǎn)品京腥、搭建平臺以及更新產(chǎn)品架構(gòu)的過程中，推動了我們對不同類型企業(yè)在數(shù)字化轉(zhuǎn)型和數(shù)據(jù)架構(gòu)升級方面的理解溅蛉。然而公浪，近兩年來，一個非常明顯的趨勢是温艇，企業(yè)對實時計算的需求量迅猛增長因悲。下面堕汞，我將分享幾點感受：
- 大數(shù)據(jù)的普及與深度應(yīng)用：大數(shù)據(jù)技術(shù)已經(jīng)不再是新奇事物勺爱，而是深深融入企業(yè)的生產(chǎn)流程中。過去讯检，大數(shù)據(jù)主要用于生成報表和展示數(shù)據(jù)琐鲁，而現(xiàn)在，它已經(jīng)逐步滲透到實時業(yè)務(wù)的主鏈路中人灼，如物聯(lián)網(wǎng)围段、風(fēng)控、推薦系統(tǒng)和用戶畫像等領(lǐng)域投放。線上業(yè)務(wù)對大數(shù)據(jù)的時效性要求越來越高奈泪。
- 硬件發(fā)展與產(chǎn)品升級：如今，產(chǎn)品硬件發(fā)展迅速灸芳，不論是從 CPU 還是內(nèi)存的角度看涝桅，云上產(chǎn)品能力的更新?lián)Q代讓用戶覺得，通過產(chǎn)品升級來節(jié)省計算時間是非常劃算的選擇烙样。
- 市場競爭與高時效性需求：市場競爭的激烈使得許多企業(yè)在進(jìn)行實時決策時需要高時效性的數(shù)據(jù)冯遂。因此，許多客戶的業(yè)務(wù)負(fù)責(zé)人不再單純依賴歷史數(shù)據(jù)進(jìn)行分析和決策谒获，而是需要及時獲取實時數(shù)據(jù)并進(jìn)行分析蛤肌，以指導(dǎo)當(dāng)前的運(yùn)營活動。
- AI分析的應(yīng)用：通過利用歷史數(shù)據(jù)和當(dāng)前的數(shù)據(jù)進(jìn)行AI分析批狱，包括推理和預(yù)測等裸准，企業(yè)能夠更好地指導(dǎo)未來的決策和運(yùn)營。
伴隨著大數(shù)據(jù)技術(shù)的演進(jìn)赔硫，從離線計算到準(zhǔn)實時計算狼速，再到實時計算和AI計算，整個技術(shù)體系的發(fā)展促進(jìn)和推動這一趨勢的演進(jìn)。根據(jù)第三方機(jī)構(gòu)的調(diào)查向胡，2023 年 Gartner 和 IDC 的大數(shù)據(jù)市場的發(fā)展趨勢報告中恼蓬，實時計算在整體大數(shù)據(jù)的占比越來越高，其增量和速度遠(yuǎn)超平均水平僵芹。因此处硬，無論是從企業(yè)角度、客戶角度還是技術(shù)角度拇派，實時計算都已經(jīng)成為當(dāng)前發(fā)展的明確需求和顯著趨勢荷辕。
二、 實時計算對于企業(yè)生產(chǎn)的意義件豌。
在探討實時計算對企業(yè)生產(chǎn)的意義之前疮方，我們可以先舉一個例子：在傳統(tǒng)制造企業(yè)的生產(chǎn)模式中，從作坊式生產(chǎn)轉(zhuǎn)變?yōu)橐胂冗M(jìn)的流水線生產(chǎn)茧彤，這對企業(yè)來說是一個顯著的跨越式升級骡显。從企業(yè)管理的角度來看，無論是生產(chǎn)效率曾掂、生產(chǎn)質(zhì)量惫谤，還是企業(yè)形象，都有明顯的提升珠洗。而且這種轉(zhuǎn)變也帶來了人力成本的下降和員工技能的提升溜歪。通過這條流水線，再加上其他批量生產(chǎn)的元器件许蓖，就可以構(gòu)建整個企業(yè)的全鏈路生產(chǎn)視圖蝴猪。
目前，許多技術(shù)型互聯(lián)網(wǎng)公司已經(jīng)成功地將實時計算鏈路引入到他們的業(yè)務(wù)流程中膊爪，這類似于傳統(tǒng)制造企業(yè)引入了流水線自阱。它改變了原本通過數(shù)據(jù)倉庫、數(shù)據(jù)庫等組件構(gòu)成的傳統(tǒng)數(shù)據(jù)生產(chǎn)鏈路蚁飒。這樣的技術(shù)架構(gòu)升級动壤，不僅提升了企業(yè)的生產(chǎn)效率和管理能力，還使企業(yè)能夠在有限的時間內(nèi)挖掘出更多的數(shù)據(jù)價值淮逻，從而支持業(yè)務(wù)提效和創(chuàng)新琼懊。
上圖展示了一張實時計算及周邊大數(shù)據(jù)核心組件的通用架構(gòu)圖。從左到右爬早，分別是數(shù)據(jù)集成哼丈、數(shù)據(jù)處理和數(shù)據(jù)應(yīng)用。在很多企業(yè)中筛严，日志類數(shù)據(jù)和業(yè)務(wù)類數(shù)據(jù)通過集成工具導(dǎo)入到實時流水線或不同的數(shù)據(jù)倉庫中進(jìn)行計算和加工醉旦。生成的數(shù)據(jù)再應(yīng)用于線上業(yè)務(wù)或算法庫。中間過程涉及開發(fā)、優(yōu)化车胡、監(jiān)控檬输、治理、運(yùn)維和管理等環(huán)節(jié)匈棘。因此丧慈，在這樣的技術(shù)架構(gòu)下，企業(yè)在進(jìn)行升級時會產(chǎn)生許多需求主卫。下面我將介紹阿里云提供的大數(shù)據(jù)產(chǎn)品和產(chǎn)品組合是如何支撐這些需求的逃默。
三、阿里云飛天大數(shù)據(jù)產(chǎn)品系統(tǒng)架構(gòu)簇搅。
上圖展示了阿里云飛天大數(shù)據(jù)體系的產(chǎn)品大圖完域。我們從下往上看，不同業(yè)務(wù)的公司有不同類型的數(shù)據(jù)源瘩将，比如業(yè)務(wù)日志數(shù)據(jù)吟税、數(shù)據(jù)庫數(shù)據(jù)及 binlog 數(shù)據(jù)、開源大數(shù)據(jù)存儲的數(shù)據(jù)鸟蟹、IoT 設(shè)備等各種類型的業(yè)務(wù)數(shù)據(jù)庫乌妙。這些數(shù)據(jù)通過集成工具接入到數(shù)據(jù)計算和分析層使兔。計算和分析層的實時計算流水線會加速企業(yè)的數(shù)據(jù)處理建钥。
阿里云實時計算引擎 Flink 已經(jīng)成為業(yè)界實時流式計算的標(biāo)準(zhǔn)。它在產(chǎn)品能力和發(fā)展速度上都處于領(lǐng)先地位虐沥，特別是在阿里巴巴收購了 Flink 的母公司 Ververica 之后熊经，F(xiàn)link 在國內(nèi)的技術(shù)影響力達(dá)到了前所未有的高度。目前欲险，阿里云 Flink 主推 Serverless 模式镐依，不僅提升了用戶的易用性和便捷性，還在穩(wěn)定性和彈性方面提供了更強(qiáng)的支持天试。
此外槐壳，與實時計算組件配合的還有三個部分，分別是離線數(shù)倉喜每、實時數(shù)倉和數(shù)據(jù)開發(fā)治理平臺务唐。下面分別簡要介紹一下各個部分：
- 與實時計算配合的第一部分是離線數(shù)倉/湖倉部分。阿里云在這方面提供了兩類產(chǎn)品：
（1）全托管產(chǎn)品：以 MaxCompute 為代表带兜。MaxCompute 已有十幾年的歷史枫笛，為幾千家客戶提供離線計算服務(wù)，其穩(wěn)定性和整體能力已獲得良好口碑刚照。MaxCompute 能夠高效處理大規(guī)模數(shù)據(jù)刑巧，為企業(yè)提供可靠的離線計算解決方案。
（2）半托管產(chǎn)品：以 EMR（Elastic MapReduce）為代表。EMR 本質(zhì)上是一套開源產(chǎn)品體系的組合啊楚，它不僅包括常用的 HDFS 存儲和 YARN 調(diào)度吠冤，還提供了諸如 Hive、Spark等計算引擎恭理。此外咨演，EMR 還支持當(dāng)前流行的一些數(shù)據(jù)湖格式，如 Paimon蚯斯、Iceberg薄风、Hudi 和 Delta Lake 等，提供靈活的數(shù)據(jù)存儲和處理能力拍嵌。
2 . 圖右側(cè)的實時數(shù)倉部分有兩款產(chǎn)品：
（1）Hologres：Hologres 是一款 HSAP（Hybrid Serving and Analytical Processing）產(chǎn)品遭赂，與 Flink 一起經(jīng)歷了多年的阿里雙十一大促考驗。它不僅可以進(jìn)行 OLAP（在線分析處理）横辆，還支持 Serving 功能撇他，即不僅可以做數(shù)據(jù)分析，還可以提供 KV（鍵值）數(shù)據(jù)查詢能力狈蚤。
（2）EMR StarRocks：EMR StarRocks 是一款全托管的實時數(shù)倉產(chǎn)品困肩，專為公有云客戶提供服務(wù)。其快速發(fā)展得益于阿里云計算平臺研發(fā)團(tuán)隊的持續(xù)投入以及開源社區(qū)的活躍度脆侮。
3 . 最后介紹的是負(fù)責(zé)數(shù)據(jù)開發(fā)與治理的平臺型產(chǎn)品 Dataworks锌畸，負(fù)責(zé)數(shù)據(jù)集成、數(shù)據(jù)開發(fā)靖避、任務(wù)調(diào)度潭枣、數(shù)據(jù)治理、數(shù)據(jù)血緣幻捏、數(shù)據(jù)服務(wù)等工作盆犁。它可以跨產(chǎn)品、跨地域篡九、跨平臺地將這些計算能力串聯(lián)在一起谐岁，不僅能夠完成不同類型的大數(shù)據(jù)任務(wù)的串聯(lián)和調(diào)度，還能夠?qū)?AI 任務(wù)融入到工作流中榛臼，進(jìn)一步提升數(shù)據(jù)處理的智能化和自動化水平伊佃。
四、實時計算的三個典型的技術(shù)場景
下面將圍繞實時計算讽坏，介紹阿里云提供的這些大數(shù)據(jù)產(chǎn)品及組合在數(shù)據(jù)集成锭魔、實時數(shù)倉和離線數(shù)倉三個主要技術(shù)場景下，如何提升大數(shù)據(jù)處理能力路呜，并分析以往架構(gòu)和現(xiàn)有架構(gòu)的特點迷捧、區(qū)別以及優(yōu)劣勢织咧，探討哪一個更符合未來發(fā)展的趨勢。
1. 技術(shù)場景一：Flink實時計算改變傳統(tǒng)數(shù)據(jù)集成的方式漠秋。
傳統(tǒng)數(shù)據(jù)集成通常包括從業(yè)務(wù)數(shù)據(jù)庫到數(shù)據(jù)倉庫的數(shù)據(jù)遷移過程笙蒙，主要涉及全量數(shù)據(jù)同步和增量數(shù)據(jù)同步兩條鏈路。全量數(shù)據(jù)同步通常使用工具如 DataX 或 Sqoop庆锦，而增量數(shù)據(jù)同步則通過 Canal 來實現(xiàn)捅位。數(shù)據(jù)同步完成后，還需要在數(shù)據(jù)倉庫中將存量表和增量表合并搂抒，以離線任務(wù)的方式生成一個全量表艇搀，供下游任務(wù)消費(fèi)和使用。這種傳統(tǒng)方法存在以下幾個明顯的缺點：
（1）鏈路割裂：需要兩條鏈路求晶，一條是全量同步鏈路焰雕，另一條是增量同步鏈路。
（2）時效性較差：除了數(shù)據(jù)導(dǎo)入的時間芳杏，還需要在數(shù)倉中進(jìn)行離線調(diào)度以完成數(shù)據(jù)合并矩屁，導(dǎo)致端到端的時間較長。
（3）組件繁多：不僅涉及業(yè)務(wù)庫和數(shù)倉爵赵，還需要使用不同的集成工具吝秕，鏈路中維護(hù)的組件非常多，增加了系統(tǒng)的復(fù)雜性空幻。
在介紹完傳統(tǒng)數(shù)據(jù)集成之后烁峭，我們來看看新一代的一體化數(shù)據(jù)集成方案。例如氛悬，從 MySQL 到 Hive 的整個集成過程则剃，可以實現(xiàn)一鍵式集成耘柱。這相當(dāng)于使用一個產(chǎn)品來完成以往的離線和實時數(shù)據(jù)集成如捅，其主要依賴于流批一體化的 Flink CDC 技術(shù)。
這種新方案的主要功能是通過一個作業(yè)（job）完成全量數(shù)據(jù)集成调煎，利用多個子任務(wù)的并發(fā)執(zhí)行镜遣，實現(xiàn)全量數(shù)據(jù)的快速導(dǎo)入。全量數(shù)據(jù)導(dǎo)入完成后士袄，系統(tǒng)通過 Hybrid Source 能力自動切換到增量的 Binlog Source悲关，實現(xiàn)無縫對接。在這個過程中娄柳，通過無鎖一致性快照來確保數(shù)據(jù)的一致性寓辱。
這個方案有以下幾個優(yōu)點：
（1）架構(gòu)簡約：只有一個全托管產(chǎn)品，具備易運(yùn)維和彈性的能力赤拒。對于客戶來說秫筏，通過云上控制臺進(jìn)行管理诱鞠，容易簡單。
（2）開發(fā)簡單：只需一條 SQL 語句这敬，就能自動將全量數(shù)據(jù)轉(zhuǎn)換成增量數(shù)據(jù)航夺，對數(shù)據(jù)開發(fā)更友好。
（3）運(yùn)維簡便：無論能力如何崔涂，只需進(jìn)行相應(yīng)的資源和參數(shù)配置阳掐，配置好前后端數(shù)據(jù)源，系統(tǒng)就會自動完成任務(wù)冷蚂。
2. 技術(shù)場景二：新一代實時數(shù)倉 Flink + Hologres
傳統(tǒng)的實時數(shù)倉架構(gòu)至少包括四個組件：Flink缭保、Kafka/MQ、維度庫或字典表的存儲蝙茶、以及應(yīng)用層（例如提供 OLAP 和 Serving 能力的庫）涮俄。其工作流程如下：
（1）數(shù)據(jù)流入：業(yè)務(wù)日志或數(shù)據(jù)流入后，先通過 Flink 進(jìn)入 Kafka尸闸，形成源表層彻亲。
（2）維度加載：接下來在 DW 層，通過 Flink 任務(wù)加載維度庫吮廉，進(jìn)行數(shù)據(jù)的整合和處理苞尝。
（3）數(shù)據(jù)加工聚合：Flink 繼續(xù)加載 kafka topic 中經(jīng)過處理的數(shù)據(jù)，進(jìn)行加工或者聚合宦芦，并將數(shù)據(jù)存儲到應(yīng)用層宙址。
（4）應(yīng)用層處理：根據(jù)需求，數(shù)據(jù)可以回歸到業(yè)務(wù)庫调卑。如果需要進(jìn)行交互式分析抡砂，數(shù)據(jù)會被加載到適合 OLAP 的數(shù)據(jù)庫中；如果需要進(jìn)行點查服務(wù)恬涧，則會加載到相應(yīng)的KV存儲注益，比如 HBase 或 Redis 數(shù)據(jù)庫中。
這種架構(gòu)廣泛應(yīng)用于傳統(tǒng)的實時數(shù)倉場景中溯捆，以滿足業(yè)務(wù)時效性和不同類型的數(shù)據(jù)服務(wù)需求丑搔。該方案具有以下三個特點：
（1）組件多、架構(gòu)復(fù)雜：如前所述提揍，至少需要四個組件（Flink啤月、Kafka、維度庫或字典表存儲劳跃、應(yīng)用層數(shù)據(jù)產(chǎn)品）谎仲。如果同時需要 Ad-hoc 或 KV 存儲，那么至少需要五個組件刨仑，運(yùn)維難度增加郑诺。
（2）中間結(jié)果查詢難：由于 Kafka 按照時間順序存儲數(shù)據(jù)绞呈，中間結(jié)果的查詢和調(diào)試變得困難。在需要進(jìn)行調(diào)試或數(shù)據(jù)校對時间景，往往需要將 Kafka 中的數(shù)據(jù)拉到 OLAP 庫中進(jìn)一步分析佃声，我們在實際工作中經(jīng)常遇到這樣的情況，即耗時費(fèi)力倘要，又增加了問題捕捉的難度圾亏。
（3）資源使用不靈活：實時數(shù)倉的各個階段和層級有明確的任務(wù)劃分。在業(yè)務(wù)低峰期封拧，某一層的資源使用率下降后志鹃，想要調(diào)整該層資源比較麻煩，需要對應(yīng)調(diào)整業(yè)務(wù)邏輯泽西，這通常是一個復(fù)雜且需要多次驗證的工作曹铃，因為邏輯的調(diào)整容易對數(shù)據(jù)分析結(jié)果產(chǎn)生影響。
這種傳統(tǒng)方案雖然能滿足業(yè)務(wù)需求捧杉，但在運(yùn)維效率和資源管理上存在一定的挑戰(zhàn)陕见。
針對這三個特點，下面介紹新一代實時數(shù)倉產(chǎn)品組合解決方案 Flink+Hologres味抖。為了大家便于理解新架構(gòu)评甜，先為大家介紹一下 Hologres 這個產(chǎn)品及特點：
（1）寫入即可見：由于 Hologres 領(lǐng)先的架構(gòu)設(shè)計，它可以做到寫入即可見仔涩，這一點可以達(dá)到 kafka 的實效性忍坷，但有別于其他 OLAP 引擎；
（2）Binlog 支持：Hologres 擁有自己的 Binlog熔脂，F(xiàn)link 可以訂閱 Binlog 進(jìn)行下一步的自動加工和分析任務(wù)佩研。這一點也是在 OLAP 產(chǎn)品中，區(qū)別于其他實時 OLAP 的顯著能力霞揉。
（2）行存與列存：Hologres 支持行存儲和列存儲旬薯。OLAP 分析通常使用列存儲，可以快速進(jìn)行實時分析零聚；同時袍暴，Hologres 也支持行存儲和行列共存，行存儲主要支持 KV 查詢隶症，非常便捷高效。因此岗宣，維度庫可以直接放在 Hologres 的行存表中蚂会，不需要其他存儲介質(zhì)。
（3）高性能實時 Serving 服務(wù)：即 Hologres 具有高性能的實時點查能力耗式，基于自身的行存功能胁住，可以進(jìn)行高 QPS 的 KV 查詢能力趁猴。
（4）強(qiáng)隔離性：Hologres 可以通過主從實例模式或者 Warehouse 模式實現(xiàn)寫入和讀取的資源隔離，也可以實現(xiàn)不同業(yè)務(wù)不同優(yōu)先級的查詢資源隔離彪见，避免相互干擾儡司。這在實時數(shù)倉中也非常關(guān)鍵，因為不同層的寫入操作可能會導(dǎo)致查詢速度變慢余指。
（5）存算分離：Hologres 具備存算分離的能力捕犬，方便運(yùn)維，能夠根據(jù)需求靈活擴(kuò)展或縮減計算資源和存儲資源酵镜。
介紹完 Hologres 的產(chǎn)品特點之后碉碉，我們來看一下新一代實時數(shù)倉的方案（如下圖）。從左到右看淮韭，業(yè)務(wù)日志進(jìn)入后通過 Flink 集成到 Hologres中 垢粮，此時除了源表外，還會存在維度表靠粪，這些維度表直接加載到 Flink 中蜡吧。Flink 在此過程中進(jìn)行數(shù)據(jù)打?qū)捄喜ⅲ缓髠鬟f到下一層占键。
在下一層斩跌，F(xiàn)link 任務(wù)可以訂閱 Hologres 對應(yīng)表的 Binlog，進(jìn)行進(jìn)一步的業(yè)務(wù)邏輯處理捞慌，并將結(jié)果存儲到 Hologres 的 ADS 層表中耀鸦。在 ADS 層對外提供服務(wù)時，只需要 Hologres 即可啸澡，因為它既具備 OLAP 能力袖订，也具備 KV 查詢能力，無需其他產(chǎn)品嗅虏。此外洛姑，Hologres 還提供交互式分析能力，如果在數(shù)據(jù)處理過程中需要對 ODS皮服、DWD楞艾、DWS 層的數(shù)據(jù)進(jìn)行查驗，可以隨時通過 SQL 查詢對應(yīng)表中的結(jié)構(gòu)化數(shù)據(jù)龄广，從而輕松完成中間的調(diào)優(yōu)和調(diào)試（ Debug ）硫眯。
所以總結(jié)下來，新一代實時數(shù)倉方案的優(yōu)勢如下：
-
架構(gòu)簡約易運(yùn)維：
（1）少量產(chǎn)品依賴：整個方案主要依賴 Flink 和 Hologres 這兩個產(chǎn)品择同，極大簡化了系統(tǒng)架構(gòu)两入。
（2）全托管易運(yùn)維：Flink 和 Hologres 均為全托管服務(wù)，易于運(yùn)維且具有良好的彈性擴(kuò)展能力敲才。
-
中間結(jié)果方便查詢：
（1）查詢便捷：數(shù)倉中間層數(shù)據(jù)以結(jié)構(gòu)化形式存在 Hologres 中裹纳，方便查詢沧奴。
（2）快速更新修改：除了查詢外闯团，還可以快速更新和修改數(shù)據(jù)偏形，提升數(shù)據(jù)處理的靈活性谎柄。
-
數(shù)據(jù)應(yīng)用層一體化：
（1）統(tǒng)一服務(wù)能力：Hologres 提供 ADS 層所有的 OLAP 和 serving 能力，減少了面向應(yīng)用的繁冗組件朋鞍。
（2）簡化數(shù)據(jù)服務(wù)：通過 Hologres 一體化的數(shù)據(jù)服務(wù)已添，減少了系統(tǒng)復(fù)雜性，提升了數(shù)據(jù)服務(wù)的效率番舆。
-
資源使用靈活：
（1）靈活的數(shù)據(jù)處理：使用Hologres后酝碳，不需要固定各層結(jié)構(gòu)，一個臨時任務(wù)可以直接從 ODS 層抽取數(shù)據(jù)恨狈，迅速形成 ADS 層數(shù)據(jù)疏哗。
（2）快速分析：對于測試、臨時任務(wù)或新業(yè)務(wù)嘗試禾怠，可以快速進(jìn)行數(shù)據(jù)分析返奉，只需根據(jù)業(yè)務(wù)需求靈活調(diào)整。
（3）按需存儲分配：存儲可以根據(jù)業(yè)務(wù)評估按需分配吗氏，提升資源利用效率芽偏。
3. 技術(shù)場景三：Flink+Paimon 流式湖倉，讓傳統(tǒng)離線的數(shù)倉進(jìn)行加速和提效弦讽。
在企業(yè)中進(jìn)行實時鏈路計算時污尉，通常會設(shè)置一條鏈路用于離線數(shù)倉。離線計算在這個場景中有兩個主要作用：
（1）數(shù)據(jù)校驗和更正：離線計算定期處理 Flink 傳遞過來的數(shù)據(jù)往产，用于對數(shù)據(jù)進(jìn)行校驗和更正被碗。
（2）周期性統(tǒng)計和分析：離線計算根據(jù)業(yè)務(wù)需求，批量處理更長時間周期的統(tǒng)計和分析任務(wù)仿村，比如月度锐朴、季度和年度的報表。
業(yè)務(wù)日志和 Binlog 通過 Flink 進(jìn)行加工后蔼囊，寫入離線存儲焚志，隨即進(jìn)入離線數(shù)倉的加工流程。這個流程從貼源層（ODS層）到數(shù)據(jù)倉庫明細(xì)層（DWD層）再到數(shù)據(jù)服務(wù)層（ADS層）畏鼓，每一層之間通過定時任務(wù)進(jìn)行逐層加工酱酬。每一層計算的結(jié)果可以通過 Hive、Spark滴肿、Trino 等引擎進(jìn)行查詢或更新岳悟。
該方案有明顯的幾個特點：
任務(wù)時效性差：每一層定時任務(wù)的調(diào)度都需要一批批計算，ODS 層算完后才可以計算 DWD 層泼差，如果有較多的表和調(diào)度任務(wù)贵少，根據(jù)業(yè)務(wù)邏輯會產(chǎn)生比較復(fù)雜的依賴關(guān)系，那么這些調(diào)度任務(wù)需要估算比較準(zhǔn)確的完成時間以及鏈路關(guān)系堆缘，才能保證在要求的時間點產(chǎn)出結(jié)果滔灶。整個過程都是小時級或天級；
技術(shù)棧差異大：在實際大數(shù)據(jù)團(tuán)隊管理時吼肥，實時業(yè)務(wù)和離線業(yè)務(wù)會被分為兩組录平，實時業(yè)務(wù)在實時引擎上做，如果做校對或更正還需要離線業(yè)務(wù)團(tuán)隊做配合缀皱，或者掌握一些離線技術(shù)棧斗这，對開發(fā)同學(xué)不是很友好，會花費(fèi)較大精力做開發(fā)運(yùn)維方面的工作以及兩個團(tuán)隊間的協(xié)調(diào)啤斗；
數(shù)據(jù)更新不便捷：以往 Hive表箭、Spark 等存儲方式都是 Insert、Overwrite 覆寫方式來完成更新钮莲，新數(shù)據(jù)得到后免钻，與老數(shù)據(jù)進(jìn)行變更合并；
離線實時數(shù)據(jù)對齊難：實時數(shù)據(jù)按時間流動崔拥，很難找到一個時間點與離線數(shù)據(jù)完全對齊极舔。
針對以上方案的特點，我們一起看一下 Flink+Paimon 流式數(shù)倉的方案是否可以解決以往的痛點链瓦。為了讓大家更好的理解拆魏，先簡要介紹一下 Paimon。
Paimon 是一種流批一體的湖存儲格式慈俯，是一個輕量級的產(chǎn)品渤刃，可以部署在 OSS 或 HDFS 上。
Paimon 的產(chǎn)品特點：
（1）區(qū)別于 Iceberg/Hudi/Delta Lake 這三個更偏向于批處理的湖格式肥卡， Paimon 是流處理演變而來的湖格式溪掀，與 Flink 是統(tǒng)一的 SQL 和 API，使用統(tǒng)一的 Flink SQL 可以直接處理湖中的數(shù)據(jù)步鉴；
（2）支持 Upsert揪胃、Delete ；
（3）可以輕量級構(gòu)建在 HDFS/OSS 上氛琢，對于 Hadoop喊递、EMR 用戶更友好，不需要大幅度改變和調(diào)整技術(shù)架構(gòu)阳似，只需要在存儲上輕量化部署就可以使用該層能力骚勘；
（4） Paimon 有 Changelog，F(xiàn)link 可以訂閱 Changelog 的變化，Changelog 的變化可以自動將上游的變化通過 Flink 任務(wù)傳給下游俏讹；
（5）支持預(yù)計算当宴，降低存儲成本與下游計算壓力；
（6）支持 Time Travel泽疆，可以在回溯歷史版本中找到某一個節(jié)點的狀態(tài)户矢；
（7）支持表結(jié)構(gòu)變更 Schema Evolution。
了解了Paimon后殉疼，我們再來看 Flink+Paimon 新方案梯浪，從左到右，業(yè)務(wù)日志和 Binlog 通過 Flink 集成后進(jìn)入 Paimon 中瓢娜，每一層可以通過訂閱 Binlog 進(jìn)行處理挂洛，逐層加工后最后形成 ADS 層，再通過 EMR 開源引擎或阿里云自研的引擎等進(jìn)行查詢和分析眠砾。
該方案的優(yōu)勢是：
（1）準(zhǔn)實時任務(wù)效率提高虏劲，除了使用 Flink 能力、有自動 Changelog 能力外荠藤，可以通過流式任務(wù)將湖的任務(wù)串聯(lián)伙单；Paimon Changelog 與 Flink 的 Checkpoint 相關(guān)，F(xiàn)link 的 Checkpoint 可以根據(jù)業(yè)務(wù)需要來設(shè)置間隔哈肖，兩個 Checkpoint 之間的變化會產(chǎn)生一個 Changelog吻育，會把這次變更傳給下游，下游得到變化后進(jìn)行進(jìn)一步的處理加工淤井；
（2）數(shù)據(jù)更新與訂正的效率高布疼，Paimon 每層支持更新和訂正；
（3）開發(fā)模型統(tǒng)一币狠，整體流程使用一套 Flink SQL/Table API 即可完成游两；
（4）數(shù)據(jù)合并預(yù)處理，Paimon 支持很多預(yù)計算操作例如去重漩绵、部分更新贱案、預(yù)聚合等，減少了 Flink 中復(fù)雜的業(yè)務(wù)邏輯止吐；
（5）第五多引擎接入宝踪，生態(tài)上支持很多常用的引擎，更開放的生態(tài)帶來對現(xiàn)有大數(shù)據(jù)架構(gòu)改造的成本很低碍扔，可以將以往偏離線數(shù)據(jù)的處理能力以流方式進(jìn)行整體改造瘩燥。
五、客戶案例
在介紹完產(chǎn)品體系和三個主要技術(shù)場景之后不同，下面介紹兩個客戶案例厉膀。
1. 某游戲?qū)崟r數(shù)倉架構(gòu)的演進(jìn)溶耘。
該客戶是全球 Top 20 的游戲公司，運(yùn)營很多游戲服鹅，每天處理的實時數(shù)據(jù)達(dá)到 pb 級凳兵。原有技術(shù)架構(gòu)的痛點是 OLAP 組件很多，每個 OLAP 都有自己的特點菱魔，例如 Clickhouse 擅長大寬表留荔、ADB 擅長較小規(guī)模數(shù)據(jù)量分析等吟孙，離線數(shù)據(jù)的查詢基于傳統(tǒng)的 Impala 方式等澜倦。整個架構(gòu)流程是：數(shù)據(jù)庫及日志數(shù)據(jù)進(jìn)入 Kafka，F(xiàn)link 消費(fèi) Kafka 中 topic 數(shù)據(jù)進(jìn)行逐層的加工和分析杰妓。同時過程中 Flink 還會把數(shù)據(jù)寫入離線鏈路藻治，離線引擎做數(shù)據(jù)的校驗和備份等。如果過程中出現(xiàn)問題巷挥，可以使用 Impala 做離線數(shù)據(jù)加速查詢桩卵，用以排查問題和校驗分析。實時鏈路最后將數(shù)據(jù)寫入 Clickhouse 中倍宾，而為了保證實時鏈路的穩(wěn)定性雏节，離線數(shù)據(jù)最后加工以及與實時數(shù)據(jù)的比對采用了另外一個 OLAP 引擎 ADB。
為了解決以往架構(gòu)的痛點高职，客戶選擇了升級新架構(gòu)的方案：實時鏈路改造成了 Flink+Hologres 實時數(shù)倉模式钩乍，并引入了 MaxCompute，借助 Hologres+MaxCompute+dataworks 共享存儲的能力怔锌，形成了實時離線一體化的能力寥粹。
這里先解釋一下實時離線一體化，從三個層面來簡要說明：第一個層面即數(shù)據(jù)開發(fā)層埃元，通過 Dataworks 統(tǒng)一 IDE 入口涝涤，可以完成 Hologres 和 MaxCompute 的任務(wù)編寫，并可以通過 Dataworks 形成同一個調(diào)度工作流岛杀，完成離線和實時任務(wù)的混合編排阔拳；第二個層面即計算層的聯(lián)邦計算，由于 Hologres 和 MaxCompute 兩個引擎的元數(shù)據(jù)可以打通类嗤，用戶很容易可以通過內(nèi)外表的形式來進(jìn)行聯(lián)合計算分析糊肠；第三個層面即存儲層，由于兩個引擎都是基于阿里云 Pangu 體系建立土浸，所以 Hologres 可以便捷的為 MaxCompute 中的離線數(shù)據(jù)做加速罪针，而且兩個引擎之間傳遞數(shù)據(jù)速度非常快黄伊，提升了效率的同時也節(jié)省了大量數(shù)據(jù)集成的資源泪酱；
在上面介紹的架構(gòu)升級方案上，客戶將原來的 ADB、Clickhouse墓阀、Impala 全部替代毡惜，因為 Hologres 強(qiáng)大的計算和存儲能力，使得以往的離線數(shù)倉分層改變斯撮，基本 ADS 層全部存儲的 Hologres 中经伙。而且 Hologres 可以做 MaxCompute 的離線加速，這些能力讓客戶決策可以縮減掉離線數(shù)倉中冗余的部分勿锅，使得離線部分更精煉和易于管理帕膜。
這些先進(jìn)的理念和架構(gòu)實現(xiàn)幫助客戶在完成架構(gòu)升級之后，有幾個明顯的體感：
（1）架構(gòu)上比較統(tǒng)一溢十，不需要維護(hù)多個組件垮刹，節(jié)省人力的同時，也不需要做很多組件聯(lián)合擴(kuò)縮容的規(guī)劃张弛；
（2）實時鏈路的可用性更強(qiáng)了荒典，在過程查詢和問題發(fā)現(xiàn)方面非常便捷，而且在支持創(chuàng)新業(yè)務(wù)時吞鸭，也可以在不改變 source 邏輯的情況下寺董，在實時數(shù)倉中快速形成臨時的實時分析任務(wù)，支持臨時決策刻剥。實時鏈路中個別場景的性能也有大幅提升遮咖，比如CK的Join查詢可以提升一個數(shù)量級以上；
（3）實時離線一體化的能力透敌，使得整體數(shù)據(jù)分層和治理更科學(xué)盯滚，任務(wù)編排統(tǒng)一化以及治理能力的提升，都讓客戶有能力在支持好現(xiàn)在和未來業(yè)務(wù)的同時酗电，掌握了規(guī)劃和控制成本的手段魄藕；
2. 某出行客戶離線數(shù)倉架構(gòu)演進(jìn)。
該客戶是一家國內(nèi)知名的出行企業(yè)撵术，月活躍用戶達(dá)到千萬級別背率，每日處理的數(shù)據(jù)量非常龐大，實時計算需求遠(yuǎn)高于離線計算需求嫩与∏拮耍客戶的業(yè)務(wù)痛點如下：
（1）技術(shù)線分離：采用典型的 Lambda 架構(gòu)，實時和離線計算分離划滋，導(dǎo)致兩條線之間存在復(fù)雜的業(yè)務(wù)邏輯交互饵筑；
（2）高存儲成本：實時和離線各存儲一份數(shù)據(jù)。對于這個客戶來說業(yè)務(wù)行為日志處理很重要处坪，因為實時和準(zhǔn)實時的處理都走實時計算的引擎和存儲根资，故導(dǎo)致實時存儲的成本占比較大架专；
（3）流處理中間數(shù)據(jù)查詢困難：實時計算過程中，查詢中間數(shù)據(jù)較為困難玄帕。
客戶原有架構(gòu)的實時線采用 Flink + Kafka部脚，定期將數(shù)據(jù) Dump 到離線 Hive 中，進(jìn)行備份和進(jìn)一步的離線加工分析裤纹。在離線鏈路中還引入了 Presto委刘，用于查詢和部分準(zhǔn)實時業(yè)務(wù)，處理完成后供應(yīng)用使用鹰椒。
新架構(gòu)通過 Flink + Paimon 將準(zhǔn)實時鏈路和離線鏈路融合在一起锡移，形成一套完整的模式。這里的準(zhǔn)實時任務(wù)要求數(shù)據(jù)處理時限在分鐘級吹零，適用于需要人為判斷的任務(wù)罩抗，例如報表生成或分鐘級的應(yīng)用處理邏輯。而實時任務(wù)通常要求秒級或毫秒級的處理時限灿椅，數(shù)據(jù)結(jié)果由機(jī)器或程序判斷，例如風(fēng)控和實時推薦等業(yè)務(wù)钞支。
上述技術(shù)場景三中茫蛹，F(xiàn)link + Paimon 的使用使得可以在數(shù)據(jù)處理中通過 Flink SQL 進(jìn)行查詢。同時烁挟，為了應(yīng)對大量的離線數(shù)據(jù)處理需求和臨時任務(wù)需求婴洼，還引入了 StarRocks。StarRocks 可以直接查詢 Paimon 表撼嗓，性能比 Presto/Impala 高出兩倍以上柬采。
這個改造之后，對于客戶的影響比較明顯：第一且警，純實時鏈路的業(yè)務(wù)復(fù)雜度明顯降低粉捻，實時和離線交互的任務(wù)減少 40%+；第二斑芜，每年節(jié)省出 65% 以上的 Kafka 存儲成本肩刃，而且準(zhǔn)實時的數(shù)據(jù)不需要存兩份，只需要存 HDFS 一份杏头；由于 Kafka 使用價格較高的 SSD 存儲介質(zhì)盈包，成本較高，換成 HDFS 的 HDD 后醇王，每年綜合節(jié)省近千萬成本呢燥；
通過圍繞實時計算產(chǎn)品 Flink，我們一起探討和梳理了系統(tǒng)架構(gòu)和技術(shù)場景寓娩，并在客戶案例中提出了對架構(gòu)升級的思考叛氨。希望這些經(jīng)驗?zāi)軐δ湍诘钠髽I(yè)有所幫助滥朱，同時期待 Flink 的新功能和特性能幫助更多企業(yè)釋放數(shù)據(jù)業(yè)務(wù)的潛能。
