究竟是什么让Redshift比Hive快10倍

Question

如题所述

Answer 1

　　究竟是什么原因产生了如此悬殊的速度，有网友在Quora上提出了这个问题，并得到了Reynold Xin的解答：

　　Redshift采用了专有的叫做ParAccel的并行数据库实现机制。我想在很多工作情境中，你会发现大多数并行数据库引擎要比Hive快。接下来，我将给出答案，并解释其中的某些原因。请注意的是，虽然该答案针对的是ParAccel，其中的大部分因素也适用于Vertica、Greenplum、OracleRAC等并行数据库。

　　在答案中呢，我将使用三个可互换的术语“并行数据库”、“关系型数据库”和“分析型数据库”。

　　比起并行数据库，Hive在可扩展性、灵活度方面遥遥领先。例如，Facebook使用Hive数据仓库跨越成千上万个节点。说起灵活度，Hive设计的初衷是与一些系列存储系统（HDFS、HBase、S3）配合使用，并能够支持多种输入格式（压缩、未压缩、Avro、纯文本、JSON）。

　　易扩展和高灵活度在给你带来便利的同时，却也阻碍了你构建性能更好的查询引擎。接下来，我将列举哪些特征会影响查询性能：

　　数据格式：数据以类似纯文本文件，相对未优化的形式存储在HDFS中。Hive 作业在处理数据之前，需要先花大量时间从硬盘中读取数据，再反序列化这些数据。

　　发起任务的系统开销：Hadoop MapReduce 使用心跳机制（heartbeats）制定作业计划，每项任务作为一独立的JVM过程发起。在Hadoop MapReduce 中，仅仅是发起一项作业就需要几十秒钟，在秒级时间单位内，是无法运行任何进程的。相反，并行数据库拥有持续进程或线程池，它们能够大大减少任务安排及发起所需要的系统开销。

　　中间数据物化 vs数据传输：Hive 使用拥有二阶模型(Map和Reduce)的MapReduce来执行。通常一个复杂的SQL查询被映射为MapReduce的多个阶段，不同阶段的中间数据在硬盘上物化。并行数据库内置有用于执行SQL查询的引擎，执行查询时，该引擎在查询操作符和数据流（steram data）之间跨节点传递数据。

　　列数据格式：列数据库将数据按照列式的格式进行存储。在典型的数据仓库中，每张数据表能够存储成百上千列，而大多数查询仅查找少数列。让我们来考虑一下如下查询，要查找的是沃尔玛每家店的营业额。它仅需要查找两三列（商店的编号、每件商品的零售价，或者还有销售日期）。以列式存储数据，执行查询时，引擎可以跳过不相关的列。这样可以减少上百次的硬盘I/O。此外，按列存储数据能够大大增加压缩比率。

　　列查询引擎：除了上面提到的按列式存储的数据格式，还可以按列构建查询执行引擎，该引擎在分析型工作负载方面得到了较好的优化。其中的技巧包括：晚期物化（late materialization）、直接操作压缩过的数据、利用现代CPU提供的向量化操作（SIMD）。

　　更快的S3连接：在这里我将给出一个大胆的猜测：AWS可能已经为他们的Redshift实例实现了一个比普通S3能够提供的更高带宽的S3整体负载。

　　我需要申明，我们刚刚讨论的这些因素是基于Hive当前版本（2013年2月）。毫无置疑，Hive社区将会推进开发工作，并解决其中的一些难题。