[[432373]]

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

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

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

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

1.1 Flink 是什么

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

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

Flink 目前主要應(yīng)用在流處理，批處理被認(rèn)為是流的特例，最終目標(biāo)是批流一體、完全 SQL 化。

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

1.2 Flink 能做什么

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

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

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

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

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

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

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

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

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

• 狀態(tài)管理，實時數(shù)倉里面會進(jìn)行很多的聚合計算，這些都需要對于狀態(tài)進(jìn)行訪問和管理，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 進(jìn)行統(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ā)布，此次的核心改進(jìn)和提升包括：

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

事件驅(qū)動型應(yīng)用 CEP

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

常見的應(yīng)用場景如下：

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

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

二、坎坷的學(xué)習(xí)之路

2.1 理論知識學(xué)習(xí)與動手實操

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

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

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

如今，我們公司剛好有了實時計算的需求，很簡單，就是要把業(yè)務(wù)系統(tǒng)的十幾張表實時同步到新的數(shù)據(jù)庫中，供數(shù)據(jù)分析團(tuán)隊使用。之前用的是阿里云服務(wù) 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)上文章永遠(yuǎn)不會告訴你的(也可能我沒找到)。比如實時更新/刪除問題、數(shù)據(jù)質(zhì)量監(jiān)控問題、故障恢復(fù)重啟時候 Kafka offset 讀取位置問題、順序消費問題、流里一條數(shù)據(jù)跟業(yè)務(wù)庫表歷史數(shù)據(jù) join 問題等等，還有十幾張表數(shù)據(jù)混在一起表結(jié)構(gòu)、列內(nèi)容都不一樣程序代碼又該如何實現(xiàn)呢?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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