本文档适用于 StarRocks 4.1 存算一体架构离线部署，基于 7 台 Linux 服务器（3 FE + 4 BE），从环境准备到集群验证全流程可直接执行。
一、集群规划
| 服务器 | 角色 | 核心端口 | 数据目录 |
|---|---|---|---|
| 61 | FE Follower（Leader） | 9030(query) / 9010(editlog) / 9020(rpc) / 8030(http) | /opt/starrocks/fe/meta |
| 62 | FE Follower | 同上 | /opt/starrocks/fe/meta |
| 63 | FE Follower | 同上 | /opt/starrocks/fe/meta |
| 64 | BE | 9060(be) / 9050(heartbeat) / 8040(http) / 8060(brpc) | /data1/starrocks/be/storage |
| 65 | BE | 同上 | /data1/starrocks/be/storage |
| 66 | BE | 同上 | /data1/starrocks/be/storage |
| 67 | BE | 同上 | /data1/starrocks/be/storage |
FE 高可用原理：3 台 Follower FE 通过 Raft 协议自动选举 Leader，任意 1 台故障不影响服务。BE 节点负责数据存储和查询计算，4 台 BE 建议使用 3 副本（容忍 1 台故障）。
二、部署前环境准备
2.1 硬件配置建议
| 节点类型 | 最低配置 | 推荐配置 | 说明 |
|---|---|---|---|
| FE | 4核 / 8GB | 16核 / 32GB | 元数据存储建议 SSD，200GB+ |
| BE | 8核 / 16GB | 32核 / 128GB | 数据盘建议 SSD/NVMe，容量按需 |
**CPU 要求：**必须支持 AVX2 指令集（StarRocks 依赖矢量化计算加速），可通过以下命令检查：
bash
grep -q avx2 /proc/cpuinfo && echo "支持 AVX2" || echo "不支持 AVX2"2.2 软件要求
-
操作系统：CentOS 7.9 / Ubuntu 22.04 / RHEL 7.9 及以上
-
JDK：StarRocks 4.1 二进制包已自带 JDK，无需额外安装
-
MySQL 客户端：5.5 及以上（用于连接 FE 管理集群）
2.3 系统配置（7 台服务器全部执行）
① 关闭防火墙
bash
# CentOS / RHEL
systemctl stop firewalld
systemctl disable firewalld
# Ubuntu
ufw disable② 关闭 SELinux
bash
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config③ 关闭 Swap（必须关闭，否则 BE 可能异常）
bash
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab④ 设置文件句柄数与进程数
bash
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
EOF⑤ 内核参数优化
bash
cat >> /etc/sysctl.conf << EOF
vm.swappiness = 0
vm.overcommit_memory = 1
vm.max_map_count = 2000000
fs.file-max = 6553560
EOF
sysctl -p⑥ 时钟同步（生产环境必须）
bash
# CentOS / RHEL
yum install -y chrony
systemctl start chronyd
systemctl enable chronyd
# Ubuntu
apt install -y chrony
systemctl start chrony
systemctl enable chrony
# 验证同步状态
chronyc sources⑦ 创建专用运行用户（不建议用 root）
bash
useradd -m -s /bin/bash starrocks
echo "starrocks" | passwd --stdin starrocks # CentOS
# echo "starrocks:starrocks" | chpasswd # Ubuntu⑧ 配置主机名与 hosts
每台机器设置对应主机名：
bash
# 61 上执行
hostnamectl set-hostname sr-fe-01
# 62 上执行
hostnamectl set-hostname sr-fe-02
# 63 上执行
hostnamectl set-hostname sr-fe-03
# 64 上执行
hostnamectl set-hostname sr-be-01
# 65/66/67 依次设为 sr-be-02 ~ sr-be-04所有机器的 /etc/hosts 都添加以下内容（替换为实际内网 IP）：
bash
cat >> /etc/hosts << EOF
192.168.1.61 sr-fe-01
192.168.1.62 sr-fe-02
192.168.1.63 sr-fe-03
192.168.1.64 sr-be-01
192.168.1.65 sr-be-02
192.168.1.66 sr-be-03
192.168.1.67 sr-be-04
EOF⑨ 安装 MySQL 客户端（FE 节点安装即可）
bash
# CentOS / RHEL
yum install -y mysql
# Ubuntu
apt install -y mysql-client三、上传并解压安装包
3.1 上传安装包到 61 服务器
将离线安装包
StarRocks-4.1.tar.gz上传到 61 服务器的/opt/目录。
3.2 解压
bash
cd /opt
tar -zxvf StarRocks-4.1.tar.gz
mv StarRocks-4.1 starrocks
chown -R starrocks:starrocks /opt/starrocks解压后目录结构：
bash
/opt/starrocks/
├── fe/ # FE 部署文件
│ ├── bin/ # 启动/停止脚本
│ ├── conf/ # 配置文件
│ ├── lib/ # 依赖库
│ └── jdk/ # 自带 JDK
├── be/ # BE 部署文件
│ ├── bin/
│ ├── conf/
│ ├── lib/
│ └── jdk/ # 自带 JDK
└── LICENSE.txt四、分发部署文件到各节点
在 61 服务器上执行，将 FE 和 BE 文件分别分发到对应节点：
4.1 分发 FE 到 62、63
bash
scp -r /opt/starrocks/fe root@sr-fe-02:/opt/starrocks/
scp -r /opt/starrocks/fe root@sr-fe-03:/opt/starrocks/4.2 分发 BE 到 64、65、66、67
bash
scp -r /opt/starrocks/be root@sr-be-01:/opt/starrocks/
scp -r /opt/starrocks/be root@sr-be-02:/opt/starrocks/
scp -r /opt/starrocks/be root@sr-be-03:/opt/starrocks/
scp -r /opt/starrocks/be root@sr-be-04:/opt/starrocks/如果用 starrocks 用户运行，分发后需在各节点执行
chown -R starrocks:starrocks /opt/starrocks修正权限。
五、配置并启动第一台 FE（61 服务器）
5.1 创建元数据目录
bash
mkdir -p /opt/starrocks/fe/meta
chown -R starrocks:starrocks /opt/starrocks/fe/meta5.2 修改 fe.conf 配置文件
bash
vi /opt/starrocks/fe/conf/fe.conf找到并修改/添加以下核心参数：
bash
# ===== 基础配置 =====
# 元数据存储路径（必改）
meta_dir = /opt/starrocks/fe/meta
# 绑定内网网卡，多网卡环境必须指定（必改，替换为实际网段）
priority_networks = 192.168.1.0/24
# ===== 端口配置（默认即可，被占用再改）=====
http_port = 8030
rpc_port = 9020
query_port = 9030
edit_log_port = 9010
# ===== JVM 配置 =====
# 堆内存，生产建议 8G~16G，按机器内存调整
JAVA_OPTS = "-Xmx8192m -XX:+UseG1GC"
# ===== 集群配置 =====
# 默认副本数，4 台 BE 建议设为 3
default_replication_num = 3
# 元数据延迟容忍时间（秒）
meta_delay_toleration_second = 3005.3 启动 FE
bash
# 切换到 starrocks 用户（如果用专用用户）
su - starrocks
# 启动 FE
cd /opt/starrocks/fe
./bin/start_fe.sh --daemon5.4 验证 FE 启动成功
bash
# 方法一：查看日志，出现 thrift server started 即成功
cat /opt/starrocks/fe/log/fe.log | grep thrift
# 方法二：查看进程
ps -ef | grep StarRocksFE
# 方法三：查看 HTTP 端口
curl -s http://127.0.0.1:8030/api/bootstrap日志中出现以下字样表示启动成功：
bash
thrift server started with port 9020六、配置并启动 BE 节点（64~67 四台）
以下操作在 64、65、66、67 每台 BE 上都要执行，操作完全相同。
6.1 创建数据存储目录
bash
# 根据实际磁盘情况，多块盘就建多个目录
mkdir -p /data1/starrocks/be/storage
mkdir -p /data2/starrocks/be/storage # 有第二块盘就建
chown -R starrocks:starrocks /data1/starrocks /data2/starrocks6.2 修改 be.conf 配置文件
bash
vi /opt/starrocks/be/conf/be.conf核心配置参数：
bash
# ===== 存储配置 =====
# 数据存储路径（必改），多块盘用分号分隔
# SSD 盘加 ,medium:ssd；HDD 盘加 ,medium:hdd
storage_root_path = /data1/starrocks/be/storage,medium:ssd;/data2/starrocks/be/storage,medium:ssd
# ===== 网络配置 =====
# 绑定内网网卡，多网卡必须指定（必改）
priority_networks = 192.168.1.0/24
# ===== 端口配置（默认即可）=====
be_port = 9060
be_http_port = 8040
heartbeat_service_port = 9050
brpc_port = 8060
# ===== 内存配置 =====
# BE 总内存限制，建议设为机器总内存的 70%~80%
mem_limit = 80%
# 查询内存占比
query_mem_limit = 60%
# 导入内存占比
load_mem_limit = 30%
# ===== 并发与性能 =====
# 并发线程数，建议 = CPU 核数 * 2
be_thread_concurrency = 64
# BRPC 线程数
max_brpc_threads = 1286.3 启动 BE
bash
su - starrocks
cd /opt/starrocks/be
./bin/start_be.sh --daemon6.4 验证 BE 启动
bash
# 查看日志
cat /opt/starrocks/be/log/be.INFO | grep heartbeat
# 查看进程
ps -ef | grep starrocks_be看到以下字样表示 BE 进程启动成功：
bash
heartbeat has started listening port on 9050此时 BE 进程虽然启动了，但还没有加入集群，需要在 FE 中执行 ADD BACKEND 后才算正式加入。
七、将 BE 添加到集群（在 61 上操作）
7.1 用 MySQL 客户端连接 FE
bash
mysql -h 192.168.1.61 -P 9030 -u root初始用户为
root，密码默认为空，直接回车即可。
7.2 添加 4 台 BE 节点
bash
ALTER SYSTEM ADD BACKEND
"192.168.1.64:9050",
"192.168.1.65:9050",
"192.168.1.66:9050",
"192.168.1.67:9050";注意：添加 BE 时用的端口是 heartbeat_service_port（默认 9050），不是 be_port（9060）！
7.3 查看 BE 状态
bash
SHOW PROC '/backends'\G每台 BE 的
Alive: true表示成功加入集群。
八、FE 高可用扩容（62、63 加入集群）
第一步：在 61 的 MySQL 中添加 Follower 节点
bash
ALTER SYSTEM ADD FOLLOWER "192.168.1.62:9010";
ALTER SYSTEM ADD FOLLOWER "192.168.1.63:9010";添加 FE 时用的端口是 edit_log_port（默认 9010）。一条 SQL 只能加一个 Follower。
第二步：配置并启动 62 的 FE
在 62 服务器上操作：
bash
# 创建元数据目录
mkdir -p /opt/starrocks/fe/meta
chown -R starrocks:starrocks /opt/starrocks/fe/meta
# 修改 fe.conf（配置和 61 完全一致）
vi /opt/starrocks/fe/conf/fe.conf配置内容参考 5.2 节，确保
meta_dir、priority_networks、端口等参数与 61 一致。
带 helper 参数启动（第一次启动必须加，指向已有 FE 以同步元数据）：
bash
su - starrocks
cd /opt/starrocks/fe
./bin/start_fe.sh --helper 192.168.1.61:9010 --daemon
--helper参数只在第一次启动时需要，后续重启不用加。
第三步：配置并启动 63 的 FE
操作与 62 完全相同：
bash
mkdir -p /opt/starrocks/fe/meta
chown -R starrocks:starrocks /opt/starrocks/fe/meta
vi /opt/starrocks/fe/conf/fe.conf # 配置同 61
su - starrocks
cd /opt/starrocks/fe
./bin/start_fe.sh --helper 192.168.1.61:9010 --daemon第四步：验证 FE 集群
在 61 上连接 MySQL 执行：
bash
SHOW PROC '/frontends'\G正常情况下应看到 3 台 FE：
-
1 台
Role: LEADER（主节点，自动选举） -
2 台
Role: FOLLOWER（跟随者，参与选举） -
所有节点
Alive: true
九、连接测试与验证
9.1 连接数据库
bash
# 连接任意一台 FE 均可
mysql -h 192.168.1.61 -P 9030 -u root9.2 建库建表测试
sql
-- 建库
CREATE DATABASE test_db;
USE test_db;
-- 建表（4 台 BE 使用 3 副本）
CREATE TABLE test_table (
id INT,
name VARCHAR(50),
age INT
)
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 3
PROPERTIES (
"replication_num" = "3"
);
-- 插入数据
INSERT INTO test_table VALUES (1, 'zhangsan', 25), (2, 'lisi', 30);
-- 查询验证
SELECT * FROM test_table;能正常查到数据说明集群读写均正常。
9.3 集群状态检查清单
| 检查项 | SQL 命令 | 预期结果 |
|---|---|---|
| FE 节点状态 | SHOW PROC '/frontends'\G | 3 台 Alive: true |
| BE 节点状态 | SHOW PROC '/backends'\G | 4 台 Alive: true |
| 数据库列表 | SHOW DATABASES; | 能看到 test_db |
| FE 配置 | SHOW FRONTEND CONFIG; | 参数生效 |
| BE 配置 | SHOW BACKEND CONFIG; | 参数生效 |
十、启停命令汇总
FE 节点
bash
# 启动
cd /opt/starrocks/fe
./bin/start_fe.sh --daemon
# 停止
./bin/stop_fe.sh
# 查看日志
tail -f log/fe.log
tail -f log/fe.warn.logBE 节点
bash
# 启动
cd /opt/starrocks/be
./bin/start_be.sh --daemon
# 停止
./bin/stop_be.sh
# 查看日志
tail -f log/be.INFO
tail -f log/be.WARNING十一、常见问题排查
| 问题现象 | 排查方法 | 常见原因 |
|---|---|---|
| FE 启动失败 | cat fe/log/fe.warn.log | 端口被占用 / meta 目录权限 / JVM 内存不足 |
| BE 启动失败 | cat be/log/be.WARNING | priority_networks 配错 / 存储目录权限 / AVX2 不支持 |
| BE 加入后 Alive 为 false | 检查 FE 到 BE 的 9050 端口连通性 | 防火墙未关 / IP 配错 / 端口不一致 |
| FE 选主失败 | 检查 3 台 FE 之间 9010 端口互通 | 时钟不同步 / 网络不通 / 少于半数存活 |
| 连不上 9030 端口 | netstat -tlnp | grep 9030 | FE 未启动 / query_port 配置错误 |
| 建表报错副本数不对 | 检查 BE 节点数量 | replication_num 不能超过 BE 节点数 |
**改配置后重启注意：**如果元数据或数据目录已有脏数据（比如之前启动失败过），需要先清空目录再重启：
bash
FE：rm -rf /opt/starrocks/fe/meta/*
BE：rm -rf /data1/starrocks/be/storage/*十二、生产环境优化建议
12.1 安全加固
-
修改 root 默认密码：
SET PASSWORD = PASSWORD('your_password'); -
创建业务专用账号，按库表分配权限
-
FE 前面挂负载均衡（LVS / HAProxy），应用连接 VIP 而非单节点 IP
12.2 性能优化
-
BE 数据盘使用 SSD/NVMe，避免 HDD 成为瓶颈
-
万兆网络，BE 之间数据同步流量大
-
根据数据量合理设置 tablet 数量和 bucket 数
-
开启自动 Compaction，关注 Compaction 状态
12.3 监控与运维
-
部署 StarRocks Manager 或 Prometheus + Grafana 监控
-
定期备份 FE 元数据
-
关注 BE 磁盘使用率，超过 80% 及时扩容
-
建立慢查询监控，定期优化慢 SQL
12.4 StarRocks 4.1 新特性提示
-
支持基于范围的数据分布与 Tablet 自动分裂合并（需开启
enable_range_distribution） -
存算分离架构下单 Tablet 容量上限提升
-
Java UDF/UDAF/UDTF 支持更多数据类型
-
Hive Connector 默认使用原生 C++ Avro Scanner（性能提升）
部署完成后，建议执行一次完整的读写压测，验证集群性能是否符合预期，再正式投入生产使用。
十三、建表模型选择与最佳实践
StarRocks 提供四种数据模型，不同模型适用于不同业务场景。选对模型直接影响查询性能、存储成本和数据更新能力。
13.1 四种数据模型对比
| 对比维度 | Duplicate Key | Aggregate Key | Unique Key | Primary Key |
|---|---|---|---|---|
| 数据保留 | 保留全部明细 | 按维度聚合 | 保留最新版本 | 保留最新版本 |
| 更新方式 | 仅追加 | 聚合追加 | 整行更新 | 整行/部分列更新 |
| 查询性能 | 快（直接读） | 快（预聚合） | 较慢（读时合并） | 快（删写分离） |
| 写入性能 | 最快 | 快 | 较快 | 中等 |
| 存储占用 | 最大 | 最小 | 中等 | 中等 |
| 适用场景 | 原始日志、明细 | 报表、指标汇总 | 需更新的维表 | 高频更新场景 |
| 引入版本 | v1.0 | v1.0 | v1.0 | v4.0+ |
13.2 Duplicate Key（明细模型）
**模型特点：**完全保留导入的原始数据，不做任何聚合或去重，相同 Key 的数据会全部保留。
适用场景
-
原始日志数据（访问日志、行为日志、审计日志）
-
需要保留每条明细记录的业务数据
-
数据不需要更新，只追加写入
-
不确定聚合维度，需要灵活分析的明细层
建表示例
sql
CREATE TABLE access_log (
log_id BIGINT,
user_id INT,
page_url VARCHAR(500),
visit_time DATETIME,
ip VARCHAR(64),
status_code INT
)
DUPLICATE KEY(log_id, user_id, visit_time)
PARTITION BY RANGE(visit_time) (
PARTITION p202401 VALUES LESS THAN ('2024-02-01')
)
DISTRIBUTED BY HASH(user_id) BUCKETS 32
PROPERTIES (
"replication_num" = "3"
);优缺点
| 优点 | 缺点 |
|---|---|
| 写入最快，直接追加 | 存储占用最大，全量保留 |
| 查询简单，无需合并 | 不支持数据更新/删除 |
| 数据零丢失，可追溯 | 聚合查询需要实时计算，较慢 |
13.3 Aggregate Key（聚合模型）
**模型特点：**按维度列（Key 列）对指标列（Value 列）进行预聚合，相同 Key 的数据会自动合并。Value 列支持 SUM、REPLACE、MAX、MIN、REPLACE_IF_NOT_NULL 等聚合函数。
适用场景
-
报表统计、数据看板、BI 分析
-
按固定维度汇总的指标数据
-
写入多为追加，查询多为聚合统计
-
数仓 ADS/DWS 层的汇总表
建表示例
sql
CREATE TABLE user_daily_stat (
stat_date DATE,
user_id INT,
city VARCHAR(64),
-- 以下是指标列，需指定聚合函数
pv INT SUM DEFAULT '0',
uv INT SUM DEFAULT '0',
order_amount DECIMAL(18,2) SUM DEFAULT '0',
last_visit_time DATETIME REPLACE,
max_order_amount DECIMAL(18,2) MAX
)
AGGREGATE KEY(stat_date, user_id, city)
PARTITION BY RANGE(stat_date) (
START ("2024-01-01") END ("2024-12-31") EVERY (INTERVAL 1 MONTH)
)
DISTRIBUTED BY HASH(user_id) BUCKETS 16
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "MONTH",
"dynamic_partition.start" = "-12",
"dynamic_partition.end" = "1",
"dynamic_partition.prefix" = "p"
);常用聚合函数
| 聚合函数 | 说明 |
|---|---|
| SUM | 求和，最常用 |
| REPLACE | 替换，后写入的覆盖先写入的 |
| REPLACE_IF_NOT_NULL | 非空值才替换，空值保留原值（适合部分列更新） |
| MAX | 取最大值 |
| MIN | 取最小值 |
| HLL_UNION | HLL 去重计数（近似去重，性能极高） |
| BITMAP_UNION | Bitmap 去重（精确去重，适合整数） |
优缺点
| 优点 | 缺点 |
|---|---|
| 存储占用最小，预聚合压缩比高 | Key 列必须固定，不灵活 |
| 聚合查询性能最好 | 不支持明细查询（查不到原始数据） |
| 写入时自动聚合，查询零延迟 | 不支持整行更新，只能追加聚合 |
13.4 Unique Key（主键模型）
**模型特点：**保证主键唯一，相同主键的新数据会覆盖旧数据。底层基于 Merge-on-Read，查询时合并不同版本。
适用场景
-
需要频繁更新的维度表（用户信息、商品信息）
-
数据有唯一主键，需要 Upsert 语义
-
更新频率不高（分钟级以上）
-
对查询性能要求不是极致
建表示例
sql
CREATE TABLE user_info (
user_id INT,
user_name VARCHAR(64),
email VARCHAR(128),
phone VARCHAR(32),
level INT,
register_time DATETIME,
update_time DATETIME
)
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 16
PROPERTIES (
"replication_num" = "3",
"enable_unique_key_merge_on_write" = "false" -- 默认 false，读时合并
);优缺点
| 优点 | 缺点 |
|---|---|
| 支持整行 Upsert（插入或更新） | 查询时需要合并版本，查询性能较差 |
| 语义简单，主键唯一 | Compaction 压力大，写入放大 |
| 兼容 MySQL Upsert 语义 | 不支持部分列更新（只能整行） |
13.5 Primary Key（主键模型 v2，推荐）
**模型特点：**StarRocks 4.0+ 推出的新一代主键模型，基于 Delete-and-Insert 实现，主键索引常驻内存，查询性能接近明细模型，同时支持高效更新。
适用场景
-
高频更新场景（实时数仓、CDC 同步）
-
需要部分列更新的业务
-
对查询性能要求高的维表
-
从 MySQL 等数据库同步的明细表
-
Replace 场景多、查询性能要求高
建表示例
sql
CREATE TABLE order_detail (
order_id BIGINT,
user_id INT,
product_id INT,
amount DECIMAL(18,2),
status TINYINT,
create_time DATETIME,
pay_time DATETIME,
update_time DATETIME
)
PRIMARY KEY(order_id)
PARTITION BY RANGE(create_time) (
START ("2024-01-01") END ("2024-12-31") EVERY (INTERVAL 1 MONTH)
)
DISTRIBUTED BY HASH(order_id) BUCKETS 32
PROPERTIES (
"replication_num" = "3",
"enable_persistent_index" = "true" -- 主键索引持久化，减少重启加载时间
);部分列更新示例
sql
-- 只更新订单状态和支付时间，其他列不变
INSERT INTO order_detail (order_id, status, pay_time, update_time) VALUES (1001, 2, '2024-01-15 10:30:00', NOW());优缺点
| 优点 | 缺点 |
|---|---|
| 查询性能接近明细模型（快） | 主键索引占用内存（主键列不能太大） |
| 支持部分列更新，灵活高效 | 写入性能比明细模型略低 |
| 支持 Delete 操作 | 4.0+ 版本才支持 |
| 支持 MvCC 多版本并发控制 | 主键列总长度建议不超过 128 字节 |
**选型建议：**StarRocks 4.1 版本下，需要更新能力的场景优先选择 Primary Key 模型，性能比 Unique Key 好很多。只有在版本较低或主键过大的情况下才考虑 Unique Key。
13.6 分布键（Distribution Key）选择
分布键决定数据如何分散到不同 BE 节点上，选对分布键是性能优化的第一步。
选择原则
-
高基数列优先：选择值多、分布均匀的列（如 user_id、order_id），避免数据倾斜
-
查询关联列优先：如果两表经常 Join，用相同的分布键可以实现 Local Join，避免数据重分布
-
常用过滤列优先：查询中经常作为 Where 条件的列，可减少扫描的 BE 节点数
-
避免热点：不要选只有少数几个值的列（如性别、状态），会导致数据集中在少数节点
常见分布键选择
| 表类型 | 推荐分布键 | 原因 |
|---|---|---|
| 用户表 | user_id | 高基数，查询常用 |
| 订单表 | order_id | 高基数，唯一 |
| 日志表 | user_id 或 log_id | 分布均匀 |
| 商品表 | product_id | 高基数 |
| 按天统计表 | user_id 或 stat_date+user_id | 避免单日数据集中 |
13.7 分区设计
分区策略选择
| 分区类型 | 适用场景 | 建议 |
|---|---|---|
| 范围分区（Range） | 时间序列数据、按日期查询 | 最常用，按天/月分区 |
| 列表分区（List） | 枚举值分区（如地区、类型） | 适合分区键值固定且少的场景 |
| 表达式分区 | 基于函数计算分区 | 灵活但性能略差 |
分区数量建议
-
单表分区数建议控制在 100~300 个以内，过多会增加 FE 元数据压力
-
按天分区的数据保留 1 年 = 365 个分区，接近上限
-
数据量小的表可以按月分区，减少分区数量
-
配合动态分区（Dynamic Partition）自动管理历史分区
动态分区配置示例
java
PROPERTIES (
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY", -- 按天分区
"dynamic_partition.start" = "-30", -- 保留最近 30 天
"dynamic_partition.end" = "3", -- 预创建未来 3 天
"dynamic_partition.prefix" = "p", -- 分区名前缀
"dynamic_partition.buckets" = "16" -- 每个分区的 bucket 数
);13.8 Bucket 数量设置
每个分区内的数据进一步分成多个 Bucket，Bucket 是数据分布的最小单位。
设置原则
-
每个 Bucket 数据量建议 1GB ~ 10GB（最佳 2~5GB）
-
Bucket 数应是 BE 节点数的整数倍，保证数据均匀分布
-
总 Bucket 数 = 分区数 × 每分区 Bucket 数，不宜过多
参考设置
| 数据规模（单分区） | 建议 Buckets | 4 台 BE 时 |
|---|---|---|
| < 10GB | 4~8 | 4 / 8 |
| 10GB ~ 50GB | 8~16 | 8 / 16 |
| 50GB ~ 200GB | 16~32 | 16 / 32 |
| 200GB ~ 1TB | 32~64 | 32 / 64 |
4 台 BE 时，Bucket 数建议设为 4 的倍数（4、8、16、32），这样每台 BE 分到的 Bucket 数相同，负载均衡。
13.9 建表选型决策树
java
需要数据更新能力吗？
├── 不需要 → 数据是明细还是汇总？
│ ├── 明细 → Duplicate Key（明细模型）
│ └── 汇总 → Aggregate Key（聚合模型）
└── 需要 → 更新频率高吗？
├── 高（实时/分钟级） → Primary Key（主键模型 v2）
└── 低（小时/天级） → 版本是 4.0+ 吗？
├── 是 → Primary Key（推荐）
└── 否 → Unique Key（主键模型 v1）13.10 常见建表踩坑提醒
-
分布键选错导致数据倾斜：用低基数列（如性别、状态）做分布键，数据集中在少数节点，查询性能差。解决：用高基数列，或多列组合分布键。
-
Bucket 数过多：小表设太多 Bucket，导致小文件多，Compaction 压力大。解决：按数据量合理设置，每 Bucket 1~10GB。
-
分区过多：按天分区保留 3 年 = 1000+ 分区，FE 元数据压力大。解决：冷热分离，历史数据归档，或按月分区。
-
Aggregate 模型 Key 列太多：Key 列太多导致聚合效果差，存储压缩比低。解决：只保留必要的维度列作为 Key。
-
Unique Key 模型查询慢：读时合并开销大。解决：升级到 4.0+ 用 Primary Key 模型。
-
Primary Key 主键过大：主键列总长度超过 128 字节，索引内存占用大。解决：用整数主键，或缩短主键长度。
-
忽略副本数设置：4 台 BE 用 3 副本是安全的（容忍 1 台故障），但如果只有 3 台 BE 就不能用 3 副本（挂 1 台就不可写）。