上下级平台之间数据同步方案_Alluxio与底层存储系统之间的元数据同步机制

请点击上方蓝字，关注我们哦！

作者简介：林意群，Apache Hadoop PMC member，Apache Ozone PMC member，拥有多年参与开源社区经验，主要专注于存储领域的研究和学习，目前任eBay Hadoop team 大数据研发工程师。

前 言

Alluxio作为一套构建于底层存储系统之上的中间层，它必不可少的会涉及到与底层系统之间metadata之间的同步问题。外部client请求访问Alluxio系统，然后Alluxio再从底层系统中(为称呼方便，后面都简称为Underlying FileSystem, UFS)查询真实的元数据信息，然后再返回给client。当然为了减少对于UFS的压力，我们当然不会每次都去查UFS。本文我们来聊聊Alluxio内部对此元数据同步处理的设计实现，它是最大可能性做到元数据请求处理的高效性以及数据的精准性的。

Alluxio内部的元数据同步行为

首先，这里我们需要想清楚一个基本的问题：作为一套构建于底层存储系统之上的Cache层，Alluxio内部会存在哪些元数据需要同步的情况。

从元数据同步的源头，目标来划分，总共为2类：

• 1)Alluxio内部metadata先修改，UFS后修改，此过程是从Alluxio到UFS的metadata同步。

• 2)UFS的metadata先被修改，Alluxio随后同步此修改，此过程则为从UFS到Alluxio的metadata同步。

在上述两种情形中，1)较之于2)来说同步控制更为简单一些，因为Alluxio本身作为外部请求的处理入口，它能第一时间知道请求的发生处理，然后它来自己控制后续如何做UFS底层存储系统的metadata同步。Alluxio率先更新metadata后，对于外界来说，其元数据已经是最新状态的了。这时Alluxio可以选择灵活的策略来更新UFS中滞后的metadata了，比如它可以采用异步更新的方式或者强制同步更新的方式。归纳起来一句话，1)情况下元数据同步更新的主动权完全掌握在Alluxio系统这边。

相比较而言，元数据同步较为复杂的是第二种情况：底层系统metadata发生改变(存在外部程序直接访问UFS导致metadata发生改变)，又没有途径能够通知到Alluxio，而且Alluxio是外界请求访问的服务。

2)的情况如下图右半边图所示，1)则为下图左半图所示情形：

上面右半图显示的就是底层存储系统HDFS存在额外更新的情况，需要Alluxio去同步来自Hive这边的对HDFS的额外更新。

下面我们来看看Alluxio内部是如何解决上面这种棘手的情况的。

基于给定时间，path粒度的UFS Status Cache

既然说存在UFS元数据意外更新的情况，为了保证Alluxio对外数据服务的准确性，我们很容易想到一种极端的做法，就是准实时地去同步HDF