技術(shù)選型: 為什么批處理我們卻選擇了 Flink?

最近接手了一個融合日志的服務. 經(jīng)過梳理, 我認為當前服務的設計上存在缺陷. 與 Leader 開會討論后, 決定重新進行技術(shù)方案調(diào)研, 最終我們選擇使用 Flink 重構(gòu)了該服務.

目前重構(gòu)后的服務已成功經(jīng)受了國慶節(jié)流量洪峰的考驗, 今日特來總結(jié)回顧, 和大家分享一下經(jīng)驗.

業(yè)務需求及背景

首先我們要明確, 我們要解決什么問題以及目前的服務是如何解決的.

當前的業(yè)務邏輯還是比較清晰的:

• 采集同一時段不同數(shù)據(jù)源的日志.
• 對采集的數(shù)據(jù)進行處理.
• 將處理后的數(shù)據(jù)上傳到指定位置, 供客戶下載.

我們面臨的痛點和難點:

• 日志的量比較大, 每小時未壓縮日志在 50 多個 G 左右; 如果是節(jié)假日等特殊時間節(jié)點, 日志量一般都會翻倍.
• 目前服務使用單機進行處理, 速度比較慢, 擴容不方便.
• 目前服務處理數(shù)據(jù)時需要清洗字段, 按時間排序, 統(tǒng)計某字段的頻率等步驟. 這些步驟都屬于 ETL 中的常規(guī)操作, 但是目前是以代碼的形式實現(xiàn)的, 我們想以配置形式減少重復編碼, 盡量更加簡單, 通用.

方案1: 我們需要一個數(shù)據(jù)庫嗎?

針對以上業(yè)務需求, 有同學提出: "我們可以把所有原始數(shù)據(jù)放到數(shù)據(jù)庫中, 后續(xù)的 ETL 可以通過 SQL 實現(xiàn)".

如果你一聽到"數(shù)據(jù)庫"想到的就是 Pg, Mysql, Oracle 等覺得這個方案不具有可行性, 那你就錯了. 如下圖所示, 數(shù)據(jù)庫的類型和維度是非常豐富的.

按業(yè)務負載特征，關(guān)系型數(shù)據(jù)庫可分為 OLTP 數(shù)據(jù)庫(交易型)和 OLAP數(shù)據(jù)庫(分析型) :

• OLTP, Online Transaction Processing. OLTP 數(shù)據(jù)庫最大的特點是支持事務, 增刪查改等功能強大, 適合需要被頻繁修改的"熱數(shù)據(jù)". 我們耳熟能詳?shù)?Mysql, Pg 等都屬于這一類. 缺點就是由于支持事務, 插入時比較慢. 拿來實現(xiàn)我們的需求顯示是不合適的.
• OLAP, Online Analytical Processing, 數(shù)據(jù)分析為主. 不支持事務, 或?qū)κ聞盏闹С钟邢? OLAP 的場景是: 大多數(shù)是讀請求, 數(shù)據(jù)總是以相當大的批(> 1000 rows)進行寫入, 不修改已添加的數(shù)據(jù).

方案1小結(jié)

OLAP 的使用場景符合我們的需求, 為此我們還專門去調(diào)研了一下 ClickHouse. 但是有一個因素讓我們最終放棄了使用 OLAP. 請注意, 數(shù)據(jù)庫存儲的數(shù)據(jù)都是二維的, 有行和列兩個維度. 但是日志只有行一個維度. 如果說為了把日志存入數(shù)據(jù)庫把每行日志都切分, 那我們統(tǒng)計字段的需求也就順手實現(xiàn)了, 又何必存到數(shù)據(jù)呢?

所以, OLAP 使用場景隱含的一個特點是: 存入的數(shù)據(jù)需要被多維度反復分析的. 這樣才有把數(shù)據(jù)存入數(shù)據(jù)庫的動力, 像我們當前的需求對日志進行簡單的變形后仍舊以文本日志的形式輸出, 使用 OLAP 是不合適的.

方案2: Hive 為什么不行?

看到這, 熟悉大數(shù)據(jù)的同學可能會覺得我們水平很 Low, 因為業(yè)務需求歸根到底就是三個字: "批處理". (提煉一下我們的需求, 其實正是大數(shù)據(jù)的典型應用場景. 大數(shù)據(jù)處理流程, 見下圖) 那么我們?yōu)槭裁吹谝粫r間沒有考慮上大數(shù)據(jù)呢?

大數(shù)據(jù)確實如雷貫耳, 但是我們團隊日志處理這塊大部分都是用 Golang 實現(xiàn)的, 團隊內(nèi)的其他業(yè)務用了 Python, Lua, C. 偏偏就是沒有用過到 Java. 而目前大數(shù)據(jù)都是基于 JVM 開發(fā)的. Golang 調(diào)用這些服務沒有一個好用的客戶端.

所以基于團隊目前的技術(shù)儲備, 大數(shù)據(jù)才沒有成為我們的首選. 但是目前的狀況, 看來上大數(shù)據(jù)是最優(yōu)解了. 那么我們該選用大數(shù)據(jù)的什么組件實現(xiàn)我們的需求呢?

放棄使用數(shù)據(jù)庫直接使用 HDFS 存儲日志文件, 應該是毋庸置疑的.

我們需求是離線批處理數(shù)據(jù), 對時效性沒有要求, MapReduce 和 Hive 都能滿足需求. 但是 MapReduce 與 Hive 相比, Hive 在 MapReduce 上做了一層封裝并且支持 SQL. 看起來 Hive 是非常合適的.

那我們?yōu)槭裁醋罱K放棄了 Hive 呢?

機器資源審批不下來. 公司其他團隊已經(jīng)有一套 HDFS 的設施, 只用來做存儲, Hadoop 的 MapReduce 這個組件根本沒跑起來. 那套 HDFS 部署的機器資源比較緊張, 他們擔心我們使用 MapReduce 和 Hive 進行計算, 會影響他們現(xiàn)在 HDFS 的性能; 我們想審批一批新的機器, 重新使用 Ambari 搭建一套 Hadoop, 卻被告知沒那么多閑置的機器資源. 而且我們即便申請下來了機器, 只跑目前服務也跑不滿, 機器資源大部分也會被閑置, 也有浪費資源的嫌疑.

存儲分離是趨勢. 在調(diào)研中我們發(fā)現(xiàn), 像 Hadoop 這樣把存儲和計算放到一起的已經(jīng)比較"落伍"了. Hadoop 存儲分離, 需要修改源碼, 目前沒有開源實現(xiàn), 只是云廠商和各個大數(shù)據(jù)公司有相關(guān)商業(yè)產(chǎn)品. 從這個角度講, 即便我們自己搞定了機器資源搭一套 Hadoop, 也只不過是拾人牙慧罷了.

方案 2 小結(jié)

再合適的技術(shù)方案不能落地也是空談. 但是技術(shù)方案想要落地時, 已經(jīng)不是一個單純的技術(shù)問題了, 資源限制, 團隊限制等都需要考慮在內(nèi).

一個優(yōu)秀的技術(shù)方案立足于解決當下的問題, 并且能放眼未來勾畫藍圖("大餅"), 這樣大家覺得 "有利可圖", 才愿意跟你一起折騰.

方案3: 為什么我們放棄了 Spark?

通用的計算引擎

雖然使用 HDFS 的團隊不贊成我們在他們的機器上跑 Hive, 但是我們把日志數(shù)據(jù)存到他們的 HDFS 上還是沒問題的. 在已知 "存儲和分離是趨勢" 是前提的基礎下, "我們到底需要什么" 這個問題已經(jīng)有答案了.

我們需要的是一個通用的計算引擎. 存儲已經(jīng)剝離給 HDFS 了, 所以我們只需要找一個工具, 幫我們處理 ETL 就可以了. Spark 和 Flink 正是這樣的場景.

Spark 與 Flink 初次交鋒

Spark 和 Flink 之間, 我們毫不猶豫地選擇了 Spark. 原因非常簡單:

• Spark 適合批處理. Spark 當初的設計目標就是用來替換 MapReduce. 而 Spark 流處理的能力是后來加上去的. 所以用 Spark 進行批處理, 可謂得心應手.
• Spark 成熟度高. Spark 目前已經(jīng)發(fā)布到 3.0, 而 Flink 尚在 Flink 1.x 階段. Flink 向來以流處理聞名, 雖然被國內(nèi)某云收購后開始鼓吹 "流批一體", 但是線上效果還是有待檢驗的.
• Scala 的加持. Spark 大部分是用 Scala 實現(xiàn)的. Scala 是一門多范式的編程語言, 并且與 Haskell 有很深的淵源. Haskell 是一門大名鼎鼎的函數(shù)式編程語言. 對于函數(shù)式編程語言, 想必大多數(shù)程序員都有一種 "雖不能至，然心向往之" 的情結(jié). 現(xiàn)在使用 Spark 能捎帶著耍一耍函數(shù)式編程語言 Scala, 豈不妙哉?

揮淚斬 Spark

前文已經(jīng)交代過了, 我們否決掉 Hive 的一個重要因素是我們沒有足夠的機器資源. 所以我們把 Spark 直接部署到云平臺上.

對于我司的云平臺要補充一些細節(jié).

它是基于 K8S 二次開發(fā)的, 通常我們使用時都是上傳 Docker 鏡像然后啟動 Docker 實例. 它暫不支持像阿里云 "容器服務 ACK" 這樣的功能. 所以 "Spark on K8S" 的運行模式我們用不了. 在這樣的條件下, 我們采用了 "Spark Standalone" 的模式. Standalone 模式, 也就是Master Slaver 模式, 類似于 Nginx 那樣的架構(gòu), Master 節(jié)點負責接收分發(fā)任務, Slaver 節(jié)點負責"干活".

等到我們在云平臺上以 "Spark Standalone" 模式部署好了, 跑了幾個測試 Case 發(fā)現(xiàn)問題又來了. 我們的云平臺與辦公網(wǎng)絡是隔離的, 如果辦公網(wǎng)絡想訪問云平臺的某個 Docker 容器, 需要配置域名. 而 Spark 的管理頁面上很多 URL 的 domain 是所在機器的 IP, 而容器的 IP 虛擬 IP, 容器重啟后虛擬 IP 就改變了. 具體如圖:

Spark 的管理平臺非常重要, 因為能從這上面看到當前各個節(jié)點運行情況, 任務的異常信息等, 現(xiàn)在很多鏈接不能訪問, 不利于我們對 Spark 任務進行問題排查和調(diào)優(yōu). 基于這個原因, 我們最終放棄了 Spark.

方案 3 小結(jié)

Spark 你真的很優(yōu)秀, 你擅長批處理, 你如此成熟, 你還有函數(shù)式的基因 ... 這些優(yōu)點早讓我傾心不已.

Spark 你真的是個好人, 如果不是云平臺的限制, 我一定選擇你.

Spark, 對不起.

方案4: Flink, 真香!

給 Spark 發(fā)完好人卡后, 我們看一看新歡 Flink. 不客氣的說, Flink 初期時很多實現(xiàn)都是抄的 Spark, 所以二者的很多概念相似. 所以 Flink 同樣有 Standard 模式, 我們部署階段沒遇到任何問題.

在跑了幾個 Flink 測試 Case 后, 我們由衷的感嘆 Flink 真香!

放棄 Spark 時我們的痛點在于 "部署在云平臺上的 Spark 服務的管理界面很多功能無法使用", 而 Flink 的管理平臺完全沒有這個問題! 除此之外, Flink 管理平臺的 "顏值" 和功能都是 Spark 無法比擬的.

管理平臺顏值對比

Spark管理平臺頁面(網(wǎng)絡圖片):

Flink管理平臺頁面:

對比之下, Spark 的頁面完全是個"黃臉婆".

Flink 管理平臺功能

由于 Spark 的功能很多不能使用, 所以就不重點和 Flink 做比較了. 這里只說 Flink 幾個讓人眼前一亮的功能.

完善的 Restful API

部署了 Flink 或 Spark 服務后, 該如何下發(fā)計算任務呢? 一般是通過 bin 目錄下的一個名稱中包含 submit 的可執(zhí)行程序. 那如果我們想把 Flink 或 Spark 做成微服務, 通過 http 接口去下發(fā)任務呢?

Spark1.0 的時候支持 http, 2.0 的時候這個功能基本上廢掉了很多參數(shù)不支持了, 把 http 這個功能交由 jobService 一個第三方開源組件去實現(xiàn). 這個 jobService 的開源組件對云平臺的支持也非常不友好. 所以在我們看來, Spark 通過 Http 下發(fā)任務的路子基本被堵死了.

反觀 Flink, 管理平臺的接口是 Restful 的, 不僅支持 Http 下發(fā)計算任務, 還可以通過相關(guān)接口查看任務狀態(tài)和獲取異?；蚍祷刂?

強大的任務分析能力

Flink 的任務分為幾個不同的階段, 每個不同的階段有不同的顏色. 這樣僅從顏色就可以判斷出當前 Flink 任務執(zhí)行的大致情況. 如下圖:

在任務詳情頁面, 會有任務分解圖和任務執(zhí)行耗時表格, 這兩個結(jié)合起來能夠知道當然 Flink 任務是如何分解的, 是否出現(xiàn)數(shù)據(jù)傾斜的情況, 哪個步驟耗時最多, 是否有優(yōu)化的空間 ...