云原生数据库系列谈（叁）：怎样兼顾存储共享与分布式计算？
上回书我们说到，基于Vertica的核心架构，Eon 模式又引入了元数据管理的分片机制。
在企业模式中，每个节点只管理完整数据中不同的一部分，它们各自独立加载和压缩数据。所以，数据的编录自然是不同的，故而节点之间没必要同步。
但是，在Eon模式下，数据将写入共享存储并可供任何节点访问。而这一过程中，分片对于实现此目标起到了最关键的作用。
订阅分片，数据共享
分片（Sharding）：
Eon模式中的分片机制，可确保每个节点都可以跟踪整个存储元数据的一个子集，所有节点都可以看到一致的视图，并且元数据与Vertica现有的投影机制保持一致，以确保相当的性能。
Eon模式通过分段型分片来显示定义用于数据分布的哈希空间区域而不再靠投影，分片在逻辑上包含被散列到特定区域（见图中的内圈）的所有元组的存储元数据对象。
虽然每个投影可能用不同的列来散列，但所有投影或表的哈希空间区域到分片的映射是相同的。
所有分段型投影的存储元数据都与分段型分片相关联。
订阅（Subscription）：
订阅了分片的节点将提供与分片关联的元数据和数据访问服务。 节点订阅控制任务执行在集群中的分布方式，并可在集群运行时创建或删除。 节点通常订阅多个分片，而分片通常具有多个订阅者。
集群要可用，每个分片必须至少有一个订阅节点。 要支持节点容错，每个分片必须有一个以上的个订阅者。
事务处理：验证有效性，确保一致性
当Eon模式中提交事务时，每个节点都可以创建元数据作为事务的一部分。
例如，批量加载可以在集群中的每个节点上创建ROS容器。 分片元数据增量尽可能被附带在现有的集群间通信消息上，以避免额外的消息开销。
在提交时，事务验证所有节点都具有其订阅所有分片的一致的元数据，确保没有其他订阅被遗漏从而导致事务无效。 如果一致性不成立，则回滚事务。
周密的订阅流程
Vertica执行一系列元数据和数据操作来完成节点订阅分片任务。当节点创建一个分片的订阅时，订阅处于PENDING(待定)状态。
一套完整的订阅流程是这样的：
订阅服务被唤醒
持续从分片的其他订阅节点同步传输元数据，直至达到最新状态
若缺少的元数据足够小，订阅服务会采用锁暂时阻止后续事务提交，并将订阅标记为PASSIVE(被动)状态，然后提交未完成的事务
其他订阅者失败，将PASSIVE态提升为ACTIVE(活动)状态
当一个节点宕掉并复原时，复原节点的所有ACTIVE状态订阅转换为PENDING状态，以便更有效地强制重新订阅。
当一个节点取消订阅分片时，它也遵循一系列步骤：
订阅过渡到REMOVING(待删)状态以声明删除订阅的意图
处于REMOVING状态时，节点可以继续响应查询
一旦存在足够数量的其他活动状态订阅，这个节点会删除该分片的相关元数据，从缓存中清除关联的数据并删除订阅
重新平衡(Rebalance)机制负责启动订阅和取消订阅，然后遵循下图中说明和上述过程。 当群集扩展或收缩时重新平衡会自动运行，但也可以在其他配置更改时手动运行。
图：分片订阅的状态转换。 黑色实线箭头表示数据和元数据操作，而其他箭头表示主动或被动的组织性变更
重重约束，避免分歧
为了简单起见，编录维护一个全局编录版本号。在发生节点宕掉时，所有分片必须在现存的节点中存在ACTIVE状态的订阅，并且辅助节点具有相同（最高）的全局编录版本。版本落后的节点将在群集形成后使用上述重新订阅过程进行修复。
如果有足够多的节点发生故障以致在群集操作期间违反上述约束，则群集将自动关闭以免产生分歧或错误答案。
复活：更有效的存储保障
在Eon模式中，尽管在事务提交之前所有的数据都会上传到共享存储中，但元数据会采用异步保存方式以免牺牲事务提交性能。
所有剩余日志都会上传，所以服务进程终止只会导致重启时继续读取本地事务日志，并且不会丢失已提交的事务。如果灾难性地丢失太多实例，则需要从已上传的日志中构建一致的版本。
这种从共享存储启动集群的操作称为复活(Revive)。
复活操作包含以下几个阶段：
1. 节点清空本地存储
2. 所有节点从共享存储中读取cluster_info.json文件，并提取截断版本和租约时间
3. 如果租约尚未到期，说明另一个群集很可能已经在共享存储位置上运行了，复活操作会终止。
4. 接下来，所有节点都从共享存储中单独下载自己的编录。
5. 最后，群集从新版本启动。
▼▼▼
现在，分片也分完了，接下来的查询流程又是怎样的呢？我们下回再表。
本系列文章摘编自刘定强所著《从无共享MPP列式数据库到弹性的云原生分析平台》