大数据分析引擎-Doris简要介绍

目录：

1、背景

2、Doris的架构

3、Doris的核心特性

4、数据的导入和输出

1、背景

大数据的时代，数据的处理能力大大增强，但在最后一个环节，即数据应用服务环节依然存在较大的瓶颈。

原来业务数据库时代，高并发、高灵活性是一个矛盾体，如何让一线在灵活定制分析SQL时候，虽然拖拉拽生成了不忍直视的SQL，但希望查询引擎依旧可以保持强劲的性能指标，不管是并发度还是查询时间都能让客户满意，是蛮有挑战的一件事情。

目前的查询分析非常多，并且还在不断的涌现出来，引擎层出不穷，各有优势也有其缺点，比如ADB、Hologres、Presto、Kylin、Hbase、Doris，这些产品本质上都是用资源换时间，或者空间换时间，本质上就是计算机制重构（比如MPP）、硬件提速（比如SSD磁盘）、索引提速（比如位图）、空间转换（比如预计算）等维度是提升性能。不断涌现且更新的技术产品也从侧面印证了查询引擎的问题依然很多，痛点依旧没有解决，同时也大有可为。

Doris最近也是比较火的一款产品，脱胎于百度的广告业务，适应于实时分析场景，确实解决了查询引擎的一些场景下的痛点问题，接下来就将个人对Doris的一些理解简单介绍一下。

2、Doris架构

在介绍Doris的特性之前，先让我们了解一下Doris的整体架构。具体包括几个核心维度：

• MPP的运行框架，充分挖掘多核CPU的并行计算能力；
• 分布式架构支持多副本支撑高可用；
• 接入了多个大数据的生态，比如Spark， Flink， Hive， ElasticSearch，提供了丰富的数据接入和输出的服务；
• 采取分区分桶的机制，支持多种索引技术，满足PB级的存储和分析能力；
• 支持Mysql协作，简单、易用；
• 列式存储和压缩技术，提升查询性能；

Doris由FrontEnd DorisDB前端节点和BackEnd DorisDB后端节点核心组件组成；前端节点负责管理元数据、管理客户端的连接、进行查询规划和调度等工作；后端节点负责数据存储、计算执行、副本管理等；另外还包括DorisManager和Broker，DorisManager管理工具，负责提供集群管理、在线查询、故障查询、监控报警的可视化工具；Broker负责和外部存储（HDFS或对象存储）进行数据的导出导入等辅助功能；Doris可以通过MySQL客户端直接访问。

Doris核心组件及运行模式如下（以下FrontEnd DorisDB简称FE，BackEnd DorisDB简称BE）：

首先是FE：

• 管理元数据, 执行SQL DDL命令, 用Catalog记录库, 表, 分区, tablet副本等信息。

• FE高可用部署, 使用复制协议选主和主从同步元数据, 所有的元数据修改操作, 由FE leader节点完成, FE follower节点可执行读操作。 元数据的读写满足顺序一致性。  FE的节点数目采用2n+1, 可容忍n个节点故障。  当FE leader故障时, 从现有的follower节点重新选主, 完成故障切换。
• FE的SQL layer对用户提交的SQL进行解析, 分析, 改写, 语义分析和关系代数优化, 生产逻辑执行计划。
• FE的Planner负责把逻辑计划转化为可分布式执行的物理计划, 分发给一组BE。
• FE监督BE, 管理BE的上下线, 根据BE的存活和健康状态, 维持tablet副本的数量。
• FE协调数据导入, 保证数据导入的一致性。

其次是BE：

• BE管理tablet副本, tablet是table经过分区分桶形成的子表, 采用列式存储。
• BE受FE指导, 创建或删除子表。
• B