來電科技：基於 Flink + Hologres 的實時數倉演進之路
主要集中在以下幾個方面
簡介：
本文將會講述共享充電寶開創企業來電科技如何基於 Flink + Hologres 構建統一資料服務加速的實時數倉
作者：陳健新，來電科技資料倉庫開發工程師，目前專注於負責來電科技大資料平臺離線和實時架構的整合。
深圳來電科技有限公司（以下簡稱 “來電科技”）是共享充電寶行業開創企業，主要業務覆蓋充電寶自助租賃、定製商場導航機開發、廣告展示裝置及廣告傳播等服務。來電科技擁有業內立體化產品線，大中小機櫃以及桌面型，目前全國超過 90% 的城市實現業務服務落地，註冊使用者超 2 億人，實現全場景使用者需求。
一、大資料平臺介紹
1. 發展歷程
來電科技大資料平臺的發展歷程主要分為以下三個階段：
1）離散 0.X Greenplum
為什麼說離散？因為之前沒有一個統一的大資料平臺來支援資料服務，而是由每個業務開發線自行取數或者做一些計算，並用一個低配版的 Greenplum 離線服務來維持日常的資料需求。
2）離線 1.0 EMR
之後架構升級為離線 1。0 EMR，這裡的 EMR 指的是阿里雲由大資料組成的彈性分散式混合叢集服務，包括 Hadoop、HiveSpark 離線計算等常見元件。
阿里雲 EMR 主要解決我們三個痛點：
一是儲存計算資源的水平可擴充套件；
二是解決了前面各個業務線異構資料帶來的開發維護問題，由平臺統一清洗入倉；
三是我們可以建立自己的數倉分層體系，劃分一個主題域，為我們的指標系統打好基礎。
3）實時、統一 2.0 Flink + Hologres
當前正經歷的 “Flink + Hologres” 實時數倉，這也是本文分享的核心。它為我們大資料平臺帶來了兩個質的改變，一是實時計算，二是統一資料服務。基於這兩點，我們加速知識資料探索，促進業務快速發展。
2. 平臺能力
總的概括來說，2。0 版本的大資料平臺提供了以下能力：
資料整合
平臺現在支援使用實時或者離線的方式整合業務資料庫或業務資料的日誌。
資料開發
平臺現已支援基於 Spark 的離線計算以及基於 Flink 的實時計算。
資料服務
資料服務主要由兩部分組成：一部分是由 Impala 提供的分析服務和即席分析的能力；另一部分是 Hologres 提供的針對業務資料的互動式分析能力。
資料應用
同時平臺可以直接對接常見的 BI 工具，業務系統也能快速地整合對接。
3. 取得成就
大資料平臺提供的能力給我們帶來了不少成就，總結為以下五點：
橫向擴充套件
大資料平臺的核心就是分散式架構，這樣我們能夠低成本地水平擴充套件儲存或者計算資源。
資源共享
可以整合所有伺服器可用的資源。以前的架構是每個業務部門自己維護一套叢集，這樣會造成一些浪費，難以保證可靠性，而且運費成本較高，現在由平臺統一排程。
資料共享
整合了業務部門所有的業務資料以及業務日誌等其他異構資料來源資料，由平臺統一清洗對接。
服務共享
資料共享之後就由平臺統一對外輸出服務，各個業務線無需自行重複開發，就能快速得到平臺提供的資料支撐。
安全保障
由平臺提供統一的安全認證等授權機制，可以做到對不同人進行不同程度的細粒度授權，保證資料安全。
二、企業業務對資料方面的需求
隨著業務的快速發展，構建統一的實時數倉迫在眉睫，綜合 0。x、1。0 版本的平臺架構，綜合業務的現在發展和未來趨勢判斷，構建 2。x 版本資料平臺的需求主要集中在以下幾個方面：
實時大屏
實時大屏需要替換舊的準實時大屏，採用更可靠、低延遲的技術方案。
統一資料服務
高效能、高併發和高可用的資料服務成為企業數字化轉型統一資料門戶的關鍵，需要構建一個統一的資料門戶，統一對外輸出。
實時數倉
資料時效性在企業運營中的重要性日益凸現，需要響應更快更及時。
三、實時數倉和統一資料服務技術方案
1. 整體技術架構
技術架構主要分為四個部分，分別是資料 ETL、實時數倉、離線數倉和資料應用。
資料 ETL 是對業務資料庫和業務日誌進行實時處理，統一使用 Flink 實時計算，
實時數倉中資料實時處理後進入 Hologres 儲存與分析
業務冷資料儲存在 Hive 離線數倉，並同步到 Hologres 做進一步的資料分析處理
由 Hologres 統一對接常用的 BI 工具，如 Tableau、Quick BI、DataV 和業務系統等。
2. 實時數倉資料模型
如上所示，實時數倉和離線數倉有一些相似的地方，只不過少一些其它層的鏈路。
第一層是原始資料層，資料來源有兩種型別，一種是業務庫的 Binlog，第二種是伺服器的業務日誌，統一用 Kafka 作為儲存介質。
第二層是資料明細層，將原始資料層 Kafka 裡面的資訊進行 ETL 提取，作為實時明細儲存至 Kafka。這樣做的目的是為了方便下游不同消費者同時訂閱，同時方便後續應用層的使用。維表資料也是透過 Hologres 儲存，來滿足下面的資料關聯或者條件過濾。
第三是資料應用層，這裡除了打通 Hologres，還使用了 Hologres 對接了 Hive，由 Hologres 統一提供上層應用服務。
3. 整體技術架構資料流
下面的資料流圖可以具象加深整體架構的規劃和數倉模型整體的資料流向。
從圖中可以看出，主要分為三個模組：
第一個是整合處理；
第二個是實時數倉；
第三塊是資料應用。
從資料的流入流出看到主要的核心有兩點：
第一個核心是 Flink 的實時計算：可以從 Kafka 獲取，或者直接 Flink cdt 讀取 MySQL Binlog 資料，或者直接再寫回 Kafka 叢集，這是一個核心。
第二個核心是統一資料服務：現在統一資料服務是由 Hologres 完成，避免資料孤島產生的問題，或者一致性難以維護等，也加速了離線資料的分析。
四、具體實踐細節
1. 大資料技術選型
方案執行分為兩個部分：實時與服務分析。實時方面我們選擇了阿里雲 Flink 全託管的方式，它主要有以下幾方面優點：
狀態管理與容錯機制；
Table API 和 Flink SQL 支援；
高吞吐低延遲；
Exactly Once 語義支援；
流批一體；
全託管等增值服務。
服務分析方面我們選擇了阿里雲 Hologres 互動式分析，它帶來了幾點好處：
極速響應分析；
高併發讀寫；
計算儲存分離；
簡單易用。
2. 實時大屏業務實踐落地
上圖為業務實時大屏新舊方案對比。
以訂單為例，舊方案中的訂單是從訂單從庫透過 DTS 同步到另一個數據庫，這雖然是實時的，但是在計算與處理這方面，主要是透過定時任務，比如排程間隔時間設為 1 分鐘或者 5 分鐘來完成資料的實時更新，而銷售層、管理層需要更實時地掌握業務動態，，因此並不能算真正意義上的實時。除此之外，響應慢且不穩定也是很大的問題。
新方案採用的是 Flink 實時計算 + Hologres 架構。
開發方式完全是可以利用 Flink 的 SQL 支援，對於我們之前的 MySQL 計算開發方式，可以說是一個無縫的遷移，實現快速落地。資料分析和服務統一使用 Hologres。還是以訂單為例，比如今日訂單營收額，今日訂單使用者數或者今日訂單使用者量，隨著業務多樣性的增加，可能需要增加城市維度。透過 Hologres 的分析能力，可以完美支撐營收額、訂單量、訂單使用者數以及城市維度的一些指標做快速展示。
3. 實時數倉和統一資料服務實踐落地
以某塊業務場景為例，比如量級比較大的業務日誌，日均資料量在 TB 級別。下面先來分析一下舊方案的痛點：
資料時效性差：
由於資料量較大，所以在舊方案中使用了每小時離線排程的策略進行資料計算。但是該方案時效性較差，無法滿足眾多業務產品的實時需求，例如硬體系統需要實時知道裝置當前狀態，如告警、錯誤、空倉等，以及時做出相應的決策行動。
資料孤島：
舊方案使用 Tableau 對接大量業務報表，報表用於分析過去一個小時或者過去一天，裝置上報有多少數量，哪些裝置上報出現異常等。針對不同的場景，會將之前透過 Spark 離線計算的資料，再備份儲存到 MySQL 或者 Redis 上。這樣就多套系統，形成資料孤島，這些資料孤島對平臺維護是一個巨大的挑戰。
現在透過 2。0 Flink+Hologres 架構，可以將業務日誌進行改造。
以前 TB 級別的日誌量在 Flink 高分子低延遲的計算框架下完全沒有壓力。例如之前的 flume HDFS 到 Spark 的一個鏈路直接被廢棄，取而代之的是 Flink，我們只需要維護一個 Flink 的計算框架即可。
裝置狀態資料採集的時候都是一些非結構的資料，需要對資料進行清洗，之後再返回 Kafka，因為消費者可能是多樣化的，這樣可以方便下游的多個消費者同時訂閱。
在剛才的場景中，硬體系統需要高併發、實時查詢上千萬的裝置（充電寶）狀態，對服務能力的要求較高。透過 Hologres 提供高併發讀寫能力，關聯狀態裝置建立主鍵表，可以實時更新狀態，滿足 CRM 系統對裝置（充電寶）的實時查詢。
同時在 Hologres 還會存最近的熱點明細資料，直接提供對外服務。
4. 業務支撐效果
透過 Flink+Hologres 的新方案，我們支撐了三大場景：
實時大屏
業務層面更高效地迭代多樣化需求，同時降低了開發、運維維護開銷。
統一資料服務
透過一個 HSAP 系統來實現服務/分析一體化，避免資料孤島以及一致性、安全性等問題。
實時數倉
滿足企業運營中對於資料時效性越來越高的要求，秒級響應。
五、未來規劃
伴隨著業務的迭代，我們未來在大資料平臺的規劃主要有兩點：流批一體和完善實時數倉。
現在的大資料平臺總的來說還是離線架構和實時架構混合，後續會廢棄冗餘的離線程式碼架構，藉助 Flink 的流批一體統一計算引擎。
另外，我們目前只遷移了部分業務，所以會參考之前已經完善的離線數倉指標系統體系，來滿足我們現在的實時數倉建設，全面遷移到 2。0 Flink + Hologres 架構上。
透過未來的規劃，我們希望同 Flink 全託管和 Hologres 一起共建更加完善的實時數倉，但也在此對其有著更近一步的需求：
1. 對 Flink 全託管的需求
Flink 全託管中的 SQL 編輯器編寫 FlinkSQL 作業很高效方便，並且也提供了很多常見的 SQL 上下游 Connector 滿足開發需求。但是仍有一些需求希望Flink全託管在後續的迭代中支援：
SQL 作業版本控制和相容性監測；
SQL 作業支援 Hive3。X 整合；
DataStream 作業打包更方便、資源包上傳速度更快；
Session 叢集模式部署的任務支援自動調優功能。
2. 對 Hologres 互動式分析的需求
Hologres 不僅能夠支援高併發地實時寫入和查詢，並且相容 PostgreSQL 生態，方便接入使用統一資料服務。但是仍有一些需求希望 Hologres 能在後期迭代中支援：
支援熱升級操作，減少對業務的影響；
支援資料表備份、支援讀寫分離；
支援加速查詢阿里雲 EMR-Hive 數倉；
支援對使用者組進行計算資源管理。