Doris知识梳理
2024-09-25 23:11:48 12 举报AI智能生成
Doris知识梳理
作者其他创作
大纲/内容
三大组件
BE
C/C++编写
主要负责数据存储、查询计划的执行
部署建议
BE、FE尽可能不要混合部署，争抢资源
一台服务器尽可能只部署一个BE
集群的性能与 BE 节点的资源有关，BE 节点越多，Doris 性能越好。通常情况下在 10 - 100 台机器上可以充分发挥 Doris 的性能
FE
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小表
三方优化方式
IN
效果明显、快速
只适用于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
0 条评论
下一页
