簡介：
利用實時數倉，企業可以實現實時 OLAP 分析、實時資料看板、實時業務監控、實時資料介面服務等用途。但想到實時數倉，很多人的第一印象就是架構複雜，難以操作與維護。而得益於新版 Flink 對 SQL 的支援，以及 TiDB HTAP 的特性，我們探索了一個高效、易用的 Flink+TiDB 實時數倉解決方案。
作者：齊智@TiDB
隨著網際網路飛速發展，企業業務種類會越來越多，業務資料量會越來越大，當發展到一定規模時，傳統的資料儲存結構逐漸無法滿足企業需求，實時資料倉庫就變成了一個必要的基礎服務。以維表 Join 為例，資料在業務資料來源中以正規化表的形式儲存，在分析時需要做大量的 Join 操作，降低效能。如果在資料清洗匯入過程中就能流式的完成 Join，那麼分析時就無需再次 Join，從而提升查詢效能。
利用實時數倉，企業可以實現實時 OLAP 分析、實時資料看板、實時業務監控、實時資料介面服務等用途。但想到實時數倉，很多人的第一印象就是架構複雜，難以操作與維護。而得益於新版 Flink 對 SQL 的支援，以及 TiDB HTAP 的特性，我們探索了一個高效、易用的 Flink+TiDB 實時數倉解決方案。
本文將首先介紹實時數倉的概念，然後介紹 Flink+TiDB 實時數倉的架構與優勢，接著給出一些已經在使用中的使用者場景，最後給出在 docker-compose 環境下的 Demo，用於讀者進行嘗試。
實時數倉的概念
資料倉庫的概念在 90 年代由 Bill Inmon 提出，是指一個面向主題的、整合的、相對穩定的、反映歷史變化的集合，用於支援管理決策。當時的資料倉庫透過訊息佇列收集來自資料來源的資料，透過每天或每週進行一次計算以供報表使用，也稱為離線數倉。
離線數倉架構
進入 21 世紀，隨著計算技術的發展、以及整體算力的提升，決策的主體逐漸從人工控制轉變為計算機演算法，出現了實時推薦、實時監控分析等需求，對應的決策週期時間由天級逐步變為秒級，在這些場景下，實時數倉應運而生。
當前的實時數倉主要有三種架構：Lambda架構、Kappa 架構以及實時 OLAP 變體架構：
Lambda 架構是指在離線數倉的基礎上疊加了實時數倉部分，使用流式引擎處理實時性較高的資料，最後將離線和線上的結果統一供應用使用。
實時數倉的 Lambda 架構
Kappa 架構則移除了離線數倉部分，全部使用實時資料生產。這種架構統一了計算引擎，降低了開發成本。
實時數倉的 Kappa 架構
隨著實時 OLAP 技術的提升，一個新的實時架構被提出，暫時被稱為“實時 OLAP 變體”。簡單來說，就是將一部分計算壓力從流式計算引擎轉嫁到實時 OLAP 分析引擎上，以此進行更加靈活的實時數倉計算。
總結一下，對於實時數倉，Lambda 架構需要維護流批兩套引擎，開發成本相較其它兩者更高。相比於 Kappa 架構，實時 OLAP 變體架構可以執行更加靈活的計算，但需要依賴額外的實時 OLAP 算力資源。接下來我們將介紹的 Flink + TiDB 實時數倉方案，就屬於實時 OLAP 變體架構。
關於實時數倉及這些架構更加詳細的對比說明，有興趣的讀者可以參考 Flink 中文社群的這篇文章：基於 Flink 的典型 ETL 場景實現方案。
Flink+ TiDB 實時數倉
Flink 是一個低延遲、高吞吐、流批統一的大資料計算引擎，被普遍用於高實時性場景下的實時計算，具有支援 exactly-once 等重要特性。
在集成了 TiFlash 之後，TiDB 已經成為了真正的 HTAP（線上事務處理 OLTP + 線上分析處理 OLAP）資料庫。換句話說，在實時數倉架構中，TiDB 既可以作為資料來源的業務資料庫，進行業務查詢的處理；又可以作為實時 OLAP 引擎，進行分析型場景的計算。
結合了 Flink 與 TiDB 兩者的特性，Flink+ TiDB 的方案的優勢也體現了出來：首先是速度有保障，兩者都可以透過水平擴充套件節點來增加算力；其次，學習和配置成本相對較低，因為 TiDB 相容 MySQL 5。7 協議，而最新版本的 Flink 也可以完全透過 Flink SQL 和強大的聯結器（connector）來編寫提交任務，節省了使用者的學習成本。
對於 Flink + TiDB 實時數倉，下面是幾種常用的搭建原型，可以用來滿足不同的需求，也可以在實際使用中自行擴充套件。
以 MySQL 作為資料來源
透過使用 Ververica 官方提供的 flink-connector-mysql-cdc，Flink 可以既作為採集層採集 MySQL 的 binlog 生成動態表，也作為流計算層實現流式計算，如流式 Join、預聚合等。最後，Flink 透過 JDBC 聯結器將計算完成的資料寫入 TiDB 中。
以 MySQL 作為資料來源的簡便架構
這個架構的優點是非常簡潔方便，在 MySQL 和 TiDB 都準備好對應資料庫和表的情況下，可以透過只編寫 Flink SQL 來完成任務的註冊與提交。讀者可以在本文末尾的【在docker-compose 中進行嘗試】一節中嘗試此架構。
以 Kafka 對接 Flink
如果資料已經從其它途徑存放到了Kafka 中，可以方便地透過 Flink Kafka Connector 使 Flink 從 Kafka 中獲得資料。
在這裡需要提一下的是，如果想要將 MySQL 或其它資料來源的變更日誌存放在 Kafka 中後續供 Flink 處理，那麼推薦使用 Canal 或 Debezium 採集資料來源變更日誌，因為 Flink 1。11 原生支援解析這兩種工具格式的 changelog，無需再額外實現解析器。
以 MySQL 作為資料來源，經過 Kafka 的架構示例
以 TiDB 作為資料來源
TiCDC 是一款透過拉取 TiKV 變更日誌實現的 TiDB 增量資料同步工具，可以利用其將 TiDB 的變更資料輸出到訊息佇列中，再由 Flink 提取。
以 TiDB 作為資料來源，透過 TiCDC 將 TiDB 的增量變化輸出到 Flink 中
在 4。0。7 版本，可以透過 TiCDC Open Protocol來完成與 Flink 的對接。在之後的版本，TiCDC 將支援直接輸出為 canal-json 形式，以供 Flink 使用。
案例與實踐
上個部分介紹了一些基礎的架構，實踐中的探索往往更加複雜和有趣，這一部分將介紹一些具有代表性和啟發性的使用者案例。
小紅書
小紅書是年輕人的生活方式平臺，使用者可以透過短影片、圖文等形式記錄生活點滴，分享生活方式，並基於興趣形成互動。截至到 2019 年 10 月，小紅書月活躍使用者數已經過億，並持續快速增長。
在小紅書的業務架構中，Flink 的資料來源和資料彙總處都是 TiDB，以達到類似於“物化檢視”的效果：
左上角的線上業務表執行正常的 OLTP 任務。
下方的 TiCDC 叢集抽取 TiDB 的實時變更資料，以 changelog 形式傳遞到 Kafka 中。
Flink 讀取 Kafka 中的 changelog，進行計算，如拼好寬表或聚合表。
Flink 將結果寫回到 TiDB 的寬表中，用於後續分析使用。
小紅書 Flink TiDB 叢集架構
整個過程形成了 TiDB 的閉環，將後續分析任務的 Join 工作轉移到了 Flink 上，並透過流式計算來緩解壓力。目前這套方案已經支援起了小紅書的內容稽核、筆記標籤推薦、增長審計等業務，經歷了大吞吐量的線上業務考驗且持續執行穩定。
貝殼金服
貝殼金服持續多年深耕居住場景，積累了豐富的中國房產大資料。貝殼金服以金融科技為驅動，利用 AI 演算法高效應用多維海量資料以提升產品體驗，為使用者提供豐富、定製化的金融服務。
在貝殼資料組的資料服務中，Flink 實時計算用於典型的維表 Join：
首先，使用 Syncer （MySQL 到 TiDB 的一個輕量級同步工具）採集業務資料來源上的維表資料同步到 TiDB 中。
然後，業務資料來源上的流表資料則透過 Canal 採集 binlog 存入 kafka 訊息佇列中。
Flink 讀取 Kafka 中流表的變更日誌，嘗試進行流式 Join，每當需要維表中的資料時，就去 TiDB 中查詢。
最後，Flink 將拼合而成的寬表寫入到 TiDB 中，用於資料分析服務。
貝殼金服資料分析平臺架構
利用以上的結構，可以將資料服務中的主表進行實時 Join 落地，然後服務方只需要查詢單表。這套系統在貝殼金服已經深入各個核心業務系統，跨系統的資料獲取統一走資料組的資料服務，省去了業務系統開發 API 和記憶體聚合資料程式碼的開發工作。
智慧芽
PatSnap（智慧芽）是一款全球專利檢索資料庫，整合了 1790 年至今的全球 116 個國家地區 1。3 億專利資料和 1。7 億化學結構資料。可檢索、瀏覽、翻譯專利，生成 Insights 專利分析報告，用於專利價值分析、引用分析、法律搜尋，檢視 3D 專利地圖。
智慧芽使用 Flink + TiDB 替換了原有的 Segment + Redshift 架構。
原有的 Segment + Redshift 架構，僅構建出了 ODS 層，資料寫入的規則和 schema 不受控制。且需要針對 ODS 編寫複雜的 ETL 來按照業務需求進行各類指標的計算來完成上層需求。Redshift 中落庫資料量大，計算慢（T+1 時效），並影響對外服務效能。
替換為基於 Kinesis +Flink + TiDB 構建的實時數倉架構後，不再需要構建 ODS 層。Flink 作為前置計算單元，直接從業務出發構建出 Flink Job ETL，完全控制了落庫規則並自定義 schema；即僅把業務關注的指標進行清洗並寫入 TiDB 來進行後續的分析查詢，寫入資料量大大減少。按使用者/租戶、地區、業務動作等關注的指標，結合分鐘、小時、天等不同粒度的時間視窗等，在 TiDB 上構建出 DWD/DWS/ADS 層，直接服務業務上的統計、清單等需求，上層應用可直接使用構建好的資料，且獲得了秒級的實時能力。
智慧芽資料分析平臺架構
使用者體驗：在使用了新架構後，入庫資料量、入庫規則和計算複雜度都大大下降，資料在 Flink Job 中已經按照業務需求處理完成並寫入 TiDB，不再需要基於 Redshift 的 全量 ODS 層進行 T+1 ETL。基於 TiDB 構建的實時數倉，透過合理的資料分層，架構上獲得了極大的精簡，開發維護也變得更加簡單；在資料查詢、更新、寫入效能上都獲得大幅度提升；在滿足不同的adhoc 分析需求時，不再需要等待類似 Redshift 預編譯的過程；擴容方便簡單易於開發。
目前這套架構正在上線，在智慧芽內部用來進行使用者行為分析和追蹤，並彙總出公司運營大盤、使用者行為分析、租戶行為分析等功能。
網易互娛
網易 2001 年正式成立線上遊戲事業部，經過近 20 年的發展，已躋身全球七大遊戲公司之一。在 App Annie 釋出的“2020 年度全球發行商 52 強”榜單中，網易位列第二。
網易互娛資料計費組平臺架構
在網易互娛計費組的應用架構中，一方面使用 Flink 完成業務資料來源到 TiDB 的實時寫入；另一方面，以 TiDB 作為分析資料來源，在後續的 Flink 叢集中進行實時流計算，生成分析報表。此外，網易互娛現在內部開發了 Flink 作業管理平臺，用於管理作業的整個生命週期。
知乎
知乎是中文網際網路綜合性內容平臺，以“讓每個人高效獲得可信賴的解答”為品牌使命和北極星。截至 2019 年 1 月，知乎已擁有超過 2。2 億使用者，共產出 1。3 億個回答。
知乎作為 PingCAP 的合作伙伴，同時也是 Flink 的深度使用者，在自己的實踐過程中開發了一套 TiDB 與 Flink 互動工具並貢獻給了開源社群：pingcap-incubator/TiBigData，主要包括瞭如下功能：
TiDB 作為 Flink Source Connector，用於批式同步資料。
TiDB 作為 Flink Sink Connector，基於 JDBC 實現。
Flink TiDB Catalog，可以在 Flink SQL 中直接使用 TiDB 的表，無需再次建立。
在 docker-compose 中進行嘗試
為了方便讀者更好的理解，我們在 https：//github。com/LittleFall/flink-tidb-rdw 中提供了一個基於 docker-compose 的 MySQL-Flink-TiDB 測試環境，供大家測試使用。
Flink TiDB 實時數倉 Slides 中提供了該場景下一個簡單的教程，包括概念解釋、程式碼示例、簡單原理以及一些注意事項，其中示例包括：
Flink SQL 簡單嘗試
利用 Flink 進行從 MySQL 到 TiDB 的資料匯入
雙流 Join
維表 Join
在啟動 docker-compose 後，可以透過 Flink SQL Client 來編寫並提交 Flink 任務，並透過 localhost：8081 來觀察任務執行情況。
如果大家對 Flink+TiDB 實時數倉方案有興趣、疑惑，或者在探索實踐過程中積累了想要分享的經驗，歡迎到 TiDB 社群（如 AskTUG）、Flink 社群（如 Flink 中文郵件）或透過我的郵件（qizhi@pingcap。com）進行探討。
參考閱讀
Flink 中文社群關於實時數倉概念及流上 Join 的討論：
基於 Flink 的典型 ETL 場景實現方案
［小紅書使用 TiDB 的實踐分享］（How We Use a Scale-Out HTAP Database for Real-TimeAnalytics and Complex Queries
https：//en。pingcap。com/case-studies/how-we-use-a-scale-out-htap-database-for-real-time-analytics-and-complex-queries）
［TiDB的 HTAP 架構以及在資料平臺上的應用］（How We Build an HTAP Database That Simplifies Your DataPlatform
https：//dzone。com/articles/how-we-build-an-htap-database-that-simplifies-your）
［TiDB 原理論文］（TiDB：A Raft-based HTAP Database
http：//www。vldb。org/pvldb/vol13/p3072-huang。pdf
）
［FlinkSQL CDC 上線！我們總結了 13 條生產實踐經驗］（https：//zhuanlan。zhihu。com/p/243187428
）
更多 Flink 技術交流可加入 Apache Flink 社群釘釘交流群：
版權宣告：
本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。
