OLAP计算引擎之Clickhouse是什么？
⼀ clickhouse简介
1.1什么是clickhouse
ClickHouse是俄罗斯的Yandex于2016年开源的⼀个⽤于联机分析(OLAP:Online Analytical Processing)的列式数据库管理系统(DBMS:Database Management System)，简称CH , 主要⽤于在线分析处理查询（OLAP），能够使⽤SQL查询实时⽣成分析数据报告。
ClickHouse是⼀个完全的列式数据库管理系统，允许在运⾏时创建表和数据库，加载数据和运⾏查询，⽽⽆需重新配置和重新启动服务器，⽀持线性扩展，简单⽅便，⾼可靠性，容错。它在⼤数据领域没有⾛ Hadoop ⽣态，⽽是采⽤ Local attached storage 作为存储，这样整个 IO 可能就没有 Hadoop 那⼀套的局限。它的系统在⽣产环境中可以应⽤到⽐较⼤的规模，因为它的线性扩展能⼒和可靠性保障能够原⽣⽀持 shard + replication 这种解决⽅案。它还提供了⼀些 SQL 直接接⼝，有⽐较丰富的原⽣ client。另外就是它⽐较快。
选择ClickHouse 的⾸要原因是它⽐较快，但其实它的技术没有什么新的地⽅，为什么会快？
它的数据剪枝能⼒⽐较强，分区剪枝在执⾏层，⽽存储格式⽤局部数据表⽰，就可以更细粒度地做⼀些数据的剪枝。它的引擎在实际使⽤中应⽤了⼀种现在⽐较流⾏的 LSM ⽅式。
它对整个资源的垂直整合能⼒做得⽐较好，并发 MPP+ SMP 这种执⾏⽅式可以很充分地利⽤机器的
集成资源。它的实现⼜做了很多性能相关的优化，它的⼀个简单的汇聚操作有很多不同的版本，会根据不同 Key 的组合⽅式有不同的实现。对于⾼级的计算指令，数据解压时，它也有少量使⽤。
ClickHouse 是⼀套完全由 C++ 模板 Code 写出来的实现，代码还是⽐较优雅的。
ClickHouse是⼀个完全的列式数据库
1.2特征
1.2.1真正的列式数据库管理系统
在⼀个真正的列式数据库管理系统中，除了数据本⾝外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长
度«number»，你必须⽀持固定长度数值类型。例如，10亿个UInt8类型的数据在未压缩的情况下⼤约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使⽤产⽣强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是⾮常重要的，因为解压缩的速度主要取决于未压缩数据的⼤⼩。
这是⾮常值得注意的，因为在⼀些其他系统中也可以将不同的列分别进⾏存储，但由于对其他场景进⾏的优化，使其⽆法有效的处理分析查询。例如： HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数⼗万的吞吐能⼒，但是⽆法得到每秒⼏亿⾏的吞吐能⼒。
update是什么
需要说明的是，ClickHouse不单单是⼀个数据库，它是⼀个数据库管理系统。因为它允许在运⾏时创建表和数据库、加载数据和运⾏查询，⽽⽆需重新配置或重启服务。
1.2.2数据压缩
在⼀些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使⽤数据压缩。但是, 若想达到⽐较优异的性能，数据压缩确实起到了⾄关重要的作⽤。
1.2.3数据的磁盘存储
许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中⼯作，这种⽅式会造成⽐实际更多的设备预算。ClickHouse被设计⽤于⼯作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使⽤SSD和内存，它也会合理的利⽤这些资源。
1.2.4多核并⾏处理
ClickHouse会使⽤服务器上⼀切可⽤的资源，从⽽以最⾃然的⽅式并⾏处理⼤型查询。
1.2.5多服务器分布式处理
上⾯提到的列式数据库管理系统中，⼏乎没有⼀个⽀持分布式的查询处理。
在ClickHouse中，数据可以保存在不同的shard上，每⼀个shard都由⼀组⽤于容错的replica组成，查询可以并⾏地在所有shard上进⾏处理。这些对⽤户来说是透明的
1.2.6⽀持sql
ClickHouse⽀持基于SQL的声明式查询语⾔，该语⾔⼤部分情况下是与SQL标准兼容的。
⽀持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及⾮相关⼦查询。
不⽀持窗⼝函数和相关⼦查询。
1.2.7向量引擎
为了⾼效的使⽤CPU，数据不仅仅按列存储，同时还按向量(列的⼀部分)进⾏处理，这样可以更加⾼效地使⽤CPU。
1.2.8实时的数据更新
ClickHouse⽀持在表中定义主键。为了使查询能够快速在主键中进⾏范围查，数据总是以增量的⽅式有序的存储在MergeTree中。因此，数据可以持续不断地⾼效的写⼊到表中，并且写⼊的过程中不会存在任何加锁的⾏为。
1.2.9索引
按照主键对数据进⾏排序，这将帮助ClickHouse在⼏⼗毫秒以内完成对数据特定值或范围的查。
1.2.10适合在线查询
在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到⽤户的页⾯中。
1.2.11⽀持近似计算
ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进⾏加速的⽅法：
1. ⽤于近似计算的各类聚合函数，如：distinct values, medians, quantiles
2. 基于数据的部分样本进⾏近似查询。这时，仅会从磁盘检索少部分⽐例的数据。
3. 不使⽤全部的聚合条件，通过随机选择有限个数据聚合条件进⾏聚合。这在数据聚合条件满⾜某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使⽤。
1.2.12⽀持数据复制和数据完整性
ClickHouse使⽤异步的多主复制技术。当数据被写⼊任何⼀个可⽤副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在⼤多数情况下ClickHouse能在故障后⾃动恢复，在⼀些少数的复杂情况下需要⼿动恢复。
1.3性能
1.3.1优点
为了⾼效的使⽤CPU，数据不仅仅按列存储，同时还按向量进⾏处理；
数据压缩空间⼤，减少IO；处理单查询⾼吞吐量每台服务器每秒最多数⼗亿⾏；
索引⾮B树结构，不需要满⾜最左原则；只要过滤条件在索引列中包含即可；即使在使⽤的数据不在索引中，由于各种并⾏处理机制ClickHouse全表扫描的速度也很快；
写⼊速度⾮常快，50-200M/s，对于⼤量的数据更新⾮常适⽤。
1.3.2缺点
不持事务，不⽀持真正的删除/更新；
不⽀持⾼并发，官⽅建议qps为100，可以通过修改配置⽂件增加连接数，但是在服务器⾜够好的情况下；
不⽀持真正的删除/更新⽀持 不⽀持事务（期待后续版本⽀持）
不⽀持⼆级索引
有限的SQL⽀持，join实现与众不同
不⽀持窗⼝功能
元数据管理需要⼈⼯⼲预维护
SQL满⾜⽇常使⽤80%以上的语法，join写法⽐较特殊；最新版已⽀持类似SQL的join，但性能不好；
尽量做1000条以上批量的写⼊，避免逐⾏insert或⼩批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写⼊的时候要尽量避开；
ClickHouse快是因为采⽤了并⾏处理机制，即使⼀个查询，也会⽤服务器⼀半的CPU去执⾏，所以Cli
ckHouse不能⽀持⾼并发的使⽤场景，默认单查询使⽤CPU核数为服务器核数的⼀半，安装时会⾃动识别服务器核数，可以通过配置⽂件修改该参数。
1.3.3优化
关闭虚拟内存，物理内存和虚拟内存的数据交换，会导致查询变慢。
为每⼀个账户添加join_use_nulls配置，左表中的⼀条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，⽽不是标准SQL中的Null值。
JOIN操作时⼀定要把数据量⼩的表放在右边，ClickHouse中⽆论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每⼀条记录到左表中查该记录是否存在，所以右表必须是⼩表。
批量写⼊数据时，必须控制每个批次的数据中涉及到的分区的数量，在写⼊之前最好对需要导⼊的数据进⾏排序。⽆序的数据或者涉及的分区太多，会导致ClickHouse⽆法及时对新导⼊的数据进⾏合并，从⽽影响查询性能。
尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进⾏聚合操作，减少数据条数。有些时候，先GROUP BY再JOIN⽐先JOIN再GROUP BY查询时间更短。
ClickHouse的分布式表性能性价⽐不如物理表⾼，建表分区字段值不宜过多，防⽌数据导⼊过程磁盘可能会被打满。
CPU⼀般在50%左右会出现查询波动，达到70%会出现⼤范围的查询超时，CPU是最关键的指标，要⾮常关注。
1.3.4性能情况
单个查询吞吐量：如果数据被放置在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也是很有讲究的。
其他补充：
MySQL单条SQL是单线程的，只能跑满⼀个core，ClickHouse相反，有多少CPU，吃多少资源，所以飞快；
ClickHouse不⽀持事务，不存在隔离级别。ClickHouse的定位是分析性数据库，⽽不是严格的关系型数据库。
IO⽅⾯，MySQL是⾏存储，ClickHouse是列存储，后者在count()这类操作天然有优势，同时，在IO⽅⾯，MySQL需要⼤量随机IO，ClickHouse基本是顺序IO。
有⼈可能觉得上⾯的数据导⼊的时候，数据肯定缓存在内存⾥了，这个的确，但是ClickHouse基本上是顺序IO。对IO基本没有太⾼要求，当然，磁盘越快，上层处理越快，但是99%的情况是，CPU先跑满了（数据库⾥太少见了，⼤多数都是IO不够⽤）。
1.4应⽤场景
绝⼤多数请求都是⽤于读访问的
数据需要以⼤批次（⼤于1000⾏）进⾏更新，⽽不是单⾏更新；或者根本没有更新操作
数据只是添加到数据库，没有必要修改
读取数据时，会从数据库中提取出⼤量的⾏，但只⽤到⼀⼩部分列
表很“宽”，即表中包含⼤量的列
查询频率相对较低（通常每台服务器每秒查询数百次或更少）
对于简单查询，允许⼤约50毫秒的延迟
列的值是⽐较⼩的数值和短字符串（例如，每个URL只有60个字节）
在处理单个查询时需要⾼吞吐量（每台服务器每秒⾼达数⼗亿⾏）
不需要事务
数据⼀致性要求较低
每次查询中只会查询⼀个⼤表。除了⼀个⼤表，其余都是⼩表
查询结果显著⼩于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存⼤⼩

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。