研发之前叫百度

在百度内部有超过200个产品线在使用部署机器超过1000台单一业务最大可达到上百

Apache

Processing即大规模并行处理分析型数据库产品。

仅需亚秒级响应时间即可获得查询结果有效地支持实时数据分析。

Apache

Doris的分布式架构非常简洁易于运维并且可以支持10PB以上的超大数据集。

Apache

Doris可以满足多种数据分析需求例如固定历史报表实时数据分析交互式数据分析和探索式数据分析等。

Doris

Analytics。

比如面向网站主的站点分析、面向广告主的广告报表并发通常要求成千上万的

QPS

面向分析师的自助分析查询模式不固定要求较高的吞吐。

小米公司基于

Doris

AnalyticsGA利用用户行为数据对业务进行增长分析平均查询延时

10s95

一个平台满足统一的数据仓库建设需求简化繁琐的大数据软件栈。

海底捞基于

Doris

Hive、Iceberg、Hudi中的数据在避免数据拷贝的前提下查询性能大幅提升。

Doris

主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。

主要有三个角色

和Follower主要是用来达到元数据的高可用保证单节点宕机的情况下元数据能够实时地在线恢复而不影响整个服务。

2Observer用来扩展查询节点同时起到元数据备份的作用。

如果在发现集群压力非常大的情况下需要去扩展整个查询的能力那么可以加

observer

会对整个数据存储多副本或者是三副本。

副本数可根据需求动态调整。

MySQL

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

Broker

1FE的磁盘空间主要用于存储元数据包括日志和image。

通常从几百MB到几个GB不等。

2BE的磁盘空间主要用于存放用户数据总磁盘空间按用户总数据量*

33副本计算然后再预留额外40%的空间用作后台compaction以及一些中间数据的存放。

副本数据那么至少需要

台机器各部署一个BE实例而不是1台机器部署3个BE实例。

多个FE所在服务器的时钟必须保持一致允许最多5秒的时钟偏差

4测试环境也可以仅适用一个BE进行测试。

实际生产环境BE实例数量直接决定了整体查询延迟。

6FE节点数据至少为11个Follower。

当部署1个Follower和1个Observer时可以实现读高可用。

当部署3个Follower时可以实现读写高可用HA。

8根据以往经验当集群可用性要求很高时比如提供在线业务可以部署3个

Follower和1-3个Observer。

如果是离线业务建议部署1个Follower和1-3个Observer。

9Broker是用于访问外部数据源如HDFS的进程。

通常在每台机器上部署一个

2.1.6

apache-doris-fe-1.2.4.1-bin-arm.tar.xz

/opt/module/dorismv

/opt/module/doris/apache-doris-fe-1.2.4.1-bin-arm

tar

apache-doris-be-1.2.4.1-bin-arm.tar.xz

/opt/module/dorismv

/opt/module/doris/apache-doris-be-1.2.4.1-bin-arm

/opt/module/doris/be3.安装其他依赖java

udf

apache-doris-dependencies-1.2.4.1-bin-arm.tar.xz

/opt/module/dorismv

/opt/module/doris/apache-doris-dependencies-1.2.4.1-bin-arm

/opt/module/doris/dependenciescp

/opt/module/doris/dependencies/java-udf-jar-with-dependencies.jar

修改FE配置文件

/opt/module/doris/fe/conf/fe.conf#

web

/opt/module/doris/fe/doris-meta

修改绑定

192.168.9.102/24-生产环境强烈建议单独指定下最好是单独的磁盘如果有SSD最好。

-如果机器有多个ip,

/opt/module/doris/fe/bin/start_fe.sh

--daemon登录

/opt/module/doris/be/conf/be.confwebserver_port

7040#

/opt/module/doris/doris-storage1;/opt/module/doris/doris-storage2.SSD,10

priority_networks

-storage_root_path默认在be/storage下需要手动创建该后不要加。

-如果机器有多个IP,

BE节点需要先在FE中添加才可加入集群。

可以使用mysql-client连接到FE。

Mysql

/opt/module/doris/be/bin/start_be.sh

--daemon查询

可以通过将FE扩容至3个以上节点(必须是奇数)来实现FE的高可用。

2.3.2

FE分为LeaderFollower和Observer三种角色。

默认一个集群只能有一个Leader可以有多个Follower和Observer。

其中Leader和Follower组成一个Paxos选择组如果

如果只部署一个FE则FE

默认就是Leader。

在此基础上可以添加若干Follower和

ALTER

hadoop104:9010;配置Follower和Observer

my_rsync

/opt/module/doris/fe/doris-meta/*在

hadoop103和

/opt/module/doris/fe/bin/start_fe.sh

--daemon

be_host:be_heartbeat_service_port;注意DROP

BACKEND

会直接删除该BE并且其上的数据将不能再恢复所以我们强烈不推荐使用

DROP

这种方式删除BE节点。

当你使用这个语句时会有对应的防误操作提示。

DECOMMISSION

be_host:be_heartbeat_service_port;该命令用于安全删除BE节点。

命令下发后Doris

会尝试将该BE上的数据向其他BE节点迁移当所有数据都迁移完成后Doris会自动删除该节点。

SHOW

节点的isDecommission状态为true。

表示该节点正在进行下线。

该命令不一定执行成功。

比如剩余BE存储空间不足以容纳下线BE上的数据或者剩余机器数量不满足最小副本数时该命令都无法完成并且BE会一直处于

PROC

中的TabletNum查看如果正在进行TabletNum将不断减少。

CANCEL

be_host:be_heartbeat_service_port;取消后该BE上的数据将维持当前剩余的数据量。

后续Doris重新进行负载均衡。

2.4

/opt/module/doris/fe/bin/start_fe.sh

--daemondonefor

/opt/module/doris/be/bin/start_be.sh

host

/opt/module/doris/fe/bin/stop_fe.sh

donefor

/opt/module/doris/be/bin/stop_be.sh

done;;*)echo

在Doris的存储引擎中用户数据首先被划分成若干个分区Partition划分的规则通常是按照用户指定的分区列进行范围划分比如按时间划分。

而在每个分区内数据被进一步的按照Hash的方式分桶分桶的规则是要找用户指定的分桶列的值进行Hash后分桶。

每个分桶就是一个数据分片Tablet也是数据划分的最小逻辑单元。

Tablet之间的数据是没有交集的独立存储的。

Tablet也是数据移动、复制等操作的最小物理存储单元。

Partition可以视为是逻辑上最小的管理单元。

数据的导入与删除都可以或仅能针对一个

Partition

(10000,2017-10-01,北京,20,0,2017-10-01

06:00:00

(10000,2017-10-01,北京,20,0,2017-10-01

07:00:00,15,2,2),\

(10001,2017-10-01,北京,30,1,2017-10-01

17:05:45,2,22,22),\

(10002,2017-10-02,上海,20,1,2017-10-02

12:59:12

(10003,2017-10-02,广州,32,0,2017-10-02

11:20:00,30,11,11),\

(10004,2017-10-01,深圳,35,0,2017-10-01

10:00:15,100,3,3),\

(10004,2017-10-03,深圳,35,0,2017-10-03

into

单条数据这种操作在Doris里只能演示不能在生产使用会引发写阻塞。

说明:

这种聚合方式替换顺序不做保证。

而对于不同导入批次中的数据可以保证后一批次的数据会替换前一批次。

中最终只会存储聚合后的数据。

换句话说即明细数据会丢失用户不能够再查询到聚合前的明细数据了。

-如果想要保留明细数据不让

的数据模型。

该模型本质上是聚合模型的一个特例也是一种简化的表结构表示方式。

-建表

(10000,wuyanzu,北京,18,0,12345678910,北京朝阳区,2017-10-01

07:00:00),\

(10000,wuyanzu,北京,19,1,12345678910,北京朝阳区,2017-10-01

08:00:00),\

(10000,zhangsan,北京,20,0,12345678910,北京海淀区,2017-11-15

CREATE

方式替代。

其内部的实现方式和数据存储方式也完全一样。

这里不再继续举例说明。

3.3.3Duplicate

在某些多维分析场景下数据既没有主键也没有聚合需求。

因此我们引入

Duplicate

模型。

数据完全按照导入文件中的数据进行存储不会有任何聚合。

即使两行数据完全相同也都会保留。

DUPLICATE

这种数据模型适用于既没有聚合需求又没有主键唯一性约束的原始数据的存储。

3.4

[database.]table_name(column_definition1[,

column_definition2,

[olap|mysql|broker|hive|es]][key_desc][COMMENT

table

comment];[partition_desc][distribution_desc][rollup_index][PROPERTIES

(keyvalue,

KEY数据模型为例进行说明。

更多数据模型参阅Doris数据模型。

CREATE

KEY数据模型中所有没有指定聚合方式SUM、REPLACE、MAX、MIN的列视为Key列。

而其余则为Value列。

-Key

-尽量选择整型类型。

因为整型类型的计算和查找比较效率远高于字符串。

3.5.2ENGINE(引擎)

mysql、broker、es、hive等等本质上只是对外部其他数据库或系统中的表的映射以保证

Doris

-Partition列可以指定一列或多列。

分区列必须为KEY列。

多列分区的使用方式在后面介绍。

-当不使用Partition建表时系统会自动生成一个和表名同名的全值范围的

Partition。

该Partition对用户不可见并且不可删改。

Rang

仅指定上界系统会将前一个分区的上界作为该分区的下界生成一个左闭右开的区间。

VALUES

(10000,2017-01-01,北京,20,0,2017-01-01

插入不成功,抛出异常

(20000,2017-11-01,北京,20,0,2017-11-01

p201705

2017-06-01)需要注意的是,这时其他分区并不会发生变化,

[2017-03-01,

综上分区的删除不会改变已存在分区的范围。

删除分区可能出现空洞。

通过

VALUES

数据类型分区值为枚举值。

只有当数据为目标分区枚举值其中之一时才可以命中分区

Partition

(10000,‘2017-01-01’,‘Beijing’,20,0,‘2017-01-01

06:00:00’,20,10,10);

(20000,‘2017-01-01’,‘shenzhen’,20,0,‘2017-01-01

06:00:00’,20,10,10);

如果选择多个分桶列则数据分布更均匀。

如果一个查询条件不包含所有分桶列的等值条件那么该查询会触发所有分桶同时扫描这样查询的吞吐会增加单个查询的延迟随之降低。

这个方式适合大吞吐低并发的查询场景。

如果仅选择一个或少数分桶列则对应的点查询可以仅触发一个分桶扫描。

此时当多个点查询并发时这些查询有较大的概率分别触发不同的分桶扫描各个查询之间的IO影响较小尤其当不同桶分布在不同磁盘上时所以这种方式适合高并发的点查询场景。

复合分区与单分区

有时间维度或类似带有有序值的维度可以以这类维度列作为分区列。

分区粒度可以根据导入频次、分区数据量等进行评估。

天的数据。

使用复合分区可以通过删除历史分区来达到目的。

也可以通过在指定分区内发送

DELETE

解决数据倾斜问题每个分区可以单独指定分桶数量。

如按天分区当每天的数据量差异很大时可以通过指定分区的分桶数合理划分不同分区的数据,分桶列建议选择区分度大的列。

多列分区

MIN_VALUE。

当用户插入数据时分区列值会按照顺序依次比较,

2017-01-01,

Shanghai)]当用户插入数据时分区列值会按照顺序依次比较最终得到对应的分区。

举例如下

---

storage_medium/storage_cooldown_time

storage_medium

版本中引入的新功能。

旨在对表级别的分区实现生命周期管理(TTL)减少用户的使用负担。

动态分区只支持

在某些使用场景下用户会将表按照天进行分区划分每天定时执行例行任务这时需要使用方手动管理分区否则可能由于使用方没有创建分区导致数据导入失败这给使用方带来了额外的维护成本。

会启动一个后台线程根据用户指定的规则创建或删除分区。

用户也可以在运行时对现有规则进行变更。

3.6.2使用方式

动态分区的规则可以在建表时指定或者在运行时进行修改。

当前仅支持对单分区列的分区表设定动态分区规则。

建表时指定

dynamic_partition.history_partition_num

expect_create_partition_num根据不同的设置具体数量如下

true

dynamic_partition.history_partition_num

未设置即

dynamic_partition.history_partition_num

已设置

不会创建历史分区expect_create_partition_num

end

max_dynamic_partition_num默认500时禁止创建过多分区。

history-num

2021-05-20按天分区动态分区的属性设置为create_history_partitiontrue,

end3,

history_partition_num1则系统会自动创建以下分区

p20210519

p20210523history_partition_num5其余属性与

p20210517

p20210523history_partition_num-1

即不设置历史分区数量其余属性与

动态分区使用过程中如果因为一些意外情况导致dynamic_partition.start

之间的丢失分区会被重新创建dynamic_partition.start与当前时间之间的丢失分区不会重新创建。

3.6.6动态分区创建示例

dynamic_partition.create_history_partition

true,

dynamic_partition.history_partition_num

-7,

student_dynamic_partition1\G插入测试数据(需要修改日期)

insert

11:00:00,name1,18);动态分区表与手动分区表相互转换

对于一个表来说动态分区和手动分区可以自由转换但二者不能同时存在有且只有一种状态。

手动分区转换为动态分区

TABLE在运行时修改动态分区相关属性来转化为动态分区具体示例可以通过HELP

ALTER

注意如果已设定dynamic_partition.start分区范围在动态分区起始偏移之前的历史分区将会被删除。

动态分区转换为手动分区

关闭动态分区功能后Doris将不再自动管理分区需要用户手动通过ALTER

TABLE

在多维分析中是“上卷”的意思即将数据按某种指定的粒度进行进一步聚合(从细粒度到粗粒度)。

3.7.1基本概念

以3.3.1中创建的example_site_visit表为例。

查看表结构信息

比如需要查看某个用户的总消费那么可以建立一个只有user_id和cost的rollup

alter

rollup_cost_userid(user_id,cost);

然后查看表结构信息

rollup_city_age_cost_maxd_mind(city,age,cost,max_dwell_time,min_dwell_time);explain

SELECT

ROLLUP已经失去了“上卷”这一层含义。

而仅仅是作为调整列顺序以命中前缀索引的作用。

下面详细介绍前缀索引以及如何使用ROLLUP改变前缀索引以获得更好的查询效率。

前缀索引

Table的数据结构中。

该结构是一种有序的数据结构可以按照指定的列进行排序存储。

在这种数据结构上以排序列作为条件进行查找会非常的高效。

Aggregate、Unique

三种数据模型中。

底层的数据存储是按照各自建表语句中AGGREGATE

KEY、UNIQUE

而前缀索引即在排序的基础上实现的一种根据给定前缀列快速查询数据的索引方式。

个字节

当我们的查询条件是前缀索引的前缀时可以极大的加快查询速度。

比如在第一个例子中我们执行如下查询

SELECT

age20所以在建表时正确的选择列顺序能够极大地提高查询效率。

Rollup

因为建表时已经指定了列顺序所以一个表只有一种前缀索引。

这对于使用其他不能命中前缀索引的列作为条件进行的查询来说效率上可能无法满足需求。

因此我们可以通过创建

ROLLUP

可以看到ROLLUP和Base表的列完全一样只是将user_id和age的顺序调换了。

那么当我们进行如下查询时

SELECT

最根本的作用是提高某些查询的查询效率无论是通过聚合来减少数据量还是修改列顺序以匹配前缀索引。

因此

ROLLUP

越多占用的磁盘空间也就越大。

同时对导入速度也会有影响导入的ETL阶段会自动产生所有

ROLLUP

物化视图的出现主要是为了满足用户既能对原始明细数据的任意维度分析也能快速的对固定维度进行分析查询。

3.8.2适用场景​

Doris自动维护物化视图的数据无论是新的导入还是删除操作都能保证base

3.8.4物化视图

这里首先你要根据你的查询语句的特点来决定创建一个什么样的物化视图。

这里并不是说你的物化视图定义和你的某个查询语句一模一样就最好。

这里有两个原则

从查询语句中抽象出多个查询共有的分组和聚合方式作为物化视图的定义。

一个物化视图如果抽象出来并且多个查询都可以匹配到这张物化视图。

这种物化视图效果最好。

因为物化视图的维护本身也需要消耗资源。

如果物化视图只和某个特殊的查询很贴合而其他查询均用不到这个物化视图。

则会导致这张物化视图的性价比不高既占用了集群的存储资源还不能为更多的查询服务。

所以用户需要结合自己的查询语句以及数据维度信息去抽象出一些物化视图的定义。

在实际的分析查询中并不会覆盖到所有的维度分析。

所以给常用的维度组合创建物化视图即可从而到达一个空间和时间上的平衡。

创建物化视图是一个异步的操作也就是说用户成功提交创建任务后Doris

3.8.5.2创建物化视图示例

假设用户有一张销售记录明细表存储了每个交易的交易id销售员售卖门店销售时间以及金额。

1)创建一个

values(1,2,3,2020-02-02,10);2)基于这个Base表的数据提交一个创建物化视图的任务

create

由于创建物化视图是一个异步的操作用户在提交完创建物化视图任务后需要异步的通过命令检查物化视图是否构建完成。

SHOW

通过下面语句首先创建一个存储广告点击数据明细的表包含每条点击的点击时间点击的是什么广告通过什么渠道点击以及点击的用户是谁。

1)创建一个

values(2020-02-02,a,app,123);2)创建物化视图

create

bitmap_union(to_bitmap(user_id))

from

聚合的结果和bitmap_union_count聚合的结果是完全一致的。

而bitmap_union_count等于bitmap_union

count(distinct)

因为本身user_id是一个INT类型所以在Doris中需要先将字段通过函数to_bitmap转换为

3)查询自动匹配

bitmap_union_count(to_bitmap(user_id))

FROM

advertiser_uv。

也就是说查询会直接扫描物化视图的数据。

说明匹配成功。

其次对于user_id字段求count(distinct)被改写为求bitmap_union_count(to_bitmap)。

也就是通过

bitmap

store_id,record_id,seller_id,sale_date,sale_amt

from

sales_records;通过上面语法创建完成后物化视图中既保留了完整的明细数据且物化视图的前缀索引为store_id列。

3)查看表结构