大数据存储：扩展Hadoop的十大要点

20世纪90年代，每台应用服务器往往都拥有直接连接存储(DAS)。创建存储区域网络(SAN)，是为了提供共享的存储池，以获得更大的规模和更高的效率。Hadoop逆转了这股潮流，让DAS重新流行起来。每个Hadoop集群都有自己的、横向扩展直接连接存储。它有助于Hadoop管理数据局部性，但是牺牲了共享存储的规模和效率。因此，如果你有Hadoop发行版的多个实例，就会有多个这种横向扩展的存储孤岛。

Hedvig公司的首席执行官兼创始人阿维纳什·拉克希曼(Avinash Lakshman)说：“我们遇到的大挑战就是，兼顾数据局部性与规模和效率。”

数据局部性是指确保大数据集存储在执行分析任务的计算资源附近。对于Hadoop来说，这就意味着管理数据节点(DataNode)，而数据节点为MapReduce拥有足够好的性能提供了存储资源。它可以高效地工作，但是导致了另一个操作问题：大数据存储孤岛。本文介绍的这些要点有助于管理Hadoop环境中的大数据存储。

1. 分散式存储

集中式存储作为传统架构已有一段时间。但是大数据其实并不适合集中存储架构。Infogix的金融服务行业(FSI)战略和运营经理森希尔·拉贾曼尼坎(Senthil Rajamanickam)表示，Hadoop旨在让计算资源更接近数据，同时充分利用HDFS文件系统的大规模横向扩展功能。

然而，解决Hadoop管理自有数据的低效问题的常见方法，一向是将Hadoop数据存储在SAN上。而这带来了性能和规模方面的一系列瓶颈。现在，你的所有数据都通过集中式SAN控制器来处理，而控制器破坏了Hadoop的分布式、并行化的特性。你需要为多个数据节点管理多个SAN，或者将所有数据节点保存到一个SAN上。

拉克希曼说：“由于Hadoop是一种分布式应用系统，它应该可以在分布式存储上运行，那样你的存储保持与Hadoop本身一样的弹性。这需要你积极采用软件定义存储方法，在商用服务器上运行，但是它比把Hadoop放在传统SAN或NAS技术上高效得多，因为后者给Hadoop造成了瓶颈。

2. 超融合vs分布式

不过要小心，别将超融合与分布式混为一谈。某些超融合方法是分布式的，但这个术语通常意味着你的应用程序和存储可以共同驻留在同一个计算节点上。解决数据局部性问题很诱人，但是这会造成严重的资源争夺现象。 Hadoop应用和存储平台将争夺同样的内存和处理器资源。拉克希曼表示，最好在专用的应用层上运行Hadoop，在专用的存储层中运行分布式存储，从而充分利用缓存和分层技术，以解决数据局部性和网络性能开销。

3. 避免控制器阻塞点

他强调了做到这一点的一个重要方面――避免通过单一(或可能两个)点(比如传统控制器)来处理数据。通过改而确保存储平台并行化，就能显著提高性能。

此外，这种方法提供了增量可扩展性。为数据湖添加容量就跟添加几台内置闪存或旋转磁盘的x86服务器一样简单。分布式存储平台可在必要时自动添加容量、重新均衡数据。

4. 重复数据删除和压缩

驾驭大数据的一个关键部分是重复数据删除和压缩。Hedvig看到常见的大数据集可以缩减70%-90%。在PB级规模下，这意味着可节省数万美元的磁盘成本。

拉克希曼说：“现代平台提供了内联式(而不是处理后)重复数据删除和压缩。这意味着，如果不先以某种方式来缩减数据，数据永远不会进入到磁盘，这大大减少了存储数据所需的容量。”

5. 整合Hadoop发行版

许多大组织都有多个Hadoop发行版。可能是由于开发人员需要访问多个“版本”，或者业务部门久而久之采用了不同的版本。不管怎样，IT总部常常最终负责这些集群的日常维护和操作。大数据数量真正开始影响业务时，存在多个Hadoop发行版会导致效率低下。

拉克希曼说：“你可以创建一个单一、经过重复数据删除的压缩数据湖，然后它可以为Hadoop的多个实例提供数据，从而获得数据效率。”

6. 对Hadoop虚拟化处理

虚拟化技术在企业界刮起了一场风暴。在许多地方，如今超过80%的物理服务器已虚拟化。不过由于性能和数据局部性问题，许多人避免了对Hadoop进行虚拟化处理。

拉克希曼说：“你可以对Hadoop或Spark进行虚拟化处理。”

7. 构建弹性数据湖

构建数据湖并非易事，但大数据存储的需求可能需要数据湖。有许多方法可以着手构建，可是哪一种才是合适的方法?合适的架构有望构建一个活跃、弹性的数据湖，可以存储来自所有数据源、采用多种格式的数据，包括结构化数据、非结构化数据和半结构化数据。更重要的是，它必须支持就在数据源处执行应用程序，而不是从远程源处执行，那样需要移动数据。

遗憾的是，传统的架构和应用程序(即非分布式)并不令人满意。由于数据集变得更庞大，必须将应用程序移到数据，而不是将数据移到应用程序，因为那样延迟太长。而有了Hadoop/Spark，分析工作流变得更具破坏性了，因为数据和应用程序从不同的孤岛来执行，迫使数据移动并存储到多个平台上。

日立公司大数据分析高级产品营销经理弗雷德·欧(Fred Oh)说：“理想的数据湖基础设施能够存储单一数据副本，并且让应用程序针对单一数据源执行，没必要移动数据或制作副本(比如在Linux、虚拟机和Hadoop之间)。”

8. 集成分析

分析不是一种新的功能，多年来它就存在于传统的RDBMS环境中。不同之处在于，出现了基于开源的应用程序，以及能够将数据库表与社交媒体和非结构化数据源(比如维基百科)集成起来。关键在于，能够把多种类型和格式的数据集成为一种标准的数据，那样就能更轻松、更一致地完成可视化和报告。拥有完成这项工作的合适工具集是确保任何分析/商业智能项目成功的关键。

欧说：“说到分析，重要的是要明白真正的挑战不在可视化，而在数据集成，尤其是集成来自多个数据源、采用多种格式的数据。一套全面的数据集成工具和基于GUI的集成控制台可以克服企业在大数据方面的挑战。”

9. 大数据遇上大视频

大数据够糟糕，大视频更是为这个现象添加了压力。比如说，企业日益使用视频监控，不仅仅出于安全性，还为了提高运营和工业效率，简化流量管理，支持监管合规及另外几种使用场合。很快，这些数据源会生成大量内容。那些要处理大视频的企业最好确保为此建立了合适类别的数据存储系统，无论是不是基于Hadoop。

欧说：“这些应用程序正在带来大量的视频数据，要是没有合适的专用存储解决方案，这些数据会带来诸多问题，比如数据丢失和视频质量下降。”

10. 没有赢家

最近Hadoop无疑攻下了许多地盘。所以，随着数据存储量急剧增长，它会是最终赢家，击败其他所有方法吗?不太可能。

比如说，由于OLTP方面的固有优点以及要求100%的可用性，基于SAN的传统架构不会在近期被取代。但是如果需要分析以及与非结构化数据(比如社交媒体)集成，那么评估超融合平台就有引人入胜的理由，因为超融合平台将服务器计算、分布式文件系统、Hadoop/Spark和更新颖的数据库应用软件与基于开源的分析工具整合起来。

因此，最佳方法将超融合平台与分布式文件系统整合起来，并集成了分析软件。基于Linux的传统RDBMS应用(DWO和数据市场等)可满足这个用途，Hadoop/Spark/MapReduce则应对新的社交媒体挑战，使用服务器虚拟化提供了灵活性和效率。但是这每种环境都可能形成不同的数据孤岛。理想的方法就是同时支持这三种环境，并增添这种功能：可在数据源处执行应用程序，并减少分析工作流中的数据移动。

欧说：“成功的关键在于实施的系统考虑到了可扩展性、分析集成和专业知识。最终，存储专业人员需要预料未来的要求，而不仅仅着眼于存储。”