ClickHouse
ClickHouse简介
ClickHouse是一款开源的面向联机分析处理的列式数据库，其独立于Hadoop大数据体系，最核心的特点是压缩率和极速查询性能。同时，ClickHouse支持SQL查询，且查询性能好，特别是基于大宽表的聚合分析查询性能非常优异，比其他分析型数据库速度快一个数量级。
ClickHouse核心的功能特性介绍如下：
完备的DBMS功能
- DDL （数据定义语言）：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。
- DML（数据操作语言）：可以动态查询、插入、修改或删除数据。
- 权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
- 数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
- 分布式管理：提供集群模式，能够自动管理多个数据库节点。
列式存储与数据压缩
ClickHouse是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存。
在执行数据查询时，列式存储可以减少数据扫描范围和数据传输时的大小，提高了数据查询的效率。
例如在传统的行式数据库系统中，数据按如下表1顺序存储：
|
row |
ID |
Flag |
Name |
Event |
Time |
|---|---|---|---|---|---|
|
0 |
12345678901 |
0 |
name1 |
1 |
2020/1/11 15:19 |
|
1 |
32345678901 |
1 |
name2 |
1 |
2020/5/12 18:10 |
|
2 |
42345678901 |
1 |
name3 |
1 |
2020/6/13 17:38 |
|
N |
… |
… |
… |
… |
… |
行式数据库中处于同一行中的数据总是被物理的存储在一起，而在列式数据库系统中，数据按如下表2顺序存储：
|
row: |
0 |
1 |
2 |
N |
|---|---|---|---|---|
|
ID: |
12345678901 |
32345678901 |
42345678901 |
… |
|
Flag: |
0 |
1 |
1 |
… |
|
Name: |
name1 |
name2 |
name3 |
… |
|
Event: |
1 |
1 |
1 |
… |
|
Time: |
2020/1/11 15:19 |
2020/5/12 18:10 |
2020/6/13 17:38 |
… |
该示例中只展示了数据在列式数据库中数据的排列方式。对于存储而言，列式数据库总是将同一列的数据存储在一起，不同列的数据也总是分开存储，列式数据库更适合于OLAP（Online Analytical Processing）场景。
向量化执行引擎
ClickHouse利用CPU的SIMD指令实现了向量化执行。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据，通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 )，它的原理是在CPU寄存器层面实现数据的并行操作。
关系模型与SQL查询
ClickHouse完全使用SQL作为查询语言，提供了标准协议的SQL查询接口，使得现有的第三方分析可视化系统可以轻松与它集成对接。
同时ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低。
数据分片与分布式查询
ClickHouse集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量（1个分片只能对应1个服务节点）。
ClickHouse提供了本地表 （Local Table）与分布式表 （Distributed Table）的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
ClickHouse应用场景
ClickHouse是Click Stream + Data WareHouse的缩写，起初应用于一款Web流量分析工具，基于页面的点击事件流，面向数据仓库进行OLAP分析。当前ClickHouse被广泛的应用于互联网广告、App和Web流量、电信、金融、物联网等众多领域，非常适用于商业智能化应用场景，在全球有大量的应用和实践，
ClickHouse开源增强特性
MRS ClickHouse具备“手动挡”集群模式升级、平滑弹性扩容、高可用HA部署架构等优势能力，具体详情如下：
- 手动挡集群模式升级
如图1所示，多个ClickHouse节点组成的集群，没有中心节点，更多的是一个静态资源池的概念，业务要使用ClickHouse集群模式，需要预先在各个节点的配置文件中定义cluster信息，等所有参与的节点达成共识，业务才可以正确的交互访问，也就是说配置文件中的cluster才是通常理解的“集群”概念。常见的数据库系统，隐藏了表级以下的数据分区、副本存储等细节，用户是无感知的，而ClickHouse则要求用户主动来规划和定义数据分片（shard）、分区（partition）、副本（replica）位置等详细配置。它的这种类似“手动挡”的属性，给用户带来极不友好的体验，所以MRS服务的ClickHouse实例对这些工作做了统一的打包处理，适配成了“自动挡”，实现了统一管理，灵活易用。具体部署形态上，一个ClickHouse实例将包含3个Zookeeper节点和多个ClickHouse节点，采用Dedicated Replica模式，数据双副本高可靠。图2 ClickHouse的cluster结构
- 平滑的弹性扩容能力
随着业务的快速增长，面对集群存储容量或者CPU计算资源接近极限等场景，MRS服务提供了ClickHouse数据迁移工具，该工具可以将某几个ClickHouseServer实例节点上的一个或多个MergeTree引擎分区表的部分分区迁移至其他ClickHouseServer节点上相同的表中，以便保障业务可用性，实现了更加平滑的扩容能力。
在用户对集群进行扩容ClickHouse节点时，可以使用该工具将原节点上的部分数据迁移至新增节点上，从而达到扩容后的数据均衡。
- 高可用HA部署架构
MRS服务提供了基于ELB的HA部署架构，可以将用户访问流量自动分发到多台后端节点，扩展系统对外的服务能力，实现更高水平的应用容错。如图3所示，客户端应用请求集群时，使用ELB（Elastic Load Balance）来进行流量分发，通过ELB的轮询机制，写不同节点上的本地表（Local Table），读不同节点上的分布式表（Distributed Table），这样，无论集群写入的负载、读的负载以及应用接入的高可用性都具备了有力的保障。
ClickHouse集群发放成功后，每个ClickHouse实例节点对应一个副本replica，两个副本组成一个shard逻辑分片。如创建ReplicatedMergeTree引擎表时，可以指定分片，相同分片内的两个副本数据就可以自动进行同步。
ClickHouse与其他组件的关系
ClickHouse安装部署依赖Zookeeper服务。
ClickHouse通过Flink流计算应用加工生成通用的报表数据（明细宽表），准实时写入到ClickHouse，通过Hive/Spark作业加工生成通用的报表数据（明细宽表），批量导入到ClickHouse。
ClickHouse暂不支持对接Kafka普通模式和HDFS安全模式。
