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