首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >StarRocks学习-初识

StarRocks学习-初识

作者头像
chimchim
发布2022-11-13 13:13:28
1.8K0
发布2022-11-13 13:13:28
举报

目录

一、什么是StarRocks?

二、适用场景

OLAP 多维分析:

实时数据仓库:

高并发查询:

统一分析 :

 三、系统架构

系统架构图

数据管理

四、StarRocks表设计

列式存储

稀疏索引

加速数据处理

五、数据模型 

明细模型

聚合模型

更新模型 

主键模型 


一、什么是StarRocks?

StarRocks 是一款高性能分析型数据仓库,使用向量化、MPP 架构、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。

二、适用场景

StarRocks 可以满足企业级用户的多种分析需求,包括 OLAP 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。

OLAP 多维分析:

  • 用户画像、标签分析、圈人
  • 用户行为分析
  • 财务报表
  • 业务问题探查分析
  • 高维业务指标报表
  • 自助式报表平台
  • 系统监控分析
  • 跨主题业务分析 

实时数据仓库:

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

高并发查询:

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

统一分析 :

  • 通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景,降低系统复杂度和多技术栈开发与维护成本。
  • 使用StarRocks 来统一数据湖和数据仓库,将高并发和实时要求性很高的业务放在StarRocks中分析,把数据湖上的分析使用StarRocks外表查询,统一使用 StarRocks 管理湖仓数据。

 三、系统架构

系统架构图

 StarRocks的架构简洁,整个系统的核心只有FE(Frontend)、BE(Backend)两类进程,不依赖任何外部组件,方便部署与维护。同时,FE和BE模块都可以在线水平扩展,元数据和数据都有副本机制,确保整个系统无单点。

FE(Frontend)是StarRocks的前端节点,负责管理元数据,管理客户端连接,进行查询规划,查询调度等工作。FE根据配置会有两种角色:Follower和Observer。

  • Follower会通过类Paxos的BDBJE协议选主出一个Leader(实现选主需要集群中有半数以上的Follower实例存活),只有Leader会对元数据进行写操作。非Leader节点会自动的将元数据写入请求路由到Leader节点。每次元数据写入时,必须有多数Follower成功才能确认是写入成功。
  • Observer不参与选主操作,只会异步同步并且回放日志,主要用于扩展集群的查询并发能力。每个FE节点都会在内存保留一份完整的元数据,这样每个FE节点都能够提供无差别的服务。

BE(Backend)是StarRocks的后端节点,负责数据存储以及SQL执行等工作。

数据存储方面,StarRocks的BE节点都是完全对等的,FE按照一定策略将数据分配到对应的BE节点。在数据导入时,数据会直接写入到BE节点,不会通过FE中转,BE负责将导入数据写成对应的格式以及生成相关索引。

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

StarRocks整体对外暴露的是一个MySQL协议接口,支持标准SQL语法。用户通过已有的MySQL客户端能够方便地对StarRocks里的数据进行查询和分析。

数据管理

在StarRocks里,一张表的数据会被拆分成多个Tablet,而每个Tablet都会以多副本的形式存储在BE节点中。StarRocks通过分区、分桶两种划分方式将Table划分成Tablet。通过分区机制(Sharding),一张表可以被划分成多个分区,如将一张表按照时间来进行分区,粒度可以是一天,或者一周等。一个分区内的数据可以根据一列、或者多列进行分桶,将数据切分成多个Tablet。用户可以自行指定分桶的大小。StarRocks会管理好每个Tablet副本的分布信息。 

由于一张表被切分成了多个Tablet,StarRocks在执行SQL语句时,可以对所有Tablet实现并发处理,从而充分的利用多机、多核提供的计算能力。此外,由于每个表可以有不同的表数据切分方式,根据每个表数据量的不同,切分成的Tablet数也可以不同。这样就能够实现在一个大规模集群内,对于不同的表使用不同的资源来进行服务。用户也可以利用StarRocks数据的切分方式,将高并发请求压力分摊到多个物理节点,从而可以通过增加物理节点的方式来扩展系统支持高并发的能力。

Tablet的分布方式与具体的物理节点没有相关性。在BE节点规模发生变化时,比如在扩容、缩容时,StarRocks可以做到无需停止服务,直接完成节点的增减。节点的变化会触发Tablet的自动迁移。当节点增加时,一部分Tablet会在后台自动被均衡到新增的节点,从而使得数据能够在集群内分布的更加均衡。在节点减少时,下线机器上的Tablet会被自动均衡到其他节点,从而自动保证数据的副本数不变。所以,管理员能够非常容易的实现StarRocks的弹性伸缩的操作,不需要手工进行任何数据重分布的操作。

StarRocks支持Tablet多副本存储,默认副本数为三个。多副本够保证数据存储的高可靠,以及服务的高可用。在使用三副本的情况下,一个节点的异常不会影响服务的可用性,集群的读、写服务仍然能够正常进行。另外,增加副本数还有助于提高系统支持高并发查询的能力。

四、StarRocks表设计

列式存储

StarRocks的表和关系型数据相同, 由行和列构成,每行数据对应用户一条记录, 每列数据有相同数据类型。一张表的列可以分为维度列(也成为key列)指标列(value列), 维度列用于分组和排序, 指标列可通过聚合函数SUM, COUNT, MIN, MAX, REPLACE, HLL_UNION, BITMAP_UNION等累加起来。 StarRocks的表也可以认为是多维的key到多维指标的映射。

查询时, 如果指定了维度列的等值条件或者范围条件, 并且这些条件中维度列可构成表维度列的前缀, 则可以利用数据的有序性, 使用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"], 则无法使用范围查找。

稀疏索引

表中数据组织有主要由三部分构成:

  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, 获得逻辑块的起始行号, 查找维度列的行号索引, 获得目标列的数据块, 读取数据块, 然后解压解码, 从数据块中找到维度列前缀对应的数据项。

加速数据处理

  1. 预先聚合:  StarRocks支持聚合模型, 维度列取值相同数据行可合并一行, 合并后数据行的维度列取值不变, 指标列的取值为这些数据行的聚合结果, 用户需要给指标列指定聚合函数.  通过预先聚合, 可以加速聚合操作。
  2. 分区分桶:  事实上StarRocks的表被划分成tablet, 每个tablet多副本冗余存储在BE上, BE和tablet的数量可以根据计算资源和数据规模而弹性伸缩. 查询时, 多台BE可并行地查找tablet快速获取数据. 此外, tablet的副本可复制和迁移, 增强了数据的可靠性, 避免了数据倾斜. 总之, 分区分桶保证了数据访问的高效性和稳定性。
  3. RollUp表索引: shortkey index可加速数据查找, 然后shortkey index依赖维度列排列次序. 如果使用非前缀的维度列构造查找谓词, 则无法使用shortkey index. 用户可以为数据表创建若干RollUp表索引, RollUp表索引的数据组织和存储和数据表相同, 但RollUp表拥有自身的shortkey index. 用户创建RollUp表索引时, 可选择聚合的粒度, 列的数量, 维度列的次序; 使频繁使用的查询条件能够命中相应的RollUp表索引。
  4. 列级别的索引技术:  Bloomfilter可快速判断数据块中不含所查找值, ZoneMap通过数据范围快速过滤待查找值, Bitmap索引可快速计算出枚举类型的列满足一定条件的行。

五、数据模型 

数据模型分为四类:明细模型(Duplicate Key)、聚合模型(Aggregate Key)、更新模型(Unique Key)、主键模型(Primary Key)

明细模型

关键字 DUPLICATE KEY

CREATE TABLE IF NOT EXISTS table1 (
    event_time DATETIME NOT NULL COMMENT "datetime of event",
    event_type INT NOT NULL COMMENT "type of event",
    user_id INT COMMENT "id of user",
    device_code INT COMMENT "device of ",
    channel INT COMMENT ""
)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id) BUCKETS 8

聚合模型

 关键字 AGGREGATE KEY (默认全表排序,一般可省略)

CREATE TABLE IF NOT EXISTS table2 (
    site_id LARGEINT NOT NULL COMMENT "id of site",
    date DATE NOT NULL COMMENT "time of event",
    city_code VARCHAR(20) COMMENT "city_code of user",
    pv BIGINT SUM DEFAULT "0" COMMENT "total page views"
)
DISTRIBUTED BY HASH(site_id) BUCKETS 8;

更新模型 

关键字 UNIQUE KEY

CREATE TABLE IF NOT EXISTS table3 (
    create_time DATE NOT NULL COMMENT "create time of an order",
    order_id BIGINT NOT NULL COMMENT "id of an order",
    order_state INT COMMENT "state of an order",
    total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8

StarRocks存储内部会给每一个批次导入数据分配一个版本号, 同一主键的数据可能有多个版本, 查询时最大(最新)版本的数据胜出。 

主键模型 

目前primary主键存储在内存中,为防止滥用造成内存占满,限制主键字段长度全部加起来编码后不能超过127字节。

主要适用场景有:

1.实时对接 TP 数据至 StarRocks。

2.利用部分列更新轻松实现多流 JOIN

关键字 PRIMARY KEY

create table table4 (
    dt date NOT NULL,
    order_id bigint NOT NULL,
    user_id int NOT NULL,
    merchant_id int NOT NULL,
    good_id int NOT NULL,
    good_name string NOT NULL,
    price int NOT NULL,
    cnt int NOT NULL,
    revenue int NOT NULL,
    state tinyint NOT NULL
) PRIMARY KEY (dt, order_id)
PARTITION BY RANGE(`dt`) (
    PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
    PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')),
    ...
    PARTITION p20210929 VALUES [('2021-09-29'), ('2021-09-30')),
    PARTITION p20210930 VALUES [('2021-09-30'), ('2021-10-01'))
) DISTRIBUTED BY HASH(order_id) BUCKETS 4
PROPERTIES("replication_num" = "3");

注意:

  1. 主键列仅支持类型: boolean, tinyint, smallint, int, bigint, largeint, string/varchar, date, datetime, 不允许NULL。
  2. 分区列(partition)、分桶列(bucket)必须在主键列中。
  3. 和更新模型不同,主键模型允许为非主键列创建bitmap等索引,注意需要建表时指定。
  4. 由于其列值可能会更新,主键模型目前还不支持rollup index和物化视图。
  5. 暂不支持使用ALTER TABLE修改列类型。 ALTER TABLE的相关语法说明和示例,请参见 ALTER TABLE
  6. 在设计表时应尽量减少主键的列数和大小以节约内存,建议使用int/bigint等占用空间少的类型。暂时不建议使用varchar。建议提前根据表的行数和主键列类型来预估内存使用量,避免出现OOM。内存估算举例: a. 假设表的主键为: dt date (4byte), id bigint(8byte) = 12byte b. 假设热数据有1000W行, 存储3副本 c. 则内存占用: (12 + 9(每行固定开销) ) * 1000W * 3 * 1.5(hash表平均额外开销) = 945M

 官方文档:StarRocks @ StarRocks_intro @ StarRocks Docs

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2022-06-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、什么是StarRocks?
  • 二、适用场景
    • OLAP 多维分析:
      • 实时数据仓库:
        • 高并发查询:
          • 统一分析 :
          •  三、系统架构
            • 系统架构图
              • 数据管理
              • 四、StarRocks表设计
                • 列式存储
                  • 稀疏索引
                    • 加速数据处理
                    • 五、数据模型 
                      • 明细模型
                        • 聚合模型
                          • 更新模型 
                            • 主键模型 
                            相关产品与服务
                            对象存储
                            对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
                            领券
                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档