

首页  思维导图  详情



Doris知识梳理

2024-09-25 23:11:48   16  举报





AI智能生成

Doris知识梳理

Doris

Java

大数据

OLAP

架构

模版推荐

作者其他创作

大纲/内容

三大组件

C/C++编写

主要负责数据存储、查询计划的执行

部署建议

BE、FE尽可能不要混合部署，争抢资源

一台服务器尽可能只部署一个BE

集群的性能与 BE 节点的资源有关，BE 节点越多，Doris 性能越好。通常情况下在 10 - 100 台机器上可以充分发挥 Doris 的性能

Java编写

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

部署建议

一台服务器尽可能只部署一个FE

BE、FE尽可能不要混合部署，争抢资源

Broker

通常情况下可以将 Broker 节点与 FE / BE 节点部署在同一台机器上

硬件

内存

建议内存至少是 CPU 核数的 4 倍，8倍更佳

存储

大规模数据量，高并发点查，高频数据更新场景选用SSD

网卡

万兆网卡

基础

数据模型

明细模型 duplicate

默认

保留明细数据

建议选择前2-4列作为Duplicate Key

主键模型 unique

保证主键唯一，新写入的数据会覆盖具有相同 key（主键）的旧数据

两种实现方式

读时合并 (merge-on-read)

写入性能好

查询性能差

内存消耗高

写时合并 (merge-on-write)

1.2引入

开启参数：enable_unique_key_merge_on_write

2.1成为unique的默认实现

聚合模型 aggregate

AggregationType

SUM

REPLACE

在同一个导入批次中的数据，对于 REPLACE 这种聚合方式，替换顺序不做保证，而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次

MAX

MIN

REPLACE_IF_NOT_NULL

在同一个导入批次中的数据，对于 REPLACE_IF_NOT_NULL 这种聚合方式，替换顺序不做保证，而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次

HLL_UNION

BITMAP_UNION

数据聚合发生在三个阶段

每一批次数据导入的 ETL 阶段。该阶段会在每一批次导入的数据内部进行聚合。

底层 BE 进行数据 Compaction 的阶段。该阶段，BE 会对已导入的不同批次的数据进行进一步的聚合。

数据查询阶段。在数据查询时，对于查询涉及到的数据，会进行对应的聚合。

使用注意

Key 列必须在所有 Value 列之前

尽量选择整型类型

聚合模型的局限性

查询性能

在查询引擎中加入了聚合算子，来保证数据对外的一致性（可能BE还没有完全完成数据的预聚合）

聚合模型下，慎用COUNT

两个建议

增加一个值恒为 1 的，聚合类型为 SUM 的列来模拟COUNT

增加一个值恒为 1 的，聚合类型为 REPLACE 的列来模拟COUNT

注意SQL语义

Key的不同含义

Duplicate 模型，表的 Key 列，可以认为只是 "排序列"，并非起到唯一标识的作用

Aggregate、Unique 模型这种聚合类型的表，Key 列是兼顾 "排序列" 和 "唯一标识列"，是真正意义上的 "Key 列"

如何选择

Aggregate

通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景

对 count(*) 查询很不友好

需要考虑语义正确性

Unique

需要唯一主键约束的场景

无法利用预聚合带来的查询优势

建议使用写时合并

Duplicate

无法利用预聚合带来的查询优势

可以发挥列存的优势

前缀索引

建表时自动取表的 Key 的前 36 字节作为前缀索引，碰见 varchar 类型的字段，会自动截断前 20 个字符，后面的列也不会加入前缀索引

一个表只能有一个前缀索引，对于前缀索引不好设计的，可以通过创建物化视图、物化索引来人为的调整列顺序

前缀索引的第一个字段一定是最常查询的字段，并且需要是高基数字段

分区分桶

Doris支持两层的数据划分，第一层是分区（Partition），第二层是分桶（Bucket、Tablet）

分区

两种方式

List

Range

如果建表不指定分区，会有默认分区

一个分区包含若干Tablet

分桶

两种方式

Hash

Random

用户数据被水平划分为若干个数据分片（Tablet，也称作数据分桶）。每个 Tablet 包含若干数据行。各个 Tablet 之间的数据没有交集，并且在物理上是独立存储的

一个 Tablet 只属于一个分区

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

一个Tablet在1-10G

进阶

动态分区

仅适用于单分区列

物化索引

物化视图

将预先计算（根据定义好的 SELECT 语句）好的数据集，存储在 Doris 中的一个特殊的表

适用场景

分析需求覆盖明细数据查询以及固定维度查询两方面

查询仅涉及表中的很小一部分列或行

查询包含一些耗时处理操作

查询需要匹配不同前缀索引

优势

自动维护物化视图的数据，可以保证与base表的一致性

自动选择最佳的物化视图进行查询

JOIN

两种物理算子

Hash Join

Nest loop Join

四种JOIN方式

Broadcast Join

把右表的全量数据都发送到左表，即每一个参与 Join 的节点，都拥有右表全量的数据

Shuffle Join

左右表根据JOIN列，将数据发送到不同的节点上

Bucket Shuffle Join

JOIN列是左表的分桶列， 右表根据JOIN列，将数据发送到左表

Colocate

条件最为苛刻，在创建表的时候就指定，提前做好了数据的Shuffle

两个专业名词

Colocation Group（CG）

Colocation Group Schema（CGS）

创建表使用 colocate_with 声明 CG

苛刻的条件

JOIN列就是分桶列

分桶列的类型和数量完全一致

所有分区（Partition）的副本数必须一致

Runtime Filter优化

场景：大表JOIN小表

三方优化方式

效果明显、快速

只适用于BroadCast

右表超过一定的数量（1024）就失败

BloomFilter

通用

计算成本较高

MinMax

仅对数值列有效

可以组合，默认是IN+BloomFilter

调优建议

简单类型、同类型做关联

大表之间的JSON尽可能Colocation

合理的使用 Runtime Filter

尽量保持左表为大表，右表为小表

必要时，使用Hint

高并发点查

手段

开启行存："store_row_column" = "true"

如果是unqiue，开启enable_unique_key_merge_on_write

开启light_schema_change

建议使用"row_store_columns"="key,v1,v2" 类似的方式指定部分列进行行存

使用 PreparedStatement，在连接字符串设置：jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true 

开启行缓存：disable_storage_row_cache，row_cache_mem_limit指定 Row cache 占用内存的百分比

增加 Observer 数量

只支持单表 key 列等值查询，且查询中不能包含 join，嵌套子查询

高效去重

bitmap精确去重

需要精确去重的列数据类型是 bitmap , 聚合函数是 bitmap_union

表中需要建立一个分桶列，分桶列与需要精确去重的列是有关系的

分桶字段的基数至少是BUCKETS数的5倍以上

无法用于分区表

HLL近似去重

两个理论

极大似然估算

伯努利试验

需要近似去重的列数据类型的hll，聚合函数是hll_union

 Collect

Get Started

数据梳理

 Collect

Get Started

AI产品经理必备知识

 Collect

Get Started

流程梳理

 Collect

Get Started

梳理





0 条评论

下一页