摘要：本文由網易 Java 技術專家吳良波分享，主要内容為 Apache Flink 在網易的實踐，文章提綱如下：
- 業務與規模演進
- Flink 平台化
- 案例分析
- 未來發展與思考
一、業務與規模演進
網易流計算演進
在很久以前，網易内部基本上都是使用 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 以及優化搜尋和推薦結果。
四、未來發展與思考
網易在流計算方面對于未來發展的思考主要包括以下五點：
- 實時計算平台支援 Flink On K8S 的任務
- 任務的自動配置功能，平台能根據業務類型，流量自動配置記憶體，并發度等，既保證業務 SLA，也能提升計算叢集的資源使用率。
- 智能診斷，對 UDF 以及代碼建構的流計算任務，調試成本高，運作出錯讓業務和平台方疲于奔命，智能診斷是流計算平台根據任務的各種 Metric 資訊，直指問題所在，減少業務和平台定位問題的時間，對于存在風險的任務，可以提前給出預警，并對調優給出建議。
- 關注 Flink 1.9 後續對于 SQL 的支援，以及 Flink 批流統一。
- 更多地參與到社群中去。
作者介紹：
吳良波，網易 JAVA 技術專家，2011 年加入網易後從事 JAVA 背景系統的研發，如網易郵件反垃圾系統，網易分布式雲爬蟲系統等，目前負責網易實時計算平台的研發。