58集團的StarRocks應(yīng)用實踐

58集團是中國互聯(lián)網(wǎng)生活服務(wù)領(lǐng)域的領(lǐng)導(dǎo)者，旗下有國內(nèi)最大的生活服務(wù)平臺，覆蓋各類業(yè)務(wù)場景，例如車業(yè)務(wù)、房產(chǎn)業(yè)務(wù)、本地服務(wù)、招聘業(yè)務(wù)、金融業(yè)務(wù)等等。

　　隨著業(yè)務(wù)的高速發(fā)展，越來越多的分析需求涌現(xiàn)，例如：安全分析、商業(yè)智能分析、數(shù)倉報表等。這些場景的數(shù)據(jù)體量都較大，對數(shù)據(jù)分析平臺提出了很高的要求。為了滿足這些分析型業(yè)務(wù)的需求，DBA團隊從2021年初就開始調(diào)研各類分析型數(shù)據(jù)庫，其中包括StarRocks、TiFlash、ClickHouse等，評測他們的性能及功能。

　　總體評測下來，StarRocks表現(xiàn)全面，在單表/多表查詢性能、物化視圖及SQL支持等方面能力都契合集團業(yè)務(wù)需求。目前，我們已經(jīng)落地了兩套StarRocks集群，還有1-2套正在測試階段，后續(xù)會進行進一步推廣和落地更多應(yīng)用。

　　一、評測信息

　　我們從兩個方面來評測以上這些分析型數(shù)據(jù)庫：一個是功能，一個是性能。每種數(shù)據(jù)庫都有各自的特點。

　　1.功能方面

　　2.性能方面

　　2021年初，我們完整對比過3種數(shù)據(jù)庫的性能，包括TiFlash(4.0.10)、ClickHouse(20.3.8.53)、StarRocks(1.11.0)單表及多表join的性能情況。TiDB5.0的TiFlash已經(jīng)支持MPP，此處為4.0版本，無MPP。

　　測試使用業(yè)界流行的Star Schema Benchmark星型模型測試集。結(jié)論如下：

　　·單表/多表查詢，StarRocks總體時間均最短。

　　·單表查詢：StarRocks最快次數(shù)最多，ClickHouse次之。

　　·多表查詢：StarRocks所有執(zhí)行均最快。

　　關(guān)于TiDB/TiFlash

　　·TiDB/TiFlash總體時間單表/多表查詢均最長。

　　·TiDB執(zhí)行計劃多數(shù)走TiKV，導(dǎo)致執(zhí)行時間長，且數(shù)據(jù)量越多，執(zhí)行時間越長。

　　·TiDB強制走TiFlash，單表多數(shù)提速多，多表多數(shù)變慢，但4.0.10版本的執(zhí)行計劃多數(shù)不走。

　　關(guān)于Clickhouse

　　·ClickHouse多表查詢需要更改SQL，使類型一致才可以，且字段名、表名區(qū)分大小寫。

　　·ClickHouse單機性能強悍，性價比較高。

　　·ClickHouse大單表查詢方式效率好，多表關(guān)聯(lián)效率降低明顯。

　　關(guān)于StarRocks

　　·StarRocks單表和多表關(guān)聯(lián)查詢速度都非常快。

　　【單表查詢結(jié)果】

　　【多表關(guān)聯(lián)查詢結(jié)果】

　　二、業(yè)務(wù)需求及應(yīng)用

　　1.安全分析相關(guān)業(yè)務(wù)

　　每天，內(nèi)部服務(wù)器上的各類操作和運行情況，是內(nèi)部安全人員比較關(guān)心的。但是服務(wù)器上每天有大量的信息，如何能快速收集落地、統(tǒng)一實時分析，是這個數(shù)據(jù)分析場景面臨的挑戰(zhàn)。具體來說，安全分析業(yè)務(wù)需要應(yīng)對以下情況：

　　·寫入數(shù)據(jù)量大，每天大約幾億的數(shù)據(jù)需要落地；

　　·實時快速的分析支持，例如：最近15分鐘，機器信息的情況是怎樣的；

　　·需要定期進行數(shù)據(jù)清理；

　　·數(shù)據(jù)量不斷累積，數(shù)據(jù)總量規(guī)模增長快。

　　綜合評估后，我們選擇了StarRocks來支持安全分析相關(guān)業(yè)務(wù)。在使用初期，我們使用了StarRocks的明細模型（即保留所有歷史數(shù)據(jù)），20天左右，數(shù)據(jù)行數(shù)總量就800億+了，磁盤空間占用8T左右，由于明細數(shù)據(jù)量龐大導(dǎo)致查詢性能也受到影響。

　　后與內(nèi)部研發(fā)人員討論，業(yè)務(wù)分析并不需要詳細的歷史明細，數(shù)據(jù)按照指定時間粒度進行聚合匯總即可。便將數(shù)據(jù)模型改成聚合模型，設(shè)置日期、小時和15分鐘三個時間維度，指標(biāo)數(shù)據(jù)按照這個級別的時間維度進行聚合，聚合后每天新增的數(shù)據(jù)在10億左右，數(shù)據(jù)量降低了75%，查詢性能也得到大幅提升。且采用kafka+routine load的方式在StarRocks中進行導(dǎo)入聚合，避免了引入冗余的組件，統(tǒng)一了技術(shù)棧。

　　2.DBA內(nèi)部業(yè)務(wù)

　　MySQL中間件，我們使用的ProxySQL，ProxySQL支持展示SQL情況。但是操作較為繁瑣，每次需要重置，才重新開始統(tǒng)計。如何分析指定時間的SQL情況，是困擾我們的另一問題。

　　每個ProxySQL有自己的全日志，我們可以分析全日志來獲取需要的信息。第一個架構(gòu)方案，我們想到了使用ES，ProxySQL全日志–>Filebeat采集–>Kafka–>Logstash–>ES。但是實際使用中，發(fā)現(xiàn)雖然可以查看流水，但是分析時就比較麻煩，不如寫SQL的方便。

　　后來架構(gòu)又改成了ProxySQL全日志–>Filebeat采集–>Kafka–>StarRocks，這樣就可以進行快速分析了。

　　另一個問題，因為線上的ProxySQL的日志量特別大，不能所有集群都開，我們設(shè)置了可以選擇開啟，這樣有需要的集群才進行分析。降低存儲的壓力。

　　舉例：分析某30分鐘某集群的SQL執(zhí)行情況，按照次數(shù)排序，查詢很快。

　　除了上述兩個場景之外，StarRocks還被用在了銷售使用的報表系統(tǒng)等場景中，包含實時數(shù)據(jù)分析等業(yè)務(wù)場景，共50+張表，占用約100T存儲空間，查詢并發(fā)量100-500+。

　　三、系統(tǒng)運維

　　1.數(shù)據(jù)接入

　　StarRocks支持的數(shù)據(jù)導(dǎo)入方式很豐富，例如本地文件、HDFS、Kafka(支持csv、json格式)、外表、批量SQL等。數(shù)據(jù)接入時有以下需要注意的問題：

　　·HDFS導(dǎo)入需要提供Namenode的信息，有些不方便提供就支持不了。

　　·外表模式，創(chuàng)建外表后，可以使用insert into select的方式，循環(huán)導(dǎo)入到StarRocks的本地表，能比較方便的從MySQL、TiDB導(dǎo)入數(shù)據(jù)。

　　·日常最常用的是Kafka的Json格式的數(shù)據(jù)，需要開發(fā)提供：

　　-表字段、字段類型及模型(明細模型，聚合模型和更新模型)。

　　-Kafka信息：kafka_broker_list，kafka_topic，client.id等。

　　·Kafka的方式，DBA創(chuàng)建表及導(dǎo)入任務(wù)就可以導(dǎo)入數(shù)據(jù)了；日常需要注意的是：最好寫個小工具，查看下Kafka的數(shù)據(jù)信息，然后指明字段，這樣來保證成功率。

　　·查看導(dǎo)入任務(wù)：SHOW ROUTINE LOADG；關(guān)注Statistic，ErrorLogUrls。

　　2.集群架構(gòu)

　　目前為單套集群，3個FE，3個BE，Broker按需建立，搭建1套監(jiān)控(Prometheus+Grafana)，推薦使用kafka來接入數(shù)據(jù)。

　　3.運維及自動化

　　因為StarRocks標(biāo)準(zhǔn)版無管理組件，需要DBA自己實現(xiàn)：

　　·標(biāo)準(zhǔn)制定，例如：運維標(biāo)準(zhǔn)、開發(fā)接入標(biāo)準(zhǔn)等；

　　·自動化部署；

　　·自動化擴縮容；

　　·自動化升級；

　　·拓撲展示、登錄；

　　·搭建開源監(jiān)控；

　　·自己實現(xiàn)報警，例如存活報警、性能報警；

　　·相關(guān)運維報表，例如表大小、集群磁盤使用情況、流量情況、SQL情況等。

　　目前我們自己已經(jīng)實現(xiàn)了部分運維規(guī)范的制定，例如集群端口、目錄、拓撲架構(gòu)等，并開發(fā)了拓撲工具：qStarRocks，可以查看所有集群、指定集群、登錄、展示監(jiān)控節(jié)點信息等。

　　后期我們會開發(fā)相關(guān)自動化管理工具，并整合至我們內(nèi)部的CDB平臺，開發(fā)相關(guān)報表、工單等，方便開發(fā)人員使用。

　　【查看指定集群拓撲】：

　　【查看所有集群】：

　　4.服務(wù)器

　　當(dāng)前我們使用如下機器進行部署，后期會考慮將FE節(jié)點使用虛擬機部署。

　　四、發(fā)現(xiàn)的問題及注意事項

　　·如果想混合部署，需要提前計劃好端口，集群間需要有一定間隔；

　　·StarRocks升級比較快，如果遇到bug可以咨詢官方，及時升級避開；

　　·查詢報錯：2021-05-09 11:38:56-WARN

　　·com.mysql.jdbc.PacketTooBigException:Packet for query is too large(1095400>1048576).You can change this value on the server by setting the max_allowed_packet’variable；

　　-處理：set global max_allowed_packet=102410248;

　　·賬號授權(quán)跟MySQL不同，需要注意；

　　·標(biāo)準(zhǔn)版的周邊較少，希望能不斷豐富，讓更多的人用起來；

　　·Json格式數(shù)據(jù)導(dǎo)入，字段沒法復(fù)用，推薦官方添加上，例如：求最大最小時間，需要開發(fā)寫入Kafka兩個時間字段，無法復(fù)用一個；

　　·導(dǎo)入數(shù)據(jù)需要一定的調(diào)試經(jīng)驗，例如Kafka，可以自己寫個工具，查看下Kafka里面的數(shù)據(jù)，再進行測試；

　　五、場景及定位

　　StarRocks是優(yōu)秀的分析型數(shù)據(jù)庫，可以滿足多種數(shù)據(jù)分析場景的需求。但還有不少業(yè)務(wù)場景需要用其他數(shù)據(jù)庫來服務(wù)，目前58DBA提供了多種數(shù)據(jù)庫，方便業(yè)務(wù)方根據(jù)自身的場景進行選擇。

　　總結(jié)

　　目前，我們已經(jīng)落地了兩套StarRocks集群，還有1-2套正在測試階段，后續(xù)會進行進一步推廣和落地更多應(yīng)用。最后，十分感謝StarRocks鼎石科技團隊專業(yè)的支持服務(wù)，希望我們能一起把StarRocks建設(shè)得更好。（作者：劉春雷負責(zé)58同城MySQL、TiDB數(shù)據(jù)庫、StarRocks的運維工作，主要從事數(shù)據(jù)庫自動化、平臺化的建設(shè)）