一、實時信號應(yīng)用

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

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

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

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

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

3、內(nèi)容創(chuàng)作精細運營

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

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

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

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

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

2、信號加工

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

3、信號觸發(fā)

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

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

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

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

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

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

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

1、整體架構(gòu)

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

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

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

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

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

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

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

2、數(shù)據(jù)接入——動態(tài)實時源自適應(yīng)感知

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

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

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

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

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

（2）配置中心：存放所有拓撲的消息隊列，如拓撲 ID、消費并行度、Kafka 配置。

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

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

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

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

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

核心問題有兩點： 

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

（2）資源開銷大：十萬級 QPS，IO 大，成本難以接受。

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

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

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

4、信號生產(chǎn)——滑動大窗口計算

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

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

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

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

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

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

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

分鐘級滑動每分鐘連續(xù)的大窗口

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

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

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

分鐘級滑動每分鐘不連續(xù)大窗口

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

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

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

分鐘級滑動每分鐘不連續(xù)大窗口

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

5、信號生產(chǎn)--超大滑動窗口的計算

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

如上圖所示，計算單個內(nèi)容 ID 的超大滑動窗口指標過程如下。

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

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

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

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

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

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

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

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

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

階段 1：特征拼接，每個源單獨加工，抽取自身特征后，進行如下過程：

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

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

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

① 批量訪問：每 50 個 Key 合并訪問，減少 IO。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因為探索性需求多，成本不斷膨脹，通過無效服務(wù)的下線，實現(xiàn)整體成本可控。通過看板無人使用的過程，與數(shù)據(jù)使用方的業(yè)務(wù)溝通來下線無人使用的數(shù)據(jù)看板。當(dāng)確實無人使用的時候，把相對于的數(shù)據(jù)進行下線，節(jié)省成本。

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

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

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

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

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

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

四、未來規(guī)劃

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

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

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

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