作者：陳健新，來電科技資料倉庫開發工程師，目前專注于負責來電科技大資料平台離線和實時架構的整合。
深圳來電科技有限公司（以下簡稱“來電科技”）是共享充電寶行業開創企業，主要業務覆寫充電寶自助租賃、定制商場導航機開發、廣告展示裝置及廣告傳播等服務。來電科技擁有業内立體化産品線，大中小機櫃以及桌面型，目前全國超過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的新方案，我們支撐了三大場景：
業務層面更高效地疊代多樣化需求，同時降低了開發、運維維護開銷。
通過一個HSAP系統來實作服務/分析一體化，避免資料孤島以及一緻性、安全性等問題。
滿足企業營運中對于資料時效性越來越高的要求，秒級響應。
五、未來規劃
伴随着業務的疊代，我們未來在大資料平台的規劃主要有兩點：流批一體和完善實時數倉。
- 現在的大資料平台總的來說還是離線架構和實時架構混合，後續會廢棄備援的離線代碼架構，借助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數倉；
- 支援對使用者組進行計算資源管理。