StarRocks数据库详解(什么是StarRocks)_ar

starrocks介绍

starrocks，作为新一代极速全场景mpp（massively parallel processing）数据库，充分汲取了关系型olap数据库与分布式存储系统在大数据时代的精髓。通过不断的改进与优化，它在架构上进行了升级，并增添了诸多创新功能，从而演变为一款领先的企业级产品。starrocks致力于为用户提供极速且统一的分析体验，能够灵活应对各种数据分析场景。它支持多种数据模型、导入方式，并能轻松整合及接入现有系统，如spark、flink、hive和elasticsearch等。

此外，starrocks还兼容mysql协议，使得用户能够通过mysql客户端及常用bi工具轻松进行数据分析。其分布式架构特性使得数据表能够水平划分并多副本存储，集群规模可灵活调整，支持高达10pb级别的数据分析。同时，mpp框架的引入使得计算能够并行加速，而多副本设计则提供了弹性容错能力。

在技术层面，starrocks采用关系模型和严格的列式存储引擎，通过精妙的编码和压缩技术来降低读写放大效应。其向量化执行方式能充分利用多核cpu的并行计算能力，从而显著提升查询性能。要实现这一技术，需要借助cpu的simd指令集，这是一种能够在cpu寄存器层面实现数据并行操作的技术。

什么是starrocks？

starrocks是新一代极速全场景mpp数据库（高并发数据库）。

starrocks充分吸收关系型olap数据库和分布式存储系统在大数据时代的优秀研究成果。

1.可以在spark和flink里面处理数据，然后将处理完的数据写到starrocks里面。

2.可以实现将数据从hadoop倒入到starrocks里面去，也可以将starrocks的数据倒入到hadoop里面，都是可以实现的。

3.可以对接es数据库（elasticsearch）。

4.starrocks兼容mysql的协议，可以通过 mysql的客户端和常用bi工具对接starrocks来进行数据分析。

5.starrocks采用分布式架构，对数据表进行水平划分并且以多副本存储，集群规模可以灵活伸缩，能够支持10pb级别的数据分析，支持mpp框架，并行加速计算，支持多副本，具有弹性容错能力。

starrocks适合什么场景？

1.olap多维分析：用户行为分析，用户画像，财务报表，系统监控分析。

2.实时数据分析：电商数据分析，直播质量分析，物流运单分析，广告投放分析。

3.高并发查询：广告主表分析，dashboard多页面分析。

4.统一分析：通过使用一套系统解决上述场景，降低系统复杂度和多技术栈开发成本。

starrocks基本概念：

1.fe：frondend是starrocks的前端节点，负责管理元数据，负责与客户端连接，进行查询规划，查询调度等工作。

2.be：backend时starrocks的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。

3.broker：broker并不是必须出现的，当starrocks和hdfs进行交互的时候（也就是数据从hdfs到starrocks中和数据从starrocks中到hdfs里面），那么starocks负责这个过程的中转服务，辅助提供导入导出功能。

4.starrocksmanager：starrocks的可视化工具，提供starrocks的集群管理，在线查询，故障查询，监控报警的可视化工具。

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

starrocks系统架构：

fe：

1.接受mysql客户端的连接，解析并且执行sql语句。

2.管理元数据，执行sql ddl命令，用catalog记录库，表，分区，tablet副本等信息。

3.fe高可用部署，使用复制协议选主和主从同步元数据，所有的元数据修改操作，都有fe的leader节点完成，fe的follower节点可执行读操作。元数据的读写满足顺序一致性，fe的节点数目采用2n+1，可以容忍n个节点故障，当fe leader故障的时候，可以从现有的follower节点中重新选主，完成故障切换。

4.fe中的sql layer对用户提交的sql进行解析，分析，改写，语义分析和关系代数优化，生产逻辑执行计划。

5.fe中的planner负责把逻辑计划转化为可分布式执行的物理计划，分发给一组be。

6.fe监督be，管理be的上下线，根据be的存活和健康状态，维持tablet副本的数量。

7.fe协调数据导入，保证数据导入的一致性。

be：

1.be管理tablet副本，tablet时table经过分区分桶形成的子表，采用列式存储。

2.be受fe指导，创建或删除子表。

3.be接收fe分发的物理执行计划并指定be coordinator节点，在be coordinator的调度下，与其他be worker共同协作完成执行。

4.be读本地的列存储引擎获取数据，并通过索引和谓词下沉快速过滤数据。

5.be后台执行compact任务，减少查询时的读放大。

6.数据导入的时候，由fe指定be coordinator，将数据以fanout的形式写入到tablet多副本所在的be上。

starrocks为什么快：

列式存储：starrocks中，一张表的列可以分为维度列（key列）和指标列（value列），维度列用于分组和排序，指标列可通过聚合函数等累加起来。starrocks可以认为是多维的key到多维指标的映射。（在写sql的时候最好要根据表的前缀，类似于mysql的索引最左前缀原则）

稀疏索引：当进行范围查询时，starrocks能够快速定位到起始目标行，是因为shortkey index（稀疏索引）。

预先聚合：starrocks支持聚合模型，维度列取值相同数据行可合并一行，合并后数据行的维度列取值不变，指标列的取值为这些数据行的聚合结果，用户需要给指标列指定聚合函数，通过预先聚合，可以加速聚合操作。

分区分桶：starrocks的表被分为tablet，每个tablet多副本冗余存储在be上，be和tablet的数量可以根据计算资源和数据规模而弹性伸缩，查询时，多台be可并行地查找tablet快速获取数据。而且tablet的副本可以复制和前一，增强了数据的可靠性，避免了数据倾斜。

列级别的索引技术：bloomfilter可以快速判断数据块中不含所查找值，zonemap通过数据范围快速过滤待查找值，bitmap索引可快速计算出枚举类型的列满足一定条件的行。

starrocks的4种表模型：

明细模型（duplicate key）：关注历史数据。

聚合模型（aggregate key）：关注总量，平均值，最大值，最小值，计算一个统一的指标。

更新模型（unique key）：设定一个主键（uid），主键是唯一的，如果主键是第一次出现在表中，那么执行插入操作，如果主键第二次出现在表中，那么执行更新操作，覆盖前一条记录。（并不是真的覆盖，其实也存着明细数据，只是将最新的一条记录返回）

主键模型（primary key）：主键模型相当于是更新模型的升级版，速度更快一些。更新模型采用merge on read读时合并策略会大大限制查询功能，在主键模型更好地解决了行级的更新操作。配合flink-connector-starrocks可以完成mysql cdc实时同步的方案。存储引擎会为主键建立索引，导入数据时会把索引加载到内存中，所以主键模型对内存的要求更高。真正保证每个主键只有一条数据存在。

各自适用场景：

1.明细模型：建表的时候注意设置排序列（duplicate key）

关注历史明细数据。

2.聚合模型：建表的时候注意设置聚合列（ distributed by hash(site_id) ）

业务方进行查询为汇总类查询，比如sum，count，max。

不需要查看明细数据。

老数据不会被频繁修改，只会追加和新增。

3.更新模型：建表的时候注意设置unique key 唯一列(create_time,order_id)

数据需要进行更新，比如拉链表。

已经写入的数据有大量的更新需求。（比如电商场景中，订单的状态经常会发生变化，没必要用明细表记录变化趋势，使用更新模型记录最新的状态即可）

需要进行实时数据分析。

4.主键模型：建表的时候注意primary key主键列（user_id）

数据冷热特征：只有最近几天的数据才需要修改，老的冷数据很少需要修改，比如订单数据，老的订单完成后就不再更新，并且分区是按天进行分区的，那么在导入数据时历史分区的数据的主键就不会被加载，也就不会占用内存了，内存中仅会加载近几天的索引。

大宽表（数百列数千列）：主键只占整个数据的很小一部分，内存开销比较低。比如用户状态/画像表，虽然列非常多，但总的用户数量不大，主键索引内存占用相对可控。

starrocks排序列：

明细模型中的排序列可以理解成是 duplicated key

聚合模型中的排序列可以理解成是 aggregate key

更新模型中的排序列可以理解成是unique key

主键模型中的排序列可以理解成是primary key

排序列的设定顺序必须和建表语句的字段顺序一样，如果想使用到排序列那么必须要按照类似于mysql的索引最左前缀原则，设定where条件。

使用排序键的本质其实就是在进行二分查找，所以排序列指定的越多，那么消耗的内存也会越大，starrocks为了避免这种情况发生也对排序键做了限制：

1.排序键的列只能是建表字段的前缀。

2.排序键的列数不能超过3.

3.字节数不超过36字节。

4.不包含float/double类型的列。

5.varchar类型列只能出现一次，并且是末尾位置。

物化视图：materialized view（mvs）物化视图

在基于维度进行分析的时候，需要使用物化视图。

starrocks中bitmap索引：

bitmap索引利用位数组（bit array）来表示数据集中某个属性的所有可能值是否出现，每个位对应数据表中的一行记录，如果该位为1，则表示该行记录具有指定的属性值；如果为0，则表示不具备。这种结构非常适合于处理布尔型查询或者枚举类型比较少的列查询，比如性别。

bitmap在一些场景下表现的比较优秀，但是同样也存在着局限性：

1.内存消耗：bitmap索引会占据比较大的内存空间。

2.更新成本：当数据插入，删除或者更新的时候，对应的位图需要维护，会产生开销。

总结：最适用的场景是针对于低基数（列中不同值的数量很少），会展现出更高的优化能力。

starrocks中布隆过滤器：

bloom filter（布隆过滤器），是用于快速地判断某个元素是否在一个集合中的数据结构，优点是空间效率和时间效率都很高，缺点是有一定的误判率。就是说，如果布隆过滤器说一个元素不在集合中，那它确实不在；但如果说一个元素可能在这个集合中，这个结论也不一定是正确的。

工作原理：布隆过滤器由一个位数组（二进制向量）和一系列哈希函数组成。在初始化的阶段，所有的位都是0。当一个元素被插入到布隆过滤器中时，会被每一个哈希函数处理，每个哈希函数都会产生一个位数组的索引，然后相应位置的位会被置为1。这样，每个元素的插入都会在位数组中留下多个标记。检查一个元素是否在集合中的时候，也是使用同样的哈希函数计算出多个索引的位置，如果所有这些位置的位都是1，那么可能在集合中，如果任何一位是0，那么就可以确定不在集合中。

（如果布隆过滤器已经判断出集合中不存在指定的值，就不需要读取数据文件。

如果布隆过滤器判断出集合中包含指定的值，就需要读取数据文件确认目标值是否存在。

另外，bloom filter索引无法确定具体是哪一行数据具有该指定的值）

在starrocks中的应用：

减少磁盘i/o：在执行查询时，布隆过滤器可以先于实际数据读取之前被查询，用于快速排除那些肯定不包含查询结果的数据块，从而减少不必要的磁盘读取操作，提高查询效率。

分区剪枝（partition pruning）：在分布式系统中，布隆过滤器可以帮助决定是否需要从特定分区或者节点中读取数据，实现查询的分区剪枝，减少网络传输和计算资源的消耗。

动态调整：starrocks的布隆过滤器支持动态调整其误报率，以适应不同查询场景的需求。通过调整哈希函数的数量和位数组的大小，可以在误报率和存储空间之间找到平衡。

通过在建表的时候设定 properties("bloom_filter_columns"="event_type,sex");

注意事项：

1.不支持对tinyint，float，double类型的列建bloom filter索引。

2.bloom filter索引只对 'in' 和 '=' 过滤查询有加速效果。

3.如果要查看某个查询是否命中了bloom filter索引，可以通过查询的profile信息查看（todo：加上查看profile的链接）。

starrocks的数据导入：

starrocks的数据导入方式	原理和场景
stream load	支持从本地直接导入数据，支持csv格式，数据量在10g以下。原理：stream load中，用户通过http协议提交导入命令，提交到fe节点，fe节点则会通过http重定向指令请求转发给某一个be节点，用户也可以直接提交导入命令指定be节点。
broker load	支持从hdfs，s3等外部存储系统导入数据，支持csv，orcfile，parquet等文件格式，数据量在几十gb到上百gb级别。
rountine load	starrocks通过这种方式支持从kafka持续不断的导入数据，并且支持通过sql控制导入任务的暂停，重启，停止。将job提交给fe，拆分成多个task，将task并行的向be（starrocks）里面写
spark load
insert into	只是通过写sql来操作。
flink connector
datax writer