Doris初识

1 简介

1、Doris由百度大数据部研发，之前叫百度Palo，于2017年开源，2018年贡献到 Apache 社区后，更名为Doris
2、是一个现代化的基于MPP（Massively Parallel Processing 大规模并行处理）技术的分析型数据库产品。简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。
3、可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。

1.1 应用场景

一般情况下，用户的原始数据，比如日志或者在事务型数据库中的数据，经过流式系统或离线处理后，导入到Doris中以供上层的报表工具或者数据分析师查询使用

核心特性：

基于MPP（大规模并行处理）架构的分析型数据库
性能卓越，PB级别数据毫秒/秒级响应
支持标准SQL语言，兼容MySQL协议
向量化执行器
高效的聚合表技术
新型预聚合技术Rollup
高性能、高可用、高可靠
极简运维，弹性伸缩

HTAP（Hybrid Transactional 混合事务/Analytical Processing 分析处理）

基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
目前，实现 HTAP 的数据库不多，主要有 PingCAP 的 TiDB、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是国内首家开源的 HTAP 分布式数据库。

1.2 开源OLAP引擎对比

OLAP按存储器的数据存储格式分为MOLAP（Multi-dimensional OLAP） 、ROLAP（Relational OLAP）和 HOLAP（Hybrid OLAP）

MOLAP模式的劣势（以Kylin为例）

应用层模型复杂，根据业务需要以及Kylin生产需要，还要做较多模型预处理。这样在不同的业务场景中，模型的利用率也比较低。
由于MOLAP不支持明细数据的查询，在“汇总+明细”的应用场景中，明细数据需要同步到DBMS引擎来响应交互，增加了生产的运维成本。
较多的预处理伴随着较高的生产成本。

ROLAP模式的优势

应用层模型设计简化，将数据固定在一个稳定的数据粒度即可。比如商家粒度的星形模型，同时复用率也比较高。
App层的业务表达可以通过视图进行封装，减少了数据冗余，同时提高了应用的灵活性，降低了运维成本。
同时支持“汇总+明细”。
模型轻量标准化，极大的降低了生产成本。

Doris是一个ROLAP引擎, 可以满足以下需求

灵活多维分析
明细+聚合
主键更新

总结：

数据压缩率Clickhouse好
ClickHouse单表查询性能优势巨大
Join查询两者各有优劣，数据量小情况下Clickhouse好，数据量大Doris好
Doris对SQL支持情况要好

2 架构

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

2.1 FE和BE

Doris的系统架构由两个角色负责（主要分为FE和BE两个角色），不依赖于外部组件，方便部署和运维

FE(Frontend)：存储、维护集群元数据（类似前端）

主要用于存储元数据，包括日志和 image。通常从几百 MB 到几个 GB 不等。
FE 角色分为 Follower 和 Observer，（Leader 为 Follower 组中选举出来的一种角色，以下统称 Follower，多个follower组成选举组，会选出一个master，master是follower的一个特例，Master跟follower，主要是用来达到元数据的高可用，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务）。Observer节点仅从 leader 节点进行元数据同步，不参与选举。可以横向扩展以提供元数据的读服务的扩展性

FE 节点数据至少为1（1 个 Follower）。当部署 1 个 Follower 和 1 个 Observer 时，可以实现读高可用。当部署 3 个 Follower 时，可以实现读写高可用（HA）。
Follower 的数量必须为奇数，Observer 数量随意。
根据以往经验，当集群可用性要求很高是（比如提供在线业务），可以部署 3 个 Follower 和 1-3 个 Observer。如果是离线业务，建议部署 1 个 Follower 和 1-3 个 Observer。

BE(Backend)：负责物理数据的存储和计算（类似后端）BE通过副本机制可以保证数据的可靠性

总磁盘空间按用户总数据量 * 3（3副本）计算，然后再预留额外 40% 的空间用作后台 compaction 以及一些中间数据的存放

2.2 元数据结构

Doris采用 “Paxos协议以及Memory+ Checkpoint + Journal” 的机制来确保元数据的高性能及高可靠。元数据的每次更新，都会遵照以下几步：

1、首先写入到磁盘的日志文件中
2、然后再写到内存中
3、最后定期checkpoint到本地磁盘上

相当于是一个纯内存的一个结构，也就是说所有的元数据都会缓存在内存之中，从而保证FE在宕机后能够快速恢复元数据，而且不丢失元数据。

Leader、follower和 observer它们三个构成一个可靠的服务，如果发生节点宕机的情况，一般是部署一个leader两个follower，目前来说基本上也是这么部署的。就是说三个节点去达到一个高可用服务。单机的节点故障的时候其实基本上三个就够了，因为FE节点毕竟它只存了一份元数据，它的压力不大，所以如果FE太多的时候它会去消耗机器资源，所以多数情况下三个就足够了，可以达到一个很高可用的元数据服务。

2.3 数据分发

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

2.4 MySQL Client

借助MySQL协议，ODBC/JDBC以及MySQL客户端都可以可直接访问doris

mysql -u xxx -p -P9030

2.5 Broker

封装了文件系统接口，提供doris读取远端存储系统中文件的能力，包括HDFS、S3、BOS等。通常，在每台机器上部署一个 broker 实例即可。

3 Doris端口

4 Doris语法

4.1 建表

查看更多帮助：

HELP CREATE TABLE; 

建表

CREATE TABLE table_name
(
    event_day DATE,
    siteid INT DEFAULT '10',
    citycode SMALLINT,
    username VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, siteid, citycode, username)
PARTITION BY RANGE(event_day)
(
    PARTITION p201706 VALUES LESS THAN ('2024-07-01'),
    PARTITION p201707 VALUES LESS THAN ('2024-08-01'),
    PARTITION p201708 VALUES LESS THAN ('2024-09-01')
)
DISTRIBUTED BY HASH(siteid) BUCKETS 10
PROPERTIES("replication_num" = "1");

4.2 字段类型

4.3 单分区和复合分区

Doris 支持两层的数据划分。第一层是 Partition，支持 Range 和 List 的划分方式。第二层是 Bucket（Tablet），仅支持 Hash 的划分方式。
也可以仅使用一层分区，即使用单分区。使用一层分区时，只支持 Bucket 划分。

单分区

CREATE TABLE table1
(
    siteid INT DEFAULT '10',
    citycode SMALLINT,
    username VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(siteid, citycode, username)
DISTRIBUTED BY HASH(siteid) BUCKETS 10
PROPERTIES("replication_num" = "1");

复合分区

使用 event_day 列作为分区列，建立3个分区: p202406, p202407, p202408(区间为左闭右开)
p202406：范围为 [最小值, 2024-07-01)
p202407：范围为 [2024-07-01, 2024-08-01)
p202408：范围为 [2024-08-01, 2024-09-01)
每个分区使用 siteid 进行哈希分桶，桶数为10

CREATE TABLE table2
(
    event_day DATE,
    siteid INT DEFAULT '10',
    citycode SMALLINT,
    username VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, siteid, citycode, username)
PARTITION BY RANGE(event_day)
(
    PARTITION p202406 VALUES LESS THAN ('2024-07-01'),
    PARTITION p202407 VALUES LESS THAN ('2024-08-01'),
    PARTITION p202408 VALUES LESS THAN ('2024-09-01')
)
DISTRIBUTED BY HASH(siteid) BUCKETS 10
PROPERTIES("replication_num" = "1");

表通过设置 replication_num 建的都是单副本的表，Doris建议用户采用默认的 3 副本设置，以保证高可用。
可以对复合分区表动态的增删分区。详见 HELP ALTER TABLE 中 Partition 相关部分。
数据导入可以导入指定的 Partition。详见 HELP LOAD。
可以动态修改表的 Schema。
可以对 Table 增加上卷表（Rollup）以提高查询性能，这部分可以参见高级使用指南关于 Rollup 的描述。
表的列的Null属性默认为true，会对查询性能有一定的影响。

荐使用复合分区的场景
有时间维度或类似带有有序值的维度，可以以这类维度列作为分区列。分区粒度可以根据导入频次、分区数据量等进行评估。
历史数据删除需求：如有删除历史数据的需求（比如仅保留最近N 天的数据）。使用复合分区，可以通过删除历史分区来达到目的。也可以通过在指定分区内发送 DELETE 语句进行数据删除。
解决数据倾斜问题：每个分区可以单独指定分桶数量。如按天分区，当每天的数据量差异很大时，可以通过指定分区的分桶数，合理划分不同分区的数据,分桶列建议选择区分度大的列。