Doris理论详解

Doris整体架构

说明:架构很简洁，只设FE(Frontend)、BE(Backend)两种角色、两个进程，不依赖于外部组件，方便部署和运维。

①以数据存储的角度观之，FE存储、维护集群元数据；BE存储物理数据。

②以查询处理的角度观之, FE节点接收、解析查询请求，规划查询计划，调度查询执行，返回查询结果；BE节点依据FE生成的物理计划，分布式地执行查询。

③FE,BE都可线性扩展

FE主要有有三个角色，一个是leader，一个是follower，还有一个observer。leader跟follower，主要是用来达到元数据的高可用，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务。

④右边observer只是用来扩展查询节点，就是说如果在发现集群压力非常大的情况下， 需要去扩展整个查询的能力，那么可以加observer的节点。observer不参与任何的写入，只参与读取。

⑤数据的可靠性由BE保证，BE会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。

数据流向

元数据层面

Doris采用==Paxos协议以及Memory+ Checkpoint + Journal的机制==来确保元数据的高性能及高可靠。元数据的每次更新，都会遵照以下几步：

①首先写入到磁盘的日志文件中，

②然后再写到内存中，

③最后定期checkpoint到本地磁盘上。

相当于是一个纯内存的一个结构，也就是说所有的元数据都会缓存在内存之中，从而保证FE在宕机后能够快速恢复元数据，而且不丢失元数据。Leader、follower和 observer它们三个构成一个可靠的服务，如果发生节点宕机的情况，一般是部署一个leader两个follower，目前来说基本上也是这么部署的。就是说三个节点去达到一个高可用服务。单机的节点故障的时候其实基本上三个就够了，因为FE节点毕竟它只存了一份元数据，它的压力不大，所以如果FE太多的时候它会去消耗机器资源，所以多数情况下三个就足够了，可以达到一个很高可用的元数据服务。

查询方面

FE来根据用户的查询生成一个完整的逻辑规划，然后这个逻辑规划最后生成一个分布式的逻辑规划，会发给整个集群去执行。

分布式物理执行计划

图展示了它的逻辑，查询会生成几个算子，主要有==扫描的算子，聚合的算子，还有Join的算子，最后再排序==。右边就相当于对整个的算子的一个实际物理划分。这个规划途中单个方框我们称之为一个Fragment，Fragment由单个BE节点执行，Fragment之间的数据交换通过RPC来完成。整个物理规划执行完之后，由FE把数据收集起来反馈给用户。返回用户的方式就是前面提到过的通过一个MySQL的协议。

数据存储

列存有很多具体的压缩方法，对于不同的类型有一些不同的压缩办法。除了简单的压缩之外，我们还有很重要的一个特点就是对数据会排序。多数分析型数据库它都只会去建一个稀疏索引，这个时候把数据排一下序，然后按一个一千行或者一万行，甚至是十万行的维度去见一个稀疏的索引，效果是非常明显的。

Doris存储引擎对于排序列，会存储min/max/sum等智能索引技术，将数据集扫描范围尽可能地缩小，减少磁盘I/O，提升查询性能。比如说这一列排过序了，然后我在这一列的十万行所组成的一个粒度上面，给它加一个min/max，然后这样查询的时候，它就可以快速去过滤这个十万行，这会大大地减少整个数据的扫描量，从而减少I/O。

向量化执行

向量化执行的方式可以提高3到4倍的性能。

Doris核心特性

上一篇: Dstream入门WordCount_大数据培训
下一篇: Dstream创建RDD队列_大数据培训