StarRocks概述

一、StarRocks简介
1.1 StarRoks介绍
StarRocks是新一代极速全场景MPP数据库
StraRocks充分吸收关系型OLAP数据库和分布式存储系统在大数据时代的优秀研究成果，在业界实践的基础上，进一步改进优化、升级架构，并增添了众多全新功能，形成了全新的企业级产品。
StarRocks致力于构建极速统一分析体验，满足企业用户的多种数据分析场景，支持多种数据模型(明细模型、聚合模型、更新模型)，多种导入方式(批量和实时)，可整合和接入多种现有系统(Spark、Flink、Hive、 ElasticSearch)。
使用StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。
StarRocks兼容MySQL协议，可使用MySQL客户端和常用BI工具对接StarRocks来进行数据分析。
StarRocks采用分布式架构，对数据表进行水平划分并以多副本存储。集群规模可以灵活伸缩，能够支持10PB级别的数据分析; 支持MPP框架，并行加速计算; 支持多副本，具有弹性容错能力。
StarRocks采用关系模型，使用严格的数据类型和列式存储引擎，通过编码和压缩技术，降低读写放大；使用向量化执行方式，充分挖掘多核CPU的并行计算能力，从而显著提升查询性能。
1.2 StarRocks适合什么场景
StarRocks可以满足企业级用户的多种分析需求，包括OLAP多维分析、定制报表、实时数据分析和Ad-hoc数据分析等。
1.2.1 OLAP多维分析
利用StarRocks的MPP框架和向量化执行引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型或者预聚合模型。适用于灵活配置的多维分析报表，业务场景包括：
1.用户行为分析
2.用户画像、标签分析、圈人
3.高维业务指标报表
4.自助式报表平台
5.业务问题探查分析
6.跨主题业务分析
7.财务报表
8.系统监控分析
1.2.2 实时数据仓库
StarRocks设计和实现了Primary-Key 模型，能够实时更新数据并极速查询，可以秒级同步TP(Transaction Processing) 数据库的变化，构建实时数仓，业务场景包括：
1.电商大促数据分析
2.物流行业的运单分析
3.金融行业绩效分析、指标计算
4.直播质量分析
5.广告投放分析
6.管理驾驶舱
7.探针分析APM(Application Performance Management)
1.2.3 高并发查询
StarRocks通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以解决面向用户侧的分析场景，业务场景包括：
1.广告主报表分析
2.零售行业渠道人员分析
3.SaaS行业面向用户分析报表
4.Dashboard多页面分析
1.2.4 统一分析
1.通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
2.使用StarRocks统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在StarRocks中分析，也可以使用External Catalog和外部表进行数据湖上的分析。
1.3 StarRocks基本概念
1.3.1 FE
FrontEnd简称FE，是StarRocks的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。每个FE节点都会在内存保留一份完整的元数据，这样每个FE节点都能够提供无差别的服务。
FE有三种角色：Leader FE，Follower FE和Observer FE。
Follower会通过类Paxos的 Berkeley DB Java Edition(BDBJE)协议自动选举出一个Leader。三者区别如下：
1.3.1.1 Leader
1.Leader从Follower中自动选出，进行选主需要集群中有半数以上的Follower节点存活。如果Leader节点失败，Follower会发起新一轮选举。
2.Leader FE提供元数据读写服务。只有Leader节点会对元数据进行写操作，Follower 和 Observer只有读取权限。
Follower和Observer将元数据写入请求路由到Leader节点，Leader 更新完数据后，会通过BDB JE同步给Follower和Observer。必须有半数以上的Follower节点同步成功才算作元数据写入成功。
1.3.1.2 Follower
只有元数据读取权限，无写入权限。通过回放 Leader 的元数据日志来异步同步数据。
参与 Leader 选举，必须有半数以上的 Follower 节点存活才能进行选主。
1.3.1.3 Observer
1.主要用于扩展集群的查询并发能力，可选部署。
2.不参与选主，不会增加集群的选主压力。
3.通过回放Leader的元数据日志来异步同步数据。
1.3.2 BE
BackEnd简称BE，是StarRocks的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。
数据存储方面，StarRocks的BE节点都是完全对等的，FE按照一定策略将数据分配到对应的BE节点。BE负责将导入数据写成对应的格式存储下来，并生成相关索引。
在执行SQL计算时，一条SQL语句首先会按照具体的语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在对应的数据存储节点上执行，这样可以实现本地计算，避免数据的传输与拷贝，从而能够得到极致的查询性能。
注意：在进行Stream load 导入时，FE会选定一个BE节点作为Coordinator BE，负责将数据分发到其他BE节点。导入的最终结果由Coordinator BE返回给用户。
1.3.3 Broker
StarRocks中和外部HDFS/对象存储等外部数据对接的中转服务，辅助提供导入导出功能。
1.3.4 StarRocksManager
StarRocks的管理工具，提供StarRocks集群管理、在线查询、故障查询、监控报警的可视化工具。
1.3.5 数据管理
StarRocks使用列式存储，采用分区分桶机制进行数据管理。一张表可以被划分成多个分区，如将一张表按照时间来进行分区，粒度可以是一天，或者一周等，一个分区内的数据可以根据一列或者多列进行分桶，将数据切分成多个Tablet。
Tablet是StarRocks中最小的数据管理单元。每个Tablet都会以多副本(replica)的形式存储在不同的BE节点中，您可以自行指定Tablet的个数和大小，StarRocks会管理好每个Tablet 副本的分布信息。

图中，表按照日期划分为4个分区，第一个分区进一步切分成4个Tablet，每个Tablet使用3副本进行备份，分布在3个不同的BE节点上。

由于一张表被切分成了多个Tablet，StarRocks在执行SQL语句时，可以对所有Tablet实现并发处理，从而充分的利用多机、多核提供的计算能力。用户也可以利用StarRocks数据的切分方式，将高并发请求压力分摊到多个物理节点，从而可以通过增加物理节点的方式来扩展系统支持高并发的能力。
Tablet的分布方式与具体的物理节点没有相关性。在BE节点规模发生变化时，比如在扩容、缩容时，StarRocks可以做到无需停止服务，直接完成节点的增减。
节点的变化会触发Tablet的自动迁移。当节点增加时，一部分Tablet会在后台自动被均衡到新增的节点，从而使得数据能够在集群内分布的更加均衡。
在节点减少时，下线机器上的Tablet会被自动均衡到其他节点，从而自动保证数据的副本数不变，管理员能够非常容易地实现StarRocks的弹性伸缩，无需手工进行任何数据的重分布。
StarRocks支持Tablet多副本存储，默认副本数为三个。多副本能够保证数据存储的高可靠以及服务的高可用，在使用三副本的情况下，一个节点的异常不会影响服务的可用性，集群的读、写服务仍然能够正常进行。另外，增加副本数还有助于提高系统的高并发查询能力。
1.4 StarRocks系统架构
StarRocks架构简洁，整个系统的核心只有 FE(Frontend)、BE(Backend)两类进程，不依赖任何外部组件，方便部署与维护。
FE和BE模块都可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRocks提供MySQL协议接口，支持标准SQL语法，用户可通过MySQL客户端方便地查询和分析StarRocks中的数据。
1.4.1 系统架构
随着 StarRocks 产品的不断演进，系统架构也从原先的存算一体 (shared-nothing) 进化到存算分离 (shared-data)。
3.0 版本之前使用存算一体架构，BE 同时负责数据存储和计算，数据访问和分析都在本地进行，提供极速的查询分析体验。
3.0 版本开始引入存算分离架构，数据存储功能从原来的 BE 中抽离，BE 节点升级为无状态的 CN 节点。数据可持久存储在远端对象存储或 HDFS 上，CN 本地磁盘只用于缓存热数据来加速查询。存算分离架构下支持动态增删计算节点，实现秒级的扩缩容能力。
1.4.1.1 存算一体架构
作为MPP数据库的典型代表，StarRocks3.0版本之前使用存算一体(shared-nothing)架构，BE同时负责数据存储和计算，在查询时可以直接访问BE本地数据，进行本地计算，避免数据传输与拷贝，从而能够得到极速的查询分析性能。
存算一体架构支持数据的多副本存储，提升了集群的高并发查询能力和数据可靠性。存算一体适用于追求极致查询性能的场景。

存算一体架构下，StarRocks由FE和BE组成：FE负责元数据管理和构建执行计划；BE负责实际执行以及数据存储管理，BE采用本地存储，通过多副本的机制保证高可用。
#FE
FE是StarRocks的前端节点，负责管理元数据、管理客户端连接、进行查询规划、查询调度等工作。每个FE节点都会在内存保留一份完整的元数据，这样每个FE节点都能够提供无差别的服务。
#BE
BE是StarRocks的后端节点，负责数据存储和SQL计算等工作。
1.数据存储方面，BE 节点都是完全对等的。FE按照一定策略将数据分配到对应的BE节点，BE负责将导入数据写成对应的格式存储下来，并生成相关索引。
2.在执行SQL计算时，一条SQL语句首先会按照语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在对应的BE节点上执行，这样可以实现本地计算，避免数据的传输与拷贝，从而得到极速的查询性能。
1.4.1.2 存算分离架构
StarRocks存算分离技术在现有存算一体架构的基础上，将计算和存储进行解耦。在存算分离新架构中，数据持久化存储在更为可靠和廉价的远程对象存储(比如 S3)或HDFS上。CN本地磁盘只用于缓存热数据来加速查询。
在本地缓存命中的情况下，存算分离可以获得与存算一体架构相同的查询性能。存算分离架构下，用户可以动态增删计算节点，实现秒级的扩缩容。存算分离大大降低了数据存储成本和扩容成本，有助于实现资源隔离和计算资源的弹性伸缩。
与存算一体架构类似，存算分离版本拥有同样简洁的架构，整个系统依然只有 FE和CN 两种服务进程，用户唯一需要额外提供的是后端对象存储。

存算分离架构下，FE的功能保持不变。BE原有的存储功能被抽离，数据存储从本地存储 (local storage) 升级为共享存储 (shared storage)。BE节点升级为无状态的CN节点，只缓存热数据。CN会执行数据导入、查询计算、缓存数据管理等任务。
#存储
目前，StarRocks存算分离技术支持如下后端存储方式，用户可根据需求自由选择：
1. 兼容AWS S3协议的对象存储系统(支持主流的对象存储系统如AWS S3、Google GCP、阿里云OSS、腾讯云COS、百度云BOS、华为云OBS以及MinIO等)
2.Azure Blob Storage
3.传统数据中心部署的HDFS
在数据格式上，StarRocks存算分离数据文件与存算一体保持一致，各种索引技术在存算分离表中也同样适用，不同的是，描述数据文件的元数据(如TabletMeta等)被重新设计以更好地适应对象存储。
#缓存
为了提升存算分离架构的查询性能，StarRocks构建了分级的数据缓存体系，将最热的数据缓存在内存中，距离计算最近，次热数据则缓存在本地磁盘，冷数据位于对象存储，数据根据访问频率在三级存储中自由流动。
查询时，热数据通常会直接从缓存中命中，而冷数据则需要从对象存储中读取并填充至本地缓存，以加速后续访问。通过内存、本地磁盘、远端存储，StarRocks存算分离构建了一个多层次的数据访问体系，用户可以指定数据冷热规则以更好地满足业务需求，让热数据靠近计算，真正实现高性能计算和低成本存储。
StarRocks存算分离的统一缓存允许用户在建表时决定是否开启缓存。如果开启，数据写入时会同步写入本地磁盘以及后端对象存储，查询时，CN节点会优先从本地磁盘读取数据，如果未命中，再从后端对象存储读取原始数据并同时缓存在本地磁盘。
同时，针对未被缓存的冷数据，StarRocks也进行了针对性优化，可根据应用访问模式，利用数据预读技术、并行扫描技术等手段，减少对于后端对象存储的访问频次，提升查询性能。
1.4.1.1 组件介绍
存算一体StarRocks集群由FE和BE构成，可以使用MySQL客户端访问StarRocks集群。
存算分离StarRocks集群由FE和CN构成，存储选择对象或HDFS。
1.4.1.1.1 FE
FE是StarRocks的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。每个FE节点都会在内存保留一份完整的元数据，这样每个FE节点都能够提供无差别的服务。
1.FE接收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协调数据导入，保证数据导入的一致性。
1.4.1.1.2 BE
BE是StarRocks的后端节点，负责数据存储、SQL执行等工作。
1.BE管理tablet副(默认3副本)，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上。
1.5 数据模型概览
建表时，您需要指定数据模型(Data Model)，这样数据导入至数据模型时，StarRocks会按照排序键对数据进行排序、处理和存储。本文介绍StarRocks支持的各种数据模型，满足您在不同业务场景下的需求。
1.5.1 数据模型
StarRocks支持四种数据模型，分别是明细模型(Duplicate Key Model)、聚合模型 (Aggregate Key Model)、更新模型(Unique Key Model)和主键模型(Primary Key Model)。这四种数据模型能够支持多种数据分析场景，例如日志分析、数据汇总分析、实时分析等。
#排序键
数据导入至使用某个数据模型的表，会按照建表时指定的一列或多列排序后存储，这部分用于排序的列就称为排序键。排序键通常为查询时过滤条件频繁使用的一个或者多个列，用以加速查询。
1.    明细模型中，数据按照排序键DUPLICATE KEY排序，并且排序键不需要满足唯一性约束。 
2.    聚合模型中，数据按照排序键AGGREGATE KEY聚合后排序，并且排序键需要满足唯一性约束。 
3.    更新模型中，数据按照排序键UNIQUE KEY REPLACE后排序，并且排序键需要满足唯一性约束。 
4.    主键模型支持分别定义主键和排序键，主键 PRIMARY KEY需要满足唯一性和非空约束，主键相同的数据进行REPLACE。排序键是用于排序，由ORDER BY指定 。
说明：3.0 版本之前，主键模型不支持分别定义主键和排序键。
排序键的更多说明，请参见排序键和前缀索引。

#如果导入的数据存在重复的主键，则数据导入至数据模型，存储在 StarRocks 时，则会按照如下方式进行处理：
1.明细模型：表中会存在主键重复的数据行，并且与导入的数据是完全对应的。您可以召回所导入的全部历史数据。
2.聚合模型：表中不存在主键重复的数据行，主键满足唯一性约束。导入的数据中主键重复的数据行聚合为一行，即具有相同主键的指标列，会通过聚合函数进行聚合。您只能召回导入的全部历史数据的聚合结果，但是无法召回历史明细数据。
3.主键模型和更新模型：表中不存在主键重复的数据行，主键满足唯一性约束。最新导入的数据行，替换掉其他主键重复的数据行。这两种模型可以视为聚合模型的特殊情况，相当于在聚合模型中，为表的指标列指定聚合函数为 REPLACE，REPLACE 函数返回主键相同的一组数据中的最新数据。
1.5.1.1 明细模型(Duplicate Key Model)
明细模型是默认的建表模型。如果在建表时未指定任何模型，默认创建的是明细类型的表。
创建表时，支持定义排序键。如果查询的过滤条件包含排序键，则StarRocks能够快速地过滤数据，提高查询效率。明细模型适用于日志数据分析等场景，支持追加新数据，不支持修改历史数据。
#适用场景
1.分析原始数据，例如原始日志、原始操作记录等。
2.查询方式灵活，不需要局限于预聚合的分析方式。
3.导入日志数据或者时序数据，主要特点是旧数据不会更新，只会追加新的数据。
在明细模型中，为了提升分析性能，一般会建立排序键，在日志分析的场景中，一般设置的排序键为事件类型和事件时间，这样分析某时间范围的某一类事件时，性能将会得到比较大的提升。但要注意的是，明细模型中没有唯一键，即使是排序键，也是可以重复的。同时，针对索引的处理，也是落盘存储的。
目前明细模型是应用最广泛的数据模型，当然需要进行“额外”的处理才行。比如通过业务主键进行数据的维护，保证数据的准确性，具体为开发人员需要自己维护业务主键的唯一性以保证业务逻辑处理过程中的正确性，实现时采取基于业务主键Delete-Insert的模式，保证业务数据明细记录的准确(不重复)和最终分析结果的准确。采取业务加持后，明细模型成为了最广泛应用的数据模型，常常应用于离线数据处理的场景中。
1.5.1.2 聚合模型(Aggregate Key Model)
建表时，支持定义排序键和指标列，并为指标列指定聚合函数。当多条数据具有相同的排序键时，指标列会进行聚合。在分析统计和汇总数据时，聚合模型能够减少查询时所需要处理的数据，提升查询效率。

聚合模型将自动根据排序键，进行指标列的汇总，从而达到查询时少扫描明细行(IO)以提升性能的目的。对于聚合模型，排序列必须唯一，且不能修改，这个对于在业务应用中比较困难，特别是对于一些历史遗留系统。核心原因是此种模型不支持Update模式，只能采取Delete-Insert模式，严格来说只能是Insert追加模式。
为什么只能是Insert模式，举个例子：比如基于City列进行人数聚合，深圳有100人(即插入了100条明细记录)，聚合的深圳的总人数是100，后来发现有一条明细记录的数据的City列出错不是深圳而是广州，需要删除一条城市是广州的一条明细，聚合最终结果为深圳总人数是99人，如果要得到正确的99人的结果，只能是将深圳的聚合100的记录删除，然后重新导入99条深圳的明细记录才能完成此数据的修改，无法通过删除一条出错记录，将深圳总人数调整为99人。
基于上述例子可以看出聚合模型基于排序键删除的是聚合后的记录，不能删除明细的记录，如果聚合明细记录的维度字段有调整，就会出现上述例子的情况，聚合模型严格来说是Insert追加模式的。基于此种模式，聚合模型的应用非常有限。
1.5.1.3 更新模型(Unique Key Model)
建表时，支持定义主键和指标列，查询时返回主键相同的一组数据中的最新数据。相对于明细模型，更新模型简化了数据导入流程，能够更好地支撑实时和频繁更新的场景。
#适用场景
实时和频繁更新的业务场景，例如分析电商订单。在电商场景中，订单的状态经常会发生变化，每天的订单更新量可突破上亿。

更新模型其实是聚合模型的一种特殊形式，聚合函数为Replace，即返回具有相同主键的一组数据的最新记录。由于采取的Replace函数，数据其实是没有做聚合的，是明细数据。
每一条明细数据，都会有多个版本的记录，查询时返回最新版本的数据，Delete删除时，所有版本都会删除掉。更新模型依然是追加模式，由于有多个版本，查询时会有比较多的开销，性能上不是太优。
1.5.1.4 主键模型(Primary Key Model)
主键模型支持分别定义主键和排序键。数据导入至主键模型的表时先按照排序键排序后存储。查询时返回主键相同的一组数据中的最新数据。相对于更新模型，主键模型在查询时不需要执行聚合操作，并且支持谓词和索引下推，能够在支持实时和频繁更新等场景的同时，提供高效查询。
#适用场景
主键模型适用于实时和频繁更新的场景，例如：
1. 实时对接事务型数据至StarRocks。事务型数据库中，除了插入数据外，一般还会涉及较多更新和删除数据的操作，因此事务型数据库的数据同步至StarRocks 时，建议使用主键模型。通过Flink-CDC等工具直接对接TP的Binlog，实时同步增删改的数据至主键模型，可以简化数据同步流程，并且相对于Merge-On-Read策略的更新模型，查询性能能够提升3~10倍。
2. 利用部分列更新轻松实现多流JOIN。在用户画像等分析场景中，一般会采用大宽表方式来提升多维分析的性能，同时简化数据分析师的使用模型。而这种场景中的上游数据，往往可能来自于多个不同业务(比如来自购物消费业务、快递业务、银行业务等)或系统(比如计算用户不同标签属性的机器学习系统)，主键模型的部分列更新功能就很好地满足这种需求，不同业务直接各自按需更新与业务相关的列即可，并且继续享受主键模型的实时同步增删改数据及高效的查询性能。