学习文档：内幕 - 文件系统
学习笔记如下：
Flink 文件系统
Flink 通过 org.apache.flink.core.fs.FileSystem 实现了文件系统的抽象。这种抽象提供了一组通用的操作，以支持使用各类文件系统。
为了支持众多的文件系统，FileSystem 的可用操作集非常有限。例如，不支持对现有文件进行追加或修改。
文件系统会添加一个 “文件系统方案” 标识，如 file://、HDFS:// 等。
Flink 支持以下文件系统：
-
file：机器的本地文件系统
其他通过 Apache Hadoop 组件连接的文件系统包括但不限于：HDFS；s3、s3n、s3a（亚马逊 S3 文件系统）、gcs（谷歌云存储）……
如果 Flink 在类路径或 fs.hdfs.hadoopconf 中找到了 Hadoop 配置，那么它就会加载 Hadoop 的文件系统。
持久化保证（Persistence Guarantees）
Flink 文件系统用于持久化存储数据，包括存储应用程序的结果以及容错和恢复。
持久化保障的定义
写入输出流的是持久的，要求满足以下两个条件：
- 可见性（Visibility）要求：只要给出绝对文件路径，那么其他访问该文件的进程、机器、虚拟机、容器均能得到一致的数据。但是对于一些最终一致的文件系统来说，对文件父目录的更新并不要求可见性。
- **持久性（Durability）要求：**在何种程度上能够保证数据不会丢失。例如，当出现硬件或系统崩溃时，本地文件系统无法保证，而复制分布式文件系统（例如 HDFS）通常在存在 n 个并发节点故障的情况下保证，其中 n 是复制因子。
一旦调用 FSDataOutputStream.close() 返回，那么 FSDataOutputStream 就必须保证写入字节数据的持久性。
容错的分布式文件系统
对于容错分布式文件系统，数据一旦被文件系统接收并确认，通常通过复制到一定数量的机器（持久性要求），此外，绝对文件路径必须对所有其他可能访问该文件的机器可见（可见性要求）。
数据在存储节点上如何实现持久性取决于特定文件系统的具体保障方法。
文件父目录的元数据更新不需要实现一致。只要所有节点都可以通过绝对路径访问文件，在列出父目录的内容时，允许一些机器看到文件，而其他机器看不到。
本地文件系统
对于本地文件系统，必须支持 POSIX 的 close-to-open（flush-on-close）一致性语义。由于本地文件系统没有任何容错保证，因此没有进一步的要求。
对于本地文件系统的角度来说，已保存的文件可能仍然在操作系统的缓存中。因此，会导致操作系统缓存丢失的崩溃都是致命的，Flink的本地文件系统也不能保证避免这个问题。
这意味着，只写入本地文件系统的计算结果、检查点和保存点不能保证在本地机器发生故障时可以恢复，这使得本地文件系统不适合生产环境。
更新文件内容
许多文件系统要么根本不支持覆盖现有文件的内容，要么在这种情况下不支持更新内容的一致可见性。因此，Flink 的文件系统不支持向现有文件中追加内容，也不支持在输出流中查找以在同一个文件中更改以前写入的数据。
覆盖文件内容
覆盖文件通常是可行的。一个文件的覆盖可以通过删除它然后再创建一个新文件。但是，有些文件系统无法使这样的更改对所有有权访问改文件的各方同步可见。例如，Amazon S3 仅保证文件替换可见性的最终一致性，有些机器会看到旧文件，有些机器会看到新文件。
为了避免这些一致性问题，Flink 中故障 / 恢复机制的实现严格避免同一文件路径被多次写入。
线程安全
文件系统必须是线程安全的：同一个 FileSystem 实例会被 Flink 的多个线程共享，因此必须能够支持同时创建输入 / 输出流和列出文件元数据。文章来源：https://www.toymoban.com/news/detail-774384.html
FSDataInputStream 和 FSDataOutputStream 的实现严格来说不是线程安全的。在读取或写入操作之间，流的实例也不应在线程之间传递，因为无法保证操作在线程之间的可见性。文章来源地址https://www.toymoban.com/news/detail-774384.html
到了这里，关于Flink｜《Flink 官方文档 - 内幕 - 文件系统》学习笔记的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
