1.5 一匹横空出世的黑马

我从2012年正式进入大数据领域，开始从事大数据平台相关的基础研发工作。2016年我所在的公司启动了战略性创新产品的规划工作，自此我开始将工作重心转到设计并研发一款具备现代化SaaS属性的BI分析类产品上。为了实现人人都是分析师的最终目标，这款BI产品必须至少具备如下特征。

❑ 一站式：下至数百条数据的个人Excel表格，上至数亿级别的企业数据，都能够在系统内部被直接处理。

❑ 自服务，简单易用：面向普通用户而非专业IT人员，通过简单拖拽或搜索维度，就能完成初步的分析查询。分析内容可以是自定义的，并不需要预先固定好。

❑ 实时应答：无论数据是什么体量级别，查询必须在毫秒至1秒内返回。数据分析是一个通过不断提出假设并验证假设的过程，只有做到快速应答，这种分析过程的路径才算正确。

❑ 专业化、智能化：需要具备专业化程度并具备智能化的提升空间，需要提供专业的数学方法。

为了满足上述产品特性，我们在进行底层数据库技术选型的时候可谓是绞尽脑汁。上文曾提及，以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据，但无法真正做到实时应答和高并发，它更适合作为一个后端的查询系统。而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题，能够做到实时应答，但数据膨胀和预处理等问题依然没有被很好解决。除了上述两类方案之外，也有一种另辟蹊径的选择，即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询，ElasticSearch是这类方案的代表。ElasticSearch支持实时更新，在百万级别数据的场景下可以做到实时聚合查询，但是随着数据体量的继续增大，它的查询性能也将捉襟见肘。

难道真的是鱼与熊掌不可兼得了吗？直到有一天，在查阅一份Spark性能报告的时候，我不经意间看到了一篇性能对比的博文。Spark的对手是一个我从来没有见过的陌生名字，在10亿条测试数据的体量下，Spark这个我心目中的绝对王者，居然被对手打得落花流水，查询响应时间竟然比对手慢数90%之多。而对手居然只使用了一台配有i5 CPU、16GB内存和SSD磁盘的普通PC电脑。我揉了揉眼睛，定了定神，这不是做梦。ClickHouse就这样进入了我的视野。