Uber是如何在大规模集群中有效提高HDFS I/O利用率

以更低的硬件成本扩展我们的数据基础设施，同时保持高性能和服务可靠性并非易事。为了适应Uber数据存储和分析计算的指数级增长，数据基础设施团队通过重新架构软件层和硬件重新设计，对Apache Hadoop数据文件系统(HDFS)的扩展方法进行了大规模改革

• HDFS 联合、温存储、YARN 在 HDFS 数据节点上的并置以及 YARN 利用率的提高提高了系统的 CPU 和内存使用效率
• 将多种硬件服务器设计（24 x 2TB HDD、24 x 4TB HDD、35 x 8TB HDD）整合到35 x 16TB HDD的统一设计中，硬件成本降低30%

新的“CAP”定理

人们可能已经在许多与分布式系统相关的文章和论文的标题中看到了 CAP 定理，它指出：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）：二选一！

下一代数据基础设施应用类似于 CAP 定理的逻辑——基础设施只能提供 3 个所需特征中的 2 个，即：成本效率、可用性和性能。

成本效率是Uber的首要任务之一，而 HDFS 是Uber必不可少的数据服务，必须达到 99.9+% 的可用性。 我们不能妥协这两个特征中的任何一个。 那么问题就变成了：我们是否必须牺牲 HDFS 性能（尤其是 IO 性能）来换取成本效率和可用性？

在接下来的博客中，我们尝试分析当前的 HDFS 磁盘 IO 利用率，以评估当多个数据服务在我们的下一代行业领先的高密度硬件上运行时，我们是否会撞到“IO 墙”。

硬盘有多忙?

考虑到这个问题，我们转向使用指标来分析 HDFS 集群中所有 134,000 个硬盘的 IO 利用率。 我们得到的数据令人震惊：

The Good：大约90%的磁盘平均IO利用率低于6%。

The Bad：尾端磁盘IO利用率可高达15%以上，是平均磁盘IO利用率的5倍以上。 尽管这些磁盘只是整个磁盘池的一小部分，但它们代表了数千个驱动器。

这些繁忙的磁盘是如何分布在所有HDFS主机上的:是均匀分布在大量主机上，还是集中在一小群主机上?如果答案是后者，那么这可能会给即将到来的高密度HDFS服务器带来严重的问题，这些服务器正在运行多个服务。

主机有多忙？

为了回答这个问题，我们选择了最繁忙的磁盘（>13,000 个磁盘）中的前 10%，并检查它们在大约 5,600 个 HDFS 主机中的分布情况。 有趣的是，结果显示大约 55% 的最繁忙的驱动器包含 10% 的 HDFS 主机。

数据显示，最繁忙的磁盘确实集中在一小群主机中，而不是分布在所有主机中。 这表明我们应该将精力集中在这些 IO 活跃度最高的主机上，因为随着我们的成长，它们更有可能成为 IO 瓶颈。

集群有多忙？

我们最初的重点是我们之前确定的前 330 个最繁忙的主机。 进一步的检查表明，这 330 个热数据节点驻留在总共约 20 个 HDFS 集群中的 4 个中：

数据告诉我们一个事实：集群使用率是磁盘 IO 利用率的主要因素。 集群级别的 IO 利用率，尤其是不平衡的 IO 流量，是团队应该解决的首要任务。

如何提高 HDFS IO 利用率？

Hadoop团队立即采取行动解决了这个问题:

• 增加小型繁忙集群的集群大小，例如 Tmp 和 Ingestion 集群；
• 重新平衡所有 HDFS 节点之间的磁盘容量使用
• 根据数据年龄进行数据块平衡和放置

采取行动后，我们再次研究了最繁忙的 HDFS 节点的前 10%。 我们发现小而繁忙的集群消失了。 然而，前 10%（或 558 个）最活跃的主机都在主 HDFS 集群中，该集群拥有 3,000 多个数据节点。 这提出了另一个问题：为什么它们都在最大的 HDFS 集群之一中？ 进一步研究表明，这 558 台主机有一个共同点：它们与新添加的 YARN 服务共置一处，以充分利用 HDFS 服务未使用的硬件资源。

为了了解并置 YARN 服务对 HDFS 主机的影响，我们再次检查了整个磁盘 IO 利用率，并根据主机上运行的服务比较了所有磁盘 IO 利用率。 差异非常显着：同时采用 HDFS 和 YARN 工作负载的磁盘比仅运行 HDFS 的磁盘具有更高的 IO 利用率。

在主机级别，混合部署yarn和hdfs的磁盘 IO 利用率更为显着：共置 YARN 服务在每个主机级别为 HDFS 节点带来了更高的 IO 请求。

什么是长期战略?

YARN服务的大量磁盘IO操作不仅损害了IO性能，而且占用了磁盘空间，产生了更高的磁盘故障率，增加了主机日常运行的额外成本。 我们认识到这些挑战，并决定在我们的下一代 HDFS 服务器中添加一个专用 SSD 来处理来自 YARN 服务的磁盘 IO 请求。 这将以部分成本消除 YARN 托管引入的所有负面影响。 与此同时，Spark 团队提出了一项远程 shuffle 服务，该服务将减少约 50% 的本地磁盘写入，并将在未来几个月内推出。

我们相信，所有出色的工程胜利都来自于对我们的应用程序的充分理解并围绕这些用例制定工程决策。 如果使用您的侦探技能来确定如何优化大数据并使我们的数据基础设施更有效地吸引您，请考虑申请我们团队的职位！