ClickHouse 联机分析处理(OLAP)

发表于 | 分类于
字数统计: 13k | 阅读时长 ≈ 49

ClickHouse 的全称是Click Stream，Data WareHouse，简称ClickHouse，是俄罗斯 Yandex 公司于2016年开源的列式存储数据库（DBMS)，主要用于联机分析处理查询（OLAP），能够使用SQL 查询实时生成分析数据报告。

一、OLAP和列式存储

1.1 什么是OLAP

OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

对比项OLAPOLTP
主要使用场景数据分析，挖掘，机器学习在线业务服务
涉及数据量历史存档数据，可能时间跨度比较大当前正在发生的业务数据
事务和数据完整性对事务能力没有要求，数据不一致也可以重建数据对事务和数据一致性要求很高
功能使用需求复杂的聚积和多数据源关联；
查询执行时间可到分钟，小时，天级别		简单的增删改查，要求响应时间极端(ms)
并发要求低并发高并发
技术实现方案大量SCAN；列式存储；存储计算可以分离事务；索引；存储计算在一起
可用性要求要求不高非常高
数据模型/规约纬度模型，关系模型，对范式要求很低关系模型，3NF范式
技术典范SQL-On-HadoopMySQL，Oracle

OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离的这两点，OLAP将不复存在，也就没有优势可言。

OLAP场景的关键特征

  • 绝大多数是读请求；
  • 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新；
  • 已添加到数据库的数据不能修改；
  • 对于读取，从数据库中提取相当多的行，但只提取列的一小部分；
  • 宽表，即每个表包含着大量的列；
  • 查询相对较少(通常每台服务器每秒查询数百次或更少)；
  • 对于简单查询，允许延迟大约50毫秒；
  • 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)；
  • 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)；
  • 事务不是必须的；
  • 对数据一致性要求低；
  • 每个查询有一个大表。除了他以外，其他的都很小；
  • 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中。

很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。

1.2 什么是列式存储

在传统的行式数据库系统中，数据按如下顺序存储：

RowWatchIDJavaEnableTitleGoodEventEventTime
#0893543506621Investor Relations12016-05-18 05:19:20
#1903295099580Contact us12016-05-18 08:10:20
#2899537060541Mission12016-05-18 07:38:00
#N……………

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

在列式数据库系统中，数据按如下的顺序存储：

Row:#0#1#2#N
WatchID:893543506629032950995889953706054…
JavaEnable:101…
Title:Investor RelationsContact usMission…
GoodEvent:111…
EventTime:2016-05-18 05:19:202016-05-18 08:10:202016-05-18 07:38:00…

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。

下图更好的展示了行式存储和列式存储的存储特点

图片1

传统行式数据库的特性如下：
1）数据是按行存储的；
2）没有索引的查询使用大量I/O。比如一般的数据库表都会建立索引，通过索引加快查询效率；
3）建立索引和物化视图需要花费大量的时间和资源；
4）面对查询需求，数据库必须被大量膨胀才能满足需求。

列式数据库的特性如下：
1）数据按列存储，即每一列单独存放；
2）数据即索引；
3）只访问查询涉及的列，可以大量降低系统I/O；
4）每一列由一个线程来处理，即查询的并发处理性能高；
5）数据类型一致，数据特征相似，可以高效压缩。比如有增量压缩、前缀压缩算法都是基于列存储的类型定制的，所以可以大幅度提高压缩比，有利于存储和网络输出数据带宽的消耗。

相比于行式存储，列式存储在分析场景下有着许多优良的特性：
1）分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询；
2）同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本；
3）更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短；
4）自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法；
5）高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

二、ClickHouse 架构概述

2.1 ClickHouse 的核心特性

2.1.1 完备的DBMS功能

ClickHouse拥有完备的数据库管理功能，所以它称得上是一个DBMS（Database Management System，数据库管理系统），而不仅是一个数据库。作为一个DBMS，它具备了一些基本功能，如下所示。
1）DDL（数据定义语言）：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。
2）DML（数据操作语言）：可以动态查询、插入、修改或删除数据。
3）权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
4）数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
5）分布式管理：提供集群模式，能够自动管理多个数据库节点。
这里只列举了一些最具代表性的功能，但已然足以表明为什么Click House称得上是DBMS了。

2.1.2 列式存储与数据压缩

列式存储和数据压缩，对于一款高性能数据库来说是必不可少的特性。一个非常流行的观点认为，如果你想让查询变得更快，最简单且有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储和数据压缩就可以帮助我们实现上述两点。列式存储和数据压缩通常是伴生的，因为一般来说列式存储是数据压缩的前提。
按列存储与按行存储相比，前者可以有效减少查询时所需扫描的数据量，这一点可以用一个示例简单说明。假设一张数据表A拥有50个字段A1～A50，以及100行数据。现在需要查询前5个字段并进行数据分析，则可以用如下SQL实现：

SELECT A1，A2，A3，A4，A5 FROM A

如果数据按行存储，数据库首先会逐行扫描，并获取每行数据的所有50个字段，再从每一行数据中返回A1～A5这5个字段。不难发现，尽管只需要前面的5个字段，但由于数据是按行进行组织的，实际上还是扫描了所有的字段。如果数据按列存储，就不会发生这样的问题。由于数据按列组织，数据库可以直接获取A1～A5这5列的数据，从而避免了多余的数据扫描。
按列存储相比按行存储的另一个优势是对数据压缩的友好性。同样可以用一个示例简单说明压缩的本质是什么。假设有两个字符串abcdefghi和bcdefghi，现在对它们进行压缩，如下所示：

压缩前：abcdefghi_bcdefghi
压缩后：abcdefghi_(9,8)

可以看到，压缩的本质是按照一定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。例如上述示例中的(9,8)，表示如果从下划线开始向前移动9个字节，会匹配到8个字节长度的重复项，即这里的bcdefghi。
真实的压缩算法自然比这个示例更为复杂，但压缩的实质就是如此。数据中的重复项越多，则压缩率越高；压缩率越高，则数据体量越小；而数据体量越小，则数据在网络中的传输越快，对网络带宽和磁盘IO的压力也就越小。既然如此，那怎样的数据最可能具备重复的特性呢？答案是属于同一个列字段的数据，因为它们拥有相同的数据类型和现实语义，重复项的可能性自然就更高。
ClickHouse就是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存（这里主要指MergeTree表引擎）。数据默认使用LZ4算法压缩，在Yandex.Metrica的生产环境中，数据总体的压缩比可以达到8:1（未压缩前17PB，压缩后2PB）。列式存储除了降低IO和存储的压力之外，还为向量化执行做好了铺垫。

2.1.3 向量化执行引擎

坊间有句玩笑，即能用钱解决的问题，千万别花时间。而业界也有种调侃如出一辙，即能升级硬件解决的问题，千万别优化程序。有时候，你千辛万苦优化程序逻辑带来的性能提升，还不如直接升级硬件来得简单直接。这虽然只是一句玩笑不能当真，但硬件层面的优化确实是最直接、最高效的提升途径之一。向量化执行就是这种方式的典型代表，这项寄存器硬件层面的特性，为上层应用程序的性能带来了指数级的提升。
向量化执行，可以简单地看作一项消除程序中循环的优化。这里用一个形象的例子比喻。小胡经营了一家果汁店，虽然店里的鲜榨苹果汁深受大家喜爱，但客户总是抱怨制作果汁的速度太慢。小胡的店里只有一台榨汁机，每次他都会从篮子里拿出一个苹果，放到榨汁机内等待出汁。如果有8个客户，每个客户都点了一杯苹果汁，那么小胡需要重复循环8次上述的榨汁流程，才能榨出8杯苹果汁。如果制作一杯果汁需要5分钟，那么全部制作完毕则需要40分钟。为了提升果汁的制作速度，小胡想出了一个办法。他将榨汁机的数量从1台增加到了8台，这么一来，他就可以从篮子里一次性拿出8个苹果，分别放入8台榨汁机同时榨汁。此时，小胡只需要5分钟就能够制作出8杯苹果汁。为了制作n杯果汁，非向量化执行的方式是用1台榨汁机重复循环制作n次，而向量化执行的方式是用n台榨汁机只执行1次。
为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式（其他的还有指令级并行和线程级并行），它的原理是在CPU寄存器层面实现数据的并行操作。
在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如下图所示。一个实用的经验告诉我们，存储媒介距离CPU越近，则访问数据的速度越快。

图片2

从上图中可以看到，从左向右，距离CPU越远，则数据的访问速度越慢。从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的3000万倍。所以利用CPU向量化执行的特性，对于程序的性能提升意义非凡。
ClickHouse目前利用SSE4.2指令集实现向量化执行。

2.1.4 关系模型与SQL查询

相比HBase和Redis这类NoSQL数据库，ClickHouse使用关系模型描述数据并提供了传统数据库的概念（数据库、表、视图和函数等）。与此同时，ClickHouse完全使用SQL作为查询语言（支持GROUP BY、ORDER BY、JOIN、IN等大部分标准SQL），这使得它平易近人，容易理解和学习。因为关系型数据库和SQL语言，可以说是软件领域发展至今应用最为广泛的技术之一，拥有极高的群众基础。也正因为ClickHouse提供了标准协议的SQL查询接口，使得现有的第三方分析可视化系统可以轻松与它集成对接。在SQL解析方面，ClickHouse是大小写敏感的，这意味着SELECT a和SELECT A所代表的语义是不同的。
关系模型相比文档和键值对等其他模型，拥有更好的描述能力，也能够更加清晰地表述实体间的关系。更重要的是，在OLAP领域，已有的大量数据建模工作都是基于关系模型展开的（星型模型、雪花模型乃至宽表模型）。ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低，可以直接沿用之前的经验成果。

2.1.5 多样化的表引擎

也许因为Yandex.Metrica的最初架构是基于MySQL实现的，所以在ClickHouse的设计中，能够察觉到一些MySQL的影子，表引擎的设计就是其中之一。与MySQL类似，ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。ClickHouse共拥有合并树、内存、文件、接口和其他6大类20多种表引擎。其中每一种表引擎都有着各自的特点，用户可以根据实际业务场景的要求，选择合适的表引擎使用。

2.1.6 多线程与分布式

ClickHouse几乎具备现代化高性能数据库的所有典型特征，对于可以提升性能的手段可谓是一一用尽，对于多线程和分布式这类被广泛使用的技术，自然更是不在话下。
如果说向量化执行是通过数据级并行的方式提升了性能，那么多线程处理就是通过线程级并行的方式实现了性能的提升。相比基于底层硬件实现的向量化执行SIMD，线程级并行通常由更高层次的软件层面控制。现代计算机系统早已普及了多处理器架构，所以现今市面上的服务器都具备良好的多核心多线程处理能力。由于SIMD不适合用于带有较多分支判断的场景，ClickHouse也大量使用了多线程技术以实现提速，以此和向量化执行形成互补。
如果一个篮子装不下所有的鸡蛋，那么就多用几个篮子来装，这就是分布式设计中分而治之的基本思想。同理，如果一台服务器性能吃紧，那么就利用多台服务的资源协同处理。为了实现这一目标，首先需要在数据层面实现数据的分布式。因为在分布式领域，存在一条金科玉律——计算移动比数据移动更加划算。在各服务器之间，通过网络传输数据的成本是高昂的，所以相比移动数据，更为聪明的做法是预先将数据分布到各台服务器，将数据的计算查询直接下推到数据所在的服务器。ClickHouse在数据存取方面，既支持分区（纵向扩展，利用多线程原理），也支持分片（横向扩展，利用分布式原理），可以说是将多线程和分布式的技术应用到了极致。

2.1.7 多主架构

HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。

2.1.8 在线查询

ClickHouse经常会被拿来与其他的分析型数据库作对比，比如Vertica、SparkSQL、Hive和Elasticsearch等，它与这些数据库确实存在许多相似之处。例如，它们都可以支撑海量数据的查询场景，都拥有分布式架构，都支持列存、数据分片、计算下推等特性。这其实也侧面说明了ClickHouse在设计上确实吸取了各路奇技淫巧。与其他数据库相比，ClickHouse也拥有明显的优势。例如，Vertica这类商用软件价格高昂；SparkSQL与Hive这类系统无法保障90%的查询在1秒内返回，在大数据量下的复杂查询可能会需要分钟级的响应时间；而Elasticsearch这类搜索引擎在处理亿级数据聚合查询时则显得捉襟见肘。
正如ClickHouse的广告词所言，其他的开源系统太慢，商用的系统太贵，只有Clickouse在成本与性能之间做到了良好平衡，即又快又开源。ClickHouse当之无愧地阐释了在线二字的含义，即便是在复杂查询的场景下，它也能够做到极快响应，且无须对数据进行任何预处理加工。

2.1.9 数据分片与分布式查询

数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量（1个分片只能对应1个服务节点）。
ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表（Local Table）与分布式表（Distributed Table）的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
这种设计类似数据库的分库和分表，十分灵活。例如在业务系统上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以使用单个节点的本地表（单个数据分片）即可满足业务需求，待到业务增长、数据量增大的时候，再通过新增数据分片的方式分流数据，并通过分布式表实现分布式查询。这就好比一辆手动挡赛车，它将所有的选择权都交到了使用者的手中。

2.2 ClickHouse 的架构设计

图片3

2.2.1 Column与Field

Column和Field是ClickHouse数据最基础的映射单元。作为一款百分之百的列式存储数据库，ClickHouse按列存储数据，内存中的一列数据由一个Column对象表示。Column对象分为接口和实现两个部分，在IColumn接口对象中，定义了对数据进行各种关系运算的方法，例如插入数据的insertRangeFrom和insertFrom方法、用于分页的cut，以及用于过滤的filter方法等。而这些方法的具体实现对象则根据数据类型的不同，由相应的对象实现，例如ColumnString、ColumnArray和ColumnTuple等。在大多数场合，ClickHouse都会以整列的方式操作数据，但凡事也有例外。如果需要操作单个具体的数值（也就是单列中的一行数据），则需要使用Field对象，Field对象代表一个单值。与Column对象的泛化设计思路不同，Field对象使用了聚合的设计模式。在Field对象内部聚合了Null、UInt64、String和Array等13种数据类型及相应的处理逻辑。

2.2.2 DataType

数据的序列化和反序列化工作由DataType负责。IDataType接口定义了许多正反序列化的方法，它们成对出现，例如serializeBinary和deserializeBinary、serializeTextJSON和deserializeTextJSON等，涵盖了常用的二进制、文本、JSON、XML、CSV和Protobuf等多种格式类型。IDataType也使用了泛化的设计模式，具体方法的实现逻辑由对应数据类型的实例承载，例如DataTypeString、DataTypeArray及DataTypeTuple等。
DataType虽然负责序列化相关工作，但它并不直接负责数据的读取，而是转由从Column或Field对象获取。在DataType的实现类中，聚合了相应数据类型的Column对象和Field对象。例如，DataTypeString会引用字符串类型的ColumnString，而DataTypeArray则会引用数组类型的ColumnArray，以此类推。

2.2.3 Block与Block流

ClickHouse内部的数据操作是面向Block对象进行的，并且采用了流的形式。虽然Column和Field组成了数据的基本映射单元，但对应到实际操作，它们还缺少了一些必要的信息，比如数据的类型及列的名称。于是ClickHouse设计了Block对象，Block对象可以看作数据表的子集。Block对象的本质是由数据对象、数据类型和列名称组成的三元组，即Column、DataType及列名称字符串。Column提供了数据的读取能力，而DataType知道如何正反序列化，所以Block在这些对象的基础之上实现了进一步的抽象和封装，从而简化了整个使用的过程，仅通过Block对象就能完成一系列的数据操作。在具体的实现过程中，Block并没有直接聚合Column和DataType对象，而是通过ColumnWithTypeAndName对象进行间接引用。
有了Block对象这一层封装之后，对Block流的设计就是水到渠成的事情了。流操作有两组顶层接口：IBlockInputStream负责数据的读取和关系运算，IBlockOutputStream负责将数据输出到下一环节。Block流也使用了泛化的设计模式，对数据的各种操作最终都会转换成其中一种流的实现。IBlockInputStream接口定义了读取数据的若干个read虚方法，而具体的实现逻辑则交由它的实现类来填充。
IBlockInputStream接口总共有60多个实现类，它们涵盖了ClickHouse数据摄取的方方面面。这些实现类大致可以分为三类：第一类用于处理数据定义的DDL操作，例如DDLQueryStatusInputStream等；第二类用于处理关系运算的相关操作，例如LimitBlockInput-Stream、JoinBlockInputStream及AggregatingBlockInputStream等；第三类则是与表引擎呼应，每一种表引擎都拥有与之对应的BlockInputStream实现，例如MergeTreeBaseSelect-BlockInputStream（MergeTree表引擎）、TinyLogBlockInputStream（TinyLog表引擎）及KafkaBlockInputStream（Kafka表引擎）等。
IBlockOutputStream的设计与IBlockInputStream如出一辙。IBlockOutputStream接口同样也定义了若干写入数据的write虚方法。它的实现类比IBlockInputStream要少许多，一共只有20多种。这些实现类基本用于表引擎的相关处理，负责将数据写入下一环节或者最终目的地，例如MergeTreeBlockOutputStream、TinyLogBlockOutputStream及StorageFileBlock-OutputStream等。

2.2.4 Table

在数据表的底层设计中并没有所谓的Table对象，它直接使用IStorage接口指代数据表。表引擎是ClickHouse的一个显著特性，不同的表引擎由不同的子类实现，例如IStorageSystemOneBlock（系统表）、StorageMergeTree（合并树表引擎）和StorageTinyLog（日志表引擎）等。IStorage接口定义了DDL（如ALTER、RENAME、OPTIMIZE和DROP等）、read和write方法，它们分别负责数据的定义、查询与写入。在数据查询时，IStorage负责根据AST查询语句的指示要求，返回指定列的原始数据。后续对数据的进一步加工、计算和过滤，则会统一交由Interpreter解释器对象处理。对Table发起的一次操作通常都会经历这样的过程，接收AST查询语句，根据AST返回指定列的数据，之后再将数据交由Interpreter做进一步处理。

2.2.5 Parser与Interpreter

Parser和Interpreter是非常重要的两组接口：Parser分析器负责创建AST对象；而Interpreter解释器则负责解释AST，并进一步创建查询的执行管道。它们与IStorage一起，串联起了整个数据查询的过程。Parser分析器可以将一条SQL语句以递归下降的方法解析成AST语法树的形式。不同的SQL语句，会经由不同的Parser实现类解析。例如，有负责解析DDL查询语句的ParserRenameQuery、ParserDropQuery和ParserAlterQuery解析器，也有负责解析INSERT语句的ParserInsertQuery解析器，还有负责SELECT语句的ParserSelectQuery等。
Interpreter解释器的作用就像Service服务层一样，起到串联整个查询过程的作用，它会根据解释器的类型，聚合它所需要的资源。首先它会解析AST对象；然后执行“业务逻辑”（例如分支判断、设置参数、调用接口等）；最终返回IBlock对象，以线程的形式建立起一个查询执行管道。

2.2.6 Functions与Aggregate Functions

ClickHouse主要提供两类函数——普通函数和聚合函数。普通函数由IFunction接口定义，拥有数十种函数实现，例如FunctionFormatDateTime、FunctionSubstring等。除了一些常见的函数（诸如四则运算、日期转换等）之外，也不乏一些非常实用的函数，例如网址提取函数、IP地址脱敏函数等。普通函数是没有状态的，函数效果作用于每行数据之上。当然，在函数具体执行的过程中，并不会一行一行地运算，而是采用向量化的方式直接作用于一整列数据。
聚合函数由IAggregateFunction接口定义，相比无状态的普通函数，聚合函数是有状态的。以COUNT聚合函数为例，其AggregateFunctionCount的状态使用整型UInt64记录。聚合函数的状态支持序列化与反序列化，所以能够在分布式节点之间进行传输，以实现增量计算。

2.2.7 Cluster与Replication

ClickHouse的集群由分片（Shard）组成，而每个分片又通过副本（Replica）组成。这种分层的概念，在一些流行的分布式系统中十分普遍。例如，在Elasticsearch的概念中，一个索引由分片和副本组成，副本可以看作一种特殊的分片。如果一个索引由5个分片组成，副本的基数是1，那么这个索引一共会拥有10个分片（每1个分片对应1个副本）。
如果你用同样的思路来理解ClickHouse的分片，那么很可能会在这里栽个跟头。ClickHouse的某些设计总是显得独树一帜，而集群与分片就是其中之一。这里有几个与众不同的特性。
1）ClickHouse的1个节点只能拥有1个分片，也就是说如果要实现1分片、1副本，则至少需要部署2个服务节点。
2）分片只是一个逻辑概念，其物理承载还是由副本承担的。

如下所示，是ClickHouse的一份集群配置示例，从字面含义理解这份配置的语义，可以理解为自定义集群ch_cluster拥有1个shard（分片）和1个replica（副本），且该副本由10.37.129.6服务节点承载。

自定义集群ch_cluster的配置示例

1
2
3
4
5
6
7
8
<ch_cluster>
    <shard>
        <replica>
            <host>10.37.129.6</host>
            <port>9000</port>
        </replica>
    </shard>
</ch_cluster>

从本质上看，这组1分片、1副本的配置在ClickHouse中只有1个物理副本，所以它正确的语义应该是1分片、0副本。分片更像是逻辑层的分组，在物理存储层面则统一使用副本代表分片和副本。所以真正表示1分片、1副本语义的配置，应该改为1个分片和2个副本，如下所示：
1分片、1副本的集群配置

1
2
3
4
5
6
7
8
9
10
11
12
<ch_cluster>
    <shard>
        <replica>
            <host>10.37.129.6</host>
            <port>9000</port>
        </replica>
        <replica>
            <host>10.37.129.7</host>
            <port>9000</port>
        </replica>
    </shard>
</ch_cluster>

2.3 常见 ClickHouse 集群部署架构

不同于Elasticsearch、HDFS这类主从架构的分布式系统，ClickHouse采用多主（无中心）架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。

ClickHouse借助分片将数据进行横向切分，而分片依赖集群，每个集群由1到多个分片组成，每个分片对应了ClickHouse的1个服务节点；分片数量的上限取决与节点数量（1个分片只能对应1个服务节点）。

但是ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能；ClickHouse提供了本地表与分布式表的概念；一张本地表等同于一个数据分片。而分布式表是张逻辑表，本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。当然，也可以在应用层实现数据分发。

ClickHouse同时支持数据副本，其副本概念与Elasticsearch类似，但在ClickHouse中分片其实是一种逻辑概念，其物理承载是由副本承担的。

ClickHouse的数据副本一般通过ReplicatedMergeTree复制表系列引擎实现，副本之间借助ZooKeeper实现数据的一致性。此外也可通过分布式表负责同时进行分片和副本的数据写入工作。

以四节点实现多分片和双副本为例：

方案一

图片5

（上图中shard作为主副本）
在每个节点创建一个数据表，作为一个数据分片，使用ReplicatedMergeTree表引擎实现数据副本，而分布式表作为数据写入和查询的入口。
这是最常见的集群实现方式。

方案二

图片6

在每个节点创建一个数据表，作为一个数据分片，分布式表同时负责分片和副本的数据写入工作。

这种实现方案下，不需要使用复制表，但分布式表节点需要同时负责分片和副本的数据写入工作，它很有可能成为写入的单点瓶颈。

方案三

图片7

在每个节点创建一个数据表，作为一个数据分片，同时创建两个分布式表，每个分布表只纳管一半的数据。

副本的实现仍需要借助ReplicatedMergeTree表引擎。

方案四

图片8

在每个节点创建两个数据表，同一数据分片的两个副本位于不同节点上，每个分布式表纳管一半的数据。
这种方案可以在更少的节点上实现数据分布与冗余，但是部署上略显繁琐。

ClickHouse 部署方案总结

  • ClickHouse的分片与副本功能完全靠配置文件实现，无法自动管理，所以当集群规模较大时，集群运维成本较高；
  • 数据副本依赖ZooKeeper实现同步，当数据量较大时，ZooKeeper可能会称为瓶颈；
  • 如果资源充足，建议使用方案一，主副本和副副本位于不同节点，以更好地实现读写分离与负载均衡；
  • 如果资源不够充足，可以使用方案四，每个节点承载两个副本，但部署方式上略复杂。

三、ClickHouse 性能

因为ClickHouse在诞生之初是为了服务Yandex自家的Web流量分析产品Yandex.Metrica，所以在存储数据超过20万亿行的情况下，ClickHouse做到了90%的查询都能够在1秒内返回的惊人之举。

图片4

更多对比数据前往官网查看：https://clickhouse.com/benchmark/dbms/

3.1 单个大查询的吞吐量

吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以 2-10GB/s（未压缩）的速度进行处理（对于简单的查询，速度可以达到 30GB/s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以 400MB/s 的速度读取数据，并且数据压缩率是3，则数据的处理速度为 1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是 1-2亿行每秒。

对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。

3.2 处理短查询的延迟时间

如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。 否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

3.3 处理大量短查询的吞吐量

在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询100次。

3.4 数据的写入性能

我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为5万到20万行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

四、ClickHouse 的优缺点

4.1 ClickHouse 优点

1）为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
2）数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
3）索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
4）写入速度非常快，50-200M/s，对于大量的数据更新非常适用。

4.2 ClickHouse 缺点

1）不支持事务，不支持真正的删除/更新；
2）不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
3）SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
4）尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
5）Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。

4.3 注意事项

1）关闭虚拟内存，物理内存和虚拟内存的数据交换，会导致查询变慢；
2）为每一个账户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值；
3）JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表；
4）批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致ClickHouse无法及时对新导入的数据进行合并，从而影响查询性能；
5）尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进行聚合操作，减少数据条数。有些时候，先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短；
6）ClickHouse的分布式表性能性价比不如物理表高，建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满；
7）CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常关注。

五、ClickHouse 部署

系统要求

ClickHouse可以在任何具有x86_64，AArch64或PowerPC64LE CPU架构的Linux，FreeBSD或Mac OS X上运行。
官方预构建的二进制文件通常针对x86_64进行编译，并利用SSE 4.2指令集，因此，除非另有说明，支持它的CPU使用将成为额外的系统需求。下面是检查当前CPU是否支持SSE 4.2的命令:

1
2
[hadoop@hadoop1 ~]$ grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported"
SSE 4.2 supported

要在不支持SSE 4.2或AArch64，PowerPC64LE架构的处理器上运行ClickHouse，您应该通过适当的配置调整从源代码构建ClickHouse。

5.1 单机模式部署

5.1.1 下载tgz包

1
2
3
4
5
6
[hadoop@hadoop1 ~]$ export LATEST_VERSION=21.11.4.14
[hadoop@hadoop1 ~]$ cd downloads/
[hadoop@hadoop1 ~/downloads]$ wget https://repo.clickhouse.tech/tgz/clickhouse-common-static-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ wget https://repo.clickhouse.tech/tgz/clickhouse-common-static-dbg-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ wget https://repo.clickhouse.tech/tgz/stable/clickhouse-server-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ wget https://repo.clickhouse.tech/tgz/clickhouse-client-$LATEST_VERSION.tgz

对于生产环境，建议使用最新的stable版本。可以在GitHub页面找到它，它以后缀-stable标志。

5.1.2 解压压缩包

1
2
3
4
[hadoop@hadoop1 ~/downloads]$ tar zxf clickhouse-client-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ tar zxf clickhouse-common-static-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ tar zxf clickhouse-common-static-dbg-$LATEST_VERSION.tgz
[hadoop@hadoop1 ~/downloads]$ tar zxf clickhouse-server-$LATEST_VERSION.tgz

安装 clickhouse-server 时需要为clickhouse输入default用户默认密码

5.1.3 安装 clickhouse

1
2
3
4
[hadoop@hadoop1 ~/downloads]$ sudo ./clickhouse-client-$LATEST_VERSION/install/doinst.sh
[hadoop@hadoop1 ~/downloads]$ sudo ./clickhouse-common-static-$LATEST_VERSION/install/doinst.sh
[hadoop@hadoop1 ~/downloads]$ sudo ./clickhouse-common-static-dbg-$LATEST_VERSION/install/doinst.sh
[hadoop@hadoop1 ~/downloads]$ sudo ./clickhouse-server-$LATEST_VERSION/install/doinst.sh

删除创建的default密码

1
[hadoop@hadoop1 ~]$ sudo rm -f /etc/clickhouse-server/users.d/default-password.xml

修改 clickhouse 目录属主，不想更改clickhouse 启动用户，则跳过这一步

1
2
3
4
[hadoop@hadoop1 ~]$ sudo chown -R hadoop.hadoop /etc/clickhouse-*
[hadoop@hadoop1 ~]$ sudo chown -R hadoop.hadoop /var/lib/clickhouse
[hadoop@hadoop1 ~]$ sudo chown -R hadoop.hadoop /var/log/clickhouse-server
[hadoop@hadoop1 ~]$ sudo chown -R hadoop.hadoop /var/run/clickhouse-server

5.1.4 启动 clickhouse

1
[hadoop@hadoop1 ~]$ nohup clickhouse-server --config-file=/etc/clickhouse-server/config.xml >/dev/null 2>&1 &

使用clickhouse 用户启动服务

sudo clickhouse start

5.1.5 client 连接 clickhouse

1
2
3
4
5
6
7
[hadoop@hadoop1 ~/downloads]$ clickhouse-client -u default --password
ClickHouse client version 21.11.4.14 (official build).
Password for user (default):
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.11.4 revision 54450.

hadoop1 :)

5.2 分布式集群安装

服务规划

主机名角色分配分片与副本依赖服务
hadoop1clickhouse-server、clickhouse-clientshard01、replica01zookeeper
hadoop2clickhouse-server、clickhouse-clientshard02、replica01zookeeper
hadoop3clickhouse-server、clickhouse-clientshard03、replica01zookeeper

前置条件

zookeeper集群是可用的

5.2.1 安装 clickhouse

安装 clickhouse 参考单机模式在集群的每台服务器上安装好clickhouse

5.2.2 添加集群配置

添加集群相关配置，在集群中所有clickhouse 服务器上操作

修改 config.xml 配置，新增外部配置文件metrika.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
[hadoop@hadoop1 ~]$ vim /etc/clickhouse-server/config.xml

<?xml version="1.0"?>
<clickhouse>
    <!-- 日志 -->
    <logger>
        <level>trace</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>10</count>
    </logger>

    <!-- 端口 -->
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <mysql_port>9004</mysql_port>
    <postgresql_port>9005</postgresql_port>
    <interserver_http_port>9009</interserver_http_port>

    <!-- 本机域名 -->
    <!-- <interserver_http_host>这里需要用域名，如果后续用到复制的话</interserver_http_host> -->

    <!-- 监听IP -->
    <listen_host>::</listen_host>
    <listen_host>0.0.0.0</listen_host>
    <!-- 最大连接数 -->
    <max_connections>64</max_connections>

    <!-- ClickHouse在关闭连接之前等待传入请求时间。 默认为3秒 -->
    <keep_alive_timeout>3</keep_alive_timeout>

    <!-- 最大并发查询数 -->
    <max_concurrent_queries>100</max_concurrent_queries>

    <!-- 单位是B -->
    <uncompressed_cache_size>8589934592</uncompressed_cache_size>
    <mark_cache_size>10737418240</mark_cache_size>

    <!-- 存储路径 -->
    <path>/data1/clickhouse/</path>
    <tmp_path>/data1/clickhouse/tmp/</tmp_path>

    <!-- user配置 -->
    <users_config>users.xml</users_config>
    <default_profile>default</default_profile>

    <log_queries>1</log_queries>

    <default_database>default</default_database>

    <!-- 新增外部配置文件metrika.xml  -->
    <include_from>/data1/clickhouse/metrika.xml</include_from>
    <remote_servers incl="clickhouse_remote_servers" />
    <zookeeper incl="zookeeper-servers" optional="true" />
    <macros incl="macros" optional="true" />

    <!-- 重新加载内置词典的时间间隔（以秒为单位），默认3600。可以在不重新启动服务器的情况下“即时”修改词典 -->
    <builtin_dictionaries_reload_interval>3600</builtin_dictionaries_reload_interval>

    <!-- 控制大表的删除 -->
    <max_table_size_to_drop>0</max_table_size_to_drop>

</clickhouse>

metrika.xml 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
[hadoop@hadoop1 ~]$ vim /etc/clickhouse-server/metrika.xml

<yandex>
<!-- 集群配置 -->
<clickhouse_remote_servers>
    <perftest_3shards_1replicas>
        <!-- 3分片1备份 -->
        <!-- 数据分片1  -->
        <shard>
            <internal_replication>true</internal_replication>
            <replica>
                <host>hadoop1</host>
                <port>9000</port>
            </replica>
        </shard>
        <!-- 数据分片2  -->
        <shard>
            <internal_replication>true</internal_replication>
            <replica>
                <host>hadoop2</host>
                <port> 9000</port>
            </replica>
        </shard>
        <!-- 数据分片3  -->
        <shard>
            <internal_replication>true</internal_replication>
            <replica>
                <host>hadoop3</host>
                <port>9000</port>
            </replica>
        </shard>
    </perftest_3shards_1replicas>
</clickhouse_remote_servers>

<!-- ZK配置 -->
<zookeeper-servers>
    <node index="1">
        <host>hadoop1</host>
        <port>2181</port>
    </node>
    <node index="2">
        <host>hadoop2</host>
        <port>2181</port>
    </node>
    <node index="3">
        <host>hadoop3</host>
        <port>2181</port>
    </node>
</zookeeper-servers>

<networks>
    <ip>::/0</ip>
</networks>

<macros>
    <shard>01</shard>
    <replica>hadoop1</replica>
</macros>

<!-- 压缩相关配置 -->
<clickhouse_compression>
    <case>
        <min_part_size>10000000000</min_part_size>
        <min_part_size_ratio>0.01</min_part_size_ratio>
        <method>lz4</method>
    </case>
</clickhouse_compression>
</yandex>

部分配置说明

  • cluster_3shards_1replicas 集群名称,可随意定义

  • 共设置3个分片，每个分片只有1个副本；

  • internal_replication 此参数设置为«true»时，写操作只选一个正常的副本写入数据。如果分布式表的子表是复制表(*ReplicaMergeTree)，请使用此方案。换句话说，这其实是把数据的复制工作交给实际需要写入数据的表本身而不是分布式表。若此参数设置为«false»（默认值），写操作会将数据写入所有副本。实质上，这意味着要分布式表本身来复制数据。这种方式不如使用复制表的好，因为不会检查副本的一致性，并且随着时间的推移，副本数据可能会有些不一样。

  • macros 是复制标识的配置，也称为宏配置，这里唯一标识一个副本名称，使用了cluster{layer}-{shard}-{replica}的表示方式（其中layer是双级分片设置，在Yandex公司的集群中用到），每个实例都要配置并且都是唯一的，这里3个节点分别配置如下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    <!-- hadoop1配置 -->
         <macros>
             <shard>01</shard>
             <replica>hadoop1</replica>
         </macros>

    <!-- hadoop2配置 -->
         <macros>
             <shard>02</shard>
             <replica>hadoop2</replica>
         </macros>

    <!-- hadoop3配置 -->
         <macros>
             <shard>03</shard>
             <replica>hadoop3</replica>
         </macros>

5.2.3 启动 clickhouse 集群

启动所有节点的clickhouse服务

1
2
3
[hadoop@hadoop1 ~]$ nohup clickhouse-server --config-file=/etc/clickhouse-server/config.xml >/dev/null 2>&1 &
[hadoop@hadoop2 ~]$ nohup clickhouse-server --config-file=/etc/clickhouse-server/config.xml >/dev/null 2>&1 &
[hadoop@hadoop3 ~]$ nohup clickhouse-server --config-file=/etc/clickhouse-server/config.xml >/dev/null 2>&1 &

5.2.4 client 连接 clickhouse

在任意一台安装clickhouse client的服务器上连接

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[hadoop@hadoop3 ~]$ clickhouse-client -h hadoop1 --port 9000 -m -u default --password
ClickHouse client version 21.11.4.14 (official build).
Connecting to hadoop1:9000 as user default.
Connected to ClickHouse server version 21.11.4 revision 54450.

hadoop1 :) show databases;

SHOW DATABASES

Query id: 6c844db3-c555-437a-847b-5e91e67635b1

┌─name───────────────┐
│ INFORMATION_SCHEMA │
│ default            │
│ information_schema │
│ system             │
└────────────────────┘

查看集群信息

1
select * from system.clusters;

图片9

5.2.5 创建本地表及分布式表

在各个节点分表创建数据库test(在一个节点执行即可)

1
create database test ON CLUSTER cluster_3shards_1replicas;

下面给出ReplicatedMergeTree引擎的完整建表DDL语句。

创建本地表及表引擎，Replicated Table & ReplicatedMergeTree Engines

1
CREATE TABLE IF NOT EXISTS test.events_local ON CLUSTER cluster_3shards_1replicas (  ts_date Date,  ts_date_time DateTime, user_id Int64,  event_type String,  site_id Int64,  groupon_id Int64,  category_id Int64,  merchandise_id Int64,  search_text String) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test/events_local','{replica}') PARTITION BY ts_date ORDER BY (ts_date,toStartOfHour(ts_date_time),site_id,event_type) SETTINGS index_granularity = 8192;

图片10

其中，ON CLUSTER语法表示分布式DDL，即执行一次就可在集群所有实例上创建同样的本地表。集群标识符{cluster}、分片标识符{shard}和副本标识符{replica}来自之前提到过的复制表宏配置，即metrika.xml中<macros>中的内容，配合ON CLUSTER语法一同使用，可以避免建表时在每个实例上反复修改这些值。

创建分布式表及分布式表引擎，Distributed Table & Distributed Engine

ClickHouse分布式表的本质并不是一张表，而是一些本地物理表（分片）的分布式视图，本身并不存储数据。
支持分布式表的引擎是Distributed，建表DDL语句示例如下，_all只是分布式表名比较通用的后缀而已。

1
CREATE TABLE IF NOT EXISTS test.events_all ON CLUSTER cluster_3shards_1replicas AS test.events_local ENGINE = Distributed(cluster_3shards_1replicas,test,events_local,rand());

图片11

在任意节点插入数据

1
insert into test.events_all values('2021-11-23','2021-11-19 16:10:00',1,'ceshi1',1,1,1,1,'test1'),('2021-11-19','2021-11-19 16:20:01',2,'ceshi2',2,2,2,2,'test2'),('2021-11-19','2021-11-19 16:30:02',3,'ceshi2',3,3,3,3,'test3'),('2021-11-19','2021-11-19 16:40:03',4,'ceshi4',4,4,4,4,'test4'),('2021-11-19','2021-11-19 16:50:04',5,'ceshi5',5,5,5,5,'test5'),('2021-11-19','2021-11-19 17:00:05',6,'ceshi6',6,6,6,6,'test6');

查询各分片数据

1
select * from test.events_all;

图片12

前面说过，分布式表只是逻辑上的表，数据真正都存储在各节点的本地表中，下面通过查看各节点的本地表，看看数据的分布情况

图片13

图片14

图片15

5.3 ClickHouse 常用操作

查询clickhouse集群信息

1
select * from system.clusters;

查看表引擎

1
show create table test.events_local;

创建数据库命令（一个节点上执行，多个节点同时创建）

1
create database test ON CLUSTER cluster_3shards_1replicas;

删除数据库命令（一个节点上执行，多个节点同时删除）

1
drop database test ON CLUSTER cluster_3shards_1replicas;

删除本地表数据（分布式表无法删除表数据）

1
alter table test.events_local ON CLUSTER cluster_3shards_1replicas delete where 1=1;

1=1表示删除所有数据，可以接字段名删除满足某个条件的数据

查看zookeeper下目录

1
select * from system.zookeeper WHERE path='/';

clickhouse导入数据

1
2
3
4
5
6
7
8
9
#方式一：交互式
insert into tableName (c1, c2, ...) values (v1, v2, ...)
insert into tableName (c1, c2, ...) select ... 

#方式二：批量
clickhouse-client --query="insert into test.events_all FORMAT CSV" < /tmp/events-all.csv

#方式三：http客户端
echo -ne '10\n11\n12\n' | POST 'http://localhost:8123/?query=insert into tableName format TabSeparated'

clickhouse导出数据

1
2
3
4
5
6
7
8
#方式一：交互式
select * from test.events_all into outfile '/tmp/events-all.csv' FORMAT CSV;

#方式二：非交互式
clickhouse-client --database bdName -u default --password password --query 'select * from tableName FORMAT CSV' > abc

#方式二：http客户端
echo 'select 1 FORMAT TabSeparated' | curl "http://user:password@localhost:8123/" -d @- > file
-------------本文结束感谢您的阅读-------------
分享到： 收藏夹 复制网址 邮件 微信 QQ空间 腾讯微博 豆瓣 一键分享 更多