不知道你是否有過和我類似的經歷？

我是 2018 年 6 月加入公司，一直負責監控平臺的告警系統。之后，我們的整個監控平臺架構中途換過兩次，其中一次架構發生了巨大的變化。我們監控告警平臺最早的架構如下圖所示：

這個架構的挑戰難點在于：

海量的監控數據（Metric & Log & Trace 數據）實時寫入 ElasticSearch；

多維度的監控指標頁面展示（Dashboard） 查 ElasticSearch 的數據比較頻繁；

不斷遞增的告警規則需要通過查詢 ElasticSearch 數據來進行判斷是否要告警。

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

01

初次接觸 Flink

在如此糟糕的架構情況下，我們挺過了幾個月，后面由于一些特殊的原因，我們監控平臺組的整體做了一個很大的架構調整，如下圖：

主要做了四點改變：

接入 Flink 集群去消費 Kafka 數據，告警的 Flink Job 消費 Kafka 數據去判斷異常點，然后做告警

Metric & Trace 數據存儲到 ElasticSearch，之前還存儲在 ElasticSearch 中的有 Log 數據

Log 數據存儲到 Cassandra

Dashboard 查詢數據增加 API 查詢 Cassandra 的日志數據

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

02

遇到 Flink 相關的挑戰

替換成這種新架構后，由于組里沒人熟悉 Flink，再加上那會兒 Flink 的資料真的很少很少，所以當時在組里對 Flink 這塊大家都是從 0 開始學習，于大家而言挑戰還挺大的。

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

消費 Kafka 數據延遲

checkpoint 失敗

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

Event Time 和 Processing Time 選擇有誤

不知道怎么利用 Watermark 機制來處理亂序和延遲的數據

Flink 自帶的 Connector 的優化

Flink 中的 JobManager 和 TaskManager 經常掛導致 Flink Job 重啟

Flink 集群模式的選型

...

因為碰到的各種各樣的問題，所以才會促使我們不斷地學習 Flink 的原理和內部機制，然后慢慢去解決上面遇到的各種問題，并逐步穩定我們監控平臺運行的 Flink Job。

03

為什么要學習 Flink？

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

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

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

04

我為什么要寫 FLink 專欄？

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

專欄亮點

全網首個使用最新版本 Flink 1.9 進行內容講解（該版本更新很大，架構功能都有更新），領跑于目前市面上常見的 Flink 1.7 版本的教學課程。

包含大量的實戰案例和代碼去講解原理，有助于讀者一邊學習一邊敲代碼，達到更快，更深刻的學習境界。目前市面上的書籍沒有任何實戰的內容，還只是講解純概念和翻譯官網。

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

在實戰和案例篇，圍繞大廠公司的經典需求進行分析，包括架構設計、每個環節的操作、代碼實現都有一一講解。

專欄內容

預備篇

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

基礎篇

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

進階篇

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

高級篇

重點介紹 Flink 作業上線后的監控運維：如何保證高可用、如何定位和排查反壓問題、如何合理的設置作業的并行度、如何保證 Exactly Once、如何處理數據傾斜問題、如何調優整個作業的執行效率、如何監控 Flink 及其作業？

實戰篇

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

系統案例篇

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

▲Flink 專欄思維導圖

多圖講解 Flink 知識點

▲Flink 支持多種時間語義

▲Flink 提供靈活的窗口

▲Flink On YARN

▲Flink Checkpoint

▲Flink 監控