更新时间:2023-04-10 GMT+08:00

ClickHouse

ClickHouse简介

ClickHouse是一款开源的面向联机分析处理的列式数据库,其独立于Hadoop大数据体系,最核心的特点是压缩率和极速查询性能。同时,ClickHouse支持SQL查询,且查询性能好,特别是基于大宽表的聚合分析查询性能非常优异,比其他分析型数据库速度快一个数量级。

ClickHouse核心的功能特性介绍如下:

完备的DBMS功能

ClickHouse拥有完备的DBMS数据库管理系统(Database Management System),基本功能如下所示。
  • DDL (数据定义语言):可以动态地创建、修改或删除数据库、表和视图,而无须重启服务。
  • DML(数据操作语言):可以动态查询、插入、修改或删除数据。
  • 权限控制:可以按照用户粒度设置数据库或者表的操作权限,保障数据的安全性。
  • 数据备份与恢复:提供了数据备份导出与导入恢复机制,满足生产环境的要求。
  • 分布式管理:提供集群模式,能够自动管理多个数据库节点。

列式存储与数据压缩

ClickHouse是一款使用列式存储的数据库,数据按列进行组织,属于同一列的数据会被保存在一起,列与列之间也会由不同的文件分别保存。

在执行数据查询时,列式存储可以减少数据扫描范围和数据传输时的大小,提高了数据查询的效率。

例如在传统的行式数据库系统中,数据按如下表1顺序存储:

表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顺序存储:

表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流量、电信、金融、物联网等众多领域,非常适用于商业智能化应用场景,在全球有大量的应用和实践,具体请参考:https://clickhouse.tech/docs/en/introduction/adopters/

ClickHouse开源增强特性

MRS ClickHouse具备“手动挡”集群模式升级、平滑弹性扩容、高可用HA部署架构等优势能力,具体详情如下:

  • 手动挡集群模式升级
    图1所示,多个ClickHouse节点组成的集群,没有中心节点,更多的是一个静态资源池的概念,业务要使用ClickHouse集群模式,需要预先在各个节点的配置文件中定义cluster信息,等所有参与的节点达成共识,业务才可以正确的交互访问,也就是说配置文件中的cluster才是通常理解的“集群”概念。
    图1 ClickHouse集群
    常见的数据库系统,隐藏了表级以下的数据分区、副本存储等细节,用户是无感知的,而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引擎表时,可以指定分片,相同分片内的两个副本数据就可以自动进行同步。

    图3 高可用HA部署架构图

ClickHouse与其他组件的关系

ClickHouse安装部署依赖Zookeeper服务。

ClickHouse通过Flink流计算应用加工生成通用的报表数据(明细宽表),准实时写入到ClickHouse,通过Hive/Spark作业加工生成通用的报表数据(明细宽表),批量导入到ClickHouse。

ClickHouse暂不支持对接Kafka普通模式和HDFS安全模式。