簡介：?本文將會講述共享充電寶開創企業來電科技如何基于 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 數倉；
• 支持對用戶組進行計算資源管理。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的来电科技：基于 Flink + Hologres 的实时数仓演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。