多點DMALL成立于2015年，是一站式全渠道數(shù)字零售解決方案服務(wù)商。數(shù)字化解構(gòu)重構(gòu)零售產(chǎn)業(yè)，提供端到端的商業(yè)SaaS解決方案。目前，多點DMALL已與120多家連鎖零售商、品牌商等達成合作，覆蓋四個國家和地區(qū)15000家門店，模式受到廣泛驗證。

多點大數(shù)據(jù)部門使用StarRocks逐步替代了Impala、Impala on Kudu、Apache Kylin等存儲引擎，實現(xiàn)了存儲引擎的收斂，簡化了實時數(shù)據(jù)處理鏈路，同時也能保障較高的查詢并發(fā)以及較低的響應延遲要求。

一、背景介紹

多點大數(shù)據(jù)部門為內(nèi)部業(yè)務(wù)研發(fā)團隊、數(shù)據(jù)分析師、外部用戶以及合作伙伴，提供了基礎(chǔ)的大數(shù)據(jù)產(chǎn)品、平臺服務(wù)，幫助零售企業(yè)解決了從基本的數(shù)據(jù)匯總管理、統(tǒng)一的數(shù)據(jù)計算應用、到各種場景下對數(shù)據(jù)的多模式使用的需求，可覆蓋零售企業(yè)絕大部分數(shù)據(jù)訴求。

技術(shù)層面，多點大數(shù)據(jù)部門基于Hadoop開源技術(shù)棧，并進行了部分二次開發(fā)后構(gòu)建起了以下的一個技術(shù)架構(gòu)全景圖。從下到上分為基礎(chǔ)設(shè)施層、數(shù)據(jù)源層、數(shù)據(jù)集成層、離線/實時計算層、集市層、分析存儲層、數(shù)據(jù)服務(wù)/應用層，數(shù)據(jù)開發(fā)、數(shù)據(jù)模型中心與運維管理層對各層提供支持。

基礎(chǔ)設(shè)施層：包括超大帶寬的專線網(wǎng)絡(luò);公有云、私有云、機房托管的混合云部署;

數(shù)據(jù)源層：包括企業(yè)OLTP數(shù)據(jù)庫、業(yè)務(wù)數(shù)據(jù)、日志數(shù)據(jù)、三方接入數(shù)據(jù);

數(shù)據(jù)集成層：DataBus是多點自研數(shù)據(jù)同步平臺，解決企業(yè)內(nèi)各業(yè)務(wù)線之間、跨企業(yè)組織之間以及跨行業(yè)的數(shù)據(jù)匯聚、融合等問題，將不同系統(tǒng)的數(shù)據(jù)相互打通，實現(xiàn)數(shù)據(jù)自由流動;

離線計算層：利用Hive/Spark高可擴展的批處理能力承擔離線數(shù)倉的ETL和數(shù)據(jù)模型加工;

實時計算層：利用Flink/Spark Streaming完成實時數(shù)據(jù)的ETL(包括維度擴充，多流Join，實時匯總)等;

離線/實時集市層：使用數(shù)倉分層模型構(gòu)建ODS(原始數(shù)據(jù)層)、DWD(數(shù)據(jù)明細層)、DWS(匯總層)、DIM(維度層)、DWT(主題層)、ADS(應用層)，并根據(jù)公司業(yè)務(wù)拆分不同的數(shù)據(jù)域;

分析存儲層：主要依賴Druid、ClickHouse、Impala on Kudu、Apache Kylin、Elasticsearch、HBase、MySQL、StarRocks提供OLAP查詢能力;

數(shù)據(jù)服務(wù)/應用層：該層通過提供BI分析產(chǎn)品、數(shù)據(jù)服務(wù)接口、營銷、報表類產(chǎn)品，向內(nèi)部運營人員、外部客戶、合作伙伴提供數(shù)據(jù)分析決策能力。

二、原有架構(gòu)痛點

上述架構(gòu)解決了多點絕大部分數(shù)據(jù)訴求，在整個架構(gòu)中，無論是基于Hive、Spark的離線計算，基于Flink、Spark Streaming的實時計算;基于HDFS、Kafka的存儲;基于數(shù)倉分層模型建設(shè)等方案都已基本成熟。但是在OLAP領(lǐng)域，無論是多點還是業(yè)界仍然處于百家爭鳴，各有所長的狀態(tài)。縱觀多點在OLAP引擎的探索實踐中，遇到了各種各樣的問題，總結(jié)起來如下：

2.1技術(shù)成本

由于上層業(yè)務(wù)場景復雜，各個場景的技術(shù)難點、核心點均不一樣。多點生活在整個技術(shù)架構(gòu)升級的過程中先后引入了HBase、Elasticsearch、Druid、ClickHouse、Impala on Kudu、Apache Kylin等OLAP引擎。但是隨著技術(shù)棧增多，技術(shù)曲線陡峭，沒有充足的資源進行多技術(shù)棧的維護，造成了比較高的技術(shù)成本。

2.2開發(fā)成本

多點的數(shù)據(jù)分析場景大致可以分為離線T+1更新分析場景、實時更新分析場景、固定維度分析場景。

2.2.1離線T+1更新的分析場景

例如多點的精細化用戶運營平臺，其核心的功能是基于用戶、消費、行為、設(shè)備等屬性，提供多維度篩選條件，并通過自定義條件實現(xiàn)用戶分層，便于進行精細化用戶運營。

針對數(shù)據(jù)更新為T+1的分析場景，原主要使用的分析引擎為ClickHouse。利用ClickHouse構(gòu)建“大寬表”模型，將事實表與維度表提前進行關(guān)聯(lián)，對外提供單表聚合的SQL查詢，以及通過構(gòu)建DWT主題寬表，提供Adhoc查詢;該場景面臨的問題是：雖然ClickHouse單表查詢強悍，但是Join能力不強，需要提前進行關(guān)聯(lián)，將多表關(guān)聯(lián)成單表，會存在額外的開發(fā)成本。

2.2.2實時更新分析場景

實時更新場景主要是實時監(jiān)控經(jīng)營的各項指標，如當前時間段內(nèi)的GMV、下單數(shù)量、妥投數(shù)量、指標達成、對比、環(huán)比等指標。為客戶的經(jīng)營決策提供更具備時效性的參考依據(jù)。

針對數(shù)據(jù)為實時(秒級)更新的場景，原主要使用Impala on Kudu引擎，采用Lambda架構(gòu)，基于相同的主鍵，將流式的預計算的結(jié)果數(shù)據(jù)、批計算的結(jié)果數(shù)據(jù)，基于相同的主鍵進行merge。

上述方案中的Flink AGG部分，該程序的功能包括窗口內(nèi)的預計算、多流Join等操作。當業(yè)務(wù)需求變更或者上游數(shù)據(jù)結(jié)構(gòu)變動的時候，需要升級Flink AGG程序，以及離線ETL的任務(wù)，類似于“煙囪式”的迭代開發(fā)，開發(fā)效率低下。資源消耗層面，在Flink里面做預計算，時間窗口的選取以及內(nèi)存占用之間也需要平衡。

2.2.3固定維度分析場景

固定維度的分析場景主要針對固化的、標準的業(yè)務(wù)場景進行分析，多維分析可以對以多維形式組織起來的數(shù)據(jù)進行上卷、下鉆、切片、切塊、旋轉(zhuǎn)等各種分析操作，以便剖析數(shù)據(jù)，使分析者、決策者能從多個角度、多個側(cè)面觀察數(shù)據(jù)倉庫中的數(shù)據(jù)，從而深入了解包含在數(shù)據(jù)中的信息和內(nèi)涵。

針對分析維度固定的分析場景，按照業(yè)務(wù)上常用的分析指標以及維度，此前使用Apache Kylin進行cube預計算。但是使用Apache Kylin也會遇到如下問題：

1)由于多點業(yè)務(wù)場景涉及的維度比較多，各種類目、營運組織的組合，會導致cube膨脹，占用比較多的存儲資源;

2)當數(shù)據(jù)重跑以及新增維度，指標的時候。針對已經(jīng)在線上運行的cube模型，為了保障數(shù)據(jù)重跑時候服務(wù)依然可用，需要新增cube模型，并行提供支持，造成存儲重復;

3)由于目前使用的Apache Kylin v3.1.2是使用HBase作為后端存儲，row key順序設(shè)計以及分區(qū)鍵的選擇會嚴重的影響查詢性能，對開發(fā)不友好。

2.3運維成本

多點作為一站式全渠道數(shù)字零售解決方案服務(wù)商，可以滿足客戶不同的接入部署需求。多點大數(shù)據(jù)產(chǎn)品系統(tǒng)的接入可以大致分為SaaS化接入、私有云以及本地化部署。針對私有云、本地化部署的客戶，OLAP引擎易部署、易維護、極簡的架構(gòu)尤其重要，像HBase、Impala on Kudu、Apache Kylin等強依賴Hadoop生態(tài)的OLAP引擎，會增加部署的復雜性;ClickHouse集群不能自動感知集群拓撲變化，也不能自動balance數(shù)據(jù)，會增加縮容、擴容等的維護成本。

三、選擇StarRocks的原因

多點大數(shù)據(jù)部門從2021年年初開始，在調(diào)研市面上常用的存儲引擎時發(fā)現(xiàn)了StarRocks。StarRocks架構(gòu)設(shè)計融合了MPP數(shù)據(jù)庫，以及分布式系統(tǒng)的設(shè)計思想，具備架構(gòu)精簡，支持全面向量化引擎、智能查詢優(yōu)化、高效更新、智能物化視圖、標準SQL、流批一體、高可用易擴展等特性，天然的解決了上述的問題。

3.1使用StarRocks的特性解決當前痛點

·引擎收斂

原有系統(tǒng)的多維分析，高并發(fā)查詢，預計算，實時分析，Adhoc查詢等場景下使用了多套系統(tǒng)，基本上可以使用一套StarRocks解決。多點大數(shù)據(jù)平臺、產(chǎn)品逐步形成以StarRocks為主，其他OLAP引擎為輔的存儲架構(gòu)，解決維護多套引擎的技術(shù)成本問題。

·使用星型、星座模型替代“大寬表”模型

StarRocks支持Broadcast Join、Colocate Join等分布式Join的特性，可以在查詢性能可接受的范圍內(nèi)，使用星型、星座模型替代“大寬表”模型，節(jié)約提前關(guān)聯(lián)的開發(fā)成本，同時針對事實表中歷史數(shù)據(jù)變更，需要重新“跑數(shù)”的場景，可以只重跑(OverWrite)部分表的數(shù)據(jù)，提高整體的“跑數(shù)”效率。

·簡化Lambda架構(gòu)中的預聚合部分

StarRocks支持明細、聚合、更新模型，可以基于StarRocks自帶預聚合的特性，優(yōu)化掉現(xiàn)有Lambda架構(gòu)的中的預聚合部分。

StarRocks直接拉取/訂閱Hive或者Kafka中的數(shù)據(jù)，在StarRocks中進行聚合運算;StarRocks的數(shù)據(jù)模型是Aggregate模型，通過MAX、SUM、MIN、BITMAP_UNION等聚合函數(shù)在StarRocks中進行預聚合。

·模型持續(xù)迭代

針對已在線上運行的模型，如果有需求上的變更，比如增加、刪除、變更字段，可以使用StarRocks簡單SQL命令動態(tài)地修改表的定義，在表結(jié)構(gòu)變更的過程中，線上的服務(wù)不受任何的影響。

·明細、匯總一體化

在實際的業(yè)務(wù)場景中，通常存在兩種場景并存的分析需求：對固定維度的聚合分析和對原始明細數(shù)據(jù)的查詢。在這種情況下，StarRocks支持對原表構(gòu)建物化視圖，數(shù)據(jù)更新的時候，物化視圖跟隨原表一起進行更新，保證數(shù)據(jù)的一致性。當用戶查詢時，并不感知物化視圖的存在，不必顯式的指定物化視圖的名稱，查詢優(yōu)化器可以根據(jù)查詢條件自動判斷是否可以路由到相應的物化視圖上。

·外表能力

StarRocks支持以外部表的形式，接入其他數(shù)據(jù)源包括MySQL、HDFS、Elasticsearch、Hive等。比如可以使用StarRocks建立Elasticsearch的外表，為Elasticsearch提供SQL查詢的能力。

3.2基于多點報表業(yè)務(wù)真實場景的性能測試

·單表聚合查詢

在現(xiàn)有的數(shù)據(jù)T+1更新的匯總業(yè)務(wù)場景中，選取了多點報表業(yè)務(wù)中的“單品銷售分析”場景進行測試，單表單天數(shù)據(jù)億級別，上百個維度和分析指標，屬于典型的基于“大寬表”的Adhoc查詢場景。在相同情況(機器配置、數(shù)據(jù)量、SQL)下進行ClickHouse對比StarRocks的性能測試：

橫坐標：分區(qū)(天)數(shù)-并發(fā)數(shù);縱坐標：響應時長(ms)

從查詢響應時長來看，單表的聚合查詢，ClickHouse與StarRocks的查詢響應時長相差不多。

·多表關(guān)聯(lián)查詢

在現(xiàn)有的數(shù)據(jù)T+1更新多表關(guān)聯(lián)的匯總分析業(yè)務(wù)場景中，選取了現(xiàn)在多點報表業(yè)務(wù)中的“門店銷售分析”場景進行測試，事實表單天數(shù)據(jù)億級別，多個維表數(shù)據(jù)量在十萬級別，屬于典型的高維分析場景。在相同情況(機器配置、數(shù)據(jù)量、SQL)下進行ClickHouse對比StarRocks的性能測試：

橫坐標：分區(qū)(天)數(shù)-并發(fā)數(shù);縱坐標：響應時長(ms)

從查詢響應時長來看，多表關(guān)聯(lián)聚合查詢，StarRocks的性能要優(yōu)于ClickHouse。

·實時更新讀寫查詢

在現(xiàn)有的數(shù)據(jù)準實時更新(邊寫邊讀)的匯總查詢業(yè)務(wù)場景中，選取了“實時銷售分析”場景進行測試，訂單數(shù)據(jù)實時更新，單天數(shù)據(jù)量億級別。屬于典型的“實時更新，實時查詢”場景。在相同情況(機器配置、數(shù)據(jù)量、SQL)下進行Impala on Kudu對比StarRocks的性能測試：

橫坐標：分區(qū)(天)數(shù)-并發(fā)數(shù);縱坐標：響應時長(ms)。

從查詢響應時長來看，在邊讀邊寫的情況下，聚合查詢的SQL，StarRocks的性能要優(yōu)于Impala on Kudu。

四、實踐經(jīng)驗

多點目前已經(jīng)在高維業(yè)務(wù)指標報表、Adhoc分析、實時全鏈路監(jiān)控等場景中引入了StarRocks，在使用中總結(jié)出以下經(jīng)驗：

4.1集群拆分

由于StarRocks極簡的架構(gòu)設(shè)計，易于運維部署。我們根據(jù)一定的規(guī)則，搭建了多套集群，避免業(yè)務(wù)之間的相互影響。

4.2按照數(shù)據(jù)更新頻率進行拆分

例如數(shù)據(jù)是T+1更新，且單表數(shù)據(jù)量在百億級別以上的場景(例如高維業(yè)務(wù)指標報表、Adhoc分析)，我們構(gòu)建了離線分析集群。通過提高StarRocks的查詢并發(fā)(parallel_fragment_exec_instance_num)、單節(jié)點內(nèi)存限制(exec_mem_limit)等對復雜查詢友好的參數(shù)，提高集群的查詢性能;

針對數(shù)據(jù)是準實時更新，寫多讀多的場景(實時報表、實時全鏈路監(jiān)控)，我們構(gòu)建了實時分析集群，通過調(diào)整StarRocks的compaction(cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk)等對寫入友好的參數(shù)，加快數(shù)據(jù)版本合并。

4.3按照業(yè)務(wù)域進行拆分

多點客戶的接入方式不同，且各種SLA要求也不同，會按照不同的需求搭建不同的StarRocks集群，盡量滿足多種客戶需求。

4.4調(diào)優(yōu)手段

針對在線服務(wù)、系統(tǒng)，為了提高系統(tǒng)整體的查詢性能，可以從不同的維度進行優(yōu)化：

4.4.1優(yōu)化表結(jié)構(gòu)定義

1)模型選擇

StarRocks的模型包括明細模型、聚合模型、更新模型。

如果需要對原始的數(shù)據(jù)(例如訂單流水，原始操作記錄等)來進行分析，可以選擇明細模型;

如果業(yè)務(wù)方進行的查詢?yōu)閰R總類查詢，比如SUM、COUNT、MAX等類型的查詢，可以選擇聚合模型，提前進行預聚合，查詢的時候直接獲取結(jié)果;

如果數(shù)據(jù)需要頻繁的進行狀態(tài)更新(比如訂單的狀態(tài)變更)，可以選擇更新模型。

2)分區(qū)(parition)和分桶(bucket)

StarRocks可以對表進行分區(qū)和分桶，分區(qū)在邏輯上把表劃分成了多個子表，可以按照時間進行分區(qū);分桶可以按照不同的策略將數(shù)據(jù)劃分為不同的tablet，分布在不同的BE節(jié)點上。按照目前多點大數(shù)據(jù)集群的機器配置(64C+256G+12TB SSD)，通常將一個tablet保持在200MB~1GB的大小，會有比較好的性能。

3)稀疏索引、bloomfilter、Bitmap Index

為了提高查詢的性能，可以對StarRocks的表結(jié)構(gòu)額外構(gòu)建索引。稀疏索引：可以將查詢中常見的過濾字段放在schema的前面，區(qū)分度越大，頻次越高的查詢字段越往前放;同時對區(qū)分度比較大的列構(gòu)建bloomfilter;對區(qū)分度不大的列構(gòu)建Bitmap Index。

4)物化視圖

針對實際查詢場景中經(jīng)常用到的查詢SQL，可以對原始表構(gòu)建物化視圖，其本質(zhì)為原始表(base table)的一個物化索引，通過物化視圖提前進行索引排序、指標預計算，查詢的時候自動路由到物化視圖進行查詢。

5)使用BITMAP/HyperLogLog數(shù)據(jù)類型進行去重

在交易場景中進行會計算交易次數(shù)，使用常規(guī)的方式(COUNT DISTRINCT order_id)去重，其缺點是需要消耗極大的計算和存儲資源，對大規(guī)模數(shù)據(jù)集和查詢延遲敏感的去重場景支持不夠友好。通過定義BITMAP的數(shù)據(jù)類型，可以減少傳統(tǒng)COUNT DISTINCT去重的執(zhí)行需要的內(nèi)存空間、執(zhí)行時長;而對于像流量統(tǒng)計場景中針對UV的計算，在允許有部分統(tǒng)計偏差的前提下，可以定義HyperLogLog的數(shù)據(jù)類型，提高去重效率。

4.4.2優(yōu)化查詢SQL

1)小表Join可以對使用Broadcast Join

當大表與小表進行Join的時候，可以使用Broadcast Join(StarRocks針對小表的默認Join方式)，小表向大表廣播的方式進行Join。該方式可以用于事實表與維度表進行關(guān)聯(lián)查詢;

2)大表Join可以使用Colocation Join

當大表與大表進行Join的時候，為了加速查詢，相關(guān)表可以采用共同的分桶列(colocate_with)進行分桶。當分桶列相同，相關(guān)表進行Join操作時，可以直接在本地進行Join，再將結(jié)果數(shù)據(jù)進行合并，避免數(shù)據(jù)在中間計算的時候就在集群中的傳輸。

3)并行度調(diào)整

當機器資源比較充裕時，可以將增加執(zhí)行并行度(parallel_fragment_exec_instance_num)，讓更多的執(zhí)行實例同時處理一組數(shù)據(jù)掃描，從而提升查詢效率。但是并行度設(shè)置為較大的數(shù)值會消耗更多的機器資源，如CPU、內(nèi)存、磁盤IO，影響整體的QPS。需要根據(jù)實際上的查詢場景來設(shè)置并行度，一般建議占用機器核數(shù)的50%。

4)CBO優(yōu)化器

針對復雜Ad-hoc場景，可以開啟StarRocks的基于成本(Cost-based Optimizer，CBO)的查詢規(guī)劃器，在眾多查詢計劃空間中快速找到最優(yōu)計劃，提高查詢優(yōu)化器。

4.5工具集成

為了與目前多點的大數(shù)據(jù)平臺進行打通，對StartRocks進行了一些集成封裝。

·數(shù)據(jù)集成

通過封裝StarRocks的Broker Load以及Stream Load接口，與多點的大數(shù)據(jù)平臺打通，實現(xiàn)通過配置的方式將數(shù)據(jù)從Hive批量同步到StarRocks，或者訂閱MQ將實時數(shù)據(jù)同步到StarRocks。

·監(jiān)控預警

通過集成Prometheus與Grafana，與監(jiān)控平臺打通。對多個StarRocks集群的運行情況進行監(jiān)控，當集群的某些指標超過一定閾值的時候進行報警。

五、總結(jié)與展望

多點從2021年上半年開始調(diào)研引入StarRocks，當前已有四個集群在穩(wěn)定運行提供線上服務(wù)，逐步替代了Impala、Impala on Kudu、Apache Kylin等存儲引擎，實現(xiàn)了存儲引擎的收斂，簡化了實時數(shù)據(jù)處理鏈路，同時也能保障較高的查詢并發(fā)以及較低的響應延遲要求。目前公司也在越來越多的業(yè)務(wù)中嘗試使用StarRocks。

在引擎引入以及切換的過程中，得到了StarRocks社區(qū)的大力支持。后續(xù)公司在有余力的情況下會參與StarRocks的社區(qū)共建，共同打造性能強悍的國產(chǎn)新一代MPP數(shù)據(jù)庫。(作者：任偉，多點生活大數(shù)據(jù)部門資深研發(fā)工程師)

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）