不知道你是否有過和我類似的經(jīng)歷？

我是 2018 年 6 月加入公司，一直負(fù)責(zé)監(jiān)控平臺的告警系統(tǒng)。之后，我們的整個監(jiān)控平臺架構(gòu)中途換過兩次，其中一次架構(gòu)發(fā)生了巨大的變化。我們監(jiān)控告警平臺最早的架構(gòu)如下圖所示：

這個架構(gòu)的挑戰(zhàn)難點(diǎn)在于：

海量的監(jiān)控數(shù)據(jù)（Metric & Log & Trace 數(shù)據(jù)）實(shí)時寫入 ElasticSearch；

多維度的監(jiān)控指標(biāo)頁面展示（Dashboard） 查 ElasticSearch 的數(shù)據(jù)比較頻繁；

不斷遞增的告警規(guī)則需要通過查詢 ElasticSearch 數(shù)據(jù)來進(jìn)行判斷是否要告警。

從上面的幾個問題我們就可以很明顯的發(fā)現(xiàn)這種架構(gòu)的瓶頸就在于 ElasticSearch 集群的寫入和查詢能力，在海量的監(jiān)控數(shù)據(jù)（Metric & Log & Trace 數(shù)據(jù)）下實(shí)時的寫入對 ElasticSearch 有極大的影響。 我依然清楚記得，當(dāng)時經(jīng)常因為寫入的問題導(dǎo)致 ElasticSearch 集群掛掉，從而讓我的告警和監(jiān)控頁面（Dashboard）歇菜（那會老被噴：為啥配置的告警規(guī)則沒有觸發(fā)告警？為啥查看應(yīng)用的 Dashboard 監(jiān)控頁面沒數(shù)據(jù)）。我也很無奈啊，只想祈禱我們的 ElasticSearch 集群穩(wěn)一點(diǎn)。

01

初次接觸 Flink

在如此糟糕的架構(gòu)情況下，我們挺過了幾個月，后面由于一些特殊的原因，我們監(jiān)控平臺組的整體做了一個很大的架構(gòu)調(diào)整，如下圖：

主要做了四點(diǎn)改變：

接入 Flink 集群去消費(fèi) Kafka 數(shù)據(jù)，告警的 Flink Job 消費(fèi) Kafka 數(shù)據(jù)去判斷異常點(diǎn)，然后做告警

Metric & Trace 數(shù)據(jù)存儲到 ElasticSearch，之前還存儲在 ElasticSearch 中的有 Log 數(shù)據(jù)

Log 數(shù)據(jù)存儲到 Cassandra

Dashboard 查詢數(shù)據(jù)增加 API 查詢 Cassandra 的日志數(shù)據(jù)

原先因為 Metric & Trace & Log 的數(shù)據(jù)量一起全部實(shí)時寫入到 ElasticSearch 中，對 ElasticSearch 的壓力很大，所以我們將 Log 的數(shù)據(jù)拆分存儲到 Cassandra 中，分擔(dān)了一些 ElasticSearch 的寫入壓力。 但是過后我們發(fā)現(xiàn)偶爾還會出現(xiàn)數(shù)據(jù)實(shí)時寫入到 ElasticSearch 集群把 ElasticSearch 寫掛的情況。所以那會不斷調(diào)優(yōu)我們的寫入數(shù)據(jù)到 ElasticSearch 的 Flink Job，然后也對 ElasticSearch 服務(wù)端做了不少的性能調(diào)優(yōu)。 另外那會我們的監(jiān)控數(shù)據(jù)是以 10s 一次為單位將采集的數(shù)據(jù)發(fā)上來的，后面我們調(diào)整了下數(shù)據(jù)采集的策略（變成 30s 一次為單位采集數(shù)據(jù)），采取多種調(diào)優(yōu)策略后，終于將我們的 ElasticSearch 弄穩(wěn)定了。

02

遇到 Flink 相關(guān)的挑戰(zhàn)

替換成這種新架構(gòu)后，由于組里沒人熟悉 Flink，再加上那會兒 Flink 的資料真的很少很少，所以當(dāng)時在組里對 Flink 這塊大家都是從 0 開始學(xué)習(xí)，于大家而言挑戰(zhàn)還挺大的。

那時候我們跑在 Flink 上面的 Job 也遇到各種各樣的問題：

消費(fèi) Kafka 數(shù)據(jù)延遲

checkpoint 失敗

窗口概念模糊、使用操作有誤

Event Time 和 Processing Time 選擇有誤

不知道怎么利用 Watermark 機(jī)制來處理亂序和延遲的數(shù)據(jù)

Flink 自帶的 Connector 的優(yōu)化

Flink 中的 JobManager 和 TaskManager 經(jīng)常掛導(dǎo)致 Flink Job 重啟

Flink 集群模式的選型

...

因為碰到的各種各樣的問題，所以才會促使我們不斷地學(xué)習(xí) Flink 的原理和內(nèi)部機(jī)制，然后慢慢去解決上面遇到的各種問題，并逐步穩(wěn)定我們監(jiān)控平臺運(yùn)行的 Flink Job。

03

為什么要學(xué)習(xí) Flink？

隨著大數(shù)據(jù)的不斷發(fā)展，對數(shù)據(jù)的及時性要求越來越高，實(shí)時場景需求也變得越來越多，主要分下面幾大類：

那么為了滿足這些實(shí)時場景的需求，衍生出不少計算引擎框架，現(xiàn)有市面上的大數(shù)據(jù)計算引擎的對比如下：

可以發(fā)現(xiàn)無論從 Flink 的架構(gòu)設(shè)計上，還是從其功能完整性和易用性來講都是領(lǐng)先的，再加上Flink 是阿里巴巴主推的計算引擎框架，所以從去年開始就越來越火了！ 雖然市面上講 Flink 的太少太少，國內(nèi)的中文資料太欠缺，已有的幾本書籍也不甚詳盡，但是國內(nèi)在阿里的推動下，我相信 Flink 會越來越火的，并且阿里內(nèi)部也將 Flink 做了一定的優(yōu)化和修改，叫 Blink，今年年初也將源碼貢獻(xiàn)到 Flink 上面，后面在 Flink 1.9 版本會將 Blink 的功能進(jìn)行合并到 Flink 上去。 目前，阿里巴巴、騰訊、美團(tuán)、華為、滴滴出行、攜程、餓了么、愛奇藝、有贊、唯品會等大廠都已經(jīng)將 Flink 實(shí)踐于公司大型項目中，帶起了一波 Flink 風(fēng)潮，勢必也會讓 Flink 人才市場產(chǎn)生供不應(yīng)求的招聘現(xiàn)象。

04

我為什么要寫 FLink 專欄？

在這個過程中我持續(xù)記錄自己的 Flink 學(xué)習(xí)之路，目前已經(jīng)對外公布了 20+ 篇 Flink 的個人學(xué)習(xí)博客，同時好多對 Flink 感興趣的童鞋也加我一起討論問題。 每天群里的童鞋會提很多遇到的 Flink 問題，但是我發(fā)現(xiàn)得到的回答比較少，其實(shí)這并不是因為群里大佬不活躍，而是因為大家對 Flink 的了解還不是很多，比如有的是大數(shù)據(jù)工程師但之前是搞 Spark 這塊的，有的是轉(zhuǎn)大數(shù)據(jù)開發(fā)的后端開發(fā)工程師，有的是對 Flink 這塊比較感興趣的研究生等。 因為自己就是從 Flink 小白過來的，所以知道初學(xué)者可能會遇到的哪些問題。當(dāng)你回首的時候，你可能會發(fā)現(xiàn)，這么簡單的問題自己當(dāng)時那么費(fèi)力地折騰了半天都出不來。這種時候要是有人指點(diǎn)一下，可以節(jié)省多少功夫啊！ 所以自己在心里萌生了一個想法：寫一個 Flink 專欄幫助大家盡快地從小白階段過渡到入門階段，然后再從入門到能夠?qū)?Flink 用上，在生產(chǎn)環(huán)境真正把你的 Flink Job 運(yùn)行起來，再做到能夠根據(jù)你生產(chǎn)環(huán)境出現(xiàn)的錯誤進(jìn)行排查并解決，還能根據(jù)你的 Job 的運(yùn)行狀況進(jìn)一步優(yōu)化！

專欄亮點(diǎn)

全網(wǎng)首個使用最新版本 Flink 1.9 進(jìn)行內(nèi)容講解（該版本更新很大，架構(gòu)功能都有更新），領(lǐng)跑于目前市面上常見的 Flink 1.7 版本的教學(xué)課程。

包含大量的實(shí)戰(zhàn)案例和代碼去講解原理，有助于讀者一邊學(xué)習(xí)一邊敲代碼，達(dá)到更快，更深刻的學(xué)習(xí)境界。目前市面上的書籍沒有任何實(shí)戰(zhàn)的內(nèi)容，還只是講解純概念和翻譯官網(wǎng)。

在專欄高級篇中，根據(jù) Flink 常見的項目問題提供了排查和解決的思維方法，并通過這些問題探究了為什么會出現(xiàn)這類問題。

在實(shí)戰(zhàn)和案例篇，圍繞大廠公司的經(jīng)典需求進(jìn)行分析，包括架構(gòu)設(shè)計、每個環(huán)節(jié)的操作、代碼實(shí)現(xiàn)都有一一講解。

專欄內(nèi)容

預(yù)備篇

介紹實(shí)時計算常見的使用場景，講解 Flink 的特性，并且對比了 Spark Streaming、Structured Streaming 和 Storm 等大數(shù)據(jù)處理引擎，然后準(zhǔn)備環(huán)境并通過兩個 Flink 應(yīng)用程序帶大家上手 Flink。

基礎(chǔ)篇

深入講解 Flink 中 Time、Window、Watermark、Connector 原理，并有大量文章篇幅（含詳細(xì)代碼）講解如何去使用這些 Connector（比如 Kafka、ElasticSearch、HBase、Redis、MySQL 等），并且會講解使用過程中可能會遇到的坑，還教大家如何去自定義 Connector。

進(jìn)階篇

講解 Flink 中 State、Checkpoint、Savepoint、內(nèi)存管理機(jī)制、CEP、Table／SQL API、Machine Learning 、Gelly。在這篇中不僅只講概念，還會講解如何去使用 State、如何配置 Checkpoint、Checkpoint 的流程和如何利用 CEP 處理復(fù)雜事件。

高級篇

重點(diǎn)介紹 Flink 作業(yè)上線后的監(jiān)控運(yùn)維：如何保證高可用、如何定位和排查反壓問題、如何合理的設(shè)置作業(yè)的并行度、如何保證 Exactly Once、如何處理數(shù)據(jù)傾斜問題、如何調(diào)優(yōu)整個作業(yè)的執(zhí)行效率、如何監(jiān)控 Flink 及其作業(yè)？

實(shí)戰(zhàn)篇

教大家如何分析實(shí)時計算場景的需求，并使用 Flink 里面的技術(shù)去實(shí)現(xiàn)這些需求，比如實(shí)時統(tǒng)計 PV／UV、實(shí)時統(tǒng)計商品銷售額 TopK、應(yīng)用 Error 日志實(shí)時告警、機(jī)器宕機(jī)告警。這些需求如何使用 Flink 實(shí)現(xiàn)的都會提供完整的代碼供大家參考，通過這些需求你可以學(xué)到 ProcessFunction、Async I／O、廣播變量等知識的使用方式。

系統(tǒng)案例篇

講解大型流量下的真實(shí)案例：如何去實(shí)時處理海量日志（錯誤日志實(shí)時告警／日志實(shí)時 ETL／日志實(shí)時展示／日志實(shí)時搜索）、基于 Flink 的百億數(shù)據(jù)實(shí)時去重實(shí)踐（從去重的通用解決方案 --> 使用 BloomFilter 來實(shí)現(xiàn)去重 --> 使用 Flink 的 KeyedState 實(shí)現(xiàn)去重）。

▲Flink 專欄思維導(dǎo)圖

多圖講解 Flink 知識點(diǎn)

▲Flink 支持多種時間語義

▲Flink 提供靈活的窗口

▲Flink On YARN

▲Flink Checkpoint

▲Flink 監(jiān)控