StarRocks_5">1.StarRocks简介

OLAP数据库(Online Analytical Processing Database,在线分析处理数据库)是大数据场景下用于进行数据分析不可或缺的系统，早期主要有Oracle、Vertica、HANA等商业数据库占据市场份额，后来出现了GreenPlum、Impala、Presto、Kylin等开源的OLAP系统，字节跳动带火了ClickHouse，Snowflake的出现和上市使OLAP进入了云原生时代，之后从百度Palo发展而来的StarRocks和Doris相继进入Linux和Aapche基金会并进行商业化。

与之相对的是 OLTP（Online Transaction Processing，在线事务处理）像MySql数据库，后者主要用于日常业务交易的处理，强调的是高并发下的短小事务的高效执行。而 OLAP 则更关注于数据的深度分析和长期趋势的研究。

StarRocks 是一款高速、实时、全场景的MPP分析型数据库系统，专为现代数据分析场景设计，强调亚秒级查询性能和高并发能力。这个分析型数据库正在重新定义我们对实时数据处理的认知。

MPP (Massively Parallel Processing)，即大规模并行处理。是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

SeStarRockstter基于MPP架构，架构简洁，采用全向量化执行引擎、列式存储技术和智能优化器等先进技术，实现了数据的快速加载、实时更新以及复杂查询的高效处理。同时，StarRocks对数据表进行水平划分并以多副本存储，集群规模可以灵活伸缩，能够支持 10PB 级别的数据分析;

StarRocks采用关系模型，使用严格的数据类型和列式存储引擎，通过编码和压缩技术，降低读写放大；使用向量化执行方式，充分挖掘多核CPU的并行计算能力，从而显著提升查询性能。

StarRocks 专注于解决实时数据分析的需求，旨在提供快速的数据查询响应时间和高效的数据处理能力。它支持标准的SQL接口，兼容MySQL协议，使得用户可以利用现有的MySQL客户端工具和BI（Business Intelligence）工具进行查询和数据分析可以与现有的BI工具和数据源无缝集成，可以满足企业级用户的多种分析需求，广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。

StarRocks__24">2.StarRocks 在数据生态的定位

随着数据量的增长，需求的不断迭代，原有的以Hadoop 为核心的大数据生态，在性能、实效性、运维难度及灵活性等方面都难以满足企业的需求，OLAP 数据库面临着越来越多的挑战，很难有一种数据库能够适配大部分的业务，这时就出现诸如 Hive 、Druid、CK、ES、Presto 等多技术栈堆叠应用的情况，虽然能解决问题，但是开发和运维的成本、难度也随之上升。

作为一款MPP 架构 的分析性数据库，StarRocks 能够支撑PB 级别的数据量 ，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层数据存储系统。

在整体的大数据生态中：

从上层应用往下看，StarRocks 兼容了 MySQL 协议，可以平稳的对接各种开源或者商业 BI ⼯具，⽐如说Tableau，FineBI，SmartBI，Superset 等；

数据同步环节，StarRocks 可以从 Oceanbase 等事务性数据库中拉取业务数据，通过CloudCanal 等数据采集工具写入 StarRocks。

中间的ETL 工作可以在计算引擎中完成，例如使用 Flink 或 Spark。StarRocks 还提供了相应的Flink Connector 和 Spark Connector 。

也可以采用 ETL 模式，在数据加载到 StarRocks 之后，利用 StarRocks 的物化视图和实时 Join 能力进行数据建模。

在 StarRocks 中可以选择多种数据模型，如预聚合、宽表或灵活性较高的星型/雪花模型。

同时，可以借助Iceberg、Hive、Hudi 外表功能构建一套湖仓一体的架构。数据湖中的有价值数据可以流入 StarRocks 进行关联查询；而 StarRocks 中的隐藏价值数据或价值不高的数据也可以流入数据湖，以低成本方式存储。

在经过一系列的建模后，StarRocks 中的数据可以服务于多种消费场景，比如说报表业务、实时指标监控、智能多维分析、客群圈选、自助 BI 业务。

3.StartRocks的使用场景

StarRocks 是一款高性能的分布式 SQL 数据库，专为实时分析和多维度数据查询设计，利用 StarRocks 的 MPP 框架和向量化执行引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型 或者预聚合模型。适用于灵活配置的多维分析报表。

业务场景包括：

• 用户行为分析
• 用户画像、标签分析、圈人
• 跨主题业务分析
• 财务报表
• 系统监控分析

3.1 实时数据仓库

设计和实现了 Primary-Key 模型，能够 实时更新数据并极速查询，可以 秒级同步 TP (Transaction Processing) 数据库的变化，构建实时数仓，业务场景包括：

• 电商大促数据分析
• 物流行业的运单分析
• 金融行业绩效分析、指标计算
• 直播质量分析
• 广告投放分析
• 管理驾驶舱

优势：低延迟、高并发，支持实时数据摄入和查询

3.2 高并发查询

StarRocks 通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以解决面向用户侧的分析 场景，业务场景包括：

• 广告主报表分析
• 零售行业渠道人员分析
• SaaS 行业面向用户分析报表
• Dashboard 多页面分析

优势：支持高并发查询，响应速度快，适合面向用户的实时分析需求。

3.3 日志与事件分析

StarRocks 支持高效的日志和事件数据分析，适用于需要快速检索和聚合大规模日志数据的场景。业务场景包括：

• 服务器日志监控与分析
• 应用性能监控（APM）
• 安全事件分析与审计
• 用户操作日志分析

优势：高效的文本处理和索引机制，支持快速日志检索和复杂分析。

3.4 物联网（IoT）数据分析

StarRocks 能够高效处理物联网设备产生的海量数据，适用于实时监控和分析设备状态的场景。业务场景包括：

• 传感器数据实时分析
• 设备状态监控与预警
• 智能制造数据分析
• 智慧城市数据管理

优势：支持高并发数据摄入和查询，适合实时处理物联网数据。

3.5 金融风控与实时监控

StarRocks 在金融领域广泛应用于实时风控和交易监控，能够快速识别异常行为。业务场景包括：

• 实时交易监控
• 反欺诈分析
• 信用评分计算
• 金融市场指标分析

优势：低延迟、高吞吐量，适合实时风险控制和预警。

3.6 数据湖查询加速

StarRocks 可以与数据湖（如 HDFS、S3）集成，加速数据湖中的查询性能。业务场景包括：

• 数据湖数据实时查询
• 跨数据源联合分析
• 数据湖数据预计算与加速

数据湖（Data Lake）是一种用于存储大量原始数据的系统或存储库，这些数据可以是结构化的、半结构化的或非结构化的。与传统数据库或数据仓库不同，数据湖允许以任意格式存储数据，并且通常不强制执行严格的数据模型或架构。数据湖的核心理念是“先存储后处理”，即数据首先被加载到湖中，然后根据需要进行分析和处理。

优势：支持外部表查询，适合与数据湖集成。

3.7 A/B 测试与实验分析

StarRocks 支持实时分析A/B 测试 结果，帮助企业优化产品和运营策略。业务场景包括：

• A/B 测试效果分析
• 用户分群与实验对比
• 实时优化实验策略

优势：高效的查询性能，适合实时分析 A/B 测试数据。

当然，StarRocks的使用场景还有很多，像多源数据融合分析、社交媒体与内容分析等，凭借其高性能、低延迟和高并发的特点，适用于多种实时分析和复杂查询场景，能够满足企业对大规模数据实时处理和分析的需求。无论是实时数据仓库、高并发查询，还是多源数据融合分析，StarRocks 都能提供高效的解决方案。

StarRocksMySQL_123">4.StarRocks与MySQL比较

4.1 相同点

兼容性：StarRocks支持MySQL协议，用户可以直接使用MySQL客户端进行查询，降低了迁移和使用门槛。

SQL语法：基本遵循MySQL的SQL语法，使得熟悉MySQL的用户能够快速适应。

4.2 不同点

应用场景：MySQL主要面向OLTP（在线事务处理）场景，而StarRocks专注于OLAP（在线分析处理）领域，尤其擅长海量数据的批量查询和实时分析。

架构设计：StarRocks采用MPP架构，能够充分利用分布式计算资源，实现大规模数据的并行处理，相较于MySQL的单机或多主从架构，更适合大数据分析。

存储与优化：StarRocks采用列式存储和向量化执行引擎，大大提高了数据压缩率和查询速度，尤其是针对大数据量、低延迟的复杂查询场景表现优异。

数据导入与更新：StarRocks支持实时数据摄入，允许用户快速加载大量数据，并对已有数据进行实时更新，而MySQL在处理大规模数据批处理和实时分析时效率相对较弱。

5.架构和功能特性

StarRocks 的架构设计融合了 MPP 数据库和分布式系统的设计思想，具有极简的架构特点。

整个系统由前端节点（FE）、后端节点（BE 和 CN）组成。这种设计使得 StarRocks 在部署和维护上更为简单，同时提升了系统的可靠性和扩展性。

5.1 基本概念

FE：FrontEnd简称FE，是StarRocks的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。功能类似于 Hadoop 中的 NameNode。

BE：BackEnd简称BE，是StarRocks的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。功能类似于 Hadoop 中的 DataNode。

Broker：StarRocks中和外部HDFS/对象存储等外部数据对接的中转服务，辅助提供导入导出功能。这个工具不是必须安装的。

StarRocksManager：StarRocks的管理工具，提供StarRocks集群管理、在线查询、故障查询、监控报警的可视化工具。

Tablet：StarRocks中表的逻辑分片，也是StarRocks中副本管理的基本单位，每个表根据分区和分桶机制被划分成多个Tablet存储在不同BE节点上。

5.2 系统架构

StarRocks 架构简洁，整个系统的核心只有FE（Frontend） 、BE（Backend）两类进程，不依赖任何外部组件，方便部署与维护。

FE 和 BE 模块都可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRocks 提供 MySQL 协议接口，支持标准 SQL 语法。用户可通过 MySQL 客户端方便地查询和分析 StarRocks 中的数据。

5.2.1 前端节点-FE

FE 是 StarRocks 的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。每个 FE 节点都会在内存保留一份完整的元数据，这样每个 FE 节点都能够提供无差别的服务。

FE 有三种角色：Leader FE，Follower FE 和 Observer FE。

Follower 会通过类 Paxos 的 Berkeley DB Java Edition（BDBJE）协议自动选举出一个 Leader。三者区别如下：

• Leader
  • Leader 从 Follower 中自动选出，进行选主需要集群中有半数以上的 Follower 节点存活。如果 Leader 节点失败，Follower 会发起新一轮选举。
  • Leader FE 提供元数据读写服务。只有 Leader 节点会对元数据进行写操作，Follower 和 Observer 只有读取权限。Follower 和 Observer 将元数据写入请求路由到 Leader 节点，Leader 更新完数据后，会通过 BDB JE 同步给 Follower 和 Observer。必须有半数以上的 Follower 节点同步成功才算作元数据写入成功。
• Follower
  • 只有元数据读取权限，无写入权限。通过回放 Leader 的元数据日志来异步同步数据。
  • 参与 Leader 选举，必须有半数以上的 Follower 节点存活才能进行选主。
• Observer
  • 主要用于扩展集群的查询并发能力，可选部署。
  • 不参与选主，不会增加集群的选主压力。
  • 通过回放 Leader 的元数据日志来异步同步数据。

5.2.2 后端节点-BE

BE 是 StarRocks 的后端节点，负责数据存储、SQL执行等工作。

数据存储方面，StarRocks 的 BE 节点都是完全对等的，FE 按照一定策略将数据分配到对应的 BE 节点。BE 负责将导入数据写成对应的格式存储下来，并生成相关索引。

在执行 SQL 计算时，一条 SQL 语句首先会按照具体的语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在对应的数据存储节点上执行，这样可以实现本地计算，避免数据的传输与拷贝，从而能够得到极致的查询性能。

在进行 Stream load 导入时，FE 会选定一个 BE 节点作为 Coordinator BE，负责将数据分发到其他 BE 节点。导入的最终结果由Coordinator BE 返回给用户。

5.2.3 中转服务-Broker

​StarRocks中和外部HDFS/对象存储等外部数据对接的中转服务，与StarRocks 的前端（FE）和后端（BE）节点协同工作，完成数据的导入、导出和查询任务。具体包括：

• 数据导入：从外部存储系统（如 HDFS、S3）导入数据到 StarRocks。
• 数据导出：将 StarRocks 中的数据导出到外部存储系统。
• 外部表查询：通过 Broker 访问外部存储系统中的数据，支持直接查询外部数据而无需导入。

主要使用场景如下：

• 数据湖查询加速
  • 场景描述：StarRocks 可以通过 Broker 直接查询数据湖（如 HDFS、S3）中的数据，而无需将数据导入到 StarRocks 中。
  • 优势：减少数据迁移成本，支持实时查询外部数据。
• 数据导入与导出
  • 场景描述：Broker 用于从外部存储系统（如 HDFS、S3）批量导入数据到 StarRocks，或者将 StarRocks 中的数据导出到外部存储系统。
  • 优势：支持大规模数据的高效导入和导出。
• 冷热数据分离
  • 场景描述：将热数据存储在 StarRocks 中，冷数据存储在外部存储系统（如 S3）中，通过 Broker 实现冷热数据的统一查询。
  • 优势：降低存储成本，同时保持数据的可访问性。
• 多源数据融合
  • 场景描述：通过 Broker 访问多个外部数据源（如 HDFS、S3、OSS），实现多源数据的联合查询和分析。
  • 优势：支持跨数据源的统一分析。

Broker 需要单独部署，并配置与外部存储系统的连接信息（如 HDFS 的 NameNode 地址、S3 的 Access Key 等）。

在 StarRocks 中，Broker 通过名称（Broker Name）进行标识，可以在 SQL 语句中指定使用的 Broker。

• 数据导入

LOAD LABEL example_db.label1
(
    DATA INFILE("hdfs://namenode:8020/path/to/data")
    INTO TABLE my_table
)
WITH BROKER "broker_name"
(
    "username" = "hdfs_user",
    "password" = "hdfs_password"
);

• 数据导出

EXPORT TABLE my_table
TO "hdfs://namenode:8020/path/to/export"
WITH BROKER "broker_name"
(
    "username" = "hdfs_user",
    "password" = "hdfs_password"
);

• 外部表查询

CREATE EXTERNAL TABLE external_table
(
    col1 INT,
    col2 STRING
)
ENGINE=FILE
LOCATION 'hdfs://namenode:8020/path/to/data'
WITH BROKER "broker_name"
(
    "username" = "hdfs_user",
    "password" = "hdfs_password"
);

在使用Broker时我们需要注意：

• 网络带宽：Broker 的性能受限于网络带宽，尤其是在与远程存储系统（如 S3）交互时。
• 存储系统兼容性：需要确保外部存储系统的版本和配置与 Broker 兼容。
• 安全性：在使用 Broker 时，需注意存储系统的访问权限和认证信息的安全性。

5.2.4 数据分布与复制

StarRocks的数据表会被划分为多个tablet（数据分片），这些tablet均匀分布在BE节点上，形成分布式数据存储。

为了实现高可用和容错，StarRocks支持数据的多副本备份，每个tablet可以在不同BE节点上有多份拷贝。

5.2.5 查询处理流程

5.2.6 集群扩展与稳定性

StarRocks通过增加FE和BE节点数量来线性扩展处理能力和存储容量。

通过心跳机制监控节点健康状况，并自动调整负载均衡和故障转移，保障系统的稳定性和可用性。

StarRocks_259">6.StarRocks的安装与部署

官方推荐docker按照，如果本地安装的话，我们既需要配置 Frontend (FE)还需要配置 Backend，并且启动也是需要分别启动，所以本文也仅提供docker安装方式，详细安装步骤可以移步:《docker安装StarRocks》

StarRocks__261">7.StarRocks 表设计

7.1 列式存储

StarRocks 是一款高性能的分布式 SQL 数据库，其核心特点之一就是采用了 列式存储（Columnar Storage）。列式存储是一种数据存储方式，与传统的行式存储（Row-based Storage）相比，它在处理大规模数据分析场景中具有显著的优势。

StarRocks_264">7.1.1 为什么StarRocks要使用列式存储

行式存储 vs 列式存储

行式存储：将一行数据的所有列存储在一起，适合事务处理（OLTP）场景，如插入、更新、删除等操作。

列式存储：将每一列的数据存储在一起，适合分析处理（OLAP）场景，如聚合、过滤、统计等操作。

列式存储的优势

高效的数据压缩：同一列的数据类型相同，更容易压缩，节省存储空间。

快速查询性能：只读取查询所需的列，减少 I/O 开销。

适合聚合操作：对某一列的聚合操作（如 SUM、AVG）更加高效。

向量化执行：列式存储天然适合向量化计算，提升 CPU 缓存命中率。

StarRocks的表和关系型数据相同, 由行和列构成。每行数据对应用户一条记录, 每列数据有相同数据类型。

所有数据行的列数相同, 可以动态增删列。

StarRocks中, 一张表的列可以分为

• 维度列(也成为key列)，
• 指标列(value列)

维度列用于分组和排序, 指标列可通过聚合函数SUM, COUNT, MIN, MAX, REPLACE, HLL_UNION, BITMAP_UNION等累加起来。 因此, StarRocks的表也可以认为是多维的key到多维指标的映射.

在StarRocks中, 表中数据按列存储

• 物理上, 一列数据会经过分块编码压缩等操作，每一列的数据单独存放，每列数据会进一步划分为多个数据块（Block），便于并行处理和压缩。
• 在逻辑上, 一列数据可以看成由相同类型的元素构成的数组。

7.1.2 行号

一行数据的所有列在各自的列数组中保持对齐, 即拥有相同的数组下标, 该下标称之为序号或者行号。

该序号是隐式, 不需要存储的, 表中的所有行按照维度列, 做多重排序, 排序后的位置就是该行的行号。

查询时, 如果指定了维度列的等值条件或者范围条件, 并且这些条件中维度列可构成表维度列的前缀, 则可以利用数据的有序性, 使用range-scan快速锁定目标行。例如:

• 对于表table1: (event_day, siteid, citycode, username)➜(pv);
• 当查询条件为event_day > 2020-09-18 and siteid = 2, 则可以使用范围查找;
• 如果指定条件为citycode = 4 and username in [“Andy”, “Boby”, “Christian”, “StarRocks”], 则无法使用范围查找。
  • 因为它的第一个条件的字段是 citycode 对应不上 starrocks 的第一个维度列，所以就无法优化查询速度）

所以我们在查询的时候需要尽量遵守这个规则。

7.2 索引

当进行范围查询时，StarRocks如何快速定位到起始目标行呢？答案是使用shortkey index. shortkey index为稀疏索引。

值得注意的是稀疏索引并不是为表中的每一行数据都创建索引项，而是每隔一定数量的数据行（例如每1024行）创建一个索引项。这样可以显著减少索引所需的存储空间，并且由于索引项较少，索引本身也可以更容易地被加载到内存中，从而提高查询效率。

7.2.1 工作原理

表中组织由三个部分组成：
（1）shortkey index表:表中数据每1024行, 构成一个逻辑block。每个逻辑block在shortkey index表中存储一项索引, 内容为表的维度列的前缀, 并且不超过36字节。 shortkey index为稀疏索引, 用数据行的维度列的前缀查找索引表, 可以确定该行数据所在逻辑块的起始行号。

（2）Per-column data block:这是实际存储数据的物理块（经过压缩）。表中每一列数据按64KB分块存储, 数据块作为一个单位单独编码压缩, 也作为IO单位, 整体写回设备或者读出.

（3）Per-column cardinal index:专门存放地址。表中的每列数据有各自的行号索引表, 列的数据块和行号索引项一一对应, 索引项由数据块的起始行号和数据块的位置和长度信息构成, 用数据行的行号查找行号索引表, 可以获取包含该行号的数据块所在位置, 读取目标数据块后, 可以进一步查找数据.

由此可见, 查找维度列的前缀的查找过程为: 先查找shortkey index, 获得逻辑块的起始行号, 查找维度列的行号索引, 获得目标列的数据块, 读取数据块, 然后解压解码, 从数据块中找到维度列前缀对应的数据项。

7.2.2 使用示例

当创建一个表时，可以指定某些列为排序键。表中的数据将根据这些排序键进行排序后存储。然后，每1024行数据会被组织成一个逻辑数据块（Data Block），每个逻辑数据块在前缀索引表中会有一个对应的索引项。这个索引项包含的是该数据块第一行数据的排序键值，用于快速定位到特定的数据块。

例如，假设我们有一个表，其中包含以下字段：event_day, site_id, city_code, user_id, 和 pv（页面浏览量）。如果我们定义了 (event_day, site_id) 作为排序键，那么 StarRocks 将按照这两个字段对数据进行排序，并为每1024行生成一个稀疏索引项。

7.2.3 使用场景

稀疏索引特别适用于那些需要频繁进行范围查询的场景。比如，如果您经常需要根据时间范围或地理位置来过滤数据，那么使用稀疏索引可以帮助加速这类查询。此外，由于稀疏索引减少了索引的大小，因此对于大规模数据集来说，它也是一种节省存储资源的有效手段。

7.2.4 注意事项

尽管稀疏索引能带来性能上的提升，但它并不适合所有类型的查询。对于那些不涉及排序键或者只涉及少量记录的查询，稀疏索引可能不会提供显著的好处。

此外，在设计表结构时选择合适的排序键非常重要，因为它直接影响到稀疏索引的效果以及查询的性能表现。如果排序键选择不当，可能会导致查询性能下降而非提升。

7.3 加速数据处理设计

7.3.1 预先聚合

概念

预先聚合（Pre-Aggregation）是指在数据写入时进行部分或全部聚合操作，而不是在查询时进行。这样可以显著减少查询时需要处理的数据量，从而加快查询速度。

实现方式

• 聚合模型：StarRocks 支持聚合模型，在这种模型下，相同维度列值的数据行会被合并为一行，指标列则会根据用户指定的聚合函数（如 SUM, COUNT, AVG 等）进行计算。
• 物化视图：通过创建物化视图，用户可以定义预计算的结果集，并在查询时直接使用这些结果，避免重复计算。

应用场景

• 实时分析：对于频繁执行的聚合查询，预先聚合可以显著提高查询性能。
• 大规模数据集：当数据量非常大时，预先聚合可以减少查询时的数据扫描量，提升响应速度。

示例

CREATE TABLE sales (
    date DATE,
    product_id INT,
    region STRING,
    sales_amount DOUBLE
) AGGREGATE KEY(date, product_id, region)
DISTRIBUTED BY HASH(product_id) BUCKETS 10
PROPERTIES (
    "function" = "SUM(sales_amount)"
);

7.3.2 分区分桶

概念

分区分桶（Partitioning and Bucketing）是将数据切分成多个小块（tablet），并分布存储在不同的Backend 节点上，以便并行处理查询。

实现方式

• 分区：按某一列（如日期、地区等）进行逻辑分区，使得查询可以根据分区条件快速定位到相关数据。
• 桶：每个分区内的数据被进一步切分为多个 tablet，每个 tablet 可以有多副本冗余存储在不同的 BE 节点上，确保高可用性和负载均衡。

应用场景

• 大规模数据集：通过分区和桶划分，可以有效管理大规模数据集，提高查询效率。
• 并行处理：查询时，多个 BE 节点可以并行地查找相应的 tablet，加快数据获取速度。

示例

CREATE TABLE sales_partitioned (
    date DATE,
    product_id INT,
    region STRING,
    sales_amount DOUBLE
) PARTITION BY RANGE (date) (
    PARTITION p2023_q1 VALUES [('2023-01-01'), ('2023-04-01')),
    PARTITION p2023_q2 VALUES [('2023-04-01'), ('2023-07-01'))
) DISTRIBUTED BY HASH(product_id) BUCKETS 10;

7.3.3 列级别的索引技术

概念

列级别索引技术包括 Bloom Filter、ZoneMap 和Bitmap 索引 ，它们分别用于不同类型的查询优化。

实现方式

• Bloom Filter：用于快速判断某个值是否存在于数据块中，适合稀疏列的过滤。
• ZoneMap：记录每列的最大值和最小值，用于快速过滤不符合条件的数据块。
• Bitmap 索引：用于枚举类型列的高效查询，特别适合布尔值或有限取值范围的列。

应用场景

• 高效过滤：Bloom Filter 和 ZoneMap 可以帮助快速过滤掉不需要的数据块，减少 I/O 操作。
• 枚举类型查询：Bitmap 索引适用于频繁查询的枚举类型列，提供高效的查询性能。

7.3 示例

-- 创建包含 Bloom Filter 的表
CREATE TABLE users (
    user_id BIGINT,
    age INT,
    active BOOLEAN
) WITH (
    "bloom_filter_columns" = "age"
);

-- 创建包含 ZoneMap 的表
CREATE TABLE orders (
    order_id BIGINT,
    order_date DATE,
    amount DOUBLE
) WITH (
    "zone_map_columns" = "order_date"
);

-- 创建包含 Bitmap 索引的表
CREATE TABLE products (
    product_id BIGINT,
    category STRING
) WITH (
    "bitmap_index_columns" = "category"
);

通过上述几种关键技术，StarRocks 能够显著加速数据处理和查询性能。

• 合理选择聚合模型：根据业务需求选择合适的聚合模型和聚合函数，确保数据写入时的预计算能够最大化查询性能。
• 优化分区和桶策略：根据数据特性和查询模式设计合理的分区和桶策略，确保查询时能充分利用并行处理能力。
• 利用 RollUp 表索引：为频繁使用的查询条件创建 RollUp 表索引，减少查询时的计算负担。
• 配置列级索引：根据列的特点选择合适的索引技术，提高数据过滤和查询效率。

7.4 数据模型

目前StarRocks根据摄入数据和实际存储数据之间的映射关系，分为明细模型（Duplicate key）、聚合模型（Aggregate key）、更新模型（Unique key）和主键模型（Primary key）。

7.4.1 明细模型

明细模型是默认的建表模型。如果在建表时未指定任何模型，默认创建的是明细类型的表。它就像我们数仓中的 ODS 层或者 DWD 层，也就是说这个表中存储的是一些明细数据（比如用户的所有下单记录）。

StarRocks建表默认采用明细模型，排序列使用稀疏索引，可以快速过滤数据。明细模型用于保存所有历史数据，并且用户可以考虑将过滤条件中频繁使用的维度列作为排序键，比如用户经常需要查看某一时间，可以将事件时间和事件类型作为排序键。

剩余内容持续输出中。。。