Uber 是如何提高 HDFS I/O 利用率的

问题导读

1.新的 CAP 理论，新在什么地方？
2.硬盘有多忙？
3.主机有多忙？
4.如何提高 HDFS IO 利用率？

以较低的硬件成本扩展我们的数据基础设施，同时保持高性能和服务可靠性并非易事。为了适应 Uber 数据存储和分析计算的指数级增长，数据基础设施团队通过结合硬件重新设计软件层，以扩展 Apache Hadoop HDFS ：

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

新的 CAP 理论

人们可能在许多与分布式系统相关的文章和论文的标题中看到过 CAP 定理，它指出：一致性、可用性和分区容忍度，这三个中只能选两个!

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




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

在接下来的章节中，我们试图分析当前 HDFS 磁盘 IO 利用率，以评估当多个数据服务在我们的下一代、行业领先的高密度硬件上运行时，我们是否会碰到 IO 瓶颈。


硬盘有多忙？


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

•好的地方：约 90% 的磁盘的平均 IO 利用率低于 6%。




•坏的地方： 部分硬盘 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 节点之间的磁盘容量使用；
• 基于 data age 的数据块平衡和布局
  

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

为了理解共存的 YARN 服务对 HDFS 主机的影响，我们再次检查了整个磁盘 IO 利用率，并根据主机上运行的服务比较了所有磁盘 IO 利用率。差异是显著的：同时接受 HDFS 和 YARN 工作负载的磁盘比只运行 HDFS 的磁盘有更高的 IO 利用率。



在主机级别，汇总的磁盘 IO 利用率更为显着：共存的 YARN 服务在每个主机级别为 HDFS 节点带来了更高的 IO 请求。





长期策略

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

Apache®, Apache Hadoop®, and Hadoop® are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks.

最新经典文章，欢迎关注公众号

原文链接：
https://mp.weixin.qq.com/s/-Bss_RtbvAQfcW1y6goq4w

。。。 高 io 服务器多数是 由于并没有只做一件事导致的 。