StarRocks的初步介绍和使用

官方文档：https://docs.starrocks.io/zh/docs/quick_start/

快速开始教程：https://docs.starrocks.io/zh/docs/quick_start/shared-nothing/

中文社区：https://forum.mirrorship.cn/

StarRocks 是一款基于 MPP（Massive Parallel Processing）架构的分布式数据仓库产品，旨在为企业提供高性能、低成本的数据分析解决方案。StarRocks 支持 ANSI SQL，可与主流的 BI 工具无缝集成，支持多种数据源接入，满足企业的多样化数据需求。充分吸收关系型 OLAP 数据库和分布式存储系统优秀成果。其架构简洁，采用了全面向量化引擎，兼容 MySQL 协议支持标准 SQL 语法，可构建大宽表、星型模型、雪花模型在内的各类模型。

特性

兼容 MySQL 协议

StarRocks 兼容 MySQL 协议，支持标准 SQL。用户可以轻松地通过 MySQL 客户端连接到 StarRocks 实时查询分析数据。

实时导入

StarRocks 能够支持秒级的导入延迟，提供准实时的服务能力。StarRocks 的存储引擎在数据导入时能够保证每一次操作的 ACID。一个批次的导入数据生效是原子性的，要么全部导入成功，要么全部失败。并发进行的各个事务相互之间互不影响，对外提供 Snapshot Isolation 的事务隔离级别。

优化器CBO

StarRocks 从零设计并实现了一款全新的，基于代价的优化器 CBO（Cost Based Optimizer）。该优化器是 Cascades Like 的，在设计时，针对 StarRocks 的全面向量化执行引擎进行了深度定制，并进行了多项优化和创新。该优化器内部实现了公共表达式复用，相关子查询重写，Lateral Join，Join Reorder，Join 分布式执行策略选择，低基数字典优化等重要功能和优化。目前，该优化器已可以完整支持 TPC-DS 99 条 SQL 语句。

由于全新 CBO 的支持，StarRocks 能比同类产品更好地支持多表关联查询，特别是复杂的多表关联查询，让全面向量化引擎能够发挥极致的性能。

分析数据湖

使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。

StarRocks 不仅能高效的分析本地存储的数据，也可以作为计算引擎直接分析数据湖中的数据。用户可以通过 StarRocks 提供的 External Catalog，轻松查询存储在 Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake 等数据湖上的数据，无需进行数据迁移。支持的存储系统包括 HDFS、S3、OSS，支持的文件格式包括 Parquet、ORC、CSV。

如上图所示，在数据湖分析场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的存储、组织和维护。使用数据湖的优势在于可以使用开放的存储格式和灵活多变的 schema 定义方式，可以让 BI/AI/Adhoc/报表等业务有统一的 single source of truth。而 StarRocks 作为数据湖的计算引擎，可以充分发挥向量化引擎和 CBO 的优势，大大提升了数据湖分析的性能。

Catalog

Catalog 分为 Internal catalog 和 External catalog。Internal catalog 是内部数据目录，用于管理导入至 StarRocks 中的数据以及内部的物化视图等。每个集群都有且只有一个名为 default_catalog 的 Internal catalog，包含一个或多个数据库。StarRocks 作为数据仓库存储数据，能够显著提高查询性能，尤其应对大规模数据的复杂查询分析。

External catalog 是外部数据目录，用于连接数据湖中的数据。您可以将 StarRocks 作为查询引擎，直接查询湖上数据，无需导入数据至 StarRocks。

数据表

StarRocks 中的表分为两类：内部表和外部表。

内部表

内部表归属于 Internal catalog 的数据库，数据保存在 StarRocks 中。内部表由行和列构成，每一行数据是一条记录。

备注

此处内部表的行和列为逻辑概念，在 StarRocks 中数据实际是按列存储的。物理上，一列数据会经过分块编码、压缩等操作，然后持久化存储。

在 StarRocks 中，根据约束的类型将内部表分四种，分别是主键表、明细表、聚合表和更新表，适用于存储和查询多种业务场景中的数据，比如原始日志、实时数据、以及汇总数据。

内部表采用分区+分桶的两级数据分布策略，实现数据均匀分布。并且分桶以多副本形式均匀分布至 BE 节点，保证数据高可用。

外部表

外部表是 External catalog 中的表，实际数据存在外部数据源中，StarRocks 只保存表对应的元数据，您可以通过外部表查询外部数据。

执行 DESCRIBE 查看表结构。

StarRocks 提供四种类型的表，包括明细表、主键表、聚合表和更新表，适用于存储多种业务数据，例如原始数据、实时频繁更新的数据和聚合数据。

• 明细表简单易用，表中数据不具有任何约束，相同的数据行可以重复存在。该表适用于存储不需要约束和预聚合的原始数据，例如日志等。
• 主键表能力强大，具有唯一性非空约束。该表能够在支撑实时更新、部分列更新等场景的同时，保证查询性能，适用于实时查询。
• 聚合表适用于存储预聚合后的数据，可以降低聚合查询时所需扫描和计算的数据量，极大提高聚合查询的效率。
• 更新表适用于实时更新的业务场景，目前已逐渐被主键表取代。

由于主键表仅支持分桶策略为哈希分桶，因此您还需要通过 DISTRIBUTED BY HASH () 定义哈希分桶键。

在实际的业务场景中，为了加速查询和管理数据，创建主键表时，通常还会用到数据分布、排序键等功能。

自 3.0 起主键表解耦了主键和排序键，因此您可以选择经常作为查询过滤条件的列去构成排序键。假设经常根据订单日期和商户组合维度查询商品销售情况，则您可以通过 ORDER BY (dt,merchant_id) 指定排序键为 dt 和 merchant_id 。

注意，如果您使用了数据分布策略，由于目前主键表要求主键必须包括分区列和分桶列，假设采用的数据分布策略是将 dt 作为分区列并且 merchant_id 作为哈希分桶列，则主键还需要包括 dt 和 merchant_id。

视图和物化视图

物化视图分为同步物化视图和异步物化视图。其中异步物化视图能力更加强大，能够存储基于多个基表（内部表和外部表）的预计算结果，并且支持丰富的聚合算子。

StarRocks 支持用户使用物化视图（materialized view）进行查询加速和数仓分层。不同于一些同类产品的物化视图需要手动和原表做数据同步，StarRocks 的物化视图可以自动根据原始表更新数据。只要原始表数据发生变更，物化视图的更新也同步完成，不需要额外的维护操作就可以保证物化视图能够维持与原表一致。不仅如此，物化视图的选择也是自动进行的。StarRocks 在进行查询规划时，如果有合适的物化视图能够加速查询，StarRocks 自动进行查询改写(query rewrite)，将查询自动定位到最适合的物化视图上进行查询加速。

StarRocks 的物化视图可以按需灵活创建和删除。用户可以在使用过程中视实际使用情况来判断是否需要创建或删除物化视图。StarRocks 会在后台自动完成物化视图的相关调整。

StarRocks 的物化视图可以替代传统的 ETL 建模流程，用户无需在上游应用处做数据转换，可以在使用物化视图时完成数据转换，简化了数据处理流程。

例如图中，最底层 ODS 的湖上数据可以通过 External Catalog MV 来构建 DWD 层的 normalized table；并且可以通过多表关联的物化视图来构建 DWS 层的宽表 (denormalized table)；最上层可以进一步构建实时的物化视图来支撑高并发的查询，提供更加优异的查询性能。

视图是一种灵活的查询工具，它可以将多个表虚拟地组合在一起。用户可以通过视图简单地执行查询操作，而无需了解底层的物理表结构和数据分布。此外，视图还可以根据用户需求进行定制，提供更灵活的查询功能。

物化视图则是用于支持多表关联和丰富的聚合操作。物化视图是预先计算并存储的视图，可以快速地执行复杂的查询操作。与视图不同，物化视图可以存储实际的数据结果，从而提升查询速度。此外，物化视图还支持多种查询重写场景，可以在查询执行时自动或透明地重写查询语句，以提高查询效率。

通过引入视图和物化视图两种技术，StarRocks实现了更高效的查询操作和更复杂的数据处理任务。这两种技术为用户提供了方便快捷的数据查询和处理服务，从而提高数据查询的整体性能和效率。

SR物化视图（即物化视图）会占用额外的存储空间。根据搜索结果中的描述，每一个新的物化视图都是额外的存储负担。因此，虽然物化视图可以提高查询性能和减少资源消耗，但是它们需要额外的存储空间来维护预定义查询的结果。所以，在使用物化视图时，需要合理控制物化视图的数量，以避免过多的存储负担。

参考：https://tech.qimao.com/starrockszhi-shi-tu-ji-wu-hua-shi-tu-de-shi-jian/

Routine Load

Routine Load是一种数据导入技术，主要用于从Kafka等消息队列中持续不断地导入数据到支持该技术的数据库中，如Apache Doris和StarRocks。以下是Routine Load的一些关键特性和基本原理：

1. 持续消费数据：Routine Load会持续消费Kafka Topic中的数据，并将其写入到数据库中。
2. 作业与任务：创建Routine Load作业后，会生成一个常驻的导入作业（load job）和若干个导入任务（load task）。导入作业是一个持续运行的任务，负责不断地消费Kafka中的数据；而导入任务是导入作业的细分，作为独立的导入基本单位，以Stream Load的方式写入到后端（BE）中。
3. 导入流程：Client向Frontend（FE）提交Routine Load作业，FE通过Job Scheduler将Routine Load作业拆分成若干个Routine Load任务，这些任务在Backend（BE）上被视为Stream Load任务进行导入，导入完成后向FE汇报，FE根据汇报结果继续生成新的任务或对失败的任务进行重试。
4. 支持的数据格式：Routine Load支持从Kafka中消费CSV和JSON格式的数据。
5. 使用限制：Routine Load支持无认证的Kafka访问以及通过SSL方式认证的Kafka集群。支持的消息格式为CSV或JSON文本格式，且CSV中每个message为一行，行尾不包含换行符。
6. Exactly-Once语义：Routine Load是一个流式导入作业，支持Exactly-Once语义，保证数据不丢不重。
7. SQL控制：用户可以通过SQL命令控制Routine Load任务的暂停、继续及停止。

Routine Load通过这种方式，提供了一种高效、可靠的数据导入解决方案，特别适用于需要实时处理流数据的场景。

安装和使用

docker run -p 9030:9030 -p 8030:8030 -p 8040:8040 -itd \
--name quickstart starrocks/allin1-ubuntu

docker exec -it quickstart \
mysql -P 9030 -h 127.0.0.1 -u root --prompt="StarRocks > "

show databases;

集群管理

配置管理

FE 参数分为动态参数和静态参数。

• 动态参数可通过 SQL 命令进行在线配置和调整，方便快捷。需要注意通过 SQL 命令所做的动态设置在重启 FE 后会失效。如果想让设置长期生效，建议同时修改 fe.conf 文件。
• 静态参数必须在 FE 配置文件 fe.conf 中进行配置和调整。调整完成后，需要重启 FE 使变更生效。

参数是否为动态参数可通过 ADMIN SHOW CONFIG 返回结果中的 IsMutable 列查看。TRUE 表示动态参数。

静态和动态参数均可通过 fe.conf 文件进行修改。

参考：https://docs.starrocks.io/zh/docs/administration/management/FE_configuration/

ADMIN SHOW FRONTEND CONFIG;

ADMIN SHOW FRONTEND CONFIG LIKE '%check_java_version%';

ADMIN SET FRONTEND CONFIG ("key" = "value");

性能调优

https://docs.starrocks.io/zh/docs/administration/Query_planning/