这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战；
Apache Doris简介
Doris是一个基于mpp的交互式SQL数据仓库，是一个面向多种数据分析场景的、 兼容MySQL协议的， 高性能的， 分布式关系型列式数据库，可以通过MySQL客户端进行通信。用于报告和分析。由百度研发。在于2018年捐赠给Apache软件基金会。
本次将主要从以下三部分介绍Apache Doris
一、Doris定位
技术定位：我们首先看一下Doris整个的定位。
1. 数据仓库建设
2. OLAP/BI分析
3. 用户行为分析
4. 广告数据分析
5. 系统监控分析
Doris 的具体使用场景，可以接入多数据源，可以把数据源读到Doris里面来，然后在Doris里面对数据做各种的存储，以及做各种的多副本管理，基于Doris引擎进行数据处理。最后可以在上面接一个可视化工具，用来展示报表以及各种多维分析的检索的效果。这对于业务方在做可视化分析的时候效果是比较明显的。
简单来说，传统数据仓库能做的事Doris也能做，查询分析引擎能干的事Doris也能搞定。
Doris特点
1. 支持高并发点查询，支持明细和聚合查询
2. 支持离线批量导入和实时数据导入
3. 兼容MySQL协议和标准SQL
4. 支持Rollup Table和Rollup Table的智能查询路由
5. 支持较好的多表Join策略和灵活的表达式查询
6. 支持Schema在线变更
二、Doris整体架构
Doris 的整体架构和 TiDB 类似，借助 MySQL 协议，用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端，都可以直接访问 Doris。
- Doris的架构很简洁，只有 FE(Frontend)、BE(Backend)两种角色
FE：主要负责元数据的管理、存储，以及查询的解析等；一个用户请求经过 FE 解析、规划后，具体的执行计划会发送给BE。
BE：则会完成查询的具体执行。BE 节点主要负责数据的存储、以及查询计划的执行。
FE 部分主要使用 JAVA，BE 部分主要使用 C++。FE,BE都可线性扩展。
FE 主要有三个角色，一个是 leader，一个是 follower，还有一个 observer。leader 跟 follower，主要是用来达到元数据的高可用，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务。
· follower节点通过选举，其中一个 follower 成为 leader 节点，负责元数据的写入操作。当 leader 节点宕机后，其他 follower 节点会重新选举出一个 leader，保证服务的高可用。
· observer节点仅从 leader 节点进行元数据同步，不参与选举，不参与任何的写入，只参与读取。可以横向扩展以提供元数据的读服务的扩展性。
数据主要都是存储在 BE 里面，数据的可靠性由 BE 保证，BE 会对整个数据存储多副本。副本数可根据需求动态调整。
- Distributed Logical Plan (分布式逻辑计划)
最早是借鉴了Impala的查询引擎，把它改造了一下引入到Doris里面形成一个分布式的查询引擎。把它查询规划所有的部分，都放到了一个FE里面，即在这个图中所看到的整个的逻辑规划，都会由FE来完成。FE来根据用户的查询生成一个完整的逻辑规划，然后这个逻辑规划最后生成一个分布式的逻辑规划，会发给整个集群去执行。
可以看一个具体的例子。上图这样一个查询，展示了最后生成的物理规划是什么样的。这个图就是展示了它的逻辑，就是说查询会生成几个算子，主要有扫描的算子，聚合的算子，还有Join的算子，最后再排序。右边就相当于对整个的算子的一个实际物理划分。这个规划途中单个方框我们称之为一个Fragment， Fragment由单个BE节点执行，Fragment之间的数据交换通过RPC来完成。整个物理规划执行完之后，由FE把数据收集起来反馈给用户。
这基本上就是一个简单的物理的执行规划。
