共计 7328 个字符，预计需要花费 19 分钟才能阅读完成。
作者：刘春雷，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 人，吸引几十家国内外行业头部企业参加共建。
