一：简介

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

简称CK, 与Hadoop, Spark相比，ClickHouse很轻量级,由俄罗斯第一大搜索引擎Yandex于2016年6月15日开源, 开发语言为C++。这对保守俄罗斯人来说是个特大事。更让人惊讶的是，这个列式存储数据库的跑分要超过很多流行的商业MPP数据库软件，例如Vertica。（如果你没有听过Vertica，那你一定听过 Michael Stonebraker，2014年图灵奖的获得者，PostgreSQL和Ingres发明者（Sybase和SQL Server都是继承Ingres而来的）, Paradigm4和SciDB的创办者。Michael Stonebraker于2005年创办Vertica公司，后来该公司被惠普收购，惠普 Vertica成为MPP列式存储商业数据库的高性能代表，Facebook就购买了Vertica数据用于用户行为分析）。简单的说，ClickHouse作为分析型数据库，有三大特点：一是跑分快，二是功能多，三是文艺范

Yandex.Metrica目前已经成为世界第三大Web流量分析平台，每天处理超过200亿个跟踪事件。能够拥有如此惊人的体量，在它背后提供支撑的ClickHouse功不可没。ClickHouse已经为Yandex.Metrica存储了超过20万亿行的数据，90%的自定义查询能够在1秒内返回，其集群规模也超过了400台服务器。

与Hadoop生态的其他数据库相比，ClickHouse更像一款"传统"MPP架构的数据库，它没有采用Hadoop生态中常用的主从架构，而是使用了多主对等网络结构，同时它也是基于关系模型的ROLAP方案。如果把数据库比作汽车，那么ClickHouse俨然就是一辆手动挡的赛车。

ClickHouse的特点:

1.真正的面向列的DBMS

在一个真正的面向列的DBMS中，没有任何“垃圾”存储在值中。

作为一个DBMS，它具备了一些基本功能，如下所示。

DDL ( 数据定义语言 )：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。

DML ( 数据操作语言 )：可以动态查询、插入、修改或删除数据。

权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。

数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。

分布式管理：提供集群模式，能够自动管理多个数据库节点。

这里只列举了一些最具代表性的功能，但已然足以表明为什么Click House称得上是DBMS了。

2.数据压缩

ClickHouse就是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存 ( 这里主要指MergeTree表引擎 )。数据默认使用LZ4算法压缩，在Yandex.Metrica的生产环境中，数据总体的压缩比可以达到8:1 ( 未压缩前17PB，压缩后2PB )。列式存储除了降低IO和存储的压力之外，还为向量化执行做好了铺垫。

3.磁盘存储的数据

许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使用SSD和内存，它也会合理的利用这些资源。

4.多核并行处理

多核多节点并行化大型查询。

5.在多个服务器上分布式处理

上面列出的列式DBMS几乎都不支持分布式处理。在ClickHouse中，数据可以驻留在不同的分片上。每个分片可以是用于容错的一组副本。查询在所有分片上并行处理。这对用户来说是透明的。

6.SQL支持

ClickHouse支持基于SQL的声明式查询语言，该语言大部分情况下是与SQL标准兼容的。

支持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及非相关子查询。

不支持窗口函数和相关子查询。

7.向量化引擎

数据不仅按列存储，而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。

向量化执行，可以简单地看作一项消除程序中循环的优化。

为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 )，它的原理是在CPU寄存器层面实现数据的并行操作。

在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如图1所示。一个实用的经验告诉我们，存储媒介距离CPU越近，则访问数据的速度越快。

从上图中可以看到，从左向右，距离CPU越远，则数据的访问速度越慢。从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的3000万倍。

所以利用CPU向量化执行的特性，对于程序的性能提升意义非凡。

8.实时数据更新

ClickHouse支持主键表。为了快速执行对主键范围的查询，数据使用合并树(MergeTree)进行递增排序。由于这个原因，数据可以不断地添加到表中。添加数据时无锁处理。

9.索引

例如，带有主键可以在特定的时间范围内为特定客户端（Metrica计数器）抽取数据，并且延迟时间小于几十毫秒。

10.支持在线查询

这让我们使用该系统作为Web界面的后端。低延迟意味着可以无延迟实时地处理查询，而Yandex.Metrica界面页面正在加载（在线模式）。

11.支持近似计算

<1>系统包含用于近似计算各种值，中位数和分位数的集合函数。

<2>支持基于部分（样本）数据运行查询并获得近似结果。在这种情况下，从磁盘检索比例较少的数据。

<3>支持为有限数量的随机密钥（而不是所有密钥）运行聚合。在数据中密钥分发的特定条件下，这提供了相对准确的结果，同时使用较少的资源。

12.数据复制和对数据完整性的支持。

使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复

clickHouse的性能:

低延迟：对于数据量（几千行，列不是很多）不是很大的短查询，如果数据已经被载入缓存，且使用主码，延迟在50MS左右。
并发量：虽然 ClickHouse 是一种在线分析型数据库，也可支持一定的并发。当单个查询比较短时，官方建议 100 Queries / second。
写入速度：在使用 MergeTree 引擎的情况下，写入速度大概是 50 - 200 M / s，如果按照 1 K 一条记录来算，大约每秒可写入 50000 ~ 200000 条记录每秒。如果每条记录比较小的话写入速度会更快

其主要的应用场景:

<1>读多于写

<2>大宽表，读大量行但是少量列，结果集较小

<3>数据批量写入，且数据不更新或少更新

<4>无需事务，数据一致性要求低

<5>灵活多变，不适合预先建模

多用于结构良好清晰且不可变的事件或日志流分析

需要注意的是: 由于clickHouse不支持事务操作, 顾不能作为传统数据库来使用(OLTP),以及高请求率的键值访问，Blob或文档存储，超标准化数据。

缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据

稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。

二，架构

核心模块如下：

具体参考官网：https://clickhouse.tech/docs/zh/development/architecture/

三，引擎（表级）

不同的引擎用各种不同的技术存储在文件(或者内存)中。

这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平。

1. TinyLog

最简单的一种引擎，每一列保存为一个文件，里面的内容是压缩过的，不支持索引，没有并发控制。所以，当你需要在读，又在写时，读会出错。并发写，内容都会坏掉。应用场景基本上就是那种只写一次，然后就是只读的场景。同时，它也不适用于处理量大的数据，官方推荐，使用这种引擎的表最多 100 万行的数据。因为这种引擎的实现非常简单，所以当你有很多很多的小表数据要处理时，使用它是比较合适的，最基本的，它在磁盘上的文件量很少，读一列数据只需要打开一个文件就好了。

2. Log

TinyLog 基本一致，它的改进点，是加了一个 __marks.mrk 文件，里面记录了每个数据块的偏移，这种做的一个用处，就是可以准确地切分读的范围，从而使用并发读取成为可能。但是，它是不能支持并发写的，一个写操作会阻塞其它读写操作。

3. Merge

工具引擎，本身不保存数据，类似视图，只用于把指定库中的指定多个表链在一起。这样，读取操作可以并发执行，同时也可以利用原表的索引，但是，此引擎不支持写操作。指定引擎的同时，需要指定要链接的库及表，库名可以使用一个表达式，表名可以使用正则表达式指定。 _table 这个列，是因为使用了 Merge 多出来的一个的一个虚拟列，它表示原始数据的来源表，它不会出现在 show table 的结果当中，同时， select * 不会包含它。

4. Distributed

Merge 可以看成是单机版的 Distributed ，而真正的 Distributed 具备跨服务器能力，当然，机器地址的配置依赖配置文件中的信息。

5. Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，不支持索引，简单查询下有非常非常高的性能表现，一般用来测试 Buffer：像是 Memory 存储的一个上层应用似的（磁盘上也是没有相应目录的）。它的行为是一个缓冲区，写入的数据先被放在缓冲区，达到一个阈值后，这些数据会自动被写到指定的另一个表中。没有索引。可以设置阈值，若一次性数据量大于阈值，则直接写入表。“友好重启”时， Buffer 数据会先落到源表，“暴力重启”， Buffer 表中的数据会丢失。

6. Null

空引擎，写入的任何数据都会被忽略，读取的结果一定是空。

7. Set

只用在 IN 操作符右侧，你不能对它 select。语法比较复杂，是全内存运行的，但是相关数据会落到磁盘上保存，启动时会加载到内存中

8. Join

跟 Set 类似只用在join右侧

9. MergeTree

支持一个日期和一组主键的两层式索引，可以实时更新数据，支持直接采样功能。tree /data/clickhouse/data/default/ 文件在/data/clickhouse/data/default(schema)/(tablename)/.bin(列文件) .mrk(块偏移量) primary.idx主键索引。

10. ReplacingMergeTree

在 MergeTree 的基础上，添加了“处理重复数据”的功能,在最后加一个“版本列”，它跟时间列配合一起，用以区分哪条数据是“新的”，并把旧的丢掉（这个过程是在 merge 时处理，不是数据写入时就处理了的，平时重复的数据还是保存着的，并且查也是跟平常一样会查出来的，所以在 SQL 上排序过滤 Limit 什么的该写还是要写的）。同时，主键列组用于区分重复的行。“版本列”允许的类型是， UInt 一族的整数，或 Date 或 DateTime。

11. SummingMergeTree

就是在 merge 阶段把数据加起来了，当然，哪些列要加（一般是针对可加的指标）可以配置，不可加的列，会取一个最先出现的值。可加列不能是主键中的列，并且如果某行数据可加列都是 null ，则这行会被删除。

12. AggregatingMergeTree

聚合数据的预计算，聚合数据的增量计算的情况。对于 AggregatingMergeTree 引擎的表，不能使用普通的 INSERT 去添加数据，那怎么办？一方面可以用 INSERT SELECT 来插入数据，更常用的，是可以创建一个物化视图。

四，稀疏索引

四维云10.60.150.218服务器

tree /data/clickhouse/data/default/

图上左边的结构图为/data/clickhouse/data/default(schema)/(tablename)/.bin(列文件) .mrk(块偏移量) primary.idx主键索引

主键是有序数据的稀疏索引。我们用图的方式看一部分的数据（原则上，图中应该保持标记的平均长度，但是用ASCI码的方式不太方便）。 mark文件，就像一把尺子一样。主键对于范围查询的过滤效率非常高。对于查询操作，CK会读取一组可能包含目标数据的mark文件。

MergeTree引擎中，默认的index_granularity(索引粒度)设置是8192；

在CH里，主键索引用的并不是B树，而是稀疏索引。

每隔8192行数据，是1个block 主键会每隔8192，取一行主键列的数据，同时记录这是第几个block 查询的时候，如果有索引，就通过索引定位到是哪个block，然后找到这个block对应的mrk文件 mrk文件里记录的是某个block的数据集，在整列bin文件的哪个物理偏移位置加载数据到内存，之后并行化过滤索引长度越低，索引在内存中占的长度越小，排序越快，然而区分度就越低。这样不利于查找。索引长度越长，区分度就高，虽然利于查找了，但是索引在内存中占得空间就多了。

五，搭建

官网 https://clickhouse.tech/#quick-start

clickhouse集群的理想方案是如下所示：

这里有3个集群，每个集群n个节点，每个节点的数据依靠zookeeper协调同步，比如cluster1提供服务，如果cluster1里面挂掉多台机器那么cluster2的副本可以切换过来提供服务，如果cluster2的分片再挂了，那么cluster3中的副本也可以提供服务，cluster1~3同时挂掉的概率就非常小了，所以集群的稳定性可以非常高，其中单个集群的节点个数n决定了clickhouse的性能，性能是可以线性扩展的，具体副本集群的个数根据机器资源配置.

如果机器资源确实特别少，想每个节点都用上提供服务的话，那么可以每个节点存储两个以上的副本，即提供服务的分片和其他机器的副本，实现相互备份，但是clickhouse不支持单个节点多个分片的配置，我们可以人为设置在每个节点上启动两个实例来实现，设计图如下：

可以看出来3个节点每个节点的tcp 9000对外提供服务，9001提供副本，其中2提供1的备份，3提供2的备份，1提供3的备份，这样假设挂掉1个节点，集群也可以正常使用，但是挂掉2个几点，就不正常了，这样的话是机器越多越稳定一些.

上面两种方案，官网上还是推荐的第一种方案可用性最高，这里为了演示采用第二种方式配置，其实两种方式的配置是完全一样的，

(10.60.150.218,10.60.150.219) 服务器单机搭建 version 20.5.4

1，root安装

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/clickhouse.repo

sudo yum install clickhouse-server clickhouse-client

修改配置文件

ClickHouse有几核心的配置文件：

config.xml 端口配置、本地机器名配置、内存设置等

metrika.xml 集群配置、ZK配置、分片配置等（这些配置也可直接配置到config.xml ）

users.xml 权限、配额设置

单机部署需要修改以下文件

/etc/clickhouse-server/config.xml

替换文件中/var/lib/clickhouse/为/data/clickhouse/ （/data/clickhouse/为数据存储目录）

修改服务器的配置文件/etc/clickhouse-server/config.xml，第65行，放开注释即可（放开远程访问）

<listen_host>::</listen_host>

修改 /etc/clickhouse-server/users.xml （单次查询使用的最大内存量）

<max_memory_usage>10000000000</max_memory_usage>

每个个节点多实例多副本集群部署需要修改以下文件

具体为什么这样配置可以参考clickhouse-server/config.xml就能明白，有这么一段被注释的配置说明：

<!-- If element has 'incl' attribute, then for it's value will be used corresponding substitution from another file.

By default, path to file with substitutions is /etc/metrika.xml. It could be changed in config in 'include_from' element.

Values for substitutions are specified in /yandex/name_of_substitution elements in that file.

-->

<1>复制启动脚本，启动脚本路径：/etc/init.d/clickhouse-server

cp /etc/init.d/clickhouse-server /etc/init.d/clickhouse-server2

主要修改clickhouse-server2脚本中配置文件位置和pid文件位置

配置文件比如使用config1.xml，pid使用clickhouse-server-1.pid

<2>修改 /etc/clickhouse-server/config.xml

进入到配置文件目录，将原有配置文件拷贝一份，这里是config1.xml，

首先 cp /etc/clickhouse-server/config.xml /etc/clickhouse-server/config1.xml

然后重点修改配置：

主要修改内容是：日志文件(和之前不要冲突)、http端口、tcp端口、副本同步端口

(这个改完之后clickhouse按照当前实例的端口自动和其他实例同步)、数据文件和tmp目录、users.xml(这个如果都一样可以用同一个)、

最后就是集群配置了，下面重点叙述：

集群配置默认为：<remote_servers incl="clickhouse_remote_servers" />

zookeeper默认为：<zookeeper incl="zookeeper-servers" optional="true" />

macros默认为：<macros incl="macros" optional="true" />

首先是集群分片的配置，这个配置所有节点的所有实例完全保持一致：

<remote_servers>

<perftest_2shards_2replicas>

<shard>

<internal_replication>true</internal_replication>

</replica>

</replica>

</shard>

<shard>

<internal_replication>true</internal_replication>

</replica>

</replica>

</shard>

</perftest_2shards_2replicas>

</remote_servers>

配置里面的<perftest_2shards_2replicas>是分布式标识标签，可以自定义，到最后创建分布式表的时候会用到；然后weight是分片权重，

即写数据时有多大的概率落到此分片，因为这里所有分片权重相同所有都设置为1，然后是internal_replication，表示是否只将数据写入

其中一个副本，默认为false，表示写入所有副本，在复制表的情况下可能会导致重复和不一致，所以这里一定要改为true，clickhouse分

布式表只管写入一个副本，其余同步表的事情交给复制表和zookeeper来进行，然后是replica配置这个好理解，就是一个分片下的所有副本，

这里副本的分布一定要手动设计好，保证相互备份，然后再次说明是所有的节点配置一致. 此部分配置严格按照官网配置，

参考链接：https://clickhouse.yandex/docs/en/operations/table_engines/distributed/

然后是zookeeper配置，这个也是所有示例配置都一样：

</node>

</node>

</node>

</zookeeper>

然后是复制标识的配置，也称为宏配置，这里唯一标识一个副本名称，每个实例都要配置并且都是唯一的，这里配置如下：

clickhouse1 9000 分片1, 副本1:

<replica>cluster01-01-1</replica>

</macros>

clickhouse1 9001 分片2, 副本2:

<replica>cluster01-02-2</replica>

clickhouse2 9000 分片2, 副本1:

<replica>cluster01-02-1</replica>

</macros>

clickhouse2 9001 分片1, 副本2:

<replica>cluster01-01-2</replica>

</macros>

由上面配置可以看到replica的分布规律，其中layer是双级分片设置，在Yandex公司的集群中用到，

因为我们这里是单集群所以这个值对我们没有影响全部一样即可，这里是01；然后是shard表示分片编号；

最后是replica是副本标识，这里使用了cluster{layer}-{shard}-{replica}的表示方式，比如cluster01-02-1表示cluster01

集群的02分片下的1号副本，这样既非常直观的表示又唯一确定副本. 副本的文档链接下面会给出.

3,启动服务

sudo /etc/init.d/clickhouse-server start

sudo /etc/init.d/clickhouse-server2 start

登录客户端

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

Clickhouse-client

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

clickhouse-client --host 10.60.150.218 --port 9000

clickhouse-client --host 10.60.150.218 --port 9001

clickhouse-client --host 10.60.150.219 --port 9000

clickhouse-client --host 10.60.150.219 --port 9001

4.验证集群

在每个节点启动clickhouse客户端，和单节点启动完全一样，查询集群信息

select * from system.clusters;

六，单机使用

1，建表

CREATE TABLE fact_user_trip_info(

trip_id String,

user_id String,

start_times Int64,

start_lon_lat String,

end_times Int64,

end_lon_lat String,

data_dt date

) ENGINE MergeTree() PARTITION BY toYYYYMM(data_dt) ORDER BY (user_id,trip_id) SETTINGS index_granularity=8192;

举例：

ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity=8192

ENGINE - 引擎名和参数。 ENGINE = MergeTree(). MergeTree 引擎没有参数。

PARTITION BY — 分区键。

要按月分区，可以使用表达式 `toYYYYMM(date_column)` ，这里的 `date_column` 是一个 [Date](../../../engines/table_engines/mergetree_family/mergetree.md) 类型的列。这里该分区名格式会是 `"YYYYMM"` 这样。

ORDER BY — 表的排序键。

可以是一组列的元组或任意的表达式。例如: `ORDER BY (CounterID, EventDate)` 。

PRIMARY KEY - 主键，(如果要设成跟排序键不相同的话设置，默认情况和排序键相同)。

默认情况下主键跟排序键（由 `ORDER BY` 子句指定）相同。

因此，大部分情况下不需要再专门指定一个 `PRIMARY KEY` 子句。

SAMPLE BY — 用于抽样的表达式。

如果要用抽样表达式，主键中必须包含这个表达式。例如：

`SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID))` 。

SETTINGS — 影响 MergeTree 性能的额外参数：

index_granularity — 索引粒度。即索引中相邻『标记』间的数据行数。默认值，8192 。该列表中所有可用的参数可以从这里查看 MergeTreeSettings.h 。

index_granularity_bytes — 索引粒度，以字节为单位，默认值: 10Mb。如果仅按数据行数限制索引粒度, 请设置为0(不建议)。

enable_mixed_granularity_parts — 启用或禁用通过 index_granularity_bytes 控制索引粒度的大小。在19.11版本之前, 只有 index_granularity 配置能够用于限制索引粒度的大小。

当从大表(数十或数百兆)中查询数据时候，index_granularity_bytes 配置能够提升ClickHouse的性能。如果你的表内数据量很大，可以开启这项配置用以提升SELECT 查询的性能。

use_minimalistic_part_header_in_zookeeper — 数据片段头在 ZooKeeper 中的存储方式。如果设置了 use_minimalistic_part_header_in_zookeeper=1 ，ZooKeeper 会存储更少的数据。

min_merge_bytes_to_use_direct_io — 使用直接 I/O 来操作磁盘的合并操作时要求的最小数据量。合并数据片段时，ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了

min_merge_bytes_to_use_direct_io 设置的字节数，则 ClickHouse 将使用直接 I/O 接口（O_DIRECT 选项）对磁盘读写。如果设置 min_merge_bytes_to_use_direct_io = 0 ，则会禁用直接 I/O。

默认值：10 * 1024 * 1024 * 1024 字节。

merge_with_ttl_timeout — TTL合并频率的最小间隔时间。默认值: 86400 (1 天)。

write_final_mark — 启用或禁用在数据片段尾部写入最终索引标记。默认值: 1（不建议更改）。

storage_policy — 存储策略。

2，准备数据

下载hive行程数据作为测试数据（206395条）

INSERT OVERWRITE local DIRECTORY '/home/big_data/biwenjun/ckdata'

ROW FORMAT DELIMITED FIELDS TERMINATED BY','

select

trip_id

,uid

,start_times

,regexp_replace(start_lon_lat,',',':')

,end_times

,regexp_replace(end_lon_lat,',',':')

,from_unixtime(unix_timestamp(data_dt,'yyyyMMdd'),'yyyy-MM-dd')

from fact_user_trip_info_dt

distribute by 1;

复制数据到clickhouse 所在服务器

scp -rv test.csv big_data@10.60.150.218:/home/big_data/biwenjun/clickhouse

3，导入CSV文件数据

cat test.csv | clickhouse-client --query="insert into default.fact_user_trip_info FORMAT CSV"

4，查询数据

echo 'select * from default.fact_user_trip_info' | clickhouse-client

七，集群使用

CK是如何实现分布式的

CK的分布式，完全依赖配置文件，即每个节点，都共享同样的配置文件，这个配置文件里，写了我跟谁是一个cluster的，我自己的名字是啥

集群怎么用?

答案是指定引擎

CK里的引擎有十几个，这里只推荐3个：

MergeTree，是CK里最Advanced的引擎，性能超高，单机写入可以达到50w峰值，查询性能非常快，有兴趣看我其他文章

ReplicatedMergeTree，基于MergeTree，同时引入ZK，做了复制，下文会说

Distributed，分布式引擎，本身不存储数据，可认为就是一张View，如果写入，会把请求丢到集群里的节点（有算法控制），如果查询，会帮你做查询转发再聚合返回

高可用原理：zookeeper + ReplicatedMergeTree(复制表) + Distributed(分布式表)

采用 ReplicatedMergeTree + Distributed引擎作为集群结构的引擎

ReplicatedMergeTree(zoo_path, replica_name,partition,primykey,8192)

zoo_path,zk路径(自动在zookeeper中创建)，如果要相互复制，必须一样,

replica_name'副本名称, 必须不一样,

partition,分区

primykey,含有主键相关字段的元组，可以为单独列

8192,索引粒度)

Distributed(cluster, datebase, local_table, sharding_key)

cluster,需要写成在config里自定义的cluster名称

database,是分片数据库的名称

local_table,是分片本地表的名称 -最后一项sharding_key是选填的，可以是一个表达式，

例如rand()，也可以是某列如user_id，不过该列必须是integer类型，

通过对该具体的值进行取余进行分片，如果担心这样没法均匀的进行分片，也可以加上hash函数，如intHash64(user_id)

1，建表

登录四个实例客户端

clickhouse-client --host 10.60.150.218 --port 9000

clickhouse-client --host 10.60.150.218 --port 9001

clickhouse-client --host 10.60.150.219 --port 9000

clickhouse-client --host 10.60.150.219 --port 9001

每个实例创建库

create database cktest;

use cktest;

各自创建表

实例1 9000

CREATE TABLE cktest.fact_user_trip_info_repli( \

trip_id String, \

user_id String, \

start_times Int64, \

start_lon_lat String, \

end_times Int64, \

end_lon_lat String, \

data_dt date \

) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-01/fact_user_trip_info_repli','cluster01-01-1',data_dt,(trip_id, data_dt),8192);

实例1 9001

CREATE TABLE cktest.fact_user_trip_info_repli( \

trip_id String, \

user_id String, \

start_times Int64, \

start_lon_lat String, \

end_times Int64, \

end_lon_lat String, \

data_dt date \

) ENGINE = ReplicatedMergeTree('/clickhouse/tables/02-01/fact_user_trip_info_repli','cluster01-02-2',data_dt,(trip_id, data_dt),8192);

实例2 9000

CREATE TABLE cktest.fact_user_trip_info_repli( \

trip_id String, \

user_id String, \

start_times Int64, \

start_lon_lat String, \

end_times Int64, \

end_lon_lat String, \

data_dt date \

) ENGINE = ReplicatedMergeTree('/clickhouse/tables/02-01/fact_user_trip_info_repli','cluster01-02-1',data_dt,(trip_id, data_dt),8192);

实例2 9001

CREATE TABLE cktest.fact_user_trip_info_repli( \

trip_id String, \

user_id String, \

start_times Int64, \

start_lon_lat String, \

end_times Int64, \

end_lon_lat String, \

data_dt date \

) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-01/fact_user_trip_info_repli','cluster01-01-2',data_dt,(trip_id, data_dt),8192);

注意引号部分只能用单引号，其中核心的地方是同一个分片在zookeeper上面的znode相同

创建分布式表，分布式表只是作为一个查询引擎，本身不存储任何数据，查询时将sql发送到所有集群分片，然后进行进行处理和聚合后将结果返回给客户端，因此clickhouse限制聚合结果大小不能大于分布式表节点的内存，当然这个一般条件下都不会超过；分布式表可以所有实例都创建，也可以只在一部分实例创建，这个和业务代码中查询的示例一致，建议设置多个，当某个节点挂掉时可以查询其他节点上的表，分布式表的建表语句如下：

CREATE TABLE fact_user_trip_info_all AS fact_user_trip_info_repli ENGINE = Distributed(perftest_2shards_2replicas, cktest, fact_user_trip_info_repli, rand());

2,准备数据

INSERT OVERWRITE local DIRECTORY '/home/big_data/biwenjun/ckdata/test'

ROW FORMAT DELIMITED FIELDS TERMINATED BY','

select

trip_id

,uid

,start_times

,regexp_replace(start_lon_lat,',',':')

,end_times

,regexp_replace(end_lon_lat,',',':')

,'2020-08-25'

from fact_user_trip_info_dt

distribute by 1;

复制数据到clickhouse 所在服务器

scp 20200825.csv root@s03:/home/big_data/biwenjun/ckdata

3，导入CSV文件数据

cat 20200825.csv | clickhouse-client --query="insert into cktest.fact_user_trip_info_repli FORMAT CSV"

4，查询数据

select * from fact_user_trip_info_all where data_dt='2018-08-25' limit 1;

clickhouse 入门介绍和预演相关推荐

《ClickHouse入门、实战与进阶》的创作之路
写作不是思考的记录,写作就是思考本身. --理查德·费曼目录写作的重要性写作之路 OLAP技术对于企业决策者.数据分析师等至关重要分享一些经验最后写作的重要性本文开头借用了费曼的名言来表 ...
.NET读写Excel工具Spire.Xls使用(1)入门介绍
原文:[原创].NET读写Excel工具Spire.Xls使用(1)入门介绍在.NET平台,操作Excel文件是一个非常常用的需求,目前比较常规的方法有以下几种: 1.Office Com组件的方式 ...
独家 | 集成学习入门介绍
作者:Jason Brownlee 翻译:wwl 校对:王琦本文约3300字,建议阅读8分钟. 本文介绍了我们在生活中的许多决定包括了其他人的意见,由于群体的智慧,有的时候群体的决策优于个体.在机器 ...
SpringBoot 2.0 系列001 -- 入门介绍以及相关概念
为什么80%的码农都做不了架构师?>>> SpringBoot 2.0 系列001 -- 入门介绍以及相关概念什么是SpringBoot? 项目地址:http://proje ...
ECC加密算法入门介绍
作者 : ZMWorm[CCG] E-Mail: zmworm@sohu.com 主页 : Http://ZMWorm.Yeah.Net/ 前言同RSA(Ron Rivest,Adi S ...
[翻译][1.4.2]Flask-Admin入门介绍
为什么80%的码农都做不了架构师?>>> #Flask-Admin入门介绍 ##让我们荡起双桨初始化 Introduction To Flask-Admin Getting ...
谷歌大脑科学家亲解 LSTM：一个关于“遗忘”与“记忆”的故事本文作者：奕欣 2017-01-14 09:46 导语：AI科技评论保证这是相对通俗易懂的一篇入门介绍了，看不懂的话欢迎关注「AI 科技
谷歌大脑科学家亲解 LSTM:一个关于"遗忘"与"记忆"的故事本文作者:奕欣 2017-01-14 09:46 导语:AI科技评论保证这是相对通俗易懂的一篇入 ...
Tomcat容器入门介绍
Tomcat容器入门介绍 Tomcat环境配置 PS:JDK的安装这里就不讲了,找到安装包直接下一步下一步就行了. 1.配置JDK 在Windows10下,找到环境变量在环境变量中添加JDK主目录 ...
QWT中Qdial的入门介绍
最近使用了一下QWT.因为是第一次使用,所以有一些需要注意的地方,特记录在此,以供后来者参考. 1,QWT的安装与配置环境有关QWT的安装与配置,网络上已经有很多篇文章,这里就不再重复了.介绍一下自 ...
Spring入门介绍：
Spring入门介绍 Spring诞生: 创建Spring的目的就是用来替代更加重量级的的企业级Java技术简化Java的开发基于POJO轻量级和最小侵入式开发通过依赖注入和面向接口实现松耦合 ...

clickhouse 入门介绍和预演

一：简介

二，架构

三，引擎（表级）

四，稀疏索引

五，搭建

六，单机使用

七，集群使用

clickhouse 入门介绍和预演相关推荐

最新文章

热门文章