随着医疗卫生信息化的发展，大数据技术已经融入到医疗卫生领域当中。为了打破传统医疗卫生机构的信息孤岛，实现大数据挖掘和分析，医疗行业急需构建一个健康医疗数据湖系统。健康医疗数据湖系统以Hadoop、Spark、关系型数据库、NoSQL数据库、MPP数据库、内存数据库等技术实现，可以大大地提高医院的运行和服务效率，为临床决策提供大数据支撑。本部分将对数据湖原理、构成、构建和支持多集群混合调度的大数据资源管理技术进行全面阐述。

数据湖是一个用于存放海量多源异构数据的大规模数据存储系统，并将原始数据分类存储到不同的数据池，在各个数据池里对数据进行的整合与优化。数据湖为共享数据提供了单一的存储库，它降低了数据复制成本，有效避免了数据的不一致性。在经济效益方面，用户可以根据不同业务场景对数据进行加工处理，分析数据的规律，挖掘数据的价值，为不同行业的业务发展提供数据量化的平台。数据湖技术现已在商业、交通、医疗、气象等领域取得了一定的成效。

数据湖技术的特点：

在大数据时代，由于数据规模呈指数级增长，传统的数据库已经难以适应。因此，需要建设一个海量数据存储架构作为大数据的支撑。数据湖就是一种可以存储海量数据的存储架构物。它将各类数据源汇聚起来，形成了数据湖泊。它能容纳散落在各处的数据，具有庞大的存储空间和架构。

从功能角度分析，数据湖技术涵盖了多数据源和各种数据种类，可以快速地存储和计算大量来源不同、格式迥异的原始数据，包括传统数据库中的结构化数据，XML、JSON等格式的半结构化数据和文本，图片、声音、网页等各种无序的非结构化数据。

从特征的角度分析，如果把不同的数据看成是不同的颜色，那么数据湖就相当于一个汇集了各种色彩的湖泊，就像把不同的色彩融合在一起会形成新的色彩一样，不同种类的数据通过智能化集成的方式结合在一起，在数据分析方法的作用下找到数据之间的规律，创造了比原始数据本身更高的应用价值。

数据湖中对其中的原始数据可根据其类别提取到不同的数据池中，在数据池中进行转换，最终形成新的数据。用户可以从数据池中挖掘、提取数据，分析数据间的关联并用于特定的需求。这种数据处理模式可以让数据充分发挥它的价值，使那些长期不被使用的数据焕发出新的活力，进而被重新利用，最终创造出新的价值。

健康医疗数据湖系统是针对健康医疗行业形成的数据湖系统。其数据来源多样，主要由医疗卫生信息系统和医疗信息采集设备而来。常见的医疗卫生信息系统有电子病历系统、医院信息系统、检验信息系统、影像诊断系统等。常见的医疗信息采集设备有生命体征监护仪、数字化影像设备、数字心电图等。这些系统和设备包含图像、病历、医嘱等多源异构数据，数据类型涵盖了结构化、半结构化、非结构化等，能覆盖健康医疗行业的各个环节。

数据湖通过将多源异构的数据分类存储到不同数据池，并将数据整合转化统一存储格式的数据，最终进行持久化存储。与传统的数据库和数据仓库不同，数据湖不需要改变原始数据的结构，它将原始的数据利用廉价的存储设备存储下来，保证了数据的原生性。利用大数据平台及分布式集群技术，将原始数据在数据湖中进行数据加工，提升数据质量，完成数据的装载和转换。这个方式可以避免海量原生数据的丢失，它利用分布式集群提升了数据转换和装载的效率，使得多源异构的大数据分析变成可能。

数据湖由原始数据池、模拟数据池、应用数据池、文本数据池和档案数据池五种不同类型的数据池组成。这五种数据池分别用来存储不同类型的数据，通过建立联系它们的联系来共享信息。用户可大量提取数据湖中的数据，分析数据的规律，挖掘数据的价值。

原始数据池用于存储大量的原始数据，它并不对数据做任何处理。为了更高效地从原始数据池中提取所需的数据，需要对原始数据进行分类存储。因此，模拟数据池、应用数据池和文本数据池等数据池在原始数据池的基础上产生。

模拟数据池是用于存放模拟数据的数据池，从原始数据池提取模拟数据到模拟数据池中，并将数据转化成更易于用户使用的格式。模拟数据是由机械、传感器等采集设备产生的。

应用数据池是存放应用数据的数据池，以标准数据库的数据格式存入应用数据池中。所有应用数据池里的数据都要进行集成，其集成过程与模拟数据池中的数据转化类似。对应用数据池内的数据进行数据集成时，通常需要先建立数据模型，并根据此模型进行数据集成。

文本数据池是用来存放文本类型数据的数据池，存储的是多源异构的文本数据。类似于其他数据池，一旦原始数据进入文本数据池后，在文本数据池中就要对它进行文本格式统一和分类储存。

档案数据池是存储来自模拟数据池、应用数据池、文本数据池中使用概率较小的数据。所有进入档案数据池中的数据都要重新对其进行标准化处理操作，使该数据直接与原始数据联系起来，保证当用户日后使用该数据时，其元数据和元操作过程都不会丢失。

数据湖中各数据池是紧密相连的，它们形成一个有机的整体。首先，数据进入数据湖的原始数据池中；其次，在原始数据池中根据其类别从原始数据池提取到模拟、应用或文本相对应的数据池中，并对其进行标准化；最后，将使用概率较小的数据存储在档案数据池中并重新对其标准化。

数据湖技术不是由一种单一技术形成的，它由分布式文件系统、内存计算、关系型数据库、非关系型数据库、数据仓库等多种架构组成，是一种与行业业务紧密结合的生产级数据解决方案。

数据湖既是一个大规模的数据存储系统，又是一个强大的数据分析系统，它为多源异构数据的采集和分析提供了平台级的支撑。以下会介绍到分布式文件系统、内存计算系统、关系型数据库系统、NoSQL数据库系统、数据仓库系统等数据湖系统中常见的技术构成及应用手段。

分布式文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连，并与集群文件系统进行存储。它可以支持大数量的节点以及海量的数据的存储。常见的专用分布式文件系统包括GFS、HDFS、PanFS、Lustre，MogileFS、FastDFS等，通用的文件系统包括NFS、AFS等。

分布式文件系统的特点如下：

1.可以利用大量廉价服务器组建海量存储系统。

2.通过内部的冗余复制，提高容错能力，保证文件的可用性。

3.可扩展性强，支持存储节点的动态扩展。

4.支持对特定索引文件进行计算。

内存计算系统主要是在硬软件系统协作的条件下，将数据库的相关计算转移到内存中进行。数据从以往的磁盘迁移到内存中，并在内存中进行数据处理和计算，摆脱以往磁盘I/O读写开销。内存计算系统基于并发处理技术实现，大大提高了数据处理计算的效率。

内存计算系统的特点如下：

1.在内存网格层进行数据读取和处理工作。

2.在数据存储层面上能够同时并行列储存和行储存。

3.在处理机制采用并发处理机制实现。

数据库是按数据结构组织、存储和管理数据的仓库，具备数据结构化、共享性高、冗余度低、独立性强等特点。数据仓库的概念最早由William H•Inmon于1991年在其著作Building The Data Warehouse中提出，即数据仓库是一个面向主题的、集成的、非易失的随时间变化的用来支持管理人员决策的数据集合。数据仓库系统的常用体系结构有单层体系结构、双层体系结构和三层体系结构等类型，其中双层体系结构是最为典型的体系结构。选用该种体系结构的数据仓库系统通常包含数据源、数据集成工具、数据存储管理、OLAP服务器、前端工具和应用等部分。

数据仓库系统的特点如下：

1.支持存储面向管理应用和综合分析的集成化和综合性的信息。

2.基于传统面向事务的数据库或外界数据库作为数据源，生成符合数据应用语义规范要求的数据集合。

3.能够支持多种复杂的数据应用和综合性的管理决策分析场景。

流计算是用于进行实时处理来自不同数据源的、连续到达的流数据处理框架，经过实时分析处理，给出有价值的分析结果。常见的流计算处理框架有Spark Streaming等。流计算秉承一个基本理念，即数据的价值随着时间的推移而降低。为了实时地对流数据进行处理，就需要一个低延迟、可扩展、高可靠的处理引擎。对于一个流计算系统来说，它应达到如下需求：

能处理大数据的基本要求，如每秒处理几十万条数据。

支持TB级甚至是PB级的数据规模。

必须保证一个较低的延迟时间，达到秒级别，甚至是毫秒级别。

支持大数据的基本架构，能在指定的时间内完成。

部署简单，支持快速开发。

能可靠地处理流数据。

在海量数据处理过程中，传统关系型数据库显得力不从心，非关系型数据库就是基于这个背景下提出来的。非关系型数据库打破了长久以来关系型数据库大一统的局面，它在存储上没有固定的表结构，通常也不存在连接操作。它常见的非关系型数据库有文档数据库、列族数据库、图形数据库、键值数据库等。

非关系型数据库的特点如下：

关系型数据支持列式存储，扩展起来非常方便。

由于数据之间无关系，数据库的结构简单，在数据量大的情况下，非关系型数据库表现出高效的读写性能。

随着信息技术的发展，互联网进入Web2.0时代，互联网上的数据呈指数级增长，“大数据”时代正式到来。“大数据”时代中海量数据存储与分析的需求推动着大数据平台技术的发展，如今市场上的大数据平台已是多种多样，如著名的美国科技公司Google的Cloud Dataflow，但Cloud Dataflow并不开源，任何公司如果想使用它都必须要为Google公司提供的服务付费。说到开源的大数据平台，首先想到的还是由Apache基金会维护的开源分布式系统基础架构Hadoop，它与Cloud Dataflow最大的不同在于Hadoop是完全开源的，并且有强大的生态圈支持。

人们所熟知的Hadoop其实有两种含义，广义的Hadoop大数据平台常常是指围绕着Hadoop的整个软件生态圈，而狭义的Hadoop大数据平台由HDFS和Hadoop MapReduce两部分组成。HDFS和MapReduce都是对Google公司分布式系统的开源实现，其中HDFS是对分布式文件系统GFS的开源实现，Hadoop MapReduce是对分布式处理框架Google MapReduce的开源实现（此文后的MapReduce如无特殊说明则特指Hadoop MapReduce）。由于Hadoop可以运行在廉价的x86服务器集群上，它的出现使得分布式系统的使用门槛大大降低，众多互联网企业纷纷选用Hadoop作为自己的大数据解决方案。

Hadoop作为一个Apache开源的项目，它继承了GFS和MapReduce的优点，并在性能上进行了很大的改进。谈起Hadoop的发展史，不得不提及Apache另一个开源项目——Lucene。2000年，Apache发布了第一个Lucene的开源版本。它由Doug Cutting开发，是一款高性能的、可扩展的信息检索（IR）工具库，广泛用于各类商业软件的全文检索子系统中。Lucene以其开放源代码的特性、优异的索引结构、良好的系统架构受到了广泛的关注，也为Hadoop系统的高质量全文搜索能力提供了重要的技术参考。可以说，Lucene项目的开源使Hadoop进入了孕育期。

Nutch的成熟进一步为Hadoop平台的产生提供了重要的条件。Nutch是一个开源Java实现的搜索引擎，是一个建立在Lucene核心之上的Web搜索引擎项目，它具备搜索引擎所需的全部工具，包括全文搜索和Web爬虫。它的发展为海量数据采集和搜索提供了条件。但随着互联网中网页数目的增多，在2002年的时候，人们发现Nutch无法扩展到拥有数十亿网页的网络，也就是说，面对海量的网页，Nutch变得无所适从。如何寻求一种可以扩展到数以十亿甚至数以百亿计网页的搜索引擎变成了人们继续解决的问题。经过不断探索，Google终于在2003年分享了自己的技术成果，它发布了一篇关于Google是如何处理大规模数据的存储问题的论文—— The Google File System，该论文中阐述的分布式存储编程思想，提出了Google文件系统的基本概念和实现方式，这为Nutch项目在解决目前所遇到的问题提供了重要的启发。一年后，Nutch项目也模仿GFS开发了自己的分布式文件系统——NDFS，即Nutch分布式文件系统，它作为HDFS的前身，用于海量数据在分布式环境的存储，它的出现解决了海量网页存储的问题，使Hadoop进入了萌芽期。

Google公司为Hadoop的产生起到至关重要的作用，尽管论文 The Google File System解决了大规模数据的存储问题，但是在处理海量原始数据的时候，Google公司吃尽了苦头。为了实现数以百计的专用计算方法，技术人员尝试了很多方法，但由于输入的数据量巨大，利用一个程序串行地进行大规模数据运算并不现实，因此他们想到了将计算任务分布于成百上千的服务器上并行完成，但如何分割、调度任务，如何对错误进行处理以及如何管理服务间通信，这需要大量的代码处理，因此也使得原本简单的运算变得难以处理。如何开发出一个海量数据并行计算框架来处理当前的数据成为了Google公司急需解决的问题。通过不断努力，技术人员终于发现了处理海量数据的方法。随后，Google公司向世人公布了大规模海量数据处理的最新成果——MapReduce，并发表了一篇对整个业界影响深远的论文—— MapReduce： Simplified Data Processing on Large Clusters，这篇论文正是阐述了MapReduce这个抽象模型的分布式编程思想。使用MapReduce技术，程序员只需要编写业务相关的简单运算代码即可，而不必关心并行计算、容错、数据分布、负载均衡等复杂的细节问题。2005年，Nutch模仿Google公司MapReduce的编程思路，开源实现了自己的MapReduce，这为Hadoop的诞生迈出了关键性的一步。

2006年2月，Nutch MapReduce和NDFS从Nutch项目中被剥离出来成立了一个新的开源项目——Hadoop，自此，Hadoop生态圈正式被确立。到了2008年1月，Hadoop项目正式成为Apache的顶级项目，逐渐被众多企业选用，Hadoop进入了发展期。

在2008年开始的后两年时间里，Hadoop MapRedcue连续打破系统排序1TB数据基准测试的世界记录，甚至将排序1TB数据基准测试的时间缩短到了62秒，这些数据都是未进行压缩的文本数据，Hadoop MapRedcue取得了分布式系统数据排序能力比拼的出色成绩。因为Hadoop MapRedcue出色的性能表现，使得它迅速发展成为最具影响力的开源分布式平台，并陆续被各大网络巨头公司所选用，Hadoop真正进入了成熟期。

相比Google公司的MapReduce，Hadoop MapRedcue的优势在于它是源代码开源的，由此吸引了众多开发者对其进行维护与升级，而且Hadoop MapRedcue是跨语言的，它支持使用Java、C、Ruby、Python等多种编程语言来开发MapReduce程序。

随着大数据业务场景的不断增多，越来越多的Apache开源项目加入到Hadoop这个大家庭当中。YARN、Zookeeper、HBase、Hive、Sqoop、Kafka、Flume等产品逐步加入到Hadoop中，并发挥其重要作用。可以说，如今的Hadoop不仅有HDFS和MapReduce，而是多种大数据技术相互融合、相互发展的产物，是一个相对完整的大数据生态圈。期待未来，Hadoop生态圈仍具备活力，以解决数据业务中的各种问题。

在众多企业和开源爱好者的努力下，Hadoop平台逐渐形成了一个生态圈，为实现各类数据挖掘、数据分析场景提供平台支持（图4-1）。

除HDFS与MapReduce以外，Hadoop大数据平台的常用核心组件主要包含：

Zookeeper是Hadoop的分布式协调服务。Hadoop的许多组件都依赖于Zookeeper，它分布式地运行在多台计算机组成的集群上，为集群提供协调服务。

HBase是一个列族数据库，适用于海量数据的分析场景。

Hive是基于MapReduce的一个数据仓库工具，它使得用户可以使用简单的类SQL语法实现数据统计处理。

Sqoop是一个用于解决传统关系型数据库、数据仓库与Hadoop集群之间进行数据导入导出工作的工具。

Flume是一个日志收集系统，它支持自定义各类日志数据的采集，并具有对数据进行简单处理的能力。

Pig是一种数据分析脚本，用于数据流的处理。

数据挖掘算法库Mahout包含在回归、聚类、分类等问题上被广泛使用的数据挖掘算法，可以帮助开发人员便捷地创建智能应用程序。

Hadoop平台最核心的组件就是HDFS和MapReduce。HDFS为大数据提供了可靠的分布式文件系统，MapReduce则为大数据提供了一个可支撑大规模数据集并行运算的编程框架。

HDFS就像Windows系统中使用的FAT32文件系统一样，它是Hadoop的文件格式系统，特点在于它是分布式的，将数据分片分块存储于由多台服务器组成的集群中。MapReduce将数据计算任务抽象为Map和Reduce两个函数，提供了一整套完整的供程序员开发MapReduce应用程序的编程接口，程序员只需实现对应接口，合理的设置数据的输入、输出，无须考虑服务器间通讯问题，即可方便、快速地写出大数据并行处理程序。这两者都充分体现了“众人拾柴火焰高”的思想，HDFS和MapReduce将在后面的部分进行详细介绍。

介绍HDFS首先需要介绍Google公司的GFS，即Google File System。GFS是由Google公司招募的数百名计算机科学博士生参与研发而成的分布式文件系统，但由于这些研发者负担不起使用高性能商业服务器以进行实验的费用，所以最终采用了成本低廉的计算机来进行研发，这些计算机常常发生硬件故障，因此GFS在设计之初就把硬件故障作为一种常态而非异常来进行处理。

HDFS是对GFS的一个开源实现，HDFS同样也继承了GFS这种将故障作为常态的容错机制，得益于这种容错机制，即使是硬件故障频出的集群，HDFS也能保证数据安全而不丢失。HDFS甚至可以稳定运行在企业从核心业务中淘汰出来的服务器组成的集群之上，可见HDFS对服务器硬件故障的容忍能力已经足够强大。

与普通文件系统类似，HDFS也采用块进行数据组织和管理，当用户请求存储文件时，文件首先会被切分为若干个块进行存储，两者差别在于HDFS的块相比普通文件系统更大，HDFS的设计前提是支持大容量的流数据操作，所以一般的数据读写所涉及的数据量都比较大，如果这个块大小设置过小，那么需要读取的数据块就比较多，普通硬盘因为需要移动磁头，所以随机寻址较慢，读越多的数据块，导致磁盘寻址耗时的比重越大，这会大大降低读取效率；如果块设置过大，由于数据块是读取数据的最小单位，因此会导致上层计算框架在加载数据时的时间过长。Apache官方推荐的默认块大小为128M，该默认值是经过众多使用者验证得出的适合一般业务场景的建议值，使用者可以按照自身业务需要对该默认值进行适当调整，以达到性能优化的目的。

分布式文件系统在物理结构上由集群中的多台服务器或虚拟机节点组成。HDFS遵循“管理节点-工作节点”的工作模式，服务节点分为管理节点（NameNode）和工作节点（DataNode）两种。NameNode是一个中心节点，负责管理文件系统、存储文件的元数据，以及接收客户端对文件系统中文件的访问请求；DataNode位于各工作节点上，负责真正存储数据块，DataNode定期向NameNode发送心跳信号以及汇报块存储信息。

HDFS采用多副本的方式对数据提供冗余存储，一个数据块一般会被存为三个副本，这三个副本会被分布存储到多个不同的DataNode节点中。数据在HDFS中的存取是按照一定的存取策略进行的，如在一个小型的数据中心存储一个数据，HDFS集群会将第一个副本存储在A服务器节点的DataNode中，第二个副本存储在与A物理环境同处一个机柜的另外一台服务器B的DataNode中，而第三个副本则存储在另一个机柜的服务器C的DataNode中。

HDFS的多备份存储机制不仅能够保证数据不被丢失，在取数据时还可以加快数据的传输速度，当多个客户端请求同一个文件时，可以让每个客户端访问不同的数据副本，从而有效降低网络瓶颈对文件读写的限制。

HDFS的写过程主要分为以下几个步骤（图4-2）：

（1）客户端先将文件发送给NameNode。

（2）NameNode将文件拆分为多个数据块并返回。

（3）客户端将数据分块按照NameNode的指导写入指定的DataNode节点。

（4）DataNode节点之间根据数据副本策略将数据块进行流水线复制。

（5）DataNode向NameNode汇报新增块信息。

HDFS的读过程主要分为以下几个步骤（图4-3）：

（1）客户端向NameNode发送请求的文件名称。

（2）NameNode根据存储的元数据信息，找出与客户端网络距离最近的数据备份，返回对应数据备份所处的DataNode节点及具体数据块存储地址。

（3）客户端向对应DataNode发起数据块读取请求。

（4）DataNode返回数据块给客户端。

1.通过元数据记录节点与数据块信息保证了数据的高可靠性。

2.提供高扩展性，存储与计算节点可以动态增加，部分框架可以按需替换。

3.通过移动计算而非移动数据，计算跟着数据走。

4.数据自动备份，副本丢失后自动通过其他数据副本进行恢复，保证了高容错。

5.可以构建在廉价x86服务器上，大大降低了成本，适合大规模数据存储与计算。

1.不适合低延迟数据访问，实时性低。

2.无法高效存储大量小文件。

3.不支持多用户写入及文件的修改。

4.数据不支持随机读取，只能从头到尾扫描。

1970年E.F.Codd在美国计算机学会会刊上发表了题为 A Relational Model of Data for Large Shared Data Banks的论文，这篇论文系统地、严格地提出了关系模型的概念，开创了数据库系统的新纪元。此后，E.F.Codd连续发表了多篇论文，奠定了关系型数据库的理论基础。

20世纪70年代末，关系方法的理论研究和软件系统的研制均取得了很大成果，IBM公司的San Jose实验室在IBM270系列机上研制的关系型数据库实验系统System R历年6年获得成功。1981年IBM公司又宣布了具有System R全部特征的新的数据库软件产品SQL/DS问世。与System R同期，美国加州大学伯克利分校也研制了INGRES关系型数据库实验系统，该产品逐渐发展成为INGRES数据库产品。40多年来，关系型数据库系统的研究和开发取得了辉煌的成就。关系型数据库系统从实验室走向了各行各业，成为应用最广泛的数据库系统。

关系型数据库在数据库市场占有率最高，有数以千万计的用户，其中许多是企业用户，它是现今最流行的数据库管理系统。但是没有一种产品是万能的，一种产品不能应用于所有的业务场景，关系型数据库仅适合用于存储结构化数据。

关系型数据库是建立在关系模型基础上的数据库，它借助于关系代数理论等数学概念和方法来处理数据库中的数据。它与非关系型数据库的区别是，关系型数据库是强一致性的，而且数据以结构化的形式存储，并且具有完善的事务特性。

目前主流的关系型数据库包括Oracle、DB2、PostgreSQL、微软SQL Server、微软Access、MySQL、WAVE K-DB等。

MySQL最初是由MySQL AB公司开发的，早在2000年，该公司公开了MySQL数据库的源代码，并采用GPL协议作为开源标准，MySQL数据库正式投入到开源世界的怀抱中。2008年，Sun公司以10亿美元将MySQL收购，并对MySQL数据库进行了大量优化，MySQL在此期间得到了普及。2009年，Oracle公司以74亿美元收购Sun公司，MySQL随之也成为了Oracle公司旗下的产品。但Oracle公司并没有将MySQL进行封闭开发，而是保持了它的开源性。随着中小企业的迅猛发展，数据库系统需求日益增加，MySQL作为一种开源的数据库系统，是当今世界最流行的关系型数据库管理系统之一，广泛用于中小企业的信息管理系统的建设当中。

MySQL数据库采用双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，一般中小型网站的开发都选择MySQL作为网站数据库。

与其他数据库管理系统相比，MySQL具有以下优势：

1.MySQL的社区版源代码开源。

2.MySQL服务器是一个快速的、可靠的和易于使用的数据库服务器。

3.MySQL服务器工作在客户/服务器或嵌入系统中。

SQL Server是一个关系型数据库管理系统，它最初是由Microsoft、Sybase、Ashton-Tate三家公司共同开发的。这三家公司于1988年推出第一个OS/2版本，在WindowsNT操作系统面世后，Microsoft将SQL Server移植到WindowsNT系统上，并专注于Windows平台的SQL Server开发。经过了多年的发展，在SQLServer2008的版本中，SQL Server推出了许多新的特性和关键的改进，使得它成为了至今最强大和最全面的数据库管理系统之一。

2017年，Microsoft正式发布了Linux版的SQL Server，SQL Server数据库从此可以运行在Linux内核的服务器上。按照微软官方的解释，SQL Server在所有支持的平台上具有相同的基础数据库引擎，提供相同的功能特性。

Microsoft SQLServer同样也是在网络上最流行的存储数据的数据库之一。它已广泛应用于电子商务、银行、保险、电力等相关行业的数据库中。

新版本SQL Server数据库产品具备以下优点：

1.真正的客户机/服务器体系结构。

2.图形化的用户界面，使系统管理和数据库管理更加直观，简单的编程接口工具，为用户进行程序设计提供了更大的选择余地。

3.有很好的伸缩性，支持Windows、Mac、Linux等常见操作系统平台，可以跨平台使用。

4.提供对Python与R语言的支持，适合需要利用机器学习等高级企业功能的企业。

Oracle是甲骨文公司的一款关系型数据库管理系统，在数据库领域一直处于领先地位。可以说Oracle数据库系统是目前世界上最流行的关系型数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。

Oracle数据库产品较其他数据库具有以下优良特性：

1.支持与多种通讯网络相连，支持各种协议（TCP/IP、DECnet等）。

2.良好的兼容性、可移植性、可连接性和高生产率，使Oracle RDBMS具有良好的开放性。

3.提供丰富的企业级特性及稳定性，较其他数据库更适合应用于金融、银行等数据安全要求极高的业务场景。

4.提供快照数据恢复功能，在发生故障后可以将数据恢复到故障发生前的1秒，数据安全性极高。

5.数据库性能高，在开放平台下保持标准SQL测试集中的TPC-D和TPC-C世界记录。

1.支持使用SQL在多个表之间做非常复杂的表关联数据查询。

2.提供强大的事务性，足以满足安全性能要求很高的数据访问需求。

3.使用标准的SQL语言，使得操作非常方便且容易移植。

4.提供数据的强一致性，大大降低数据丢失的概率，保证数据安全。

5.技术成熟、使用广泛、支持工具丰富且功能强大。

1.关系型数据库要求数据强一致性，导致在对一致性的维护中产生很大的开销。

2.模型单一、扩展性较差，系统的升级、功能的增加往往会导致数据结构巨大变动。

3.在进行多表关联查询的过程中，复杂数据分析类型的报表查询等操作会极大地耗费数据库服务器性能。

常见的关系型数据库应用场景如下：

1.银行、证券公司等数据量大且对数据安全性、一致性、高可用性要求极高的业务场景。

2.中小型企业的ERP系统、OA系统等公司内部系统的业务场景。

3.企业网站、博客、论坛和电商网站中需要对结构化数据持久化的互联网业务场景。

MPP即大规模并行处理，是系统架构角度的一种服务器分类方法。从系统架构的分类来看，商用服务器主要分为三类，分别为对称多处理器结构、非一致存储访问结构和大规模并行处理结构。所谓的MPP数据仓库是指以大规模并行处理架构为架构核心，以x86服务器作为底层硬件支撑环境，用于对海量结构化数据进行联机分析处理的并行数据仓库。

MPP数据仓库能轻松应对海量结构化数据的应用场景，其I/O处理能力强，在多种联机分析处理场景有广泛的应用。除此之外，MPP数据仓库部署在x86服务器上，其成本低廉、扩展能力强。在应对复杂多变的海量结构化数据分析的场景中，MPP服务器的并行处理能力优越，能对复杂的数据进行综合分析与处理，其节点互联网络的I/O性能非常突出，是大规模数据处理解决方案中的佼佼者。当然，这也需要借助支持MPP技术的关系型数据库系统来屏蔽节点之间负载平衡与调度的复杂性，以达到数据仓库性能的最优化。

MPP数据库即大规模并行处理数据库，它采用Shared-Nothing架构，各个节点都有自己私有的CPU、内存、硬盘等资源，它们之间是不共享的，每台服务器都有独立的操作系统和管理数据库的实例副本，可以独立工作。这种架构设计具有良好的可拓展性，在应对数据量递增的场景中，只需要增加服务器数量就可以对其处理能力和容量进行横向拓展。

Greenplum数据库是在开源的PostgreSQL的基础上采用了MPP架构的基础上开发出来的性能非常强大的分布式数据仓库。数据仓库主要由主节点（Master Host）、工作节点（Segment Host）、内部通信（Interconnect）三大部分组成。

与其他MPP数据库管理系统相比，Greenplum具有以下优势：

1.平台与基础架构无关，避免云/硬件供应商锁定，具有良好的跨平台性。

2.以Apache协议将源代码开源，受到广泛的关注和社区支持，团结PostgreSQL社区力量快速创新。

Sysbase IQ从16.0 SP10版本开始引入对MPP的支持。采用的Share Nothing Multiplex是一个在大数据环境下针对大规模并行处理的存储和处理架构。在这个存储架构下，主数据存储在一组节点中的直插式存储DAS设备集合中，而不是存储在一个共享存储区域网络设备中。

与其他MPP数据库管理系统相比，Sysbase IQ具有以下优势：

1.Sysbase IQ对列存储的数据通常能得到大于50%的压缩，加上大页面I/O，使得Sybase IQ在获得优良的查询性能的同时，减少了对存储空间的需求。

2.提供智能压缩技术，与精巧的索引结构和列存储结合，Sysbase IQ比其他数据库引擎拥有更好的存储效果。

3.Sysbase IQ数据库引擎的设计与执行进程优先考虑查询性能，支持用户高并发即时查询。

1.相比传统数据库的行存储方式，MPP数据库支持行列混合存储数据，有利于数据压缩，以相对较小的代价换取较大的性能提升。

2.MPP数据库采用无共享架构进行实现，其节点内部只访问自身的CPU、内存和磁盘等资源，它在拓展节点时表现出良好的拓展性，性能稳定，能实现线性扩展。

3.MPP架构数据在决策支持和数据挖掘方面有明显的优势，适合OLAP应用场景。

1.MPP架构数据库需要在不同处理单元之间传送信息，当通信时间占比较高时，MPP架构的性能较弱，效率较SMP架构数据库低。

2.在OLTP应用场景下MPP架构数据库性能没有传统的SMP架构数据库性能高。

传统的关系型数据库具有很多优点，它容易理解、使用方便、易于维护，在社会生产和生活中得到了广泛应用。尽管传统关系型数据库的事物和查询机制能够较好地满足银行、电信运营企业等各类商业公司的数据管理需求，但是随着大数据时代的到来和Web2.0的兴起，关系型数据库在使用时已经显得越来越力不从心，暴露出了很多致命的难以客服的设计缺陷，NoSQL数据库应运而生。

传统型数据库对用户高并发读写的需求响应不够迅速，而通常网站类用户的并发性访问非常高，一台数据库的最大连接数有限，同时硬盘I/O有限，形成了严重的I/O瓶颈，对于海量数据的读写效率十分低。传统的关系型数据库很难满足Web2.0时代对于可扩展性和可用性的高需求，这时市场就急需一个属于新Web2.0时代的数据库解决方案。

在这种背景下，NoSQL应运而生。NoSQL泛指非关系型数据库，它的产生就是为了解决大规模数据集合多重数据种类带来的挑战，它的出现很好地满足了Web2.0的需求，开辟了一片新市场。

在社交网络等新型应用的冲击下，面对数以亿计数据的高效存储和高并发读写，以及系统要求较好的扩展性和可用性等，传统数据库的RDBMS渐渐暴露了自身的不足，越来越多的数据库架构设计者将重点对准了非关系型数据库技术。在这种环境下，NoSQL的出现引起了世界的关注。因为NoSQL数据库具有灵活的存储方式、高可用性和高扩展性等优点，很多知名的数据库生产商都把重心渐渐转向对NoSQL的研究和开发。NoSQL存储形式是在牺牲了部分RDBMS中的标准功能（如存取控制、数据一致性等功能）的基础上，保证了超大量数据存储时的高可用性。NoSQL数据库技术是在人们结合自身业务系统的实际情况中逐步发展起来的，它主要分成了“Non-Relational”和“Not Only SQL”两个阶段。

在社交网络等新型应用的冲击下，传统关系型数据库逐渐出现了不少问题，它在数据的类型上有一定的局限性，无法存储对象数据，无法存储和处理Web2.0时代所产生的海量文本、图像等非结构化数据。“Non-Relational”的概念就是从这个时期开始吹捧起来的。“Non-Relational”是指非关系型数据库，即利用非关系型数据库解决业务系统数据组织、存储、管理的所有问题，它被认为是取代传统关系型数据库的解决方案。一些人把传统关系型数据库批判得一无是处，认为所有的数据都应该使用NoSQL来组织、存储、管理。然而，在“Non-Relational”应用到实际生产当中时，人们又发现了非关系型数据库搜索繁琐、存储结构混乱等缺点，特别是在处理强一致性事务的时候，显得无计可施。在经过对自身业务场景的深入思考后，人们发现非关系型数据库也存在一定缺陷，一味地否定关系型数据库在信息管理系统建设中的作用是不可取的，应该将关系型数据库和非关系型数据库的优势结合起来，以解决Web2.0时代所存在的新问题。因此，人们对NoSQL的定义开始从“Non-Relational”向“Not Only SQL”转变。

关系型数据库和非关系型数据库各自拥有不同的优势。关系型数据库的ACID特性让许多联机事务处理的应用场景变得非常简单，而非关系型数据库的出现也放开了数据的存储方式的限制。通过上述分析发现，它们两者并不是对立关系，而是相互补充。因此，从“Non-Relational”向“Not Only SQL”转变的呼声便越来越高。所谓的“Not Only SQL”，即数据管理技术不仅仅是SQL。在人们认识到关系型数据库也有其无法取代的特点的同时，也确定了非关系型数据库的数据存储的重要性，大家也开始逐渐接受“Not Only SQL”的说法。

随着Web2.0的发展，适合于存储非结构化数据的NoSQL数据库得到了快速发展。NoSQL数据库虽然品类繁多，但从功能上主要可以划分为键值数据库、文档数据库、列族数据库和图形数据库四类。

键值数据库（key-value database）会使用一个哈希表，这个表中有一个特定的键（key）和一个指针指向特定的值（value）。键可以用来定位值，即存储和检索具体的值。值对数据库而言是透明不可见的，不能对值进行索引和查询，只能通过键进行查询。值可以用来存储任意类型的数据，包括整型、字符型、数组、对象等。在存在大量写操作的情况下，键值数据库可以比关系型数据库取得明显更好的性能。因为关系型数据库需要建立索引来加速查询，当数据库进行大量写操作时，索引会发生频繁更新，由此会产生高昂的索引维护代价。所以，关系型数据库通常很难进行水平扩展，而键值数据库天生具有良好的伸缩性，理论上几乎可以实现数据量的无限扩容。键值数据库可以进一步划分为内存键值数据库和持久化（persistent）键值数据库。内存键值数据库把数据保存在内存，如Memcached和Redis。持久化键值数据库把数据保存在磁盘，如BerkeleyDBVoldmort和Riak。持久化就是将内存数据转换为硬盘数据，并从内存模型转换到存储模型，或者说是瞬时状态和持久状态的相互转换。当然，键值数据库也有自身的局限性，条件查询就是键值数据库的弱项。因此，如果只对部分值进行查询或更新，键值数据库的效率就会比较低下。在使用键值数据库时，应该尽量避免多表关联查询，此时可以采用双向冗余存储关系来代替表关联，把操作分解成单表操作。此外，键值数据库在发生故障时不支持回滚操作，因此无法支持事务。表4-1给出了键值数据库的相关产品、数据模型、典型应用、优缺点和使用者。

在文档数据库中，文档是数据库的最小单位。文档数据库种类虽多样，但是大都对数据以某种标准化格式进行封装存储，包括XML、YAML、JSON和BSON等，或者使用二进制格式（如Word、PDF等）。文档数据库通过键来定位一个文档，因此可以看成键值数据库的一个衍生品，而且前者比后者具有更高的查询效率。对于那些可以把输入数据表示成文档的应用而言，文档数据库是非常合适的一个文档可以包含非常复杂的数据结构，如嵌套对象，并且不需要采用特定的数据模式，每个文档可能具有完全不同的结构。文档数据库既可以根据键来构建索引，也可以基于文档内容来构建索引。尤其是在基于文档内容的索引和查询上，它不同于键值数据库，因为在键值数据库中，值对数据库是透明不可见的，不能根据值来构建索引。文档数据库主要用于存储并检索文档数据，当需要考虑很多关系和标准化约束以及需要事务支持时，传统的关系型数据库是更好的选择。表4-2给出了文档数据库的相关产品、数据模型、典型应用、优缺点和使用者。

列族数据库一般釆用列族数据模型，数据库由多个行构成，每行数据包含多个列族，不同的行可以具有不同数量的列族，属于同一列族的数据会被存放在一起。每行数据通过行键进行定位，与这个行键对应的是一个列族，从这个角度来说，列族数据库也可以被视为一个键值数据库。列族可以被配置成支持不同类型的访问模式，一个列族中各列限定符共享同一存储空间。表4-3给出了列族数据库的相关产品、数据模型、典型应用、优缺点和使用者。

图形数据库以图论为基础，图是一种典型的数据结构，用来表示一个对象集合。通常图分为有向图和无向图两种，是一种权值结构。图形数据库使用图作为数据模型来存储数据，完全不同于键值、列族和文档数据模型，可以高效地存储不同顶点之间的关系。图形数据库专门用于处理具有高度相互关联关系的数据，可以高效地处理实体之间的关系，比较适合于社交网络、依赖分析、推荐系统及路径寻找等问题。有些图形数据库（如Neo4J），完全兼容ACID。但是，除了在处理图和关系这些应用领域具有很好的性能以外，在其他领域，图形数据库的性能不如其他NoSQL数据库。表4-4给出了图形数据库的相关产品、数据模型、典型应用、优缺点和使用者。

NoSQL数据库的优点主要包括以下几种：

相比于传统数据库系统，NoSQL具备优良的可扩展性。NoSQL数据库不存在关系型数据库的关系型特性，数据之间没有关联，故得到可扩展性。

NoSQL数据库相对于其他数据库系统具备很高的读写性能，特别适合在大数据量环境下使用。这个优势得益于它的非关系型架构，结构也十分简单。NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能就要高很多了。同时“索引”作为一个在传统关系型数据库中加快检索表中数据的方法，使用在大量非结构化数据的处理时反而会使性能变低。NoSQL中没有“索引”这一概念，使其在性能上比传统的关系型数据库略胜一筹。

NoSQL可以随时存储自定义的数据格式，无须事先为要存储的数据建立字段。反观关系型数据库，在关系型数据库中修改字段一直是一件非常不方便的事情。如果表的数据量非常大，则无法完成对数据库系统字段的修改。

1.不支持原生SQL标准查询语句，用户需要花费一定的学习和理解时间才能掌握使用方法。

2.NoSQL产品大多为初创产品，在成熟程度上，与经历了几十年逐步完善的传统关系型数据库不可同日而语。

3.NoSQL数据库不支持事务特性，也不提供BI和报表等各种附加功能。

因此在现阶段，NoSQL数据库并不能将关系型数据库的地位取而代之，而是作为不同应用场景的另一种有效的解决方案。

Web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，数据库的负荷量会非常高，要达到每秒上万次读写请求，这时候需要NoSQL数据库来处理和保存这些巨量的高并发数据。

大型的网站，每天用户产生海量用户动态，比如某些网站一个月就能产生2.5亿条用户动态，对于关系型数据库来说，在一张2.5亿条记录的表里面进行SQL查询，它的效率极其低下。大型Web网站的用户登录系统，关系型数据库无法解决并发查询和访问的需求。

关系型数据库在基于Web的架构中进行横向扩展有很高的难度，这导致其缺乏了高可用性和可伸缩性。NoSQL数据库能够使用数据冗余来提高可用性，NoSQL追求强最终一致性，它通常只有当最终一致性是可接受的时，读操作才能被分散到不同的节点，这也是NoSQL具备高可用性的原因。

HBase是Apache Hadoop中的一个子项目，是Bigtable的开源版本，所用的语言为Java。HBase在列上实现了BigTable论文提到的压缩算法、内存操作和布隆过滤器。HBase的表能够作为MapReduce任务的输入和输出，可以通过Java API来访问数据，也可以通过REST、Avro或者Thrift的API来访问。

（1）存储容量大，一个表可以容纳上亿行，上百万列。

（2）通过版本进行检索，搜到所需的历史版本数据。

（3）负载高时，通过简单的添加机器来实现水平切分扩展，与Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。在此基础上可有效避免单点故障的发生。

（1）单一RowKey固有的局限性决定了它不可能有效地支持多条件查询。

（2）不适合大范围扫描查询。

（3）不直接支持SQL的语句查询。

（1）Bigtable类型的数据存储。

（2）对数据版本查询的需求。

（3）处理超大数据量，要求扩展简单的需求。

Redis是一个开源的键值数据库，它基于ANSI C语言编写，支持网络，可基于内存亦可持久化的日志型、键值数据库，并提供多种语言的API。由VMware主持开发工作。

Redis被称为数据结构服务器，值可以是字符串、哈希、列表、集合和有序集合五种类型，操作非常方便。比如，如果在做好友匹配系统，查看自己的好友关系时，如果采用其他的键值系统，把对应的好友拼接成字符串，然后在提取好友时，value进行解析，Redis则相对简单，直接支持list的存储（采用双向链表或者压缩链表的存储方式）。

（1）支持多种数据结构的存储。

（2）Redis提供了事务的功能，保证一串命令的原子性，不会被任何操作打断。

（3）数据存在内存中，读写高速，可以达到10w/s的频率。

（1）Redis3.0后出来官方的集群方案，存在一些架构上的问题。

（2）持久化功能体验不佳，通过快照方法实现的话，需要每隔一段时间将整个数据库的数据写到磁盘上，代价非常高；aof方法只追踪变化的数据，类似于MySQL的binlog方法，但追加log可能会出现过大，同时所有操作均要重新执行一遍，恢复速度慢。

（3）由于Redis是一种内存数据库，所以单台机器存储的数据量是机器本身的内存大小。虽然Redis本身有Key过期策略，但还是需要提前预估和节约内存。在使用过程中，需要定期删除数据。

适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。

MongoDB是一个高性能、开源、无模式的文档型数据库，开发语言是C++。它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。在MongoDB中，文档是对数据的抽象，它的表现形式就是常说的BSON（Binary JSON）。BSON是一个轻量级的二进制数据格式。MongoDB能够使用BSON，并将BSON作为数据的存储存放在磁盘中。BSON是为效率而设计的，它只需要使用很少的空间，同时其编码和解码都是非常快速的。即使在最坏的情况下，BSON格式也比JSON格式存储效率高。

（1）强大的自动化shading功能。

（2）全索引支持，查询非常高效。

（3）面向文档（BSON）存储，数据模式简单而强大。

（4）支持动态查询，查询指令也使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。

（5）支持JavaScript表达式查询，可在服务器端执行任意的JavaScript函数。

（1）单个文档大小限制为16M，32位系统上，不支持大于2.5G的数据。

（2）对内存要求比较大，至少要保证热数据（索引，数据及系统其他开销）都能装进内存。

（3）非事务机制，无法保证事件的原子性。

（1）适用于实时插入、更新与查询的需求，并具备应用程序实时性高的场景。

（2）适合文档化格式的存储、查询。

Couchbase其实是由CouchDB和Membase的开发商合并后开发出来的产品。两家公司合并之后的公司基于Membase与CouchDB开发了一款新产品，新产品的名字叫做Couchbase。Couchbase可以说是集合众家之长，目前应该是最先进的Cache系统，其开发语言是C/C++。Couchbase Server是个面向文档的数据库（其所用的技术来自于Apache CouchDB项目），能够实现水平伸缩，并且对于数据的读写来说都能提供低延迟的访问（这要归功于Membase技术）。

（1）高并发性、高灵活性、高拓展性、容错性好。

（2）以vBucket的概念实现更理想化的自动分片以及动态扩容（了解更多）。

（1）Couchbase的存储方式为Key/Value，但value的类型很单一，不支持数组类型，另外也不会自动创建docid，需要为每一文档指定一个用于存储的Document Indentifer。

（2）采用缓存全部Key的策略，需要大量内存。节点宕机时failover过程有不可用时间，并且有部分数据丢失的可能，在高负载系统上有假死现象。

（3）逐渐倾向于闭源，社区版本和商业版本之间有较大的差距。

（1）适合对读写速度要求较高，但服务器负荷和内存花销可遇见的需求。

（2）需要支持memcached协议的需求。

LevelDB是由Google公司重量级工程师开发的开源项目，它是能处理十亿级别规模键值型数据持久性存储的程序库，开发语言是C++。LevelDB有一个特点是写的性能远高于读的性能。

（1）操作接口简单，基本操作包括写记录、读记录和删除记录，也支持针对多条操作的原子批量操作。

（2）写入性能远强于读取性能。

（3）随着数据量的增长，读写性能下降趋于平缓。

（1）随机读性能一般。

（2）对分布式事务的支持还不成熟。而且机器资源浪费率高。

适用于对写入需求远大于读取需求的场景。

内存数据库是一个位于应用集群和后端数据源之间的高性能、分布式的操作数据管理的基础架构。它提供了低延迟、高吞吐量的数据共享和事件分发。内存数据库充分利用网络中的内存和磁盘资源，形成一个实时的数据网格。

考虑到问题的多样性和架构的灵活性，内存数据库提供了多种选项来配置管理缓存数据，从而可以在P2P、CS、WAN三大组件构建出合适的缓存架构。

整个内存数据库分成四层（图4-4），其中，最底层为数据库层，用于数据存储和数据持久化。往上是内存计算层，这一层是用于实现内存计算的，这一层可对数据进行缓存，它为客户端提供了内存访问的接口，此层可以负责跨分布式系统同步内存中的数据，通过透明网关，将缓存的数据存储到数据层中。在集群中大量的内存计算通过内存计算层，形成数据网格，从而实现内存计算。第三层为中间件层，该层主要由服务器组成，在服务器上面部署操作系统和中间件应用，供上层应用使用。在这个结构的最上面，有一个友好的应用管理界面，所有需要使用内存计算的应用都通过这个应用界面进行操作。在中间件层和Web层之间，使用负载均衡对整个集群的服务器进行负载管理，以适应实时数据大并发量的问题。

使用该体系的四层结构具有以下优点：

1.应用层的负载均衡，通过应用系统灵活的部署方式借助虚拟化技术充分利用系统硬件资源，提升系统整体性能，保障业务连续性。

2.服务级的故障切换，借助虚拟化的高可用机制及负载均衡器的动态监测机制，当服务发生故障或者系统服务压力过大时，实现服务的自动切换或迁移。

3.集群中服务出现异常时，可以自适应地切换到正常的服务上去。当某系统主机资源出现压力过大时，可以动态调整空闲资源提供服务，针对这一点传统中间件集群是做不到的。

通过将若干x86服务器的内存集中起来，组成一个几十TB的内存资源池，将全部数据加载到内存中，进行内存计算。计算过程本身不需要读写磁盘，只是定期将数据以同步或异步的方式写到磁盘。内存数据库在分布式集群中保存了多份数据，任何一台机器故障，其他机器上还有备份数据，不用担心数据丢失，而且有磁盘数据作为备份。内存数据库支持把内存数据持久化到关系型数据库、HDFS和其他文件系统中。

内存数据库有很多相对于其他数据库的优点：

1.采用复杂的数据模型表示数据结构，数据冗余小、易扩充，能实现数据共享。

2.具有较高的数据和程序独立性，数据库的独立性分成物理独立性和逻辑独立性。

3.内存数据库提供易用的用户接口。

4.内存数据库提供4个方面的数据控制功能，分别是并发控制、恢复、完整性和安全性。数据库中各个应用程序所使用的数据由数据库统一规定，按照一定的数据模型组织和建立，由系统统一管理和集中控制。

5.增加了系统的灵活性。

尽管如此，内存数据库现阶段还有很多劣势不可忽视，例如其成本过高。内存数据库不同于其他数据库使用磁盘作为存储介质，它通过结合多台服务器的内存组成一个TB级甚至PB级的内存存储空间。众所周知，内存的价格是普通硬盘价格的几十倍，故内存数据库的配置成本是十分昂贵的。

1.稳定且高性能的基于内存的数据存储。

2.灵活的Cache部署策略　支持点对点、客户端/服务端、多集群等方式的本地或远程数据同步，支持数据高性能灾备和双活。

3.提供灵活的Region分布式处理　同一集合数据、同一个Region，将整个集群的多个节点进行同步或切割后不同点保存，支持数据实时再平衡（即数据分隔保存后，若加入新的空闲服务器，数据可以在不重启服务的情况下重新切割和平衡数据），从而达到真正的数据在线动态延展。

4.具有数据高可用性和容错性　各个分散的数据点可以配置一个或多个基于内存的热备数据点，在主数据点宕机的情况下，其中一个热备数据点就会提升成为主数据点，同时可以继续在空闲机器上创建备份点，从而达到数据的持续可用性。同时，数据可以通过配置同步或异步地持续化到本地硬盘，或者到指定的数据库或文件中。

5.数据地客户端缓存　客户端可以将最常用的数据缓存一个备份到本地，进一步加快效能。

6.支持在线数据备份。

7.数据全内存和部分内存策略　通过配置可以将数据全部存入内存，或者通过将非频繁使用数据挤出策略（LRU）来将部分频繁使用的数据保存于内存中，达到成本效益最大化。

8.内置资源优化器用以降低JAVA GC所带来的延迟，支持单个大容量Cache点（一般服务器可配置超过40GB内存的Java heap size）。

9.安全支持　基于用户和角色的数据访问，数据传输渠道加密（SSL）。

SQL Server 2016的In-Memory OLTP，通俗地讲，是内存数据库，使用内存优化表（Memory-Optimized Table，MOT）来实现。MOT驻留在内存中，使用Hekaton内存数据库引擎访问。在查询MOT时，只从内存中读取数据行，不会产生Disk IO消耗。在更新MOT时，数据的更新直接写入内存中。内存优化表能够在Disk上维护一个数据副本，该副本只用于持久化数据，不用于数据读写操作。

Apache Ignite是一个内存数据组织，是高性能的、集成化的以及分布式的内存平台，它可以实时地在大数据集中执行事务和计算，和传统的基于磁盘或者闪存的技术相比，性能有很大提升。

FastDB是高效的关系型内存数据库系统，具备实时能力及便利的C++接口。FastDB针对应用程序，通过控制读访问模式进行了优化。通过降低数据传输的开销，利用锁机制提供高速查询支撑。将每一个使用数据库的应用数据库文件映射到虚拟内存空间中，因此查询在应用的上下文中执行而不需要切换上下文以及数据传输。FastDB并发访问数据库的同步机制通过原子指令实现，几乎不需要增加查询的开销。

资源管理器要处理的问题通常包括几部分：资源分配的策略、资源分配的粒度、资源分配的方式、不同类型任务的调度。

进行资源调度管理的目的是为了提高全系统的资源利用率，并使其支持动态调整切分资源，增强系统扩展性。目前常见的资源调度框架有Mesos、YARN、Coraca、Torca等。

Mesos诞生于UC Berkeley的一个研究项目，是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后得到广泛使用。Mesos现已成为Apache Incubator中的项目，当前一些公司使用Mesos来管理集群资源。

同其他大部分分布式系统一样，Apache Mesos为了简化设计，也采用了master/slave结构，为了解决master的单点故障，将master做得尽可能轻量级，其上面所有的元数据可以通过各个slave重新注册而进行重构，故很容易通过Zookeeper解决单点故障问题。

YARN从Hadoop1.0发展而来。由于Hadoop1.0资源管理十分混乱，存在很多资源调度上的问题。在Hadoop1.0中MapReduce是master/slave结构，在集群中的表现形式为集群中含有一个JobTracker节点和多个TaskTracker节点。

1.JobTracker负责资源管理和作业调度。

2.TaskTracker定期向JobTracker汇报本节点的健康状况、资源使用情况以及任务执行情况，接收来自JobTracker的命令（启动/杀死任务等）并执行接收到的命令。

Hadoop1.0存在的主要问题为：

Hadoop1.0中JobTracker只有一个，一旦JobTracker失效，则整个集群会无法使用。

Hadoop1.0中JobTracker负责接收来自各个JobTracker节点的RPC请求，压力会很大，限制了集群的扩展。随着节点规模的增大，JobTracker成为了一个瓶颈。

MapReduce计算框架是一个基于Map和Reduce两阶段、适合批处理的基于磁盘的计算框架。Hadoop1.0仅支持MapReduce这一个计算框架，不支持其他的任何计算框架。

在没有YARN之前，Hadoop平台是一个集群对应一个计算框架。但是这种架构造成各个集群管理复杂，资源的利用率很低，有时候会出现在某个时间段内Hadoop集群繁忙而Spark集群闲置的情况，反之亦然。这样会导致各个集群之间不能共享资源，造成集群间资源无法充分利用，资源严重浪费。

YARN的出现主要解决了Hadoop1.0扩展性受限、单点故障、难以支持MapReduce之外的计算框架的问题，实现了通用的统一的资源管理系统：①YARN可以同时运行长应用程序；②YARN可以运行短应用程序。对于YRAN的具体介绍和分析我们会在后面的部分提到。

Hadoop Corona是Facebook开源的下一代MapReduce框架。基本设计动机和Apache的YARN一致。Cluster Manager类似于YARN中的Resource Manager，负责资源分配和调度。Cluster Manager掌握着各个节点的资源使用情况，并将资源分配给各个作业（默认调度器为Fair Scheduler）。同YARN中的Resource Manager一样，Resource Manager是一个高度抽象的资源统一分配与调度框架，它不仅可以为MapReduce，也可以为其他计算框架分配资源。Corona Job Tracker类似于YARN中的Application Master，用于作业的监控和容错，它可以运行在两个模式下：

1.作为JobClient，用于提交作业和方便用户跟踪作业运行状态。

2.作为一个Task运行在某个TaskTracker上。与MRv1中的JobTracker不同，每个Corona Job Tracker只负责监控一个作业。

3.Corona Task Tracker类似于YARN中的Node Manager，它的实现重用了MRv1中Task Tracker的很多代码，通过心跳将节点资源使用情况汇报给Cluster Manager，同时会与Corona Job Tracker通信，以获取新任务和汇报任务运行状态。

4.Proxy Job Tracker用于离线展示一个作业的历史运行信息，包括Counter、metrics、各个任务运行信息等。相比YARN，Coraca和Hadoop耦合比较深。

云计算的基础技术是集群技术，支撑集群高效协同工作需要一系列资源和任务调度算法。良好的调度算法可以提高集群处理能力、有效分配资源、加速作业进度。在这系列调度算法中，有三种核心算法奠定了集群互连互通的基础，它们是Paxos算法、DHT算法和Gossip协议。Paxos算法解决分布式系统中信息一致性问题；DHT算法解决分布式网络的应用层选路问题；Gossip协议解决分布式环境下信息高效分发问题。

Paxos算法解决的问题是一个分布式系统如何就某个Value（决议）达成一致。在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么它们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。Paxos算法作为分布式系统中最著名的算法之一，在目前所有的一致性算法中，该算法最常用而且被认为是最有效的。

Paxos算法的核心是，只要满足下面三个条件就能保证数据的一致性：

条件1：一个Value只有在被proposer提出之后才可以被choose。

条件2：每次只有一个Value被choose。

条件3：Value只有被choose之后才能被learners所获取。

这三个条件其实很好理解，而这三个条件中最重要的就是条件2，Paxos算法也就是对条件2的不断加强。

下面有一个使用Paxos算法的例子：

在一个分布式数据库系统中，有5个节点S1、S2、S3、S4、S5，假设各节点的初始状态一致，则每个节点都执行相同的操作序列，那么它们最后能得到一个一致的状态。现在用Paxos算法保证每个节点都执行相同的操作序列。假设S1只传输SQL命令（Proposer），剩下的都是数据库节点（Accepter）。

步骤1：S1选定编号1（假设第一个命令编号为1），向集合Database={S2，S3，S4，S5}的一个多数派子集发送Prepare Request（PR）。

步骤2：如果通信顺利，所有的多数派都收到了PR，因为这是它们所接收的第一个prepare，所以这个多数派的成员都会回应S1一个promise，因为之前它们还没有接收过任何proposal，所以promise不带回proposal。如果通信部分失败，导致接收到PR的节点不构成多数派，则S1重复步骤1（PR编号递增）。

步骤3：S1接收到多数派的paromise，向集合Database发出带有第一个SQL命令（这里的SQL命令就是之前的Value）的proposal，编号为1。因为promise没有带回，所以这里的SQL命令没有限制。

步骤4：如果通信顺利，所有的数据库节点都收到了S1所提出的proposal（编号为1），因为之前它们并没有做过任何编号大于1的prepare，因此它们接收这个proposal，由此多数派形成，决议也就产生了。然后各个节点执行决议的内容，也就是SQL命令，等待S1提出第二个SQL命令。如果通信部分失败，这种情况下，如果接受到proposal 1的节点可以构成多数派，则和通信顺利的情况下一样；反之则不然，由于构不成多数派，则不能产生决议，所有的数据库节点都不执行SQL命令，从而保证了数据库内容的一致性。

步骤5：重复以上操作，注意proposal、prepare及promise的编号递增，以及promise根据情况带回proposal。

YARN是在Hadoop2.0中新定义并加入Hadoop生态系统的组件，它本质上是一个分布式统一资源管理与调度系统。YARN接管了Hadoop1.0版本中MapReduce负责的资源管理部分的工作，使得资源管理与资源使用两种功能之间解耦合，增强了Hadoop的组件化、模块化架构。

YARN总体上仍然是master/slave结构，在整个资源管理框架中，ResourceManager为master，NodeM-anager是slave。ResourceManager负责对各个NodeManager上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

ResouceManager是master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等。整个系统集群的资源调度与管理都由ResouceManager来实现，并且通过它处理来自客户端的请求，从而监控各NodeManager的状态以及向其分发任务。它是一个全局的资源管理器，在一个集群中只存在一个，负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控APP master、监控NodeManager、资源的分配与调度。它主要由两个组件构成：调度器（scheduler）和应用程序管理器（applications manager，ASM）。

NodeManager是slave上一个独立运行的进程，一个集群存在多个NodeManager，它负责每个节点上的资源和使用，并且负责单个节点上的资源管理和任务、处理来自ResourceManager的命令以及处理来自app master的命令。

ApplicationMaster由NodeManager启动并负责对应用容器的生命周期进行管理，它管理YARN内运行的应用程序的每个实例，为应用程序申请资源并进一步分配给内部任务。ApplicationMaster可以协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用情况。

Container容器是封装了一定数量CPU、内存、磁盘等资源的逻辑单元，它由ResourceManager根据请求资源的容量而创建。Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前为止，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制cGroups进行资源隔离。

YARN接收一个MapReduce作业的资源请求可分为以下几个步骤（图4-5）：

1.客户端向ResouceManager提交MapReduce应用程序作业请求。

2.ResouceManager经过资源调度算法的计算向多个NodeManager分发任务。

3.NodeManager启动一个应用管理器ApplicationMaster。

4.ApplicationMaster向ResourceManager请求资源运行应用程序。

5.ResourceManager根据请求资源的容量以及队列限制创建容器并返回。

6.用户的MapReduce应用程序分布式地运行在多个容器上。

7.在程序执行结束后，由于ApplicationMaster向ResourceManager申请对容器进行注销操作。

真正做到“一个集群多个框架”，是YARN一直努力的方向，YARN希望在一个集群上只需要部署一个统一的资源调度管理框架，即可在其上部署各种各样的计算框架，如Storm、MapReduce、Spark等。由统一的资源调度管理框架为这些计算框架提供资源管理调度服务，统一监控各计算框架对资源的使用情况，实现资源的共享与弹性缩放。

实现由统一的资源调度管理，可以提高集群的利用率，满足因需要使用多个计算框架而进行统一资源管理的需求。同时，不同计算框架可以共享底层存储，在一个集群上集成多个数据集，使用多个计算框架来访问这些数据集，从而避免了数据集跨集群移动，符合分布式系统中“计算跟随数据走”的思想，这种部署方式由于多种框架运行于同一集群，可以大大降低企业运维成本。

1.Xinzhu Lu，Keatkeong Phang.An Enhanced Hadoop Heartbeat Mechanism for MapReduce Task Scheduler Using Dynamic Calibration[J].中国通信，2018，15（11）：93-110.

2.Raste K S .Big Data analytics-Hadoop performance analysis[J].Dissertations&Theses-Gradworks，2014.

3.Lakhe B .Practical Hadoop migration[J].Springer Berlin，2016.

4.Xie J，Luo J.Construction for the city taxi trajectory data analysis system by Hadoop platform[C]//IEEE，International Conference on Big Data Analysis.IEEE，2017.

5.吴信东，嵇圣硙.MapReduce与Spark用于大数据分析之比较[J].软件学报，2018，29（06）：1770-1791.

6.宋杰，孙宗哲，毛克明，等.MapReduce大数据处理平台与算法研究进展[J].软件学报，2017，28（03）：514-543.

7.王会举，覃雄派，王珊，等.面向大规模机群的可扩展OLAP查询技术[J].计算机学报，2015，38（01）：45-58.

8.潘巍，李战怀，伍赛，等.基于消息传递机制的MapReduce图算法研究[J].计算机学报，2011，34（10）：1768-1784.

9.郭文惠.数据湖——一种更好的大数据存储架构[J].电脑知识与技术，2016，12（30）：4-6.

10.杨栋枢，张明明，石磊.基于内存计算的电力负荷预测[J].计算机系统应用，2016，25（7）：203-207.

11.李玉卿，吴帆，张见，等.AFC动态数据仓库应用系统中的查询竞争问题研究[J].铁路通信信号工程技术，2017，14（5）：83-87.

12.李敏强，纪仕光，陈富赞，等.数据仓库系统的结构与设计研究[J].管理科学学报，1997（2）：25-33.

13.张华强.关系型数据库与NoSQL数据库[J].电脑知识与技术，2011，7（20）：4802-4804.

14.Vohra D .Practical Hadoop Ecosystem[M].Apress，2016.

15.White T .Hadoop：the Definitive Guide[M].南京：东南大学出版社，2011.

16.Devlin　B.DataWarehouseFrom　ArchitecturetoImplementation[M]//DataWarehouse：From　Architectureto Implementation.1997.

17.林子雨.大数据技术原理与应用：概念、存储、处理、分析与应用.北京：人民邮电出版社，2015.

18.王伟.计算机科学前沿技术.北京：清华大学出版社，2012.

19.王宏志，李春静.Hadoop集群程序设计与开发.北京：人民邮电出版社，2018.

20.侯宾.NoSQL数据库原理.北京：人民邮电出版社，2018.

21.刘鹏.大数据.北京：电子工业出版社，2017.

22.刘鹏.云计算.北京：电子工业出版社，2015.

23.国家工业信息安全发展研究中心.大数据优秀产品、服务和应用解决方案案例集（2016）.北京：电子工业出版社，2017.