本文汇总了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任务的并行度。实际的任务并行度参照如下的计算公式 |
max_batch_interval | properties | 10s | Routine Load任务调度周期。 |
max_batch_rows | properties | 200000 | 该参数只用于定义错误检测窗口范围，窗口的范围是 |
max_error_number | properties | 0 | 采样窗口内，允许的最大错误行数。必须大于等于0。默认是0，即不允许有错误行。 重要 被where条件过滤掉的行不算错误行。 |
strict_mode | properties | true | 是否开启严格模式，默认为开启。如果开启后，非空原始数据的列类型变换为NULL，则会被过滤。 |
如何选择数据模型？
StarRocks的数据模型主要有以下四种，您可以根据实际情况选择。
数据模型 | 适用场景 |
duplicate key |
|
agg模型 |
|
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小时）。
创建物化视图时报错，该如何处理？
问题现象：具体报错如下图所示。
解决方法：
执行命令
show proc "/cluster_balance";和show proc "/statistic";。查看是否有tablet正在进行rebalance：
如果有，则等待执行完成。
如果没有，则可以执行命令
set disable_balance=true，然后发起创建物化视图操作。
数据查询缓慢，如何处理？
建议处理方法如下：
开启Profile，之后在StarRocks UI上查看Profile信息。
执行命令
SET is_report_success = true;开启Profile。基本排查方法：
调整并行度。
Pipeline
SET pipeline_dop = 8; SET enable_pipeline_engine = true;非Pipeline
SET enable_pipeline_engine=false; SET parallel_fragment_exec_instance_num=8;
查看tablet分布。
show data xxx;说明建议tablet大小在1 GB~10 GB。
查看建表。
通过Profile判断iotime。如果很大，可以删除一些不必要的索引，例如，删除建得比较多的bitmap索引。
查看表数据模型，选择合适的数据模型。例如，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元数据目录。
查看
/opt/apps/STARROCKS/starrocks-current/fe/conf/下的fe.conf文件，获取meta_dir的配置目录。删除上面配置目录下的bdb文件夹。
清空上面配置目录下的image文件夹。
清空BE数据和元数据。
查看
/opt/apps/STARROCKS/starrocks-current/be/conf/下的be.conf文件，获取storage_root_path的配置目录。删除上面配置目录下除data和meta之外的文件夹和文件。
清空上面配置目录下的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/
如何使用StarRocks的存算分离模式？
EMR on ECS形态下的StarRocks不支持存算分离模式。如果您需要使用存算分离模式，请购买EMR Serverless StarRocks。有关存算分离的详细信息，请参见快速使用存算分离版实例。
为什么Task节点扩容后未参与计算？
问题描述
对StarRocks集群进行了弹性扩容，添加三个Task节点后，这些节点被分配到了Compute Node（CN），未能自动执行计算任务。尽管现有BE节点承受高负载，新加入的Task节点却未得到充分利用，监控数据显示它们的负载一直很低。
原因分析
在存算一体的架构下，StarRocks集群的CN节点仅支持对外部表的查询。因此，如果应用场景主要涉及到内表查询，这些查询任务通常由BE节点处理，导致新增的CN节点未得到充分利用。
解决方案
在查询任务执行前，通过执行以下SQL命令来设置CN节点优先执行。
SET GLOBAL prefer_compute_node=true;