doris通关之概念、架构篇

1.OLTP和OLAP概念

OLTP是 Online Transaction Processing 的简称;OLAP 是 OnLine Analytical Processing 的简称
OLTP的查询一般只会访问少量的记录,且大多时候都会利用索引。比如最常见的基于主键的 CRUD 操作
OLAP 的查询一般需要 Scan 大量数据,大多时候只访问部分列,聚合的需求(Sum,Count,Max,Min 等)会多于明细的需求(查询原始的明细数据)
在这里插入图片描述

1.1.OLAP分类

  • MOLAP:通过预计算,提供稳定的切片数据,实现多次查询一次计算,减轻了查询时的计算压力,保证了查询的稳定性,是“空间换时间”的最佳路径。实现了基于Bitmap的去重算法,支持在不同维度下去重指标的实时统计,效率较高。
  • ROLAP:基于实时的大规模并行计算,对集群的要求较高。MPP引擎的核心是通过将数据分散,以实现CPU、IO、内存资源的分布,来提升并行计算能力。在当前数据存储以磁盘为主的情况下,数据Scan需要的较大的磁盘IO,以及并行导致的高CPU,仍然是资源的短板。因此,高频的大规模汇总统计,并发能力将面临较大挑战,这取决于集群硬件方面的并行计算能力。传统去重算法需要大量计算资源,实时的大规模去重指标对CPU、内存都是一个巨大挑战。目前Doris最新版本已经支持Bitmap算法,配合预计算可以很好地解决去重应用场景。
    在这里插入图片描述

1.2.MOLAP和ROLAP对比

a.MOLAP模式的劣势(以Kylin为例)

  • 应用层模型复杂,根据业务需要以及Kylin生产需要,还要做较多模型预处理。这样在不同的业务场景中,模型的利用率也比较低。
  • 由于MOLAP不支持明细数据的查询,在“汇总+明细”的应用场景中,明细数据需要同步到DBMS引擎来响应交互,增加了生产的运维成本。
  • 较多的预处理伴随着较高的生产成本。

b.ROLAP模式的优势

  • 应用层模型设计简化,将数据固定在一个稳定的数据粒度即可。比如商家粒度的星形模型,同时复用率也比较高。
  • App层的业务表达可以通过视图进行封装,减少了数据冗余,同时提高了应用的灵活性,降低了运维成本。
  • 同时支持“汇总+明细”。
  • 模型轻量标准化,极大的降低了生产成本。

综上所述,在变化维、非预设维、细粒度统计的应用场景下,使用MPP引擎驱动的ROLAP模式,可以简化模型设计,减少预计算的代价,并通过强大的实时计算能力,可以支撑良好的实时交互体验。

1.3.对比其他的OLAP系统

在这里插入图片描述

2.doris架构

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都可线性扩展

2.1.FE的两种角色

FE主要有两个角色,一个是follower,另一个是observer。多个follower组成选举组,会选出一个master,master是follower的一个特例,Master跟follower,主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。

Observer节点仅从 leader (master)节点进行元数据同步,不参与选举。可以横向扩展以提供元数据的读服务的扩展性。

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

2.1.1.follower个数为什么要是奇数?

一条元数据日志需要在多数 Follower 节点写入成功,才算成功。比如3个 FE ,2个写入成功才可以。这也是为什么 Follower 角色的个数需要是奇数的原因。
在这里插入图片描述

2.2.元数据管理及数据可靠性

在这里插入图片描述
Doris采用Paxos协议以及Memory+ Checkpoint + Journal的机制来确保元数据的高性能及高可靠。元数据的每次更新,都会遵照以下几步:

  1. 首先写入到磁盘的日志文件中
  2. 然后再写到内存中
  3. 最后定期checkpoint到本地磁盘上

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

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇

)">
下一篇>>