[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=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4977.html

《[read]ClickHouse原理解析与应用实践》上的5个想法

  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、特别适用于数据量大,查询频次可控的场景,如数据分析、埋点日志系统
    `

发表评论

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