ClickHouse 基础介绍

一、ClickHouse 是什么?

ClickHouse 是 Yandex(俄罗斯最大的搜索引擎)开源的一个用于实时数据分析的基于列存储的数据库,其处理数据的速度比传统方法快 100-1000 倍。ClickHouse 的性能超过了目前市场上可比的面向列的 DBMS,每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。

ClickHouse是近年来备受关注的开源列式数据库,主要用于数据分析(OLAP)领域。目前国内社区火热,各个大厂纷纷跟进大规模使用:

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

在国外,Yandex内部有数百节点用于做用户点击行为分析,CloudFlare、Spotify等头部公司也在使用。

特别值得一提的是:国内云计算的领导厂商 阿里云 率先推出了自己的ClickHouse托管产品,产品首页地址为 云数据库ClickHouse,可以点击链接申请参加免费公测,一睹为快!

二、ClickHouse 特性

  1. 快速:ClickHouse 会充分利用所有可用的硬件,以尽可能快地处理每个查询。单个查询的峰值处理性能超过每秒 2 TB(解压缩后,仅使用的列)。在分布式设置中,读取是在健康副本之间自动平衡的,以避免增加延迟。
  2. 容错:ClickHouse 支持多主机异步复制,并且可以跨多个数据中心进行部署。所有节点都相等,这可以避免出现单点故障。单个节点或整个数据中心的停机时间不会影响系统的读写可用性。
  3. 可伸缩:ClickHouse 可以在垂直和水平方向上很好地缩放。ClickHouse 易于调整以在具有数百或数千个节点的群集上或在单个服务器上,甚至在小型虚拟机上执行。当前,每个单节点安装的数据量超过数万亿行或数百兆兆字节。
  4. 易用:ClickHouse 简单易用,开箱即用。它简化了所有数据处理:将所有结构化数据吸收到系统中,并且立即可用于构建报告。SQL 允许表达期望的结果,而无需涉及某些 DBMS 中可以找到的任何自定义非标准 API。
  5. 充分利用硬件:ClickHouse 与具有相同的可用 I/O 吞吐量和 CPU 容量的传统的面向行的系统相比,其处理典型的分析查询要快两到三个数量级。列式存储格式允许在 RAM 中容纳更多热数据,从而缩短了响应时间。
  6. 提高 CPU 效率:向量化查询执行涉及相关的 SIMD 处理器指令和运行时代码生成。处理列中的数据会提高 CPU 行缓存的命中率。
  7. 优化磁盘访问:ClickHouse 可以最大程度地减少范围查询的次数,从而提高了使用旋转磁盘驱动器的效率,因为它可以保持连续存储数据。
  8. 最小化数据传输:ClickHouse 使公司无需使用专门针对高性能计算的专用网络即可管理其数据。

三、为什么 ClickHouse 速度这么快?

ClickHouse 是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

我们首先理清一些基础概念:

  • OLTP:是传统的关系型数据库,主要操作增删改查,强调事务一致性,比如银行系统、电商系统。

  • OLAP:是仓库型数据库,主要是读取数据,做复杂数据分析,侧重技术决策支持,提供直观简单的结果。

ClickHouse OLAP场景的特点

读多于写

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

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

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

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

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

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

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

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

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

 

ClickHouse 从 OLAP 场景需求出发,定制开发了一套全新的高效列式存储引擎

column-oriented  图片来源见水印

相比于行式存储,列式存储在分析场景下有着许多优良的特性。
  1. 如前所述,分析场景中往往需要读大量行但是少数几个列。在行存模式下,数据按行连续存储,所有列的数据都存储在一个 block 中,不参与计算的列在 IO 时也要全部读出,读取操作被严重放大。而列存模式下,只需要读取参与计算的列即可,极大的减低了 IO cost,加速了查询。
  2. 同一列中的数据属于同一类型,压缩效果显著。列存往往有着高达十倍甚至更高的压缩比,节省了大量的存储空间,降低了存储成本。
  3. 更高的压缩比意味着更小的 data size,从磁盘中读取相应数据耗时更短。
  4. 自由的压缩算法选择。不同列的数据具有不同的数据类型,适用的压缩算法也就不尽相同。可以针对不同列类型,选择最合适的压缩算法。
  5. 高压缩比,意味着同等大小的内存能够存放更多数据,系统 cache 效果更好。

四、和其他列式存储的对比

没有银弹,各种数据存储类型还是要结合具体的场景使用。

 

 

何时使用 ClickHouse:用于分析结构良好且不可变的事件或日志流,建议将每个此类流放入具有预连接维度的单个宽表中。
何时不使用 ClickHouse:不适合事务性工作负载(OLTP)、高价值的键值请求、Blob 或文档存储。
 

参考文章:

 https://zhuanlan.zhihu.com/p/183076358
 
posted @ 2021-12-08 15:40  VicLW  阅读(1096)  评论(0编辑  收藏  举报