摘要：本文整理自阿里云高級產品解決方案架構師王啟華（敖北）老師在 Flink Forward Asia 2023 中閉門會的分享。內容分為以下四個部分：

1. 業務需求變化推動架構演進
2. 實時計算對于企業生產的意義
3. 從技術架構和技術場景來看發展和迭代
4. 客戶做技術架構的痛點、邏輯和收益。

一、實時計算在大數據計算發展中的趨勢

阿里云計算平臺事業部在過去十年中，通過與百余家企業合作，積累了豐富的大數據應用經驗。這些企業在使用大數據產品、搭建平臺以及更新產品架構的過程中，推動了我們對不同類型企業在數字化轉型和數據架構升級方面的理解。然而，近兩年來，一個非常明顯的趨勢是，企業對實時計算的需求量迅猛增長。下面，我將分享幾點感受：

1. 大數據的普及與深度應用：大數據技術已經不再是新奇事物，而是深深融入企業的生產流程中。過去，大數據主要用于生成報表和展示數據，而現在，它已經逐步滲透到實時業務的主鏈路中，如物聯網、風控、推薦系統和用戶畫像等領域。線上業務對大數據的時效性要求越來越高。
2. 硬件發展與產品升級：如今，產品硬件發展迅速，不論是從 CPU 還是內存的角度看，云上產品能力的更新換代讓用戶覺得，通過產品升級來節省計算時間是非常劃算的選擇。
3. 市場競爭與高時效性需求：市場競爭的激烈使得許多企業在進行實時決策時需要高時效性的數據。因此，許多客戶的業務負責人不再單純依賴歷史數據進行分析和決策，而是需要及時獲取實時數據并進行分析，以指導當前的運營活動。
4. AI分析的應用：通過利用歷史數據和當前的數據進行AI分析，包括推理和預測等，企業能夠更好地指導未來的決策和運營。

伴隨著大數據技術的演進，從離線計算到準實時計算，再到實時計算和AI計算，整個技術體系的發展促進和推動這一趨勢的演進。根據第三方機構的調查，2023 年 Gartner 和 IDC 的大數據市場的發展趨勢報告中，實時計算在整體大數據的占比越來越高，其增量和速度遠超平均水平。因此，無論是從企業角度、客戶角度還是技術角度，實時計算都已經成為當前發展的明確需求和顯著趨勢。

二、 實時計算對于企業生產的意義。

在探討實時計算對企業生產的意義之前，我們可以先舉一個例子：在傳統制造企業的生產模式中，從作坊式生產轉變為引入先進的流水線生產，這對企業來說是一個顯著的跨越式升級。從企業管理的角度來看，無論是生產效率、生產質量，還是企業形象，都有明顯的提升。而且這種轉變也帶來了人力成本的下降和員工技能的提升。通過這條流水線，再加上其他批量生產的元器件，就可以構建整個企業的全鏈路生產視圖。

目前，許多技術型互聯網公司已經成功地將實時計算鏈路引入到他們的業務流程中，這類似于傳統制造企業引入了流水線。它改變了原本通過數據倉庫、數據庫等組件構成的傳統數據生產鏈路。這樣的技術架構升級，不僅提升了企業的生產效率和管理能力，還使企業能夠在有限的時間內挖掘出更多的數據價值，從而支持業務提效和創新。

上圖展示了一張實時計算及周邊大數據核心組件的通用架構圖。從左到右，分別是數據集成、數據處理和數據應用。在很多企業中，日志類數據和業務類數據通過集成工具導入到實時流水線或不同的數據倉庫中進行計算和加工。生成的數據再應用于線上業務或算法庫。中間過程涉及開發、優化、監控、治理、運維和管理等環節。因此，在這樣的技術架構下，企業在進行升級時會產生許多需求。下面我將介紹阿里云提供的大數據產品和產品組合是如何支撐這些需求的。

三、阿里云飛天大數據產品系統架構。

上圖展示了阿里云飛天大數據體系的產品大圖。我們從下往上看，不同業務的公司有不同類型的數據源，比如業務日志數據、數據庫數據及 binlog 數據、開源大數據存儲的數據、IoT 設備等各種類型的業務數據庫。這些數據通過集成工具接入到數據計算和分析層。計算和分析層的實時計算流水線會加速企業的數據處理。

阿里云實時計算引擎 Flink 已經成為業界實時流式計算的標準。它在產品能力和發展速度上都處于領先地位，特別是在阿里巴巴收購了 Flink 的母公司 Ververica 之后，Flink 在國內的技術影響力達到了前所未有的高度。目前，阿里云 Flink 主推 Serverless 模式，不僅提升了用戶的易用性和便捷性，還在穩定性和彈性方面提供了更強的支持。

此外，與實時計算組件配合的還有三個部分，分別是離線數倉、實時數倉和數據開發治理平臺。下面分別簡要介紹一下各個部分：

1. 與實時計算配合的第一部分是離線數倉/湖倉部分。阿里云在這方面提供了兩類產品：

（1）全托管產品：以 MaxCompute 為代表。MaxCompute 已有十幾年的歷史，為幾千家客戶提供離線計算服務，其穩定性和整體能力已獲得良好口碑。MaxCompute 能夠高效處理大規模數據，為企業提供可靠的離線計算解決方案。

（2）半托管產品：以 EMR（Elastic MapReduce）為代表。EMR 本質上是一套開源產品體系的組合，它不僅包括常用的 HDFS 存儲和 YARN 調度，還提供了諸如 Hive、Spark等計算引擎。此外，EMR 還支持當前流行的一些數據湖格式，如 Paimon、Iceberg、Hudi 和 Delta Lake 等，提供靈活的數據存儲和處理能力。

2 . 圖右側的實時數倉部分有兩款產品：

（1）Hologres：Hologres 是一款 HSAP（Hybrid Serving and Analytical Processing）產品，與 Flink 一起經歷了多年的阿里雙十一大促考驗。它不僅可以進行 OLAP（在線分析處理），還支持 Serving 功能，即不僅可以做數據分析，還可以提供 KV（鍵值）數據查詢能力。

（2）EMR StarRocks：EMR StarRocks 是一款全托管的實時數倉產品，專為公有云客戶提供服務。其快速發展得益于阿里云計算平臺研發團隊的持續投入以及開源社區的活躍度。

3 . 最后介紹的是負責數據開發與治理的平臺型產品 Dataworks，負責數據集成、數據開發、任務調度、數據治理、數據血緣、數據服務等工作。它可以跨產品、跨地域、跨平臺地將這些計算能力串聯在一起，不僅能夠完成不同類型的大數據任務的串聯和調度，還能夠將 AI 任務融入到工作流中，進一步提升數據處理的智能化和自動化水平。

四、實時計算的三個典型的技術場景

下面將圍繞實時計算，介紹阿里云提供的這些大數據產品及組合在數據集成、實時數倉和離線數倉三個主要技術場景下，如何提升大數據處理能力，并分析以往架構和現有架構的特點、區別以及優劣勢，探討哪一個更符合未來發展的趨勢。

1. 技術場景一：Flink實時計算改變傳統數據集成的方式。

傳統數據集成通常包括從業務數據庫到數據倉庫的數據遷移過程，主要涉及全量數據同步和增量數據同步兩條鏈路。全量數據同步通常使用工具如 DataX 或 Sqoop，而增量數據同步則通過 Canal 來實現。數據同步完成后，還需要在數據倉庫中將存量表和增量表合并，以離線任務的方式生成一個全量表，供下游任務消費和使用。這種傳統方法存在以下幾個明顯的缺點：

（1）鏈路割裂：需要兩條鏈路，一條是全量同步鏈路，另一條是增量同步鏈路。

（2）時效性較差：除了數據導入的時間，還需要在數倉中進行離線調度以完成數據合并，導致端到端的時間較長。

（3）組件繁多：不僅涉及業務庫和數倉，還需要使用不同的集成工具，鏈路中維護的組件非常多，增加了系統的復雜性。

在介紹完傳統數據集成之后，我們來看看新一代的一體化數據集成方案。例如，從 MySQL 到 Hive 的整個集成過程，可以實現一鍵式集成。這相當于使用一個產品來完成以往的離線和實時數據集成，其主要依賴于流批一體化的 Flink CDC 技術。

這種新方案的主要功能是通過一個作業（job）完成全量數據集成，利用多個子任務的并發執行，實現全量數據的快速導入。全量數據導入完成后，系統通過 Hybrid Source 能力自動切換到增量的 Binlog Source，實現無縫對接。在這個過程中，通過無鎖一致性快照來確保數據的一致性。

這個方案有以下幾個優點：

（1）架構簡約：只有一個全托管產品，具備易運維和彈性的能力。對于客戶來說，通過云上控制臺進行管理，容易簡單。

（2）開發簡單：只需一條 SQL 語句，就能自動將全量數據轉換成增量數據，對數據開發更友好。

（3）運維簡便：無論能力如何，只需進行相應的資源和參數配置，配置好前后端數據源，系統就會自動完成任務。

2. 技術場景二：新一代實時數倉 Flink + Hologres

傳統的實時數倉架構至少包括四個組件：Flink、Kafka/MQ、維度庫或字典表的存儲、以及應用層（例如提供 OLAP 和 Serving 能力的庫）。其工作流程如下：

（1）數據流入：業務日志或數據流入后，先通過 Flink 進入 Kafka，形成源表層。

（2）維度加載：接下來在 DW 層，通過 Flink 任務加載維度庫，進行數據的整合和處理。

（3）數據加工聚合：Flink 繼續加載 kafka topic 中經過處理的數據，進行加工或者聚合，并將數據存儲到應用層。

（4）應用層處理：根據需求，數據可以回歸到業務庫。如果需要進行交互式分析，數據會被加載到適合 OLAP 的數據庫中；如果需要進行點查服務，則會加載到相應的KV存儲，比如 HBase 或 Redis 數據庫中。

這種架構廣泛應用于傳統的實時數倉場景中，以滿足業務時效性和不同類型的數據服務需求。該方案具有以下三個特點：

（1）組件多、架構復雜：如前所述，至少需要四個組件（Flink、Kafka、維度庫或字典表存儲、應用層數據產品）。如果同時需要 Ad-hoc 或 KV 存儲，那么至少需要五個組件，運維難度增加。

（2）中間結果查詢難：由于 Kafka 按照時間順序存儲數據，中間結果的查詢和調試變得困難。在需要進行調試或數據校對時，往往需要將 Kafka 中的數據拉到 OLAP 庫中進一步分析，我們在實際工作中經常遇到這樣的情況，即耗時費力，又增加了問題捕捉的難度。

（3）資源使用不靈活：實時數倉的各個階段和層級有明確的任務劃分。在業務低峰期，某一層的資源使用率下降后，想要調整該層資源比較麻煩，需要對應調整業務邏輯，這通常是一個復雜且需要多次驗證的工作，因為邏輯的調整容易對數據分析結果產生影響。

這種傳統方案雖然能滿足業務需求，但在運維效率和資源管理上存在一定的挑戰。

針對這三個特點，下面介紹新一代實時數倉產品組合解決方案 Flink+Hologres。為了大家便于理解新架構，先為大家介紹一下 Hologres 這個產品及特點：

（1）寫入即可見：由于 Hologres 領先的架構設計，它可以做到寫入即可見，這一點可以達到 kafka 的實效性，但有別于其他 OLAP 引擎；

（2）Binlog 支持：Hologres 擁有自己的 Binlog，Flink 可以訂閱 Binlog 進行下一步的自動加工和分析任務。這一點也是在 OLAP 產品中，區別于其他實時 OLAP 的顯著能力。

（2）行存與列存：Hologres 支持行存儲和列存儲。OLAP 分析通常使用列存儲，可以快速進行實時分析；同時，Hologres 也支持行存儲和行列共存，行存儲主要支持 KV 查詢，非常便捷高效。因此，維度庫可以直接放在 Hologres 的行存表中，不需要其他存儲介質。

（3）高性能實時 Serving 服務：即 Hologres 具有高性能的實時點查能力，基于自身的行存功能，可以進行高 QPS 的 KV 查詢能力。

（4）強隔離性：Hologres 可以通過主從實例模式或者 Warehouse 模式實現寫入和讀取的資源隔離，也可以實現不同業務不同優先級的查詢資源隔離，避免相互干擾。這在實時數倉中也非常關鍵，因為不同層的寫入操作可能會導致查詢速度變慢。

（5）存算分離：Hologres 具備存算分離的能力，方便運維，能夠根據需求靈活擴展或縮減計算資源和存儲資源。

介紹完 Hologres 的產品特點之后，我們來看一下新一代實時數倉的方案（如下圖）。從左到右看，業務日志進入后通過 Flink 集成到 Hologres中 ，此時除了源表外，還會存在維度表，這些維度表直接加載到 Flink 中。Flink 在此過程中進行數據打寬合并，然后傳遞到下一層。

在下一層，Flink 任務可以訂閱 Hologres 對應表的 Binlog，進行進一步的業務邏輯處理，并將結果存儲到 Hologres 的 ADS 層表中。在 ADS 層對外提供服務時，只需要 Hologres 即可，因為它既具備 OLAP 能力，也具備 KV 查詢能力，無需其他產品。此外，Hologres 還提供交互式分析能力，如果在數據處理過程中需要對 ODS、DWD、DWS 層的數據進行查驗，可以隨時通過 SQL 查詢對應表中的結構化數據，從而輕松完成中間的調優和調試（ Debug ）。

所以總結下來，新一代實時數倉方案的優勢如下：

1. 架構簡約易運維：

   （1）少量產品依賴：整個方案主要依賴 Flink 和 Hologres 這兩個產品，極大簡化了系統架構。

   （2）全托管易運維：Flink 和 Hologres 均為全托管服務，易于運維且具有良好的彈性擴展能力。

2. 中間結果方便查詢：

   （1）查詢便捷：數倉中間層數據以結構化形式存在 Hologres 中，方便查詢。

   （2）快速更新修改：除了查詢外，還可以快速更新和修改數據，提升數據處理的靈活性。

3. 數據應用層一體化：

   （1）統一服務能力：Hologres 提供 ADS 層所有的 OLAP 和 serving 能力，減少了面向應用的繁冗組件。

   （2）簡化數據服務：通過 Hologres 一體化的數據服務，減少了系統復雜性，提升了數據服務的效率。

4. 資源使用靈活：

   （1）靈活的數據處理：使用Hologres后，不需要固定各層結構，一個臨時任務可以直接從 ODS 層抽取數據，迅速形成 ADS 層數據。

   （2）快速分析：對于測試、臨時任務或新業務嘗試，可以快速進行數據分析，只需根據業務需求靈活調整。

   （3）按需存儲分配：存儲可以根據業務評估按需分配，提升資源利用效率。

3. 技術場景三：Flink+Paimon 流式湖倉，讓傳統離線的數倉進行加速和提效。

在企業中進行實時鏈路計算時，通常會設置一條鏈路用于離線數倉。離線計算在這個場景中有兩個主要作用：

（1）數據校驗和更正：離線計算定期處理 Flink 傳遞過來的數據，用于對數據進行校驗和更正。
（2）周期性統計和分析：離線計算根據業務需求，批量處理更長時間周期的統計和分析任務，比如月度、季度和年度的報表。

業務日志和 Binlog 通過 Flink 進行加工后，寫入離線存儲，隨即進入離線數倉的加工流程。這個流程從貼源層（ODS層）到數據倉庫明細層（DWD層）再到數據服務層（ADS層），每一層之間通過定時任務進行逐層加工。每一層計算的結果可以通過 Hive、Spark、Trino 等引擎進行查詢或更新。

該方案有明顯的幾個特點：

1. 任務時效性差：每一層定時任務的調度都需要一批批計算，ODS 層算完后才可以計算 DWD 層，如果有較多的表和調度任務，根據業務邏輯會產生比較復雜的依賴關系，那么這些調度任務需要估算比較準確的完成時間以及鏈路關系，才能保證在要求的時間點產出結果。整個過程都是小時級或天級；

2. 技術棧差異大：在實際大數據團隊管理時，實時業務和離線業務會被分為兩組，實時業務在實時引擎上做，如果做校對或更正還需要離線業務團隊做配合，或者掌握一些離線技術棧，對開發同學不是很友好，會花費較大精力做開發運維方面的工作以及兩個團隊間的協調；

3. 數據更新不便捷：以往 Hive、Spark 等存儲方式都是 Insert、Overwrite 覆寫方式來完成更新，新數據得到后，與老數據進行變更合并；

4. 離線實時數據對齊難：實時數據按時間流動，很難找到一個時間點與離線數據完全對齊。

針對以上方案的特點，我們一起看一下 Flink+Paimon 流式數倉的方案是否可以解決以往的痛點。為了讓大家更好的理解，先簡要介紹一下 Paimon。

Paimon 是一種流批一體的湖存儲格式，是一個輕量級的產品，可以部署在 OSS 或 HDFS 上。

Paimon 的產品特點：

（1）區別于 Iceberg/Hudi/Delta Lake 這三個更偏向于批處理的湖格式， Paimon 是流處理演變而來的湖格式，與 Flink 是統一的 SQL 和 API，使用統一的 Flink SQL 可以直接處理湖中的數據；

（2）支持 Upsert、Delete ；

（3）可以輕量級構建在 HDFS/OSS 上，對于 Hadoop、EMR 用戶更友好，不需要大幅度改變和調整技術架構，只需要在存儲上輕量化部署就可以使用該層能力；

（4） Paimon 有 Changelog，Flink 可以訂閱 Changelog 的變化，Changelog 的變化可以自動將上游的變化通過 Flink 任務傳給下游；

（5）支持預計算，降低存儲成本與下游計算壓力；

（6）支持 Time Travel，可以在回溯歷史版本中找到某一個節點的狀態；

（7）支持表結構變更 Schema Evolution。

了解了Paimon后，我們再來看 Flink+Paimon 新方案，從左到右，業務日志和 Binlog 通過 Flink 集成后進入 Paimon 中，每一層可以通過訂閱 Binlog 進行處理，逐層加工后最后形成 ADS 層，再通過 EMR 開源引擎或阿里云自研的引擎等進行查詢和分析。

該方案的優勢是：

（1）準實時任務效率提高，除了使用 Flink 能力、有自動 Changelog 能力外，可以通過流式任務將湖的任務串聯；Paimon Changelog 與 Flink 的 Checkpoint 相關，Flink 的 Checkpoint 可以根據業務需要來設置間隔，兩個 Checkpoint 之間的變化會產生一個 Changelog，會把這次變更傳給下游，下游得到變化后進行進一步的處理加工；

（2）數據更新與訂正的效率高，Paimon 每層支持更新和訂正；

（3）開發模型統一，整體流程使用一套 Flink SQL/Table API 即可完成；

（4）數據合并預處理，Paimon 支持很多預計算操作例如去重、部分更新、預聚合等，減少了 Flink 中復雜的業務邏輯；

（5）第五多引擎接入，生態上支持很多常用的引擎，更開放的生態帶來對現有大數據架構改造的成本很低，可以將以往偏離線數據的處理能力以流方式進行整體改造。

五、客戶案例

在介紹完產品體系和三個主要技術場景之后，下面介紹兩個客戶案例。

1. 某游戲實時數倉架構的演進。

該客戶是全球 Top 20 的游戲公司，運營很多游戲，每天處理的實時數據達到 pb 級。原有技術架構的痛點是 OLAP 組件很多，每個 OLAP 都有自己的特點，例如 Clickhouse 擅長大寬表、ADB 擅長較小規模數據量分析等，離線數據的查詢基于傳統的 Impala 方式等。整個架構流程是：數據庫及日志數據進入 Kafka，Flink 消費 Kafka 中 topic 數據進行逐層的加工和分析。同時過程中 Flink 還會把數據寫入離線鏈路，離線引擎做數據的校驗和備份等。如果過程中出現問題，可以使用 Impala 做離線數據加速查詢，用以排查問題和校驗分析。實時鏈路最后將數據寫入 Clickhouse 中，而為了保證實時鏈路的穩定性，離線數據最后加工以及與實時數據的比對采用了另外一個 OLAP 引擎 ADB。

為了解決以往架構的痛點，客戶選擇了升級新架構的方案：實時鏈路改造成了 Flink+Hologres 實時數倉模式，并引入了 MaxCompute，借助 Hologres+MaxCompute+dataworks 共享存儲的能力，形成了實時離線一體化的能力。

這里先解釋一下實時離線一體化，從三個層面來簡要說明：第一個層面即數據開發層，通過 Dataworks 統一 IDE 入口，可以完成 Hologres 和 MaxCompute 的任務編寫，并可以通過 Dataworks 形成同一個調度工作流，完成離線和實時任務的混合編排；第二個層面即計算層的聯邦計算，由于 Hologres 和 MaxCompute 兩個引擎的元數據可以打通，用戶很容易可以通過內外表的形式來進行聯合計算分析；第三個層面即存儲層，由于兩個引擎都是基于阿里云 Pangu 體系建立，所以 Hologres 可以便捷的為 MaxCompute 中的離線數據做加速，而且兩個引擎之間傳遞數據速度非?？?，提升了效率的同時也節省了大量數據集成的資源；

在上面介紹的架構升級方案上，客戶將原來的 ADB、Clickhouse、Impala 全部替代，因為 Hologres 強大的計算和存儲能力，使得以往的離線數倉分層改變，基本 ADS 層全部存儲的 Hologres 中。而且 Hologres 可以做 MaxCompute 的離線加速，這些能力讓客戶決策可以縮減掉離線數倉中冗余的部分，使得離線部分更精煉和易于管理。

這些先進的理念和架構實現幫助客戶在完成架構升級之后，有幾個明顯的體感：

（1）架構上比較統一，不需要維護多個組件，節省人力的同時，也不需要做很多組件聯合擴縮容的規劃；

（2）實時鏈路的可用性更強了，在過程查詢和問題發現方面非常便捷，而且在支持創新業務時，也可以在不改變 source 邏輯的情況下，在實時數倉中快速形成臨時的實時分析任務，支持臨時決策。實時鏈路中個別場景的性能也有大幅提升，比如CK的Join查詢可以提升一個數量級以上；

（3）實時離線一體化的能力，使得整體數據分層和治理更科學，任務編排統一化以及治理能力的提升，都讓客戶有能力在支持好現在和未來業務的同時，掌握了規劃和控制成本的手段；

2. 某出行客戶離線數倉架構演進。

該客戶是一家國內知名的出行企業，月活躍用戶達到千萬級別，每日處理的數據量非常龐大，實時計算需求遠高于離線計算需求?？蛻舻臉I務痛點如下：

（1）技術線分離：采用典型的 Lambda 架構，實時和離線計算分離，導致兩條線之間存在復雜的業務邏輯交互；

（2）高存儲成本：實時和離線各存儲一份數據。對于這個客戶來說業務行為日志處理很重要，因為實時和準實時的處理都走實時計算的引擎和存儲，故導致實時存儲的成本占比較大；

（3）流處理中間數據查詢困難：實時計算過程中，查詢中間數據較為困難。

客戶原有架構的實時線采用 Flink + Kafka，定期將數據 Dump 到離線 Hive 中，進行備份和進一步的離線加工分析。在離線鏈路中還引入了 Presto，用于查詢和部分準實時業務，處理完成后供應用使用。

新架構通過 Flink + Paimon 將準實時鏈路和離線鏈路融合在一起，形成一套完整的模式。這里的準實時任務要求數據處理時限在分鐘級，適用于需要人為判斷的任務，例如報表生成或分鐘級的應用處理邏輯。而實時任務通常要求秒級或毫秒級的處理時限，數據結果由機器或程序判斷，例如風控和實時推薦等業務。

上述技術場景三中，Flink + Paimon 的使用使得可以在數據處理中通過 Flink SQL 進行查詢。同時，為了應對大量的離線數據處理需求和臨時任務需求，還引入了 StarRocks。StarRocks 可以直接查詢 Paimon 表，性能比 Presto/Impala 高出兩倍以上。

這個改造之后，對于客戶的影響比較明顯：第一，純實時鏈路的業務復雜度明顯降低，實時和離線交互的任務減少 40%+；第二，每年節省出 65% 以上的 Kafka 存儲成本，而且準實時的數據不需要存兩份，只需要存 HDFS 一份；由于 Kafka 使用價格較高的 SSD 存儲介質，成本較高，換成 HDFS 的 HDD 后，每年綜合節省近千萬成本；

通過圍繞實時計算產品 Flink，我們一起探討和梳理了系統架構和技術場景，并在客戶案例中提出了對架構升級的思考。希望這些經驗能對您和您所在的企業有所幫助，同時期待 Flink 的新功能和特性能幫助更多企業釋放數據業務的潛能。