看過許多分享為什么我還是不懂 Flink？
一、為什么要學習 Flink
隨著大數據時代深入普及，數據倉庫從業者也必須得跟上時代發展，去學習很多大數據組件，離線數倉我們可以使用 Hive 或者 ODPS 等云服務。傳統數倉轉型大數據數倉，憑借熟悉的 SQL 實踐技能和豐富的數倉方法論等理論知識，想必大家不會遇到太大阻力。
一方面隨著數據應用的深入發展，對于時效性的要求越來越高。另一方面大數據技術棧從 Storm 到 Spark Streaming 再到 Flink API 再到 Flink SQL。目前為止，實時計算在吞吐、易用性、穩定性方面已經非常成熟了。
應用上的真實需求伴隨實時計算的成熟(特別是這兩年 Flink 的大力推廣和迭代)，使得實時數倉和批流一體概念成為熱點話題，但是離線數倉向實時數倉的轉變需要考慮的因素很多，學習起來困難重重。
1.1 Flink 是什么
在 Flink 之前，傳統的批處理方式和早期的流式處理框架也有自身的局限性，難以滿足延遲、吞吐、容錯、便捷性等方面日益苛刻的要求。在這種形勢下，Flink 以其獨特的天然流式計算特性和更為先進的架構設計，極大地改善了以前的流式處理框架所存在的問題。
Flink 是德國幾所大學發起的的學術項目，后來不斷發展壯大，并于 2014 年末成為 Apache 頂級項目，美團在 2017 年已經在使用了，直到 2019 年初隨著阿里的大力推廣，Flink 在國內開始普及，并且版本迭代非常之快，兩年半時間已經從 1.7 迭代到 1.14 了。
Flink 目前主要應用在流處理，批處理被認為是流的特例，最終目標是批流一體、完全 SQL 化。
越來越多的國內公司開始用 Flink 來做實時數據處理，其中阿里巴巴率先將 Flink 技術在全集團推廣使用，比如 Flink SQL 與 Hive 生態的集成、擁抱 AI 等;騰訊、百度、字節跳動、滴滴、華為等眾多互聯網公司也已經將 Flink 作為未來技術重要的發力點。在未來 3 ~ 5 年，Flink 必將發展成為企業內部主流的數據處理框架，成為開發者進入大廠的“敲門磚”。
1.2 Flink 能做什么
實時數據計算
雙十一電商大促銷，管理者要以秒級的響應時間查看實時銷售業績、庫存信息以及與競品的對比結果，以爭取更多的決策時間。
股票交易要以毫秒級的速度來對新信息做出響應。
風險控制要對每一份欺詐交易迅速做出處理，以減少不必要的損失。
網絡運營商要以極快速度發現網絡和數據中心的故障等等。
實時數據倉庫和 ETL
離線數據倉庫的計算和數據的實時性均較差。在許多場景下，數據本身的價值隨著時間的流逝會逐步減弱，因此數據發生后必須盡快的達到用戶的手中，實時數倉的構建需求也應運而生。
實時數據倉庫的建設是“數據智能 BI”必不可少的一環，也是大規模數據應用中必然面臨的挑戰。
Flink 在實時數倉和實時 ETL 中有天然的優勢：
- 狀態管理，實時數倉里面會進行很多的聚合計算，這些都需要對于狀態進行訪問和管理，Flink 支持強大的狀態管理。
- 豐富的 API，Flink 提供極為豐富的多層次 API，包括 Stream API、Table API 及 Flink SQL。
- 生態完善，實時數倉的用途廣泛，Flink 支持多種存儲(HDFS、ES 等)。
- 批流一體，Flink 已經在將流計算和批計算的 API 進行統一。
實時數據同步 CDC
Flink SQL CDC 可以從 MySQL、PostgreSQL 等數據庫直接讀取數據，實時寫入到 sink 組件。并且整個過程對源端數據庫是沒有影響的。
8月份 ，Flink CDC 2.0 也已經正式發布，此次的核心改進和提升包括：
- 并發讀取，全量數據的讀取性能可以水平擴展;
- 全程無鎖，不對線上業務產生鎖的風險;
- 斷點續傳，支持全量階段的 checkpoint。
事件驅動型應用 CEP
事件驅動型應用是一類具有狀態的應用，它從一個或多個事件流提取數據，并根據到來的事件觸發計算、狀態更新或其他外部動作。
常見的應用場景如下：
- 反欺詐
- 異常檢測
- 基于規則的報警
- 業務流程監控
- (社交網絡)Web 應用
- 機器學習與圖計算
Flink 的野心一點都不比 Spark 小。做為一個統一的一站式大數據計算引擎，雖然這兩塊目前還沒有真正發力，讓我們拭目以待吧。
二、坎坷的學習之路
2.1 理論知識學習與動手實操
第一次接觸 Flink 還是 2019 年初，那時候 Flink 的使用還僅限于各個互聯網大廠，阿里收購 Flink 背后的公司后開始大力宣傳，組織了系列性的在線課程，那時候網上的資源還好很少，Flink 的問題還很多。我也只是硬著頭皮聽到了 1.5 節就掉隊了。但當時很欣慰的是我竟然照著 1.3 的手冊下載了源碼并且編譯成功了(那時候還是 1.7 版本)，雖然花費了好幾天的時間，但對于開發小白來說已經很滿意了。
我為什么會掉隊呢，因為純理論的知識理解起來真的很費勁，而且也記不住，所以就在網上找了些實戰視頻跟著敲了一兩周的代碼，比如 PV/UV、電商訂單金額計算，并且同時實現了 Spark/Flink 兩個版本。但感覺這些更像是個 Demo，因為實際工作環境要面對的問題可要比這些要復雜。最終由于工作中沒有實時計算場景也就放棄了。
2.2 試圖用 Flink 解決公司實時同步問題
如今，我們公司剛好有了實時計算的需求，很簡單，就是要把業務系統的十幾張表實時同步到新的數據庫中，供數據分析團隊使用。之前用的是阿里云服務 DTS，直接 Mysql 實時同步到 ODPS ，但 DTS 同步到 ODPS，數據源的刪除更新都會新增一條數據，使用起來會麻煩些需要取最新一條數據同時還要判斷該條數據是否已經刪除，同時數據還得定期去重保留最后一條用來節省 ODPS 查詢成本(ODPS 是按照查詢數據量收費的)。
生產環境涉及到的實際問題，視頻課程、網上文章永遠不會告訴你的(也可能我沒找到)。比如實時更新/刪除問題、數據質量監控問題、故障恢復重啟時候 Kafka offset 讀取位置問題、順序消費問題、流里一條數據跟業務庫表歷史數據 join 問題等等，還有十幾張表數據混在一起表結構、列內容都不一樣程序代碼又該如何實現呢?
想到這些感覺真的無從下手，之前學的很多理論知識，還有網上的各種分享，這都無法解決我的問題。
沒辦法，只能硬著頭皮上。
方案一：Flink 讀取 Kafka 數據 sink 到 Hbase。
Hbase 自動處理更新問題，刪除插入速度也很快，可以一條一條寫入，忙活了兩周終于寫完全部代碼并測試通過上線試運行了。
我把數據分析團隊用到的其他數據也都導入到了 Hbase，再搭建個 Phoenix，最好再開發一套提交 SQL 的 Web 頁面就好了。
但很快問題來了：穩定運行一周多后，Hbase 服務器磁盤滿了，經查發現存儲開銷是正常預期的好多倍，相比 ODPS 這樣成本就太不劃算了。
方案二：Flink 讀取 Kafka 數據 sink 到 ODPS。
經咨詢 ODPS 的更新刪除功能今年三月份才上線，而且處于測試階段，生產當然不能用，所以只能跟 DTS 一樣，數據源的刪除更新都新增一條數據做好標記就好。
然后就開始在方案一基礎上修改代碼了，但一條一條插入性能太慢，后來又費老大勁改用批量插入。
方案三：Flink 讀取 Kafka 數據 sink 到 ClickHouse。
這時候其他幾個問題基本都已解決，但之前的邏輯還都保持跟業務系統表一樣的表結構sink到目標數據庫。
走到這一步，我也算是有些實時 ETL 經驗了，一開始遇到的很多問題也都解決掉了，但還有一個棘手的問題亟待解決：流里一條業務數據過來后要跟全量歷史維度數據 join ，這該如何實現?
由于數據量有點大，所以考慮將維度表實時寫入 Redis 或 Hbase，遇到業務表時候實時根據主鍵過去實時查詢即可。
哈哈，到這里，基本上滿足需求了，下一步就是性能優化了，但是對于 Flink 還有別的可選方式，比如 Flink CDC、FLink SQL。
最后，給大家分享幾張 Web UI 截圖：
