除了Append-only表之外，Greenplum Database还支持Heap表，这是一类能够支持增删改查的表。结合前面提到的Segment实例的本地状态，我们可以将本地存储分成四大类：系统表、日志、Append-only表分区数据和非Append-only表分区数据。我们将其中的Append-only表分区数据放到了HDFS上面。每个Segment实例对应一个HDFS的目录，非常直观。其它三类数据还是保存在本地的磁盘中。
总体上说，相比于传统的Greenplum Database， Greenplum on HDFS架构上并没有太多的改动，只是将一部分数据从本地存储放到了HDFS上面，但是每个Segment实例还是需要通过本地存储保存本地状态数据。所以，从高可用性的角度看，我们还是需要为每个实例提供备份，只是需要备份的数据少了，因为Append-only表数据的高可用性现在是由HDFS数据的高可用性来保证。
Greenplum on HDFS作为一个原型系统，验证了MPP数据库和HDFS是可以很好地整合起来工作的。基于这个原型系统，我们开始将它当成一个真正的产品来打造，也就是后来的HAWQ。
从Greenplum on HDFS到HAWQ，我们主要针对本地存储做了系统架构上的调整。我们希望将计算节点的本地状态彻底去掉。本地状态除了前面提到的系统表（系统表又可以细分成只读系统表（系统完成初始化后不会再发生更改的元数据，主要是数据库内置的数据类型和函数）和可写系统表（主要是通过DDL语句对元数据的修改，如创建新的数据库和表））、事务日志、Append-only表分区数据和非Append-only表分区数据，同时还有系统在查询执行过程中产生的临时数据，如外部排序时用到的临时文件。其中临时数据和本地只读系统表的数据都是不需要持久化的。我们需要考虑的是如何在Segment节点上面移除另外四类状态数据。
Append-only表分区数据前面已经提到过，交给HDFS处理。为了提高访问HDFS的效率，我们没有采用Hadoop官方提供的HDFS访问接口，而是用C++实现了原生的HDFS访问库，libhdfs3。针对非Append-only表数据的问题，我们的解决方案就比较简单粗暴了：通过修改DDL，我们彻底禁止用户创建Heap表，因为Heap表支持更新和删除。所以，从那时起到现在最新的Apache HAWQ，都只支持表数据的追加，不支持更新和删除。没有了表数据的更新和删除，分布式事务就变得非常简单。通过为每个Append-only表文件对应的元数据增加一列，逻辑EoF，即有效的文件结尾，只要能够保证EoF的正确性，我们就能够保证事务的正确性。而且Append-only表文件的逻辑EoF信息是保存在主节点的全局系统表中的，它的正确性通过主节点的本地事务保证。为了清理Append-only表文件在追加新数据时事务abort造成的脏数据，我们实现了HDFS Truncate功能。
对于本地可写系统表，我们的做法是将Segment实例上面的本地可写系统表放到主节点的全局系统表中。这样主节点就拥有了全局唯一的一份系统表数据。查询执行过程中需要用到的系统元数据，我们通过Metadata Dispatch的方式和查询计划一起分发给每个Segment实例。
通过上述的一系列策略，我们彻底摆脱了Segment节点的本地状态，也就是实现了无状态Segment。整个系统的高可用性策略就简单很多，而且也不再需要为Segment节点提供Mirror，系统的利用率大大提升。
数据的高可用交给了HDFS来保证。当一个Segment节点出故障后，我们可以在任意一台有空闲资源的机器上重新创始化一个新的Segment节点，加入到集群中替代原来出故障的节点，整个集群就能够恢复正常工作。
我们也做到了计算和存储物理上的解耦合，往彻底摆脱传统MPP数据库（例如Greenplum Database）计算和存储紧耦合的目标迈出了有着实质意义的一步。
虽然在HAWQ 1.x的阶段，我们做到了计算和存储物理上的分离，但是逻辑上两者还是集成的。原因是，在将本地表分区数据往HDFS上面迁移的时候，为了不改变原来Segment实例的执行逻辑流程，我们为每个Segment指定了一个其专有的HDFS目录，以便跟原来本地数据目录一一对应。每个Segment负责存储和管理的数据都放在其对应的目录的底下，而且该目录底下的文件，也只有它自身能够访问。这种HDFS数据跟计算节点逻辑上的集成关系，使得HAWQ 1.x版本依然没有摆脱传统MPP数据库刚性的并发执行策略：无论查询的复杂度如何，所有计算节点都需要参与每条查询的执行。这意味着，系统执行一条单行插入语句所使用的计算资源，和执行一条对几TB数据进行复杂多表连接和聚合的语句所使用的资源是一样的。这种刚性的并行执行策略，极大地约束了系统的扩展性和吞吐量，同时也与Hadoop基于查询复杂度来调度计算资源的弹性策略相违背。