在线分析处理查询clickhouse

ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的列式存储数据（DBMS），使用 C++语言编写，主要用于在线分析处理查询（OLAP），能够使用 SQL 查询实时生成分析数据报告

1）Parser与Interpreter

Parser和Interpreter是非常重要的两组接口：Parser分析器是将sql语句已递归的方式形成AST语法树的形式，并且不同类型的sql都会调用不同的parse实现类。而Interpreter解释器则负责解释AST，并进一步创建查询的执行管道。Interpreter解释器的作用就像Service服务层一样，起到串联整个查询过程的作用，它会根据解释器的类型，聚合它所需要的资源。首先它会解析AST对象；然后执行"业务逻辑" ( 例如分支判断、设置参数、调用接口等 )；最终返回IBlock对象，以线程的形式建立起一个查询执行管道。

2）表引擎

表引擎是ClickHouse的一个显著特性，上文也有提到，clickhouse有很多种表引擎。不同的表引擎由不同的子类实现。表引擎是使用IStorage接口的，该接口定义了DDL ( 如ALTER、RENAME、OPTIMIZE和DROP等 ) 、read和write方法，它们分别负责数据的定义、查询与写入。

3）DataType

数据的序列化和反序列化工作由DataType负责。根据不同的数据类型，IDataType接口会有不同的实现类。DataType虽然会对数据进行正反序列化，但是它不会直接和内存或者磁盘做交互，而是转交给Column和Filed处理。

4）Column与Field

Column和Field是ClickHouse数据最基础的映射单元。作为一款百分之百的列式存储数据库，ClickHouse按列存储数据，内存中的一列数据由一个Column对象表示。Column对象分为接口和实现两个部分，在IColumn接口对象中，定义了对数据进行各种关系运算的方法，例如插入数据的insertRangeFrom和insertFrom方法、用于分页的cut，以及用于过滤的filter方法等。而这些方法的具体实现对象则根据数据类型的不同，由相应的对象实现，例如ColumnString、ColumnArray和ColumnTuple等。在大多数场合，ClickHouse都会以整列的方式操作数据，但凡事也有例外。如果需要操作单个具体的数值 ( 也就是单列中的一行数据 )，则需要使用Field对象，Field对象代表一个单值。与Column对象的泛化设计思路不同，Field对象使用了聚合的设计模式。在Field对象内部聚合了Null、UInt64、String和Array等13种数据类型及相应的处理逻辑。

5）Block

ClickHouse内部的数据操作是面向Block对象进行的，并且采用了流的形式。虽然Column和Filed组成了数据的基本映射单元，但对应到实际操作，它们还缺少了一些必要的信息，比如数据的类型及列的名称。于是ClickHouse设计了Block对象，Block对象可以看作数据表的子集。Block对象的本质是由数据对象、数据类型和列名称组成的三元组，即Column、DataType及列名称字符串。Column提供了数据的读取能力，而DataType知道如何正反序列化，所以Block在这些对象的基础之上实现了进一步的抽象和封装，从而简化了整个使用的过程，仅通过Block对象就能完成一系列的数据操作。在具体的实现过程中，Block并没有直接聚合Column和DataType对象，而是通过ColumnWith TypeAndName对象进行间接引用。

自从ClickHouse2016年6月15日开源后，ClickHouse中文社区随后成立。中文开源组开始以易观，海康威视,美团，新浪，京东,58,腾讯,酷狗音乐和俄罗斯开源社区等人员组成，随着开源社区的不断活跃，陆续有神州数码，青云，PingCAP，中软国际等公司成员加入以及其他公司成员加入。初始在群里讨论技术后续有一些大型公司陆续运用到项目中，介于分享不方便问题解决，建立了相应的论坛。根据交流得知一些大公司已经运用。

最大的应用来自于Yandex的统计分析服务Yandex.Metrica，类似于谷歌Analytics(GA)，或友盟统计，小米统计，帮助网站或移动应用进行数据分析和精细化运营工具，据称Yandex.Metrica为世界上第二大的网站分析平台。ClickHouse在这个应用中，部署了近四百台机器，每天支持200亿的事件和历史总记录超过13万亿条记录，这些记录都存有原始数据（非聚合数据），随时可以使用SQL查询和分析，生成用户报告。

1. 准备工作

1）确定防火墙处于关闭状态

2）CentOS 取消打开文件数限制

在 hadoop102 的 /etc/security/limits.conf 文件的末尾加入以下内容

在 hadoop102 的/etc/security/limits.d/20-nproc.conf 文件的末尾加入以下内容

执行同步操作

3） CentOS 取消打开文件数限制

4）CentOS 取消 SELINUX

修改/etc/selinux/config 中的 SELINUX=disabled

执行同步操作

重启三台服务器。

2. 单机安装

1）在 hadoop102 的/opt/software 下创建 clickhouse 目录

2）将/2.资料/ClickHouse 下 4 个文件上传到 hadoop102 的software/clickhouse 目录下

3）将安装文件同步到 hadoop103、hadoop104 并rpm执行

4）修改配置文件

把 :: 的注释打开，这样的话才能让 ClickHouse 被除本

机以外的服务器访问

分发配置文件

sudo /home/atguigu/bin/xsync /etc/clickhouse-server/config.xml

在这个文件中，有 ClickHouse 的一些默认路径配置，比较重要的

数据文件路径：/var/lib/clickhouse/

日志文件路径：/var/log/clickhouse-server/clickhouse-server.log

5）启动 Server

6）使用 client 连接 server

Clickhouse为什么做查询分析那么快？

因为clickhouse使用了下列方案：

• clickhouse 数据分区

• clickhouse 列式存储

所有的OLAP技术，基本都是使用的列式存储。其有以下优点：

分析场景中往往需要读大量行但是少量列。在行存储模式中，所有的列数据都存储在一个block中，不参与计算的列在IO的时候也需要读取，造成没必要的IO浪费。而列式存储，则只需要读取参与计算的列即可，极大的减少了IO消耗，加快了查询效率同一列数据中的数据类型相同，这有利于提高压缩比，节省大量存储空间而压缩比高，则意味着数据体积小，对应的其IO读取耗时更短

自由压缩算法选择，不同的列可以根据数据类型，来使用不同的压缩算法高压缩比，同时也会减少内存消耗，同样的内存可以缓存更多的数据

• clickhouse 数据压缩

关于数据压缩：Clickhouse的数据存储文件 column.bin中存储的是一列数据，由于一列是相同的数据类型，所以方便高效压缩，在进行压缩的时候，请注意：一个压缩数据块由头信息和压缩数据两部分组成，头信息固定使用9位字节表示，具体由1个UInt8（1字节）整型和2个UInt32(4字节)整型组成，分别代表使用的压缩算法类型、压缩后的数据大小和压缩前的数据大小。每个压缩数据块的体积，按照其压缩前的数据字节大小，都被严格控制在64KB ~ 1MB，其上下限分别由 min_compress-block_size(默认65535=64KB)与max_compress_block_size(默认1MB)参数指定。

具体压缩规则：

1. 单个批次数据 size < 64KB：如果单个批次数据小于64KB，则继续获取下一批数据后，直至累计到size >= 64KB时，生成下一个压缩数据块。如果平均每条记录小于8byte，多个数据批次压缩成一个数据块

2. 单个批次数据 64KB <= size <= 1MB：如果单个批次数据大小在64KB与1MB之间，则直接生成下一个压缩数据块

3. > 单个批次数据 size > 1MB：如果单个批次数据直接超过1MB，则首先按照1MB大小截断并生成下一个压缩数据块。剩余数据继续依照上述规则执行。此时，会出现一个批次数据生成多个压缩数据块的情况。如果平均每条记录的大小超过128byte，则会把当前这一个批次的数据压缩成多个数据块

• clickhouse 数据标记

关于数据标记，数据标记文件也与xxx.bin文件一一对应，是一级索引与数据块之间关系的数据

END

更多精彩干货分享

点击下方名片关注

IT那活儿