ClickHouse的配置搭建和应用以及迁移MySql数据库的方案和注意问题
目录
- ClickHouse简介
-
- 1. 什么是ClickHouse：
-
- 1.1 简介：
- 1.2 OLAP：
- 1.3 列式数据库更适合OLAP场景的原因：
- 2. ClickHouse适用场景：
- 3. ClickHouse本地环境搭建：
-
- 3.1本地快速部署：
-
- 3.1.1基于tgz的安装：
- 3.2开启远程访问：
- 3.3 java代码中的使用：
- 4. ClickHouse的使用：
-
- 4.1创建使用库:
- 4.1.1Atomic 库引擎:
- 4.1.2 MySQL库引擎:
- 4.2 建表:
-
- 4.2.1 数据类型：
- 4.2.2表引擎：
- 5. ClickHouse迁移方案（MySql）：
-
- 5.1 方案1：
- 5.2 方案2：
- 5.3 方案3：
- 5.4 方案4：
- 5.5 方案5：
- 5.6 方案6：
-
- 5.6.1 创建表:
- 5.6.2 修改脚本:
- 5.6.3 导入建表:
- 5.6.4 数据导入:
- 5.7 方案7：
- 6. 关于mysql迁移到clickhouse需要准备的工作：
-
- 6.1 mysql和clickhouse语法的区分：
- 6.2 mysql和clickhouse数据库引擎的区分：
-
- 6.2.1 mysql:
- 6.2.1 clickhouse:
- 6.3 改造整体流程：
- 7. 总结：
ClickHouse简介
本文精简的介绍了ClickHouse数据库以及MySql相关的改造方案，欢迎大家点赞收藏~
ClickHouse官网地址：https://clickhouse.com/docs/zh
1. 什么是ClickHouse：
1.1 简介：
Clickhouse是由俄罗斯yandex公司开源的一个用于联机分析OLAP的列式数据库 管理系统。他是使用C++语言编写的，支持SQL实时查询的大型数据管理系统。由 于Clickhouse在大型数据集查询处理的高效表现，从2016年开源以来，就吸引了全 球的目光，甚至一度登上github的关注度头把交椅。
以上这一段介绍中标出了Clickhouse的几个显著特点。
1.2 OLAP：
- OLAP场景的关键特征:
- 绝大多数是读请求
- 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
- 已添加到数据库的数据不能修改。
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
- 宽表，即每个表包含着大量的列
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
- 事务不是必须的
- 对数据一致性要求低
- 每个查询有一个大表。除了他以外，其他的都很小。
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
1.3 列式数据库更适合OLAP场景的原因：
Clickhouse的设计定位就是用于OLAP离线数据处理。相比于OLTP在线事务处 理，Clickhouse更关注于对海量数据的计算分析，关注的是数据吞吐、查询速度、计算性能等指标。而对于数据频繁的修改变更，则不太擅长。所以 Clickhouse通常用来构建后端的实时数仓或者离线数仓。
列式存储：
Clickhouse是一个真正意义上的列式存储数据库。传统数据库存储数据都是按照数据行进行存储。
在传统的行式数据库系统中，数据按如下顺序存储：
比如常用的MySQL，他的B+树的叶子节点就会整体保留一行数据。 这样的好处是，当想要查询某一条数据时，可以通过一次磁盘查找加顺序读取 获得这一条完整的数据。
而Clickhouse存储数据的方式则是按照列来存储，将来自不同列的数据进行单 独存储。实际上后面会介绍到，Clickhouse存储一个表数据时，就是以一列为一 个文件进行存储的。
处于同一行中的数据总是被物理的存储在一起。
常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。
在列式数据库系统中，数据按如下的顺序存储：
列式存储的数据库产品其实也有很多，像Druid数据库，InfiniDB等等很多。 只是在国内其实用的还是比较少的。列式存储相比于行式存储在很多数据计算方 面会体现出很多优势。例如通常一个计算过程都只会用到少数几个列的数据，这时行式存储就需要读取到相关行的所有列数据再进行过滤。而列式存储就可以直 接读取这几个列的相关数据，而不用查找其他不关心的数据。
列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：
行式:
列式:
2. ClickHouse适用场景：
一个典型的OLAP场景主要是对海量数据进行更新，相比于我们常用的mysql等OLTP数据库，有一些很明显的特征。
- 绝大多数请求都是读请求。对数据的修改比较少或者几乎没有。
- 数据量很大。这个量即包括数据的行数，也包括数据的列数。也就是通常说的宽表。大部分情况下，对分布式表结构的要求是必须的。
- 数据通常以大的批次进行整体更新，而不是单行更新。这需要有很高的数据吞吐量。对事务的要求不是必须的。
- 对于数据一致性的要求不会太高。通常只要求数据最终一致性。
Clickhouse的数据吞吐量相当大，能够存储海量的数据，并能够以水平扩展的方式进行扩容。对大表的查询计算处理效率也非常高，甚至很多场景下都可以拥有媲美于关系型数据库的查询效率。官网给出的一些测试数据也大都是 上千万行*数百列的数据规模。很多大规模的数据查询也都能轻松达到毫秒级别。
但是需要指出，Clickhouse高效性能的背后，肯定伴随计算机资源的大量消耗。 Clickhouse对内存和CPU的占用率都非常高，一个很普通的查询都可能需要消耗非常多的资源。因此，Clickhouse的查询频率也不宜太高。过于频繁的连续或者并发查询甚至很容易导致服务直接崩溃。
综合Clickhouse的特点，他就非常适合用于后端数仓的建设。当然，这本身也是 Clickhouse的设计目标。
3. ClickHouse本地环境搭建：
3.1本地快速部署：
详见官网：https://clickhouse.com/docs/zh/getting-started/install/
安装包：https://repo.clickhouse.com/deb/stable/main/
3.1.1基于tgz的安装：
下载官网的压缩包：
clickhouseserver-21.9.5.16.tgz
clickhouse-common-static-dbg-21.9.5.16.tgz
clickhouse-common-static-21.9.5.16.tgz
clickhouse-client-21.9.5.16.tgz
分别执行以下命令：
tar -xzvf clickhouse-common-static-21.9.5.16.tgz
sudo clickhouse-common-static-21.9.5.16/install/doinst.sh
tar -xzvf clickhouse-common-static-dbg-21.9.5.16.tgz
sudo clickhouse-common-static-dbg-21.9.5.16/install/doinst.sh
tar -xzvf clickhouse-server-21.9.5.16.tgz
sudo clickhouse-server-21.9.5.16/install/doinst.sh
tar -xzvf clickhouse-client-21.9.5.16.tgz
sudo clickhouse-client-21.9.5.16/install/doinst.sh
请注意执行的先后顺序！
在安装clickhouse-server-21.9.5.16.tgz时，会出现default用户设置密码的设置，可以在此时给定password：
Enter password for default user:
Password for default user is empty string. See /etc/clickhouseserver/users.xml and /etc/clickhouse-server/users.d to change it.
Setting capabilities for clickhouse binary. This is optional.
ClickHouse has been successfully installed.
Start clickhouse-server with:
sudo clickhouse start #启动clickhouse
通过以下命令进行登录：
官方客户端操作指令：https://clickhouse.com/docs/zh/interfaces/cli/
clickhouse-client -u default --password root -m
-u : 指定用户名 --password : 指定用户密码 -m : 允许客户端多行执行，直到";"进行提交。 -h : 可以指定其他环境上的clickhouse
3.2开启远程访问：
/etc/clickhouse-server 此目录下执行
vim config.xml
<listen_host>::</listen_host> 将此行注释打开
clickhouse restart 重启clickhouse
此时可以通过Dbear进行连接
默认端口号为8123，默认用户名为default，用户密码可以为空（如果没有设置时）
3.3 java代码中的使用：
<dependency>
<groupId>ru.yandex.clickhousegroupId>
<artifactId>clickhouse-jdbcartifactId>
<version>0.3.1version>
dependency>
注：用的阿里云和maven仓库没办法联机下载最新版本0.3.2
github官方版本：https://github.com/ClickHouse/clickhouse-jdbc
此处未用第三方版本，用官网版本jdbc驱动
使用案例：
URL syntax: jdbc:clickhouse://:[/], e.g. jdbc:clickhouse://localhost:8123/test
JDBC Driver Class: ru.yandex.clickhouse.ClickHouseDriver
4. ClickHouse的使用：
注意：clickhouse和标准SQL相反，所有其它的关键字都是大小写敏感的，包括函数名称。
详见：https://clickhouse.com/docs/zh/sql-reference/syntax/
4.1创建使用库:
4.1.1Atomic 库引擎:
这是clickhouse默认的库引擎。默认创建的default库就是使用的这种引擎。可以 在建库时进行声明。
show databases #参看所使用的的库
CREATE DATABASE eiot_manager [ ENGINE = Atomic]; #创建所要使用的数据库
Atomic类型的数据库完全由clickhouse自己管理数据。每个数据库对 应**/var/lib/data/目录下的一个子目录。数据库中的每个表会分配一个唯一**的 UUID，数据存储在目录 /var/lib/clickhouse/store/xxx/xxxyyyyy-yyyy-yyyyyyyy-yyyyyyyyyyyy/，其中xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy是该表的 UUID。
4.1.2 MySQL库引擎:
MySQL引擎用于将远程的MySQL服务器中的表映射到ClickHouse中，并允许您对表进行INSERT和SELECT查询，以方便您在ClickHouse与MySQL之间进行数据交换。MySQL数据库引擎会将对其的查询转换为MySQL语法并发送到MySQL服务器中，因此您可以执行诸如SHOW TABLES或SHOW CREATE TABLE之类的操作。 通过MySQL引擎可以省掉很多ETL的过程。例如下面的语句就可以在clickhouse 中创建一个mysqldb。
CREATE DATABASE IF NOT EXISTS eiot_manager ENGINE = MySQL('127.0.0.1:3306',
'mysql', 'root', 'root');
对于mysqldb库的操作，会转义成mysql语法，发送到相对应的MySQL中执行。
详情见：https://clickhouse.com/docs/zh/engines/database-engines/materialized-mysql/
注：也可以通过将clickhouse当做从库的引擎，数据保存在clickhouse上，因为是试验阶段因此不进行选型使用。
4.2 建表:
4.2.1 数据类型：
clickhouse的数据类型简介：
1. 整型:
Int8-[-128:127] 占用8个字节，对应java中的byte
Int16-[-32768:32767] 占用16个字节，对应java中的short
Int32-[-2147483648:2147483647] 占用32个字节，对应java中的int
Int64-[-9223372036854775808:9223372036854775807] 占用64个字节，对 应java中的long
无符号整型范围：
UInt8-[0:255]
UInt16-[0:65535]
UInt32-[0:4294967295]
UInt64-[0:18446744073709551615]
2. boolean布尔型:
clickhouse中没有定义表示true和false的布尔类型数据，通常都是直接使用 UInt8
3. 浮点型:
Float32 - float
Float64 - double
官方建议尽量使用整型来存储数据，将固定精度的数字转换成为整数值。例如时 间用毫秒为单位保存。这是因为使用浮点型有精度丢失问题。例如执行 select 1-0.9 得到的结果将是 0.09999999999999998 而不是0.1。
浮点型一般用于数据值比较小，不设计大量的统计计算，精度要求也不高的场 景。例如保存商品的重量。但是对于精度要求比较高的金额，就极不建议使用浮点 型。而应该用Decimal型。
4. Decimal型:
有符号的浮点数，可以在加、减和乘法运算过程中保持精度。对于除法，最低有 效数字将被抛弃(不进行四舍五入)。通常有三种声明： Decimal32(s)、 Decimal64(s)、Decimal128(s)。后面的s表示小数点后的数字位数。前面的32， 64, 128表示浮点精度，决定可以有多少个十进制数字(包含小数位)，也就代表不同 的取值范围。
数据在底层会采用与自身位宽相同的有符号整数存储。而现代CPU不支持128位 的数字，因此Decimal128上的操作需要由软件来进行模拟。所以Decimal128的运 算速度会明显慢于Decimal32\Decimal64。也就是说尽量少用Decimal128。
5. 字符型:
clickhouse的字符型数据使用String进行声明。这个字符串可以是任意长度的。 他可以包含任意的字节集，包含空字节。因此，字符串类型可以代替其他数据库中 的VARCHAR、BLOB、CLOB等类型。
clickhouse中没有编码的概念。字符串可以是任意的字节集，按他们原本的方式 进行存储和输出。对于不同的编码文本，clickhouse会有不同处理字符串的函数。 比如 length函数可以计算字符串包含的字节数组的长度，而lengthUTF8函数是假 设字符串以UTF-8编码，计算的字符串包含的Unicode字符的长度。
还有一个固定长度的字符串类型FixedString(N)，这个N就是要声明的字节数。 如果字符串包含的字节数不足N，将会对字符串末尾进行空字节填充。如果字符串包 含的字节数大于N，将会抛出异常。可以用来保存一些例如手机号码、IP地址这一类 等长的规范数据。在实际开发中使用比较少。
6 .枚举类型:
包含Enum8和Enum16两种类型。Enum保存’string’=integer的对应关系。在 clickhouse中，尽管用户使用的是字符串常量，但所有罕有Enum数据类型的操作都 是按照韩包含整数的值来执行的。这在性能方便比使用String数据类型更有效。 Enum后面的8和16也是对应的整数值integer的位宽。
7. 数组类型:
类型声明： array(T) 。表示一个由T类型元素组成的数组。T可以是任意类型，甚 至也可以是数组类型。但是不建议使用多位数组，clickhouse对多维数组的支持有 限。例如在MergeTree引擎中就不能存储多维数组。
详情见官网，不在此一一赘述：https://clickhouse.com/docs/zh/sql-reference/data-types/
4.2.2表引擎：
clickhouse的表引擎比较丰富，一般最长使用的是MergeTree,总体可分为一下四类：
MergeTree合并树家族：https://clickhouse.com/docs/zh/engines/table-engines/mergetree-family/versionedcollapsingmergetree/
这是适用于高负载任务的最通用同时功能最强大的表引擎。这一类引擎的共同特点是可以快速插入数据并进行后续的后台数据处理。 是clickhouse默认的也是最为重要的引擎。
特点： 快速的insert数据和读取数据，后续根据对应策略进行分区合并。
可能出现的问题： 数据的重复和丢失。
Log 日志系列:
具有最小功能的轻量级引擎。用于快速写入许多小表(最多约100 万行)，并在以后整体读取这些数据。例如常用的滚动日志。例如TinyLog引擎， 以列文件的形式保存在磁盘上，不支持索引，没有并发控制，通常只用于练习。
Integration Engines 集成引擎：
用于与其他的数据存储与处理系统集成的引 擎。通常可用来简化一些ETL的工作。例如同样有MySQL的表引擎，将对表的查 询语句转发到远程MySQL数据库中。另外，可以看到，clickhouse支持的集成表 引擎比库引擎丰富很多。
Special Engines 特别引擎：
用于其他特定功能的引擎。比如使用内存表、字典 表等。
见官网表引擎：https://clickhouse.com/docs/zh/engines/table-engines/
MergeTree：
**存储的数据按主键排序。**这样你能够创建一个小型的稀疏索引来加快数据检索。
**如果指定了分区键的话，可以使用分区。**查询中国指定分区键时，clickhouse会自动截取分区数据，能有效增加查询性能。
支持数据副本
支持数据采样。如果需要的话，可以给表设置一个采样方式。
详细研究见：https://clickhouse.com/docs/zh/engines/table-engines/mergetree-family/mergetree/
注意：由于clickhouse的表引擎MergeTree采用了分区合并策略。而合并的时间大概在10~15分钟，因此如果不想等待需要进行手动处理即执行以下指令：
optimize table t_stock final;
5. ClickHouse迁移方案（MySql）：
以下为基于mysql的迁移方案
实际在接到迁移任务后进行的资料查询，资料搜索未经过严谨推敲，方案仅供参考！
5.1 方案1：
CREATE TABLE bigscreen_config
ENGINE = MergeTree
ORDER BY id AS
SELECT * FROM mysql('47.94.81.27:3306', 'eiot_bi', 'bigscreen_config', 'root', 'xxxx');
通过连接mysql进行数据库的迁移，主要问题是clickhouse大小写敏感，从mysql直接转到clickhouse的时候会把小写变成大写。这样无法很好的兼容原有的业务代码，因此作为备选方案。
5.2 方案2：
利用cvs格式来迁移数据
本次只测试了Dbeaver的批量cvs导入功能，结果并不尽如人意。在clickhouse处理相关数字信息时，会出现错误。
5.3 方案3：
重新建库建表，完成clickhouse的整体创建。
个人比较推荐此种方式，因为这个建库建表后我们可以有针对性的对sql进行优化。并且如果不考虑消耗的时间的话，我认为这种方式可以大大增加我们对clickhouse的理解。
5.4 方案4：
CREATE DATABASE IF NOT EXISTS eiot_manager ENGINE = MySQL('127.0.0.1:3306',
'mysql', 'root', 'root')；
此方式只是做了mysql的映射，并没有实际保存在clickhouse中，性能问题没有改变，因此否定此方案。
5.5 方案5：
-- 先建表
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = engine
-- 导入数据
INSERT INTO [db.]table [(c1, c2, c3)] select 列或者* from mysql('host:port', 'db', 'table_name', 'user', 'password')
此方案类似方案1，可以优先考虑方案1。
5.6 方案6：
Altinity/clickhouse-mysql-data-reader
Altinity 公司开源的一个 python 工具，用来从 mysql 迁移数据到 clickhouse(支持 binlog 增量更新和全量导入)，但是官方 readme 和代码脱节，根据 quick start 跑不通。
5.6.1 创建表:
clickhouse-mysql \
--src-host=127.0.0.1 \
--src-user=reader \
--src-password=Qwerty1# \
--table-templates-with-create-database \
--src-table=airline.ontime > create_clickhouse_table_template.sql
5.6.2 修改脚本:
vim create_clickhouse_table_template.sql
5.6.3 导入建表:
clickhouse-client -mn < create_clickhouse_table_template.sql
5.6.4 数据导入:
clickhouse-mysql \
--src-host=127.0.0.1 \
--src-user=reader \
--src-password=Qwerty1# \
--table-migrate \
--dst-host=127.0.0.1 \
--dst-table=logunified \
--csvpool
官方文档: https://github.com/Altinity/clickhouse-mysql-data-reader#mysql-migration-case-1—migrate-existing-data
5.7 方案7：
streamsets
此方案为尝试使用，可以后续进行评估。
6. 关于mysql迁移到clickhouse需要准备的工作：
6.1 mysql和clickhouse语法的区分：
数据修改对应update和delete操作。clickhouse也提供了这两个操作的能力，但是在clickhouse中，对数据的修改和删除是非常"重"的操作，因为对应的目标数据 需要放弃原有的分区，重建新的临时分区，然后还要进行大量的合并。在语句执行过程中，只是将原有的数据打上逻辑上的删除标记，然后新增数据放入新的分区。 直到触发分区合并的时候，才会删除旧的数据。频繁的update和delete操作会加大 服务器的负担。
在clickhouse中，数据变更操作被称为Mutation查询，他被作为alter指令的一部 分，即对表进行变更。实际上，你会发现，在官方文档上SQL部分都没有列出 UPDATE和DELETE语句。通常情况下，这类Mutation操作都要交由运维人员来完成。普通用户更多的只需要关注数据的查询与分析，尽量避免不必要的数据变更操作。
-- 删除操作
alter table bi_dim_administrative_area delete where id='1';
-- 修改操作
alter table bi_dim_administrative_area update administrative_area_code=630000 where id=2;
6.2 mysql和clickhouse数据库引擎的区分：
6.2.1 mysql:
MyISAM：这种引擎是mysql最早提供的。这种引擎又可以分为静态MyISAM、动态MyISAM 和压缩MyISAM三种：
静态MyISAM：如果数据表中的各数据列的长度都是预先固定好的，服务器将自动选择这种表类型。因为数据表中每一条记录所占用的空间都是一样的，所以这种表存取和更新的效率非常高。当数据受损时，恢复工作也比较容易做。
动态MyISAM：如果数据表中出现varchar、xxxtext或xxxBLOB字段时，服务器将自动选择这种表类型。相对于静态MyISAM，这种表存储空间比较小，但由于每条记录的长度不一，所以多次修改数据后，数据表中的数据就可能离散的存储在内存中，进而导致执行效率下降。同时，内存中也可能会出现很多碎片。因此，这种类型的表要经常用optimize table 命令或优化工具来进行碎片整理。
压缩MyISAM：以上说到的两种类型的表都可以用myisamchk工具压缩。这种类型的表进一步减小了占用的存储，但是这种表压缩之后不能再被修改。另外，因为是压缩数据，所以这种表在读取的时候要先时行解压缩。
但是，不管是何种MyISAM表，目前它都不支持事务，行级锁和外键约束的功能。
MyISAM Merge引擎：这种类型是MyISAM类型的一种变种。合并表是将几个相同的MyISAM表合并为一个虚表。常应用于日志和数据仓库。
InnoDB：InnoDB表类型可以看作是对MyISAM的进一步更新产品，它提供了事务、行级锁机制和外键约束的功能。
memory(heap)：这种类型的数据表只存在于内存中。它使用散列索引，所以数据的存取速度非常快。因为是存在于内存中，所以这种类型常应用于临时表中。
**archive：**这种类型只支持select 和 insert语句，而且不支持索引。常应用于日志记录和聚合分析方面。
当然MySql支持的表类型不止上面几种。
6.2.1 clickhouse:
库引擎： Atomic、mysql等
表引擎： MergeTree、Log、Integration Engines、Special Engines等
6.3 改造整体流程：
- 完成数据库库表建设
- 完成bi库相关数据的整理
- 对需要update和delete以及时间函数相关sql进行改造
- 测试修改
- 完成改造
需要注意的是在clickhouse中标准sql的join语法可以兼容，但是可以进行优化。应该遵循join前是大表join后是小表的原则，主要原因是会将join后的表写入内存中进行读取。
7. 总结：
数据库迁移需要明确要选用哪种clickhouse数据库引擎，例如MegerTree引擎，通过学习对应引擎的语法规则，进行数据库迁移的开发。其中clickhouse并不兼容mysql的部分函数，需要进行对应的转义修改。其次，clickhouse部分的数据字段类型和mysql也不相同，因此需要注意。最后，例如MegerTree引擎非实时的更新，需要手动调用刷新或者通过version字段进行控制。
以上就是本次clickhouse的配置搭建和应用以及迁移mysql数据库的各种方案和注意问题，欢迎大家多多点赞多多收藏哦~