都說現在的主流技術是Flink，那麼讓我們看看FLink在網易是如何實戰的？

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

 

1. 業務與規模演進

2. Flink 平臺化

3. 案例分析

4. 未來發展與思考

 

一、業務與規模演進

 

網易流計算演進

 

在很久以前，網易內部基本上都是使用 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、數據分析、推薦、風控、搜索、直播等。

 

轉存失敗重新上傳取消

 

二、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.5、Flink 1.7、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 低於某一值時就觸發報警。此外，報警方式也支持多樣化的工具，比如各種網易內部的聊天工具、郵件、電話以及短信等，對於任務調試階段，爲了避免被騷擾，可以設置任務報警抑制時間間隔。

 

 

三、案例分析

 

數據實時同步

 

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 以及優化搜索和推薦結果。

 

 

四、未來發展與思考

 

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

 

1. 實時計算平臺支持 Flink On K8S 的任務

2. 任務的自動配置功能，平臺能根據業務類型，流量自動配置內存，併發度等，既保證業務 SLA，也能提升計算集羣的資源利用率。

3. 智能診斷，對 UDF 以及代碼構建的流計算任務，調試成本高，運行出錯讓業務和平臺方疲於奔命，智能診斷是流計算平臺根據任務的各種 Metric 信息，直指問題所在，減少業務和平臺定位問題的時間，對於存在風險的任務，可以提前給出預警，並對調優給出建議。

4. 關注 Flink 1.9 後續對於 SQL 的支持，以及 Flink 批流統一。

5. 更多地參與到社區中去。

 

作者介紹：

 

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