导读：一次机缘巧合，在研究BI产品技术选型的时候，我接触到了ClickHouse，瞬间就被其惊人的性能所折服。这款非Hadoop生态、简单、自成一体的技术组件引起了我极大的好奇。那么ClickHouse好在哪呢?本文带你做一个初步了解。

作者：朱凯

来源：大数据DT（ID：hzdashuju）

01 传统BI系统之殇

得益于IT技术的迅猛发展，ERP、CRM这类IT系统在电力、金融等多个行业均得以实施。这些系统提供了协助企业完成日常流程办公的功能，其应用可以看作线下工作线上化的过程，这也是IT时代的主要特征之一，通常我们把这类系统称为联机事务处理(OLTP)系统。

企业在生产经营的过程中，并不是只关注诸如流程审批、数据录入和填报这类工作。站在监管和决策层面，还需要另一种分析类视角，例如分析报表、分析决策等。而IT系统在早期的建设过程中多呈烟囱式发展，数据散落在各个独立的系统之内，相互割裂、互不相通。

为了解决数据孤岛的问题，人们提出了数据仓库的概念。即通过引入一个专门用于分析类场景的数据库，将分散的数据统一汇聚到一处。借助数据仓库的概念，用户第一次拥有了站在企业全局鸟瞰一切数据的视角。

随着这个概念被进一步完善，一类统一面向数据仓库，专注于提供数据分析、决策类功能的系统与解决方案应运而生。最终于20世纪90年代，有人第一次提出了BI(商业智能)系统的概念。自此以后，人们通常用BI一词指代这类分析系统。相对于联机事务处理系统，我们把这类BI系统称为联机分析(OLAP)系统。

传统BI系统的设计初衷虽然很好，但实际的应用效果却不能完全令人满意。我想之所以会这样，至少有这么几个原因。

首先，传统BI系统对企业的信息化水平要求较高。按照传统BI系统的设计思路，通常只有中大型企业才有能力实施。因为它的定位是站在企业视角通盘分析并辅助决策的，所以如果企业的信息化水平不高，基础设施不完善，想要实施BI系统根本无从谈起。这已然把许多潜在用户挡在了门外。

其次，狭小的受众制约了传统BI系统发展的生命力。传统BI系统的主要受众是企业中的管理层或决策层。这类用户虽然通常具有较高的话语权和决策权，但用户基数相对较小。同时他们对系统的参与度和使用度不高，久而久之这类所谓的BI系统就沦为了领导视察、演示的“特供系统”了。

最后，冗长的研发过程滞后了需求的响应时效。传统BI系统需要大量IT人员的参与，用户的任何想法，哪怕小到只是想把一张用饼图展示的页面换成柱状图展示，可能都需要依靠IT人员来实现。一个分析需求从由用户大脑中产生到最终实现，可能需要几周甚至几个月的时间。这种严重的滞后性仿佛将人类带回到了飞鸽传书的古代。

02 现代BI系统的新思潮

技术普惠是科技进步与社会发展的一个显著特征。从FM频段到GPS定位乃至因特网都遵循着如此的发展规律。有时我们很难想象，这些在现今社会习以为常的技术，其实在几十年前还仅限于服务军队这类少数群体。

每一次技术普惠的浪潮，一方面扩展了技术的受众，让更多的人享受到了技术进步带来的福利;另一方面，由于更多的人接触到了新的技术，反过来也提升了技术的实用性和完善程度，加速了技术的成长与发展。

如果说汽车、火车和飞机是从物理上拉近了人与人之间的距离，那么随着互联网的兴起与风靡，世界的距离从逻辑上再一次被拉近了。现今世界的社会结构与人类行为，也已然被互联网深度改造，我们的世界逐渐变得扁平化与碎片化，节奏也越来越快。

根据一项调查，互联网用户通常都没有耐心。例如47%的消费者希望在2秒或更短的时间内完成网页加载，40%的人放弃了加载时间超过3秒的网站，而页面响应时间每延迟1秒就可以使转换率降低7%。实时应答、简单易用，已经是现代互联网系统的必备素质。

SaaS模式的兴起，为传统企业软件系统的商业模式带来了新的思路，这是一次新的技术普惠。一方面，SaaS模式将之前只服务于中大型企业的软件系统放到了互联网，扩展了它的受众;另一方面，由于互联网用户的基本特征和软件诉求，又倒逼了这些软件系统在方方面面进行革新与升级。

技术普惠，导致现代BI系统在设计思路上发生了天翻地覆的变化。

首先，它变得“很轻”，不再需要强制捆绑于企业数据仓库这样的庞然大物之上，就算只根据简单的Excel文件也能进行数据分析。

其次，它的受众变得更加多元化，几乎人人都可以成为数据分析师。现代BI系统不需要IT人员的深度参与，用户直接通过自助的形式，通过简单拖拽、搜索就能得到自己想要的分析结果。

最后，由于经过互联网化的洗礼，即便现代BI系统仍然私有化地部署在企业内部，只服务于企业客户，但它也必须具有快速应答、简单易用的使用体验。从某种角度来看，经过SaaS化这波技术普惠的洗礼，互联网帮助传统企业系统在易用性和用户体验上进行了革命性提升。

如果说SaaS化这波技术普惠为现代BI系统带来了新的思路与契机，那么背后的技术创新则保障了其思想的落地。在传统BI系统的体系中，背后是传统的关系型数据库技术(OLTP数据库)。

为了能够解决海量数据下分析查询的性能问题，人们绞尽脑汁，在数据仓库的基础上衍生出众多概念，例如：对数据进行分层，通过层层递进形成数据集市，从而减少最终查询的数据体量;提出数据立方体的概念，通过对数据进行预先处理，以空间换时间，提升查询性能。

然而无论如何努力，设计的局限始终是无法突破的瓶颈。OLTP技术由诞生的那一刻起就注定不是为数据分析而生的，于是很多人将目光投向了新的方向。

Google于2003～2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”，将大数据的处理技术带进了大众视野。三篇论文开启了大数据的技术普惠，Hadoop生态由此开始一发不可收拾，数据分析开启了新纪元。

2006年开源项目Hadoop的出现，标志着大数据技术普及的开始，大数据技术真正开始走向普罗大众。长期以来受限于数据库处理能力而苦不堪言的各路豪杰们，仿佛发现了新大陆，于是一轮波澜壮阔的技术革新浪潮席卷而来。

从某种角度来看，以使用Hadoop生态为代表的这类非传统关系型数据库技术所实现的BI系统，可以称为现代BI系统。换装了大马力发动机的现代BI系统在面对海量数据分析的场景时，显得更加游刃有余。

然而Hadoop技术也不是银弹，在现代BI系统的构建中仍然面临诸多挑战。在海量数据下要实现多维分析的实时应答，仍旧困难重重。(现代BI系统的典型应用场景是多维分析，某些时候可以直接使用OLAP指代这类场景。)

Hadoop最初指代的是分布式文件系统HDFS和MapReduce计算框架，但是它一路高歌猛进，在此基础之上像搭积木一般快速发展成为一个庞大的生态(包括Yarn、Hive、HBase、Spark等数十种之多)。在大量数据分析场景的解决方案中，传统关系型数据库很快就被Hadoop生态所取代，我所处的BI领域就是其中之一。

传统关系型数据库所构建的数据仓库，被以Hive为代表的大数据技术所取代，数据查询分析的手段也层出不穷，Spark、Impala、Kylin等百花齐放。Hadoop发展至今，早已上升成为大数据的代名词，仿佛一提到海量数据分析场景下的技术选型，就非Hadoop生态莫属。

虽然Hadoop生态化的属性带来了诸多便利性，例如分布式文件系统HDFS可以直接作为其他组件的底层存储(例如HBase、Hive等)，生态内部的组件之间不用重复造轮子，只需相互借力、组合就能形成新的方案。

但生态化的另一面则可以看作臃肿和复杂。Hadoop生态下的每种组件都自成一体、相互独立，这种强强组合的技术组件有些时候显得过于笨重了。与此同时，随着现代化终端系统对实效性的要求越来越高，Hadoop在海量数据和高时效性的双重压力下，也显得有些力不从心了。

03 一匹横空出世的黑马

我从2012年正式进入大数据领域，开始从事大数据平台相关的基础研发工作。2016年我所在的公司启动了战略性创新产品的规划工作，自此我开始将工作重心转到设计并研发一款具备现代化SaaS属性的BI分析类产品上。为了实现人人都是分析师的最终目标，这款BI产品必须至少具备如下特征。

一站式：下至数百条数据的个人Excel表格，上至数亿级别的企业数据，都能够在系统内部被直接处理。

自服务，简单易用：面向普通用户而非专业IT人员，通过简单拖拽或搜索维度，就能完成初步的分析查询。分析内容可以是自定义的，并不需要预先固定好。

实时应答：无论数据是什么体量级别，查询必须在毫秒至1秒内返回。数据分析是一个通过不断提出假设并验证假设的过程，只有做到快速应答，这种分析过程的路径才算正确。

专业化、智能化：需要具备专业化程度并具备智能化的提升空间，需要提供专业的数学方法。

为了满足上述产品特性，我们在进行底层数据库技术选型的时候可谓是绞尽脑汁。

以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据，但无法真正做到实时应答和高并发，它更适合作为一个后端的查询系统。而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题，能够做到实时应答，但数据膨胀和预处理等问题依然没有被很好解决。

除了上述两类方案之外，也有一种另辟蹊径的选择，即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询，ElasticSearch是这类方案的代表。ElasticSearch支持实时更新，在百万级别数据的场景下可以做到实时聚合查询，但是随着数据体量的继续增大，它的查询性能也将捉襟见肘。

难道真的是鱼与熊掌不可兼得了吗?直到有一天，在查阅一份Spark性能报告的时候，我不经意间看到了一篇性能对比的博文。

Spark的对手是一个我从来没有见过的陌生名字，在10亿条测试数据的体量下，Spark这个我心目中的绝对王者，居然被对手打得落花流水，查询响应时间竟然比对手慢数90%之多。而对手居然只使用了一台配有i5 CPU、16GB内存和SSD磁盘的普通PC电脑。

我揉了揉眼睛，定了定神，这不是做梦。ClickHouse就这样进入了我的视野。

1. 天下武功唯快不破

我对ClickHouse的最初印象极为深刻，其具有ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用等许多特点。

特别是它那夸张的查询性能，我想大多数刚接触ClickHouse的人也一定会因为它的性能指标而动容。在一系列官方公布的基准测试对比中，ClickHouse都遥遥领先对手，这其中不乏一些我们耳熟能详的名字。

所有用于对比的数据库都使用了相同配置的服务器，在单个节点的情况下，对一张拥有133个字段的数据表分别在1000万、1亿和10亿三种数据体量下执行基准测试，基准测试的范围涵盖43项SQL查询。

在1亿数据集体量的情况下，ClickHouse的平均响应速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。

详细的测试结果可以查阅：

https://clickhouse.yandex/benchmark.html

2. 社区活跃

ClickHouse是一款开源软件，遵循Apache License 2.0协议，所以它可以被免费使用。同时它的开源社区也非常跃度，其在全球范围内约有400位贡献者。

ClickHouse版本发布频率惊人，基本保持着每个月发布一次版本的更新频率。友好的开源协议、活跃的社区加上积极的响应，意味着我们可以及时获取最新特性并得到修复缺陷的补丁。

篇幅有限，如果你想了解ClickHouse的更多细节，可以看一看《QQ音乐大数据架构技术演进》这篇文章，并关注我们后续的推送文章，还有下面这本书。