訂閱
糾錯
加入自媒體

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

2021-05-26 14:25
來源: 粵訊

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

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

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

一、評測信息

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

1.功能方面

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

2.性能方面

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

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

·單表/多表查詢,DorisDB總體時間均最短。

·單表查詢:DorisDB最快次數(shù)最多,ClickHouse次之。

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

關于TiDB/TiFlash

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

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

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

關于Clickhouse

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

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

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

關于DorisDB

·DorisDB單表和多表關聯(lián)查詢速度都非?臁

【單表查詢結果】

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

【多表關聯(lián)查詢結果】

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

二、業(yè)務需求及應用

1.安全分析相關業(yè)務

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

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

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

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

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

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

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

2.DBA內部業(yè)務

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

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

后來架構又改成了 ProxySQL全日志–>Filebeat采集–>Kafka–>DorisDB,這樣就可以進行快速分析了。

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

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

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

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

三、系統(tǒng)運維

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

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

·HDFS導入需要提供Namenode的信息,有些不方便提供就支持不了。

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

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

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

··Kafka信息:kafka_broker_list,kafka_topic,client.id等。

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

·查看導入任務:SHOW ROUTINE LOADG;關注Statistic,ErrorLogUrls。

2.集群架構

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

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

3.運維及自動化

因為DorisDB標準版無管理組件,需要DBA自己實現(xiàn):

·標準制定,例如:運維標準、開發(fā)接入標準等;

·自動化部署;

·自動化擴縮容;

·自動化升級;

·拓撲展示、登錄;

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

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

·相關運維報表,例如表大小、集群磁盤使用情況、流量情況、SQL情況等。

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

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

【查看指定集群拓撲】:

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

【查看所有集群】:

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

4.服務器

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

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

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

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

·DorisDB升級比較快,如果遇到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;

·賬號授權跟MySQL不同,需要注意;

·標準版的周邊較少,希望能不斷豐富,讓更多的人用起來;

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

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

五、場景及定位

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

58集團 x DorisDB:全面升級數(shù)據(jù)分析能力,滿足多場景業(yè)務分析需求

總結

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

聲明: 本文系OFweek根據(jù)授權轉載自其它媒體或授權刊載,目的在于信息傳遞,并不代表本站贊同其觀點和對其真實性負責,如有新聞稿件和圖片作品的內容、版權以及其它問題的,請聯(lián)系我們。

發(fā)表評論

0條評論,0人參與

請輸入評論內容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續(xù)

暫無評論

暫無評論

人工智能 獵頭職位 更多
掃碼關注公眾號
OFweek人工智能網(wǎng)
獲取更多精彩內容
文章糾錯
x
*文字標題:
*糾錯內容:
聯(lián)系郵箱:
*驗 證 碼:

粵公網(wǎng)安備 44030502002758號