StarRocks调优 - Broker Load导入

Broker Load是StarRocks离线导入方式，用于将存储在HDFS、S3、OSS等外部存储的数据导入到StarRocks，支持CSV、ORCFile、Parquet等文件格式，适用于几十GB到上百GB的数据导入。

Broker Load通过Broker进程访问远端存储，因此使用Broker Load前需要搭建好Broker。Broker的搭建分为三步：

1、切换到StarRocks的安装目录下，进入apache_hdfs_broker/conf目录

可根据需要修改broker配置，另外，如果要访问HDFS，需要将hdfs-site.xml拷贝到conf目录下

2、启动Broker

$ cd $STARROCKS_HOME/apache_hdfs_broker
$ bin/start_broker.sh --daemon

3、添加Broker节点到集群中，并确认启动成功，如果Alive为false，到log下查看具体报错信息并修复后重启

MySQL> ALTER SYSTEM ADD BROKER broker1 "192.168.1.10:8000";
MySQL> SHOW PROC "/brokers" G
*************************** 1. row ***************************
          Name: broker1
            IP: 192.168.1.10
          Port: 8000
         Alive: true
 LastStartTime: 2022-01-19 19:08:35
LastUpdateTime: 2020-0-19 19:08:45
        ErrMsg: 
1 row in set (0.00 sec)

在这里，broker1是个组的概念，可以将多个broker加入到同一个分组中。

机器规格：16c 64 G , 1x 5T, 3节点，阿里云

StarRocks：1FE + 3BE，其中有一台FE和BE混部

测试数据集：选用ClickHouse官网的Anonymized Yandex.Metrica Data

https://datasets.clickhouse.com/hits/tsv/hits_100m_obfuscated_v1.tsv.xz

本次测试Parquet的导入性能，因而将其转化为Parquet格式后进行测试。

上述tsv文件解压后大小为70G，转换为Parquet后大小为14G，将其上传到hdfs。

1、1 Broker 参数默认

创建Broker Load导入任务：

LOAD LABEL testdb.hits_1broker
(
    DATA INFILE("hdfs://192.168.1.10:9002/test/hits.parquet")
    INTO TABLE hits
)
WITH BROKER 'broker1'
PROPERTIES
(
    "timeout" = "3600"
);

运行结果：耗时12min15s，导入速度：136054条/s，19.5M/s

2、1 Broker，修改FE配置文件设置单个BE上的并发实例数：load_parallel_instance_num=8

运行结果：耗时12min18s，与并行度为1差不多

3、将broker增加到3个，分别设置不同的并发实例数，导入耗时接近。

对于Broker Load来说，csv/tsv文件可以自动做切分，分配给多个broker并行处理，而orc和parquet只能给一个broker，所以在测试时，增加broker并不能提升导入性能。同样，提升并行度也没有提升导入性能，在BE节点找到对应导入的profile：

File Scan速度很快，Sink端较慢，因而调整BE参数：olap_table_sink_send_interval_ms=1，减小轮询发送等待时间，总体导入时间缩短到9min左右。

将上述数据集拆分成10个parquet文件，每个大小1.3G左右，创建Broker Load导入任务：

MySQL> LOAD LABEL testdb.hits_3broker_paral1_interval1
(
    DATA INFILE("hdfs://192.168.1.10:9002/test/hits/*.parquet")
    INTO TABLE hits
)
WITH BROKER 'broker1'
PROPERTIES
(
    "timeout" = "3600"
);

1、1broker导入，参数默认

运行结果：耗时10min39s

2、1broker导入，load_parallel_instance_num=8

运行结果：耗时8min7s

3、1broker导入，olap_table_sink_send_interval_ms=1

运行结果：耗时5min12s

4、1broker导入，load_parallel_instance_num=8，olap_table_sink_send_interval_ms=1

运行结果：耗时4min15s

可以，将文件拆分后，提高并行度能提高导入性能，同时，减小轮询发送等待时间，导入性能进一步提升。

5、将broker增加到3个，load_parallel_instance_num=1，olap_table_sink_send_interval_ms=1

运行结果：耗时5min9s 

6、将broker增加到3个，load_parallel_instance_num=8，olap_table_sink_send_interval_ms=1

运行结果：耗时4min27s

可见，在并行度提高，轮询等待时间减小后，增加broker并不能提升导入性能，因为broker只是负责读取数据，而在本次测试中文件数据量较少，数据读取本身不存在瓶颈。

本文介绍了Broker Load的基本使用，并使用较少的数据对性能进行了测试以及调优。当然，实际使用场景可能会更加复杂，对于并行度以及等待时间的调整，需要结合BE/Broker的数量、机器配置、数据情况等，结合导入profile的分析，进行针对性的优化。

对Broker Load导入的测试也可以参考58的测试报告：StarRocks的 broker load导入性能测试 - 评测报告 - StarRocks数据库论坛