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

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

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

業(yè)務(wù)需求及背景

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

當(dāng)前的業(yè)務(wù)邏輯還是比較清晰的:

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

我們面臨的痛點(diǎn)和難點(diǎn):

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

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

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

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

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

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

方案1小結(jié)

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

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

方案2: Hive 為什么不行?

看到這, 熟悉大數(shù)據(jù)的同學(xué)可能會(huì)覺(jué)得我們水平很 Low, 因?yàn)闃I(yè)務(wù)需求歸根到底就是三個(gè)字: "批處理". (提煉一下我們的需求, 其實(shí)正是大數(shù)據(jù)的典型應(yīng)用場(chǎng)景. 大數(shù)據(jù)處理流程, 見(jiàn)下圖) 那么我們?yōu)槭裁吹谝粫r(shí)間沒(méi)有考慮上大數(shù)據(jù)呢?

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

所以基于團(tuán)隊(duì)目前的技術(shù)儲(chǔ)備, 大數(shù)據(jù)才沒(méi)有成為我們的首選. 但是目前的狀況, 看來(lái)上大數(shù)據(jù)是最優(yōu)解了. 那么我們?cè)撨x用大數(shù)據(jù)的什么組件實(shí)現(xiàn)我們的需求呢?

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

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

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

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

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

方案 2 小結(jié)

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

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

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

通用的計(jì)算引擎

雖然使用 HDFS 的團(tuán)隊(duì)不贊成我們?cè)谒麄兊臋C(jī)器上跑 Hive, 但是我們把日志數(shù)據(jù)存到他們的 HDFS 上還是沒(méi)問(wèn)題的. 在已知 "存儲(chǔ)和分離是趨勢(shì)" 是前提的基礎(chǔ)下, "我們到底需要什么" 這個(gè)問(wèn)題已經(jīng)有答案了.

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

Spark 與 Flink 初次交鋒

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

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

揮淚斬 Spark

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

對(duì)于我司的云平臺(tái)要補(bǔ)充一些細(xì)節(jié).

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

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

Spark 的管理平臺(tái)非常重要, 因?yàn)槟軓倪@上面看到當(dāng)前各個(gè)節(jié)點(diǎn)運(yùn)行情況, 任務(wù)的異常信息等, 現(xiàn)在很多鏈接不能訪問(wèn), 不利于我們對(duì) Spark 任務(wù)進(jìn)行問(wèn)題排查和調(diào)優(yōu). 基于這個(gè)原因, 我們最終放棄了 Spark.

方案 3 小結(jié)

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

Spark 你真的是個(gè)好人, 如果不是云平臺(tái)的限制, 我一定選擇你.

Spark, 對(duì)不起.

方案4: Flink, 真香!

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

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

放棄 Spark 時(shí)我們的痛點(diǎn)在于 "部署在云平臺(tái)上的 Spark 服務(wù)的管理界面很多功能無(wú)法使用", 而 Flink 的管理平臺(tái)完全沒(méi)有這個(gè)問(wèn)題! 除此之外, Flink 管理平臺(tái)的 "顏值" 和功能都是 Spark 無(wú)法比擬的.

管理平臺(tái)顏值對(duì)比

Spark管理平臺(tái)頁(yè)面(網(wǎng)絡(luò)圖片):

Flink管理平臺(tái)頁(yè)面:

對(duì)比之下, Spark 的頁(yè)面完全是個(gè)"黃臉婆".

Flink 管理平臺(tái)功能

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

完善的 Restful API

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

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

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

強(qiáng)大的任務(wù)分析能力

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

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