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

Gerrad
159 阅读15分钟

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

内容来自字节青训营录播：第五届青训营 ClickHouse-你没见过的列存储.pptx、【后端专场 学习资料七】第五届字节跳动青训营 - 掘金

一、本堂课重点内容：

  1. 数据库基本概念
  2. 列式存储
  3. ClickHouse存储设计
  4. ClickHouse典型应用场景

二、详细知识点介绍：

1. 数据库基本概念

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

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

image.png

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

image.png

数据库的类型

按模型来分类：

  • 关系数据库：关系型数据库是把数据以表的形式进行储存，然后再各个表之间建立关系，通过这些表之间的关系来操作不同表之间的数据。
  • 非关系数据库： NoSQL 或非关系数据库，支持存储和操作非结构化及半结构化数据。相比于关系型数据库，NoSQL没有固定的表结构，且数据之间不存在表与表之间的关系，数据之间可以是独立的。NoSQL的关键是它们放弃了传统关系型数据库的强事务保证和关系模型，通过所谓最终一致性和非关系数据模型（例如键值对，图，文档）来提高Web应用所注重的高可用性和可扩展性。

从架构上分类：

  • 单机数据库：在一台计算机上完成数据的存储和查询的数据库系统。
  • 分布式数据库：分布式数据库由位于不同站点的两个或多个文件组成。数据库可以存储在多台计算机上，位于同一个物理位置，或分散在不同的网络上。

从使用场景上看：

  • OLTP 数据库 ：OLTP（Online transactional processing）数据库是一种高速分析数据库，专为多个用户执行大量事务而设计（很多的点查）。
  • OLAP 数据库：OLAP (Online analytical processing) 数据库旨在同时分析多个数据维度，帮助团队更好地理解其数据中的复杂关系。

ClipHouse：关系型、分布式、OLAP数据库

OLAP数据库

  • 大量数据的读写，PB级别的存储（如何加速查询？）
  • 窗口函数，自定义UDF（User Define Function）

image.png

  • 多维分析（通过一条sql就可在多个维度展示指标），复杂的聚合函数

image.png

  • 离线/实时分析（都要对数据的导入/查询进行优化）

SQL

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

SQL的结构：

  查询包含一系列含有最终结果的字段, 紧跟SELECT关键词。星号（"*"）也可以用来指定查询应当返回查询表所有字段，可选的关键词和子句包括：

  • FROM子句指定了选择的数据表。FROM子句也可以包含JOIN 二层子句来为数据表的连接设置规则。
  • WHERE子句后接一个比较谓词以限制返回的行。WHERE子句仅保留返回结果里使得比较谓词的值为True的行。
  • GROUP BY子句用于将若干含有相同值的行合并。 GROUP BY通常与SQL聚合函数连用，或者用于清除数据重复的行。GROUP BY子句要用在WHERE子句之后。
  • HAVING子句后接一个谓词来过滤从GROUP BY子句中获得的结果，由于其作用于GROUP BY子句之上，所以聚合函数也可以放到其谓词中。
  • ORDER BY子句指明将哪个字段用作排序关键字，以及排序顺序(升序/降序)，如果无此子句，那么返回结果的顺序不能保证有序。

image.png

SQL的用途：定义数据模型；读写数据库数据

SQL的优点

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

数据库的架构

image.png

  • Client：解析用户输入的sql，传给server；client包括很多种：自己数据库提供的client产品、业务的代码协议（与server协议兼容）、第三方自己编写的Driver
  • 存储引擎，重点
    • 管理内存数据结构【index、内存数据、缓存（Query cache、Data cache、Index cache）】
    • 管理磁盘数据【磁盘数据的文件格式、磁盘数据的增删查改】
    • 读写算子【数据写入逻辑、数据读取逻辑】

sql的执行流程

image.png

  1. Parser：词法分析，语法分析，生成AST树 (Abstract syntax tree)
  2. Analyzer：变量绑定、类型推导、语义检查、安全、权限检查、完整性检查等，为生成计划做准备
    • 例如:判断a, b是不是类型正确
    • a, b是不是来自表t
    • group by字段是否合法，是否存在聚合函数
  3. Optimizer：为查询生成性能最优的执行计划；进行代价评估

image.png

  1. Executor 将执行计划翻译成可执行的物理计划

image.png

存储引擎

  1. 管理内存数据结构
    • 索引
    • 内存数据
    • 缓存
      • Query cache
      • Data cache
      • Index cache
  2. 管理磁盘数据
    • 磁盘数据的文件格式
    • 磁盘数据的增删查改
  3. 读写算子
    • 数据写入逻辑
    • 数据读取逻辑

问题

  • 如何存储数据?
    • 是否可以并发处理
    • 是否可以构建索引（什么样的数据格式？）
    • 行存，列存或者行列混合存储
  • 如何读写数据?（不同场景在构建底层索引时有不同的考量）
    • 读多写少
    • 读少写多
    • 点查场景
    • 分析型场景

2. 列式存储

列存的优点

a. 数据压缩

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

eg. 【LZ4】、【Run-length encoding】（压缩重复的数据；可在压缩数据上直接计算）、【Delta encoding】（将数据存储为连续数据之间的差异，而不是直接存储数据本身；特定算子也能在压缩数据上直接计算）

b. 数据选择

  1. 可以选择特定的列做计算而不是读所有列
  2. 对聚合计算友好

c. 延迟物化

  • 物化：将列数据转换为可以被计算或者输出的行数据或者内存数据结果的过程（数据格式转换），物化后的数据通常可以用来做数据过滤，聚合计算，Join
  • 延迟物化：尽可能推迟物化操作的发生
    • 缓存友好
    • CPU / 内存带宽友好
    • 可以利用到执行计划和算子的优化，例如filter
    • 保留直接在压缩列做计算的机会

image.png

最后一步再解压c进行计算

image.png

d. 向量化

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

SIMD程序使用的指令集有SSE和AVX系列，AVX有AVX-256和AVX-512，SSE提供128-bits的寄存器，AVX-256提供256-bits，AVX-512提供512bits的寄存器（寄存器越宽，单条指令能处理的数据越大）

image.png

同时处理8位的int

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

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

如果这时候CPU也可以并行的计算我们写的代码，那么理论上我们的处理速度就会是之前代码的100倍，SIMD指令就可以完成这样的工作，用SIMD指令完成的代码设计和执行的逻辑就叫做向量化

  • 数据格式要求:
    • 需要处理多个数据，因此数据需要是连续内存
    • 需要明确数据类型
  • 执行模型
    • 数据需要按批读取
    • 函数的调用需要明确数据类型

列存数据库适合设计出这样的执行模型，从而使用向量化技术:

  • 按列读取
  • 每种列类型定义数据读写逻辑
  • 函数按列类型处理

列存 VS 行存

image.png

3. ClickHouse存储设计

表定义和结构

image.png

集群架构

image.png

  • 右图Replica 互为备份；Shard 分为不同组
  • 右图local_table 实际存储的表；distributed_table 面向用户的表
  • 左图distributed_table要选择去查哪个副本

引擎架构

image.png

存储架构

image.png

底层part分布格式：

image.png

part和partition

  • part是物理文件夹的名字
  • partition是逻辑结构

image.png

part和column

  • 每个column都是一个文件
  • 所有的column文件都在自己的part文件夹下

column和index

  • 一个part有一个主键索引
  • 每个column都有列索引

索引设计

Hash Index

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

B-Tree

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

image.png

B+Tree

  1. 所有的数据都存储在叶子节点，非叶子节点只保存key值（只是值的索引和指向叶子的信息，节省空间，树能够更深）
  2. 叶子节点维护到相邻叶子节点的引用
  3. 可以通过key值做二分查找，也可以通过叶子节点做顺序访问

image.png

对于ClickHouse来说：

  • 对于大数据量，B(B+)-Tree深度太高
  • 索引数据量太大，多个列如何平衡查询和存储
  • OLAP场景写入量非常大，（而B/B+ Tree是一颗排序树）如何优化写入

—— LSM-Tree

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

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

SSTables

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

Memtable

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

数据查询

  • 需要从最新的segment开始遍历每个key
  • 也可以为每个segment建一个索引，例如

二分查找稀疏索引 image.png

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. 数据被组织成granule
    • granule是引擎做数据处理的最小数据单位，引擎读数据的时候不是按照一行一行读取的，而是最少读取一个granule
    • 方便构建稀疏索引
    • 方便并行计算
  3. 每个granule都对应primary.idx里面的一行
  4. 默认每8192行记录主键的一行值，primary.idx需要被全部加载到内存里面
  5. 每个主键的一行数据被称为一个index mark
  6. 每个列都有这样一个mark文件，mark文件存储所有granule在物理文件里面的地址，每一列都有一个mark文件
  7. mark文件里面的每一行存储两个地址
    • 第一个地址称为block_offset，用于定位一个granule的压缩数据在物理文件中的位置，压缩数据会以一个block为单位解压到内存中。
    • 第二个地址称为granule_offset，用于定位一个granule在解压之后的block中的位置。

 索引的缺陷和优化

  1. 缺陷：数据按照key的顺序做排序，因此只有第一个key的过滤效果好，后面的key过滤效果依赖第一个key的基数大小（第二个bin就不是有序的，这种稀疏索引高度依赖于第一个key）如何解决：？
    • 二级索引 secondary index ： 在URL列上构建二级索引
    • 构建多个主键索引
      • 再建一个表(数据需要同步两份,查询需要用户判断查哪张表)
      • 建一个物化视图(数据自动同步到隐式表,查询需要用户判断查哪张表)
      • 使用Projection(数据自动同步到隐式表,查询自动路由到最优的表)

小结:

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

数据合并

image.png

数据的可见性

  • 数据合并过程中，未被合并的数据对查询可见（被持有）。完成后不可见
  • 数据合并完成后，新part可见，被合并的part被标记删除

数据查询

SELECT
    URL,
    count(URL) AS Count
FROM hits_UserID_URL
WHERE UserID = 749927693
GROUP BY URL
ORDER BY Count DESC
LIMIT 10
  1. 通过主键找到需要读的mark
  2. 切分marks（保证每个mark覆盖的数据是均匀的），然后并发的调度reader
  3. Reader 通过mark block_offset得到需要读的数据文件的偏移量
  4. Reader 通过mark granule_offset得到解压之后数据的偏移量
  5. 构建列式filter做数据过滤

4. ClickHouse典型应用场景

大宽表存储和查询

  1. 大宽表查询
    • 可以建非常多的列
    • 可以增加，删除，清空每一列的数据
    • 查询的时候引擎可以快速选择需要的列
    • 可以将列涉及到的过滤条件下推到存储层从而加速查询
  2. 动态表结构
    • map中的每个key都是一列
    • map中的每一列都可以单独的查询–使用方式同普通列，可以做任何计算

离线数据分析

  1. 数据导入
    • 数据可以通过spark生成clickhouse格式的文件
    • 导入到hdfs上由hive2ch导入工具完成数据导入
    • 数据直接导入到各个物理节点
  2. 数据按列导入
    • 保证查询可以及时访问已有数据
    • 可以按需加载需要的列

实时数据分析

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

复杂类型查询

  1. bitmap索引
  2. bitmap64类型
  3. lowcardinality
    • 对于低基数列使用字典编码
    • 减少数据存储和读写的IO使用
    • 可以做运行时的压缩数据过滤

总结

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