系统架构

系统架构图

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

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

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

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

数据存储方面，StarRocks的BE节点都是完全对等的，FE按照一定策略将数据分配到对应的BE节点。BE负责将导入数据写成对应的格式以及生成相关索引。

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

StarRocks提供MySQL协议接口，支持标准SQL语法。用户可通过MySQL客户端方便地查询和分析StarRocks里的数据。

数据管理

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

Table数据划分 + Tablet三副本的数据分布

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

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

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