欢迎关注大数据技术架构与案例微信公众号:过往记忆大数据
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
过往记忆大数据

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

以较低的硬件成本扩展我们的数据基础设施,同时保持高性能和服务可靠性并非易事。 为了适应 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个,即:成本效率、可用性和性能。


如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

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

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

硬盘有多忙?

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

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

    如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据
  • 坏的地方:部分硬盘 IO 利用率可高达15%以上,是平均硬盘 IO 利用率的5倍以上。尽管这些磁盘只是整个磁盘池的一小部分,但这也有数千个驱动器。

    如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

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

主机有多忙

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


如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

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

集群有多繁忙?

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


如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

数据告诉我们一个事实:集群使用率是磁盘 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 利用率。


如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

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


如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:过往记忆大数据

长期策略

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.

本文翻译自:Improving HDFS I/O Utilization for Efficiency

本博客文章除特别声明,全部都是原创!
原创文章版权归过往记忆大数据(过往记忆)所有,未经许可不得转载。
本文链接: 【Uber 是如何提高 HDFS I/O 利用率的】(https://www.iteblog.com/archives/10060.html)
喜欢 (0)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!