[toc]
概述
StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing，大规模并行处理) 数据库。
StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。StarRocks 还兼容多种主流 BI 产品，包括 Tableau、Power BI、FineBI 和 Smartbi。
使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。
StarRocks 是 Linux 基金会项目，采用 Apache 2.0 许可证。
StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP (Online Analytical Processing) 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。
通俗的说法：StarRocks是关系型数据库的一种，采用列存储，可以作为mysql平替，在CRUD方面碾压mysql，语法和mysql几乎一致，迁移的开发量非常少。不支持事务。在 db-engines.com 中当前（202405）排名88位，在github中有8K个小星星。
应用场景
- OLAP：用户行为分析，用户画像、标签分析、圈人、报表、系统监控分析
- 实时数仓：电商大促数据分析、物流行业的运单分析、金融行业绩效分析、指标计算、直播质量分析、探针分析APM（Application Performance Management）
- 高并发查询：广告主报表分析、零售行业渠道人员分析
- 数据分析：
- 通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
- 使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。
系统架构
StarRocks 架构简洁，整个系统的核心包括：
- FE（Frontend）
- BE (Backend) 或 CN (Compute Node)
部署方便与维护简单，节点可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRocks 提供 MySQL 协议接口，支持标准 SQL 语法。用户可通过 MySQL 客户端方便地查询和分析 StarRocks 中的数据。
FE&BE
FE 是 StarRocks 的前端节点，负责管理元数据、管理客户端连接、进行查询规划、查询调度等工作。每个 FE 节点都会在内存保留一份完整的元数据，这样每个 FE 节点都能够提供无差别的服务。
FE 有三种角色：Leader FE，Follower FE 和 Observer FE，区别如下：
| FE角色 | 元数据读写 | Leader选举 |
|---|---|---|
| Leader | Leader FE 提供元数据读写服务，Follower 和 Observer 只有读取权限，无写入权限。Follower 和 Observer 将元数据写入请求路由到 Leader，Leader 更新完元数据后，会通过 BDB JE (Berkeley DB Java Edition) 同步给 Follower 和 Observer。必须有半数以上的 Follower 节点同步成功才算作元数据写入成功。 | Leader 本身也是 Follower 节点，是从 Follower 中自动选出的。如果当前 Leader 节点失败，Follower 会发起新一轮选举 |
| Follower | 只有元数据读取权限，无写入权限。通过回放 Leader 的元数据日志来异步同步数据 | Follower 参与 Leader 选举，会通过类 Paxos 的 BDBJE 协议自动选举出一个 Leader，必须有半数以上的 Follower 节点存活才能进行选主 |
| Observer | 同 Follower | Observer 主要用于扩展集群的查询并发能力，可选部署。Observer 不参与选主，不会增加集群的选主压力 |
BE 是 StarRocks 的后端节点，负责数据存储和 SQL 计算等工作。
- 数据存储方面，BE 节点都是完全对等的。FE 按照一定策略将数据分配到对应的 BE 节点，BE 负责将导入数据写成对应的格式存储下来，并生成相关索引。
- 在执行 SQL 计算时，一条 SQL 语句首先会按照语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在对应的 BE 节点上执行，这样可以实现本地计算，避免数据的传输与拷贝，从而得到极速的查询性能。
存算一体
StarRocks 3.0 版本之前使用存算一体 (shared-nothing) 架构，BE 同时负责数据存储和计算，在查询时可以直接访问 BE 本地数据，进行本地计算，避免数据传输与拷贝，从而能够得到极速的查询分析性能
存算分离
StarRocks 存算分离技术在现有存算一体架构的基础上，将计算和存储进行解耦。
在存算分离新架构中，数据持久化存储在更为可靠和廉价的远程对象存储（比如 S3）或 HDFS 上。
CN 本地磁盘只用于缓存热数据来加速查询。在本地缓存命中的情况下，存算分离可以获得与存算一体架构相同的查询性能。
存算分离架构下，用户可以动态增删计算节点，实现秒级的扩缩容。
存算分离大大降低了数据存储成本和扩容成本，有助于实现资源隔离和计算资源的弹性伸缩。
与存算一体架构类似，存算分离版本拥有同样简洁的架构，整个系统依然只有 FE 和 CN 两种服务进程，用户唯一需要额外提供的是后端对象存储。
表类型
StarRocks 支持四种表类型，分别是明细表 (Duplicate key table)、聚合表 (Aggregate table)、更新表 (Unique Key table) 和主键表 ( Primary Key table)。
- 明细表简单易用，表中数据不具有任何约束，相同的数据行可以重复存在。该表适用于存储不需要约束和预聚合的原始数据，例如日志等
- 主键表能力强大，具有唯一性非空约束。该表能够在支撑实时更新、部分列更新等场景的同时，保证查询性能，适用于实时查询
- 聚合表适用于存储预聚合后的数据，可以降低聚合查询时所需扫描和计算的数据量，极大提高聚合查询的效率
- 更新表适用于实时更新的业务场景，目前已逐渐被主键表取代
建表时，您需要指定表类型 (Table Type)，这样数据导入至表时，StarRocks 会按照排序键对数据进行排序、处理和存储。本文介绍 StarRocks 支持的各种表类型，满足您在不同业务场景下的需求。
不同类型表能力对比
创建主键表示例；
CREATE TABLE orders1 (
order_id bigint NOT NULL,
dt date NOT NULL,
user_id INT NOT NULL,
good_id INT NOT NULL,
cnt int NOT NULL,
revenue int NOT NULL
)
PRIMARY KEY (order_id)
DISTRIBUTED BY HASH (order_id);
- 由于主键表仅支持分桶策略为哈希分桶，因此您还需要通过 DISTRIBUTED BY HASH () 定义哈希分桶键
- 在实际的业务场景中，为了加速查询和管理数据，创建主键表时，通常还会用到数据分布、排序键等功能
- 可以通过 ORDER BY (dt,merchant_id) 指定排序键为 dt 和 merchant_id
- 在建表语句中，主键列必须定义在其他列之前
- 主键必须包含分区列和分桶列
数据类型
StarRocks 支持以下数据类型：数值类型、字符串类型、日期类型、半结构化类型、其他类型
数值类型
TINYINT
SMALLINT
INT
BIGINT
LARGEINT
DECIMAL
DOUBLE
FLOAT
BOOLEAN
PERCENTILE
字符串类型
CHAR
STRING
VARCHAR
BINARY
日期类型
DATE
DATETIME
半结构化类型
ARRAY
JSON
MAP
STRUCT
其他类型
BITMAP
HLL
关键字
非保留关键字 (Non-reserved keywords) 可以直接作为标识符，如表名和列名，不需要做特殊处理。例如，DB 是非保留关键字，如要创建一个名为 DB 的数据库，语法如下。
CREATE DATABASE DB;
Query OK, 0 rows affected (0.00 sec)
保留关键字 (Reserved keywords) 不能直接作为标识符给变量或者函数等命名，需要做特殊处理。在 StarRocks 中，使用保留关键字作为标识符，需要用反引号将其括起。例如，LIKE为保留关键字，如要创建一个名为LIKE的数据库，语法如下。
CREATE DATABASE `LIKE`;
Query OK, 0 rows affected (0.01 sec)
引用
https://docs.starrocks.io/zh/docs/introduction/what_is_starrocks/
