点击查看第一章
点击查看第二章

第3章 数据处理平台的演进

在上一章中，我们回顾了云原生应用的数字化战略，进而提出大数据和机器学习是未来企业构筑竞争优势和壁垒的高地，最后从人才和技术角度介绍如何建立合适的数据平台。本章将着重介绍数据处理平台的发展历程，根据其演进的内在动力、外在环境和当前趋势，提出集成数据处理和分析平台是未来发展的方向。最后从技术层面介绍大数据平台选型时需要考虑的因素。

3.1　前数据处理时代

Data（数据）一词最早出现于17世纪40年代，而使用“数据”表示“可传输和可存储的计算机信息”始于1946年。Data Processing（数据处理）一词的使用则始于1954年前后，泛指收集和处理数据以生成有意义的信息。
在“数据处理”一词出现之前，数据处理任务和行为一直存在，这可追溯到上古时期的结绳记事。之后常用的数据处理工具是算盘，基于算盘发展而来的珠心算至今仍深受国人喜爱。
人工数据处理持续使用了数千年。19世纪末，人们开始使用称为单元记录设备（Unit Record Equipment）、电算机（Electric Accounting Machine）或制表机（Tabulating Machines）的机电设备进行自动数据处理。由于可以较快速地处理一些复杂的数据处理任务，因此这类设备在政府和企业中变得非常流行。但整个数据处理流程需要精心策划，以便各种单元记录设备可以正确处理表示各种信息的打孔卡片。这些机器每分钟可以处理100～2000个打孔卡。打孔卡是一块纸板，通过在固定的位置打孔或者不打孔来表示数据。在磁带出现之前，它是一种非常流行的存储器，现在很多学校使用的答题卡就是基于类似原理。
人类曾经发明过很多存储数据的介质，包括上古用于计数的绳子、壁画、甲骨、碑刻、竹简、帛书及后来的纸。然而，这些数据或信息只有人类可以识别。工业革命时期，人们发明了可以控制机器的丝织机，同样的原理后来用于自动钢琴演奏。这些机器可以解读存储在介质上的指令。19世纪80年代，霍尔瑞斯发明了打孔卡，这是一种可以被机器解读的存储数据而非指令的介质。他还发明了键控穿孔机、分拣机和制表机等单元记录机器，这些发明奠定了自动数据处理行业的基础。霍尔瑞斯发明的方法被用于1890年的美国人口普查。1896年，他创建了制表机公司（TMC），后来该公司和其他三家公司合并组建了计算制表记录公司。1924年，计算制表记录公司改名为国际商业机器公司（IBM）。
IBM是当时最大的单元记录设备供应商，因此这种打孔卡又称为IBM卡，因其发明者为霍尔瑞斯，也被称为霍尔瑞斯式卡。图3-1显示了80列、矩形孔的IBM打孔卡片。

自动数据处理大大提高了效率，并节约了成本。1880年的美国人口普查数据的统计工作耗时7、8年之久，使用了自动数据处理设备之后，仅用时不到2年（统计制表工作用时不到2个月，后进行了大量的验证工作）就完成了1890年的人口普查数据的统计工作。尽管工作量是之前的2倍，但成本却节省了大约500万美元。
同时期比较流行的其他设备还有打字机、加法机和收银机等。雷明顿（Remington）公司自1873年开始就是主要的打字机制造商，推出了第一台量产打字机和QWERTY键盘。1894年，国家收银公司（NCR）公司发明了电动收银机，1922年销售了200万台。1925年，底特律的伯劳斯公司推出一款便携加法机。到了20世纪20年代，大多数公司装备了雷明顿的打字机、伯劳斯的加法机、IBM的制表机、NCR的收银机。其主要客户包括政府、保险公司和铁路公司等。
电子计算机出现之后，代替了多个独立的单元记录设备，数据处理进入电子数据处理（Electric Data Processing，EDP）时代。美国人口普查局于20世纪50年代首次使用电子计算机进行人口普查工作，当时使用的是UNIVAC I系统。
若非特殊说明，之后内容中提到的“数据处理”指使用计算机的电子数据处理。

3.2　早期的电子数据处理

3.2.1　电子计算机的出现

前面说过，在电子计算机出现之前，人类就发明了各种计算工具和机器，早期的人工计算工具有算筹和算盘。1642年，法国哲学家和数学家帕斯卡（Blaise Pascal）发明了世界上第一台加减法计算机。它利用齿轮转动原理进行机械式计算，通过手摇方式操作运算。1671年，德国数学家莱布尼兹（G.W. Leibnitz）制造出第一台能够进行加减乘除四则运算的机械式计算机。1833年，英国科学家巴贝奇（Charles Babbage）提出了制造自动化计算机的设想，他所设计的分析机引进了程序控制的概念。尽管该机器未能实现，但其设计思想和方案成为现代计算机的雏形。1886年，巴贝奇发明了差分机，使用齿轮进行数值计算。1925年，美国麻省理工学院制造了第一台机械模拟式计算机，1942年又研制出采用了速度更快的继电器的模拟式计算机。1944年，艾肯（Howard Aiken）在IBM的资助下成功研制出世界上第一台数字式自动计算机Mark I，实现了当年巴贝奇的设想。这台机器使用了三千多个继电器，可以进行全自动运算，代表着当时人类制造机械式电动计算机的最高水平。
随着电子技术的发展，美国宾夕法尼亚大学在美国军方的资助下于1946年研制出第一台电子数字积分机和计算机（ENIAC），这是世界上第一台通用电子数字计算机。它使用了18000多个电子管、1500个继电器，重30吨，占地约170平方米，运算速度达到每秒5000次，比Mark I快1000倍以上。
但ENIAC有一个致命的缺点—程序和数据分离，即数据存储在存储器中，而程序存储在机器外部的电路里。运算之前，先要按照程序手工把相应的电路接通或通过读卡机读卡以执行各个指令，费时费力，无法发挥它的运算速度。冯·诺依曼（Von Neumann）和宾夕法尼亚大学的莫尔电机系小组提出了“存储程序”的概念，确立了计算机由输入、存储、运算、控制和输出五个基本部件组成的结构，将指令像数据一样进行存储和处理。按照此原则制成的第一台存储程序、顺序控制的电子离散变量自动计算机（EDVAC）于1949年在英国的剑桥大学投入使用。EDVAC也是第一台使用磁带的计算机，可以多次在磁带上存储程序。至今，计算机仍遵循此存储程序原则。

3.2.2　软件

早期的计算机通过重新布线等方式进行编程，多为专门的信息处理任务而定制。后来，阿兰·图灵和冯·诺依曼提出的存储程序思想为解决通用问题提供了思路，可编程性开始受到关注。
软件（Software）一词最早指软制品，如毛织物或者棉织物，也指相对易腐烂的消费品。20世纪50年代，硬件（Hardware）一词已经广泛使用，但是软件还没有出现。直到1960年前后，“软件”一词在计算机领域才开始使用，用于描述计算机制造商提供的除了硬件之外的所有东西，包括程序和服务等。软件的概念一直在变迁，到20世纪70年代中期，开始用于表示计算机使用的程序和其他操作信息。此时，软件成为计算机程序的同义词。
早期基于电子计算机的电子数据处理基本上直接继承自基于单元记录设备的数据处理方式，计算机使用也是独占式的。之后，随着计算能力的提升，开始出现批处理模式和分时共享模式，逐渐演变出软件和操作系统。
早期的计算机没有操作系统，每个用户在预定的时段独占整个计算机，包括外设（例如打印机和读卡器）。在指定的时间段，用户带着程序和数据来运行其程序。程序和数据存储在打孔卡、纸袋或者磁带上。通过输入设备加载程序和数据后，一直独占机器运行，直至程序运行结束或者出现错误。通常，可以通过控制面板调试程序（控制面板常使用拨号盘、切换开关或者面板灯）。
早期的代码使用机器码编写。为了提高编程效率，出现了符号语言。汇编器和编译器将符号程序编译成机器码。之后出现了操作打孔卡或者磁带的库代码，用以协助常用的输入和输出操作，这些代码可以链接到用户的程序，避免了重复开发。这是现代操作系统的起源。但此时，机器仍然一次只能运行一个作业。
随着计算机能力的提升，运行程序的时间逐渐减少，而将设备交给下一个用户的时间占比越来越大。之前根据墙上的时钟核算机器使用账单的方式开始转变为由计算机自动记账；运行队列也由门口的人工排队变成了工作台上的诸如打孔卡或者磁带之类的等待队列。之后，自动记录和检测程序不仅需要记载CPU的使用情况，还需要计算打印页数、打卡次数、读卡次数、磁盘使用容量等信息。慢慢地，这些功能融合为一个程序，它在第一个客户的工作开始之前已经运行，可以读取客户作业、控制其执行情况、记录客户作业资源使用情况、在作业结束后重新分配资源，然后立即处理下一个作业。这些驻留的程序在操作系统这个术语出现前通常被称为监控程序。
一个早期的用于实际工作的操作系统是通用汽车于1956年为其IBM 704研发的GM-NAA I/O。大多数早期IBM大型机操作系统也是由客户研发的，每个供应商或者客户都为其特定主机研发一个或者多个特定操作系统。即使是同一个供应商，其每个操作系统也可能具有完全不同的操作模式。这种情况一直持续到1964年IBM System/360和OS/360发布，该项目致力于为所有兼容机提供相同的指令和输入、输出架构。
此时，树形结构的分级文件系统开始出现。1958年的东部联合计算机会议介绍了早期的分级文件系统。1965年发布的Multics系统（一个早期的分时操作系统）对文件系统的影响比较大。之后的Unix的文件系统基于Multics，并支持任意级别的文件目录层级。
“文件”（File）一词早在1950年就被用来表示计算机存储的内容。美国无线电公司（RCA）的广告中指出：无数计算的结果可以保存在文件中，之后可以再次取出。在20世纪50年代，文件通常指存储在打孔卡上的信息。图3-2给出了当时常见的打孔卡照片。

在20世纪50年代到60年代，伴随着通用电子计算机、磁存储介质、操作系统、文件系统等技术的发展，电子数据处理技术逐渐发展起来。到20世纪60年代中后期，数据处理应用基本还是使用文件作为持久化数据的存储方式，主要的存储格式之一是衍生自打孔卡技术的称为平面文件的格式，即文件由记录组成，一个文件的记录由同一种类型的记录组成，记录类型由固定长度的字段组成。
支持分时共享的操作系统可以同时运行多个数据处理应用，它们各自有保存数据的文件，互相之间不能访问。一些通用的文件操作被开发出来用以提高效率，包括排序、合并和报表等。

3.3　数据库

随着硬件技术和应用的发展，基于文件的数据管理显现出其不足之处：

• 每个应用程序要自行定义底层数据格式，依赖程度高，维护代价昂贵。

• 文件格式不兼容，无法在不同应用间共享数据。

为了解决这些问题，人们开始研究能进行更高效、安全、快捷的数据处理的系统，于是造就了一个历经半个多世纪仍然极具活力的领域—数据库和数据库管理。
1964年前后，计算机领域的文献中出现了一个新词—Data Base。这个词由美国军事情报系统的工作人员创造，表示分时共享计算机系统中的多用户共享的数据集合。当时的数据处理技术正在经历“集成数据处理”的阵痛，而Data Base很快成为描述集成不同应用程序的数据而形成的数据集的名词。现在维基百科对于数据库的定义是：按照一定方式组织起来的数据集合，通常使用数据库管理系统访问这些数据。
数据库管理系统的发展经历了很多阶段，有些数据库管理系统已经淡出大众视野，有些仍然在不断演进。数据管理系统主要有以下几个发展阶段：

• 导航型数据库

• 关系型数据库

• 面向对象型数据库

• 关系-对象型数据库

• NoSQL

• 分布式数据库

• NewSQL

本节将聚焦于NoSQL出现之前的数据库技术的演进。
20世纪60年代早期的研究源自以下用户需求：
1）数据整合：早期的数据处理应用程序使用主文件（Master File）持久化保存数据。主文件是应用程序的一部分，企业内部不同应用的主文件是独立设计和维护的，数据重复和不一致的问题很普遍。因此，整合不同应用的各种主文件，实现数据共享和集中管理的需求越来越旺盛。此外，信息管理应用程序也需要这种整合才能起效。
2）数据独立性：早期的应用使用机器语言或者汇编语言编写，效率低下，并且依赖于硬件。这种复杂度使不懂编程的人员难以访问数据。因此，提供更抽象的语言，使得应用程序独立于底层数据存储和管理成为一个重要需求。
3）数据保护：数据整合也带来了新的挑战，原来每个应用访问自己的主文件，不会涉及权限管理的问题，而整合之后需要防止数据丢失和未授权的访问，因此需要访问控制和防止数据丢失的机制。
这些需求催生了相应技术的发展。

3.3.1　数据模型

数据库系统的基石之一是数据结构以及对数据结构的操作方法，早期称之为数据结构化方法。后来Edgar F. Codd提出关系理论时，使用数据模型来描述这一问题，这一概念沿用至今。
早期数据处理系统的数据模型衍生自打孔卡技术，因此比较简单。常用的一种模型由文件组成，文件由记录组成，一个文件的记录属于同一类型，记录类型由固定长度的字段定义。这种方式称为平面文件（Flat File）。文件通常保存在顺序存储介质上，如打孔卡或者磁带（这个时候可随机访问的磁盘还没有出现）。
当试图对数据进行整合时，早期数据模型的局限性立刻显现出来。最主要的问题是缺乏有效的表示实体之间关联的方法，例如一对多或者多对多关系。处理这种实体之间关联的操作和处理打孔卡不一样，需要额外的排序和合并操作。为了解决这些问题，数据库技术领域发展出了多种新的数据模型。

1. 层次模型

层次模型出现在20世纪60年代早期，它在一定程度上解决了实体关联问题。基于层次模型的数据库由链接在一起的记录集合组成，一个记录包含多个字段，每个字段只有一个数据值。链接（Link）将两个记录关联在一起。
层次模型可以方便地表示实体间一对一关系和一对多关系，但不适合表示多对多关系。多对多关系可以通过记录复制之类的方式实现，这种方法有两种主要缺点：1）更新记录时容易造成数据不一致；2）浪费空间。使用虚拟记录（类似于文件系统中的符号链接）方法可以在一定程度上解决这个问题。
使用树形逻辑结构可以较好地描述层次模型。例如，有两个记录类型：

• 公司（company）：有公司名字、地址等字段。

• 员工（employee）：有员工名字、年龄等字段。

用树形逻辑结构表示公司和员工记录的数据模型如图3-3所示。

层次模型最自然的存储方式是使用父子指针方式存储，如图3-4所示。
这种方式造成的问题是：即使记录类型本身是定长记录，但由于子记录个数可能不同，造成该记录类型的存储长度是不固定的。这种变长记录不利于高效地存储和处理。
一个常见的优化存储结构是使用最左子指针和兄弟指针替代父子指针，如图3-5所示。

实际存储时，可以一个文件存储一种记录类型，也可以一个文件存储多种记录类型。
IBM的IMS数据库就是一种层次模型数据库，也是最古老的数据库系统之一，至今仍然被广泛使用。

2. 网状模型

层次模型虽然在一定程度上解决了实体关联的问题，但仍有一定的局限。更通用的方法直到20世纪60年代中期直接访问存储设备（Direct Access Storage Device，DASD）普及后才出现，DASD使得网状模型成为可能。
早期的商业数据处理中的网状模型起源于物料清单应用（BOM），这种应用常需要表示一对多和多对多关系。为了简化物料清单应用的开发，IBM提出了一种称为BOMP的访问方法，后又推出增强版的DBOMP。BOMP数据模型使用两种类型的文件：主文件（Master File）和链文件（Chain File）。每个记录类型包含单个固定格式类型的记录和一个称为链的结构。链结构含有单个主文件记录和来自单个链文件的可变数量的记录。某个链文件记录可以出现在不同类型的不同链中，并关联主文件记录到这些链的头部。对于物料清单类型应用，“零件链”和“零件使用链”这两种链足以表示多对多的零部件关联关系。虽然最初是为物料清单应用而开发，但是BOMP被应用于各种各样的应用程序中。CINCOM公司的TOTAL DBMS也是基于BOMP思想。
另一种非常成功的网状模型数据库是GE的IDS系统（Integrated Data Store）。在IDS中，一个数据库由记录和记录链组成，没有文件的概念。记录链和BOMP的链文件相似，由一个所有者（owner）记录和多个成员记录组成。一个记录可以是不同类型的不同链的成员。和BOMP不同的是，所有者记录可以是其他链的成员。这样就可以建立任意深度的层次模型，以及复杂的网状模型。
网状模型概念上也是由不同类型的记录集合组成，记录之间的关系通过链接（Link）来表示。20世纪60年代后期、70年代早期，CODASYL的数据库工作组（Data Base Task Group）基于网状模型的商业数据库对网状数据模型进行了标准化。
为了简化实现和处理，在DBTG模型中，不允许使用多对多Link，因而两个记录类型之间的数据结构图的形式都是A←B（记录类型A可以有多个子记录类型，记录类型B只能有一个父记录类型），这称为一个DBTG集合（set）。每个DBTG集合有且只有一个记录类型为该集合的所有者（owner），其他记录类型为该集合的成员（member）。一个DBTG集合可以有任意数目的集合实例，一个集合实例可包含一个所有者记录和多个成员记录类型的记录。
DBTG模型的实现技术充分利用了其模型对多对多关系的限制，通过为每个集合实例使用环结构，从而避免使用可变长度记录。假设有如下3个记录类型（如图3-6所示）：

通过如下两个链可以实现多对多关系：客户购买链和商品出售链。客户购买链将每个客户与其购买记录链接成一个环，而商品出售链将每个商品与其销售记录链接成一个环（如图3-7所示）。
前面介绍的层次模型中的记录类型可以组织成树形结构，网状模型中的记录类型可组成图结构。

3. 关系模型

20世纪60年代中期，研究者们开始不满足于使用指针或者类似的方法实现实体之间的关联，因为对于用户而言，为了使用这些系统，他们需要了解这些关联及其实现的细节，这种体验是非常糟糕的。作为当时最令人瞩目和最有动力研究这一难题的公司，在不同的时间和场合下，IBM有多位研究者提出了实体集合（Entity Set）或者类似的概念。也就是说，数据通过一组表来表示，一个表对应于一种类型的实体集，每个表的行对应于实体集中的单个实体，列则对应于实体集的属性，行列交叉处对应某个实体的某个属性的值。

实体之间的关联也通过表来表示，这是最关键的改变，它统一了实体和实体关联关系的表示方式。使用实体标识符（ID）而不是指针或者其他硬件结构来表示实体关系，也为数据独立性打下了基础。
20世纪60年代后期，Ted Codd意识到可以用集合论来表示实体集，其中实体集为域（Domain）的集合D1，D2，…，Dn，每个域对应实体集的一个属性。实体关联也用类似的方法表示，每个域对应实体的标识符。这奠定了关系模型的理论基础。
使用关系模型，图3-7中的客户购买信息可以用三张表表示：客户表存储客户信息，商品表存储商品信息，客户购买商品表存储客户购买商品的信息。如图3-8所示。

关系模型与层次模型和网状模型的最大区别是，记录之间的关联关系不再使用指针表示，而是通过记录ID表示。另一个重大区别是，层次模型、网状模型处理的基本单元是记录，而关系模型处理的基本单元是记录集合。
关系数据模型最常用的两个访问方法（Access Method）是IBM的索引顺序访问方法（Indexed Sequential Access Method，ISAM）和虚拟储存访问方法（Virtual Storage Access Method，VSAM）。这两种方法都同时支持随机访问和顺序访问。ISAM是1966年作为OS/360的一个组件出现的，也是数据处理领域第一个广泛使用的同时支持顺序访问和随机访问的访问方法，它使用了DASD。VSAM是1972年提出的，它使用记录分割策略解决了ISAM的长溢出链问题，此外也支持索引压缩和索引复制。

4. 对象数据模型和关系对象模型

在关系模型之后，为了进一步抽象并适应编程语言的发展，提出了很多更复杂的模型，包括对象数据模型、对象关系模型、XML数据库等。然而，这些数据模型随着时间的流逝，基本上已经淡出了大众的视野。主要原因是这些模型过于复杂，其带来的价值不足以补偿实现的复杂性。关系模型则因简单且有完备的理论支撑而经久不衰。
其中值得一提的是PostgreSQL。PostgreSQL官方称其为最高级的对象关系数据库，对象模型的概念在最新的版本中已经被淡化，其早期对象关系模型中保留至今仍有活力的是其抽象数据类型、自定义数据类型、自定义操作符和函数等。这为PostgreSQL的灵活性和可扩展性奠定了坚实的基础。现在，鲜有用户会提及PostgreSQL的面向对象的数据模型。
XML数据库也曾风靡全球，然而，在图灵奖获得者Michael Stonebraker看来，这种数据库只不过是站在前人的脚趾而不是肩膀上的重复当年的网状数据模型、期望解决却未能解决问题。因此，XML数据库只是昙花一现就不足为奇了。

3.3.2　数据独立性和高级数据处理语言

数据独立性是早期数据库系统追求的一个主要目标，它是指应用程序代码和数据存储结构、访问策略相互独立。数据库提供高级接口，使用户可以处理数据，而不用考虑底层细节，例如二进制位、指针、数组、链表等。尽管底层还会使用这些基本数据结构来表示和处理数据，但数据库可以选择内部数据表示方法，并且可以改变这种存储方式，而对用户和应用完全透明。
早期处理数据的代码内嵌在宿主编程语言中。宿主编程语言起源于通用数据处理例程，例如缓冲区处理、错误处理等。后来演变成I/O子例程工具包，之后又演变成I/O系统和访问方法（Access Method）。而DASD的出现大大扩展了这些通用操作工具的数量，包括空间分配、格式化、地址转换、索引等。
随着数据库管理系统的出现，访问方法（Access Method）接口被数据库子语言取代，数据库子语言比访问方法更强大，比如可以更新或者删除多个记录，此外还可以执行数据库独有的操作，例如锁和事务控制等。由于内存的限制一次无法处理过多的数据，为了处理大量记录，有些数据库子语言提供了游标（Cursor）。
Edgar F. Codd提出的关系数据模型大大促进了数据独立性的发展。他认为传统数据库主要存储两种信息：1）数据库记录的内容；2）数据库记录之间的关系。不同的系统使用不同的方式存储记录之间的关系，例如links、sets、chains、parents等。
关系模型系统有三个重要的属性：1）提供一个和底层实现无关的数据模型或者视图，所有信息都以数据值方式表示，不存储任何连接信息；2）系统提供高级语言执行数据处理操作，而不用关心其实现细节；3）高级语言以记录集合为操作单位，一次处理多个记录，而层次数据库和网状数据库一次操作一个记录。因此关系数据模型可以更好地解决数据独立性问题。
正是有了数据独立性，数据库才能作为一个产品和使用数据库的应用松散耦合在一起。数据库产品可以不断改进增加新功能，只要提供向后兼容的SQL支持，应用程序就可以直接在新版本上运行。另一方面，应用程序从数据存储和访问方式上脱身而出，专注在业务逻辑上，将越来越多的业务构建在数据库这一基础软件上，两者相互促进。为了满足来自应用的更好、更快地处理数据的需求，数据库需要不断改进升级，而每一次数据库功能和性能的增强，又会带动更多应用和更大规模的应用场景，推动数据库技术进一步提升。

1. 关系模型及查询语言

1970年，Edgar F. Codd发表了论文《A Relational Model of Data for Large Data Banks》。
在这篇论文中，他首次提出了关系模型，奠定了关系数据库的理论基础。这个模型通过一种简单、高级的查询语言访问数据。这种思维模式使得开发人员能够一次对一个数据集执行操作，而不是像之前那样一次操作一个记录。
Codd在关系数据模型理论中提出了两种关系查询语言：一种是关系代数，一种是关系演算（Relational Calculus）。
假设有一张如图3-9所示的员工表（Employee），我们希望从中找到“比老板薪水高的员工”。

使用关系代数，查询语言如图3-10所示：

使用关系演算，查询语言如下所示：

RANGE employee e;
RANGE employee m;
GET w(e.name):m((e.manager = m.name) ∧(e.salary > m.salary)

2. SQL

SQL衍生自System R的数据库子语言，这是对数据库发展极为重要的一种高级语言。SQL来源于如下一些早期IBM对关系语言的研究。

• Alpha语言：尝试使用过程语言代替关系演算。

假设有如下两张表，从中找出学习课程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数据库子语言，则解决方法为：

Range Student X
Range Enroll Y Some
Get W X.Name:
        Y((Y.Course = "Math") & (Y.Grade = "A") & (Y.StuNum = X.Number)

这个Alpha语言程序返回满足条件的学生的名字，并用表W表示，宿主语言的语句可以访问并操作W。

• GAMMO-0：低级关系语言，试图实现关系代数和查询语言。

• SQUARE：使用图形化方式，从而避免使用关系演算中的数学符号。

• SEQUEL：基于SQUARE，但是使用类自然语言。SEQUEL借鉴了已有查询语言的某些结构，如GIS（GIS and File Management, J.H. Bryant，1966）的SELECT-FROM-WHERE，并扩充使之满足关系完整性。很重要的一个突破是，它能够支持子查询。System R的SQL基于增强版的SEQUEL，在程序中使用SQL时，SQL语句可以使用宿主语言的变量。

1972年，在Edgar F. Codd组织的一个计算研讨会上，SQL的发明者Raymond Boyce和Donald Chamberlin接触到了关系数据模型。他们发现，用几行关系语言代码就可以实现复杂的DBTG语言程序才能实现的功能，因而被Codd的关系语言的表达能力所震撼。不过，他们也感到该语言的门槛很高，需要具备一定的数学基础才能驾驭。他们认为影响该语言流行的主要障碍有两个：第一个障碍是普通键盘很难输入数学符号。这个障碍比较容易解决，如使用“project”代替数学符号π；另一个更大的障碍来自语义级别，Codd的关系语言的基本概念来自于集合论和符号逻辑理论，普通用户很难理解。于是在1973年，他们设计了一种类似自然语言的查询语言，称为SEQUEL。该语言流畅地描述了需要查询什么信息，但是不涉及任何实现细节，所以SEQUEL是一种声明式语言。1974年，他们发表了论文“SEQUEL: A Structured English Query Language”。之后，SEQUEL语言随着System R项目持续演进，根据早期用户的反馈，于1976年发布了更完整的SEQUEL语言设计。1977年由于商标问题，SEQUEL改为SQL。
解决“比老板薪水高的员工”这个问题的SQL查询如下，可以看到，查询语句非常简洁易懂。

SELECT e.name
FROM employee e, employee m
WHERE e.manager = m.name AND e.salary > m.salary

SQL的成功主要得益于关系模型的突破性创新，很好地抽象了用户和存储的数据之间的交互。此外，还有其他因素推动了SQL的发展：

• 从早期相关研究和实现中受益匪浅。

• 同时支持DDL和DML，为用户提供了一个统一的接口来使用和管理数据库，从而提高了应用开发人员的效率。

• SQL标准催生了一个完整的生态，不再被单个厂商锁定。1986年，ANSI和ISO标准工作组定义了SQL的标准。此后，SQL发布了多个后续标准版本，包括1992、1996、1999、2003、2006、2008、2016。经过多年的发展，SQL标准修正了最初版本中的不足，并增加了很多新的特性，包括外连接、表表达式、递归、触发器、自定义类型和自定义函数、OLAP扩展、JSON等。

3.3.3　数据保护

数据保护方面两个出色的早期产品是IMS和System R。IMS提供了数据一致性保护，而System R则提供了更全面的数据保护措施，包括并发访问控制、故障恢复、数据恢复、权限管理等。很多经典数据库书籍对这些内容进行了详尽的分析，这里不再赘述。

3.3.4　数据库早期发展过程中的困境

数据库技术的发展不是一蹴而就的，现在看似很自然的技术，当初也经历了很多争论才持续发展起来。其中最大的争论来自关系模型和CODSYAL的DBTG模型，直到IBM发布DB2后形成双数据库战略（IMS和DB2），才终结了这场长达十年的争论。
20世纪60年代，数据库技术初现，使用数据库管理数据比使用文件系统管理数据面临更多挑战：

• 由于需要消耗更多计算资源，数据库系统比文件系统处理速度慢；而当时硬件性能较弱，使得这个缺点更为明显。

• 作为新生事物，数据库系统的稳定性不如文件系统。

• 相关技术人才匮乏。

这些挑战在数据库技术发展了近10年后才基本得到解决。
20世纪70年代出现的关系模型，虽然具有简单灵活的优点，但在当时也经历了很大的争论：

• 相比层次和网状数据模型，关系模型需要更多的系统资源，因而速度更慢。

• 关系模型依赖优化技术生成高效查询计划，当时人们对优化技术能否实现期待的优化效果存疑。

• 作为新生事物，相关技术人才匮乏。

经过十多年的关系理论发展、原型迭代和产品打磨，到了20世纪80年代，随着Oracle、IBM等商业数据库的成功，关系数据库才真正发展起来。
但关系数据库仍然存在很多问题，其中最突出的问题是数据模型不匹配，也称为阻抗不匹配（Impedance Mismatch），是指关系数据模型和应用程序内部使用的数据结构不匹配。关系数据模型使用表或者关系（Relation）和记录或者元组（Tuple）组织数据，元组是一组名字-值对，关系是元组集合。这种数据模型优雅而简洁，然而也有明显的局限性—无法表示嵌套数据结构，而应用程序内存中的数据结构通常包含非常复杂的嵌套数据结构。为解决这个问题，必须在关系数据模型和应用内存数据结构之间进行双向转换，因此需要很多转换代码。对象关系映射（Object Relational Mapping）框架在一定程度上解决了这个问题，比较知名的框架包括Hibernate、iBATIS。

3.4　NoSQL数据库

NoSQL一词最早出现于1998年，用于命名一个轻量级关系数据库。该数据库使用文本文件存储数据，每个元组由制表键分割的字段组成，使用shell脚本访问数据，不支持SQL接口，但仍然是关系数据库。2009年，NoSQL一词出现于一个技术大会上，用于表示当时出现的大量非关系型分布式数据存储系统，这也是当前NoSQL一词的含义。然而，NoSQL一词没有广为接受的官方定义，它在不同的场合被解释为不同的意思，包括“No to SQL”“NOSQL/Not Only SQL”“No，SQL”等，现在广泛使用的含义为Not Only SQL，即SQL数据库的一种补充，而非替代关系数据库。

3.4.1　NoSQL出现的背景

在新千年的第一个十年，数据处理领域最令人瞩目的变化是各种NoSQL数据库如雨后春笋般涌现，呈现出百花齐放、百家争鸣的局面。根据nosql-database.org在2018年的统计数据，共有超过225个NoSQL产品，这种情况的出现有鲜明的时代背景。
始于1969年的互联网（Internet）改变了人类的方方面面，其影响仍然在进一步深化，甚至可以说其影响才刚刚开始。互联网出现不久，电子邮件就成为深受人们喜爱的高效、便捷的沟通方式之一，电子布告板（BBS）成为便捷的信息发布平台。1989诞生的万维网（WWW）则彻底改变了信息的链接方式。随后海量网站出现，信息呈爆炸式增长，获取数据变得非常容易，而从大量网络数据中找到需要的信息变得越来越困难，这催生了互联网巨头。Yahoo从黄页起步快速成为流行的门户网站，Google开始提供高质量搜索服务。1999年出现、2004年开始流行的Web 2.0标志着互联网进入新时代：用户生成内容提高了服务的粘性，更好的交互性大大提高了用户体验，粘性和体验的提升又进一步带来更多的访问量和更长的访问时间。这个时期常用的服务包括社交平台、电商平台、网络社区、博客等。
快速增长的数据量给年轻的互联网巨头带来了巨大的技术挑战：现有的数据处理技术无法适应数据量的快速增长。传统的企业（如银行）也有大量的数据，但由于其核心业务是交易，因此他们可以通过控制数据量（特别是历史数据量）使现有的数据处理技术能够满足其业务需求。对于互联网公司，数据是核心资产，因此只能努力前进，解决这些他人还未遇到的难题，而不能退缩。互联网公司面临两种选择：垂直扩展（Scale Up）或者水平扩展（Scale Out）。垂直扩展指采购功能更强大的机器解决问题，这也意味着要有更大的资金投入，且这种投入增长不是线性的，另外，垂直扩展总是有上限的。所以，很多互联网公司采用水平扩展的方案，通过购买更多的商用硬件组建集群来解决扩展问题。
水平扩展方案也带来了一个新的问题：虽然从20世纪80年代开始，学术界和企业界就对分布式数据库进行研究和开发，但当时还没有可以很好地支持集群的商用事务型关系数据库。Oracle RAC和微软的SQL Server虽然支持集群，但仍然基于共享磁盘，扩展能力有限。这种关系数据库和分布式集群的不匹配，使得互联网巨头和大企业不得不考虑其他存储方案。早期的尝试之一是使用基于中间件的方案，包括eBay的基于Oracle的集群和谷歌的基于MySQL的集群。中间件方案的底层大多使用某种关系数据库，而关系数据库自身的特性（如ACID）限制了性能和可用性，使用关系数据库做底层存储代价过高。于是，某些公司开始尝试改变这一状况，很多新技术和产品应运而生。这些新产品放弃了ACID、模式（Schema）和跨节点关联等关键SQL特性，以获得对海量数据的高速处理能力、高扩展性和高可用性等。谷歌于2003年发表了GFS论文、2004年发表了MapReduce论文、2006年发表了BigTable论文；亚马逊于2007年发表了Dynamo论文；雅虎于2006年开源了Hadoop；Facebook于2008年开源了Cassandra。这些研究和技术为NoSQL的发展奠定了良好的基础。其他很多知名NoSQL产品也是在这一时期开始研发或者发布的，包括CouchDB（2005）、MongoDB（2007）、Hypertable（2008）、Cassandra（2008）、Redis（2009）、MongoDB（2009）、ElasticSearch（2010）等。
NoSQL是一次由开发人员主导的技术趋势。大型互联网公司在发展过程中吸引了大量优秀人才，积蓄了强大的技术实力，具备开发新型系统的能力。同时，来自业务的需求给他们带来了开发新型系统的动力。开发全新系统是机遇也是挑战。很多系统的开发者希望借此机会解决长期困扰开发效率的某些问题，其中之一就是数据处理领域自关系模型出现以来就存在的对象和关系模型不匹配（Object Relational Impedance Mismatch）问题。存储和处理数据的关系模型本质上是一个扁平的二维数据结构，不支持灵活的嵌套，而编程语言在内存中的数据结构通常是具有多级嵌套的结构体或者对象。这种内存和外存数据模型的不匹配使得开发人员不得不实现大量烦琐的代码进行转换，不但影响开发效率，而且容易出错。另一个问题是修改应用数据结构之前通常需要修改数据库的模式，这在需要频繁更新数据结构的场景下非常不方便。
图3-11显示了这种内外存数据模型不匹配的问题，左边是内存中的数据结构，右边是数据库中的存储结构，内存中的数据结构是嵌套型，而关系数据库的数据模型是扁平的。很多NoSQL产品解决或避免了这个问题，如文档数据库使用支持嵌套的JSON格式存储数据，而键值数据库则忽略数据的内部格式，把内存中的数据序列化为二进制串存储，读取的时候再进行反序列化。

3.4.2　NoSQL产品的共性

NoSQL产品数量众多，出现时机和原因各不相同，应用场景也多种多样，但这些产品之间存在一些共性。
1）顾名思义，NoSQL数据库（开始时）不提供SQL接口。某些NoSQL数据库提供了类SQL接口，然而都没有达到SQL标准的能力。
2）集群基因。NoSQL数据库大多具备良好的集群管理能力，有的NoSQL最初就是为集群而设计，因而具备很好的线性扩展性和高可用性。
3）追求高性能和高吞吐量。NoSQL数据库大多以追求高性能、高吞吐量和高可用性为目标，因而放弃了某些关系数据库的特性，如事务、强一致性、关联（JOIN）等。
4）NoSQL数据库的数据模型都是非关系型的，常见的数据模型有键值、列族、文档类型和图类型。
5）NoSQL数据库不使用模式（Schemaless）或者使用灵活的模式。因此，NoSQL数据库不需要事先设计完善的模式即可操作数据，并允许动态添加新数据类型或者修改已有数据类型。这为编程人员提供了很大的灵活性和便利性。然而，访问数据必须知道其模式，否则数据就是0和1组成的一堆无意义的二进制字符，所以需要有隐式模式，即对所存储数据的结构和类型的假设。这些隐式模式通常隐藏在应用代码中，NoSQL数据库本身不用关心，数据的使用者仍然需要了解这些隐式模式才能操作数据，所谓的无模式数据库不过是把模式从数据库移到了应用程序内部。
6）大多数NoSQL数据库以不同协议开放源代码。

3.4.3　NoSQL的分类

NoSQL数据库根据数据模式的不同分为四种类型：键值数据库、文档型数据库、列族型数据库和图数据库。

1. 键值数据库

键值数据库以键/值对形式存储数据，键必须唯一，这和哈希表的存储/操作方式类似。主键对应的值可以是任意二进制数据（包括文本数据），NoSQL数据库不知道数据内部细节，应用程序负责解析其语义。应用编程接口非常简单，支持读、写和删除键值对。有些键值数据库支持主键排序和范围（Range）操作。键值数据库性能出色，扩展性很好。流行的键值数据库包括Riak、Redis（由于可以存储集合、列表等，也称为数据结构服务器）、Memcached等。

2. 文档型数据库

文档型数据库的核心数据模型是文档（半结构化数据），以键/文档对存储。文档可以是XML、JSON、BSON等格式。文档多为树形结构，可以包含数组、子文档等。不同的文档可以有不同的字段，相同的字段可以有不同的数据类型。和键值数据库相比，文档内容对数据库可见，因而支持对文档的特定字段建立索引以实现高效检索。常见的文档型数据库包括MongoDB、CouchDB等。

3. 列族型数据库

列族型（Column-family）数据库支持定义多个列族，每个列族内允许定义可变数量的列，支持动态定义新列。通常将逻辑上相关、经常同时访问的数据放在一个列族内。和关系数据模型相比，可以把列族看成关系模型的一个列，列对应的值是一个复杂结构。常见的列族型数据库有Cassandra、HBase、Hypertable等。

4. 图数据库

图数据库支持非常灵活的实体关系，实体称为顶点，实体间的关系称为边。在图数据库中，边是内嵌的概念。常见的图数据库有Neo4J、OrientDB等。

3.5　SQL数据库的回归

3.5.1　NoSQL与SQL的融合

2017年，谷歌发表了一篇名为《Spanner: Becoming a SQL System》的论文，引发了关于SQL回归的热议。
图灵奖得主Michael Stonebraker和David J. DeWitt早在2008年就曾指出MapReduce是技术倒退。他们认为，MapReduce的基本思路很简单，开发人员只需实现两类函数：map函数和reduce函数。map函数对输入记录执行过滤或变形处理，通过split函数（通常是哈希）将map的结果分成多个分区，每个分区对应一个文件，具有相同split结果的记录都在同一个文件中；reduce函数对map的结果进行进一步处理，结果也以文件方式保存。MapReduce框架会自动并行运行这些程序进行计算。若用SQL术语类比，map类似于聚集语句的group-by；而reduce类似于聚集函数，对每个分组的所有元组进行聚集计算。他们指出：

• 作为一种数据处理模式，MapReduce是一种倒退。自1968年IBM发布IMS后的40年里，数据库社区吸取了三个教训：1）模式（Schema）很有价值，它描述了数据的元信息，防止垃圾数据污染数据集，没有模式的数据是没有意义的1和0的数字串，很快会变成垃圾；2）从应用程序中抽离出模式很好，数据是符合模式的高质量数据，可以在不同应用间共享，否则数据会变成单个应用的私有数据；3）高级访问语言很有价值，20世纪70年代关系阵营和CODASYL阵营就曾因为是否使用高级语言进行过长达数年的辩论，最终CODASYL淡出了视野。使用高级语言可以方便地描述要做什么而不是怎么做，程序易于实现、易于修改，也易于理解和维护。MapReduce丢掉了这些经验，因此倒退到了20世纪60年代。

• MapReduce是次优实现。数据库社区从20世纪60年代就支持不同的数据访问方法（Access Method），包括基于索引的方式和顺序扫描方式，优化器可以根据代价选择最佳路径。MapReduce仅仅支持顺序扫描。作为一个并行执行引擎，MapReduce也过于简单，如不能处理数据倾斜、基于文件的数据交换效率低下等。

• MapReduce本身也不是数据处理新模式，20年前就有大量关于高效并行处理大数据集的研究和商业实现，很多开源或者商业数据库也支持用户自定义类似map或者reduce的函数。

• MapReduce无法支持很多数据库管理系统提供的特性，包括高速加载、索引、更新、事务、完整性约束、参照完整性和视图等。

• MapReduce和广为使用的工具不兼容，如报表工具、BI工具、数据挖掘工具等。

当时，这些观点受到了MapReduce拥护者的反对。但十年之后的2018年，事实证明他们的观点是有道理的。
大量开发人员和组织最初采用各种NoSQL产品时，体验到了其优势。然而，随着时间推移，他们开始发现其中存在的问题，包括NoSQL的首倡者谷歌。（实际上，所有问题都是50年前在数据处理进入电子数据处理时代就已经深入讨论和研究过的。）这些问题包括：

• 不支持SQL，计算远离数据，开发人员需要自己实现复杂的代码并进行聚集分析等。

• 使用低级查询语言，数据物理独立性和逻辑独立性差、灵活性差、维护代价高。

• 不支持ACID和事务，开发人员需要自己写代码处理数据不一致造成的问题。

• 不支持关联，只能使用宽表，会引起数据冗余，维护代价高。

• 缺少标准接口，学习代价高、应用使用代价高，需要大量的胶水代码和转换代码。

• 多种NoSQL产品的引入导致数据整合代价高。

• 缺少生态，从数据迁移、ETL、报表、BI到可视化都要从头开发，难以进行数据分析。

• 人才缺乏，企业积累的大量SQL人才和资产无用武之地，造成浪费。

尽管如此，NoSQL产品仍然继续演进，其中一个趋势是支持更多关系数据库的优秀特性，如SQL标准。目前Apache社区有多个SQL-on-Hadoop项目，包括HAWQ、Impala、Presto等。此外，Kafka也开始提供SQL接口KSQL。
传统的关系数据库也开始支持越来越多的NoSQL特性，如2012年发布的PostgreSQL 9.2开始支持JSON。
由于NoSQL开始提供更多SQL特性，SQL数据库也开始支持更多NoSQL特性，NoSQL
与SQL的融合越来越深入。

3.5.2　Hadoop不等于大数据

过去，很多人认为Hadoop =大数据，一谈大数据必谈Hadoop。然而，这是一种误解。
Gartner在2015年发布报告《Survey Analysis: Hadoop Adoption Drivers and Challenges》，
该报告指出：尽管Hadoop被大量炒作，并有早期采用者的成功案例，但超过一半的受访者目前没有计划投资。此外，只有18％的用户计划在未来两年内投资Hadoop。
Gartner在2017年发布的数据管理产品周期图（如图3-12所示）中指出，Hadoop发行版在达到生产高峰期前已经过时。整个Hadoop技术栈的复杂性和可用性令许多组织重新考虑其在信息基础架构中的角色。
谷歌的发展经历也说明，SQL数据库更适合作为大数据的基础处理平台。这对很多组织都具有借鉴意义。

3.5.3　SQL从未离开

如前文所述，NoSQL出现和发展的主要推动力来自大数据引起的集群化需求和希望通过线性扩展能力获得更高的性能和可用性的需求。分布式、集群式SQL数据库的研究可以追溯到20世纪80年代中期，当时有多个组织和公司开始了分布式并行数据库的研发，包括Gamma、Teradata、Bubba和Tandem等。Teradata至今仍然是数据仓库市场的主力军之一。
目前主流的分布式SQL和NoSQL数据库都采用无共享架构（Shared-Nothing），威斯康星大学1984年启动的Gamma数据库项目首先提出了该架构。该项目研究人员1990年在IEEE上发表论文《The Gamma Database Machine Project》，其中详细介绍了设计和评测报告。其中提到的无共享架构、分布表（原文是Partitioned Table，Partition一词后来多用于表示单机上的分区表，如根据日期分区，因而此处使用分布表一词）、副本、Interconnect、数据流（Dataf?low）、哈希关联（Hash Join）等至今仍是很多分布式数据库系统的核心。
2000年后，在NoSQL流行前夕，一批新的分布式数据库厂商涌现出来。和NoSQL数据库放弃SQL和事务等技术方向不同，这些厂商实现了支持SQL、事务、ACID等特性的分布式大数据处理系统，主要以联机分析处理（OLAP）场景为主，包括2003年发布的Netezza、2005年发布的Greenplum（当时叫Bizgres，其Postgres基因一看便知）、2005年成立的Vertica、2008年提出的SAP HANA（HANA的早期前身系统更早）等。
针对联机事务处理（OLTP）业务的分布式SQL数据库系统也开始浮现。2007年提出的H-Store便是这种系统。作为一个学术型数据库，其开发团队成员来自于布朗大学、卡内基·梅隆大学、麻省理工学院和耶鲁大学，系统设计由Michael Stonebraker、Sam Madden、Andy Pavlo和Daniel Abadi操刀，阵容堪称豪华。H-Store的架构和传统RDMBS架构区别很大，它基于内存、只有undo没有redo日志且undo日志不落盘、单线程处理、不使用行级锁和latch等。然而，这种系统也有其限制，如需要预先对事务进行分类和编译、不支持交互式事务等。基于H-Store的商业公司VoltDB于2010年成立，提供企业级产品和服务。其他类似的产品还有ClustrixDB、CockroachDB等。

3.6　集成数据处理和分析平台

用户对数据整合的需求在20世纪60年代造就了数据库，进入21世纪的第二个十年，数据整合需求再现其强大的影响力，这次将催生集成数据处理和分析平台。

3.6.1　数据类型

早期数据库主要面对业务数据处理（Business Data Processing）场景。这种场景下的数据具有良好的结构，数据类型以定长数值类型和定长字符串为主。随着业务的发展，逐渐产生了对非结构化数据的处理需求。
最早的非结构化数据为可变长度文本数据。尽管SQL标准支持LIKE操作符，但是其性能很差。十年前常用的方案为，应用程序集成数据库和文本检索两类产品：应用数据存储到数据库，文本数据存储到Solr或ElasticSearch之类的文本检索服务器上，保存数据时将其中的文本数据定期或者实时地发送给文本检索服务器建立索引，查询时则需要在应用中对两种系统的查询结果进行关联处理。这种方式复杂、易错、性能不高、数据独立性差。
为了解决这个问题，很多数据库（例如Oracle、PostgreSQL）实现了文本检索产品中常用的倒排索引技术，大大提高了文本检索的效率。近几年，有些数据库开始支持一些高级的文本检索特性，如PostgreSQL支持停用词、短语搜索、多种词干库和高亮显示等。Greenplum的GPText产品组件则整合了Greenplum MPP数据库的特性和Solr丰富的文本检索特性，应用程序使用标准的SQL（而不用写代码）即可对文本数据进行高效的索引和查询，并且支持关联（JOIN）。
另一种常见的非结构化数据是地理空间数据。该领域知名的产品之一是ArcGIS。其早期产品使用shapef?ile格式的文件保存数据，后来改用称为geodatabase的对象关系型数据库存储空间数据，这是一种专为空间数据而优化的数据库。传统的关系型数据库也开始支持地理空间数据处理，如PostgreSQL的PostGIS扩展提供了非常强大的空间数据处理能力，支持点、线、面等基本要素，支持几何地理数据、经纬度数据、栅格数据和拓扑数据等，支持索引，还提供了200多个空间数据处理函数。此外，文本检索产品Solr和Elasticsearch等也支持地理空间数据处理。
自20世纪60年代后期至今，工业界和学术界一直在研究如何支持嵌套数据或半结构化数据，包括层级数据、网状数据、对象数据、XML和JSON等。XML数据库一度是最热门的研究课题。然而，基于XML数据模型的数据库没有普及，最终变成了关系数据模型的一种数据类型。基于JSON的文档数据库（例如MongoDB）是最受开发人员欢迎的NoSQL数据库之一。JSON作为数据交互格式和数据存储格式逐渐流行后，关系数据库也开始支持JSON作为一种数据类型，使得开发人员不但可以享受关系数据库的所有优势，还能利用JSON这种半结构化数据结构的灵活性。如，PostgreSQL 9.2开始支持JSON数据格式，2014年发布的9.4引入了增强型的JSONB，功能更强大、效率更高。
数据库还在持续加入更多的数据类型，如图（Graph）数据、多媒体数据等。Oracle 12c包括了对地理空间数据、图数据和多媒体数据的支持。
与此同时，用户开始厌倦为不同的数据处理采用不同的数据处理系统，更倾向于采用集成数据处理平台来处理企业的各种数据类型，包括结构化数据、半结构化（JSON、XML等）数据、文本数据、地理空间数据、图数据、音视频数据等。

3.6.2　业务场景

目前，数据库市场主要的两种应用场景为联机事务处理（OLTP）和联机分析处理（OLAP）。联机事务处理场景下，只查询处理少量数据，时间很短；在联机分析处理场景下，要查询处理大量数据，以读为主，通常时间较长，从几分钟到几个小时不等。为应对这两种不同的场景，需要使用两种不同的数据库产品。企业通常使用OLTP数据库支撑交易型业务；使用ETL（抽取、转换、加载）工具将事务型数据库的数据导入OLAP数据库进行商务智能分析，再根据分析后的结果调整交易业务。
2014年，Gartner的一份报告中使用混合事务分析处理（HTAP）一词描述新型的应用程序架构，以打破OLTP和OLAP之间的隔阂，实现实时业务决策。这种架构具备显而易见的优势：不但避免了烦琐且昂贵的ETL操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。
移动互联网、物联网和传感器的发展导致大量的流式数据产生，相应地出现了专有的流式数据处理平台，如Apache Storm、Apache Kafka等。近年来，很多数据库开始支持流式数据处理，如MemSQL、PipelineDB。有些专有流式数据处理平台开始提供SQL接口，如KSQL基于Kafka提供了流式SQL处理引擎。
传统的高级数据分析工作使用SAS之类的专业产品完成。这些产品通常需要从数据库或者其他数据存储系统中读取数据，然后进行计算（数据贴近计算）。这种方式效率不高，而且由于内存的限制，数据量大时只能使用采样数据，准确度较低。为了解决这个问题，有些数据库内建了机器学习、统计分析和模式识别等算法库，可以在数据库内对存储的数据进行高效的全量数据分析。例如，Greenplum数据库的MADlib组件提供了超过50种数据分析算法，包括回归、神经网络、支持向量机、决策树、主题建模、聚类、PageRank和最短路径等算法。

3.6.3　集中还是分散

Michael Stonebraker认为，单个数据库不能处理各种应用场景（one size does not f?it all），不同的场景应该使用不同的数据处理技术。他指出，联机分析处理、文本处理、流数据处理、科学计算等具有不同的特点，专有系统的性能将比通用系统性能高一到两个数量级，因而不同的业务应采用不同的系统，类似图3-13所示（他在一篇文章中提到，OLTP、OLAP和其他场景市场份额大约各占1/3，“其他”部分包含很多细分领域，由于场景差别很大，每种场景需要专有的系统）。
就当前的用户需求和软硬件技术发展状况来看，集成数据平台将能满足绝大多数用户的场景，只有极少数企业需要使用专有系统以实现其特殊的需求。比如，PostgeSQL的性能在使用英特尔至强处理器E7-8890的单机系统上可达百万TPS（Transaction Per Second，每秒事务处理量），尽管某些专为OLTP优化的内存数据库可能达到更快的TPS，然而有如此大业务量的公司非常少。大多数用户将采用集成数据平台，如图3-14所示。

集成数据平台有以下优势：

• 通过数据整合避免信息孤岛，便于共享和统一数据管理。

• 基于SQL的数据集成平台可提供良好的数据独立性，使应用能专注于业务逻辑，不用关心数据的底层操作细节。

• 集成数据平台能提供更好的实时性和更全的数据，为业务提供更快更准的分析和决策。

• 能够避免各种系统之间的胶合，企业总体技术架构简单，不需要复杂的数据导入/导出等，易于管理和维护。

• 便于人才培养和知识共享，无须为各种专有系统培养开发、运维和管理人才。

集成数据平台也有其不足之处：

• 性能比专有系统逊色。

• 集成数据平台多是分布式数据库系统，出现问题时，分析原因较复杂。

• 数据集中存储和处理，权限管理复杂。

古人说“天下大势，分久必合、合久必分”，这句话用在数据处理领域也不为过。需求和技术是一对矛盾，当这对矛盾缓和时，数据处理领域将更趋向于整合；而当这对矛盾尖锐时，数据处理领域将趋于分散。就软硬件技术发展现状和当前需求来看，未来整合的趋势更为明显。

3.7　数据平台的选型

前面我们介绍了数据平台的演进历程和发展趋势，了解其发展过程和趋势可以帮助我们更好地选择适合自身的数据平台。
选型时首先需弄清楚企业自身的业务需求和未来的发展趋势，避免杀鸡用牛刀或者蚂蚁撼大象的情况。之后，对候选数据平台进行多维度考量。下面从技术角度列出一些大数据处理平台选型的因素或原则以供参考。

• 产品成熟度：成熟的产品可以避免用户走弯路，避免企业做小白鼠、浪费各种资源和时间。衡量一个产品的成熟度可以参考其付费企业级客户的数量和体量。通常，经历过金融等高压/高要求行业核心业务验证的产品，其成熟度更可靠。另一个参考指标是产品在本行业内的普及度。

• 开发和运维的复杂度：开发和运维在整个大数据平台生命周期中占有很大的比重，其投入通常大于初期产品采购的投入。大数据处理平台越大，这一趋势越明显。对于开发人员而言，写SQL等类自然语言通常比写分布式Java、Python代码更快、更易维护。对于运维人员而言，良好的监控和管理工具必不可少。此外，自动化智能运维工具开始出现，也越来越有吸引力。

• 标准兼容度：SQL标准逐渐成为大数据系统的主要标准之一。SQL标准有很多版本，对不同SQL版本的兼容度是衡量大数据系统的一个重要指标。很多大数据系统支持一些简单的SQL，但不支持很多高级SQL特性，如跨节点关联查询、子查询、窗口函数、数据立方格（CUBE）、通用表表达式（Common Table Expression，CTE）等。如果系统不支持这些特性，应用开发人员只能自己实现，既费时费力，又不利于重用和维护。良好的标准兼容度也可以降低数据和产品迁移的代价。

• 核心技术特性：列出平台支持的核心技术特性，根据自身需求进行评估。对于一个大数据处理系统，可以考量其ACID支持能力、数据水平分布能力、并行查询执行能力、查询优化能力、线性扩展能力、多态存储能力、资源管理能力、数据加载能力等。

• 跨硬件平台：是指大数据系统可以运行在各种硬件平台之上，不管是裸机、私有云、公有云还是容器环境。由于不受限于硬件环境和平台，用户便可以保留选择适合自己的硬件环境的权利，未来的迁移代价低，开发和运维人员不需要学习新的数据库处理技术。硬件环境的普适性可以避免硬件平台的制约和锁定，为客户解决后顾之忧。

• 开放源代码：开源意味着透明，用户可以了解甚至评估代码风格、代码质量、代码审核严谨度、开发人员的素质、项目进度、合作方式、社区活跃度等各个方面。了解这些细节比仅仅听取销售的推销而购买一张刻录了代码的光盘更让人有信心。此外，采用开源方案，不用担心后门问题，也不用担心被锁定。优秀的开源产品更容易吸纳新用户，从而促进开源项目的发展。相对于封闭系统，围绕开源系统进行开发更容易，同时有利于构建更好的生态。

• 完善生态系统：完善的生态一方面可以降低用户端到端的部署代价，另一方面有助于生态内的各个产品的健康发展。

• 数据源和数据格式：如果企业和组织内部存在多种数据源和数据格式，则应考虑选择支持这些数据源和数据格式的大数据平台。常见的数据源包括各种关系数据库、Kafka、ElasticSearch、Redis、MongoDB、Hadoop、HIVE、HBase、S3、文件等。常见的数据格式包括结构化数据、半结构化（XML、JSON、KV等）数据、非结构化数据（文本数据、GIS数据、图数据等）。

• 高级分析能力：如果项目有高级数据分析或者机器学习的需求，则优先考虑内建了高级数据分析和机器学习能力的平台。通过内建高级分析算法到平台之中，而不是抽取数据到业务应用或者第三方应用中再作分析，可以大大简化业务的复杂度，提高开发效率，同时提高分析模型精度。从基于大数据的高阶数字化战略（详见第2章）高度出发，内建的高级分析能力更为重要。

• 扩展能力：当产品提供的特性不能满足用户的特定需求时，则要对产品进行扩展，可扩展性是具有此类需求的用户考虑的一个因素。建立了基于大数据的高阶数字化战略的企业对平台扩展能力要求更高。

在数据经济时代，数据处理和分析的能力与效率是企业的核心竞争力，因此选择合适的集成平台至关重要。读者可以参考以上方面选择出适合自己的大数据处理基础平台。
经过15年的发展，Greenplum在以上各个方面做了非常精心的考量，成为一款值得信赖的大数据处理基础平台。后面各章将会对Greenplum进行详细的介绍。

3.8　小结

本章以数据处理平台的演进历史和未来趋势为主题，着重介绍了三次整合的背景及影响：

• 机器整合：第一次数据处理的大整合是硬件上的整合。在电子计算机出现之前，企业使用各种专用机器实现不同目的的数据处理，如使用加法机进行算术计算、使用制表机生成报表等。电子计算机出现后，电子数据处理（EDP）逐渐取代之前使用的各种专用机器，实现了硬件上的整合。

• 数据整合：第二次数据处理的大整合是数据的整合。在数据库出现之前，各个应用程序存储和管理各自的数据，造成数据共享困难和数据独立性差等问题。数据库实现了数据的整合，各个应用程序通过数据库存储和访问数据，解决了数据共享和独立性的问题。

• 处理整合：第三次数据处理的大整合是处理的整合，其结果是集成数据处理和分析平台。在数据平台出现之前，企业为不同的场景使用不同类型的数据库，造成了数据孤岛。数据平台将提供集成数据处理和分析能力，满足不同场景的需求，避免数据孤岛及其带来的各种问题。

现在，第三次整合快速发展。我们正处于这一整合的关键发展阶段，涌现出很多新产品。企业决策者应考虑各种影响因素以选择适合自己的平台。

进一步阅读

为了更好地理解本章内容，推荐有兴趣的读者进一步阅读以下书籍、论文或网上资源。

• A History and Evaluation of System R，作者Donald D. Chamberlin等。

• A General-Purpose File System For Secondary Storage，参见http://www.multicians.org/fjcc4.html 。

• A Study of SQL-on-Hadoop Systems，作者Yueguo Chen等。

• Batch Processing，参见https://en.wikipedia.org/wiki/Batch_processing 。

• Computer File，参见https://en.wikipedia.org/wiki/Computer_file 。

• Data，参见https://en.wikipedia.org/wiki/Data 。

• Data Base Technology，参见https://dl.acm.org/citation.cfm?id=1664865 。

• Data processing，参见https://en.wikipedia.org/wiki/Data_processing 。

• Data Processing Technology and Accounting: A Historical Perspective，作者Robert Kee。

• Database，参见https://en.wikipedia.org/wiki/Database 。

• Database System Concepts（第6版），作者Avi Silberschatz、Henry F. Korth、S. Sudarshan。

• Early History of SQL，作者Donald D. Chamberlin。

• Jim Gray at IBM The Transaction Processing Revolution，作者Bruce G. Lindsay。

• File system，参见https://en.wikipedia.org/wiki/File_system 。

• History of Operating systems，参见https://en.wikipedia.org/wiki/History_of_operating_systems 。

• H-Store: A High-Performance, Distributed Main Memory Transaction Processing System。

• IMS Then and Today。

• Ingres: Can you Ever Go Back?，参见https://kellblog.com/2006/04/08/ingres-can-you-ever-go-back/ 。

• MapReduce: A major step backwards，作者David J. DeWitt and Michael Stonebraker，参见https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html 。

• Multics（Multiplexed information and computing service），参见https://en.wikipedia.org/wiki/Multics 。

• NoSQL，参见https://en.wikipedia.org/wiki/NoSQL 。

• NoSQL Distilled: A brief guide to the emerging world of polyglot persistence，作者Pramod J. Sadalage, Martin Fowler。

• NoSQL for Mere Mortals，作者Dan Sullivan。

• OLTP Through the Looking Glass, and What We Found There，作者Stavros Harizo-poulos等。

• “One Size Fits All”: An Idea Whose Time Has Come and Gone。

• Organization and Retrieval of Records Generated in a Large-Scale Engineering Project，参见https://www.computer.org/csdl/proceedings/af?ips/1958/5053/00/50530059-abs.html 。

• PostgreSQL Scalability: Towards Millions TPS，参见http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/ 。

• Readings in Database Systems（5th Edition），参见http://www.redbook.io/ 。

• Relational databases and beyond，作者MF Worboys。

• Software in the 1960s as Concept, Service, and Product，作者Thomas Haigh。

• Spanner: Becoming a SQL System，作者David F. Bacon、Andrew Fikes等。

• System R: Relational Approach to Database Management。

• The Commercialization of Database Management Systems，1969-1983。

• The Design and Implementation of INGRES。

• The Design of Postgres。

• The end of an architectural era，作者Michael Stonebraker等。

• The evolution of the filesystems，参见http://cs-exhibitions.uni-klu.ac.at/index.php?id=188 。

• The Gamma Database Machine Project, DeWitt, et. al., IEEE Transactions on Knowledge and Data Engineering, Vol. 2, No. 1, March 1990。

• The U.S. Software Industry: An Analysis and Interpretive History W.Edward Steinmueller。

• The History of Storage Systems，作者Kazuo Goda, Masaru Kitsuregawa。

• The History of The History of Software，作者Martin Campbell-Kelly。

• Timeline of operating systems，参见https://en.wikipedia.org/wiki/Timeline_of_operating_systems 。

• Tutorial: SQL-on-Hadoop Systems，作者Daniel Abadi等。

• What Goes Around Comes Around，作者Michael Stonebraker, Joseph M. Hellerstein。

• What’s Really New with NewSQL?，作者Andrew Pavlo, Matthew Aslett。