日均处理万亿数据！Flink在快手的应用实践与技术演进之路
董亭亭，快手大數(shù)據(jù)架構(gòu)實(shí)時(shí)計(jì)算引擎團(tuán)隊(duì)負(fù)責(zé)人。目前負(fù)責(zé) Flink 引擎在快手內(nèi)的研發(fā)、應(yīng)用以及周邊子系統(tǒng)建設(shè)。2013 年畢業(yè)于大連理工大學(xué)，曾就職于奇虎 360、58 集團(tuán)。主要研究領(lǐng)域包括：分布式計(jì)算、調(diào)度系統(tǒng)、分布式存儲(chǔ)等系統(tǒng)。
本次的分享包括以下三個(gè)部分：
一．Flink 在快手應(yīng)用場(chǎng)景與規(guī)模
1. Flink 在快手應(yīng)用場(chǎng)景
快手計(jì)算鏈路是從 DB/Binlog 以及 WebService Log 實(shí)時(shí)入到 Kafka 中，然后接入 Flink 做實(shí)時(shí)計(jì)算，其中包括實(shí)時(shí) ETL、實(shí)時(shí)分析、Interval Join 以及實(shí)時(shí)訓(xùn)練，最后的結(jié)果存到 Druid、ES 或者 HBase 里面，后面接入一些數(shù)據(jù)應(yīng)用產(chǎn)品；同時(shí)這一份 Kafka 數(shù)據(jù)實(shí)時(shí) Dump 一份到 Hadoop 集群，然后接入離線計(jì)算。
Flink 在快手應(yīng)用的類(lèi)別主要分為三大類(lèi)：
- 80% 統(tǒng)計(jì)監(jiān)控：實(shí)時(shí)統(tǒng)計(jì)，包括各項(xiàng)數(shù)據(jù)的指標(biāo)，監(jiān)控項(xiàng)報(bào)警，用于輔助業(yè)務(wù)進(jìn)行實(shí)時(shí)分析和監(jiān)控；
- 15% 數(shù)據(jù)處理：對(duì)數(shù)據(jù)的清洗、拆分、Join 等邏輯處理，例如大 Topic 的數(shù)據(jù)拆分、清洗；
- 5% 數(shù)據(jù)處理：實(shí)時(shí)業(yè)務(wù)處理，針對(duì)特定業(yè)務(wù)邏輯的實(shí)時(shí)處理，例如實(shí)時(shí)調(diào)度。
Flink 在快手應(yīng)用的典型場(chǎng)景包括：
- 快手是分享短視頻跟直播的平臺(tái)，快手短視頻、直播的質(zhì)量監(jiān)控是通過(guò) Flink 進(jìn)行實(shí)時(shí)統(tǒng)計(jì)，比如直播觀眾端、主播端的播放量、卡頓率、開(kāi)播失敗率等跟直播質(zhì)量相關(guān)的多種監(jiān)控指標(biāo)；
- 用戶(hù)增長(zhǎng)分析，實(shí)時(shí)統(tǒng)計(jì)各投放渠道拉新情況，根據(jù)效果實(shí)時(shí)調(diào)整各渠道的投放量；
- 實(shí)時(shí)數(shù)據(jù)處理，廣告展現(xiàn)流、點(diǎn)擊流實(shí)時(shí) Join，客戶(hù)端日志的拆分等；
- 直播 CDN 調(diào)度，實(shí)時(shí)監(jiān)控各 CDN 廠商質(zhì)量，通過(guò) Flink 實(shí)時(shí)訓(xùn)練調(diào)整各個(gè)CDN廠商流量配比。
2.Flink 集群規(guī)模
快手目前集群規(guī)模有 1500 臺(tái)左右，作業(yè)數(shù)量大約是 500 左右，日處理?xiàng)l目數(shù)總共有 1.7 萬(wàn)億，峰值處理?xiàng)l目數(shù)大約是 3.7 千萬(wàn)。集群部署都是 On Yarn 模式，分為離線集群和實(shí)時(shí)集群兩類(lèi)集群，其中離線集群混合部署，機(jī)器通過(guò)標(biāo)簽進(jìn)行物理隔離，實(shí)時(shí)集群是 Flink 專(zhuān)用集群，針對(duì)隔離性、穩(wěn)定性要求極高的業(yè)務(wù)部署。
二．快手 Flink 技術(shù)演進(jìn)
快手 Flink 技術(shù)演進(jìn)主要分為三部分：
1.場(chǎng)景優(yōu)化
1.1 Interval Join 應(yīng)用場(chǎng)景
Interval Join 在快手的一個(gè)應(yīng)用場(chǎng)景是廣告展現(xiàn)點(diǎn)擊流實(shí)時(shí) Join 場(chǎng)景：打開(kāi)快手 App 可能會(huì)收到廣告服務(wù)推薦的廣告視頻，用戶(hù)有時(shí)會(huì)點(diǎn)擊展現(xiàn)的廣告視頻。這樣在后端形成兩份數(shù)據(jù)流，一份是廣告展現(xiàn)日志，一份是客戶(hù)端點(diǎn)擊日志。這兩份數(shù)據(jù)需進(jìn)行實(shí)時(shí) Join，將 Join 結(jié)果作為樣本數(shù)據(jù)用于模型訓(xùn)練，訓(xùn)練出的模型會(huì)被推送到線上的廣告服務(wù)。該場(chǎng)景下展現(xiàn)以后 20 分鐘的點(diǎn)擊被認(rèn)為是有效點(diǎn)擊，實(shí)時(shí) Join 邏輯則是點(diǎn)擊數(shù)據(jù) Join 過(guò)去 20 分鐘展現(xiàn)。其中，展現(xiàn)流的數(shù)據(jù)量相對(duì)比較大，20 分鐘數(shù)據(jù)在 1 TB 以上。最初實(shí)時(shí) Join 過(guò)程是業(yè)務(wù)自己實(shí)現(xiàn)，通過(guò) Redis 緩存廣告展現(xiàn)日志，Kafka 延遲消費(fèi)客戶(hù)端點(diǎn)擊日志實(shí)現(xiàn) Join 邏輯，該方式缺點(diǎn)是實(shí)時(shí)性不高，并且隨著業(yè)務(wù)增長(zhǎng)需要堆積更多機(jī)器，運(yùn)維成本非常高?；?Flink 使用 Interval Join 完美契合此場(chǎng)景，并且實(shí)時(shí)性高，能夠?qū)崟r(shí)輸出 Join 后的結(jié)果數(shù)據(jù)，對(duì)業(yè)務(wù)來(lái)說(shuō)維護(hù)成本非常低，只需要維護(hù)一個(gè) Flink 作業(yè)即可。
1.2 Interval Join 場(chǎng)景優(yōu)化
1.2.1 Interval Join 原理：
Flink 實(shí)現(xiàn) Interval join 的原理：兩條流數(shù)據(jù)緩存在內(nèi)部 State 中，任意一數(shù)據(jù)到達(dá)，獲取對(duì)面流相應(yīng)時(shí)間范圍數(shù)據(jù)，執(zhí)行 joinFunction 進(jìn)行 Join。隨著時(shí)間的推進(jìn)，State 中兩條流相應(yīng)時(shí)間范圍的數(shù)據(jù)會(huì)被清理。
在前面提到的廣告應(yīng)用場(chǎng)景 Join 過(guò)去 20 分鐘數(shù)據(jù)，假設(shè)兩個(gè)流的數(shù)據(jù)完全有序到達(dá)，Stream A 作為展現(xiàn)流緩存過(guò)去 20 分鐘數(shù)據(jù)，Stream B 作為點(diǎn)擊流每來(lái)一條數(shù)據(jù)到對(duì)面 Join 過(guò)去 20 分鐘數(shù)據(jù)即可。
Flink 實(shí)現(xiàn) Interval Join：
KeyedStreamA.intervalJoin(KeyedStreamB).between(Time.minutes(0),Time.minutes(20)).process(joinFunction)1.2.2 狀態(tài)存儲(chǔ)策略選擇
關(guān)于狀態(tài)存儲(chǔ)策略選擇，生產(chǎn)環(huán)境狀態(tài)存儲(chǔ) Backend 有兩種方式：
在 Interval join 場(chǎng)景下，RocksDB 狀態(tài)存儲(chǔ)方式是將兩個(gè)流的數(shù)據(jù)存在兩個(gè) Column Family 里，RowKey 根據(jù) keyGroupId+joinKey+ts 方式組織。
1.2.3 RocksDB 訪問(wèn)性能問(wèn)題
Flink 作業(yè)上線遇到的第一個(gè)問(wèn)題是 RocksDB 訪問(wèn)性能問(wèn)題，表現(xiàn)為：
- 作業(yè)在運(yùn)行一段時(shí)間之后出現(xiàn)反壓，吞吐下降。
- 通過(guò) Jstack 發(fā)現(xiàn)程序邏輯頻繁處于 RocksDB get 請(qǐng)求處。
- 通過(guò) Top 發(fā)現(xiàn)存在單線程 CPU 持續(xù)被打滿。
進(jìn)一步對(duì)問(wèn)題分析，發(fā)現(xiàn)：該場(chǎng)景下，Flink 內(nèi)部基于 RocksDB State 狀態(tài)存儲(chǔ)時(shí)，獲取某個(gè) Join key 值某段范圍的數(shù)據(jù)，是通過(guò)前綴掃描的方式獲取某個(gè) Join key 前綴的 entries 集合，然后再判斷哪些數(shù)據(jù)在相應(yīng)的時(shí)間范圍內(nèi)。前綴掃描的方式會(huì)導(dǎo)致掃描大量的無(wú)效數(shù)據(jù)，掃描的數(shù)據(jù)大多緩存在 PageCache 中，在 Decode 數(shù)據(jù)判斷數(shù)據(jù)是否為 Delete 時(shí)，消耗大量 CPU。
以上圖場(chǎng)景為例，藍(lán)色部分為目標(biāo)數(shù)據(jù)，紅色部分為上下邊界之外的數(shù)據(jù)，前綴掃描時(shí)會(huì)過(guò)多掃描紅色部分無(wú)用數(shù)據(jù)，在對(duì)該大量無(wú)效數(shù)據(jù)做處理時(shí)，將單線程 CPU 消耗盡。
1.2.4 針對(duì) RocksDB 訪問(wèn)性能優(yōu)化
快手在 Interval join 該場(chǎng)景下對(duì) RocksDB 的訪問(wèn)方式做了以下優(yōu)化：
- 在 Interval join 場(chǎng)景下，是可以精確的確定需訪問(wèn)的數(shù)據(jù)邊界范圍。所以用全 Key 范圍掃描代替前綴掃描，精確拼出查詢(xún)上下邊界 Full Key 即 keyGroupId+joinKey+ts[lower,upper]。
- 范圍查詢(xún) RocksDB ，可以更加精確 Seek 到上下邊界，避免無(wú)效數(shù)據(jù)掃描和校驗(yàn)。
優(yōu)化后的效果：P99 查詢(xún)時(shí)延性能提升 10 倍，即 nextKey 獲取 RocksDB 一條數(shù)據(jù)， P99 時(shí)延由 1000 毫秒到 100 毫秒以?xún)?nèi)。 作業(yè)吞吐反壓?jiǎn)栴}進(jìn)而得到解決。
1.2.5 RocksDB 磁盤(pán)壓力問(wèn)題
Flink 作業(yè)上線遇到的第二個(gè)問(wèn)題是隨著業(yè)務(wù)的增長(zhǎng)， RocksDB 所在磁盤(pán)壓力即將達(dá)到上限，高峰時(shí)磁盤(pán) util 達(dá)到 90%，寫(xiě)吞吐在 150 MB/s。詳細(xì)分析發(fā)現(xiàn)，該問(wèn)題是由以下幾個(gè)原因疊加導(dǎo)致：
- Flink 機(jī)器選型為計(jì)算型，大內(nèi)存、單塊 HDD 盤(pán)，在集群規(guī)模不是很大的情況下，單個(gè)機(jī)器會(huì)有 4-5 個(gè)該作業(yè) Container，同時(shí)使用一塊 HDD 盤(pán)。
- RocksDB 后臺(tái)會(huì)頻繁進(jìn)行 Compaction 有寫(xiě)放大情況，同時(shí) Checkpoint 也在寫(xiě)磁盤(pán)。
針對(duì) RocksDB 磁盤(pán)壓力，快手內(nèi)部做了以下優(yōu)化：
- 針對(duì) RocksDB 參數(shù)進(jìn)行調(diào)優(yōu)，目的是減少 Compaction IO 量。優(yōu)化后 IO 總量有一半左右的下降。
- 為更加方便的調(diào)整 RocksDB 參數(shù)，在 Flink 框架層新增 Large State RocksDB 配置套餐。同時(shí)支持 RocksDBStateBackend 自定義配置各種 RocksDB 參數(shù)。
- 未來(lái)計(jì)劃，考慮將 State 用共享存儲(chǔ)的方式存儲(chǔ)，進(jìn)一步做到減少 IO 總量，并且快速Checkpoint 和恢復(fù)。
2.穩(wěn)定性改進(jìn)
首先介紹下視頻質(zhì)量監(jiān)控調(diào)度應(yīng)用背景，有多個(gè) Kafka Topic 存儲(chǔ)短視頻、直播相關(guān)質(zhì)量日志，包括短視頻上傳/下載、直播觀眾端日志，主播端上報(bào)日志等。Flink Job 讀取相應(yīng) Topic 數(shù)據(jù)實(shí)時(shí)統(tǒng)計(jì)各類(lèi)指標(biāo)，包括播放量、卡頓率、黑屏率以及開(kāi)播失敗率等。指標(biāo)數(shù)據(jù)會(huì)存到 Druid 提供后續(xù)相應(yīng)的報(bào)警監(jiān)控以及多維度的指標(biāo)分析。同時(shí)還有一條流是進(jìn)行直播 CDN 調(diào)度，也是通過(guò) Flink Job 實(shí)時(shí)訓(xùn)練、調(diào)整各 CDN 廠商的流量配比。以上 Kafka Topic 數(shù)據(jù)會(huì)同時(shí)落一份到 Hadoop 集群，用于離線補(bǔ)償數(shù)據(jù)。實(shí)時(shí)計(jì)算跟離線補(bǔ)數(shù)據(jù)的過(guò)程共用同一份 Flink 代碼，針對(duì)不同的數(shù)據(jù)源，分別讀取 Kafka 數(shù)據(jù)或 HDFS 數(shù)據(jù)。
2.1 數(shù)據(jù)源控速
視頻應(yīng)用場(chǎng)景下遇到的問(wèn)題是：作業(yè) DAG 比較復(fù)雜，同時(shí)從多個(gè) Topic 讀取數(shù)據(jù)。一旦作業(yè)異常，作業(yè)失敗從較早狀態(tài)恢復(fù)，需要讀取部分歷史數(shù)據(jù)。此時(shí)，不同 Source 并發(fā)讀取數(shù)據(jù)速度不可控，會(huì)導(dǎo)致 Window 類(lèi)算子 State 堆積、作業(yè)性能變差，最終導(dǎo)致作業(yè)恢復(fù)失敗。 另外，離線補(bǔ)數(shù)據(jù)，從不同 HDFS 文件讀數(shù)據(jù)同樣會(huì)遇到讀取數(shù)據(jù)不可控問(wèn)題。在此之前，實(shí)時(shí)場(chǎng)景下臨時(shí)解決辦法是重置 GroupID 丟棄歷史數(shù)據(jù)，使得從最新位置開(kāi)始消費(fèi)。
針對(duì)該問(wèn)題我們希望從源頭控制多個(gè) Source 并發(fā)讀取速度，所以設(shè)計(jì)了從 Source 源控速的策略。
Source 控速策略
Source 控速策略是 ：
- SourceTask 共享速度狀態(tài)提供給 JobManager。
- JobManager 引入 SourceCoordinator，該 Coordinator 擁有全局速度視角，制定相應(yīng)的策略，并將限速策略下發(fā)給 SourceTask。
- SourceTask 根據(jù) JobManager 下發(fā)的速度調(diào)節(jié)信息執(zhí)行相應(yīng)控速邏輯。
- 一個(gè)小細(xì)節(jié)是 DAG 圖有子圖的話， 不同子圖 Source 源之間互相不影響。
Source 控速策略詳細(xì)細(xì)節(jié)
SourceTask 共享狀態(tài)
- SourceTask 定期匯報(bào)狀態(tài)給 JobManager，默認(rèn) 10 s 間隔。
- 匯報(bào)內(nèi)容為。
協(xié)調(diào)中心 SourceCoordinator
- 限速閾值：最快并發(fā) Watermark - 最慢并發(fā) Watermark > ?t(默認(rèn) 5 分鐘)。只要在達(dá)到限速閾值情況下，才進(jìn)行限速策略制定。
- 全局預(yù)測(cè)：各并發(fā) targetWatermark=base+speed*time；Coordinator 先進(jìn)行全局預(yù)測(cè)，預(yù)測(cè)各并發(fā)接下來(lái)時(shí)間間隔能運(yùn)行到的 Watermark 位置。
- 全局決策：targetWatermark = 預(yù)測(cè)最慢 Watermark+?t/2；Coordinator 根據(jù)全局預(yù)測(cè)結(jié)果，取預(yù)測(cè)最慢并發(fā)的 Watermark 值再浮動(dòng)一個(gè)范圍作為下個(gè)周期全局限速?zèng)Q策的目標(biāo)值。
- 限速信息下發(fā)：。將全局決策的信息下發(fā)給所有的 Source task，限速信息包括下一個(gè)目標(biāo)的時(shí)間和目標(biāo)的 Watermark 位置。
以上圖為例，A 時(shí)刻，4 個(gè)并發(fā)分別到達(dá)如圖所示位置，為 A+interval 的時(shí)刻做預(yù)測(cè)，圖中藍(lán)色虛線為預(yù)測(cè)各并發(fā)能夠到達(dá)的位置，選擇最慢的并發(fā)的 Watermark 位置，浮動(dòng)范圍值為 Watermark + ?t/2 的時(shí)間，圖中鮮紅色虛線部分為限速的目標(biāo) Watermark，以此作為全局決策發(fā)給下游 Task。
SourceTask 限速控制
- SourceTask 獲取到限速信息后，進(jìn)行限速控制。
- 以 KafkaSource 為例，KafkaFetcher 獲取數(shù)據(jù)時(shí)，根據(jù)限速信息 Check 當(dāng)前進(jìn)度，確定是否需要限速等待。
該方案中，還有一些其他考慮，例如：
- 時(shí)間屬性：只針對(duì) EventTime 情況下進(jìn)行限速執(zhí)行。
- 開(kāi)關(guān)控制：支持作業(yè)開(kāi)關(guān)控制是否開(kāi)啟 Source 限速策略。
- DAG 子圖 Source 源之間互相不影響。
- 是否會(huì)影響 CheckPoint Barrier 下發(fā)。
- 數(shù)據(jù)源發(fā)送速度不恒定，Watermark 突變情況。
Source 控速結(jié)果
拿線上作業(yè)，使用 Kafka 從最早位置(2 days ago)開(kāi)始消費(fèi)。如上圖，不限速情況下State 持續(xù)增大，最終作業(yè)掛掉。使用限速策略后，最開(kāi)始 State 有緩慢上升，但是 State 大小可控，最終能平穩(wěn)追上最新數(shù)據(jù)，并 State 持續(xù)在 40 G 左右。
2.2 JobManager 穩(wěn)定性
關(guān)于 JobManager 穩(wěn)定性，遇到了兩類(lèi) Case，表現(xiàn)均為：JobManager 在大并發(fā)作業(yè)場(chǎng)景 WebUI 卡頓明顯，作業(yè)調(diào)度會(huì)超時(shí)。進(jìn)一步分析了兩種場(chǎng)景下的問(wèn)題原因。
場(chǎng)景一，JobManager 內(nèi)存壓力大問(wèn)題。JobManager 需要控制刪除已完成的 Checkpoint 在 HDFS 上的路徑。在 NameNode 壓力大時(shí)，Completed CheckPoint 路徑刪除慢，導(dǎo)致CheckPoint Path 在內(nèi)存中堆積。 原來(lái)刪除某一次 Checkpoint 路徑策略為：每刪除目錄下一個(gè)文件，需 List 該目錄判斷是否為空，如為空將目錄刪除。在大的 Checkpoint 路徑下， List 目錄操作為代價(jià)較大的操作。針對(duì)該邏輯進(jìn)行優(yōu)化，刪除文件時(shí)直接調(diào)用 HDFS delete(path,false) 操作，語(yǔ)義保持一致，并且開(kāi)銷(xiāo)小。
場(chǎng)景二，該 Case 發(fā)生在 Yarn Cgroup 功能上線之后，JobManager G1 GC 過(guò)程變慢導(dǎo)致阻塞應(yīng)用線程。AppMaster 申請(qǐng) CPU 個(gè)數(shù)硬編碼為1，在上線 Cgroup 之后可用的 CPU 資源受到限制。解決該問(wèn)題的方法為，支持 AppMaster 申請(qǐng) CPU 個(gè)數(shù)參數(shù)化配置。
2.3 作業(yè)頻繁失敗
機(jī)器故障造成作業(yè)頻繁失敗，具體的場(chǎng)景也有兩種：
場(chǎng)景一：磁盤(pán)問(wèn)題導(dǎo)致作業(yè)持續(xù)調(diào)度失敗。磁盤(pán)出問(wèn)題導(dǎo)致一些 Buffer 文件找不到。又因?yàn)?TaskManager 不感知磁盤(pán)健康狀況，會(huì)頻繁調(diào)度作業(yè)到該 TaskManager，作業(yè)頻繁失敗。
場(chǎng)景二：某臺(tái)機(jī)器有問(wèn)題導(dǎo)致 TaskManager 在某臺(tái)機(jī)器上頻繁出 Core，陸續(xù)分配新的 TaskManager 到這臺(tái)機(jī)器上，導(dǎo)致作業(yè)頻繁失敗。
針對(duì)機(jī)器故障問(wèn)題解決方法：
- 針對(duì)磁盤(pán)問(wèn)題，TaskManager 增加 DiskChecker 磁盤(pán)健康檢查，發(fā)現(xiàn)磁盤(pán)有問(wèn)題 TaskManager 自動(dòng)退出；
- 針對(duì)有些機(jī)器頻繁出現(xiàn) TaskManager 出現(xiàn)問(wèn)題，根據(jù)一定的策略將有問(wèn)題機(jī)器加到黑名單中，然后通過(guò)軟黑名單機(jī)制，告知 Yarn 盡量不要調(diào)度 Container 到該機(jī)器。
3.平臺(tái)化建設(shè)
3.1 平臺(tái)建設(shè)：
快手的平臺(tái)化建設(shè)主要體現(xiàn)在青藤作業(yè)托管平臺(tái)。通過(guò)該平臺(tái)可進(jìn)行作業(yè)操作、作業(yè)管理以及作業(yè)詳情查看等。作業(yè)操作包括提交、停止作業(yè)。作業(yè)管理包括管理作業(yè)存活、性能報(bào)警，自動(dòng)拉起配置等；詳情查看，包括查看作業(yè)的各類(lèi) Metric 等。
上圖為青藤作業(yè)托管平臺(tái)的一些操作界面。
3.2 問(wèn)題定位流程優(yōu)化：
我們也經(jīng)常需要給業(yè)務(wù)分析作業(yè)性能問(wèn)題，幫助業(yè)務(wù) debug 一些問(wèn)題，過(guò)程相對(duì)繁瑣。所以該部分我們也做了很多工作，盡量提供更多的信息給業(yè)務(wù)，方便業(yè)務(wù)自主分析定位問(wèn)題。首先，我們將所有 Metric 入 Druid，通過(guò) Superset 可從各個(gè)維度分析作業(yè)各項(xiàng)指標(biāo)。第二，針對(duì) Flink 的 WebUI 做了一些完善，支持 Web 實(shí)時(shí)打印 jstack，Web DAG 為各 Vertex 增加序號(hào)，Subtask 信息中增加各并發(fā) SubtaskId。第三，豐富異常信息提示，針對(duì)機(jī)器宕機(jī)等特定場(chǎng)景信息進(jìn)行明確提示。第四，新增各種 Metric。
三．未來(lái)計(jì)劃
快手的未來(lái)規(guī)劃主要分為兩個(gè)部分：
第一，目前在建設(shè)的 Flink SQL 相關(guān)工作。因?yàn)?SQL 能夠減少用戶(hù)開(kāi)發(fā)的成本，包括我們現(xiàn)在也在對(duì)接實(shí)時(shí)數(shù)倉(cāng)的需求，所以 Flink SQL 是我們未來(lái)計(jì)劃的重要部分之一。
第二，我們希望進(jìn)行一些資源上的優(yōu)化。目前業(yè)務(wù)在提作業(yè)時(shí)存在需求資源及并發(fā)預(yù)估不準(zhǔn)確的情況，可能會(huì)過(guò)多申請(qǐng)資源導(dǎo)致資源浪費(fèi)。另外如何提升整體集群資源的利用率問(wèn)題，也是接下來(lái)需要探索的問(wèn)題。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的日均处理万亿数据！Flink在快手的应用实践与技术演进之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 为什么选择Cassandra
- 下一篇： 编码方法论，赋能你我他