多條告白如次劇本只需引入一次

2021年，字節撲騰旗下產物總MAU已勝過19億。在以抖音、本日頭條、無籽西瓜視頻等為代辦的產物交易后臺下，宏大的引薦體例顯得尤為要害。Flink供給了特殊宏大的SQL模塊和有狀況計劃模塊。暫時在字節引薦場景，及時大略計數特性、窗口計數特性、序列特性仍舊實足遷徙到FlinkSQL計劃上。貫串FlinkSQL和Flink有狀況計劃本領，咱們正在建立下一代通用的普通特性計劃一致框架結構，憧憬不妨高效扶助常用有狀況、無狀況普通特性的消費。

交易后臺

對至今日頭條、抖音、無籽西瓜視頻等字節撲騰旗下產物，鑒于Feed流和短實效的引薦是中心交易場景。而引薦體例最普通的燃料是特性，高效消費普通特性對交易引薦體例的迭代至關要害。

重要交易場景

抖音、火山短視頻等為代辦的短視頻運用引薦場景，比方Feed流引薦、關心、應酬、同城等各個場景，完全在海內大約有6億+范圍DAU；頭條、無籽西瓜等為代辦的Feed消息流引薦場景，比方Feed流、關心、子頻段等各個場景，完全在海內數億范圍DAU；交易痛點和挑撥

暫時字節撲騰引薦場景普通特性的消費近況是“百花齊放”。離線特性計劃的基礎形式都是經過耗費Kafka、BMQ、Hive、HDFS、Abase、RPC等數據源，鑒于Spark、Flink計劃引擎實行特性的計劃，爾后把特性的截止寫入在線、離線保存。百般各別典型的普通特性計劃散落在各別的效勞中，不足交易籠統，帶來了較大的運維本錢和寧靜性題目。

而更要害的是，不足一致的普通特性消費平臺，使交易特性開拓迭代速率和保護生存諸多未便。如交易方需自行保護洪量離線工作、特性消費鏈路不足監察和控制、沒轍滿意連接興盛的交易需要等。

在字節的交易范圍下，建立一致的及時特性消費體例面對著較大挑撥，重要來自四個上面：

宏大的交易范圍：抖音、頭條、無籽西瓜、火山等產物的數據范圍可到達每日平均PB級別。比方在抖音場景下，晚頂峰Feed播放量達數百萬QPS，存戶端上報用戶動作數據高達數萬萬IOPS。交易方憧憬在任何功夫，特性工作都不妨做到連接流、耗費沒有lag等，這就訴求特性消費完備特殊高的寧靜性。

較高的特性及時化訴求：在以直播、電商、短視頻為代辦的引薦場景下，為保護引薦功效，及時特性離線消費的實效性需實行常態寧靜于秒鐘級別。

更好的擴充性和精巧性：跟著交易場景連接攙雜，特性需要更為精巧反復無常。從統計、序列、屬性典型的特性消費，到須要精巧扶助窗口特性、多維特性等，交易方須要特性中臺不妨扶助漸漸派生而來的新特性典型和需要。

交易迭代速率快：特性中臺供給的面向交易的DSL須要充滿場景，特性消費鏈路盡管讓交易少寫代碼，底層的計劃引擎、保存引擎對交易實足通明，完全開釋交易計劃、保存選型、調優的承擔，完全實行及時普通特性的范圍化消費，連接提高特性消費力；

迭代演進進程

在字節交易暴發式延長的進程中，為了滿意形形***的交易特性的需要，引薦場景派生出了稠密特性效勞。那些效勞在一定的交易場景和汗青前提下較好扶助了交易趕快興盛，大概的過程如次：

引薦場景特性效勞演進過程

在這個中2020年頭是一個要害節點，咱們發端在特性消費中引入FlinkSQL、FlinkState本領體制，漸漸在計數特性體例、模子演練的樣品拼接、窗口特性等場景舉行落地，探究出新一代特性消費計劃的思緒。

新一代體例框架結構

貫串上述交易后臺，咱們鑒于FlinkSQL和Flink有狀況計劃本領從新安排了新一代及時特性計劃計劃。新計劃的定位是：處置普通特性的計劃和在線Serving，供給越發籠統的普通特***易層DSL。在計劃層，咱們鑒于FlinkSQL精巧的數據處置表白本領，以及FlinkState狀況保存和計劃本領等本領，扶助百般攙雜的窗口計劃。極地面減少交易普通特性的消費周期，提高特性產出鏈路的寧靜性。新的框架結構里，咱們將特性消費的鏈路分為數據源抽取/拼接、狀況保存、計劃三個階段，FlinkSQL實行特性數據的抽取和流式拼接，FlinkState實行特性計劃的中央狀況保存。

有狀況特性利害常要害的一類特性，個中最常用的即是帶有百般窗口的特性，比方統計邇來5秒鐘視頻的播放VV等。對于窗口典型的特性在字節里面有少許鑒于保存引擎的計劃，完全思緒是“輕離線重在線”，即把窗口狀況保存、特性會合計劃十足放在保存層和在線實行。離線數據流控制基礎數據過濾和寫入，離線明細數據依照功夫切分會合保存（一致于microbatch），底層的保存大局部是KV保存、大概特意優化的保存引擎，在線層實行攙雜的窗口會合計劃論理，每個乞求來了之后在線層拉取保存層的明細數據做會合計劃。

咱們新的處置思緒是“輕在線重離線”，即把比擬重的功夫切片明細數據狀況保存和窗口會合計劃十足放在離線層。窗口截止會合經過離線窗口觸發體制實行，把特性截止推到在線KV保存。在線模塊特殊輕量級，只控制大略的在線serving，極地面簡化了在線層的框架結構攙雜度。在離線狀況保存層。咱們重要依附Flink供給的原生狀況保存引擎RocksDB，充溢運用離線計劃集群當地的SSD磁盤資源，極大減少在線KV保存的資源壓力。

對于長窗口的特性（7天之上窗口特性），因為波及Flink狀況層明細數據的上溯進程，FlinkEmbedded狀況保存引擎沒有供給更加好的外部數據回灌體制（大概說不符合做）。所以對于這種“狀況冷啟用”場景，咱們引入了重心化保存動作底層狀況保存層的保存介質，完全是Hybrid框架結構。比方7天以內的狀況保存在當地SSD，7～30天狀況保存到重心化的保存引擎，離線數據上溯不妨特殊簡單的寫入重心化保存。

除窗口特性外，這套體制同樣實用于其余典型的有狀況特性（如序列典型的特性）。

及時特性分門別類體制

特性典型

設置

特性舉例

有狀況特性

有狀況特性是一類特殊要害的特性，咱們對有狀況特性的設置是：計劃特性須要緩存左右文數據。

帶有窗口的特性，比方抖音視頻邇來1h的點贊量（滑行窗口）、直播間用戶邇來一個session的看播時間長度（session窗口）等；序列特性，比方邇來100個引薦展示視頻。無狀況特性

大略的ETL特性，經過大略的數據過濾不妨計劃的特性。

模子預估特性

須要過程外部攙雜模子預估的特性

用戶的年紀、性別等特性。

圖特性

在直播和應酬聯系場景生存比擬多的須要二跳聯系的圖典型的特性。

很多圖特性同聲也是有狀況典型的特性。

禮品排序：用戶觀察最多的主播收到最多的禮品，首要選擇須要找到用戶觀察最多的主播ArchorId，而后經過archon_id獲得到主播收到最多的禮品id；應酬聯系：心腹（大概是發掘出來的聯系）關心、看播、送人情、連麥的屋子，應酬聯系自然是圖數據構造。完全框架結構

數據源層

在新的一體化特性框架結構中，咱們一致把百般典型數據源籠統為SchemaTable，這是由于底層依附的FlinkSQL計劃引擎層對數據源供給了特殊和睦的TableFormat籠統。在引薦場景，依附的數據源特殊百般，每個特性上流依附一個大概多個數據源。數據源不妨是Kafka、RMQ、KV保存、RPC效勞。對于多個數據源，扶助數據泉源式、批式拼接，拼接典型囊括WindowJoin和鑒于key粒度的WindowUnionJoin，維表Join扶助Abase、RPC、HIVE等。簡直每種典型的拼接論理如次：

數據源典型

Schema領會

Kafka、BMQ

Kafka、BMQ等message典型基礎都是JSON和PB，是自刻畫的數據典型。不妨特殊簡單地映照成SchemaTable***，個中對于PB典型，交易須要上傳PBIDL實行TableSchema設置。

KV保存

KV保存里的Value大局部為JSON、PB***，和MQ一致。交易方經過供給PBIDL實行TableSchema設置。咱們經過FlinkSQL的維表Join本領，把普遍的獲得外部保存數據源進程籠統為基礎的維表Join操縱，簡化交易開拓周期。

RPC

FlinkSQL供給了對RPC維表的Join本領，交易供給RPCThriftIDL完備rpcresponseTableSchema設置。經過維表Join，咱們把普遍的經過RPC獲得外部數據源的進程籠統為了基礎維表Join模子，簡化交易開拓周期。

Hive

Hive自己即是SchemaTable的保存***，對于在線Join數據量較小的離線Hive數據(本來即是MapSideJoin)，可經過Hive維表Join實行。

三種典型的Join和Union不妨拉攏運用，實行攙雜的普遍據流拼接。比方(AunionB)WindowJoin(CLookupJoinD)。

拼接典型

拼接論理

備注

WindowJoin

運用Flink原生API供給的Join算子，把多個數據流浪入相同學口的數據Join起來。

徑直在原始數據流上運用TumblingWindow舉行切分，按照event_time或process_time對齊兩個窗口后再關系數據。

鑒于Key粒度的IntervalStateJoin

和樣品拼接論理一致。經過Union上流多個數據源，在每個關系主鍵上頭備案timer，等候一個恒定的功夫窗口實行普遍據源的Join操縱。

IntervalStateJoin是運用State保存數據再處置。上流兩個數據流過程Union后，同一個uid的instance數據和label數據落在同一個operator內，Joiner中正負例樣品的爆發即是經過這種Join辦法。

Lookup維表Join

經過關系主鍵，從Abase、RPC、Hive等效勞察看須要關系的數據，實行數據的Join操縱。

普遍據源Union

普遍據源Union起來

其余，FlinkSQL扶助攙雜字段的計劃本領，也即是交易方不妨鑒于數據源設置的TableSchema普通字段實行擴充字段的計劃。交易計劃論理實質是一個UDF，咱們會供給UDFAPI接口給交易方，而后上傳JAR到特性后盾加載。其余對于比擬大略的計劃論理，后盾也扶助經過提交大略的Python代碼實行多談話計劃。

交易DSL

從交易視角供給莫大籠統的特性消費DSL談話，樊籬底層計劃、保存引擎詳細，讓交易方聚焦于交易特性設置。交易DSL層供給：數據根源、數據***、數據抽取論理、數據天生特性典型、數據輸入辦法等。

狀況保存層

如下文所述，新的特性一體化計劃處置的重要痛點是：怎樣應付百般典型（普遍是滑行窗口）有狀況特性的計劃題目。對于這類特性，在離線計劃層框架結構里會有一個狀況保存層，把抽取層索取的RawFeature依照切片Slot保存起來(切片不妨是功夫切片、也不妨是Session切片等)。切片典型在里面是一個接口典型，在框架結構上不妨按照交易需要自行擴充。狀況內里本來保存的不是原始RawFeature（保存原始的動作數據太濫用保存空間），而是變化為FeaturePayload的一種POJO構造，這個構造內里扶助了罕見的百般數據構造典型：

Int：保存大略的計數值典型(多維度counter)；HashMap：保存二維計數值，比方ActionCounter，key為target_id，value為計數值；SortedMap:保存topk二維計數；LinkedList：保存id_list典型數據；HashMap>：保存二維id_list；自設置典型，交易不妨按照需要FeaturePayload內里自設置數據典型狀況層革新的交易接口：輸出是SQL抽取/拼接層抽掏出來的RawFeature，交易方不妨按照交易需務實現updateFeatureInfo接口對狀況層的革新。對于常用的特性典型內置實行了update接口，交易方自設置特性典型不妨接受update接話柄現。

/***特性狀況update接口*/publicinterfaceFeatureStateApiextendsSerializable{/***特性革新接口,上流每條日記會索取需要字段變換為fields,用來革新對應的特性狀況**@paramfields*context:生存特性稱呼、主鍵和少許擺設參數;*oldFeature:特性之前的狀況*fields:平臺/擺設文獻中的抽取字段*@return*/FeaturePayLoadassign(Contextcontext,FeaturePayLoadfeature,Map<String,Object>rawFeature);}復制代碼

固然對于無狀況的ETL特性是不須要狀況保存層的。

計劃層

特性計劃層實行特性計劃會合論理，有狀況特性計劃輸出的數據是狀況保存層保存的帶有切片的FeaturePayload東西。大略的ETL特性沒有狀況保存層，輸出徑直是SQL抽取層的數據RawFeature東西，簡直的接口如次：

/***有狀況特性計劃接口*/publicinterfaceFeatureStateApiextendsSerializable{/***特性會合接口，會按照擺設的特性計劃窗口,讀取窗口內一切特性狀況，排序后傳入該接口**@paramfeatureInfos,包括2個field*timeslot:特性狀況對應的功夫槽*Feature:該功夫槽的特性狀況*@return*/FeaturePayLoadaggregate(Contextcontext,List<Tuple2<Slot,FeaturePayLoad>>slotStates);}復制代碼

有狀況特性會合接口

/***無狀況特性計劃接口*/publicinterfaceFeatureConvertApiextendsSerializable{/***變換接口,上流每條日記會索取需要字段變換為fields,無狀況計劃時，變換為里面的feature典型;**@paramfields*fields:平臺/擺設文獻中的抽取字段*@return*/FeaturePayLoadconvert(Contextcontext,FeaturePayLoadfeatureSnapshot,Map<String,Object>rawFeatures);}復制代碼

無狀況特性計劃接口

其余經過觸發體制來觸發特性計劃層的實行，暫時扶助的觸發體制重要有：

戰略

證明

OnTimerTrigger

周期性準時觸發特性的計劃論理

OnUpdateTrigger

上流狀況層歷次革新即觸發特性計劃

CustomTrigger

自設置特性計劃的觸發機會

交易落地

暫時在字節引薦場景，新一代特性框架結構仍舊在抖音直播、電商、推送、抖音引薦等場景連接上線了少許及時特性。主假如有狀況典型的特性，帶有窗口的一維統計典型、二維倒排拉鎖典型、二維TOPK典型、及時CTR/CVRRate典型特性、序列典型特性等。

在交易中心目標完畢上面功效明顯。在直播場景，依靠新特性框架結構宏大的表白本領上線了一批特性之后，交易看播中心目標、互動目標收益特殊明顯。在電阛阓景，鑒于新特性框架結構上線了400+及時特性。個中在直播電商上面，交易中心GMV、下單率目標收益明顯。在抖音推送場景，鑒于新特性框架結構離線狀況的保存本領，會合用戶動作數據而后寫入卑劣各路保存，極地面緩和了交易卑劣數據庫的壓力，在少許場景中QPS不妨低沉到之前的10%安排。其余，抖音引薦Feed、指摘等交易都在鑒于新特性框架結構重構原有的特性體制。

犯得著一提的是，在電商和抖音直播場景，Flink流式工作狀況最大仍舊到達60T，并且這個量級還在連接增大。估計不久的未來，單工作的狀況有大概會沖破100T，這對框架結構的寧靜性是一個不小的挑撥。

本能優化

FlinkStateCache

暫時Flink供給兩類StateBackend：鑒于Heap的FileSystemStateBackend和鑒于RocksDB的RocksDBStateBackend。對于FileSystemStateBackend，因為數據都在外存中，考察速度很快，沒有特殊開支。而RocksDBStateBackend生存查盤、序列化/反序列化等特殊開支，CPU運用量會有鮮明飛騰。在字節里面有洪量運用State的功課，對于大狀況功課，常常會運用RocksDBStateBackend來處置當地狀況數據。RocksDB是一個KV數據庫，以LSM的情勢構造數據，在本質運用的進程中，有以次特性：

運用層和RocksDB的數據交互是以Bytes數組的情勢舉行，運用層歷次考察都須要序列化/反序列化；數據以追加的情勢連接寫入RocksDB中，RocksDB后盾會連接舉行compaction來簡略失效數據。交易方運用State的場景多是get-update，在運用RocksDB動作當地狀況保存的進程中，展示過以次題目：

爬蟲數據引導熱key，狀況會連接舉行革新(get-update)，單KV數據到達5MB，而RocksDB追加革新的特性引導后盾在連接舉行flush和compaction，單task展示慢節點（抖音直播場景）。電阛阓景功課普遍為大狀況功課(暫時已上線功課狀況約60TB)，交易論理中會一再舉行State操縱。在融洽FlinkState進程中創造CPU的開支和原有的鑒于外存或abase的實行有40%~80%的升高。經優化后，CPU開支重要會合在序列化/反序列化的進程中。對準上述題目，不妨經過在外存保護一個東西Cache，到達優化熱門數據考察和貶低CPU開支的手段。經過上述后臺引見，咱們蓄意能為StateBackend供給一個通用的Cache功效，經過FlinkStateBackendCache功效安排計劃完畢以次目的：

縮小CPU開支：經過對熱門數據舉行緩存，縮小和底層StateBackend的交互度數，到達縮小序列化/反序列化開支的手段。提高State含糊本領：經過減少Cache后，State含糊本領應比原有的StateBackend供給的含糊本領更高。表面上在Cache充滿大的情景下，含糊本領應和鑒于Heap的StateBackend好像。Cache功效通用化：各別的StateBackend不妨徑直適配該Cache功效。暫時咱們重要扶助RocksDB，將來蓄意不妨徑直供給給其余StateBackend運用，比方RemoteStateBackend。過程和字節普通框架結構Flink共青團和少先隊的協作，在及時特性消費晉級，上線Cache大局部場景的CPU運用率大約會有高達50%安排的收益；

PBIDL裁剪

在字節里面的及時特性離線天生鏈路傍邊，咱們重要依附的數據流是Kafka。那些Kafka都是經過PB設置的數據，字段稠密。公司級其余大Topic普遍會有100+的字段，但大局部的特性消費工作只運用了個中的局部字段。對于Protobuf***的數據源，咱們不妨實足經過裁剪數據流，mask少許非需要的字段來儉樸反序列化的開支。PB典型的日記，不妨徑直裁剪idl，維持需要字段的序號靜止，在反序列化的功夫會跳過unknownfield的領會，這對于CPU來說是更儉樸的，然而搜集帶寬不會有收益，估計裁剪后能儉樸特殊多的CPU資源。在上線了PBIDL裁剪之后，大局部工作的CPU收益在30%安排。

遇到的題目

新框架結構特性消費工作實質即是一個有狀況的Flink工作，底層的狀況保存StateBackend主假如當地的RocksDB。重要面對兩個比擬難解的題目，一是工作DAG變革Checkpoint作廢，二是當地保存不許很好地扶助特性狀況汗青數據上溯。

及時特性工作不許動靜增添新的特性：對于一個線上的Flink及時特性消費工作，咱們不許隨便增添新的特性。這是因為引入新的特性會引導Flink工作計劃的DAG爆發變換，進而引導Flink工作的Checkpoint沒轍回復，這對及時有狀況特性消費工作來說是不許接收的。暫時咱們的解法是遏止變動線上安置的特性工作擺設，但這也就引導了線上天生的特性是不許隨意底線的。對于這個題目姑且沒有找到更好的處置***，后期仍需連接探究。特性狀況冷啟用題目：暫時重要的狀況保存引擎是RocksDB，不許很好地扶助狀況數據的上溯。后續籌備

暫時新一代框架結構還在字節引薦場景中趕快演進，暫時已較好處置了及時窗口特性的消費題目。

出于實行一致引薦場景下特性消費的手段，咱們后續會連接鑒于FlinkSQL流批一體本領，在批式特性消費發力。其余也會鑒于Hudi數據湖本領，實行特性的及時入湖，高效扶助模子演練場景離線特性上溯痛點。準則引擎目標，安置連接探究CEP，激動在電阛阓景有更多落地試驗。在及時窗口計劃目標，將連接深刻調查研究Flink原生窗口體制，以期處置暫時計劃面對的窗口特性數據出場題目。

扶助批式特性：這套特性消費計劃主假如處置及時有狀況特性的題目，而暫時字節離線場景下再有洪量批式特性是經過SparkSQL工作消費的。后續咱們也會鑒于FlinkSQL流批一體的計劃本領，供給對批式場景特性的一致扶助，暫時也發端有了幾個場景的落地；特性離線入湖：鑒于HudiOnFlink扶助及時特性的離線數倉樹立，主假如為了扶助模子演練樣品拼接場景離線特性上溯；FlinkCEP準則引擎扶助：FlinkSQL實質上即是一種準則引擎，暫時在線上咱們把FlinkSQL動作交易DSL過濾語義底層的實行引擎。但FlinkSQL長于表白的ETL典型的過濾準則，不許表白帶偶爾序典型的準則語義。在直播、電阛阓景的時序準則須要試驗FlinkCEP越發攙雜的準則引擎。FlinkNativeWindowing體制引入：對于窗口典型的有狀況特性，咱們暫時沿用下文所述的籠統SlotState功夫切片計劃一致舉行扶助。其余Flink自己供給了特殊完備的窗口體制，經過WindowAssigner、WindowTrigger等組件不妨特殊精巧地扶助百般窗書面語義。所以后續咱們也會在窗口特性計劃場景引入Flink原生的Windowing體制，越發精巧地扶助窗口特性迭代。FlinkHybridStateBackend框架結構：暫時在字節的線上場景中，Flink底層的StateBackend默許都是運用RocksDB保存引擎。這種內嵌的保存引擎不許經過外部體制去供給狀況數據的回灌和多工作共享，所以咱們須要扶助KV重心化保存計劃，實行精巧的特性狀況上溯。靜態屬性典型特性一致處置：經過特性平臺供給一致的DSL語義，一致處置其余外部靜態典型的特性效勞。比方少許其余交易共青團和少先隊維度的用戶分門別類、標簽效勞等。