StarRocks使用时的常见问题 - 开源大数据平台E-MapReduce

本文汇总了StarRocks使用时的常见问题。

硬件资源有什么要求？

整体机器配置
BE推荐16核64 GB以上，FE推荐8核16 GB以上。
生产环境FE通常是16核，32 GB或64 GB内存，200~500 GB NVMe。
磁盘
- HDD和SSD都可以。
- 磁盘容量评估，可以按照压缩比3，磁盘利用率70%~75%作为上限来进行评估。
- 如果导入到SR的数据是Parquet或Orc的Hive数据，则压缩比按照1：1来评估。
  例如，Hive数据是3T，则导入StarRocks的数据也是3T。
CPU
- CPU必须支持AVX2指令集，可以通过cat /proc/cpuinfo |grep avx2命令判断。
- 向量化技术需要配合CPU指令集才能发挥更好地作用，所以没有相关指令集的话建议更换机器。
网络
建议选择万兆网卡和万兆交换机。

软件配置有什么要求？

软件配置的详细的信息，请参见参数配置。

生产环境下的副本数应该设置为多少？

通常生产环境下副本数2~3即可，建议设置为3。

如何分区？

合理的分区可以有效的裁剪scan的数据量。

通常是从业务本身对数据进行管理的角度来选择分区键。例如选用时间或者区域作为分区键。
如果需要自动创建分区，则可以使用动态分区。

如何分桶？

选择高基数的列来作为分桶键，避免Bucket之间数据倾斜。
- 如果有唯一ID，则建议使用唯一ID分桶。
- 如果碰到数据倾斜严重的，则可以使用多列作为分桶键，但通常不要使用太多列作为分桶键。
Tablet的最佳大小可以按下面进行评估，基于以下参数值和总数据量可以预估出Bucket的数目。
- 原始非压缩数据，例如CSV格式，通常每个tablet设置为1 GB ~10 GB之间。
- Parquet格式的数据，建议1 GB左右。
在机器比较少的情况下，如果想充分利用机器资源可以考虑使用BE数量 * cpu core / 2来设置Bucket数量。

如何设计排序键？

排序键要根据查询的特点来设计：

将经常作为过滤条件和Group BY的列作为排序键，可以加速查询。
如果是有大量点查，建议把查询点查的ID放到第一列。
例如，查询命令为select sum(revenue) from lineorder where user_id='aaa100'; ，并且有很高的并发，强烈推荐把user_id作为排序键的第一列。
如果查询的主要是聚合和scan比较多，建议把低基数的列放在前面。
例如，查询命令为select region, nation, count(*) from lineorder_flat group by region, nation，则建议把region作为第一列，nation作为第二列会更合适。

如何合理的选择数据类型？

尽量使用精准的数据类型。例如，能够使用整型就不要使用字符串类型，能够使用int就不要使用bigint，精确的数据类型能够更好的发挥数据库的性能。

当Routine Load出现性能问题时，如何进行参数调优？

参数调优策略

当Routine Load出现性能问题时，您可以考虑从如下几个维度来进行参数调优：

任务调度周期
您可以通过缩短任务调度周期（即修改参数max_batch_interval）加速数据消费。但是，缩短任务调度周期可能会带来更多的CPU资源消耗。
重要
任务调度周期最小值为5s。
任务并行度
在Partition数量和BE数量较多时，您可以调大以下参数来加速任务执行。但是，增加并行度可能会带来更多的CPU资源消耗。
- max_routine_load_task_concurrent_num
- desired_concurrent_number
单个Routine Load任务会根据Kafka Topic Partition数和BE数等被拆分为若干个子任务，分发至多个BE执行。此处的任务并行度，实际上是指单个Routine Load拆分成的子任务个数。
实际的任务并行度参照如下的计算公式。
```
concurrent_num = Min( Min( partition_num, Min( desired_concurrent_num, alive_be_num ) ),Config.max_routine_load_task_concurrent_num )
```
任务批量大小
- routine_load_task_consume_second：通过增大单次读取持续时间加速数据消费。
- max_routine_load_batch_size：通过增大单次读取的数据量加速数据消费。
您可以根据以下日志来判定当前的批量参数设置是否过小。正常情况下，该日志的left_bytes字段应该>=0，表示一次读取的数据量还未超过max_routine_load_batch_size上限。否则，说明max_routine_load_batch_size过小。
```
I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done:
41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190,
received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking
get time(us): 3065086, blocking put time(us): 24855
1
```

Routine Load参数

参数	类型	默认值	描述
max_routine_load_job_num	fe.conf	100	NEED_SCHEDULE、RUNNING、PAUSED状态的routine load任务上限。
max_routine_load_task_concurrent_num	fe.conf	5	单个Routine Load任务的最大并行度。
max_routine_load_task_num_per_be	fe.conf	5	单个BE节点上调度分配的最大Routine Load任务数。
max_routine_load_batch_size	fe.conf	500 MB	最大单次批量读取Kafka数据量。
routine_load_task_consume_second	fe.conf	3	最大单次批量读取Kafka数据时间。
routine_load_task_timeout_second	fe.conf	15	单个Routine Load任务running超时时间。
max_consumer_num_per_group	be.conf	3	单个consumer group最大consumer数。
desired_concurrent_number	properties	3	期望Routine Load任务的并行度。实际的任务并行度参照如下的计算公式`concurrent_num = Min( Min( partition_num, Min(desired_concurrent_num, alive_be_num ) ),Config.max_routine_load_task_concurrent_num )`。
max_batch_interval	properties	10s	Routine Load任务调度周期。
max_batch_rows	properties	200000	该参数只用于定义错误检测窗口范围，窗口的范围是`10 * maxbatch-rows`。
max_error_number	properties	0	采样窗口内，允许的最大错误行数。必须大于等于0。默认是0，即不允许有错误行。重要被where条件过滤掉的行不算错误行。
strict_mode	properties	true	是否开启严格模式，默认为开启。如果开启后，非空原始数据的列类型变换为NULL，则会被过滤。

如何选择数据模型？

StarRocks的数据模型主要有以下四种，您可以根据实际情况选择。

数据模型	适用场景
duplicate key	数据更新不频繁。查询模式灵活没有预聚合的模式。需要保留原始数据。
agg模型	只追加不更新数据。业务方查询都包含聚合函数，例如min、max或sum等。不需要查询原始明细数据。
uniq key	适合于有更新和实时分析的场景。
primary key	适合于有更新和实时分析的场景。如果有部分列更新的场景建议列在200列以内。

StarRocks数据模型count的实现机制是怎么样的？

StarRocks的数据模型主要有四种，分别为duplicate key、uniq key、agg模型和primary key模型，他们对于count的实现有比较大的区别。具体区别如下：

duplicate key：该模型不需要做merge操作，所以count比较快。
uniq key和agg模型：对count操作的实现涉及多版本merge的操作，所以相对要慢一些。
如果key是string类型，则理论上count操作会更慢。
primary key：在读取数据的时候因为有内存中的索引和delete vector，不需要做merge操作，所以count操作比uniq key和agg模型会快些。
如果有更新操作，建议使用该模型。

如何减少`/mnt/disk1/starrocks/storage/trash/`目录磁盘占用？

/mnt/disk1/starrocks/storage/trash/目录中存储的是删除的数据。如果您想减少该目录的磁盘占用，可以通过调小be.conf中的trash_file_expire_time_sec参数，控制trash目录保留时间。默认值是259200（72小时）。

创建物化视图时报错，该如何处理？

问题现象：具体报错如下图所示。
解决方法：
1. 执行命令show proc "/cluster_balance"; 和show proc "/statistic"; 。
2. 查看是否有tablet正在进行rebalance：
  - 如果有，则等待执行完成。
  - 如果没有，则可以执行命令set disable_balance=true，然后发起创建物化视图操作。

数据查询缓慢，如何处理？

建议处理方法如下：

开启Profile，之后在StarRocks UI上查看Profile信息。
执行命令SET is_report_success = true; 开启Profile。
基本排查方法：
1. 调整并行度。
  - Pipeline
```
SET pipeline_dop = 8;
SET enable_pipeline_engine = true;
```
  - 非Pipeline
```
SET enable_pipeline_engine=false;
SET parallel_fragment_exec_instance_num=8;
```
2. 查看tablet分布。
```
show data xxx;
```
  说明
  建议tablet大小在1 GB~10 GB。
3. 查看建表。
  1. 通过Profile判断iotime。如果很大，可以删除一些不必要的索引，例如，删除建得比较多的bitmap索引。
  2. 查看表数据模型，选择合适的数据模型。例如，uniq key模型在compaction没有做完的时候下推无法适用，容易导致查询慢。

为什么8030、8040端口访问失败？

因为EMR Starrocks在EMR-5.8.0及以下版本、EMR-3.42.0及以下版本中load_url的端口号为8030，webserver_port为8040，但在EMR-5.9.0及以上版本、EMR-3.43.0及以上版本中load_url的端口号为18030，webserver_port为18040，所以请根据您的集群版本选择访问的端口。

说明

您可以使用show frontends命令查看实际的端口。

EMR StarRocks支持哪些地域？

目前StarRocks已经全量发布在各个地域。

BE数据盘和数据分布的关系？

目前默认是挂载4块ESSD PL1的云盘，StarRocks会根据负载和分桶机制等将数据均衡分布在各个节点。同一个tablet同一个副本的数据存储在同一块盘。

数据异常，如何重置集群进行恢复？

重要

以下操作会清空集群数据，请慎重操作！

停止集群服务（FE、BE）。
清理FE元数据目录。
1. 查看/opt/apps/STARROCKS/starrocks-current/fe/conf/下的fe.conf文件，获取meta_dir的配置目录。
2. 删除上面配置目录下的bdb文件夹。
3. 清空上面配置目录下的image文件夹。
清空BE数据和元数据。
1. 查看/opt/apps/STARROCKS/starrocks-current/be/conf/下的be.conf文件，获取storage_root_path的配置目录。
2. 删除上面配置目录下除data和meta之外的文件夹和文件。
3. 清空上面配置目录下的data和meta文件夹。
说明
上面的配置可能会有多个路径，需要在每个路径下都进行操作。
重启集群服务（FE、BE）。

如何查看日志？

日志目录通常在以下路径：

FE
- /opt/apps/STARROCKS/starrocks-current/fe/log/
- /mnt/disk1/log/starrocks/
BE
- /opt/apps/STARROCKS/starrocks-current/be/log/
- /mnt/disk1/log/starrocks/

为什么Task节点扩容后未参与计算？

问题描述

对StarRocks集群进行了弹性扩容，添加三个Task节点后，这些节点被分配到了Compute Node（CN），未能自动执行计算任务。尽管现有BE节点承受高负载，新加入的Task节点却未得到充分利用，监控数据显示它们的负载一直很低。

原因分析

在存算一体的架构下，StarRocks集群的CN节点仅支持对外部表的查询。因此，如果应用场景主要涉及到内表查询，这些查询任务通常由BE节点处理，导致新增的CN节点未得到充分利用。

解决方案

在查询任务执行前，通过执行以下SQL命令来设置CN节点优先执行。

SET GLOBAL prefer_compute_node=true;