[正式版]《大数据原理与实践》第7次微信公开课：Management
本次课程讨论大数据管理方面的技术，主要包括如下几个方面的内容：
什么是数据管理？
数据库和数据仓库
大数据管理技术新格局
实例分析：星环TDH
1、什么是数据管理？
数据获取技术的革命性进步、存储器价格的显著下降以及人们希望从数据中获得知识的客观需要等，催生了大数据。数据管理技术迎来了大数据时代。
数据管理是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程。其目的在于充分有效地发挥数据的作用。随着计算机技术的发展，数据管理经历了人工管理、文件系统、数据库系统、以及今天的大数据管理四个发展阶段。
（1）人工管理阶段
20世纪50年代中期以前，计算机主要用于科学计算，这一阶段数据管理的主要特征是：
数据不保存。由于当时计算机主要用于科学计算，一般不需要将数据长期保存，只是在计算某一课题时将数据输入，用完就撤走。不仅对用户数据如此处置，对系统软件有时也是这样。
应用程序管理数据。数据需要由应用程序自己设计、说明和管理，没有相应的软件系统负责数据的管理工作。
数据不共享。数据是面向应用程序的，一组数据只能对应一个程序，因此程序与程序之间有大量的冗余。
数据不具有独立性。数据的逻辑结构或物理结构发生变化后，必须对应用程序做相应的修改，这就加重了程序员的负担。
（2）文件系统阶段
20世纪50年代后期到60年代中期，这时硬件方面已经有了磁盘、磁鼓等直接存取存储设备；软件方面，操作系统中已经有了专门的数据管理软件，一般称为文件系统；处理方式上不仅有了批处理，而且能够联机实时处理。用文件系统管理数据具有如下特点：
数据可以长期保存。由于大量用于数据处理，数据需要长期保留在外存上反复进行查询、修改、插入和删除等操作。
由文件系统管理数据。
同时，文件系统也存在着一些缺点，其中主要的是数据共享性差，冗余度大。在文件系统中，一个文件基本上对应于一个应用程序，即文件仍然是面向应用的。当不同的应用程序具有部分相同的数据时，也必须建立各自的文件，而不能共享相同的数据，因此数据冗余度大，浪费存储空间。同时，由于相同数据的重复存储、各自管理，容易造成数据的不一致性，给数据的修改和维护带来了困难。
（3）数据库系统阶段
20世纪60年代后期以来，计算机管理的对象规模越来越大，应用范围有越来越广泛，数据量急剧增长，同时多种应用、多种语言互相覆盖地共享数据集合的要求越来越强烈，数据库技术边应运而生，出现了同意管理数据的专门软件系统——数据库管理系统。
用数据库系统来管理数据比文件系统具有明显的优点，从文件系统到数据库系统，标志着数据库管理技术的飞跃。
（4）大数据管理系统
随着大数据时代的来临，数据管理面临着新一轮的挑战。针对大数据的复杂特征，如体量大、结构类型多、来源广、多维度、关联强、及时性、积累久、价值密度低、最终价值大等，如何开展大数据的管理工作成为学术界和工业界共同关注的话题。从技术上来看，Hadoop生态和Spark生态已经成为构建大数据管理系统的主流方案。
而从管理角度看，大数据管理的本质是在大数据基础设施层之上向用户提供更加方便、高效、友好的人数交互界面。随着大数据处理技术的发展，大数据的终端用户将越来越不用关心底层的基础设施（计算、存储、网络）细 33 44593 33 14987 0 0 2378 0 0:00:18 0:00:06 0:00:12 3122节，只用关心数据本身，以及如何来开展大数据应用的创新与服务。这种大数据基础设施的透明化将成为大数据平台的一大趋势，也是本次课程的重点内容。
2、数据库管理
20世纪70年代初，IBM工程师Codd发表了著名的论文“ARelational Model of Data for Large Shared Data Banks”，开启了数据管理技术的新纪元——关系数据库时代。关系数据库管理系统（Relational Database Management System，简称RDBMS）就是在这篇论文的基础上设计出来的。在此之前的数据库系统主要有基于层次模型的层次数据库（比如IBM公司的IMS系统）、基于网状模型的网状数据库（比如IDS数据库）等。这些数据库的主要缺点是，其数据模型对于普通用户来讲难以理解，同时，软件的编写和数据的模式（Schema）联系过于紧密。层次和网状数据结构都是导航式（Navigational）的数据结构，存取特定的数据单元必须在软件中按照一定的存取路径去提取，当数据模式发生改变时，已经编写好的软件需要做相应的修改。
Codd提出的关系数据模型基于表格（关系）、行、列、属性等基本概念，把现实世界中的各类实体（entity）及其关系（relationship）映射到表格上。这些概念易于理解。Codd还为关系模型建立了严格的关系代数运算。
关系模型在首次提出来的时候曾经受到严重的质疑。一些专家学者认为，关系数据库需要进行表格的连接操作，不可能获得和层次、网状数据库一样的高性能。但是历史的潮流不可阻挡，世界各地的研究人员致力于关系数据模型及相关技术（特别是查询处理技术）的研究和开发。研究人员对包括存储、索引、并发控制、查询优化、执行优化（包括各种连接算法）等关键技术进行了研究，并且针对数据库的ACID（Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性）保证提出了日志、检查点和恢复等技术。这些技术解决了数据的一致性、系统的可靠性等关键问题，为关系数据库技术的成熟以及在不同领域的大规模应用创造了必要的条件。
研究人员还掀起了关系数据库系统开发热潮，特别值得提及的两个原型系统，一个是IBM开发的System R，另一个是加州大学伯克利分校开发的Ingres。这两个系统最后都演化为成熟的关系数据库产品。若干围绕关系技术的数据库公司和产品部门纷纷成立，大浪淘沙，其中获得商业上成功的公司（部门）主要有IBM（DB2）、Oracle（oracle）、Informix、Sybase、微软（SQL server）、SAP等。这些数据库技术公司创造了庞大的数据库产业，每年创造巨大的产值，仅Oracle一家，年财政年度的销售收入就达到几百亿美元。
1974年，交互式查询语言SEQUEL（Structured EnglishQuery Language）作为System R项目的一部分，被IBM的工程师开发出来。这是SQL语言的前身。现在，SQL语言已经成为国际标准，成为各个厂家数据库产品的标准的数据定义语言、查询语言和控制语言。SQL语言非常容易理解，普通用户经过简单培训就可以掌握和使用。使用SQL语言，用户只需要告诉系统查询目的是什么（需要查询什么数据），即“What”，并不需要告诉系统怎么样去做，即“How”，包括数据在磁盘上是怎么存储的、可以使用什么索引结构来加快数据访问以及使用什么算法对数据进行处理等，都无需用户关心。关系数据库系统的查询优化器根据用户的查询特点和数据的特点，自行选择合适的查询执行计划，通过过滤、连接、聚集等操作完成用户的查询，达到执行速度快、消耗资源少、尽快获得部分结果等目标。查询优化器经历了从简单到复杂、基于规则到基于代价模型的发展阶段，是关系数据库系统最重要的和最复杂的模块之一。
容易理解的模型、容易掌握的查询语言、高效的优化器、成熟的技术和产品，使得关系数据库成为数据管理的首要选择。虽然1970年至2000年间并非所有的数据库系统都是基于关系模型的，针对特定应用出现了包括面向XML文档管理和查询（XQuery）的XML数据库、面向多媒体数据管理的多媒体数据库、面向高维时空数据处理的时空数据库、RDF数据库、面向对象的数据库等，但是关系数据库技术和产品占据了绝对的统治地位（包括技术和市场）。关系数据库管理系统厂商还通过扩展关系模型，支持半结构化和非结构化数据的管理，包括XML数据、多媒体数据等，并且通过用户自定义类型（User Defined Type，UDT）和用户自定义函数（User Defined Function，UDF）提供面向对象的处理能力，进而巩固了关系数据库技术的王者地位。关系数据库还可以通过裁剪适应特定的应用场合，比如流数据的处理（Stream processing，一般基于内存数据库实现），用户可以在源源不断涌来的序列数据上运行SQL查询，获得时间窗口上的结果，实现数据的及时（On the fly）分析和监控。
围绕RDBMS，形成了一个完整的生态系统（厂家、技术、产品、服务等），提供了包括数据采集、清洗和集成、数据管理、数据查询和分析、数据展现（可视化）等技术和产品，创造了巨大的数据库产业。
然而，大数据的出现给辉煌的关系数据库系统带来了严峻的挑战。大数据除了数据量巨大、速度快、结构类型丰富等特点外，更麻烦的是数据的多样性，其处理和分析操作是非常多样和复杂的。我们不仅仅需要简单的增加、删除、修改、查询和汇总操作，更需要进行复杂的计算和分析，这些分析依赖于人工智能、机器学习、数据挖掘、情感计算、网络分析、搜索等技术。比如在“危险边缘”游戏中，打败人类冠军的“沃森（Watson）”计算机（IBM公司研发的一个原型系统）集成了人工智能、自然语言处理等先进的技术。正如Stonebraker所说的，SQL查询只是简单的汇总分析，从数据中获得知识必须依赖于更复杂的计算，大数据之上必然要进行大分析（Big analytics，即复杂分析），才能把数据变废为宝，否则，我们将迷失在数据的海洋中。
大数据时代迎面而来，关系数据库系统并未做好准备：
首先，关系模型不容易组织和管理所有类型多样的数据，比如在关系数据库里，管理大规模的高维时空数据、大规模的图数据等都显得力不从心。
其次，如何通过大量节点的并行操作实现大规模数据的高速处理，仍然是一个巨大的挑战。在关系数据库上进行大规模的事务处理，不仅要解决读操作（查询）的性能问题，更需要解决修改操作的性能问题，大量的新事务（操作）到达，需要有效的处理，才能保证数据的持久性和可靠性。
再次，在关系数据库上进行数据的复杂分析，可以使用统计分析和数据挖掘软件包；现有的统计分析、数据挖掘软件包（SPSS，SAS，R等）能够处理的数据量受限于内存大小，并行化程度不够。从数据库中提取数据，注入到分析软件中进行分析，将导致大量的数据移动，在大数据时代已经不合适，分析应该向数据移动（move computation toward data），尽可能地靠近数据完成计算。通过数据的划分和并行计算，实现高性能的数据分析成为必然选择。
基于关系数据库系统，我们可以采用一些暂时的手段解决大数据处理问题。比如：关系数据库的分割（sharding）、关系数据库的非规范化（de-normalization）处理、为关系数据库部署分布式缓存（distributed cache）等。但是，这些技术不能完全应对现代数据管理的重要挑战（数据规模巨大、数据类型多样等），从根本上解决问题。
为了对大规模数据进行处理，无论是操作型应用还是分析型应用，并行处理都是唯一的选择。这个并行处理不仅是跨越多核的，更为重要的是，它是跨越节点的，依赖于大量节点的并行处理来提高性能。大量节点构成的分布式系统，即便成本不是问题而选用高端的、可靠的硬件设备，但由于集群规模很大，达到上千节点，节点的失败、网络的失效变得很平常，容错保证变得尤其重要。对系统进行大规模横向扩展，关系数据库系统并未为此做好准备，目前还没有一个关系数据库系统部署到超过1000个节点规模的集群上，而MapReduce技术则已经达到8000节点的部署规模。
3、数据仓库
3.1 数据仓库的概念
关系数据库系统最初主要用于事务处理领域，因此有时候也称作联机事务处理（Online Transaction Processing，OLTP）。随着数据的不断积累，人们需要对数据进行分析，包括简单汇总、联机分析处理（Online Analytical Processing，简称OLAP，主要是多维分析）、统计分析、数据挖掘等。在关系模型上支持这些分析操作成为一个自然的选择，比如建立于RDBMS上的联机分析处理技术OLAP。面向分析型应用的技术集大成者就是数据仓库。
数据仓库是企业统一的数据管理的方式，将不同的应用中的数据汇聚，然后对这些数据加工和多维度分析，并最终展现给用户。它帮助企业将纷繁浩杂的数据整合加工，并最终转换为关键流程上的KPI，从而为决策/管理等提供最准确的支持，并帮助预测发展趋势。因此，数据仓库是企业IT系统中非常核心的系统。
根据企业构建数据仓库的主要应用场景不同，我们可以将数据仓库分为以下四种类型，每一种类型的数据仓库系统都有不同的技术指标与要求。
（1）传统数据仓库
企业会把数据分成内部数据和外部数据，内部数据通常分为两类，OLTP交易系统以及OLAP分析系统数据，他们会把这些数据全部集中起来，经过转换放到数据库当中，这些数据库通常是Teradata、Oracle、DB2数据库等。然后在这上面对数据进行加工，建立各种主题模型，再提供报表分析业务。一般来说，数据的处理和加工是通过离线的批处理来完成的，通过各种应用模型实现具体的报表加工。
（2）实时处理数据仓库
随着业务的发展，一些企业客户需要对一些实时的数据做一些商业分析，譬如零售行业需要根据实时的销售数据来调整库存和生产计划，风电企业需要处理实时的传感器数据来排查故障以保障电力的生产等。这类行业用户对数据的实时性要求很高，传统的离线批处理的方式不能满足需求，因此他们需要构建实时处理的数据仓库。数据可以通过各种方式完成采集，然后数据仓库可以在指定的时间窗口内对数据进行处理，事件触发和统计分析等工作，再将数据存入数据仓库以满足其他一些其他业务的需求。因此，实时数据仓库增强了对实时性数据的处理能力要求，也要求系统的架构在技术层面上需要革命性的调整。
（3）关联发现数据仓库
在一些场景下，企业可能不知道数据的内联规则，而是需要通过数据挖掘的方式找出数据之间的关联关系，隐藏的联系和模式等，从而挖掘出数据的价值。很多行业的新业务都有这方面的需求，如金融行业的风险控制，反欺诈等业务。上下文无关联的数据仓库一般需要在架构设计上支持数据挖掘能力，并提供通用的算法接口来操作数据。
（4）数据集市
数据集市一般是用于某一类功能需求的数据仓库的简单模式，往往是由一些业务部门构建，也可以构建在企业数据仓库上。一般来说数据源比较少，但往往对数据分析的延时有很高的要求，并需要和各种报表工具有很好的对接。
3.2 数据仓库架构的挑战
到了大数据时代，传统架构的数据仓库遇到了非常多的挑战，因此也需要对它的架构做更多的一些演变。
首先最大的问题是数据增长速度非常迅速，导致原有的数据仓库在处理这些数据存在架构上的问题，无法通过业务层面的优化来解决。譬如，一个省级农信社的数据审计类的数据通常在十几TB，现有基于关系数据库或者MPP的数据仓库方案已经无法处理这么大数据，亟需一种新的更强计算能力的架构设计来解决问题。
其次，随着业务的发展，数据源的类型也越来越多。很多行业的非结构化数据的产生速度非常快，使用传统Oracle/DB2的数据仓库并不能很好的处理这些非结构化数据，往往需要额外构建一些系统作为补充。
再次，在一家比较大的企业内部，因为业务不同企业内部可能会有几百个数据库，各自建设方案也不同，没有一个简单的办法将数据统一到一个数据平台上。因此需要一个数据库虚拟化技术，能够通过有效的方式将各个数据库统一化，有效的进行数据分析和批处理。而在过去，这个技术并不存在。
最后，过去的数据库没有提供搜索和数据挖掘的能力，而这些需求已经是企业的刚需。譬如金融行业需要使用复杂的数据挖掘方法代替传统的规则引擎来做风险控制，而这无法在基于关系数据库的方案中得到解决。
随着Hadoop以及Spark技术的快速成熟，基于Hadoop/Spark的数据仓库解决方案能有效的解决这些问题和挑战。
3.3 基于大数据的数据仓库关键技术
下图是一个典型的基于Hadoop的数据仓库的架构设计。
首先有一个传统数据仓库层，它包含一个集中的数据存储平台，以及元数据管理，数据稽查和数据处理的工作调度层。数据存储平台包含多种数据源，有结构化数据和非结构化数据。结构化数据的处理分为三层，按照数据模型分成贴源层、基础明细层和公共主题模型层，数据加工业务按照模型进行切分成不同的批处理业务，通过分布式计算引擎来执行离线的批处理计算。同时为了满足多个模型层的业务需求，有一个统一的资源调度层和工作流调度系统，保证每个业务能够得到给定配额的资源，确保资源分配的合理性和有效性。
其次就是几个不同的应用的场景，通过资源管理层动态分配出来的逻辑集群。各个业务集群获取模型层加工的数据，并结合自身的业务使用相关的数据，同时各个业务之间也可以通过数据库联邦等技术在计算中共享数据。这类业务包含各种查询与检索业务，数据集市以及关联发现数据仓库。
因此，基于Hadoop的解决方案能够用一套系统实现企业对传统数据仓库，实时处理数据仓库，关联发现数据仓库以及数据集市的需求，并通过逻辑划分的方法使用一套资源来实现，无需多个项目重复建设。
从技术层面上，现有的一些SQL on Hadoop引擎（如Spark SQL，CDH等）能够部分实现数据仓库的需求，但是离完整覆盖还有一些距离。一些关键的技术特点必须实现突破，才能符合企业的数据仓库建设的业务指标。
4、大数据管理技术的新格局
基于上述数据库和数据仓库的分析，我们可以从两个维度入手大数据管理技术的新格局，即应用维度（操作型应用/分析型应用）和数据模型维度（关系模型/ NoSQL 数据模型），展现了当前数据管理技术的新格局。
分析型应用和操作型应用（主要是事务处理）具有不同的特点。操作型应用的数据处理任务主要包括对数据进行增加、删除、修改和查询以及简单的汇总操作，涉及的数据量一般比较少，事务执行时间一般比较短。而分析型应用（包括联机分析处理和数据挖掘等）则需要扫描大量的数据，进行分析、聚集操作，最后获得数据量相对小得多的聚集结果和分析结果。有些分析处理需要对数据进行多遍扫描（比如数据挖掘的K-Means算法），分析查询执行的时间以分钟计或者小时计。
（1）面向操作型应用的关系数据库技术
首先，传统的基于行存储的关系数据库系统，比如IBM的DB2、Oracle、微软的SQL Server等，提供了高度的一致性、高度的精确度、系统的可恢复性等关键的特性，仍然是事务处理系统的核心引擎，无可替代；其次，面向实时计算的内存数据库系统，比如Altibase，Timesten，Hana等，通过把数据全部存储在内存里，并且针对内存存储进行了并发控制、查询处理和恢复技术的优化,获得了极高的性能，在电信、证券交易、军工、网络管理等特定领域获得了广泛应用，提供比磁盘数据库快1个数量级（10倍、20倍，甚至30倍）的性能。此外，以VoltDB为代表的新的面向OLTP应用的数据库系统（new SQL）采用了若干颠覆性的实现手段，包括串行执行事务（避免加锁开销）、全内存日志处理等（加速持久化过程），获得了超过磁盘数据库50倍~60倍的事务处理性能。其他宣称保持了ACID特性，同时具有NoSQL 扩展性的NewSQL技术还有Clustrix和NuoDB等。
（2）面向分析型应用的关系数据库技术
TeraData是数据仓库领域的领头羊。TeraData数据库采用了SharedNothing的体系结构，支持较高的扩展性。面向分析型应用，列存储数据库的研究形成了一个重要的潮流。列存储数据库以其高效的压缩、更高的I/O效率等特点，在分析型应用领域获得了比行存储数据库高得多的性能。MonetDB是一个典型的列存储数据库系统，此外还有InforBright，InfiniDB，LucidDB，Vertica，SybaseIQ等。MonetDB和Vertica是基于列存储技术的内存数据库系统，主要面向分析型应用。
（3）面向操作型应用的NoSQL技术
NoSQL 数据库系统相对于关系数据库系统具有两个明显的优势。一个是数据模型灵活、支持多样的数据类型（包括图数据），使用关系数据库系统对图数据进行建模、存储和分析，其性能、扩展性等很难与专门的图数据库。另一个优势是高度的扩展性。从来没有一个关系数据库系统部署到超过1000个节点的集群上，而NoSQL技术通过灵活的数据模型、新的一致性约束机制，在大规模集群上获得了极高的性能。比如，HBase一天的吞吐量超过200亿个写操作，这个结果是在完全保证持久性的情况下获得的，也就是说，数据已经到达硬盘，真正实现了大数据的有效处理。基于关系模型的内存数据库系统也能获得极高的性能，但是在持久性完全保证的情况下，这个性能（写入性能）是要打折扣的。同时，其扩展性目前无法与NoSQL 匹敌，尚无法应付大数据的实时处理挑战。
操作型应用是一个比事务处理具有更广泛外延的概念，某些操作型应用并不需要ACID这样高强度的一致性约束，但是需要处理的数据量极大，对性能的要求也很高，必须依赖于大规模集群的并行处理能力来实现数据处理，弱一致性或者最终一致性是足够的。在这些应用场合，操作型NoSQL技术大有用武之地。Facebook从使用RDBMS（MySQL）到弃用RDBMS转向HBase，最后持续改进HBase，作为其操作型应用数据处理架构的基础技术，具有标本意义。
（4）面向分析型应用的NoSQL技术
这一象限的典型技术代表无疑是MapReduce和Spark。
MapReduce技术以其创新的设计理念、高度的扩展性和容错性，获得了学术界和工业界的青睐，围绕MapReduce的数据分析生态系统已经在几年前形成。同时，为了进一步提升计算性能和数据的实时分析能力，Hadoop与内存计算模式进行混合，目前已经成为实现高实时性的大数据查询和计算分析新的趋势。这种混合计算模式之集大成者当属UC Berkeley AMP Lab开发的Spark生态系统。
Spark是开源的类似Hadoop的通用的数据分析集群计算框架，用于构建大规模、低延时的数据分析应用，建立于HDFS之上。Spark提供强大的内存计算引擎，几乎涵盖了所有典型的大数据计算模式，包括迭代计算、批处理计算、内存计算、流式计算（Spark Streaming）、数据查询分析计算（Shark）以及图计算（GraphX）。Spark 使用Scala 作为应用框架，采用基于内存的分布式数据集，优化了迭代式的工作负载以及交互式查询。Spark支持分布式数据集上的迭代式任务，实际上可以在Hadoop文件系统上与Hadoop一起运行（通过YARN、Mesos等实现）。另外，基于性能、兼容性、数据类型的研究，还有Shark、Phoenix、Apache Accumulo、Apache Drill、Apache Giraph、Apache Hama、Apache Tez、Apache Ambari 等其他开源解决方案。未来相当长一段时间内，主流的Hadoop平台改进后将与各种新的计算模式和系统共存，并相互融合，形成新一代的大数据处理系统和平台。同时，由于有Spark SQL的支持，Spark是既可以处理非结构化数据，也可以处理结构化数据的，为统一这两类数据处理平台提供了非常好的技术方案，成为目前的一个新的趋势。
同时，一批新公司涌现出来。比如提供Hadoop开源版本、相关培训和支持服务的Cloudera公司，提供具有更高性能的分布式文件系统的MapR公司，提供围绕Hadoop的完整工具套件的Karmashpere公司，致力于Postgres和Hadoop的集成、脱胎于HadoopDB大学项目的Hadapt公司，从Yahooo剥离出来、致力于Hadoop技术的研发和商用的Hortonworks公司等。
与此同时，传统数据库厂商和数据分析套件厂商纷纷发布基于Hadoop技术的产品发展战略，这些公司包括Microsoft，Oracle，SAS，IBM等。微软公司已经关闭Dryad系统，全面投入MapReduce/Spark的研发。Oracle 在长期轻视NoSQL和MapReduce技术以后，于2011年下半年发布Big Plan战略计划，全面进军大数据处理领域（当然少不了Hadoop技术）。IBM则早已捷足先登，IBM的“沃森（Watson）”计算机，其软件系统即是基于Hadoop技术开发的，与此同时，IBM发布了Big Insights计划，基于Hadoop，Netezza和SPSS（统计分析、数据挖掘软件）等技术和产品构建大数据分析处理的技术框架。虽然有些公司的集成方案是肤浅的，只提供数据交换连接器，但是大家几乎不约而同地形成一个共识，那就是深度的集成方案是技术发展的方向。
需要注意的是，上述对各类技术的划分是一种观察问题的角度。在具体的研究和开发实践中，理论界的研究人员和工业界的工程师不仅继续发展已有的技术和平台，同时不断地借鉴来自其他研究和技术的创新思想改进自身，或者提出兼具若干技术优点的混合技术架构。
各种技术将继续互相借鉴，持续发展。面向事务处理的RDBMS技术和面向操作型应用的NoSQL技术将各自获得新的发展。在分析型应用方面，在围绕RDBMS的生态系统旁边生长出了围绕Hadoop技术的新生态系统，这两个生态系统的目标是一致的，即数据分析。关系数据库技术经过几十年的积淀和发展，擅长结构化数据的处理，性能高，但遇到扩展能力的困难；而MapReduce/Spark技术则在系统的扩展能力、数据的多样性、数据装载速度、分析和数据紧密结合/靠近数据进行分析、分析的复杂度等方面见长。实际上，这两项技术和生态系统最终走向融合，一个基于HDFS/Hadoop技术的大数据统一分析平台（Unified big data analytics platform）和生态圈将最终形成。这个框架的核心技术是HDFS/Hadoop，包括关系数据模型和查询处理技术被借鉴过来，溶解在这个框架里。该框架不仅提供关系数据的存储、处理和分析，还能采集、处理和分析类型多样的数据，并且在各个类型数据之间建立必要的联系（Bridging unstructured and structured data），对其进行联合分析（Together analysis），获得更全面的数据分析结果。现在，来自TeraData（Aster data），EMC（Greenplum），Hadapt（HadoopDB）等公司的大数据分析技术方案，经过不断演化，将生长得越来越彼此相似。值得注意的是，也有研究试图在RDBMS领域把OLTP和OLAP结合起来，通过一个统一的存储模型和查询处理框架实现事务处理和多维分析。希望这种尝试能够慢慢成为主流，对最终用户来说无疑会带来很多的好处。
5、实例分析：星环TDH
星环科技是目前国内极少数掌握企业级大数据Hadoop和Spark核心技术的高科技公司，从事大数据时代核心平台数据库软件的研发与服务。在全球去IOE的大背景下，Hadoop/Spark技术已成为公认的替代传统数据库的大数据产品。公司产品Transwarp Data Hub（TDH）的整体架构及功能特性比肩硅谷同行，产品性能在业界处于领先水平。
TDH是基于Hadoop和Spark的分布式内存分析引擎和实时在线大规模计算分析平台，相比开源Hadoop版本有10x~100x倍性能提升，可处理GB到PB级别的数据。星环科技同时提供存储、分析和挖掘大数据的高效数据平台和服务。从架构图中，我们可以看到星环对Spark、Shark、HBase等Hadoop生态圈的组件都进行很多的改造和优化。随着Hadoop/Spark上SQL性能上及安全容错上的不断提升，Hadoop/Spark在未来两三年将会取代MPP，混合架构会逐渐的消失。
TDH的主要特性包括：
最完整的SQL支持：99%的SQL 2003支持，唯一支持PL/SQL的引擎（98%），唯一支持ACID分布式事务的SQL引擎；定位数据仓库和数据集市市场，可用于补充或替代Oracle、DB2等分析用数据库。
高效内存/SSD计算：第一个支持SSD的基于Hadoop的高效计算引擎，可比硬盘快一个数量级；可用于建立各种数据集市，对接多种主流报表工具。
最完整的分布式机器学习算法库：支持最全（超过40余种）的分布式统计算法和机器学习算法，同时整合超过5000个R语言算法包。适合金融业风险控制、反欺诈、文本分析、精准营销等应用。
支持最完整SQL和索引的NoSQL数据库：支持SQL 2003、索引、全文索引，支持图数据库和图算法，支持非结构化数据存储。
最健壮和功能丰富的流处理框架：支持真正的Exactly Once语义、支持所有组件的高可用(HA)、支持流式SQL和流式机器学习等。
除了TDH以外，星环还开辟了一个新的产品线TOS（Transwarp Operating System），TOS是为大数据应用量身订做的云操作系统。基于Docker和Kubernetes，TOS支持一键部署TDH，基于优先级的抢占式资源调度和细粒度资源分配，让大数据应用轻松拥抱云服务，不限于跑Hadoop集群，也可以跑传统的数据库业务如MySQL，PostgreSQL，Redis等。这个大数据操作系统不久前已经证实发布了，在国内Docker化的Hadoop系统中是非常领先的。
大家可以看到，随着大数据管理系统的日趋成熟，使用大数据的技术门槛越来越低，像TDH这样的工业界成熟产品，已经开始越来越多的解放广大数据科学家和数据工程师了，使得他们不用关心复杂的大数据底层基础设施，只用把精力放在数据、算法和行业问题上。而这些才是更能释放大数据创新价值的地方。同时，大数据基础设施的成熟，也为大数据的学科建设和大数据的教育普及奠定了基础。
关于TDH和TOS，我们的公众号后面会专门有文章进行这方面的详细介绍，敬请关注。
参考文献：
孟小峰, 慈祥, 大数据管理: 概念、技术与挑战, 计算机研究与发展, 2013, 50(1): 146-169.
申德荣, 于戈登,支持大数据管理的NoSQL 系统研究综述, 软件学报, 2013,24(8): 1786-1803.
覃雄派, 王会举等, 数据管理技术的新格局, 软件学报, 2013, 24(2): 175-197.
孙元浩, 大数据关键技术发展趋势及产业构成, TR专家报告, 2016.
下面是本次课程的讲义，欢迎大家观看~（同样，最后有PPT下载的方法）
注：如需该课件，可以在微信公众号中回复“大数据07”进行获取，欢迎订阅本公众号！
Make data management as simple as possible~