來電科技：基於 Flink + Hologres 的實時數倉演進之路

簡介： 本文將會講述共享充電寶開創企業來電科技如何基於 Flink + Hologres 構建統一數據服務加速的實時數倉。

做者：陳健新，來電科技數據倉庫開發工程師，目前專一於負責來電科技大數據平臺離線和實時架構的整合。

深圳來電科技有限公司（如下簡稱 「來電科技」）是共享充電寶行業開創企業，主要業務覆蓋充電寶自助租賃、定製商場導航機開發、廣告展現設備及廣告傳播等服務。來電科技擁有業內立體化產品線，大中小機櫃以及桌面型，目前全國超過 90% 的城市實現業務服務落地，註冊用戶超 2 億人，實現全場景用戶需求。

1、大數據平臺介紹

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. 取得成就

大數據平臺提供的能力給咱們帶來了很多成就，總結爲如下五點：

橫向擴展

大數據平臺的核心就是分佈式架構，這樣咱們可以低成本地水平擴展存儲或者計算資源。

資源共享

能夠整合全部服務器可用的資源。之前的架構是每一個業務部門本身維護一套集羣，這樣會形成一些浪費，難以保證可靠性，並且運費成本較高，如今由平臺統一調度。

數據共享

整合了業務部門全部的業務數據以及業務日誌等其餘異構數據源數據，由平臺統一清洗對接。

服務共享

數據共享以後就由平臺統一對外輸出服務，各個業務線無需自行重複開發，就能快速獲得平臺提供的數據支撐。

安全保障

由平臺提供統一的安全認證等受權機制，能夠作到對不一樣人進行不一樣程度的細粒度受權，保證數據安全。

2、企業業務對數據方面的需求

隨着業務的快速發展，構建統一的實時數倉迫在眉睫，綜合 0.x、1.0 版本的平臺架構，綜合業務的如今發展和將來趨勢判斷，構建 2.x 版本數據平臺的需求主要集中在如下幾個方面：

實時大屏

實時大屏須要替換舊的準實時大屏，採用更可靠、低延遲的技術方案。

統一數據服務

高性能、高併發和高可用的數據服務成爲企業數字化轉型統一數據門戶的關鍵，須要構建一個統一的數據門戶，統一對外輸出。

實時數倉

數據時效性在企業運營中的重要性日益凸現，須要響應更快更及時。

3、實時數倉和統一數據服務技術方案

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 完成，避免數據孤島產生的問題，或者一致性難以維護等，也加速了離線數據的分析。

4、具體實踐細節

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 系統來實現服務/分析一體化，避免數據孤島以及一致性、安全性等問題。

實時數倉

知足企業運營中對於數據時效性愈來愈高的要求，秒級響應。

5、將來規劃

伴隨着業務的迭代，咱們將來在大數據平臺的規劃主要有兩點：流批一體和完善實時數倉。

• 如今的大數據平臺總的來講仍是離線架構和實時架構混合，後續會廢棄冗餘的離線代碼架構，藉助 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 數倉；
• 支持對用戶組進行計算資源管理。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。