?摘要：本文整理自快手實(shí)時(shí)計(jì)算團(tuán)隊(duì)技術(shù)專家劉建剛在 Flink Forward Asia 2021 生產(chǎn)實(shí)踐專場(chǎng)的演講。主要內(nèi)容包括：

1. 快手 Flink 的歷史及現(xiàn)狀
2. Flink 容錯(cuò)能力提升
3. Flink 引擎控制與實(shí)踐
4. 快手批處理實(shí)踐
5. 未來(lái)規(guī)劃

01快手 Flink 的歷史與現(xiàn)狀

快手從 2018 年開(kāi)始對(duì) Flink 進(jìn)行深度整合，經(jīng)過(guò) 4 年發(fā)展，實(shí)時(shí)計(jì)算平臺(tái)逐漸完善并賦能周邊各種組件。

• 2018 年我們針對(duì) Flink 1.4 進(jìn)行了平臺(tái)化建設(shè)并大幅提升運(yùn)維管理能力，達(dá)到了生產(chǎn)可用。
• 2019 年我們開(kāi)始基于 1.6 版本進(jìn)行迭代開(kāi)發(fā)，很多業(yè)務(wù)都開(kāi)始實(shí)時(shí)化，比如優(yōu)化 interval join 為商業(yè)化等平臺(tái)帶來(lái)顯著收益、開(kāi)發(fā)實(shí)時(shí)多維分析加速超大多維報(bào)表的實(shí)時(shí)化，這一年我們的 Flink SQL 平臺(tái)也投入使用。
• 到了 2020 年，我們升級(jí)到 1.10，對(duì) sql 的功能進(jìn)行了非常多的完善，同時(shí)進(jìn)一步優(yōu)化 Flink 的核心引擎，保障了 Flink 的易用性、穩(wěn)定性、可維護(hù)性。
• 2021 年我們開(kāi)始發(fā)力離線計(jì)算，支持湖倉(cāng)一體的建設(shè)，進(jìn)一步完善 Flink 生態(tài)。

上圖是快手基于 Flink 的技術(shù)棧。

• 最核心、最底層是 Flink 的計(jì)算引擎，包括流計(jì)算和批處理，我們針對(duì)穩(wěn)定性和性能做了大量工作。
• 外面一層是跟 Flink 打交道的周邊組件，既有 Kafka、rocketMQ 等中間件，也有 ClickHouse、Hive 等數(shù)據(jù)分析工具，還有 Hudi 等數(shù)據(jù)湖的使用。用戶可以基于 Flink 和這些組件構(gòu)建各種應(yīng)用，涵蓋了實(shí)時(shí)、近實(shí)時(shí)、批處理的各種場(chǎng)景。
• 最外層是具體的使用場(chǎng)景，常見(jiàn)的有電商、商業(yè)化等視頻相關(guān)的業(yè)務(wù)方，應(yīng)用場(chǎng)景包含機(jī)器學(xué)習(xí)、多維分析等。另外還有很多技術(shù)部門(mén)基于 Flink 來(lái)實(shí)現(xiàn)數(shù)據(jù)的導(dǎo)入、轉(zhuǎn)換，比如 CDC、湖倉(cāng)一體等。

應(yīng)用規(guī)模上，我們有 50 萬(wàn) CPU 核，主要通過(guò) Yarn 和 K8s 的方式進(jìn)行資源托管，上面運(yùn)行著 2000+ 作業(yè)，峰值處理達(dá)到了 6億/秒，日處理?xiàng)l數(shù)達(dá)到了 31.7 萬(wàn)億，節(jié)假日或活動(dòng)的時(shí)候流量甚至?xí)丁?/p>

02容錯(cuò)能力提升

容錯(cuò)能力主要包含以下部分：

• 首先是單點(diǎn)恢復(fù)，支持任意多個(gè) task 失敗時(shí)的原地重啟，long-running 作業(yè)基本可以做到永不斷流；
• 其次，是集群故障的應(yīng)對(duì)，包含冷備、熱備以及 Kafka 雙集群的集成；最后是黑名單的使用。

Flink 為了做到 exactly-once，任何節(jié)點(diǎn)出現(xiàn)故障都需要重啟整個(gè)作業(yè)，全局重啟會(huì)帶來(lái)長(zhǎng)時(shí)間的停頓，最高可達(dá)十幾分鐘。有些場(chǎng)景不追求 exactly-once，比如推薦等實(shí)時(shí)場(chǎng)景，但它們對(duì)服務(wù)可用性的要求很高，無(wú)法容忍作業(yè)的斷流，還有模型訓(xùn)練等初始化很慢的場(chǎng)景，重啟時(shí)間特別長(zhǎng)，一旦重啟將會(huì)造成很大的影響。基于以上考慮，我們開(kāi)發(fā)了單點(diǎn)恢復(fù)功能。

上圖是單點(diǎn)恢復(fù)的基本原理。如圖有三個(gè) task，其中中間的 task 失敗了，那么首先 Flink 的主節(jié)點(diǎn)會(huì)重新調(diào)度中間的 task，此時(shí)上下游的 task 不會(huì)失敗，而是等待重連。等中間的 task 調(diào)度成功后，master 節(jié)點(diǎn)會(huì)通知下游的 task 去重連上游的 task，與此同時(shí)中間的 task 也會(huì)去連它上游的 task，通過(guò)重新構(gòu)建讀視圖來(lái)恢復(fù)數(shù)據(jù)的讀取。等上下游都連接成功后這個(gè)作業(yè)就可以正常工作了。

了解完基本原理，再來(lái)看一下線上多 task 恢復(fù)的案例。實(shí)際環(huán)境中經(jīng)常會(huì)出現(xiàn)多個(gè) task 同時(shí)失敗的情況，這個(gè)時(shí)候我們會(huì)按照拓?fù)漤樞騺?lái)逐個(gè)恢復(fù)失敗的 task，比如上圖中是按照從左往右的順序恢復(fù)。

這個(gè)功能上線之后，我們內(nèi)部有將近 100 個(gè)作業(yè)使用了這個(gè)功能，常規(guī)故障下作業(yè)都可以做到不斷流，即便出現(xiàn)小的流量波動(dòng)，業(yè)務(wù)也可以做到無(wú)感知，業(yè)務(wù)方徹底告別了服務(wù)斷流的噩夢(mèng)。

集群故障一旦發(fā)生就是致命性的，所有的數(shù)據(jù)都會(huì)流失，服務(wù)也會(huì)掛掉。我們的方案主要包含冷備、熱備，以及 Flink 和 Kafka 的雙集群集成。

冷備主要指的是對(duì)數(shù)據(jù)做備份，集群掛掉以后可以快速在另外一個(gè)集群?jiǎn)?dòng)計(jì)算任務(wù)。

如上圖，KwaiJobManager 是快手的作業(yè)管理服務(wù)，其中的 failover coordinator 主要負(fù)責(zé)故障處理。我們會(huì)把所有 jar 包等文件保存在 HDFS，所有的信息保存在 Mysql，這兩者都做到了高可用。作業(yè)運(yùn)行在主集群 ClusterA，線上用的是增量快照，會(huì)存在文件依賴的問(wèn)題，所以我們定期做 savepoint 并拷貝到備集群。為了避免文件過(guò)多，我們?cè)O(shè)置了定時(shí)刪除歷史快照。

一旦服務(wù)檢測(cè)到集群 A 故障，就會(huì)立刻在集群B啟動(dòng)作業(yè)，并從最近一次的快照恢復(fù)，確保了狀態(tài)不丟失。對(duì)于用戶來(lái)說(shuō)，只需要設(shè)置一下主備集群，剩下的全都交由平臺(tái)方來(lái)做，用戶全程對(duì)故障無(wú)感知。

熱備就是雙集群同時(shí)運(yùn)行一樣的任務(wù)。我們的熱備都是全鏈路的，Kafka 或者 ClickHouse 等都是雙跑。最上面的展示層只會(huì)使用其中一份結(jié)果數(shù)據(jù)做展示，一旦出現(xiàn)故障，展示層會(huì)立刻切換到另外一份數(shù)據(jù)，切換過(guò)程在一秒以內(nèi)，用戶全程無(wú)感知。

相比冷備，熱備需要等量的資源來(lái)備份運(yùn)行，但切換的速度更快，比較適用于春晚等要求極高的場(chǎng)景。

Flink 與 Kafka 的雙集群集成，主要是因?yàn)榭焓值?Kafka 都具備雙集群的能力，所以需要 Flink 支持讀寫(xiě)雙集群的 Kafka topic，這樣某個(gè) Kafka 集群掛掉時(shí)Flink可以在線無(wú)縫切換。如上圖所示，我們 Flink 對(duì) Kafka 雙集群做了抽象，一個(gè)邏輯上的 topic 底層對(duì)應(yīng)兩個(gè)物理上的 topic，里面由多個(gè) partition 組合而成，F(xiàn)link 消費(fèi)邏輯 topic 就相當(dāng)于同時(shí)讀取底層兩個(gè)物理 topic 的數(shù)據(jù)。

針對(duì)集群的各種變動(dòng)，我們?nèi)砍橄蟪闪?partition 上的擴(kuò)縮容，比如集群掛掉，可以看成是邏輯 topic 的 partition 縮容；單集群切雙集群，可以看成是邏輯 topic 的擴(kuò)容；topic 的遷移，可以看成邏輯 topic 先擴(kuò)容再縮容。這里我們都是按照雙集群來(lái)舉例，實(shí)際上無(wú)論是雙集群還是更多的集群，原理都是一樣的，我們都提供了支持。

出現(xiàn)以下兩種情況的時(shí)候需要使用黑名單功能。第一種是反復(fù)調(diào)度有故障的機(jī)器，導(dǎo)致作業(yè)頻繁失敗。另一種是機(jī)器因?yàn)橛布蚓W(wǎng)絡(luò)等原因，導(dǎo)致 Flink 個(gè)別節(jié)點(diǎn)卡主但未失敗。

針對(duì)第一種情況，我們開(kāi)發(fā)了閾值拉黑，如果作業(yè)在同一個(gè)機(jī)器上失敗或者多次部署閾值失敗，超過(guò)配置的閾值就會(huì)拉黑；針對(duì)第二種情況，我們建立了異常分類機(jī)制，針對(duì)網(wǎng)絡(luò)卡頓和磁盤(pán)卡頓情況，直接驅(qū)除容器并且拉黑機(jī)器。另外我們還對(duì)外暴露了拉黑接口，打通了運(yùn)維 Yarn 等外部系統(tǒng)，實(shí)現(xiàn)了實(shí)時(shí)拉黑。我們還以 Flink 黑名單為契機(jī)，建立了一套完整的硬件異常處理流程，實(shí)現(xiàn)了作業(yè)自動(dòng)遷移，全程自動(dòng)化運(yùn)維，用戶無(wú)感知。

03Flink 引擎控制與實(shí)踐

3.1 Flink實(shí)時(shí)控制?

針對(duì) long-running 的實(shí)時(shí)作業(yè)，用戶經(jīng)常需要作出變更比如調(diào)整參數(shù)來(lái)更改行為，還有一些系統(tǒng)運(yùn)維比如作業(yè)降級(jí)、修改日志級(jí)別等，這些變更都需要重啟作業(yè)來(lái)生效，有時(shí)會(huì)高達(dá)幾分鐘到幾十分鐘，在一些重要的場(chǎng)合，這是無(wú)法容忍的。比如在活動(dòng)期間或者排查問(wèn)題的關(guān)鍵點(diǎn)，作業(yè)一旦停止將會(huì)功虧一簣，所以我們需要在不停止作業(yè)的情況下實(shí)時(shí)調(diào)整作業(yè)的行為，也就是實(shí)時(shí)控制。

從更廣泛的角度來(lái)看，F(xiàn)link 不僅是計(jì)算任務(wù)，也是一個(gè) long-running service。我們的實(shí)時(shí)控制正是基于這樣的考慮，來(lái)為實(shí)時(shí)計(jì)算提供交互式的控制模式。如上圖所示，用戶通過(guò)經(jīng)典的 kv 數(shù)據(jù)類型與 Flink dispatcher 交互，F(xiàn)link 收到消息后，會(huì)先將它們持久化到 zk 用于 failover，然后根據(jù)具體的消息做相應(yīng)的控制，比如控制 resource manager、控制 job master 或者其他組件。

我們既支持用戶自定義動(dòng)態(tài)參數(shù)，也為用戶提供了很多現(xiàn)成的系統(tǒng)控制。用戶自定義主要是使用 RichFunction 來(lái)獲取動(dòng)態(tài)參數(shù)，并且實(shí)現(xiàn)相應(yīng)的邏輯，這樣在作業(yè)運(yùn)行的時(shí)候就可以實(shí)時(shí)傳入?yún)?shù)，達(dá)到實(shí)時(shí)控制的效果。

系統(tǒng)提供的實(shí)時(shí)控制能力，主要包含數(shù)據(jù)源限速、采樣、重置 Kafka offset、調(diào)整快照參數(shù)以及運(yùn)維相關(guān)的更改日志級(jí)別、拉黑節(jié)點(diǎn)等功能。除此之外，我們還支持動(dòng)態(tài)修改部分 Flink 原生配置。

快手內(nèi)部對(duì)實(shí)時(shí)控制功能實(shí)現(xiàn)了產(chǎn)品化，用戶使用起來(lái)非常方便。

3.2 源端控制能力?

Flink 處理歷史任務(wù)或者作業(yè)性能跟不上的的時(shí)候，會(huì)引發(fā)以下的問(wèn)題:

首先 source 的各個(gè)并發(fā)處理速度不一致，會(huì)進(jìn)一步加重?cái)?shù)據(jù)的亂序、丟失、對(duì)齊慢等問(wèn)題。其次，快照會(huì)持續(xù)變大，嚴(yán)重影響作業(yè)性能。另外還有流量資源的不可控，在高負(fù)載的情況下會(huì)引發(fā) CPU 打滿、oom 等穩(wěn)定性問(wèn)題。

由于 Flink 是一種 pipeline 實(shí)時(shí)計(jì)算，因此從數(shù)據(jù)源入手可以從根本上解決問(wèn)題。

首先來(lái)看下歷史數(shù)據(jù)精準(zhǔn)回放功能。上圖是以二倍速率去消費(fèi) Kafka 的歷史數(shù)據(jù)，F(xiàn)link 作業(yè)追上 lag 之后就可以轉(zhuǎn)成實(shí)時(shí)消費(fèi)。通過(guò)這種方式可以有效解決復(fù)雜任務(wù)的穩(wěn)定性問(wèn)題。

上圖的公式是一個(gè)基本原理，消費(fèi)倍率 = Kafka 的時(shí)間差 / Flink 的系統(tǒng)時(shí)間差，用戶使用的時(shí)候只需要配置倍率即可。

另外一個(gè)能力是 QPS 限速。數(shù)據(jù)流量很大的時(shí)候，會(huì)導(dǎo)致 Flink 的負(fù)載很高以及作業(yè)不穩(wěn)定。我們基于令牌桶算法，實(shí)現(xiàn)了一套分布式的限速策略，可以有效減緩 Flink 的壓力。使用 QPS 限速后，作業(yè)變得非常健康，上圖綠色部分可見(jiàn)。19 年的春晚大屏，我們就是通過(guò)這個(gè)技術(shù)實(shí)現(xiàn)了柔性可用的保障。

另外我們還支持自動(dòng)適配 partition 的變更和實(shí)時(shí)控制，用戶可以隨時(shí)隨地調(diào)整作業(yè)的 QPS。

最后一個(gè)功能是數(shù)據(jù)源對(duì)齊，主要指 watermark 的對(duì)齊。首先每個(gè) subtask 都會(huì)定期向主節(jié)點(diǎn)匯報(bào)自己的 watermark 進(jìn)度，主要包括 watermark 的大小和速度。主節(jié)點(diǎn)會(huì)計(jì)算下一個(gè)周期的 target，即預(yù)期的最大 watermark，再加一個(gè) diff 返回給各個(gè)節(jié)點(diǎn)。各個(gè) source task 會(huì)保證下一個(gè)周期的 watermark 不超過(guò)設(shè)置的 target。上圖最下面是 target 的計(jì)算公式，預(yù)測(cè)每個(gè) task 下個(gè)周期結(jié)束時(shí)候的 waterMark 值，再加上我們?cè)试S的 maxdiff 然后取最大值，通過(guò)這種方式可以保障各個(gè) source 的進(jìn)度一致，避免 diff 過(guò)大導(dǎo)致的穩(wěn)定性問(wèn)題。

3.3 作業(yè)均衡調(diào)度

生產(chǎn)環(huán)境中經(jīng)常會(huì)出現(xiàn)資源不均衡的現(xiàn)象，比如第一點(diǎn) Flink 的 task 分布不均勻，導(dǎo)致 task manager 資源使用不均衡，而作業(yè)的性能又往往受限于最繁忙的節(jié)點(diǎn)。針對(duì)這個(gè)問(wèn)題，我們開(kāi)發(fā)了作業(yè)均衡調(diào)度的策略；第二點(diǎn)是 CPU 使用不均衡，有些機(jī)器被打滿而有些機(jī)器很閑。針對(duì)這個(gè)問(wèn)題，我們開(kāi)發(fā)了 CPU 均衡調(diào)度的功能。

上圖中有三個(gè) jobVertex，通過(guò) hash shuffle 的方式來(lái)連接。上圖中間部分顯示了 Flink 的調(diào)度，每個(gè) jobVertex 都是自上而下往 slot 里調(diào)度 task，結(jié)果就是前兩個(gè) slot 很滿而其他 slot 很空閑，第一個(gè) task manager 很滿而第二個(gè) task manager 很空閑。這是一個(gè)很典型的資源傾斜的場(chǎng)景，我們對(duì)此進(jìn)行了優(yōu)化。調(diào)度的時(shí)候首先計(jì)算需要的總資源，也就是需要多少個(gè) task manager，然后計(jì)算每個(gè) TM 分配的 slot 個(gè)數(shù)，確保 TM 中的 slot 資源均衡。最后均衡分配 task 到各個(gè) slot 中，確保 slot 中 task 均衡。

實(shí)際運(yùn)行過(guò)程中還存在另外一種傾斜情況 —— CPU 傾斜，我們來(lái)看下怎么解決這個(gè)問(wèn)題。上圖左側(cè)，用戶申請(qǐng)了一個(gè)核但實(shí)際只使用了 0.5 個(gè)核，也有申請(qǐng)了一個(gè)核實(shí)際使用了一個(gè)核。按照默認(rèn)調(diào)度策略，大量此類 case 可能會(huì)導(dǎo)致有的機(jī)器 CPU 使用率很高，有的卻很閑，負(fù)載高的機(jī)器不論是性能還是穩(wěn)定性都會(huì)比較差。那么如何讓申請(qǐng)和使用的 diff 盡可能小？

我們的方案是對(duì)作業(yè)資源精準(zhǔn)畫(huà)像，具體做法分為以下步驟：作業(yè)運(yùn)行過(guò)程中統(tǒng)計(jì)每個(gè) task 所在容器的 CPU 使用率，然后建立 task 到 executionSlotSharingGroup，再到 container 的映射，這樣就知道了每個(gè) task 所在 slot 的 CPU 使用情況，然后根據(jù)映射關(guān)系重啟作業(yè)，根據(jù) task 所在 slot 的歷史 CPU 使用率來(lái)申請(qǐng)相應(yīng)的資源，一般來(lái)說(shuō)會(huì)預(yù)留一些 buffer。如上圖右圖所示，如果預(yù)測(cè)足夠準(zhǔn)，重啟后 task manager 使用的資源不變，但是申請(qǐng)值變小了，二者的 diff 就變小了。

其實(shí)業(yè)界一些先進(jìn)的系統(tǒng)，比如 borg 是支持動(dòng)態(tài)修改申請(qǐng)值的，但我們的底層調(diào)度資源不持這種策略，所以只能在 Flink 這一層使用資源畫(huà)像來(lái)解決這個(gè)問(wèn)題。當(dāng)然資源畫(huà)像不能保證百分百準(zhǔn)確，我們還有其他策略，比如限制高 CPU 負(fù)載的機(jī)器繼續(xù)分配資源，盡可能減少不均衡。另外我們還建立了分級(jí)保障制度，不同優(yōu)先級(jí)的作業(yè)有不同的 cgroup 限制，比如低優(yōu)先級(jí)作業(yè)不再超配，高優(yōu)先級(jí)作業(yè)允許少量超配，從而避免 CPU 使用過(guò)多導(dǎo)致的不均衡。

04快手批處理實(shí)踐

上圖是我們的批處理架構(gòu)圖。最底層為離線集群，中間是 Flink 引擎以及 Flink 的 data stream API、SQL API，再上面是一些平臺(tái)方比如 sql 入口、定時(shí)調(diào)度平臺(tái)等，此外還有一些流批一體的探索，最上面是各種用戶比如視頻、商業(yè)化等。

流批一體中，流的特性是低延時(shí)，批的特性是高吞吐。針對(duì)流批一體，我們期待系統(tǒng)既能處理 unfield batch 數(shù)據(jù)，也可以調(diào)整數(shù)據(jù)塊的 shuffle 大小等來(lái)均衡作業(yè)的吞吐和時(shí)延。

快手內(nèi)部對(duì)流批一體進(jìn)行了很多探索，我們?yōu)榇鎯?chǔ)數(shù)據(jù)建立了統(tǒng)一的 Schema 標(biāo)準(zhǔn)，包括流表和批表，用戶可以使用相同的代碼來(lái)處理流表和批表，只是配置不同。產(chǎn)生的結(jié)果也需要符合統(tǒng)一的 Schema 標(biāo)準(zhǔn)，這樣就可以打通上下游，實(shí)現(xiàn)盡可能多的邏輯復(fù)用。Schema 統(tǒng)一是我們快手?jǐn)?shù)據(jù)治理的一部分，湖倉(cāng)一體等場(chǎng)景也都有這個(gè)需求。

應(yīng)用場(chǎng)景主要包括以下幾個(gè)方面：

• 指標(biāo)計(jì)算，比如實(shí)時(shí)指標(biāo)和報(bào)表計(jì)算。
• 數(shù)據(jù)回溯，利用已有的離線數(shù)據(jù)重新生成其他指標(biāo)。
• 數(shù)倉(cāng)加速，主要是數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的實(shí)時(shí)加速。

流批一體帶來(lái)的收益是多方面的，首先是降低了開(kāi)發(fā)和運(yùn)維成本，實(shí)現(xiàn)了盡可能多的代碼邏輯復(fù)用，運(yùn)維不再需要維護(hù)多個(gè)系統(tǒng)。其次是實(shí)時(shí)處理和批處理的口徑保持一致，保障了最終結(jié)果的一致。最后是資源方面的收益，有些場(chǎng)景只需要一套實(shí)時(shí)系統(tǒng)。

我們?cè)谡{(diào)度方面進(jìn)行了優(yōu)化。如上圖所示的三個(gè) task，起初 a 和 c 已經(jīng)完成，b 還在運(yùn)行。這時(shí) a 失敗了，按照默認(rèn)的策略 ABC 都需要重新運(yùn)行，即便 c 已經(jīng)完成。在實(shí)際場(chǎng)景中會(huì)有大量的 c 進(jìn)行重算，帶來(lái)巨大的資源損耗。針對(duì)這種情況如果，我們默認(rèn)開(kāi)啟了以下策略：如果 a 的結(jié)果是決定性的（實(shí)際上大部分批處理的輸出都是決定性的），可以不再重算 c，只需計(jì)算 a 和 b。

上圖是我們快手內(nèi)部針對(duì)批處理的優(yōu)化和改進(jìn)。

第一個(gè)是 shuffle service，現(xiàn)在既有內(nèi)部的集成，也在試用社區(qū)的版本，主要是為了實(shí)現(xiàn)存儲(chǔ)和計(jì)算的解耦，同時(shí)提高 shuffle 的性能。第二個(gè)是動(dòng)態(tài)資源的調(diào)度，主要是根據(jù)數(shù)據(jù)量來(lái)自動(dòng)決定算子的并發(fā)，避免人工反復(fù)調(diào)整。第三個(gè)是慢節(jié)點(diǎn)規(guī)避，也叫推測(cè)執(zhí)行，主要是為了減少長(zhǎng)尾效應(yīng)，減少總執(zhí)行時(shí)間。第四個(gè)是 hive 的優(yōu)化，比如 UDF 適配、語(yǔ)法兼容。另外針對(duì) partition 生成 split，我們?cè)黾恿司彺妗⒍嗑€程生成等方式，極大減少了分片的時(shí)間。最后是一些壓縮方式的支持，比如支持 gzip、zstd 等。

05未來(lái)規(guī)劃

我們的未來(lái)規(guī)劃主要分為以下幾個(gè)方面：

• 首先是實(shí)時(shí)計(jì)算，進(jìn)一步增強(qiáng) Flink 的性能、穩(wěn)定性和應(yīng)用性，并通過(guò)實(shí)時(shí)計(jì)算來(lái)加速各種業(yè)務(wù)場(chǎng)景。
• 第二個(gè)是在線和離線的統(tǒng)一，包含實(shí)時(shí)、近實(shí)時(shí)和批處理。我們期待能用 Flink 統(tǒng)一快手的數(shù)據(jù)同步、轉(zhuǎn)換和在離線計(jì)算，讓ETL、數(shù)倉(cāng)、數(shù)據(jù)湖處理等各類場(chǎng)景，都使用一套 Flink 計(jì)算系統(tǒng)。
• 最后一個(gè)是彈性可伸縮，主要是云原生相關(guān)，包含在離線混部和作業(yè)的彈性伸縮等。?