Drois（Palo）

        Drois是百度大数据部数据团队所开发的一套面向大规模数据分析的并行数据库系统。主要目标是支撑稳定的、在线的、交互式的数据报表(Reporting)和数据多维分析（OLAP）服务。Palo 的一个很大的特色是：将会满足报表和OLAP分析这两类不同的需求。它是一个现代化的MPP分析型数据库产品。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris的分布式架构非常简洁，易于运维，并且可以支持10PB以上的超大数据集。

Drois主要具有以下特点：

• 高性能的行列存储引擎
• 小批量更新，批量原子提交，多版本支持
• 高效的分布式数据导入
• 支持Rollup Table, Scheme Change, Data Recovery
• 较完备的分布式管理框架，使得整个Palo易用易运维
• Range partition: 全局key排序，自动分裂(in progress)
• 支持低并发大查询
• 支持高并发小查询(in progress)
• 调度和资源隔离(in progress)
• 实现了Mysql网络协议，可以很容易与各种上层工具打通
• 支持多表join(一个大表与多个小表；大表与可以加载到分布式内存的大表)
• Rollup表智能选择
• 复杂谓词下推
• Palo通过外部表的方式支持直接查询用户的Mysql数据表

一、Doris 整体架构

Doris 的整体架构和 TiDB 类似，借助 MySQL 协议，用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端，都可以直接访问 Doris。Doris 中的模块包括 FE 和 BE 两类：FE 主要负责元数据的管理、存储，以及查询的解析等；一个用户请求经过 FE 解析、规划后，具体的执行计划会发送给 BE，BE 则会完成查询的具体执行。BE 节点主要负责数据的存储、以及查询计划的执行。

Frontend守护进程：由查询协调器和目录管理器组成.

1. 查询协调器负责接收用户的SQL查询、编译查询和管理查询执行

2. 目录管理器负责管理数据库、表、分区、副本等元数据

可以部署多个前端守护程序来保证容错和负载平衡。

Backend守护程序：负责存储数据并执行查询片段，同样可以部署许多后端守护程序来提供可扩展性和容错性。

Broker为可选组件，如果客户用到hdfs功能，broker就负责拉取hdfs的数据并放在本地，然后palo就能流式的读到hdfs的数据了

Doris 数据分布

        如果从表的角度来看数据结构，用户的一张 Table 会拆成多个 Tablet，Tablet 会存成多副本，存储在不同的 BE 中，从而保证数据的高可用和高可靠。

 二、Drois 的索引 

    Drois 中的索引不特定指数据库中的索引，这里的索引是一个宽泛的概念，指能提高查询效率的设计；Drois 中存在类似功能的设计，包括针对组合后 key 的排序设计、视图下的分区设计都有索引的功能；与数据库中索引不同的是：数据库中的索引是一个B树结构，占用存储空间的，而 Drois 中的索引概念是通过其他方式加快查询。Drois 之所以能以较低的成本提供在大数据集上的高性能分析和报表查询功能，主要源于以下的设计。

数据模型

物化索引

两级分区

1. 数据模型

        Palo 将 Google Mesa 数据模型和ORC File/Parquet 存储技术相结合。在Mesa中，将OLAP 系统中的维度列称为Key，将指标列称为Value。数据按照指定的key列进行排序，加快数据检索。并且针对key指定一个聚合函数，来对数据进行预聚合。

                                                                         

  注：其中 DUPLICATE 模型适合数据既没有主键，也没有聚合需求的场景，DUPLICATE KEY 只能指明底层数据排序顺序，而 UNIQUE KEY 能保证 KEY 列值得唯一性；

        比如，Palo中有一张表包含三列：k1，k2和v，其中v是int类型的value列，聚合方法是SUM，k1和k2是key列。假如原本有数据如下：

2. 物化索引（Rollup）

        Rollup 可以理解为 Table 的一个物化索引结构。物化 是因为其数据在物理上是独立存储的。而 索引 的意思是，Rollup 存在的目是用于加速在这个 Table 上的某类查询响应。Rollup 附属于 Table，一个 Table 可以有多个 Rollup。在创建 Table 时会默认生成一个 Base Rollup，该 Rollup 包含 Table 的所有列。后续的其他 Rollup 在此基础上创建。并且通常其他 Rollup 的列数要少于 Base Rollup。如下图所示：

                                

        Rollup 通过指定某些常用的维度组合，对指标列进行聚合，能够极大地减少数据量，从而加速查询。 

3. 两级分区

    第一级 Range 分区（partition）：按照用户定义将数据划分成不同区间，查询和删除可以按照分区进行。用户可以指定某一维度列作为分区列（当前只支持整型和时间类型的列），并可以指定每个分区的取值范围。

      有4个维度列（event_day, siteid, citycode, username）和1个指标列（pv）；其中event_day作为分区列，并设置了三个分区p1,p2,p3。其中每个分区使用 siteid 进行哈希分桶，桶数为 32。

* p1：范围为 [最小值,     2015-06-30)
* p2：范围为 [2015-06-30, 2015-07-31)
* p3：范围为 [2015-07-31, 2015-08-31)

       第二级分区 Hash 分桶（bucket）：根据 hash值将数据划分成不同的 bucket，应该采用区分度较大的列来作为分桶，避免出现数据倾斜。

        除次之外，drois 中使用类似 前缀索引 的结构来提高查询性能。数据在 Palo 内部组织为一个个 Data Block。每个 Data Block 的第一行的前几列会被用作这个 Data Block 的索引，在数据导入时被创建。考虑到索引大小等因素，Palo 最多使用一行的前 36 个字节作为索引，并且遇到 VARCHAR 类型则会中断并截止。并且 VARCHAR 类型最多只是用字符串的前 20 个字节。下面举例说明：

        以 表2 和 表3 为例，进一步说明表模式对查询性能的影响。两个表的 Schema 除了列顺序不同，其他完全一样。

如下查询:

                SELECT * from tbl WHERE k1 = 12345;

      在表2 的查询性能会明显优于 表3。因为在 表2 可以运用到 k1 索引，而 表3 因为只有 k3 作为索引，因此等同于全表扫描。

三、Backup & Restore 备份与恢复

        Drois 支持将当前数据以文件的形式，通过broker 备份到远端存储系统中。之后可以通过恢复命令，从远端存储系统中将数据恢复到任意Palo 集群。通过这个功能，Palo 可以支持将数据定期的进行快照备份。也可以通过这个功能，在不同集群间进行数据迁移。（该功能需要Palo 版本0.8.2+）。使用该功能，需要部署对应远端存储的broker。如BOS、HDFS 等。可以通过 SHOW BROKER; 查看当前部署的broker。简要原理说明如下：

备份

备份 *** 作是将指定表或分区的数据，直接以Palo 存储的文件的形式，上传到远端仓库中进行存储。主要有如下步骤：

快照及快照上传：快照阶段会对指定的表或分区数据文件进行快照。之后，备份都是对快照进行 *** 作。在快照之后，对表进行的更改、导入等 *** 作都不再影响备份的结果。快照只是对当前数据文件产生一个硬链，耗时很少。快照完成后，会开始对这些快照文件进行逐一上传。快照上传由各个Backend 并发完成。

元数据准备及上传：数据文件快照上传完成后，Frontend 会首先将对应元数据写成本地文件，然后通过broker 将本地元数据文件上传到远端仓库。完成最终备份作业。

恢复

恢复 *** 作需要指定一个远端仓库中已存在的备份，然后将这个备份的内容恢复到本地集群中。主要有如下步骤：

在本地创建对应的元数据：这一步首先会在本地集群中，创建恢复对应的表分区等结构。创建完成后，该表可见，但是不可访问。

本地snapshot：这一步是将上一步创建的表做一个快照。这其实是一个空快照（因为刚创建的表是没有数据的），其目的主要是在Backend 上产生对应的快照目录，用于之后接收从远端仓库下载的快照文件。

下载快照：远端仓库中的快照文件，会被下载到对应的上一步生成的快照目录中。这一步由各个Backend 并发完成。

生效快照：快照下载完成后，我们要将各个快照映射为当前本地表的元数据。然后重新加载这些快照，使之生效，完成最终的恢复作业。