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

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

交易后臺

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

重要交易場景

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

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

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

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

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

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

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

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

迭代演進(jìn)進(jìn)程

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

引薦場景特性效勞演進(jìn)過程

在這個中2020年頭是一個要害節(jié)點(diǎn)，咱們發(fā)端在特性消費(fèi)中引入FlinkSQL、FlinkState本領(lǐng)體制，漸漸在計數(shù)特性體例、模子演練的樣品拼接、窗口特性等場景舉行落地，探究出新一代特性消費(fèi)計劃的思緒。

新一代體例框架結(jié)構(gòu)

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

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

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

對于長窗口的特性（7天之上窗口特性），因為波及Flink狀況層明細(xì)數(shù)據(jù)的上溯進(jìn)程，F(xiàn)linkEmbedded狀況保存引擎沒有供給更加好的外部數(shù)據(jù)回灌體制（大概說不符合做）。所以對于這種“狀況冷啟用”場景，咱們引入了重心化保存動作底層狀況保存層的保存介質(zhì)，完全是Hybrid框架結(jié)構(gòu)。比方7天以內(nèi)的狀況保存在當(dāng)?shù)豐SD，7～30天狀況保存到重心化的保存引擎，離線數(shù)據(jù)上溯不妨特殊簡單的寫入重心化保存。

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

及時特性分門別類體制

特性典型

設(shè)置

特性舉例

有狀況特性

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

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

大略的ETL特性，經(jīng)過大略的數(shù)據(jù)過濾不妨計劃的特性。

模子預(yù)估特性

須要過程外部攙雜模子預(yù)估的特性

用戶的年紀(jì)、性別等特性。

圖特性

在直播和應(yīng)酬聯(lián)系場景生存比擬多的須要二跳聯(lián)系的圖典型的特性。

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

禮品排序：用戶觀察最多的主播收到最多的禮品，首要選擇須要找到用戶觀察最多的主播ArchorId，而后經(jīng)過archon_id獲得到主播收到最多的禮品id；應(yīng)酬聯(lián)系：心腹（大概是發(fā)掘出來的聯(lián)系）關(guān)心、看播、送人情、連麥的屋子，應(yīng)酬聯(lián)系自然是圖數(shù)據(jù)構(gòu)造。完全框架結(jié)構(gòu)

數(shù)據(jù)源層

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

數(shù)據(jù)源典型

Schema領(lǐng)會

Kafka、BMQ

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

KV保存

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

RPC

FlinkSQL供給了對RPC維表的Join本領(lǐng)，交易供給RPCThriftIDL完備rpcresponseTableSchema設(shè)置。經(jīng)過維表Join，咱們把普遍的經(jīng)過RPC獲得外部數(shù)據(jù)源的進(jìn)程籠統(tǒng)為了基礎(chǔ)維表Join模子，簡化交易開拓周期。

Hive

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

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

拼接典型

拼接論理

備注

WindowJoin

運(yùn)用Flink原生API供給的Join算子，把多個數(shù)據(jù)流浪入相同學(xué)口的數(shù)據(jù)Join起來。

徑直在原始數(shù)據(jù)流上運(yùn)用TumblingWindow舉行切分，按照event_time或process_time對齊兩個窗口后再關(guān)系數(shù)據(jù)。

鑒于Key粒度的IntervalStateJoin

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

IntervalStateJoin是運(yùn)用State保存數(shù)據(jù)再處置。上流兩個數(shù)據(jù)流過程Union后，同一個uid的instance數(shù)據(jù)和label數(shù)據(jù)落在同一個operator內(nèi)，Joiner中正負(fù)例樣品的爆發(fā)即是經(jīng)過這種Join辦法。

Lookup維表Join

經(jīng)過關(guān)系主鍵，從Abase、RPC、Hive等效勞察看須要關(guān)系的數(shù)據(jù)，實行數(shù)據(jù)的Join操縱。

普遍據(jù)源Union

普遍據(jù)源Union起來

其余，F(xiàn)linkSQL扶助攙雜字段的計劃本領(lǐng)，也即是交易方不妨鑒于數(shù)據(jù)源設(shè)置的TableSchema普通字段實行擴(kuò)充字段的計劃。交易計劃論理實質(zhì)是一個UDF，咱們會供給UDFAPI接口給交易方，而后上傳JAR到特性后盾加載。其余對于比擬大略的計劃論理，后盾也扶助經(jīng)過提交大略的Python代碼實行多談話計劃。

交易DSL

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

狀況保存層

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

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

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

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

計劃層

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

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

有狀況特性會合接口

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

無狀況特性計劃接口

其余經(jīng)過觸發(fā)體制來觸發(fā)特性計劃層的實行，暫時扶助的觸發(fā)體制重要有：

戰(zhàn)略

證明

OnTimerTrigger

周期性準(zhǔn)時觸發(fā)特性的計劃論理

OnUpdateTrigger

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

CustomTrigger

自設(shè)置特性計劃的觸發(fā)機(jī)會

交易落地

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

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

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

本能優(yōu)化

FlinkStateCache

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

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

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

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

PBIDL裁剪

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

遇到的題目

新框架結(jié)構(gòu)特性消費(fèi)工作實質(zhì)即是一個有狀況的Flink工作，底層的狀況保存StateBackend主假如當(dāng)?shù)氐腞ocksDB。重要面對兩個比擬難解的題目，一是工作DAG變革Checkpoint作廢，二是當(dāng)?shù)乇４娌辉S很好地扶助特性狀況汗青數(shù)據(jù)上溯。

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

暫時新一代框架結(jié)構(gòu)還在字節(jié)引薦場景中趕快演進(jìn)，暫時已較好處置了及時窗口特性的消費(fèi)題目。

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

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