1. BI系统的沉浮
1.1 传统BI之死
为了解决传统早期IT系统在建设过程中“烟囱式”的发展模式，打通相互割裂的“数据孤岛”，让用户拥有站在企业全局鸟瞰一切数据的视角，BI(商业智能)系统的概念在20世纪90年代被提出，即一种统一面向数据仓库，专注于提供数据分析、决策类功能的系统与解决方案。人们通常用BI一词指代这类分析系统。相对于联机事务处理系统(OLTP)，我们把这类BI系统称为联机分析(OLAP)系统。
但是传统BI系统的实际的应用效果一直是差强人意。其原因至少有一下几点。
- 对企业的信息化和数据化水平要求较高。需要企业有完善的信息化系统和统一的数据化仓库来作为技术支持，否者难以实现“站在企业视角通盘分析并辅助决策"的定位。
- 狭小的受众制约了传统BI系统发展的生命力。如果主要受众是企业中的管理和决策层，这些人虽然有较高的话语权于系统的参与度和使用度不高，久而久之BI系统就沦为了领导视察、演示的“特供玩具”。
- 冗长的研发过程滞后了需求的响应时效。传统BI系统多为定制开发，需要大量IT人员的参与。一个分析Idea从需求的提出到最终实现，可能需要几周甚至几个月的时间，滞后性严重影响体验。
1.2 互联网大潮下的BI系统新生
互联网和云原生SaaS化模式的兴起，为BI系统的商业模式带来了新的思路:
首先，部署“轻量级化”，即不再需要强制捆绑于企业数据仓库这样的庞然大物之上进行数据同步，可以对于多种数据源直连即用。
其次，使用“多元化”，即使用门槛降低，不需要IT人员的深度参与，用户直接通过自助的形式，通过简单拖拽、搜索就能得到自己想要的分析结果，而不用关心底层具体的实现方式和数据源类型。
最后，体验“互联网化”，即便现代BI系统必须具有快速应答、简单易用的使用体验。从某种角度来看，经过SaaS化这波技术普惠的洗礼，互联网帮助传统企业系统在易用性和用户体验上进行了革命性提升。
如果说互联网和SaaS化这波技术普惠为现代BI系统带来了新的思路与契机，那么背后的技术创新则保障了其思想的落地。
Google于2003~2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”，将大数据的处理技术带进了大众视野。2006年开源项目Hadoop最初指代的是分布式文件系统HDFS和MapReduce计算框架，但是它一路高歌猛进，在此基础之上像搭积木一般快速发展成为一个庞大的生态(包括Yarn、Hive、 HBase、Spark等数十种之多)。在大量数据分析场景的解决方案中， 传统关系型数据库很快就被Hadoop生态所取代。数据查询分析的手段也层出不穷，Spark、 Impala、Kylin等百花齐放。
然而世间并没有万全之策， 虽然Hadoop生态化的属性带来了诸多便利性，但生态化的另一面是臃肿和复杂。Hadoop生态下的每种组件都自成一体、相互独立的格局显很多场景下都过于笨重了。与此同时，随着现代化终端系统对实效性的要求越来越高，Hadoop在海量数据和高时效性的双重压力下，也显得有些力不从心了。
探索式BI的方向
探索式BI系统，在产品定位与设计上是带有互联网SaaS化属性的产品，期望其包括以下特性：
- 更统一：统一的数据门户，管理核心指标和口径。部门内下至数百条数据的个人Excel表格，上至数亿级别的企业数据，都能够在系统内部被直接处理；统一权限管理，降低管理的复杂度，提升数据安全性。统一数据运维，确保系统稳定性。
- 更易用：面向普通用户而非专业IT人员，通过简单拖拽或搜索维度，就能完成初步的分析查询。分析内容可以是自定义 的，并不需要预先固定好。
- 更实时：无论数据是什么体量级别，查询必须在秒级时间内返回。数据分析是一个通过不断提出假设并验证假设的过程，只有做到快速应答，这种分析过程的路径才算正确，这也是”探索式“BI的最大的特点。
- 更专业：需要具备专业化程度并具备智能化的提升空间，需要提供专业的数学统计方法和可视化组件。
为了满足上述产品特性，开发人员在底层数据库技术选型的时候可谓是绞尽脑汁，尽最大可能来选择合适OLAP技术方案。
OLPA演进之路
OLAP领域技术发展至今可谓百花齐放，但是Mars团队在技术调研后却发现可能要面临无牌可打的窘境。为了解释这个问题，就要先说清楚OLAP的几种常见思路。
OLAP名为联机分析，又可以称为多维分析。 顾名思义，它指的是通过多种不同的维度审视数据，进行深层次分析。维度可以看作观察数据的一种视角，例如人类能看到的世界是三维的，它包含长、宽、高三个维度。直接一点理解，维度就好比是一张数据表的字段，而多维分析则是基于这些字段进行聚合查询。
可以使用一个立方体的图像具象化操作，如上图所示， 对于一张销售明细表，数据立方体可以进行如下操作。
- 下钻：从高层次向低层次明细数据穿透；
- 上卷：和下钻相反，从低层次向高层次汇聚；
- 切片：观察立方体的一层，将一个或多个维度设为单个固定值， 然后观察剩余的维度；
- 切块：与切片类似，只是将单个固定值变成多个值。例如将商品 维度固定成“足球”“篮球”和“乒乓球”；
- 旋转：旋转立方体的一面，如果要将数据映射到一张二维表，那么就要进行旋转，这就等同于行列置换。
为了实现上述这些操作，将常见的OLAP架构大致分成三类。
第一类架构称为ROLAP(Relational OLAP，关系型OLAP)。它直接使用关系模型构建，数据模型常使用星型模型或者雪花模型。这是最先能够想到，也是最为直接的实现方法。因为OLAP概念在最初提出的时候，就是建立在关系型数据库之上的。多维分析的操作可以直接转换成SQL查询。例如，通过上卷操作查看省份的销售额，就可以转换成类似下面的SQL语句:
select 地区, sum(价格) from Cube group by 地区；
但是这种架构对数据的实时处理能力要求很高。如果对一张存有上亿行数据的数据表同时执行数十个字段的GROUP BY查询，一般的关系型数据库是难以承受的。
第二类架构称为MOLAP(Multidimensional OLAP，多维型 OLAP)。它的出现是为了缓解ROLAP性能问题。MOLAP使用多维数组的形式保存数据，其核心思想是借助预先聚合结果，用更多的存储空间换得查询时间的减少。其具体的实现方式是依托立方体模型的概念：首先， 对需要分析的数据进行建模，框定需要分析的维度字段；然后通过预处理的形式，对各种维度进行组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来(通常只保留聚合后的结果，不存储明细数据)。这样一来，在随后的查询过程中，就可以直接利用结果返回数据。
但是这种架构也并不完美。维度预处理可能会导致数据膨胀。当维度数据基数较高的时候(高基数意味着重复相同的数据少)，其立方体预聚合后的数据量可能会达到10到20倍的膨胀。另外，由于使用了预处理的形式，数据立方体会有一定的滞后性，不能实时进行数据分析。而且，立方体只保留了聚合后的结果数据，导致无法查询明细数据。
第三类架构称为HOLAP(Hybrid OLAP，混合架构的OLAP)。这种思路可以理解成ROLAP和MOLAP两者的集成，即预先聚合一些维度，然后在此基础上再试试聚合计算，算是一种折中的办法。
在介绍了OLAP几种主要的架构之后，再回来说说Mars技术选项。
第一种选项称为传统关系型数据库。在这种选择里，OLAP主要基于以MySQL为数据实现。在ROLAP架构下，直接使用这些数据库作为存储与计算的载体；在MOLAP架构下，则借助物化视图的形式实现数据立方体。在这个时期，不论是 ROLAP还是MOLAP，在数据体量大、维度数目多的情况下都存在严重的性能问题。在Mars项目实战的场景中，在数据量超过80W行后，在KDB上所搭建的Mysql集群需要30s以上才能响应结果，根本无法使用。
第二种选择为大数据技术。以ROLAP架构为例，传统关系型数据库就被Hive和SparkSQL所取代。以Spark相比MySQL这类传统数据库而言，在面向海量数据的处理上性能要优秀很多，但是它更适合作为一个后端的查询系统，在实时性上还是太差，动辄几十秒甚至数分钟的响应时间，难以满足用户需求。再看MOLAP架构，MOLAP背后也转为依托MapReduce或Spark等技术，将其作为立方体的计算引擎，加速立方体的构建过程。其预聚合结果的存储载体也转向HBase这类高性能分布式数据库。主流MOLAP架构已经能够在亿万级数据的体量下实现毫秒级的查询响应时间。尽管如此，MOLAP架构依然存在维度爆炸、数据同步实时性不高的问题。
总结而言，以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据，但无法真正做到实时应答和高并发；而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题，能够做到实时应答，但数据膨胀和预处理等问题依然没有被很好解决。不难发现，虽然OLAP在经历了大数据技术的洗礼之后，其各方面性能已经有了脱胎换骨式的改观，但不论是ROLAP还是MOLAP，仍然存在各自的痛点。
其实，除了上述两类方案之外，也有一种另辟蹊径的选择，即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询，ElasticSearch是这类方案的代表。ElasticSearch支持实时更新，在百万级别数据的场景下可以做到实时聚合查询，但是随着数据体量的继续增大，它的查询性能也将无法保证。
如果单纯从模型角度考虑，很明显ROLAP架构更胜一筹。因为关系模型拥有最好的“群众基础”，也更简单且容易理解。它直接面向明细数据查询，由于不需要预处理，也就自然没有预处理带来的负面影响(维度组合爆炸、数据实时性、更新问题)。
那是否存在这样一种技术，它既使用ROLAP模型，同时又拥有比肩MOLAP的性能呢? 答案就是Clickhouse
Clickhouse的横空出世
ClickHouse 是一个用于联机分析 (OLAP) 的列式数据库管理系统 (DBMS)。来俄罗斯本土搜索引擎企业Yandex 公司， 诞生之初就是为了服务 Yandex 公司自家的 Web 流量分析产品 Yandex.Metrica，后来经过演变，逐渐形成为现在的 ClickHouse，全称是:Click Stream, Data WareHouse。
ClickHouse官网:https://clickhouse.tech/，其具有 ROLAP、在线实时查询、完整的 DBMS 功能支持、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的 SQL 持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用等许多特点。
更让笔者印象深刻的是其查询能力。在 1 亿数据集体量的情况下，ClickHouse 的平均响应速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的 429 倍以及Greenplum 的 10 倍。详细的测试结果可以查阅：https://clickhouse.tech/benchmark/dbms/。
ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析(OLAP)领域。目前国内社区火热，各个大厂纷纷跟进大规模使用:
今日头条内部用 ClickHouse 来做用户行为分析，内部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据 300TB 左右。
腾讯内部用 ClickHouse 做游戏数据分析，并且为之建立了一整套监控运维体系。
携程内部从 18 年 7 月份开始接入试用，目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查询请求。
快手内部也在使用 ClickHouse，存储总量大约 10PB， 每天新增 200TB， 90% 查询小于 3S。
正如上文所述，“世间没有万全策”。ClickHouse作为一款高性能OLAP数据库，虽然足够优秀，但也不是万能的。我们不应该把它用于任何OLTP事务性操作的场景，因为它有以下几点不足：
- 不支持事务。
- 为稀疏索引，不擅长根据主键按行粒度进行查询(虽然支持)，故不应该把ClickHouse当作Key-Value数据库使用。
- 缺少高频率，低延迟的修改或删除已存在数据的能力。
这些弱点并不能视为ClickHouse的缺点，事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。
BI与Clickhouse的一拍即合
ClickHouse非常适用于商业智能领域(也就Mars所在的BI领域)，是因为在这个BI分析的场景下，ClickHouse的缺点都可以被规避：
- BI分析场景多为海量数据集中的高性能低延迟的单表单张大宽表聚合查询分析，不关心数据的事务性；
- BI分析场景绝大部分场景都是范围聚合，极少按主键获取单行数据；
- BI分析分析不会去主动删除数据，不关心删除数据的性能；
正因Clickhouse拥有ROLAP的标准SQL模型，同时又拥有超越MOLAP的极强查询性能，正好符合探索式BI的产品目标。在Clickhouse的助力下，可以实现基于RLOAP的实时数据分析，成功突破数据查询能力瓶颈。根据笔者试验，使用阿里云g5规格云服务器（2vCPUs & 8 GB），便可实现如下计算能力：
- 对于8000W行的数据规模，任意维度的聚合查询可以在4s内返回，使用索引和过滤可以在1秒以内返回；
- 对于2亿行的数据规模，任意维度的聚合查询可以在9s内返回，使用索引和过滤可以在3秒以内返回；
后续笔者将会继续介绍Clickhouse架构设计，为大家揭秘其性能突出原因，以及mars上数据查询的实战内容，敬请期待。