在执行多个查询的时候，后面的查询能够利用前面查询的查询结果(有点类似于数据仓库中的物化视图的概念)，从而可以提高查询的性能。
现在企业级应用大多使用的方案是Hadoop+MPP的方式，即通过Hadoop批处理非结构化数据(进行ETL操作)然后通过 connector导入MPP进行结构化数据的查询操作。但是这只是临时的替代方案，Hadapt说invisible loading才是最合理的，这样企业就有了一个统一分析平台。
Hawq
原来GPDB中的存储是本地磁盘，现在改成HDFS，原来GPDB的单节点的RDBMS只充当执行引擎的功能，不再充当存储引擎功能。
查询执行通过GPDB的并行执行引擎(不再使用MR)，每次查询开始把数据从HDFS中导入到GPDB，执行过程中通过内存交换数据而非MR那样每次任务结束都写磁盘。
GP特有的cost-based parallel query optimizer and planner是它的一大优势，也是目前其他大多数的产品中没有的，它能够帮用户选出该SQL最高效的执行顺序。
使用GPDB充当执行引擎的好处：标准SQL兼容;支持ACID事务;JDBC/ODBC支持;JOIN顺序优化和索引支持(查询优化器);支持行/列两种存储格式。
GPXF使得Hawq能够读取存储在HDFS上的任何格式的数据以及存储在其他文件系统和设备中的数据。
底层的HDFS需要支持trancate语义和native C interface。
支持In-Database analytics ( http://madlib.net/ ):
性能相关：
Scott Yara(Greenplum老大)公开承认Hawq比pure GPDB要慢。这么做的目的无非就是更好的利用HDFS的可扩展性，统一存储管理。
和其他SQL on Hadoop产品的性能对比方面，Hawq在group by和join操作上与其他方案相比优势明显，前提是数据量不是特别大。(是不是因为数据导入的时候partition做的好呢，是不是拿load的时间 换group by/join的时间呢？)
总之，目前在SQL on Hadoop领域普遍比较薄弱的环节是：
1. workload management and query optimization多个表的JOIN如何执行，例如3个表的JOIN会有6种执行策略，那么哪一种才是效率最高的呢。显然要通过计算每种执行顺序的开销来获得。在传统数据库或者数据仓库领域都有非常好的查询优化器，而在分布式系统中该如何衡量这些指标(磁盘IO，网络带宽，内存)与最后查询效率之间的关系是个需要认真研究的问题。
2. 关联子查询correlated sub-queries还是没有谁能够实现。在TPC-H中又很多关联子查询的例子，但是现在的SQL on Hadoop产品都不支持。听Impala的人说，他们客户对这个的需求不是很强烈，大部分关联子查询可以转化成JOIN操作。但是目前的商业产品像 Hawq是支持关联子查询的。
除了上面主要讨论的开源产品以外，大数据分析领域还有很多商业产品。这些商业产品可以分为两类：一类是面向企业级应用的、以卖license或软硬件一体机形式出售的Teradata/Aster Data, HP/Vertica, SAP/HANA,IBM/BigSQL, Oracle和Microsoft也有类似的产品;另一类是利用大规模云计算基础设施，提供的数据分析服务的Google/BigQuery(典型的Analysis as a Service)和Amazon/Redshif。