Apache Doris——简介

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)

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

• 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 上副本的分布与补齐。

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

3.doris内部组件及周边生态组件介绍

3.1 Frontend（FE）

Java语言开发，Doris 系统的元数据管理和节点调度。在导入流程中主要负责导入 plan 生成和导入任务的调度工作，请求接入等

3.2 Backend（BE）

C++语言开发，Doris 系统的计算和存储节点，执行SQL计划等。在导入流程中主要负责数据的 ETL 和存储。

3.3 Broker

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

3.4 Mysql Client

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

3.5 Doris on ES

Doris-On-ES将Doris的分布式查询规划能力和ES(Elasticsearch)的全文检索能力相结合，提供更完善的OLAP分析场景解决方案：

• ES中的多index分布式Join查询
• Doris和ES中的表联合查询，更复杂的全文检索过滤

3.6 ODBC External Table Of Doris

ODBC External Table Of Doris 提供了Doris通过数据库访问的标准接口(ODBC)来访问外部表，外部表省去了繁琐的数据导入工作，让Doris可以具有了访问各式数据库的能力，并借助Doris本身的OLAP的能力来解决外部表的数据分析问题：

• 支持各种数据源接入Doris
• 支持Doris与各种数据源中的表联合查询，进行更加复杂的分析操作
• 通过insert into将Doris执行的查询结果写入外部的数据源

3.7 Spark Doris Connector

Spark Doris Connector 可以支持通过 Spark 读取 Doris 中存储的数据。

• 当前版本只支持从Doris中读取数据。
• 可以将Doris表映射为DataFrame或者RDD，推荐使用DataFrame。
• 支持在Doris端完成数据过滤，减少数据传输量。

3.8 Flink Doris Connector

Flink Doris Connector 可以支持通过 Flink 读取 Doris 中存储的数据。

• 可以将Doris表映射为DataStream或者Table
• 支持通过Flink table的方式使用doris数据
• 可以通过Flink table 方式方便的将数据通过insert into select方式将数据插入到doris表中

3.9 DataX doriswriter

DataX doriswriter 插件，用于通过 DataX 同步其他数据源的数据到 Doris 中。

这个插件是利用Doris的Stream Load 功能进行数据导入的。需要配合 DataX 服务一起使用。

这个扩展可以很方便的将业务数据库中的数据快速的抽取导入到doris数仓中

3.10 Doris output plugin

该插件用于logstash输出数据到Doris，使用 HTTP 协议与 Doris FE Http接口交互，并通过 Doris 的 stream load 的方式进行数据导入.

3.11 审计日志扩展

Doris 的审计日志插件是在 FE 的插件框架基础上开发的。是一个可选插件。用户可以在运行时安装或卸载这个插件。

该插件可以将 FE 的审计日志定期的导入到指定 Doris 集群中，以方便用户通过 SQL 对审计日志进行查看和分析。

4、使用场景

报表分析可视化

• 实时仪表板
• 内部分析师和经理的报告
• 高度并发的面向用户或面向客户的报表分析

ad-hoc

• 以分析师为导向的自助服务分析，具有不规则的查询模式和高吞吐量要求。

统一数据仓库建设

• 一个满足统一数据仓库建设需求和简化复杂数据软件堆栈的平台。
• 流批一体
• 实时数仓

数据湖查询

• 通过使用外部表联合位于 Apache Hive、Apache Iceberg 和Apache Hudi 中的数据，查询性能大大提高，同时避免了数据复制。

参考：
https://doris.apache.org/zh-CN/docs/dev/summary/basic-summary

https://zhuanlan.zhihu.com/p/400642016

https://blog.csdn.net/Shockang/article/details/127062897

https://blog.csdn.net/qq_43141726/article/details/120607561

https://blog.csdn.net/yy8623977/article/details/126072971

https://blog.csdn.net/Hello_Java2018/article/details/124806183