大数据面临一个具有讽刺意味的小文件问题，它会阻碍生产力并浪费宝贵的资源。
如果管理不善，小文件问题会降低数据系统的性能，并使您的分析变得陈旧。这种违背目的的，不是吗？
HDFS 文件存储通常没有优化，它会导致 NameNode 内存利用率和 RPC 调用不佳。这最终阻止了扫描吞吐量的下降，并降低了应用层的性能。如果您是任何现代数据湖的大数据管理员，您总会遇到小文件问题。
分布式文件系统很棒，但让我们面对现实吧，您拆分存储层的次数越多，读取这些文件时的开销就越大。因此，我们的想法是优化文件大小以最好地服务于您的用例，同时积极优化您的数据湖。
小文件对业务的影响
- 减慢阅读速度— 读取小文件需要多次查找以从每个小文件中检索数据，这是一种低效的数据访问方式。
- 减慢处理速度— 小文件会减慢 Spark、MapReduce 和 Hive 作业的速度。例如，MapReduce 映射任务一次处理一个块。文件每个使用一个地图任务，如果有很大的编号。每个地图任务处理的输入很少。文件的数量越大，任务的数量就越大。
- 浪费存储— 每天在运行作业时可能会创建数十万个每个大小为 5 KB 甚至 1 KB 的文件，这些文件会迅速增加。它们所在位置缺乏透明度增加了复杂性。
- 过时的数据— 所有这些都会导致数据陈旧，从而拖累提取价值的整个报告和分析过程。如果作业运行不快或响应速度慢，决策就会变慢，数据就不再有价值。你失去了数据首先要带来的优势。
- 花时间解决运营问题而不是战略改进— 资源最终被用于主动监控工作。如果可以删除这种依赖关系，则可以使用资源来探索如何优化作业本身，以使之前需要 4 小时的作业现在只需要 1 小时。因此，这具有级联效应。
- 影响扩展能力— 运营成本呈指数增长。如果您在此过程中增长 10 倍，则运营成本的增长不是线性的。这会影响您的扩展成本。虽然小文件是一个大问题，但它们也不是完全可以避免的。遵循最佳实践以有效地将它们应用于您的组织将使您能够控制而不是救火。在任何生产系统中，重点都是保持其正常运行。随着问题的出现，我们会部署资源来解决它。
小文件问题
让我们以 HDFS 为例，它是一种分布式文件系统，它是 Hadoop 基础架构的一部分，旨在处理大型数据集。在 HDFS 中，数据分布在多台机器上并复制以优化并行处理。
由于数据和元数据是分开存储的，因此无论大小如何创建的每个文件都占用内存中的最小默认块大小。小文件是小于 1 个 HDFS 块的文件，通常为 128MB。小文件，即使小到 1kb，也会导致名称节点上的负载过大（涉及将文件系统操作转换为数据节点上的块操作）并消耗与 128 MB 文件一样多的元数据存储空间。较小的文件大小也意味着较小的集群，因为可以通过名称模式管理的文件数量（无论大小）存在实际限制。
您可以做些什么来识别和消除小文件问题？
在 HDFS 之上没有简单的工具来查看存在多少文件，每个文件或目录的大小是多少，或者用户创建文件的方式和位置。
现在从跨越多个集群和区域的系统的角度来考虑这一点，PB 级的数据占用了存储空间并降低了性能。您不仅会浪费存储空间，而且像 Hive 和 MapReduce 这样运行的任何作业也会减慢速度。
现在需求发生了变化，并且随着数据湖概念的出现，用户希望将其降低，以便他们甚至可以从他们的数据湖平台服务移动应用程序（即亚秒级响应时间）。人们想要使用此基础设施的时间界限呈指数下降。因此，您的最佳块大小甚至可能是 64 MB，这一切都取决于用例。
一个极端的用例是您正在处理 1 KB 的文件大小，这是一个常见的用例，当您处理 IoT 数据或传感器数据时，您可能每 200 毫秒获取一个文件并且您想要为每一分钟。这些仍然是非常小的文件，不会超过 10 KB。
因此，虽然无法避免小文件，但可以对其进行管理，以便将它们保持在比大文件低的百分比。这是一个连续的过程，需要一个维护周期。
为什么识别和消除小文件问题如此困难？
在 HDFS 之上没有简单的工具来查看存在多少文件，每个文件或目录的大小是多少，或者用户创建文件的方式和位置。
现在从跨越多个集群和区域的系统的角度来考虑这一点，PB 级的数据占用了存储空间并降低了性能。您不仅会浪费存储空间，而且像 Hive 和 MapReduce 这样运行的任何作业也会减慢速度。
现在需求发生了变化，并且随着数据湖概念的出现，用户希望将其降低，以便他们甚至可以从他们的数据湖平台服务移动应用程序（即亚秒级响应时间）。人们想要使用此基础设施的时间界限呈指数下降。因此，您的最佳块大小甚至可能是 64 MB，这一切都取决于用例。
一个极端的用例是您正在处理 1 KB 的文件大小，这是一个常见的用例，当您处理 IoT 数据或传感器数据时，您可能每 200 毫秒获取一个文件并且您想要为每一分钟。这些仍然是非常小的文件，不会超过 10 KB。
因此，虽然无法避免小文件，但可以对其进行管理，以便将它们保持在比大文件低的百分比。这是一个连续的过程，需要一个维护周期。
用于管理小文件的现有工具
一个理想的解决方案是一个与软件无关的系统，它可以提供公司整个大数据基础设施的横截面视图。公司目前使用现有工具面临的问题有三个方面：
- 单线程 APM 工具——传统的 APM 工具是单线程的，专注于 Web 应用程序，但它们都没有提供深度文件系统分析。
- 特定于引擎的优化工具——像 Spark、Hive 这样的查询引擎有特定的监控和优化产品，只专注于他们的平台，并且只有通过他们的软件摄取数据时才会进行优化。
- 内部脚本软件和手动干预——因此，在公司的大数据生态系统中识别小文件的过程在很大程度上仍然是手动的，依靠支持人员来浏览各个文件夹，并且随着公司的快速发展和系统变得更加复杂，现有的监控工具还不够。
用户影响
更短的维护周期——从 12 小时到 15 分钟
我们的一位客户通过 Spark 和 MapReduce 工作负载拥有超过 40 PB 的数据。该卷导致阅读目录需要花费很多秒，这比理想情况下应该花费的时间多 100 倍。
他们还有一个资源密集型的维护周期，其中涉及遍历每个文件夹，找出那里有哪些文件以及他们可能需要压缩文件的位置。仅仅弄清楚要压缩哪些文件就需要很多时间。
HongKe数据可观察性平台通过使其变得非常简单，减少了识别小文件所需的时间。因此，我们将其从 12 小时的维护周期缩短到 15 分钟以下。
降低维护成本 – 至少降低 50%
维护是有成本的，如果每 7 天完成一次，成本非常高。它也每天在案件中进行。使用 HongKe，即使您将许可和计算因素考虑在内，对于此特定功能，它也只是其中的一小部分。
更简单、更快速的 RCA – 更少的票证，更快的解决方案
另一种情况是客户希望发送有关其维护周期的定期报告。
早期的日志文件被收集、整理并发回建模团队进行分析。现在使用HK-Pulse，您可以在一个地方获得所有这些上下文 – 具有多维可见性。因此，Ops 资源可能会在问题出现时发现问题，而不是几个小时，当然也不是几个月。
管理数据湖中的小文件可以从降低成本到更快地解决问题等方面带来显着的好处，这会影响到您的其他业务。联系我们以了解有关这些优势的更多信息，或者如果您想了解有关优化数据湖的更多信息并探索 HongKe 如何提供帮助。
Your point of view caught my eye and was very interesting. Thanks. I have a question for you.
I may need your help. I tried many ways but couldn’t solve it, but after reading your article, I think you have a way to help me. I’m looking forward for your reply. Thanks.