我们决心对HAWQ的系统架构做一次大的调整，使其更加地Hadoop Native，Hadoop原生，而不仅仅是简单地将数据放到HDFS上面。当时，我们内部称这个新版本为HAWQ 2.0，也就是大家现在在github上面看到的Apache HAWQ。
其中最重要的一步是，我们希望计算和存储不仅物理上分离，逻辑上也是分离。数据库中的用户表数据在HDFS上不再按照每个Segment单独来组织，而是按照全局的数据库对象来组织。举个例子，我们将一张用户表对应的多个数据文件（因为往该表插入数据的时候，为了提高数据插入的效率，系统会启动了多个QE进程同时往HDFS写数据，每个QE写一个单独文件）放到同一个目录底下，而不是像原来那样，每个QE进程将文件写到自己对应的Segment目录底下。这种改变带来的一个直观结果就是，由于所有的数据文件都放在一起，查询执行的时候，根据需要扫描的数据量不同，我们既可以使用一个Segment实例去完成表扫描操作，也可以使用多个Segment实例去做，彻底摆脱了原来只能使用固定数量个Segment实例来执行查询的刚性并行执行策略。
当然，HDFS数据目录组织的改变只是实现HAWQ 2.0弹性执行引擎的一步，但却是最重要的一步。计算和存储的彻底分离，使得HAWQ可以像MapReduce一样根据查询的复杂度灵活地调度计算资源，极大地提升了系统的扩展性和吞吐量。
我们简单比较一下HAWQ 1.x和HAWQ 2.0的资源调度。
左边展现的是HAWQ 1.x在同时处理三个查询（分别来自三个不同的会话）时的资源调度情况。和传统MPP数据库一样，无论查询的复杂度如何，每个Segment实例都会参与每条查询的执行。换句话说，每个Segment实例都会启动一个QE进程处理分配给它的任务。在这种情况下，系统能够支持的并发查询数量，跟集群的计算节点数没有任何关系，完全由一个计算节点上面的资源量决定（这里，我们先不考虑主节点成为瓶颈的问题）。一个4个节点的HAWQ集群能够支持的并发查询数量和一个400个节点的集群是一样的。
右边展现的是HAWQ 2.0在同样并发查询下的资源调度情况。和Hadoop的MapReduce一样，我们能够根据查询的复杂度决定需要调度多少计算资源参与查询的执行。为了方便阐述，这里假设每条查询只需要两个计算资源单元。而且，执行单元可以根据资源管理器的调度算法分配到不同的物理计算节点上面。这两点灵活性：计算资源的数量可变和计算资源的位置可变，正是HAWQ 2.0弹性执行引擎的核心。在这种情况下，系统能够支持的并发查询数量，跟集群的计算节点数量呈线性关系：计算节点越多，系统能够支持的并发查询数量越多（再次提醒，这里，我们先不考虑主节点成为瓶颈的问题）。
所以，可以说，HAWQ 2.0成功解决了传统MPP数据仓库中计算节点首先成为吞吐量瓶颈的问题。同时，由于并不是所有计算节点都需要参与到每条查询的执行中，HAWQ 2.0同时也解决了传统MPP数据库由于单个计算节点性能下降直接影响整个集群性能的问题（这导致MPP集群不能包含太多的计算节点，因为根据概率，集群节点到达一定值后，出现单个计算节点性能下降的概率将会非常高），从而也很大程度上解决了扩展性问题。
通过将计算和存储彻底分离成功解决了计算节点成为系统吞吐量瓶颈的问题后，现在系统的唯一瓶颈就剩下主节点。