58DorisDB使用分享

58DorisDB分享

                            2021-05-18 刘春雷

OLAP分析哪家强!58集团分析业务DorisDB应用实践

58集团是中国互联网生活服务领域的领导者,旗下有国内最大的生活服务平台,覆盖各类业务场景,例如车业务、房产业务、本地服务、招聘业务、金融业务等等。

随着业务的高速发展,越来越多的分析需求涌现,例如:安全分析、商业智能分析、数仓报表等。这些场景的数据体量都较大,对数据分析平台提出了很高的要求。为了满足这些分析型业务的需求,DBA团队从2021年初就开始调研各类分析型数据库,其中包括DorisDB、TiFlash、ClickHouse等,评测他们的性能及功能。

总体评测下来,DorisDB表现十分优秀,能够很好的满足业务要求。目前,我们已经落地了2套DorisDB集群,还有1-2套正在测试阶段,后续会进行进一步推广和落地更多应用。

一、评测信息

我们从两个方面来评测以上这些分析型数据库:一个是功能,一个是性能。每种数据库都有各自的特点。

功能方面

性能方面

年初完整对比过3种数据库的性能,包括 TiFlash (4.0.10) 、ClickHouse (20.3.8.53)、DorisDB (1.11.0)单表及多表join的性能情况。 使用:Star schema benchmark星型模型测试集。

结论如下:

  • 单表/多表查询,DorisDB总体时间均最短

  • 单表查询:DorisDB最快次数最多,ClickHouse次之

  • 多表查询:DorisDB所有执行均最快

  • 多表Join场景均比单表查询时间长

关于TiDB/TiFlash

  • TiDB/TiFlash总体时间单表/多表查询均最长

  • TiDB执行计划多数走TiKV,导致执行时间长,且数据量越多,执行时间越长

  • TiDB强制走TiFlash ,单表多数提速多,多表多数变慢,但4.0.10 版本的执行计划多数不走

关于Clickhouse

  • ClickHouse多表查询需要更改SQL,使类型一致才可以,且字段名、表名区分大小写

  • ClickHouse单机性能强悍,性价比较高

  • ClickHouse大单表查询方式效率好,多表关联效率降低明显

  • ClickHouse分布式表Join 比 全本地单表Join 的查询快

  • ClickHouse小表不推荐使用分布式表Join,只大表进行分布式表Join,执行时间均变短

关于DorisDB

  • DorisDB多表关联效率好

另:TiDB5.0 的TiFlash已经支持MPP,此处为4.0版本无MPP,我们内部测试性能比4.0提升很多,后期可以再对比下

【单表查询】:

【多表关联查询】:

二、业务需求及应用

安全分析相关业务

每天,内部服务器上的各类操作和运行情况,是内部安全人员比较关心的。但是服务器上每天有大量的信息,如何能快速收集落地、统一实时分析,是这个数据分析场景面临的挑战。具体来说,安全分析业务需要应对以下情况:

  • 写入数据量大,每天大约几亿的数据需要落地;

  • 实时快速的分析支持,例如:最近15分钟,机器信息的情况是怎样的;

  • 需要定期进行数据清理

  • 数据量不断累积,数据总量规模增长快。

综合评估后,我们选择了DorisDB来支持安全分析相关业务。在使用初期,我们使用了明细模型,20天左右,数据量就800亿+了,磁盘空间占用8T左右,导致一定的性能影响。后与内部研发人员商定,不要详细的历史明细,记录指定时间的数量即可。将数据模型改成聚合模型,每15分钟进行聚合,次数累增,这样就减少了数据量。且按照时间分区,定期清理分区即可,方便了数据清理且方便了查询。目前该业务每天新增10亿左右数据,数据量降低了 75%。

报表业务

某智能部门的销售使用的报表系统,需求:

  • 低延时的实时分析能力

  • 良好的物化视图能力,提升查询效率

  • 存储100T左右,表50+

  • 查询100-500+

同样,因为存储与物化视图等需求,我们选择了DorisDB,下图为业务同学调研的情况~

DBA 内部业务

MySQL中间件,我们使用的ProxySQL,ProxySQL支持展示SQL情况。但是操作较为繁琐,每次需要重置,才重新开始统计。如何分析指定时间的SQL情况,是困扰我们的另一问题。

每个ProxySQL有自己的全日志,我们可以分析全日志来获取需要的信息。第一个架构方案,我们想到了使用ES,ProxySQL全日志–>filebeat采集–>kafka–>logstash–>ES。但是实际使用中,发现虽然可以查看流水,但是分析时就比较麻烦,不如写SQL的方便。

后来架构又改成了 ProxySQL全日志–>filebeat采集–>kafka–>DorisDB,这样就可以进行快速分析了。

另一个问题,因为线上的ProxySQL的日志量特别大,不能所有集群都开,我们设置了可以选择开启,这样有需要的集群才进行分析。降低存储的压力。

举例:分析某30分钟某集群的SQL执行情况,按照次数排序,查询很快~

三、系统运维

数据接入

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 LOAD\G; 关注Statistic,ErrorLogUrls

集群架构

目前为单套集群,3个FE,3个BE ,Broker按需建立,搭建1套监控(Prometheus+Grafana),推荐使用kafka来接入数据。

运维及自动化

因为DorisDB标准版无管理组件,需要DBA自己实现:

  • 标准制定,例如:运维标准、开发接入标准等

  • 自动化部署

  • 自动化扩缩容

  • 自动化升级

  • 拓扑展示、登录

  • 搭建开源监控

  • 自己实现报警,例如存活报警、性能报警

  • 相关运维报表,例如表大小、集群磁盘使用情况、流量情况、SQL情况等

目前我们自己已经实现了部分运维规范的制定,例如集群端口、目录、拓扑架构等,并开发了拓扑工具:qdorisdb,可以查看所有集群、指定集群、登录、展示监控节点信息等。

后期会开发相关自动化管理工具,并整合至我们内部的CDB平台,开发相关报表、工单等,方便开发人员使用

【查看指定集群拓扑】:

【查看所有集群】:

服务器

因缺少一定的运维经验,先暂时使用如下机器进行部署,后期会考虑将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=1024 1024 8;
  • 账号授权跟MySQL不同,需要注意

  • 标准版暂时未开源,会影响一部分用户的使用信心

  • 标准版的周边很少,推荐官方丰富下,让更多的人用起来~

  • 本地连接,root没密码,有安全风险

  • json格式数据导入,字段没法复用,推荐官方添加上,例如:求最大最小时间,需要开发写入kafka 2个时间字段,无法复用一个

  • bug:创建导入任务,多写了字段,导致BE宕机,已经联系官方,后续会修复

  • 无法使用第三方客户端连接,因为有些第三方的客户端会校验mysql库的部分表,导致连接失败

  • 导入数据得话,例如kafka,需要一定的调试经验,可以自己写个工具,查看下kafka里面的数据,再进行测试

  • 旧版本需要设置数据库的配额:ALTER DATABASE xxx SET DATA QUOTA 24576GB;新版本取消

五、场景及定位

DorisDB很优秀,但是没有一种数据库是银弹!数据库都有各自适用的场景,使用不当,就会存在问题,所以目前58DBA提供了多种数据库,方便大家根据自身的业务场景进行选择~

MySQL :关系型数据库

特性:稳定、轻量级、高可用、成熟,指定点恢复

业务:日常的轻量级OLTP业务,重要性高的业务

Redis :NoSQL 缓存型数据库

特性:内存型,Key-Value,轻量、不支持恢复、查询效率高

业务:读流量高、数据变化不频繁的业务

MongoDB:NoSQL 非关系型数据库

特性:高可用,面向集合存储,模式自由

业务:适用于文档型、地理位置等业务

Elasticsearch :搜索与数据分析引擎

特性:分布式,可扩展,周边组件配合使用(例如:filebeat,logstash,kibana等),写入速度快,数据源灵活

业务:日志、搜索型、标签画像等业务

TiDB :NewSQL 分布式关系型数据库

特性:分布式,可扩展,行存+列存,HTAP( OLTP+OLAP )

业务:日志,报表、监控、大量数据存储需求的、一定量分析需求的

DorisDB : NewSQL 分布式列存数据库

特性:分布式,可扩展、写入速度快,列存,分析SQL效率好,支持SQL

业务:数仓、纯分析业务、大体量报表

1赞