在今天，我们频繁地地接触到“大数据”这个术语。不过业内还是对大数据究竟是什么缺少一种标准化的定义。那么，大数据对数据存储基础架构中有意味着什么呢？
企业战略集团（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查询运行各项子任务的数据存储位置，而后将这些子任务发送到数据存储所在的计算节点。其实，它是将计算任务发送到数据端。各项子任务的结果会送回映射化简中心，进行整合并推导出最后的结论。