Azure Data Lake Store 的一致性答案

【问题标题】：Consistency of Azure Data Lake StoreAzure Data Lake Store 的一致性
【发布时间】：2017-01-18 19:15:29
【问题描述】：

Azure Data Lake Store 的一致性保证是什么？有没有人找到描述它的技术文档？

我特别感兴趣的是目录移动是否是原子的、目录列表是否一致以及文件是否在写后读一致。

【问题讨论】：

【解决方案1】：

在 Azure Data Lake Store 中，文件具有写后读一致性（有时也称为强一致性）。目录列表也非常一致。

目录和文件重命名操作是原子的。这包括将目录/文件移动到不同的父级。此行为的唯一警告是当重命名操作的目标已经存在并且使用了 OVERWRITE 选项时。在这种情况下，重命名操作不是原子的。有关使用 OVERWRITE 选项重命名的更多信息 [位于此处](https://hadoop.apache.org/docs/r2.6.1/api/org/apache/hadoop/fs/FileSystem.html#rename(org.apache.hadoop.fs.Path, org.apache.hadoop.fs.Path, org.apache.hadoop.fs.Options.Rename...))。

-Azure 数据湖存储团队

【讨论】：

是否有任何关于 Azure Data Lake Store 一致性的公开技术文档，顺便说一句？
暂时没有。除了上述内容之外，您还有什么特别需要寻找的吗？
我对使用工作流管理器构建批处理作业管道感兴趣，例如路易吉或气流。存储一致性与管道中一个作业和下一个作业之间的切换有关。在典型的场景中，集群计算框架中的 reducer，例如Spark，每个文件写入一个临时目录，master 写入一个标记文件。然后工作流管理器将目录移动到其最终位置。工作流管理器启动下一个 Spark 作业，该作业拾取写入的文件。
为了让事情可靠地工作，目录移动需要是原子的，第二个作业中的Spark master在读取目录时需要获取完整的文件列表，工作节点需要能够读取文件。 HDFS 提供这些保证，而云对象存储服务通常不提供。如果罕见的故障导致作业失败，即读后写有时会失败，管道可以存活，但如果目录移动是非原子的或列表不一致，则不会，因为这些情况会导致静默数据损坏。
与许多云对象存储不同，ADLS 是一个文件系统。它被设计成具有许多与 HDFS 相似的特性，例如原子目录移动、目录列表的一致以及文件的后写一致性。我们已经测试和认证了在 Azure HDInsight 中运行的所有工作负载，包括带有 ADLS 的 Spark。所以它应该适用于所有场景。