MENU

ClickHouse 的前世今生

January 29, 2023 • Read: 1015 • 编码,算法,ClickHouse

如果要说明白为什么需要在业务中引入 ClickHouse ,我们就需要从BI系统的发展开始说起。

传统 BI 系统

随着互联网技术的不断发展,越来越多的企业通过 ERP、CRM 等系统将自己的业务进行数字化管理,我们通常将这类系统称为“联机事务处理 (OLTP) 系统”。在企业的生产经营过程中,并不是只关注流程审批、数据录入这些工作。站在监管和决策层面,还需要另一种分析类的视角,例如分析报表、分析决策等。而 IT 系统的早期建设过程一般都缺少与其他系统互相配合的规划,数据散落在各个独立的系统中,互不相通。

为了解决数据孤岛的问题,人们提出了数据仓库的概念,通过引入一个专门用于分析类场景的数据库,将分散的数据汇总在一起。随着数据库仓库的发展,专注于提供数据分析、决策类功能的系统于解决方案应运而生。最终在二十世纪九十年代,第一次有人提出了 BI (商业智能)系统的概念。自此之后,人们通常用 BI 一次指代这类分析系统。相对于“联机事务处理系统”,我们把这类 BI 系统称为 “联机分析 (OLAP) 系统”

传统 BI 系统的设计初衷虽好,但实际应用效果却不令人满意,主要原因有如下几点:

  • 传统 BI 系统对企业的信息化水平要求较高。按照传统的 BI 设计思路,只有中大型企业才有能力实施。因为它的定位是站在企业视角通盘分析并辅助决策,所以如果企业的信息化水平不高,基础设施不完善,想要实施 BI 根本无从谈起。
  • 狭小的受众制约了传统 BI 系统发展的生命力。传统 BI 系统的主要受众是企业中的管理层或决策层。这类用户通常有着较高的话语权和决策权,但用户基数太小,同时他们对系统的参与度和使用度不高,久而久之这类所谓的 BI 系统就沦为了领导视察时用于演示的特供系统。
  • 研发过程滞后了需求的响应时效,传统 BI 不够灵活,有任何需求都想要大量的开发人员参与,一个分析需求的产生到最终实现,可能想要数周或者几个月的时间。

现代 BI 系统

SaaS 模式的兴起,为传统企业软件系统的商业模式带来了新思路,是一次新的技术普惠。一方面 SaaS 模式将之前只服务于大型企业的软件系统放到了互联网,扩展了它的受众;另一方面,由于互联网用户的基本特征和软件诉求,加上同类系统的互相竞争,又倒逼了这些软件系统在方方面面进行革新于升级。而这次的技术普惠,同样也影响了 BI 系统在设计思路上的变革。

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

经过互联网的系列,即使现代 BI 系统仍私有化部署在企业内部,只服务于企业用户,但它也必须具有快速应答,简单易用的使用体验,从某种角度来看,互联网浪潮帮助企业系统在易用性和用户体验上进行了革命性的提升。

如果说 SaaS 化为现代 BI 系统提供了新的思路与契机,那么背后的技术创新则保障了其思想的落地。在传统 BI 系统的架构体系中,数据存储使用的是传统的关系型数据库(OLTP 数据库)。为了能够解决在海量数据下分析查询的性能问题,在数据库仓库的基础上衍生了众多新的概念:

  • 数据分层:通过对对数据进行分层,通过层层递进形成数据集市,从而减少最终查询到数据体量。
  • 数据立方体:通过对数据进行预先处理,以空间换时间,提高查询性能。

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

随着 Google 陆续发表的三篇论文开启了大数据时代的技术普惠,Hadoop 生态由此刻开始一发不可收拾,数据分析开启了新纪元。从某种角度来看,使用 Hadoop 生态为代表的这类非传统关系型数据库技术所实现的 BI 系统,可以被称之为现代 BI 系统。换装了大马力发动机的现代 BI 系统在面对海量数据分析时的场景时,显得更加游刃有余。然而 Hadoop 技术也不是银弹,在现代 BI 系统的构建中仍面临诸多挑战,在海量数据下要实现多维度分析的实时应答,仍困难重重。

::: alert-info
现代 BI 系统的典型应用场景是多维分析,某些时候可以直接使用 OLAP 指代这类场景
:::

OLAP 常见架构分类

OLAP 技术发展至今,分析型数据库百花齐放。然而,看似手上拥有很多筹码的架构师们,有时却面临无牌可打的窘境,为什么会这样?要理解这个问题,我们需要重温一下什么是 OLAP,以及实现 OLAP 的几种思路。

之前说过,OLAP 为联机分析,又称多维分析,是由数据库关系之父 埃德加 ·科德 于 1993 年提出的概念。顾名思义,它是通过多种不同的维度审视数据,进行深层次的分析。维度可以看作是观察数据的一种视角,例如人类能看到的世界是三维的,包含长宽高三个维度(不考虑时间维度)。直接地说,维度就好比是一张数据表的字段,而多维分析就是针对这些字段进行聚合查询。

那么多维分析通常都包含哪些基本操作?为了更好地理解多维分析的概念,可以使用一个立方体的图像具象化操作。

title=

例如,对于张销售明细表,数据立方体可以进行如下操作。

  • 下钻 从高层次向低层次明细数据穿透。例如从省下钻到市,从湖北省穿透到武汉和宜昌。
  • 上卷 和下钻相反,从低层次向高层次汇聚,例如从市汇聚成省,将武汉和宜昌汇聚成湖北。
  • 切片 观察立方体的一层,将一个或多个维度设为单个固定值,然后观察剩余的维度,例如将商品维度固定为足球。
  • 切块 与切片类似,只是将单个固定值变成多个固定值。例如将商品的维度设置为足球、篮球和乒乓球。
  • 选择 旋转立方体的一面,如果要将数据映射到一张二维表,那么就要进行旋转,也就是行列置换。

为了使能实现上面的操作,常见的 OLAP 架构大致分为三大类:

ROLAP

第一类架构称为 ROLAP (Relational OLAP 关系型 OLAP),正如这个名字所说,它是直接使用关系模型构建,数据模型通常是星型模型或雪花模型。这是最先能想到,也是最为直接的实现方法。因为 OLAP 概念在最初提出的时候,是建立在关系型数据库技术之上,多维分析操作可以直接转换为 SQL 查询。例如通过上卷操作查看省份销售额,可以通过下面的SQL实现:

SELECT SUM(price) FROM selling_price GROUP BY province

但是这样的架构对数据的实时处理能力要求很高,如果单张表数据达到上一条,分组字段达到数十个字段,那么不但执行查询的性能消耗是巨大的,而且查询所需的时间消耗也会很长。

MOLAP

第二类架构称为 MOLAP (Multidimensional OLAP 多维型 OLAP),它的出现主要是为了缓解 ROLAP 性能问题。MOLAP 使用的是多维数组的形式保存数据,也就是我们所说的空间换时间。具体的实现方法就是先确定维度字段, 过预处理的方式对多维数据进行聚合运算,然后将聚合结果缓存起来。这样一来在后续的查询过程中可以直接返回预先缓存的数据,但这样并不完美,多维度的预处理可能会导致缓存数据量的膨胀。以前面的销售明细表为例,如果数据立方体包含了五个维度的数据,那么维度组合的方式有 2^5^ (2^n^, 其中 n 代表维度个数) 个。当一张数据量为千万级的数据表,聚合后的数据量可以膨胀到亿级别。人们意识到这个问题之后,也实现了一些能够降低数据膨胀率的优化手段,但治标不治本。另外,预处理的方式会造成数据立方体有一定的滞后性,不能进行实时的数据分析。而且数据立方体只保留了聚合后的查询数据,不能查询明细数据。

HOLAP

第三类架构称为 HOLAP (Hybrid OLAP 混合架构 OLAP)。这个架构的思路是 ROLAP 和 MOLAP 的融合版,将两者的优点进行互补。对于查询频繁而耗时的SQL,通过预计算来提速。对于查询较快,发生次数较少或查询条件不固定的需求,像 ROLAP 一样操作物理表和维度表。

OLAP 实现技术的演进

在了解完 OLAP 的几种架构后,再看看这些架构背后技术的演进过程,我们可以把这些过程分为两个阶段。

第一阶段可以称为关系型数据库阶段,在这个阶段中,OLAP 主要是基于 Oracle、MySQL 为代表的一系列关系型数据实现。在 ROLAP 架构下,直接使用这些数据库作为存储与计算的载体。在 MOLAP 架构下,则借助物化视图的形式实现数据立方体。在这个发展阶段,无论是 ROLAP 还是 MOLAP 在数据体量巨大、维度众多的情况下都存在严重性能问题。

第二阶段可以称为大数据技术阶段,由于大数据处理技术的普及,人们开始使用大数据技术重构 ROLAP 和 MOLAP。以 ROLAP 为例,传统关系型数据库被 Hive 和 SparkSQL 这类新兴技术所取代。虽然以 SparkSQL 为代表的分布式计算系统,相比 Oracle、MySQL 这类传统数据库系统来说,在海量数据处理方面已经优秀了很多,但面向终端用户的查询需求还是太慢。互联网用户普遍缺乏耐心,如果一个查询请求需要几十秒或数分钟才能响应,依然不能满足需求。再看 MOALP 架构,MOLAP 的背后技术也转为依托 MapReduce 或 Spark 这类新兴技术,将其作为立方体计算引擎,加速立方体的构建过程。其聚合结果的存储载体也转为 HBase 这类高性能分布式数据库系统。在大数据阶段,主流的 MOLAP 架构已经能够在亿万级数据的体量下,实现毫秒级的查询响应。尽管如此,MOLAP 依然存在维度爆炸、数据同步实施性不高的问题。

不难发现,虽然 OLAP 在经历大数据的洗礼后,在其各方面性能有了脱胎换骨的改观,但不论是ROLAP 还是 MOLAP,仍然存在各自的痛点。

如果单从模型角度考虑,很显然 ROLAP 架构更胜一筹。因为 ROLAP 模型拥有更好的“群众基础”,也更简单且容易理解。它可以直接面向明细数据查询,由于不需要预处理自然也没有维度组合爆炸、数据实时性、额外的更新逻辑之类的繁琐问题。那么有没有一种技术,既可以使用 ROLAP 模型,又拥有比肩 MOLAP 的性能呢。

横空出世的黑马

上文提到,以 Spark 为代表的新一代 ROLAP 方案虽然可以一站式处理海量数据,但无法真正做到实时应答和高并发,更适合作为一个后端的查询系统。而新一代 MOLAP 方案虽然解决了大部分查询性能的问题,能做到实时应答,但数据膨胀和预处理的问题并没有被解决。除了以上两种方案,还有一种另辟蹊径的选择,既抛弃 ROLAP 和 MOLAP 转而使用搜索引擎来实现 OLAP 查询,ElasticSearch 就是这类方案的代表。ElasticSearch 支持实时更新,在百万级别数据的场景下可以做到实时的聚合查询,但随着数据量的持续增加,它的查询性能也开始捉襟见肘。

面对上面提到的种种问题,也就引出了书讨论的主角。

天下武功 唯快不破

Clickhouse 具有 ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量写入/更新、拥有非常完善的 SQL 语法支持和函数、支持高可用,不依赖 Hadoop 复杂生态、部署方便和开箱即用等许多特点。特别是 ClickHouse 那离谱的查询性能,相信大多数刚接触 ClickHouse 的开发者一定会因为它的性能指标而动容。在官方公布的基准测试对比中,ClickHouse 都是遥遥领先对手,而参与对比的数据库,不乏一些我们耳熟能详的名字。

所有对比的数据库都使用了相同的服务器,在单机部署的场景下,对一张拥有 133 个字段的数据库表分别在 1000 万、1 亿、10 亿 三种数据体量下执行基准测试,基准测试范围覆盖 43 项 SQL 查询。ClickHouse 的平均响应速度是 MySQL 的 751 倍、MonetDB 的 3.28 倍、SQLite 的 251 倍、MongoDB 的 116 倍。详细测试结果可以查询 https://benchmark.clickhouse.com,需要注意的是因版本不断更新的原因,官方的测试结果可能会随之更新,测试结果可能与本文会有所不同。

活跃的社区

ClickHouse 是一款开源软件,遵循 Apache License 2.0 协议。同时 ClickHouse 开源项目在 Github 上也十分活跃,截至目前(2023-1-17)已经拥有超过1100 位贡献者,发布版本达到 425 个。惊人的更新频率、友好的开源协议、活跃的社区、积极的响应,这意味着我们可以及时获取最新特性并且遇到问题时也能得到修复缺陷的补丁。

ClickHouse 的发展

ClickHouse 的研发团队是来自于俄罗斯的 Yandex 公司,这家公司的核心产品是搜索引擎,目前已占据了 俄罗斯 53% 的的搜索市场,是目前世界上最大的俄语搜索引擎。

搜索引擎的营收非常依赖流量和在线广告业务。所以通常搜索引擎公司为了更好的帮助自身以及用户分析网站流量,都会推出自家的在线流量分析产品,例如谷歌的 Google Analytics、百度的百度统计。而 Yandex 也拥有自家的在线流量分析产品 Yandex.Metrica。ClickHouse 就是在这样的产品背景下诞生的,伴随着 Yandex.Metrica 业务的发展,其底层架构经历了四个阶段,一步一步形成了目前大家所看到的 ClickHouse。纵观这四个阶段的发展,俨然是数据分析产品形态以及 OLAP 架构历史演进的缩影。通过了解这段演进过程,我们能够更加透彻地了解 OLAP 面对的挑战,以及 ClickHouse 能够解决的问题。

MySQL 时期

从技术发展的角度来看,当时还处于关系型数据库的霸主时期,所以 Yandex 在其他的内部产品中使用了 MySQL 数据库作为统计信息系统的底层存储方案。Yandex.Metrica 的第一版架构就顺理成章地延续了这套成熟稳定的 MySQL 方案,并将其作为数据存储和分析引擎的解决方案。

Yandex.Metrica 的表引擎为 MyISAM 引擎,这类分析场景更关注数据的写入和查询性能,不关注事务。相比 InnoDB 表引擎, MyISAM 表引擎在分析场景中具有更好的性能。业内有一个常识性的认知,按照顺序存储的数据会拥有更高的查询性能,因为读取顺序文件会减少磁盘寻址时间。同时顺序读取也能充分利用操作系统层面文件缓存的预读功能。所以数据库查询时如果按照顺序读取,会比随机读取的查询性能会高很多。但 Yandex 内部的 MySQL 方案却无法做到顺序存储。

MyISAM 表引擎使用的是 B + Tree 结构存储索引,而数据则是使用单独的存储文件。如果只考虑单线程写入场景,并且写入过程中不涉及数据删除或更新操作,那么数据会按照写入顺序一次被写入磁盘,然而实际的业务场景不可能如此简单。

流量数据采集的链路是这样的,Web 端的应用通过 Yandex 提供的站点 SDK 实时采集数据并发送到远端的接收系统,再由接收系统将数据写入 MySQL 集群。由于数据接收系统的个分布式系统,所以他们会并行、随机将数据写入 MySQL 集群。这也导致了数据最终在磁盘里是完全随机存储的,并且会产生大量的磁盘碎片。

市面上一块 7200 RPM SATA 磁盘的 IOPS (每秒能处理请求数量) 仅为 100 左右,也就是每秒只能执行 100 次随机读取。假设一次随机读取返回十行数据,那么查询 10 万行记录则需要至少 100 秒,这样的响应时间显然是不可接受的。虽然可以通过 RAID 提高磁盘的 IOPS 性能,但并不能解决根本问题,SSD 随机读取性能很高,但考虑到硬件成本和集群规模,不可能全部采用 SSD 存储。

随着时间的推移,MySQL 中存储的数据越来越多(截止 2011 年,存储数据已超过 5800 亿行),虽然 Yandex 又额外做了很多优化,成功的将 90% 的分析报告控制在26秒内返回,但这套方案越来越显得力不从心。

Metrage 时期

由于 MySQL 带来的局限性,Yandex 自研了一套全新的系统并命名为 Metrage。Metrage 在设计上与 MySQL 完全不同,他选择了另一条完全不同的道路:

  • 在模型层面,它使用了 Key-Value 模型代替了关系模型;
  • 在索引层面,他使用了 LSM 代替了 B+ 树;
  • 在数据处理层面,由实时查询的方式改为了预处理;

LSM Tree 是一种非常流行的索引结构,发源于 Google 的 Big Table,现在最具有代表性使用 LSM Tree 索引结构系统的是 HBase。LSM 本质上可以看作是将原本的一颗大树拆成了许多棵小树,每一批次写入的数据都会经过如下的过程:首先会在内存中构建一棵小树,构建完毕即算写入成功。写入动作只发生在内存中,不涉及磁盘操作,所以极大地提升了写入的性能。其次小树在构建的过程中会进行排序,这样保证了数据的有序性。最后当内存中的小树的数量大达到某个阈值时,跳过后台线程将小树刷入磁盘,并生成一个小的数据段。在每个数据段中,数据局部有序。也正是因为数据有序,所以能够使用稀疏索引来优化查询性能。借助 LSM Tree 索引,可以让 Metrage 引擎在软硬件层面同时得到优化(磁盘顺序读取、预读缓存、稀疏索引等),最终有效提高系统的综合性能。

在索引结构优化的基础上,还是不能解决根本的性能问题。Metrage 的第二个重大转变就是通过预处理的方式将数据进行预先聚合。按照数据立方体的思想计算所有维度组合,最后将聚合的结果按照 Key-Value 的形式存储。这样一来,对于固定分析场景,可以直接利用数据立方体的聚合结果立即返回相关数据。这套系统的实现思路与现如今的一些 MOLAP 系统如出一辙。

经过一系列的转变,Metrage 为 Yandex.Metrica 的性能带来了革命性地提升。截至 2015 年,Metrage 内部存储超过了3 万亿行数据,其集群规模超过了 60 台服务器,查询耗时也由之前的 26 秒下降到 1 秒内。然而,使用立方体的思路会产生一个新的问题,就是维度组合爆炸,因为需要预先对所有的维度组合进行计算,这是一种指数级的增长方式,维度组合的爆炸会直接导致数据膨胀。

OLAPServer 时期

在 Yandex.Metrica 的产品初期,它只支持固定报表的分析功能。随着时间的推移,这种固定化的分析形式早已不能满足用户的诉求,于是 Yandex.Metrica 计划推出自定义分析报告的功能。然而 Metrage 系统却无法满足这类自定义的分析场景,因为它需要预先聚合,并且只提供了内置的 40 多种固定分析场景。单独为每个用户提供个人的预聚合功能显然是不切实际的。在这种背景下,Yandex.Metrica 研发团队只能寻求自我突破,于是研发了 OLAPServer 系统。

OLAPServer 系统被设计成了专门处理自定义报告这样临时性分析需求的系统,与 Metrage 系统形成互补关系。结合之前两个阶段的建设经验,OLAPServer 在设计思路是取众家之所长。数据模型方面又换回了关系模型,因为相比 Key-Value 模型来说,关系模型拥有更好的描述能力,使用 SQL 作为查询语言,也会拥有更好的“群众基础”。而在存储结构和索引方面,OLAPServer 吸收了 MyISAM 和 LSM Tree 最精华的部分。

  • 存储结构,它与 MyISAM 表引擎类似,分别为索引文件和数据文件两个部分。
  • 索引方面,它并没有完全沿用 LSM Tree,而是使用了 LSM Tree 所使用的稀疏索引。
  • 数据文件,在数据文件的设计上,沿用了 LSM Tree 中数据段的思想,即数据段内数据有序,借助稀疏索引定位数据段。

在拥有上述基础后,OLAPServer 引入了列式存储的思想,将索引文件按照列字段的颗粒度进行拆分,每个列字段各自独立存储,以进一步减少数据读取的范围。

虽然 OLAPServer 在实时聚合方面性能相比 MySQL 有了质的飞跃,但从功能完备的角度来说,还是差了一个量级。因此 OLAPServer 的定位只是和 Metrage 形成互补,所以它确实列一些基础的功能,例如 它只支持定长的 INT 类型,且没有 DBMS 应有的基础管理功能。

ClickHouse 时代

在初步满足需求后,Yandex.Metrica 又面临了新的选择题,实时聚合还是预先聚合?实时聚合的方案在查询性能方面带来了质的提升,成功的将查询报告所需的时间从 26 秒降低到 1 秒内,但又带来了新的问题。

  1. 预先聚合只能支持固定的分析场景,所以无法满足自定义需求的分析。
  2. 维度组合爆炸会导致数据膨胀,会造成不必要的计算和存储开销。因为用户不一定会用到所有维度的组合,那些用到的组合将成为浪费的开销。
  3. 流量数据是在线实时接收的,所以预聚合还需要考虑如何及时地更新数据。

所以,如果查询性能可以得到保障,实时聚合会是一个更为简洁的架构。由于 OLAPServer 的成功经验,选择倾向于实时聚合这一方。

OLAPServer 的查询性能并不比 Metrage 差太多,在查询的灵活性方面反而更胜一筹。于是 Yandex.Metrica 的研发团队以 OLAPServer 为基础进一步完善,以实现一个完备的数据库管理系统(DBMS)为目标 ,最终打造出了 ClickHouse,并于 2016 年开源。

ClickHouse 名称的含义

由于 Yandex.Metrica 是一款 Web 流量分析工具,采集用户在网页上的点击行为数据,然后进行一系列的数据分析,类似于数据库仓库的 OLAP 分析。所以 ClickHouse 的全称是 Click Stream, Data WareHouse , 简称为 ClickHouse。

ClickHouse 适用场景

因为 ClickHouse 在诞生之初就是为了服务自家的 Web 流量分析产品 Yandex.Metrica, 所以在存储数据量超过 20 万亿行的情况下,ClickHouse 做到了 90% 的查询都能在 1 秒内响应结果。随后,ClickHouse 进一步被应用到 Yandex 内部大大小小数十个其他的分析场景中。可以说 ClickHouse 是具备了人们对一款高性能 OLAP 数据库的向往。所以它基本能胜任各种数据分析类场景,并随着数据体量的增大,它的优势也会变的越为明显。

ClickHouse 非常适用于商业智能领域(也就是 BI 领域),除此之外,他能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

ClickHouse 不适用场景

ClickHouse 作为一款高性能 OLAP 数据库,虽然足够优秀,但也不是万能的,我们不应该把它用于任何 OLTP 事务性操作场景,因为它有以下几点不足:

  • 不支持事务
  • 不擅长根据主键按行粒度进行查询(虽然支持),故不应该把 ClickHouse 当作 Key-Value 数据库使用。
  • 不擅长按行删除数据(虽然支持)

虽然 ClickHouse 数据库有上面这些缺点,但事实上 其他同类高性能的 OLAP 数据库同样也不擅长上述的这些方面。因为对于一款 OLAP 数据库来说,上述的这些能力并不是重点,所以为了极致的查询性能做出权衡。

都有谁在使用

除了 Yandex 自己将 ClickHouse 用来计算广告收益和流量分析统计外,还被众多商业公司运用到了生产环境。

  • CENRN(欧洲核子研究中心)将其用于保存强对撞机试验后记录下的数十亿时间的测试数据,并将数据查找时间由几个小时缩短到几秒。
  • Mail.ru 使用 ClickHouse 作为其网络游戏平台的数据分析引擎,用于实时统计玩家行为和游戏数据。
  • Uber 使用 ClickHouse 作为其运营数据分析平台,用于实时监控和优化其网约车业务。
  • Samsung 使用 ClickHouse 作为其物联网平台的数据分析引擎,用于统计设备数据和监控设备状态。
  • Wargaming 使用 ClickHouse 作为其多人在线游戏平台的数据分析引擎,用于实时统计玩家行为和游戏数据。
  • 阿里巴巴集团在其电商、金融、物流等业务中使用 ClickHouse 来实现实时大数据分析。
  • 腾讯在其社交、游戏、广告等业务中使用 ClickHouse 来实现实时大数据分析。
  • 百度在搜索、广告等业务中使用 ClickHouse 来实现实时大数据分析。
  • 字节跳动在其新闻、短视频等业务中使用 ClickHouse 来实现实时大数据分析。
  • 哔哩哔哩、永辉超市、京东云、网易、新浪等国内的互联网公司也都有应用。

笔记来自:《ClickHouse 原理解析与应用实践》第一章 ClickHouse 的前世今生