StarRocks(SR)的基本概念、架构及基本使用介绍

StarRocks(原名 DorisDB ,后开源并更名为 StarRocks)是一款高性能、实时、MPP(大规模并行处理)架构的现代化分布式 SQL 数据库 ,专为 OLAP(在线分析处理) 场景设计。它兼容 MySQL 协议,支持标准 SQL,具备亚秒级查询响应能力,适用于实时报表、即席查询、多维分析、用户画像、日志分析等场景。


一、核心基础概念

1. 表模型(Table Model)

StarRocks 提供三种数据模型,适应不同业务场景:

模型 适用场景 特点
Aggregate Key(聚合模型) 预聚合指标(如 sum、count) 相同 key 的 value 自动聚合(如 sum(clicks))
Unique Key(唯一主键模型) 实时更新、主键去重 支持 Upsert,类似 Hudi/Iceberg 的主键更新
Duplicate Key(明细模型) 日志、事件流等原始明细 不聚合,保留所有记录,支持排序键加速查询

推荐

  • 实时数仓 → Unique Key(支持 CDC 更新)
  • 报表聚合 → Aggregate Key
  • 原始日志 → Duplicate Key

2. 分区(Partition)与分桶(Bucket)

  • 分区(Partition) :按时间/地域等逻辑切分数据(如 PARTITION BY RANGE(date)),用于分区裁剪
  • 分桶(Bucket) :每个分区内按 Hash(分桶列) 分成多个 Tablet(物理存储单元),实现并行计算
sql 复制代码
-- 示例:按天分区,按 user_id 分桶
CREATE TABLE user_behavior (
    event_time DATETIME,
    user_id BIGINT,
    item_id BIGINT,
    behavior VARCHAR(32)
)
ENGINE=OLAP
DUPLICATE KEY(event_time, user_id)
PARTITION BY RANGE(event_time) (
    PARTITION p20241201 VALUES LESS THAN ("2024-12-02"),
    PARTITION p20241202 VALUES LESS THAN ("2024-12-03")
)
DISTRIBUTED BY HASH(user_id) BUCKETS 10;

3. 物化视图(Materialized View)

  • 自动构建预聚合索引,加速特定查询模式;
  • 查询时自动路由到最优物化视图(无需改写 SQL);
  • 支持 Rollup (上卷)、Bitmap 精确去重HLL 近似去重
sql 复制代码
-- 创建物化视图:按天统计 UV
CREATE MATERIALIZED VIEW uv_daily_mv
AS
SELECT 
    DATE(event_time) AS dt,
    BITMAP_UNION(TO_BITMAP(user_id)) AS uv
FROM user_behavior
GROUP BY DATE(event_time);

4. 向量化引擎 + CBO 优化器

  • 向量化执行:一次处理 1024 行,大幅提升 CPU 利用率;
  • 基于成本的优化器(CBO):自动选择最优 Join 顺序、索引、聚合策略;
  • 支持 Runtime FilterPredicate Pushdown 等高级优化。

二、系统架构(Shared-Nothing MPP)

StarRocks 采用 无共享(Shared-Nothing) 架构,主要包含两类节点:

1. FE(Frontend) ------ 元数据 & 查询协调

  • 角色
    • Leader FE:管理元数据(表结构、分区信息)、选举主节点;
    • Follower FE:参与元数据写入(多数派共识);
    • Observer FE:只读副本,提升高并发查询能力。
  • 功能
    • SQL 解析、查询计划生成;
    • 集群管理、负载均衡;
    • 兼容 MySQL 协议(客户端直连 FE)。

2. BE(Backend) ------ 存储 & 计算

  • 负责数据存储(Tablet)、本地计算、向量化执行;

  • 数据在 BE 上以 列式存储(Column-Oriented),支持 Parquet-like 编码;

  • 自动副本管理(默认 3 副本),支持跨机架容灾。

    +---------------------+
    | Client (MySQL) |
    +----------+----------+
    |
    +-----v-----+
    | FE (SQL解析, 优化) |
    +-----+-----+
    |
    +-------v--------+ +------------------+
    | BE1 (Tablet A) | <---> | BE2 (Tablet B) |
    +----------------+ +------------------+
    | |
    +-------v--------+ +------v-----------+
    | BE3 (副本) | | BE4 (副本) |
    +----------------+ +------------------+

优势

  • 无单点瓶颈,横向扩展;
  • 计算靠近数据(Data Locality);
  • 自动故障恢复。

三、核心使用语法(兼容 MySQL)

1. 建表(关键参数)

sql 复制代码
CREATE TABLE sales (
    sale_date DATE,
    region VARCHAR(32),
    product_id INT,
    amount DECIMAL(10,2),
    user_id BIGINT
)
ENGINE=OLAP
AGGREGATE KEY(sale_date, region, product_id)
PARTITION BY RANGE(sale_date) (
    START ("2024-01-01") END ("2025-01-01") EVERY (INTERVAL 1 DAY)
)
DISTRIBUTED BY HASH(product_id) BUCKETS 16
PROPERTIES(
    "replication_num" = "3",
    "storage_format" = "DEFAULT"
);

2. 数据导入

方式 1:Stream Load(HTTP 推送)
bash 复制代码
curl --location-trusted -u user:passwd \
    -H "label:load_20241229" \
    -H "column_separator:," \
    -T data.csv http://fe_host:8030/api/db/sales/_stream_load
方式 2:Routine Load(Kafka 实时消费)
sql 复制代码
CREATE ROUTINE LOAD db.sales_kafka ON sales
PROPERTIES(
    "desired_concurrent_number"="3",
    "max_batch_interval" = "20"
)
FROM KAFKA(
    "kafka_broker_list" = "kafka:9092",
    "kafka_topic" = "sales_topic",
    "property.kafka_default_offsets" = "OFFSET_BEGINNING"
);
方式 3:Broker Load(从 HDFS/S3 批量导入)
sql 复制代码
LOAD LABEL db.load_hdfs_001
(DATA INFILE("hdfs://path/to/data.parquet")
 INTO TABLE sales
 FORMAT AS "parquet")
WITH BROKER "my_broker";

3. 查询示例

sql 复制代码
-- 多表 Join(支持 Shuffle/Broadcast)
SELECT 
    u.city, 
    SUM(s.amount) AS total
FROM sales s
JOIN user_dim u ON s.user_id = u.id
WHERE s.sale_date >= '2024-12-01'
GROUP BY u.city
ORDER BY total DESC
LIMIT 10;

-- Bitmap 精确去重(UV)
SELECT 
    COUNT(DISTINCT user_id)  -- 自动转为 BITMAP_UNION
FROM user_behavior;

4. 更新与删除(Unique Key 模型)

sql 复制代码
-- Upsert(通过 Stream Load 或 Routine Load)
-- 新数据自动覆盖旧主键

-- Delete(谨慎使用,仅支持 Duplicate/Unique 模型)
DELETE FROM sales WHERE sale_date < '2023-01-01';

四、核心优势 vs 传统 OLAP

能力 StarRocks Hive/Spark ClickHouse
查询延迟 亚秒级 秒~分钟级 亚秒级
实时更新 ✅(Unique Key) ❌(ReplacingMergeTree 有限支持)
标准 SQL ✅(完整 JOIN、子查询) ⚠️(JOIN 性能差)
多表关联 ✅(Shuffle + Broadcast)
物化视图 ✅(自动匹配) ❌(需手动) ✅(但难维护)
运维复杂度 低(无依赖) 高(YARN/HDFS)

五、典型应用场景

  1. 实时大屏:Kafka → StarRocks → Superset/Grafana;
  2. 用户行为分析:埋点日志 → Duplicate Key 表 → 多维漏斗/留存;
  3. 广告效果归因:Click/Impression 表 → Bitmap UV → ROI 计算;
  4. 金融风控:交易流水 → Unique Key → 实时黑名单更新。

六、部署建议(生产环境)

  • FE:3 节点(1 Leader + 2 Follower),8C16G+;
  • BE:≥3 节点,32C64G+,SSD 存储,万兆网络;
  • 监控:集成 Prometheus + Grafana(StarRocks 提供 exporter);
  • 备份:通过 EXPORT 命令导出到 HDFS/S3。

七、生态集成

  • BI 工具:Tableau、Power BI、Superset(通过 MySQL 协议连接);
  • 数据湖:支持 External Catalog(Hive/Iceberg/Hudi);
  • 流处理:Flink CDC → Kafka → Routine Load;
  • 云原生:支持 Kubernetes 部署(StarRocks Operator)。

总结

StarRocks = 高性能 + 实时性 + 易用性 + 开源免费

它解决了传统 OLAP "快而不全"(如 ClickHouse)或"全而不快"(如 Hive)的痛点,是当前国产开源 OLAP 引擎的标杆。如果你需要:

  • 替代 Kylin/Druid 的预计算;
  • 替代 ClickHouse 的复杂分析;
  • 构建统一实时数仓,

那么 StarRocks 是一个非常值得投入的技术选型

相关推荐
梦梦代码精1 分钟前
BuildingAI vs Dify vs 扣子:三大开源智能体平台架构风格对比
开发语言·前端·数据库·后端·架构·开源·推荐算法
小程故事多_802 小时前
AI Agent进阶架构:用渐进式披露驯服复杂性
人工智能·架构
百***78752 小时前
Grok-4.1技术深度解析:双版本架构突破与Python API快速集成指南
大数据·python·架构
谢尔登3 小时前
Vue3 响应式系统——computed 和 watch
前端·架构
Francek Chen3 小时前
【大数据基础】大数据处理架构Hadoop:01 Hadoop概述
大数据·hadoop·分布式·架构
edisao5 小时前
六、 读者高频疑问解答 & 架构价值延伸
大数据·开发语言·人工智能·科技·架构·php
五度易链-区域产业数字化管理平台6 小时前
五度易链企业数据服务架构思考:从“存数据”到“用数据”的全周期解决方案
大数据·人工智能·架构
CRMEB7 小时前
2026年开源电商系统技术实测榜:从架构到适配的全维度解析
架构·开源
a程序小傲7 小时前
蚂蚁Java面试被问:向量数据库的相似度搜索和索引构建
开发语言·后端·python·架构·flask·fastapi
喜欢吃豆9 小时前
企业级 AI 系统分层存储架构深度研究报告
人工智能·架构·大模型·2025博客之星