摘要：本文整理自中原銀行數(shù)據(jù)信息部杜威科打月，在 Flink Forward Asia 2022 行業(yè)案例專場的分享乔妈。本篇內(nèi)容主要分為四個部分：
- OLAP 實時化建設(shè)背景
- OLAP 全鏈路實時化
- OLAP 實時化探索
- 未來探索方向
中原銀行成立于 2014 年外莲，是河南省唯一的省級法人銀行队贱，2017 年在香港聯(lián)交所主板上市欣除，2022 年 5 月經(jīng)中國銀保監(jiān)會批準正式吸收合并洛陽銀行住拭、平頂山銀行及焦作中旅銀行。合并后總資產(chǎn)突破 1.2 萬億耻涛，在國內(nèi)城市商業(yè)銀行排名第八位废酷，下轄 18 家分行、700 余家營業(yè)網(wǎng)點及 17 家附屬機構(gòu)抹缕，先后榮獲“年度十佳城市商業(yè)銀行”澈蟆、“鐵馬十佳銀行”、“最佳上市公司”等稱號卓研。
一趴俘、OLAP 實時化建設(shè)背景
近幾年實時需求涌現(xiàn)，尤其是銀行更加重視挖掘?qū)崟r數(shù)據(jù)的使用與價值奏赘。主要表現(xiàn)在逐年增多的實時報表寥闪、實時大屏等面向 BI 的場景。還有實時指標或特征計算等面向 AI 的場景磨淌。從技術(shù)角度疲憋，實時 OLAP 相較于傳統(tǒng) OLAP 發(fā)展起步較晚，多種多樣的實時數(shù)據(jù)需求對實時 OLAP 體系也提出了更高的要求梁只。隨著近年來技術(shù)迭代缚柳，如 StarRocks埃脏、ClickHouse 等支持實時 OLAP 場景的數(shù)據(jù)庫也是推陳出新，對于解決銀行業(yè)的實時場景也帶來了更多可能秋忙。
銀行業(yè)想要獲取實時報表數(shù)據(jù)彩掐，這樣基本的 OLAP 場景需要解決哪些困難呢？
首先需要全鏈路實時化灰追。全鏈路是指數(shù)據(jù)實時采集堵幽、實時分析、實時寫入數(shù)據(jù)庫以及實時提供查詢分析弹澎。整個鏈路的實時化相較于傳統(tǒng)的 OLAP朴下，各個環(huán)節(jié)均有一些難點需要克服。比如受到銀行記賬模型無法變更苦蒿、數(shù)據(jù)庫管理嚴格桐猬、數(shù)據(jù)安全要求較高等多方面的限制，當前金融行業(yè)數(shù)據(jù)實時采集也不是一路暢通的刽肠。另一方面來說溃肪，對于流計算業(yè)務，實時計算面臨數(shù)據(jù)源多音五、整合困難惫撰、技術(shù)復雜、監(jiān)控運維成本較高等問題躺涝。業(yè)務需求也往往涉及多個數(shù)據(jù)部門配合厨钻，多種業(yè)務類型交織，一旦流計算任務出現(xiàn)問題坚嗜，監(jiān)控分析排查也會比較困難夯膀。
其次，從生產(chǎn)實踐得知苍蔬，實時場景僅有實時數(shù)據(jù)往往是不夠的诱建，需要配合離線數(shù)據(jù)才能計算出所需的業(yè)務數(shù)據(jù)。尤其是在銀行體系下碟绑，面向規(guī)范化俺猿、精準化加工的傳統(tǒng)離線數(shù)倉體系，能夠較好的解決財務分析等場景格仲，且在很長時間內(nèi)仍是主流方案押袍。離線數(shù)據(jù)加工的復雜度往往也較高，當前階段尚無法達到全部業(yè)務數(shù)據(jù)的實時化計算凯肋。
最后谊惭，普遍依賴維度表。眾所周知，在 kimball 維度建模中圈盔，分為事實表和維度表惭蟋。在我行，基于事實表的場景基本上已經(jīng)解決药磺。但銀行業(yè)的報表大多都基于維度表的統(tǒng)計分析，該場景也是銀行業(yè)實時報表落地困難的關(guān)鍵因素之一煤伟。
為了解決該場景癌佩，我行進行了大量的生產(chǎn)實踐，但仍未有較好的解決落地方案便锨。希望隨著實時技術(shù)的發(fā)展能夠徹底解決該場景围辙。
二、OLAP 全鏈路實時化
首先介紹一下實時化的演進歷程放案，對整個發(fā)展過程和未來的方向有一個概括性的了解姚建。
第一階段：起步≈ㄑ常基于 Kafka 的實時 ETL掸冤，包括實時采集、實時加工友雳、實時載入稿湿、實時 OLAP。該架構(gòu)能夠解決的問題大都是基于事實表的統(tǒng)計分析押赊，已經(jīng)在行內(nèi)有大量的落地案例饺藤，但無法解決銀行基于維度表的統(tǒng)計分析。另外流礁，該方案很難形成規(guī)奶樗祝化的數(shù)據(jù)分層復用，Kafka 數(shù)據(jù)無法查詢和長期持久化等問題也比較突出神帅。
-
第二階段：探索再姑。為了解決銀行業(yè)大量基于維度表統(tǒng)計分析場景，先載入后分析找御，也就是 ELT 的方式询刹。過程是先實時采集，然后不進行邏輯加工直接實時載入，最后再實時 OLAP 查詢階段進行邏輯加工智润。
在 ELT 探索初期爪飘，我們采用過微批全量的方式，在數(shù)據(jù)實時寫入到數(shù)據(jù)庫后蔽挠，定時執(zhí)行全量加工邏輯，類似于離線數(shù)倉跑批的概念。只不過是從每天跑批縮短到了小時級別澳淑，甚至分鐘級別比原，達到準時加工的效果。顯而易見這種方式不可取杠巡，存在時效性差量窘、跑批不穩(wěn)定等問題。
隨著 MPB 數(shù)據(jù)庫的發(fā)展氢拥，查詢性能也得到了極大的提升蚌铜。使用 View 視圖嵌套加工邏輯的方式也進行了探索，也就是把業(yè)務數(shù)據(jù)以 CDC 的方式載入 MPP 數(shù)據(jù)庫的明細層嫩海，分析查詢邏輯使用 View 封裝冬殃，在查詢時觸發(fā)底層計算。這種方式也可以解決維度表的統(tǒng)計分析叁怪，但每次查詢資源消耗太大审葬，無法大范圍推廣。這種 ELT 方式雖然能夠解決一部分的實時場景奕谭，但局限很大涣觉。
第三階段：優(yōu)化。接下來到了優(yōu)化升級和未來方向選擇的節(jié)點血柳。為了解決銀行業(yè)基于維度表的實時 OLAP旨枯，必須把部分計算向前移動到 Flink 計算。數(shù)據(jù)湖 Flink Table Store(Apache Paimon) 的出現(xiàn)混驰，使基于維度表的全量統(tǒng)計分析成為了可能攀隔。也就是前期一部分的加工工作在 Flink 中完成，另一部分聚合等計算工作在 OLAP 數(shù)據(jù)庫中完成栖榨，兩者分攤了計算的時間消耗昆汹。
第四階段：未來。在未來還是希望能夠把全部加工邏輯在 Flink 端完成婴栽，向著存算分離流批一體的流式數(shù)倉方向發(fā)展满粗。
全鏈路實時化具體是怎么做的呢？承載哪些業(yè)務或者使用了哪些組件呢愚争？上圖我們從下往上看映皆。最下面是數(shù)據(jù)源，分為了四類實時數(shù)據(jù)轰枝，分別是業(yè)務的數(shù)據(jù)庫數(shù)據(jù)捅彻、客戶的行為埋點數(shù)據(jù)、網(wǎng)絡(luò)流量日志類數(shù)據(jù)鞍陨、應用消息直接產(chǎn)生的數(shù)據(jù)步淹。所有數(shù)據(jù)均打入 Kafka，供后續(xù)的實時計算平臺使用。
中間是實時計算平臺缭裆，加工邏輯使用 Flink SQL 和自定義函數(shù)處理键闺，F(xiàn)link 任務運行在 Yarn 或 K8s 上，當前主要推廣運行在云環(huán)境上澈驼。使用 Kafka 和 Flink Table Store(Apache Paimon) 作為數(shù)據(jù)的傳輸和存儲辛燥，維表統(tǒng)一使用 ES 提供。在銀行業(yè)維表使用比較普遍缝其，同一張維度表可能使用其中的多列進行關(guān)聯(lián)挎塌，且維度表往往需要實時的，如在新開戶場景氏淑。在我們平臺上，使用頻率較高的維表硕噩，引用次數(shù)達 60 多次假残。
再往上來到了數(shù)據(jù)服務層，提供在線服務的同時需要支持實時數(shù)據(jù)的寫入炉擅，常用場景是直接寫入業(yè)務目標數(shù)據(jù)庫 Oracle 或 MySQL 提供在線服務辉懒。大多數(shù)場景數(shù)據(jù)是寫入公共的 ES 或者 StarRocks，提供查詢或者在線分析服務谍失，后期也會提供直接對 Flink Table Store(Apache Paimon) 的查詢眶俩。
最上層是各個業(yè)務場景的實時數(shù)據(jù)需求，如實時反欺詐快鱼、實時營銷颠印、數(shù)據(jù)安全行為分析、實時報表等場景抹竹。
左邊的數(shù)據(jù)源有關(guān)系型數(shù)據(jù)庫 Oracle线罕、MySQL，還有在起步階段的國產(chǎn) OceanBase窃判。銀行當前主要使用的還是 Oracle钞楼，我們采用商業(yè)的實時數(shù)據(jù)采集工具 Attunity Replicate，該工具在部署方式袄琳、抽取數(shù)據(jù)的時延和吞吐表現(xiàn)優(yōu)秀询件。對少數(shù) MySQL 采用了開源的 Flink CDC 工具，該工具滿足各個場景的需求唆樊。明年行內(nèi)將大范圍推廣國產(chǎn)的 OceanBase 數(shù)據(jù)庫宛琅，其自帶的 OMS 數(shù)據(jù)遷移工具是抽取該庫的最好選擇。
這幾種關(guān)系數(shù)據(jù)庫均采用 JOSN 格式逗旁，全部寫入 Kafka 中夯秃。對于手機銀行、微信銀行等用戶行為埋點數(shù)據(jù)，使用的是商業(yè)神策平臺提供的能力仓洼。實時計算平臺直接從神策的 Kafka 進行數(shù)據(jù)消費介陶。交換機的流量鏡像等日志經(jīng)過報文解析后也直接寫入 Kafka，這部分的實時流量是最大的色建。另外還有少量產(chǎn)品是把相關(guān)的實時數(shù)據(jù)直接寫入 Kafka哺呜。
對于 Kafka 中的 topic，也有多種方式適配不同的數(shù)據(jù)場景箕戳。對于關(guān)系型數(shù)據(jù)庫某残，一張表對應一個 topic。對于用戶行為陵吸，采用大寬表的形式把所有數(shù)據(jù)都寫入同一個 topic玻墅。采用 Kafka 作為統(tǒng)一對接下游流計算平臺，達到復用 topic 的目的壮虫，如核心的交易流水表復用了三十多次澳厢。
通過介紹發(fā)現(xiàn)不同場景的實時數(shù)據(jù)最優(yōu)的采集工具也不同，通過各種采集工具抽取了各個業(yè)務部門的數(shù)據(jù)囚似，但海納百川剩拢，都需要流入 Kafka 對接后續(xù)的實時計算。
最后拋出來一個疑問饶唤，對于紛繁復雜的數(shù)據(jù)源徐伐，大家是如何統(tǒng)一管理起來的呢？
2018 年首次引入實時計算業(yè)務募狂，主要以代碼開發(fā)為主办素。2019 年開始系統(tǒng)的建設(shè)實時計算平臺，以 Flink SQL 開發(fā)實時業(yè)務祸穷，能夠界面配置摸屠、啟停、監(jiān)控任務粱哼。2020 年支持運行在 K8s 云平臺上季二，能夠手機小程序遠程監(jiān)控，承載的任務也達到了 100 多個揭措。2021 年開始支持 CDC 同步場景胯舷，探索實時 OLAP，承載的業(yè)務也達到了 200 多個绊含。2022 年支持了最新的 Flink Table Store(Apache Paimon) 湖存儲桑嘶，也引入了高性能的 OLAP 引擎 StarRocks，探索實時報表場景躬充，承載的業(yè)務也達到了 300 多個逃顶。
這幾年實時任務的運行現(xiàn)狀如下：
實時任務個數(shù) 380+讨便，以每年 100+的速度穩(wěn)步增長。支撐了二十多個項目組的業(yè)務需求以政。日均處理數(shù)據(jù)行數(shù) 50 億+霸褒，日均接收數(shù)據(jù)量 20T+。
這么多的實時任務多種多樣盈蛮，如流量日志計算指標废菱，數(shù)據(jù)量大但邏輯簡單；監(jiān)控用戶賬戶信息抖誉，數(shù)據(jù)量小但引用維表個數(shù)較多殊轴；監(jiān)控用戶行為埋點數(shù)據(jù)，使用了 CEP 進行復雜事件處理袒炉。
顯然數(shù)據(jù)加工實時化在鏈路中處于關(guān)鍵位置旁理，平臺化也能夠降低使用門檻，加快開發(fā)效率我磁。用戶能夠像使用普通的 SQL 一樣孽文，對實時的數(shù)據(jù)進行處理，不需要關(guān)注流計算底層復雜的處理過程十性，極大地降低了實時數(shù)據(jù)開發(fā)的門檻叛溢。
其中主要的功能有數(shù)據(jù)源管理塑悼、實時任務開發(fā)劲适、任務運維監(jiān)控、項目管理厢蒜、集群管理等功能霞势。在實時任務開發(fā)模塊中，主要有數(shù)據(jù)源配置斑鸦、源表/維表/結(jié)果表配置愕贡、SQL 開發(fā)、自定義函數(shù)巷屿、SQL 語法檢測固以，包括上線過程中需要的導出和導入功能。
在任務運維中有收發(fā)統(tǒng)計嘱巾、集群資源監(jiān)控憨琳、異常短信告警、遠程小程序監(jiān)控等旬昭，同時具備企業(yè)級的權(quán)限管理篙螟、租戶管理等功能。該平臺涵蓋了實時數(shù)據(jù)開發(fā)的全生命周期问拘，平臺化可以徹底規(guī)避繁重的底層流計算處理邏輯遍略，繁瑣的提交過程等惧所。為用戶打造一個只需要關(guān)注實時計算邏輯的平臺，助力企業(yè)向?qū)崟r化绪杏、智能化大數(shù)據(jù)轉(zhuǎn)型下愈。
前面也已經(jīng)提到了，實時計算的場景往往離不開離線數(shù)據(jù)寞忿，不管是在數(shù)據(jù)加工階段驰唬，還是在查詢分析階段，實時數(shù)據(jù)主要是寫入 Oracle腔彰、MySQL叫编、ES、StarRocks 等霹抛。
以 StarRocks 為例搓逾，寫入的既有離線數(shù)據(jù)，也有實時數(shù)據(jù)杯拐。既有寫入 ODS 層明細層數(shù)據(jù)霞篡，也有計算匯總后的 ADS 層匯總數(shù)據(jù)。StarRocks 作為一款 MPP 架構(gòu)的高性能數(shù)據(jù)庫端逼，能夠支撐 PB 級的數(shù)據(jù)量朗兵，擁有靈活的建模方式，可以通過向量化引擎顶滩、物化視圖余掖、位圖索引、稀疏索引等手段構(gòu)建統(tǒng)一的數(shù)據(jù)存儲系統(tǒng)礁鲁。
我行搭建了一站式商業(yè)智能 BI 平臺盐欺，該平臺有客戶行為分析系統(tǒng)——知秋、一站式報表平臺——魯班仅醇、一站式大屏——鴻圖冗美、自助分析平臺——云間、一站式活動運營平臺——智贏等系統(tǒng)析二，未來還會加大對Table Store的投入粉洼，作為實時數(shù)據(jù)的統(tǒng)一存儲。
接下來我們看一下典型 ELT 鏈路的工作過程叶摄。當前銀行業(yè)的數(shù)據(jù)庫主要還是 Oracle属韧，采用商業(yè)的 Attunity Replicate 實時采集數(shù)據(jù)。該工具提供全量和增量的實時同步准谚，秒級時延挫剑，數(shù)據(jù)以 JOSN 格式統(tǒng)一寫入 Kafka，以便復用 topic柱衔。也可以按照主鍵哈希順序?qū)懭?topic樊破，以保證分區(qū)有序性愉棱。
然后基于 Flink SQL 構(gòu)建的實時計算平臺進行業(yè)務邏輯處理，統(tǒng)一使用 ES 作為維表哲戚，關(guān)聯(lián)離線和實時的數(shù)據(jù)奔滑。這里沒有選擇 Hbase 和 Redis 作為維表是因為他們只能主建關(guān)聯(lián)，構(gòu)建二級索引又比較麻煩顺少。另一方面朋其，維表數(shù)據(jù)量最大也就是千萬級別，使用 ES 能夠滿足所有場景脆炎。
最后數(shù)據(jù)實時寫入 StarRocks 中梅猿，StarRocks 支持快速 update，提供高效 OLAP 的能力秒裕，能夠應對多種查詢場景袱蚓。這個典型的 ETL 鏈路對于事實表的行為分析有很好的效果，比如用來統(tǒng)計交易筆數(shù)几蜻、交易金額喇潘、業(yè)務量等指標，但對于維度表的分析卻無能為力梭稚，比如計算分支行存款余額場景颖低。
三、OLAP 實時化探索
我們以銀行的典型動賬場景為例弧烤，一次動賬操作其實是一個事務忱屑，至少要操作兩張表。第一張表是交易流水表扼褪，記錄轉(zhuǎn)賬的一次行為想幻，第二張則是用戶的屬性表粱栖，其中有一個字段是用戶的余額话浇，需要隨著轉(zhuǎn)賬同步更新。
上圖中的兩個表是演示兩次轉(zhuǎn)賬動作闹究，該場景在 12:00:01 秒張三轉(zhuǎn)入 100 元幔崖，客戶表張三的余額也從 100 更新為 200。12:00:02 秒渣淤，李四轉(zhuǎn)出來 100 元赏寇，客戶表李四的余額也從 200 元更新為 100 元，在這個轉(zhuǎn)賬場景下進行分析价认。
流水表的特點嗅定，主要是 insert 操作，記錄行為信息用踩，適合增量計算渠退，如統(tǒng)計開戶忙迁、取款、貸款碎乃、購買理財?shù)刃袨槭录⑷印偛盘岬降牡湫偷幕?Kafka 的實時計算能夠較好的解決該場景，比如實時營銷包括大額動賬提醒梅誓、工資代發(fā)恰梢、理財產(chǎn)品購買、申請反欺詐梗掰、交易反欺詐等嵌言。在貸后管理也有應用，如零貸貸后臨期催收及穗、扣款等呀页。
客戶屬性表的特點，主要是 update 操作拥坛，記錄屬性信息蓬蝶，客戶的總資產(chǎn)、貸款猜惋、理財丸氛、基金、保險等產(chǎn)品的余額是在維度表中著摔，所以常使用維度表全量計算資產(chǎn)信息缓窜，如資產(chǎn)余額類的計算等。
應用的場景主要是實時報表和實時大屏谍咆，比如對公 CRM禾锤、零售 CRM；經(jīng)營管理摹察；資產(chǎn)負債管理等恩掷。
接下來主要探討的是基于維度表的實時全量計算場景。以在行內(nèi)落地的對公 CRM 實時存貸款場景為例供嚎，來講解一下涉及哪些方面的工作黄娘。對公 CRM 實時存貸款功能面向總分行領(lǐng)導、支行行長克滴、客戶經(jīng)理等逼争，可以隨時查看行內(nèi)分支行及客戶的存貸款情況，從而時刻掌握全行的資產(chǎn)最新狀況劝赔。
從數(shù)據(jù)的角度來看誓焦，分為三個部分，實時數(shù)據(jù)着帽、離線數(shù)據(jù)杂伟、實時查詢分析數(shù)據(jù)竿秆，也就是在查詢的時候才開始進行邏輯計算。
先來看一下實時數(shù)據(jù)稿壁，不斷變化的有存款余額幽钢、貸款余額、應解匯款傅是、實時匯率匪燕、新開賬戶等。剛才提到實時場景往往離不開離線數(shù)據(jù)一起進行配合計算喧笔，離線數(shù)據(jù)主要包括員工信息帽驯、機構(gòu)層級、歸屬關(guān)系等基本信息书闸，還有離線跑批生成的年末月末余額尼变、績效關(guān)系、管戶關(guān)系等浆劲。
這兩部分數(shù)據(jù)均載入到實時 OLAP 引擎嫌术，用戶查詢的時候在引擎內(nèi)計算資產(chǎn)負債明細匯總，根據(jù)績效關(guān)系對資產(chǎn)負債進行分組聚合牌借。實時的存貸款和日終度气、月終進行比較，分支行根據(jù)存貸款進行排序等膨报。對公 CRM 提供的查詢功能有全行匯總磷籍、分支行匯總、分支行明細现柠、分支行下轉(zhuǎn)院领、客戶明細、年末月末比較够吩、趨勢分析等比然。
了解了實時存貸款業(yè)務功能，下面我們來看一下是如何實現(xiàn)的废恋。上圖是該案例的技術(shù)架構(gòu)圖谈秫，也就是使用了實時的 ELT扒寄。
首先鱼鼓，實時數(shù)據(jù)全部來自于 Oracle 數(shù)據(jù)庫，通過實時采集導入到 Kafka该编。使用流計算平臺迄本，以 CDC 的形式寫入到 StarRocks，在其中構(gòu)建全量和增量的數(shù)據(jù)课竣。作為 ODS 原始層嘉赎，離線數(shù)據(jù)在數(shù)倉中跑批生成置媳，使用離線同步工具，百川平臺以 T+1 的形式寫入 StarRocks公条，然后在 StarRocks 中使用 view 靈活的對數(shù)據(jù)進行轉(zhuǎn)換處理拇囊。View 視圖可以隨業(yè)務進行調(diào)整，上層應用直接查詢封裝好的視圖實現(xiàn)即席查詢靶橱。當用戶進行點擊的時候寥袭，觸發(fā)原始的數(shù)據(jù)進行計算，如查詢某分行的存款余額关霸。
該方案可以解決基于維表的實時全量計算場景传黄，無需跑批，現(xiàn)場計算队寇，端到端分鐘級甚至秒級完成膘掰。尤其是在月末、季末等關(guān)鍵節(jié)點佳遣，給分支行的領(lǐng)導查詢最新資產(chǎn)負債等信息帶來了極大的便利识埋。
當然，該方案并不完美零渐，缺點是當 view 的邏輯較為復雜惭聂，數(shù)據(jù)量較多時，查詢性能影響較大相恃，因此比較適合數(shù)據(jù)量不大辜纲、對 QPS 要求不高、靈活性要求較高的場景拦耐，且需要計算資源比較充足耕腾。
該方案的探索也讓我們得出了一個寶貴的經(jīng)驗。雖然 OLAP 引擎性能強大杀糯，但仍然不能把所有的計算邏輯全部在引擎中執(zhí)行扫俺，必須向前推移。但是 Flink 只有計算沒有存儲固翰，這個問題該怎么解決呢狼纬？具體有哪些方面的困難呢？下面來分析一下骂际。
想要解決基于維度表的實時全量計算疗琉，存儲需要以下三個能力。
第一歉铝、存儲全量數(shù)據(jù)盈简，并支持快速更新。維度表有大量的更新操作，比如在結(jié)息日源庫進行跑批的時候柠贤。
第二香浩、支持流批寫、流批讀臼勉，尤其是流讀邻吭。流讀是數(shù)據(jù)驅(qū)動計算分析，只有能夠流讀才能使用數(shù)據(jù)自動計算分析宴霸，而不是使用微批調(diào)度或者查詢時觸發(fā)分析計算镜盯。
第三、支持存儲“完整”的 changelog猖败。完整的數(shù)據(jù)庫日志存儲是數(shù)據(jù)驅(qū)動計算正確性的重要保證速缆。
四、未來探索方向
今年發(fā)布的 Flink Table Store(Apache Paimon) 能夠很好的解決之前遇到的問題恩闻。Flink Table Store(Apache Paimon) 是一個統(tǒng)一的存儲艺糜，用于在 Flink 中構(gòu)建流式處理和批處理的動態(tài)表，支持高速數(shù)據(jù)攝取和快速查詢幢尚，是一種湖存儲格式破停，存儲和計算分離。導入數(shù)據(jù)時雙寫到數(shù)據(jù)文件和日志系統(tǒng)尉剩，并且支持流批寫入真慢、流批讀取，支持快速 update 操作理茎。還支持豐富的 OLAP 引擎生態(tài)黑界，比如 Hive 等。我還了解到 StarRocks 也在支持數(shù)據(jù)湖查詢皂林，相信在不久的將來 StarRocks 也能夠支持查詢 Flink Table Store(Apache Paimon)朗鸠。
在加入 Flink Table Store(Apache Paimon) 后，原有的 ELT 架構(gòu)的基礎(chǔ)上進行優(yōu)化升級础倍，帶來了如下變化烛占。
在流計算平臺中，把原始數(shù)據(jù)寫入 Flink Table Store(Apache Paimon)沟启，實時存儲歷史全量和實時更新的表數(shù)據(jù)忆家，然后計算邏輯使用 Flink SQL 實現(xiàn)，最后把初步匯總的數(shù)據(jù)寫入 StarRocks 中德迹，原始明細數(shù)據(jù)在 Flink 中計算芽卿，極大減少了 StarRocks 的計算量。
這種架構(gòu)我們在生產(chǎn)上已經(jīng)進行了初步嘗試浦辨，效果非常顯著蹬竖。但這并不是終點沼沈，上圖展示的就是未來的藍圖流酬，我們將朝著流式數(shù)倉的方向進行演進币厕。流式數(shù)倉能夠支持存儲全量的數(shù)據(jù)和完整的 changelog，也支持批量導入離線數(shù)據(jù)芽腾。使用廉價的存儲和存算分離旦装，能夠更加靈活的進行彈性計算。
數(shù)倉的分層可以解決實時數(shù)據(jù)的復用摊滔，多指標隨著數(shù)據(jù)的實時流動而實時變化阴绢，數(shù)據(jù)主動的變化驅(qū)動分析，從另一個角度說也是在使用空間換取時間艰躺。當數(shù)據(jù)在源頭發(fā)生變化時就能夠即刻捕捉到呻袭，讓所有數(shù)據(jù)實時的流動起來，并且對所有流動中的數(shù)據(jù)都可以進行實時或批量的查詢腺兴。
離線數(shù)據(jù)和實時數(shù)據(jù)共同存儲在 Flink Table Store(Apache Paimon) 中左电，離線分析 SQL 和實時 SQL 完全一樣，最終達到流批一體的效果页响。那么為什么現(xiàn)在不直接采用這種架構(gòu)進行構(gòu)建呢篓足？當前階段這個架構(gòu)還無法落地，比如其中聚合計算有大量的撤銷動作闰蚕，多個層次間的實時數(shù)據(jù)流動也需要大量的資源和調(diào)試技能栈拖，不過我相信流式數(shù)倉一定會到來。
