文档

常见问题

更新时间:

本文汇总了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 3.x版本存算分离

EMR StarRocks 3.x默认为存算一体模式,暂不支持存算分离,如果您需要使用存算分离模式,请提交工单处理。

  • 本页导读 (1)
文档反馈