StarRocks 内表导入性能波动分析与优化

问题背景

为了加速数据即席查询,需要将离线 Hive 表数据通过 ETL 写入 StarRocks 内表,采用 INSERT INTO 按天分区导入数据。Hive 表各分区数据量相差不大,但导入耗时在 3~20 分钟之间波动。初步排查通过监控集群 CPU、内存、磁盘 IO 和网络 IO,未发现明显瓶颈。查看BE compaction score也是在一个合理的范围内。进一步检查 Hive 表各分区数据量,确认数据量级一致,排除数据量差异导致的耗时问题。源码分析(StarRocks-3.4.0)通过分析 INSERT INTO 任务的执行计划(EXPLAIN),发现查询计划生成一个 PlanFragment,包含 HdfsScanNode 和 OlapTableSink,表示从 Hive 表读取数据并直接写入 StarRocks 内表,无复杂中间算子。数据通过内存从 HdfsScanNode 传递到 OlapTableSink,由 Pipeline 驱动器协调。因此,瓶颈可能出现在 OlapTableSink。BE 发送端发送端逻辑如下:

  1. IndexChannel → NodeChannel(通过 _request_queue 发送请求)→ 调用 brpc 的 _stub->tablet_writer_add_chunks。

    负责将输入的数据块 Chunk 发送到对应的 tablet ,根据输入数据块 Chunk 的分区键值,为每行数据分配目标分区(partitions)和 tablet(indexes),将数据块 Chunk 中的指定行添加到当前节点通道的缓冲区,处理数据过滤、打包,并根据缓冲区状态决定是否发送 RPC 请求到目标存储节点 BE。

  2. 根据输入数据块(Chunk)的分区键值,为每行数据分配目标分区和 tablet,计算哈希值:

BE 接收端接收端流程如下:

  1. internal_service.cpp::tablet_writer_add_chunks → load_channel_mgr::add_chunks → load_channel::add_chunks → tablet_channel::add_chunk。

  2. 数据通过 AsyncDeltaWriter 异步写入 MemTable,内存表满时由 memtable_flush_executor 异步刷盘到持久化存储。

    BE内部会有服务用来接收RPC请求,该流程从 tablet_writer_add_chunks 接收外部数据块开始,经过LoadChannelMgr和LoadChannel 的任务分发,路由到 TabletChannel 进行 tablet 级处理。通过 AsyncDeltaWriter 的异步调度,数据被写入MemTable,并在内存表满时由 memtable_flush_executor 异步刷盘到持久化存储。

瓶颈分析

  1. 数据倾斜排查

    最初怀疑是分桶键设置不合理导致数据倾斜。通过 SHOW TABLET FROM tablet_xx DESC RowCount 查看分桶数据量,确认存在一定不均衡,但最大数据量的 tablet 写入速度并非最慢。分析 BE 的 LocalTabletsChannel 日志显示,所有 TabletChannel 持续写入数据,排除分桶键导致的倾斜问题。

  2. 发送端数据不均衡

    进一步分析发现,发送端 tablet_sink_sender 在各 BE 上的数据量差异较大,处理数据量最多的 sender 耗时最长。需要注意的是,这里的数据不均衡是指经过分桶键hash前的数据不均衡。由于任务在一个 PlanFragment 中,问题可能出在 HdfsScanNode 的数据分配。

  3. 任务分配问题

    而执行计划构建和任务分配由FE 完成,流程为:InsertPlanner.plan() → 构建 LogicalPlan → 构建 ExecPlan → DefaultCoordinator 调度。通过DefaultCoordinator 把任务分片分配到不同的BE上。由于scan 的是一张hive表,数据分片的分配逻辑在 HDFSBackendSelector在 forceReBalance = false 且 enableDataCache = false 的情况下,reBalanceScanRangeForComputeNode 方法直接选择一致性哈希环的首个候选节点,不考虑负载均衡:上述逻辑导致数据分配完全依赖哈希映射,未强制平衡数据量(未限制数据量超出 avgNodeScanRangeBytes * 1.1)。

优化措施设置 hdfs_backend_selector_force_rebalance=true,强制重新平衡数据分配。优化后,导入耗时从 19 分钟+缩短至 3 分钟+,显著提升性能。

优化前

优化后 更多大数据干货,欢迎关注我的微信公众号---BigData共享

相关推荐
A-刘晨阳40 分钟前
时序数据库选型指南:从大数据视角切入,聚焦 Apache IoTDB
大数据·apache·时序数据库·iotdb
汤姆yu40 分钟前
基于大数据的短视频流量数据分析与可视化
大数据·数据挖掘·数据分析
Ribou42 分钟前
Elasticsearch 9.2.0 三节点集群配置
大数据·elasticsearch·搜索引擎
啊吧怪不啊吧2 小时前
SQL之表的时间类内置函数详解
大数据·服务器·数据库·sql
TDengine (老段)3 小时前
TDengine 产品组件 taosX
大数据·数据库·物联网·时序数据库·iot·tdengine·涛思数据
字节数据平台3 小时前
火山引擎发布Data Agent新能力,推动用户洞察进入“智能3.0时代”
大数据·人工智能
TDengine (老段)3 小时前
TDengine 字符串函数 CHAR_LENGTH 用户手册
大数据·数据库·时序数据库·tdengine·涛思数据
TDengine (老段)4 小时前
TDengine 数学函数 CRC32 用户手册
java·大数据·数据库·sql·时序数据库·tdengine·1024程序员节
数智顾问4 小时前
(111页PPT)大型集团IT治理体系规划详细解决方案(附下载方式)
大数据·人工智能
geneculture4 小时前
官学商大跨界 · 产学研大综合:融智学新范式应用体系
大数据·人工智能·物联网·数据挖掘·哲学与科学统一性·信息融智学