覆蓋電商、推薦、ETL、風控等多場景，網易的實時計算平臺作了啥？

目前網易流計算規模已經達到了一千多個任務，2 萬多個 vcores 以及 80 多 T 的內存，網易流計算覆蓋了絕大多數場景，包括廣告、電商大屏、ETL、數據分析、推薦、風控、搜索、直播等。

摘要：本文由網易 Java 技術專家吳良波分享，主要內容爲 Apache Flink 在網易的實踐，文章提綱以下：

1. 業務與規模演進
2. Flink 平臺化
3. 案例分析
4. 將來發展與思考

1、業務與規模演進

網易流計算演進

在好久之前，網易內部基本上都是使用 Storm 來處理實時的計算任務，比較主要的使用場景是實時郵件反垃圾，廣告，新聞推薦等業務。現在內部仍有一部分任務是運行在 Storm 上，目前正往 Flink 上遷移。

• 16 年左右 Flink 社區在網絡上逐漸開始火起來，網易這邊開始調研 Flink，發現 Flink 具備不少優秀的特性，好比高吞吐、低延遲、支持 Checkpoint、支持 Exactly once 語義，支持 Event time 等，可以很好的知足業務實時計算的場景，所以不少項目開始使用 Flink 來做爲流計算的引擎來搭建流計算平臺。
• 在 2017 年 2 月份，網易杭州研究院成立了一個代號爲 Sloth 的項目，基於 SQL 的實時計算平臺，底層計算引擎採用 Apache Flink。

可是這套系統作的並非很成功，一方面是由於平臺化，產品化作的不是很到位，用戶使用起來不是很方便，SLA 也沒有獲得很好的保障。另外一方面對 Flink 底層的代碼改動較大，致使後面跟不上社區的節奏。因而在今年年初對系統進行從新改造，從新擁抱社區，在 SQL 方面採用了阿里巴巴年初新開源的 Blink，使用 Blink 來提交 SQL 任務，同時支持用戶直接寫 JAVA 代碼來提交流計算任務，方便那些有開發能力的同窗開發 Flink 任務。

網易杭研在作流計算平臺的同時，公司一些大的業務方也在開發本身的流計算平臺，這樣一來就形成了公司很大的資源和人力上的浪費。爲了整合公司資源，以及應對各個業務不斷增加的實時計算任務的需求，決定和各個業務方一塊兒共建分佈式的實時計算平臺，將業務方的任務所有遷移到新的分佈式實時計算平臺上，杭研負責底層平臺和接口的研發與維護，業務方則更加關注業務自己。

基於流計算的業務規模

目前網易流計算規模已經達到了一千多個任務，2 萬多個 vcores 以及 80 多 T 的內存。

業務場景

目前網易流計算覆蓋了絕大多數場景，包括廣告、電商大屏、ETL、數據分析、推薦、風控、搜索、直播等。

2、Flink 平臺化

平臺架構演進-Sloth 0.x

在 2017 年初的時候,由於當時社區版本的 Flink 對於 SQL 的支持不是很完善，因此 Sloth 平臺自定義了 SQL 規範，本身實現了 DDL 等。但當時這個平臺的架構存在不少問題，特別是版本升級的時候，代碼遷移等的工做量很是大，運維起來也很是困難。另外當時實時計算只是做爲離線計算平臺的一個功能模塊，所以 Sloth 的前端是和離線平臺綁定在一塊兒的，實時計算模塊前端每次升級發佈都須要和離線計算平臺一塊兒，很是不方便。

平臺架構演進-Sloth 1.0

在 Sloth 的 1.0 版本中，Flink 版本實現了插件化管理，每次 Flink 升級的時候就不須要進行復雜的代碼合併工做了，這一點主要經過父子進程架構來實現的。此外，Sloth 1.0 版本的運維方便了許多，而且也支持 jar 包任務開發，用戶能夠直接經過 Stream API 來寫流計算任務。Sloth 的 1.0 版本還支持了阿里巴巴開源的 Blink SQL，而且在監控方面還接入了 Grafana，任務 metrics 存儲則使用了網易自研的時序數據庫 Ntsdb。

平臺架構演進-Sloth 2.0

在 Sloth 的 2.0 版本中，實現了平臺的 PaaS 化以及平臺的高可用。Sloth 平臺提供對外的平臺 API，Sloth 開發了一套獨立部署的前端界面，同時業務方也能夠開發跟本身業務更爲緊密的前端界面，經過平臺的 API 來提交任務以及後續的任務運維等等。

之前的計算平臺都是單點的，都是部署在同一臺服務器，一旦服務器出了故障，整個平臺就掛了，因此 Sloth 2.0 設計成分佈式的，能夠部署多個 Server，使用 Nginx 做爲負載均衡器，來達到系統的高可用。同時支持了更多的 Flink 版本，由於各個業務之前用的版本均可能不同，爲了將任務直接遷移過來，須要支持這些歷史的版本，因此平臺支持了 Flink 1.五、Flink 1.七、Flink 1.9 和 Blink 等多個版本。

平臺模塊圖

下圖所示是 Sloth 的模塊圖。在 Web 端，業務方能夠搭建本身的任務管控平臺 Web，業務方所須要的前端平臺可能和公用 Sloth 的前端平臺不一樣，業務方內部還包括各類不一樣的部門，他們須要對於各個部門的用戶權限進行控制等。Sloth-Server 模塊，包括用戶的權限管理，會話管理，任務開發，元數據管理，任務運維，標籤管理，內核調度，文件管理。Sloth-Bill 模塊主要是對資源以及用量的統計，Sloth-admin 模塊包括監控，報警，任務恢復，以及任務診斷。Sloth-Kernel 模塊負責任務執行、語法檢測以及 SQL 調試。

事件管理

對於分佈式平臺的任務操做而言，當前任務只容許一我的操做，而不容許兩我的同時操做，這就須要如下幾個模塊來共同配合：

• Server：事件執行的發起者，接受事件的請求，進行數據校驗，拼裝，將事件發送給 Kernel 執行。
• Kernel：事件具體邏輯的執行者，根據請求向集羣發送指令(Shell 腳本方式)。
• Admin：事件執行結果的確認者，根據事件類型，獲取事件的最終結果，保證結果的正確性。

以啓動場景爲例：

• 首先，Server 會接收到來自用戶的啓動請求，以後會建立一個分佈式鎖，Admin 會監控這個鎖。
• 而後， Server 向 Kernel 提交任務，提交以後會當即返回，返回以後就會當即更新數據庫中的狀態，將狀態更新爲啓動中，這樣在頁面上用戶就可以看到任務是啓動中的狀態了。
• 接下來，Server 就會等待內核的 Shell 腳本的執行結果，若是 Shell 腳本執行成功了，就會去寫 Zookeeper，寫完 Zookeeper 以後 Admin 模塊就會立刻檢測到 Zookeeper 節點有狀態發生了修改，Admin 會當即去獲取 YARN 上的任務狀態，若是獲取到任務狀態是運行中，就將數據庫的任務狀態更新爲運行中，這會在前端看到任務就已是運行狀態了。
• 最後一步是 Admin 更爲完數據庫以後，會釋放掉 Zookeeper 上的鎖，其餘人這時候就能夠操做這個任務了。

Server、Kernel 和 Admin 這三個模塊都是不可靠的，那麼如何保證其穩定和高可用呢？Server 能夠經過部署多個，水平擴展來實現，Kernel 則會由 Server 來進行監聽，當發現 Kernel 掛了，能夠由 Server 從新拉起或者從新建立。而 Admin 的高可用則是經過熱備來實現的，若是主 Admin 掛掉了，能夠立刻遷移到備 Admin，備 Admin 能夠迅速將元數據以及任務信息所有加載進來接替工做，進而實現高可用。

內核調度

對於內核調度而言，是基於父子進程的架構實現的。Server 會經過 Sloth RPC 啓動不一樣的 kernel 子進程，分爲常駐子進程模式和臨時子進程模式。常駐子進程負責處理啓動，中止，語法檢查，表結構解析，獲取提交結果的請求，臨時子進程是用於 SQL 的 Debug 的，當調試完成須要將這個子進程關閉掉，將資源進行回收。內核經過子進程來實現的好處在於當 Kernel 掛掉的時候，Server 能夠經過監聽自動拉起來。

平臺任務狀態圖

平臺的任務狀態主要由 Server 和 Admin 來控制。Server 主要控制初始狀態的執行，Admin 則主要負責控制全部與 YARN 相關的狀態交互。

任務開發

任務開發的界面支持的功能主要有：任務調試、任務 Tab 頁、語法檢查、任務標籤、元數據管理、用戶資源文件管理以及任務複製等。

Blink SQL

擴展完善了 Blink 對維表 Join 的支持，以及如 HDFS、Kafka、HBase，ES，Ntsdb，Kudu 等 Sink 端的支持。

任務調試

SQL 類型的任務支持調試功能，用戶能夠根據不一樣的 source 表和 dim 表，上傳不一樣的 csv 文件做爲輸入數據，進行調試。調試執行由指定的 kernel 來完成，sloth-server 負責組裝請求，調用 kernel，返回結果，蒐集日誌。

日誌檢索

在 YARN 集羣的每一個節點上面部署 Filebeat，經過 Filebeat 將節點上面的任務日誌寫入到 Kafka 消息隊列中，而後經過 Logstash 進行解析處理，以後寫入 ES 集羣中。主要用於兩個用途，一個是經過界面 Kibana 來提供給開發和運維人員使用，另一個就是將運行時狀態的任務日誌直接在界面上展現供用戶進行搜索和查看。

監控

在監控方面，使用的是 influxdb metric report 組件對於指標進行監控。時序數據庫使用的是網易自研的 ntsdb 時序數據庫，其可以支持動態擴展和高可用等功能。監控指標的使用方式有兩種：

• 一種是經過 Grafana 的界面來查看指標；
• 另一種是報警模塊會從Ntsdb中獲取相關指標數據並進行監控報警。

報警

Sloth 流計算平臺支持常見的任務失敗，數據滯留延遲，failover 報警，也支持用戶自定義規則報警，包括對於輸入 QPS、輸出 QPS，戶自定義延遲的監控等。以輸入 QPS 爲例，能夠設置當連續幾個週期內 QPS 低於某一值時就觸發報警。此外，報警方式也支持多樣化的工具，好比各類網易內部的聊天工具、郵件、電話以及短信等，對於任務調試階段，爲了不被騷擾，能夠設置任務報警抑制時間間隔。

3、案例分析

數據實時同步

AI 智能對話服務場景中，客戶在前端配置知識庫數據，經過 Sloth 實時處理後，寫入到 ES 中供查詢場景使用。

實時數倉

目前網易不少產品已經開始實時數倉的建設了，但仍舊處於持續完善過程當中。實時數倉的建設和離線數倉大體相同，只不過實時數倉是通過實時計算平臺進行處理的。大體的過程就是首先收集日誌、埋點數據等，將其寫入到 Kafka 裏面，通過實時計算平臺進行處理，將 ODS 層中的明細數據抽取出來，在進行彙總以及維度關聯等操做，將結果寫入到 Redis，Kudu 等，再經過數據服務提供給前端的業務使用。

電商應用-數據分析

電商的數據分析場景主要包括實時活動分析、首頁資源分析、流量漏斗以及實時毛利計算等。簡要的邏輯就是從 Hubble 收集用戶的訪問日誌推進到 Kafka，使用 Sloth 清洗出明細層，寫入 Kafka，再用 Sloth 任務，關聯維度，實時寫入 Kudu，落入 Kudu 表的數據，一方面能夠提供給業務方使用，分析師能夠開發實時查詢；另一方面，能夠在這個實例的 Kudu 表上面，提供給數據應用。

電商應用-搜索推薦

電商的搜索推薦場景則主要包括用戶實時足跡、用戶實時特徵、商品實時特徵、實時 CTR CVR 樣本組建、首頁 A 區輪播、B 區活動精選等 UV、PV 實時統計等。簡要的邏輯就是使用 Sloth 讀取應用日誌，進行數據清洗和維度拆分，寫入 Kafka，再使用 Sloth 讀取 Kafka 的數據，實時統計多維特徵，實時統計多維特徵 5min、30min、1 小時的 PV 和 UV，寫入 Redis，供線上工程計算 CTR、CVR 以及優化搜索和推薦結果。

4、將來發展與思考

網易在流計算方面對於將來發展的思考主要包括如下五點：

1. 實時計算平臺支持 Flink On K8S 的任務
2. 任務的自動配置功能，平臺能根據業務類型，流量自動配置內存，併發度等，既保證業務 SLA，也能提高計算集羣的資源利用率。
3. 智能診斷，對 UDF 以及代碼構建的流計算任務，調試成本高，運行出錯讓業務和平臺方疲於奔命，智能診斷是流計算平臺根據任務的各類 Metric 信息，直指問題所在，減小業務和平臺定位問題的時間，對於存在風險的任務，能夠提早給出預警，並對調優給出建議。
4. 關注 Flink 1.9 後續對於 SQL 的支持，以及 Flink 批流統一。
5. 更多地參與到社區中去。

做者介紹：

吳良波，網易 JAVA 技術專家，2011 年加入網易後從事 JAVA 後臺系統的研發，如網易郵件反垃圾系統，網易分佈式雲爬蟲系統等，目前負責網易實時計算平臺的研發。