AI 助理
备案控制台
官方文档
输入文档关键字查找
首页 开源大数据平台 E-MapReduce EMR on ECS 操作指南 组件操作 StarRocks 常见问题

常见问题

更新时间：
产品详情
我的收藏

本文汇总了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小时）。

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

  • 问题现象：具体报错如下图所示。error

  • 解决方法：

    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同一个副本的数据存储在同一块盘。

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

重要

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

  1. 停止集群服务（FE、BE）。

  2. 清理FE元数据目录。

    1. 查看/opt/apps/STARROCKS/starrocks-current/fe/conf/下的fe.conf文件，获取meta_dir的配置目录。

    2. 删除上面配置目录下的bdb文件夹。

    3. 清空上面配置目录下的image文件夹。

  3. 清空BE数据和元数据。

    1. 查看/opt/apps/STARROCKS/starrocks-current/be/conf/下的be.conf文件，获取storage_root_path的配置目录。

    2. 删除上面配置目录下除data和meta之外的文件夹和文件。

    3. 清空上面配置目录下的data和meta文件夹。

    说明

    上面的配置可能会有多个路径，需要在每个路径下都进行操作。

  4. 重启集群服务（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;

如何查看StarRocks集群的密码？

StarRocks集群的密码是您在创建集群时为root账户设置的。如果您忘记了密码，可以重置集群登录密码，详情请参见如何重置集群登录密码？

上一篇：基于实时计算Flink使用CTAS&CDAS功能同步MySQL数据至StarRocks下一篇：ClickHouse