第2.1章 StarRocks表设计——概述_starocks 3.2

注：本篇文章阐述的是StarRocks-3.2版本的表设计相关内容。

    建表是使用StarRocks非常重要的一环，规范化的表设计在某些场景下能使查询性能有数倍的提升。StarRocks的表设计涉及到的知识点主要包括数据表类型、数据分布（分区分桶及排序键）、索引以及视图、物化视图等。

一、数据表类型

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

1.1 Duplicate Key Model

  明细模型是StarRocks中最常用的数据模型，适用于既没有聚合需求，又没有主键唯一性约束的原始数据的存储。在该模型下，即便导入两条完全相同的数据，StarRocks也会将数据原封不动的保存进表。

1.2 Aggregate Key Model

    聚合模型会在数据导入时将维度列相同的数据，根据指标列设定的聚合函数进行聚合，最终表格中只会保留聚合后的数据。

1.3 Unique Key Model

    更新模型的特点是只保留相同主键下最新导入的数据。在更新模型中，排序键构成表的唯一性约束，成为我们常说的“主键”。（明细模型会将所有写入的数据保留，聚合模型是对写入的数据进行聚合处理）

1.4 Primary Key Model

    主键模型建表时支持定义主键和指标列，查询时返回主键相同的一组数据中的最新数据。主键模型和更新模型的区别在于：更新模型的实现方式是读时合并（merge on read)，简称Mor 。Primary 模型实现方式是写时合并（merge on write)，简称mow。聚合模型和更新模型都不支持update功能，主键模型通过Delete+Insert 的策略，实现update功能。

   ps：数据表（数据模型）的详细内容见文章： 

第2.2章 StarRocks表设计——排序键和数据模型_starrocks排序键和分桶键-CSDN博客

二、数据分布

    StarRocks 采用分区+分桶的两级数据分布策略，将数据均匀分布各个 BE 节点。查询时能够有效裁剪数据扫描量，最大限度地利用集群的并发性能，从而提升查询性能。

2.1 分区

    逻辑概念，表中数据可以根据分区列（通常是时间和日期）分成一个个更小的数据管理单元。查询时，通过分区裁剪，可以减少扫描的数据量，显著优化查询性能。

2.2 分桶

   物理概念，同一个分区中的数据通过分桶，划分成更小的数据管理单元。并且分桶以多副本形式（默认为3）均匀分布在BE节点上，保证数据的高可用。

  一个分区按分桶方式被分成了多个桶bucket，每个桶的数据称之为一个Tablet。StarRocks一般采用Hash算法作为分桶算法，即在同一分区内，分桶键哈希值相同的数据会划分到同一个Tablet（数据分片），Tablet 以多副本冗余的形式存储，是数据均衡和恢复的最⼩单位，数据导入和查询最终都下沉到所涉及的Tablet 副本上。（建表时，如果使用哈希分桶，则必须指定分桶键）

   ps：分区分桶及副本的详细内容见文章（文章是StarRocks-2.5.4）： 

第2.4章 StarRocks表设计——分区分桶与副本数_starrocks中主键表创建表达式分区-CSDN博客

三、数据类型

      除了基本的数据类型，如数值、日期和字符串类型，StarRocks 还支持复杂的半结构化数据类型，包括 ARRAY、JSON、MAP、STRUCT。

四、存储设计

4.1 列式存储

   在StarRocks中，一张表的列可以分为维度列（也称为 Key 列）和指标列（也称为 Value 列）。维度列用于分组和排序，指标列的值可以通过聚合函数sum，count，min，max，bitmap_union等累加起来。

   在StarRocks中，表数据按列存储。物理上，一列数据会经过分块编码（data page，默认是64kb）、压缩等操作，然后持久化存储到非易失设备上。但在逻辑上，一列数据可以看成是由相同类型的元素构成的一个数组。 一行数据的所有列值在各自的数组中按照列顺序排列，即拥有相同的数组下标。表中所有的行按照维度列，做多重排序，排序后的位置就是该行的行号。

4.2 索引

   索引是一种特殊的数据结构，相当于数据的目录。查询条件命中索引列时，StarRocks 能够快速定位到满足条件的数据的位置。

    StarRocks 提供内置索引，包括前缀索引、Ordinal索引和 ZoneMap索引。也支持用户手动创建索引，以提高查询效率，包括 Bitmap和 Bloom Filter 索引。

 4.2.1 前缀索引

    由于StarRocks底层数据是按照排序键排序后存储的，而前缀索引是在key (duplicate key、aggregate key、unique key、primary key)排序的基础上，实现的一种根据给定一定数量（不超过3列，不超过36个字节，遇到字符串会自动截断）前缀列，每间隔一定行数（1024），生成的一个索引项 （稀疏索引）。当查询的过滤条件命中前缀索引时，就能快速定位到数据存储所在的比较精确地址。

 4.2.2 Ordinal 索引

   Ordinal lndex索引提供了通过行号来查找Column Data Page数据页的物理地址，Ordinal lndex索引能够将按照列存储的数据按行对齐，可以理解为一级索引。因此，其他类型的索引在查找数据的时候，都要借助Ordinal lndex（一级索引）查找 Data Page数据页物理地址。

    在一个segment文件中，数据始终按照key排序存储，数据写入的过程中，每一列的data page会由Ordinal Index管理，他会记录每一列对应的data page的offset，size大小，和该data page的第一个数据的行号信息。这样在查询的时候，就能通过Ordinal lndex索引够快速定位到对应的data page的物理地址。

 4.2.3 ZoneMap 索引

   StarRocks 会为Segment文件中的一列数据（key 列）自动添加ZoneMap索引，当表的模型为dupulcate时，会所有字段开启zonemap索引。

   ZoneMap索引存储了Segment和每个列对应每个Page的统计信息。Doris可以根据这些统计信息，快速判断这些数据块是否可以过滤掉，从而减少扫描数据量，提升查询速度。统计信息包括了Min最大值、Max最小值、HashNull空值、HasNotNull不全为空的信息。

 4.2.4 BitMap 索引

    StarRocks 支持对低基数列创建Bitmap位图索引来加速数据查询。高基数列：例如UserID，低基数列：例如性别，婚姻状态等。

     Bitmap位图索引创建时需要通过create index进行创建。Bitmap的索引是整个Segment中的Column字段的索引，而不是为每个Page单独生成一份。在写入数据时，会维护一个map结构，去记录下每个key值对应的行号，并采用Roaring位图对rowid进行编码。生成索引数据时，首先写入字典数据，即将map结构的key值写入到DictColumn中。然后，key对应Roaring编码的rowid（value值）以字节方式将数据写入到BitMapColumn。   

 4.2.5 BloomFilter 索引

   StarRocks 支持用户对适用于高基数列（取值区分度比较大的字段）添加Bloom Filter（布隆过滤器）索引，Bloom filter索引主要用于快速判断某列中是否存在某个值。BloomFilter判定该列中不存在指定的值，如果确定不存在，就不会读取这个数据文件；如果索引判定该列中存在指定的值，也有可能这个值实际上不会存在，这时会读取数据文件来进一步确认。

  ps：高基数列:例如UserID，低基数列:例如性别，婚姻状态等。

 ps：这几类索引的详细内容见文章：

Doris存储层设计介绍1——存储结构设计解析（索引底层结构）_doris底层结构-CSDN博客

五、物化视图

待补充~

参考文章：

表概览 | StarRocks

理解 StarRocks 表设计 | StarRocks

理解 StarRocks 表设计 | StarRocks

第2.1章：StarRocks表设计--概述_starrocks array-CSDN博客