一、StarRocks 产品介绍
1.1 定位与背景
StarRocks 是一款面向数据湖仓（Lakehouse）的 MPP 查询引擎，核心设计目标是在开放存储格式（Parquet、Iceberg）之上，提供接近本地盘速度的亚秒级交互式分析性能。
| 引擎 | 架构 | 优势场景 | 对比 StarRocks |
|---|---|---|---|
| Presto/Trino | Interpreter（解释器） | 联邦查询 | 无物化视图，延迟高 |
| ClickHouse | MPP，向量化列存 | 单表聚合，极致压缩 | 多表 Join 弱，生态偏封闭 |
| Apache Spark | 批处理优先 | ETL 大规模数据 | 延迟高，不适合交互式 |
| Druid | 预聚合 + 列存 | 时序场景 | 灵活性差，生态弱 |
StarRocks 在 TPC-H 多表关联 场景下比 ClickHouse 快 3-5x，在 ClickBench 基准上排名领先。
1.2 架构详解
StarRocks 只有两类核心组件，无外部依赖（无 ZooKeeper、无 HDFS 强依赖）：
FE (Frontend) · 元数据管理（BDB JE + Raft） · 查询规划（Query Planning） · 查询调度（Query Scheduling） · MySQL 协议兼容（客户端连接） 角色：Leader / Follower（多数派写） / Observer（只读扩展） FE 发送物理执行计划到: Shared-Nothing: BE（本地存储） - 存储+计算一体，最优延迟 Shared-Data: CN（共享存储） - 纯计算+缓存，无状态可弹性扩缩
Shared-Nothing 模式：BE 同时负责数据存储和计算，数据按分区键 Hash 分桶，每桶多个 Tablet 多副本，适合对延迟敏感的高并发报表场景。
Shared-Data 模式：CN 只做计算、无状态，可秒级扩缩容，数据卸载到 S3/MinIO/HDFS，多层缓存（内存 → 本地盘 → 对象存储），适合成本敏感、需要弹性的场景。
1.3 核心能力矩阵
| 能力 | 说明 | 状态 |
|---|---|---|
| Hive Catalog | 直连 HMS，元数据无需迁移 | GA |
| Iceberg Catalog | 支持 Time Travel / 版本回溯 | GA (v3.4+) |
| Delta Lake Catalog | 通过 Delta Kernel Java | GA |
| 物化视图 | 同步 + 异步两种，支持查询改写 | GA |
| 向量化执行 | 列式 Vectorized Engine，C++ 实现 | GA |
| Bucket Shuffle Join | 减少网络传输，优化 Join 分布 | GA |
| Colocate Join | 同节点 Join，避免 Shuffle | GA |
| 向量检索 | KNN/近似搜索，支持 RAG 场景 | GA (v3.3+) |
| 资源组 | 租户/用户级资源隔离 | GA |
| Kubernetes Operator | K8s 自动化部署 | GA |
二、现状痛点分析
- Tableau → Kyuubi → Spark：延迟高，交互体验差（冷启动 10-30s）
- Adhoc 查询：需要启动 Spark 容器，冷启动慢，排队等待资源
- Agent 场景写 CK：额外数据链路，维护成本高，数据一致性难保证
- 多表 Join 查询：性能差，Spark 不擅长
- 物化视图：没有预计算层，重复计算浪费资源
三、StarRocks 接入方案
3.1 整体接入架构
数据源 → Spark 批处理 → S3 (Parquet/Iceberg)
|
Hive Metastore
|
┌───────────────────┼───────────────────┐
│ │ │
StarRocks Internal StarRocks External StarRocks Vector
(高性能查询层) Catalog (Hive/Iceberg) (RAG/Agent)
│ │ │
Tableau 直连 Tableau 透传 LLM / Agent
(< 1s 响应) 现有表直接读 SQL + 向量合一
Spark 批处理结果 → StarRocks Internal 表
(通过 Flink CDC / Spark Connector / Routine Load)
3.2 部署模式建议
推荐：Shared-Data 模式 + S3
- 你已有 S3 存储，StarRocks 可直接读取 Parquet/Iceberg，无需数据迁移
- 存算分离，FE/CN 可独立扩缩，成本可控
- CN 无状态，K8s 环境可快速弹性伸缩
- 冷启动代价低（Adhoc 查询不需要等待 Spark 容器启动）
最小生产集群配置：
| 组件 | 配置 | 说明 |
|---|---|---|
| FE（3节点） | 8C / 16G × 3 | Leader + 2 Follower（Raft 多数派） |
| CN（2~N 节点） | 16C / 64G × 可扩展 | 本地 SSD 缓存 200GB+，接 S3 |
3.3 Hive Catalog 对接（不改现有架构）
-- 创建 Hive Catalog，直接指向现有 HMS
CREATE EXTERNAL CATALOG hive_catalog
PROPERTIES (
"type" = "hive",
"hive.metastore.type" = "hive",
"hive.metastore.uris" = "thrift://:9083",
"aws.s3.region" = "",
"aws.s3.use_instance_profile" = "true"
);
效果：StarRocks 直接查询 S3 上的 Parquet/Iceberg 文件，无需数据迁移，对现有 Spark 批处理链路零改动。
3.4 StarRocks Internal 表（高性能查询层）
| 写入方式 | 适用场景 | 说明 |
|---|---|---|
| Spark Connector | Spark → StarRocks 批写 | DataFrame.write |
| Flink CDC 3.0 | 实时 CDC 链路 | MySQL/PG → StarRocks |
| Routine Load | Kafka 实时流 | 单表持续导入 |
| INSERT INTO | 定时任务 | INSERT INTO sr_table SELECT ... FROM hive_catalog |
3.5 Tableau 对接
StarRocks 提供官方认证的 Tableau JDBC Connector，从 Tableau Exchange 下载 StarRocks-Connector-for-Tableau.taco 即可。
| 维度 | Kyuubi Spark SQL | StarRocks Tableau 直连 |
|---|---|---|
| 首次查询延迟 | 10-30s（Spark 容器冷启动） | < 1s（向量化执行） |
| 并发支持 | 一般 | 高并发向量化 |
| 多表 Join | 弱 | Bucket Shuffle / Colocate Join |
| 物化视图 | 无 | 支持查询改写 |
四、体验优化分析
4.1 Tableau / BI 场景优化
| 场景 | 现状（Kyuubi Spark） | 接入后（StarRocks） |
|---|---|---|
| 仪表板加载 | 10-30s 冷启动 | < 1s 热查询 |
| 多表关联报表 | 性能差，易 OOM | Bucket Shuffle Join 优化 |
| 重复聚合计算 | 每次全量计算 | 物化视图透明改写 |
| 报表并发上限 | 受 Spark 容器限制 | 横向扩展 CN |
-- 创建异步物化视图，自动聚合
CREATE MATERIALIZED VIEW mv_monthly_sales
AS
SELECT region,
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM dw_orders
GROUP BY region, DATE_TRUNC('month', order_date);
-- Tableau 查询月汇总时自动命中 mv_monthly_sales
-- SQL 改写对 Tableau 透明，无需修改报表
4.2 Adhoc 分析优化
Kyuubi Spark SQL Adhoc 查询需要：①申请 Spark 容器资源（排队等待）②冷启动 YARN Application（30s+）③任务结束资源释放。
接入后：用户 → StarRocks FE → CN（热节点，秒级响应），启动延迟从 30s+ 降至 < 100ms。
-- 创建 Adhoc 用户资源组，限制并发和内存
CREATE RESOURCE GROUP adhoc_group
PROPERTIES (
"cpu_core_limit" = "16",
"mem_limit" = "40%",
"concurrency_limit" = "10",
"type" = "normal"
);
CREATE USER "adhoc_user" IDENTIFIED BY 'xxx';
ALTER USER "adhoc_user" RESOURCE GROUP adhoc_group;
4.3 Agent / LLM 场景优化
现状：Agent 通过 ClickHouse 查询，CK 和 Spark 数仓是两套系统，数据一致性难保证。
StarRocks 一套系统同时支持 SQL 分析和向量检索，消除 CK 依赖：
| 能力 | 实现方式 |
|---|---|
| 结构化 SQL 分析 | Internal Table，向量化引擎 |
| 文本模糊搜索 | LIKE / 正则，内置分词 |
| 向量语义搜索 | ARRAY<FLOAT> 列 + cosine_distance() |
| 混合检索 | SQL + 向量权重融合排序 |
| 跨数据源查询 | External Catalog 穿透 Hive/Iceberg |
-- 存储 embedding ALTER TABLE article_db ADD COLUMN embedding ARRAY; -- 语义搜索 SELECT id, title, cosine_distance(embedding, '<query_embedding>') AS score FROM article_db ORDER BY score ASC LIMIT 10;
4.4 数据链路简化
现状多系统问题：Spark → S3 → Hive Metastore 分叉到 Kyuubi（BI）和 CK（Agent），两套数据链路，一致性难保证。
接入后统一：所有查询入口归一化为 StarRocks，BI 和 Agent 共享同一查询引擎，无需维护 CK 集群。
五、迁移路径与风险
5.1 推荐迁移步骤
| 阶段 | 时长 | 内容 | 风险 |
|---|---|---|---|
| Phase 1 | 2-4周 | 验证 Hive Catalog 直读，部署 FE + 1 CN，对比性能 | 低（只读） |
| Phase 2 | 2-4周 | Tableau 切换到 StarRocks Internal 表，灰度验证 | 中 |
| Phase 3 | 2-4周 | Agent 从 CK 切换到 StarRocks，A/B 对比召回效果 | 中 |
| Phase 4 | 持续 | 物化视图、资源组隔离、Shared-Data 弹性优化 | - |
5.2 风险清单
| 风险 | 级别 | 缓解措施 |
|---|---|---|
| Spark SQL 与 MySQL 语法兼容差异 | 低 | 先做语法适配测试；StarRocks MySQL 协议兼容度高 |
| S3 访问延迟影响查询性能 | 低 | CN 本地缓存热数据；Shared-Nothing 模式可选项 |
| 物化视图改写失败 | 中 | 上线前用 EXPLAIN 验证改写规则；逐步灰度 |
| Agent 召回效果不如 CK | 中 | 先并行运行 CK 和 StarRocks 做 A/B 对比 |
5.3 StarRocks 与现有组件共存
不替代：Spark 批处理（ETL）、Hive Metastore（元数据）、S3 存储（Parquet/Iceberg 文件）。
替代：Kyuubi Spark SQL（Tableau 直连 / Adhoc）、ClickHouse（Agent 场景）。
补充：物化视图层、向量检索能力。
六、关键配置参考
6.1 Hive Catalog 连接 S3
-- AWS IAM Role（推荐）
CREATE EXTERNAL CATALOG hive_catalog
PROPERTIES (
"type" = "hive",
"hive.metastore.type" = "hive",
"hive.metastore.uris" = "thrift://<hms-host>:9083",
"aws.s3.use_instance_profile" = "true",
"aws.s3.region" = "us-east-1"
);
-- MinIO / S3 兼容存储
CREATE EXTERNAL CATALOG minio_catalog
PROPERTIES (
"type" = "hive",
"hive.metastore.type" = "hive",
"hive.metastore.uris" = "thrift://<hms-host>:9083",
"aws.s3.enable_ssl" = "true",
"aws.s3.enable_path_style_access" = "true",
"aws.s3.endpoint" = "http://<minio-host>:9000",
"aws.s3.access_key" = "<access_key>",
"aws.s3.secret_key" = "<secret_key>"
);
6.2 Shared-Data CN 配置（MinIO 为例）
fe.conf: frontend_default_port = 9030 cn.conf: starlet_port = 9030 be_port = 9040 heartbeat_service_port = 9050 storage_root_path = /opt/starrocks/storage run_mode = shared_data aws_s3_enabled = true aws_s3_endpoint = http://<minio-host>:9000 aws_s3_access_key = <access_key> aws_s3_secret_key = <secret_key> aws_s3_region = auto
6.3 Tableau Connector 部署
- 下载
StarRocks-Connector-for-Tableau.taco - 放置到 Tableau 插件目录
- 重启 Tableau，使用 JDBC 连接：
jdbc:mysql://<fe-host>:9030/
七、总结
| 维度 | 结论 |
|---|---|
| Hive Catalog 对接 | 直接读取现有 S3 Parquet/Iceberg，零数据迁移 |
| Tableau 体验 | Kyuubi 30s+ → StarRocks < 1s；多表 Join 性能大幅提升 |
| Adhoc 查询 | 免冷启动，秒级响应，资源组隔离 |
| Agent 场景 | 一套系统同时支持 SQL + 向量检索，消除 CK 依赖 |
| 物化视图 | 对 Tableau 透明的查询加速层，现有架构无类似能力 |
| 迁移风险 | 低风险，可先以 External Catalog 只读方式验证 |
一句话建议：StarRocks 以 External Catalog 零改动接入现有 Hive Metastore + S3 架构，替换 Kyuubi Spark SQL 作为 Tableau 主数据源，替代 CK 作为 Agent 统一查询入口，并通过物化视图为高频报表提供透明加速。