StarRocks详解

什么是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 LoadStarRocks通过这种方式支持从Kafka持续不断的导入数据,并且支持通过SQL控制导入任务的暂停,重启,停止。将Job提交给FE,拆分成多个task,将task并行的向BE(StarRocks)里面写
Spark Load
Insert into只是通过写SQL来操作。
Flink Connector
Datax Writer

Colocate join:

colocate join可以避免数据网络传输开销,核心思想是将同一个Colocation Group中表采用一致的分桶键,一致的副本数量和一致副本放置方式。因此如果join列分桶键一致,则计算节点只需做本地join即可,无须从其他节点获取数据,从而规避网络shuffle的过程。

可以通过设置PROPERTIES("colocate_with" = "group"),如果colocate:true,那么就是得到了colocate join优化,如果colocate:false,那么就是没有得到colocate join优化(可能会存在shuffle)。

StarRocks外部表:

<think>好的,我现在需要向用户介绍StarRocks的自增功能。首先,我要理解用户的问题是什么。他们可能想知道StarRocks中是否有自增列,如何实现自增,或者有什么使用场景和注意事项。 首先,我应该回顾StarRocks的文档,确认自增功能的支持情况。记得StarRocks在某个版本之后引入了自增列,可能是在3.0之后。需要确认这一点,避免提供错误的信息。 接下来,自增列的定义方式。通常是在建表时使用AUTO_INCREMENT属性,比如在某个字段后面。例如,CREATE TABLE语句中的某个列定义为BIGINT AUTO_INCREMENT,然后指定主键或者唯一键。需要详细说明语法结构,可能需要举例说明,比如创建表时的语句示例。 然后,自增列的作用。用户可能关心它的用途,比如用于主键、唯一标识,或者避免写入时的冲突。需要解释自增列如何保证唯一性,特别是在分布式系统中如何生成唯一值,是否会有性能影响。 接下来是使用场景。常见的应用包括主键自动生成、数据分片、或者作为业务逻辑中的唯一标识。需要举几个具体的例子,比如订单ID、用户ID等,这样用户更容易理解。 然后,注意事项。这部分很重要,因为用户可能会遇到问题。比如自增列不能更新,必须为主键的一部分,初始值和步长的设置,以及与其他系统的兼容性。如果有版本限制,比如某些功能只在特定版本中可用,需要明确指出。 另外,可能需要提到自增列的实现机制,比如是否基于全局或本地的计数器,是否有性能瓶颈。比如,StarRocks可能采用了一种分布式ID生成策略,确保高并发下的唯一性和有序性。 需要检查是否所有的技术细节都正确,比如AUTO_INCREMENT是否只支持BIGINT类型,是否必须为主键,是否允许显式插入值,或者插入时是否可以忽略该列。例如,当用户插入数据时,如果不指定自增列的值,系统会自动生成;如果指定了,可能会覆盖,但需要确认是否有冲突的风险。 可能还需要比较StarRocks的自增功能与其他数据库(如MySQL的AUTO_INCREMENT或PostgreSQL的SERIAL)的异同,帮助用户迁移或理解差异。 最后,结构安排要清晰,分点列出,如自增列的定义、作用、使用场景、注意事项,每个部分用子标题分开,方便用户阅读。同时,要确保使用正确的中文术语,避免技术术语翻译错误。 在撰写过程中,要确保所有数学表达式或代码示例使用正确的格式,比如用$...$或$$...$$包裹LaTeX表达式,但根据用户的要求,可能不需要数学公式,而是代码块。不过用户提到系统级指令中的数学表达式需要正确格式,但在当前问题中可能涉及较少,重点在代码示例,比如CREATE TABLE语句中的AUTO_INCREMENT。需要确认代码示例的正确性,例如: CREATE TABLE example ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(50), ... ) PRIMARY KEY (id) DISTRIBUTED BY HASH(id) BUCKETS 10; 这里是否正确?需要确认StarRocks的建表语法是否要求主键在列定义后指定,或者是否使用其他关键字,比如DUPLICATE KEY或UNIQUE KEY。可能需要查阅最新的文档,确保示例准确无误。 此外,是否支持复合主键中的自增列?比如,主键包含多个列,其中一个是自增的。或者自增列是否必须是主键的一部分?比如,在StarRocks中,自增列必须被包含在主键中,否则会报错。这一点需要注意,并在注意事项中说明。 还有,自增列的起始值和步长是否可以调整?例如,MySQL可以设置AUTO_INCREMENT=100,StarRocks是否支持类似的语法?如果有,需要说明;如果没有,也要指出当前不支持,用户只能使用默认的起始值和步长。 另外,分布式系统中的自增ID生成可能会有性能问题,比如全局锁或者冲突。StarRocks如何处理这个问题?是否采用了分片ID的方式,比如每个节点有自己的ID范围,或者使用雪花算法等分布式ID生成方法?这可能影响自增ID的唯一性和有序性,需要简要说明。 最后,总结自增功能的优点和限制,帮助用户决定是否适合他们的使用场景。比如,高并发插入时是否会有瓶颈,自增ID是否单调递增,是否保证连续等。 现在,将这些思考整理成一个结构化的回答,确保每个部分都涵盖必要的信息,同时语言简洁明了,符合用户的要求。</think>### StarRocks自增列详解 #### 1. **定义与语法** StarRocks通过 `AUTO_INCREMENT` 属性实现自增列功能(自3.0版本起支持),**仅支持 `BIGINT` 类型**,且必须作为主键(或主键的一部分)。建表示例如下: ```sql CREATE TABLE user_orders ( order_id BIGINT NOT NULL AUTO_INCREMENT, user_name VARCHAR(50), amount DECIMAL(10,2), PRIMARY KEY (order_id) ) DISTRIBUTED BY HASH(order_id) BUCKETS 10; ``` - **关键规则**: - 自增列需显式定义为主键(或联合主键之一)。 - 插入数据时,若未指定自增列值,系统自动生成唯一值;若手动指定,需确保不冲突。 #### 2. **核心作用** - **唯一标识**:自动生成分布式唯一ID,避免主键冲突。 - **简化写入**:无需业务层生成ID,降低写入复杂度。 - **查询优化**:自增主键天然有序,可提升范围查询效率。 #### 3. **适用场景** - **高并发插入**:如日志采集、IoT设备数据写入,自动生成ID避免性能瓶颈。 - **无业务含义主键**:订单ID、用户ID等场景,无需结合业务字段。 - **分片与负载均衡**:通过哈希分布自增列,实现数据均匀分布。 #### 4. **注意事项** - **禁止更新**:自增列一旦生成,不可通过 `UPDATE` 修改。 - **显式插入限制**:手动插入值需全局唯一,否则报错。 - **起始值与步长**:当前版本不支持自定义(默认从1开始,步长1)。 - **分布式唯一性**:采用全局协调策略,但**不保证严格连续**(如节点重启可能导致ID间隙)。 #### 5. **实现机制** StarRocks通过“全局预分配+本地缓存”策略保障高性能: 1. **预分配区间**:FE(前端节点)向BE(后端节点)分配ID区间(如1000个ID块)。 2. **本地消耗**:BE直接在内存中使用预分配ID,减少全局锁竞争。 3. **区间耗尽时**:BE重新向FE申请新区间,确保高吞吐。 #### 6. **对比其他数据库** | 特性 | StarRocks | MySQL | |---------------------|--------------------|--------------------| | 分布式支持 | ✔️ | ❌(单机自增) | | 主键要求 | 必须为主键 | 无需主键 | | 自定义步长/起始值 | ❌ | ✔️ | | 严格连续性与单调性 | 仅保证单调递增 | 单机连续,集群不保证 | #### 7. **最佳实践** - **避免过度依赖连续性**:设计业务逻辑时允许ID存在间隙。 - **监控ID分配**:通过SHOW PROC语句观察预分配区间使用情况。 - **版本兼容性**:确保集群版本≥3.0,并定期升级以获得优化修复。 #### 总结 StarRocks自增列是分布式场景下简化主键管理的利器,尤其适合高吞吐写入与无状态服务。需注意其分布式特性带来的限制(如不连续),结合业务需求选择是否采用。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值