作者：董亭亭

作為短視頻分享跟直播的平臺(tái)，快手有諸多業(yè)務(wù)場(chǎng)景應(yīng)用了 Flink，包括短視頻、直播的質(zhì)量監(jiān)控、用戶增長(zhǎng)分析、實(shí)時(shí)數(shù)據(jù)處理、直播 CDN 調(diào)度等。 本文將從 Flink 在快手的應(yīng)用場(chǎng)景以及目前規(guī)模、Flink 在落地過(guò)程的技術(shù)演進(jìn)過(guò)程、未來(lái)計(jì)劃這三個(gè)方面詳細(xì)介紹 Flink 在快手的應(yīng)用與實(shí)踐。

一.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)用的類別主要分為三大類：

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);

用戶增長(zhǎng)分析，實(shí)時(shí)統(tǒng)計(jì)各投放渠道拉新情況，根據(jù)效果實(shí)時(shí)調(diào)整各渠道的投放量;

實(shí)時(shí)數(shù)據(jù)處理，廣告展現(xiàn)流、點(diǎn)擊流實(shí)時(shí) Join，客戶端日志的拆分等;

直播 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í)集群兩類集群，其中離線集群混合部署，機(jī)器通過(guò)標(biāo)簽進(jìn)行物理隔離，實(shí)時(shí)集群是 Flink 專用集群，針對(duì)隔離性、穩(wěn)定性要求極高的業(yè)務(wù)部署。

二.快手 Flink 技術(shù)演進(jìn)

快手 Flink 技術(shù)演進(jìn)主要分為三部分：

基于特定場(chǎng)景優(yōu)化，包括 Interval Join 場(chǎng)景優(yōu)化;

穩(wěn)定性改進(jìn)，包括數(shù)據(jù)源控速、JobManager 穩(wěn)定性、作業(yè)頻繁失敗;

平臺(tái)建設(shè)。

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ù)推薦的廣告視頻，用戶有時(shí)會(huì)點(diǎn)擊展現(xiàn)的廣告視頻。這樣在后端形成兩份數(shù)據(jù)流，一份是廣告展現(xiàn)日志，一份是客戶端點(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)客戶端點(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 有兩種方式：

FsStateBackend：State 存儲(chǔ)在內(nèi)存，Checkpoint 時(shí)持久化到 HDFS;

RocksDBStateBackend：State 存儲(chǔ)在 RocksDB 實(shí)例，可增量 Checkpoint，適合超大 State。在廣告場(chǎng)景下展現(xiàn)流 20 分鐘數(shù)據(jù)有 1 TB 以上，從節(jié)省內(nèi)存等方面綜合考慮，快手最終選擇的是 RocksDBStateBackend。

在 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)景下，F(xiàn)link 內(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 范圍掃描代替前綴掃描，精確拼出查詢上下邊界 Full Key 即 keyGroupId+joinKey+ts[lower,upper]。

范圍查詢 RocksDB ，可以更加精確 Seek 到上下邊界，避免無(wú)效數(shù)據(jù)掃描和校驗(yàn)。

優(yōu)化后的效果：P99 查詢時(shí)延性能提升 10 倍，即 nextKey 獲取 RocksDB 一條數(shù)據(jù)， P99 時(shí)延由 1000 毫秒到 100 毫秒以內(nèi)。 作業(yè)吞吐反壓?jiǎn)栴}進(jìn)而得到解決。

1.2.5 RocksDB 磁盤壓力問(wèn)題

 

 

Flink 作業(yè)上線遇到的第二個(gè)問(wèn)題是隨著業(yè)務(wù)的增長(zhǎng)， RocksDB 所在磁盤壓力即將達(dá)到上限，高峰時(shí)磁盤 u’ti’l 達(dá)到 90%，寫吞吐在 150 MB/s。詳細(xì)分析發(fā)現(xiàn)，該問(wèn)題是由以下幾個(gè)原因疊加導(dǎo)致：

Flink 機(jī)器選型為計(jì)算型，大內(nèi)存、單塊 HDD 盤，在集群規(guī)模不是很大的情況下，單個(gè)機(jī)器會(huì)有 4-5 個(gè)該作業(yè) Container，同時(shí)使用一塊 HDD 盤。

RocksDB 后臺(tái)會(huì)頻繁進(jìn)行 Compaction 有寫放大情況，同時(shí) Checkpoint 也在寫磁盤。

針對(duì) RocksDB 磁盤壓力，快手內(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ì)各類指標(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 類算子 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)定性，遇到了兩類 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)銷小。

場(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)景一：磁盤問(wèn)題導(dǎo)致作業(yè)持續(xù)調(diào)度失敗。磁盤出問(wèn)題導(dǎo)致一些 Buffer 文件找不到。又因?yàn)?TaskManager 不感知磁盤健康狀況，會(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ì)磁盤問(wèn)題，TaskManager 增加 DiskChecker 磁盤健康檢查，發(fā)現(xià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è)的各類 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 能夠減少用戶開(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)題。

作者介紹：董亭亭，快手大數(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)。

標(biāo)簽： 處理數(shù)據(jù) 數(shù)據(jù)處理

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。