clickhouse数据库简介

1、关于列存储

所说的行式存储和列式存储，指的是底层的存储形式，数据在磁盘上的真实存储，至于暴漏在上层的用户的使用是没有区别的，看到的都是一行一行的表格。

id	name	user_id
1	闪光	1026603
2	轨道物流	1026556

行式存储

列式存储

存储方式的不同就决定了读取和存储数据的逻辑不同，比如，要查询id这一列的全部数据，如果是行存储的话，就需要加载整张表，然后遍历取出id这一个字段；如果是列存储的话，只需要加载第一段的数据即可。相反的，如果你需要查询第一条记录，如果是行存储的话，只需要读取第一段数据，如果是列存储的话，需要全部读取出来遍历后拼凑出第一条记录。

同样的，在写入数据的时候，显然列存储要更费劲一些。

列存储模式下，同一类数据存放在一起，这在一定程度上有利于数据压缩，比如user_id字段，可以抽出基数部分（1026556）和偏移量(47，0)，数据量大的话压缩效果就出来了。而对于字符串字段，同样可以采取很好的压缩算法。官方数据显示，通过使用列存，在某些分析场景下，能够获得100倍甚至更高的加速效应。

行式更适合OLTP（OnLineTransaction ），比如传统的基于增删改查操作的应用。列式更适合OLAP（OnLineAnalyticalProcessing），非常适合于在数据仓库领域发挥作用，比如数据分析、海量存储和商业智能；涉及不经常更新的数据。

2、OLAP场景的特点

读多于写

不同于**事务处理（OLTP）**的场景，比如电商场景中加购物车、下单、支付等需要在原地进行大量insert、update、delete操作；**数据分析（OLAP）**场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。数据一次性写入后，分析师需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

大宽表，读大量行但是少量列，结果集较小

在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。

数据批量写入，且数据不更新或少更新

OLTP类业务对于延时（Latency）要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加关注写入吞吐（Throughput），要求海量数据能够尽快导入完成。一旦导入完成，历史数据往往作为存档，不会再做更新和删除操作。

无需事务，数据一致性要求低

OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。多数OLAP系统都支持最终一致性。

灵活多变，不适合预先建模

分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价十分高昂。预先建模技术虽然可以在特定场景中加速计算，但是无法满足业务灵活多变的发展需求，维护成本过高。

3、关于clickHouse

clickHouse是一个开源的列式数据库（DBMS），于2016年，由俄罗斯最大的搜索公司Yandex开源，采用C++开发。凭借优秀的性能，市场反应非常热烈。阿里，腾讯，头条都在大量使用clickhouse来做数据分析智能推荐。

在OLAP场景中侧重于对数据的分析，因此读数据操作是多于写数据的。在数据一次性写入后，数据工程师需要从各个角度对数据进行挖掘、分析，直到发现其中的业务变化趋势，对于数据的读取是非常频繁，而且不需要数据的更新，也不需要事务来强调一致性，只要获取到数据就好啦，ClickHouse非常适合作为底层数据库提供支持。

ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。

所谓数据的有序存储指的是数据在建表时可以将数据按照某些列进行排序，排序之后，相同类型的数据在磁盘上有序的存储，在进行范围查询时所获取的数据都存储在一个或若干个连续的空间内，极大的减少了磁盘IO时间；所谓数据分区分片，指的是在ClickHouse的部署模式上支持单机模式和分布式集群模式，在分布式中会把数据分为多个分片，并且分布到不同的节点上，它提供了丰富的分片策略，包含random随机分片（将写入数据随机分发到集群中的某个节点）、constant固定分片（将写入数据分发到某个固定节点）、columnvalue分片（将写入数据按某一列的值进行hash分片）、自定义表达式分片（将写入数据按照自定义的规则进行hash分片）。

在计算层ClickHouse提供了多核并行、分布式计算、近似计算、复杂数据类型支持等技术能力，最大化程度利用CPU资源，提升系统查询速度。所谓多核并行指的是在ClickHouse中数据是被分成了多个分区，查询某条数据时通过多分区的数据利用CPU的多核同时并行处理获取数据，降低了查询时长；所谓分布式计算指的是ClickHouse将查询任务拆分成多个子任务下发到多个集群中进行多机并行处理，最后汇聚结果给到用户，提供最近hostname规则（即将任务下发到机器最近的hostname节点）、inorder（即按顺序进行分发，当某个分片不可用时，下发到下一个分片）；所谓近似计算指的是牺牲一定的精确度获取数据，在海量数据的分析中，其实并不需要非常精准的数据，近似数据足以分析决策，ClickHouse提供了中位数、分位数等多种聚合函数，极大的提高了查询性能，减轻了计算压力。

ClickHouse的发展可谓是非常快速，除了各个大厂都在使用之外，在社区方面，github标记为星级项目的人超过9000，成为最受开源的项目之一。它是一套完整的解决方案，自带存储能力、计算能力，自己实现了分布式计算、分布式集群部署，完全高可用，真可谓是简单灵活又不失强大！

4、结语

近年来ClickHouse发展趋势迅猛，社区和大厂都纷纷跟进使用。本文尝试从OLAP场景的需求出发，介绍了ClickHouse存储层、计算层的主要设计。ClickHouse实现了大多数当前主流的数据分析技术，具有明显的技术优势：

• 提供了极致的查询性能：开源公开benchmark显示比传统方法快1001000倍，提供50MB200MB/s的高吞吐实时导入能力）
• 以极低的成本存储海量数据： 借助于精心设计的列存、高效的数据压缩算法，提供高达10倍的压缩比，大幅提升单机数据存储和计算能力，大幅降低使用成本，是构建海量数据仓库的绝佳方案。
• 简单灵活又不失强大：提供完善SQL支持，上手十分简单；提供json、map、array等灵活数据类型适配业务快速变化；同时支持近似计算、概率数据结构等应对海量数据处理。

相比于开源社区的其他几项分析型技术，如Druid、Presto、Impala、Kylin、ElasticSearch等，ClickHouse更是一整套完善的解决方案，它自包含了存储和计算能力（无需额外依赖其他存储组件），完全自主实现了高可用，而且支持完整的SQL语法包括JOIN等，技术上有着明显优势。相比于hadoop体系，以数据库的方式来做大数据处理更加简单易用，学习成本低且灵活度高。当前社区仍旧在迅猛发展中，相信后续会有越来越多好用的功能出现。

参考阅读

https://zhuanlan.zhihu.com/p/98135840

https://developer.aliyun.com/live/43846