ClickHouse系列-前世今生

1 BI系统: BI（商业智能）系统的概念。企业在生产经营的过程中，并不是只关注诸如流程审批、数据录入和填报这类工作。站在监管和决策层面，还需要另一种分析类视角，例如分析报表、分析决策等。定位是站在企业视角通盘分析并辅助决策的，所以如果企业的信息化水平不高，基础设施不完善，想要实施BI系统根本无从谈起。

2 数据仓库: 通过引入一个专门用于分析类场景的数据库，将分散的数据统一汇聚到一处。(解决数据孤岛问题)。

3 OLAP: 联机分析，又可以称为多维分析，由关系型数据库之父埃德加·科德（Edgar Frank Codd）于1993年提出的概念。顾名思义，它指的是通过多种不同的维度审视数据，进行深层次分析。维度可以看作观察数据的一种视角，例如人类能看到的世界是三维的，它包含长、宽、高三个维度。直接一点理解，维度就好比是一张数据表的字段，而多维分析则是基于这些字段进行聚合查询。

4 现代BI系统
特点:
4.1 SaaS模式扩展受众
4.2 受众多元化
4.3 传统的BI系统使用的是OLTP数据库,为了解决海量数据分析查询的性能问题,使用Hadoop生态为代表的非传统关系数据库技术(BI典型的应用场景是多维分析,某些时候可以用OLAP指代这类场景)

5 OLAP常见的架构分类
多维分析通常都包含哪些基本操作呢?

• 下钻：从高层次向低层次明细数据穿透。例如从“省”下钻到“市”，从“湖北省”穿透到“武汉”和“宜昌”。

• 上卷：和下钻相反，从低层次向高层次汇聚。例如从“市”汇聚成“省”，将“武汉”“宜昌”汇聚成“湖北”。

• 切片：观察立方体的一层，将一个或多个维度设为单个固定值，然后观察剩余的维度，例如将商品维度固定为“足球”。

• 切块：与切片类似，只是将单个固定值变成多个值。例如将商品维度固定成“足球”“篮球”和“乒乓球”。

• 旋转：旋转立方体的一面，如果要将数据映射到一张二维表，那么就要进行旋转，这就等同于行列置换。

  5.1 ROLAP（Relational OLAP，关系型OLAP）。它直接使用关系模型构建，数据模型常使用星型模型或者雪花模型。OLAP概念在最初提出的时候，就是建立在关系型数据库之上的。多维分析的操作，可以直接转换成SQL查询。例如，通过上卷操作查看省份的销售额，就可以转换成类似下面的SQL语句：SELECT SUM（价格）FROM 销售数据表 GROUP BY 省

  5.2 MOLAP（Multidimensional OLAP，多维型OLAP）。它的出现是为了缓解ROLAP性能问题。MOLAP使用多维数组的形式保存数据，其核心思想是借助预先聚合结果，使用空间换取时间的形式最终提升查询性能。也就是说，用更多的存储空间换得查询时间的减少。其具体的实现方式是依托立方体模型的概念。首先，对需要分析的数据进行建模，框定需要分析的维度字段；然后，通过预处理的形式，对各种维度进行组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来（通常只保留聚合后的结果，不存储明细数据）。这样一来，在随后的查询过程中，就可以直接利用结果返回数据。
  维度预处理可能会导致数据的膨胀。如果数据立方体包含了5个维度（字段），那么维度组合的方式则有2^5 （2^n ，n=维度个数）个。一张千万级别的数据表，就有可能膨胀到亿级别的体量。
  其预聚合结果的存储载体也转向HBase这类高性能分布式数据库。大数据技术阶段，主流MOLAP架构已经能够在亿万级数据的体量下，实现毫秒级的查询响应时间。尽管如此，MOLAP架构依然存在维度爆炸、数据同步实时性不高的问题。
  5.3 HOLAP（Hybrid OLAP，混合架构的OLAP）。这种思路可以理解成ROLAP和MOLAP两者的集成。

6 ClickHouse 特点: ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用等。同时ClickHouse是一款开源软件，遵循Apache License 2.0协议，所以它可以被免费使用。它的开源社区也非常活跃

7 ClickHouse的发展历程
ClickHouse背后的研发团队是来自俄罗斯的Yandex公司。这是一家俄罗斯本土的互联网企业，于2011年在纳斯达克上市，它的核心产品是搜索引擎。

• MySQL时期
  使用了MyISAM表引擎
• Metrage时期
  首先，在数据模型层面，它使用Key-Value模型（键值对）代替了关系模型；其次，在索引层面，它使用LSM树代替了B+树；最后，在数据处理层面，由实时查询的方式改为了预处理的方式。随着时间的推移，这种固定化的分析形式早已不能满足用户的诉求，Metrage系统却无法满足这类自定义的分析场景
• OLAPServer时期
  专门处理自定义报告这类临时性分析需求的系统，与Metrage系统形成互补的关系。数据模型方面，它又换回了关系模型，因为相比Key-Value模型，关系模型拥有更好的描述能力。使用SQL作为查询语言，也将会拥有更好的“群众基础”。而在存储结构和索引方面，它结合了MyISAM和LSM树最精华的部分。在存储结构上，它与MyISAM表引擎类似，分为了索引文件和数据文件两个部分。在索引方面，它并没有完全沿用LSM树，而是使用了LSM树所使用到的稀疏索引。在数据文件的设计上，则沿用了LSM树中数据段的思想，即数据段内数据有序，借助稀疏索引定位数据段。在有了上述基础之后，OLAPServer又进一步引入了列式存储的思想，将索引文件和数据文件按照列字段的粒度进行了拆分，每个列字段各自独立存储，以此进一步减少数据读取的范围。
  新的难题:
  （1）由于预先聚合只能支持固定的分析场景，所以它无法满足自定义分析的需求。
  （2）维度组合爆炸会导致数据膨胀，这样会造成不必要的计算和存储开销。因为用户并不一定会用到所有维度的组合，那些没有被用到的组合将会成为浪费的开销。
  （3）流量数据是在线实时接收的，所以预聚合还需要考虑如何及时更新数据。
• ClickHouse时代

8 ClickHouse适用的场景
适用于商业智能领域（也就是我们所说的BI领域），除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

9 ClickHouse不适用的场景
不应该把它用于任何OLTP事务性操作的场景，因为它有以下几点不足。

1. 不支持事务。
2. 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
3. 不擅长按行删除数据（虽然支持）。

10 有谁在使用ClickHouse
欧洲核子研究中心（CERN）将它用于保存强对撞机试验后记录下的数十亿事件的测量数据，并成功将先前查找数据的时间由几个小时缩短到几秒。著名的CDN服务厂商CloudFlare将ClickHouse用于HTTP的流量分析。国内的头条、阿里、腾讯和新浪等一众互联网公司对ClickHouse也都有涉猎。