ClickHouse(01)什么是ClickHouse,ClickHouse适用于什么场景

2024-03-20 454

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

实时数仓Hologres，5000CU*H 100GB 3个月

智能开放搜索 OpenSearch行业算法版，1GB 20LCU 1个月

实时计算 Flink 版，5000CU*H 3个月

简介： ClickHouse是一款高性能的列式存储OLAP数据库，由俄罗斯的Yandex公司开发，用于在线分析处理（OLAP）。它提供秒级大数据查询，适用于商业智能、广告流量等领域。ClickHouse速度快的原因包括列式存储、数据压缩、向量化执行和多线程分布式处理。然而，它不支持事务，不适合OLTP操作。相比Hadoop生态中的查询引擎，ClickHouse在大量数据查询上表现出色。一系列的文章详细介绍了ClickHouse的各个方面，包括安装、表引擎和使用场景。

ClickHouse的由来

ClickHouse是什么数据库？ClickHouse速度有多快？应用场景是怎么样的？ClickHouse是关系型数据库吗？ClickHouse目前是很火爆的一款面向OLAP的数据，可以提供秒级的大数据查询。

Google于2003～2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”，将大数据的处理技术带进了大众视野。2006年开源项目Hadoop的出现，标志着大数据技术普及的开始，大数据技术真正开始走向普罗大众。长期以来受限于数据库处理能力的大数据技术，开始了波澜壮阔的技术革新浪潮席卷而来。Hadoop最初指代的是分布式文件系统HDFS和MapReduce计算框架，但是它一路高歌猛进，在此基础之上像搭积木一般快速发展成为一个庞大的生态，包括Yarn、Hive、HBase、Spark等数十种之多组件相继开源。Hadoop全家桶很快成为了主流。传统关系型数据库所构建的数据仓库，被以Hive为代表的大数据技术所取代，数据查询分析的查询计算引擎Spark、Impala、Kylin等都出来了。Hadoop成为大数据的代名词。

Hadoop虽然带来了诸多便利性，随着时代的发展，但是也带来了一些新的问题。

Hadoop生态化的两面性：臃肿和复杂。Hadoop生态下的每种组件都自成一体、相互独立，强强组合的技术组件有些时候显得过于笨重了。
随着现代化终端系统对实效性的要求越来越高，Hadoop在海量数据和高时效性的双重压力下，速度有点更不上了。

当然这是hadoop生态的确定，但是目前最普及的方案还是hadoop莫属，但是hadoop生态在大数据量的查询和组件的笨重确实存在，在日常的数据开发中，数据分析，BI等都需要查询数据，目前的hadoop查询引擎提供的查询速度，相对于ClickHouse，会慢很多。

所以，这款非Hadoop生态、简单、自成一体的技术组件ClickHouse横空出世。

ClickHouse背后的研发团队是一家俄罗斯本土的互联网企业Yandex公司，2011年在纳斯达克上市，它是现今世界上最大的俄语搜索引擎,占据了本国47%以上的搜索市场,Google是它的直接竞争对手。 ClickHouse的前身是一款在线流量分析的产品Yandex.Metrica，类似Google Analytics，随着Yandex.Metrica业务的发展，其底层架构历经四个阶段，最终形成了大家现在所看到的ClickHouse。

ClickHouse的定义及其优缺点

ClickHouse是一款高性能、MPP架构、列式存储、具有完备DBMS功能的OLAP数据库。

ClickHouse可以在存储数据超过20万亿行的情况下，做到了90%的查询能够在1秒内返回。它基本能够满足各种数据分析类的场景，并且随着数据体量的增大，它与Spark、Impala、Kylin对比，优势也会变得越为明显。

ClickHouse适用于商业智能领域（BI），也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。应该说它适合的场景，就是OLAP。

ClickHouse不是万能的。它对于OLTP事务性操作的场景支持有限，它有以下几点不足。

不支持事务。
不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
不擅长按行删除数据（虽然支持）。

这些弱点并不能视为ClickHouse的缺点，事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。

ClickHouse为何这么快的原因

前面我们说了ClickHouse以在存储数据超过20万亿行的情况下，在1秒内返回查询，那它是怎么做到的？主要有下面的原因。

列式存储与数据压缩
列式存储和数据压缩，对于一款高性能数据库来说是必不可少的。如果你想让查询变得更快，那么最简单且有效的方法是减少数据扫描范围和数据传输时的大小，列式存储和数据压缩就可以做到这两点。
向量化执行
能升级硬件解决的问题，千万别优化程序。能用钱解决的问题，那都不是问题。
向量化执行，可以简单地看作一项消除程序中循环的优化，是基于底层硬件实现的优化。这里用一个形象的例子比喻。小胡经营了一家果汁店，虽然店里的鲜榨苹果汁深受大家喜爱，但客户总是抱怨制作果汁的速度太慢。小胡的店里只有一台榨汁机，每次他都会从篮子里拿出一个苹果，放到榨汁机内等待出汁。如果有8个客户，每个客户都点了一杯苹果汁，那么小胡需要重复循环8次上述的榨汁流程，才能榨出8杯苹果汁。如果制作一杯果汁需要5分钟，那么全部制作完毕则需要40分钟。为了提升果汁的制作速度，小胡想出了一个办法。他将榨汁机的数量从1台增加到了8台，这么一来，他就可以从篮子里一次性拿出8个苹果，分别放入8台榨汁机同时榨汁。此时，小胡只需要5分钟就能够制作出8杯苹果汁。为了制作n杯果汁，非向量化执行的方式是用1台榨汁机重复循环制作n次，而向量化执行的方式是用n台榨汁机只执行1次。

向量化执行

上图中，右侧为vectorization(向量化计算)，左侧为经典的标量计算。将多次for循环计算变成一次计算完全仰仗于CPU的SIMD指令集，SIMD指令可以在一条cpu指令上处理2、4、8或者更多份的数据。在Intel处理器上，这个称之为SSE以及后来的AVX；在ARM处理器上，这个称之为NEON。

因此简单来说，向量化计算就是将一个loop——处理一个array的时候每次处理1个数据共处理N次，转化为vectorization——处理一个array的时候每次同时处理8个数据共处理N/4次，假如cpu指令上可以处理更多份的数据，设为M，那就是N/M次。

为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式，它的原理是在CPU寄存器层面实现数据的并行操作。ClickHouse目前利用SSE4.2指令集实现向量化执行。

多样化的表引擎
与MySQL类似，ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。目前ClickHouse共拥有合并树、内存、文件、接口和其他6大类20多种表引擎。每一种表引擎都有着各自的特点，用户可以根据实际业务场景的要求，选择合适的表引擎使用。
多线程与分布式
多线程处理就是通过线程级并行的方式实现了性能的提升，ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。这种设计下，可以使得ClickHouse单条Query就能利用整机所有CPU，极致的并行处理能力，极大的降低了查询延时。

而分布式数据属于基于分而治之的基本思想，实现的优化，如果一台服务器性能吃紧，那么就利用多台服务的资源协同处理。这个前提是需要在数据层面实现数据的分布式，因为计算移动比数据移动更加划算，在各服务器之间，通过网络传输数据的成本是高昂的，所以预先将数据分布到各台服务器，将数据的计算查询直接下推到数据所在的服务器。