如前面提到，主节点的功能主要分成两类：元数据管理，包括系统表存储和管理、锁管理和分布式事务等等，和计算资源调度管理和执行。前者我们可以看成是状态管理，后者是没有状态的组件。通过将状态管理提取出来成为单独一个功能层，我们让主节点跟计算节点一样变得没有状态。这样，我们能够根据系统并发查询的变化，动态增加或者减少主节点的数量。这个设计借鉴了Hadoop YARN的设计。YARN的框架通过将原来的JobTracker的功能分成了Resource Manager和Application Manager，从而解决Hadoop集群吞吐量的问题。
这是一个云端数据仓库的架构图。实际上，我们在HashData希望通过云端数据仓库解决企业用户使用数据仓库时碰到的多种难题，包括商业上的和技术上的。在这里，我们只关注技术上的。
在这个系统架构中，我们将管理即元数据、计算和存储三者分离，每一层都能单独动态伸缩，在解决系统吞吐量和扩展性问题的同时，提供了多维度的弹性。
我们利用云平台的对象存储服务，如AWS的S3和青云QingCloud的QingStor，作为系统数据的持久层。除了按需付费的经济特性外，云平台的对象存储服务在可扩展性、稳定性和高可用性等方面远胜于我们自己维护的分布式文件系统（如HDFS）。虽然对象存储的访问延迟远高于本地磁盘访问，但是我们可以通过本地缓存的策略很大程度减轻延迟问题。
同样的，我们利用云平台提供的虚拟机作为我们的计算资源，也能够一定程度上实现资源的隔离，从而保证不同的工作负载之间没有相互影响。
云平台提供的近乎无限的计算和存储资源（相对于数据仓库应用来说），使得云端数据仓库能够存储和处理的数据达到一个全新的高度。
最后，我们做一个简单的总结。从PostgreSQL到Greenplum Database，我们通过大规模并行处理（MPP）技术，实现了处理海量数据时的低延迟目标。从Greenplum Database到Apache HAWQ，通过计算和存储分析的策略，我们提升了系统的并发处理能力和扩展性。从Apache HAWQ到Cloud Data Warehouse，我们借助云平台近乎无限的计算资源和存储资源，以及管理、计算和数据三者分离，还有计算资源严格隔离，我们能够取得近乎无限的并发处理能力和扩展性。
MPP数据库采取的是流水式的执行引擎，中间的每个阶段是不带检查点的。这意味着，只有有一个参与到查询执行的QE进程出错，整条查询将会失败，只能从头开始重新执行这条查询。而我们知道，当参与到查询执行的QE进程达到一定数量的时候，QE进程出错将是必然的，特别是在一个资源共享的环境中。这时候，即使是重新提交查询重跑，失败还是必然的。换句话说，我们几乎无法成功执行需要调度大量计算资源的查询。
展望未来，我们希望实现带检查点的流水式执行引擎，从而使得系统能够处理任意大的查询（单个查询需要同时调度成千上万的计算资源）。