ClickHouse的入门、使用和优化

ClickHouse是俄罗斯的重要网络服务门户之一Yandex所开源的一套针对数据仓库场景的多维数据存储与检索工具,一个用于联机分析(OLAP)的列式数据库管理系统(DBMS),它通过针对性的设计力图解决海量多维度数据的查询性能问题。

下面,enjoy:

一、数据库的行存与列存

在传统的行式数据库系统中,数据按顺序存储:处于同一行中的数据总是被物理的存储在一起,常见的行式数据库系统有:MySQL、Postgres和MS SQL Server。

行存需要逐行读取而后进行整合,速度较慢

在列式数据库系统中,来自不同列的值被单独存储,来自同一列的数据被存储在一起。列式数据库更适合于OLAP场景(对于大多数查询而言,处理速度至少提高了100倍)。新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。

列存能够快速读取同类型数据,速度较行存有着显著提升

ClickHouse采取的就是列示存储的方式。

二、ClickHouse安装及常用命令参数

1.ClickHouse支持的操作系统和硬件环境

只要是Linux,64位都可以。优先支持Ubuntu,Ubuntu有官方编译好的安装包可以使用。其次是CentOS和RedHat,有第三方组织编译好的rpm包可以使用。

如果是其他Linux系统,需要自己编译源码。

而且,机器的CPU必须支持SSE 4.2指令集。

[root@localhost ~]# grep -q sse4_2 /proc/cpuinfo && echo “SSE 4.2 supported” || echo “SSE 4.2 not supported”


2.ClickHouse的安装方法

(1)RPM安装包

推荐使用CentOS、RedHat和所有其他基于rpm的Linux发行版的官方预编译rpm包。

首先,您需要添加官方存储库:

sudo yum install yum-utils

sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG

sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64

然后运行命令安装:

sudo yum install clickhouse-server clickhouse-client

(2)设置系统参数

CentOS取消打开文件数限制

在/etc/security/limits.conf、/etc/security/limits.d/90-nproc.conf这2个文件的末尾加入以下内容:

* soft nofile 65536

* hard nofile 65536

* soft nproc 131072

* hard nproc 131072

CentOS取消SELINUX

修改/etc/selinux/config中的SELINUX=disabled后重启

关闭防火墙

Centos 6.X:

service iptables stop

service ip6tables stop

Centos 7.X:

chkconfig iptables off

chkconfig ip6tables off

(3)启动连接

启动服务:service clickhouse-server start

连接客户端:clickhouse-client


3.ClickHouse常用命令参数

(1)进入交互式客户端

用clickhouse-client连接本机clickhouse-server服务器:

clickhouse-client -m

用本机clickhouse-client连接远程clickhouse-server服务器:

clickhouse-client –host http://192.168.x.xxx –port 9000 –database default–user default –password ””

启动失败可以查看日志,日志的目录默认为/var/log/clickhouse-server/下。


(2)服务

停止:

service clickhouse-server stop

启动:

service clickhouse-server start

重启:

service clickhouse-server restart


(3) 设置数据目录

vi /etc/clickhouse-server/config.xml

(4) 放开远程访问

vi /etc/clickhouse-server/config.xml

修改服务器的配置文件/etc/clickhouse-server/config.xml,第65行,放开注释即可。

(5) 内存限制设置

vi /etc/clickhouse-server/users.xml

三、ClickHouse引擎介绍

ClickHouse提供了大量的数据引擎,分为数据库引擎、表引擎,根据数据特点及使用场景选择合适的引擎至关重要。

1.ClickHouse引擎分类

在以下几种情况下,ClickHouse使用自己的数据库引擎:

●决定表存储在哪里以及以何种方式存储

●支持哪些查询以及如何支持

●并发数据访问

●索引的使用

●是否可以执行多线程请求

●数据复制参数

在所有的表引擎中,最为核心的当属MergeTree系列表引擎,这些表引擎拥有最为强大的性能和最广泛的使用场合。对于非MergeTree系列的其他引擎而言,主要用于特殊用途,场景相对有限。而MergeTree系列表引擎是官方主推的存储引擎,支持几乎所有ClickHouse核心功能。

MergeTree作为家族系列最基础的表引擎,主要有以下特点:

●存储的数据按照主键排序:允许创建稀疏索引,从而加快数据查询速度

●支持分区,可以通过PRIMARY KEY语句指定分区字段

●支持数据副本

●支持数据采样


2.建表引擎参数

ENGINE:ENGINE = MergeTree(),MergeTree引擎没有参数。

ORDER BY:order by 设定了分区内的数据按照哪些字段顺序进行有序保存。

order by是MergeTree中唯一一个必填项,甚至比primary key 还重要,因为当用户不设置主键的情况,很多处理会依照order by的字段进行处理。

要求:主键必须是order by字段的前缀字段。

如果ORDER BY与PRIMARY KEY不同,PRIMARY KEY必须是ORDER BY的前缀(为了保证分区内数据和主键的有序性)。

ORDER BY 决定了每个分区中数据的排序规则;

PRIMARY KEY 决定了一级索引(primary.idx);

ORDER BY 可以指代PRIMARY KEY, 通常只用声明ORDER BY 即可。

PARTITION BY:分区字段,可选。如果不填:只会使用一个分区。

分区目录:MergeTree 是以列文件+索引文件+表定义文件组成的,但是如果设定了分区那么这些文件就会保存到不同的分区目录中。

PRIMARY KEY:指定主键,如果排序字段与主键不一致,可以单独指定主键字段。否则默认主键是排序字段。可选。

SAMPLE BY:采样字段,如果指定了该字段,那么主键中也必须包含该字段。比如SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID))。可选。

TTL:数据的存活时间。在MergeTree中,可以为某个列字段或整张表设置TTL。当时间到达时,如果是列字段级别的TTL,则会删除这一列的数据;如果是表级别的TTL,则会删除整张表的数据。可选。

SETTINGS:额外的参数配置。可选。


3.建表示例

4.数据导入

clickhouse-client --query "INSERT INTO default.emp_mgetree FORMAT CSV" --max_insert_block_size=100000 < test_data.csv

默认情况下间隔符是 ,


四、ClickHouse的优劣势总结

1.优势

为了高效的使用CPU,数据不仅仅按列存储,同时还按向量进行处理

数据压缩空间大,减少IO。处理单查询高吞吐量每台服务器每秒最多数十亿行

索引非B树结构,不需要满足最左原则,只要过滤条件在索引列中包含即可。即使在使用的数据不在索引中,由于各种并行处理机制ClickHouse全表扫描的速度也很快

写入速度非常快,50-200M/s,对于大量的数据更新非常适用


2.劣势

不支持事务,不支持真正的删除/更新

不支持高并发,官方建议qps为100,在服务器足够好的情况下可以通过修改配置文件增加连接数

SQL满足日常使用80%以上的语法,join写法比较特殊。最新版已支持类似SQL的join,但性能不好

尽量做1000条以上批量的写入,避免逐行insert或小批量的insert,update,delete操作,因为ClickHouse底层会不断的做异步的数据合并,会影响查询性能,这个在做实时数据写入的时候要尽量避开

Clickhouse快是因为采用了并行处理机制,即使一个查询,也会用服务器一半的CPU去执行,所以ClickHouse不能支持高并发的使用场景,默认单查询使用CPU核数为服务器核数的一半,安装时会自动识别服务器核数,可以通过配置文件修改该参数

全量数据导入:数据导入临时表 -> 导入完成后,将原表改名为tmp1 -> 将临时表改名为正式表 -> 删除原表

增量数据导入:增量数据导入临时表 -> 将原数据除增量外的也导入临时表 -> 导入完成后,将原表改名为tmp1-> 将临时表改成正式表-> 删除原数据表


五、ClickHouse使用优化总结

1.数据类型

建表时能用数值型或日期时间型表示的字段,就不要用字符串——全String类型在以Hive为中心的数仓建设中常见,但CK环境不应受此影响。

虽然clickhouse底层将DateTime存储为时间戳Long类型,但不建议直接存储Long类型,因为DateTime不需要经过函数转换处理,执行效率高、可读性好。

官方已经指出Nullable类型几乎总是会拖累性能,因为存储Nullable列时需要创建一个额外的文件来存储NULL的标记,并且Nullable列无法被索引。因此除非极特殊情况,应直接使用字段默认值表示空,或者自行指定一个在业务中无意义的值(例如用-1表示没有商品ID)。


2.分区和索引

分区粒度根据业务特点决定,不宜过粗或过细。一般选择按天分区,也可指定为tuple();以单表1亿数据为例,分区大小控制在10-30个为最佳。

必须指定索引列,clickhouse中的索引列即排序列,通过order by指定,一般在查询条件中经常被用来充当筛选条件的属性被纳入进来;可以是单一维度,也可以是组合维度的索引;通常需要满足高级列在前、查询频率大的在前原则;还有基数特别大的不适合做索引列,如用户表的userid字段;通常筛选后的数据满足在百万以内为最佳。


3.表参数

index_granularity 是用来控制索引粒度的 默认是8192,如非必须不建议调整。

如果表中不是必须保留全量历史数据,建议指定TTL,可以免去手动过期历史数据的麻烦。TTL也可以通过ALTER TABLE语句随时修改。


4.单表查询

使用prewhere替代where关键字;当查询列明显多于筛选列时使用prewhere可十倍提升查询性能。


5.数据采样策略

通过采用运算可极大提升数据分析的性能。

数据量太大时应避免使用select * 操作,查询的性能会与查询的字段大小和数量成线性变换;字段越少,消耗的io资源就越少,性能就会越高。

千万以上数据集进行order by查询时需要搭配where条件和limit语句一起使用。

如非必须不要在结果集上构建虚拟列,虚拟列非常消耗资源浪费性能,可以考虑在前端进行处理,或者在表中构造实际字段进行额外存储。

不建议在高基列上执行distinct去重查询,改为近似去重 uniqCombined。

多表Join时要满足小表在右的原则,右表关联时被加载到内存中与左表进行比较。


6.存储

ClickHouse不支持设置多数据目录,为了提升数据io性能,可以挂载虚拟券组,一个券组绑定多块物理磁盘提升读写性能;多数查询场景SSD盘会比普通机械硬盘快2-3倍。

END

更多干货内容请关注微信公众号“录信数软”~

你可能感兴趣的:(ClickHouse的入门、使用和优化)