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