一、實(shí)時(shí)信號(hào)應(yīng)用

騰訊內(nèi)容中臺(tái)提供從內(nèi)容生產(chǎn)、內(nèi)容加工、內(nèi)容分發(fā)、內(nèi)容結(jié)算等全鏈路環(huán)節(jié)的一站式服務(wù)，在這個(gè)過(guò)程中，會(huì)產(chǎn)生大量的數(shù)據(jù)以及圍繞這些數(shù)據(jù)衍生的實(shí)時(shí)流業(yè)務(wù)應(yīng)用，如內(nèi)容周期智能管理，內(nèi)容加工智能路由，內(nèi)容創(chuàng)作精細(xì)運(yùn)營(yíng)等。

1、內(nèi)容周期智能管理

為滿足不同用戶的體驗(yàn)，需要給內(nèi)容進(jìn)行多種場(chǎng)景適配，隨著內(nèi)容不斷增加，服務(wù)商成本非常高。為此，我們提供了一種基于內(nèi)容周期提供分級(jí)服務(wù)的能力，在保障整體體驗(yàn)的前提下，可有效降低成本。

2、內(nèi)容加工智能路由

內(nèi)容加工場(chǎng)景中有很多的加工精度，會(huì)抽象為一個(gè)微服務(wù)的編排系統(tǒng)。其中會(huì)有調(diào)度器控制任務(wù)的分發(fā)、路徑尋優(yōu)、彈性伸縮等工作。通過(guò)實(shí)時(shí)的數(shù)據(jù)采集， 如算法、耗時(shí)、加工狀態(tài)等信息，并進(jìn)行實(shí)時(shí)流加工，產(chǎn)生不同算法的實(shí)時(shí)效果特征信號(hào)，將這個(gè)實(shí)時(shí)信號(hào)反饋給調(diào)度器?？梢赃M(jìn)一步提高調(diào)度效果，減少加工耗時(shí)，提高處理成功率。

3、內(nèi)容創(chuàng)作精細(xì)運(yùn)營(yíng)

互聯(lián)網(wǎng)平臺(tái)主要圍繞著技術(shù)、產(chǎn)品和運(yùn)營(yíng)，運(yùn)營(yíng)是一個(gè)非常關(guān)鍵的環(huán)節(jié)，運(yùn)營(yíng)人員會(huì)不斷發(fā)布精細(xì)化運(yùn)營(yíng)活動(dòng)，創(chuàng)作者會(huì)領(lǐng)取運(yùn)營(yíng)任務(wù)并發(fā)文。基于實(shí)時(shí)計(jì)算的消費(fèi)量、互動(dòng)量等特征信號(hào)，可以進(jìn)行活動(dòng)達(dá)標(biāo)判斷，進(jìn)而將激勵(lì)實(shí)時(shí)觸達(dá)給創(chuàng)作者，提升運(yùn)營(yíng)活動(dòng)效率。

二、問(wèn)題與挑戰(zhàn)

在上述場(chǎng)景中會(huì)遇到很多問(wèn)題和挑戰(zhàn)，可以抽象為四個(gè)方面：數(shù)據(jù)源、信號(hào)加工、信號(hào)觸發(fā)和數(shù)據(jù)治理。

1、數(shù)據(jù)源

騰訊內(nèi)部各個(gè)業(yè)務(wù)方生產(chǎn)的數(shù)據(jù)各異，且擁有各自的 ID 體系；隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)源還會(huì)動(dòng)態(tài)添加消息 Topic，需要實(shí)時(shí)動(dòng)態(tài)感知新增的數(shù)據(jù)源，并以中臺(tái)統(tǒng)一的 ID 視角串聯(lián)各個(gè)業(yè)務(wù)的內(nèi)容數(shù)據(jù)。

2、信號(hào)加工

內(nèi)容加工時(shí)會(huì)產(chǎn)生較多的復(fù)雜計(jì)算需求，比如，我們需要在有限資源內(nèi)保障 TB 級(jí)多條實(shí)時(shí)數(shù)據(jù)拼接工作，以及長(zhǎng)時(shí)間運(yùn)行下需要對(duì)實(shí)時(shí)流應(yīng)用的計(jì)算口徑進(jìn)行調(diào)整而面臨的批數(shù)據(jù)重建流式數(shù)據(jù)狀態(tài)等問(wèn)題，我們探索了一系列自研技術(shù)，解決了海量數(shù)據(jù)實(shí)時(shí)流計(jì)算問(wèn)題。

3、信號(hào)觸發(fā)

內(nèi)容生態(tài)系統(tǒng)很多場(chǎng)景依賴實(shí)時(shí)信號(hào)，并且基于規(guī)則進(jìn)行控制和流轉(zhuǎn)，煙囪式開發(fā)有較大成本，我們需要構(gòu)建一套日千億次匹配的規(guī)則引擎信號(hào)服務(wù)，保障資源共享，實(shí)現(xiàn)新增場(chǎng)景一鍵配置即可支持。

4、數(shù)據(jù)治理體系

我們希望建立全流程、全生命周期地建設(shè)數(shù)據(jù)治理體系。主要有以下幾個(gè)可通用的方法論：

（1）可觀測(cè)性：鏈路長(zhǎng)，感知和定位問(wèn)題慢。需要一個(gè)流程可觀測(cè)系統(tǒng)，幫助我們快速解決問(wèn)題。

（2）退場(chǎng)機(jī)制：互聯(lián)網(wǎng)迭代非常快，探索性需求多，計(jì)算機(jī)系統(tǒng)資源開銷大。需要建立一套退場(chǎng)機(jī)制，當(dāng)一些服務(wù)項(xiàng)失效的時(shí)候，及時(shí)將資源釋放，來(lái)降低服務(wù)的成本。

三、架構(gòu)與解決方案

接下來(lái)，針對(duì)以上難點(diǎn)和挑戰(zhàn)，來(lái)介紹一下我們的解決方案。

1、整體架構(gòu)

騰訊內(nèi)容生態(tài)實(shí)時(shí)信號(hào)系統(tǒng)的整體架構(gòu)如下圖所示。

自下而上來(lái)看，首先，原始數(shù)據(jù)包括各個(gè)業(yè)務(wù)渠道的生產(chǎn)流水、加工流水和消費(fèi)流水等。 

接著是數(shù)據(jù)接入，通過(guò)動(dòng)態(tài)多源、ID 映射、渠道衍生、數(shù)據(jù)清洗等能力，保證基礎(chǔ)數(shù)據(jù)的完整性和可用性。

再往上是信號(hào)生產(chǎn)，包括日千億次滑動(dòng)大窗口計(jì)算，延遲流數(shù)據(jù)滾動(dòng)大窗口計(jì)算，實(shí)時(shí)流數(shù)據(jù)拼接，融合批數(shù)據(jù)重建流狀態(tài)保障服務(wù)的不中斷，單體流量適應(yīng)水平拓展保障程序不出現(xiàn)瓶頸，以及提供了輸出小文件數(shù)自適應(yīng)流量的能力解決小文件過(guò)多的問(wèn)題。 

規(guī)則引擎，主要提供統(tǒng)一的規(guī)則引擎和觸發(fā)系統(tǒng)，提供千億次的匹配，高效系統(tǒng)分發(fā)，以滿足各個(gè)業(yè)務(wù)系統(tǒng)的需求。 

數(shù)據(jù)治理，主要包括，保證系統(tǒng)的高可用性，一套可觀測(cè)性系統(tǒng)幫助我們快速地分析和解決問(wèn)題，通過(guò)數(shù)據(jù)退場(chǎng)機(jī)制來(lái)降低成本，通過(guò)分層體系（常規(guī)的數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)，ODS 層，TWD 層，ADS 層等）保障數(shù)據(jù)的規(guī)范性和數(shù)據(jù)的可理解性，云數(shù)據(jù)管理系統(tǒng)將數(shù)據(jù)存在云端，供使用方查詢，并保障數(shù)據(jù)安全。

最上面是信號(hào)應(yīng)用。 

2、數(shù)據(jù)接入——?jiǎng)討B(tài)實(shí)時(shí)源自適應(yīng)感知

騰訊內(nèi)容中臺(tái)，提供一站式工業(yè)化的內(nèi)容加工能力，每個(gè)業(yè)務(wù)方可自定義編排加工內(nèi)容的任務(wù)流拓?fù)?。為了穩(wěn)定性和隔離性，每條任務(wù)流拓?fù)鋬?nèi)容加工操作流水會(huì)生成一個(gè) Topic，隨著業(yè)務(wù)發(fā)展，新的 Topic 會(huì)不斷增加，同時(shí)存量 Topic 數(shù)據(jù)量可能變大。因新增 Topic 所屬集群地址差異大，F(xiàn)link Source 無(wú)法用正則匹配到，導(dǎo)致程序無(wú)法自動(dòng)感知。因此，我們?cè)O(shè)計(jì)了 Topic 動(dòng)態(tài)添加的自適應(yīng)感知的技術(shù)方案，可以做到：

（1）數(shù)據(jù)完整性：自動(dòng)感知新添加的拓?fù)?Topic，保證數(shù)據(jù)不遺漏。

（2）數(shù)據(jù)時(shí)效性：存量的 Topic 數(shù)據(jù)量級(jí)變大時(shí)，能夠自動(dòng)擴(kuò)容，保障整體時(shí)效性。

主要由以下幾個(gè)模塊構(gòu)成：

（1）控制器模塊：監(jiān)測(cè)消息隊(duì)列并通過(guò)配置中心異步控制Flink的消費(fèi)。新增 Topic 時(shí)，注冊(cè)到配置中心。Topic 數(shù)據(jù)量變大導(dǎo)致消費(fèi)延遲時(shí)，增加該 Topic 的消費(fèi)并行度。

（2）配置中心：存放所有拓?fù)涞南㈥?duì)列，如拓?fù)?ID、消費(fèi)并行度、Kafka 配置。

（3）Flink 自適應(yīng) Source：自適應(yīng)消費(fèi) Kafka 數(shù)據(jù)，保障數(shù)據(jù)完整性和時(shí)效性。在 Task 內(nèi)開啟消費(fèi)線程池，負(fù)責(zé) Kafka 的消費(fèi)；并有自適應(yīng) Client，負(fù)責(zé)控制線程池的消費(fèi)，每分鐘執(zhí)行一次，保障消費(fèi)的完整性和時(shí)效性。具體步驟如下：

① 步驟 1：拉取所有消息隊(duì)列配置。

② 步驟 2：生成本 Task 消費(fèi)的 Topic 消費(fèi)列表，保障并行度 N 的 Topic 會(huì)被 N 個(gè) Task 消費(fèi)。總 Task 數(shù)目是 M，每個(gè) Task 會(huì)被分到如下 Task 中：hash（pipeline_id）% M 到（hash（pipeline_id）+ N）% M。遍歷 Topic 可能被消費(fèi)的 Task 列表，如果其中包含本 Task，則可對(duì)其進(jìn)行消費(fèi)。

③ 步驟 3：調(diào)整線程池消費(fèi)列表，如果步驟 2 中添加了 Topic，則添加對(duì)應(yīng) Topic 的消費(fèi)。

3、數(shù)據(jù)接入——十萬(wàn)級(jí) QPS 高并發(fā) ID 映射

核心問(wèn)題有兩點(diǎn)： 

（1）數(shù)據(jù)孤島：各個(gè)渠道有自己的內(nèi)容 ID 體系。 

（2）資源開銷大：十萬(wàn)級(jí) QPS，IO 大，成本難以接受。

我們通過(guò)圖中所示的二級(jí)緩存，構(gòu)建了一套高并發(fā) ID 映射的解決方案，能夠打通中臺(tái) ID，同時(shí)節(jié)省百倍的計(jì)算資源。

ID 映射有二級(jí)緩存，一級(jí)是在 Flink 內(nèi)構(gòu)建的渠道 ID 到中臺(tái) ID 的映射，同時(shí)有一個(gè)遠(yuǎn)程的第三方服務(wù)，可以提供實(shí)時(shí)的映射。整體的執(zhí)行機(jī)制為，當(dāng)有消費(fèi)流水進(jìn)來(lái)時(shí)，首先判斷在 Flink 應(yīng)用內(nèi)是否有緩存，如果有就直接返回中臺(tái) ID，如果沒(méi)有，則進(jìn)行遠(yuǎn)程的 ID 映射，更新 Flink 狀態(tài)，返回中臺(tái) ID，最后給業(yè)務(wù)輸出含中臺(tái) ID 的消費(fèi)流水。

我們?cè)?Flink 中構(gòu)建了兩種 cache，一種是可以映射的，將渠道 ID 映射到中臺(tái) ID，另一種是未能映射的渠道 ID 和映射值。我們會(huì)采用不同的機(jī)制，保障數(shù)據(jù)的時(shí)效性和可用性。對(duì)于可以映射的情況，為了應(yīng)對(duì)映射狀態(tài)的不斷膨脹，我們將 TTL 設(shè)置了 7 天，同時(shí)設(shè)置了 LRU 的緩存機(jī)制來(lái)進(jìn)行控制。而未能映射的情況，可能是當(dāng)時(shí)沒(méi)有映射上，而隔一段時(shí)間能夠通過(guò)第三方 ID 映射服務(wù)重新映射到中臺(tái) ID。此時(shí)設(shè)置的 TTL 比較短，常為 1 小時(shí)。同時(shí)為了保障一段時(shí)間后仍然能映射上，采用了 FIFO 的機(jī)制，以保障映射的可用性，同時(shí)成本也能極大的降低。

4、信號(hào)生產(chǎn)——滑動(dòng)大窗口計(jì)算

在內(nèi)容場(chǎng)景中，需要對(duì)內(nèi)容消費(fèi)數(shù)據(jù)的大時(shí)間窗口（如 24 小時(shí)）的每分鐘滑動(dòng)指標(biāo)進(jìn)行日千億次的實(shí)時(shí)流計(jì)算，并基于這樣的數(shù)據(jù)指標(biāo)來(lái)控制業(yè)務(wù)流轉(zhuǎn)，如果我們直接基于 Flink 內(nèi)部的窗口函數(shù)，進(jìn)行實(shí)時(shí)計(jì)算窗口指標(biāo)時(shí)，因不能及時(shí)關(guān)閉窗口，狀態(tài)數(shù)據(jù)會(huì)占用大量的內(nèi)存，導(dǎo)致計(jì)算出現(xiàn)反壓的情況，程序穩(wěn)定性差，容易出現(xiàn)卡死現(xiàn)象。

基于上述挑戰(zhàn)，我們?cè)O(shè)計(jì)了一種高性能的大窗口計(jì)算方法，主要有如下優(yōu)點(diǎn)：

① 傳統(tǒng)的方式需要每次對(duì)大窗口中的全量數(shù)據(jù)做計(jì)算，而現(xiàn)有方式可以復(fù)用前一次計(jì)算結(jié)果，可極大減少計(jì)算量。

② 我們方案中大窗口是邏輯上的大窗口，相比 Flink 原生的窗口計(jì)算會(huì)保留大窗口時(shí)間內(nèi)的原始數(shù)據(jù)，我們?cè)趦?nèi)存中并不存放這些原始數(shù)據(jù)，只存放算法提到的聚合維度的數(shù)據(jù)，同時(shí)利用數(shù)據(jù)淘汰機(jī)制，防止內(nèi)存占用過(guò)大，節(jié)約大量的內(nèi)存資源。

對(duì)實(shí)時(shí)流數(shù)據(jù)根據(jù)數(shù)據(jù)自身的事件時(shí)間是否連續(xù)分為如下不同的幾種情況：

情況一：分鐘級(jí)別滑動(dòng)，每分鐘窗口連續(xù)有流量的情況。

當(dāng)數(shù)據(jù)自身的事件時(shí)間連續(xù)的時(shí)候，我們需要拿到上次大窗口的計(jì)算結(jié)果值，在上次計(jì)算結(jié)果的基礎(chǔ)上，對(duì)窗口的頭部和尾部進(jìn)行加減操作就可以得到新的大窗口的值。

分鐘級(jí)滑動(dòng)每分鐘連續(xù)的大窗口

其中，T（6, 4）代表的是 6min 時(shí)候近 4min 的累計(jì)值大小，其中 6 代表的是當(dāng)前最新時(shí)間，4 代表的是需要統(tǒng)計(jì)的窗口大小，是人為規(guī)定的。M(5) 代表的是第 5min 的值。

情況二：分鐘級(jí)別滑動(dòng)，每分鐘窗口流量不連續(xù)情況。

當(dāng)間隔的時(shí)間小于窗口大小的情況下，計(jì)算當(dāng)前窗口的值需要得到上一個(gè)窗口的值進(jìn)行加減操作，由于數(shù)據(jù)自身的事件時(shí)間中斷，所以要對(duì)最后一次窗口的值進(jìn)行校準(zhǔn)。

分鐘級(jí)滑動(dòng)每分鐘不連續(xù)大窗口

其中，T(5, 4) 代表的是 5min 時(shí)候近 4min 的累計(jì)值大小，其中 5 代表的是當(dāng)前最新時(shí)間，4 代表的是需要統(tǒng)計(jì)的窗口大小，是人為規(guī)定的，M(5) 代表的是第 5min 的值。

情況三：分鐘級(jí)別滑動(dòng)，每分鐘窗口流量不連續(xù)并且當(dāng)間隔的時(shí)間大于窗口的情況。

當(dāng)間隔的時(shí)間大于窗口大小的情況下，由于窗口時(shí)間內(nèi)沒(méi)有出現(xiàn)流量，可以直接認(rèn)為大窗口的計(jì)算值為當(dāng)前分鐘流量值。

分鐘級(jí)滑動(dòng)每分鐘不連續(xù)大窗口

其中，T（6, 4）代表的是 6min 時(shí)候近 4min 的累計(jì)值大小，其中 6 代表的是當(dāng)前最新時(shí)間，4 代表的是需要統(tǒng)計(jì)的窗口大小，是人為規(guī)定的，M（5）代表的是第 5min 的值

5、信號(hào)生產(chǎn)--超大滑動(dòng)窗口的計(jì)算

還有一種場(chǎng)景是超大滑動(dòng)窗口的計(jì)算，每分鐘滑動(dòng)一次，計(jì)算 30 天等超大滑動(dòng)窗口指標(biāo)。這種場(chǎng)景中狀態(tài)極大，資源開銷無(wú)法承受。以 30 天為例，如果只考慮半天的精度，可以將成本降低為千分之一，而精度只損失了百分之一，在成本和精度間達(dá)到了高效平衡。

如上圖所示，計(jì)算單個(gè)內(nèi)容 ID 的超大滑動(dòng)窗口指標(biāo)過(guò)程如下。

（1）狀態(tài)更新：讀取消費(fèi)流水，更新該 ID 的狀態(tài)值。

（2）計(jì)算超大窗口指標(biāo)：基于應(yīng)用內(nèi)狀態(tài)進(jìn)行計(jì)算。具體如下：

① 如果內(nèi)容產(chǎn)生時(shí)間在 N 天內(nèi)：取累計(jì)流量。

② 如果內(nèi)容產(chǎn)生時(shí)間在 N 天前：基于輸入流量的時(shí)間取不同范圍的數(shù)據(jù)，整體半天精度，如 30 天超大窗口的誤差約 1.6%。時(shí)間區(qū)間劃分如下：

a）00:00—15:00：取過(guò)去 N 天+當(dāng)天流量值。

b）15:00—23:59：取過(guò)去 N-1 天+當(dāng)天流量值。

6、信號(hào)生產(chǎn)——TB 級(jí)實(shí)時(shí)流數(shù)據(jù)拼接

這里介紹的是 TB 級(jí)實(shí)時(shí)流數(shù)據(jù)拼接的場(chǎng)景。TB 級(jí)別數(shù)據(jù)拼接，計(jì)算慢、狀態(tài)易丟失，F(xiàn)link 難以支持高可用。通過(guò)引入第三方 KV 存儲(chǔ)來(lái)備份狀態(tài)，保證了高可用和秒級(jí)時(shí)效。

主要思路如上圖所示，我們借助第三方 HBase 存儲(chǔ)完成多流關(guān)聯(lián)。

階段 1：特征拼接，每個(gè)源單獨(dú)加工，抽取自身特征后，進(jìn)行如下過(guò)程：

① 步驟 1：將自身特征同步到 HBase 中，每個(gè)源只更新自身屬性對(duì)應(yīng)的列。HBase 中會(huì)包含每個(gè)內(nèi)容最新最全的屬性。

② 步驟 2：將有變更的內(nèi)容推送到消息隊(duì)列中。當(dāng)前實(shí)現(xiàn)是將所有有變更的內(nèi)容實(shí)時(shí)推送下游，可改造該過(guò)程，多流水位對(duì)齊后再推送，以支持多流拼接的多種語(yǔ)義。

在本階段的存儲(chǔ)設(shè)計(jì)中，HBase 的 Rowkey 為待關(guān)聯(lián)的 Key，列分別為屬性 Key 和屬性值。同時(shí)，我們進(jìn)行了大量?jī)?yōu)化設(shè)計(jì)：

① 批量訪問(wèn)：每 50 個(gè) Key 合并訪問(wèn)，減少 IO。

② 隨機(jī)主鍵：將 Key 進(jìn)行 md5 哈希，讓數(shù)據(jù)均勻分布在 HBase 中，防止熱點(diǎn)，提高隨機(jī)訪問(wèn)性能。

③ 存儲(chǔ)壓縮：部分屬性值較大，將其序列化后，使用 GZIP 壓縮，減少存儲(chǔ)。

④ 過(guò)期機(jī)制：按需設(shè)置 TTL，防止數(shù)據(jù)無(wú)限膨脹。

階段 2：特征輸出，通過(guò)一個(gè)程序統(tǒng)一加工處理，可將每個(gè)內(nèi)容的全量特征輸出到目標(biāo)業(yè)務(wù)系統(tǒng)中。

① 步驟 3：實(shí)時(shí)感知特征有變更的內(nèi)容。

② 步驟 4：批量拉取內(nèi)容的全量特征，HBase 中每一列對(duì)應(yīng)一個(gè)特征，某個(gè)內(nèi)容的全部列即為其全部特征。

③ 步驟 5：入庫(kù)，將從 HBase 中獲取的全量特征，轉(zhuǎn)換成目標(biāo)存儲(chǔ)格式，輸出到目標(biāo)系統(tǒng)。

7、基于規(guī)則引擎的實(shí)時(shí)信號(hào)觸發(fā)器

根據(jù)很多配置規(guī)則，可以一鍵支持，秒級(jí)觸發(fā)，按照規(guī)則分發(fā)給業(yè)務(wù)系統(tǒng)。

首先在規(guī)則管理平臺(tái)，業(yè)務(wù)方配置規(guī)則；閾值可以通過(guò)預(yù)估模塊去訓(xùn)練并進(jìn)行更新，也可以手動(dòng)設(shè)置。規(guī)則里面有靜態(tài)規(guī)則或者動(dòng)態(tài)規(guī)則。同時(shí)有一些閾值服務(wù)，包括閾值同步和閾值查詢的能力。接著，在規(guī)則執(zhí)行引擎，數(shù)據(jù)接入實(shí)時(shí)信號(hào)和消費(fèi)流水，拉取到各個(gè)執(zhí)行引擎里面，基于規(guī)則類型進(jìn)行規(guī)則路由，分發(fā)到對(duì)應(yīng)的動(dòng)態(tài)規(guī)則匹配和固定規(guī)則模塊匹配，進(jìn)行相應(yīng)的信號(hào)觸發(fā)。配置加載，可以實(shí)時(shí)的加載閾值。設(shè)置信號(hào)去重的機(jī)制，可以保障同一信號(hào)短時(shí)間內(nèi)不會(huì)重新觸發(fā)給下游。之后進(jìn)行數(shù)據(jù)的分發(fā)，產(chǎn)生的信號(hào)會(huì)按照規(guī)則，分發(fā)到各自的系統(tǒng)。

規(guī)則類型主要分為固定規(guī)則和動(dòng)態(tài)規(guī)則。固定規(guī)則，即所有內(nèi)容的閾值相同；動(dòng)態(tài)規(guī)則，不同內(nèi)容閾值可以精細(xì)化設(shè)置。動(dòng)態(tài)規(guī)則的人力成本較高，但是對(duì)一些成本非常高的場(chǎng)景，可以降低整體成本。

規(guī)則定義可以分為規(guī)則條件表達(dá)式和規(guī)則動(dòng)作。比如騰訊視頻的流量大于多少就可以用一個(gè)條件表達(dá)式進(jìn)行配置。同時(shí)會(huì)攜帶一些信息，比如去重周期等等。執(zhí)行動(dòng)作，是如何將匹配的信號(hào)分發(fā)給下游，通過(guò) API 或者相應(yīng)的消息隊(duì)列。

執(zhí)行優(yōu)化有三方面。

靈活引擎：基于 Flink + Aviator， 就可以構(gòu)建一個(gè)分布式的，支持規(guī)則動(dòng)態(tài)添加和修改的輕量級(jí)的規(guī)則匹配引擎。

二級(jí)緩存：針對(duì)每一個(gè)輸入信號(hào)，拉取其相關(guān)規(guī)則和閾值，因 IO 和 QPS 較高，整體成本非常大。二級(jí)緩存是規(guī)則 ID 和閾值 ID 直接去請(qǐng)求內(nèi)容服務(wù)。然后引入二級(jí)緩存機(jī)制，通過(guò)拉取的閾值進(jìn)行緩存之后，可以進(jìn)行節(jié)省上百倍的資源。

預(yù)編譯：規(guī)則執(zhí)行的過(guò)程為，首先將內(nèi)容流量轉(zhuǎn)為 Map，表達(dá)式編譯為字節(jié)碼，進(jìn)行執(zhí)行，得到 True or False。如果是 False 就沒(méi)匹配上。在整個(gè)過(guò)程中消耗比較大的是將表達(dá)式編譯成字節(jié)碼。構(gòu)建表達(dá)式到字節(jié)碼的緩存，該過(guò)程耗時(shí)會(huì)從 0.1ms 變成 0.04μs，在引入緩存的預(yù)編譯以后，單次規(guī)則匹配就可以節(jié)省上千倍的算力開銷。

8、數(shù)據(jù)治理——端到端全鏈路服務(wù)可觀測(cè)性

端到端的鏈路非常長(zhǎng)，從 ODS 到 DWD， 到 DWS 層，到 ADS 層。對(duì)應(yīng)一些延遲問(wèn)題難以感知，有時(shí)需要業(yè)務(wù)方反饋才可知有延遲問(wèn)題。同時(shí)當(dāng)發(fā)現(xiàn)延遲以后的定位時(shí)間非常長(zhǎng)。引入了服務(wù)可觀測(cè)系統(tǒng)的能力，將延遲的感知和定位問(wèn)題環(huán)節(jié)從小時(shí)級(jí)縮短到分鐘級(jí)。

解決方案主要是引入了下面的幾個(gè)模塊：

數(shù)據(jù)染色：本模塊集成到各個(gè)加工程序中，將本環(huán)節(jié)和上游各個(gè)環(huán)節(jié)的時(shí)效性信息染色到輸出數(shù)據(jù)中，如事件時(shí)間、輸出時(shí)間等。

時(shí)效性統(tǒng)計(jì)：因?yàn)槊總€(gè)環(huán)節(jié)的輸出包含自身以及上游各個(gè)環(huán)節(jié)的時(shí)間信息，可基于某個(gè)環(huán)節(jié)的輸出數(shù)據(jù)，統(tǒng)計(jì)從數(shù)據(jù)源到當(dāng)前環(huán)節(jié)端到端分環(huán)節(jié)、分?jǐn)?shù)據(jù)源的時(shí)效性信息。

延遲監(jiān)控：基于統(tǒng)計(jì)模塊計(jì)算的數(shù)據(jù)，監(jiān)控端到端的延遲。

可觀測(cè)性分析工具：可以提供全鏈路的延遲分析。用戶可以選擇對(duì)應(yīng)的主題，個(gè)性化設(shè)置延遲的閾值，分析不同節(jié)點(diǎn)的延遲情況，當(dāng)有延遲時(shí)，可以快速定位延遲源頭。

9、數(shù)據(jù)治理——退場(chǎng)

因?yàn)樘剿餍孕枨蠖啵杀静粩嗯蛎?，通過(guò)無(wú)效服務(wù)的下線，實(shí)現(xiàn)整體成本可控。通過(guò)看板無(wú)人使用的過(guò)程，與數(shù)據(jù)使用方的業(yè)務(wù)溝通來(lái)下線無(wú)人使用的數(shù)據(jù)看板。當(dāng)確實(shí)無(wú)人使用的時(shí)候，把相對(duì)于的數(shù)據(jù)進(jìn)行下線，節(jié)省成本。

同時(shí)還有一個(gè)解決方案是優(yōu)化 TTL。部分服務(wù)場(chǎng)景起初需要去分析過(guò)去半年或者一年的數(shù)據(jù)，運(yùn)行一段時(shí)間后，可能只用到過(guò)去一周的數(shù)據(jù)，這樣我們就可以根據(jù)訪問(wèn)記錄去和用戶溝通。將一些熱數(shù)據(jù)保存在實(shí)時(shí)的 OLAP 系統(tǒng)里面，一些冷數(shù)據(jù)通過(guò)離線進(jìn)行分析，降低我們資源的成本 。

10、數(shù)據(jù)治理——旁路系統(tǒng)保障狀態(tài)高可用

部分場(chǎng)景對(duì)數(shù)據(jù)的一致性要求非常高，但是開發(fā)過(guò)程中，依賴眾多，有小概率導(dǎo)致程序崩潰，當(dāng)崩潰后程序狀態(tài)就丟失了。引入旁路系統(tǒng)后，可以保障核心狀態(tài)是 100% 可靠的。

我們構(gòu)建了旁路系統(tǒng)，保障 Flink 狀態(tài)異常丟失后核心狀態(tài)的高可用。架構(gòu)如圖所示，主要由兩個(gè)模塊構(gòu)成

① 旁路系統(tǒng)：程序外起一個(gè)異步作業(yè)，將核心狀態(tài)從輸出中實(shí)時(shí)同步到 Redis 中。

② Flink 應(yīng)用內(nèi)狀態(tài)恢復(fù)模塊：為訪問(wèn) State 的前置邏輯，如果 Key 在應(yīng)用內(nèi)狀態(tài)中丟失，則從遠(yuǎn)程 Redis 中恢復(fù)。

四、未來(lái)規(guī)劃

未來(lái)規(guī)劃主要在業(yè)務(wù)支撐、流批一體和資源優(yōu)化三大方面。

（1）業(yè)務(wù)支撐。整體業(yè)務(wù)功能已經(jīng)比較完備，接下來(lái)要更加關(guān)注精細(xì)化的運(yùn)營(yíng)需求，提高服務(wù)體驗(yàn)。還要進(jìn)一步實(shí)現(xiàn)核心能力的實(shí)時(shí)化，提高推薦效果和分析決策的效率。

（2）流批一體，實(shí)現(xiàn)一套代碼，兩種執(zhí)行模式；一套系統(tǒng)，統(tǒng)一技術(shù)棧；一套運(yùn)維，統(tǒng)一資源調(diào)度。數(shù)倉(cāng)開發(fā)主要分為計(jì)算和存儲(chǔ)，存儲(chǔ)將使用數(shù)據(jù)湖模式，同時(shí)探索用 SQL 來(lái)統(tǒng)一離線和實(shí)時(shí)的技術(shù)棧，來(lái)保證更高效的開發(fā)。

（3）資源優(yōu)化。順應(yīng)降本增效的大環(huán)境，我們會(huì)探索資源彈性自適應(yīng)技術(shù)的應(yīng)用，和存儲(chǔ)優(yōu)化，進(jìn)一步降低成本。