对数据位置和处理位置做出明智的决策是关键。
近来，我参加了一些会议，从而注意到一个潜而未显的话题。人们将大量的注意力集中在转移到（混合云）基于云的架构，以及那个架构需要什么上，但同时一些演示表明，每个人都意识到了一个有意思的整体发展趋势，但这个发展趋势并没有引起大多数人的高度关注：世界上存储的数字数据在急剧增长。
最吸引我的一个演示来自PureStorage（一个存储供应商），它整合了两个供应商的数据点。首先，是思科于2017年6月发布的白皮书《泽字节时代：趋势和分析》，它推断了互联网带宽的增长情况；其次，是由Seagate赞助的IDC研究报告《数据时代2025》，它推断了世界上数据的增长趋势。PureStorage将这两个推断进行了整合，从而得出了如下图所示的结论（经许可再次使用）：
PureStorage所描述的世界数据增长和世界互联网带宽增长之间的冲突
未来几年，这些趋势——如果它们成为现实，我们有足够的理由认为这些预测是合理的——将会对计算和数据全局带来重大影响。注意：云是真实存在的，并且将会成为未来IT布局十分重要的一部分，但将它看作是治愈所有IT疾病的一个灵丹妙药却是十分天真的，就像在互联网泡沫中怀抱“新经济”梦一样。我们都知道那场互联网泡沫是如何收场的。
无法逃避的问题
不管怎样，所有IT都有两个核心元素：数据和数据的逻辑工作。大数据不仅仅是数据的问题。除非可以使用它，否则数据就是无用的（或者如Ludwig Wittgenstein所说：无用的）。人们处理数据的方式已众所周知：为了使用巨量数据，你需要将处理带到数据中，而不是将数据放进处理中。在任何“距离”处理数据造成了这样一个重大的传输瓶颈，以至于性能几乎消失殆尽，并且获取性能背后的逻辑也完全变成了一个理论上的事情。
甚至就算是少量数据，也有可能因为延迟而出现这种情况。举例来说，将应用程序的服务器迁移到云端，同时将数据库保留在本地在理论上是可行的，但如果应用程序对在云端和数据库之间的延迟十分敏感，那么就根本行不通。这种情况在少量数据的情况中也有可能发生过。这就是为什么许多企业正试图适应软件，以使它们变得对延迟不那么敏感，从而使迁移到云端成为可能。但是，对于巨量数据，你需要使处理数据的位置和数据所在的位置更加接近，否则就行不通。这就需要对数据进行大量并行处理，同时你会获得Hadoop（分布式系统基础架构）和其他架构。这些架构可以解决处理巨量数据的问题。
目前，全球数据总量正在大幅增长。如果IDC报道的内容可信的话，在几年的时间中，全球数据存储总量有望达到50泽字节，或者50,000,000,000,000,000,000,000字节。另一方面，尽管互联网移动数据的总体能力也会增加，但它是以一种十分轻松的方式。在全球数据存储总量达到50泽字节的这一段时间，互联网总的带宽将达到大约2.5泽字节每年（如果思科的数据可信的话）。
我们可以从这两个（合理的）预测中得出一个结论：到目前为止，可用的互联网带宽对移动全球相当大的数据总量是不够的。然而，这种情况正在被忽视，尽管存在当前80%的带宽被用以流媒体这样一个事实。因此，尽管你已经通过编码来解决核心应用程序的延迟性问题，但在巨量数据的情形下，还是会存在带宽问题。
这个问题现在真的是一个问题吗？除非在本地处理或使用那些数据——即在存储数据的同一个数据中心上。但另一方面，如果数据大幅增长，人们还是会追求云策略；即，将不同种类的工作负载放在云端，在极端的情况下，甚至还会出现“无服务器”（举例来说，AWS Lambda）。
假设我们可以从巨量的数据集中得出小部分的结果——这可能会有一点帮助，但巨量数据真正的价值来自于整合不同拥有者（举例来说，来自Twitter上的客户记录）的数据。聚合所有不同的数据集才是关键。
因此，我们便看到两个相互阻碍的发展情况。一方面，所有人都忙于适应基于云的基础架构，这个架构最终以对分布式的数据进行分布式的处理为基础。另一方面，我们使用的数据总量变得如此巨大，以至于我们必须在一个单个的物理位置整合和处理数据。
因此，这意味着什么？
好吧，我们可以期望，Hadoop在应用程序架构级所做的事情也可能会在全世界发生：巨量数据集对使之变得有意义的逻辑是一个吸引所在。并且这些巨量数据集将会被聚集起来。
一个恰当的例子是，现在许多人正急于减少对移动数据的需要。因此，在物联网世界，很多人都在讨论边缘计算：在传感器和其他物联网设备所在的地方处理数据。当然，这也意味着，你可以放心地认为，因为超出了一个传感器（组）的承受能力，你将不会获得同样级别的计算能力，就像在大量的分析设置中那样。或者换一种说法，不久以后，你将很有可能不会在车盖下看到Hadoop集群。因此，是的，你可以通过那种方法减少数据流量，但要以降低计算量为代价。
这个问题还有另外一个解决方案：聚集在数据中心周围。这也是我看到的正在发生的情况。主机代管供应商在不断增加。他们可以提供拥有最佳内部流量性能的大型数据中心。在这些数据中心中，云供应商和大用户团结在一起，相互支持。从逻辑上来说，你可能是在云中，但从物理角度来看，你和你的云供应商处于相同的情形下。你不会想要只在AWS或Azure运行你的逻辑；你想要在数据中心中也能进行那些任务。在这些数据中心中，你有属于自己的私有数据库，因此所有的数据对于处理来讲是本地的，对于数据聚合来讲也是本地的。我在其他地方提到过，云供应商可能会连接到你的数据中心，但对解决数据急剧增长过程中出现的无法避免的带宽和延迟问题来说，主机代管是另一个可行的解决方案。
情形可能并没有我所描述的那么可怕。举例来说，所有数据的实际平均波动性可能最终将十分低。另一方面，你不会想要在以往的数据上运行分析。但是，我们已经可以得出一个结论：简单地假设你可以将工作负载分配给许多不同的云供应商是十分危险的，尤其同时你正在使用的数据总量在大幅增长（情况确实将会如此，如果所有人都想要把他们自己的数据和来自Twitter、脸书等上的数据流整合起来，更不用这些整合的数据还会产生各种各样的数据流。）
因此，做出明智的战略设计决策（也称为“基础架构”）是关键，这包括决定数据所处的位置和处理数据的位置，以及（不）能与其他数据进行隔开的数据。战略设计决策…恩，这听起来像是一项针对基础架构的工作。
