Doris知识梳理
2024-09-25 23:11:48 1 举报AI智能生成
Doris知识梳理
作者其他创作
大纲/内容
C/C++编写
主要负责数据存储、查询计划的执行
BE、FE尽可能不要混合部署，争抢资源
一台服务器尽可能只部署一个BE
集群的性能与 BE 节点的资源有关，BE 节点越多，Doris 性能越好。通常情况下在 10 - 100 台机器上可以充分发挥 Doris 的性能
部署建议
BE
Java编写
主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作
一台服务器尽可能只部署一个FE
FE
通常情况下可以将 Broker 节点与 FE / BE 节点部署在同一台机器上
Broker
三大组件
建议内存至少是 CPU 核数的 4 倍，8倍更佳
内存
大规模数据量，高并发点查，高频数据更新场景选用SSD
存储
万兆网卡
网卡
硬件
默认
保留明细数据
建议选择前2-4列作为Duplicate Key
明细模型 duplicate
保证主键唯一，新写入的数据会覆盖具有相同 key（主键）的旧数据
写入性能好
查询性能差
内存消耗高
读时合并 (merge-on-read)
1.2引入
开启参数：enable_unique_key_merge_on_write
2.1成为unique的默认实现
写时合并 (merge-on-write)
两种实现方式
主键模型 unique
SUM
在同一个导入批次中的数据，对于 REPLACE 这种聚合方式，替换顺序不做保证，而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次
REPLACE
MAX
MIN
在同一个导入批次中的数据，对于 REPLACE_IF_NOT_NULL 这种聚合方式，替换顺序不做保证，而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次
REPLACE_IF_NOT_NULL
HLL_UNION
BITMAP_UNION
AggregationType
每一批次数据导入的 ETL 阶段。该阶段会在每一批次导入的数据内部进行聚合。
底层 BE 进行数据 Compaction 的阶段。该阶段，BE 会对已导入的不同批次的数据进行进一步的聚合。
数据查询阶段。在数据查询时，对于查询涉及到的数据，会进行对应的聚合。
数据聚合发生在三个阶段
聚合模型 aggregate
Key 列必须在所有 Value 列之前
尽量选择整型类型
在查询引擎中加入了聚合算子，来保证数据对外的一致性（可能BE还没有完全完成数据的预聚合）
增加一个值恒为 1 的，聚合类型为 SUM 的列来模拟COUNT
增加一个值恒为 1 的，聚合类型为 REPLACE 的列来模拟COUNT
两个建议
聚合模型下，慎用COUNT
查询性能
注意SQL语义
聚合模型的局限性
Duplicate 模型，表的 Key 列，可以认为只是 \"排序列\"，并非起到唯一标识的作用
Aggregate、Unique 模型这种聚合类型的表，Key 列是兼顾 \"排序列\" 和 \"唯一标识列\"，是真正意义上的 \"Key 列\"
Key的不同含义
使用注意
通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景
对 count(*) 查询很不友好
需要考虑语义正确性
Aggregate
需要唯一主键约束的场景
无法利用预聚合带来的查询优势
建议使用写时合并
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表的一致性
自动选择最佳的物化视图进行查询
优势
物化视图
Hash Join
Nest loop Join
两种物理算子
把右表的全量数据都发送到左表，即每一个参与 Join 的节点，都拥有右表全量的数据
Broadcast Join
左右表根据JOIN列，将数据发送到不同的节点上
Shuffle Join
JOIN列是左表的分桶列， 右表根据JOIN列，将数据发送到左表
Bucket Shuffle Join
条件最为苛刻，在创建表的时候就指定，提前做好了数据的Shuffle
Colocation Group（CG）
Colocation Group Schema（CGS）
两个专业名词
创建表 使用 colocate_with 声明 CG
JOIN列就是分桶列
分桶列的类型和数量完全一致
所有分区（Partition）的副本数必须一致
苛刻的条件
Colocate
四种JOIN方式
场景：大表JOIN小表
效果明显、快速
只适用于BroadCast
右表超过一定的数量（1024）就失败
IN
通用
计算成本较高
BloomFilter
仅对数值列有效
MinMax
可以组合，默认是IN+BloomFilter
三方优化方式
Runtime Filter优化
简单类型、同类型做关联
大表之间的JSON尽可能Colocation
合理的使用 Runtime Filter
尽量保持左表为大表，右表为小表
必要时，使用Hint
调优建议
JOIN
开启行存：\"store_row_column\" = \"true\"
如果是unqiue，开启enable_unique_key_merge_on_write
开启light_schema_change
建议使用\"row_store_columns\"=\
使用 PreparedStatement，在连接字符串设置：jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true
开启行缓存：disable_storage_row_cache，row_cache_mem_limit指定 Row cache 占用内存的百分比
增加 Observer 数量
手段
只支持单表 key 列等值查询，且查询中不能包含 join，嵌套子查询
高并发点查
表中需要建立一个分桶列，分桶列与需要精确去重的列是有关系的
分桶字段的基数至少是BUCKETS数的5倍以上
无法用于分区表
bitmap精确去重
极大似然估算
伯努利试验
两个理论
需要近似去重的列数据类型的hll，聚合函数是hll_union
HLL近似去重
高效去重
进阶
Doris 2.1
0 条评论
回复 删除
下一页
