OLAP分析哪家强！58集团分析业务DorisDB应用实践
58集团是中国互联网生活服务领域的领导者，旗下有国内最大的生活服务平台，覆盖各类业务场景，例如车业务、房产业务、本地服务、招聘业务、金融业务等等。
随着业务的高速发展，越来越多的分析需求涌现，例如：安全分析、商业智能分析、数仓报表等。这些场景的数据体量都较大，对数据分析平台提出了很高的要求。
为了满足这些分析型业务的需求，DBA团队从2021年初就开始调研各类分析型数据库，其中包括DorisDB、TiFlash、ClickHouse等，评测他们的性能及功能。
总体评测下来，DorisDB表现十分优秀，能够很好的满足业务要求。
目前，我们已经落地了2-3套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=102410248;
账号授权跟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
业务：数仓、纯分析业务、大体量报表
