大数据的挑战是小文件

小文件可能会给存储平台及其支持的应用程序带来大问题。在 Google 上搜索 “small files performance” 会产生 2M+ 的结果。这篇博文将更深入地研究小文件问题，深入研究其根源并总结解决方案。

问题陈述

出于本讨论的目的，小文件通常被视为小于 64 KB 的任何文件。当我们与客户合作优化他们的集群时，我们看到 16 KB 到 1 MB 之间的文件越来越多（以数十亿和万亿计）。像这样的小文件通常是保存机器生成的基于事件的流的结果。将小文件写入对象存储非常简单，但对它们的查询运行速度会慢得多，甚至无法完成。查询许多小文件会产生读取元数据、执行非连续磁盘查找、打开文件、关闭文件并重复的开销。每个文件的开销只有几毫秒，但是当您查询数千、数百万甚至数十亿个文件时，这些毫秒加起来就是这些毫秒。分析引擎难以对大量小文件运行查询。许多企业在处理 IoT 设备、服务器、网络设备和应用程序日志等流源时都面临着这一挑战，所有这些源每秒都可以生成数千个事件日志，每个日志都存储在单独的 JSON、XML 或 CSV 文件中。仅查询一天的日志就可能需要数小时。

为解决昨天的大数据问题而构建的技术无法应对大量小文件的挑战。硬件和应用程序旨在处理少量大文件，但无法提取、编目和查询大量小文件。衡量系统在存储大量小文件时蓬勃发展的能力的关键指标是 IOPS，即每秒输入和输出（读取和写入）的数量。IOP 包括寻道时间、读取时间和数据传输时间。对于机械介质（如硬盘驱动器），顺序读取和写入比随机读取和写入快得多。随机读写单个文件的效率低于连续读写多个文件的效率。元数据管理、跨节点和磁盘的数据分配、I/O 管理、缓存管理和网络开销都可能导致性能低下和存储效率降低。这些是针对大量小文件进行优化时需要关注的领域。优化需要对系统工程有全面的了解，包括硬件和软件的组合和交互。必须从多个层面对大量小文件造成的问题进行攻关，并纠正瓶颈，以实现显著优化。特别是元数据管理，可能会削弱存储系统有效存储大量小文件的能力。在对大型连续文件进行操作时，元数据操作开销会被更大的数据操作开销所抵消。当小文件的数量急剧增加时，元数据操作开始严重降低系统性能。

Hadoop 和小文件

尤其是 Hadoop，它受到了向小文件的转变的沉重打击。Hadoop 可以有效地存储和处理少量大文件，而不是大量小文件。HDFS 的默认块大小现在是 128MB（以前是 64MB）。存储 128MB 文件与存储 16KB 文件占用的 128MB 块相同。此外，HDFS 中的每个文件、目录和块都在元数据中进行跟踪，每条 NameNode 内存记录占用 150 到 300 字节。1 亿个小文件将消耗数百 GB 的 namenode 内存，并且通过存储大部分为空的数据块浪费了 10 TB 以上。随着节点之间的通信量增加，必须写入、映射和查询更多的文件，效率会进一步降低。

SAN/NAS 和小文件

SAN 和 NAS 解决方案在处理大量小文件时也存在不足。这两种技术都旨在提供高 IOPS，但都不是为应用程序的大量并发读取和数据源的写入而设计的。两者都依靠 RAID 和复制来实现持久性和高可用性，这两者都会增加写入延迟并降低存储效率。SAN 提供非常低的延迟和高吞吐量，但仅限于直接连接到它的服务器。NAS 作为网络挂载卷，在存储大量小文件时面临块存储效率低下和文件系统限制的问题。但 NAS 的主要弱点是它无法大规模提供足够的性能，并且在面对大量并发请求时性能会下降。

使用传统数据库

对小文件问题的典型应对措施是将这些微小的数据写入传统的关系数据库。不幸的是，这也无法解决性能问题。它会在一段时间内，但没有数据库可以为 1 PB 的小文件提供持久性和性能。是的，从历史上看，使用数据库来存储和查询小文件是一个不错的主意 - 数据库提供 ACID 事务、索引，并且可以对这些记录执行详细查询，但是当面对解决组织当今面临的大量小文件问题所需的大量记录时，它们无法快速完成这两项工作。数据库在快速摄取大量小文件方面做得不是很好，但这正是流数据使用案例所需要的。表示数据记录、日志条目或设备遥测的小对象以大规模和速度来自无数应用程序和设备。此数据无法写入数据库。任何数据库都无法以支持实时分析所需的速度和规模运行。架构正在从传统的数据库和文件系统中移出来存储和查询大量小文件。数据库是用于 schema on write、分区/分片、提前构建索引以加快查询速度的出色工具，但这些都不适用于大量小文件。

适用于小文件的数据湖仓一体

数据湖仓一体是一个由一部分组成的数据仓库和一个由一部分组成的数据湖，这两个部分都使用底层的对象存储进行存储。这为工程师在决定如何处理大量小文件时提供了多种选择。以 Parquet、AVRO 或 ORC 形式到达的文件可以轻松摄取到数据湖仓一体的数据仓库端。其他文件可以发送到数据湖，在那里可以对其进行分析或转换，以便摄取到数据仓库中。

数据仓库不是普通的数据仓库，它基于开放表格式，提供时间旅行、架构演变、分区演变、零副本分支、外部表和 ACID 事务等现代功能。对于小文件，特别值得注意的是，基于 OTF 的数据仓库是 schema-on-read，在摄取大量小文件时提供性能优势。这是一款功能强大的新兴存储解决方案，可利用对象存储结构化和非结构化数据。由于数据湖仓一体构建在分布式对象存储之上，因此可以轻松横向扩展。此外，计算和存储在数据湖仓一体中解耦，从而允许进一步优化处理用于查询数据仓库的 SQL 的处理引擎。

MinIO 作为数据湖仓一体的存储层

MinIO 非常适合作为数据湖仓一体的存储层。在最近的性能基准测试中，我们测量了 165 GiB/秒的 PUT 吞吐量和 325 GiB/秒的 GET 吞吐量。MinIO 将元数据和对象内联存储，无需查询外部元数据数据库。MinIO 可以在上传后自动提取 .tar 文件，并从 ZIP 档案中下载单个文件。MinIO 的纠删码实施是小对象领先性能、存储效率和功能的关键组成部分。快速纠删码允许大规模捕获小型对象，并在多个驱动器和节点上以奇偶校验方式分发，以立即保护持久性和高可用性。例如，在最大纠删码奇偶校验的情况下，您可以丢失 MinIO 集群中一半的驱动器，但仍能保持持久性。

小文件解决方案

当今的许多工作负载（尤其是流式处理和日志分析）都对应用程序和存储系统提出了很高的要求，迫使它们处理大量小文件。大数据很少意味着分析大文件。更常见的是，大数据意味着数百万或数十亿个小于 1 MB 的文件。数据库和文件系统无法扩展以提供实时分析所需的性能。使用 MinIO 构建的数据湖仓一体是小文件问题的答案。行业领先的性能可加快摄取、查询和检索速度，而纠删码可提供持久性。永远不会丢失数据或导致查询再次超时。