系统架构

系统架构图

system_architecture

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副本的分布信息。

data_management

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

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

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

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