数据存储主要有两种方式：Database和FileSystem,后面发展出了Object-oriented storage,但是总的来看就是存储结构化和非结构化数据两种。 DB开始是为了结构化数据存储和共享而服务的。FileSystem存储和共享的是大文件，非结构的数据，像图片，文档，影音等。随着数据量的增大，单机存储已经不能满足结构化和非结构化数据的需求，那么在云计算的时代，就出现了分布式存储和分布式数据库的解决方案。
1，File System, Object-oriented storage
那么对于非结构化数据存储就出现了分布式文件系统(Lustre)，分布式对象存储系统(Ceph/S3)，P2P存储系统(Oceanstore)等。
(1)像Lustre这类的分布式文件系统在HPC领域应用很广，对于文件系统底层硬件的要求相对比较高，一般是SAN和磁盘阵列这样的高端存储。所以这类文件系统的IO性能会比较高，背后的代价就是成本比较高。这类存储产品一般用在银行、证券、石油、航天等领域。
(2)像Ceph/S3这样的面向对象存储是目前非常火的一种非结构化数据存储方式。这是顺应云计算大潮的一种存储方式，用户存储提供的不再是POSIX文件系统接口，而是通过REST等方式访问云端数据的接口，用户不需要维护和管理任何存储设备。而且云计算服务提供商会提供相应的SLA来保证IO性能和数据的reliability以及availability，所以这种方式对于用户很受欢迎。在现在互联网开放平台的大潮中，各种各样的API就是用户构建应用的基础，而API背后的服务就是基于云提供商的。在各种云计算服务中，云存储服务是其中最重要的。在云计算领域提倡数据和应用分离，例如Amazon推荐使用EC2的用户把数据存到S3中而不是存放在自己EC2 Instance的本地硬盘上。最近国内最像Amazon的云计算服务提供商盛大云出现了用户数据丢失的情况，仔细研究了下发现是用户云主机(类似于EC2 Instance)上的数据丢失了，原来是云主机没有备份机制，所以云主机磁盘出了问题就会导致数据丢失。从AWS(Amazon Web Service)和GCE(Google Compute Engine)的官网可以知道，这两家顶级的云计算服务提供商都不提供云主机的本地磁盘备份机制。我们可以这样理解，在这种计算模型下，云主机EC2 Instance相当于计算机的CPU和Memory，不具备持久化功能;而云存储S3具备持久化存储功能，相当于计算机的硬盘。所以可以把整个云看成是一个新型的计算机体系结构。
(3)像Oceanstore这种P2P存储的方式，在大家共享影音文件方面的应用比较成熟。比较典型的包括当时的eMule,Maze等。影音文件一般比较大，我们相当于把它存放在广域网/局域网的大的存储池里，这样用户之间都可以就近下载东西，而且用户自己也充当服务器的功能为别人提供下载的来源，省得每次都去中央服务器那下载，带宽的bottleneck解决了。但是这类存储一般不能保证延迟，用户在下载一个电影可能需要几分钟，那么用户不太关心中间的传输速度是不是有什么波峰波谷，只要总的带宽比较高就行了，根据“文件大小/带宽=传输时间”只要传输时间最小就行了。但是我觉得随着云计算云存储的普及，主要的云计算服务提供商会在全国铺设多个存储和计算的数据中心，这样就可以分散主数据中心的带宽压力，形成粒度很大的类似P2P的存储网络。而且随着CDN技术的发展，还有就是网络带宽的不断提高，P2P这种模式的发展可能会受到制约。
2,Database, Data warehouse, Big Data
说完FileSystem，就该说DB了。RDBMS设计的初衷是为了存储关系型数据，也就是存储的数据之间存在着各种范式的严格要求。但是现实世界中的数据不是都那么严格规范化的，尤其是越来越多的机器和人类社会活动中产生的数据(如用户浏览互联网的日志数据，社交网络数据，医疗诊断数据，交通数据，金融交易数据，电子商务交易数据等)是半结构化或者非结构化的。这些数据同样有存储和分析的需求，而且这些数据中往往蕴藏着极大的商业价值。对传统RDBMS中的关系型数据的分析是数据仓库DW干的事，即分析的对象是各种关系型数据。那么对于这些非结构化数据的分析就不像DW那么简单了，除了我们常见的DW的功能，我们在对这些“大数据”的分析中又出现了回归，聚类，分类，关联分析等机器学习的需求，那么在“大数据”时代的分析平台就不像数据仓库DW那么简单了。
那么对半结构化和非结构化数据存储和分析的需求，催生了NoSQL数据库的诞生。提到NoSQL数据库，我们发现现在的NoSQL数据库和RDBMS类似都有两方面的需求：OLTP和OLAP。当然我觉得这两个术语放在这不太合适，毕竟OLTP中的T(Trasaction)现在大多数NoSQL数据库是不提供的，所以这两个词只是形象的表示下，从严格意义上是不对的。通俗的解释这两方面的需求就是：用户对数据的在线存储访问;离线分析型应用对数据的访问。前者主要是对数据的CRUD操作，用户在线访问数据比较关心访问延迟，同时尽可能高的提高吞吐。后者呢主要是对数据的一次写多次读操作，应用访问数据不太关心延迟，只在乎吞吐量。那么我们可以把这两种典型应用对应到以前的数据库DB和数据仓库DW。同时在“大数据”时代，数据的分析型应用已经不仅仅局限在数据仓库DW的范畴内，以聚类，分类，关联分析为代表的机器学习应用也是重要的需求。
在“大数据”时代数据存储和处理的事实标准Hadoop生态系统中，大多数人把它认为是数据仓库DW在大数据领域替代品，更多的人也是把Hadoop用到以数据挖掘和机器学习为代表的分析型应用的场景中。但是我感觉从整个生态系统中还是能看到数据库DB的影子的。下面这张图是Hadoop生态系统的主要组件，从架构上看是面向分析型应用的。但是其中的HBase已经在一些大公司用在实时在线数据的存储中了(Facebook的统一消息系统和Apple的iCloud)。HBase作为一个在线数据存储和访问的数据库主要的几个问题是：底层HDFS的HA还没有稳定下来;没有一个保证数据完整性的机制(例如事务或者类似的机制);没有一个统一的访问接口(类似SQL)。相信这些问题解决了，以HBase为代表的NoSQL数据库在在线数据存储访问方面会更进一步。
而在分析型应用市场，Hadoop可谓所向披靡，已经成为大数据分析的事实标准。目前用的最多的就是把RDBMS里面的关系型数据导入HDFS中，然后用MapReduce进行分析(淘宝会把用户的交易数据从RDBMS中导入HDFS上然后用MR进行分析和挖掘);或者把日志数据放到HDFS用MapReduce进行分析(百度的搜索日志分析)。但是目前对于这些半结构化或者非结构化数据的元数据管理还不太成熟和统一，图中的HCatalog就是为了完善这一部分功能而开发的，有了它Hive和Pig的使用会更加便捷。另外一种就是在HBase中产生的数据，直接用基于HBase的MapReduce进行处理和分析，这个就有点像Greenplum或者Teradata做的基于RDBMS的分布式数据库产品了。由于基于Hadoop的分析平台有很多机器学习的计算需求，而很多机器学习的算法是计算密集型或者是计算数据双密集型的，所以基于Hadoop的分析平台也有计算密集型的需求。同时由于MapReduce是为了离线分析而设计的，那么对于实时分析来说没有优势。而有些数据的时效性是很重要的，分析的实时性就很关键，所以我们还需要实时计算引擎。
|
|
基于上述需求，在后面的Hadoop的版本YARN中会把MapReduce做成统一的资源管理和任务调度层，会支持OpenMPI,Storm,S4,Spark,MapReduce等多种计算模型，横跨实时数据处理，离线数据处理，计算密集型和数据密集型应用。到那个时候整个Hadoop生态系统就是真正意义的统一数据存储和处理平台了。
