ClickHouse - 你没有见过的列存储 | 青训营笔记

乌云暮年
472 阅读14分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 18 天

前言

这是我将参加青训营期间的收获进行整理和总结，同时便于日后复习和查阅。如果能给各位小伙伴提供些帮助，也是我的荣幸，希望大家可以多多赐教，一起学习和交流。

ClickHouse最初是为 YandexMetrica 世界第二大Web分析平台 而开发的。多年来一直作为该系统的核心组件被该系统持续使用着。而Yandex.Metrica是基于用户定义的字段，对实时访问、连接会话，生成实时的统计报表。在Yandex.Metrica中，ClickHouse被用于多个场景中。 它的主要任务是使用原始数据在线的提供各种数据报告。它使用374台服务器的集群，存储了20.3万亿行的数据。在去除重复与副本数据的情况下，压缩后的数据达到了2PB。未压缩前（TSV格式）它大概有17PB。

本篇文章主要内容

  • 数据库基本概念
  • 列式存储
  • ClickHouse 存储设计
  • ClickHouse 典型应用场景

数据库基本概念

数据库是结构化信息或数据的有序集合，一般以电子形式存储在计算机系统中。通常由数据库管理系统（DBMS）来控制。在现实中，数据、DBMS即关联应用一起被称为数据库系统，通常简称为数据库。

一个简单的例子

1.数据解析整理成有序集合。 例1.png

2.数据的写入和读取，可以通过查询语言获取想要的信息 例2.png

数据库类型

  • 关系数据库： 关系型数据库是把数据以表的形式进行储存，然后再各个表之间建立关系，通过这些表之间的关系来操作不同表之间的数据。
  • 非关系数据库： NoSQL 或非关系数据库，支持存储和操作非结构化及半结构化数据。相比于关系型数据库，NoSQL没有固定的表结构，且数据之间不存在表与表之间的关系，数据之间可以是独立的。NoSQL的关键是它们放弃了传统关系型数据库的强事务保证和关系模型，通过所谓最终一致性和非关系数据模型（例如键值对，图，文档）来提高Web应用所注重的高可用性和可扩展性。
  • 单机数据库： 在一台计算机上完成数据的存储和查询的数据库系统。
  • 分布式数据库： 分布式数据库由位于不同站点的两个或多个文件组成。数据库可以存储在多台计算机上，位于同一个物理位置，或分散在不同的网络上。
  • OLTP 数据库： OLTP（Online transactional processing）数据库是一种高速分析数据库，专为多个用户执行大量事务而设计。
  • OLAP 数据库： OLAP (Online analytical processing) 数据库旨在同时分析多个数据维度，帮助团队更好地理解其数据中的复杂关系。

OLAP数据库

  • 大量数据的读写，PB级别的存储。
  • 多维分析，复杂的聚合函数。
  • 窗口函数，自定义UDF（User Define Fucntion）
  • 离线/实时分析
select inventory, count(), avg(price), countDistinct(prod_name), max(discount)
from table_product
where category = 'xxxxxx '
group by inventory;

select inventory, quantile(0.9)(price) from table_product;

select
	categroy, 
	groupArray(inventory) over (partition by prod_place order by price)
from table_product;

OLAP数据库.png

SQL

一种编程语言，目前几乎所有的关系数据库都是用 SQL (Structured Query Language) 编程语言来查询、操作和定义数据、进行数据访问控制。

  • 一个简单的SQL查询包含SELECT关键词。星号("*")也可以用来指定查询，应当返回查询表所有字段可选的关键词和子句。
  • FROM子句指定了选择的数据表。FROM子句也可以包含JOIN二层子句来为数据表的连接设置规则。
  • WHERE子句后接一个比较谓词以限制返回的行。WHERE子句仅保留返回结果里使得比较谓词的值为True的行。
  • GROUP BY子句用于将若干含有相同值的行合并GROUP BY通常与SOL聚合函数连用，或者用于清除数据重复的行。GROUP BY子句要用在WHERE子句之后。

SQL的用途

  1. 定义数据模型
CREATE TABLE default.test_insert_local
(
	`p_date` Date,
    `id` Int32
)
ENGINE = MergeTree
PARTITION BY p_date
ORDER BY id
SETTINGS index_granularity = 8192
  1. 读写数据库数据
insert into default.test_insert_local values ('2022-01-01', 1);
select count() from default.test_insert_local;

SQL的优点

  1. 标准化，ISO和ANSI是长期建立使用的SQL数据库标准。
  2. 高度非过程化，用SQL进行数据操作，用户只需提出“ 做什么”，而不必指明“怎么做”，因此用户无须了解存取路径，存取路径的选择以及SOL语句的操作过程由系统自动完成。这不但大大减轻了用户负担，而且有利于提高数据独立性。
  3. 以同一种语法结构提供两种使用方式，用户可以在终端上直接输入SOL命令对数据库进行操作。作为嵌入式语言，SOL语句能够嵌入到高级语言 (如C、C#、JAVA) 程序中，供程序员设计程序时使用。而在两种不同的使用方式下，SOL的语法结构基本上是一致的。
  4. 语言简洁，易学易用: SOL功能极强，但由于设计巧妙，语言十分简洁，完成数据定义、数据操纵、数据控制的核心功能只用了9个动词: CREATE、ALTER、DROP、SELECT、INSERT.UPDATE、DELETE、GRANT、REVOKE。且SOL语言语法简单，接近英语口语，因此容易学习，也容易使用。

数据库架构

数据库架构.png

  1. Client
  2. Parser：词法分析，语法分析，生成AST树（Abstract syntax tree）
  3. Analyzer：变量绑定、类型推导、语义检查、安全、权限检查、完整性检查等，为生成计划做准备。
  4. Optimizer：为查询生产性能最优的执行计划，进行代价评估。
  5. Executor：将执行计划翻译成可执行的物理计划并驱动其执行。

存储引擎

  • 管理内存数据结构【索引、内存数据、缓存】
    • Query cache
    • Datacache
    • Index cache
  • 管理磁盘数据
    • 磁盘数据的文件格式
    • 磁盘数据的增删查改
  • 读写算子
    • 数据写入逻辑
    • 数据读取逻辑

列式存储

行式存储： 行式存储.gif

列式存储： 列式存储.gif

列存的优点

数据压缩

  • 数据压缩可以使读的数据量更少，在IO密集型计算中获得更大的性能优势
  • 相同类型压缩效率更高
  • 排序之后压缩效率更高
  • 可以针对不同类型使用不同的压缩算法

【LZ4】

输入：abcde_bcdefgh_abcdefghxxxxxxx
输出：abcde_(5,4)fgh_(14,5)fghxxxxxxx

（5，4）代表向前5个byte，匹配到的内容长度有4，即”bcde“是一个重复。

重复项越多或者越长，压缩率就会越高。

【Run-length encoding】

输入：WWWWWWWWWWWWBWWWWWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWWBWWWWWWWWWWWWWW
输出：12W1B12W3B24W1B14W

压缩重复的数据

【Delta encoding】

输入：105, 135, 112, 135, 143, 147
输出：105(base),30, -23, 23, 8, 4

将数据存储为连续数据之间的差异，而不是直接存储数据本身

数据处理

【查询优化】1.可以选择特定的列做计算而不是都所有列 2.对聚合计算友好 查询优化.png

【延迟物化】

  • 物化：将列数据转换为可以被计算或者输出的行数据或者内存数据结果的过程，物化后的数据通常可以用来做数据过滤，聚合计算，Join。 物化.png

  • 延迟物化：尽可能推迟物化操作的发生。 延迟物化.png

  • 缓存友好

  • CPU / 内存带宽友好

  • 可以利用到执行计划和算子的优化，例如filter

  • 保留直接在压缩列做计算的机会

【向量化】

  • SIMD(single instruction multiple data)对于现代多核CPU，其都有能力用一条指令执行多条数据。

    for (size_t i = 0; i < 100; ++i) 
 c[i] = a[i] + b[i];

非向量化执行

c[0] = a[0] + b[0]; 
c[1] = a[1] + b[1];
... ...

指令集.png 数据格式要求：

  • 需要处理多个数据，因此数据需要是连续内存；需要明确数据类型。

执行模型要求：

  • 数据需要批次读取；函数的调用需要明确数据类型。
vec<int> sel_eq_string(vec<string> col, string o)
  vec<int> res;
  for(int i=0;i<col.size(); i++) // for colors
    if(col[i] == o) // compare color
       res.append(i) // remember position
  return res

vec<int> sel_eq_int(vec<int> tir, int o, vec<int> s)
  vec<int> res;
  for(i : s) // for remembered position
    if(tir[i] == o) // compare tires
       res.append(i) // add to final result
  return res
  • 列存数据库适合设计出这样的执行模型，从而使用向量化技术。

列存 VS 行存

行存列存
优点数据被保存在一起。INSERT/UPDATE容易查询时只有涉及到的列会被读取。投影（Projection）很高效。任何列都能作为索引。便于做延迟物化和向量化计算。压缩效率高，每一列可以使用不同的压缩算法。
缺点选择（Selection）时即使只涉及某几列，所有数据也都会被读取。选择完成时，被选择的列要重新组装。INSERT/UPDATE比较麻烦。点查询不适合。
使用场景点查询（返回记录少，基于索引的简单查询）。增、删、改操作较多的场景。统计分析类查询（OLAP，比如数据仓库业务，此类型的表上会做大量的汇聚计算，且涉及的列操作较少，关联、分组操作较多）。及时查询（查询条件不确定，行存表扫描难以使用索引）。

CilckHouse 存储设计

  1. 架构图 架构图.png
  2. 表定义和结构
  • 分布式表：不存储数据，用于将查询路由到集群的各个节点
    • cluster：逻辑集群，有多个结点组成
    • shard_key：知道数据写入分布式表时的分布方式
  • 本地表：实际存储数据的表
CREATE TABLE [IF NOT EXISTS] [db.]table_name
[ON CLUSTER cluster]
{
	name1 [typel] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
	name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
	...
	INDEX index_namel expr1 TYPE type1(...) GRANULARITY value1,
	INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
} ENGINE = MergeTree()
ORDER BY expr
	[PARTITION BY expr]
	[PRITARTRET KEY expr]
	[SAMPLE BY expr]
	[TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
	[SETTINGS name=value, ...]
  1. 集群架构 集群架构.png

ClickHouse 的存储架构

数据结构

  1. 文件组织 文件组织.png
  2. 文件内容

表

CREATE TABLE test.test_insert_local
(
    `p_date` Date,
    `id` Int32
)
ENGINE = MergeTree
PARTITION BY p_date
ORDER BY id
SETTINGS index_granularity = 8192

文件组织

├── 20220101_1_1_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   ├── minmax_p_date.idx
│   ├── partition.dat
│   ├── primary.idx
│   └── versions.txt
├── 20220102_2_2_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   ├── minmax_p_date.idx
│   ├── partition.dat
│   ├── primary.idx
│   └── versions.txt
├── detached
└── format_version.txt
  1. part 和 partition
    • part 是物理文件夹的名字
    • partition 是逻辑结构
  2. part 和 column
    • 每个 column 都是一个文件
    • 所有的 column 文件都在自己的 part 文件夹下
  3. column 和 index
    • 一个 part 有一个主键索引
    • 每个column 都有列索引

索引设计

Hash Index Hash Index.png

  1. 将输入的Key通过一个HashFunction映射到一组bucket上
  2. 每个 bucket 都包含一个指向一条记录的地址
  3. 哈希索引在查找的时候只适用于等值比较

B - Tree B-Tree.png

  1. 数据写入是有序的，支持增删改查
  2. 每个节点有多个孩子节点
  3. 每个节点都按照升序排列key值
  4. 每个key有两个指向左右孩子节点的引用
    • 左孩子节点保存的key都小于当前的key
    • 右孩子节点的保存的key都大于当前key

B + Tree B+Tree.png

  1. 所有的数据都存储在叶子节点，非叶子节点只保存key值
  2. 叶子节点维护到相邻叶子节点的引用
  3. 可以通过key值做二分法查找，也可以通过叶子节点做顺序访问。

Log-structured merge - tree（LSM tree）是一种为大吞吐写入场景而设计的数据结构。

  • 着重优化顺序写入
  • 主要数据结构
    • SSTables
    • Memtable

SSTables 索引设计 - SSTables.png

  1. Key 按顺序存储到文件中，称为 segment
  2. 包含多个 segment
  3. 每个 segment 写入磁盘后都是不可更改的，新加的数据只能生成新的 segment

Memtable 索引设计 - Compation.png

  • 在内存中的数据保存在 memtable 中，大多数实现都是一颗Binary search tree
  • 当 memtable 存储的数据到达一定的阈值的时候，就会按顺序写入到磁盘。

Compaction（合并）

  • Compaction 指将多个 segments 合并成一个 segments 的过程。
  • 一般是有一个后台线程完成
  • 不同的 segments 写入新的 segment 的时候也是需要排序，形成新的 segment 之后，旧的 segment 文件会被删除。

索引实现

  1. 主键索引
CREATE TABLE hits_UserID_URL
(
    `UserID` UInt32,
    `URL` String,
    `EventTime` DateTime
)
ENGINE = MergeTree
PRIMARY KEY (UserID, URL)
ORDER BY (UserID, URL, EventTime)
SETTINGS index_granularity = 8192, index_granularity_bytes = 0;

  1. 数据按照主键顺序一次排序 UserID首先做排序,然后是URL,最后是EventTime。 索引实现2.png

  2. 数据被组织成granule

  • granule是引擎做数据处理的最小数据单位，引擎读数据的时候不是按照一行一行读取的，而是最少读取一个granule。
  • 方便构建稀疏索引。
  • 方便并行计算。 索引实现3.png
  1. 每个granule都对应primary.idx里面的一行 索引实现4.png

5 默认每8192行记录主键的一行值，primary.idx需要被全部加载到内存里面 索引实现5.png

  1. 每个主键的一行数据被称为一个mark 索引实现6.png

  2. 每个列都有这样一个mark文件，mark文件存储所有granule在物理文件里面的地址，每一列都有一个mark文件 索引实现7.png

  3. mark文件里面的每一行存储两个地址

  • 第一个地址称为block_offset，用于定位一个granule的压缩数据在物理文件中的位置，压缩数据会以一个block为单位解压到内存中。
  • 第二个地址称为granule_offset，用于定位一个granule在解压之后的block中的位置。

索引的缺陷和优化

  1. 缺陷：数据按照key的顺序做排序，因此只有第一个key的过滤效果好，后面的key过滤效果依赖第一个key的基数大小。 缺陷和优化1.png

  2. 二级索引

  • 在URL列上构建二级索引 缺陷和优化2.png
  1. 构建多个主键索引

  • 再建一个表(数据需要同步两份,查询需要用户判断查哪张表) 缺陷和优化3.png

  • 建一个物化视图(数据自动同步到隐式表,查询需要用户判断查哪张表) 缺陷和优化4.png

  • 使用Projection(数据自动同步到隐式表,查询自动路由到最优的表) 缺陷和优化5.png

小结：

  • 主键包含的数据顺序写入
  • 主键构造一个主键索引
  • 每个列构建一个稀疏索引
  • 通过mark的选择让主键索引可以定位到每一列的索引
  • 可以通过多种手段优化非主键列的索引

数据合并

数据合并.png

数据的可见性

  1. 数据合并过程中，未被合并的数据对查询可见。
  2. 数据合并完成后，新part可见，被合并的part被标记删除。

数据查询

  1. 通过主键找到需要读的mark。

    SELECT
	URL,
	count(URL) AS Count
FROM hits_UserID_URL
WHERE USERID = 749927693
GROUP BY URL
ORDER BY Count DESC
LIMIT 10

  2. 切分marks，然后并发的调度reader。 数据查询2.png

  3. Reader 通过 mark block_offset 得到需要读得数据文件的偏移量。

  4. Reader 通过 mark granule_offset 得到解压之后数据的偏移量。 数据查询3.png

  5. 构建列式filter做数据过滤 数据查询4.png

ClickHouse应用场景

大宽表存储和查询

  1. 动态表结构
    • map 中的每个key都是一列。
    • map中的每一列都可以单独的查询。
    • 使用方式同普通列，可以做任何计算。
CREATE TABLE test_multi_columns
(
    `p_date` Date,
    `id` Int32,
    `map_a` Map(String, Int32)
)
ENGINE = MergeTree
PARTITION BY p_date
ORDER BY map_a

大宽表1.png 2. 大宽表查询

  • 可以建非常多的列。
  • 可以增加、删除、清空每一列的数据。
  • 查询的时候引擎可以快速选择需要的列。
  • 可以将列涉及到的过滤条件下推到存储层从而加速查询。

离线数据分析

  1. 数据导入 离线数据1.png

    • 数据可以通过spark生成clickhouse格式的文件。
    • 导入到 hdfs 上由hive2ch 导入工具完成数据导入。
    • 数据直接导入到各个物理节点

  2. 数据按列导入 离线数据2.png

    • 保证查询可以及时访问已有数据
    • 可以按需加载需要的列

实时数据分析

实时数据1.png

  1. 数据可以被立刻查询
  2. 使用memory table减少parts数量
  • 数据先缓存在内存中
  • 到达一定阈值再写到磁盘 实时数据2.png

复杂类型查询

  1. bitmap索引
  • 构建 复杂类型查询1.png
  • 查询 复杂类型查询2.png
  1. bitmap64类型
select countDistinct(uid)
from user_detial
where tag_id = 'a' and uid in 
(
    select uid from user_detail
    wherer tag_id = 'b'
)

复杂类型查询3.png

  1. lowcardinality
  • 对于低基数列使用字典编码
  • 减少数据存储和读写的IO使用
  • 可以做运行时的压缩数据过滤 复杂类型查询4.png

总结

  1. ClickHouse是标准的列存结构
  2. 存储设计是LSM - Tree架构
  3. 使用稀疏索引加速查询
  4. 每个列都有丰富的压缩算法和索引结构
  5. 基于列存设计的高效的数据处理逻辑

引用

  • 字节录播课《ClickHouse - 你没有见过的列存储》
  • ClickHouse
avatar
文章
阅读
粉丝