扩展大数据网络的规模

Scaling Big Data fabrics

原文作者：Mike Bushong

原文地址：https://dzone.com/articles/scaling-big-data-fabrics

译者微博：@从流域到海域

译者博客：blog.csdn.net/solo95

扩展大数据网络的规模

当人们谈论大数据时，重点通常放在Big上。当然，大数据应用都大规模分布式(部署)是因为执行计算的数据(规模)的大小比典型应用能够处理的数据大得多。但是扩展提供大数据节点之间连接的网络不仅仅只是创建大规模的相互连接。

实际上，网络的规模可能是扩展大数据网络最不感兴趣的方面。

大数据到底有多大？

不久之前，我问了一个问题：一个典型的大数据部署(指部署起来的应用，下同)有多大？我期待着，正如我怀疑许多人的看法一样，标题中的“大”意味着部署(起来)将会是一个大问题。但平均的大数据部署实际上比大多数人意识到的要小得多。我在去年的一篇文章中在HadoopWizard中抓取了一份清单。

这份名单值得称赞的地方在于它指明了部署的规模其实是多么的微不足道。当然，这份清单是过时的，现在的部署肯定会变得更大。是的没错，像雅虎这样的公司正在推动扩展规模的限制。但如果你拿雅虎平均的部署而言！out(输出)仅仅有113个节点。即使每个节点多连接(直译多宿主，即multi-homed)到两台交换机，这也意味着平均部署时可以由4台接入交换机处理。

即使每个部署的规模翻了四番，您也只需要谈论16台接入交换机的部署。当我们的行业谈到扩展时，我们通常认为数量会超过16个交换机。

扩大规模是个问题吗？

因此，如果部署量很小，这是否意味着扩展是一个需要解决的问题？答案既是肯定的也是否定的。如果最终目标为每个大数据应用程序构建单独的网络，那么答案是肯定的。虽然公司需要的网络规模在一直变大，但绝大多数客户将在当今这个时间点受到扩展限制(指设备和技术等造成的扩展网络的限制)。

但问题在于，大数据并不仅仅是大数据。当我们谈论大数据时，我们通常应该使用不同的名字。对于大多数人来说，大数据跟Hadoop联系很少，更多的是关于集群应用程序（至少就网络而言）。通过将定义扩展到集群式应用程序，您可以跨过Hadoop并进入集群计算乃至集群存储环境。任何集群的东西都依赖于某种互连性。

集群环境中的挑战

所有这些类型的集群环境面临的挑战是它们的要求是各不相同的。对于Hadoop而言，作业完成时间主要由计算方面决定，因此网络实际上的作用是提供始终可用的无拥塞互联。对于集群计算，延迟可能更重要。而对于多终端(或译多租户)环境，隔离流量可能是最重要的。无论什么应用，关键是它具体的需求是跟使用环境高度相关的。

这将我们带回了扩大规模的问题。

扩展大数据网络的真正问题不在于把小型互连规模扩大。网络并不会沿着单一应用程序的规模去扩展（或者至少它们不应该这样）。实际进行中扩展的挑战是构建从单个大数据应用程序到托管多个集群式应用程序的环境的过程，每一个集群应用程序的需求都是不同的。

这看起来非常简单，但事实并非如此。现在当人们部署大数据应用时，大的部分把人们指向有大量数据工作负载基于目的构建的体系结构。在很多情况下，这包括构建针对特定工作负载的分割的网络。

但即使在最好的情况下，Hadoop也可以利用机架感知(Rack Awareness)等功能，这有助于提供应用程序的弹性，同时最大限度地减少网络中的流量。无论您是将此视为应用程序还是网络，最后邻近性和局部性都会集成到基础结构中。这在扩展时会产生需要注意的考虑（以及潜在的限制）。如果你想扩展一个集群，你不能使用任何数据中心中可用的服务器; 有些服务器由于其物理位置而完全优于其他服务器。

可伸缩性不仅仅是扩展或缩小

为这种类型的集群应用程序创建可伸缩的互连不仅仅是支持大量（或者如前所述，并不是那么多）的节点。可伸缩性的目标是从头到尾提供一条完美的路径。这意味着体系结构不仅需要考虑结束状态，还要考虑如何从这里到那里(即路径)。

借助Hadoop，这意味着像位置这样的事情必须成为架构互连时明确的考虑因素。横跨数据中心的一堆交叉连接是不是正确答案呢(即这种架构方式能不能解决位置问题)？也许。又或者，它可能是在集群服务器之间提供互连的一个不同的架构方法。

此外，它不仅仅是一个应用程序。当前带宽的构建是因为您拥有Hadoop-y这个非常好的应用程序可用，但如果下一代的集群应用程序对延迟敏感，又会怎么样？也许它会带来了一套更典型的HIPAA风格应用程序的审核和合规性要求？

如果体系结构没有明确考虑如何在单个应用程序之外扩展，即使它的规模可以增长到数千个交换机，它是也无关紧要的(即没有可伸缩性)。

最重要的关键点

这里的重点在于扩展的规模不仅仅会越来越大。而且种类也可能越来越多样化。如果说Hadoop部署的数字教会了一件事情，这件事情就是人们仍在尝试。如果您仍在尝试，您怎样确切地预测出未来的5年或10年对于您的业务应用而言意味着什么？您无法做出预测。这意味着最关键的架构目标可能远远超出部署中交换机的数量。可伸缩性可能在于为您的数据中心增加灵活性。即您如何将一堆不同的专用功能集成到一个单一的通用网络中？这个问题的回答可能是确定如何扩展大数据结构的真正关键。