ToB企服应用市场:ToB评测及商务社交产业平台

标题: 新一代MPP数据库：StarRocks [打印本页]
作者: 北冰洋以北    时间: 9 小时前
标题: 新一代MPP数据库：StarRocks
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 报表、数据湖分析等场景。
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 通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以办理面向用户侧的分析 场景，业务场景包括：

上风：支持高并发查询，响应速度快，得当面向用户的及时分析需求。
3.3 日志与事件分析

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

上风：高效的文本处置惩罚和索引机制，支持快速日志检索和复杂分析。
3.4 物联网（IoT）数据分析

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

上风：支持高并发数据摄入和查询，得当及时处置惩罚物联网数据。
3.5 金融风控与及时监控

StarRocks 在金融领域广泛应用于及时风控和生意业务监控，能够快速辨认异常活动。业务场景包括：

上风：低延迟、高吞吐量，得当及时风险控制和预警。
3.6 数据湖查询加速

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

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

上风：支持外部表查询，得当与数据湖集成。
3.7 A/B 测试与实验分析

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

上风：高效的查询性能，得当及时分析 A/B 测试数据。
固然，StarRocks的使用场景还有很多，像多源数据融合分析、社交媒体与内容分析等，依附其高性能、低延迟和高并发的特点，实用于多种及时分析和复杂查询场景，能够满意企业对大规模数据及时处置惩罚和分析的需求。无论是及时数据仓库、高并发查询，还是多源数据融合分析，StarRocks 都能提供高效的办理方案。
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。三者区别如下：

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）节点协同工作，完成数据的导入、导出和查询任务。具体包括：

主要使用场景如下：

Broker 必要单独摆设，并设置与外部存储系统的毗连信息（如 HDFS 的 NameNode 地点、S3 的 Access Key 等）。
在 StarRocks 中，Broker 通过名称（Broker Name）进行标识，可以在 SQL 语句中指定使用的 Broker。

  1. LOAD LABEL example_db.label1
  2. (
  3.     DATA INFILE("hdfs://namenode:8020/path/to/data")
  4.     INTO TABLE my_table
  5. )
  6. WITH BROKER "broker_name"
  7. (
  8.     "username" = "hdfs_user",
  9.     "password" = "hdfs_password"
  10. );
复制代码

  1. EXPORT TABLE my_table
  2. TO "hdfs://namenode:8020/path/to/export"
  3. WITH BROKER "broker_name"
  4. (
  5.     "username" = "hdfs_user",
  6.     "password" = "hdfs_password"
  7. );
复制代码

  1. CREATE EXTERNAL TABLE external_table
  2. (
  3.     col1 INT,
  4.     col2 STRING
  5. )
  6. ENGINE=FILE
  7. LOCATION 'hdfs://namenode:8020/path/to/data'
  8. WITH BROKER "broker_name"
  9. (
  10.     "username" = "hdfs_user",
  11.     "password" = "hdfs_password"
  12. );
复制代码
在使用Broker时我们必要注意：

5.2.4 数据分布与复制

StarRocks的数据表会被划分为多个tablet（数据分片），这些tablet均匀分布在BE节点上，形成分布式数据存储。
为了实现高可用和容错，StarRocks支持数据的多副本备份，每个tablet可以在不同BE节点上有多份拷贝。
5.2.5 查询处置惩罚流程


5.2.6 集群扩展与稳固性

StarRocks通过增长FE和BE节点数目来线性扩展处置惩罚能力和存储容量。
通过心跳机制监控节点康健状态，并自动调整负载平衡和故障转移，保障系统的稳固性和可用性。
6.StarRocks的安装与摆设

官方保举docker按照，假如当地安装的话，我们既必要设置 Frontend (FE)还必要设置 Backend，而且启动也是必要分别启动，以是本文也仅提供docker安装方式，详细安装步骤可以移步:《docker安装StarRocks》
7.StarRocks 表设计

7.1 列式存储

StarRocks 是一款高性能的分布式 SQL 数据库，其核心特点之一就是采用了 列式存储（Columnar Storage）。列式存储是一种数据存储方式，与传统的行式存储（Row-based Storage）相比，它在处置惩罚大规模数据分析场景中具有明显的上风。
7.1.1 为什么StarRocks要使用列式存储

行式存储 vs 列式存储


行式存储：将一行数据的所有列存储在一起，得当事务处置惩罚（OLTP）场景，如插入、更新、删除等操作。
列式存储：将每一列的数据存储在一起，得当分析处置惩罚（OLAP）场景，如聚合、过滤、统计等操作。
列式存储的上风

高效的数据压缩：同一列的数据范例相同，更容易压缩，节省存储空间。
快速查询性能：只读取查询所需的列，淘汰 I/O 开销。
得当聚合操作：对某一列的聚合操作（如 SUM、AVG）更加高效。
向量化实行：列式存储天然得当向量化计算，提升 CPU 缓存命中率。
StarRocks的表和关系型数据相同, 由行和列构成。每行数据对应用户一条记载, 每列数据有相同数据范例。
所有数据行的列数相同, 可以动态增删列。
StarRocks中, 一张表的列可以分为

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

7.1.2 行号

一行数据的所有列在各自的列数组中保持对齐, 即拥有相同的数组下标, 该下标称之为序号或者行号。
该序号是隐式, 不必要存储的, 表中的所有行按照维度列, 做多重排序, 排序后的位置就是该行的行号。
查询时, 假如指定了维度列的等值条件或者范围条件, 而且这些条件中维度列可构成表维度列的前缀, 则可以使用数据的有序性, 使用range-scan快速锁定目标行。比方:

以是我们在查询的时候必要尽量遵守这个规则。
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）是指在数据写入时进行部门或全部聚合操作，而不是在查询时进行。这样可以明显淘汰查询时必要处置惩罚的数据量，从而加速查询速度。
实现方式


应用场景


示例

  1. CREATE TABLE sales (
  2.     date DATE,
  3.     product_id INT,
  4.     region STRING,
  5.     sales_amount DOUBLE
  6. ) AGGREGATE KEY(date, product_id, region)
  7. DISTRIBUTED BY HASH(product_id) BUCKETS 10
  8. PROPERTIES (
  9.     "function" = "SUM(sales_amount)"
  10. );
复制代码
7.3.2 分区分桶

概念

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


应用场景


示例

  1. CREATE TABLE sales_partitioned (
  2.     date DATE,
  3.     product_id INT,
  4.     region STRING,
  5.     sales_amount DOUBLE
  6. ) PARTITION BY RANGE (date) (
  7.     PARTITION p2023_q1 VALUES [('2023-01-01'), ('2023-04-01')),
  8.     PARTITION p2023_q2 VALUES [('2023-04-01'), ('2023-07-01'))
  9. ) DISTRIBUTED BY HASH(product_id) BUCKETS 10;
复制代码
7.3.3 列级别的索引技能

概念

列级别索引技能包括 Bloom Filter、ZoneMap 和Bitmap 索引 ，它们分别用于不同范例的查询优化。
实现方式


应用场景


7.3 示例

  1. -- 创建包含 Bloom Filter 的表
  2. CREATE TABLE users (
  3.     user_id BIGINT,
  4.     age INT,
  5.     active BOOLEAN
  6. ) WITH (
  7.     "bloom_filter_columns" = "age"
  8. );
  10. -- 创建包含 ZoneMap 的表
  11. CREATE TABLE orders (
  12.     order_id BIGINT,
  13.     order_date DATE,
  14.     amount DOUBLE
  15. ) WITH (
  16.     "zone_map_columns" = "order_date"
  17. );
  19. -- 创建包含 Bitmap 索引的表
  20. CREATE TABLE products (
  21.     product_id BIGINT,
  22.     category STRING
  23. ) WITH (
  24.     "bitmap_index_columns" = "category"
  25. );
复制代码
通过上述几种关键技能，StarRocks 能够明显加速数据处置惩罚和查询性能。

7.4 数据模型

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

明细模型是默认的建表模型。假如在建表时未指定任何模型，默认创建的是明细范例的表。它就像我们数仓中的 ODS 层或者 DWD 层，也就是说这个表中存储的是一些明细数据（比如用户的所有下单记载）。
StarRocks建表默认采用明细模型，排序列使用稀疏索引，可以快速过滤数据。明细模型用于保存所有汗青数据，而且用户可以考虑将过滤条件中频仍使用的维度列作为排序键，比如用户经常必要查看某一时间，可以将事件时间和事件范例作为排序键。
剩余内容一连输出中。。。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4