嘿科技在这里|现代BI系统有哪些问题？如何解决？，从Hadoop到ClickHouse( 三 ) 导读：一次机缘巧合

虽然Hadoop生态化的属性带来了诸多便利性，例如分布式文件系统HDFS可以直接作为其他组件的底层存储（例如HBase、Hive等），生态内部的组件之间不用重复造轮子，只需相互借力、组合就能形成新的方案。
但生态化的另一面则可以看作臃肿和复杂。 Hadoop生态下的每种组件都自成一体、相互独立，这种强强组合的技术组件有些时候显得过于笨重了。与此同时，随着现代化终端系统对实效性的要求越来越高， Hadoop在海量数据和高时效性的双重压力下，也显得有些力不从心了。

文章图片
03一匹横空出世的黑马
我从2012年正式进入大数据领域，开始从事大数据平台相关的基础研发工作。 2016年我所在的公司启动了战略性创新产品的规划工作，自此我开始将工作重心转到设计并研发一款具备现代化SaaS属性的BI分析类产品上。为了实现人人都是分析师的最终目标，这款BI产品必须至少具备如下特征。
一站式：下至数百条数据的个人Excel表格，上至数亿级别的企业数据，都能够在系统内部被直接处理。自服务，简单易用：面向普通用户而非专业IT人员，通过简单拖拽或搜索维度，就能完成初步的分析查询。分析内容可以是自定义的，并不需要预先固定好。实时应答：无论数据是什么体量级别，查询必须在毫秒至1秒内返回。数据分析是一个通过不断提出假设并验证假设的过程，只有做到快速应答，这种分析过程的路径才算正确。专业化、智能化：需要具备专业化程度并具备智能化的提升空间，需要提供专业的数学方法。为了满足上述产品特性，我们在进行底层数据库技术选型的时候可谓是绞尽脑汁。
以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据，但无法真正做到实时应答和高并发，它更适合作为一个后端的查询系统。而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题，能够做到实时应答，但数据膨胀和预处理等问题依然没有被很好解决。
除了上述两类方案之外，也有一种另辟蹊径的选择，即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询， ElasticSearch是这类方案的代表。 ElasticSearch支持实时更新，在百万级别数据的场景下可以做到实时聚合查询，但是随着数据体量的继续增大，它的查询性能也将捉襟见肘。
难道真的是鱼与熊掌不可兼得了吗？直到有一天，在查阅一份Spark性能报告的时候，我不经意间看到了一篇性能对比的博文。
Spark的对手是一个我从来没有见过的陌生名字，在10亿条测试数据的体量下， Spark这个我心目中的绝对王者，居然被对手打得落花流水，查询响应时间竟然比对手慢数90%之多。而对手居然只使用了一台配有i5CPU、16GB内存和SSD磁盘的普通PC电脑。
我揉了揉眼睛，定了定神，这不是做梦。 ClickHouse就这样进入了我的视野。

文章图片
1.天下武功唯快不破
我对ClickHouse的最初印象极为深刻，其具有ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用等许多特点。
特别是它那夸张的查询性能，我想大多数刚接触ClickHouse的人也一定会因为它的性能指标而动容。在一系列官方公布的基准测试对比中， ClickHouse都遥遥领先对手，这其中不乏一些我们耳熟能详的名字。
所有用于对比的数据库都使用了相同配置的服务器，在单个节点的情况下，对一张拥有133个字段的数据表分别在1000万、1亿和10亿三种数据体量下执行基准测试，基准测试的范围涵盖43项SQL查询。