数据分析引擎黑马 ClickHouse 最新技术的实践与应用

导语 | ClickHouse 在近几年是大数据分析引擎界的一匹黑马，从默默无闻到一路起飞，在 DB engine Rank 上进入前50名，成为全球数据引擎界耀眼的一颗明星。在全球范围内，ClickHouse 单表查询比其他引擎要快数倍以上，在过去的4年以来未曾有对手。ClickHouse 为什么会这么快？在实际使用当中如何应用这样一个引擎？还有哪些让人振奋和欣喜的feature将会发布？本文由易观CTO、腾讯云TVP 郭炜在 Techo TVP开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」的《ClickHouse最新技术的实践与应用》演讲分享整理而成，为大家详尽介绍最新的 ClickHouse Feature 和实战应用。

点击可观看精彩演讲视频

一、ClickHouse 的前世今生

我今天主要讲四件事，第一是讲讲 ClickHouse 的前世今生；第二是给大家讲讲实战应用，因为很多小伙伴觉得 ClickHouse 很好，但到底该怎么使用还并不了解；第三介绍比较新的一些Feature，会挑几个我比较感兴趣的和大家聊一聊；最后是对未来的一些畅想。

1. ClickHouse 的诞生与腾飞

先说 ClickHouse 是谁？ClickHouse 其实是源自俄罗斯黑科技的一个引擎，它最早是用于Yandex 公司的工具 Metrica。ClickHouse 一直基于自身新的独立架构的核心在不断演进，它能够在服务器集群很大的情况下依然保持稳定。目前在国内被腾讯、今日头条、新浪等多家公司所使用。

为什么 ClickHouse 很火呢？这个项目是在 2016 年年底的时候开源的，我是在 2017 年把它引进中国，来做 ClickHouse 的中文社区。最近这一年它突然在国内、国外都特别火，在 DB Ranking 这个网站上的排名就上升了 71 位，成为第 50 名，但其实它已经发展了四年，仅次于它的另一个热门产品是 Snowflake。所以大家看这个上升的趋势，Snowflake 这么火，是不是 ClickHouse 将来会像 Snowflake 一样？我之后会介绍应用场景，ClickHouse 和 Snowflake 有相似之处，但它绝对不是Snowflake，所以 ClickHouse 到底是谁？

2. ClickHouse 就是这么快

我们当时的 ClickHouse 技术架构师说“ClickHouse 就是这么快”，它是一个非常快的引擎，列式存储、列式可压缩，而且支持模糊查询，也支持一些复杂的SQL，几乎线性的扩展；如果用得好，数据加载和引入的操作也是最快的，而且简单易用，对新手友好，所以很多人都在快速地使用 ClickHouse。

这张图是在 2018 年 Meetup 上，新浪Jack Gao分享的数据，是比较早的版本，但大家可以看到，19 台服务器，300 亿/天，800 万次/天有效的查询，基本上平均查询时间在 200 毫秒，ClickHouse 就是这么快，19 台服务器的数量、200 毫秒对于一个 OLAP 引擎来讲是很难得的，当然它对一些核心监控查询可能时间更短，在 40 毫秒。

2018 年的时候，我们也做了一个和常见的 OLAP 引擎的横向比对测试。看右边的图会发现浅蓝色的柱子，就是 ClickHouse，在单表查询时非常快，相比其它引擎如传统的 Hive、Spark-SQL，那是几十倍的快，Join它稍微慢一些。所以基于场景来讲，它不是 Snowflake，它现在解决的还是一些单表的场景，Join的时候它跟普通引擎差不多，没有那么快，所以如果做宽表这种单表查询，它是目前大家用得最多的。

ClickHouse 为什么这么快？从我的角度来看有三点原因：

第一个是计算引擎。大家知道它叫向量化计算，另一个用向量化计算引擎的是 Snowflake，在这个点上这两个项目是很像的，它用 C 写的时候，其实会在汇编级别对每个计算单元都做向量化的处理，后面包括像 C++，它也用了很多极致的代码框架的优化，单表聚合的这个场景下用散列表的优化，包括精细化的内存处理，这些都是 ClickHouse 擅长的地方。

第二是存储设计。在列存储上，单独的每一列它都嵌套了一个单独的数据文件。在列压缩上，用了很多算法，和别的引擎不同，每一列都可以用单独不同的压缩算法来提升存储，包括在 ClickHouse 做解析和查询的时候，每一个表选择的内部查询引擎都可以不同。今年我们还提了一个叫 Projections 的东西，会帮助在 ClickHouse 里再加一个预聚合，所以它的查明细、预聚合也会很快，解决了非常多查询场景里的问题。

第三是 ClickHouse 的社区。这是我特别推崇的地方，我也在运营中国社区，其实 ClickHouse 全球社区很有意思，它是自循环的，没有外部依赖，不像过去大家要做一个东西，你还得部署一堆 Hadoop、HDFS、Hive、Spark，而 ClickHouse 一套就能搞定，很多我们的用户就是用一台机器解决了过去 30 台 Hadoop 的问题，而且用的是自底向上的设计，每次我们要去合并代码的时候都会被朵夫拆一遍，每一个审查都非常细节。社区承诺如果出现一个更快的模式，你提交到社区里，并且经验证在 ClickHouse 里有效的话，社区会立马采纳，并在下一个版本里快速地把它容纳进来。所以 ClickHouse 的版本几乎每个月要更新一两版，因为全球都有特别聪明的人在不断地将它优化。当然有些人会诟病它的不稳定性，就像最近 CentOS 出滚动版，可能是有这样的问题，但是你会发现它的迭代速度和最新的东西往往特别快，所以如果大家愿意加入开源社区，能学到很多新的东西，你会发现你的东西只要做得好，很快会在全球范围内散播开去。整体来说，ClickHouse 高效地把这些技术全都融合起来，而且非常注重具体实现的细节，所以 ClickHouse 的第三个特性是社区开放性的精神。

二、ClickHouse 的实战应用

ClickHouse 帮助大家解决了很多固定场景的实际问题，几乎所有的互联网公司都在使用它，包括一些大厂像腾讯、阿里，都开始做 ClickHouse 云的服务，传统行业也开始大量使用 ClickHouse，这都是社区未来的一个机会。

1. 腾讯音乐

在实践应用上，最早在腾讯用得最多的就是腾讯音乐，做什么呢？主要是解决数据仓库到最后数据分析和使用的最后一公里的问题。过去都在做数仓，但其实数仓到最后一公里之间需要有一个 OLAP 引擎能快速响应需求，能让我们的数据分析师和运营人员秒级查出数据，ClickHouse 解决的就是这个问题，所以腾讯音乐是以 ClickHouse 计算+存储作为中间件的方式做了实时数仓，实现了批流一体计算。

这张图是今年 2 月份腾讯音乐 Zelus 做的分享：最早的时候使用日志流，会进入消息队列，也许是 kafka，也许是腾讯内部的东西，它通过 Flink 和 Consumer 做了一个实时ETL，实时ETL 的时候会分两条线走，一条线现在就进入到 ClickHouse 里，去实现它的交互式数据分析和存储；对于应用来讲，所有的即席查询直接走这条线就出来了，因为它用同样的ETL，能保证明细数据口径是一样的。另一条线走了离线文件，离线文件其实是走了传统的数据仓库，Spark 和Hadoop 的这一块，走了中间表，走了宽表，最后结果表再出来，原来实时的数据实现了批流一体，查询能够快速实现，帮助最终用户有大量的即席查询报表。

我相信很多做数据的小伙伴都会遇到这个问题，经常领导说这个事要查一下，或者运营人员说给我出一个东西，你好不容易做了一个中间表、宽表，出一个结果表，过完以后发现这个表只用了一次，其实 ClickHouse 的出现就是解决这个问题，让大家立刻出数据，而且现在有很多数据分析人员包括运营人员已经会写SQL，所以我们告诉他这个东西是怎么样的，在上面加一个 Superset 或其他的数据工具，直接搭上 ClickHouse，业务分析人员就可以直接出数据而不用研发人员再做ETL。技术人员还是在原来的底层数据、中间表等数据里多花精力，那些临时的即席查询需求就不需要技术人员浪费时间每天开发ETL和数据脚本了，直接用 ClickHouse 就可以查询。

2. 新浪

新浪当时实践时，面临的问题是每天 300 亿条数据，查询特别多，达到800 万次。因为它提供的是系统 API，所以很痛苦，后来用了 ClickHouse 快速查询，单表查询以最快的方式完美地解决这个问题。它其实做了几件事：第一个是 ClickHouse 在入库的时候是非常快的，所以它直接利用了这个特性，做了实时入库，原始数据库可以随便查，因为最后过去还得ETL加汇总层，先原子层、后汇总层、最后再上去，现在直接就到最底层把要的数据当时查出，缩短整个数据处理的路径，ETL也容易扩容，资源大大降低。它的使用还是从 kafka开始，把复杂的ETL自己做了一层 kafka，最后从 kafka 直接进了 ClickHouse，从 ClickHouse 开始，有些数据的结果提取进入了 MySQL，通过 Superset 做了一个DashBoard，通过 Adhoc 界面直接查明细。前两天 Grafana 比较热闹，它改了协议，最后通过 Grafana 把这个数据用 ClickHouse 查出来，因为 MySQL 数据量比较大以后就出不来了，所以 ClickHouse 在这里是通过日志查询和这种基础来帮助做这件事。

3. 喜马拉雅

喜马拉雅其实也是早期开始使用 ClickHouse 的企业，有三个使用场景，也是国内使用 ClickHouse 最常用的几个场景：第一个是用户行为分析日志，留存、转化怎么做；第二个是用户画像圈选，比如要选一波人群，人群中10-15岁有多少人，分别是谁，最后怎么能直接发出；喜马拉雅还用于机器日志查询，哪里出问题，APM中间哪里能够分析出各种各样的异常，就是用 ClickHouse，当然也用了千亿数据，秒级响应。整体上说，其实它的做法和前面的不太一样，使用了两条路线，一条是通过实时数据，把所谓的用户事件，包括tracking、events、system logs通过 Spark 做了streaming到 ClickHouse 里；另一条是把原来一些交易数据的标签，从数仓里通过SQL做批量的数据导入 ClickHouse，最后从 ClickHouse 里直接提供最后一步的查询。无论是用户的行为分析、分群，还是最后的日志查询，都通过这种方式来做，这也是一种新的用法。

4. 趣头条

趣头条2019年的实践应用遇到的挑战是千亿数据，21万次的巨大查询，用 ClickHouse 的特性完美解决。千亿数据，100多台机器，32核128G，80%的查询，一秒内搞定。它的玩法也比较有特点的，先从 kafka 进 Flink，一部分数据进了 HDFS，ClickHouse 的查询优势在于宽表和单表，Join的时候它可能没有那么快，这个时候趣头条做了一个创新的方法：引入 presto。presto 可以跨库查询，在做Join的时候，它把一些数据放到 HDFS 里，通过 presto 和 ClickHouse 做Join，通过这种方式解决一些问题。它做了两个集群，满足整个日志查询和其它的查询，一个是APM查询的集群，另一个是给分析师用的集群。

5. B站

B站的场景也比较典型，它是做用户行为分析。有几千种事件类型，包括实时接入，每天有上千个查询，它遇到的挑战是任意维度、任意事件。在很久以前大家都用OLAP这种引擎去做，但都搞不定，必须得用最明细的SQL查到最底下的东西，最后分析师还要求秒级出结果，这时候B站做了响应式超大规模的用户行为分析的东西，和前面两个有点类似，第一个是把原来离线的数据导入，通过 Spark 从 HDFS 里放进来，实时的数据通过 kafka、Flink 进来，当然现在我们社区在尝试写出能直接从 kafka 进入、把 Flink 替换掉的东西。通过 ClickHouse 做查询接入服务，最后通过 JDBC 把各种报表平台、交付查询都放过去，当然它还做了一些库表管理、权限、元数据管理、集群监控等内部开发。所以整体上，B站把 ClickHouse 用于行为分析的场景。

6. 苏宁

苏宁做的是另一个场景：用户画像。它需要精准识别每一个用户的标签是什么、降低计算成本，所以做了物化视图，用去重解决了用户画像的问题。具体来说，因为在做用户画像时很多标签加工是离线计算的，这个标签不需要实时打上，但是查询或推送的时候会需要，所以苏宁一开始把所有相关的标签在 HDFS 里存了，在 MySQL 里存了维度表，把 ClickHouse 当作最后一步给用户画像平台使用的场景。现在我看到很多的传统用户也是这么使用 ClickHouse 的——当作用户的查询平台，因为它的查询是最快的。

7. 金数据

金数据它解决的是什么？大家填完统计报表，数据量可能很大，但填完以后马上就能看到结果。金数据原来使用的是 Mongo DB，但是查得不够快，而且Mongo DB 很多时候SQL兼容性不好，该怎么办？现在它的存储仍是 Mongo DB，但大家每次用金数据的报表去填或者去查的时候，背后是 ClickHouse 提供给最终使用用户去查询，所以 ClickHouse 不仅是给数据分析师使用，而且可以作为最终用户快速查询明细数据的工具。

8. 虎牙直播

虎牙做日志查询的基本做法是，通过几个 kafka 集群把所有的日志信息都放到 ClickHouse 里，进行快速查询。

刚才的场景比较多，整体上，ClickHouse 的使用场景有几个特色。第一它非常快，快到可以让最终用户直接使用。第二，它在使用用户画像和用户日志分析方面非常擅长，因为这是它在俄罗斯诞生时原生的目的。第三是擅长做APM查询log日志，在这个环节里把日志存在 ClickHouse 里而不是 MySQL 里，查询速度会比原来想象的要快很多。

三、ClickHouse 的最新特色 Feature 与未来

现在有各种各样的Feature，我讲几个比较有意思的。经常有人问我：“你看我SELECT一个2000行的东西太慢，对于列式存储数据，这件事不是特别友好，怎么办呢？”就把相关的列合并，在使用的时候稍微解析一下，ClickHouse 的速度就上去了，不要把它当成是2000列的，而是把2000列变成100列，100列里面根据不同的维度再区分，它就会很快，这是2021年的其中一个新Feature。

第二个是刚才说的 Projections。Projections 的特点是可以做预聚合，而且这和以前的 Vertica 是不一样的，Vertica 过去只支持一些聚合函数的预聚合，而 Projections 支持所有的函数。

还有存算分离。很多小伙伴说 ClickHouse 怎么存算分离？最近我们的社区公众号“Clickhouse 开发者”里连续发了案例——怎么在腾讯云上做存算分离，怎么做S3的存算分离。社区也会顺应趋势，快速、逐步地做存算分离。

余下感兴趣的大家可以去订阅最后一页社区的微信公众号，里面会有细节，也有非常多的Meetup视频我也整理在B站“ClickHouse 社区官方号”上，大家可以仔细学习。

对于未来畅想，刚才提到了很多的 Roadmap，ClickHouse 会在具体深入场景和结合解决客户使用数据最后一公里上做非常多的工作。在中国我们遇到了非常多用户和客户提出的想法和需求，所以现在中国社区也考虑是不是将来有机会能成为 ClickHouse 商业化的公司和俄罗斯一起把 ClickHouse 做大做好。

ClickHouse 有这样一些资源，在网站 Clickhouse.Yandex 上，国内的志愿者社区是www.clickhouse.com.cn，也可以注明公司-职业-姓名加我的微信号Guodaxia2999，一起把社区做的更好。非常欢迎大家使用 ClickHouse，让它成为你公司数据分析的最后一公里。

讲师简介

郭炜

易观CTO、腾讯云TVP

易观CTO，腾讯云TVP，全球顶级开源基金会 - Apache基金会正式 Member，Apache DolphinScheduler 发起人 & PMC，ClickHouse 中国社区发起人，中国软件行业协会智能应用服务分会副主任委员，中国开源社区最佳 33 人。郭炜先生毕业于北京大学，曾任联想研究院大数据总监，万达电商数据部总经理，先后在中金、IBM、Teradata任大数据方重要职位，对大数据前沿研究做出卓越贡献。2015年加入易观后，推动易观大数据技术架构及体系搭建，易观混合云架构搭建；2018年提出大数据IOTA架构（Big Data IOTA）并提出企业“数据河”（Data River）的概念，带领团队打造秒算数据计算引擎，进行了架构验证，同时在易观开源Dolphin Scheduler，在2019年入选Apache基金孵化器，2021年被评选为Apache Foundation Member成员。

点击观看峰会的精彩总结视频?