ClickHouse概述

ClickHouse概述

ClickHouse是俄罗斯的Yandex于2016年开源的一个用于联机分析(OLAP:online Analytical Processing)的列式数据库管理系统(DBMS:Database Management System) , 主要用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。

ClickHouse是一个完全的列式分布式数据库管理系统，允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，容错。它在大数据领域没有走 Hadoop 生态，而是采用 Local attached storage 作为存储，这样整个 IO 可能就没有 Hadoop 那一套的局限。它的系统在生产环境中可以应用到比较大的规模，因为它的线性扩展能力和可靠性保障能够原生支持 shard + replication 这种解决方案。它还提供了一些 SQL 直接接口，有比较丰富的原生 client。另外就是它比较快，主要用于交互式查询。

交互式分析场景具有如下典型特点：

1. 大多数访问是读请求。
2. 写入通常为追加写，较少更新、删除 *** 作。
3. 读写不关注事务、强一致等特性。
4. 查询通常会访问大量的行，但仅部分列是必须的。

查询结果通常明显小于访问的原始数据，且具有可理解的统计意义。

架构层面适用场景

1. 绝大多数请求都是用于读访问的
2. 数据需要以大批次（大于1000行）进行更新，而不是单行更新；或者根本没有更新 *** 作
3. 数据只是添加到数据库，没有必要修改
4. 读取数据时，会从数据库中提取出大量的行，但只用到一小部分列  
5. 表很“宽”，即表中包含大量的列
6. 查询频率相对较低（通常每台服务器每秒查询数百次或更少）
7. 对于简单查询，允许大约50毫秒的延迟
8. 列的值是比较小的数值和短字符串（例如，每个URL只有60个字节）
9. 在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）
10. 不需要事务
11. 数据一致性要求较低
12. 每次查询中只会查询一个大表。除了一个大表，其余都是小表
13. 查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小

架构层面不适合的场景

1. 不支持事务
2. 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用
3. 不擅长按行删除数据（虽然支持）
4. 并发高 , 查询频次高

特征
1 完备的DBMS系统
ClickHouse拥有完备的管理功能，所以它称得上是一个DBMS（Database Management System，数据库管理系统），而不仅是一个数据库。作为一个DBMS，它具备了一些基本功能，如下所示。 
DDL（数据定义语言）：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。 
DML（数据 *** 作语言）：可以动态查询、插入、修改或删除数据。 
权限控制：可以按照用户粒度设置数据库或者表的 *** 作权限，保障数据的安全性。 
数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。 
分布式管理：提供集群模式，能够自动管理多个数据库节点。这里只列举了一些最具代表性的功能，但已然足以表明为什么Click House称得上是DBMS了。
2 真正的列式数据库管理系统
在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。
例如，10亿个UInt8类型的数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是非常重要的，因为解压缩的速度主要取决于未压缩数据的大小。
这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如： Hbase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。
需要说明的是，ClickHouse不单单是一个数据库，它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。
3 数据压缩 
在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。
但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用,那么CK底层数据的存储使用的是列式数据存储,所以方便实施压缩算法,并且压缩比例和读取性能都比较理想 !
4 数据的磁盘存储
许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使用SSD和内存，它也会合理的利用这些资源。
5 多核心并行处理
ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。
6 多服务器分布式处理 
上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。
在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的
7 支持SQL (函数丰富 , 灵活) 高阶函数 
ClickHouse支持基于SQL的声明式查询语言，该语言大部分情况下是与SQL标准兼容的。
支持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及非相关子查询。
不支持窗口函数和相关子查询。
8 向量引擎 (并行) 
为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。利用CPU的SIMD指令。SIMD的全称是 Single Instruction Multiple Data，即用单条指机系统概念中，它是通过数据并行以提高性能的一种实现方式（其他的还有指令级并行和线程级并行），它的原理是在CPU寄存器层面实现数据的并行 *** 作!

处理使用多线程处理数据以外，CK也使用CPU的寄存器,单指令并行处理数据,将数据的处理效率做到极致!
9 实时的数据更新 
ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。
10 索引 
按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找。
11 适合在线查询 
在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。
12 支持近似计算 
ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：
用于近似计算的各类聚合函数，如：distinct values, medians, quantiles
基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。
不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。
13 支持数据复制和数据完整性 
ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。
14 多主架构
HDFS、Spark、Hbase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景

技术层面优缺点
 优点
为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
 缺点
不支持事务，不支持真正的删除/更新；
不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
不支持真正的删除/更新不支持事务（期待后续版本支持）
不支持二级索引
有限的SQL支持，join实现与众不同
不支持窗口功能
元数据管理需要人工干预维护
SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete *** 作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
ClickHouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。

性能
单个查询吞吐量：如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。
处理短查询的延时时间：数据被page cache缓存的情况下，它的延迟应该小于50毫秒(最佳情况下应该小于10毫秒)。 否则，延迟取决于数据的查找次数。延迟可以通过以下公式计算得知： 查找时间（10 ms）* 查询的列的数量 * 查询的数据块的数量。
处理大量短查询：ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。建议每秒最多查询100次。
数据写入性能：建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。
count: 千万级别，500毫秒，1亿 800毫秒  2亿 900毫秒 3亿 1.1秒
group: 百万级别 200毫米，千万 1秒，1亿 10秒，2亿 20秒，3亿 30秒
join：千万-10万 600 毫秒， 千万 -百万：10秒，千万-千万 150秒
ClickHouse并非无所不能，查询语句需要不断的调优，可能与查询条件有关，不同的查询条件表是左join还是右join也是很有讲究的。

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

相比于行式存储，列式存储在分析场景下有着许多优良的特性。
如前所述，分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取 *** 作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。
同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。
自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。
官方数据显示，通过使用列存，在某些分析场景下，能够获得100倍甚至更高的加速效应。
3 向量化(算法)
ClickHouse不仅将数据按列存储，而且按列进行计算。传统OLTP数据库通常采用按行计算，原因是事务处理中以点查为主，SQL计算量小，实现这些技术的收益不够明显。但是在分析场景下，单个SQL所涉及计算量可能极大，将每行作为一个基本单元进行处理会带来严重的性能损耗：
对每一行数据都要调用相应的函数，函数调用开销占比高；
存储层按列存储数据，在内存中也按列组织，但是计算层按行处理，无法充分利用CPU cache的预读能力，造成CPU Cache miss严重；
按行处理，无法利用高效的SIMD指令；
ClickHouse实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。
(SIMD全称Single Instruction Multiple Data，单指令多数据流，能够复制多个 *** 作数，并把它们打包在大型寄存器的一组指令集。以同步方式，在同一时间内执行同一条指令)
4 表
联想以前学习的表, 有表名和表结构
5 分片
ClickHouse的集群由分片 ( Shard ) 组成，而每个分片又通过副本 ( Replica ) 组成。这种分层的概念，在一些流行的分布式系统中十分普遍。例如，在Elasticsearch的概念中，一个索引由分片和副本组成，副本可以看作一种特殊的分片。如果一个索引由5个分片组成，副本的基数是1，那么这个索引一共会拥有10个分片 ( 每1个分片对应1个副本 )。
如果你用同样的思路来理解ClickHouse的分片，那么很可能会在这里栽个跟头。ClickHouse的某些设计总是显得独树一帜，而集群与分片就是其中之一。这里有几个与众不同的特性。
ClickHouse的1个节点只能拥有1个分片，也就是说如果要实现1分片、1副本，则至少需要部署2个服务节点。
分片只是一个逻辑概念(类似于Hbase中的region的概念,表的范围数据)，其物理承载还是由副本承担的。
6 分区 
ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区 *** 作，比如通过toYYYYMM()将数据按月进行分区、toMonday()将数据按照周几进行分区、对Enum类型的列直接每种取值作为一个分区等。
类似于hive中的分区表 
7 副本
数据存储副本,在集群模式下实现高可用
简单理解就是相同的数据备份，在CK中通过复制集，我们实现保障了数据可靠性外，也通过多副本的方式，增加了CK查询的并发能力。这里一般有2种方式：
基于ZooKeeper的表复制方式；
基于Cluster的复制方式。
由于我们推荐的数据写入方式本地表写入，禁止分布式表写入，所以我们的复制表只考虑ZooKeeper的表复制方案。
8 引擎
不同的引擎决定了表数据的存储特点和表数的 *** 作行为:
决定表存储在哪里以及以何种方式存储
支持哪些查询以及如何支持
并发数据访问
索引的使用
是否可以执行多线程请求
数据复制参数
表引擎决定了数据在文件系统中的存储方式，常用的也是官方推荐的存储引擎是MergeTree系列，如果需要数据副本的话可以使用ReplicatedMergeTree系列，相当于MergeTree的副本版本。读取集群数据需要使用分布式表引擎Distribute。

后续博主会出详解，敬请期待