多點DMALL成立于2015年，是一站式全渠道數字零售解決方案服務商。數字化解構重構零售產業，提供端到端的商業SaaS解決方案。目前，多點DMALL已與120多家連鎖零售商、品牌商等達成合作，覆蓋四個國家和地區15000家門店，模式受到廣泛驗證。
多點大數據部門使用StarRocks逐步替代了Impala、Impala on Kudu、Apache Kylin等存儲引擎，實現了存儲引擎的收斂，簡化了實時數據處理鏈路，同時也能保障較高的查詢并發以及較低的響應延遲要求。
一、背景介紹
多點大數據部門為內部業務研發團隊、數據分析師、外部用戶以及合作伙伴，提供了基礎的大數據產品、平臺服務，幫助零售企業解決了從基本的數據匯總管理、統一的數據計算應用、到各種場景下對數據的多模式使用的需求，可覆蓋零售企業絕大部分數據訴求。
技術層面，多點大數據部門基于Hadoop開源技術棧，并進行了部分二次開發后構建起了以下的一個技術架構全景圖。從下到上分為基礎設施層、數據源層、數據集成層、離線/實時計算層、集市層、分析存儲層、數據服務/應用層，數據開發、數據模型中心與運維管理層對各層提供支持。
基礎設施層：包括超大帶寬的專線網絡；公有云、私有云、機房托管的混合云部署；
數據源層：包括企業OLTP數據庫、業務數據、日志數據、三方接入數據；
數據集成層：DataBus是多點自研數據同步平臺，解決企業內各業務線之間、跨企業組織之間以及跨行業的數據匯聚、融合等問題，將不同系統的數據相互打通，實現數據自由流動；
離線計算層：利用Hive/Spark高可擴展的批處理能力承擔離線數倉的ETL和數據模型加工；
實時計算層：利用Flink/Spark Streaming完成實時數據的ETL（包括維度擴充，多流Join，實時匯總）等；
離線/實時集市層：使用數倉分層模型構建ODS（原始數據層）、DWD（數據明細層）、DWS（匯總層）、DIM（維度層）、DWT（主題層）、ADS（應用層），并根據公司業務拆分不同的數據域；
分析存儲層：主要依賴Druid、ClickHouse、Impala on Kudu、Apache Kylin、Elasticsearch、HBase、MySQL、StarRocks提供OLAP查詢能力；
數據服務/應用層：該層通過提供BI分析產品、數據服務接口、營銷、報表類產品，向內部運營人員、外部客戶、合作伙伴提供數據分析決策能力。
二、原有架構痛點
上述架構解決了多點絕大部分數據訴求，在整個架構中，無論是基于Hive、Spark的離線計算，基于Flink、Spark Streaming的實時計算；基于HDFS、Kafka的存儲；基于數倉分層模型建設等方案都已基本成熟。但是在OLAP領域，無論是多點還是業界仍然處于百家爭鳴，各有所長的狀態。縱觀多點在OLAP引擎的探索實踐中，遇到了各種各樣的問題，總結起來如下：
2.1技術成本
由于上層業務場景復雜，各個場景的技術難點、核心點均不一樣。多點生活在整個技術架構升級的過程中先后引入了HBase、Elasticsearch、Druid、ClickHouse、Impala on Kudu、Apache Kylin等OLAP引擎。但是隨著技術棧增多，技術曲線陡峭，沒有充足的資源進行多技術棧的維護，造成了比較高的技術成本。
2.2開發成本
多點的數據分析場景大致可以分為離線T+1更新分析場景、實時更新分析場景、固定維度分析場景。
2.2.1離線T+1更新的分析場景
例如多點的精細化用戶運營平臺，其核心的功能是基于用戶、消費、行為、設備等屬性，提供多維度篩選條件，并通過自定義條件實現用戶分層，便于進行精細化用戶運營。
針對數據更新為T+1的分析場景，原主要使用的分析引擎為ClickHouse。利用ClickHouse構建“大寬表”模型，將事實表與維度表提前進行關聯，對外提供單表聚合的SQL查詢，以及通過構建DWT主題寬表，提供Adhoc查詢；該場景面臨的問題是：雖然ClickHouse單表查詢強悍，但是Join能力不強，需要提前進行關聯，將多表關聯成單表，會存在額外的開發成本。
2.2.2實時更新分析場景
實時更新場景主要是實時監控經營的各項指標，如當前時間段內的GMV、下單數量、妥投數量、指標達成、對比、環比等指標。為客戶的經營決策提供更具備時效性的參考依據。
針對數據為實時（秒級）更新的場景，原主要使用Impala on Kudu引擎，采用Lambda架構，基于相同的主鍵，將流式的預計算的結果數據、批計算的結果數據，基于相同的主鍵進行merge。
上述方案中的Flink AGG部分，該程序的功能包括窗口內的預計算、多流Join等操作。當業務需求變更或者上游數據結構變動的時候，需要升級Flink AGG程序，以及離線ETL的任務，類似于“煙囪式”的迭代開發，開發效率低下。資源消耗層面，在Flink里面做預計算，時間窗口的選取以及內存占用之間也需要平衡。
2.2.3固定維度分析場景
固定維度的分析場景主要針對固化的、標準的業務場景進行分析，多維分析可以對以多維形式組織起來的數據進行上卷、下鉆、切片、切塊、旋轉等各種分析操作，以便剖析數據，使分析者、決策者能從多個角度、多個側面觀察數據倉庫中的數據，從而深入了解包含在數據中的信息和內涵。
針對分析維度固定的分析場景，按照業務上常用的分析指標以及維度，此前使用Apache Kylin進行cube預計算。但是使用Apache Kylin也會遇到如下問題：
1）由于多點業務場景涉及的維度比較多，各種類目、營運組織的組合，會導致cube膨脹，占用比較多的存儲資源；
2）當數據重跑以及新增維度，指標的時候。針對已經在線上運行的cube模型，為了保障數據重跑時候服務依然可用，需要新增cube模型，并行提供支持，造成存儲重復；
3）由于目前使用的Apache Kylin v3.1.2是使用HBase作為后端存儲，row key順序設計以及分區鍵的選擇會嚴重的影響查詢性能，對開發不友好。
2.3運維成本
多點作為一站式全渠道數字零售解決方案服務商，可以滿足客戶不同的接入部署需求。多點大數據產品系統的接入可以大致分為SaaS化接入、私有云以及本地化部署。針對私有云、本地化部署的客戶，OLAP引擎易部署、易維護、極簡的架構尤其重要，像HBase、Impala on Kudu、Apache Kylin等強依賴Hadoop生態的OLAP引擎，會增加部署的復雜性；ClickHouse集群不能自動感知集群拓撲變化，也不能自動balance數據，會增加縮容、擴容等的維護成本。
三、選擇StarRocks的原因
多點大數據部門從2021年年初開始，在調研市面上常用的存儲引擎時發現了StarRocks。StarRocks架構設計融合了MPP數據庫，以及分布式系統的設計思想，具備架構精簡，支持全面向量化引擎、智能查詢優化、高效更新、智能物化視圖、標準SQL、流批一體、高可用易擴展等特性，天然的解決了上述的問題。
3.1使用StarRocks的特性解決當前痛點
·引擎收斂
原有系統的多維分析，高并發查詢，預計算，實時分析，Adhoc查詢等場景下使用了多套系統，基本上可以使用一套StarRocks解決。多點大數據平臺、產品逐步形成以StarRocks為主，其他OLAP引擎為輔的存儲架構，解決維護多套引擎的技術成本問題。
·使用星型、星座模型替代“大寬表”模型
StarRocks支持Broadcast Join、Colocate Join等分布式Join的特性，可以在查詢性能可接受的范圍內，使用星型、星座模型替代“大寬表”模型，節約提前關聯的開發成本，同時針對事實表中歷史數據變更，需要重新“跑數”的場景，可以只重跑（OverWrite）部分表的數據，提高整體的“跑數”效率。
·簡化Lambda架構中的預聚合部分
StarRocks支持明細、聚合、更新模型，可以基于StarRocks自帶預聚合的特性，優化掉現有Lambda架構的中的預聚合部分。
StarRocks直接拉取/訂閱Hive或者Kafka中的數據，在StarRocks中進行聚合運算；StarRocks的數據模型是Aggregate模型，通過MAX、SUM、MIN、BITMAP_UNION等聚合函數在StarRocks中進行預聚合。
·模型持續迭代
針對已在線上運行的模型，如果有需求上的變更，比如增加、刪除、變更字段，可以使用StarRocks簡單SQL命令動態地修改表的定義，在表結構變更的過程中，線上的服務不受任何的影響。
·明細、匯總一體化
在實際的業務場景中，通常存在兩種場景并存的分析需求：對固定維度的聚合分析和對原始明細數據的查詢。在這種情況下，StarRocks支持對原表構建物化視圖，數據更新的時候，物化視圖跟隨原表一起進行更新，保證數據的一致性。當用戶查詢時，并不感知物化視圖的存在，不必顯式的指定物化視圖的名稱，查詢優化器可以根據查詢條件自動判斷是否可以路由到相應的物化視圖上。
·外表能力
StarRocks支持以外部表的形式，接入其他數據源包括MySQL、HDFS、Elasticsearch、Hive等。比如可以使用StarRocks建立Elasticsearch的外表，為Elasticsearch提供SQL查詢的能力。
3.2基于多點報表業務真實場景的性能測試
·單表聚合查詢
在現有的數據T+1更新的匯總業務場景中，選取了多點報表業務中的“單品銷售分析”場景進行測試，單表單天數據億級別，上百個維度和分析指標，屬于典型的基于“大寬表”的Adhoc查詢場景。在相同情況（機器配置、數據量、SQL）下進行ClickHouse對比StarRocks的性能測試：
橫坐標：分區（天）數-并發數；縱坐標：響應時長（ms）
從查詢響應時長來看，單表的聚合查詢，ClickHouse與StarRocks的查詢響應時長相差不多。
·多表關聯查詢
在現有的數據T+1更新多表關聯的匯總分析業務場景中，選取了現在多點報表業務中的“門店銷售分析”場景進行測試，事實表單天數據億級別，多個維表數據量在十萬級別，屬于典型的高維分析場景。在相同情況（機器配置、數據量、SQL）下進行ClickHouse對比StarRocks的性能測試：
橫坐標：分區（天）數-并發數；縱坐標：響應時長（ms）
從查詢響應時長來看，多表關聯聚合查詢，StarRocks的性能要優于ClickHouse。
·實時更新讀寫查詢
在現有的數據準實時更新（邊寫邊讀）的匯總查詢業務場景中，選取了“實時銷售分析”場景進行測試，訂單數據實時更新，單天數據量億級別。屬于典型的“實時更新，實時查詢”場景。在相同情況（機器配置、數據量、SQL）下進行Impala on Kudu對比StarRocks的性能測試：
橫坐標：分區（天）數-并發數；縱坐標：響應時長（ms）。
從查詢響應時長來看，在邊讀邊寫的情況下，聚合查詢的SQL，StarRocks的性能要優于Impala on Kudu。
四、實踐經驗
多點目前已經在高維業務指標報表、Adhoc分析、實時全鏈路監控等場景中引入了StarRocks，在使用中總結出以下經驗：
4.1集群拆分
由于StarRocks極簡的架構設計，易于運維部署。我們根據一定的規則，搭建了多套集群，避免業務之間的相互影響。
4.2按照數據更新頻率進行拆分
例如數據是T+1更新，且單表數據量在百億級別以上的場景（例如高維業務指標報表、Adhoc分析），我們構建了離線分析集群。通過提高StarRocks的查詢并發（parallel_fragment_exec_instance_num）、單節點內存限制（exec_mem_limit）等對復雜查詢友好的參數，提高集群的查詢性能；
針對數據是準實時更新，寫多讀多的場景（實時報表、實時全鏈路監控），我們構建了實時分析集群，通過調整StarRocks的compaction（cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk）等對寫入友好的參數，加快數據版本合并。
4.3按照業務域進行拆分
多點客戶的接入方式不同，且各種SLA要求也不同，會按照不同的需求搭建不同的StarRocks集群，盡量滿足多種客戶需求。
4.4調優手段
針對在線服務、系統，為了提高系統整體的查詢性能，可以從不同的維度進行優化：
4.4.1優化表結構定義
1）模型選擇
StarRocks的模型包括明細模型、聚合模型、更新模型。
如果需要對原始的數據（例如訂單流水，原始操作記錄等）來進行分析，可以選擇明細模型；
如果業務方進行的查詢為匯總類查詢，比如SUM、COUNT、MAX等類型的查詢，可以選擇聚合模型，提前進行預聚合，查詢的時候直接獲取結果；
如果數據需要頻繁的進行狀態更新（比如訂單的狀態變更），可以選擇更新模型。
2）分區(parition)和分桶(bucket)
StarRocks可以對表進行分區和分桶，分區在邏輯上把表劃分成了多個子表，可以按照時間進行分區；分桶可以按照不同的策略將數據劃分為不同的tablet，分布在不同的BE節點上。按照目前多點大數據集群的機器配置（64C+256G+12TB SSD），通常將一個tablet保持在200MB~1GB的大小，會有比較好的性能。
3）稀疏索引、bloomfilter、Bitmap Index
為了提高查詢的性能，可以對StarRocks的表結構額外構建索引。稀疏索引：可以將查詢中常見的過濾字段放在schema的前面，區分度越大，頻次越高的查詢字段越往前放；同時對區分度比較大的列構建bloomfilter；對區分度不大的列構建Bitmap Index。
4）物化視圖
針對實際查詢場景中經常用到的查詢SQL，可以對原始表構建物化視圖，其本質為原始表(base table)的一個物化索引，通過物化視圖提前進行索引排序、指標預計算，查詢的時候自動路由到物化視圖進行查詢。
5）使用BITMAP/HyperLogLog數據類型進行去重
在交易場景中進行會計算交易次數，使用常規的方式（COUNT DISTRINCT order_id）去重，其缺點是需要消耗極大的計算和存儲資源，對大規模數據集和查詢延遲敏感的去重場景支持不夠友好。通過定義BITMAP的數據類型，可以減少傳統COUNT DISTINCT去重的執行需要的內存空間、執行時長；而對于像流量統計場景中針對UV的計算，在允許有部分統計偏差的前提下，可以定義HyperLogLog的數據類型，提高去重效率。
4.4.2優化查詢SQL
1）小表Join可以對使用Broadcast Join
當大表與小表進行Join的時候，可以使用Broadcast Join（StarRocks針對小表的默認Join方式），小表向大表廣播的方式進行Join。該方式可以用于事實表與維度表進行關聯查詢；
2）大表Join可以使用Colocation Join
當大表與大表進行Join的時候，為了加速查詢，相關表可以采用共同的分桶列（colocate_with）進行分桶。當分桶列相同，相關表進行Join操作時，可以直接在本地進行Join，再將結果數據進行合并，避免數據在中間計算的時候就在集群中的傳輸。
3）并行度調整
當機器資源比較充裕時，可以將增加執行并行度（parallel_fragment_exec_instance_num），讓更多的執行實例同時處理一組數據掃描，從而提升查詢效率。但是并行度設置為較大的數值會消耗更多的機器資源，如CPU、內存、磁盤IO，影響整體的QPS。需要根據實際上的查詢場景來設置并行度，一般建議占用機器核數的50%。
4）CBO優化器
針對復雜Ad-hoc場景，可以開啟StarRocks的基于成本（Cost-based Optimizer，CBO）的查詢規劃器，在眾多查詢計劃空間中快速找到最優計劃，提高查詢優化器。
4.5工具集成
為了與目前多點的大數據平臺進行打通，對StartRocks進行了一些集成封裝。
·數據集成
通過封裝StarRocks的Broker Load以及Stream Load接口，與多點的大數據平臺打通，實現通過配置的方式將數據從Hive批量同步到StarRocks，或者訂閱MQ將實時數據同步到StarRocks。
·監控預警
通過集成Prometheus與Grafana，與監控平臺打通。對多個StarRocks集群的運行情況進行監控，當集群的某些指標超過一定閾值的時候進行報警。
五、總結與展望
多點從2021年上半年開始調研引入StarRocks，當前已有四個集群在穩定運行提供線上服務，逐步替代了Impala、Impala on Kudu、Apache Kylin等存儲引擎，實現了存儲引擎的收斂，簡化了實時數據處理鏈路，同時也能保障較高的查詢并發以及較低的響應延遲要求。目前公司也在越來越多的業務中嘗試使用StarRocks。
在引擎引入以及切換的過程中，得到了StarRocks社區的大力支持。后續公司在有余力的情況下會參與StarRocks的社區共建，共同打造性能強悍的國產新一代MPP數據庫。（作者：任偉，多點生活大數據部門資深研發工程師）
