OLAP数据库ClickHouse，补充你的弹药库

ClickHouse是由俄罗斯搜索引擎公司Yandex公司开源的OLAP数据库，性能表现优异，官方的基准测试中，平响速度是Hive的126倍，MySQL的429倍。

从2016年开源以来，飞速发展，在官网的使用者列表里，你会发现有许多国内互联网公司在用，有云产品、日志产品、银行数据分析等等。每个后面都会有相对应的PPT或视频。

官网在介绍ClickHouse是什么时，用下面两张图形象的来传达一个「列式」数据库带来的查询速度的提升，以及在OLAP是多么的合适。

短短几年的发展，从DB-Engines上的这条红线就能看出势头迅猛

除了基础数据类型外，ClickHouse还提供了对复合数据类型的支持，像数组、元组、枚举和嵌套，通过array、json、tuple、set等复合数据类型，业务Schema 能更灵活。

由于ClickHouse设计之初，就是OLAP的需求，所以提供的特性，自然契合和满足OLAP的场景，比如下面的特点：

读多于写

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

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

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

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

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

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

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

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

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

和MySQL支持多种存储引擎类似，ClickHouse 也提供了丰富的表引擎，像合并树、外部存储、文件、接口等六大类20多种表引擎。

官网之外，市面上关于ClickHouse成体系的书籍不多，这本『ClickHouse 原理解析与应用实践』首本讲解ClickHouse书籍，作者朱凯，是ClickHouse贡献者之一，书籍从ClickHouse的产生时代背景、运行原理，实践指导等多个维度来解析ClickHouse 的架构、原理和使用，运维等。