1.2 大数据

云计算是个概念清晰的新技术，相比之下，大数据则是在量变到质变的过程中突然火爆起来的。大数据可以看作是一系列技术和商业实践的集合，因此业界对于大数据的定义可谓丰富。如同在《Cloud Foundry：从数字化战略到实现》一书中解读云计算那样，作者仍将通过剖析技术背后产业变迁的驱动力的方式来解读大数据。

知名咨询公司Gartner指出，数字宇宙在不断膨胀。谷歌首席经济学家范里安也指出：“从人类文明诞生到2003年，一共创造了5ET的数据，而现在几乎每两天就能创造这么多数据。”早在2012年，作者和易安信（EMC）联邦的大数据产品领导人讨论PC时代如何向云计算时代跨越时，就谈及大数据产业发展趋势以及我们应该建立怎样的技术。

1.2.1 从CRUD到CRAP

在PC时代，计算机主要用于流程的自动化，因为在流程的各个环节都会产生大量事务（Transaction），计算机的数据系统主要用于对这些事务记录进行操作。假设我们要为一所学校创建一个学生管理系统。当一个学生被录取，系统就需要记录这样一个事务，为此需要创建（Create）一条学生记录，记录学生的一些信息，例如身份证号、性别、年龄、籍贯和录取分数等。当该名学生到学校报到的时候，我们可能需要更新（Update）相关的记录（比如，学籍管理字段用于记录学生报到时间，此时就需要把这条字段更新到最新的报到日期）。如果报到后有人获得授权查询该学生的录取分数，则可以从数据库系统中获取（Retrieve）该学生的记录。因为系统的存储容量有限，所以当系统饱和的时候，就会删除（Delete）一些过去的记录。简言之，记录的上述操作可归结为创建（Create）、获取（Retrieve）、更新（Update）和删除（Delete）的组合，取英文首字母的缩写叫作CRUD。关系数据库管理系统（RDBMS）的关键就是保证事务操作的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），取四个英文单词的首字母叫作ACID属性（我们会在后面详细介绍ACID属性）。目前，读者只要记住ACID是保证记录的CRUD操作不出现任何错误的重要性质即可。这个工作听上去容易，但考虑到多个用户产生的事务同时操作一条记录，以及像银行这样要确保任何一笔事务都实现零差错（不然用户账户余额可能出现差错）的情况，事情就不那么简单了。Oracle数据库、IBM的DB2数据库和微软的SQL Server数据库就是靠卓越的ACID能力成为PC时代伟大的产品。

随着数据记录的数量与日俱增，一些企业开始对历史记录进行数据挖掘，以获取有价值的信息。比如，美国的学校非常关心自己的生源和学生就业之间的关系。如果说GRE分数越高的学生就业越好，那么是否应该提高录取的GRE分数？反之，是否可以在录取条件中降低GRE的录取分数？这些带着预设问题的报表操作就叫作商业智能（Business Intelligence, BI），它其实和人工智能开始接近。在BI上尝到甜头的企业，在清理事务数据系统的记录的时候会把它们导入到另外一个叫作数据仓库（Data Warehousing）的数据管理系统，以备后续BI操作之用。此外，如果在事务数据系统中运行BI操作，会导致事务数据系统性能急剧下降，进而影响正常业务应用。举个例子，一个学生入学的时候，教务处希望更新该学生学籍，而前面一个BI操作正在生成所有毕业生的GRE成绩和就业单位起薪的报表，那么更新学籍的操作就会等待很长时间才能执行。所以，需要建立一个专门针对BI的数据仓库系统以便让事务系统的运行不受干扰。当事务系统接近存储极限的时候，可以把部分老数据导入到数据仓库，以免丢失有价值的历史数据。由此，数据仓库系统出现了两个很有意思的操作：历史数据追加（Append）操作和报表处理（Process）操作。当然，数据仓库系统依然需要创建（Create）和获取（Retrieve）操作。但是，因为数据仓库中的数据记录都是有价值的，所以数据仓库中的删除（Delete）操作会减少，即使执行删除，记录也会被备份到更加低速、廉价的存储介质上而不是真正被删除。此外，更新（Update）操作在数据仓库里面也被减少，因为历史记录是有价值的，所以当一条记录被更新时候，系统只是追加了一条新的记录，而不是将原记录替换为新记录。例如，用户每次更新密码的时候，系统会在数据仓库系统里面追加老密码的记录，以备后续检查（预防用户重设密码或者在用户忘记新密码的时候作为额外途径进行认证）。因为历史记录的价值在BI系统中被逐步发现，所以数据系统的创建（Create）、获取（Retrieve）、更新（Update）和删除（Delete）为主的CRUD操作慢慢转为创建（Create）、获取（Retrieve）、追加（Append）和处理（Process）为主的CRAP操作（CRAP是四个操作的英文首字母）。伴随着数据仓库技术的发展带来数据量的上升和数据处理速度提升的要求，工业界对于数据处理技术的要求也不断提升，于是大规模并行计算(Massively Parallel Processing, MPP）技术应运而生。

1.2.2 MPP（大规模并行计算）

原来专注于事务的数据库管理系统主要涉及针对单条记录的CRUD操作。因为数据仓库的出现，BI（甚至早期的AI）算法开始整表整表地扫描所有数据。为了提高数据的处理速度，在PC时代人们不再挑战单个大型机的性能极限，取而代之的是利用一个PC集群来提高计算性能。人类面临复杂问题的时候，分而治之是常用策略，MPP是典型的分而治之策略的产物。为了帮助读者理解分而治之的策略，我们来解析一个快速排序算法的设计，无论读者是否有计算机专业背景，理解这种方法背后的设计原则都是有益的。

快速排序算法问题陈述：假设给定任意一组无序的和不定数量的数，例如{0,50,24,9,23,7,35,17}，我们要让计算机找到一个步骤（算法）将这堆数从小到大依次排列。

快速排序算法描述：采用分而治之策略的快速排序算法就是在中间位置挑选一个数（即枢数，英文为Pivot），比枢数小的数移到其左边，比枢数大的数则移到其右边。然后，依次对左边的一组数和右边的一组数分别再进行快速排序。如果我们挑选23作为第一趟排序的枢数，那么第一趟排序后的结果为：

{0,9,7,17},23, {54,24,35}

读者可以自己尝试对左右两组数继续做第二趟排序。注意，这时，本来对一堆数排序变成了对两堆数分别排序，第二趟排序后就有四堆数需要排序，这就是一个不断分而治之的过程。

同样地，并行计算也不是新理论，只是在BI业务场景下它有独特的适用之处。随着数据量越来越大，BI业务的结果返回速度越来越慢。作者从几个世界级公司的大数据团队那里了解到，得出一个市场活动的报表常常需要几天乃至数周。可见，提高处理（Process）的速度已成为关键。MPP的分而治之策略就是把数据均匀分布到一群PC上，然后让每台机器同时工作进行处理。举个简单的例子，我们要找出双十一活动中消费金额最高的顾客给予奖励。假设我们把双十一的消费记录导入数据仓库并均匀分布在数据仓库的10台PC服务器上。只要同时对这10台服务器上的数据进行扫描，每台服务器分别返回消费金额最高的顾客记录，然后对比这10台服务器各自返回的消费金额最高的顾客记录，最终找到获奖的顾客。这种方式的扫描速度接近单台服务器速度的10倍。如果企业还是觉得这个速度不够快，那么可以把数据仓库扩大到100台等同的PC服务器，速度可以再快10倍。当然，实际情况没有这么简单，因为在这个例子中，10台服务器只要交换一次数据就可以解决问题。喜欢挑战的读者可以考虑一下如何计算消费记录的中数，就会发现10台服务器之间交换的数据量要大很多。当然，现在Greenplum中有大量的技术可以用于处理这些复杂场景下的系统性能。热爱技术的读者可以在后续章节领略到Greenplum中大量体现匠人精神的性能设计方式。一个技术产品是一系列设计艺术的集合，它需要人才、时间和组织文化的沉淀。

随着大数据的爆发，产业趋势拉动数据仓库技术朝大数据平台的方向发展。产业需要数据仓库产品拥抱开源、云计算和人工智能等新趋势。Greenplum和Teradata等伙伴们一直在演进，Greenplum因为Pivotal的第三平台战略的要求，演进速度非常快，这些将在后续章节阐述。值得一提的是，市场迫切需要一个数据仓库以外的MPP数据引擎，以处理数据仓库结构化数据以外的半结构化数据。典型的场景是Google的搜索，它需要处理大量半结构化的Web文本。为此，Google提出了MapReduce并行计算和Google文件系统（Google File System, GFS）。Google虽然发表了论文，但是并没有提供软件和源代码。于是，社区里热心的粉丝们启动了一个Hadoop项目，实现了类似的Hadoop MapReduce和Hadoop文件系统（Hadoop File System, HDFS）。Greenplum为了支持Hadoop社区，把Greenplum的并行SQL执行引擎和HDFS结合，创建了Hadoop生态内的HAWQ项目。HAWQ的研发工作主要在Pivotal中国研发中心内部完成，并且在2018年成为Apache的顶级开源项目。

除了结构化数据和半结构化数据的MPP, Pivotal中国研发中心还对其他特定场景数据的并行计算进行了探索。Pivotal上海研发团队曾发起Open-MPI项目，探索基于开放高速消息传递接口的并行化以计算社交网络图谱数据。这样的探索最终不一定都会取得商业上的成功，但是对于一个意图成为MPP计算行业意见领袖的机构来说是必须的。基于这种探索精神，Greenplum和HAWQ产品创造了行业中很多从无到有的创新点。

1.2.3 大数据系统

在Greenplum和Hadoop出现之前，数据仓库和BI有两大局限性：一是系统的成本太高；二是BI需要结合人为判断才能产生商业意义。

首先来说成本的问题。假设一个四年制高校每年有8万名在校生（即每年有2万名新生），那么事务系统只要存储8万个学生相关的记录。但是，为了保留过去20年间所有学生的记录，数据仓库系统需要保留过去16年毕业生的32万个记录。在存储价格昂贵的PC时代（读者可以回忆一下，当时容量为32MB的可以下载8首MP3的U盘要卖200多元），成本数倍于业务系统但又不是刚需的数据仓库系统对于大部分企业来说是高阶玩家的装备。更为糟糕的是，不少早期的数据产品建立在封闭的硬件和软件之上。硬件方面，数据仓库都有专用存储系统，这些存储的价格是通用磁盘或者快闪存储价格的数倍到十余倍。同时，软件系统也是封闭的，围绕软件系统开发更多BI工具或者高阶的AI算法非常困难。加上当时BI应用普遍被认为非刚需应用，使得大部分企业很难看到投入产出比（ROI），导致进一步禁锢了大数据的价值。

其次来看BI需要人为判断的问题。BI生成了很多报表，但是这些报表要靠公司的决策者来解读。依靠直觉的人为判断会浪费决策者大量时间。尽管决策者擅长分析解读数据并工作勤奋，但BI的真正问题在于只有在决策者提出一个问题后才会生成报表。例如，一名校董提出希望了解学生的GRE成绩和就业薪水的关系，数据仓库工程部门才会生成相应的报表。但是，决策者们更希望计算机的数据系统能够覆盖他们的盲点。如果一个计算机系统能够自动发现GRE分数高和就业起薪高的人群在二维空间分布图上聚集度高的规律并能自动提醒决策者，那么这样的数据仓库系统才能真正帮助到决策者（实际上，这里隐含了一个叫作聚类的非监督学习的人工智能算法）。所以，产业界开始由BI向AI迁移，但是AI比起BI需要更多的算力、更多的廉价数据存储和更开放的软件系统。

开源Hadoop和Greenplum解决了这两个进入大数据时代的绊脚石。首先，Hadoop和Greenplum是开放源代码的，这使得专用的数据仓库可以接受更多高阶算法的改进。例如，技术人员在Greenplum上面建立了一套叫作MADLib的人工智能和机器学习的库函数，企业可以在自己的数据上面应用很多高阶的机器学习算法，其中包括我们上面提到的非监督学习的算法，这意味着大数据系统可以找出更多靠人类直觉无法发现的智能和关联关系。MADLib最早是由Greenplum和加州伯克利大学联合开发的，Pivotal成立以后，将MADLib完全开源给Apache，使其于2017年成为Apache的顶级开源项目。同样，Hadoop也建立了一套机器学习的库函数Spark ML，它的逻辑和MADLib几乎是平行的。

其次，Hadoop和Greenplum都建立在通用的服务器存储上，也就是说，大数据系统的存储和读者家用电脑的存储是一样的。那么，Hadoop和Greenplum是如何利用普通硬盘达到专用存储的可靠性和性能的？无论是普通硬盘还是专用存储设备，其本质都是通过相关的软件和硬件冗余来实现存储的性能和可靠性的。Hadoop和Greenplum只是把这些软件的逻辑上移到服务器层次（Tier）。因为大数据系统需要对数据整遍整遍地读取，硬盘很容易损坏，所以Hadoop和Greenplum采用冗余方式解决这个问题，即把一个数据块同时拷贝在2～3台服务器上（有些没有安全感的公司甚至拷贝到5～7台服务器上）。如图1-2所示，文件块1、2、3同时在三台服务器上存有两个拷贝。服务器A上有文件块1和3，服务器B上有文件块2和3，服务器C上有文件块1和2。这样做的好处是，任何一台服务器损坏时都不必担心，因为它上面的文件块必然在其他两台服务器上有备份。假设服务器C损坏，其硬盘上的文件块1和2丢失，此时插入一台新的服务器D，就可以从服务器A上恢复文件块1，从服务器B上恢复文件块2，最终服务器D重构了文件块1和文件块2，从而完美取代了原来的服务器C。

数据冗余的另一个好处就是可以实现数据本地性（Data Locality）。并行计算的一个关键瓶颈是数据移动，而通过数据冗余可以实现在本地移动数据的效果。仍以图1-2为例，如果一个计算任务需要扫描文件块1，而服务器A正忙于其他任务。这时候因为服务器C上有文件块1的冗余，就可以把这个计算任务分派到服务器C。假设没有服务器C上的冗余备份，那么只能从服务器A上拷贝数据块1，在这种情况下，有大量时间不是用于计算文件块1，而是等待数据块1从服务器A拷贝C，造成大量的时间浪费。

因为Hadoop系统和Greenplum系统的开源和开放以及使用通用硬件构建大数据系统，从而极大降低了大数据系统建设和使用的门槛。加之很多学术机构和顶级公司已经用它们的专用系统通过大数据在机器学习和人工智能上取得成功，强烈的示范效应使大数据风靡全球。大部分中大型企业都开始考虑通过大数据系统增强自己的竞争力。

1.2.4 当大数据遇到云计算

前面谈到，大数据系统云上北向迁移的趋势很难阻挡。云计算除了带来更低的运营成本，也带来了更低的存储价格和可以伸缩的计算资源。这一趋势的推动力来自第三代平台，而第三代平台是CPU、存储和网络的产能不断升级过程中由量变到质变的产物。但是，大数据系统上云也有两个核心的技术问题要解决：1）提供适应于云计算的运维环境；2）按照云上存储环境进行适配。

首先，我们来看云计算对于大数据运维的影响。一个软件系统运维的简便性与否会极大影响软件的推广。公有云的一个优势就是把系统运维的复杂性留给了云厂商，而给用户提供了一个不需要专业人员即可运维的环境。以淘宝网为例，淘宝店主不需要太多培训就可以在淘宝网上开设并运营自己的网店。相比之下，传统线下的企业大数据系统则需要专业团队来维护，而Hadoop系统的运维尤其复杂。对于500强企业来说，可以招聘一个运维团队来运维这个系统；但对于中小企业来说，运维复杂性带来的成本增加远大于软件许可费下降带来的成本节省。Gartner在2017年发布的技术成熟度曲线指出，Hadoop系统运维的复杂性将使得Hadoop系统在到达“生产成熟期”之前直接过时。当大数据遇到云计算以后，获得了一个新的契机，那就是可以通过云上可运维性的改善让中小企业像运维淘宝网店一样运维自己的大数据系统。类似于Snowf lake的一批数据产品开始朝云上可维护性这个方向发力，开源Greenplum在阿里云等公有云平台上的发布也降低了产品部署和运维的复杂性。

其次，我们再看云计算存储对于大数据的影响。云上的存储分为块（Block）存储和对象（Object）存储。前者通常依赖Dell EMC这样的存储系统保障，它的优点是快速和可靠，缺点是成本高昂。对象存储（例如亚马逊的S3）的特点是价格低廉，但计算访问速度相对较慢。在《Cloud Foundry：从数字化战略到实现》中我们说过，云计算通过软件和硬件的分离实现了软件的永生能力，而传统的大数据系统可以直接访问本地的存储。因此，云上的共享块存储环境与传统大数据系统的本地存储环境存在一定矛盾。大数据系统上云需要解决计算主体和存储主体分离的问题。另外，云上的对象存储因为廉价、可靠等优势存放了各种不同的数据源。除了半结构化的文本数据，也有大量的图片、音频和视频数据。因此，大数据系统上云也要支持对更多数据源的处理。在云上，Greenplum提供了新技术来访问S3文件系统内的半结构化数据，在后面的章节中将讨论这一点。对于云上的图片和视频等数据，因为存储和计算系统需要对相应的机器学习算法进行特殊调优，所以催生了Google的TensorFlow等产品。