基于StarRocks的實時數倉設計

高海峰，葉春明

(上海理工大學管理學院，上海 200090)

0 引言

當今社會，數字化、信息化和智能化已成為時代特征，數字經濟已成為經濟發展的必然支持。隨著5G時代的來臨，數字經濟成為新的發展動力，數字化轉型成為企業發展戰略的一個重要選擇。

IBM Marketing cloud的一份最新報告中指出“僅過去兩年就建立了今天90%的資料，每天建立2.5 億億字節，隨著新設備、傳感器和新技術的出現，數據增長率也會隨之加速。”

目前，我國已發展出一系列成熟的大數據基礎設施，批計算方面有基于Spark 計算的分布式集群，流計算方面有基于Storm 的分布式集群。大數據的存儲方面有基于融合型數據庫的TiDB，有基于MPP 架構的數據庫ClickHouse[1]，有基于Hadoop 的Hive 等等[2]。但是，由于技術迭代更新，各類運算與儲存設備層出不窮，我們在做集群模式的選型時，須遵循三方面的基本原則：集群的穩定性、數據處理的高效性和投資的合理性。應結合實際情況，采用相對成熟的更先進的技術，提高整體應用性能，并減少資源的浪費，提升整體的應用建設效能。

基于上述考慮，本文提出一種新型實時數倉設計方案，結合使用了基于StarRocks的存儲技術以及基于Flink的實時計算技術[3]，應用于數據中臺[4]相關領域的業務中，在性能以及吞吐量等方面都有明顯的提升。一方面，有效減少了整個集群中服務器節點的數量，進而節約了硬件資源的投入；另一方面，大幅提高了整體的計算性能。

1 Flink概述

Apache Flink 是一個較成熟的流計算技術，主要用于在無邊界和有邊界數據流上進行有狀態的計算。Flink 的兼容性以及擴展性都非常優秀，常見的集群環境中都可以運行Flink，計算的速度媲美內存計算的速度，計算的數據規模可以達到任意規模。

Apache Flink 功能非常強大，可以開發多種不同種類的應用[5]。它的主要特征包含：流批一體化、事件支持、精細的狀態管理以及精確一次的狀態一致性保障等。Flink不僅可以運行在多種資源管理框架上，包括YARN、Mesos、Kubernetes 等，也可以運行在裸機集群上。在高可用模式下，不存在單點故障的問題。事實證明，Flink 可以擴展到數千核心，其狀態可以達到TB 級別，且仍能保持高吞吐、低延遲的特點。全球各地，有非常多要求苛刻的流處理應用都運行在Flink上面。

Flink 是近兩年大數據計算領域的一顆新星。但是，在我國很多的大型互聯網企業中均有實際應用，如阿里、美團、京東等。本文對三種主流的開源流處理框架做對比[6]，具體如表1所示。

表1 3種主流的開源流處理框架的技術對比

基于以上的綜合比較分析，Flink 是一個設計優良的框架，低延遲、高性能、高吞吐是三個典型的特征，非常符合項目的選型特征，所以本文采用Flink 技術作為流計算支撐。

2 StarRocks概述

StarRocks 是一款高性能分析型數據倉庫，使用向量化、MPP 架構、可實時更新的列式存儲引擎等技術實現多維、實時、高并發的數據分析。StarRocks 既支持從各類實時和離線的數據源高效導入數據，也支持直接分析數據湖上各種格式的數據。同時StarRocks具備水平擴展，高可用，高可靠，易運維等特性。廣泛應用于實時數倉、OLAP 報表、數據湖分析等場景。

StarRocks 也是近兩年在大數據分析領域發展起來的一顆新星，但在國內許多大型互聯網企業的數倉建設中均有應用，本文對近幾年主流開源數倉技術作對比，具體如表2所示。

表2 ClickHouse和StarRocks的對比

綜合比較之下，StarRocks 是一個非常不錯的選擇，不僅性能出色，而且功能也非常強大，解決了很多傳統數倉架構的問題，所以這是本文采用StarRocks作為數倉的根本原因。

3 架構設計

3.1 整體架構設計

本項目的整體設計結合了分層架構[7]和功能模塊化[8]思路。模塊間采用標準接口的方式，便于升級替換，整體架構分為三層，具體如圖1所示。

圖1 系統整體架構圖

⑴數據采集層：支持多源異構數據的采集。包括：各類關系型數據庫、非關系型數據庫、日志平臺、統一數據采集工具等。

⑵數據處理層：與數據采集的源數據端進行對接，從而實現數據的多樣化處理。包括流計算、批計算等，并對外提供統一的數據查詢服務。

⑶數據應用層：基于數據處理層提供的統一數據查詢服務，提供多場景應用的支持。包括數據可視化分析、實時場景等。

3.2 實時數倉架構設計

在圖1 所示的系統整體架構圖基礎上，對實時鏈路以及數據倉庫等細節進行細化，遵循分層架構的原則，將數據處理層進一步拆分為兩層：數據處理層和數據存儲層，旨在突出Flink 的核心角色以及StarRocks 在數據存儲中的核心角色。實時數倉的架構設計，具體如圖2所示。

圖2 實時數倉架構圖

4 業務實現

圖3 所示為考勤業務場景數據處理的流程，技術選型[9]為Kafka+Flink+Redis+StarRocks。

圖3 考勤業務場景數據處理流程圖

Kafka 用于實時傳遞需要計算的數據，Flink 用于實時計算并將計算結果存儲于Redis 中，StarRocks 承擔數據倉庫的職責，包括ODS、DWD、DWS、ADS 層，并對外提供統一數據查詢服務。

4.1 數據采集

考勤數據實時寫入Kafka 集群，基于業務屬性和數據規模的考慮，對KafkaTopic 做了細化設計，具體如表3所示。

表3 KafkaTopic設計

4.2 數據處理

Flink計算的時間維度如表4所示。

表4 Flink計算的時間維度

考勤場景的數據范圍及計算要求如表5所示。

表5 考勤場景的數據范圍及計算要求

4.3 數據存儲

本文采用的存儲技術是StarRocks 集群，具體如圖4所示。

圖4 StarRocks的數據存儲

StarRocks 支持使用物化視圖來進行查詢加速。不同于一些同類產品的物化視圖需要異步和原表做數據同步，StarRocks 的物化視圖可以自動根據原表更新數據。只要原表數據發生變更，物化視圖的更新也同步完成，不需要額外的操作。

4.4 應用效果

根據本文的設計方案，集群部署了50 臺物理機，可以達到以下的性能要求：處理數據量50T/天，處理數據條數200億條/天。

經過多輪綜合驗證，具體的時延效果如表6所示。大幅節省了物理機的部署，降低了CPU 使用率，具體性能效果如表7所示。

表6 時延效果表

表7 性能效果表

基于StarRocks 的13 種查詢場景的性能效果，如表8所示。

表8 StarRocks性能效果表

120億數據規模下的性能效果，如圖5所示。

圖5 StarRocks與ClickHouse性能對比

從圖5 數據可見，StarRocks 的查詢性能明顯優于ClickHouse，這得益于StarRocks 針對HLL 查詢的性能優化。

5 結束語

本文面向解決傳統數倉架構的效率和吞吐量等問題，設計了高效的實時數倉架構，結合使用了Flink流計算技術及StarRocks 存儲技術。并結合企業內的考勤業務場景，實現了基于Kafka+Flink+Redis+StarRocks技術組合的系統升級上線。在減少一倍硬件資源投入的情況下，時延降低至原先的一半，數據處理吞吐性能提升至四倍以上，滿足了企業對于高并發、實時計算、低延遲和大數據存儲的需求，達到了降本增效的目的。