青青免费在线视频,日本视频不卡不卡,日本破处视频,国产黄片免费在线观看,天天肏天天干,国产精品人妻熟女毛片av,久久精品内射国产,亚洲天堂在线观看一区

摘要：本文整理自 bilibili 資深開發(fā)工程師張楊，在 Flink Forward Asia 2022 核心技術(shù)專場的分享。本篇內(nèi)容主要分為四個部分：

1. 相關(guān)背景

2. state 壓縮優(yōu)化

3. Remote state 探索

4. 未來規(guī)劃

Tips：點擊「閱讀原文」免費領(lǐng)取 5000CU*小時 Flink 云資源

相關(guān)背景

1.1 業(yè)務(wù)概況

業(yè)務(wù)規(guī)模，B 站目前大約是 4000+的 Flink 任務(wù)，其中 95%是 SQL 類型。
部署模式，B 站有 80%的部署是 on yarn application 部署，我們的 yarn 集群和離線的 yarn 是分開的，是實時專用的 yarn 集群。剩下的 20%作業(yè)，為了響應(yīng)公司降本增效的號召，目前是在線集群混部。這個方案的采用主要是從成本考慮，目前在使用 yarn on docker。
state 使用情況，平臺默認(rèn)開啟的全部是 rocksdb statebackend，大概有 50%的任務(wù)都是帶狀態(tài)的，其中有上百個任務(wù)的狀態(tài)超過了 500GB，這種任務(wù)我們稱之為超大狀態(tài)的 state 任務(wù)。

1.2 statebackend 痛點

主要痛點有 3 個：

cpu 抖動大。rocksdb 的原理決定了它一定會有一個 compaction 的操作。目前，在小狀態(tài)下這種操作對任務(wù)本身沒什么影響，但是在大狀態(tài)下，尤其是超過 500GB 左右，compaction 會造成 cpu 抖動大，峰值資源要求高。尤其是在 5、10、15 分鐘這種 checkpoint 的整數(shù)被間隔的情況下，整個 cpu 的起伏會比較高。對于一個任務(wù)來說，它的峰值資源要求會比較高。如果我們的資源滿足不了峰值資源的需求，任務(wù)就會觸發(fā)一陣陣的堆積和消積的情況。
恢復(fù)時間長。因為 rocksdb 是一個嵌入式的 DB 存儲，每次重啟或者任務(wù)的 rescale 狀態(tài)恢復(fù)時間長。因為它要把很大的文件下載下來，然后再在本地進(jìn)行一些重新的 reload，這就需要一些大量的掃描工作，所以會導(dǎo)致整個任務(wù)的狀態(tài)恢復(fù)時間比較長。觀察下來，正常來說大任務(wù)基本需要 5 分鐘左右才能恢復(fù)平穩(wěn)的狀態(tài)。
rocksdb 非常依賴本地磁盤。rocksdb 是嵌入式的 DB，所以會非常依賴本地 io 的能力。由于今年公司有降本增效的策略，我們也會在線推薦一些混部，因為 Flink 的帶狀態(tài)任務(wù)有對本地 io 依賴的特點，對于混部來講是沒法用的，這就導(dǎo)致我們使用混部的資源是非常有限的。

主要通過兩個方面解決這些痛點:

第一個是 state 壓縮。出于對如何降低 compaction 開銷的思考，對任務(wù)進(jìn)行了一些 cpu 火焰圖的分析。通過分析發(fā)現(xiàn)，整個 cpu 的消耗主要在 2 個方面，一個是 compaction，一個是壓縮數(shù)據(jù)的換進(jìn)換出，這就會帶來大量的壓縮和解壓縮的工作。所以我們在壓縮層做了一些工作。
第二個是基于云原生的部署。由于本地沒有 io 能力，我們參考了一些云原生的方案，把整個本地的 rocksdb backend 進(jìn)行了 Remote state 的升級。這相當(dāng)于上面的一個存算分離，然后遠(yuǎn)程進(jìn)行了服務(wù)化的操作。這樣就可以實現(xiàn)即連即用，不需要進(jìn)行 reload 的操作，整個 state 是基于遠(yuǎn)程化進(jìn)行的。

state 壓縮優(yōu)化

2.1 業(yè)務(wù)場景

從業(yè)務(wù)場景角度來看，大 state 分析下來，它主要集中于模型訓(xùn)練和樣本拼接。我們的商業(yè)化和 AI 推薦部門就是這種典型的應(yīng)用場景。它的特點就是 key 數(shù)據(jù)量龐大，分布稀疏，很難命中 cache。且數(shù)據(jù) ttl 短，基本都是小時級。

如下右圖所示，整個業(yè)務(wù)的模型包含展現(xiàn)和點擊。通過這兩個動作我們進(jìn)行了校驗，然后完成計算，從而生成樣本，再灌入模型進(jìn)行訓(xùn)練。這個場景下它的特點是緩存失效就很快失效，它的 key 數(shù)量比較大且比較稀疏。

第二個點是數(shù)據(jù)的提交比較短，那么整個緩存的失效會比較快，這樣就會導(dǎo)致 rocksdb 在使用的時候會反復(fù)從磁盤里不斷地 reload 數(shù)據(jù)，然后進(jìn)行壓縮和解壓縮，或者中間 compaction 數(shù)據(jù)不斷地過期，導(dǎo)致 compaction 過于頻繁。

2.2 優(yōu)化思路

以上兩個問題會導(dǎo)致整個 cpu 的消耗非常高，所以我們能觀察到，在前面提及的整個任務(wù)的峰值 cpu 消耗會非常高。我們的優(yōu)化思路是通過包括對社區(qū)的一些方案和業(yè)界其他公司分享的一些文章進(jìn)行的調(diào)研，調(diào)研和優(yōu)化方案主要圍繞三個方面進(jìn)行：

第一個是開啟 partitoned index filter，減少緩存競爭。從火焰圖中可以看到，data block 會不斷地從 block cache 中被換進(jìn)換出，同時產(chǎn)生大量的壓縮和解壓縮工作，大量的 cpu 其實消耗在這里。
第二個是關(guān)閉 rocksdb 壓縮，減少緩存加載 /compaction 時候的 cpu 消耗。從火焰圖中可以看到，整個 SSD 數(shù)據(jù)進(jìn)行底層生成的時候，它會不斷地進(jìn)行整個文件的壓縮和解壓縮。所以我們的思路就是如何去關(guān)閉一些 rocksdb 壓縮，減少整個緩存加載或者 cpu 的消耗。
第三個是支持接口層壓縮，在數(shù)據(jù) state 讀寫前后進(jìn)行解壓縮操作，減少 state 大小。如果關(guān)閉 rocksdb 底層的壓縮，我們觀察到整個磁盤的使用量非常高。這樣的話，壓力就是從壓縮和解壓縮的 cpu 消耗變成磁盤的 io 消耗，磁盤的 io 很容易就被消耗盡了。所以我們就把整個底層的壓縮往上層進(jìn)行了一個牽引，支持接口層的壓縮。

在數(shù)據(jù)層寫入讀寫前后進(jìn)行壓縮和解壓縮的操作，減少底層的存儲大小，我們也與內(nèi)部的一些 DB 存儲團隊進(jìn)行了一些溝通，他們一般建議在上層進(jìn)行壓縮，這樣會比在底層做效率更高一些。因為底層整個是以 Block 維度進(jìn)行壓縮與解壓縮的。

2.3 整體架構(gòu)

partitoned index filter 開啟，B 站內(nèi)部目前主要用的是 Flink 1.11 版本。當(dāng)初我們大概調(diào)研到這個參數(shù)的時候，發(fā)現(xiàn)社區(qū)本身在 1.12 版本已經(jīng)提升了這個功能，所以就直接把 1.12 版本相關(guān)的功能直接用過來了，同時 rocksdb 壓縮關(guān)閉，官方文檔均有參數(shù)，這個部分成本比較低。

第二個部分是支持業(yè)務(wù)的壓縮。為了減少磁盤 io 的壓力，在接口上做了一些壓縮。接口壓縮架構(gòu)，如上圖，重寫了所有 rocksdb state 的 put/get 接口，使用的是最新的 Zstd 壓縮算法。目前使用的是 LTZ 算法，比一些常用的壓縮收益更高，cpu 的消耗比較小。

2.4 業(yè)務(wù)效果

如上業(yè)務(wù)效果對比圖，這里面包含 test 1、2、3、4，主要看看 test 0 和 test 4。test 0 是社區(qū)默認(rèn)的方案，也就是底層用是 snappy 壓縮，上層不做什么。test 4 是完全關(guān)閉了底層的壓縮，無論是上層還是底層，整個壓縮是全部關(guān)閉的，在業(yè)務(wù)層使用了最新的 STD 方法進(jìn)行壓縮。

整個觀察下來，峰值和低峰期的數(shù)據(jù)都進(jìn)行了查看，cpu 均值大概是下降到 15%左右，峰值大概下降到 25%，相信對毛刺的下降會更明顯一些。另外，在業(yè)務(wù)層做完壓縮之后，這個文件大小基本保持不變，或是只提升了一點點。這樣一來，最底層的存儲空間或者 io 其實完全沒有增加任何壓力。

目前來講，線上所有新增的大的任務(wù)基本都已經(jīng)全部開啟了，老的任務(wù)也在進(jìn)行一些推進(jìn)。

最后補充下這個場景的適應(yīng)性。因為整個方案是匹配到我們的推薦功能或是廣告模型拼接場景來做的，所有的性能分析也是在這樣的場景下進(jìn)行的，結(jié)論是主要雙流 join 的大 state 場景，小 state 場景下基本沒有收益，主要原因是小 state 的模式下，cache 本身的命中率非常高，換進(jìn)換出頻率較低。另外，Liststate 暫時不支持業(yè)務(wù)層壓縮，add 接口底層的特殊 merge 實現(xiàn)暫時無法做業(yè)務(wù)層壓縮。

Remote state 探索

3.1 業(yè)務(wù)場景和問題

第一，降本增效。這是今年大部分互聯(lián)網(wǎng)公司可能都在做的事情，B 站也不列外。我們在推一個離在線混部，主要是為了提升資源的使用效率。把 Flink 大數(shù)據(jù)的場景和在線服務(wù)的場景進(jìn)行資源的混部。

第二，大 state 作業(yè)重啟下載 state 慢。有些用戶反應(yīng)，對一些重啟時間比較敏感的業(yè)務(wù)方，會覺得大狀態(tài)下的重啟對業(yè)務(wù)會有一些抖動，尤其在廣告、AI 模型推薦等方面體驗感不好。

第三，大 state 作業(yè)重啟加載 state 慢。希望在重啟或是擴容的時候，加載更快一些。這里包括兩個業(yè)務(wù)場景，一個是離在線混部，第二個是用戶的重啟體驗。這兩個方面即使是用 rocksdb 來做都比較難。例如在線混部，因為在線的機器的磁盤基本是 100-200GB 的那種本地較小的磁板，同時 io 性能也不是很高，在這種情況下，將Flink大任務(wù)丟到在線混部上去，會對在線的機器負(fù)載壓力比較大。這就造成在線混部上的任務(wù)是相對有限的。

其實用戶很難區(qū)分到底哪些任務(wù)是可以丟到在線混部，哪些不能。這需要用戶通過 state 來判斷。另外， state 的慢導(dǎo)致用戶體驗比較差，主要是因為它重啟的時候強依賴 load 過程，尤其是當(dāng)遇到超過 500GB 的任務(wù)時候，這個體驗感就會比較差。

3.2 優(yōu)化思路

首先是實現(xiàn) Flink state 的存算分離。如果進(jìn)行混部，本地實際上沒有磁盤，就很難給到在線的機器，在 Flink 上最直接的辦法就是存算分離。存算分離不是陌生的概念，尤其是在云上。存儲放在存儲的機器上，按照存儲的需求進(jìn)行機型采購，計算同理。

其次是 state 遠(yuǎn)程化/服務(wù)化，重啟 /rescale 直接建立連接進(jìn)行讀寫。B 站的做法是把 Flink 的 state 進(jìn)行存儲的分離，這樣就能解決在線的混部問題。分離之后，就可以進(jìn)行遠(yuǎn)程化和服務(wù)化的部署，最終重啟或是其他就能直接與遠(yuǎn)程服務(wù)進(jìn)行連接。

第三是遠(yuǎn)程 state 服務(wù)需要支持 checkpoint 完整功能依賴的接口。這是正常開發(fā)流程中所依賴的，即遠(yuǎn)程服務(wù)。需要支持一個 checkpoint 的完整功能，主要對標(biāo)的就是 rocksdb 的功能。

3.3 整體架構(gòu)

上圖是 Flink state 整體的架構(gòu)，也是 statebackend 對象拓?fù)洌褪巧蠄D右側(cè)。另外，F(xiàn)link statebackend 的核心數(shù)據(jù)或是數(shù)據(jù)存儲主要是由 keyed statebackend 承擔(dān)，還有一部分是由 operator state 承擔(dān)，這部分主要是存在內(nèi)存里，并全量往遠(yuǎn)程刷，一般支持的數(shù)據(jù)不會特別大。

核心的大規(guī)模數(shù)據(jù)會存在 keyed statebackend 里。keyed statebackend 主要有 heap 和 rocksdb 兩種實現(xiàn)，支持大規(guī)模額數(shù)據(jù)存儲。

B 站主要使用的是 rocksdb 存儲，主要圍繞的核心是改進(jìn) keyed statebackend，因為 operator state 主要針對的是小規(guī)模數(shù)據(jù)，它不會占用本地 io，也不會在重啟的時候產(chǎn)生大量的重復(fù)操作，速度相對來說要快很多。

上圖是社區(qū) keyed statebackend 的分配邏輯架構(gòu)。如果想要把 keyed statebackend 做存算分離，需要了解：

Flink 的分片邏輯，它的底層有一個 keyed group 的概念。在所有狀態(tài)在任務(wù)第一次啟動的時候，底層分片就已經(jīng)確定好了。這個分片大小就是 Flink 的最大并發(fā)度的值。這個最大并發(fā)度實際上是在任務(wù)第一次不從 checkpoint 啟動時候算出來的。這中間如果一直從 checkpoint 啟動，那么最大并發(fā)度永遠(yuǎn)不會變。
Flink checkpoint rescale 能力是有限的，本質(zhì)是分片 key-group 在 subtask 之間的移動，分片無法分裂。一旦啟動生成切換之后，這個分片的數(shù)量因為已經(jīng)固定好了，后面不管怎么 rescale，本質(zhì)是分片的移動，其實最大的變動是后面 rescale 不能超過整個分片的數(shù)量，這個數(shù)量對應(yīng)的是分片最大的并發(fā)度。
多個 key-group 存儲在相同 rocksdb 的 cf 里面，以 key-group 的 ID 作為 key 的 prefix，依賴 rocksdb 的排序特性，rescale 過程通過 prefix 進(jìn)行定位遍歷提取。

上圖是 Remote state 整體架構(gòu)，主要的核心工作有三點：

替換 rocksdb 為 B 站內(nèi)部的 taishan 存儲。Taishan 存儲底層是分布式結(jié)構(gòu)，F(xiàn)link 的一些概念是可以對應(yīng)到 taishan 存儲上的。
key-group 概念對應(yīng) taishan 存儲的 shard，cf 對應(yīng) table。key-group 的概念就可以對應(yīng)上 taishan 存儲，同時里面 cf 的概念也對應(yīng) taishan 存儲中的一個 table 概念，也支持一個 table 里面可以有多個 key-group。
Taishan 存儲支持對應(yīng) shard 的 snapshot，以及從歷史的 snapshot 進(jìn)行快速切換。比如重啟的時候可以從老的 checkpoint 進(jìn)行回復(fù)，實際上能夠調(diào)用 taishan 存儲這樣一套接口進(jìn)行快速 snapshot 切換，并可以指定對應(yīng)的 snapshot 并進(jìn)行加載，加載的速度非常快，基本是秒級左右。

3.4 緩存架構(gòu)

在上文介紹的基礎(chǔ)上可以觀察到，開發(fā)完之后實際上整個功能來說是完全夠用的，但也發(fā)現(xiàn)了一些比較嚴(yán)重的性能問題：

每次 state 操作都需要走網(wǎng)絡(luò) rpc， cpu 的消耗太高
網(wǎng)絡(luò) rpc 的延遲高，任務(wù)吞吐低
cache 是一個自然而然的選擇

3.5 緩存難點

寫緩存相對來講是比較簡單，內(nèi)存攢批，后臺定期 checkpoint 刷出去就可以上百倍的減少寫的 rpc。

讀緩存是比較難的。讀緩存是把場景進(jìn)行拆分來看：

key 比較少的場景效果明顯，命中率極高，效果好，甚至達(dá)到幾百上千倍的效果提升。
稀疏的 key 場景，大量讀 null，緩存命中率低。這個場景是當(dāng)下比較大的難點。
周期性業(yè)務(wù)導(dǎo)致緩存定期失效，讀 null，命中率暴跌。周期性業(yè)務(wù)到周期末節(jié)點，就會觸發(fā)一個緩存失效，一旦跨過這個節(jié)點，緩存里就會變成新的數(shù)據(jù)。如果正巧遇上讀 null，命中率就會很低，甚至導(dǎo)致任務(wù)抖動。這也是比較大的難點。

基于以上的問題，優(yōu)化方案是支持 key 全量緩存配置，有效解決稀疏/緩存失效場景性能問題，使內(nèi)存使用上升。但是這個優(yōu)化缺點也比較明顯，即對內(nèi)存的要求會高些。因為所有的 key 都要存在一個緩存里，而這個緩存就是內(nèi)存。

除了以上介紹的兩點難點，其實還有另外兩個難點。其一是冷啟動，因為緩存不會進(jìn)行持久化，那么當(dāng)任務(wù)重啟等狀態(tài)下，其實重啟之后緩存內(nèi)是空的，那么也就會造成重啟的時候，讀和寫的請求量都很大，會給性能造成壓力。

另外，全量 key 的緩存，啟動的時候也沒法立即使用，需要等一個ttl周期，這樣才能可以保證后面的全量 key 緩存是真正的全量 key。

3.6 off-heap 緩存模型圖

上圖是 off-heap 緩存模型，我們使用的是 Facebook 的 OHC（off-heap cache）。可以觀察到，基于 ttl 的主動淘汰，它帶來的性能消耗相對來講會比較大。但是如果完全關(guān)掉基于ttl的淘汰機制，在某些特殊場景，基于 io 淘汰機制，也會消耗比較大的空間。因為 io 淘汰的時候會進(jìn)行判斷哪個 key 可以真的被淘汰。如果完全通過 io 淘汰，在有些場景下面可能判定了很多 key，這些 key 都無法滿足一個 io 的淘汰條件，那么這個淘汰流程就會很長，會導(dǎo)致接口卡的時間會比較久。所以在這里 B 站進(jìn)行了調(diào)優(yōu)，既保留了一個主動淘汰的思路，也依賴 io 這樣一個淘汰機制。

目前來講，我們已經(jīng)完成針對部分任務(wù)的灰度，灰度任務(wù)的計算資源消耗降低了 30%左右。遠(yuǎn)程 state 的服務(wù)消耗暫時沒有統(tǒng)計，粗略看整體的資源應(yīng)該是持平或是只有略微一點升高。離在線混部以及快速 rescale 的意義是巨大的。Flink 側(cè)可以實現(xiàn)存算分離的效果，同時，這也能夠做快速的重啟而不需要進(jìn)行狀態(tài)的重新下載、重新加載或是 reload 的過程。