logo头像

Always believe youself.

clickHouse入门

本文于754天之前发表,文中内容可能已经过时。

什么是ClickHouse

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

存储结构: 来自不同列的值被单独存储,来自同一列的数据被存储在一起。

常见的列式数据库:

  • Vertica : Vertica是一款基于列存储的MPP (massively parallel processing)架构的数据库。它可以支持存放多至PB(Petabyte)级别的结构化数据。
  • Paraccel (Actian Matrix,Amazon Redshift): 一种比同类产品性能更高、速度快50倍以上的列式数据库,提供快速和选择性查询。其产品ParAccel SMP/MMP能为商业智能工具以及其他应用程序利用大多数非结构化数据进行高速分析。
  • Sybase IQ : Sybase IQ是Sybase公司推出的特别为数据仓库设计的关系型数据库,IQ的架构与大多数关系型数据库不同,特别的设计用以支持大量并发用户的即时查询。
  • Exasol :
  • Infobright : infobright是开源的MySQL数据仓库解决方案,引入了列存储方案,高强度的数据压缩,优化的统计计算。是基于mysql的,但不装mysql亦可,因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎,infobright主要实现的就是一个存储引擎,但因为它自身存储逻辑跟关系型数据库根本不同,所以,它不能像InnoDB那样直接作为插件挂接到mysql,它的逻辑层是mysql的逻辑 层加上它自身的优化器。
  • InfiniDB : 提供一个可伸缩的分析型数据库引擎,主要为数据仓库、商业智能、以及对实时性要求不严格的应用而开发。基于 MySQL 搭建。包括对查询、事务处理以及大数据量加载的支持。
  • MonetDB (VectorWise, Actian Vector) : MonetDB是一个开源的面向列的数据库管理系统。MonetDB被设计用来为较大规模数据(如几百万行和数百列的数据库表)提供高性能查询的支持。
  • LucidDB :
    LucidDB是唯一一款专注于数据仓库和商务智能的开源RDBMS,它使用了列存储架构,支持位图索引,哈希连接/聚合和页面级多版本,大部分数据库最初都注重事务处理能力,而分析功能都是后来才加上去的。相反,LucidDB中的所有组件从一开始就是为满足灵活的需求,高性能数据集成和大规模数据查询而设计的,此外,其架构设计彻底从用户出发,操作简单,完全无需DBA。
  • SAP HANA: 是一款支持企业预置型部署和云部署模式的内存计算平台 [1] ,提供高性能的数据查询功能,用户可以直接对大量实时业务数据进行查询和分析,而不需要对业务数据进行建模、聚合等。SAP内存数据库的数据并不是只在内存里,也会不停写到硬盘里,这就用到复制服务器Replication Server,包括Log-based,Trigger-based和ETL-based。
  • Google Dremel : 数据模型起源于分布式系统的应用环境(Protocol Buffers,一种在Google内广泛使用,现已开源的实现)。其数据模型是基于强类型的嵌套记录,嵌套列式存储。
  • Google PowerDrill : PowerDrill 就可以处理上万亿条信息,Google 从 2008 年开始使用 PowerDrill,将其作为 Dremel 的变通方案。PowerDrill 与 Dremel 的类似之处在于都用了列存,都为 SQL 接口。
  • Druid : 是一个高效的数据查询系统,主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入,进入到Druid后立即可查,同时数据是几乎是不可变。通常是基于时序的事实事件,事实发生后进入Druid,外部系统就可以对该事实进行查询。
  • kdb+ : 是来自Kx Systems Inc的高性能列式数据库。 kdb +旨在捕获,分析,比较和存储数据 - 所有这些都是高速和大量数据。

    不同的数据存储方式适用不同的业务场景,数据访问的场景包括:进行了何种查询、多久查询一次以及各类查询的比例;每种类型的查询(行、列和字节)读取多少数据;读取数据和更新之间的关系;使用的数据集大小以及如何使用本地的数据集;是否使用事务,以及它们是如何进行隔离的;数据的复制机制与数据的完整性要求;每种类型的查询要求的延迟与吞吐量等等。

PowerDrill 与 Dremel

不同

  • 两者的设计目标不同,Dremel 设计用来管理非常大量的大数据集(指数据集的数量和每数据集的规模都大),而 PowerDrill 设计用来分析少量的大数据集(指数据集的规模大,但数据集的数量不多)时提供更强劲的分析性能。
  • 设计思路不同,包括:
    • Dremel 数据存于外存;PowerDrill 数据存于内存。
    • Dremel 没做数据分区,分析时要扫瞄所有需要的列;PowerDrill 做了组合范围分区,分析时可以跳过很多不需要的分区(真实应用统计可以跳过 92.41% 的分区)。
    • Dremel 用层次数据模型;PowerDrill 用普通关系模型。
    • Dremel 数据通常不需要 load,增加数据很方便;PowerDrill 数据要 load,增加数据(估计)不太方便。

PowerDrill 最鲜明的特点:

  • 一个是已经提到的组合范围分区,另一个是空间效率非常高的内存数据结构。
  • 首先,各列的数据使用基于字典的压缩技术,并且是双层字典。全局字典编码列中所有不同值,每个分区还有个小字典,映射分区内不同值的编码到全局编码,这样各分区内的值的编码取值范围比较小,从而可以用较少的比特来编码一个值。
  • 在这个基本方法之上,还通过一下方式进一步优化空间效率:全局字典用 trie 结构;属性值 Zippy 压缩(热点数据不压缩,LRU 替换);reorder 纪录。这些优化通常能带来 2-10+ 倍的空间效率提升。

OLAP场景的关键特征

  • 绝大多数是读请求
  • 数据以相当大的批次(> 1000行)更新,而不是单行更新;或者根本没有更新。
  • 已添加到数据库的数据不能修改。
  • 对于读取,从数据库中提取相当多的行,但只提取列的一小部分。
  • 宽表,即每个表包含着大量的列
  • 查询相对较少(通常每台服务器每秒查询数百次或更少)
  • 对于简单查询,允许延迟大约50毫秒
  • 列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节)
  • 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
  • 事务不是必须的
  • 对数据一致性要求低
  • 每个查询有一个大表。除了他以外,其他的都很小。
  • 查询结果明显小于源数据。换句话说,数据经过过滤或聚合,因此结果适合于单个服务器的RAM中

输入/输出

  • 针对分析类查询,通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如,如果只需要读取100列中的5列,这将帮助你最少减少20倍的I/O消耗。
  • 由于数据总是打包成批量读取的,所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
  • 由于I/O的降低,这将帮助更多的数据被系统缓存。

常用命令:

  • SHOW DATABASES
  • SHOW TABLES FROM datasets
  • DESCRIBE TABLE hits_100m_obfuscated
  • SHOW CREATE TABLE hits_100m_obfuscated
  • SELECT * FROM hits_100m_obfuscated WHERE EventDate = ‘2013-07-15’ LIMIT 100;

补充1

ClickHouse 是一个列导向数据库,是原生的向量化执行引擎。它在大数据领域没有走 Hadoop 生态,而是采用 Local attached storage 作为存储,这样整个 IO 可能就没有 Hadoop 那一套的局限。它的系统在生产环境中可以应用到比较大的规模,因为它的线性扩展能力和可靠性保障能够原生支持 shard + replication 这种解决方案。它还提供了一些 SQL 直接接口,有比较丰富的原生 client。

查询快的原因

  • 它的数据剪枝能力比较强,分区剪枝在执行层,而存储格式用局部数据表示,就可以更细粒度地做一些数据的剪枝。它的引擎在实际使用中应用了一种现在比较流行的 LSM 方式。
  • 它对整个资源的垂直整合能力做得比较好,并发 MPP+ SMP 这种执行方式可以很充分地利用机器的集成资源。它的实现又做了很多性能相关的优化,它的一个简单的汇聚操作有很多不同的版本,会根据不同 Key 的组合方式有不同的实现。对于高级的计算指令,数据解压时,它也有少量使用。
  • 我当时选择它的一个原因,ClickHouse 是一套完全由 C++ 模板 Code 写出来的实现,代码还是比较优雅的。

列式存储与数据压缩

列式存储和数据压缩,对于一款高性能数据库来说是必不可少的特性。一个非常流行的观点认为,如果你想让查询变得更快,最简单且有效的方法是减少数据扫描范围和数据传输时的大小,而列式存储和数据压缩就可以帮助我们实现上述两点。列式存储和数据压缩通常是伴生的,因为一般来说列式存储是数据压缩的前提。

按列存储与按行存储相比,前者可以有效减少查询时所需扫描的数据量,这一点可以用一个示例简单说明。假设一张数据表A拥有50个字段A1~A50,以及100行数据。

SELECT A1,A2,A3,A4,A5 FROM A

按列存储相比按行存储的另一个优势是对数据压缩的友好性。同样可以用一个示例简单说明压缩的本质是什么。假设有两个字符串abcdefghi和bcdefghi,现在对它们进行压缩,如下所示:

压缩前:abcdefghi_bcdefghi
压缩后:abcdefghi_(9,8)

可以看到,压缩的本质是按照一定步长对数据进行匹配扫描,当发现重复部分的时候就进行编码转换。例如上述示例中的 (9,8),表示如果从下划线开始向前移动9个字节,会匹配到8个字节长度的重复项,即这里的bcdefghi。

真实的压缩算法自然比这个示例更为复杂,但压缩的实质就是如此。数据中的重复项越多,则压缩率越高;压缩率越高,则数据体量越小;而数据体量越小,则数据在网络中的传输越快,对网络带宽和磁盘IO的压力也就越小。既然如此,那怎样的数据最可能具备重复的特性呢?答案是属于同一个列字段的数据,因为它们拥有相同的数据类型和现实语义,重复项的可能性自然就更高。

ClickHouse就是一款使用列式存储的数据库,数据按列进行组织,属于同一列的数据会被保存在一起,列与列之间也会由不同的文件分别保存 ( 这里主要指MergeTree表引擎 )。数据默认使用LZ4算法压缩,在Yandex.Metrica的生产环境中,数据总体的压缩比可以达到8:1 ( 未压缩前17PB,压缩后2PB )。列式存储除了降低IO和存储的压力之外,还为向量化执行做好了铺垫。

ClickHouse的特性