{{ item.name }}
{{ item.name }}

{{ it.name }}

{{ it.text }}

{{ it.name }}

{{ innerIt.name }}

{{ innerIt.text }}

{{news.time}}
{{news.title}}
第01期:一文了解 ClickHouse
2020-08-13发布 1,292浏览
一、简介

1.1 ClickHouse 是什么?

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

1.2 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:
不适合事务性工作负载(OLTP)、高价值的键值请求、Blob 或文档存储。

1.3 为什么 ClickHouse 速度这么快?

首先我们了解一下 OLAP 场景的特点:

  1. 读多于写。
  2. 大宽表,读大量行但是少量列,结果集较小。
  3. 数据批量写入,且数据不更新或少更新。

针对分析类查询,通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如,如果只需要读取 100 列中的 5 列,这将帮助你最少减少 20 倍的 I/O 消耗。

由于数据总是打包成批量读取的,所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了 I/O 的体积。由于 I/O 的降低,这将帮助更多的数据被系统缓存。

例如,查询《统计每个广告平台的记录数量》需要读取《广告平台 ID》这一列,它在未压缩的情况下需要 1 个字节进行存储。如果大部分流量不是来自广告平台,那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法,它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说,这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

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

column-oriented  图片来源见水印
相比于行式存储,列式存储在分析场景下有着许多优良的特性。

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


二、安装实践

2.1 安装

sudo yum install yum-utils
sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64
sudo yum install clickhouse-server clickhouse-client

本案例安装的是单机版本。yum 安装会自动创建 clickhouse 用户。

2.2 修改配置文件

yum 安装完成之后,配置文件,数据文件日志目录设置如下:

配置文件目录:/etc/clickhouse-server/
数据文件目录:/var/lib/clickhouse/
日志文件目录:/var/log/clickhouse-server/

clickhouse 相关的各个目录可以在配置文件 /etc/clickhouse-serverconfig.xml 中进行修改。

启动

sudo /etc/init.d/clickhouse-server start

连接

clickhouse-client -m #默认以 default 用户登录

在 /etc/clickhouse-server/users.xml 中可以设置其他用户的访问权限等。

clickhouse-client [--user=xxx --password=xxx --host=xxx]

2.3 速度测试

localhost :) SELECT
:-]     C_CITY,
:-]     S_CITY,
:-]     toYear(LO_ORDERDATE) AS year,
:-]     sum(LO_REVENUE) AS revenue
:-] FROM lineorder_flat
:-] WHERE (C_CITY = 'UNITED KI1' OR C_CITY = 'UNITED KI5'AND (S_CITY = 'UNITED KI1' OR S_CITY = 'UNITED KI5'AND year >= 1992 AND year <= 1997
:-] GROUP BY
:-]     C_CITY,
:-]     S_CITY,
:-]     year
:-] ORDER BY
:-]     year ASC,
:-]     revenue DESC;

SELECT 
    C_CITY, 
    S_CITY, 
    toYear(LO_ORDERDATE) AS year
    sum(LO_REVENUE) AS revenue
FROM lineorder_flat
WHERE ((C_CITY = 'UNITED KI1'OR (C_CITY = 'UNITED KI5')) AND ((S_CITY = 'UNITED KI1'OR (S_CITY = 'UNITED KI5')) AND (year >= 1992AND (year <= 1997)
GROUP BY 
    C_CITY, 
    S_CITY, 
    year
ORDER BY 
    year ASC
    revenue DESC

┌─C_CITY─────┬─S_CITY─────┬─year─┬────revenue─┐
│ UNITED KI1 │ UNITED KI1 │ 1992 │ 5776096629 │
│ UNITED KI5 │ UNITED KI1 │ 1992 │ 5555883901 │
│ UNITED KI5 │ UNITED KI5 │ 1992 │ 5348705805 │
│ UNITED KI1 │ UNITED KI5 │ 1992 │ 5326870427 │
│ UNITED KI1 │ UNITED KI1 │ 1993 │ 5892974670 │
│ UNITED KI1 │ UNITED KI5 │ 1993 │ 5490859451 │
│ UNITED KI5 │ UNITED KI1 │ 1993 │ 5468354303 │
│ UNITED KI5 │ UNITED KI5 │ 1993 │ 5089909647 │
│ UNITED KI5 │ UNITED KI1 │ 1994 │ 5437315108 │
│ UNITED KI1 │ UNITED KI1 │ 1994 │ 5348775917 │
│ UNITED KI5 │ UNITED KI5 │ 1994 │ 5310936695 │
│ UNITED KI1 │ UNITED KI5 │ 1994 │ 5237461110 │
│ UNITED KI1 │ UNITED KI1 │ 1995 │ 5737551920 │
│ UNITED KI5 │ UNITED KI5 │ 1995 │ 5657584590 │
│ UNITED KI5 │ UNITED KI1 │ 1995 │ 5260093556 │
│ UNITED KI1 │ UNITED KI5 │ 1995 │ 5213763257 │
│ UNITED KI5 │ UNITED KI1 │ 1996 │ 5522325005 │
│ UNITED KI1 │ UNITED KI1 │ 1996 │ 5451244409 │
│ UNITED KI5 │ UNITED KI5 │ 1996 │ 5231759057 │
│ UNITED KI1 │ UNITED KI5 │ 1996 │ 5203962897 │
│ UNITED KI1 │ UNITED KI1 │ 1997 │ 5340760807 │
│ UNITED KI5 │ UNITED KI1 │ 1997 │ 5295685214 │
│ UNITED KI1 │ UNITED KI5 │ 1997 │ 5188428156 │
│ UNITED KI5 │ UNITED KI5 │ 1997 │ 5024634475 │
└────────────┴────────────┴──────┴────────────┘

24 rows in set. Elapsed: 1.723 sec. Processed 546.67 million rows4.46 GB (317.28 million rows/s., 2.59 GB/s.) 

扫描 1.7 秒处理 546w 的数据量每秒处理 317w 行数据,速度是相当快了。

三、和其他列式存储的对比
没有银弹,各种数据存储类型还是要结合具体的场景使用。
图片来自 新浪 高鹏的 ppt 
目前大量使用 ClickHouse 的互联网公司:
1. 今日头条内部用 ClickHouse 来做用户行为分析,内部一共几千个 ClickHouse 节点,单集群最大 1200 节点,总数据量几十 PB,日增原始数据 300TB 左右。
2. 腾讯内部用 ClickHouse 做游戏数据分析,并且为之建立了一整套监控运维体系。
3. 携程内部从 18 年 7 月份开始接入试用,目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿,近百万次查询请求。
4. 快手内部也在使用 ClickHouse,存储总量大约 10PB, 每天新增 200TB, 90% 查询小于 3S。
5. 在国外,Yandex 内部有数百节点用于做用户点击行为分析,CloudFlare、Spotify 等头部公司也在使用。
当然还有一些没有关注到的公司也在大量使用,有兴趣的朋友可以积极尝试。

四、小结
本文是浅出的介绍了 Clickhouse 的是什么,有哪些新特性。需要深入学习还是要看官方文档,纸上来得终觉浅,绝知此事要躬行。

参考文章

  1. https://www.cnblogs.com/zhoujinyi/p/12625655.html

  2. https://clickhouse.tech/docs/zh/

  3. https://zhuanlan.zhihu.com/p/98877249

  4. https://github.com/ClickHouse-China/ClickhouseMeetup



上一篇
技术译文 | How Can ScaleFlux Handle MySQL Workload?
400-820-6580 13916131869
marketing@actionsky.com
上海市闵行区万源路2138号泓茂中心2号楼
产品详情
关系型数据库
AI数据库
数据库智能管理平台
数据库生态产品
行业案例
金融行业
新零售行业
制造业
通信行业
更多
公司动态
最新新闻
国产化信息
技术分享
关于我们
公司简介
公司分布
国家专利
资质认证
扫码关注公众号
© Copyright 2017, All rights reserved by: 上海爱可生信息技术股份有限公司 沪ICP备12003970号-1 | 法律声明 | 网站地图
沪公网安备 31010402003331号