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

本文通过分析总结几篇文章来看目前工业界可能偏好的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 提供各种各样在允许牺牲精度的情况下对查询进行加速的方法

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

多核并行

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日志分析实践

上一篇:【原理+实战+视频+源码】细说JVM内存模型,请查收


下一篇:clickhouse学习笔记