作者：刘春雷，58 集团数据库专家，StarRocks Community Champion
58 集团是中国互联网生活服务领域的领导者，旗下有国内最大的生活服务平台，覆盖各类业务场景，例如车业务、房产业务、本地服务、招聘业务、金融业务等等。
随着业务的高速发展，越来越多的分析需求涌现，例如：安全分析、商业智能分析、数仓报表等。这些场景的数据体量都较大，对数据分析平台提出了很高的要求。
为了满足这些分析型业务的需求，DBA 团队从 2021 年初就开始调研各类分析型数据库，包括 StarRocks、TiFlash、ClickHouse 等，评测性能及功能。
总体评测下来，StarRocks 在运维方便性、查询性能、写入性能上、官方支持力度上均表现优秀，于是我们进行了测试并逐步上线应用，在实际使用上也是满足预期。
#01
引入 StarRocks
—
DBA 组运维大量的 TiDB 数据库，集群 120 套+，TiDB 在 4.0 版本引入了 TiFlash 组件，支持 HTAP 的场景，DBA 引入并上线了部分集群。
使用中发现 TiFlash 的性能无法完全满足业务的需求，例如：
- 写入性能不能满足
原因：TiFlash 数据同步于 TiKV，写速度受限于 TiKV 的性能，如果 AP 的业务比重比较大，则需要很多的 TiKV 与 TiFlash，才能保证性能，造成了资源浪费
- 读性能不能满足
原因：SQL 的执行计划会自动选择 TiKV、TiFlash，有时执行计划不准，本应该走 TiFlash 更快，但是走了 TiKV，导致 SQL 执行时间不稳定；另有些走了 TiFlash 的，性能也无法满足要求
综上：TiDB 主打的 HTAP 场景，TP 为主，AP 次要，或者轻量级的 AP 分析
但是业务有很多纯AP的分析场景，为了更好的满足 AP 分析需求，DBA 组调研了StarRocks，并对比了 ClickHouse，发现 StarRocks 在性能、功能、易运维等方面均优于 ClickHouse，便进行了引入与落地。
1、新一代极速全场景 MPP 数据库 StarRocks
简介
- StarRocks 是⼀款经过业界检验、现代化的、⾯向多种数据分析场景、兼容 MySQL 协议的⾼性能分布式关系型列式数据库。
- StarRocks 充分吸收关系型 OLAP 数据库和分布式存储系统在大数据时代的优秀研究成果， 并在业界实践的基础上， 进⼀步改进、优化、架构升级，加⼊新功能，形成企业级产品。
- StarRocks 致力于满足企业⽤户的多种数据分析场景。支持多种数据模型(明细模型、聚合模型、主键模型)， 多种导入方式，可整合和接⼊多种现有系统(Apache Spark、Apache Flink、Apache Hive、ElasticSearch)。
- StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端，常用 BI ⼯具都可以对接 StarRocks 来进行数据分析。
- StarRocks 采⽤分布式架构，对 table 进行水平划分并以多副本存储。集群规模可以灵活伸缩，能够支持 10PB 级别的数据分析，支持 MPP 并行加速计算，支持多副本，具有弹性容错能力。
- StarRocks 采用关系模型，使用严格的数据类型。使用列式存储引擎，通过编码和压缩技术，降低读写放大。使用向量化执行方式，充分挖掘多核 CPU 的并行计算能力，从而显著提升查询性能。
优势
- 性能好：
- 写入性能好，Broker Load 导入速度 170W+/s
- 读性能好，大单表以及多表关联查询性能均优于 ClickHouse
- 易运维：
- 只有 FE、BE、Broker 节点，架构简单
- 新建集群简单，正常只创建 FE、BE 角色即可
- 扩容、缩容简单，一条命令即可扩缩容，自动均衡数据
- 数据接入方便
- 多种导入途径，例如 Broker Load(数据源HDFS)、Routine Load(数据源 Apache Kafka)、Stream Load(数据源本地文件)、外表(数据源 MySQL、TiDB、ES、Hive 等)、Flink、 DataX 等
- 58 已经支持多种导入途径
- 支持、兼容 MySQL 协议
- 无需更改 SQL，直接可以使用，迁移方便
- 表支持多种模型：
- 支持明细模型，聚合模型，更新模型，主键模型，可以满足业务的明细查询、聚合查询以及数据更新的需求
- 高并发：
- 支持高并发查询
2、基于满足 AP 分析需求的评测
大致评测方向，从两方面来看，一个是功能上，一个是性能上。StarRocks、ClickHouse、TiDB&TiFalsh 每种数据库都有各自的特点。
功能
性能
此处引用的测试版本比较低了，根据社区小伙伴以及我们自己内部的测试，StarRocks 新版本比老的版本，性能提升明显，后面会再进行一次整体的对比测试，敬请期待~
测试基本信息：
性能测试结论：
- 单表/多表查询，StarRocks 总体时间均最短
- 单表查询：StarRocks 最快次数最多，ClickHouse 次之
- 多表查询：StarRocks 所有执行均最快
- TiDB/TiFlash 总体时间单表/多表查询均最长
- TiDB 执行计划多数走 TiKV，导致执行时间长，且数据量越多，执行时间越长
- TiDB 强制走 TiFlash，单表多数提速多，多表多数变慢，但 4.0.10/5.0.1 版本的执行计划多数不走
- ClickHouse 多表查询需要更改 SQL，使类型一致才可以，且字段名、表名区分大小写
- ClickHouse 大单表查询方式效率较好，多表关联效率降低明显
- ClickHouse 分布式表 Join 比全本地单表 Join 的查询快
- ClickHouse 小表不推荐使用分布式表 Join，只大表进行分布式表 Join，执行时间均变短
单表查询对比
多表关联查询
低基数查询性能对比
StarRocks 2.0 版本引入低基数优化后，与 ClickHouse 的 SQL 查询性能对比。
基本信息：
结论：
StarRocks 1.19.5 无低基数字典优化，平均执行性能：是 ClickHouse 单实例的 3.18倍，是 ClickHouse 分布式的 1.23 倍
StarRocks 2.0.1 未启用低基数字典优化，平均执行性能：是 ClickHouse 单实例的 3.09 倍，是 ClickHouse 分布式的 1.20 倍
StarRocks 2.0.1 启用低基数字典优化，平均执行性能，是 ClickHouse 单实例的 7.05 倍，是 ClickHouse 分布式的 2.73 倍
总体来看，在分布式对等条件下，StarRocks 1.19.5 和 2.0.1 未开启低基数优化时，性能略优于 ClickHouse，在开启低基数优化后，StarRocks 性能明显提升，是 ClickHouse 的 2-3 倍。
#02
业务实践
—
目前 StarRocks 已经应用到了所有业务线，涉及日志流水、用户画像、安全分析、DBA 慢 SQL、实时数仓，报表系统、监控数据、风控数据分析等场景，很好地支撑了业务需求。业务类型比较多，以下面三个业务为例：
1、安全分析相关业务
每天服务器上的信息情况，是内部安全人员比较关心的，但是服务器上每天有大量的信息，如何能快速收集落地，统一实时分析呢？
- 写入的量上的要求，每天大约几亿的数据需要落地
- 实时分析：快速的分析，例如：最近 15 分钟，机器信息的情况是怎样的？
- 定期数据清理
- 数量累增
因为写入量大及快速分析的需求，我们选择了 StarRocks。在使用初期，我们使用了明细模型，20 天左右，数据量就 800 亿+了，磁盘 8T 左右，导致一定的性能影响，后与开发方商定，不需要存储详细的历史明细，记录指定时间的汇总数量即可，于是改成聚合模型，每 15 分钟进行聚合，次数累增，这样就大幅减少了数据量，并且数据按照时间分区，定期清理分区即可，方便了数据清理且方便了查询。目前每天 10 亿左右数据，数据量降低了 75%。
2、DBA 内部业务
MySQL 中间件我们使用的是 ProxySQL，ProxySQL 支持展示 SQL 情况，但是每次需要重置，才重新开始统计，比较麻烦。如何分析指定时间的 SQL 情况，比较困扰。每个 ProxySQL 有自己的全日志，我们可以分析全日志来获取需要的信息。第一个架构方案，我们想到了 ElasticSearch，ProxySQL全日志-->filebeat采集-->Kafka-->logstash-->ElasticSearch，但是实际使用，发现查看流水可以，但是分析起来就比较麻烦，不如写 SQL 方便。后来架构又改成了 ProxySQL 全日志-->filebeat采集-->Kafka-->StarRocks，这样就可以利用 SQL 进行快速分析了。
另一个问题，因为线上的 ProxySQL 的日志量特别大，不能所有集群都开，我们设置了可以选择开启，这样有需要的集群才进行分析，降低了存储的压力。
举例：分析某 30 分钟某集群的 SQL 执行情况，按照次数排序，查询很快。
3、业务报表
某部门的报表系统底层存储使用的是自己搭建的数据库，为 Infobright，这是一款基于知识网格的列式数据库，对大批量数据的查询性能非常高。
但是公司要进行成本节约，不允许再申请机器了，且业务需要自己维护数据库，所以需要有一个由运维团队支持运维且性能更好的数据库产品进行替代。使用 StarRocks，在性能上提升明显，之前千万级别的表的查询在 2s+，当前查询在300ms 左右，查询平均提升 90% 以上。目前业务整体已经迁移了 80%，已经迁移表 700张+。既减少了运维压力，又提升了查询性能。
#03
管理实践
—
58 内部使用的 StarRocks 经历了多个版本，从 1.11 到 2.2.3 版本，每次新版本的发布都会带来一定的性能提升、bug 修复。在版本上，推荐大家按需升级到最新的版本比较好，优先升级不太重要的业务的集群，分批逐步升级。
1、拓扑工具
如何快速知道一个 StarRocks 集群的拓扑，需要有方便展示的工具。我们开发了qstarrocks 工具，此工具跟元信息架构紧密相连的，大家逐层设计好元信息表即可，例如集群信息表，实例信息表，业务线信息表，库信息表，负责人信息表，域名信息表，vip 信息表等，大家参考各自公司的实际情况实现即可。
功能支持：
- 支持集群拓扑信息展示，包括：角色、IP、Port、机房、Domain、VIP、业务线、负责人、重要性、创建时间、监控地址等
- 支持快速登录指定 FE，方便日常操作
- 支持集群重点信息展示、集群号、端口、版本、重要性、类型、各节点数量、库数量、磁盘总量、使用量、占比、增速、业务线等
集群拓扑信息展示：
所有集群重点信息展示：
2、集群管理工具
为了应对大量集群的部署、扩缩容、版本升级、开启、管理、维护等管理员操作，需要有一个统一的管理工具，因此我们开发了starrocks_manage工具，支持：
- 部署新集群
- 复用集群
- 添加
- 删除
- 开启
- 停止
- 重启
- 升级
- 信息
- 重新加载配置重启
- 创建账号
- 创建 ETL 域名
3、监控实现
StarRocks 监控分为：存活监控 、性能监控。参考之前 TiDB 的经验，建设分为：
- 存活监控：
- 存活检查工具，方便日常的状态检查
- 存活监控，任务式采集，报警
- 性能监控：
- 根据一定的运维经验，获取重要的监控指标，分为：服务器相关指标、实例相关的指标
- 汇总监控：
- 因为正常部署是一套集群一套监控，要同一地点查看所有集群的重点监控的话，就要汇总到一套 Grafana 上
当前监控工具也可以检查元信息与 Zabbix 的差异 host，并添加/删除节点。
此处为监控的全部架构设计图：
存活监控
存活监控的节点信息获取是来自于数据库的命令：
- SHOW FRONTENDS;
- SHOW BACKENDS;
Prometheus+Grafana 是官方推荐的监控架构，所以我们通过 Prometheus 的接口来获取节点的存活信息，可以从监控项：up 里面获取 FE、BE 节点的存活情况，上报到 DBA 统一监控 Zabbix，利用 Zabbix 发送报警等。
例如：
检查工具实现：
性能监控
prometheus 接口获取重点信息、服务器级别、实例级别信息，上报到 Zabbix，利用 Zabbix 实现性能报警等。
当前已经完成了监控项的采集，具体的监控图展示还在开发中。
4、导入任务管理
在业务使用 StarRocks 时，有多种接入方式，常见的有 Flink、DataX、Kafka、Stream Load 等，其中 Kafka 直接写入是很方便的一种方式，为 Routine Load；
当前已经在运行的 Kafka 任务超过了 120 个，急需一个对 Kafka 导入任务的管理体系。
梳理需求如下：
- 业务人员：工单申请接入 Kafka，简单的引导方式
- DBA：自动化执行 Kafka 工单
- 开发、DBA：查看
- 可查看任务运行状态
- 可查看任务的基本信息
- 非 running 等异常状态，可报警
- 可查看延迟信息及详细的各个 Partition 的延迟信息
- 可查看创建 SQL
- 可查看导入的条数、报错条数等
- 开发：操作
- 可以下线任务
- 可以重建任务
- 可以设置报警接收人员
我们开发了快速查看任务创建 SQL 的工具——qstarrocks，可以通过此命令快速查看任务的状态，创建 SQL，进行快速重建。原理就是利用 show routine load 命令的结果，拼接任务的创建 SQL。
查看集群的所有导入任务状态：
查看创建 SQL：
为了更方便开发、DBA 详细的了解任务的情况，我们又整体设计了任务的管理，并开发了 starrocks_kafka 工具。
此工具整合了多种功能：
- 创建、重建 Kafka 任务
- 查看 Kafka 的状态：运行状态、延迟状态、消费行数等状态
- 查看 Kafka 的具体数据
- 获取创建 SQL
- 监控与报警：DBA 与业务负责人
架构图：
我们自己开发的管理平台，分为用户端与管理端。
用户端-申请 Kafka 接入任务的工单：
用户端-任务展示：
用户端-具体任务展示：基本信息与报错信息
用户端-具体任务展示：监控图
用户端-具体任务展示：创建 SQL
通过开发以上工具和平台，当前可以比较轻松的实现 Kafka 的任务维护，业务同学也可以方便地查看任务的相关信息。
5、慢 SQL 管理
具体实现
在 StarRocks 的日常使用中，我们需要清晰的了解数据库的 SQL 运行效率，展示慢 SQL 的情况，方便 DBA 与开发查看，包括天级别慢 SQL 情况、SQL 实时流水、指定时间汇总展示三部分。
StarRocks 的 SQL 日志格式：
fe/log/fe.audit.log
里面有 2 种日志：[query] 和 [slow_query] ，慢 SQL 我们过滤 slow_query 即可
慢 SQL日志举例如下：
2022-06-08 09:05:49,223 [slow_query] |Client=10.1.1.2:42141|User=default_cluster:xxx|Db=default_cluster:xxx|State=EOF|Time=10|ScanBytes=1339|ScanRows=1|ReturnRows=1|StmtId=43542666|QueryId=edbdd4e3-fd64-11eb-b176-0ab2114db0b3|IsQuery=true|feIp=10.1.1.1|Stmt=SELECT 1|Digest=99fa3a962b9640a78ceb79d81a9e83c0
具体实现：
- 使用通用的日志采集工具，filebeat
- StarRocks作为底层的存储，方便分析
- Kafka接入方式，快速、高效
- SQL指纹方便进行分类
实现架构：
filebeat 过滤采集 --> Kakfa --> StarRocks
查看录入到库里的慢 SQL 结果：
平台展示
集群的天级别慢 SQL 趋势情况：
具体慢 SQL：
实时慢 SQL：
指定时间的汇总：
6、云化实践
StarRocks 使用初期，BE 使用物理机混合部署，FE 使用虚拟机部署，虚拟机公司最高的配置为 8 核 32G 内存 300G 磁盘的，架构图如下：
但是随着业务的使用，我们发现总会有 FE 节点宕掉的情况发生，查看原因为，内存吃满 oom 了，有些是慢 SQL 导致，有些是元信息过大导致的。但是 FE 已经是公司虚拟机最高的配置了，不能再增加了，此时我们就想到了使用 Docker 来部署，于是制定了套餐，以满足不同的业务需求：
FE套餐：
- 8核-32G内存-200G磁盘
- 16核-64G内存-200G磁盘
BE套餐：
- 8核-32G内存-1024G磁盘
- 16核-64G内存-1500G磁盘
- 32核-64G内存-1500G磁盘
- 32核-128G内存-3200G磁盘
云化的集群架构如下：
目前已经使用云化部署的集群已经有 7 套左右了，历史的集群在逐步迁移到云环境上。新的集群默认使用云化环境部署。
其他云化相关管理的工作还在持续开发中，例如云宿主机智能诊断、套餐资源池情况等等，后续会进行分享。
#04
总结和展望
—
我们线上使用 StarRocks 已经近 1 年了，承载了内部多项业务，性能良好，运行稳定，运维方便，很好地满足了 OLAP 场景的需求。
虽然对于开发者来说有一定的学习成本，例如表模型、导入方式选择、查询调优等，但是通过我们开发的内部工具和平台，在一定程度上解决了这些问题，让使用 StarRocks 变得简单。当然，也希望官方能在这几点上持续发力，让大家更加简单和高效地用起来。
未来我们会将更多的业务接入到 StarRocks，高效支撑业务方极速数据分析的需求。
关于 StarRocks
StarRocks 创立两年多来，一直专注打造世界顶级的新一代极速全场景 MPP 数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业全面数字化经营。
当前已经帮助腾讯、携程、顺丰、Airbnb 、滴滴、京东、众安保险等超过 110 家大型用户构建了全新的数据分析能力，生产环境中稳定运行的 StarRocks 服务器数目达数千台。
2021 年 9 月，StarRocks 源代码开放，在 Github 上的星数已超过 3100 个。StarRocks 的全球社区飞速成长，至今已有超百位贡献者，社群用户突破 5000 人，吸引几十家国内外行业头部企业参与共建。
