[read]ClickHouse原理解析与应用实践


=Start=

缘由:

之前总是用Hive/Presto做离线分析,现在要用ClickHouse了,之前只是听说过但没用过,不太懂,所以买本书来了解学习一下。

正文:

参考解答:

推荐序一 <*>
推荐序二
推荐序三
推荐序四
推荐序五
赞誉
前言 <*>

第1章 ClickHouse的前世今生 <*>

1.1 传统BI系统之殇
1.2 现代BI系统的新思潮
1.3 OLAP常见架构分类
1.4 OLAP实现技术的演进
1.5 一匹横空出世的黑马
1.5.1 天下武功唯快不破
1.5.2 社区活跃
1.6 ClickHouse的发展历程
1.6.1 顺理成章的MySQL时期
1.6.2 另辟蹊径的Metrage时期
1.6.3 自我突破的OLAPServer时期
1.6.4 水到渠成的ClickHouse时代
1.7 ClickHouse的名称含义
1.8 ClickHouse适用的场景
1.9 ClickHouse不适用的场景
1.10 有谁在使用ClickHouse
1.11 本章小结

第2章 ClickHouse架构概述 <*>

2.1 ClickHouse的核心特性
2.1.1 完备的DBMS功能
2.1.2 列式存储与数据压缩
2.1.3 向量化执行引擎
2.1.4 关系模型与SQL查询
2.1.5 多样化的表引擎
2.1.6 多线程与分布式
2.1.7 多主架构
2.1.8 在线查询
2.1.9 数据分片与分布式查询
2.2 ClickHouse的架构设计
2.2.1 Column与Field
2.2.2 DataType
2.2.3 Block与Block流
2.2.4 Table
2.2.5 Parser与Interpreter
2.2.6 Functions 与Aggregate Functions
2.2.7 Cluster与Replication
2.3 ClickHouse为何如此之快
2.3.1 着眼硬件,先想后做
2.3.2 算法在前,抽象在后
2.3.3 勇于尝鲜,不行就换
2.3.4 特定场景,特殊优化
2.3.5 持续测试,持续改进

2.4 本章小结

第3章 安装与部署

3.1 ClickHouse的安装过程
3.1.1 环境准备
3.1.2 安装ClickHouse
3.2 客户端的访问接口
3.2.1 CLI
3.2.2 JDBC
3.3 内置的实用工具
3.3.1 clickhouse-local
3.3.2 clickhouse-benchmark
3.4 本章小结

第4章 数据定义

4.1 ClickHouse的数据类型
4.1.1 基础类型
4.1.2 复合类型
4.1.3 特殊类型
4.2 如何定义数据表
4.2.1 数据库
4.2.2 数据表
4.2.3 默认值表达式
4.2.4 临时表
4.2.5 分区表
4.2.6 视图
4.3 数据表的基本操作
4.3.1 追加新字段
4.3.2 修改数据类型
4.3.3 修改备注
4.3.4 删除已有字段
4.3.5 移动数据表
4.3.6 清空数据表
4.4 数据分区的基本操作
4.4.1 查询分区信息
4.4.2 删除指定分区
4.4.3 复制分区数据
4.4.4 重置分区数据
4.4.5 卸载与装载分区
4.4.6 备份与还原分区
4.5 分布式DDL执行
4.6 数据的写入
4.7 数据的删除与修改
4.8 本章小结

第5章 数据字典

5.1 内置字典
5.1.1 内置字典配置说明
5.1.2 使用内置字典
5.2 外部扩展字典
5.2.1 准备字典数据
5.2.2 扩展字典配置文件的元素组成
5.2.3 扩展字典的数据结构
5.2.4 扩展字典的类型
5.2.5 扩展字典的数据源
5.2.6 扩展字典的数据更新策略
5.2.7 扩展字典的基本操作
5.3 本章小结

第6章 MergeTree原理解析

6.1 MergeTree的创建方式与存储结构
6.1.1 MergeTree的创建方式
6.1.2 MergeTree的存储结构
6.2 数据分区
6.2.1 数据的分区规则
6.2.2 分区目录的命名规则
6.2.3 分区目录的合并过程
6.3 一级索引
6.3.1 稀疏索引
6.3.2 索引粒度
6.3.3 索引数据的生成规则
6.3.4 索引的查询过程
6.4 二级索引
6.4.1 granularity与index_granularity的关系
6.4.2 跳数索引的类型
6.5 数据存储
6.5.1 各列独立存储
6.5.2 压缩数据块
6.6 数据标记
6.6.1 数据标记的生成规则
6.6.2 数据标记的工作方式
6.7 对于分区、索引、标记和压缩数据的协同总结
6.7.1 写入过程
6.7.2 查询过程
6.7.3 数据标记与压缩数据块的对应关系
6.8 本章小结

第7章 MergeTree系列表引擎

7.1 MergeTree
7.1.1 数据TTL
7.1.2 多路径存储策略
7.2 ReplacingMergeTree
7.3 SummingMergeTree
7.4 AggregatingMergeTree
7.5 CollapsingMergeTree
7.6 VersionedCollapsingMergeTree
7.7 各种MergeTree之间的关系总结
7.7.1 继承关系
7.7.2 组合关系
7.8 本章小结

第8章 其他常见类型表引擎

8.1 外部存储类型
8.1.1 HDFS
8.1.2 MySQL
8.1.3 JDBC
8.1.4 Kafka
8.1.5 File
8.2 内存类型
8.2.1 Memory
8.2.2 Set
8.2.3 Join
8.2.4 Buffer
8.3 日志类型
8.3.1 TinyLog
8.3.2 StripeLog
8.3.3 Log
8.4 接口类型
8.4.1 Merge
8.4.2 Dictionary
8.4.3 Distributed
8.5 其他类型
8.5.1 Live View
8.5.2 Null
8.5.3 URL
8.6 本章小结

第9章 数据查询 <*>

9.1 WITH子句
9.2 FROM子句
9.3 SAMPLE子句
9.4 ARRAY JOIN子句
9.5 JOIN子句
9.5.1 连接精度
9.5.2 连接类型
9.5.3 多表连接
9.5.4 注意事项
9.6 WHERE与PREWHERE子句
9.7 GROUP BY子句
9.7.1 WITH ROLLUP
9.7.2 WITH CUBE
9.7.3 WITH TOTALS
9.8 HAVING子句
9.9 ORDER BY子句
9.10 LIMIT BY子句
9.11 LIMIT子句
9.12 SELECT子句
9.13 DISTINCT子句
9.14 UNION ALL子句
9.15 查看SQL执行计划
9.16 本章小结

第10章 副本与分片

10.1 概述
10.2 数据副本
10.2.1 副本的特点
10.2.2 ZooKeeper的配置方式
10.2.3 副本的定义形式
10.3 ReplicatedMergeTree原理解析
10.3.1 数据结构
10.3.2 副本协同的核心流程
10.4 数据分片
10.4.1 集群的配置方式
10.4.2 基于集群实现分布式DDL
10.5 Distributed原理解析
10.5.1 定义形式
10.5.2 查询的分类
10.5.3 分片规则
10.5.4 分布式写入的核心流程
10.5.5 分布式查询的核心流程
10.6 本章小结

第11章 管理与运维

11.1 用户配置
11.1.1 用户profile
11.1.2 配置约束
11.1.3 用户定义
11.2 权限管理
11.2.1 访问权限
11.2.2 查询权限
11.2.3 数据行级权限
11.3 熔断机制
11.4 数据备份
11.4.1 导出文件备份
11.4.2 通过快照表备份
11.4.3 按分区备份
11.5 服务监控
11.5.1 系统表
11.5.2 查询日志
11.6 本章小结


推荐序一

We released ClickHouse in open-source in 2016, four years ago. And as far as I know, this book is going to be the first published book on ClickHouse. Why do I appreciate that so much? When we released ClickHouse, we had only one goal in mind, to give people the fastest analytical DBMS in the world. But now, after a few years, I see many more opportunities. We can make ClickHouse an example of the most community and developers friendly open-source product.

According to Eric S. Raymond, there are two models of software development:the “Cathedral” and the “Bazaar” model. In the first model, the software is developed by a closed team of a few developers who “do the right thing”. An example of the “Cathedral” model is SQLite that is developed mostly by a single person—Richard Hipp. In contrast, the “Bazaar” model is trying to benefit by invitation of as many independent developers as possible. An example of the “Bazaar” model is the Linux kernel. For ClickHouse, we practice the “Bazaar” model. But this model requires many efforts in building the community. These efforts are summarized in the following 8 points.

According to Eric S. Raymond, there are two models of software development:the “Cathedral” and the “Bazaar” model. In the first model, the software is developed by a closed team of a few developers who “do the right thing”. An example of the “Cathedral” model is SQLite that is developed mostly by a single person—Richard Hipp. In contrast, the “Bazaar” model is trying to benefit by invitation of as many independent developers as possible. An example of the “Bazaar” model is the Linux kernel. For ClickHouse, we practice the “Bazaar” model. But this model requires many efforts in building the community. These efforts are summarized in the following 8 points.

(1)The development process must be as open as possible, no secrets should be kept; we should do everything in public.

(2)The codebase must be well documented and understandable even for amateur developers. And amateur developers should be able to learn good practices from ClickHouse.

(3)We should be eager to try experimental algorithms and libraries, to be on edge and invite more enthusiastic people. As an example, today is 2020, so we are using C++20 language standard.

(4)We should move fast. Try 10 algorithms, throw off 9 of 10, and keep moving forward.

(5)To keep the codebase sane, we should define high-quality standards. And enforce these standards by automated tools in a continuous integration process, not by arguing with people.

(6)We should maintain a high accept rate of contributions. Even if a contribution is not ready, we should actively help each other. Even if the code is wrong, we keep the idea and make it right. Contributors should feel their efforts well received, and they should be proud of their contributions.

(6)We should maintain a high accept rate of contributions. Even if a contribution is not ready, we should actively help each other. Even if the code is wrong, we keep the idea and make it right. Contributors should feel their efforts well received, and they should be proud of their contributions.

(7) ClickHouse is for everyone. You can make a product on top of ClickHouse, and use it in your company, and we will welcome it. We love our users, and we are interested in ClickHouse widespread in any possible way.

(8)We need to provide good tutorials and educational materials for potential contributors. I hope that this book helps people to understand ClickHouse architecture.

The Cathedral model is easier to manage, but the Bazaar model definitely gives more fun!

We can make ClickHouse the best educational and research product in the area of database engineering.

If you look at the architectural details of ClickHouse, you will find that most of them are nothing new. Most of them are already well researched and implemented in some other systems. What’s unique in ClickHouse is the combination of these choices, how well they are integrated together, and the attention to implementation details. There are multiple books on computer science, on managing data, and so on. But you will not find many that describe the internals, the guts, and low-level details that differentiate one system from another. ClickHouse can be considered as a collection of good choices in implementation and also as a playground for experiments. And I hope that this book will guide you through these details.

If you look at the architectural details of ClickHouse, you will find that most of them are nothing new. Most of them are already well researched and implemented in some other systems. What’s unique in ClickHouse is the combination of these choices, how well they are integrated together, and the attention to implementation details. There are multiple books on computer science, on managing data, and so on. But you will not find many that describe the internals, the guts, and low-level details that differentiate one system from another. ClickHouse can be considered as a collection of good choices in implementation and also as a playground for experiments. And I hope that this book will guide you through these details.

ClickHouse should become a standard of good usability among database management systems.

A database management system is not an easy product to develop. And people get used to that it is neither easy to work with. Distributed systems are even harder. Working with a typical distributed system is a painful experience from the start. But we can try to break this stereotype. At least we can eliminate typical obstacles. ClickHouse is easy to set up and run, so you can start working in minutes. But what about further details like data replication, distributed set up, choosing of table engines, and indexes? Couldn’t they be so simple too? Probably not. But at least they can be understandable. This book covers these details, and you will understand what is under the hood of ClickHouse.

Alexey Milovidov
Head of ClickHouse Development Team at Yandex


推荐序一(译文)

我们在2016年发布了ClickHouse的开源版本。据我所知,这本书将是关于ClickHouse的第一本正式出版的图书,对此我非常激动。因为当我们发布ClickHouse的时候,心中只有一个目标,即向人们提供世界上最快的分析型数据库。而现在,我看到了更多的可能性。我们可以把ClickHouse打造成面向社区与开发者的最友好的开源产品。

根据Eric S.Raymond的理论,目前主要有两种软件开发模式——Cathedral(大教堂)模式与Bazaar(集市)模式。在Cathedral模式中,软件由一个封闭的开发者小组进行开发。使用该模式开发的典型产品就是SQLite数据库,它是由Richard Hipp一个人开发的。而Bazaar模式则是邀请尽可能多的独立开发者进行开发,Linux内核就是采用这种模式开发出来的。对ClickHouse而言,我们采用了Bazaar模式。采用Bazaar模式,需要花费很大的精力来维护开发社区。对于在开发ClickHouse的过程中采用Bazaar模式,我总结出了以下8点经验。

(1)整个开发流程完全公开透明,没有任何秘密。

(2)有帮助理解代码的、新手开发者也可看懂的详细文档,这样新手开发者可从ClickHouse代码中学到有价值的实践经验。

(3)乐于尝试新的算法与第三方库,以保持ClickHouse的先进性,也只有这样才能吸引更多的开发热爱者。例如,刚刚进入2020年,我们就在ClickHouse中应用了C++20标准。

(4)虽然需要快速迭代ClickHouse,但是我们依然不会放低要求,比如我们为了使用1个算法,就会至少尝试10个算法。而且在选择了某个算法后,后续还会继续尝试其他更多算法,以便下次迭代时使用。

(5)为了保证代码的质量,我们始终向高标准看齐,并使用工具来确保这些标准得以实施,而不是人为干预。

(6)对于贡献者提交的补丁,我们保证有比较高的接收率。即使某个补丁还没有完成,我们也会适当参与,为贡献者提供帮助。若补丁的代码中有错误,我们会尝试修复。这样补丁的贡献者会感受到他们的努力获得了认可,并因此感到自豪。

(7)ClickHouse是提供给所有人的,你甚至可以用ClickHouse来实现其他产品,也可以把它部署在自己的公司。我们爱我们的用户,我们对ClickHouse在任何场景下的应用都表示支持,并且有兴趣了解你的使用情况。

(8)我们希望为潜在的贡献者提供高质量的教程和参考资料。我很高兴看到这本书上市,因为它能够帮助读者理解ClickHouse的架构。

Cathedral模式便于管理,但是Bazaar模式显然更有意思!我们可以把ClickHouse打造为最适合用于数据库教学与研究的产品。如果细看ClickHouse的架构,你会发现其中没有什么新颖的技术,其中使用的大部分技术都是经过了多年研究并已在其他数据库中实现了的成熟技术。ClickHouse独特的地方在于其高效地将这些技术结合了起来并灵活地加以运用,在此过程中我们十分注重具体的实现方式与细节。许多图书在介绍计算机科学或数据管理的知识时并不会在细节方面进行展开,也不会对不同的系统针对底层实现进行对比,为了对此进行补充,ClickHouse在上述两方面进行了尝试。作为一个比较好的技术实现集合,ClickHouse特别适合用来在细节方面做性能优化实验。我希望这本书能够引导你了解这些技术细节。

ClickHouse可以作为数据库中易用性的代表。数据库系统并不是一款容易开发的产品,这也使得人们认为数据库开发上手很难,分布式数据库的开发就更难了,甚至在刚开始使用分布式系统时会觉得非常烦琐。在开发ClickHouse的过程中,我们尝试打破这些固有的认识,至少扫清了一些常见的障碍。ClickHouse上手非常容易,你可以在几分钟内安装好并开始使用。然而如果你需要使用更多的功能,如数据副本、分布式、不同的表引擎、索引等,就不会那么简单了,但这些功能在理解与学习上相对于其他数据库还是简单的。本书介绍了理解和学习ClickHouse的方法,也介绍了ClickHouse的诸多细节。通过这本书你将会透彻理解ClickHouse是如何运行的。

Alexey Milovidov
Yandex公司ClickHouse开发团队负责人

(郑天祺译)


前言

生生不息,“折腾”不止。为什么新的技术层出不穷,一直会更替变换?因为人们总是乐于追求更加美好的事物,因此业务总会产生新的诉求。

在软件领域,技术与业务犹如一对不可拆分的双轨车道,承载着产品这辆火车稳步向前。一方面,业务的诉求必须得到满足,所以它倒逼技术提升;另一方面,技术的提升又为业务模式带来了新的可能。

第1章 ClickHouse的前世今生

Google于2003~2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”,将大数据的处理技术带进了大众视野。2006年开源项目Hadoop的出现,标志着大数据技术普及的开始,大数据技术真正开始走向普罗大众。

  1. 【IT系统从无到有】得益于IT技术的迅猛发展,各行各业开始置办IT系统以提高效率。
  2. 【烟囱式发展——互不相通】早期发展没考虑太多,多呈烟囱式发展,数据散落在各个独立的系统之内,相互割裂、互不相通。
  3. 【引入数据仓库】为了解决数据孤岛的问题,人们提出了数据仓库的概念。即通过引入一个专门用于分析类场景的数据库,将分散的数据统一汇聚到一处。
  4. 【BI概念的诞生】于20世纪90年代,有人第一次提出了BI(商业智能)系统的概念。自此以后,人们通常用BI一词指代这类分析系统。相对于联机事务处理系统,我们把这类BI系统称为联机分析(OLAP)系统。
  5. 【传统BI系统的设计想法很美好,实际应用场景和效果却有限】原因很多在此不赘述。
  6. 【技术创新让部分想法可落地】2003年起,Google陆续发表的三篇论文开启了大数据的技术普惠,Hadoop生态由此开始一发不可收拾,数据分析开启了新纪元。
  7. 【ClickHouse的横空出世让BI产品的选型又多了一个选择】天下武功唯快不破。

1.8 ClickHouse适用的场景

可以说ClickHouse具备了人们对一款高性能OLAP数据库的美好向往,所以它基本能够胜任各种数据分析类的场景,并且随着数据体量的增大,它的优势也会变得越为明显。

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

1.9 ClickHouse不适用的场景

ClickHouse作为一款高性能OLAP数据库,虽然足够优秀,但也不是万能的。我们不应该把它用于任何OLTP事务性操作的场景,因为它有以下几点不足。

·不支持事务。
·不擅长根据主键按行粒度进行查询(虽然支持),故不应该把ClickHouse当作Key-Value数据库使用。
·不擅长按行删除数据(虽然支持)。

这些弱点并不能视为ClickHouse的缺点,事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言,上述这些能力并不是重点,只能说这是为了极致查询性能所做的权衡。

参考链接:

ClickHouse原理解析与应用实践
https://book.douban.com/subject/35091211/
https://github.com/nauu/clickhousebook

《clickhouse原理解析与应用实践》读书笔记
https://blog.csdn.net/lonelymanontheway/article/details/108181649

https://clickhouse.tech/#quick-start

https://clickhouse.tech/docs/zh/

ClickHouse大数据分析技术与实战
https://www.jianshu.com/p/560bb382f91a

ClickHouse深度解析
https://www.cnblogs.com/zfwwdz/p/13151727.html

=END=


《“[read]ClickHouse原理解析与应用实践”》 有 11 条评论

  1. HDFS+Clickhouse+Spark:从0到1实现一款轻量级大数据分析系统
    https://mp.weixin.qq.com/s/3kk9oGJaoVrcWUONkYk38Q

    基于Clickhouse实现实时聚合计算秒级响应技术方案
    https://mp.weixin.qq.com/s/SKO3iAVJzwwcFyGQFetoYA

    基于ClickHouse + Redash + Python去做安全数据分析
    https://mp.weixin.qq.com/s/O7IuAZV1XuogKwsoLhx4Qw

    干货 | 携程ClickHouse日志分析实践
    https://mp.weixin.qq.com/s/IjOWAPOJXANRQqRAMWXmaw

    实时数仓在滴滴的实践和落地
    https://mp.weixin.qq.com/s/PdxjNQd7SNx1POv6fVKVmA

  2. 阿里云ClickHouse海量数据分析分享
    https://mp.weixin.qq.com/s/MnirNdLxyvrCAPd51SiW6w
    `
    ClickHouse经验分享,我们今天主要分享两个部分:
    * 写入:主要是围绕MergeDataPart这个环节去讲
    * 查询:我们都知道,一个大查询任务,主要消耗的时间就会花在数据加载和计算这两个环节,其他数据库产品也是这样子,他们都会利用一些数据本地性、数据缓存、网络协议、算法的优化等去做一些优化。

    对于ClickHouse我们这块的优化主要有三点:
    * 查询条件带上shard、分区、索引等条件,主要是让他尽可能少的加载数据
    * 业务需求会经常有一些聚合条件,可以通过物化试图提前预聚合好,保存在物化试图内,从而加快查询速度,当然可能会消耗一些内存。
    * 我们的需求会经常查询历史30天以内的sql,展示需要倒着排序,如果我们正序排的话,我们查询出来还得做一次排序计算。
    `

    阿里云数据库ClickHouse核心技术解析
    https://mp.weixin.qq.com/s/_Q1molkIBHeGHGL5p4khNw
    `
    为什么各大互联网都在使用ClickHouse,以及为什么ClickHouse能够在更短的时间取到如此好的成绩呢?我认为在如下几个方面可以找到答案:
    * 大宽表查询性能优异,他的主要分析都是大宽表的sql聚合,ClickHouse整个的聚合耗时都非常小,性能好,并且具有量级的提升
    * 我们在使用中发现ClickHouse单表性能分析以及分区对其的join计算都能取得很好的性能优势。
    `

  3. 浅淡 Apache Kylin 与 ClickHouse 的对比
    https://mp.weixin.qq.com/s/TyeT1JvV1NZRJW5dIiV4zA
    `
    Apache Kylin 和 ClickHouse 都是目前市场流行的大数据 OLAP 引擎;Kylin 最初由 eBay 中国研发中心开发,2014 年开源并贡献给 Apache 软件基金会,凭借着亚秒级查询的能力和超高的并发查询能力,被许多大厂所采用,包括美团,滴滴,携程,贝壳找房,腾讯,58同城等;

    OLAP 领域这两年炙手可热的 ClickHouse,由俄罗斯搜索巨头 Yandex 开发,于2016年开源,典型用户包括字节跳动、新浪、腾讯等知名企业。

    这两种 OLAP 引擎有什么差异,各自有什么优势,如何选择?本文将尝试从技术原理、存储结构、优化方法和优势场景等方面,对比这两种 OLAP 引擎, 为大家的技术选型提供一些参考。

    05 – 总结

    本文就技术原理,存储结构,优化方法及优势场景,对 Kylin 和 ClickHouse 进行了对比。

    技术原理方面:
    ClickHouse 采用 MPP + Shared nothing 架构,查询比较灵活,安装部署和操作简便,由于数据存储在本地,扩容和运维相对较麻烦;
    Kylin 采用 MOLAP 预计算,基于 Hadoop,计算与存储分离(特别是使用 Parquet 存储后)、Shared storage 的架构,更适合场景相对固定但数据体量很大的场景,基于 Hadoop 便于与现有大数据平台融合,也便于水平伸缩(特别是从 HBase 升级为 Spark + Parquet 后)。

    存储结构方面:
    ClickHouse 存储明细数据,特点包括MergeTree 存储结构和稀疏索引,在明细之上可以进一步创建聚合表来加速性能;
    Kylin 采用预聚合以及 HBase 或 Parquet 做存储,物化视图对查询透明,聚合查询非常高效但不支持明细查询。

    优化方法方面:
    ClickHouse 包括分区分片和二级索引等优化手段,
    Kylin 采用聚合组、联合维度、衍生维度、层级维度,以及 rowkey 排序等优化手段

    优势场景方面:
    ClickHouse 通常适合几亿~几十亿量级的灵活查询(更多量级也支持只是集群运维难度会加大)。
    Kylin 则更适合几十亿~百亿以上的相对固定的查询场景。

    综合下来, Kylin 和 ClickHouse 有各种使用的领域和场景 。现代数据分析领域没有一种能适应所有场景的分析引擎。企业需要根据自己的业务场景,选择合适的工具解决具体问题。希望本文能够帮助企业做出合适的技术选型。
    `

  4. 支撑700亿数据量的ClickHouse高可用架构实践
    https://mp.weixin.qq.com/s/vNHFOkG_2j9J2gvQA-fJWw
    `
    以前我认为大数据要给用户提供更好的体验都要靠分布式的大量铺机器才能换得更好的性能,但ClickHouse的出现,改变了我的看法。

    今天也是主要分享我们如何合理的利用好ClickHouse,如何合理的利用硬件资源,根据我们的数据量、应用场景以及合理的架构来支撑我们的数据量和使用场景,为用户提供更好体验的大数据平台。当前根据我们的积累主要是十台物理机的ClickHouse支撑,当然,我也评估过数据量再翻个倍,除了SSD存储空间需要扩容,CPU和内存不会成为我们的瓶颈。

    我今天主要从这几个方面给大家分享一下ClickHouse,为什么选择ClickHouse?我们在实际应用中的一个高可用架构,最后就是给大家介绍ClickHouse的一些优点,还有现在ClickHouse的一些问题和我们对未来的一些展望规划。

    ==
    根据实际业务场景需要来选择
    1、不固定的查询条件,不固定的汇总维度。
    2、数据量日益增量,每天要更新的数据量也不断增大。
    3、业务场景不断增多,涉及面越来越广。
    4、需要保证高可用并秒出。
    5、从SQL、ES、Kylin、Ingite、CrateDB、MongoDB、HBase 不断的研究,实践。

    从上面的一些场景,我们研究了很多数据库。

    最初我们是用SQL,2015年开始做这个平台的时候,其实没有像现在这么多成熟的大数据技术。

    大概2016年,我开始在部分场景应用ES,其实这几年ES在很多公司里面都有应用,大家也应该比较了解,ES在搜索上面有很大的优势,速度也是非常快的。特别是对于做大宽表之类的订单查询、搜索产品信息,ES其实很强,高并发QPS上千基本上没问题。

    Kylin也是大数据方面的,其实它是相当于把时间花在它的机器层面提前算好,但是如果我们的维度不固定,建Cube的时间会非常长。

    Ingite是内存数据库,我在2018年测试过这个数据库,10台虚拟机是8核24G内存,性能确实能做到秒级,但是不能支持高并发,并发上来内存就会被打爆,同比ClickHouse硬件成本是不划算的,完全基于分布式内存,所以我后面也没有用它。

    CrateDB底层是基于ES,但CrateDB解决了ES不能join的问题,但是一样的,在高并发的时候一样会把内存打爆,ES大家应用的时候发现它的语法比较复杂,CrateDB解决了这个问题,我们可以通过写SQL的方式获取数据。

    MongoDB要建一些索引,强依赖左侧原则,当走索引的时候性能确实很好,但我们的搜索条件不固定,无法每次都能靠上索引。

    HBase属于非结构化数据存储的数据库,在实时汇总计算方面也不合适。

    ClickHouse的优点
    1)数据压缩比高,存储成本低。
    2)支持常用的SQL语法,写入速度非常快,适用于大量的数据更新。
    3)依赖稀疏索引,列式存储,CPU/内存的充分利用造就了优秀的计算能力,并且不用考虑左侧原则。

    缺点
    1)不支持事务,没有真正的update/delete
    2)不支持高并发,可以根据实际情况修改qps相关配置文件
    ==

    下面是我对ClickHouse的一些小结
    1、数据导入之前要评估好分区字段。
    2、数据导入提前根据分区做好排序,避免同时写入过多分区导致clickhouse内部来不及Merge。
    3、左右表join的时候要注意数据量的变化。
    4、根据数据量以及应用场景评估是否采用分布式。
    5、监控好服务器的CPU/内存波动。
    6、数据存储磁盘尽量采用SSD。
    7、减少数据中文本信息的冗余存储。
    8、特别适用于数据量大,查询频次可控的场景,如数据分析、埋点日志系统
    `

  5. ClickHouse使用实践与规范
    https://mp.weixin.qq.com/s/dAz5DCGKQbM5Q0QDCHiRqQ
    `
    # ClickHouse应用场景

    1. 写在前面
    (1)如果你的业务预算或机器资源有限,强烈不推荐使用clickhouse,因为这套架构成本比较高。
    (2)最小集群部署所需机器:ck节点需要2台256G内存/40c cpu物理机,磁盘使用SSD,加上3台zookeeper和2台chproxy应用主机或者云主机。
    (3)Clickhouse自带了丰富的功能来应对复杂的业务场景和大数据量,所以在使用期间需要运维和开发侧都投入人力对这些功能(表引擎类型)学习和掌握。

    2. 业务在数据层的表现
    (1)业务大多数是读请求,存储宽表,无大字段,较少的并发(单台100-200qps左右)。
    (2)数据批写入(1000条以上,线上业务建议5w-10w),不修改或少修改已添加的数据。
    (3)无事务要求,对数据一致性要求低。
    (4)对于简单查询,允许延迟大约50毫秒,每一个查询除了一个大表外都很小。
    (5)处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行)。

    3.具体业务场景
    (1)用户行为分析,精细化运营分析:日活,留存率分析,路径分析,有序漏斗转化率分析,Session分析等;
    (2)实时日志分析,监控分析;
    (3)实时数仓。

    # 开发规范

    1. 查询sql编写规范
    (1)当多表联查时,查询的数据仅从其中一张表出时,可考虑使用IN操作而不是JOIN。
    (2)多表查询性能较差,多表Join时要满足小表在右的原则,右表关联时被加载到内存中与左表进行比较,ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在,所以右表必须是小表。
    (3)将一些需要关联分析的业务创建成字典表进行join操作,前提是字典表不宜太大,因为字典表会常驻内存。
    (4)禁⽌业务select * ,列存数据,每减少一个字段会减少大量的数据扫描,提升查询效率。
    (5)建议使用 limit 限制返回数据条数使用limit返回指定的结果集数量,不会进行向下扫描,大大提升了查询效率。
    (6)查询时如果可以建议带上分区键查询,可以有效减少数据扫描量,提升查询效率。
    (7)CK的稀疏索引使得点查询(即kv类型的查询)性能不佳,千万不要把它简单当做关系型数据库进行查询。
    (8)使用Global优化分布式子查询,避免出现查询指数级放大。
    (9)使用 uniqCombined 替代 distinctuniqCombined 对去重进行了优化,通过近似去重提升十倍查询性能。
    (10)尽量不去使用字符串类型,时间类型最终会转换成数值类型进行处理,数值类型在执行效率和存储上远好过字符串。
    (11)ClickHouse的分布式表性能性价比不如物理表高,建表分区字段值不宜过多,防止数据导入过程磁盘可能会被打满。
    (12)不要在唯一列或大基数列上进行分组或去重操作,基数太大会消耗过多的io和内存。
    (13)CPU一般在50%左右会出现查询波动,达到70%会出现大范围的查询超时,CPU是最关键的指标,要非常关注。

    2. 数据写入注意事项
    (1)不适合高并发写入,最好还是从异步化队列写入,batch insert 5w-10w 起步,尽量不要执行单条或插入操作,会产生大量小分区文件,给后台merge任务带来巨大压力。
    (2)几乎完全不支持update/delete,也不支持事务。
    (3)建议表要指定分区键,尤其是数据量大的表,插入/查询/合并都是以分区为单位,合理的分区可以提升整体性能。
    (4)分区不建议太多,如果分区太多,会因需要打开的文件描述符过多导致查询效率不佳。
    (5)数据在写入ClickHouse前预先的对数据进行分组,避免一次插入的数据属于多个分区。
    (6)注意MerTree 主键允许存在重复数据(ReplacingMergeTree可以在分区内去重)。

    3. 建表规范
    (1)本地表命名格式:{tab_name}_local,分布式表命名格式:{tab_name}_shard 。
    (2)物化视图命名规范:{tabl_name_xxx}_mv 。
    (3)尽量不要使用Nullable类型,该类型对性能有一定影响,且不能包含在索引中。
    (4)合理设置分区,所有本地表使用order by关键字指定分区字段,建议采用日期作为一级分区。默认 order by 字段作为主键。
    (5)如果表中不是必须保留全量历史数据,建议指定TTL,可以免去手动过期历史数据的麻烦。
    (6)所有复制引擎表建表指定 use_minimalistic_part_header_in_zookeeper=1。
    `

  6. B站基于Clickhouse的下一代日志体系建设实践
    https://mp.weixin.qq.com/s/dUs7WUKUDOf9lLG6tzdk0g
    `
    # 01 背景介绍

    日志作为线上定位问题排障的重要手段,在可观测领域有着不可替代的作用。稳定性、成本、易用性、可扩展性都是日志系统需要追求的关键点。

    B站基于Elastic Stack的日志系统(Billions) 从2017建设以来, 已经服务了超过5年,目前规模超过500台机器,每日写入日志量超过700TB。
    ELK体系是业界最常用的日志技术栈,在传输上以结合规范key的JSON作为传输格式,易于多种语言实现和解析,并支持动态结构化字段。存储上ElasticSearch支持全文检索,能够快速从杂乱的日志信息中搜寻到关键字。展示上Kibana具有美观、易用等特性。
    随着业务系统的高速发展,日志系统的规模也随之快速扩展,我们遇到了一系列的问题,同时可观测业界随着OpenTelemetry规范的成熟,推动着我们重新考量,迈入下一代日志系统。

    # 02 遇到的问题

    * 首先必须要提的就是成本和稳定性。日志作为一种应用产生的实时数据,随着业务应用规模发展而紧跟着扩大。日志系统必须在具备高吞吐量的同时,也要具备较高的实时性要求。Elasticsearch由于分词等特性,在写吞吐量上有着明显的瓶颈,分词耗CPU且难以解决热点问题。如果资源冗余不足,就容易导致稳定性下降,日志摄入发生延迟,日志的延迟会对排障产生极大负面影响。
    * 同时由于压缩率不高的原因,ES的存储成本也较高,对内存有着较高的要求。这些因素导致我们日志必须进行常态化的采样和限流,对用户使用上造成了困扰,限制了排障的场景。
    * 内存使用率的问题也迫使我们必须将warm阶段的索引进行Close,避免占用内存。用户如果需要查询就必须操作进行Open,牺牲了一定的易用性。
    * 为了稳定性和成本,动态Mapping也必须被关闭,有时用户引导不到位,就会导致用户发现自己搜索的日志遗留了Mapping配置而导致难以追溯查询。
    * 在运维上,ES7之前缺少生命周期的能力,我们必须维护一整套生命周期相关组件,来对索引进行预创建、关闭和删除,不可避免的带来高维护成本。
    * Kibana虽然好用,但也不是没有缺点的,整体代码复杂,二次开发困难。且每次升级ES必须升级到对应的Kibana版本也增加了用户迁移的成本。还有一点就是Kibana Query虽然语法较为简单,但对于初次接触的研发还是有一定的学习成本的。
    * 在采集和传输上,我们制定了一套内部的日志格式规范,使用JSON作为传输格式,并提供了Java和Golang的SDK。这套传输格式本身在序列化/反序列化上性能一般,且私有协议难以避免兼容性和可维护性问。

    # 03 新架构体系

    针对上述的一系列问题,我们设计了Bilibili日志服务2.0的体系,主要的进化为使用ClickHouse作为存储,实现了自研的日志可视化分析平台,并使用OpenTelemetry作为统一日志上报协议。

    # 04 Clickhouse 功能增强与优化

    4.1 Clickhouse配置优化
    4.2 Clickhouse 动态类型 Map
    4.3 Clickhouse Map实现原理
    4.4 Map 类型索引支持
    4.5 Map隐式列简介
    4.6 Map隐式列实现
    4.7 查询测试

    # 05 下一步的工作

    5.1 日志模式提取

    目前虽然我们通过日志最佳实践和日志规范引导用户尽可能继续结构化日志的输出,但是仍然不可避免部分场景难以进行结构化,用户会将大段文本输入到日志中,在分析和查询上都有一定受限。我们计划实现日志模式并使用在查询交互,日志压缩, 后置结构化,异常模式检测这些场景上。

    5.2 结合湖仓一体

    在湖仓一体日益成熟的背景下,日志入湖会带来以下收益:
    * 部分日志有着三年以上的存储时间要求,比如合规要求的审计日志,关键业务日志等,数据湖的低成本存储特性是这个场景的不二之选。
    * 现在日志除了用来进行研发排障外,也有大量的业务价值蕴含其中。日志入湖后可以结合湖上的生态体系,快速结合如机器学习、BI分析、报表等功能,将日志的价值发挥到最大。
    此外,我们长远期探索减少日志上报的中间环节,如从agent直接到ClickHouse,去掉中间的Kafka,以及更深度的结合ClickHouse和湖仓一体,打通ClickHouse和iceberg。

    5.3 Clickhouse全文检索

    * 在全文检索场景下,Clickhouse的性能表现依旧与ES有一定的差距,为了能够覆盖日差查询的全场景,clickhouse在这方面的探索依旧任重道远。
    * 在全文检索索引的实践上,我们也需要尝试不同的数据结构,极力做到内存资源和查询性能的双重保证。
    `

  7. 2023,数据库发展展望
    https://cloud.tencent.com/developer/article/2213288

    十年对于数据库意味着什么?
    https://doris.apache.org/zh-CN/blog/summit/

    2023年数据库行业研究报告
    https://www.21jingji.com/article/20230217/herald/ba44b80145c6592f8b18e97eb261c772.html

    PingCAP 黄东旭万字长文剖析数据库发展新趋势:脱离应用开发者的数据库,不会成功
    https://tidb.net/book/tidb-monthly/2023/2023-01/feature-indepth/tidb-db-development-ed-huang

  8. 贝壳 OLAP 平台架构演进
    https://www.infoq.cn/article/qgvyuf9kl4wljio8ufvy
    https://mp.weixin.qq.com/s/H0KzKtwiD8u3YId4HJmemg

    数据分析的技术源流
    https://aws.amazon.com/cn/blogs/china/the-technical-origin-of-data-analysis/

    MPP database (massively parallel processing database)
    https://www.techtarget.com/searchdatamanagement/definition/MPP-database-massively-parallel-processing-database
    `
    MPP(大规模并行处理)是由处理程序不同部分的多个处理器协调处理程序。 每个处理器都有自己的操作系统和内存。 MPP 可加快处理大量数据的大型数据库的性能。

    MPP 数据库使用多核处理器、多个处理器和服务器以及为并行处理配备的存储设备。 这种组合可以同时读取多个处理单元中的许多数据,从而提高速度。 这种方法是必要的,因为处理器的频率正在达到所用技术的极限并且增加缓慢。
    `

  9. 京东李海波:OLAP关键技术演进思考
    https://mp.weixin.qq.com/s/ORPob1cGRjKCMeupb-bgDw
    `
    1. OLAP 背景由来
    联机分析处理的概念最早由关系数据库之父E.F. Codd于1993年提出。Codd认为,联机事务处理已不能满足终端用户对数据库查询分析的要求,SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果,而查询的结果并不能满足决策者提出的需求。

    因此,Codd提出了多维数据库和多维分析的概念,即OLAP(Online analytical processing)。OLAP委员会对联机分析处理的定义为:使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取,从而获得对数据更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求,它的技术核心是“维”这个概念,因此OLAP也可以说是多维数据分析工具的集合。

    2. 海量、实时、支持演进的新需求
    随着互联网、电商和移动互联网等行业的兴起,数据规模越来越来大,分析洞察需求越来越精细化,激烈市场环境下的决策要求数据具有更高的时效性,不同于早期的技术,新时期的OLAP技术也呈现快速的迭代进化。

    早期的报表系统,通过MapReduce计算出统计结果并存储在MySQL中,这个架构有两个局限,其一是MySQL单表存储能力有限只能保存有限的维度组合,数据量大时需要分库分表,其二是只能处理离线或微批准实时的数据,无法实时统计数据。

    为了解决维度组合存储的问题,一种新的解决方案是把维度的组合作为Key、指标作为Value存储在KV引擎如HBase中,这样就让维度的数量大大增加,但是也无法支持更多的维度,因为维度的增加会导致维度组合量的成倍的增长,出现维度爆炸的问题。

    为了解决海量数据实时查询的问题,Druid和ElasticSearch出现了,通过增量追加、实时聚合、索引、位图等技术,把数据的新鲜度从几十分钟提升到秒级。

    另一个问题是维度和指标需要支持演进,比如为了适应业务新的变化,需要在原来的维度基础之上,增加新的采集维度,或者调整计算口径;另一种情况是维度字典表发生变化,比如组织架构调整后,需要把历史数据按照新的维度来计算。

    为了解决维度爆炸、实时查询以及模型演进的问题,一种新架构的OLAP出现了,整合了列存、MVCC、物化视图的向量化执行引擎的MPP架构,解决海量数据、实时分析的需求,同时支持表结构的演进,其中以ClickHouse和Doris为代表。

    # Hadoop&数据库蓬勃发展

    谈到新时期的OLAP的演化,就不得不提Hadoop的生态,以Google三驾马车的论文发表为代表, Hadoop开源生态得到蓬勃发展。数据存储在HDFS中,Hive进行数据结构的管理并支持SQL,处理引擎由MapReduce升级为Spark,实时流从Storm升级为Spark Streaming和Flink,非结构化的音视频和网页存储在HBase中,同时搭配分布式一致性组件ZooKeeper,数据管道Kafka,调度Yarn等,各类组件百花齐放,组件的升级迭代非常迅速。数据计算链路以Lambda和Kappa架构最为典型,离线以HDFS为存储Spark为处理引擎,输出结果存在OLAP中;实时以Kafka为管道,Flink为处理引擎,输出结果存储在OLAP中。而OLAP承接了大数据处理引擎的写入,并支持上层数据应用的查询,处在一个较为核心的位置。

    而在数据库领域,为了简化数据摄入和ETL的过程,同时发挥行存和列存的优势,也提出了HTAP的概念。HTAP就是把OLTP和OLAP的优势结合起来,弥补了OLAP的一些不足,如行存引擎能支持高频写入,同时支持高并发的查询单条明细数据。在减少ETL复杂度方面,内置的数据同步能力,在小规模数据量和中低复杂度的业务场景中完全足够。国内数据库也在快速发展中,如阿里的OceanBase和PingCAP的TiDB。

    1. 实时 Druid
    2. 搜索技术 Elasticsearch
    3. 预聚合 Kylin
    4. 简单易用 Doris/StarRocks
    5. 功能强悍 ClickHouse
    6. 总结和建议
    上面几个引擎简单介绍完了,如果之前没有使用过OLAP引擎,推荐大家试试Doris/StarRocks,这两款引擎门槛低、场景适应性好,如动手能力强可以尝试ClickHouse,而ElasticSearch更适合全文检索的场景,Kylin适合离线预聚合场景,看看所选的引擎是否能覆盖上面几个问题的场景。

    如果已经用了以上某款或其他引擎,也大可不必急于切换其他引擎,深入挖掘这款引擎的潜力,等有痛点需求满足不了,综合权衡之后再决定是否切换或迁移。另外选型时,也应当考虑社区活跃度和成熟度,避免遇到问题时找不到技术支持,最后,选型应该亲自安装部署并用实际的场景去测试。

    最后我再提醒一下,多维分析技术在公司内全面成功实施,运维和运营非常重要,大部分问题来自错误使用或不当的运维方式。
    `

回复 abc 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注