大数据-137 - ClickHouse 集群 表引擎详解2 - MergeTree 存储结构 一级索引 跳数索引

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据-137 - ClickHouse 集群 表引擎详解2 - MergeTree 存储结构 一级索引 跳数索引

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(正在更新···)

章节内容

上节我们完成了如下的内容:


表引擎详解 介绍

日志部分

Log部分

Memory部分

Merge部分

MergeTree

ClickHouse中最强大的表引擎当属 MergeTree(合并树)引擎及该系列(*MergeTree)中的其他引擎。

MergeTree 引擎系列的基本理念如下,当你有巨量数据要插入到表中,你要高效的一批批写入数据片段,并希望这些数据片段在后台按照一定规则合并,相比在插入时不断修改(重写)数据进存储,这种策略会高效很多。


存储结构

创建新表

CREATE TABLE mt_table(date Date, id UInt8, name String) 
ENGINE = MergeTree PARTITION BY toYYYYMM(date) ORDER BY id;

CREATE TABLE mt_table3 (
  `date` Date,
  `id` UInt8,
  `name` String
) ENGINE = MergeTree PARTITION BY toYYYYMM(date) ORDER BY id;

执行的结果如下图所示:

插入数据

INSERT INTO mt_table VALUES ('2024-07-31', 1, 'wzk');
INSERT INTO mt_table VALUES ('2024-07-30', 2, 'icu');
INSERT INTO mt_table VALUES ('2024-07-29', 3, 'wzkicu');

执行结果如下图所示:

查看目录

cd /var/lib/clickhouse/data/default/mt_table
ls

执行结果如下图所示:

我们随便进入一个目录,可以看到:

  • bin 是按列保存数据的文件
  • mrk 保存块偏移量
  • primary.idx 保存主键索引

存储结构

.
├── 202407_1_1_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   ├── minmax_date.idx
│   ├── partition.dat
│   └── primary.idx
├── 202407_2_2_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   ├── minmax_date.idx
│   ├── partition.dat
│   └── primary.idx
├── 202407_3_3_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   ├── minmax_date.idx
│   ├── partition.dat
│   └── primary.idx
├── detached
└── format_version.txt

执行结果如下图所示:

checknums.txt 二进制校验文件,保存了余下文件的大小size和size的hash值,用于快速校验文件的完整和正确性

columns.txt 明文的列信息

date.bin 压缩格式(默认LZ4)的数据文件,保存了原始数据,以列名 bin 命名。

date.mrk2 使用了自适应大小的索引间隔

primary.idx 二进制一级索引文件,在建表的时候通过 order by 或者 primary key 声明稀疏索引。

数据分区

数据是以分区目录的形式组织的,每个分区独立分开存储。这种形式,在数据查询的时候,可以有效的跳过无用的数据文件。


分区规则

分区键的取值,生成分区ID,分区根据ID决定,根据分区键的数据类型不同,分区ID的生成目前有四种规则:


不指定分键

使用整型

使用日期类型 toYYYYMM(date)

使用其他类型

数据在写入的时候,会按照分区ID落入对应的分区。

分区目录生成

BlockNum 是一个全局整型,从1开始,每当新创建一个分区目录,此数字就累加1。

MinBlockNum:最小数据块编号

MaxBlockNum:最大数据块编号

对于一个新的分区,MinBlockNum和MaxBlockNum的值是相同的

分区目录合并

MergeTree 的分区目录在数据写入过程中被创建,不同的批次写入数据属于同一分区,也会生成不同的目录,在之后某个时刻再合并(写入后10-15分钟),合并后的旧分区目录默认8分钟后删除。


同一个分区的多个目录合并以后得命名规则:


MinBlockNum:取同一分区中MinBlockNum值最小的

MaxBlockNum:取同一分区中MaxBlockNum最大的

Level:取同一分区最大的Level值+1

一级索引

稀疏索引

文件:primary.idx

MergeTree的主键使用PrimaryKey定义,主键定义之后,MergeTree会根据index_granularity间隔(默认8192)为数据生成一级索引并保存至primary.idx中,这种方式就是稀疏索引。

简化形式:通过 ORDER BY 指代 主键


primary.idx 文件的一级索引采用稀疏索引。


稠密索引:每一行索引标记对应一行具体的数据记录

稀疏索引:每一行索引标记对应一段数据记录(默认索引粒度是8192)

稀疏索引占用空间小,所以primary.idx内的索引数据常驻内存,取用速度快。


生成规则

primary.idx文件,由于稀疏索引,所以MergeTree要间隔index_granularity行数据才会生成一个索引记录,其他索引值会根据声明的主键字段获取。


查询过程

索引是如何工作的?对primary.idx文件的查询过程


MarkRange: 一小段数据区间,按照 index_granularity的间隔粒度,将一段完整的数据划分成多个小的数据段,小的数据段就是MarkRange

MarkRange与索引编号对应

小案例:


200行数据

index_granularity大小为5

主键ID为int,取值从0开始

共200行数据/5 = 40个MarkRange

假设索引查询 where Id = 3

  • 第一步:形成区间格式 [3,3]
  • 第二步:进行交集 [3,3] ∩ [0, 199]
    以MarkRange的步长大于8分块,进行剪枝:
  • 第三步:合并, MarkRange(start0, end20)

在ClickHouse中,MergeTree引擎表的索引列在建表使用ORDER BY语法来指定。

而在官方中,用了下面一副图来说明。

这张图示出了以 CounterID、Date两列为索引列的情况,即先以CounterID为主要关键字排序,再以Date为次要关键字排序,最后用两列的组合作为索引键。Marks与MarkNumbers就是索引标记,且Marks之间的间隔就由建表时的索引粒度参数index_granularity来制定,默认是8192。


在 ClickHouse 之父Alexey Milovidov分享的PPT中,有更加详细的图示:

这样,每一列都通过ORDER BY列进行了索引,查询时,先查找到数据所在的parts,再通过mrk2文件确定bin文件中数据的范围即可。

不过,ClickHouse的稀疏索引与Kafka的稀疏索引不同,可以由用户自由组合多列,因此也要格外注意不要加入太多索引列,防止索引数据过于稀疏,增大存储和查找成本。另外,基数太小(即区分度太低)的列不适合做索引列,因为很有可能横跨多个mark值仍然相同,没有索引的意义了。


跳数索引

index_granularity 定义了数据的粒度

granularity定义了聚合信息汇总的粒度

granularity定义了一行跳数索引能够跳过多少个index_granularity区间的数据

可用类型

minmax存储指定表达式的极值(如果表达式是tuple,则存储tuple中每个元素的极值),这些信息用于跳过数据块,类似主键

set(max_rows)存储指定表达式的唯一值(不超过max_rows个,max_rows=0则表示无限制)。这些信息可以用于检查 WHERE 表达式是否满足某个数据块

ngrambf_v1 存储包含数据块中所有N元短语的布隆过滤器。只可用于字符串上,用于优化equals、like和in表达式的性能。

tokenbf_v1 跟 ngrambf_v1 类似,不同于ngrams 存储字符串指定长度的所有片段,它只存储被非字母数据字符分割的片段。


相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
10月前
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
684 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
9月前
|
存储 数据采集 监控
阿里云DTS踩坑经验分享系列|SLS同步至ClickHouse集群
作为强大的日志服务引擎,SLS 积累了用户海量的数据。为了实现数据的自由流通,DTS 开发了以 SLS 为源的数据同步插件。目前,该插件已经支持将数据从 SLS 同步到 ClickHouse。通过这条高效的同步链路,客户不仅能够利用 SLS 卓越的数据采集和处理能力,还能够充分发挥 ClickHouse 在数据分析和查询性能方面的优势,帮助企业显著提高数据查询速度,同时有效降低存储成本,从而在数据驱动决策和资源优化配置上取得更大成效。
352 9
|
10月前
|
存储 监控 数据挖掘
【Clikhouse 探秘】ClickHouse 物化视图:加速大数据分析的新利器
ClickHouse 的物化视图是一种特殊表,通过预先计算并存储查询结果,显著提高查询性能,减少资源消耗,适用于实时报表、日志分析、用户行为分析、金融数据分析和物联网数据分析等场景。物化视图的创建、数据插入、更新和一致性保证通过事务机制实现。
1057 14
|
10月前
|
分布式计算 大数据 BI
ClickHouse与大数据生态整合:从ETL到BI报表
【10月更文挑战第27天】在这个数据驱动的时代,企业越来越依赖于数据来做出关键决策。而高效的数据处理和分析能力则是支撑这一需求的基础。作为一位数据工程师,我有幸参与到一个项目中,该项目旨在利用ClickHouse与Hadoop、Spark、Flink等大数据处理框架的整合,构建一个从数据提取(Extract)、转换(Transform)、加载(Load)到最终生成商业智能(BI)报表的全流程解决方案。以下是我在这个项目中的经验和思考。
442 1
|
10月前
|
存储 缓存 大数据
ClickHouse核心概念详解:表引擎与数据模型
【10月更文挑战第26天】在大数据时代,数据处理的速度和效率变得至关重要。ClickHouse,作为一个列式存储数据库系统,以其高效的查询性能和强大的数据处理能力而受到广泛欢迎。本文将从我个人的角度出发,详细介绍ClickHouse的核心概念,特别是其表引擎和数据模型,以及这些特性如何影响数据的存储和查询。
368 1
|
10月前
|
存储 Prometheus 监控
构建高可用性ClickHouse集群:从理论到实践
【10月更文挑战第27天】在数据驱动的时代,构建一个稳定、高效的数据库系统对于企业的业务发展至关重要。作为一名数据工程师,我深知数据库系统的高可用性和可扩展性对于支撑企业应用的重要性。在这篇文章中,我将分享如何构建一个高可用性的ClickHouse集群,从分布式表的设计到数据复制与分片,再到故障恢复机制,确保系统在大规模数据处理中的稳定性和可靠性。
361 0
|
10月前
|
存储 监控 大数据
构建高可用性ClickHouse集群:从单节点到分布式
【10月更文挑战第26天】随着业务的不断增长,单一的数据存储解决方案可能无法满足日益增加的数据处理需求。在大数据时代,数据库的性能、可扩展性和稳定性成为企业关注的重点。ClickHouse 是一个用于联机分析处理(OLAP)的列式数据库管理系统(DBMS),以其卓越的查询性能和高吞吐量而闻名。本文将从我的个人角度出发,分享如何将单节点 ClickHouse 扩展为高可用性的分布式集群,以提升系统的稳定性和可靠性。
999 0
|
11月前
|
SQL 消息中间件 分布式计算
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
330 0
|
2月前
|
存储 监控 分布式数据库
ClickHouse分布式数据库动态伸缩(弹性扩缩容)的实现
实现ClickHouse数据库的动态伸缩需要持续的维护和精细的操作。从集群配置到数据迁移,再到监控和自动化,每一步都要仔细管理以确保服务的可靠性和性能。这些活动可以显著提高应用的响应性和成本效率,帮助业务根据实际需求灵活调整资源分配。
187 10
|
4月前
|
关系型数据库 MySQL 定位技术
MySQL与Clickhouse数据库:探讨日期和时间的加法运算。
这一次的冒险就到这儿,期待你的再次加入,我们一起在数据库的世界中找寻下一个宝藏。
205 9

热门文章

最新文章

推荐镜像

更多