导读：本文介绍几个知名数仓技术及其核心思路。
Hive是一个基于HDFS（Hadoop Distributed File System , Hadoop分布式文件系统）的数仓系统，可以将存储在HDFS之上的文件进行结构化解析，并向用户提供使用SQL操作Hadoop的能力。由于Hive构建在基于HDFS和Spark/MapReduce的系统之上，使得Hive具备了理论上近乎无限的大数据处理能力，因此Hive迅速在业界占据主导地位，在其巅峰时期，Hive+SparkSQL就是大数据系统的标配。Hive使用的是中间件思路，构建在Hadoop的组件之上。
Hive本质是一个元数据系统，由于自身没有存储和计算引擎，因此Hive无法单独使用，必须配合HDFS+Spark/MapReduce，才能完成整个数仓的功能。甚至Hive的元数据存储都借助了MySQL等关系型数据库。这样的架构设计使得Hive成为事实上的Hadoop中间件系统，在大数据早期阶段存在着如下非常重要的意义。
降低了Hadoop的技术门槛。
提高了Hadoop的使用效率。
投入产出比高。
随着技术的进步，Hadoop本身的问题越来越突出，使得Hive成为整个系统的瓶颈，这时候Hive的一些问题也随之暴露，主要体现在以下几点。
安装运维困难：安装Hive需要同时安装更多的组件、易出现单点故障等。
受限于底层HDFS：小文件问题、不支持更新等。
-
受限于底层计算引擎：计算效率太低，延迟高无法支撑即席查询等。
在ClickHouse技术尚未出现的年代，使用Hive需要同时配备非常庞大的大数据平台，这使得传统烟囱式数据开发模型由于成本原因无法在大数据时代早期广泛应用，因此出现了数据中台的概念。建设数据中台的一个重要原因是技术的不成熟使得大数据应用成本非常高，企业没有建设多个大数据平台的动力，需要尽可能降低建设和维护成本，这就需要将所有数据整合到“大中台小前台”的架构中，并由此诞生了一大批数据中台的公司，极大地推动了产业的发展和技术的应用。
烟囱式的数据开发模式在数据中台时代被视为洪水猛兽，应该绝对避免。当然这个观点在数据中台时代是正确的。随着大数据技术的成熟，使用全新技术的烟囱式数据开发模式其实也有着数据中台无法比拟的优势——成本低、研发快、架构灵活。这更体现出了计算机科学中的一个经典理论——没有银弹。作为架构师，应该理性平等地分析每个架构的优点和缺点来找到最合适的架构，而不是找到正确的架构。
和Hive类似，HBase也是建立在HDFS之上的NoSQL数据库。和Hive不同的是，HBase实现了自己的存储引擎，避开了HDFS低性能的缺陷，获得了非常高的吞吐能力。由于HBase远比Hive高的性能，因此在大数据的早期，部分场景也会将HBase当成数据仓库来使用。
HBase采用重新设计的存储引擎解决了一些数仓的技术瓶颈。HBase的存储引擎是面向NoSQL设计的，由于无法真正完整地实现SQL的能力，因此除了少部分不需要强大SQL能力的场景之外，HBase的使用非常有限。HBase的出现也有着非常重要的意义。
证明了基于低效的HDFS也能设计出相对高性能的系统。
弥补了Hive无法支持实时场景的缺陷。
-
填补了大数据系统即席查询的空白，扩充了大数据的应用场景.
Kylin是一个多维OLAP数仓。前文提到Hive的查询延迟很高，尤其在复杂的多维分析中显得格外明显，难以满足某些实时场景下的查询需求。Hbase虽然可以解决一部分场景下的高延迟问题，但因为不支持SQL特性，所以也无法支持复杂的多维分析。
Kylin就是在这样的背景下应运而生。Kylin的基本原理是复杂的多维分析查询速度慢，那就提前计算好结果保存到HBase中，即可在需要时快速得出结果。Kylin采用将复杂计算前置的思路，降低了复杂计算的延迟。从本质上看，可以认为Kylin也是一个大数据中间件。Kylin也面临着如下一些挑战。
维度爆炸：Kylin的本质上是将计算前置，由于很难事先预测需要组合维度，因此只能进行穷举。这种穷举的方式面临着维度爆炸的风险。
数据实时性弱：由于Kylin存在预计算过程，新的数据必须经过预计算才能被检索到，因此Kylin本质上只是解决了实时查询的问题，没有解决数据无法实时响应的缺陷。
资源浪费：由于预计算的结果并不一定会被使用，因此可能存在资源浪费的现象。
-
指标逃逸：所需的数据未被预计算，这种情况需要重新使用Spark/MapReduce进行计算。
以上介绍了三款常用的数据仓库及其核心思路，这三种数仓分别采用了三种不同的思路来实现大数据下的数据仓库。而其他的数仓，大多也是采用其中的一种或几种思路，例如Greenplum采用的是Hive类似的中间件思路，只不过其底层数据库是PostgreSQL而不是Hive的Hadoop。ClickHouse则是采用类似HBase的思路，以极限单机性能为目标，重新设计了存储引擎和计算引擎。
本文摘编自《ClickHouse性能之巅：从架构设计解读性能之谜》，经出版方授权发布。（书号：9787111716587）转载请保留文章出处。
推荐语：滴普合伙人兼首席架构师/资深ClickHouse专家撰写，从架构剖析ClickHouse底层逻辑，总结大量性能调优方法。