clickhouse简介
1.1什么是clickhouse
ClickHouse是俄罗斯的Yandex于年开源的一个用于联机分析(OLAP:OnlineAnalyticalProcessing)的列式数据库管理系统(DBMS:DatabaseManagementSystem)，简称CH,主要用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。
ClickHouse是一个完全的列式数据库管理系统，允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，容错。它在大数据领域没有走Hadoop生态，而是采用Localattachedstorage作为存储，这样整个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。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。
需要说明的是，ClickHouse不单单是一个数据库，它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。
1.2.2数据压缩
在一些列式数据库管理系统中(例如：InfiniDBCE和MonetDB)并没有使用数据压缩。但是,若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。
1.2.3数据的磁盘存储
许多的列式数据库(如SAPHANA,GooglePowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使用SSD和内存，它也会合理的利用这些资源。
1.2.4多核并行处理
ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。
1.2.5多服务器分布式处理
上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的
1.2.6支持sql
ClickHouse支持基于SQL的声明式查询语言，该语言大部分情况下是与SQL标准兼容的。支持的查询包括GROUPBY，ORDERBY，IN，JOIN以及非相关子查询。不支持窗口函数和相关子查询。
1.2.7向量引擎
为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。
1.2.8实时的数据更新
ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。
1.2.9索引
按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找。
1.2.10适合在线查询
在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。
1.2.11支持近似计算
ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：
1.用于近似计算的各类聚合函数，如：distinctvalues,medians,quantiles
2.基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。
3.不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。
1.2.12支持数据复制和数据完整性
ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。
1.3性能
1.3.1优点
为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；写入速度非常快，50-M/s，对于大量的数据更新非常适用。
1.3.2缺点
不持事务，不支持真正的删除/更新；不支持高并发，官方建议qps为，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；不支持真正的删除/更新支持不支持事务（期待后续版本支持）不支持二级索引有限的SQL支持，join实现与众不同不支持窗口功能元数据管理需要人工干预维护SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；尽量做0条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；ClickHouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。
1.3.3优化
关闭虚拟内存，物理内存和虚拟内存的数据交换，会导致查询变慢。为每一个账户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值。JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是LeftJoin、RightJoin还是InnerJoin永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致ClickHouse无法及时对新导入的数据进行合并，从而影响查询性能。尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进行聚合操作，减少数据条数。有些时候，先GROUPBY再JOIN比先JOIN再GROUPBY查询时间更短。ClickHouse的分布式表性能性价比不如物理表高，建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满。CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常