[业界方案] ClickHouse业界解决方案学习笔记
- [业界方案] ClickHouse业界解决方案学习笔记
- 0x00 摘要
- 0x01 简介
- 0x02 OLAP场景的特点
- 0x03 选型原因
- 携程选型原因
- 头条选型原因
- 0x04 技术特点
- 0x05 多
- 数据Sharding
- 数据Partitioning
- 高吞吐写入能力
- 支持数据复制和数据完整性
- 0x06 快
- 列式存储
- 主键索引
- 稀疏索引
- 实时数据更新
- 支持近似计算
- 多核并行
- 向量化执行与SIMD
- 分布式计算
- 数据Sharding
- 0x07 好
- 复杂数据类型支持
- 主备同步
- 支持数据复制和数据完整性
- 功能多
- 稳定性更高，运维成本更低
- 0x08 省
- 列式存储
- 数据TTL
- 有限支持delete、update
- 动态代码生成Runtime Codegen
- 0x09 独立
- 0x10 ClickHouse 的缺点
- 0x11 下一步发展
- 0xFF 参考
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日志分析实践