站長資訊網58集團是中國互聯網生活服務領域的領導者，旗下有國內最大的生活服務平臺，覆蓋各類業務場景，例如車業務、房產業務、本地服務、招聘業務、金融業務等等。
隨著業務的高速發展，越來越多的分析需求涌現，例如：安全分析、商業智能分析、數倉報表等。這些場景的數據體量都較大，對數據分析平臺提出了很高的要求。為了滿足這些分析型業務的需求，DBA團隊從2021年初就開始調研各類分析型數據庫，其中包括DorisDB、TiFlash、ClickHouse等，評測他們的性能及功能。
總體評測下來，DorisDB表現全面，在單表/多表查詢性能、物化視圖及SQL支持等方面能力都契合集團業務需求。目前，我們已經落地了兩套DorisDB集群，還有1-2套正在測試階段，后續會進行進一步推廣和落地更多應用。
一、評測信息
我們從兩個方面來評測以上這些分析型數據庫：一個是功能，一個是性能。每種數據庫都有各自的特點。
1.功能方面
2.性能方面
2021年初，我們完整對比過3種數據庫的性能，包括TiFlash(4.0.10)、ClickHouse(20.3.8.53)、DorisDB(1.11.0)單表及多表join的性能情況。TiDB5.0的TiFlash已經支持MPP，此處為4.0版本，無MPP。
測試使用業界流行的Star Schema Benchmark星型模型測試集。結論如下：
·單表/多表查詢，DorisDB總體時間均最短。
·單表查詢：DorisDB最快次數最多，ClickHouse次之。
·多表查詢：DorisDB所有執行均最快。
關于TiDB/TiFlash
·TiDB/TiFlash總體時間單表/多表查詢均最長。
·TiDB執行計劃多數走TiKV，導致執行時間長，且數據量越多，執行時間越長。
·TiDB強制走TiFlash，單表多數提速多，多表多數變慢，但4.0.10版本的執行計劃多數不走。
關于Clickhouse
·ClickHouse多表查詢需要更改SQL，使類型一致才可以，且字段名、表名區分大小寫。
·ClickHouse單機性能強悍，性價比較高。
·ClickHouse大單表查詢方式效率好，多表關聯效率降低明顯。
關于DorisDB
·DorisDB單表和多表關聯查詢速度都非常快。
【單表查詢結果】
【多表關聯查詢結果】
二、業務需求及應用
1.安全分析相關業務
每天，內部服務器上的各類操作和運行情況，是內部安全人員比較關心的。但是服務器上每天有大量的信息，如何能快速收集落地、統一實時分析，是這個數據分析場景面臨的挑戰。具體來說，安全分析業務需要應對以下情況：
·寫入數據量大，每天大約幾億的數據需要落地;
·實時快速的分析支持，例如：最近15分鐘，機器信息的情況是怎樣的;
·需要定期進行數據清理;
·數據量不斷累積，數據總量規模增長快。
綜合評估后，我們選擇了DorisDB來支持安全分析相關業務。在使用初期，我們使用了DorisDB的明細模型(即保留所有歷史數據)，20天左右，數據行數總量就800億+了，磁盤空間占用8T左右，由于明細數據量龐大導致查詢性能也受到影響。
后與內部研發人員討論，業務分析并不需要詳細的歷史明細，數據按照指定時間粒度進行聚合匯總即可。便將數據模型改成聚合模型，設置日期、小時和15分鐘三個時間維度，指標數據按照這個級別的時間維度進行聚合，聚合后每天新增的數據在10億左右，數據量降低了75%，查詢性能也得到大幅提升。且采用kafka+routine load的方式在DorisDB中進行導入聚合，避免了引入冗余的組件，統一了技術棧。
2.DBA內部業務
MySQL中間件，我們使用的ProxySQL，ProxySQL支持展示SQL情況。但是操作較為繁瑣，每次需要重置，才重新開始統計。如何分析指定時間的SQL情況，是困擾我們的另一問題。
每個ProxySQL有自己的全日志，我們可以分析全日志來獲取需要的信息。第一個架構方案，我們想到了使用ES，ProxySQL全日志–>Filebeat采集–>Kafka–>Logstash–>ES。但是實際使用中，發現雖然可以查看流水，但是分析時就比較麻煩，不如寫SQL的方便。
后來架構又改成了 ProxySQL全日志–>Filebeat采集–>Kafka–>DorisDB，這樣就可以進行快速分析了。
另一個問題，因為線上的ProxySQL的日志量特別大，不能所有集群都開，我們設置了可以選擇開啟，這樣有需要的集群才進行分析。降低存儲的壓力。
舉例：分析某30分鐘某集群的SQL執行情況，按照次數排序，查詢很快。
除了上述兩個場景之外，DorisDB還被用在了銷售使用的報表系統等場景中，包含實時數據分析等業務場景，共50+張表，占用約100T存儲空間，查詢并發量100-500+。
三、系統運維
1.數據接入
DorisDB支持的數據導入方式很豐富，例如本地文件、HDFS、Kafka(支持csv、json格式)、外表、批量SQL等。數據接入時有以下需要注意的問題：
·HDFS導入需要提供Namenode的信息，有些不方便提供就支持不了。
·外表模式，創建外表后，可以使用insert into select的方式，循環導入到DorisDB的本地表，能比較方便的從MySQL、TiDB導入數據。
·日常最常用的是Kafka的Json格式的數據，需要開發提供：
··表字段、字段類型及模型(明細模型,聚合模型和更新模型)。
··Kafka信息：kafka_broker_list，kafka_topic，client.id等。
·Kafka的方式，DBA創建表及導入任務就可以導入數據了;日常需要注意的是：最好寫個小工具，查看下Kafka的數據信息，然后指明字段，這樣來保證成功率。
·查看導入任務：SHOW ROUTINE LOADG;關注Statistic，ErrorLogUrls。
2.集群架構
目前為單套集群，3個FE，3個BE，Broker按需建立，搭建1套監控(Prometheus+Grafana)，推薦使用kafka來接入數據。
3.運維及自動化
因為DorisDB標準版無管理組件，需要DBA自己實現：
·標準制定，例如：運維標準、開發接入標準等;
·自動化部署;
·自動化擴縮容;
·自動化升級;
·拓撲展示、登錄;
·搭建開源監控;
·自己實現報警，例如存活報警、性能報警;
·相關運維報表，例如表大小、集群磁盤使用情況、流量情況、SQL情況等。
目前我們自己已經實現了部分運維規范的制定，例如集群端口、目錄、拓撲架構等，并開發了拓撲工具：qdorisdb，可以查看所有集群、指定集群、登錄、展示監控節點信息等。
后期我們會開發相關自動化管理工具，并整合至我們內部的CDB平臺，開發相關報表、工單等，方便開發人員使用。
【查看指定集群拓撲】：
【查看所有集群】：
4.服務器
當前我們使用如下機器進行部署，后期會考慮將FE節點使用虛擬機部署。
四、發現的問題及注意事項
·如果想混合部署，需要提前計劃好端口，集群間需要有一定間隔;
·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格式數據導入，字段沒法復用，推薦官方添加上，例如：求最大最小時間，需要開發寫入Kafka兩個時間字段，無法復用一個;
·導入數據需要一定的調試經驗，例如Kafka，可以自己寫個工具，查看下Kafka里面的數據，再進行測試;
五、場景及定位
DorisDB是優秀的分析型數據庫，可以滿足多種數據分析場景的需求。但還有不少業務場景需要用其他數據庫來服務，目前58DBA提供了多種數據庫，方便業務方根據自身的場景進行選擇。
總結
目前，我們已經落地了兩套DorisDB集群，還有1-2套正在測試階段，后續會進行進一步推廣和落地更多應用。最后，十分感謝DorisDB鼎石科技團隊專業的支持服務，希望我們能一起把DorisDB建設得更好。(作者：劉春雷 負責58同城MySQL、TiDB數據庫、DorisDB的運維工作，主要從事數據庫自動化、平臺化的建設)
特別提醒：本網信息來自于互聯網，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。
