摘要：本文整理自米哈游大數(shù)據(jù)實(shí)時(shí)計(jì)算團(tuán)隊(duì)負(fù)責(zé)人張劍绽昼，在 FFA 行業(yè)案例專場(chǎng)的分享。本篇內(nèi)容主要分為三個(gè)部分：

1. 發(fā)展歷程

2. 平臺(tái)建設(shè)

3. 未來展望

點(diǎn)擊查看直播回放 & 演講PPT

一、發(fā)展歷程

隨著公司業(yè)務(wù)的發(fā)展葵第，實(shí)時(shí)計(jì)算需求應(yīng)運(yùn)而生税弃。我們根據(jù)重點(diǎn)的工作內(nèi)容將發(fā)展階段劃分為三個(gè)部分，

• 第一階段是以 DataStream API 開發(fā)為主的 Flink 平臺(tái)

• 第二個(gè)階段是以 Flink SQL 為主一站式開發(fā)平臺(tái)

• 第三階段是一站式開發(fā)平臺(tái)的功能深化和場(chǎng)景覆蓋

1

第一階段伺帘，以 DataStream API 開發(fā)為主的 Flink 平臺(tái)昭躺，很好的解決了我們對(duì)于實(shí)時(shí)計(jì)算的需求。但隨著開發(fā)同學(xué)越來越多伪嫁，大家發(fā)現(xiàn)基于 DataStream API 開發(fā)為主的實(shí)時(shí)計(jì)算平臺(tái)领炫，具有三個(gè)弊端，分別是開發(fā)成本高张咳、版本易沖突帝洪、運(yùn)維難度大，因此大家對(duì) Flink SQL 的呼聲就越來越高脚猾。

2

第二階段碟狞，以 Flink SQL 為主一站式開發(fā)平臺(tái)。主要的工作內(nèi)容有：Flink SQL 能力提升婚陪、指標(biāo)和日志體系建設(shè)族沃、元數(shù)據(jù)和血緣管理∶诓危基于此脆淹，業(yè)務(wù)人員有了新的期望。

• 第一沽一，希望平臺(tái)能夠更加智能化盖溺，降低用戶的使用調(diào)參、調(diào)優(yōu)等成本

• 第二铣缠，希望流量的波動(dòng)能夠具有自動(dòng)擴(kuò)縮容的資源管理能力

• 第三烘嘱，希望數(shù)據(jù)更具時(shí)效性。比如數(shù)據(jù)入倉(cāng)蝗蛙、入湖后分鐘級(jí)可查蝇庭，或者基于近實(shí)時(shí)數(shù)倉(cāng)開發(fā)

3

第三階段，一站式開發(fā)平臺(tái)功能深化和場(chǎng)景覆蓋捡硅。主要的工作和未來要持續(xù)做的工作包含如下幾個(gè)方面：

• 第一哮内，任務(wù)資源的靜態(tài)和動(dòng)態(tài)調(diào)優(yōu)能力

• 第二，資源的彈性擴(kuò)縮容能力

• 第三壮韭，加強(qiáng)近實(shí)時(shí)數(shù)倉(cāng)的建設(shè)

4

下面我們進(jìn)入平臺(tái)的整體架構(gòu)北发，從下圖中可以看到平臺(tái)總體包含三個(gè)部分纹因，分別是用戶權(quán)限及鑒權(quán)、功能和服務(wù)模塊琳拨、以及環(huán)境和資源功能瞭恰。

功能和服務(wù)主要包含作業(yè)大盤、概覽狱庇、開發(fā)惊畏、運(yùn)維、日志僵井、元數(shù)據(jù)陕截、血緣、監(jiān)控告警批什、資源調(diào)優(yōu)农曲、自動(dòng)擴(kuò)縮容、彈性資源管理以及安全管控等驻债。

5

二乳规、平臺(tái)建設(shè)

那么基于這樣的實(shí)時(shí)計(jì)算平臺(tái)，我們是如何建設(shè)的呢合呐？圍繞 Flink SQL 或者平臺(tái)化的主要工作有如下四個(gè)方面：

• 第一暮的，語(yǔ)義表達(dá)和控制能力的建設(shè)

• 第二，資源調(diào)優(yōu)和彈性能力的建設(shè)

• 第三淌实，指標(biāo)體系建設(shè)

• 第四冻辩，近實(shí)時(shí)數(shù)倉(cāng)建設(shè)

截止目前，F(xiàn)link SQL 占比總?cè)蝿?wù)數(shù)已經(jīng)在 90%以上拆祈，極大的提高了大家的開發(fā)效率恨闪。下面我們將對(duì)每一個(gè)部分進(jìn)行詳細(xì)的講解，來看一看具體都是怎么做的放坏。

6

DataStream API 相較于 Flink SQL 有如下幾個(gè)優(yōu)點(diǎn)：

• 第一咙咽，算子并行度和傳輸方式可控
• 第二，執(zhí)行圖直觀易于理解
• 第三淤年，狀態(tài)保存時(shí)間可以分別設(shè)置钧敞。

但在轉(zhuǎn)變到 SQL 的時(shí)候，會(huì)產(chǎn)生一些問題麸粮「瓤粒基于此，我們舉個(gè)例子豹休，來看一看為什么算子并行度和傳輸方式不可控了炊昆。

比如用戶定義了一個(gè) UDF 函數(shù)，用來處理 Kafka 數(shù)據(jù)源的某一個(gè)日志威根，然后將這個(gè)處理后的數(shù)據(jù)寫入下游的 MySQL 或者其他存儲(chǔ)凤巨。我們假定 Kafka 某一個(gè) Topic 分區(qū)有 10 個(gè)，整個(gè)任務(wù)的并行度設(shè)置為 20洛搀。這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)敢茁，UDF 實(shí)際只會(huì)處理 10 個(gè)并行度的數(shù)據(jù)。Flink SQL 需要怎樣才能拓展呢留美？

7

針對(duì)這種情況彰檬，我們當(dāng)前的解決方案是提供對(duì)執(zhí)行圖編輯的功能，按照編輯結(jié)果同 SQL 一起保存谎砾。如下圖所示逢倍，有三個(gè) Operator，Data Source Operator 的 ID=1景图，UDF Operator 的 ID=2较雕，Data Sink Operator 的 ID=3。

在這個(gè)過程中挚币，將整個(gè)作業(yè)的并行度設(shè)為 20亮蒋，Source 源 Operator1 的并行度設(shè)置為 10，1 和 2 之間的傳輸方式設(shè)為 rescale妆毕。然后在后端接收到后慎玖，同步將 Job Graph 進(jìn)行修改，就會(huì)得到如下的執(zhí)行圖笛粘，用戶就能夠比較好的解決掉這個(gè)問題了趁怔。

8

對(duì)于這個(gè)問題，未來我們的改進(jìn)思路是通過 SQL 利用 Hint 功能來實(shí)現(xiàn)薪前，或者更加智能化一點(diǎn)润努，根據(jù)作業(yè)指標(biāo)信息，自動(dòng)探測(cè)反壓節(jié)點(diǎn)序六，自動(dòng)化設(shè)置任连，來降低用戶的使用成本。

對(duì)于 Create View 邏輯視圖的含義是指什么呢例诀？我也用一個(gè)案例來加以說明随抠。從下圖可以看到，用戶自定義了一個(gè) UDF 函數(shù)模擬了一個(gè)數(shù)據(jù)源繁涂。我們將這個(gè)數(shù)據(jù)進(jìn)行解析拱她，創(chuàng)建 Create View，比如叫 Row Table扔罪，然后向下游兩個(gè)目標(biāo)表 SinkTable1 和 SinkTable2 寫入秉沼。最后看執(zhí)行圖，會(huì)發(fā)現(xiàn) UDF 函數(shù)被執(zhí)行了兩次。

9

目前我們針對(duì)這一個(gè)問題收集并提供了一些解決方案唬复。但在提供解決方案之前矗积，我想先闡述一下這個(gè)問題產(chǎn)生的原因。Flink SQL 利用 Apache calcite 進(jìn)行 SQL 語(yǔ)法解析敞咧，然后將解析后的 SQL 轉(zhuǎn)換成一個(gè)語(yǔ)法樹棘捣，經(jīng)過 Flink Planner 生成 RealNode，經(jīng)過 Optimizer Rule 進(jìn)入 Codegen 環(huán)節(jié)休建。之后實(shí)際代碼會(huì)有一個(gè) Physical Plan 的過程乍恐，經(jīng)過 Optimizer 形成 Steam Graph，然后轉(zhuǎn)化成 Job Graph测砂，最終轉(zhuǎn)化成 Execution Graph茵烈。

10

那么 View 是在哪一層級(jí)丟失的呢？其實(shí)是在 Apache calcite 語(yǔ)法解析的時(shí)候砌些，View 它只是一個(gè)邏輯輔助呜投，在這一過程會(huì)將其丟棄。那么我們?nèi)绾巫?View 這一信息被底層感知到呢寄症？

主要有兩個(gè)辦法:

• 辦法一是 SQL 解析的時(shí)候不丟失 View 信息

• 辦法二是在 RealNode 到 Optimizer Rule 能夠識(shí)別到 View 的特征信息宙彪，這樣就可以把 View 當(dāng)成一個(gè)真正的代碼去翻譯了

11

辦法一是一個(gè)非常好的解決辦法，但是需要對(duì) Apache calcite 進(jìn)行很多改動(dòng)有巧，實(shí)現(xiàn)難度比較大释漆，成本也比較高，所以采用了辦法二篮迎。最終的方案是采用識(shí)別特定函數(shù)實(shí)現(xiàn)男图，內(nèi)置了一個(gè) breakpoint 函數(shù)。在創(chuàng)建 View 的時(shí)候可以同時(shí)多 select 一個(gè) breakpoint甜橱，這樣在底層翻譯的時(shí)候逊笆，就可以把它當(dāng)成一個(gè)真正的 RealNode 處理。這個(gè)問題岂傲，未來我們是也是希望通過 SQL 利用 Hint 功能來實(shí)現(xiàn)难裆。

對(duì)于狀態(tài)的保存時(shí)間方面我們要怎么處理呢？以數(shù)據(jù)流關(guān)聯(lián) MySQL 分庫(kù)分表的數(shù)據(jù)舉例镊掖。常見的解決方案是利用 Flink CDC 將 MySQL 中的分庫(kù)分表數(shù)據(jù)乃戈，抽取寫入下游的 KV 存儲(chǔ)中，然后再通過另一個(gè) Flink SQL 任務(wù)接入 Kafka 關(guān)聯(lián)亩进，用時(shí)態(tài)表 Join 的方式將數(shù)據(jù)打?qū)捴⒙牵罱K輸出結(jié)果。

這一過程可能會(huì)有兩個(gè)問題归薛。第一谍憔，引入 HBase匪蝙，我們的任務(wù)就會(huì)從一個(gè)拆分成兩個(gè)。其次需要假定下面這條鏈路的速度快于流的速度习贫，否則上面 Topic 的數(shù)據(jù)到達(dá)的時(shí)候逛球，而維表的數(shù)據(jù)還沒到達(dá)就關(guān)聯(lián)不上。那么怎樣去解決這個(gè)問題沈条，也是我們思考的地方需忿。

12

我們采用的方案是用 Flink SQL+CDC+Regular Join 的方式來實(shí)現(xiàn)诅炉。接入還是一樣消費(fèi) Kafka蜡歹，通過 CDC 來消費(fèi)數(shù)據(jù)庫(kù)分庫(kù)分表的數(shù)據(jù)，最后通過正常的 Regular Join 來實(shí)現(xiàn)涕烧。

這里的 Regular join 底層同時(shí)依賴兩個(gè) MapState月而，比如 Topic A 對(duì)應(yīng) MapState 是 A，MySQL 里的數(shù)據(jù)庫(kù)的數(shù)據(jù)對(duì)應(yīng)的是 B议纯。如果我們能輕易的將 MapState B 的狀態(tài)設(shè)置為 0 或者不過期父款，那么這個(gè)狀態(tài)的數(shù)據(jù)就會(huì)被永久的保存下來。即使流的數(shù)據(jù)先到達(dá)了瞻凤，后面狀態(tài)數(shù)據(jù)到達(dá)也能觸發(fā)數(shù)據(jù)的關(guān)聯(lián)憨攒，從而比較好的解決這類問題。

具體的解決辦法是阀参，我們可以在 Flink SQL 中指定左右流 Join 的狀態(tài)時(shí)間肝集，在 Graph 中識(shí)別有 Join 的算子，最終透?jìng)鞯?Join 算子做狀態(tài)時(shí)間的設(shè)置蛛壳。

任務(wù)開發(fā)完成杏瞻，需要多少資源呢？線上流量波動(dòng)衙荐，出現(xiàn)延遲怎么辦捞挥？任務(wù)越來越多或任務(wù)并發(fā)調(diào)整，資源不足怎么辦忧吟？

針對(duì)這些問題砌函，我們對(duì)應(yīng)的解決辦法主要包含：靜態(tài)資源調(diào)優(yōu)、動(dòng)態(tài)資源調(diào)優(yōu)及擴(kuò)縮容溜族、資源彈性能力的建設(shè)讹俊。那么具體我們是怎么做的呢？下面請(qǐng)大家跟著我來一起來看一看斩祭。

13

舉個(gè)例子劣像，任務(wù)終于開發(fā)完成，通過了任務(wù)校驗(yàn)摧玫，但是任務(wù)參數(shù)耳奕，比如并行度绑青、Slot、內(nèi)存……該給多少才能正常運(yùn)行呢屋群？提供了如下三種 case：

• Case1：資源直接給足-->正常運(yùn)行-->結(jié)束--->資源浪費(fèi)

• Case2：資源不足-->反壓或者延遲嚴(yán)重-->反復(fù)調(diào)整資源-->費(fèi)時(shí)費(fèi)力

• Case3：指標(biāo)計(jì)算 Groupby-->托管內(nèi)存不足/增量 Checkpoint 沒開-->任務(wù)運(yùn)行一段時(shí)間失敗

綜上所述闸婴，三個(gè)案例的共性是任務(wù)調(diào)優(yōu)成本高，且對(duì)用戶本身有一定的能力要求芍躏。對(duì)此我們專門做了靜態(tài)資源調(diào)優(yōu)的解決辦法邪乍。

14

假定用戶開發(fā)了一個(gè) Flink SQL，第一個(gè)環(huán)節(jié)对竣，首先進(jìn)行語(yǔ)法校驗(yàn)庇楞，然后通過語(yǔ)法校驗(yàn)及后端生成 Stream Graph，拿到 Stream Graph 的同時(shí)我們還會(huì)進(jìn)行 Source/Sink 連通校驗(yàn)和參數(shù)初步調(diào)整否纬。

第二個(gè)環(huán)節(jié)吕晌，根據(jù)當(dāng)前的任務(wù)邏輯及流量合理的調(diào)整資源。首先探測(cè) Source 的流量临燃，然后拿這個(gè)值和用戶的作業(yè) SQL睛驳、Stream Graph 做 Optimizer。Optimizer 部分主要包括 Restart膜廊、HighAvailable乏沸、Checkpoint、Parallelism爪瓜、TaskManager蹬跃、JobManager、StateBackend钥勋。

通過不斷優(yōu)化炬转，得到一個(gè)比較好的任務(wù)資源參數(shù)，供用戶作為初始任務(wù)資源使用算灸。如果探測(cè)的資源流量較大扼劈，Sink 到 MySQL 的 Batch 設(shè)置較小，針對(duì)這種情況菲驴，我們會(huì)提醒 SQL 當(dāng)中的參數(shù)進(jìn)行調(diào)整荐吵，來幫助用戶更好的調(diào)整 SQL 任務(wù)的參數(shù)。

最終我們會(huì)給用戶提供給兩個(gè)視圖赊瞬，分別是 SQL 本身調(diào)整的預(yù)覽先煎、任務(wù)所依賴參數(shù)的調(diào)整預(yù)覽。如果用戶覺得 ok巧涧，就可以按照當(dāng)前的參數(shù)上線運(yùn)行了薯蝎。以上是靜態(tài)資源調(diào)優(yōu)。

那么任務(wù)上線后是什么情況呢谤绳？比如 Flink SQL 正常的 Running占锯，首先將指標(biāo)采集 Push 到 Kafka袒哥，然后會(huì)有實(shí)時(shí)任務(wù)進(jìn)行指標(biāo)的清洗聚合。針對(duì)重要的指標(biāo)消略，比如消費(fèi)延遲指標(biāo)堡称、算子速率指標(biāo)、JVM 進(jìn)程指標(biāo)艺演，狀態(tài)大小指標(biāo)等却紧。

這些指標(biāo)作為動(dòng)態(tài)資源調(diào)整服務(wù)的入?yún)ⅲ芗皶r(shí)感知到當(dāng)前任務(wù)的運(yùn)行狀況胎撤，然后動(dòng)態(tài)資源調(diào)整會(huì)進(jìn)行需求資源的申請(qǐng)晓殊，將任務(wù)重啟，并給用戶發(fā)送通知哩照。如果重啟失敗挺物，會(huì)進(jìn)行配置回滾，然后告知用戶調(diào)整失敗需要手工介入飘弧。

針對(duì)動(dòng)態(tài)資源調(diào)整，我們的場(chǎng)景大概有如下四個(gè)：

• 設(shè)定歷史數(shù)據(jù)追數(shù)：Kafka 積壓歷史數(shù)據(jù)初次消費(fèi)砚著、CDC 全量到增量次伶。

• 期望時(shí)間動(dòng)態(tài)調(diào)整：特定時(shí)間擴(kuò)縮容，解決活動(dòng)可預(yù)知的流量高峰稽穆。

• 根據(jù)指標(biāo)動(dòng)態(tài)調(diào)整：延遲或反壓及時(shí)調(diào)整冠王，預(yù)測(cè)流量變化提前調(diào)整。

• 異常指標(biāo)動(dòng)態(tài)調(diào)整：例如 JVM GC 頻繁舌镶，及時(shí)調(diào)整 TM 內(nèi)存柱彻。

如上就是我們想做的動(dòng)態(tài)資源調(diào)優(yōu)，最終實(shí)現(xiàn)的效果及具體的做法餐胀。

15

下面進(jìn)入彈性資源能力的建設(shè)哟楷。過去我們基于 Yarn On ECS 的方式，在擴(kuò)容的時(shí)候需要較長(zhǎng)的時(shí)間否灾。目前我們基于 Yarn On K8s 來實(shí)現(xiàn)的卖擅，在 Yarn Label 上我們會(huì)進(jìn)行三種隊(duì)列的設(shè)置打標(biāo)簽，固定資源隊(duì)列對(duì)應(yīng)的是正式任務(wù)墨技；彈性資源隊(duì)列對(duì)應(yīng)的是突發(fā)流量任務(wù)惩阶；搶占資源隊(duì)列對(duì)應(yīng)的是測(cè)試任務(wù)。

如果突然線上流量波動(dòng)扣汪，當(dāng)前任務(wù)的固定資源不足断楷。那么我們就可以將通過分鐘級(jí)的時(shí)效，將彈性資源隊(duì)列資源擴(kuò)出來崭别，然后將任務(wù)調(diào)度上去冬筒。這樣就避免了突發(fā)流量所帶來額外資源的消耗统刮，同時(shí)我們也不需要按照最高峰值流量去預(yù)估資源，只需按照常定的任務(wù)資源數(shù)量來設(shè)定底層所需要的資源账千。

未來我們將引進(jìn) Flink Native K8S侥蒙，希望借助 K8s 本身的資源管理能力提供資源彈性使用戶有較好的體驗(yàn)。

16

指標(biāo)體系在 Flink 任務(wù)中至關(guān)重要匀奏，主要包含任務(wù)可觀測(cè)鞭衩、動(dòng)態(tài)資源調(diào)優(yōu)和擴(kuò)縮容、調(diào)度任務(wù)依賴三個(gè)方面娃善。

• 第一论衍，任務(wù)可觀測(cè)方面，我們的做法是采集指標(biāo)到 Kafka聚磺，然后通過 Flink 清洗聚合寫入 Influxdb/MySQL坯台，Grafana 展示/指標(biāo)異常監(jiān)控告警。

• 第二瘫寝，動(dòng)態(tài)資源調(diào)整和擴(kuò)縮容的指標(biāo)應(yīng)用已經(jīng)前面說明蜒蕾，就不再贅述了。

• 第三焕阿，調(diào)度任務(wù)依賴咪啡，是指 Kafka/MysqlCDC 數(shù)據(jù)入湖，下游有離線調(diào)度依賴暮屡，我們需要感知當(dāng)前任務(wù)是否有延遲撤摸，Checkpoint 有沒有做，數(shù)據(jù)在數(shù)倉(cāng)里是否具有可見性褒纲，還需要保證數(shù)據(jù)完整入倉(cāng)入湖后准夷，下游任務(wù)才會(huì)啟動(dòng)。

17

分享兩個(gè)場(chǎng)景莺掠。第一個(gè)場(chǎng)景衫嵌，日志場(chǎng)景建設(shè)。當(dāng)數(shù)據(jù)量大汁蝶，入倉(cāng)時(shí)間多于 10 分鐘的時(shí)候渐扮，下游任務(wù)相應(yīng)增大，有沒有辦法縮短入倉(cāng)時(shí)間掖棉？當(dāng) HDFS 寫入流量波動(dòng)較大的時(shí)候墓律，能不能更加平穩(wěn)，且數(shù)據(jù)不丟不重幔亥？

眾所周知耻讽，從日志文件通過 Kafka 到 Flink SQL、寫入 Iceberg 都有可能產(chǎn)生數(shù)據(jù)重復(fù)帕棉，這一鏈路能保證數(shù)據(jù)不丟针肥，但較難保證數(shù)據(jù)不重饼记。

對(duì)此我們的方案是基于文件日志采集 MetaData Logs，然后將 MetaData Logs 在下游復(fù)用慰枕。其中 MetaData Logs 的文件的行數(shù)起到很重要的作用具则，因?yàn)檫@一鏈路能保證數(shù)據(jù)不丟。

如果數(shù)據(jù)的行數(shù)等于 MetaData Logs具帮，就代表這個(gè)數(shù)據(jù)沒有重復(fù)博肋，一旦數(shù)據(jù)行數(shù)多于 MetaData Logs，就代表這個(gè)數(shù)據(jù)有重復(fù)了蜂厅，但我們只需要基于重復(fù)的某一個(gè)文件日志進(jìn)行去重處理匪凡，而不需要對(duì)全量日志文件都進(jìn)行去重處理【蛟常基于這樣處理方式病游，我們發(fā)現(xiàn)入倉(cāng)時(shí)效從原來的 10-20 分鐘，降低到分鐘級(jí)別的延遲稠通。同時(shí)這一鏈路也能保證入倉(cāng)數(shù)據(jù)不丟不重衬衬，直接可用，等同于離線日志拉取 ETL 的場(chǎng)景采记。

針對(duì) Iceberg 表我們建立了 Iceberg Manager 來做小文件合并佣耐、過期快照清理、孤兒文件清理唧龄。

18

第二個(gè)場(chǎng)景，數(shù)據(jù)庫(kù)場(chǎng)景建設(shè)奸远。比如數(shù)據(jù)庫(kù)是 MySQL既棺，我們想通過 Flink CDC 將數(shù)據(jù)直接寫入 Iceberg V2 表。那么就會(huì)有如下幾方面的考慮：

• 多個(gè) Flink CDC 任務(wù)是否會(huì)對(duì)一個(gè) MySQL 讀壤僚选丸冕？數(shù)據(jù)庫(kù)是否會(huì)有壓力？已經(jīng)讀取的數(shù)據(jù)能否復(fù)用起來薛窥？

• Flink CDC 增量讀取胖烛，支持指定讀取的時(shí)間起點(diǎn)。

• IcebergV2 全量數(shù)據(jù)同步時(shí)诅迷，數(shù)據(jù)量較大佩番，容易產(chǎn)生了較多 Delete Files，輔助鏈路的 Iceberg Manager 在進(jìn)行表級(jí)別優(yōu)化的時(shí)候罢杉，就會(huì)產(chǎn)生較大的壓力趟畏。

• Flink CDC 同步任務(wù)太麻煩，希望配置化就生成好任務(wù)滩租，希望有一鍵數(shù)據(jù)入湖的能力赋秀。

19

基于此利朵，我們做了一個(gè)鏈路的輔助，一鍵任務(wù)生成猎莲。輔助自動(dòng)任務(wù)的調(diào)優(yōu)擴(kuò)縮容機(jī)制绍弟，保證 Flink CDC 全量同步和增量同步資源的切換問題，通過 Kafka 來實(shí)現(xiàn)對(duì)同一個(gè)數(shù)據(jù)源讀取時(shí)候的壓力問題著洼，將數(shù)據(jù)寫入 Kafka樟遣，Kafka 的數(shù)據(jù)會(huì)被下游的 Flink SQL 任務(wù)自動(dòng)感知并同步。

為了解決 Delete Files 全量數(shù)據(jù)過多的問題郭脂。我們?cè)谶M(jìn)行全量同步的時(shí)候年碘，會(huì)關(guān)閉寫入 Iceberg V2 表的 upsert 功能，在增量的時(shí)候才會(huì)開啟展鸡，這樣就可以保證全量同步的時(shí)候數(shù)據(jù)既不丟也不重屿衅。同時(shí)，F(xiàn)link SQL 任務(wù)增量數(shù)據(jù)會(huì)寫入 Iceberg V1 表莹弊，方便下游鏈路進(jìn)行復(fù)用涤久。

三、未來展望

未來 Flink SQL 或者平臺(tái)建設(shè)將圍繞以下四個(gè)方面進(jìn)行展開：

• 第一忍弛，批流一體响迂。大數(shù)據(jù)離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)分為兩套系統(tǒng)，一般離線數(shù)倉(cāng)通過 Spark细疚、Hive 來實(shí)現(xiàn)蔗彤，實(shí)時(shí)數(shù)倉(cāng)使用 Flink。隨著 Flink 批處理能力的不斷建設(shè)疯兼，我們認(rèn)為使用一套批流一體然遏，既能降低用戶成本，還能更方便的避免兩套引擎所帶來的指標(biāo)含義不同的影響吧彪。

• 第二待侵，資源彈性能力的建設(shè)。未來會(huì)基于 K8s 不斷引進(jìn)彈性資源能力姨裸，更好的提供給用戶使用秧倾。

• 第三，使用場(chǎng)景的建設(shè)傀缩，結(jié)合 Flink SQL 基于 Kafka 提供延遲消息的功能那先。

• 第四，近實(shí)時(shí)數(shù)倉(cāng) TableStore 的建設(shè)扑毡。TableStore 新版本發(fā)布胃榕，計(jì)劃先實(shí)踐起來，同時(shí)還將結(jié)合 Iceberg 不斷探索實(shí)踐，實(shí)現(xiàn)讓大家基于近實(shí)時(shí)數(shù)倉(cāng)勋又，就能夠得到時(shí)效性和確定性兩種融合的效果苦掘。

20

點(diǎn)擊查看直播回放 & 演講PPT