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

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

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

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

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

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

從上面的幾個問題我們就可以很明顯的發現這種架構的瓶頸就在於 ElasticSearch 集群的寫入和查詢能力，在海量的監控數據（Metric & Log & Trace 數據）下實時的寫入對 ElasticSearch 有極大的影響。

我依然清楚記得，當時經常因為寫入的問題導致 ElasticSearch 集群掛掉，從而讓我的告警和監控頁面（Dashboard）歇菜（那會老被噴：為啥配置的告警規則沒有觸發告警？為啥查看應用的 Dashboard 監控頁面沒數據）。我也很無奈啊，只想祈禱我們的 ElasticSearch 集群穩一點。

初次接觸 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 弄穩定了。

遇到 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。

為什麼要學習 Flink？

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

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

可以發現無論從 Flink 的架構設計上，還是從其功能完整性和易用性來講都是領先的，再加上 Flink 是阿里巴巴主推的計算引擎框架，所以從去年開始就越來越火了！

雖然市面上講 Flink 的太少太少，國內的中文資料太欠缺，已有的幾本書籍也不甚詳盡，但是國內在阿里的推動下，我相信 Flink 會越來越火的，並且阿里內部也將 Flink 做了一定的優化和修改，叫 Blink，今年年初也將源碼貢獻到 Flink 上面，後面在 Flink 1.9 版本會將 Blink 的功能進行合併到 Flink 上去。

目前，阿里巴巴、騰訊、美團、華為、滴滴出行、攜程、餓了麼、愛奇藝、有贊、唯品會等大廠都已經將 Flink 實踐於公司大型項目中，帶起了一波 Flink 風潮，勢必也會讓 Flink 人才市場產生供不應求的招聘現象。

我為什麼要寫 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 監控

專欄作者-zhisheng

在某大型公司擔任監控平臺研發工程師，負責實時計算引擎開發和流式告警，現專注於實時計算開發工作。

擅長 Flink、kafka、ElasticSearch 等大數據組件的項目開發和管理等。

專欄作者-範瑞

現就職於北京微鯉科技有限公司，負責數據倉庫的研發、集群維護及 Flink 實時流處理開發。兩年內經歷了公司數據量的爆炸式增長，從中收益良多。

你將獲得什麼

• 掌握 Flink 與其他計算框架的區別

• 掌握 Flink Time／Window／Watermark／Connectors 概念和實現原理

• 掌握 Flink State／Checkpoint／Savepoint 狀態與容錯

• 熟練使用 DataStream／DataSet／Table／SQL API 開發 Flink 作業

• 掌握 Flink 作業部署／運維／監控／性能調優

• 學會如何分析並完成實時計算需求

• 獲得大型高併發流量系統案例實戰項目經驗

適宜人群

• Flink 愛好者

• 實時計算開發工程師

• 大數據開發工程師

• 計算機專業研究生

• 有實時計算場景場景的 Java 開發工程師

最主要的是採用了分佈式快照ABS 算法，在數據保證一致性語義，procesing time , event time , ingestion time 做的更是比較好，希望 Flink 能在大家的共同努力下，發展得更加厲害！

閱讀更多 CSDN 的文章

關鍵字: 大數據 Dashboard 阿里巴巴集團