ClickHouse 结构以及使用场景

大多数公司的日志系统检索使用的都是 ELK+Kafka+ES 的架构,在日志数据量不是特别庞大的时候其实这种架构还是挺好的,简单并且也很高效,但是当你的公司日志数据量非常庞大每分钟生产1亿条数据的场景下,这种架构的问题就很明显了,主要会出现下面几个问题:

  • 延迟很高,kafka收集push 的延迟变高
  • ES 插入性能迅速下降,大量插入请求只能排队不然 ES 会被打挂,限流排队也就意味着延迟变得更加高

我们这边文章只讨论数据存储层进行提效,那么就是 CK 来替代 ES 了

ClickHouse 结构以及使用场景_第1张图片

 CK 高性能的4个特点上图已经说明很清楚,我们来详细了解下 CK 内部的核心内容

一般想要获得最佳的查询效率不外乎两种做法,一个是缩小查询返回的结果集大小一个是减少查询扫描的数据块。

想让查询变快,最简单有效的方法是减少数据扫描范围和数据存储时的大小。

列式存储是数据压缩的前提,可以有效减少查询时所需扫描的数据量(行式存储需要扫描并不需要的其他字段)并根据每一列具有相同类型和现实语义所以可以提供更高的压缩比。降低 I/O 和存储的压力,并为向量化执行做好铺垫。向量化可以简单看作一项消除程序中循环的优化。

实现向量化执行需要利用 CPU 的 SIMD (Single Instruction Multiple Data)指令用单条指令操作多条数据。ClickHouse 主要利用 SSE4.2 指令集。除此之外,ClickHouse 支持分区使,用多线程来提升在多分支判断场景下的性能表现。支持分片分布式计算,并使用多主架构(HDFS、Spark、HBase、ElasticSearch 是单主架构)来简化系统架构,天然回避了单点故障的问题,适合用于多数据中心、异地多活的场景。

MergeTree

在介绍具体方案之前先简单了解一下 MergeTree 的存储格式。MergeTree 是 ClickHouse 最主要使用的存储引擎,当创建表时可以通过 PARTITION BY 语句指定以某一个或多个字段作为分区字段,数据在磁盘上的目录结构类似如下形式:

$ ls -l /var/lib/clickhouse/data//
drwxr-xr-x  2 test  test    64B Mar  8 13:46 202102_1_3_0
drwxr-xr-x  2 test  test    64B Mar  8 13:46 202102_4_6_1
drwxr-xr-x  2 test  test    64B Mar  8 13:46 202103_1_1_0
drwxr-xr-x  2 test  test    64B Mar  8 13:46 202103_4_4_0

以 202102_1_3_0 为例,202102 是分区的名称,1 是最小的数据块编号,3 是最大的数据块编号,0 是 MergeTree 的深度。可以看到 202102 这个分区不止一个目录,这是因为 ClickHouse 每次在写入的时候都会生成一个新的目录,并且一旦写入以后就不会修改(immutable)。每一个目录称作一个「part」,当 part 逐渐变多以后 ClickHouse 会在后台对多个 part 进行合并(compaction),通常的建议是不要保留过多 part,否则会影响查询性能。

每个 part 目录内部又由很多大大小小的文件组成,这里面既有数据,也有一些元信息,一个典型的目录结构如下所示:

$ ls -l /var/lib/clickhouse/data//
/202102_1_3_0 -rw-r--r-- 1 test test ?? Mar 8 14:06 ColumnA.bin -rw-r--r-- 1 test test ?? Mar 8 14:06 ColumnA.mrk -rw-r--r-- 1 test test ?? Mar 8 14:06 ColumnB.bin -rw-r--r-- 1 test test ?? Mar 8 14:06 ColumnB.mrk -rw-r--r-- 1 test test ?? Mar 8 14:06 checksums.txt -rw-r--r-- 1 test test ?? Mar 8 14:06 columns.txt -rw-r--r-- 1 test test ?? Mar 8 14:06 count.txt -rw-r--r-- 1 test test ?? Mar 8 14:06 minmax_ColumnC.idx -rw-r--r-- 1 test test ?? Mar 8 14:06 partition.dat -rw-r--r-- 1 test test ?? Mar 8 14:06 primary.idx

其中比较重要的文件有:

  • primary.idx:这个文件包含的是主键信息,但不是当前 part 全部行的主键,默认会按照 8192 这个区间来存储,也就是每 8192 行存储一次主键。
  • ColumnA.bin:这是压缩以后的某一列的数据,ColumnA 只是这一列的代称,实际情况会是真实的列名。压缩是以 block 作为最小单位,每个 block 的大小从 64KiB 到 1MiB 不等。
  • ColumnA.mrk:这个文件保存的是对应的 ColumnA.bin 文件中每个 block 压缩后和压缩前的偏移。
  • partition.dat:这个文件包含的是经过分区表达式计算以后的分区 ID。
  • minmax_ColumnC.idx:这个文件包含的是分区字段对应的原始数据的最小值和最大值。

数据的操作是面向块对象进行的,并采用了流的形式。块对象由数据对象(列对象)、数据类型(DataType)和列名称(字符串)组成。列对象负责数据读取操作,使用泛化的设计思路。内存中一列由一个列对象表示, ~定义~ 了插入、分页以及过滤的 ~方法~ ,具体实现则由具体的对象实现。对于某个具体数值(列中的一行)的操作需要使用字段对象,字段对象使用聚合的设计模式,按数据类型提供不同的处理逻辑。DataType 负责序列化工作。覆盖常用类型并与列对象的设计思路一致,具体方法由对应的数据类型实例进行承载。

不过,块没有直接聚合列对象和 DataType 对象,而是通过 ColumnWithTypeAndName 对象进行间接引用。块流对象也使用了泛化的设计模式, 定义了读取运算以及输出的接口

表引擎(而不是表对象)由 IStorage 接口定义DDL、读写方法。不同的表引擎由不同的子类实现,表引擎负责根据 ATS 查询语句返回指定列的原始数据,后续数据处理由解释器对象完成。解释器对象负责解释 AST 并创建查询管道,串联整个查询流程:分析器将一条 SQL 语句根据 DDL 类型交由不同分析器分析成 AST 语法树,解释器会根据类型聚合所需资源,完成业务逻辑,最终返回块对象,以线程的形式建立起查询执行管道。

Clickhouse常见应用场景

  • 电信行业用于存储数据和统计数据使用;
  • 新浪微博用于用户行为数据记录和分析工作;
  • 用于广告网络和RTB,电子商务的用户行为分析;
  • 日志分析;
  • 检测和遥感信息的挖掘;
  • 商业智能;
  • 网络游戏以及物联网的数据处理和价值数据分析;
  • 最大的应用来自于Yandex的统计分析服务Yandex.Metri ca。

你可能感兴趣的:(架构,数据库技术,spring,webflux,nginx)