应对大数据的存储准备

在今天，我们频繁地地接触到“大数据”这个术语。不过业内还是对大数据究竟是什么缺少一种标准化的定义。那么，大数据对数据存储基础架构中有意味着什么呢？

企业战略集团（ESG）对大数据作出的定义是“大小规模超过常规处理能力边界的数据集，它使得你不得不采取非常规手段。”简单来讲，我们可以将大数据这个词使用在任何突破了传统IT处理支撑日常业务运作能力边界的数据集合上。

这些边界可能会出现在以下几种情况下：

?过高的交易数据量导致传统的数据存储系统达到了瓶颈，无法及时地完成各项运作任务。简单来说其无法提供应对如此多的I/O请求的处理能力。在有些时候，用户环境内的磁盘转速无法应对所有的I/O请求。这往往使得用户在每块磁盘驱动器上放置很少一部分数据并采取“短击控制”。这意味着通过使用磁盘的很少一部分来增加每GB数据的整体转速，即使用更多的磁盘驱动器来处理I/O。这种情况也会导致用户部署许多存储系统并行使用，但却因为性能瓶颈而不使用其全部的容量。或两者兼而有之。这种方式代价高昂，是的购买了过多的磁盘驱动器而其中的绝大部分是空的。

?数据（单独的记录、文件或对象）尺寸使得传统的系统没有足够的吞吐量及时传输数据。这可能只是由于没有足够的带宽来处理交易量。但带宽所带来的挑战却非常严谨。我们看到许多企业采用“短击控制”来增加系统带宽，也增加了驱动器数量，而这又导致了低利用率和增加开销的问题。

?整个卷容量超过了传统的存储系统容量所能承受的阈值。简单来讲就是存储系统无法提供足够的容量来处理卷内的数据。这会导致存储蔓延成几十或上百个存储堆栈，又由数以十计或百计的管理节点进行管理，造成利用率低下，并消耗了大量的占地空间、能源和制冷。

这些症状同时出现时就会变得非常严重——没有什么可以证明用户不会同时面临大文件所组成的大量数据，并且要求大量I/O的要求。事实上，大数据这个词最开始出现在一些特殊的垂直行业的IT需求讨论中，诸如医疗和娱乐行业组织，以及石油和天然气公司。

支持大数据的存储基础架构

我们正在存储基础架构中寻求一种全新的变革方式来处理和大数据相关的日益增长的数据容量。每一种方式的特点都不尽相同，但又互有重叠。

在对I/O敏感的高交易量事务处理中，ESG发现应用了大量可以通过增加磁盘进行纵向扩展的基础架构方式。这种系统是诸如EMC VMAX、IBM DS800以及HDS VSP等公司最传统的解决方案。

在大文件尺寸的应对方面，前沿的企业在几年之前就开始采用横向扩展的系统，配置足够的带宽来处理大文件尺寸，从而解决大数据的问题。这类系统包括DataDirect Networks、Hewlett-Packard Ibrix、Isilon（现被EMC收购）以及Panasas等。这些系统通过纵向扩展（增加磁盘数量）以及横向扩展（增加带宽和处理器能力）来满足性能所需。随着大数据尺寸的问题变得日益常见，这些系统中的一部分也在寻求更为主流的商业应用。这些更主流的环境中通常混合着I/O和吞吐量敏感的高性能要求，因此横向扩展和纵向扩展的能力都必须具备。

最后，在内容容量方面，我们正看到横向扩展、基于对象的存储基础架构系统可以在单个简易的管理系统中更轻松地扩展至数以百亿的数据对象。这类系统的优势在于其更易于管理和跟踪鲁棒的元数据，并且设计可以使用高密度、低成本的硬盘驱动器，就像Dell 的DX那样。

关于Hadoop

没有哪项大数据的应用和分布式计算毫无关系。分布式计算所具有的以合理的成本加快业务分析周期（从数周缩短至数小时甚至分钟）的能力对企业非常有吸引力。这种开源的技术通常运行在廉价的服务器上，使用并不昂贵的直连存储（DAS）。

分布式计算用于处理大量的数据，并且由两部分构成：映射化简（MapReduce）和分布式文件系统（HDFS）。映射化简处理管理计算机任务的工作，而HDFS自动化地管理数据存储于哪一个计算机群（从而降低开发设备的负载）。当一项计算任务启动后，映射化简接管这项任务，并将其分解成可以并行运行的子任务。映射化简会向HDFS查询运行各项子任务的数据存储位置，而后将这些子任务发送到数据存储所在的计算节点。其实，它是将计算任务发送到数据端。各项子任务的结果会送回映射化简中心，进行整合并推导出最后的结论。

相比之下，传统系统需要一台非常大型而昂贵的服务器，配置足够强劲的计算能力，以及一台同样代价高昂的存储阵列来完成相同的任务。传统系统需要以一种相对连续的方式读取所有所需数据、运行分析操作并获取结论，在相同的数据量下，相比基于分布式计算的映射化简任务处理方式需要更长的处理时间。

这其中的不同可以这样简单概括。假如一家杂货店中有20个人要通过同一个收银台。假如每个人购买价值200美元的商品，并且需要2分钟来完成其所有采购货物的扫描。那么即便是最佳雇员也需要40分钟来处理这4,000美元的货物采购。不过如果采用分布式计算的方式：会有10个收银台，每个收银台只是配置一位低成本，兼职的高校学生，其处理每一项交易需要额外的50%时间（3分钟）。那么同样20个人只需要6分钟，而你仍可以获取4,000美金。从业务角度来看，将一项工作时间从40分钟压缩到6分钟意味着什么？利用多出的34分钟你又可以完成多少额外的工作？你可以进行更多的调研并对于市场趋势有更快的了解？这在业务方面就类似于你无须等待很久就能够得到所要的分析结果。

分布式计算也并非完美的方案。集群文件系统非常复杂，并且很多时候这种复杂性隐藏在HDFS管理员端建立分布式集群并使其高效运行需要花费大量的时间。此外，在HDFS中，保持所有数据位置（元数据）路径的数据映射（或称为命名节点，NameNode）在最新发布的Apache分布式计算中存在单点故障——其中一部分重要问题将会在下一个计划发布的主版本中解决。数据保护也依靠管理员进行控制；数据复制设置决定了每个数据文件在集群内复制的次数。默认的设置是3次，而这会使得整体容量较实际使用容量扩大了3倍。而且这只是本地集群内部的保护；远程站点内的备份容灾在现有版本的分布式计算中还未被考虑。要记住目前市场上还没有分布式计算的大牌专家；不过，诸如Cloudera、EMC以及MapR等公司目前在培训方面扮演着重要角色，而成形的专业团队仍需时日。这也是不应当被忽略的一件事。最近的研究显示利用这方面外部咨询服务的成本每年高达250,000美元。

大数据，更大的事实

以上各类不足，结合上该商业领域的巨大潜在市场，使得诸如EMC、IBM和NetApp等大型存储厂商关注着大数据的市场机会。各家厂商都发布了（或者其指日可待）设计用于分布式计算环境的存储系统，在可管理性、可扩展性以及数据保护方面帮助用户克服HDFS的欠缺点。其中大部分可以用开放式接口（比如NFS和CFS）替换HDFS存储层，而另一些提供其自有的映射化简框架版本，提供较开源分布更好的性能。一些提供可以填补开源HDFS差异的特性，比如通过标准的NFS和CFS接口在其它应用之间共享数据的能力，或者是数据保护和容灾方面的功能。

NetApp则采取了一种完全不同的方式。其内置了开源的分布式计算标准，并在数据节点上使用DAS。不同于以分布式计算的名义使用自有的文件系统，NetApp在低端的Engenio平台上使用SAS连接的JBOD充当DAS。而在命名节点方面，其使用NFS直连的FAS箱来提供从一个故障命名节点的快速恢复。这是“两个领域最佳”的混合的解决问题的方式。

市场是否会愿意购买更为可靠或更具应用潜力的工具，这仍有待观察，现在断言还为时过早。

大数据是真实的存在的，并且各不相同：不同类型的大数据需要不同的存储方式。如果你已经面临大数据的各项问题，面临一些阻碍，这表示你应当采取一些不同的方式，和供应商谈论需求的最佳的途径是直指问题本身，而不要围绕着大数据这个话题。你应当谈论业务问题和案例情况，这有助于将问题细化到某一特殊的负载上。这样你就能快速找到对应的存储解决之道了。

(责任编辑：蒙遗善)