作者 | 弘遠君

導讀

本文以百度垂類離線計算系統(tǒng)的演進方向為主線，詳細描述搜索垂類離線計算系統(tǒng)發(fā)展過程中遇到的問題，以及對應的解決方案。架構(gòu)演進過程中一直奉行“沒有最好的架構(gòu)，只有最合適的架構(gòu)”的宗旨，面對不同階段遇到的問題，給出了適合的解決方案。尤其是近10年來的超大規(guī)模系統(tǒng)架構(gòu)的升級， 一方面需要考慮系統(tǒng)本身的通用性和適配性，以滿足多個業(yè)務方的需求；另一方面需要結(jié)合系統(tǒng)當前運行的特點，在易用性、穩(wěn)定性、智能化等不同方面進行提升。希望讀者能在了解系統(tǒng)演進的過程中獲得一些啟發(fā)。

01相關(guān)背景介紹

在過去，用戶通過“百度一下”得到的搜索結(jié)果是從互聯(lián)網(wǎng)上抓取來的結(jié)果，也被稱為“自然結(jié)果”。隨著網(wǎng)絡(luò)信息日益豐富，自然結(jié)果不能有效滿足用戶需求。為了解決自然結(jié)果無法滿足搜索需求的問題，提出了針對各個垂類深耕的搜索結(jié)果的解決方案，一方面為用戶帶來的更優(yōu)質(zhì)的內(nèi)容，讓用戶體驗即搜即得的便捷，另一方面也可以幫助優(yōu)質(zhì)內(nèi)容生產(chǎn)者提升訪問量。

隨著業(yè)務發(fā)展，除了標準通用的業(yè)務處理需求變更之外，越來越多的業(yè)務有自定義代碼的更新需求。通過自定義數(shù)據(jù)處理，一方面，產(chǎn)品負責同學可以將原始傳入的數(shù)據(jù)按照業(yè)務需求進行定制化處理，將原始數(shù)據(jù)轉(zhuǎn)化為最終搜索的結(jié)果數(shù)據(jù)。 另一方面，通用默認的一些功能機制限制了少量垂類的發(fā)展，業(yè)務希望引入更多的策略 模型邏輯 信號等處理以及打分機制，提升排序召回的效果。

在這樣的背景下，業(yè)務對于數(shù)據(jù)加工計算的框架引擎的需求越來越強烈，并且功能也逐漸成為整個垂搜離線處理過程中不可或缺的一部分。

02計算系統(tǒng)演進過程

百度搜索系統(tǒng)離線數(shù)據(jù)處理從時間線的發(fā)展階段來說一共經(jīng)歷如下幾個階段：

a.原始離線處理系統(tǒng): 本階段主要是實現(xiàn)業(yè)務加工入口從0到1的構(gòu)建。整體上還沒有形成完備的框架體系并且開發(fā)成本較高，并且所有業(yè)務邏輯混在一個公共服務中，不同數(shù)據(jù)通過不同配置調(diào)用不同的策略邏輯。

b.業(yè)務離線處理架構(gòu): 本階段初步形成一整套的業(yè)務服務處理框架，有統(tǒng)一的服務框架和開發(fā)階段，實現(xiàn)了云原生和服務隔離的模式。

c.Serverless架構(gòu): 本階段業(yè)務的接入效率上進一步提高，業(yè)務從管理服務面向轉(zhuǎn)向管理業(yè)務加工函數(shù)，業(yè)務只需注冊函數(shù)就可以快速測試上線，同時支持容器實例的自動伸縮，使得在業(yè)務的使用效率得到的極大提升的同時相應資源成本急劇壓縮。

d.數(shù)據(jù)智能架構(gòu): 在原有服務部署的基礎(chǔ)上同時實現(xiàn)了數(shù)據(jù)的管理，從函數(shù)管理進一步升級成為需求管理，實現(xiàn)多語言服務框架支持的基礎(chǔ)上，成本進一步壓縮&效率提升。

03計算系統(tǒng)核心設(shè)計核心思路

&核心實現(xiàn)

下面詳細闡述各個階段的詳細特點以及核心實現(xiàn)。

3.1 原始離線處理系統(tǒng)

這套架構(gòu)應用于2018以前，當時垂類的發(fā)展整體屬于起步階段。該階段業(yè)務主要的需求就是可以將原始的業(yè)務數(shù)據(jù)直接上線。架構(gòu)的主要精力聚焦于通用業(yè)務能力的建設(shè)。隨著業(yè)務的逐步深耕，發(fā)現(xiàn)有少量的業(yè)務慢慢演化出來自定義加工的需求。

根據(jù)當時的業(yè)務需求，最終從原有的數(shù)據(jù)加工模塊中衍生出業(yè)務數(shù)據(jù)加工系統(tǒng)。當前階段的數(shù)據(jù)加工處理方式是使用統(tǒng)一Handler處理方式，當然這個處理并非是必選項，多數(shù)業(yè)務仍然不需要自定義加工處理。各業(yè)務之間也完全沒有數(shù)據(jù)隔離，這種架構(gòu)最核心的意義就是從無到有提供業(yè)務的自定義加工能力。如下圖所示，此時計算系統(tǒng)只包含計算引擎部分，其他系統(tǒng)完全沒有建設(shè)。下面會對該系統(tǒng)的部分細節(jié)進行詳細說明。

3.1.1 業(yè)務特點

這個時期的業(yè)務特點主要有兩個：

多數(shù)業(yè)務，核心訴求最主要的是通用能力的建設(shè)。

個別業(yè)務，有少量簡單的自定義加工處理的需求。

所以這個時間點的核心主要是為了解決業(yè)務加工入口的問題。

3.1.2 核心設(shè)計

初版本的離線架構(gòu)模塊非常簡單，如下圖所示藍色部分。隨著業(yè)務發(fā)展，為了滿足業(yè)務自定義加工的需求，引入紅色數(shù)據(jù)通路，其中統(tǒng)一數(shù)據(jù)加工模塊就是主要處理業(yè)務自定義加工邏輯。

如上圖所示，灰色部分是業(yè)務外層接入的數(shù)據(jù)系統(tǒng)，最開始的時候只有XML、POST 和 數(shù)據(jù)隊列的這種模式。藍色部分就是業(yè)務沒有自定義時候原始的數(shù)據(jù)框架代碼。紅色部分就是為了針對業(yè)務自定義需求引入的框架模塊：

用戶數(shù)據(jù)代理：主要是為了適配業(yè)務數(shù)據(jù)接入方式，數(shù)據(jù)的協(xié)議打平，主要是不同用戶協(xié)議的RPC做建庫層的數(shù)據(jù)轉(zhuǎn)化。

用戶通用需求：主要是為用戶共性需求做統(tǒng)一處理，會根據(jù)不同業(yè)務的不同配置做功能處理：比如業(yè)務圖片視頻的轉(zhuǎn)化處理，業(yè)務用戶版本管理處理以及用戶的核心機制等。

統(tǒng)一數(shù)據(jù)加工模塊：主要是為了統(tǒng)一用戶數(shù)據(jù)的加工處理，主要是給所有接入的業(yè)務的數(shù)據(jù)提供了一個可以數(shù)據(jù)加工的入口。

3.2 業(yè)務處理架構(gòu)

如上文所述3.1架構(gòu)核心價值是自定義加工能力的從0到1的建設(shè)，然而隨著業(yè)務的快速發(fā)展，越來越多的業(yè)務需要自定義加工能力。業(yè)務自定義加工的需求從原來個位數(shù)迅速膨脹了10倍。因此，為了滿足業(yè)務在自定義開發(fā)上易用性和穩(wěn)定性的訴求，將原來3.1的中心化的處理模式升級成為服務框架的模式。總體上來說，當前階段的計算系統(tǒng)建設(shè)已經(jīng)基本具備了服務層和業(yè)務層兩層：

業(yè)務層：業(yè)務通過平臺已經(jīng)基本上可以實現(xiàn)，基礎(chǔ)的服務管理。

服務層：對計算引擎進行重構(gòu)，讓新的服務框架支持業(yè)務的高效開發(fā)。

下面會對該系統(tǒng)的部分細節(jié)進行詳細說明。

3.2.1 業(yè)務特點

由于3.1中上一代系統(tǒng)數(shù)十個業(yè)務自定義需求統(tǒng)一在同一個模塊里面開發(fā)&統(tǒng)一線上運行，遇到了主要如下幾方面問題：

效率：業(yè)務在相同的模塊里面開發(fā)，導致業(yè)務開發(fā)上線的過程中經(jīng)常遇到?jīng)_突，以及上線排隊的問題，導致整體生效周期比較長。

穩(wěn)定性：由于這種業(yè)務流量混合的模式隔離性比較差，導致單個業(yè)務出問題，經(jīng)常會影響所有的業(yè)務。

因此，架構(gòu)構(gòu)建出完善的服務框架，業(yè)務可以基于服務框架構(gòu)建自己的業(yè)務代碼，從效率和穩(wěn)定性兩個方面解決上述問題：

效率：服務開發(fā)上線的過程是完全隔離的，業(yè)務在開發(fā)上線的過程中完全沒有業(yè)務阻塞，整體服務上線周期從天級縮短到小時級別。

穩(wěn)定性：由于每個業(yè)務服務執(zhí)行邏輯都有完全獨立的app，導致業(yè)務的穩(wěn)定性大大提升，不會存在業(yè)務之間的互相影響。

3.2.3 核心設(shè)計

業(yè)務處理框架：建設(shè)一個數(shù)據(jù)處理框架，業(yè)務可以基于這個框架來實現(xiàn)自己的業(yè)務處理功能。

任務平臺：每個任務注冊、升級、管理都可以通過任務平臺來進行管理。

統(tǒng)一網(wǎng)關(guān)：所有數(shù)據(jù)的統(tǒng)一入口，統(tǒng)一接收上游數(shù)據(jù)，并且做數(shù)據(jù)的轉(zhuǎn)發(fā)和分發(fā)。

業(yè)務APP：每個業(yè)務都有自己獨立服務的app，每個業(yè)務開發(fā)是基于框架的獨立分支開發(fā)，上線是每個業(yè)務單獨上線，業(yè)務處理的服務流量也都是完全隔離的。

3.3 Serverless架構(gòu)

如上文中3.2表述已經(jīng)解決系統(tǒng)隔離性的問題，業(yè)務快速發(fā)展從最開始的幾十個，發(fā)展到上百個業(yè)務應用。當業(yè)務發(fā)展到井噴狀態(tài)后，服務框架的形式已經(jīng)完全不能滿足業(yè)務的開發(fā)需求。

Serverless架構(gòu)如下圖所示，此時計算系統(tǒng)整體版圖已經(jīng)相對完善，相比上一代計算架構(gòu)，不僅僅業(yè)務層包含的全流程的優(yōu)化，提供了完整的工具功能；服務層充分考慮的架構(gòu)的設(shè)計和復用，同時增加控制層增加智能調(diào)度的功能針對系統(tǒng)流量進行資源的動態(tài)調(diào)度。

下面會對該系統(tǒng)的部分細節(jié)進行詳細說明。

3.3.1 業(yè)務特點&解決問題

業(yè)務學習成本：大量的新業(yè)務接入需要進行開發(fā)，導致框架本身學習成本需要幾天的時間，新業(yè)務的接入和開發(fā)的時間基本上都在周級別。

資源如何節(jié)省：大量的業(yè)務也帶來app的高速膨脹，原來接入的數(shù)百臺機器已經(jīng)用滿，到了資源瓶頸，當前的資源量無法支持業(yè)務的快速膨脹。

3.3.3 核心設(shè)計

應用層：針對于基礎(chǔ)服務架構(gòu)，上面給業(yè)務開放的各種云服務，從業(yè)務的 接入、開發(fā)到后面的調(diào)試、測試，到服務上線后的監(jiān)控。

服務層：這部分是整體架構(gòu)的基礎(chǔ)，應用層都是基于這里進行開發(fā)的，這部分是整個系統(tǒng)的基石，屬于整體系統(tǒng)的核心框架。

調(diào)度層：通過根據(jù)流量形式的擴縮容，保證后續(xù)服務可以自動化的進行服務操作。

下面重點介紹一下 服務層的主要內(nèi)容，對業(yè)務來說主要包含兩部分:

極致抽象的業(yè)務框架：是核心框架基礎(chǔ)中的基礎(chǔ)，提供新的開發(fā)范式同時，為后續(xù)智能調(diào)度奠定良好基礎(chǔ)。

高度復用的基礎(chǔ)服務：強大豐富的后端服務能力封裝，支持業(yè)務低成本復用，降低開發(fā)成本同時提升穩(wěn)定性。同時系統(tǒng)還提供強大的編排能力，低成本支持業(yè)務從簡單到復雜的發(fā)展。

極致抽象的業(yè)務框架

業(yè)務框架作為FaaS層和業(yè)務代碼的載體，是整個業(yè)務邏輯的代碼框架。框架本身維護數(shù)據(jù)流語義，面向有向無環(huán)圖（DAG）的數(shù)據(jù)流，調(diào)用業(yè)務函數(shù)代碼。業(yè)務框架是面向有向無環(huán)圖的數(shù)據(jù)流實時計算，基于公司基礎(chǔ)的數(shù)據(jù)流框架支持完備的流式計算語義，結(jié)合業(yè)務場景需要功能構(gòu)建出業(yè)務框架：

如上圖左邊就是用戶實際的執(zhí)行代碼，對于函數(shù)的接口定義：入?yún)⒑头祷刂刀际荄ict類型。業(yè)務的代碼邏輯直接在函數(shù)中實現(xiàn)，需要變更的數(shù)據(jù)，如上圖所示業(yè)務在根目錄下增加了一個時間戳字段，然后把更新后的結(jié)果傳遞給下游。

業(yè)務端使用開發(fā)成本低的腳本語言進行開發(fā)（例如Python），基礎(chǔ)服務框架使用C++實現(xiàn)，結(jié)合數(shù)據(jù)壓縮、批處理、數(shù)據(jù)預分發(fā)等機制，使得業(yè)務可以在簡化服務框架開發(fā)同時優(yōu)化服務運行性能。通過架構(gòu)層面的優(yōu)化策略來達到服務性能和開發(fā)成本的平衡。

高度復用的基礎(chǔ)服務

業(yè)務依賴的后端服務，包括多媒體長留服務，數(shù)據(jù)存儲服務，策略計算等十項服務能力，所有的服務架構(gòu)的支持目標都是通過簡單配置、少量代碼的方式進行服務接入。

架構(gòu)通用能力：包括索引處理(倒排、正排、向量索引)，數(shù)據(jù)審核(政治敏感數(shù)據(jù)/色情數(shù)據(jù)識別&過濾)，多路分發(fā)、數(shù)據(jù)建庫等能力。

與業(yè)務聯(lián)合研發(fā)的能力：數(shù)據(jù)的低質(zhì)過濾能力(實現(xiàn)數(shù)據(jù)清洗/歸一化/數(shù)據(jù)去重/類目拼接)，數(shù)據(jù)多元融合，數(shù)據(jù)質(zhì)量打分計算(質(zhì)量打分/作弊識別/物料打分)。

基于公司強大基礎(chǔ)能力: 多媒體處理服務(外鏈轉(zhuǎn)內(nèi)鏈/OCR/水印計算/重復圖計算/主體識別/視頻轉(zhuǎn)儲等)，自然語言處理服務，數(shù)據(jù)沉淀服務。

支持的基礎(chǔ)服務(BaaS服務)主要是兩個特點:簡單穩(wěn)定 & 充分集成公司內(nèi)其他優(yōu)質(zhì)能力。用戶通過SDK調(diào)用、算子復用和數(shù)據(jù)流復用等方式直接進行能力復用，完全不需要進行服務的部署和管理，服務易用性、穩(wěn)定性由搜索中臺來處理。使用任何服務后端都可以收口在一個地方，避免業(yè)務頻繁跟多個服務團隊進行交流處理，極大降低業(yè)務使用成本。業(yè)務最開始接入通常只需要簡單的少數(shù)功能（例如，修改部分字段的信息)，多數(shù)業(yè)務直接用我們提供的平臺化的開發(fā)模板即可完成開發(fā)。但是隨著業(yè)務的逐步深耕，業(yè)務逐步使用，業(yè)務會向復雜逐步過渡，例如搜索中臺某業(yè)務通過復用數(shù)十種能力的組合使用，建設(shè)出具有深度定制的數(shù)據(jù)系統(tǒng)。

3.4 數(shù)據(jù)智能架構(gòu)

如上文中3.3 表述已經(jīng)很大程度上解決業(yè)務接入效率的問題并且在資源的使用效率上實現(xiàn)根據(jù)流量的擴縮容實現(xiàn)的資源極大程度的節(jié)省，業(yè)務的app的數(shù)量已經(jīng)發(fā)展到上千個，業(yè)務對于效率、成本、服務質(zhì)量提出來更高的要求。至此已經(jīng)構(gòu)建出，從業(yè)務層、邏輯層、服務層、控制層的四層架構(gòu)，實現(xiàn)離線計算系統(tǒng)從指令式計算系統(tǒng)到聲明式計算系統(tǒng)的徹底轉(zhuǎn)變。

3.4.1 業(yè)務特點

效率業(yè)務的迭代開發(fā)很多都是針對少數(shù)幾個字段，但是當前業(yè)務同學仍然需要了解服務全拓撲才能開發(fā)。

隨著業(yè)務復雜深耕業(yè)務的開發(fā)迭代業(yè)務開發(fā)者出現(xiàn)多語言開發(fā)情況來提高服務的開發(fā)和執(zhí)行效率。

業(yè)務如何實現(xiàn)新類目的快速接入、在不了解全面的情況下快速迭代。

計算引擎執(zhí)行效率更高，用更少的資源計算跑更多的服務資源。

業(yè)務問題能不能快速定位&發(fā)現(xiàn)以及問題的自動處理。

3.4.2 核心思路

從設(shè)計思路來看當前系統(tǒng)架構(gòu)是上一代架構(gòu)的拓展：

數(shù)據(jù)管理：出了原始服務管理外，引入數(shù)據(jù)全面管理，為列計算奠定基礎(chǔ)。

編排能力：將原來業(yè)務手動編排的函數(shù)能力擴展成為需求聲明式自動編排的能力。

服務處理：極致高效的服務處理能力，支持多種不同業(yè)務開發(fā)者的高效開發(fā)效率，將整體的計算從行計算轉(zhuǎn)向列計算，提高整體的計算復用。

控制能力：將原來自動伸縮的能力擴展成為智能控制能力，做到問題的自動識別、自動分發(fā)、自動分析 和 自動處理。

整體架構(gòu)的設(shè)計核心理念大致是多層抽象、分層復用。

3.4.3 核心設(shè)計

當前階段的核心設(shè)計已經(jīng)呈現(xiàn)出完整的四層架構(gòu)的抽象能力：

應用層：業(yè)務直接可見的相關(guān)服務，包括業(yè)務從開始數(shù)據(jù)接入到服務運行的全周期各階段各種應用。

邏輯層：也可以稱之為編排層，負責將原始的業(yè)務需求表達轉(zhuǎn)化成為線上真實運行的服務， 業(yè)務通過Codeless 平臺化選擇勾選自己的功能集合，以及對應數(shù)據(jù)映射關(guān)系進行提交，將用戶提供的功能 & 數(shù)據(jù)的綁定關(guān)系轉(zhuǎn)化為業(yè)務的自定義的功能 以及映射關(guān)系。

服務層：計算系統(tǒng)的核心，業(yè)務實際計算運行在這層，主要包含計算引擎 和服務架構(gòu)兩部分。向上承接邏輯層的編排結(jié)果運行服務，向下提供基礎(chǔ)信號作為控制層的輸入。

控制層：包含智能調(diào)度和智能控制兩部分：智能控制主要是通過自動接受業(yè)務指標數(shù)據(jù)進行智能控制保證服務穩(wěn)定，而智能調(diào)度是除了根據(jù)數(shù)據(jù)流量進行進行自動伸縮以外還可以根據(jù)業(yè)務服務關(guān)系進行流量復用，減少業(yè)務的重復計算。

下面我們針對部分核心系統(tǒng)（如上圖藍色部分）的設(shè)計作展開說明。

需求表達邏輯

需求邏輯的表達的核心就是如何把用戶原始的功能需求轉(zhuǎn)化成真是線上服務的算子、配置、關(guān)系的表達。用戶最原始的輸入包含兩部分：

業(yè)務數(shù)據(jù)：業(yè)務數(shù)據(jù)需要功能的最小單位進行切割，后續(xù)算子進行配置轉(zhuǎn)化以及服務綁定的列式計算。這里說的有點繞口，其實本質(zhì)上就是把業(yè)務數(shù)據(jù)的原始Proto或者數(shù)據(jù)Schema注冊一下就可以。

功能集合：功能集合既可以用戶直接使用的系統(tǒng)提供的默認模版的功能集合 也可以是用戶通過平臺自定義的集合，值的注意的是每個功能都都有其指定的傳入?yún)?shù)，比如圖片計算，需要傳入圖片URL，向量計算需要傳入原始數(shù)據(jù) & 向量參數(shù)等等。功能完成后也會有對應的輸出結(jié)果業(yè)務可以指定。

獲取完成用戶的原始輸入后，架構(gòu)通過兩層邏輯映射的方式，將原始用戶需求轉(zhuǎn)化成為線上服務部署信息：

需求表達服務：用戶的原始需求轉(zhuǎn)化為功能模版的組合。這個階段會根據(jù)用戶配置，將原始算子和數(shù)據(jù)進行綁定，原始用戶抽象的需求實例化成帶數(shù)據(jù)的算子集合。

需求編排服務：通過業(yè)務算子的本身的依賴關(guān)系和數(shù)據(jù)依賴的血緣關(guān)系進行表達組合，將帶數(shù)據(jù)的算子構(gòu)建出N個有向無環(huán)圖。

整體需求表達都可以通過Codeless方式表達，通過描述功能集合數(shù)據(jù)集合描述方式，加之兩層邏輯映射的轉(zhuǎn)化，這樣就可以將原始用戶聲明式需求直接轉(zhuǎn)化線上服務關(guān)系和系統(tǒng)配置，并且服務的算子的拓撲關(guān)系完全可以通過業(yè)務的數(shù)據(jù)關(guān)系表達自動化推導出來， 實現(xiàn)了95%以上的功能可以完全自動化配置實現(xiàn)，當然有個別服務無法低成本轉(zhuǎn)化表達的，也提供了人工接口。

計算引擎實現(xiàn)

計算引擎層的核心組件大致分成兩部分，圖計算引擎 & 多語言算子的執(zhí)行引擎 。

圖計算引擎：主要控制的業(yè)務拓撲的表達關(guān)系，通過有向無環(huán)圖來表達。

算子執(zhí)行引擎：主要控制業(yè)務真實業(yè)務函數(shù)的執(zhí)行，不同語言有不同的函數(shù)實現(xiàn)，例如Python、GoLang、C/C++都有自己的執(zhí)行引擎。

下面針對兩部分進行仔細說明

線程管理：每個業(yè)務算子默認都是多線程的分發(fā)模式（如果業(yè)務算子只支持單線程，可以把線程數(shù)設(shè)置成1）。

分發(fā)模式：數(shù)據(jù)消費分發(fā)模式默認是輪詢分發(fā)，固定KEY分發(fā)（實現(xiàn)保序）以及按消費能力分發(fā)。

數(shù)據(jù)壓縮：這個默認支持常見數(shù)據(jù)壓縮方法，是可選的吞吐優(yōu)化手段，支持LZ4、Gzip、Snappy等常見壓縮算法。

圖計算引擎實現(xiàn)：實現(xiàn)的核心功能就是實現(xiàn)支持表達有向無環(huán)圖的框架，使用C++實現(xiàn)的，圖下圖部分中，藍色部分就是有向無環(huán)圖的框架實現(xiàn)，當然我們這個框架的底層實現(xiàn)支持了多種數(shù)據(jù)的表達：

本地隊列表達：如圖左下角部分表達的就是一個簡單的拓撲表達，拓撲關(guān)系是通過本地的無鎖隊列進行串聯(lián)的，每個隊列下面掛載一個業(yè)務算子，業(yè)務算子處理完成數(shù)據(jù)后，算子拓撲配置管理分發(fā)到下游的本地隊列中，如果是最后一個算子，數(shù)據(jù)結(jié)果全部處理完成后輸出到遠程隊列Producer中。左側(cè)這邊是框架內(nèi)部的通用功能：

遠程隊列表達：每個藍色大框表示一個具體實例，實例之間使用遠程隊列交互，如果每個實例里面只有一個業(yè)務算子，這種的交互方式類似于遠程隊列的表達方式。

混合方式表達：更多使用方式是混合使用，一個巨型拓撲會拆分成多個子拓撲，每個子拓撲使用本地隊列的方式進行表達，而子拓撲之間使用遠程隊列的方式進行表達。

多語言引擎執(zhí)行層：語言執(zhí)行層整體框架整體根據(jù)不同的語言有不同實現(xiàn)模式，大體上分成三部分：編譯型、解釋型、原生C++。

解釋型：最典型的就是Python實現(xiàn)方式，這種方式也是過去同學最喜歡用的開發(fā)語言之一。圖上圖最上面，左邊灰色部分是C++開發(fā)的部分，最右邊黃色部分是業(yè)務代碼，中間這部分就是C++轉(zhuǎn)Python的交互引擎調(diào)用。這種方式的本質(zhì)就C++的開發(fā)引擎使用PyBind實現(xiàn)指定接口服務解釋器，根據(jù)指定的數(shù)據(jù)序列化和反序列化方式進行操作，在函數(shù)調(diào)用時再實時轉(zhuǎn)化為python的Dict。

編譯型：典型是Golang的使用方式。與Python的實現(xiàn)類似，左邊灰色部分是C++開發(fā)的部分，最右邊黃色部分是Golang業(yè)務代碼，中間是C++轉(zhuǎn)Golang的交互引擎。Golang的實現(xiàn)相比Python的方式有點復雜，本質(zhì)是通過原生CGO作為用戶接口，為了統(tǒng)一用戶接口層，其實分成兩部分：左半部分是直接跟C++交互，直接用C++實現(xiàn)負責把原生C++轉(zhuǎn)化為基礎(chǔ)的C類型的函數(shù)指針進行調(diào)用。右半部分使用Golang實現(xiàn)負責把原生序列化好的函數(shù)反序列化成業(yè)務結(jié)構(gòu)體，然后再進行真正調(diào)用。

原生C++：這里很多人可能覺得奇怪，C++不是也是編譯型的么，已經(jīng)有編譯型的實現(xiàn)模式何必畫蛇添足，增加這么一種實現(xiàn)模式，其實本質(zhì)不然，golang雖然是編譯型語言，底層框架的實現(xiàn)由于盡量考慮通用性，數(shù)據(jù)傳遞的過程中勢必需要進行序列化和反序列操作，而在原生的C++的實現(xiàn)過程中我們在實現(xiàn)的過程完全摒棄所有的序列化和反序列操作，數(shù)據(jù)在本地隊列中的傳遞完全是業(yè)務的數(shù)據(jù)指針（而非序列化數(shù)據(jù)），而每個業(yè)務算子在處理數(shù)據(jù)過程中，直接根據(jù)原始的數(shù)據(jù)指針通過反射機制（實現(xiàn)方式有很多最簡單的 map）可以直接獲取對應列的數(shù)據(jù)項，整個過程無鎖的超高效率。這里的核心優(yōu)化思路數(shù)據(jù)鏈式處理過程。拉鏈上的每個算子，都共享同一個輸入和輸出。每個算子，其實就是一個接口相同的函數(shù)，這樣就可以隨意地調(diào)整函數(shù)指針的組合，形成不同的處理鏈。比如：一個請求走 A 模型排序，一個請求要走 B 模型排序，他們可以共享前序的算子，只在最后一個算子有所不同。在鏈式處理基礎(chǔ)上，算子也可以是繼承同一基類接口的派生類，或者 lambda 表達式。結(jié)合工廠模式等一些編程技巧，處理鏈的調(diào)整可以配置化、動態(tài)化、腳本化。實測執(zhí)行業(yè)務單算子普通的純數(shù)據(jù)項帶分支的多節(jié)點的拓撲計算單機(單線程/算子)可以達到數(shù)十萬的處理能力。

通過新計算引擎的實現(xiàn)從使用上完全兼容上一代計算系統(tǒng)的使用方式，將不常使用的功能做精簡，同時優(yōu)化復雜拓撲執(zhí)行方式，通過架構(gòu)層也業(yè)務層解耦，支持多語言高效執(zhí)行方式，對于老業(yè)務平遷的數(shù)據(jù)框架平均計算效率提高5~10倍，同時業(yè)務由于針對性建設(shè)業(yè)務框架業(yè)務開發(fā)效率進一步提升。

智能控制實現(xiàn)

自動化問題分析引擎是整個智能控制系統(tǒng)的大腦。它上游接收觀測提供的原始數(shù)據(jù)，進行自動的分析決策后，通過系統(tǒng)提供的自愈能力處理。自動化問題分析引擎的核心思路: 只要歷史上出現(xiàn)過的問題，RD同學能找到問題和解決方案，就可以轉(zhuǎn)化為系統(tǒng)規(guī)則和后置函數(shù)梳理。那當下一次遇到問題則無需人工干預。規(guī)則引擎的核心分析過程是2段式的:

階段1: 傳統(tǒng)配置化的規(guī)則引擎的配置（上圖中右上角黃色部分），配置多個采集指標項的邏輯關(guān)系（與或交非）， 這里主要是針對問題的基礎(chǔ)分析功能,判定規(guī)則是否觸發(fā)。

階段2: 基于這個基礎(chǔ)分析的結(jié)果，進行后置Function的執(zhí)行分析，這個主要是針對復雜問題的分析補充， 最終執(zhí)行引擎根據(jù)這個返回結(jié)果進行函數(shù)執(zhí)行。

下面針對問題分析引擎的執(zhí)行結(jié)果如下:

前提: 開發(fā)者需要配置好處理邏輯規(guī)則（以及規(guī)則依賴的數(shù)據(jù)項，必填） & 回調(diào)函數(shù)（選填）。

數(shù)據(jù)解析器: 數(shù)據(jù)解析器主要承擔的數(shù)據(jù)的原始抽取的工作，一共分成如下3步：

a.配置解析: 邏輯執(zhí)行根據(jù)開發(fā)者配置的數(shù)據(jù)信息解析；

b.數(shù)據(jù)抽取: 根據(jù)解析出來的配置通過數(shù)據(jù)接口進行獲取，可以從統(tǒng)一接口根據(jù)配置的信息從不同的介質(zhì)充抽取所需求的信息；

c.數(shù)據(jù)歸一化: 將不同介質(zhì)的原始數(shù)據(jù)歸一化成為統(tǒng)一的數(shù)據(jù)格式供規(guī)則管理器使用。

規(guī)則管理器: 規(guī)則管理器主要承擔核心的邏輯分析工作，一共分成如下幾步:

a.規(guī)則解析: 根據(jù)開發(fā)者配置的規(guī)則邏輯，將原始配置信息，解釋成原始的規(guī)則樹。

b.執(zhí)行計算: 根據(jù)數(shù)據(jù)解析器提供的數(shù)據(jù)結(jié)果和配置的函數(shù)規(guī)則分別執(zhí)行計算。執(zhí)行計算過程中最重要的就是基礎(chǔ)分析器，整體提供了5大基礎(chǔ)能力，數(shù)十種常見的邏輯計算來輔助規(guī)則配置。

c.規(guī)則邏輯運算: 根據(jù)上層解析出來的規(guī)則樹 和 每個數(shù)據(jù)項執(zhí)行完成的計算結(jié)果進行邏輯運算，并根據(jù)執(zhí)行的結(jié)果確定是否進行高級數(shù)據(jù)分析器，如果判斷結(jié)果為真則根據(jù)所配置的后置函數(shù)進行處理。

高級數(shù)據(jù)分析器: 如圖所示有兩種模式，對于簡單基礎(chǔ)分析可以判斷結(jié)果的，直接給默認的處理函數(shù)進行數(shù)據(jù)拓傳；對于簡單邏輯規(guī)則無法準確表達的，開發(fā)者可以自定義后置分析函數(shù)， 函數(shù)會將原始數(shù)據(jù)和基礎(chǔ)計算的計算結(jié)果作為參數(shù)傳出來，開發(fā)者只需要通過處理后的數(shù)據(jù)描述清楚分析邏輯即可。

動作執(zhí)行器: 就是這個分析器的真正的執(zhí)行引擎，根據(jù)規(guī)則運算的結(jié)果中包含的參數(shù)進行動態(tài)調(diào)整。

通過智能控制系統(tǒng)的建設(shè)，月級別分析處理上萬的異常問題，自動恢復的比例占總數(shù)的95%以上，絕大多數(shù)的問題幾分鐘內(nèi)完成自動恢復， 核心故障同比減少60% （由于預處理防止普通問題惡化成嚴重問題）。

04結(jié)論以及展望

本文全篇以離線計算系統(tǒng)的發(fā)展為主線，貫穿全文講解遇到的問題以及解決方案。尤其是當前新一代架構(gòu)核心就是以數(shù)據(jù)+功能為核心的聲明式的設(shè)計，配合高效計算引擎、配合智能化的設(shè)計，把整體的離線計算系統(tǒng)的高度做了進一步提升。設(shè)計中其實還是雖然解決了過去的很多問題，但是仍然有不完善的地方，當然當前的效果還遠沒有達到最終的理想狀態(tài)，部分系統(tǒng)功能有待持續(xù)性的打磨升級。

審核編輯：湯梓紅