为大文件数据应用配置存储

　　大多数有关大数据分析的讨论均涉及由网络流量，交易数据库或者程序输出产生的以百万数量计的小文件。但事实上是，有关大数据的讨论不应局限于此，我们也需要关注如何处理大型文件和大型数据。使用场景会包含“大数据归档”以及类似的应用，在针对大文件存储的存储设计时，也需要将其独一无二的特性考虑进去。

　　大文件数据的定义

　　通常说来，大文件数据会包含图片或者影像数据，一般会是电影或者电视。这些场景的制作过程会产生大量的数据，但最终的产品却不一定会占用如此大的空间。通常针对不同的观看平台和市场会有不同格式和类型的数据源。并且这类型的数据还在不断增长，随着新兴技术的发展，高清，3D，4K等等场景的需求，在增加影片分辨率的同时也在增加对这类数据存储处理的需求。影像市场的发展也带动了电脑摄像头以及廉价的摄影器材市场。有关于这类会动的图片，文件大小与影片长度相关，是几小时的还是几天的录制。另外，摄像工具的分辨率也和文件大小相关，例如需要和手机级别的百万像素摄像头拍出来的照片放在个人存储上看的效果类似。

　　基于卫星的遥感技术以及空间图片拍摄是有关图片文件增长的新兴应用场景，不管是其中的哪种，随着新一代卫星的发展，像素的增高，势必带来的是文件大小的增长。

　　类似的例子是和科学研究相关的射电望远镜。在下一个十年，有一项关于在更广泛区域中使用多个射电望远镜的计划预期将每天产生1PB的新数据。

　　就像“不可移动的物体”那样，在现有架构下大文件归档终究会有一天大到不可被管理。

　　大文件数据处理真的这么重要吗？

　　不可移动的物体。当存储系统达到了无法再扩展的容量的时候，或者访问延时和吞吐量达到极限的时候，通常就到了需要迁移到新系统的时候。然而对于大文件数据应用而言，迁移几乎是不可能实现的。很少有业务或者组织会允许足够的宕机时间来迁移数PB级别的数据，尤其是当新数据还在不断往里写入的时候。就像那个术语“不可移动的物体”，大文件归档有一天真的可能大到传统架构无法管理。

　　就像修房子那样，一旦架构建立好且进入运行，通常就很难改变。正因为如此，大文件数据存储架构设计之初就需要考虑最大可能的升级灵活度，且升级过程中尽可能小影响。

　　长期保留。对数据长期保留的需求不仅限于大文件数据应用，任何文件到了10GB或者100GB以上的时候，对这些数据的保留就很快成为了一个问题。数据保留问题与大小关系不大，但问题是人们需要保留的这些数据通常都是影像数据。例如像视频或者音频数据。

　　长期数据保留一直以来均来自法规的需求，而现在长期保留数据的需求则可能来自于对这些数据的重新使用或者从安全角度考虑。一个好例子就是监控录像。过去录像由于法规需求就都归档保存起来，而现在保存则是因为要分析消费者的消费行为习惯。为了存储这些数据也同时意味着增加运营商的成本消耗。要将成百TB级别的数据保存数年不是一件小事，但是更需要考虑的是保存这些数据所需要耗费的电力，存储空间以及即便是最廉价的磁盘存储上的花费。

　　人力消耗。在许多的大数据分析应用里，由于分析是由计算机产生的，因此数据大都存储在相同的数据中心里，并通过Hadoop集群进行管理。但是对大文件数据场景，这些数据通常是人为分析，但人并不会住在数据中心里。当人们希望在家里的平板电脑上分析或者在回家路上用智能手机进行分析时，存储架构就需要以更合适的方式交付数据。

　　大多数文件都是按顺序分析的，故而需要流化操作，通常通过低带宽的连接方式，并且这些大数据文件也不能被切片和重组。为了能支持这样的类型，许多大文件数据存储池都会需要一个随机访问存储池，这样当开始传输的时候就可以连续不断的传输数据，同时也缓存剩下的数据。但是数据存储层需要足够的大且足够的可扩展，因为不仅需要能包含文件的第一部分，还需要能支撑归档不断增长的需求。

　　设计大文件数据存储系统

　　为了应对大文件数据所特有的挑战，存储架构的设计需要特别的考虑。比如说，不可移动的对象方面的挑战意味着需要将灵活性最大可能的考虑进去。除此之外，架构本身也需要允许存储系统能够在线扩展，以类似搭积木的方式。不仅作为一个可扩展存储，这些系统通常需要囊括多种类型的存储型号以及全局文件系统。它们需要能够在磁带存储最长名称的数据，并且为了特定的应用增加磁盘存储节点。这种混合类型的存储方式可能需要磁盘不仅具有高性能，高容量，有时候甚至需要和闪存盘混合使用。

　　举例说明，SGI公司的DMF能够实现横向和纵向的扩展，意味着一方面可以并行扩展以增加性能处理节点，同时容量上也能同时扩展以保证成本维持在恒定单位水平。这类模块化的架构同样包括了后端的并行数据处理节点能够提供快速的文件访问后端资源能力。带来的结果是，虽然是同一品牌的产品，在不同场景和需求下部署出来的结果也是不尽相同的。

　　一家大型提供天气分析服务的政府机构在过去的20年中经理了数据爆发式增长的过程。如今他们所管理的数据总量已经超过了60PB，系统后端每天需要处理近300TB的数据，与此同时需要提供超过每秒100GB的文件访问吞吐能力给NFS客户端。正是在基于SGI公司的DMF系统的52个1U服务器节点配置才能让他们完成这样的任务，每个1U节点提供2GB每秒的吞吐量给前端客户端。6个1U后端数据处理节点以光纤通道的方式提供60GB每秒数据的吞吐服务，这样使得数据能在后端不同层级的存储之间移动。在这样的方式下，整个架构就以最优化且最省成本的方式以满足不断增加的性能要求。

　　LTFS线性文件系统让磁带成为大文件数据的选择

　　LTFS线性磁带文件系统是基于文件开放格式的跨平台文件系统，它本身由LTO联盟开发并兼容不同类型的LTO磁带。通过在每个磁带上创建索引分区，LTFS允许存放在磁带上的文件可以类似磁盘的方式实现搜索功能。明确说来，这类型文件仍然是需要被线性传输的，但LTFS本身增强了磁带在这方面的功能。除此，LTFS还实现了每个磁带盒“自我描述”功能，用户能很快大致知道磁带里面的文件是什么。

　　磁带对于大文件数据系统尤其重要

　　考虑到对大文件数据存储池大小的需求，以及事实上许多数据本身并没有明确的过期时间，就暗示了我们使用磁带的可能性。传统方式下很难从经济角度考虑存放这些数据的可能性，此外还有电力成本的损坏，空调的费用以及存放这些设备所需的物理空间租赁费用等等。

　　除了成本方面的考量，磁带本身也有不少让人羡慕的性能优势，尤其是在处理大文件需要将流数据从资源池中拿出和放入的时候。拿LTO-6举个例子，能够提供每秒160MB的文件吞吐能力。若能良好的设计，前端放上足够随机访问的存储，例如闪存，磁带就可以以较为有效的方式作为大文件数据的存储。

　　传统看来，基于磁带的归档方式还是有些复杂。大文件以文件的形式存放在文件系统上，而磁带却不能以文件的形式存放。因此这些架构需要能够基于文件的接口到用户和应用前端的特殊的归档软件以实现，同时也需要能够与后端的磁带驱动器通信。如今，线性磁带文件系统LTFS，作为开放系统磁带接口，简化磁带访问的同时也能提升其灵活度。

　　Spectra Logic公司最近发布了一款名为“深度简易存储服务（DS3）”的服务。它起到亚马逊S3接口类似的功能，此外增加了顺序数据移动和移动存储介质的支持。最终实现了为磁带准备了REST接口，使得访问互联网亚马逊S3接口的应用也能支持直接访问他们的磁带。DS3另外还支持将磁带和对象存储通过REST API接口直接连起来。

　　BlackPearl是支持Spectra DS3接口的一款设备，它能以固态存储的方式在前端将缓存提供给客户端，与此同时还能处理与后端磁带驱动器的即时通讯。它还能实现对磁带上数据的安全及长期完整性方面的管理，以及对LTFS线性磁带文件系统的自由转换。

　　然而大文件数据存储需要不仅仅是磁带库和磁盘缓存的组合。假设对大文件有访问方面的需求，对象存储系统就是很好的选择因为它们通常具有很好的横向扩展能力，能高效的扩展到上PB级别，相比传统基于RAID的存储系统更有效率。

　　对象存储的优势

　　大文件数据存储系统现在的构建模式为多磁盘层级以满足实时分析及快速访问形式，亦有磁带层级作为长期归档层级使用。例如像昆腾公司的对象存储系统Lattus，能够提供足够大容量的存储空间给前端，甚至还能提供大容量的基于磁带的大文件资源池以支撑全局可用性，常用于动画制作以及广播行业。使用复杂的分析技术，这些公司可以实现将文件按照地理区域存放，这样就可以以就近原则访问这些数据，此外在访问前，甚至可以实现“批量迁移”至合适的存储层级上。

　　昆腾公司的StorNext文件系统和数据管理系统以模块化的架构设计，且允许元数据处理从存储容量中剥离出来以保持其独立性。这项特性就可以允许用于在后端增加元数据引擎以支撑数据在磁带或者对象存储中更快的访问效率，同时亦可在前端扩展文件系统大小以满足不同用户来自不同平台的访问需求。

　　大文件数据的底线

　　大文件数据会带来一些特别的存储上的需求和挑战。看起来要求仅仅是能够存储海量数据且同时满足足够的吞吐量和访问性能，但传统的架构下已经不再合适。这些系统需要足够的灵活以至于能够支持多个不同类型的随机访问存储及磁带，允许用户在保持数据不动的情况下能够在线升级和做变更。此外，还需要一套高可扩展性且经济的磁盘，就像对象存储那样，以满足流方式下大文件或者小文件传输的需要。

　　大文件归档需要引入磁带的支持同时也需要将数据以开放格式写入后存放，例如像LTFS这样的线性磁带文件系统，以满足支持多用户在不同平台的访问流程需求。磁带需要使用支持REST的接口形式而不是传统的专有归档软件所具备的形式。这将帮助应用和磁带之间的直接连接，对象存储甚至可以连接到互联网上，这也是大多数大文件数据存储池将会支持的形式。