一、StarRocks介绍
-
StarRocks简介
StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理,就可以用 StarRocks 来支持多种数据分析场景的极速分析。
StarRocks 架构简洁,采用了全面向量化引擎,并配备全新设计的 CBO (Cost Based Optimizer) 优化器,查询速度(尤其是多表关联查询)远超同类产品。
StarRocks 能很好地支持实时数据分析,并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图,进一步加速查询。
使用 StarRocks,用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。
StarRocks 兼容 MySQL 协议,支持标准 SQL 语法,易于对接使用,全系统无外部依赖,高可用,易于运维管理。StarRocks 还兼容多种主流 BI 产品,包括 Tableau、Power BI、FineBI 和 Smartbi。
-
适用场景
大数据、报表平台、数据汇总层等
二、StarRocks技术规范
-
版本规范
-
StarRocks 版本规范:
- StarRocks 的二进制包的名称格式为
StarRocks-{Version}-{OS}-{ARCH}.tar.gz,其中Version表示版本号(例如3.3.3),OS表示操作系统(包括centos和ubuntu),ARCH表示 CPU 架构(目前仅支持amd64,相当于 x86_64)。请确保选择了正确版本的发行包。 - 推荐版本: 新增集群推荐使用最新的Stable 版本如(Stable)3.1 或2.5,持续包含对应分支的 Bug 修复,稳定性更高。
- StarRocks 的二进制包的名称格式为
-
架构规范
存算一体架构
推荐场景:
-
性能需求极高的场景:由于计算节点和存储节点在同一硬件上,数据传输延迟极低,可以提供极快的查询响应速度,适合对实时性要求高的业务场景。
-
数据局部性优化:存算一体可以最大化数据局部性,减少网络传输,提升查询效率,尤其适用于数据密集型的查询。
-
管理简便:物理部署更简单,运维成本相对较低,因为计算和存储的扩展都是同步进行的。
存算分离架构
推荐场景:
-
灵活的资源扩展:存算分离架构允许独立扩展计算和存储资源,适合于存储需求和计算需求不均衡增长的场景。
-
云环境和大数据生态兼容性:存算分离架构更适合云环境,可以利用云服务提供的弹性计算和存储服务。同时,它也适用于需要与Hadoop、S3等大数据生态系统集成的场景。
-
高可用性和灾难恢复:在存算分离的架构中,更容易实现高可用性和灾难恢复策略,存储可以在多个地理位置冗余,而计算节点可以根据需要动态地调整和恢复。
-
路径要求规范
安装路径:
/opt/StarRocks/数据路径:
/data/StarRocks/data多块盘数据路径如下:
/data1/SR/data; /data2/SR/data; /data3/SR/data日志路径:
/data/StarRocks/logs/系统服务配置文件:
/usr/lib/systemd/system/StarRocks-server.service
-
分片、副本规范
分片数是指一个表的数据被水平切分的份数。分片数的选择依赖于数据的总量和查询的并行度。通常,分片数可以按照以下原则来设置:
- 数据量: 每个分片建议处理 10GB 到 50GB 的数据。
- 并行度: 分片数等于集群中的 BE(Backend)节点数,以便充分利用集群的并行处理能力。
副本数量决定了数据的冗余度和可用性,默认配置3个副本数。
三、资源规格
-
节点数量
StarRocks 主要由两种类型的组件组成:FE 节点和 BE 节点。每个节点必须单独部署在物理机或虚拟机上。
对于 StarRocks 生产集群,建议至少部署三个 Follower FE 节点,以防止单点故障。Leader FE 会从 Follower FE 中自动选出。
如果应用程序会产生高并发查询请求,可以在集群中添加 Observer FE 节点。Observer FE 节点只负责处理查询请求,不会参与 Leader FE 节点的选举。
对于 StarRocks 生产集群,建议至少部署三个 BE 节点,这些节点会自动形成一个 BE 高可用集群,避免由于发生单点故障而影响数据可靠性和服务可用性。
可以通过增加 BE 节点的数量来实现查询的高并发。
-
性能资源评估
通常,FE 服务不会消耗大量的 CPU 和内存资源。建议为每个 FE 节点分配 8 个 CPU 内核和 16 GB RAM。
与 FE 服务不同,如果应用程序需要在大型数据集上处理高度并发或复杂的查询,BE 服务可能会使用大量 CPU 和内存资源。因此,建议为每个 BE 节点分配 16 个 CPU 内核和 64 GB RAM。
由于 FE 节点仅在其存储中维护 StarRocks 的元数据,因此在大多数场景下,每个 FE 节点只需要 100 GB 的 HDD 存储。
StarRocks 集群需要的总存储空间同时受到原始数据大小、数据副本数以及使用的数据压缩算法的压缩比的影响。
可以通过以下公式估算所有 BE 节点所需的总存储空间:
BE 节点所需的总存储空间 = 原始数据大小 * 数据副本数/数据压缩算法压缩比
原始数据大小 = 单行数据大小 * 总数据行数
建议配置内存相关配置项
| 名称 | 默认值 | 说明 |
|---|---|---|
| mem_limit | 90% | BE 进程内存上限。可设为比例上限(如 "80%")或物理上限(如 "100G")。默认硬上限为 BE 所在机器内存的 90%,软上限为 BE 所在机器内存的 80%。如果 BE 为独立部署,则无需配置,如果 BE 与其它占用内存较多的服务混合部署,则需要合理配置。 |
| load_process_max_memory_limit_bytes | 107374182400 | 单节点上所有的导入线程占据的内存上限,取 mem_limit * load_process_max_memory_limit_percent / 100 和 load_process_max_memory_limit_bytes 中较小的值。如导入内存到达限制,则会触发刷盘和反压逻辑。 |
| load_process_max_memory_limit_percent | 30 | 单节点上所有的导入线程占据的内存上限比例,取 mem_limit * load_process_max_memory_limit_percent / 100 和 load_process_max_memory_limit_bytes 中较小的值,导入内存到达限制,会触发刷盘和反压逻辑。 |
| compaction_max_memory_limit | -1 | 所有 Compaction 线程的最大内存使用量,取 mem_limit * compaction_max_memory_limit_percent/100 和 compaction_max_memory_limit 中较小的值,-1 表示没有限制。当前不建议修改默认配置。Compaction 内存到达限制,会导致 Compaction 任务失败。 |
| compaction_max_memory_limit_percent | 100 | 所有 Compaction 线程的最大内存使用百分比,取 mem_limit * compaction_max_memory_limit_percent / 100 和 compaction_max_memory_limit 中较小的值,-1 表示没有限制。当前不建议修改默认配置。Compaction 内存到达限制,会导致 Compaction 任务失败。 |
| disable_storage_page_cache | FALSE | 是否开启 PageCache。开启 PageCache 后,StarRocks 会缓存最近扫描过的数据,对于查询重复性高的场景,会大幅提升查询效率。true 表示不开启。该配置项与 storage_page_cache_limit 配合使用,在内存资源充足和有大数据量 Scan 的场景中启用能够加速查询性能。自 2.4 版本起,该参数默认值由 TRUE 变更为 FALSE。 自 3.1 版本开始,该参数由静态变为动态。 |
| storage_page_cache_limit | 20% | BE 存储层 page 缓存可以使用的内存上限。 |
| chunk_reserved_bytes_limit | 2147483648 | 用于加速小块内存分配的 Cache,默认上限为 2GB。可以在内存资源充足的情况下打开。 |
| consistency_max_memory_limit_percent | 20 | 一致性校验任务使用的内存上限,取 mem_limit * consistency_max_memory_limit_percent / 100 和 consistency_max_memory_limit 中较小的值。内存使用超限,会导致一致性校验任务失败。 |
| consistency_max_memory_limit | 10G | 一致性校验任务使用的内存上限,取 mem_limit * consistency_max_memory_limit_percent / 100 和 consistency_max_memory_limit 中较小的值。内存使用超限,会导致一致性校验任务失败。 |
| memory_limitation_per_thread_for_schema_change | 2 | 单个 Schema Change 任务的内存使用上限,内存使用超限,会导致 Schema Change 任务失败。 |
| max_compaction_concurrency | -1 | Compaction 线程数上限(即 BaseCompaction + CumulativeCompaction 的最大并发)。该参数防止 Compaction 占用过多内存。 -1 代表没有限制。0 表示不允许 compaction。 |
-
服务器选型
部署 StarRocks 集群虚拟机或者物理机选择
- 如果应用场景需要快速部署、灵活性高、成本敏感,或者是处于开发,测试阶段,或者小中型生产环境,建议使用虚拟机部署。
- 如果应用场景对性能要求极高,如大规模数据处理和分析, I/O 密集型的数据库操作中,且对硬件资源的控制和配置有特别需求,建议使用物理机。
- BE建议使用物理机,FE可虚机可物理机。
- FE和BE建议分开,需求量小或者预算低,可以接入“大平层”的starrocks集群。
配置建议表:
| 并发量 | FE节点数 | FE配置参数 | BE节点数 | BE配置参数 | BE节点挂盘 | 服务器类型 |
|---|---|---|---|---|---|---|
| 小于100 | 3 | 8C,32G内存 | 3 | 16 C , 64 GB内存 | 单节点最多挂4块2T的硬盘 | 虚拟机 |
| 100-500 并发 | 3 | 16C,64G内存 | 6 | 16 C , 64 GB内存 | 单节点最多挂4块2T的硬盘 | 物理机 / 虚拟机 |
| 大于500并发 | 大于等于5 | 32C,128G内存 | 大于等于10 | 32 C , 128 GB内存 | 单节点最多挂8块4T的硬盘 | 物理机 |
-
混部
SR资源只允许部署SR的服务,不允许非SR服务部署。一台主机最多只能部署一个BE进程和一个FE进程,broker进程除外。
四、部署环境与部署规范
正确设置这些配置项可以确保集群的高可用并提升性能。StarRocks 为不同的服务使用特定的端口。如果在这些实例上部署了其他服务,请检查这些端口是否被占用。
-
前置要求:
-
FE和BE节点需要分开单独部署。
-
FE节点最少是3个节点起步,满足读写HA能力。
-
在用于 FE 部署的实例上,需要检查以下端口:
8030:FE HTTP Server 端口(http_port)9020:FE Thrift Server 端口(rpc_port)9030:FE MySQL Server 端口(query_port)9010:FE 内部通讯端口(edit_log_port)6090:FE 云原生元数据服务 RPC 监听端口(cloud_native_meta_port)
在用于 BE 或者CN 部署的实例上,需要检查以下端口:
9060:BE Thrift Server 端口(be_port)8040:BE HTTP Server 端口(be_http_port)9050:BE 心跳服务端口(heartbeat_service_port)8060:BE bRPC 端口(brpc_port)9070:BE 和 CN 的额外 Agent 服务端口。(starlet_port)
在 FE 实例上执行如下命令查看这些端口是否被占用:
netstat -tunlp | grep 8030
netstat -tunlp | grep 9020
netstat -tunlp | grep 9030
netstat -tunlp | grep 9010
netstat -tunlp | grep 6090
netstat -tunlp | grep 9060
netstat -tunlp | grep 8040
netstat -tunlp | grep 9050
netstat -tunlp | grep 8060
netstat -tunlp | grep 9070
如果上述任何端口被占用,必须在部署 指定可用于替换的端口。
-
主机名
如需为 StarRocks 集群 启用 FQDN 访问,必须为每个实例设置一个主机名。
在每个实例的 /etc/hosts 文件中,必须指定集群中其他实例的 IP 地址和相应的主机名。
注意
/etc/hosts 文件中的所有 IP 地址都必须是唯一。
-
JDK 设置
StarRocks 集群推荐使用 JDK 1.8 版本,StarRocks 的开发和测试主要是基于 JDK 1.8 进行的,因此与该版本的 JDK 具有很好的兼容性。
- StarRocks 依靠环境变量
JAVA_HOME定位实例上的 Java 依赖项。
运行以下命令查看环境变量 JAVA_HOME:
echo $JAVA_HOME
按照以下步骤设置 JAVA_HOME:
- 在 /etc/profile 文件中设置
JAVA_HOME:
sudo vi /etc/profile
将 <path_to_JDK> 替换为 JDK 的安装路径。
export JAVA_HOME=<path_to_JDK>
export PATH=$PATH:$JAVA_HOME/bin
- 使变更生效:
source /etc/profile
运行以下命令验证变更是否成功:
java -version
4. ## 优化系统配置
如果 CPU 支持 Scaling Governor配置项,建议将其设置为 performance 以获得更好的 CPU 性能:
echo 'performance' | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
更新/etc/sysctl.conf配置
cat >> /etc/sysctl.conf << EOF
vm.overcommit_memory=1
vm.swappiness=0
#允许系统重置新连接
net.ipv4.tcp_abort_on_overflow=1
#监听 Socket 队列的最大连接请求数为 1024
net.core.somaxconn=1024
#进程可以拥有的 VMA(虚拟内存区域)的数量
vm.max_map_count = 262144
EOF
sysctl -p
echo 120000 > /proc/sys/kernel/threads-max
echo 200000 > /proc/sys/kernel/pid_max
- 关闭 Swap Space。
swapoff /<path_to_swap_space>
swapoff -a
2. 从 /etc/fstab 文件中删除 Swap Space 信息。
/<path_to_swap_space> swap swap defaults 0 0
可以使用以下命令检查当前使用的调度算法:
cat /sys/block/${disk}/queue/scheduler例如,运行 cat /sys/block/vdb/queue/scheduler
推荐为 SATA 磁盘使用 mq-deadline 调度算法,为 NVMe 或 SSD 磁盘使用 kyber 调度算法。
cat >> /etc/rc.d/rc.local << EOF
echo mq-deadline | sudo tee /sys/block/${disk}/queue/scheduler
EOF
chmod +x /etc/rc.d/rc.local #例子为使用 mq-deadline算法,永久生效
禁用selinux
#临时变更。
setenforce 0
#永久变更。
sed -i 's/SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
sed -i 's/SELINUXTYPE/#SELINUXTYPE/' /etc/selinux/config
关闭防火墙配置
systemctl stop firewalld.service
systemctl disable firewalld.servie
需要使用以下命令手动检查和配置 LANG 变量:
修改配置文件。
echo "export LANG=en_US.UTF8" >> /etc/profile
使修改生效。
source /etc/profile
将时区设置为 /Asia/Shanghai。
cp -f /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
hwclock
最大文件描述符和最大用户进程的值设置得过小,StarRocks 运行可能会出现问题。建议将系统资源上限调大。
cat >> /etc/security/limits.conf << EOF
soft nproc 65535
hard nproc 65535
soft nofile 655350
hard nofile 655350
soft stack unlimited
hard stack unlimited
hard memlock unlimited
soft memlock unlimited
EOF
cat >> /etc/security/limits.d/20-nproc.conf << EOF
soft nproc 65535
root soft nproc 65535
EOF
5. ## NTP服务配置
- 查看 NTP 时间服务器或 Chrony 服务是否存在。
rpm -qa | grep ntp
systemctl status chrony
- 如不存在,运行以下命令安装 NTP 时间服务器。
sudo yum install ntp ntpdate && \
sudo systemctl start ntpd.service && \
sudo systemctl enable ntpd.service
- 检查 NTP 服务。
systemctl list-unit-files | grep ntp
- 检查 NTP 服务连接和监控状态。
netstat -tunlp | grep ntp
- 检查服务是否与 NTP 服务器同步。
ntpstat
6. ## 部署StarRocks集群(存算一体)
准备阶段
- 可选择从 下载 StarRocks 页面直接下载 StarRocks 二进制包,或在终端中运行以下命令获取:
将 替换为想要下载的 StarRocks 版本,例如 3.3.3, 并将 替换为 centos 或 ubuntu。 wget releases.starrocks.io/starrocks/S…--amd64.tar.gz
- 解压二进制包。
将 替换为想要下载的 StarRocks 版本,例如 3.3.3, tar -xzvf StarRocks---amd64.tar.gz
- 二进制包中包含以下路径及文件:
| 路径/文件 | 说明 |
|---|---|
| apache_hdfs_broker | Broker 节点的部署路径。自 StarRocks 2.5 起,无需在一般场景中部署 Broker 节点。 |
| fe | FE 节点的部署路径。 |
| be | BE 节点的部署路径。 |
| LICENSE.txt | StarRocks license 文件。 |
| NOTICE.txt | StarRocks notice 文件。 |
- 将路径 fe 分发至所有 FE 实例,将路径 be 分发至所有 BE 或 CN 实例以用于手动部署。
部署阶段
- 第一步:启动 Leader FE 节点
以下操作在 FE 实例上执行。
- 创建元数据存储路径。建议将元数据存储在与 FE 部署文件不同的路径中。请确保此路径存在并且拥有写入权限。
将 <meta_dir> 替换为要创建的元数据目录。 mkdir -p <meta_dir>
- 进入先前准备好的 StarRocks FE 部署文件路径,修改 FE 配置文件 fe/conf/fe.conf。
- 在配置项
meta_dir中指定元数据路径。
将 <meta_dir> 替换为已创建的元数据目录。 meta_dir = <meta_dir>
- 如果任何在 环境配置清单 提到的 FE 端口被占用,必须在 FE 配置文件中为其分配其他可用端口。
http_port = aaaa 默认值:8030
rpc_port = bbbb 默认值:9020
query_port = cccc 默认值:9030
edit_log_port = dddd 默认值:9010
注意
如需在集群中部署多个 FE 节点,必须为所有 FE 节点分配相同的
http_port。
- 为集群启用 IP 地址访问,必须在配置文件中添加配置项
priority_networks,为 FE 节点分配一个专有的 IP 地址(CIDR格式)。如需为集群启用 FQDN 访问,则可以忽略该配置项。
priority_networks = x.x.x.x/x
说明
可以在终端中运行
ifconfig以查看当前实例拥有的 IP 地址。
-
如果实例安装了多个 JDK,并且要使用 JDK 与环境变量
JAVA_HOME中指定的不同,则必须在配置文件中添加配置项JAVA_HOME来指定所选该 JDK 的安装路径。JAVA_HOME = <path_to_JDK> -
启动 FE 节点。
- 如需为集群启用 IP 地址访问,请运行以下命令启动 FE 节点:
-
./fe/bin/start_fe.sh --daemon - 如需为集群启用 FQDN 访问,请运行以下命令启动 FE 节点::
-
./fe/bin/start_fe.sh --host_type FQDN --daemon
-
查看 FE 日志,检查 FE 节点是否启动成功。
-
使用systemd管理fe服务的启停
#
vi /etc/systemd/system/starrocks_fe.service
[Unit]
Description=starrocks Frontend Service
After=network.target
[Service]
Type=forking
User=root
Group=root
ExecStart=/data/starrocks/fe/bin/start_fe.sh --daemon
ExecStop=/data/starrocks/fe/bin/stop_fe.sh
PIDFile=/data/starrocks/fe/bin/fe.pid
Restart=on-failure
RestartSec=5
LimitNOFILE=1000000
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload 使生效
- 第二步:启动 BE 服务
以下操作在 BE 实例上执行。
- 创建数据存储路径。建议将数据存储在与 BE 部署文件不同的路径中。请确保此路径存在并且拥有写入权限。
将 <storage_root_path> 替换为要创建的数据存储路径。 mkdir -p <storage_root_path>
- 进入先前准备好的StarRocks BE 部署文件所在路径,修改 BE 配置文件 be/conf/be.conf。
- 在配置项
storage_root_path中指定数据存储路径。
将 <storage_root_path> 替换为创建的数据存储路径。 storage_root_path = <storage_root_path>
- 如果任何在环境配置清单 中提到的 BE 端口被占用,必须在 BE 配置文件中为其分配其他可用端口。
be_port = vvvv 默认值:9060
be_http_port = xxxx 默认值:8040
heartbeat_service_port = yyyy 默认值:9050
brpc_port = zzzz 默认值:8060
5. 如需为集群启用 IP 地址访问,必须在配置文件中添加配置项 priority_networks,为 BE 节点分配一个专有的 IP 地址(CIDR格式)。如需为集群启用 FQDN 访问,则可以忽略该配置项。
priority_networks = x.x.x.x/x
6. 如果实例安装了多个 JDK,并且要使用 JDK 与环境变量 JAVA_HOME 中指定的不同,则必须在配置文件中添加配置项 JAVA_HOME 来指定所选该 JDK 的安装路径。 JAVA_HOME = <path_to_JDK>
7. 启动 BE 节点。
./be/bin/start_be.sh --daemon
8. 查看 BE 日志,检查 BE 节点是否启动成功。
cat be/log/be.INFO | grep heartbeat
如果日志打印以下内容,则说明该 BE 节点启动成功:
"I0614 17:41:39.782819 3717531 thrift_server.cpp:388] heartbeat has started listening port on 9050"
9. 在其他 BE 实例上重复以上步骤,即可启动新的 BE 节点。
说明
在一个 StarRocks 集群中部署并添加至少 3 个 BE 节点后,这些节点将自动形成一个 BE 高可用集群。
- 使用systemd管理be进程的启停
vi /etc/systemd/system/starrocks_be.service
[Unit]
Description=starrocks Backend Service
After=network.target
[Service]
Type=forking
User=root
Group=root
ExecStart=/data/starrocks/be/bin/start_be.sh --daemon
ExecStop=/data/starrocks/be/bin/stop_be.sh
PIDFile=/data/starrocks/be/bin/be.pid
Restart=on-failure
RestartSec=5
LimitNOFILE=1000000
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload 使生效
- 第三步:(可选)启动 CN 服务
Compute Node(CN)是一种无状态的计算服务,本身不存储数据。可以通过添加 CN 节点为查询提供额外的计算资源。可以使用 BE 部署文件部署 CN 节点。CN 节点自 v2.4 版本起支持。
- 进入先前准备好的 StarRocks BE 部署文件所在路径,修改 CN 配置文件 be/conf/cn.conf。
- 如果任何在 环境配置清单 中提到的 CN 端口被占用,必须在 CN 配置文件中为其分配其他可用端口。.
be_port = vvvv 默认值:9060
be_http_port = xxxx 默认值:8040
heartbeat_service_port = yyyy 默认值:9050
brpc_port = zzzz 默认值:8060
- 如需为集群启用 IP 地址访问,必须在配置文件中添加配置项
priority_networks,为 CN 节点分配一个专有的 IP 地址(CIDR格式)。如需为集群启用 FQDN 访问,则可以忽略该配置项。.
priority_networks = x.x.x.x/x
2. 由于大部分 CN 参数都继承自 BE 节点。 3. 启动 CN 节点。
./be/bin/start_cn.sh --daemon
注意
- 如需启用 FQDN 访问,在启动 CN 节点之前,请确保已经在 /etc/hosts 中为所有实例分配了主机名。
- 启动 CN 节点时无需指定参数
--host_type。
- 查看 CN 日志,检查 CN 节点是否启动成功。
cat be/log/cn.INFO | grep heartbeat
5. 如果日志打印以下内容,则说明该 CN 节点启动成功: 6. "I0313 15:03:45.820030 412450 thrift_server.cpp:375] heartbeat has started listening port on 9050"
- 在其他实例上重复以上步骤,即可启动新的 CN 节点。
- 第四步:搭建集群
当所有 FE、BE、CN 节点启动成功后,即可搭建 StarRocks 集群。
以下过程在 MySQL 客户端实例上执行。必须安装 MySQL 客户端(5.5.0 或更高版本)。
- 通过 MySQL 客户端连接到 StarRocks。需要使用初始用户
root登录,密码默认为空。
将 <fe_address> 替换为 Leader FE 节点的 IP 地址(priority_networks)或 FQDN,
并将 <query_port>(默认:9030)替换为在 fe.conf 中指定的 query_port。
mysql -h <fe_address> -P<query_port> -uroot
2. 执行以下 SQL 查看 Leader FE 节点状态。
SHOW PROC '/frontends'\G
3. 添加 BE 节点至集群。
-- 将 <be_address> 替换为 BE 节点的 IP 地址(priority_networks)或 FQDN,
-- 并将 <heartbeat_service_port>(默认:9050)替换为在 be.conf 中指定的 heartbeat_service_port。
ALTER SYSTEM ADD BACKEND "<be_address>:<heartbeat_service_port>", "<be2_address>:<heartbeat_service_port>", "<be3_address>:<heartbeat_service_port>";
说明
可以通过一条 SQL 添加多个 BE 节点。每对
<be_address>:<heartbeat_service_port>代表一个 BE 节点。
- 执行以下 SQL 查看 BE 节点状态。
SHOW PROC '/backends'\G
5. 如果字段 Alive 为 true,说明该 BE 节点正常启动并加入集群。
6. (可选)添加 CN 节点至集群。
-- 将 <cn_address> 替换为 CN 节点的 IP 地址(priority_networks)或 FQDN,
-- 并将 <heartbeat_service_port>(默认:9050)替换为在 cn.conf 中指定的 heartbeat_service_port。
ALTER SYSTEM ADD COMPUTE NODE "<cn_address>:<heartbeat_service_port>", "<cn2_address>:<heartbeat_service_port>", "<cn3_address>:<heartbeat_service_port>";
说明
可以通过一条 SQL 添加多个 CN 节点。每对
<cn_address>:<heartbeat_service_port>代表一个 CN 节点。
- (可选)执行以下 SQL 查看 CN 节点状态。
SHOW PROC '/compute_nodes'\G
8. 如果执行查询时需要使用 CN 节点扩展算力,则需要设置系统变量 SET prefer_compute_node = true; 和 SET use_compute_nodes = -1;。
- 第五步:(可选)部署高可用 FE 集群
高可用的 FE 集群需要在 StarRocks 集群中部署至少三个 Follower FE 节点。如需部署高可用的 FE 集群,需要额外再启动两个新的 FE 节点。
- 通过 MySQL 客户端连接到 StarRocks。需要使用初始用户
root登录,密码默认为空。
将 <fe_address> 替换为 Leader FE 节点的 IP 地址(priority_networks)或 FQDN,
并将 <query_port>(默认:9030)替换为在 fe.conf 中指定的 query_port。
mysql -h <fe_address> -P<query_port> -uroot
- 执行以下 SQL 将额外的 FE 节点添加至集群。
-- 将 <new_fe_address> 替换为需要添加的新 FE 节点的 IP 地址(priority_networks)或 FQDN,
-- 并将 <edit_log_port>(默认:9010)替换为在新 FE 节点的 fe.conf 中指定的 edit_log_port。
ALTER SYSTEM ADD FOLLOWER "<new_fe_address>:<edit_log_port>";
说明
- 只能通过一条 SQL 添加一个 Follower FE 节点。
- 如需添加更多的 Observer FE 节点,请执行
ALTER SYSTEM ADD OBSERVER "<fe_address>:<edit_log_port>"。
- 在新的 FE 示例上启动终端,创建元数据存储路径,进入 StarRocks 部署目录,并修改 FE 配置文件 fe/conf/fe.conf。
- 配置完成后,通过以下命令为新 Follower FE 节点分配 helper 节点,并启动新 FE 节点:
说明
向集群中添加新的 Follower FE 节点时,必须在首次启动新 FE 节点时为其分配一个 helper 节点(本质上是一个现有的 Follower FE 节点)以同步所有 FE 元数据信息。
- 如已为集群启用 IP 地址访问,请运行以下命令启动 FE 节点:
将 <helper_fe_ip> 替换为 Leader FE 节点的 IP 地址(priority_networks),
并将 <helper_edit_log_port>(默认:9010)替换为 Leader FE 节点的 edit_log_port。
./fe/bin/start_fe.sh --helper <helper_fe_ip>:<helper_edit_log_port> --daemon
4. 只需在第一次启动节点时指定参数 --helper。
1. 如已为集群启用 FQDN 访问,请运行以下命令启动 FE 节点:
将 <helper_fqdn> 替换为 Leader FE 节点的 FQDN,
并将 <helper_edit_log_port>(默认:9010)替换为 Leader FE 节点的 edit_log_port。
./fe/bin/start_fe.sh --helper <helper_fqdn>:<helper_edit_log_port> \
--host_type FQDN --daemon
5. 查看 FE 日志,检查 FE 节点是否启动成功。
cat fe/log/fe.log | grep thrift
6. 如果日志打印以下内容,则说明该 FE 节点启动成功:
"2022-08-10 16:12:29,911 INFO (UNKNOWN x.x.x.x_9010_1660119137253(-1)|1) [FeServer.start():52] thrift server started with port 9020."
- 重复上述步骤 2、3 和 4 直至启动所有 Follower FE 节点后,通过 MySQL 客户端查看 FE 节点状态。
SHOW PROC '/frontends'\G
7.集群扩容
Fe 扩容步骤:
-
集群健康状态检查
-
-- 检查所有 FE 节点状态 登录FE节点 执行 :mysql -h 172.25.xx.xx -uroot -P9030 -p'xxxxx' SHOW PROC '/frontends'\G 确保现有FE节点Alive=ture 记录Leader 节点地址(IsMaster=true)
-
-
确保版本一致
-
# 在所有节点执行 cat /opt/starrocks/fe/log/fe.log | grep "StarRocks version"
-
-
新节点初始化
-
# 1.1 安装 StarRocks FE wget https://releases.starrocks.io/starrocks-${VERSION}.tar.gz tar -xzf starrocks-${VERSION}.tar.gz cd starrocks-${VERSION}/fe # 1.2 创建元数据目录 mkdir -p /data/starrocks/fe/meta && chmod 755 /data/starrocks/fe/meta # 1.3 修改配置文件 conf/fe.conf vi /opt/starrocks/fe/conf/fe.conf 复制原节点FE的配置文件 meta_dir = /data/starrocks/fe/meta # priority_networks = 10.0.1.0/24 # 新节点 IP 网段
-
-
启动新fe节点
-
# 2.1 首次启动需指定 --helper( 指向 FE的Leader节点IP ) ./bin/start_fe.sh --helper 10.0.1.5:9010 --daemon # 2.2 观察日志 tail -f log/fe.log | grep "transfer from UNKNOWN to FOLLOWER"
-
-
将新节点加入集群
-
sql复制代码 -- 3.1 登录 Leader -- 添加 Follower-- 节点执行: ALTER SYSTEM ADD FOLLOWER "new_fe_host:9010"; -- 添加 Observer-- 或 ALTER SYSTEM ADD OBSERVER "new_fe_host:9010"; 3.2 验证节点状态(Role 应为 FOLLOWER/OBSERVER) SHOW PROC '/frontends'\G
-
-
扩容后验证
-
CREATE DATABASE IF NOT EXISTS scale_test; CREATE TABLE scale_test.tbl (k INT) DISTRIBUTED BY HASH(k); INSERT INTO scale_test.tbl VALUES (1); SELECT * FROM scale_test.tbl; -- 检查元数据同步 SHOW CREATE TABLE scale_test.tbl;
-
五、使用规范
-
数据库设计规范
To do
- 【强制】数据库字符集指定utf-8,并且只支持utf-8。
- 【强制】数据库名称应具有明确的业务含义,建议采用小写字母、数字和下划线的组合,避免使用特殊字符和中文,且命名应简洁明了,易于理解和识别。
- 【建议】根据不同的用户角色和业务需求,合理分配数据库的访问权限。例如,数据分析师可能只需要对数据库进行查询操作,而开发人员可能需要读写权限。通过严格的权限管理,可以确保数据的安全性和完整性。
-
表设计规范
To do
- 【强制】表名同样应遵循小写字母、数字和下划线的命名规则,并且要能够准确反映表中存储的数据内容。
- 【强制】数据目录名、数据库名、表名、视图名、用户名、角色名大小写敏感,列名和分区名大小写不敏感
- 【建议】合理的分区策略可以提高查询性能和数据管理效率。根据数据的特点和查询模式,使用合适的分区策略(如按日期分区)来减少查询扫描的数据量。分区粒度选择:StarRocks 的分区粒度视数据量而定,单个分区原始数据量建议维持在100G以内。
- 【建议】在选择数据类型时,应根据数据的实际范围和精度要求,选择最合适的数据类型,以节省存储空间和提高查询性能。例如,对于表示年龄的字段,使用 TINYINT 类型即可满足需求,而对于存储金额的字段,可以使用 DECIMAL 类型来保证数据的精度。
- 【建议】为每张表定义一个唯一的主键,主键应具有稳定性和唯一性,通常选择业务上具有唯一标识意义的字段作为主键。例如,对于用户表,可以使用用户 ID 作为主键。主键的存在有助于数据的快速定位和关联操作。
- 【建议】分桶数的设置通常也建议以数据量为参考,每个分桶的原始数据建议不要超过5G
- 【建议】值不会变化的时间列可经常用于where过滤,使用该列作为创建分区
- 【建议】有数据淘汰需求的场景建议选择动态分区
- 【强制】数据更新有明显的冷热特征的,必须创建分区,例如经常更新最近一周的数据,可以按天分区。
- 【强制】超过50G或5KW的表建议创建分区
Not to do
-
【强制】单个分区数据量不得超过100GB
-
【强制】KEY列不能使用FLOAT、DOUBLE类型
-
【建议】避免设计过多的冗余列,只保留与业务逻辑密切相关的必要列。同时,要注意列的顺序,将经常一起查询的列放在相邻位置,以提高查询性能。对于一些可能为空的列,要根据实际情况合理设置默认值,以减少数据存储和查询时的处理逻辑。
-
【建议】按需创建分区,不要提前创建大量空分区,避免元数据太多占用FE的内存
-
【强制】非分区表不要使用动态分桶,按照实际数据量估算分桶个数
-
【强制】主键长度不超过128字节
-
【建议】不要使用null属性
-
默认插件
审计日志插件 Startrocks审计日志插件
-
Starrock 管理平台
略
六、监控告警
-
监控对接原则
由于FE和BE的监控指标需要分别抓取,因此监控根据StarRocks节点的角色分开监控。监控和告警规则中都是按照FE和BE的默认端口进行过滤筛选,如果非标StarRocks,监控和告警会匹配失败。
【CMDB与监控】
监控的元数据来自CMDB,如果CMDB中信息不准确, 监控就会出问题。请准确录入CMDB。
FE节点与BE节点按裸资源的形式在CMDB中登记,StarRocks的监控是按FE和BE分开展示,FE有单独的FE监控屏,BE单独一个监控屏。
| 项目 | 说明 | 例子 |
|---|---|---|
| SRV名 | 格式: [sid]-业务线-应用名-starrocks。名字中需要带有“starrocks”关键词 | s1093-adserving-vm-starrocks(后期建议s1093-adserving-vm-starrocks-fe 或 s1093-adserving-vm-starrocks-be) |
| 资源实例 | 裸资源,不能登记为“计算资源” | “裸资源” |
| SR端口 | 使用默认的端口 | FE:8030 BE:8040 |
【规则举例】
FE的指标抓取规则:label_values(up{instance=~".*:8030"},srv)
BE的指标抓取规则:label_values(up{instance=~".*:8040"},srv)
-
常用监控命令
SHOW PROC '/frontends';— 显示所有前端的状态。SHOW PROC '/backends';— 显示所有后端的状态。SHOW PROC '/brokers';显示所有配置的Broker的状态。SHOW PROC '/compute_nodes';查看当前集群的 CN 节点信息。SHOW PROC '/jobs';查看当前集群的作业信息。SHOW PROC '/transactions';查看当前正在执行的事务。SHOW PROC '/dbs';查看当前集群的数据库信息。SHOW PROC '/statistic';查看当前集群各数据库的统计信息。SHOW PROC '/cluster_balance';查看当前集群的负载信息。
-
监控告警架构
Prometheus + StarRocks-http_port + Grafana方式进行监控,并对核心指标提供监控大屏及告警通知。
-
核心指标监控
FE/BE状态监控
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| Frontends Status | FE 节点状态。存活(alive)的节点状态为 1,宕机(DEAD)的节点会显示为 0。 | 所有 FE 节点状态需均为alive,任一 FE 节点状态为 DEAD 都应触发报警。 | FE 或 BE 宕机都属于异常行为,需要及时排查宕机原因。 |
| Backends Status | BE 节点状态。存活(alive)的节点状态为 1,宕机(DEAD)的节点会显示为 0。 | 所有 BE 节点状态需均为 alive,任一 BE 节点状态为 DEAD 都应触发报警。 |
查询失败监控
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| Query Error | 一分钟内失败的查询率(包括 Timeout)。其值即为一分钟内失败的查询条数除以 60 秒。 | 可以结合业务实际的 QPS 来配置。初步可将该项报警阈值设置在 5% 左右,后续再调整。 | 正常情况下,查询失败率不应太高。将阈值设为 5% 表示每分钟最多允许 3 条查询失败。如果该项报警,可以排查资源占用情况或合理配置查询超时时间。 |
外部感知失败监控
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| Schema Change | Schema Change 操作失败率。 | 由于 Schema Change 是较低频的操作,建议将该项配置为出现失败立即报警。 | 正常情况下,Schema Change 操作不应该失败。如果该项报警,可以调大变更表操作可用的内存上限,默认为 2G。 |
内部操作失败监控
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| BE Compaction Score | 所有 BE 最大的Compaction Score,表示当前 Compaction 压力。 | 通常离线场景下,该值小于 100。但当有大量导入任务存在时,Compaction Score 会有明显增高。通常当该值大于 800 的时候需要干预。 | 通常,Compaction Score大于 1000 时就会报错,StarRocks 会报错 “Too many versions”。可以调低导入并发和导入频率。 |
| Clone | BE 的 Clone 任务失败率。 | 建议将该项配置为出现失败立即报警。 | 如果该项报警,可以检查 BE 状态、磁盘状态和网络状态。 |
服务可用性监控
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| Meta Log Count | FE 节点 BDB 元数据 Log 条数。 | 建议将该项配置为大于 100000 立即报警。 | Leader FE 节点的 Log 数量默认超过 50000 条会触发 CheckPoint 进行落盘。如果该值远超 50000,通常代表 CheckPoint 失败。可以排查 fe.conf 中的 Xmx 堆内存配置是否合理。 |
机器过载监控项
| 报警项 | 说明 | 报警规则 | 备注 |
|---|---|---|---|
| BE CPU Idle | BE CPU 空闲率。 | 建议将该项配置为空闲率小于 10% 持续30 秒则报警。 | 该项主要用于监测 CPU 资源瓶颈。CPU 占用率的波动性比较大,如果统计间隔太小会导致误报。所以需要结合业务实际情况调整该项,如果确实存在多个大任务的批量处理或较多的查询,可调低该阈值。 |
| BE Mem | 各个 BE 节点的内存使用情况。 | 建议将该项配置为各个 BE 可用内存大小的90%。 | 该值与 Process Mem 取值相同,BE 默认内存上限为 be.conf 中的mem_limit=90%,即 BE 所在服务器内存的 90%。如果同时在该服务器上混部其他服务,请注意调整该值,避免 OOM。而该项的报警阈值则需要设为该上限的 90%,以确认 BE 内存资源是否已达到瓶颈。 |
| Disks Avail Capacity | 各 BE 节点本地磁盘容量可用比例(百分比)。 | 建议将该项配置为小于 20% 立即报警。 | 建议根据业务需求为集群保留充足可用空间。 |
| FE JVM Heap Stat | StarRocks 集群各个 FE 的 JVM 堆内存使用百分比。 | 建议将该项配置为大于等于 80% 立即报警。 | 堆内存报警后建议调大 fe.conf 中的 Xmx 堆内存,否则容易影响查询效率或出现 FE OOM。 |
-
metrics端口
FE服务器配置
命令示例:fe.conf里面配置http_port后,启动FE节点。
端口:默认8030
路由: /metrics
BE服务器配置
命令示例:be.conf里面配置be_http_port后,启动BE节点。
端口:默认8040
路由: /metrics
七、生命周期管理
-
IAC申请
-
扩缩容
-
IAC下线
八, infra 支持范围(有限支持)
- 标准化安装部署
- 标准化监控告警
- 基本服务可用性保障
- 标准化的扩缩容
- 版本升级(计划内的)
八、附录
-
监控地址
-
FE节点的监控地址:infra-grafana.hwwt2.com/d/1fFiWJ4m1…
-
BE节点的监控地址:infra-grafana.hwwt2.com/d/1fFiWJ4m1…
-
九 、日常命令
创建不了routine_load 报错
需要通过Mysql 连接FE 执行如下命令动态调整routine_load 的参数:
动态修改: ADMIN SET FRONTEND CONFIG("max_routine_load_job_num" = "110");
避免重启失效,在fe.conf也新增下 max_routine_load_job_num=110