“HashData云原生架构”是HashData原创的系列文章。在第一篇《对象存储与HashData多云战略》的文章中提到：HashData数据仓库使用对象存储作为数据持久层，通过巧妙地在对象存储Bucket与数据库表空间建立映射关系，同一个HashData集群可访问（读写）不同对象存储系统的数据，原生支持多云数据访问。本文为系列解读第二篇，主要介绍HashData的多集群共享统一存储架构（Multi-cluster, Shared-data Architecture），重点分享——保存在对象存储上的同一份数据（同一张表的数据）如何被不同计算集群访问。

HashData数据仓库由三部分组成: 元数据集群、计算集群和分布式共享存储，分别对应管理、计算和存储功能，每一层可独立扩容。

部署拓扑图

以一个简化的架构图（演示环境中的部署拓扑图）为例：部署拓扑图包含两个计算集群，一个集群由4个计算节点组成，另一个由8个计算节点组成。两个计算集群共享上层的元数据集群和底层的对象存储集群，与传统MPP数据库Shared-Nothing对比，这种架构被称为Shared-Everything。

下面通过三个典型的操作流程解析HashData多集群共享统一存储架构的工作原理:

1. 数据库连接：用户基于数据库来连接信息——通过PSQL、JDBC等客户端程序连接计算集群（随便一个计算集群）主节点；主节点接受客户端连接后，访问元数据集群，对客户端进行一系列身份/权限认证；当通过认证后，fork出特定的主进程（QD进程）负责该数据库连接接下来的查询处理。从用户体验的角度看，整体实现流程与开源的Greenplum Database应用方式完全相同。
   
   
2. SQL执行: 用户通过客户端将查询SQL语句提交给主节点的QD进程，QD进程负责解析接收到的SQL语句，生成查询计划。在这一过程中，如本地未缓存所需的元数据，QD进程会请求元数据集群获取并在本地缓存一份。查询计划生成后，QD进程会连接到计算节点，启动执行进程（QE进程），并把查询计划分发到各个QE进程。QE进程随即开始执行被分配的子计划。在执行过程中，如果发现需要用到的元数据本地未缓存，将再次访问元数据集群，获取并缓存一份在本地。
   对于一个新启动的计算集群（冷启动），每个计算节点本地没有任何数据，数据块保存在对象存储上。因此，当计算集群第一次访问某张表时，需要直接访问对象存储获取需要的数据块，并在本地缓存一份。无论是元数据还是数据访问，均为按需进行——仅当查询需要时，才在元数据集群/对象存储中拉取后缓存本地。
   
   
3. 数据加载: 为了对新插入的数据提供ACID的数据库特性，采取了write-through策略：即不通过缓存的方式写到对象存储，然后更新元数据，提交数据库事务。
   
   

1. 在小集群创建test表，插入100万条记录：

这篇文章中，我们介绍了HashData数据仓库多集群共享统一存储的架构。首先，这个架构不仅可以安全、轻松地实现不同集群之间的数据共享，同时避免了数据复制与数据移动的延迟和复杂性；其次，我们可以通过横向增加集群数量的方式，提升数据并发访问度；再次，由于支持多集群之间的数据强一致性，消费者集群始终可以查看最新的数据，即便数据在生产者集群上不断更新；最后，企业能够安全管理与外部的协作以及跨组织共享数据。