Apache Doris——简介

2024-04-09 18:20:30 阅读数 5068

1.概述

Apache Doris 是一个基于MPP架构的高性能实时分析 OLAP 引擎，以其极快的速度和易用性而闻名。

它只需要亚秒的响应时间即可在海量数据下返回查询结果，并且不仅可以支持高并发点查询场景，还可以支持高吞吐量复杂分析场景。

Apache Doris是一个现代化的MPP分析型数据库产品。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris的分布式架构非常简洁，易于运维，并且可以支持10PB以上的超大数据集。

Apache Doris可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。令您的数据分析工作更加简单高效！

MPP ( Massively Parallel Processing )，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说，MPP 是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果 ( 与 Hadoop 相似 )。

Doris 主要解决 PB 级别的数据量（如果高于 PB 级别，不推荐使用 Doris 解决，可以考虑用 Hive 等工具），解决结构化数据，查询时间一般在秒级或毫秒级。

Doris 由百度大数据部研发 ( 之前叫百度 Palo，2018年贡献到 Apache 社区后，更名为 Doris )，在百度内部，有超过200个产品线在使用，部署机器超过1000台，单一业务最大可达到上百 TB。

百度将 Doris 贡献给 Apache 社区之后，许多外部用户也成为了 Doris 的使用者，例如新浪微博，美团，小米等著名企业。

Apache Doris 核心特性：

发展历程

2012 年之前，Doris 的定位就是一个 NoSQL 数据库。

2012~2020 年期间，Doris 的定位是 NewSQL，也就是说除了要兼顾存储海量数据，也要具备 RDBMS 的 ACID 特性以及对于 SQL 的支持能力。

2020 年以后，Doris 的定位是 Lakehouse。

关于 Lakehouse 请参考博客——湖仓一体（Lakehouse）是什么？

2.doris 架构

Doris主要整合了Google Mesa（数据模型），Apache Impala（MPP Query Engine) 和 Apache ORCFile (存储格式，编码和压缩) 的技术。

Google Mesa（数据模型）

Mesa是一种高度可扩展的分析数据存储系统，用于存储与Google的互联网广告业务有关的关键测量数据。
Mesa满足一系列复杂且具有挑战性的用户和系统需求，包括接近实时的数据提取和查询能力，以及针对大数据和查询量的高可用性，可靠性，容错性和可伸缩性。但是Mesa本身不提供SQL查询引擎所以借鉴了下面。

Apache Impala（MPP Query Engine)

Impala是一个非常好的MPP SQL查询引擎，做更多的查询优化，在速度上做到了很好。但是缺少比较完美的分布式存储引擎，所以需要集成下面。

Apache ORCFile (存储格式，编码和压缩)

只访问查询涉及的列，能大量降低系统I/O；列数据相对来说比较类似，压缩比更高；每一列由一个线索来处理，更有利于查询的并发处理。

因此选择了这三种技术的组合。

Doris的系统架构如下图：架构很简洁，只设FE(Frontend)、BE(Backend)两种角色、两个进程，不依赖于外部组件，方便部署和运维。

Doris 的整体架构和 TiDB 类似，借助 MySQL 协议，用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端，都可以直接访问 Doris。

Doris 中的模块包括 FE 和 BE 两类：FE 主要负责元数据的管理、存储，以及查询的解析等；一个用户请求经过 FE 解析、规划后，具体的执行计划会发送给 BE，BE 则会完成查询的具体执行。BE 节点主要负责数据的存储、以及查询计划的执行。

2.1 核心组件介绍

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

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

名词解释

名词	说明
FE	Frontend，即 Doris 的前端节点。以 Java 语言为主,主要负责接收和返回客户端请求、元数据以及集群管理、查询计划生成等工作。
BE	Backend，即 Doris 的后端节点。以 C++ 语言为主,主要负责数据存储与管理、查询计划执行等工作。
Tablet	Tablet是一张表实际的物理存储单元，一张表按照分区和分桶后在BE构成分布式存储层中以Tablet为单位进行存储，每个Tablet包括元信息及若干个连续的RowSet。
Rowset	Rowset是Tablet中一次数据变更的数据集合，数据变更包括了数据导入、删除、更新等。Rowset按版本信息进行记录。每次变更会生成一个版本。
Version	由Start、End两个属性构成，维护数据变更的记录信息。通常用来表示Rowset的版本范围，在一次新导入后生成一个Start，End相等的Rowset，在Compaction后生成一个带范围的Rowset版本。
Segment	表示Rowset中的数据分段。多个Segment构成一个Rowset。
Compaction	连续版本的Rowset合并的过程成称为Compaction，合并过程中会对数据进行压缩操作。

FE(Frontend)

主要负责查询的编译，分发和元数据管理。

1、管理元数据（库、表、分区、tablet副本等信息），执行SQL语句命令。
2、FE高可用部署，使用复制协议选主和主从同步元数据，所有的元数据修改操作，由FE Leader节点完成，FE Follower节点可执行读操作。元数据的读写满足顺序一致性。 FE的节点数目采用2n+1，可容忍n个节点故障。当FE Leader故障时，从现有的Follower节点重新选主，完成故障切换。
- Observer节点仅从 Leader节点进行元数据同步，不参与选举。能够横向扩展以提供元数据的读服务的扩展性。
3、FE的SQL layer对用户提交的SQL进行解析、分析、语义分析和关系代数优化，生产逻辑执行计划。
4、FE的Planner负责把逻辑计划转化为可分布式执行的物理计划，分发给一组BE。
5、FE监督，管理BE的上下线，根据BE的健康状态和存活数，维持tablet副本的数量。
6、FE协调数据导入, 保证数据导入的一致性。

BE([Backend]

主要负责数据的存储、以及查询计划的执行

1、BE管理tablet副本，tablet是table经过分区分桶形成的子表，采用列式存储。
2、BE受驱动FE，创建或删除子表。
3、BE接收FE分发的物理执行计划并指定BE coordinator节点，在BE coordinator的调度下，与其他BE worker共同协作完成执行。
4、BE读取本地的列存储引擎获取数据，并通过索引和谓词下沉快速过滤数据。
5、BE后台执行compact任务，减少查询时的读放大。
6、数据导入时, 由FE指定BE coordinator，将数据以fanout的形式写入到tablet多副本所在的BE上。

MySQL Client

Doris借助MySQL协议，用户使用任意MySQL的ODBC/JDBC以及MySQL的客户
端，都可以直接访问Doris

Broker

Broker为一个独立的无状态进程。封装了文件系统接口，提供Doris读取远端存储系统中文件的能力，包括HDFS、S3、BOS等

元数据

Doris 采用 Paxos 协议以及 Memory + Checkpoint + Journal 的机制来确保元数据的高性能及高可靠。
元数据的每次更新，都首先写入到磁盘的日志文件中，然后再写到内存中，最后定期 checkpoint 到本地磁盘上。相当于是一个纯内存的一个结构，也就是说所有的元数据都会缓存在内存之中，从而保证 FE 在宕机后能够快速恢复元数据，而且不丢失元数据。* Leader、follower 和 observer 它们三个构成一个可靠的服务，这样如果发生节点宕机的情况，在百度内部的话，一般是部署一个 leader 两个 follower，外部公司目前来说基本上也是这么部署的。就是说三个节点去达到一个高可用服务。
单机的节点故障的时候其实基本上三个就够了，因为 FE 节点毕竟它只存了一份元数据，它的压力不大，所以如果 FE 太多的时候它会去消耗机器资源，所以多数情况下三个就足够了，可以达到一个很高可用的元数据服务

Doris FE高可用方案：

如果你是离线业务，对高可用要求不是那么高可以使用 1 FE（Follower leader） + 1 FE（Observer）
如果你是实时在线业务，对高可用要求很高，建议使用 3 FE（Follower），会自动选举出一个 leader

数据分布及可靠性

Doris 数据主要都是存储在 BE 里面，BE 节点上物理数据的可靠性通过多副本来实现，默认是 3 副本，副本数可配置且可随时动态调整,满足不同可用性级别的业务需求。FE 调度 BE 上副本的分布与补齐。

如果说用户对可用性要求不高，而对资源的消耗比较敏感的话，我们可以在建表的时候选择建两副本或者一副本。比如在百度云上我们给用户建表的时候，有些用户对它的整个资源消耗比较敏感，因为他要付费，所以他可能会建两副本。但是我们一般不太建议用户建一副本，因为一副本的情况下可能一旦机器出问题了，数据直接就丢了，很难再恢复。我们在公司内部的话，一般是默认建三副本，这样基本可以保证一台机器单机节点宕机的情况下不会影响整个服务的正常运作。