文章目录

  • 1. 《ClickHouse和Doris之OLAP谁与争锋》课程介绍
  • 1.1. 本次系列课程介绍
  • 1.2. 今日课程大纲
  • 2. ClickHouse 表引擎详解和架构原理
  • 2.1. ClickHouse 设计思想和核心技术特征
  • 2.1.1. ClickHouse 全知全解
  • 2.1.2. ClickHouse 设计思路剖析
  • 2.2. ClickHouse 表引擎详解
  • 2.2.1. ClickHouse 表引擎介绍
  • 2.2.2. MergeTree 引擎工作机制详解



clickhouse 和mongodb 性能对比 clickhouse vs doris_数据

第一天回放链接：https://qcs.h5.xeknow.com/s/37qJd9
第二天回放链接：https://qcs.h5.xeknow.com/s/2OKW31
第三天回放链接：https://qcs.h5.xeknow.com/s/16gFJS

  1. 架构设计篇：实时OLAP处理引擎 ClickHouse架构体系深入剖析篇
  2. 核心技术篇：实时OLAP处理引擎核心技术深入剖析篇
  3. 应用实践篇：实时OLAP处理引擎企业大数据应用实践篇

注意：本文档非原创，来源于上面视频课程的课件。只做学习使用，如有侵权，请告知删除，谢谢！

1. 《ClickHouse和Doris之OLAP谁与争锋》课程介绍

1.1. 本次系列课程介绍

OLAP 之 ClickHouse 和 Doris 谁与争锋？ClickHouse 和 Doris 深度大 PK ？

  • 首次完整揭秘 ClickHouse 核心特性，知其然，知其所以然
  • 彻底揭秘千亿级企业 ClickHouse 实时处理引擎架构设计、核心技术设计、运行机理全流程;
  • 彻底揭秘千亿级企业 ClickHouse 在企业大数据业务场景下的应用实践;
  • Doris 源码核心作者揭秘 Doris 架构设计核心原理;
  • 首次全方位深度对比 ClickHouse 和 Doris 两大 OLAP 利器。

1.2. 今日课程大纲

今天主要的内容，是跟大家交付，关于 ClickHouse 如何做查询分析那么快的原因原理分析。咱们先从探讨，一款高效的 OLAP 系统组件的核心技术应该有哪些？然后 ClickHouse 实现了那些？最终的工作流程是怎样的？

  • ClickHouse 全知全解
  • ClickHouse 设计思路和核心特性剖析
  • ClickHouse 表引擎详解
  • ClickHouse 工作原理（数据分区，一级索引，二级索引，数据压缩，数据标记，数据查询）

2. ClickHouse 表引擎详解和架构原理

2.1. ClickHouse 设计思想和核心技术特征

2.1.1. ClickHouse 全知全解

ClickHouse 是一个用于联机分析 (OLAP) 的列式数据库管理系统 (DBMS)。来自于 2011 年在纳斯达克上市的俄罗斯本土搜索引擎企业 Yandex 公司，诞生之初就是为了服务 Yandex 公司自家的 Web 流量分析产品 Yandex.Metrica，后来经过演变，逐渐形成为现在的 ClickHouse，全称是：Click Stream, Data WareHouse。

ClickHouse 官网：点我，它具有 ROLAP、在线实时查询、完整的 DBMS 功能支持、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的 SQL 支持和函数、支持高可用、不依赖 Hadoop 复杂生态、开箱即用等许多特点。

在 1 亿数据集体量的情况下，ClickHouse 的平均响应速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的429 倍以及Greenplum 的 10 倍。详细的测试结果可以查阅：https://clickhouse.tech/benchmark/dbms/。

ClickHouse 非常适用于商业智能领域（也就是我们所说的 BI 领域），除此之外，它也能够被广泛应用于广告流量、Web、App 流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。

  • 今日头条内部用 ClickHouse 来做用户行为分析，内部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据300TB 左右。
  • 腾讯内部用 ClickHouse 做游戏数据分析，并且为之建立了一整套监控运维体系。
  • 携程内部从 18 年 7 月份开始接入试用，目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查询请求。
  • 快手内部也在使用 ClickHouse，存储总量大约 10PB， 每天新增 200TB， 90% 查询小于 3S。

ClickHouse 缺点：

1、没有完整的事务支持
2、稀疏索引导致 ClickHouse 不擅长细粒度或者 key-value 类型数据的查询需求
3、缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据
4、不擅长 join 操作

第三天中讲解 Doris 的时候，会告诉大家： Doris 跟 CK 最大的区别是： Doris 对于 Join 有专门的解决方案

2.1.2. ClickHouse 设计思路剖析

头脑风暴：如果是你，你怎么去设计一个 OLAP 的技术？海量数据集中

关于 OLTP 系统和 OLAP 系统的核心设计思想和技术路线有哪些呢？我们做一个完整的探讨。

数据存储系统的关于查询的典型操作：

-- 第一种需求： 根据 key（1） 找 value（name,age）， 单点查询
select name, age from student where id = 1;

-- 第二种需求： 根据 department 统计平均年龄， 全表查询
select name, age from student where age > 30;
select department, avg(age) from student group by department;

如果：第一种需求多

如果数据量小，并且数据是结构化的，使用 MySQL 去存储即可 如果数据量大，不管是不是结构化的，可以转成 key-value 的存储，使用
HBase,Cassandra 等来解决

如果：第二种需求多：

如果数据量小，并且数据是结构化的，使用 MySQL 去存储即可
如果数据量大，不管是不是结构化的，设计一个专门用来做分析的存储计算引擎解决分析的低效率问题

关于如何设计一个 OLTP 存储系统，核心需求是实现海量数据集中的低延时随机读写操作，我们探讨一下它的核心设计思想：

01、数据排序：在海量数据中要想保证低延时的随机读写操作，数据最好是排序的
02、范围分区：当数据排序之后，可以进行范围分区，来平摊负载，让多台服务器联合起来对外提供服务
03、内存 + 磁盘：保证处理效率，也保证数据安全
04、内存：必须经过设计，内存具备优秀的数据结构，保证基本的读写高效，甚至为了不同的需求，可以让读写效率倾斜。
05、写缓存：将为了实现数据有序而进行的低效率随机写转换为内存随机写+磁盘顺序写的方式
06、读缓存：将经常查询的热点数据缓存在内存中，提高查询效率
07、磁盘：数据必须存放在磁盘，保证数据安全。磁盘数据文件必须经过精心设计，保证扫描磁盘数据文件的高效率
08、跳表：基于数据排序+范围分区构建索引表，形成跳表的拓扑结构，方便用户操作时快速定位数据分区的位置
09、LSM-Tree 存储引擎：把随机写变成顺序追加，在通过定期合并的方式来合并数据，去除无效数据，从而实现数据的删除和修改。
10、布隆过滤器：快速判断一个元素（1）是否存在于一个庞大集合内/文件中（100E），常数级别的执行效率！

海量数据中，如果进行高效率的查询的核心思想：设计一种架构，能够快速把待搜寻的数据范围降低到原来的 1/n，然后再结合索引或者热点数据放在内存等思路，就能实现高效率的查询了。

那么一个专门用来做 OLAP 分析的存储引擎该如何设计呢？如何在海量数据中，针对大量数据进行查询分析呢？一些常见的方案和手段如下：

01、数据排序
02、数据分区分片 + 分布式查询
03、列式存储 + 字段类型统一
04、列裁剪
05、预聚合(搜索引擎：输入关键词，搜索引擎根据关键词到 数据库 找到这个 关键词对应的所有的 URL：这些 URL 就是提前计算出来的 )
06、利用CPU特性：向量化引擎，操作系统必须支持
07、主键索引 + 二级索引 + 位图索引 + 布隆索引 等等各种索引技术
08、支持近似计算
09、定制引擎：多样化的存储引擎满足不同场景的特定需要
10、多样化算法选择：Volnitsky高效字符串搜索算法 和 HyperLogLog基于概率高效去重算法

总结一下：单条记录的增删改等操作，通过数据的横向划分，做到数据操作的快速定位，在海量数据查询分析中，一般就是针对某些列做分析，既然并不是全部列，那么把数据做纵向切分把表中的数据按照列来单独存储，那么在做分析的时候，同样可以快速把待查询分析的数据总量降低到原来表的1/n，同样提高效率。

提到预聚合，大家会想到 Kylin，Kylin 是一个把预聚合技术发挥到极致的一个 OLAP 技术，但是 Kylin 也有它的缺点：

1、预聚合只支持固定的分析场景，无法满足自定义分析场景，所以预聚合只能作为一种可选方案
2、维度组合爆炸会导致数据膨胀，这样会造成不必要的计算和存储开销。无必要的维度组合的计算就属于浪费资源
3、大概率数据都是增量生成，预聚合不能进行数据更新。所以会产生大量的重算。

2.2. ClickHouse 表引擎详解

2.2.1. ClickHouse 表引擎介绍

ClickHouse OLAP 类型的数据库： 库 表

MySQL： innodb myisam

表引擎在 ClickHouse 中的作用十分关键，直接决定了数据如何存储和读取、是否支持并发读写、是否支持 index、支持的 query 种类、是否支持主备复制等。

1、数据的存储方式和位置，写到哪里以及从哪里读取数据
2、支持哪些查询以及如何支持。
3、并发数据访问。
4、索引的使用（如果存在）。
5、是否可以执行多线程请求。
6、数据复制参数。

具体可看官网：https://clickhouse.tech/docs/zh/engines/table-engines/

关于 ClickHouse 的底层引擎，其实可以分为 数据库引擎 和 表引擎 两种。在此，我们重点讲解 表引擎。

关于库引擎，简单总结一下：ClickHouse 也支持在创建库的时候，指定库引擎，目前支持 5 种，分别是：Ordinary，Dictionary， Memory， Lazy，MySQL，其实 Ordinary 是默认库引擎，在此类型库引擎下，可以使用任意类型的表引擎。

1、Ordinary引擎：默认引擎，如果不指定数据库引擎创建的就是 Ordinary 数据库
2、Dictionary引擎：此数据库会自动为所有数据字典创建表
3、Memory引擎：所有数据只会保存在内存中，服务重启数据消失，该数据库引擎只能够创建 Memory 引擎表
4、MySQL引擎：改引擎会自动拉取远端 MySQL 中的数据，并在该库下创建 MySQL 表引擎的数据表
5、Lazy延时引擎：在距最近一次访问间隔 expiration_time_in_seconds 时间段内，将表保存在内存中，仅适用于
Log 引擎表

ClickHouse 的表引擎提供了四个系列（Log、MergeTree、Integration、Special）大约 28 种表引擎，各有各的用途。比如 Log 系列用来做小表数据分析，MergeTree 系列用来做大数据量分析，而 Integration 系列则多用于外表数据集成。Log、Special、Integration 系列的表引擎相对来说，应用场景有限，功能简单，应用特殊用途，MergeTree 系列表引擎又和两种特殊表引擎（Replicated，Distributed）正交形成多种具备不同功能的 MergeTree 表引擎。

这是 ClickHouse 的表引擎系列家谱：

clickhouse 和mongodb 性能对比 clickhouse vs doris_大数据_02


MergeTree 作为家族中最基础的表引擎，提供了主键索引、数据分区、数据副本和数据采样等基本能力，而家族中其他的表引擎则在 MergeTree 的基础之上各有所长：

clickhouse 和mongodb 性能对比 clickhouse vs doris_数据_03

2.2.2. MergeTree 引擎工作机制详解

MergeTree 系列是官方主推的存储引擎，支持几乎所有 ClickHouse 核心功能，该系列中，常用的表引擎有：MergeTree、ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree、SummingMergeTree、AggregatingMergeTree 等。学习好 MergeTree 表引擎的工作机制，是应用好 ClickHouse 的最基本基础。

关于 MergeTree 表引擎类型：

  • 原生 MergeTree
  • 第一：MergeTree 表引擎主要用于海量数据分析，支持数据分区、存储有序、主键索引、稀疏索引、数据 TTL 等。MergeTree 支持所有
    ClickHouse SQL 语法，但是有些功能与 MySQL 并不一致，比如在 MergeTree 中主键并不用于去重。
  • 解决去重
  • 第二：为了解决 MergeTree 相同主键无法去重的问题，ClickHouse 提供了 ReplacingMergeTree 引擎，用来做去重。ReplacingMergeTree
    确保数据最终被去重，但是无法保证查询过程中主键不重复。因为相同主键的数据可能被 shard 到不同的节点，但是 compaction 只能在一个
    节点中进行，而且 optimize 的时机也不确定。
  • 解决删除场景
  • 第三：CollapsingMergeTree 引擎要求在建表语句中指定一个标记列 Sign（插入的时候指定为 1，删除的时候指定为 -1），后台
    Compaction 时会将主键相同、Sign 相反的行进行折叠，也即删除。来消除 ReplacingMergeTree 的限制。
  • 第四：为了解决 CollapsingMergeTree 乱序写入情况下无法正常折叠问题，VersionedCollapsingMergeTree 表引擎在建表语句中新增了一
    列 Version，用于在乱序情况下记录状态行与取消行的对应关系。主键相同，且 Version 相同、Sign 相反的行，在 Compaction 时会被删除。
  • 解决聚合场景
  • 第五：ClickHouse 通过 SummingMergeTree 来支持对主键列进行预先聚合。在后台 Compaction 时，会将主键相同的多行进行 sum 求
    和，然后使用一行数据取而代之，从而大幅度降低存储空间占用，提升聚合计算性能。
  • 第六：AggregatingMergeTree 也是预先聚合引擎的一种，用于提升聚合计算的性能。与 SummingMergeTree 的区别在于：
    SummingMergeTree 对非主键列进行 sum 聚合，而 AggregatingMergeTree 则可以指定各种聚合函数。

后面的懒得写了，直接上传了文件，需要的请参考：
下载地址