[业界方案] ClickHouse业界解决方案学习笔记

[业界方案] ClickHouse业界解决方案学习笔记

0x00 摘要

本文通过分析总结几篇文章来看目前工业界可能偏好的解决方案。学习目的是：大致知道其应用领域，技术特点和未来方向，看看目前工作中是否可以用到，或者当以后选型时候能够做到心里有数。

0x01 简介

ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。

目前国内社区火热，各个大厂纷纷跟进大规模使用：

今日头条用ClickHouse来做用户行为分析，一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。
腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。
携程目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。
快手内部也在使用ClickHouse，存储总量大约10PB，每天新增200TB， 90%查询小于3S。
在国外，Yandex内部有数百节点用于做用户点击行为分析，CloudFlare、Spotify等头部公司也在使用。

0x02 OLAP场景的特点

读多于写，需要尝试从各个角度对数据做挖掘、分析。需要反复试错、不断调整、持续优化，其中数据的读取次数远多于写入次数。要求底层数据库为这个特点做专门设计。
大宽表，读大量行但是少量列，结果集较小
数据批量写入，且数据不更新或少更新
无需事务，数据一致性要求低
灵活多变，不适合预先建模

0x03 选型原因

携程选型原因

尝试过关系型数据库，但千万级表关联数据库基本上不太可能做到秒出
考虑过Sharding，但数据量大，各种成本都很高。
热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，因为权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，维护成本也很高。
Redis键值对存储无法做到实时汇总，
也测试过Presto，GreenPlum，kylin，真正让我们停下来深入研究，不断的扩展使用场景的是ClickHouse。

头条选型原因

产品需求
- 交互式分析能力（in seconds）
- 查询模式多变
- 以大宽表为主
- 数据量大
开源MPP OLAP引擎 - （性能、特点、优质）

0x04 技术特点

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

从用户角度来说，ClickHouse就是实现了“多快好省，独立”。

快：提供了极致的查询性能
多：支持分布式集群模式，支持高吞吐写入能力
省：以极低的成本存储海量数据
好：提供完善SQL支持，上手十分简单；提供json、map、array等灵活数据类型适配业务快速变化；同时支持近似计算、概率数据结构等应对海量数据处理。
独立：独立于Hadoop技术栈

下面我们逐一介绍。

0x05 多

“多”这个特点具体是由如下具体技术实现来完成的。

数据Sharding

ClickHouse支持单机模式，也支持分布式集群模式。在分布式模式下，ClickHouse会将数据分为多个分片，并且分布到不同节点上。不同的分片策略在应对不同的SQL Pattern时，各有优势。ClickHouse提供了丰富的sharding策略，让业务可以根据实际需求选用。

sharding机制使得ClickHouse可以横向线性拓展，构建大规模分布式集群，从而具备处理海量数据的能力。

数据Partitioning

ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作。

在partition key上进行分区裁剪，只查询必要的数据。
对partition进行TTL管理，淘汰过期的分区数据。

高吞吐写入能力

ClickHouse采用类LSM Tree的结构，数据写入后定期在后台Compaction。通过类LSM tree的结构，ClickHouse在数据导入时全部是顺序append写，写入后数据段不可更改，在后台compaction时也是多个段merge sort后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在HDD上也有着优异的写入性能。

支持数据复制和数据完整性

ClickHouse 使用异步的多主复制技术。当数据被写入到任何一个可用副本后，系统在后台将数据分发给其他副本。

0x06 快

“ 快”这个特点具体是由如下具体技术实现来完成的。

列式存储

而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。
同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。

主键索引

ClickHouse支持主键索引。通过对主键索引进行二分查找，能够直接定位到对应的index granularity，避免了全表扫描从而加速查询。ClickHouse的主键索引并不用于去重，即便primary key相同的行，也可以同时存在于数据库中。

稀疏索引

ClickHouse支持对任意列创建任意数量的稀疏索引。之所以叫稀疏索引，是因为它本质上是对一个完整index granularity（默认8192行）的统计信息，并不会具体记录每一行在文件中的位置。

实时数据更新

ClcikHouse 数据是以增量的方式有序的存储在 MergeTree 中。因此，数据可以持续不断高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。

支持近似计算

ClickHouse 提供各种各样在允许牺牲精度的情况下对查询进行加速的方法

用于近似计算的各类聚合函数，比如，近似估算distinct values、中位数，分位数等多种聚合函数；
基于数据的部分样本进行近似查询，比如，建表DDL支持SAMPLE BY子句，支持对于数据进行抽样处理；
不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。

多核并行

ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下，单条Query就能利用整机所有CPU。极致的并行处理能力，极大的降低了查询延时。

向量化执行与SIMD

ClickHouse不仅将数据按列存储，而且按列进行计算。ClickHouse实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。

分布式计算

除了优秀的单机并行处理能力，ClickHouse还提供了可线性拓展的分布式计算能力。ClickHouse会自动将查询拆解为多个task下发到集群中，然后进行多机并行处理，最后把结果汇聚到一起。

数据Sharding

数据分片，让ClickHouse可以充分利用整个集群的大规模并行计算能力，快速返回查询结果。

0x07 好

“ 好”这个特点具体是由如下具体技术实现来完成的。

复杂数据类型支持

ClickHouse还提供了array、json、tuple、set等复合数据类型，支持业务schema的灵活变更。

主备同步

ClickHouse通过主备复制提供了高可用能力，主备架构下支持无缝升级等运维操作。而且相比于其他系统它的实现有着自己的特色：

1）默认配置下，任何副本都处于active模式，可以对外提供查询服务；

2）可以任意配置副本个数，副本数量可以从0个到任意多个；

3）不同shard可以配置不提供副本个数，用于解决单个shard的查询热点问题；

支持数据复制和数据完整性

ClickHouse 使用异步的多住复制技术。当数据被写入到任何一个可用副本后，系统在后台将数据分发给其他副本。

功能多

- 支持类SQL查询，比ES的DSL更加简单，学习成本更低。

- 支持繁多库函数（例如IP转化，URL分析等，预估计算/HyperLoglog等）

- 支持数据库异地复制部署

稳定性更高，运维成本更低

相比ES，ClickHouse稳定性更高，运维成本更低。

ES中不同的Group负载不均衡，有的Group负载高，会导致写Rejected等问题，需要人工迁移索引；在ClickHouse中通过集群和Shard策略，采用轮询写的方法，可以让数据比较均衡的分布到所有节点。
ES中一个大查询可能导致OOM的问题；ClickHouse通过预设的查询限制，会查询失败，不影响整体的稳定性。
ES需要进行冷热数据分离，每天200T的数据搬迁，稍有不慎就会导致搬迁过程发生问题，一旦搬迁失败，热节点可能很快就会被撑爆，导致一大堆人工维护恢复的工作；ClickHouse按天分partition，一般不需要考虑冷热分离，特殊场景用户确实需要冷热分离的，数据量也会小很多，ClickHouse自带的冷热分离机制就可以很好的解决。

0x08 省

“ 省”这个特点具体是由如下具体技术实现来完成的。

列式存储

而列存模式下，同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

数据TTL

在分析场景中，数据的价值随着时间流逝而不断降低，多数业务出于成本考虑只会保留最近几个月的数据，ClickHouse通过TTL提供了数据生命周期管理的能力。

有限支持delete、update

在分析场景中，删除、更新操作并不是核心需求。ClickHouse没有直接支持delete、update操作，而是变相支持了mutation操作。目前主要限制为删除、更新操作为异步操作，需要后台compation之后才能生效。

动态代码生成Runtime Codegen

ClickHouse实现了Expression级别的runtime codegen，动态地根据当前SQL直接生成代码，然后编译执行。不仅消除了大量的虚函数调用（即图中多个function pointer的调用），而且由于在运行时表达式的参数类型、个数等都是已知的，也消除了不必要的if-else分支判断。

0x09 独立

基于Hadoop而衍生的Hive、Pig、Spark、Presto、Impala等一系列组件共同构成了Hadoop生态体系。Hadoop生态为今天的大数据领域提供着稳定可靠的数据服务。

Hadoop生态体系解决了大数据界的大部分问题，当然其也存在缺点。Hadoop体系的最大短板在于数据处理时效性。基于Hadoop生态的数据处理场景大部分对时效要求不高，按照传统的做法一般是 T + 1 的数据时效。即 Trade + 1，数据产出在交易日 + 1 天。

ClickHouse的产生就是为了解决大数据量处理的时效性。完全独立于Hadoop生态。

0x10 ClickHouse 的缺点

没有完整的事务支持
缺少高频率、低延迟的修改或删除已存在数据的能力，仅能用于批量删除或修改数据。
不支持Transaction：想快就别想Transaction
聚合结果必须小于一台机器的内存大小：不是大问题
缺少完整的Update/Delete操作
支持有限操作系统
不支持高并发，官方建议qps为100

0x11 下一步发展

ClickHouse会向两个方向发展。

1 云计算数据库：　

Yandex希望通过ClickHouse促进公司云计算数据库的发展，包括用户可以通过云服务的方式，使用ClickHouse，开源是走向市场的第一步。

2. 加强SQL兼容性。

为了支持更多的企业用户，目前的查询虽然采用非常近似的SQL语言，但是还有很多地方需要改进，包括和一些商业软件（例如Tableau,Pentaho）的集成无缝使用。

0xFF 参考

ClickHouse 详解

最快开源 OLAP 引擎！ ClickHouse 在头条的技术演进

彪悍开源的分析数据库-ClickHouse

ClickHouse深度揭秘

干货 | 每天十亿级数据更新，秒出查询结果，ClickHouse在携程酒店的应用

从携程性能测试case中重新认识clickhouse

干货 | 携程ClickHouse日志分析实践