Doris主要整合了Google Mesa(数据模型),Apache Impala(MPP Query Engine)和Apache ORCFile (存储格式,编码和压缩)的技术。
为什么要将这三种技术整合?
Mesa可以满足我们许多存储需求的需求,但是Mesa本身不提供SQL查询引擎。
Impala是一个非常好的MPP SQL查询引擎,但是缺少完美的分布式存储引擎。
自研列式存储:存储层对存储数据的管理通过storage_root_path路径进行配置,路径可以是多个。存储目录下一层按照分桶进行组织,分桶目录下存放具体的tablet,按照tablet_id命名子目录。因此选择了这三种技术的组合。
Doris的系统架构如下,Doris主要分为FE和BE两个组件。
整体架构
Doris的架构很简洁,使用MySQL协议,用户可以使用任何MySQL ODBC/JDBC和MySQL客户端直接访问Doris,只设FE(Frontend)、BE(Backend)两种角色、两个进程,不依赖于外部组件,方便部署和运维。
FE:Frontend,即Doris的前端节点。主要负责接收和返回客户端请求、元数据以及集群管理、查询计划生成等工作。
BE:Backend,即Doris的后端节点。主要负责数据存储与管理、查询计划执行等工作。
FE,BE都可线性扩展FE主要有两个角色,一个是follower,另一个是observer。多个follower组成选举组,会选出一个master,master是follower的一个特例,Master跟follower,主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。
Observer节点仅从leader节点进行元数据同步,不参与选举。可以横向扩展以提供元数据的读服务的扩展性。
数据的可靠性由BE保证,BE会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。
元数据结构
Doris采用Paxos协议以及Memory+ Checkpoint + Journal的机制来确保元数据的高性能及高可靠。元数据的每次更新,都会遵照以下几步:
(1)写入到磁盘的日志文件中
(2)再写到内存中
(3)定期checkpoint到本地磁盘上
相当于是一个纯内存的一个结构,也就是说所有的元数据都会缓存在内存之中,从而保证FE在宕机后能够快速恢复元数据,而且不丢失元数据。
Leader、follower和observer它们三个构成一个可靠的服务,如果发生节点宕机的情况,一般是部署一个leader两个follower,目前来说基本上也是这么部署的。就是说三个节点去达到一个高可用服务。单机的节点故障的时候其实基本上三个就够了,因为FE节点毕竟它只存了一份元数据,它的压力不大,所以如果FE太多的时候它会去消耗机器资源,所以多数情况下三个就足够了,可以达到一个很高可用的元数据服务。