入职以来,一直感慨于腾讯基建之差,平常业务自己CRUD没什么问题,但是一遇到大规模数据计算场景就捉襟见肘,特别是降本增效以来成本抠的很死,以至业务不敢放开手进行数仓建设.但当业务发展到深水区,数仓能力对于业务价值挖掘有着极为重要的意义,故借用本文,以Clickhouse为引子,介绍一下数仓建设的一般过程和技术选型考量.
原文地址: ClickHouse 的基本介绍，什么是 ClickHouse？ – 古明地盆 – 博客园 (cnblogs.com)
最近公司决定采用 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 个维度（字段），那么维度的组合方式就有 2525 种。维度组合爆炸会导致数据膨胀，这样会造成不必要的计算和存储开销。此外，用户并不一定会用到所有维度的组合，那么没有被用到的组合将会浪费。
- 另外，由于使用了预聚合的方式，数据立方体会有一定的滞后性，不能实时地进行数据分析。所以对于在线实时接收的流量数据，预聚合还需要考虑如何及时更新数据。而且立方体只保留了聚合后的结果数据，因此明细数据是无法查询的。
第三类架构称为 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（数据操作语言）：可以动态地查询、插入、修改或删除数据权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求分布式管理：提供集群模式，能够自动管理多个数据库节点
上面只列举了一些最具代表性的功能，但这已然足以表明为什么 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 从寄存器中获取数据的速度是最快的，是内存的 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 等，它与这些数据库确实存在许多相似之处。例如，它们都可以支撑海量数据的查询场景，都拥有分布式架构，都支持列存储、数据分片、计算下推等功能。这其实也说明了 ClickHouse 在设计上吸取了各路奇技淫巧，而与其它数据库相比，ClickHouse 也拥有明显的优势。例如，Vertica 这类商用软件价格高昂；SparkSQL 与 Hive 这类系统无法保障 90% 的查询都能在 1 秒内返回，在大数据量下的复杂查询可能会需要分钟级的响应时间；而 Elasticsearch 这类搜索引擎在处理亿级数据聚合查询时则已经显得捉襟见肘。
正如 ClickHouse 的 “广告词” 所言，其它的开源系统太慢，商用的系统太贵，只有 ClickHouse 在成本与性能之间选择了良好平衡，又快又开源。ClickHouse 当之无愧地阐释了 “在线” 二字的含义，即便是在复杂的查询场景下，它也能够做到极其快速的响应，且无需对数据进行任何预处理加工。
数据分片与分布式查询
数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分之思想的体现。ClickHouse 支持分片，而分片则依赖集群，每个集群可以有一到多个分片，但是注意：一个服务节点只能有一个分片，所以分片的数量取决于节点数量。那么什么是分片呢？往下看。
ClickHouse 并不像其他分布式系统那样，拥有高度自动化的分片功能，ClickHouse 提供了本地表（Local Table）和分布式表（Distributed Table）的概念。一张本地表等同于一份数据的分片，而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
这类设计类似于数据库的分库和分表，十分灵活。例如在业务上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以使用单个节点的本地表（单个数据分片）即可满足业务需求，待到业务增长、数据量增大的时候，再通过新增数据分片的方式分流数据，并通过分布式表实现分布式查询。这就好比一辆手动挡赛车，它将所有的选择权都交给了使用者。
ClickHouse 具有无与伦比的查询速度
ClickHouse 查询速度快我们已经说过了，这里来探讨一下速度快的原因，虽然前面对这个问题已经做出了科学合理的解释，比方说：因为 ClickHouse 是列式存储数据库；ClickHouse 使用了向量化引擎等等。这些解释虽然都站得住脚，但是依然不能消除全部的疑问，因为这些技术不是什么秘密，市面有很多数据库同样使用了这些技术，但是依然没有 ClickHouse 这么快，因此我们需要从另外一个角度来探讨一番 ClickHouse 的秘诀到底是什么？
首先抛出一个疑问：在设计软件架构的时候，做设计的原则应该是自顶向下地去设计，还是自底向上地去设计呢？在传统的观念中，自然是自顶向下的设计，因为在做什么事情的一定先有一个大纲，然后再慢慢实现细节。而 ClickHouse 的设计则采用了自底向上的方式，因为它的原型早在 2008 年就诞生了，在诞生之处它并没有宏伟的规划。相反它的目的很单纯，就是希望能以最快的速度进行 GROUP BY 查询和过滤，那么战斗民族的攻城狮们是如何实现自底向上的设计呢？
着眼硬件，先想后做
首先从硬件功能层面着手设计，在设计伊始就至少需要想清楚如下几个问题：
将要使用的硬件水平是怎样的？包括 CPU、内存、硬盘、网络等等在这样的硬件上，需要达到怎样的性能？包括延迟、吞吐量等等准备使用怎样的数据结构？包括 String、HashTable、Vetcor 等等选择这样的数据结构，在硬件上会如何工作？
如果能想清楚上面这些问题，那么在动手实现功能之前，就已经能够计算出粗略的性能了。所以，基于将硬件功效最大化的目的，ClickHouse 会在内存中进行 GROUP BY，并且使用 HashTable 装载数据。与此同时，攻城狮们非常在意 CPU L3 级别的缓存，因为一次 L3 的缓存失效将会带来 700~100ns 的延迟，这意味着在单核 CPU 上，它会浪费每秒 4000 万次的运算；而在一个 32 线程的 CPU 上，将会浪费每秒 5 亿次的运算。所以别小看这些细节，一点一滴地将它们累加起来，数据是非常可观的。正是因为注意这些细节，ClickHouse 在基准查询中才能做到每秒 1.75 亿次的数据扫描性能。
算法在前，抽象在后
常有人念叨：”有时候选择比努力更重要”，确实，路线选错了的话再努力也是白搭。在 ClickHouse 的底层实现中，经常会面对一些重复的场景，例如字符串子串查询、数据排序、使用 HashTable 等，如何才能实现性能的最大化呢？算法的选择就变成了重中之重。以字符串为例，有一本专门讲解字符串搜索的书，里面列举了 35 种常见的字符串搜索算法，那么你猜猜 ClickHouse 使用了里面的哪种算法呢？答案是一种都没有，因为性能不够快，在字符串搜索方面，针对不同的场景，ClickHouse 最终选择了这些算法：对于常量，使用 Volnitsky 算法；对于非常量，使用 CPU 的向量化执行 SIMD，暴力优化；正则匹配使用 re2 和 hyperscan 算法。
性能是算法选择的首要考量指标。
用于尝鲜，不行就换
除了字符串之外，其余的场景也与它类似，ClickHouse 会使用最合适、最快的算法。如果市面上出现了号称性能最强大的新算法，那么 ClickHouse 团队就会立即将其纳入并进行验证。如果效果不错就保留使用，不尽人意的话就将其丢弃。
特定场景，特殊优化
针对同一个场景的不同状况，选择使用不同的实现方式，尽可能将性能最大化。关于这一点，其实在前面介绍字符串查询的时候，针对不同场景选择不同算法的思路就有所体现了。
类似的例子还有很多，例如去重计数 uniqCombined 函数，会根据数据量的不同选择不同的算法；当数据量很小的时候，会选择使用 Array 保存；当数据量中等的时候，会选择 HashSet；而当数据量很大的时候，则使用 HyperLogLog 算法。
对于数据结构化比较清晰的场景，会通过代码生成技术实现循环展开，以减少循环次数。接着就是大家熟知的大杀器 “向量化执行”。SIMD 被广泛地应用于文本转换、数据过滤、数据解压和 JSON 转换等场景。相较于单纯地使用 CPU，利用寄存器暴力优化也算是一种降维打击了。
持续测试，持续改进
如果只是单纯地在上述细节上下功夫，还不足以构建出如此强大的 ClickHouse，因此还需要一个能够持续验证、持续改进的机制。由于 Yandex 公司的天然优势，ClickHouse 经常使用真实的数据进行测试，这一点很好地保证了测试场景的真实性。与此同时，ClickHouse 算是更新速度最快的开源软件了，差不多每个月都能发布一个版本，没有一个可靠的持续集成环境，这一点是做不到的。正因为拥有这样的频率，ClickHouse 才能快速迭代、快速改进。
所以 ClickHouse 的黑魔法并不是一项单一的技术，而是一种自底向上的、追求极限性能的设计思路，这就是它如此块的秘诀。