簡介： 本文將會講述共享充電寶開創(chuàng)企業(yè)來電科技如何基于Flink+Hologres構建統(tǒng)一數(shù)據(jù)服務加速的實時數(shù)倉

作者：陳健新，來電科技數(shù)據(jù)倉庫開發(fā)工程師，目前專注于負責來電科技大數(shù)據(jù)平臺離線和實時架構的整合。

?

深圳來電科技有限公司（以下簡稱“來電科技”）是共享充電寶行業(yè)開創(chuàng)企業(yè)，主要業(yè)務覆蓋充電寶自助租賃、定制商場導航機開發(fā)、廣告展示設備及廣告?zhèn)鞑サ确铡黼娍萍紦碛袠I(yè)內(nèi)立體化產(chǎn)品線，大中小機柜以及桌面型，目前全國超過90%的城市實現(xiàn)業(yè)務服務落地，注冊用戶超2億人，實現(xiàn)全場景用戶需求。

一、大數(shù)據(jù)平臺介紹

（一）發(fā)展歷程

來電科技大數(shù)據(jù)平臺的發(fā)展歷程主要分為以下三個階段：

1.離散0.X Greenplum

為什么說離散？因為之前沒有一個統(tǒng)一的大數(shù)據(jù)平臺來支持數(shù)據(jù)服務，而是由每個業(yè)務開發(fā)線自行取數(shù)或者做一些計算，并用一個低配版的Greenplum離線服務來維持日常的數(shù)據(jù)需求。

2.離線1.0 EMR

之后架構升級為離線1.0 EMR，這里的EMR指的是阿里云由大數(shù)據(jù)組成的彈性分布式混合集群服務，包括Hadoop、HiveSpark離線計算等常見組件。

阿里云EMR主要解決我們?nèi)齻€痛點：一是存儲計算資源的水平可擴展；二是解決了前面各個業(yè)務線異構數(shù)據(jù)帶來的開發(fā)維護問題，由平臺統(tǒng)一清洗入倉；三是我們可以建立自己的數(shù)倉分層體系，劃分一個主題域，為我們的指標系統(tǒng)打好基礎。

3.實時、統(tǒng)一 2.0 Flink+Hologres

當前正經(jīng)歷的“Flink+Hologres”實時數(shù)倉，這也是本文分享的核心。它為我們大數(shù)據(jù)平臺帶來了兩個質(zhì)的改變，一是實時計算，二是統(tǒng)一數(shù)據(jù)服務。基于這兩點，我們加速知識數(shù)據(jù)探索，促進業(yè)務快速發(fā)展。

（二）平臺能力

總的概括來說，2.0版本的大數(shù)據(jù)平臺提供了以下能力：

1）數(shù)據(jù)集成

平臺現(xiàn)在支持使用實時或者離線的方式集成業(yè)務數(shù)據(jù)庫或業(yè)務數(shù)據(jù)的日志。

2）數(shù)據(jù)開發(fā)

平臺現(xiàn)已支持基于Spark的離線計算以及基于Flink的實時計算。

3）數(shù)據(jù)服務

數(shù)據(jù)服務主要由兩部分組成：一部分是由Impala提供的分析服務和即席分析的能力，另一部分是Hologres提供的針對業(yè)務數(shù)據(jù)的交互式分析能力。

4）數(shù)據(jù)應用

同時平臺可以直接對接常見的BI工具，業(yè)務系統(tǒng)也能快速地集成對接。

?

（三）取得成就

大數(shù)據(jù)平臺提供的能力給我們帶來了不少成就，總結為以下五點：

1）橫向擴展

大數(shù)據(jù)平臺的核心就是分布式架構，這樣我們能夠低成本地水平擴展存儲或者計算資源。

2）資源共享

可以整合所有服務器可用的資源。以前的架構是每個業(yè)務部門自己維護一套集群，這樣會造成一些浪費，難以保證可靠性，而且運費成本較高，現(xiàn)在由平臺統(tǒng)一調(diào)度。

3）數(shù)據(jù)共享

整合了業(yè)務部門所有的業(yè)務數(shù)據(jù)以及業(yè)務日志等其他異構數(shù)據(jù)源數(shù)據(jù)，由平臺統(tǒng)一清洗對接。

4）服務共享

數(shù)據(jù)共享之后就由平臺統(tǒng)一對外輸出服務，各個業(yè)務線無需自行重復開發(fā)，就能快速得到平臺提供的數(shù)據(jù)支撐。

5）安全保障

由平臺提供統(tǒng)一的安全認證等授權機制，可以做到對不同人進行不同程度的細粒度授權，保證數(shù)據(jù)安全。

二、企業(yè)業(yè)務對數(shù)據(jù)方面的需求

隨著業(yè)務的快速發(fā)展，構建統(tǒng)一的實時數(shù)倉迫在眉睫，綜合0.x、1.0版本的平臺架構，綜合業(yè)務的現(xiàn)在發(fā)展和未來趨勢判斷，構建2.x版本數(shù)據(jù)平臺的需求主要集中在以下幾個方面：

1）實時大屏

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

2）統(tǒng)一數(shù)據(jù)服務

高性能、高并發(fā)和高可用的數(shù)據(jù)服務成為企業(yè)數(shù)字化轉型統(tǒng)一數(shù)據(jù)門戶的關鍵，需要構建一個統(tǒng)一的數(shù)據(jù)門戶，統(tǒng)一對外輸出。

3）實時數(shù)倉

數(shù)據(jù)時效性在企業(yè)運營中的重要性日益凸現(xiàn)，需要響應更快更及時。

三、實時數(shù)倉和統(tǒng)一數(shù)據(jù)服務技術方案

（一）整體技術架構

技術架構主要分為四個部分，分別是數(shù)據(jù)ETL、實時數(shù)倉、離線數(shù)倉和數(shù)據(jù)應用。

• 數(shù)據(jù)ETL是對業(yè)務數(shù)據(jù)庫和業(yè)務日志進行實時處理，統(tǒng)一使用Flink實時計算，
• 實時數(shù)倉中數(shù)據(jù)實時處理后進入Hologres存儲與分析
• 業(yè)務冷數(shù)據(jù)存儲在Hive離線數(shù)倉，并同步到Hologres做進一步的數(shù)據(jù)分析處理
• 由Hologres統(tǒng)一對接常用的 BI工具，如Tableau、Quick BI、DataV和業(yè)務系統(tǒng)等。

?

（二）實時數(shù)倉數(shù)據(jù)模型

如上所示，實時數(shù)倉和離線數(shù)倉有一些相似的地方，只不過少一些其它層的鏈路。

• 第一層是原始數(shù)據(jù)層，數(shù)據(jù)來源有兩種類型，一種是業(yè)務庫的Binlog，第二種是服務器的業(yè)務日志，統(tǒng)一用Kafka作為存儲介質(zhì)。
• 第二層是數(shù)據(jù)明細層，將原始數(shù)據(jù)層Kafka里面的信息進行ETL提取，作為實時明細存儲至Kafka。這樣做的目的是為了方便下游不同消費者同時訂閱，同時方便后續(xù)應用層的使用。維表數(shù)據(jù)也是通過Hologres存儲，來滿足下面的數(shù)據(jù)關聯(lián)或者條件過濾。
• 第三是數(shù)據(jù)應用層，這里除了打通Hologres，還使用了Hologres對接了Hive，由Hologres統(tǒng)一提供上層應用服務。

（三）整體技術架構數(shù)據(jù)流

下面的數(shù)據(jù)流圖可以具象加深整體架構的規(guī)劃和數(shù)倉模型整體的數(shù)據(jù)流向。

從圖中可以看出，主要分為三個模塊，第一個是集成處理，第二個是實時數(shù)倉，第三塊是數(shù)據(jù)應用。

從數(shù)據(jù)的流入流出看到主要的核心有兩點：

• 第一個核心是Flink的實時計算：可以從Kafka獲取，或者直接Flink cdt讀取MySQL Binlog數(shù)據(jù)，或者直接再寫回Kafka集群，這是一個核心。
• 第二個核心是統(tǒng)一數(shù)據(jù)服務：現(xiàn)在統(tǒng)一數(shù)據(jù)服務是由Hologres完成，避免數(shù)據(jù)孤島產(chǎn)生的問題，或者一致性難以維護等，也加速了離線數(shù)據(jù)的分析。

?

四、具體實踐細節(jié)

（一）大數(shù)據(jù)技術選型

方案執(zhí)行分為兩個部分：實時與服務分析。實時方面我們選擇了阿里云Flink全托管的方式，它主要有以下幾方面優(yōu)點：

1）狀態(tài)管理與容錯機制；

2）Table API和Flink SQL支持；

3）高吞吐低延遲；

4）Exactly Once語義支持；

5）流批一體；

6）全托管等增值服務。

服務分析方面我們選擇了阿里云Hologres交互式分析，它帶來了幾點好處：

1）極速響應分析；

2）高并發(fā)讀寫；

3）計算存儲分離；

4）簡單易用。

?

（二）實時大屏業(yè)務實踐落地

?

上圖為業(yè)務實時大屏新舊方案對比。

以訂單為例，舊方案中的訂單是從訂單從庫通過DTS同步到另一個數(shù)據(jù)庫，這雖然是實時的，但是在計算與處理這方面，主要是通過定時任務，比如調(diào)度間隔時間設為1分鐘或者5分鐘來完成數(shù)據(jù)的實時更新，而銷售層、管理層需要更實時地掌握業(yè)務動態(tài)，，因此并不能算真正意義上的實時。除此之外，響應慢且不穩(wěn)定也是很大的問題。

新方案采用的是Flink實時計算+Hologres架構。

開發(fā)方式完全是可以利用Flink的SQL支持，對于我們之前的MySQL計算開發(fā)方式，可以說是一個無縫的遷移，實現(xiàn)快速落地。數(shù)據(jù)分析和服務統(tǒng)一使用Hologres。還是以訂單為例，比如今日訂單營收額，今日訂單用戶數(shù)或者今日訂單用戶量，隨著業(yè)務多樣性的增加，可能需要增加城市維度。通過Hologres的分析能力，可以完美支撐營收額、訂單量、訂單用戶數(shù)以及城市維度的一些指標做快速展示。

?

（三）實時數(shù)倉和統(tǒng)一數(shù)據(jù)服務實踐落地

?

以某塊業(yè)務場景為例，比如量級比較大的業(yè)務日志，日均數(shù)據(jù)量在TB級別。下面先來分析一下舊方案的痛點：

• 數(shù)據(jù)時效性差：由于數(shù)據(jù)量較大，所以在舊方案中使用了每小時離線調(diào)度的策略進行數(shù)據(jù)計算。但是該方案時效性較差，無法滿足眾多業(yè)務產(chǎn)品的實時需求，例如硬件系統(tǒng)需要實時知道設備當前狀態(tài)，如告警、錯誤、空倉等，以及時做出相應的決策行動。
• 數(shù)據(jù)孤島：舊方案使用Tableau對接大量業(yè)務報表，報表用于分析過去一個小時或者過去一天，設備上報有多少數(shù)量，哪些設備上報出現(xiàn)異常等。針對不同的場景，會將之前通過Spark離線計算的數(shù)據(jù)，再備份存儲到MySQL或者Redis上。這樣就多套系統(tǒng)，形成數(shù)據(jù)孤島，這些數(shù)據(jù)孤島對平臺維護是一個巨大的挑戰(zhàn)。

?

現(xiàn)在通過2.0 Flink+Hologres架構，可以將業(yè)務日志進行改造。

• 以前TB級別的日志量在Flink高分子低延遲的計算框架下完全沒有壓力。例如之前的flume HDFS到Spark的一個鏈路直接被廢棄，取而代之的是Flink，我們只需要維護一個Flink的計算框架即可。
• 設備狀態(tài)數(shù)據(jù)采集的時候都是一些非結構的數(shù)據(jù)，需要對數(shù)據(jù)進行清洗，之后再返回Kafka，因為消費者可能是多樣化的，這樣可以方便下游的多個消費者同時訂閱。
• 在剛才的場景中，硬件系統(tǒng)需要高并發(fā)、實時查詢上千萬的設備（充電寶）狀態(tài)，對服務能力的要求較高。通過Hologres提供高并發(fā)讀寫能力，關聯(lián)狀態(tài)設備建立主鍵表，可以實時更新狀態(tài)，滿足CRM系統(tǒng)對設備（充電寶）的實時查詢。
• 同時在Hologres還會存最近的熱點明細數(shù)據(jù)，直接提供對外服務。

（四）業(yè)務支撐效果

通過Flink+Hologres的新方案，我們支撐了三大場景：

1）實時大屏

業(yè)務層面更高效地迭代多樣化需求，同時降低了開發(fā)、運維維護開銷。

2）統(tǒng)一數(shù)據(jù)服務

通過一個HSAP系統(tǒng)來實現(xiàn)服務/分析一體化，避免數(shù)據(jù)孤島以及一致性、安全性等問題。

3）實時數(shù)倉

滿足企業(yè)運營中對于數(shù)據(jù)時效性越來越高的要求，秒級響應。

五、未來規(guī)劃

伴隨著業(yè)務的迭代，我們未來在大數(shù)據(jù)平臺的規(guī)劃主要有兩點：流批一體和完善實時數(shù)倉。

• 現(xiàn)在的大數(shù)據(jù)平臺總的來說還是離線架構和實時架構混合，后續(xù)會廢棄冗余的離線代碼架構，借助Flink的流批一體統(tǒng)一計算引擎。
• 另外，我們目前只遷移了部分業(yè)務，所以會參考之前已經(jīng)完善的離線數(shù)倉指標系統(tǒng)體系，來滿足我們現(xiàn)在的實時數(shù)倉建設，全面遷移到2.0 Flink+Hologres架構上。

通過未來的規(guī)劃，我們希望同F(xiàn)link全托管和Hologres一起共建更加完善的實時數(shù)倉，但也在此對其有著更近一步的需求：

（一）對Flink全托管的需求

Flink全托管中的SQL編輯器編寫FlinkSQL作業(yè)很高效方便，并且也提供了很多常見的SQL上下游 Connector滿足開發(fā)需求。但是仍有一些需求希望Flink全托管在后續(xù)的迭代中支持：

• SQL作業(yè)版本控制和兼容性監(jiān)測；
• SQL作業(yè)支持Hive3.X集成；
• DataStream作業(yè)打包更方便、資源包上傳速度更快；
• Session集群模式部署的任務支持自動調(diào)優(yōu)功能。

?

（二）對Hologres交互式分析的需求

Hologres不僅能夠支持高并發(fā)地實時寫入和查詢，并且兼容PostgreSQL生態(tài)，方便接入使用統(tǒng)一數(shù)據(jù)服務。但是仍有一些需求希望Hologres能在后期迭代中支持：

• 支持熱升級操作，減少對業(yè)務的影響；
• 支持數(shù)據(jù)表備份、支持讀寫分離；
• 支持加速查詢阿里云EMR-Hive數(shù)倉；
• 支持對用戶組進行計算資源管理。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載。

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。