1.4.1　大数据存储和管理技术

近年来互联网、云计算、移动和物联网的迅猛发展。无所不在的移动设备、RFID、无线传感器每分每秒都在产生数据，数以亿计用户的互联网服务时时刻刻在产生巨量的交互，要处理的数据量实在是太大、增长太快了，而业务需求和竞争压力对数据处理的实时性、有效性又提出了更高要求，传统的常规技术手段根本无法应付。在这种情况下，技术人员纷纷研发和采用了一批新技术，主要包括分布式缓存使用、基于MPP的分布式数据库、分布式文件系统、各种NoSQL分布式存储方案等。

1.分布式缓存使用技术

分布式缓存使用（Caching Array Routing Protocol，CARP）技术可以产生一种高效率无接缝式的缓存，使用上让多台缓存服务器形同一台，并且不会造成数据重复存放的情况。分布式缓存提供的数据内存缓存可以分布于大量单独的物理机器中。换句话说，分布式缓存所管理的机器实际上就是一个集群。它负责维护集群中成员列表的更新，并负责执行各种操作，比如说在集群成员发生故障时执行故障转移，以及在机器重新加入集群时执行故障恢复。

分布式缓存支持一些基本配置：重复（Replicated）、分区（Partitioned）和分层（Tiered）。重复用于提高缓存数据的可用性。在这种情况下，数据将重复缓存在分布式系统的多台成员机器上，一旦某个成员发生故障，其他成员便可继续提供该数据。分区是一种用于实现高可伸缩性的技巧。通过将数据分区存放在许多机器上，内存缓存的大小随着机器的增加而呈线性增长。结合分区和重复这两种机制创建出的缓存可同时具备大容量和高可伸缩的特性。分层缓存又称客户机-服务器（Client-Server）缓存，它是一种拓扑结构，在该结构中缓存功能将集中于一组机器上。缓存客户机通常并不会亲自执行任何缓存操作，而是连接到缓存并检索或更新其中的数据。分层缓存架构可以包含多层结构。Memcached是danga.com（运营LiveJournal的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性能。许多Web应用程序都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重，产生数据库响应恶化、网站显示延迟等重大影响。Memcached是高性能的分布式内存缓存服务器。一般的使用目的是通过缓存数据库查询结果，减少数据库的访问次数，以提高动态Web应用的速度、提高扩展性。Memcached作为高速运行的分布式缓存服务器具有以下特点：

（1）协议简单：Memcached服务器客户端通信并不使用复杂的MXL等格式，而是使用简单的基于文本的协议。

（2）基于libevent的事件处理：libevent是个程序库，他将Linux的epoll、BSD类操作系统的kqueue等时间处理功能封装成统一的接口。Memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。

（3）内置内存存储方式：为了提高性能，Memcached中保存的数据都存储在memcached内置的内存存储空间中。由于数据仅存在于内存中，因此重启Memcached、重启操作系统会导致全部数据消失。另外，内容容量达到指定的值之后Memcached会自动删除不适用的缓存。

（4）Memcached不互通信的分布式：Memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个Memcached不会互相通信以共享信息。它的分布式主要是通过客户端实现的。

Memcached处理的原子是每个（Key，Value）对（以下简称KV对），Key会通过一个hash算法转化成hash-Key，便于查找、对比以及做到尽可能的散列。同时，Memcached用的是一个二级散列，通过一张大hash表来维护。Memcached由两个核心组件组成：服务端（ms）和客户端（mc），在一个Memcached的查询中，ms先通过计算Key的hash值来确定KV对所处在的ms位置。当ms确定后，mc就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以Memcached交互带给网络的影响是最小化的。 MemcacheDB是一个分布式、Key-Value形式的持久存储系统。它不是一个缓存组件，而是一个基于对象存取的、可靠的、快速的持久存储引擎。协议与Memcached一致（不完整），所以，很多Memcached客户端都可以跟它连接。MemcacheDB采用Berkeley DB作为持久存储组件，因此，很多Berkeley DB的特性它都支持。类似这样的产品也很多，如淘宝Tair就是Key-Value结构存储，在淘宝中得到广泛使用。后来Tair也做了一个持久化版本，思路基本与新浪MemcacheDB一致。

2.分布式数据库

分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都有DBMS的一份完整拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的大型数据库。分布式数据库系统是数据库系统与计算机网络相结合的产物。分布式数据库系统产生于20世纪70年代末期，在20世纪80年代进入迅速成长阶段。由于数据库应用需求的拓展和计算机硬件环境的改变，计算机网络与数字通信技术的飞速发展，卫星通信、蜂窝通信、计算机局域网、广域网和Internet的迅速发展，使得分布式数据库系统应运而生，并成为计算机技术最活跃的研究领域之一。

分布式数据库系统符合信息系统应用的需求，符合当前企业组织的管理思想和管理方式。对于地域上分散而管理上又相对集中的大企业而言，数据通常是分布存储在不同地理位置，每个部门都会负责维护与自己工作相关的数据。整个企业的信息就被分隔成多个“信息孤岛”。分布式数据库为这些信息孤岛提供了一座桥梁。分布式数据库的结构能够反映当今企业组织的信息数据结构，本地数据保存在本地进行维护，而又可以在需要时存取异地数据。也就是说，既需要有各部门的局部控制和分散管理，同时也需要整个组织的全局控制和高层次的协同管理。这种协同管理要求各部门之间的信息既能灵活交流与共享，又能统一管理和使用，也就自然而然地提出了对分布式数据库系统的需求。随着应用需求的扩大和要求的提高，人们越来越认识到集中式数据库的局限性，迫切需要把这些子部门的信息通过网络连接起来，组成一个分布式数据库。世界上第一个分布式数据库系统为SDD-1，是由美国计算机公司于1976—1978年设计的，并于1979年在DEC-10和DEC-20计算机上面实现。 Spanner是一个可扩展、多版本、全球分布式并支持同步复制的分布式数据库。它是Google的第一个可以在全球扩展并且支持外部一致性事务的分布式数据库。Spanner能做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此，Spanner有几个给力的功能：无锁读事务、原子模式修改、读历史数据无阻塞。

原始的数据存储在文件系统中，但是，用户习惯通过数据库系统来存取文件。因为这样会屏蔽掉底层的细节，且方便数据管理。直接采用关系模型的分布式数据库并不能适应大数据时代的数据存储，主要原因有：

（1）规模效应所带来的压力。大数据时代的数据量远远超过单机所能容纳的数据量，因此必须采用分布式存储的方式。这就需要系统具有很好的扩展性，但这恰恰是传统数据库的弱势之一。因为传统的数据库产品对于性能的扩展更倾向于Scale-Up（纵向扩展）的方式，而这种方式对于性能的增加速度远低于需要处理数据的增长速度，且性能提升存在上限。适应大数据的数据库系统应当具有良好的Scale-Out（横向扩展）能力，而这种性能扩展方式恰恰是传统数据库所不具备的。即便是性能最好的并行数据库产品，其Scale-Out能力也相对有限。

（2）数据类型的多样化。传统的数据库比较适合结构化数据的存储，但是数据的多样性是大数据时代的显著特征之一。这也就意味着除了结构化数据，半结构化和非结构化数据也将是大数据时代的重要数据类型组成部分。如何高效地处理多种数据类型是大数据时代数据库技术面临的重要挑战之一。

（3）设计理念的冲突。关系数据库追求的是“One size fits all”的目标，希望将用户从繁杂的数据管理中解脱出来，在面对不同的问题时不需要重新考虑数据管理问题，从而可以将重心转向其他部分。但在大数据时代不同的应用领域在数据类型、数据处理方式以及数据处理时间的要求上有极大的差异。在实际的处理中几乎不可能有一种统一的数据存储方式能够应对所有场景。比如对于海量Web数据的处理就不可能和天文图像数据采取同样的处理方式。在这种情况下，很多公司开始尝试从“One size fits one”和“One size fits domain”的设计理念出发来研究新的数据管理方式，并产生了一系列非常有代表性的工作。

（4）数据库事务特性。众所周知，关系数据库中事务的正确执行必须满足ACID特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。对于数据强一致性的严格要求使其在很多大数据场景中无法应用。这种情况下出现了新的BASE特性，即只要求满足Basically Available（基本可用）、Soft State（柔性状态）和Eventually Consistent（最终一致）。从分布式领域著名的CAP理论的角度来看，ACID追求一致性C，而BASE更加关注可用性A。正是在事务处理过程中对于ACID特性的严格要求，使得关系型数据库的可扩展性极其有限。

面对这些挑战，以Google为代表的一批技术公司纷纷推出了自己的解决方案。Bigtable是Google早期开发的数据库系统，它是一个多维稀疏排序表，由行和列组成，每个存储单元都有一个时间戳，形成三维结构。不同的时间对同一个数据单元的多个操作形成的数据的多个版本之间由时间戳来区分。除了Bigtable，Amazon的Dynamo和Yahoo的PNUTS也都是非常具有代表性的系统。Dynamo综合使用了键/值存储、改进的分布式哈希表（DHT）、向量时钟（Vector Clock）等技术实现了一个完全的分布式、去中心化的高可用系统。PNUTS是一个分布式数据库，在设计上使用弱一致性来达到高可用性的目标，主要的服务对象是相对较小的记录，比如在线的大量单个记录或者小范围记录集合的读/写访问，不适合存储大文件、流媒体等。Big-table、Dynamo、PNUTS等的成功促使人们开始对关系数据库进行反思，由此产生了一批未采用关系模型的数据库，这些方案现在被统一称为NoSQL（Not Only SQL）。NoSQL并没有一个准确的定义，但一般认为NoSQL数据库应当具有以下的特征：模式自由（Schema-free）、支持简易备份（Easy Replication Support）、简单的应用程序接口（Simple API）、最终一致性（或者说支持BASE特性，不支持ACID）、支持海量数据（Huge Amount Of Data）。 Bigtable的模型简单，但是，相较传统的关系数据库其支持的功能非常有限，不支持ACID特性。因此，Google开发了Megastore系统，虽然其底层数据存储依赖Bigtable，但是它实现了类似RDBMS的数据模型，同时提供数据的强一致性解决方案。Megastore将数据进行细粒度的分区，数据更新会在机房间进行同步复制。Spanner是已知的Google最新的数据库系统，Google在OSDI 2012上公开了Spanner的实现。Spanner是第一个可以实现全球规模扩展（Global Scale）并且支持外部一致的事务（Support Externally-consistent Distributed Transactions）的数据库。通过GPS和原子时钟（Atomic Clocks）技术，Spanner实现了一个时间API。借助该API，数据中心之间的时间同步能够精确到10 ms以内。Spanner类似于Bigtable，但是它具有层次性的目录结构以及细粒度的数据复制。对于数据中心之间不同操作会分别支持强一致性或弱一致性，且支持更多的自动操作。Spanner的目标是控制100万～1000万台服务器，最多包含大约10万亿目录和1000万亿字节的存储空间。另外，在SIGMOD 2012上，Google公开了用于其广告系统的新数据库产品F1，作为一种混合型数据库，F1融合兼有Bigtable的高扩展性以及SQL数据库的可用性和功能性。该产品的底层存储正是采用Spanner，具有很多新的特性，包括全局分布式、同步跨数据中心复制、可视分片和数据移动、常规事务等。有些比较激进的观点认为“关系数据库已死”，但是，一般而言，关系数据库和NoSQL并不是矛盾的对立体，而是可以相互补充的、适用于不同应用场景的技术。例如，实际的互联网系统往往都是ACID和BASE两种系统的结合。近年来，以Spanner为代表的若干新型数据库的出现，给数据存储带来了SQL、NoSQL之外的新思路。这种融合了一致性和可用性的NewSQL或许会是未来大数据存储新的发展方向。NoSQL数据库，指的是非关系型的数据库。随着互联网Web 2.0网站的兴起，传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型的Web 2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型数据库则由于其本身的特点得到了非常迅速的发展。现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性（Horizontal Scalability，是指能够连接多个软硬件的特性，这样可以将多个服务器从逻辑上看成一个实体），而NoSQL致力于改变这一现状。目前Google的Bigtable和Amazon的Dynamo使用的就是NoSQL型数据库。2010年下半年，Facebook选择HBase来做实时消息存储系统，替换原来开发的Cassandra系统。这使得很多人开始关注NoSQL型数据库HBase。Facebook选择HBase是基于短期小批量临时数据和长期增长的很少被访问到的数据这两个需求来考虑的。 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建大规模结构化存储集群。HBase是Bigtable的开源实现，使用HDFS作为其文件存储系统。Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用MapReduce来处理HBase中的海量数据；Bigtable利用Chubby作为协同服务，HBase则利用Zookeeper作为对应。

3.分布式文件系统

文件系统是支撑上层应用的基础。在Google之前，尚未有哪个公司面对过如此多的海量数据。因此，对于Google而言并没有完全成熟的存储方案可以直接使用。Google认为系统组件失败是一种常态而不是异常，基于此思想，Google自行设计开发了Google文件系统（Google File System，GFS）。GFS是构建在大量廉价服务器之上的一个可扩展的分布式文件系统，GFS主要针对文件较大，且读远大于写的应用场景，采用主从（Master-Slave）结构。GFS通过数据分块、追加更新（Append-Only）等方式实现了海量数据的高效存储。随着时间的推移，GFS的架构逐渐开始无法适应需求。Google对GFS进行了重新设计，该系统正式的名称为Colossus，其中，GFS的单点故障（指仅有一个主节点容易成为系统的瓶颈）、海量小文件的存储等问题在Colossus中均得到了解决。除了Google，众多企业和学者也从不同方面对满足大数据存储需求的文件系统进行了详尽的研究。微软自行开发的Cosmos支撑着其搜索、广告等业务。HDFS和CloudStore都是模仿GFS的开源实现。GFS类的文件系统主要是针对较大文件设计的，而在图片存储等应用场景，文件系统主要存储海量小文件，此时GFS等文件系统因为频繁读取元数据等原因，效率很低。针对这种情况，Facebook推出了专门针对海量小文件的文件系统Haystack，通过多个逻辑文件共享同一个物理文件、增加缓存层、部分元数据加载到内存等方式有效地解决了Facebook海量图片存储问题。淘宝推出了类似的文件系统TFS（Tao File System），通过将小文件合并成大文件、文件名隐含部分元数据等方式实现了海量小文件的高效存储。FastDFS针对小文件的优化类似于TFS谈到分布式文件系统，不得不提的是Google的GFS。基于大量安装有Linux操作系统的普通PC构成的集群系统，整个集群系统由一台Master（通常有几台备份）和若干台TrunkServer构成。GFS中文件被分成固定大小的Trunk分别存储在不同的Trunk-Server上，每个Trunk有多份（通常为3份）副本，也存储在不同的TrunkServer上。Master负责维护GFS中的Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的TrunkServer通信，获取文件数据。在Google的论文发表后，就诞生了Hadoop。Hadoop被很多中国最大互联网公司所追捧，百度的搜索日志分析，腾讯、淘宝和支付宝的数据仓库都可以看到Hadoop的身影。

Hadoop具备低廉的硬件成本、开源的软件体系、较强的灵活性、允许用户自己修改代码等特点，同时能支持海量数据存储和计算任务。

如果将各种大数据的应用比作一辆辆“汽车”的话，支撑起这些“汽车”运行的“高速公路”就是云计算。正是云计算技术在数据存储、管理与分析等方面的支撑，才使得大数据有用武之地。在所有的“高速公路”中，Google无疑是技术最为先进的一个。需求推动创新，面对海量的Web数据， Google于2006年首先提出了云计算的概念。支撑Google内部各种大数据应用的正是其自行研发的一系列云计算技术和工具。难能可贵的是Google并未将这些技术完全封闭，而是以论文的形式逐步公开其实现。正是这些公开的论文，使得以GFS、MapReduce、Bigtable为代表的一系列大数据处理技术被广泛了解并得到应用，同时还催生出以Hadoop为代表的一系列云计算开源工具。云计算技术很多，但是通过Google云计算技术的介绍能够快速、完整地把握云计算技术的核心和精髓。这里以Google的相关技术介绍为主线，详细介绍Google以及其他众多学者和研究机构在大数据技术方面已有的一些工作。根据Google已公开的论文及相关资料，结合大数据处理的需求，可以看出Google的技术演化过程，如图1-3所示。