丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
在上一章中，我们回顾了云原生应用的数字化战略，进而提出大数据和机器学习是未来企业构筑竞争优势和壁垒的高地，最后从人才和技术角度介绍如何建立合适的数据平台。本章将着重介绍数据处理平台的发展历程，根据其演进的内在动力、外在环境和当前趋势，提出集成数据处理和分析平台是未来发展的方向。最后从技术层面介绍大数据平台选型时需要考虑的因素。
自动数据处理大大提高了效率，并节约了成本。1880年的美国人口普查数据的统计工作耗时7、8年之久，使用了自动数据处理设备之后，仅用时不到2年（统计制表工作用时不到2个月，后进行了大量的验证工作）就完成了1890年的人口普查数据的统计工作。尽管工作量是之前的2倍，但成本却节省了大约500万美元。同时期比较流行的其他设备还有打字机、加法机和收银机等。雷明顿（Remington）公司自1873年开始就是主要的打字机制造商，推出了第一台量产打字机和QWERTY键盘。1894年，国家收银公司（NCR）公司发明了电动收银机，1922年销售了200万台。1925年，底特律的伯劳斯公司推出一款便携加法机。到了20世纪20年代，大多数公司装备了雷明顿的打字机、伯劳斯的加法机、IBM的制表机、NCR的收银机。其主要客户包括政府、保险公司和铁路公司等。电子计算机出现之后，代替了多个独立的单元记录设备，数据处理进入电子数据处理（ElectricDataProcessing，EDP）时代。美国人口普查局于20世纪50年代首次使用电子计算机进行人口普查工作，当时使用的是UNIVACI系统。若非特殊说明，之后内容中提到的“数据处理”指使用计算机的电子数据处理。
在20世纪50年代到60年代，伴随着通用电子计算机、磁存储介质、操作系统、文件系统等技术的发展，电子数据处理技术逐渐发展起来。到20世纪60年代中后期，数据处理应用基本还是使用文件作为持久化数据的存储方式，主要的存储格式之一是衍生自打孔卡技术的称为平面文件的格式，即文件由记录组成，一个文件的记录由同一种类型的记录组成，记录类型由固定长度的字段组成。支持分时共享的操作系统可以同时运行多个数据处理应用，它们各自有保存数据的文件，互相之间不能访问。一些通用的文件操作被开发出来用以提高效率，包括排序、合并和报表等。
随着硬件技术和应用的发展，基于文件的数据管理显现出其不足之处：
为了解决这些问题，人们开始研究能进行更高效、安全、快捷的数据处理的系统，于是造就了一个历经半个多世纪仍然极具活力的领域—数据库和数据库管理。1964年前后，计算机领域的文献中出现了一个新词—DataBase。这个词由美国军事情报系统的工作人员创造，表示分时共享计算机系统中的多用户共享的数据集合。当时的数据处理技术正在经历“集成数据处理”的阵痛，而DataBase很快成为描述集成不同应用程序的数据而形成的数据集的名词。现在维基百科对于数据库的定义是：按照一定方式组织起来的数据集合，通常使用数据库管理系统访问这些数据。数据库管理系统的发展经历了很多阶段，有些数据库管理系统已经淡出大众视野，有些仍然在不断演进。数据管理系统主要有以下几个发展阶段：
数据库系统的基石之一是数据结构以及对数据结构的操作方法，早期称之为数据结构化方法。后来EdgarF.Codd提出关系理论时，使用数据模型来描述这一问题，这一概念沿用至今。早期数据处理系统的数据模型衍生自打孔卡技术，因此比较简单。常用的一种模型由文件组成，文件由记录组成，一个文件的记录属于同一类型，记录类型由固定长度的字段定义。这种方式称为平面文件（FlatFile）。文件通常保存在顺序存储介质上，如打孔卡或者磁带（这个时候可随机访问的磁盘还没有出现）。当试图对数据进行整合时，早期数据模型的局限性立刻显现出来。最主要的问题是缺乏有效的表示实体之间关联的方法，例如一对多或者多对多关系。处理这种实体之间关联的操作和处理打孔卡不一样，需要额外的排序和合并操作。为了解决这些问题，数据库技术领域发展出了多种新的数据模型。
层次模型出现在20世纪60年代早期，它在一定程度上解决了实体关联问题。基于层次模型的数据库由链接在一起的记录集合组成，一个记录包含多个字段，每个字段只有一个数据值。链接（Link）将两个记录关联在一起。层次模型可以方便地表示实体间一对一关系和一对多关系，但不适合表示多对多关系。多对多关系可以通过记录复制之类的方式实现，这种方法有两种主要缺点：1）更新记录时容易造成数据不一致；2）浪费空间。使用虚拟记录（类似于文件系统中的符号链接）方法可以在一定程度上解决这个问题。使用树形逻辑结构可以较好地描述层次模型。例如，有两个记录类型：
用树形逻辑结构表示公司和员工记录的数据模型如图3-3所示。
层次模型最自然的存储方式是使用父子指针方式存储，如图3-4所示。这种方式造成的问题是：即使记录类型本身是定长记录，但由于子记录个数可能不同，造成该记录类型的存储长度是不固定的。这种变长记录不利于高效地存储和处理。一个常见的优化存储结构是使用最左子指针和兄弟指针替代父子指针，如图3-5所示。
实际存储时，可以一个文件存储一种记录类型，也可以一个文件存储多种记录类型。IBM的IMS数据库就是一种层次模型数据库，也是最古老的数据库系统之一，至今仍然被广泛使用。
通过如下两个链可以实现多对多关系：客户购买链和商品出售链。客户购买链将每个客户与其购买记录链接成一个环，而商品出售链将每个商品与其销售记录链接成一个环（如图3-7所示）。前面介绍的层次模型中的记录类型可以组织成树形结构，网状模型中的记录类型可组成图结构。
实体之间的关联也通过表来表示，这是最关键的改变，它统一了实体和实体关联关系的表示方式。使用实体标识符（ID）而不是指针或者其他硬件结构来表示实体关系，也为数据独立性打下了基础。20世纪60年代后期，TedCodd意识到可以用集合论来表示实体集，其中实体集为域（Domain）的集合D1，D2，…，Dn，每个域对应实体集的一个属性。实体关联也用类似的方法表示，每个域对应实体的标识符。这奠定了关系模型的理论基础。使用关系模型，图3-7中的客户购买信息可以用三张表表示：客户表存储客户信息，商品表存储商品信息，客户购买商品表存储客户购买商品的信息。如图3-8所示。
关系模型与层次模型和网状模型的最大区别是，记录之间的关联关系不再使用指针表示，而是通过记录ID表示。另一个重大区别是，层次模型、网状模型处理的基本单元是记录，而关系模型处理的基本单元是记录集合。关系数据模型最常用的两个访问方法（AccessMethod）是IBM的索引顺序访问方法（IndexedSequentialAccessMethod，ISAM）和虚拟储存访问方法（VirtualStorageAccessMethod，VSAM）。这两种方法都同时支持随机访问和顺序访问。ISAM是1966年作为OS/360的一个组件出现的，也是数据处理领域第一个广泛使用的同时支持顺序访问和随机访问的访问方法，它使用了DASD。VSAM是1972年提出的，它使用记录分割策略解决了ISAM的长溢出链问题，此外也支持索引压缩和索引复制。
1970年，EdgarF.Codd发表了论文《ARelationalModelofDataforLargeDataBanks》。在这篇论文中，他首次提出了关系模型，奠定了关系数据库的理论基础。这个模型通过一种简单、高级的查询语言访问数据。这种思维模式使得开发人员能够一次对一个数据集执行操作，而不是像之前那样一次操作一个记录。Codd在关系数据模型理论中提出了两种关系查询语言：一种是关系代数，一种是关系演算（RelationalCalculus）。假设有一张如图3-9所示的员工表（Employee），我们希望从中找到“比老板薪水高的员工”。
使用关系代数，查询语言如图3-10所示：
使用关系演算，查询语言如下所示：
假设有如下两张表，从中找出学习课程Math的成绩为A的所有学生。
Student(Number,Name)Enroll(Course,Date,StuNum,Grade)如果用关系演算，则解决方法如下：
{x[Name]∈Student:(y∈Enroll)(y[Course]="Math"&y[Grade]="A"&y[StuNum]=x[Number])}如果使用Alpha数据库子语言，则解决方法为：
RangeStudentXRangeEnrollYSomeGetWX.Name:Y((Y.Course="Math")&(Y.Grade="A")&(Y.StuNum=X.Number)这个Alpha语言程序返回满足条件的学生的名字，并用表W表示，宿主语言的语句可以访问并操作W。
SELECTe.nameFROMemployeee,employeemWHEREe.manager=m.nameANDe.salary>m.salarySQL的成功主要得益于关系模型的突破性创新，很好地抽象了用户和存储的数据之间的交互。此外，还有其他因素推动了SQL的发展：
数据保护方面两个出色的早期产品是IMS和SystemR。IMS提供了数据一致性保护，而SystemR则提供了更全面的数据保护措施，包括并发访问控制、故障恢复、数据恢复、权限管理等。很多经典数据库书籍对这些内容进行了详尽的分析，这里不再赘述。
数据库技术的发展不是一蹴而就的，现在看似很自然的技术，当初也经历了很多争论才持续发展起来。其中最大的争论来自关系模型和CODSYAL的DBTG模型，直到IBM发布DB2后形成双数据库战略（IMS和DB2），才终结了这场长达十年的争论。20世纪60年代，数据库技术初现，使用数据库管理数据比使用文件系统管理数据面临更多挑战：
这些挑战在数据库技术发展了近10年后才基本得到解决。20世纪70年代出现的关系模型，虽然具有简单灵活的优点，但在当时也经历了很大的争论：
经过十多年的关系理论发展、原型迭代和产品打磨，到了20世纪80年代，随着Oracle、IBM等商业数据库的成功，关系数据库才真正发展起来。但关系数据库仍然存在很多问题，其中最突出的问题是数据模型不匹配，也称为阻抗不匹配（ImpedanceMismatch），是指关系数据模型和应用程序内部使用的数据结构不匹配。关系数据模型使用表或者关系（Relation）和记录或者元组（Tuple）组织数据，元组是一组名字-值对，关系是元组集合。这种数据模型优雅而简洁，然而也有明显的局限性—无法表示嵌套数据结构，而应用程序内存中的数据结构通常包含非常复杂的嵌套数据结构。为解决这个问题，必须在关系数据模型和应用内存数据结构之间进行双向转换，因此需要很多转换代码。对象关系映射（ObjectRelationalMapping）框架在一定程度上解决了这个问题，比较知名的框架包括Hibernate、iBATIS。
NoSQL一词最早出现于1998年，用于命名一个轻量级关系数据库。该数据库使用文本文件存储数据，每个元组由制表键分割的字段组成，使用shell脚本访问数据，不支持SQL接口，但仍然是关系数据库。2009年，NoSQL一词出现于一个技术大会上，用于表示当时出现的大量非关系型分布式数据存储系统，这也是当前NoSQL一词的含义。然而，NoSQL一词没有广为接受的官方定义，它在不同的场合被解释为不同的意思，包括“NotoSQL”“NOSQL/NotOnlySQL”“No，SQL”等，现在广泛使用的含义为NotOnlySQL，即SQL数据库的一种补充，而非替代关系数据库。
NoSQL数据库根据数据模式的不同分为四种类型：键值数据库、文档型数据库、列族型数据库和图数据库。
键值数据库以键/值对形式存储数据，键必须唯一，这和哈希表的存储/操作方式类似。主键对应的值可以是任意二进制数据（包括文本数据），NoSQL数据库不知道数据内部细节，应用程序负责解析其语义。应用编程接口非常简单，支持读、写和删除键值对。有些键值数据库支持主键排序和范围（Range）操作。键值数据库性能出色，扩展性很好。流行的键值数据库包括Riak、Redis（由于可以存储集合、列表等，也称为数据结构服务器）、Memcached等。
文档型数据库的核心数据模型是文档（半结构化数据），以键/文档对存储。文档可以是XML、JSON、BSON等格式。文档多为树形结构，可以包含数组、子文档等。不同的文档可以有不同的字段，相同的字段可以有不同的数据类型。和键值数据库相比，文档内容对数据库可见，因而支持对文档的特定字段建立索引以实现高效检索。常见的文档型数据库包括MongoDB、CouchDB等。
图数据库支持非常灵活的实体关系，实体称为顶点，实体间的关系称为边。在图数据库中，边是内嵌的概念。常见的图数据库有Neo4J、OrientDB等。
2017年，谷歌发表了一篇名为《Spanner:BecomingaSQLSystem》的论文，引发了关于SQL回归的热议。图灵奖得主MichaelStonebraker和DavidJ.DeWitt早在2008年就曾指出MapReduce是技术倒退。他们认为，MapReduce的基本思路很简单，开发人员只需实现两类函数：map函数和reduce函数。map函数对输入记录执行过滤或变形处理，通过split函数（通常是哈希）将map的结果分成多个分区，每个分区对应一个文件，具有相同split结果的记录都在同一个文件中；reduce函数对map的结果进行进一步处理，结果也以文件方式保存。MapReduce框架会自动并行运行这些程序进行计算。若用SQL术语类比，map类似于聚集语句的group-by；而reduce类似于聚集函数，对每个分组的所有元组进行聚集计算。他们指出：
尽管如此，NoSQL产品仍然继续演进，其中一个趋势是支持更多关系数据库的优秀特性，如SQL标准。目前Apache社区有多个SQL-on-Hadoop项目，包括HAWQ、Impala、Presto等。此外，Kafka也开始提供SQL接口KSQL。传统的关系数据库也开始支持越来越多的NoSQL特性，如2012年发布的PostgreSQL9.2开始支持JSON。由于NoSQL开始提供更多SQL特性，SQL数据库也开始支持更多NoSQL特性，NoSQL与SQL的融合越来越深入。
过去，很多人认为Hadoop=大数据，一谈大数据必谈Hadoop。然而，这是一种误解。Gartner在2015年发布报告《SurveyAnalysis:HadoopAdoptionDriversandChallenges》，该报告指出：尽管Hadoop被大量炒作，并有早期采用者的成功案例，但超过一半的受访者目前没有计划投资。此外，只有18％的用户计划在未来两年内投资Hadoop。Gartner在2017年发布的数据管理产品周期图（如图3-12所示）中指出，Hadoop发行版在达到生产高峰期前已经过时。整个Hadoop技术栈的复杂性和可用性令许多组织重新考虑其在信息基础架构中的角色。谷歌的发展经历也说明，SQL数据库更适合作为大数据的基础处理平台。这对很多组织都具有借鉴意义。
用户对数据整合的需求在20世纪60年代造就了数据库，进入21世纪的第二个十年，数据整合需求再现其强大的影响力，这次将催生集成数据处理和分析平台。
集成数据平台有以下优势：
集成数据平台也有其不足之处：
古人说“天下大势，分久必合、合久必分”，这句话用在数据处理领域也不为过。需求和技术是一对矛盾，当这对矛盾缓和时，数据处理领域将更趋向于整合；而当这对矛盾尖锐时，数据处理领域将趋于分散。就软硬件技术发展现状和当前需求来看，未来整合的趋势更为明显。
前面我们介绍了数据平台的演进历程和发展趋势，了解其发展过程和趋势可以帮助我们更好地选择适合自身的数据平台。选型时首先需弄清楚企业自身的业务需求和未来的发展趋势，避免杀鸡用牛刀或者蚂蚁撼大象的情况。之后，对候选数据平台进行多维度考量。下面从技术角度列出一些大数据处理平台选型的因素或原则以供参考。
在数据经济时代，数据处理和分析的能力与效率是企业的核心竞争力，因此选择合适的集成平台至关重要。读者可以参考以上方面选择出适合自己的大数据处理基础平台。经过15年的发展，Greenplum在以上各个方面做了非常精心的考量，成为一款值得信赖的大数据处理基础平台。后面各章将会对Greenplum进行详细的介绍。
本章以数据处理平台的演进历史和未来趋势为主题，着重介绍了三次整合的背景及影响：
现在，第三次整合快速发展。我们正处于这一整合的关键发展阶段，涌现出很多新产品。企业决策者应考虑各种影响因素以选择适合自己的平台。
为了更好地理解本章内容，推荐有兴趣的读者进一步阅读以下书籍、论文或网上资源。