ClickHouse
2021-10-30 13:11:44 
阿炯
ClickHouse 系俄罗斯搜索巨头Yandex 公司在 2016年开源的一个极具实力的实时数据分析数据库，是一个用于联机分析 (OLAP:Online Analytical Processing) 的列式数据库管理系统 (DBMS:Database Management System)，简称 CK，工作速度比传统方法快100-1000倍，它的性能超过了目前市场上可比的面向列的DBMS。每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。它允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，容错。
ClickHouse 作为一个高性能 OLAP 数据库，虽然OLAP能力逆天但也不应该把它用于任何OLTP事务性操作的场景，相比OLTP：不支持事务、不擅长根据主键按行粒度的查询、不擅长按行删除数据，目前市场上的其他同类高性能 OLAP 数据库同样也不擅长这些方面。因为对于一款OLAP数据库而言，OLTP 能力并不是重点，支持Linux, MacOS操作系统，采用C++编写并在Apache许可证下授权。
ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。这些功能共同为ClickHouse极速的分析性能奠定了基础。
架构
1、ClickHouse 存储架构
2、ClickHouse部署
扩展性
其本身不扩展，可借助Distributed引擎(本身不存储数据)
写：
指定哪些数据写入到哪些节点里
通过一个节点写，数据分到不同的节点里，通过指定分片的key来分发数据。
数据写入是异步的，对于插入数据到集群的其他节点，数据先是写入到本地磁盘，然后在后台发送到其他分片服务器，如果想查看数据有没有同步完，可以检查下面的目录：/var/lib/clickhouse/data/database/table
读：
由一个节点收集所有节点数据返回客户端
可靠性
依赖于zookeeper，使用物理复制
ClickHouse适合流式或批次入库的时序数据。ClickHouse不应该被用作通用数据库，而是作为超高性能的海量数据快速查询的分布式实时处理平台，在数据汇总查询方面(如GROUP BY)，ClickHouse的查询速度非常快。
典型特点：ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、具有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用。
简言之：ClickHouse作为分析型数据库，有三大特点:一是跑分快， 二是功能多 ，三是文艺范。
(1)、跑分快：ClickHouse跑分是Vertica的五倍快
其性能超过了市面上大部分的列式存储数据库，相比传统的数据ClickHouse要快100-1000X， ClickHouse还是有非常大的优势：
100Million 数据集：ClickHouse比Vertica约快5倍，比Hive快279倍，比MySQL快801倍
1Billion 数据集：ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了
(2)、功能多：ClickHouse支持数据统计分析各种场景
支持类SQL查询，支持繁多库函数(例如IP转化，URL分析等，预估计算/HyperLoglog等)、支持数组(Array)和嵌套数据结构(Nested Data Structure)、支持数据库异地复制部署+支持分布式
(3)、文艺范：目前ClickHouse的限制很多，生来就是为小资服务的
– 相对较缺乏的文档，社区刚开始活跃，只有开源的C++源码
– 不理睬Hadoop生态，走自己的路
ClickHouse特点
在内存数据库领域号称是最快的。
数据始终以列存储，包括矢量执行过程。
有两种不同的加速查询处理的方法： 矢量化查询执行和运行时代码生成。
列存储数据库，使用向量查询技术，select，orderby，limit操作都不改原列向量，而是新建。适合少修改的数据。
使用抽象渗漏提高速度，使列的数据与数据类型、数据块处理分离。
查询流水线每一步中间数据都保存，临时数据要适合CPU缓存。
对于分布式数据不完全支持join这样的复杂查询。
使用稀疏索引，不适合高负载的点状查询。
不依赖Hadoop生态，能够存储和处理数PB的数据。
不支持事物，缺乏完整的UPDATE/DELETE实现。
向量化引擎：数据不仅按列存储，而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。
允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器。
真正的列式数据库，没有任何内容与值一起存储。例如，支持常量长度值，以避免将它们的长度“ number”存储在值的旁边。
线性可扩展性，可以通过添加服务器来扩展集群。
容错性。系统是一个分片集群，其中每个分片都是一组副本。ClickHouse使用异步多主复制。数据写入任何可用的副本，然后分发给所有剩余的副本。Zookeeper用于协调进程，但不涉及查询处理和执行。
SQL支持，Clickhouse支持类似SQL的扩展语言，包括数组和嵌套数据结构、近似函数和URI函数，以及连接外部键值存储的可用性。
使用向量计算。数据不仅由列存储，而且由向量处理(一部分列)。这种方法可以实现高CPU性能。
支持采样和近似计算和进行并行和分布式查询处理(包括JOIN)。
数据压缩与HDD优化，可以处理不适合内存的数据。
用于数据库(DB)连接的客户端。数据库连接方式包括控制台客户端、HTTP API，或者各种编程语言的wrapper(可以用的有Python、PHP、NodeJS、Perl、Ruby与R语言)，也可以使用JDBC驱动。
1、ClickHouse适用场景
适合:用于结构良好清晰且不可变的事件或日志流实时查询分析。
不适合:事务性工作(OLTP)，高请求率的键值访问，低延迟的修改或删除已存在数据，Blob或文档存储，超标准化数据。
2、ClickHouse优点
与 Hadoop、Spark 这些巨无霸组件相比，ClickHouse 具有轻量级的优点，它的特点包括以下内容：
(1)真正的面向列的 DBMS
ClickHouse 是一个 DBMS，而不是一个单一的数据库。它允许在运行时创建表和数据库、加载数据和运行 查询，而无需重新配置和重新启动服务器。
(2)数据压缩
一些面向列的 DBMS(InfiniDB CE 和 MonetDB)不使用数据压缩，但数据压缩确实提高了性能。
(3)磁盘存储的数据
许多面向列的 DBMS(SAP HANA 和 GooglePowerDrill)只能在内存中工作。但即使在数千台服务器 上，内存也太小，无法在 Yandex.Metrica 中存储所有浏览量和会话。
(4)多核并行处理、多核多节点并行化大型查询。
(5)在多个服务器上分布式处理
在 ClickHouse 中，数据可以驻留在不同的分片上。每个分片都可以用于容错的一组副本，查询会在所有分 片上并行处理。
(6)SQL支持
ClickHouse SQL 跟真正的 SQL 有不一样的函数名称。不过语法基本跟 SQL 语法兼容，支持 JOIN、 FROM、IN 和 JOIN 子句以及标量子查询支持子查询。
(7)向量化引擎
数据不仅按列存储，而且由矢量 – 列的部分进行处理，这使开发者能够实现高 CPU 性能。
(8)实时数据更新
ClickHouse 支持主键表。为了快速执行对主键范围的查询，数据使用合并树 (MergeTree) 进行递增排序。由于这个原因，数据可以不断地添加到表中。
(9)支持近似计算
该库支持为有限数量的随机密钥(而不是所有密钥)运行聚合。在数据中密钥分发的特定条件下，这提供了相 对准确的结果，同时使用较少的资源。
(10)数据复制和对数据完整性的支持
ClickHouse 使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复。扩展成为分布式的数据库OLAP引擎，严重依赖于zookeeper。
3、ClickHouse缺点
ClickHouse 作为一个被设计用来在实时分析的 OLAP 组件，只是在高效率的分析方面性能发挥到极致，那必然就会在其他方面做出取舍：
(1)没有完整的事务支持，不支持Transaction，想快就别想Transaction
(2)缺少完整的Update/Delete操作，缺少高频率、低延迟的修改或删除已存在数据的能力，仅能用于批量删除或修改数据
(3)聚合结果必须小于一台机器的内存大小:不是大问题
(4)支持有限操作系统，正在慢慢完善
(5)开源社区刚刚启动，主要是俄语为主
(6)不适合key-value存储，不支持 Blob 等文档型数据库
ClickHouse还可以用作内部分析师的内部数据仓库，它可以存储来自不同系统的数据(比如Hadoop或某些日志)，分析人员可以使用这些数据构建内部指示板，或者为了业务目的执行实时分析。
ClickHouse产生背景
1、现有的大数据架构分析报表的缺点
如果我们要做一个基于Hadoop传统的数据分析会是下面的一个架构：程序实时的生成日志发送到kafka，在经过ETL处理之后入库到Hive仓库，数据仓库经过分析之后，将结果导出最后生成报表。
基于Hadoop 的报表数据分析架构缺点如下：
1)、数据时效性：数据经过了Kafka、ELK、调度和各种的处理，所以最终的时效性不是那么的理想，就算这个架构最终优化的很好，那么最终的查询结果也都是秒级
2)、即席分析性能：Hive数据存储在HDFS中，HDFS是不支持随机读写的，Hive底层使用的分析引擎，要么是MapReduce要么是Spark，相对来说，他们的执行效率都没有理想中那么好，不适合即席查询
3)、涉及组件多：涉及Kafka、Flume、HDFS等等，数据冗余过多，维护起来麻烦
4)、数据链路长：数据从源头到最终生成报表，中间经过了非常多的技术组件的处理，要是其中一个技术组件出现问题，那么都会影响我们的可用性
最终的结果就是，我们基于传统的大数据分析架构进行报表分析，貌似没能达到我们理想中的效果，这个时候我们就期望大数据的性能能够更进一步，或者说有一个系统能够帮我们解决这些问题。
2、新时代的选择
架构目标：
1)、海量数据
2)、实时导入
3)、实时查询
4)、多维聚合分析，可以随意做交互式查询
假设我们依旧希望使用Hadoop来解决问题，那么我们希望Hadoop的性能可以翻上几番，但是Hadoop生态体系还是很复杂的，对开发、运维、架构师都有不少的挑战，所以在新时代，新需求冒出来之后，就有很多的公司开发出来了很多的新技术，有kylin,doris,clickhouse,kudu等，这种技术能通过比较低的复杂度来帮助我们高效的解决即席查询的需求。
OLAP和OLTP技术要点分析
1、OLAP和OLTP介绍
ClickHouse作为OLAP分析引擎，那么OLAP和OLTP也是我们不得不了解的概念。
OLTP：T(transaction)联机事务处理，侧重于增删改
OLAP：A(analysis)联机分析处理，侧重于分析Select非事务大批量数据的聚合查询
事务处理作用：保证数据的一致性，如果涉及到事务操作，这个操作的执行效率必然不高。
我们设计一款存储系统，没法做到既能满足高效的增删改，又能做高效的查询分析，两者同时满足很困难。基本在业界出现的查询系统，要么是OLAP要么是OLTP，很少且几乎没有同时具备OLAP和OLTP两种特性的高效性。
2、读模式和写模式
写模式：数据存储到系统中的时候，系统会对数据进行校验，如果满足要求数据就能插入进去，如果不满足要求则拒绝写入。
读模式：校验数据模式的时候，在读取数据的时候才进行校验，不是在插入数据的时候进行校验。
OLAP一般都是读模式，OLTP写模式，ClickHouse出来，界限就模糊了。
ClickHouse写模式+OLAP。
3、海量数据高效即席查询需要的条件
海量数据做查询分析高效：列式数据库，写模式(保证同一列的数据类型是一样的，方便压缩)，排序，具体优点如下：
1、列式数据库：假设我们一张表有100个字段，我们做查询分析只需要用到其中的几个字段，如果我们是行式数据库，那么我们就需要把这张表的数据都读取出来，我们读取到这行的时候，只需要提取100个字段中的几个字段就能分析。如果是列式数据库，则只需要扫描需要的字段即可完成查询分析。 所以我们在海量数据，想要设计出一块高效的即席查询系统，一定要将底层的数据存储改为列式存储。
2、既然我们将存储改成了列式存储，那么我们就需要对每一列的数据做一个校验，ClickHouse是一个列式数据库，同时他也是一个写模式，就是为了数据写入的时候可以进行校验，写入一列数据，它可以保证一列数据值的类型都是一样的。因为每一个记录这个值的大小都是一样的，所以就类似于我们可以通过连续内存的这个模式来进行存储，对于我们解析和处理来说也会显现的非常高效。
3、同时因为所有字段的值都是一样的，所以我们压缩的时候效果也会特别的高。
4、因为我们这一列的值都是一样的，所以我们做排序的时候也有助于我们进行查询分析。
OLAP体系的重要三个特点：排序+写模式+列式数据库，ClickHouse全部具备。
ClickHouse核心目录：
(1)/etc/clickhouse-server:服务端的配置文件目录，包括全局配置config.xml和用户配置users.xml等
(2)/var/lib/clickhouse:默认数据存储目录，通常会修改默认路径配置，将数据保存到大容量磁盘挂 载路径
(3)/var/log/clickhouse-server:默认日志保存目录，通常会修改路径配置将日志保存到大容量磁盘 挂载的路径
ClickHouse可执行文件：
(1)clickhouse:主程序的可执行文件
(2)clickhouse-client:一个指向ClickHouse可执行文件的软链接，供客户端连接使用
(3)clickhouse-server:一个指向ClickHouse可执行文件的软链接，供服务端启动使用
(4)clickhouse-compressor:内置提供的压缩工具，可用于数据的正压反解
ClickHouse每个节点在安装的时候，都是独立的。就算是配置成集群了，每个服务器依然还是单独运行的；如果创建了一张表，这张表的引擎是分布式的引擎，那么这个表所存储在那个集群里面的机器，就是一个集群了。
运行快的原因
它的数据剪枝能力比较强，分区剪枝在执行层，而存储格式用局部数据表示，就可以更细粒度地做一些数据的剪枝。它的引擎在实际使用中应用了一种现在比较流行的 LSM 方式。
它对整个资源的垂直整合能力做得比较好，并发 MPP+SMP 这种执行方式可以很充分地利用机器的集成资源。它的实现又做了很多性能相关的优化，它的一个简单的汇聚操作有很多不同的版本，会根据不同 Key 的组合方式有不同的实现。对于高级的计算指令，数据解压时，它也有少量使用。
ClickHouse 是一套完全由 C++ 模板 Code 写出来的实现。
不支持Transaction。
使用了矢量化查询执行
当进行查询时，操作被转发到数组上，而不是在特定的值上。
向量化查询执行实用性并不那么高，如果临时数据并不适合L2缓存，读缓存将有问题。但是向量化查询执行更容易利用CPU的SIMD能力。
提供了有限的运行时动态代码生成(group by的内部循环第一阶段)。
运行时代码生成可以更好地将多个操作融合在一起，从而充分利用 CPU 执行单元和流水线。矢量化查询执行不是特别实用，因为它涉及必须写到缓存并读回的临时向量。如果 L2 缓存容纳不下临时数据，那么这将成为一个问题。但矢量化查询执行更容易利用 CPU 的 SIMD 功能。
使用场景
为OLAP查询而设计的。
它可以处理少量包含大量字段的表。
查询可以使用从数据库中提取的大量行，但只用一小部分字段。
查询相对较少(通常每台服务器大约100个RPS)。
对于简单的查询，允许大约50毫秒的延迟。
列值相当小，通常由数字和短字符串组成(例如每个URL，60字节)。
处理单个查询时需要高吞吐量(每台服务器每秒数十亿行)。
查询结果主要是过滤或聚合的。
数据更新使用简单的场景(通常只是批量处理，没有复杂的事务)。
ClickHouse的一个常见情况是服务器日志分析。在将常规数据上传到ClickHouse之后(建议将数据每次1000条以上批量插入)，就可以通过即时查询分析事件或监视服务的指标，如错误率、响应时间等。
2021年10月下末旬消息：ClickHouse 宣布获得 2.5 亿美元 B 轮融资，估值已达 20 亿美元。
ClickHouse 是开源、高性能的列式 OLAP 数据库，支持使用 SQL 进行实时分析。官方称其性能超过了市场上同类的列式数据库，每台服务器每秒可处理数亿到超过十亿行、体积达数十 GB 的数据，运行速度比传统数据库快 100-1000 倍。它最初由俄罗斯 IT 公司 Yandex 为 Yandex.Metrica 网络分析服务开发，并于 2016 年正式开源。自开源以来，总共有 800 多个贡献者向 ClickHouse 提交了 20000 多个 PR。作为开源技术解决方案，ClickHouse 被诸如 Uber, Comcast, eBay 和 Cisco 等大公司采用。
2021 年 8 月，ClickHouse 注册成立公司，并宣布筹集到 5000 万美元 A 轮融资。根据 DB-Engines 数据库排行榜的2021年10月数据，ClickHouse 排名为 45 名，较去年同期上升了 10 名。
最新版本：20.11
ClickHouse官网
ClickHouse中文社区
ClickHouse 作为一个高性能 OLAP 数据库，虽然OLAP能力逆天但也不应该把它用于任何OLTP事务性操作的场景，相比OLTP：不支持事务、不擅长根据主键按行粒度的查询、不擅长按行删除数据，目前市场上的其他同类高性能 OLAP 数据库同样也不擅长这些方面。因为对于一款OLAP数据库而言，OLTP 能力并不是重点，支持Linux, MacOS操作系统，采用C++编写并在Apache许可证下授权。
ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。这些功能共同为ClickHouse极速的分析性能奠定了基础。
架构
1、ClickHouse 存储架构
2、ClickHouse部署
扩展性
其本身不扩展，可借助Distributed引擎(本身不存储数据)
写：
指定哪些数据写入到哪些节点里
通过一个节点写，数据分到不同的节点里，通过指定分片的key来分发数据。
数据写入是异步的，对于插入数据到集群的其他节点，数据先是写入到本地磁盘，然后在后台发送到其他分片服务器，如果想查看数据有没有同步完，可以检查下面的目录：/var/lib/clickhouse/data/database/table
读：
由一个节点收集所有节点数据返回客户端
可靠性
依赖于zookeeper，使用物理复制
ClickHouse适合流式或批次入库的时序数据。ClickHouse不应该被用作通用数据库，而是作为超高性能的海量数据快速查询的分布式实时处理平台，在数据汇总查询方面(如GROUP BY)，ClickHouse的查询速度非常快。
典型特点：ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、具有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用。
简言之：ClickHouse作为分析型数据库，有三大特点:一是跑分快， 二是功能多 ，三是文艺范。
(1)、跑分快：ClickHouse跑分是Vertica的五倍快
其性能超过了市面上大部分的列式存储数据库，相比传统的数据ClickHouse要快100-1000X， ClickHouse还是有非常大的优势：
100Million 数据集：ClickHouse比Vertica约快5倍，比Hive快279倍，比MySQL快801倍
1Billion 数据集：ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了
(2)、功能多：ClickHouse支持数据统计分析各种场景
支持类SQL查询，支持繁多库函数(例如IP转化，URL分析等，预估计算/HyperLoglog等)、支持数组(Array)和嵌套数据结构(Nested Data Structure)、支持数据库异地复制部署+支持分布式
(3)、文艺范：目前ClickHouse的限制很多，生来就是为小资服务的
– 相对较缺乏的文档，社区刚开始活跃，只有开源的C++源码
– 不理睬Hadoop生态，走自己的路
ClickHouse特点
在内存数据库领域号称是最快的。
数据始终以列存储，包括矢量执行过程。
有两种不同的加速查询处理的方法： 矢量化查询执行和运行时代码生成。
列存储数据库，使用向量查询技术，select，orderby，limit操作都不改原列向量，而是新建。适合少修改的数据。
使用抽象渗漏提高速度，使列的数据与数据类型、数据块处理分离。
查询流水线每一步中间数据都保存，临时数据要适合CPU缓存。
对于分布式数据不完全支持join这样的复杂查询。
使用稀疏索引，不适合高负载的点状查询。
不依赖Hadoop生态，能够存储和处理数PB的数据。
不支持事物，缺乏完整的UPDATE/DELETE实现。
向量化引擎：数据不仅按列存储，而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。
允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器。
真正的列式数据库，没有任何内容与值一起存储。例如，支持常量长度值，以避免将它们的长度“ number”存储在值的旁边。
线性可扩展性，可以通过添加服务器来扩展集群。
容错性。系统是一个分片集群，其中每个分片都是一组副本。ClickHouse使用异步多主复制。数据写入任何可用的副本，然后分发给所有剩余的副本。Zookeeper用于协调进程，但不涉及查询处理和执行。
SQL支持，Clickhouse支持类似SQL的扩展语言，包括数组和嵌套数据结构、近似函数和URI函数，以及连接外部键值存储的可用性。
使用向量计算。数据不仅由列存储，而且由向量处理(一部分列)。这种方法可以实现高CPU性能。
支持采样和近似计算和进行并行和分布式查询处理(包括JOIN)。
数据压缩与HDD优化，可以处理不适合内存的数据。
用于数据库(DB)连接的客户端。数据库连接方式包括控制台客户端、HTTP API，或者各种编程语言的wrapper(可以用的有Python、PHP、NodeJS、Perl、Ruby与R语言)，也可以使用JDBC驱动。
1、ClickHouse适用场景
适合:用于结构良好清晰且不可变的事件或日志流实时查询分析。
不适合:事务性工作(OLTP)，高请求率的键值访问，低延迟的修改或删除已存在数据，Blob或文档存储，超标准化数据。
2、ClickHouse优点
与 Hadoop、Spark 这些巨无霸组件相比，ClickHouse 具有轻量级的优点，它的特点包括以下内容：
(1)真正的面向列的 DBMS
ClickHouse 是一个 DBMS，而不是一个单一的数据库。它允许在运行时创建表和数据库、加载数据和运行 查询，而无需重新配置和重新启动服务器。
(2)数据压缩
一些面向列的 DBMS(InfiniDB CE 和 MonetDB)不使用数据压缩，但数据压缩确实提高了性能。
(3)磁盘存储的数据
许多面向列的 DBMS(SAP HANA 和 GooglePowerDrill)只能在内存中工作。但即使在数千台服务器 上，内存也太小，无法在 Yandex.Metrica 中存储所有浏览量和会话。
(4)多核并行处理、多核多节点并行化大型查询。
(5)在多个服务器上分布式处理
在 ClickHouse 中，数据可以驻留在不同的分片上。每个分片都可以用于容错的一组副本，查询会在所有分 片上并行处理。
(6)SQL支持
ClickHouse SQL 跟真正的 SQL 有不一样的函数名称。不过语法基本跟 SQL 语法兼容，支持 JOIN、 FROM、IN 和 JOIN 子句以及标量子查询支持子查询。
(7)向量化引擎
数据不仅按列存储，而且由矢量 – 列的部分进行处理，这使开发者能够实现高 CPU 性能。
(8)实时数据更新
ClickHouse 支持主键表。为了快速执行对主键范围的查询，数据使用合并树 (MergeTree) 进行递增排序。由于这个原因，数据可以不断地添加到表中。
(9)支持近似计算
该库支持为有限数量的随机密钥(而不是所有密钥)运行聚合。在数据中密钥分发的特定条件下，这提供了相 对准确的结果，同时使用较少的资源。
(10)数据复制和对数据完整性的支持
ClickHouse 使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复。扩展成为分布式的数据库OLAP引擎，严重依赖于zookeeper。
3、ClickHouse缺点
ClickHouse 作为一个被设计用来在实时分析的 OLAP 组件，只是在高效率的分析方面性能发挥到极致，那必然就会在其他方面做出取舍：
(1)没有完整的事务支持，不支持Transaction，想快就别想Transaction
(2)缺少完整的Update/Delete操作，缺少高频率、低延迟的修改或删除已存在数据的能力，仅能用于批量删除或修改数据
(3)聚合结果必须小于一台机器的内存大小:不是大问题
(4)支持有限操作系统，正在慢慢完善
(5)开源社区刚刚启动，主要是俄语为主
(6)不适合key-value存储，不支持 Blob 等文档型数据库
ClickHouse还可以用作内部分析师的内部数据仓库，它可以存储来自不同系统的数据(比如Hadoop或某些日志)，分析人员可以使用这些数据构建内部指示板，或者为了业务目的执行实时分析。
ClickHouse产生背景
1、现有的大数据架构分析报表的缺点
如果我们要做一个基于Hadoop传统的数据分析会是下面的一个架构：程序实时的生成日志发送到kafka，在经过ETL处理之后入库到Hive仓库，数据仓库经过分析之后，将结果导出最后生成报表。
基于Hadoop 的报表数据分析架构缺点如下：
1)、数据时效性：数据经过了Kafka、ELK、调度和各种的处理，所以最终的时效性不是那么的理想，就算这个架构最终优化的很好，那么最终的查询结果也都是秒级
2)、即席分析性能：Hive数据存储在HDFS中，HDFS是不支持随机读写的，Hive底层使用的分析引擎，要么是MapReduce要么是Spark，相对来说，他们的执行效率都没有理想中那么好，不适合即席查询
3)、涉及组件多：涉及Kafka、Flume、HDFS等等，数据冗余过多，维护起来麻烦
4)、数据链路长：数据从源头到最终生成报表，中间经过了非常多的技术组件的处理，要是其中一个技术组件出现问题，那么都会影响我们的可用性
最终的结果就是，我们基于传统的大数据分析架构进行报表分析，貌似没能达到我们理想中的效果，这个时候我们就期望大数据的性能能够更进一步，或者说有一个系统能够帮我们解决这些问题。
2、新时代的选择
架构目标：
1)、海量数据
2)、实时导入
3)、实时查询
4)、多维聚合分析，可以随意做交互式查询
假设我们依旧希望使用Hadoop来解决问题，那么我们希望Hadoop的性能可以翻上几番，但是Hadoop生态体系还是很复杂的，对开发、运维、架构师都有不少的挑战，所以在新时代，新需求冒出来之后，就有很多的公司开发出来了很多的新技术，有kylin,doris,clickhouse,kudu等，这种技术能通过比较低的复杂度来帮助我们高效的解决即席查询的需求。
OLAP和OLTP技术要点分析
1、OLAP和OLTP介绍
ClickHouse作为OLAP分析引擎，那么OLAP和OLTP也是我们不得不了解的概念。
OLTP：T(transaction)联机事务处理，侧重于增删改
OLAP：A(analysis)联机分析处理，侧重于分析Select非事务大批量数据的聚合查询
事务处理作用：保证数据的一致性，如果涉及到事务操作，这个操作的执行效率必然不高。
我们设计一款存储系统，没法做到既能满足高效的增删改，又能做高效的查询分析，两者同时满足很困难。基本在业界出现的查询系统，要么是OLAP要么是OLTP，很少且几乎没有同时具备OLAP和OLTP两种特性的高效性。
2、读模式和写模式
写模式：数据存储到系统中的时候，系统会对数据进行校验，如果满足要求数据就能插入进去，如果不满足要求则拒绝写入。
读模式：校验数据模式的时候，在读取数据的时候才进行校验，不是在插入数据的时候进行校验。
OLAP一般都是读模式，OLTP写模式，ClickHouse出来，界限就模糊了。
ClickHouse写模式+OLAP。
3、海量数据高效即席查询需要的条件
海量数据做查询分析高效：列式数据库，写模式(保证同一列的数据类型是一样的，方便压缩)，排序，具体优点如下：
1、列式数据库：假设我们一张表有100个字段，我们做查询分析只需要用到其中的几个字段，如果我们是行式数据库，那么我们就需要把这张表的数据都读取出来，我们读取到这行的时候，只需要提取100个字段中的几个字段就能分析。如果是列式数据库，则只需要扫描需要的字段即可完成查询分析。 所以我们在海量数据，想要设计出一块高效的即席查询系统，一定要将底层的数据存储改为列式存储。
2、既然我们将存储改成了列式存储，那么我们就需要对每一列的数据做一个校验，ClickHouse是一个列式数据库，同时他也是一个写模式，就是为了数据写入的时候可以进行校验，写入一列数据，它可以保证一列数据值的类型都是一样的。因为每一个记录这个值的大小都是一样的，所以就类似于我们可以通过连续内存的这个模式来进行存储，对于我们解析和处理来说也会显现的非常高效。
3、同时因为所有字段的值都是一样的，所以我们压缩的时候效果也会特别的高。
4、因为我们这一列的值都是一样的，所以我们做排序的时候也有助于我们进行查询分析。
OLAP体系的重要三个特点：排序+写模式+列式数据库，ClickHouse全部具备。
ClickHouse核心目录：
(1)/etc/clickhouse-server:服务端的配置文件目录，包括全局配置config.xml和用户配置users.xml等
(2)/var/lib/clickhouse:默认数据存储目录，通常会修改默认路径配置，将数据保存到大容量磁盘挂 载路径
(3)/var/log/clickhouse-server:默认日志保存目录，通常会修改路径配置将日志保存到大容量磁盘 挂载的路径
ClickHouse可执行文件：
(1)clickhouse:主程序的可执行文件
(2)clickhouse-client:一个指向ClickHouse可执行文件的软链接，供客户端连接使用
(3)clickhouse-server:一个指向ClickHouse可执行文件的软链接，供服务端启动使用
(4)clickhouse-compressor:内置提供的压缩工具，可用于数据的正压反解
ClickHouse每个节点在安装的时候，都是独立的。就算是配置成集群了，每个服务器依然还是单独运行的；如果创建了一张表，这张表的引擎是分布式的引擎，那么这个表所存储在那个集群里面的机器，就是一个集群了。
运行快的原因
它的数据剪枝能力比较强，分区剪枝在执行层，而存储格式用局部数据表示，就可以更细粒度地做一些数据的剪枝。它的引擎在实际使用中应用了一种现在比较流行的 LSM 方式。
它对整个资源的垂直整合能力做得比较好，并发 MPP+SMP 这种执行方式可以很充分地利用机器的集成资源。它的实现又做了很多性能相关的优化，它的一个简单的汇聚操作有很多不同的版本，会根据不同 Key 的组合方式有不同的实现。对于高级的计算指令，数据解压时，它也有少量使用。
ClickHouse 是一套完全由 C++ 模板 Code 写出来的实现。
不支持Transaction。
使用了矢量化查询执行
当进行查询时，操作被转发到数组上，而不是在特定的值上。
向量化查询执行实用性并不那么高，如果临时数据并不适合L2缓存，读缓存将有问题。但是向量化查询执行更容易利用CPU的SIMD能力。
提供了有限的运行时动态代码生成(group by的内部循环第一阶段)。
运行时代码生成可以更好地将多个操作融合在一起，从而充分利用 CPU 执行单元和流水线。矢量化查询执行不是特别实用，因为它涉及必须写到缓存并读回的临时向量。如果 L2 缓存容纳不下临时数据，那么这将成为一个问题。但矢量化查询执行更容易利用 CPU 的 SIMD 功能。
使用场景
为OLAP查询而设计的。
它可以处理少量包含大量字段的表。
查询可以使用从数据库中提取的大量行，但只用一小部分字段。
查询相对较少(通常每台服务器大约100个RPS)。
对于简单的查询，允许大约50毫秒的延迟。
列值相当小，通常由数字和短字符串组成(例如每个URL，60字节)。
处理单个查询时需要高吞吐量(每台服务器每秒数十亿行)。
查询结果主要是过滤或聚合的。
数据更新使用简单的场景(通常只是批量处理，没有复杂的事务)。
ClickHouse的一个常见情况是服务器日志分析。在将常规数据上传到ClickHouse之后(建议将数据每次1000条以上批量插入)，就可以通过即时查询分析事件或监视服务的指标，如错误率、响应时间等。
2021年10月下末旬消息：ClickHouse 宣布获得 2.5 亿美元 B 轮融资，估值已达 20 亿美元。
ClickHouse 是开源、高性能的列式 OLAP 数据库，支持使用 SQL 进行实时分析。官方称其性能超过了市场上同类的列式数据库，每台服务器每秒可处理数亿到超过十亿行、体积达数十 GB 的数据，运行速度比传统数据库快 100-1000 倍。它最初由俄罗斯 IT 公司 Yandex 为 Yandex.Metrica 网络分析服务开发，并于 2016 年正式开源。自开源以来，总共有 800 多个贡献者向 ClickHouse 提交了 20000 多个 PR。作为开源技术解决方案，ClickHouse 被诸如 Uber, Comcast, eBay 和 Cisco 等大公司采用。
2021 年 8 月，ClickHouse 注册成立公司，并宣布筹集到 5000 万美元 A 轮融资。根据 DB-Engines 数据库排行榜的2021年10月数据，ClickHouse 排名为 45 名，较去年同期上升了 10 名。
最新版本：20.11
ClickHouse官网
ClickHouse中文社区