[[432373]]

一、為什么要學習 Flink

隨著大數(shù)據(jù)時代深入普及，數(shù)據(jù)倉庫從業(yè)者也必須得跟上時代發(fā)展，去學習很多大數(shù)據(jù)組件，離線數(shù)倉我們可以使用 Hive 或者 ODPS 等云服務。傳統(tǒng)數(shù)倉轉型大數(shù)據(jù)數(shù)倉，憑借熟悉的 SQL 實踐技能和豐富的數(shù)倉方法論等理論知識，想必大家不會遇到太大阻力。

一方面隨著數(shù)據(jù)應用的深入發(fā)展，對于時效性的要求越來越高。另一方面大數(shù)據(jù)技術棧從 Storm 到 Spark Streaming 再到 Flink API 再到 Flink SQL。目前為止，實時計算在吞吐、易用性、穩(wěn)定性方面已經(jīng)非常成熟了。

應用上的真實需求伴隨實時計算的成熟(特別是這兩年 Flink 的大力推廣和迭代)，使得實時數(shù)倉和批流一體概念成為熱點話題，但是離線數(shù)倉向實時數(shù)倉的轉變需要考慮的因素很多，學習起來困難重重。

1.1 Flink 是什么

在 Flink 之前，傳統(tǒng)的批處理方式和早期的流式處理框架也有自身的局限性，難以滿足延遲、吞吐、容錯、便捷性等方面日益苛刻的要求。在這種形勢下，F(xiàn)link 以其獨特的天然流式計算特性和更為先進的架構設計，極大地改善了以前的流式處理框架所存在的問題。

Flink 是德國幾所大學發(fā)起的的學術項目，后來不斷發(fā)展壯大，并于 2014 年末成為 Apache 頂級項目，美團在 2017 年已經(jīng)在使用了，直到 2019 年初隨著阿里的大力推廣，F(xiàn)link 在國內(nèi)開始普及，并且版本迭代非常之快，兩年半時間已經(jīng)從 1.7 迭代到 1.14 了。

Flink 目前主要應用在流處理，批處理被認為是流的特例，最終目標是批流一體、完全 SQL 化。

越來越多的國內(nèi)公司開始用 Flink 來做實時數(shù)據(jù)處理，其中阿里巴巴率先將 Flink 技術在全集團推廣使用，比如 Flink SQL 與 Hive 生態(tài)的集成、擁抱 AI 等;騰訊、百度、字節(jié)跳動、滴滴、華為等眾多互聯(lián)網(wǎng)公司也已經(jīng)將 Flink 作為未來技術重要的發(fā)力點。在未來 3 ~ 5 年，F(xiàn)link 必將發(fā)展成為企業(yè)內(nèi)部主流的數(shù)據(jù)處理框架，成為開發(fā)者進入大廠的“敲門磚”。

1.2 Flink 能做什么

實時數(shù)據(jù)計算

雙十一電商大促銷，管理者要以秒級的響應時間查看實時銷售業(yè)績、庫存信息以及與競品的對比結果，以爭取更多的決策時間。

股票交易要以毫秒級的速度來對新信息做出響應。

風險控制要對每一份欺詐交易迅速做出處理，以減少不必要的損失。

網(wǎng)絡運營商要以極快速度發(fā)現(xiàn)網(wǎng)絡和數(shù)據(jù)中心的故障等等。

實時數(shù)據(jù)倉庫和 ETL

離線數(shù)據(jù)倉庫的計算和數(shù)據(jù)的實時性均較差。在許多場景下，數(shù)據(jù)本身的價值隨著時間的流逝會逐步減弱，因此數(shù)據(jù)發(fā)生后必須盡快的達到用戶的手中，實時數(shù)倉的構建需求也應運而生。

實時數(shù)據(jù)倉庫的建設是“數(shù)據(jù)智能 BI”必不可少的一環(huán)，也是大規(guī)模數(shù)據(jù)應用中必然面臨的挑戰(zhàn)。

Flink 在實時數(shù)倉和實時 ETL 中有天然的優(yōu)勢：

• 狀態(tài)管理，實時數(shù)倉里面會進行很多的聚合計算，這些都需要對于狀態(tài)進行訪問和管理，F(xiàn)link 支持強大的狀態(tài)管理。
• 豐富的 API，F(xiàn)link 提供極為豐富的多層次 API，包括 Stream API、Table API 及 Flink SQL。
• 生態(tài)完善，實時數(shù)倉的用途廣泛，F(xiàn)link 支持多種存儲(HDFS、ES 等)。
• 批流一體，F(xiàn)link 已經(jīng)在將流計算和批計算的 API 進行統(tǒng)一。

實時數(shù)據(jù)同步 CDC

Flink SQL CDC 可以從 MySQL、PostgreSQL 等數(shù)據(jù)庫直接讀取數(shù)據(jù)，實時寫入到 sink 組件。并且整個過程對源端數(shù)據(jù)庫是沒有影響的。

8月份 ，F(xiàn)link CDC 2.0 也已經(jīng)正式發(fā)布，此次的核心改進和提升包括：

• 并發(fā)讀取，全量數(shù)據(jù)的讀取性能可以水平擴展;
• 全程無鎖，不對線上業(yè)務產(chǎn)生鎖的風險;
• 斷點續(xù)傳，支持全量階段的 checkpoint。

事件驅動型應用 CEP

事件驅動型應用是一類具有狀態(tài)的應用，它從一個或多個事件流提取數(shù)據(jù)，并根據(jù)到來的事件觸發(fā)計算、狀態(tài)更新或其他外部動作。

常見的應用場景如下：

• 反欺詐
• 異常檢測
• 基于規(guī)則的報警
• 業(yè)務流程監(jiān)控
• (社交網(wǎng)絡)Web 應用
• 機器學習與圖計算

Flink 的野心一點都不比 Spark 小。做為一個統(tǒng)一的一站式大數(shù)據(jù)計算引擎，雖然這兩塊目前還沒有真正發(fā)力，讓我們拭目以待吧。

二、坎坷的學習之路

2.1 理論知識學習與動手實操

第一次接觸 Flink 還是 2019 年初，那時候 Flink 的使用還僅限于各個互聯(lián)網(wǎng)大廠，阿里收購 Flink 背后的公司后開始大力宣傳，組織了系列性的在線課程，那時候網(wǎng)上的資源還好很少，F(xiàn)link 的問題還很多。我也只是硬著頭皮聽到了 1.5 節(jié)就掉隊了。但當時很欣慰的是我竟然照著 1.3 的手冊下載了源碼并且編譯成功了(那時候還是 1.7 版本)，雖然花費了好幾天的時間，但對于開發(fā)小白來說已經(jīng)很滿意了。

我為什么會掉隊呢，因為純理論的知識理解起來真的很費勁，而且也記不住，所以就在網(wǎng)上找了些實戰(zhàn)視頻跟著敲了一兩周的代碼，比如 PV/UV、電商訂單金額計算，并且同時實現(xiàn)了 Spark/Flink 兩個版本。但感覺這些更像是個 Demo，因為實際工作環(huán)境要面對的問題可要比這些要復雜。最終由于工作中沒有實時計算場景也就放棄了。

2.2 試圖用 Flink 解決公司實時同步問題

如今，我們公司剛好有了實時計算的需求，很簡單，就是要把業(yè)務系統(tǒng)的十幾張表實時同步到新的數(shù)據(jù)庫中，供數(shù)據(jù)分析團隊使用。之前用的是阿里云服務 DTS，直接 Mysql 實時同步到 ODPS ，但 DTS 同步到 ODPS，數(shù)據(jù)源的刪除更新都會新增一條數(shù)據(jù)，使用起來會麻煩些需要取最新一條數(shù)據(jù)同時還要判斷該條數(shù)據(jù)是否已經(jīng)刪除，同時數(shù)據(jù)還得定期去重保留最后一條用來節(jié)省 ODPS 查詢成本(ODPS 是按照查詢數(shù)據(jù)量收費的)。

生產(chǎn)環(huán)境涉及到的實際問題，視頻課程、網(wǎng)上文章永遠不會告訴你的(也可能我沒找到)。比如實時更新/刪除問題、數(shù)據(jù)質(zhì)量監(jiān)控問題、故障恢復重啟時候 Kafka offset 讀取位置問題、順序消費問題、流里一條數(shù)據(jù)跟業(yè)務庫表歷史數(shù)據(jù) join 問題等等，還有十幾張表數(shù)據(jù)混在一起表結構、列內(nèi)容都不一樣程序代碼又該如何實現(xiàn)呢?

想到這些感覺真的無從下手，之前學的很多理論知識，還有網(wǎng)上的各種分享，這都無法解決我的問題。

沒辦法，只能硬著頭皮上。

方案一：Flink 讀取 Kafka 數(shù)據(jù) sink 到 Hbase。

Hbase 自動處理更新問題，刪除插入速度也很快，可以一條一條寫入，忙活了兩周終于寫完全部代碼并測試通過上線試運行了。

我把數(shù)據(jù)分析團隊用到的其他數(shù)據(jù)也都導入到了 Hbase，再搭建個 Phoenix，最好再開發(fā)一套提交 SQL 的 Web 頁面就好了。

但很快問題來了：穩(wěn)定運行一周多后，Hbase 服務器磁盤滿了，經(jīng)查發(fā)現(xiàn)存儲開銷是正常預期的好多倍，相比 ODPS 這樣成本就太不劃算了。

方案二：Flink 讀取 Kafka 數(shù)據(jù) sink 到 ODPS。

經(jīng)咨詢 ODPS 的更新刪除功能今年三月份才上線，而且處于測試階段，生產(chǎn)當然不能用，所以只能跟 DTS 一樣，數(shù)據(jù)源的刪除更新都新增一條數(shù)據(jù)做好標記就好。

然后就開始在方案一基礎上修改代碼了，但一條一條插入性能太慢，后來又費老大勁改用批量插入。

方案三：Flink 讀取 Kafka 數(shù)據(jù) sink 到 ClickHouse。

這時候其他幾個問題基本都已解決，但之前的邏輯還都保持跟業(yè)務系統(tǒng)表一樣的表結構sink到目標數(shù)據(jù)庫。

走到這一步，我也算是有些實時 ETL 經(jīng)驗了，一開始遇到的很多問題也都解決掉了，但還有一個棘手的問題亟待解決：流里一條業(yè)務數(shù)據(jù)過來后要跟全量歷史維度數(shù)據(jù) join ，這該如何實現(xiàn)?

由于數(shù)據(jù)量有點大，所以考慮將維度表實時寫入 Redis 或 Hbase，遇到業(yè)務表時候實時根據(jù)主鍵過去實時查詢即可。

哈哈，到這里，基本上滿足需求了，下一步就是性能優(yōu)化了，但是對于 Flink 還有別的可選方式，比如 Flink CDC、FLink SQL。

最后，給大家分享幾張 Web UI 截圖：