快狗叫車實時數倉演進之路

快狗叫車業務快速發展是公司眾多人員的努力，同時對資料側提出了更高的要求。資料的價值隨著時間的增加而降低，分析以及運營更加希望實時資料助力業務發展，研發也希望藉助BI側的大資料綜合計算能力得到彙總資料。

在這樣的基礎上，快狗叫車實時資料倉儲歷經兩次迭代，從Spark計算引擎到阿里雲Blink+Flink，從Hbase儲存到目前多樣式OLAP系統使用。本文將分享快狗叫車實時倉庫的發展和實踐。

▲快狗叫車實時資料倉儲負責人 楊錚

嘉賓介紹： 2019年加入快狗叫車，負責實時資料倉儲整體架構。畢業於山東理工大學，在離線和實時資料倉儲有豐富經驗，熱愛分散式相關技術，在OLAP，Flink，Spark等技術有較深理解。

分享大綱：

1、以往的開發流程和實時計算

2、從上雲開始轉變

3、解決痛點

4、應用

首先交代下，快狗叫車實時數倉的業務背景。業務的複雜度比較高，業務線比較多，各個業務線之間資料相互關聯，不相互獨立。流量比較大，目前有小程式、APP端、網頁、H5等，這些端產生的業務資料日增有幾TB，如果全部應用到實時數倉裡，對成本和計算都有壓力。

此外，實時資料的應用場景也比較多，比如駕駛艙、報表、應用於線上的智慧的調控等，這些場景對實時資料需求多。在業務發展初期時，也會面臨或多或少的問題，比如開發時長等。

以往的開發流程和實時計算

在歷史上，實時資料的開發流程如上圖所示。首先，需求同學提出需求到資料產品經理。然後，資料產品經理再把需求下發到開發同學身上。在業務發展的快速期，更多的是以應對需求和快速解決問題為主。

在開發時，會出現重複的任務，然後就形成了一系列問題。比如，煙囪式開發會導致任務堆積，任務的血緣變得混亂。在這個時候，我們逐步發現，運維成本和機器成本變得非常高，資料的複用性也很差。

關於實時計算的過程，從DS到kafka，然後Spark消費kafka的資料，繼而產生服務。這在當時來講，是一個非常簡單的流程。它的疊加歷史時期，也是一個業務快速發展的時期，我們在上面堆積了非常多的任務，從風控到流量，以及駕駛艙等一系列的任務。

我們發現，開發成本非常高，通用化模版應用少，功能越複雜，開發成本越高，大量時間在編碼設計上。早期Spark版本維護有困難，任務失敗修復重複資料帶來的高昂運維成本。另外，當時使用服務沒有節制，服務鏈路無監控，導致資料來源維護成本高。開發應用服務混亂，資料得不到統一，冗餘資料也越來越多。

從上雲開始轉變

從所有的離線數倉和實時數倉遷移上雲開始，我們決定做一次完整的改變。在2019年之前，我們使用Spark作為主流的處理引擎，加上多儲存的資料來源。資料服務大多來自於這些資料來源，比如，Mysql、ES等儲存引擎。

在2019年到2020年之間，我們完成了一次上雲，把整體的離線數倉和實時數倉都遷移到阿里雲上面。在這個時期，我們提出了兩點：一個是OneData，一個是OneService。

從2020年開始，我們開啟了智慧化系列。比如說，智慧調優、智慧運營等一系列的基於實時資料的智慧化操作。

解決痛點

在上雲的時候，以解決我們的痛點為主，煙囪式的開發，資料得不到複用，成本無限的增高，沒有合理的架構，當時是為了解決問題而存在，現在我們希望沉澱資料。

首先，第一點是模型升級，我們採取了大家認可的分層模型，為了擺脫混亂開發，建設分層模型，主要目的是讓資料重複利用。我們採取實時和離線完全相等的方案，這麼操作運維起來很方便。

我們嚴格按照離線模型，區分了幾個層面。第一是ODS基礎資料層，第二是DWS服務資料層，第三是DWF事實資料層，第四是DWA高度彙總資料層，第五是DIM維度資料層。

之前我們使用的是Spark，後來用到了Flink。上雲的基礎運用的是阿里云云原生，最開始是Flink，現在是全託管Flink，很少用到開源的Flink。從Spark遷移到Flink，很大的一部分原因是希望得到效率方面的巨大提升。

在ODS層面，我們已經做了一次格式的預處理。當時在架構設計方面實現離線實時一體化。RDS主要為Binlog訂閱，新增中間處理，統一資料格式。日誌資料是透過各個端上的日誌傳輸，統一規範，日誌中心格式處理。

上圖是資料一鍵整合圖，在這裡，只需要我們填寫DTS標識、庫名、表名、Topic，它就會自動的一鍵建立資料，並且自動轉化出來，把資料格式經過一次處理傳輸，直接轉發到kafka裡面。

一鍵配置平臺的資料訂閱工作，極大的節省了我們與DBA溝通把資料訂閱進來的操作流程。另外，建立Topic、刪除Topic、消費位點等一系列操作都可以在一鍵配置平臺上進行操作。自動格式化資料，方便後續做模版化的開發，不需要進行定製化開發。

關於開發模版的大致流程分為四步：

第一，Flink SQL讀取kafka資料來源格式固定，可變的是topic引數和讀取位點，group等;

第二，建立檢視，利用核心UDF統一離線和實時Schema資訊，任務啟動階段進行校驗兩方的shcema資訊(型別，名稱等)，嚴格一致;

第三，多流處理階段，一般無法定製模板，需要注意state，資源等;

第四，輸出階段，分為輸出至OLAP、Mysql、Kafka，輸出至Kafka利用核心UDF固定格式。

在資料流入和流出階段，進行嚴格的格式控制，利用通用模板提高效率，同時保持離線實時一致。

事實上，日誌處理是一個非常麻煩的過程，佔用大量的時間。所以，我們做了一次整合化的處理，做成了一個引數化配置的平臺，僅需傳入離線日誌表，任務自動獲取離線任務所有資訊，自動配置到實時任務。

它類似於一個動態規則的配置，自動建立topic，初步清洗好的日誌資料自動傳入topic，並且最佳化格式。此外，這個任務還具有資源最佳化功能，內部核心為任務清洗程式，配置後臺，根據任務資源，日誌資料切分任務，極大縮短開發時間。

在我們平滑上雲之後，用了三個主儲存系統。第一個是Hbase+ES，Hbase儲存資料+ES構建加速查詢索引。第二個是阿里雲ADB(雲原生資料倉儲)，同時也是即席分析平臺，支援存算分離、動態擴充套件、高併發等。第三個是我們與阿里雲共建的Hologres，主要使用的HOL AP系統，支援PB級別，支援高併發。

我們在Hologres用到讀寫分離的架構，Hologres支援實時+離線資料對映查詢，支援聯邦查詢，實時和離線資料混合使用。支援統一資料出口，無論是即席分析還是實時介面查詢等，資料出口均在Hologres。

應用

構建好實時資料倉儲之後，有哪些應用?

首先，對外提供應用介面。比如，Http介面，靈活性高，可擴充性強;採取表對映形式，可以解耦，無感知變更;介面監測，所有介面的響應時長，ip，查詢頻率等進行資源監控;平臺一站式開發，內部研發的介面管理平臺，上線介面從測試到上線達到分鐘級別;慢查詢監控，慢查詢及時監控預警。

介面開發平臺的介面配置為SQL開發，測試之後自動生成介面id，分鐘級別上線。目前介面規模300+個，平均查詢時長在毫秒級別。

在風控應用方面，業務資料經過訊息佇列裡面的消費，加工，然後傳輸到圖計算裡面，離線資料先把全量灌進去，然後實時的增量資料構建插入。這部分更多體現我們在風控和圖計算方面的內容。

關於指標預警，透過構建運營同學關注的指標，可以以自定義規則定製實時預警和離線預警方式，目前支援SQL和指標形式進行監控，小時級別和天級別的預警，智慧預警形式結合演算法，自動測算，實時預警。

OneData指標管理是實時指標和離線指標統一管理平臺，具備指標血緣、版本等各種管理功能。無論實時或者離線指標，首先是指標管理平臺收錄，再進行三方嵌入使用。

上圖是實時數倉整體架構圖，從ODS、DWS、DWF、DWA，經過FlinkSQL一層一層的加工，資料分別存入到Kafka/Holo，在往上進入到OneData、OneService，最後進入到應用體系。

展望未來，我們希望透過流批一體，達到一套系統，一個邏輯。目前來講，我們實現了實時資料離線資料相互統一，但是它仍然存在資料互動的問題。另外，它依然是兩套系統，務必存在系統之間的相互隔離。同時，我們正在做一套動態規則，智慧營銷，實現運營策略。