置顶 ClickHouse 基础介绍
发布于 4 个月前 作者 theseusyang 1633 次浏览 来自 文档翻译

image.png

什么是ClickHouse?

ClickHouse 是面向 OLAP 的分布式列式 DBMS.

在“正常”的面向行的DBMS中,数据按顺序进行存储:

5123456789123456789 1 Eurobasket - Greece - Bosnia and Herzegovina - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0

5234985259563631958 0 Consulting, Tax assessment, Accounting, Law 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0

换句话说,与一行相关的所有值都被存储在一起。面向行的DBMS主要有MySQL,Postgres,MS SQL Server等等。

在面向列的DBMS中,数据存储如下:

WatchID:5385521489354350662 5385521490329509958 5385521489953706054 5385521490476781638 5385521490583269446 5385521490218868806 5385521491437850694 5385521491090174022 5385521490792669254 5385521490420695110 5385521491532181574 5385521491559694406 5385521491459625030 5385521492275175494 5385521492781318214 5385521492710027334 5385521492955615302 5385521493708759110 5385521494506434630 5385521493104611398

JavaEnable:1 0 1 0 0 0 1 0 1 1 1 1 1 1 0 1 0 0 1 1

Title:Yandex Announcements - Investor Relations - Yandex Yandex — Contact us — Moscow Yandex — Mission Ru Yandex — History — History of Yandex Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations Yandex Board of Directors - Corporate Governance - Yandex Yandex — Technologies

GoodEvent:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

EventTime:2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 2016-05-18 01:13:08 2016-05-18 00:04:06 2016-05-18 04:21:30 2016-05-18 00:34:16 2016-05-18 07:35:49 2016-05-18 11:41:59 2016-05-18 01:13:32…

这些示例仅显示数据排列的顺序。不同列的值分开存储,同一列的数据一起存储。例如,面向列的DBMS:Vertica,Paraccel(Actian Matrix)(Amazon Redshift),Sybase IQ,Exasol,Infobright,InfiniDB,MonetDB(VectorWise)(Actian Vector),LucidDB,SAP HANA,Google Dremel,Google PowerDrill,Druid ,kdb +等。

存储数据的不同存储顺序更适合于不同的应用场景。数据访问场景指的是执行什么查询,多长时间查询,每种类型的查询读取多少数据 - 行,列和字节;写取和更新数据之间的关系;数据的大小以及它在本地的使用情况;是否使用交易处理,以及它们是如何隔离的;数据同步和逻辑完整性的要求;每类查询的延迟和吞吐量要求等等。

系统上的负载越高,场景化的系统定制就越重要,定制化就越具体。没有一个系统能够适用于截然不同的应用场景。如果一个系统可以适应多种场景,那么在高负载情况下,系统处理所有场景表现都会很差,或者仅其中一种场景表现良好。

对于OLAP(联机分析处理)方案,将会有如下几种应用场景:

  • 绝大多数请求是以读为主。

  • 数据以相当大的批次(> 1000行)进行更新,而不是单行更新;或者根本不更新。

  • 数据被添加到数据库,基本不怎么修改。

  • 对于读取,大量的数据从数据库中抽取出来,但只有列的一个子集。

  • 表是“宽的”,这意味着它们包含大量的列。

  • 查询相对较少(通常每台服务器数百个查询或更少)。

  • 对于简单的查询,允许大约50 ms的延迟。

  • 列值相当小 - 数字和短字符串(例如,每个URL 60个字节)。

  • 处理单个查询时需要高吞吐量(每台服务器每秒高达数十亿行)。

  • 无事务处理。

  • 数据一致性要求低- 每个查询有一个大表,其他所有的表都是小表。

  • 查询结果显著小于源数据。也就是说,数据被过滤或聚合。结果可以放在单个服务器的内存中。

很容易看出,OLAP方案与其他常见方案(如OLTP或Key-Value访问)有很大不同。所以,如果你想获得不错的表现,尝试使用OLTP或Key-Value DB来处理分析查询是没有意义的。例如,如果您尝试使用MongoDB或Elliptics进行分析,与OLAP数据库相比,您的性能会很差。

面向列的数据库更适合于OLAP方案(对于大多数查询,处理速度至少提高了100倍),原因如下:

1.对于I/O

1.1 对于分析查询,只需要读取少量的列。在面向列的数据库中,您只能读取所需的数据。例如,如果您需要100列中的5列,则I/O可能会减少20倍。

1.2 由于数据是以数据包的形式读取的,因此压缩比较容易。列中的数据也更容易压缩。这进一步减少了I/O量。

1.3 由于减少的I/O,更多的数据适合在系统缓存中。

例如,查询“统计每个广告平台的记录数量”需要读取一个“广告平台ID”列,其占用1个未压缩字节。如果大多数流量不是来自广告平台,那么您可以期望至少有10倍的压缩比。当使用快速压缩算法时,数据解压缩速度可以达到每秒至少几千兆字节的未压缩数据。换句话说,这个查询可以在一台服务器上以每秒大约几十亿行的速度处理。这个速度实际上是在实践中是容易实现的。

milovidov@████████.yandex.ru:~$ clickhouse-client

ClickHouse client version 0.0.52053.

Connecting to localhost:9000.

Connected to ClickHouse server version 0.0.52053.

:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20

SELECT

CounterID,

count()

FROM hits

GROUP BY CounterID

ORDER BY count() DESC

LIMIT 20

┌─CounterID─┬──count()─┐

│ 114208 │ 56057344 │

│ 115080 │ 51619590 │

│ 3228 │ 44658301 │

│ 38230 │ 42045932 │

│ 145263 │ 42042158 │

│ 91244 │ 38297270 │

│ 154139 │ 26647572 │

│ 150748 │ 24112755 │

│ 242232 │ 21302571 │

│ 338158 │ 13507087 │

│ 62180 │ 12229491 │

│ 82264 │ 12187441 │

│ 232261 │ 12148031 │

│ 146272 │ 11438516 │

│ 168777 │ 11403636 │

│ 4120072 │ 11227824 │

│ 10938808 │ 10519739 │

│ 74088 │ 9047015 │

│ 115079 │ 8837972 │

│ 337234 │ 8205961 │

└───────────┴──────────┘

20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)

:)

2.对于CPU

由于执行查询需要处理大量的行,因此它有助于为整个向量而不是单独的行指派所有操作,或者实现查询引擎,以便没有指派成本。如果你不这样做,任何半象限的磁盘子系统,查询解释器不可避免地中断CPU。将数据存储在列中并在可能的情况下按列处理是有意义的。

有两种方法可以做到这一点:

1.向量引擎。所有的操作都是为向量而写的,而不是单独的值。这意味着您不需要经常调用操作,调度成本可以忽略不计。操作代码包含一个优化的内部循环。

2.代码生成。为查询生成的代码具有所有的间接调用。

这不是在“普通”数据库中完成的,因为运行简单查询时没有意义。但是,也有例外。例如,MemSQL在处理SQL查询时使用代码生成来减少延迟。(为了比较,分析DBMS需要优化吞吐量,而不是延迟。)

请注意,为了提高CPU效率,查询语言必须是声明式的(SQL或MDX),或者至少是一个向量(J,K)。查询应该只包含隐式循环,以便优化。

ClickHouse的显著特性

1.真正的面向列的DBMS

2.数据高效压缩

3.磁盘存储的数据

4.多核并行处理

5.在多个服务器上分布式处理

  1. SQL语法支持

7.向量化引擎

8.实时数据更新

9.索引

10.适合在线查询

11.支持近似预估计算

12.支持嵌套的数据结构

支持数组作为数据类型

13.支持限制查询复杂性以及配额

14.复制数据复制和对数据完整性的支持

我们来看看其中的一些功能:

1.真正的面向列的DBMS

在一个真正的面向列的DBMS中,没有任何“垃圾”存储在值中。例如,必须支持定长数值,以避免在数值旁边存储长度“数字”。例如,十亿个UInt8类型的值实际上应该消耗大约1 GB的未压缩磁盘空间,否则这将强烈影响CPU的使用。由于解压缩的速度(CPU使用率)主要取决于未压缩的数据量,所以即使在未压缩的情况下,紧凑地存储数据(没有任何“垃圾”)也是非常重要的。

因为有些系统可以单独存储单独列的值,但由于其他场景的优化,无法有效处理分析查询。例如HBase,BigTable,Cassandra和HyperTable。在这些系统中,每秒钟可以获得大约十万行的吞吐量,但是每秒不会达到数亿行。

另外,ClickHouse是一个DBMS,而不是一个单一的数据库。ClickHouse允许在运行时创建表和数据库,加载数据和运行查询,而无需重新配置和重新启动服务器。

2.数据压缩 一些面向列的DBMS(InfiniDB CE和MonetDB)不使用数据压缩。但是,数据压缩确实提高了性能。

3.磁盘存储的数据

许多面向列的DBMS(SAP HANA和Google PowerDrill)只能在内存中工作。但即使在数千台服务器上,内存也太小,无法在Yandex.Metrica中存储所有浏览量和会话。

4.多核并行处理

多核多节点并行化大型查询。

5.在多个服务器上分布式处理 上面列出的列式DBMS几乎都不支持分布式处理。在ClickHouse中,数据可以驻留在不同的分片上。每个分片可以是用于容错的一组副本。查询在所有分片上并行处理。这对用户来说是透明的。

  1. SQL支持 如果你熟悉标准的SQL,我们不能真正谈论SQL的支持。

NULL不支持。

所有的函数都有不同的名字。

JOIN支持。

子查询在FROM,IN,JOIN子句中被支持;

标量子查询支持。

关联子查询不支持。

7.向量化引擎 数据不仅按列存储,而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。

8.实时数据更新

ClickHouse支持主键表。为了快速执行对主键范围的查询,数据使用合并树(MergeTree)进行递增排序。由于这个原因,数据可以不断地添加到表中。添加数据时无锁处理。

9.索引

例如,带有主键可以在特定的时间范围内为特定客户端(Metrica计数器)抽取数据,并且延迟时间小于几十毫秒。

10.支持在线查询 这让我们使用该系统作为Web界面的后端。低延迟意味着可以无延迟实时地处理查询,而Yandex.Metrica界面页面正在加载(在线模式)。

11.支持近似计算 1.系统包含用于近似计算各种值,中位数和分位数的集合函数。

2.支持基于部分(样本)数据运行查询并获得近似结果。在这种情况下,从磁盘检索比例较少的数据。

3.支持为有限数量的随机密钥(而不是所有密钥)运行聚合。在数据中密钥分发的特定条件下,这提供了相对准确的结果,同时使用较少的资源。

12.数据复制和对数据完整性的支持。 使用异步多主复制。写入任何可用的副本后,数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复,或对复杂情况使用“按钮”。有关更多信息,请参阅“数据复制”一节。

ClickHouse目前未实现功能 1.无事务处理。

2.对于聚合,查询结果必须适合单个服务器上的内存。但是,查询的源数据量可能无限大。

3.缺乏全面的UPDATE / DELETE实现

Yandex.Metrica任务 我们需要根据点击和会话获取自定义报告,并使用用户设置的自定义。报告数据实时更新。查询必须立即运行(在线模式)。我们必须能够在任何时间段建立报告。必须计算复杂的汇总,例如唯一访客的数量。目前(2014年4月),Yandex.Metrica每天接收约120亿次事件(浏览量和鼠标点击)。所有这些事件都必须存储以建立自定义报告。单个查询可能需要几秒钟扫描数亿行,或者数百万行不超过几百毫秒。

汇总和非汇总数据 有一种流行的观点认为,为了有效地计算统计数据,您必须汇总数据,因为这会减少数据量。

但是数据聚合是一个非常有限的解决方案,原因如下:

  • 您必须具有用户需要的预定义报告列表。用户不能进行自定义报告。

  • 聚合大量密钥时,数据量不会减少,聚合无用。

  • 对于大量的报告,聚合变化太多(组合爆炸)。

  • 聚合高基数密钥(如URL)时,数据量不会减少太多(小于两倍)。出于这个原因,聚合的数据量可能会增长,而不是缩小。

  • 用户不会查看我们为他们计算的所有报告。大部分的计算是无用的。

  • 各种聚合可能违反数据的逻辑完整性。

如果我们不汇总任何内容并使用非汇总的数据,这实际上可能会减少计算量。

但是,通过汇总,相当一部分工作脱离了线索,相对冷静地完成了工作。相反,在线计算需要尽可能快地计算,因为用户正在等待结果。

Yandex.Metrica有一个专门的系统来汇总称为Metrage的数据,这个数据用于大多数报告。从2009年开始,Yandex.Metrica还使用专门的OLAP数据库来处理非聚合数据,称为OLAPServer,以前用于报告生成器。OLAPServer对非汇总数据运行良好,但是它有许多限制,不能根据需要用于所有报告。这些包括缺乏对数据类型(仅数字)的支持,以及无法实时增量更新数据(只能通过每天重写数据来完成)。OLAPServer不是一个DBMS,而是一个专门的DB。

为了消除OLAPServer的限制,并解决所有报告使用非汇总数据的问题,我们开发了ClickHouse DBMS。

用于Yandex.Metrica和其他Yandex服务 ClickHouse在Yandex.Metrica中用于多种用途。其主要任务是使用非聚合数据以在线模式构建报告。它使用374个服务器的集群,在数据库中存储超过8万亿行(超过四十亿个值)。压缩数据量不计复制和复制,大约是800TB。未压缩的数据量(以TSV格式)将大约为7PB。

ClickHouse还用于:

  • 存储WebVisor数据。

  • 处理中间数据。

  • 使用Google Analytics构建全球报告。

  • 运行查询以调试Metrica引擎。

  • 分析来自API和用户界面的日志。

ClickHouse在其他Yandex服务中至少安装了十几个安装:搜索行业,市场,Direct,业务分析,移动开发,AdFox,个人服务等。

类似开源系统 有没有类似的ClickHouse可用。目前(2016年5月),没有任何可用的开源和免费系统具有上面列出的所有功能。但是,这些功能对于Yandex.Metrica是绝对必要的。

可能愚蠢的问题 1.为什么不使用map-reduce等系统? 像map-reduce这样的系统是分布式计算系统,其中使用分布式排序来执行缩减阶段。回顾这个方面,map-reduce与YAMR,Hadoop,YT等其他系统类似。

这些系统由于延迟而不适合在线查询,所以不能用于后台级别的网页界面。这样的系统也不适合实时更新。分布式排序并不是减少操作的最佳解决方案,如果操作的结果和所有中间结果都存在,就像通常在联机分析查询的情况下发生的那样,它们适合单个服务器的运行内存。在这种情况下,执行reduce操作的最佳方法是使用散列表。map-reduce任务的常用优化方法是在内存中使用散列表的组合操作(partial reduce)。这个优化是由用户手动完成的。分布式排序是简单的map-reduce作业长时间延迟的主要原因。

与map-reduce类似的系统可以在集群上运行任何代码。但是,对于OLAP,使用情况下的执行查询语言更为合适,因为经过调研它们可以更快地运行。例如,Hadoop有Hive和Pig。还有其他:Cloudera Impala,Shark (depricated)andSpark SQLforSpark,Presto,Apache Drill.。然而,与专门系统的性能相比,这些任务的性能是非常不理想的,相对较高的延迟不允许将这些系统用作网络接口的后端。YT允许您存储单独的一组列。但YT不是一个真正的列式存储系统,因为系统没有固定长度的数据类型(所以你可以有效地存储一个数字而不是“垃圾”),而且没有向量化引擎。YT中的任务由流模式下的任意代码执行,因此不能被充分优化(每台服务器每秒高达数亿行)。在2014-2016年,YT将开发使用合并树,强类型值和类SQL语言支持的“动态表格排序”功能。动态排序的表不适用于OLAP任务,因为数据存储在行中。YT中的查询语言开发仍处于孵化阶段,不能专注于这个功能。YT开发人员正在考虑在OLTP和Key-Value方案中使用动态排序的表。

性能 根据内部测试结果,ClickHouse在可用于测试的同类系统中显示出最佳性能。这包括长查询的最高吞吐量和短查询的最低延迟。测试结果显示在此页面上。

吞吐量为单个大型查询 吞吐量可以以每秒行数或兆字节每秒来衡量。如果数据放置在页面缓存中,则在现代硬件上处理不太复杂的查询,在单个服务器上以大约2-10 GB / s的未压缩数据的速度进行处理(对于最简单的情况,速度可能会达到30 GB / s)。如果数据不在页面缓存中,则速度取决于磁盘子系统和数据压缩率。例如,如果磁盘子系统允许以400 MB / s读取数据,并且数据压缩率为3,则速度将在1.2 GB / s左右。要获得每秒行数的速度,请将查询中使用的列的总大小除以每秒字节数。例如,如果提取10个字节的列,速度将在每秒大约1到2亿行。

处理速度对于分布式处理几乎线性地增加,但是只有在聚合或排序产生的行数不太大的情况下。

处理短的查询时延迟 如果一个查询使用一个主键,并且没有选择太多的行来处理(成千上万),并且不使用太多的列,我们可以预计到不到50毫秒的延迟(最好的情况下,单位为毫秒)if数据被放置在页面缓存中。否则,延迟是根据搜索的数量来计算的。如果使用旋转驱动器,对于没有过载的系统,延迟时间通过以下公式计算:查找时间(10 ms)查询的列数数据部分的数量。

处理大量的短查询时的吞吐量 在相同的条件下,ClickHouse可以在单个服务器上每秒处理几百个查询(在最好的情况下可以达到几千个)。由于这种情况对分析型DBMS并不常见,因此我们建议每秒最多可以查询100个查询。

数据插入性能

我们建议将数据插入至少1000行的数据包中,或者每秒不超过一个请求。从制表符分隔转储插入到MergeTree表时,插入速度将从50到200 MB / s。如果插入的行大小约为1Kb,速度将从每秒50,000到200,000行。如果行很小,则每秒的行数会更高(Yandex Banner System数据 - > 500,000行/秒,Graphite数据 - > 1,000,000行/秒)。为了提高性能,可以并行执行多个INSERT查询,并且性能会线性增加。

回到顶部