58 团体是中国互联网生存服务畛域的领导者，旗下有国内最大的生存服务平台，笼罩各类业务场景，例如车业务、房产业务、本地服务、招聘业务、金融业务等等。
随着业务的高速倒退，越来越多的剖析需要涌现，例如：平安剖析、商业智能剖析、数仓报表等。这些场景的数据体量都较大，对数据分析平台提出了很高的要求。为了满足这些剖析型业务的需要，DBA 团队从 2021 年初就开始调研各类剖析型数据库，其中包含 StarRocks、TiFlash、ClickHouse 等，评测他们的性能及性能。
总体评测下来，StarRocks 体现全面，在单表 / 多表查问性能、物化视图及 SQL 反对等方面能力都符合团体业务需要。目前，咱们曾经落地了两套 StarRocks 集群，还有 1 - 2 套正在测试阶段，后续会进行进一步推广和落地更多利用。
“作者：刘春雷，
负责 58 同城 MySQL、TiDB 数据库、StarRocks 的运维工作，次要从事数据库自动化、平台化的建设”
评测信息
咱们从两个方面来评测以上这些剖析型数据库：一个是性能，一个是性能。每种数据库都有各自的特点。
性能方面
性能方面
2021 年初，咱们残缺比照过 3 种数据库的性能，包含 TiFlash (4.0.10)、ClickHouse (20.3.8.53)、StarRocks (1.11.0) 单表及多表 join 的性能状况。TiDB5.0 的 TiFlash 曾经反对 MPP，此处为 4.0 版本，无 MPP。
测试应用业界风行的 Star Schema Benchmark 星型模型测试集。论断如下：
- 单表 / 多表查问，StarRocks 总体工夫均最短 。
- 单表查问：StarRocks 最快次数最多 ，ClickHouse 次之 。
- 多表查问：StarRocks 所有执行均最快 。
对于 TiDB/TiFlash
- TiDB/TiFlash 总体工夫单表 / 多表查问均最长。
- TiDB 执行打算少数走 TiKV，导致执行工夫长，且数据量越多，执行工夫越长。
- TiDB 强制走 TiFlash，单表少数提速多，多表少数变慢，但 4.0.10 版本的执行打算少数不走。
对于 Clickhouse
- ClickHouse 多表查问须要更改 SQL，使类型统一才能够，且字段名、表名辨别大小写。
- ClickHouse 单机性能强悍，性价比较高。
- ClickHouse 大单表查问形式效率好，多表关联效率升高显著。
对于 StarRocks
- StarRocks 单表和多表关联查问速度都十分快。
【单表查问后果】
【多表关联查问后果】
业务需要及利用
平安剖析相干业务
每天，外部服务器上的各类操作和运行状况，是外部平安人员比较关心的。然而服务器上每天有大量的信息，如何能疾速收集落地、对立实时剖析，是这个数据分析场景面临的挑战。具体来说，平安剖析业务须要应答以下状况：
- 写入数据量大，每天大概几亿的数据须要落地；
- 实时疾速的剖析反对，例如：最近 15 分钟，机器信息的状况是怎么的；
- 须要定期进行数据清理；
- 数据量一直累积，数据总量规模增长快。
综合评估后，咱们抉择了 StarRocks 来反对平安剖析相干业务。在应用初期，咱们应用了 StarRocks 的明细模型（即保留所有历史数据），20 天左右，数据行数总量就 800 亿 + 了，磁盘空间占用 8T 左右，因为明细数据量宏大导致查问性能也受到影响。
后与外部研发人员探讨，业务剖析并不需要具体的历史明细，数据依照指定工夫粒度进行聚合汇总即可。便将数据模型改成聚合模型，设置日期、小时和 15 分钟三个工夫维度，指标数据依照这个级别的工夫维度进行聚合，聚合后每天新增的数据在 10 亿左右，数据量升高了 75%，查问性能也失去大幅晋升。且采纳 kafka+routine load 的形式在 StarRocks 中进行导入聚合，防止了引入冗余的组件，对立了技术栈。
DBA 外部业务
MySQL 中间件，咱们应用的 ProxySQL，ProxySQL 反对展现 SQL 状况。然而操作较为繁琐，每次须要重置，才从新开始统计。如何剖析指定工夫的 SQL 状况，是困扰咱们的另一问题。
每个 ProxySQL 有本人的全日志，咱们能够剖析全日志来获取须要的信息。第一个架构计划，咱们想到了应用 ES，ProxySQL 全日志–>Filebeat 采集–>Kafka–>Logstash–>ES。然而理论应用中，发现尽管能够查看流水，然而剖析时就比拟麻烦，不如写 SQL 的不便。
起初架构又改成了 ProxySQL 全日志–>Filebeat 采集–>Kafka–>StarRocks，这样就能够进行疾速剖析了。
另一个问题，因为线上的 ProxySQL 的日志量特地大，不能所有集群都开，咱们设置了能够抉择开启，这样有须要的集群才进行剖析。升高存储的压力。
举例：剖析某 30 分钟某集群的 SQL 执行状况，依照次数排序，查问很快。
除了上述两个场景之外，StarRocks 还被用在了销售应用的报表零碎等场景中，蕴含实时数据分析等业务场景，共 50+ 张表，占用约 100T 存储空间，查问并发量 100-500+。
零碎运维
数据接入
StarRocks 反对的数据导入形式很丰盛，例如本地文件、HDFS、Kafka(反对 csv、json 格局)、表面、批量 SQL 等。数据接入时有以下须要留神的问题：
- HDFS 导入须要提供 Namenode 的信息，有些不不便提供就反对不了。
- 表面模式，创立表面后，能够应用 insert into select 的形式，循环导入到 StarRocks 的本地表，能比拟不便的从 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 来接入数据。
运维及自动化
因为 StarRocks 标准版无治理组件，须要 DBA 本人实现：
- 规范制订，例如：运维规范、开发接入规范等；
- 自动化部署；
- 自动化扩缩容；
- 自动化降级；
- 拓扑展现、登录；
- 搭建开源监控；
- 本人实现报警，例如存活报警、性能报警；
- 相干运维报表，例如表大小、集群磁盘应用状况、流量状况、SQL 状况等。
目前咱们本人曾经实现了局部运维标准的制订，例如集群端口、目录、拓扑架构等，并开发了拓扑工具：qstarrocks，能够查看所有集群、指定集群、登录、展现监控节点信息等。
前期咱们会开发相干自动化管理工具，并整合至咱们外部的 CDB 平台，开发相干报表、工单等，不便开发人员应用。
【查看指定集群拓扑】：
【查看所有集群】：
服务器
以后咱们应用如下机器进行部署，前期会思考将 FE 节点应用虚拟机部署。
发现的问题及注意事项
- 如果想混合部署，须要提前打算好端口，集群间须要有肯定距离；
- 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;
- 账号受权跟 MySQL 不同，须要留神；
- 标准版的周边较少，心愿能不断丰富，让更多的人用起来；
- Json 格局数据导入，字段没法复用，举荐官网增加上，例如：求最大最小工夫，须要开发写入 Kafka 两个工夫字段，无奈复用一个；
- 导入数据须要肯定的调试教训，例如 Kafka，能够本人写个工具，查看下 Kafka 外面的数据，再进行测试；
场景及定位
StarRocks 是优良的剖析型数据库，能够满足多种数据分析场景的需要。但还有不少业务场景须要用其余数据库来服务，目前 58DBA 提供了多种数据库，不便业务方依据本身的场景进行抉择。
总结
目前，咱们曾经落地了两套 StarRocks 集群，还有 1 - 2 套正在测试阶段，后续会进行进一步推广和落地更多利用。最初，非常感激 StarRocks 鼎石科技团队业余的反对服务，心愿咱们能一起把 StarRocks 建设得更好。