ClickHouse的基本介绍，什么是ClickHouse？
楔⼦
最近公司决定采⽤ ClickHouse 来做数据的⼤规模处理，关于 ClickHouse 虽然早有⽿闻，但因为时间原因并没有专门去学习。⽽公司也考虑到⽬前内部具有 ClickHouse 使⽤经验的⼈还不是很多，因此给了相对⽐较充⾜的时间去了解。虽然 ClickHouse 诞⽣于 2016 年，但相对于 Hadoop ⽣态圈⽽⾔，普及度显然还没有那么⼴，因此除了官⽹之外还没有看到⽐较合适的教程。不过幸运的是在京东上⾯发现了⼀本关于 ClickHouse 的书，叫
《ClickHouse 原理解析与应⽤实践》，由朱凯⽼师编写，据悉这是第⼀本讲解 ClickHouse 的书。看了⼀下⽬录，感觉内容还是⽐较充实的，于是果断买下来，⽤于学习。
因此本⽂很多内容均来⾃于此书，只不过书中的 ClickHouse 版本有些低了（ClickHouse 的发布频率还是挺快
的），这⾥采⽤了⼀个⽐较新的版本，因此安装时的细节会有些不同。那么下⾯就开始 ClickHouse 的学习之旅
吧，看看 ClickHouse 究竟是何⽅神圣，为何能够异军突起。
Google 于 2003~2006 年相继发表了三篇论⽂："Google File System"、"Google MapReduce"、"Google Bigtable"，将⼤数据的处理技术带进了⼤众视野，⽽ 2006 年开源项⽬ Hadoop 的出现，则标志着⼤数据处理技术普及的开始，⼤数据技术真正开始⾛向⼤众。Hadoop 最初指的是分布式⽂件系统 HDFS 和 MapReduce 计算框架，但是它⼀路⾼歌猛进，在此基础之上像搭积⽊⼀样快速发展成为⼀个庞⼤的⽣态（被称为 Hadoop ⽣态圈），其中包括 Hive、HBase、Spark 等数⼗种框架。⽽在⼤数据分析场景的解决⽅案中，传统的关系型数据库很快就被 Hadoop ⽣态圈所取代，BI 领域就是其中之⼀。像传统关系型数据库所构建的数据仓库，就被以 Hive 为代表的⼤数据技术所取代，数据查询分析的⼿段更是层出不穷，Spark、Impala、Kylin 等框架百花齐放。Hadoop 发展⾄今，早已上升成为⼤数据的代名词，仿佛⼀提到海量数据分析场景下的技术选型，就⾮ Hadoop ⽣态莫属。
然⽽世间并没有银弹（万全之策），Hadoop 也跳不出这个规则。虽然 Hadoop ⽣态圈已经相当完善了，不同的组件也可以相互对接，例如分布式⽂件系统 HDFS 可以直接作为其他组件的底层存储（像 HBase、Hive 等），⽣态内部的组件之间不⽤重复造轮⼦，只需相互借⼒、组合就能形成新的⽅案。但⽣态化的另⼀⾯则可以看做臃肿和复杂，Hadoop ⽣态下每种组件都⾃成⼀体、相互独⽴，这种强强组合的技术组件有些时候则显得过于笨重了。与此同时，随着现代化终端系统对实时性的要求越来越⾼，Hadoop ⽣态在海量数据和⾼时效性的双重压⼒下，也显得有些⼒不从⼼了。
⽽这个时候，ClickHouse出现了，它是俄罗斯的 Yandex 公司于 2016 年开源的列式存储数据库，使⽤ C++ 语⾔编写，专门⽤于 OLAP（联机分析处理），其惊⼈的性能可以瞬间让你跪倒在它的⽯榴裙下。
什么是 OLAP？
这⾥先回顾⼀下什么是 OLAP，以及实现 OLAP 的⼏种常见思路。
前⾯说了，OLAP 名为联机分析处理，⼜可以称之为多维分析处理，是由关系型数据之⽗于 1993 年提出的概念。顾名思义，它指的是通过多种不同的维度审视数据，进⾏深层次分析。维度可以看成是观察数据的⼀种视⾓，例如⼈类能看到的世界是三维的，它包含长、宽、⾼三个维度。直接⼀点理解，维度就好⽐是⼀张数据表的字段，⽽多维分析则是基于这些字段进⾏聚合查询。那么多维分析通常都包含哪些基本操作呢？为了更好地理解多维分析的概念，可以通过对⼀个⽴⽅体的图像进⾏具象化来描述。以如下⼀张销售明细表为例：
那么数据⽴⽅体可以进⾏如下操作：
下钻：从⾼层次向低层次明细数据进⾏穿透。例如从 "省" 下钻到 "市"，从 "湖北省" 穿透到 "武汉" 和 "宜昌" 。
上卷：和下钻相反，从低层次向⾼层次汇聚。例如从 "市" 汇聚到 "省"，将 "武汉" 和 "宜昌" 汇聚成 "湖北"。
切⽚：观察⽴⽅体的⼀层，将⼀个或多个温度设为单个固定的值，然后观察剩余的维度，例如将商品维度固定为 "⾜球"。
切块：和切⽚类似，只是将单个固定值变成多个固定值。例如将商品维度固定为"⾜球"、"篮球" 和 "乒乓球"。
旋转：旋转⽴⽅体的⼀⾯，如果要将数据映射到⼀张⼆维表，那么就要进⾏旋转，等同于⾏列转换。
OLAP 架构分类
为了实现上述操作，将常见的 OLAP 架构⼤致分为三类。
第⼀类架构称为 ROLAP（Relational OLAP，关系型 OLAP），顾名思义，它直接使⽤关系模型构建，数据模型常使⽤星型模型或者雪花模型，这是最先能够想到、也是最为直接的实现⽅法。
星型模型：事实表周围的维度表只能有⼀层；雪花模型：事实表周围的维度表可以有多层。
因为 OLAP 概念在最初提出的时候，就是建⽴在关系型数据库之上的，多维分析的操作可以直接转成 SQL 查询。例如，通过上卷操作查看省份的销售额，就可以转成类似下⾯的 SQL 语句：
SELECT SUM(价格) FROM 销售数据表 GROUP BY 省;
但是这种架构对数据的实时处理能⼒要求很⾼，试想⼀下，如果对⼀张存有上亿条记录的表同时执⾏数⼗个字段的GROUP BY查询，将会发⽣什么事情？
第⼆类架构称为 MOLAP（Multidimensional OLAP，多维型 OLAP），它的出现就是为了缓解 ROLAP 性能问题。
MOLAP 使⽤多维数组的形式保存数据，其核⼼思想是借助预先聚合结果（说⽩了就是提前先算好，然后将结果保存起来），使⽤空间换取时间的形式从⽽提升查询性能。也就是说，⽤更多的存储空间换得查询时间的减少，其具体的实现⽅式是依托⽴⽅体模型的概念。⾸先，对需要分析的数据进⾏建模，框定需要分析的维度字段；然后，通过预处理的形式，对各种维度进⾏组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来（通常只保留聚合后的结果，不存储明细数据），这样⼀来，在随后的查询过程中，可以直接利⽤结果返回数据。
但是这种架构显然并不完美，原因如下：
预聚合只能⽀持固定的分析场景，所以它⽆法满⾜⾃定义分析的需求。
维度的预处理会导致数据膨胀，这⾥可以做⼀次简单的计算，以上⾯的销售明细表为例，如果数据⽴⽅体包含了 5 个维度（字段），那么维度的组合⽅式就有 \(2^{5}\) 种。维度组合爆炸会导致数据膨胀，这样会造成不必要的计算和存储开销。此外，⽤户并不⼀定会⽤到所有维度的组合，那么没有被⽤到的组合将会浪费。
另外，由于使⽤了预聚合的⽅式，数据⽴⽅体会有⼀定的滞后性，不能实时地进⾏数据分析。所以对于在线实时接收的流量数据，预聚合还需要考虑如何及时更新数据。⽽且⽴⽅体只保留了聚合后的结果数据，因此明细数据是⽆法查询的。
第三类架构称为 HOLAP（Hybrid OLAP，混合架构的OLAP），这种思路可以理解成 ROLAP 和 MOLAP 两者的组合，这⾥不再展开，我们重点关注 ROLAP 和 MOLAP。
OLAP 实现技术的演进
在介绍了 OLAP ⼏种主要的架构之后，再来看看它们背后技术的演进过程，我们把这个演进过程划分为两个阶段。
第⼀个可以称为传统关系型数据库阶段。在这个阶段中，OLAP 主要基于以 Oracle、MySQL 为代表
的⼀种关系型数据库实现。在 ROLA P架构下，直接使⽤这些数据作为存储与计算的载体；在 MOLAP 架构下，则借助物化视图的⽅式实现数据⽴⽅体。在这个时期，不论是 ROLAP 还是 MOLAP，在数据体量⼤、维度数⽬多的情况下都存在严重的性能问题，甚⾄存在根本查询不出结果的情况。
第⼆个阶段可以称为⼤数据技术阶段。由于⼤数据技术的普及，⼈们开始使⽤⼤数据技术重构 ROLAP 和 MOLAP。以ROLAP 架构为例，传统关系型数据库就被 Hive 和 SparkSQL 这类新兴技术所取代。虽然，以 Spark 为代表的分布式计算系统，相⽐ Oracle 这类传统数据库⽽⾔，在⾯向海量数据的处理性能⽅⾯已经优秀很多，但是直接把它们作为⾯向终端⽤户的在线查询系统则还是太慢了。我们的⽤户普遍缺乏耐⼼，如果⼀个查询响应需要⼏⼗秒甚⾄数分钟才能返回，那么这套⽅案就完全⾏不通。再看 MOLAP 架构，MOLAP 背后也转为依托 MapReduce 或 Spark 这类新兴技术，将其作为⽴⽅体的计算引擎，进⾏⽴⽅体的构建，其预聚合结构的存储载体也转向 HBase 这类⾼性能分布式数据库。⼤数据技术阶段，主流MOLAP 架构已经能够在亿万级数据的体量下，实现毫秒级的查询，但我们说 MOLAP 架构会存在维度爆炸、数据同步实时性不⾼的问题。
不难发现，虽然 OLAP 在经历了⼤数据技术的洗礼之后，其各⽅⾯性能已经有了脱胎换⾻式的改观，但不论是 ROLAP 还是MOLAP，仍然存在各⾃的痛点。可如果单纯从模型⾓度考虑，很明显 ROLAP 要更胜⼀筹，因为关系型数据库的存在，所以关系模型拥有最好的 "众基础"，也更简单且容易理解。它直接⾯向明细数据查询，由于不需要预处理，也就⾃然没有预处理带来的负⾯影响（维度组合
爆炸、数据实时性、更新问题）。那是否存在这样⼀种技术，它使⽤ ROLAP 模型，但同时⼜拥有⽐肩 MOLAP 的性能呢？
显然是存在的，就是我们今天的主⾓ ClickHouse，有⼀篇性能报告，在 10 亿条测试数据的体量下，Spark 被 ClickHouse 打的落花流⽔。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 倍。
此外 ClickHouse 是⼀款开源软件，遵循 Apache License 2.0 协议，所以它可以被免费使⽤。
ClickHouse 的名字由来：ClickHouse 最初的设计⽬标是为了服务于⾃家公司的⼀款名叫 Metrica 流量分析⼯具。
Metrica 在采集数据的过程中，⼀次页⾯点击（Click），就会产⽣⼀个事件（Event），就是基于页⾯的点击事件流（Stream），然后⾯向数据仓库进⾏ OLAP 分析。所以 ClickHouse 的全称是 Click Stream、Data
WareHouse，简称 ClickHouse。
初识 ClickHouse
随着业务的迅猛增长，Yandex 公司的 Metrica ⽬前已经成为世界第三⼤ Web 流量分析平台，每天处理超过两百亿个跟踪事件，⽽之所以能够有如此惊⼈的体量，在背后为其提供⽀撑的 ClickHouse 功不可没。ClickHouse 已经为 Metrica 存储了超过 20 万亿⾏的数据，百分之 90 的查询能够在 1 秒内返回，其集规模也已经超过了 400 台服务器。虽然 ClickHouse 起初只是为了 Metrica ⽽研发的，但由于它出众的性能，⽬前也被⼴泛应⽤于 Yandex 公司内部的其它数⼗个产品中。
除了 Yandex ⾃⼰以外，ClickHouse 还被众多商业公司或研究组织应⽤到了其⽣产环境。欧洲核⼦研究中⼼（CERN，想起了⽯头门）将它⽤于保存强对撞机试验后所记录的数⼗亿事件的测量数据，并成功将先前的数据查询时间从⼏个⼩时缩短到⼏秒；著名的 CDN 服务⼚商 CloudFlare 将 ClickHouse ⽤于 HTTP 的流量分析；国内的头条、阿⾥巴巴、腾讯和新浪等⼀众互联⽹公司都在应⽤ ClickHouse。
可以说 ClickHouse 具备了⼈们对⼀款⾼性能 OLAP 数据库的美好向往，所以它基本能够胜任各种数据分析类的场景，并且随着数据体量的增⼤，它的优势也会变得越为明显。ClickHouse ⾮常适⽤于商业智能领域，也就是我们所说的 BI 领域。除此之外，它也能够被⼴泛应⽤于⼴告流量、Web、App流量、电信、⾦融、电⼦商务、信息安全、⽹络游戏、物联⽹等众多其它领域。
想必到了这⾥，你是不是产⽣了这样的⼀种错觉呢？ClickHouse 仿佛违背了物理定律，没有任何缺点，是⼀个不真实的存在，⼀款⾼性能、⾼可⽤ OLAP 数据库的⼀切诉求，ClickHouse 都能满⾜。但是估计很多⼈之前都是 Hadoop ⽣态圈的，那么你在转向 ClickHouse 的时候应该会有⼀些不适应，因为它和我们平时使⽤的技术的 "性格" 迥然不同，这是正常现象。如果把数据库⽐作汽车，那么 ClickHouse 俨然就是⼀辆⼿动挡的赛车，它在很多⽅⾯不像其它系统那样⾼度⾃动化。ClickHouse 的⼀些概念也和我们平常理解的有所不同，特别是在分⽚和副本⽅⾯，有些时候数据的分⽚甚⾄需要⼿动完成。但在进⼀步深⼊使⽤ ClickHouse 之后，我们就会渐渐理解这些设计的⽬的，某些看似不⾃动化的设计，在实际使⽤中反⽽带来了极⼤的灵活性。与 Hadoop ⽣态的其它数据库相⽐，ClickHouse 更像是⼀款传统 MPP 架构的列式存储数据库，它没有采⽤ Hadoop ⽣态中常⽤的主从架构，⽽是使⽤了多主对等⽹络结构，同时它也是基于关系模型的 ROLAP ⽅案。
那么下⾯就让我们抽丝剥茧，看看 ClickHouse 都有哪些核⼼特性。
完备的 DBMS 功能
ClickHouse 拥有完备的管理功能，所以它称得上是⼀个 DBMS（DataBase Management System，数据库管理系统），⽽作为⼀个 DBMS，它具备如下功能：
DDL（数据定义语⾔）：可以动态地创建、修改或者删除数据库、表和视图，⽽⽆需重启服务
DML（数据操作语⾔）：可以动态地查询、插⼊、修改或删除数据
权限控制：可以按照⽤户粒度设置数据库或者表的操作权限，保障数据的安全性
数据备份与恢复：提供了数据备份导出与导⼊恢复机制，满⾜⽣产环境的要求
常见mpp数据库分布式管理：提供集模式，能够⾃动管理多个数据库节点
上⾯只列举了⼀些最具代表性的功能，但这已然⾜以表明为什么 ClickHouse 称得上是 DBMS 了。
但是注意，ClickHouse 虽然很优秀，但它毕竟是⼀款⾯向 OLAP 的数据库，我们不能把它⽤于任何 OLTP 事务性操作的场景，因为它有以下⼏点不⾜：
不⽀持事务
不擅长根据主键按⾏粒度进⾏查询（虽然⽀持），所以不应该把 ClickHouse 当做键值对数据库使⽤
不擅长按⾏删除数据（虽然⽀持）
不过这些不⾜并不能算是 ClickHouse 的缺点，事实上其它的同类⾼性能⾯向 OLAP 的数据库⼀样不擅长上⾯这些。因为对于 OLAP 数据库⽽⾔，上述这些能⼒不是重点，只能说这是为了极致的查询性能所做的权衡。
列式存储与数据压缩
列式存储与数据压缩，对于⼀款⾼性能数据库来说是必不可少的特性。⼀个⾮常流⾏的观点认为：如果你想让查询变得更快，最简单且有效的⽅法就是减少数据扫描范围和数据传输时的⼤⼩，⽽列式存储和数据压缩就可以实现上⾯两点。列式存储和数据压缩通常是伴⽣的，因为⼀般来说列式存储是数据压缩的前提。
那什么是列式存储呢？
⾸先列式存储，或者说按列存储，相⽐按⾏存储，前者可以有效减少查询时需要扫描的数据量，我们可以举个栗⼦说明⼀下。假设⼀张数据表 A，⾥⾯有 50 个字段 A1 ~ A50，如果我们需要查询前 5 个字段的数据的话，那么可以使⽤如下 SQL 实现：
SELECT A1, A2, A3, A4, A5 from A;
但是这样问题来了，数据库每次都会逐⾏扫描、并获取每⾏数据的全部字段，这⾥就是 50 个，然后再从中返回前 5 个字段。因此不难发现，尽管只需要前 5 个字段，但由于数据是按⾏进⾏组织的，实际上还是扫描了所有的字段。但如果数据是按列进⾏存储，则不会出现这样的问题，由于数据按列进⾏组织，数据库可以直接选择 A1 ~ A5 这 5 列的数据并返回，从⽽避免多余的数据扫描。为了更好的说明这两者的区别，我们画⼀张图：
如果是按⾏存储的话，那么假设我们要计算 age 这⼀列的平均值，就需要⼀⾏⼀⾏扫描，所以最终会⾄少扫描 11 个值（ 3 + 3 + 3 + 2 ）才能到 age 这⼀列所存储的 4 个值。这意味着我们要花费更多的时间等待 IO 完成，⽽且读完之后还要扔掉很多（因为我们只需要部分字段）。但如果是按列存储的话，我们只需要获取 age 这⼀列的连续快，即可得到我们想要的 4个值，所以这种操作速度更快、效率更⾼。
按列存储相⽐按⾏存储的另⼀个优势是对数据压缩的友好性，同样可以举⼀个栗⼦简单说明⼀下压缩的本质是什么。假设有个字符串 abcdefghi_bcdefghi，现在对它进⾏压缩，如下所⽰：
压缩前：abcdefghi_bcdefghi
压缩后：abcdefghi_(9,8)
可以看到，压缩的本质就是按照⼀定步长对数据进⾏匹配扫描，当发现重复部分的时候就会编码转换。例如上⾯的(9, 8)
，表⽰从下划线开始向前移动 9 个字节，会匹配到 8 个字节长度的重复项，即 bcdefghi。
尽管真实的压缩算法要⽐这个复杂许多，但压缩的本质就是如此。数据中的重复项越多，则压缩率越⾼；压缩率越⾼，则数据体量越⼩；⽽数据体量越⼩，在⽹络中传输的速度则越快，并且对⽹络带宽和磁盘 IO 的压⼒也就越⼩。可怎样的数据最可能具备重复的特性呢？答案是属于同⼀个列字段的数据，因为它们具有相同的数据类型和现实语义，重复项的可能性⾃然就更⾼。
ClickHouse 就是⼀款使⽤列式存储的数据库，数据按列进⾏组织，属于同⼀列的数据会被保存在⼀起，并进⾏压缩，⽽列与列之间的数据也会由不同的⽂件分别保存（这⾥主要是指 MergeTree 引擎，后续会详细介绍）。数据默认使⽤ LZ4 算法压缩，在 Yandex 公司的 Metrica ⽣产环境中，数据整体的压缩⽐可以达到 8 ⽐ 1（未压缩前 17 PB，压缩后 8 PB）。另外列式存储除了降低 IO 和存储的压⼒之外，还为向量化执⾏做好了铺垫。
向量化执⾏引擎
坊间有句玩笑："能⽤ money 解决的问题，千万别花时间"。⽽业界也有种调侃与之如出⼀辙："能升级
硬件解决的问题，千万别优化程序"。有时候，你千⾟万苦优化程序逻辑带来的性能提升，还不如直接升级硬件来的简单直接。这虽然是⼀句玩笑话不能当真，但硬件层⾯的优化确实是最简单粗暴、并且有效的途径之⼀。向量化执⾏就是典型代表，这项寄存器硬件层⾯的特性，为上层应⽤的程序在性能上带来了指数级的提升。
向量化执⾏可以简单地看做成⼀种消除程序中的循环所做的优化，举个栗⼦。假设⼩明在卖果汁，⽽榨⼀杯果汁假设需要 2分钟，有客户抱怨太慢了，那么为了增加速度要怎么办呢？显然多准备⼏台榨汁机就好了，因此⾮向量化执⾏的⽅式是利⽤1 台榨汁机重复 n 次，⽽向量化执⾏的⽅式是利⽤ n 台榨汁机只执⾏ 1 次。
⽽为了实现向量化执⾏，需要利⽤ CPU 的 SIMD 指令。SIMD 的全称是：Single Instruction Multiple Data，即⽤单条指令操作多条数据。现代计算机系统概念中，它是通过数据并⾏以提⾼性能的⼀种实现⽅式（其它的还有指令级并⾏和线程级并⾏），它的原理是在 CPU 寄存器层⾯实现数据的并⾏计算。
在计算机系统的体系结构中，存储系统是⼀种层次结构，典型服务器计算机的存储层次结构如下所⽰：
它们的⼤⼩会根据 CPU 的不同⽽不同，以我之前的个⼈笔记本电脑为例：
从左向右距离 CPU 越近，访问速度就越快，显然能够容纳的数据⼤⼩也就越⼩；别忘了，CPU 寄存器也是可以存储数据的，CPU 从寄存器中获取数据的速度是最快的，是内存的 300 倍，磁盘的 3000 万倍。所以利⽤ CPU 向量化执⾏的特性，对于程序的性能提升有着⾮凡的意义。
ClickHouse ⽬前使⽤ SSE 4.2 指令集实现向量化执⾏。
关系模型与 SQL 查询
相⽐ HBase 和 Redis 这类 NoSQL 数据库，ClickHouse 使⽤关系模型描述数据并提供了传统数据库的概念（数据库、表、视图和函数等）。与此同时，ClickHouse 完全使⽤ SQL 作为查询语⾔（⽀持 GROUP BY、ORDER BY、JOIN、IN 等⼤多数标准 SQL），这使得它平易近⼈，容易理解和学习。因为关系型数据库和 SQL 语⾔，可以说是软件领域发展⾄今应⽤最为⼴泛的技术之⼀，也正因为 ClickHouse 提供了标准协议的 SQL 查询接⼝，使得现有的第三⽅分析可视化系统可以轻松地与它集成对接。⽽在 SQL 解析⽅⾯，ClickHouse 是⼤⼩写敏感的，这意味着 SELECT a 和 SELECT A 所代表的语义是不同的（关键字⾮⼤⼩写敏感）。
关系模型相⽐⽂档模型、键值对模型等等，拥有更好的描述能⼒，也能更加清楚地表⽰实体之间的关系。更重要的是，在OLAP 领域，已有的⼤量数据建模⼯作都是基于关系模型展开的（星座模型、雪花模型和宽表模型）。ClickHouse 使⽤了关系模型，所以将构建在传统关系型数据库或者数仓之上的
系统迁移到 ClickHouse 的成本会变得更低，可以直接沿⽤之前的经验成果。
多样化的表引擎
ClickHouse 并不是直接就⼀蹴⽽就的，Metrica 产品的最初架构是基于MySQL实现的，所以在 ClickHouse 的设计中，能够察觉到⼀些 MySQL 的影⼦，表引擎的设计就是其中之⼀。与 MySQL 类似，ClickHouse 也将存储部分进⾏了抽象，把存储引擎作为⼀层独⽴的接⼝，并且拥有合并树、内存、⽂件、接⼝等 20 多种引擎。其中每⼀种引擎都有着各⾃的特点，⽤户可以根据实际业务场景的需求，选择合适的引擎。
通常⽽⾔，⼀个通⽤系统意味着更⼴泛的实⽤性，能够适应更多的场景。但通⽤的另⼀种解释是平庸，因为它⽆法在所有场景中都做到极致。
在软件的世界中，并不会存在⼀个能够适⽤任何场景的通⽤系统，为了突出某项特性势必会在别处有所取舍。所以将表引擎独⽴设计的好处是显⽽易见的，通过特定的表引擎⽀撑特定的场景，⼗分灵活。对于简单的场景，可直接使⽤简单的引擎降低成本，⽽复杂的场景也有合适的选择。
多线程与分布式
ClickHouse ⼏乎具备现代化⾼性能数据库的所有典型特征，对于可以提升性能的⼿段可谓是全部⽤尽，
对于多线程和分布式这类被⼴泛应⽤的技术⾃然更是不在话下。
如果说向量化执⾏是通过数据级别的并⾏⽅式提升了性能，那么多线程处理就是通过线程级并⾏的⽅式实现了性能提升。相⽐基于底层硬件实现的向量化执⾏ SIMD，线程级并⾏通常由更⾼层次的软件层⾯控制。现代计算机系统早已普及了多处理器架构，所以现今市⾯上的服务器都具备良好的多核⼼多线程处理能⼒。由于 SIMD 不适合⽤于带有较多分⽀判断的场
景，ClickHouse 也⼤量使⽤了多线程技术以实现提速，以此和向量化执⾏形成互补。
如果⼀个篮⼦装不下所以的鸡蛋，就多⽤⼏个篮⼦来装，这就是分布式设计中分⽽治之的思想。同理，如果⼀台服务器性能吃紧，那么就利⽤多台服务的资源协同处理。为了实现这⼀⽬标，⾸先就要在数据层⾯实现数据的分布式，因为在分布式领域，存在着⼀条公认的理论：移动计算优于移动数据。在各服务器之间，通过⽹络传输数据的成本是很⾼的，所以相⽐移动数据，更为聪明的做法是预先将数据分布到各台服务器，将数据的计算查询直接下推到数据所在的服务器。⽽ ClickHouse 在数据存储⽅⾯，既⽀持分区（纵向扩展，利⽤多线程资源），也⽀持分⽚（横向扩展，利⽤分布式原理），可以说是将多线程和分布式的技术应⽤到了极致。
多主架构
HDFS、Spark、HBase 和 Elasticsearch 这类分布式系统，都采⽤了 master-slave 主从架构，由⼀个管控节点作为 Leader 统筹全局，⽽ ClickHouse 则采⽤ multi-master 多主架构，集中的每个节点⾓⾊对等，客户端访问任意⼀个节点都能得到相同的效果。这种多主架构有很多优势，例如对等的⾓⾊使系统架构变得更加简单，不⽤再区分主控节点、数据节点和计算节点，集中的所有节点功能相同。所以它天然规避了单点故障的问题，⾮常适合⽤于多数据中⼼、异地多活的场景。
在线查询
ClickHouse 经常会被拿来与其它的分析性数据库做对⽐，⽐如 Vertica、SparkSQL、Hive 和 Elasticsearch 等，它与这些数

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。