4.3　海量并行处理系统

海量并行处理（Massively Parallel Processing，MPP）数据库系统已经出现几十年了。不同供应商的系统架构可能存在差异，但对于存储并分析海量数据来说，MPP是最成熟、经过验证的、使用最广泛的处理机制。MPP到底是什么？它有什么特别之处？

一个MPP数据库会把数据切分成不同的独立数据块，由独立存储与CPU资源进行管理。在概念上，这有点像把一些数据导入您家里多台电脑构成的网络中。MPP打破了数据被仅拥有一个CPU单元和磁盘的中央服务器进行管理的限制。MPP系统中的数据被切分导入一系列的服务器中，存储于不同CPU单元管理的不同磁盘里。图4-3说明了MPP的原理。

图4-3　海量并行处理系统的数据存储

为什么MPP架构有如此巨大的威力？想象一下，您正在一条六车道的高速公路上开车，假如六车道变成一车道，即使只发生在某一小段距离内，这都会带来可怕的交通拥堵。如果从出发地到目的地始终都是六车道，那么交通会顺畅得多。虽然在某些时刻比如高峰期，拥堵仍然不可避免，但也不会持续很长时间，这让公路状况变好了很多。在非MPP架构的数据库中，即使不是全过程，在某些处理环节，也会出现六车道变成一车道的情况。在车流不多的情况下，一车道也没问题，一旦出现大的车流量就会出现问题。这就是MPP架构处理海量数据时无与伦比的优势，它开放了更多车道让车辆快速通过。

让我们来看一个数据库的例子。假如有一张1T的数据表，一个传统的数据库在同一时间只能查询一行。如果是一个拥有10个处理单元的MPP系统，它可以把这个1T的数据表切分成10份，每份100GB数据，并分配给不同的处理单元。这意味着在同一时间可以同时查询10份100GB的数据。如果需要更强大的分析能力和更快的分析速度，只要增加更多的处理单元，系统能力就会得到提高。

分工合作！

一个海量并行处理架构（MPP）的数据库，会把数据分配给不同的CPU单元和不同的磁盘空间。逻辑上，这类似于拥有几十台甚至几百台个人电脑，每台电脑存储一部分数据。在执行查询时，用不同处理单元同时执行的许多小型查询替代了一个单一的大型查询，查询速度自然就快了很多。

在这个数据库的例子中，如果这个系统升级到了20个处理单元，那么就不是同时进行10次100GB的查询，而是同时进行20次50GB的查询，这相当于100％的性能提升。当查询要求不同数据单元的数据进行信息交互时，事情会更复杂一些，但是MPP系统在设计时就已经考虑到了这一点，因此可以非常快速地处理这种情况，如图4-4所示。

图4-4　传统查询与MPP查询的比较

MPP系统会制造一定程度的数据冗余，同一份数据可以同时存储在不同的地方，这样做的好处是，一旦出现系统故障，数据恢复会非常简单。MPP系统里的资源管理工具会管理这些CPU和磁盘空间，查询优化器会对执行的查询任务进行优化，这都使得整个系统变得更容易管理，计算效率也更高。对这些内容更深度层次的讨论不在本书的范围内。

4.3.1　使用MPP系统进行数据准备与评分

MPP能够给复杂分析带来巨大提升的原因是，复杂分析的主要困难都发生在数据处理阶段。在数据处理阶段，人们要对数据进行大量的连接与汇总，生成新的衍生数据并对数据进行各种转换。在这个过程中，来自不同数据源的各种数据实现了整合。连接在前面的章节已经介绍过了，而汇总则意味着把多条记录转换成一条记录，从而获得更全面的信息。例如，抽取客户的多条交易记录，计算客户的总体销售量与单次平均销售量。生成衍生指标与数据转换则包含一系列的复杂操作过程，如计算客户每次交易的各类占比，或使用log或平方根等数学函数以获得新的分析指标。

这些数据处理任务的逻辑通常来说并不复杂，这正是关系型数据库，以及结构化查询语言（Structured Query Language，SQL）适合执行的任务。对大多数分析而言，今天的SQL，即使不能支持所有也可以支持绝大部分的数据处理工作。SQL的使用正是库内处理理念在MPP系统的具体表现。分析师再也不需要把数据从数据库中抽取出来并通过分析工具进行处理，相反地，他们可以简单地通过撰写并提交SQL脚本，就可以把这些复杂的数据处理工作交给数据库执行。

仅仅在10年前，SQL还存在一些缺陷，难以支持高级分析需要的某些复杂计算。但现在，SQL已经强大了许多。事实上，SQL的一些限制条件已经不存在了，例如，SQL在处理某一行数据时不能了解其他行数据。现在已经出现了一些叫“窗口式汇集（Windowed Aggregates）”的SQL函数，它们可以在处理某一行数据的同时，对其他区域的数据进行查询。通过这些SQL函数，查询某一个交易是客户的第一次还是最后一次交易就很轻松了，这使得数据处理过程也发生了变化。某些高级分析工具为数据准备过程提供的处理过程，完全可以使用SQL的这些函数来实现。

在SQL拥有这个强大功能之前，为了进行必要的数据处理，人们不得不把数据从数据库中抽取出来。幸运的是，随着SQL的发展，已经不再需要这样做了。数据处理过程中的绝大部分操作都可以通过SQL在数据库内实现。最近也出现了一些新的整合处理方式，我们将会在后面进行讨论。

不要低估SQL！

在过去的这些年，SQL已经强大了很多，现在它可以胜任几乎所有的数据处理任务。分析专家可以使用SQL或者其他分析工具把数据处理过程提交给数据库执行，从而显著扩大了分析人员可以处理的数据规模，而这对于大数据格外重要。

作为库内处理理念的发展趋势，分析工具的很多厂商已经开始在分析软件中内置把分析流程提交给数据库执行的功能。在这些工具里，这些分析流程都已经开发好了，但是这些软件现在发现，如果可以连接到MPP数据库引擎，软件就可以把处理复杂任务的指令提交给数据库，让数据库来执行处理任务，而无需抽取大量数据。

分析工具将分析流程内置到数据库中的演进过程意味着，分析专家现在可以自由地选择他们感到顺手的、具有高度可扩展性的分析环境。与此同时，分析应用仍然在将更多的功能和特性集成到MPP数据库中，这将进一步增加库内分析的影响力。

库内处理也被广泛的用于各种评分模型。通常，我们会使用抽样数据来建立模型，但使用这个模型来进行评分，则需要针对全部数据。例如，通过部分抽样的客户数据建立了一个客户购买倾向的评分模型，到了应用这个模型时，则需要对所有客户进行评分，这样才能挑选出得分最高的客户来进行营销。把所有数据从数据库中抽取出来进行评分的传统做法，即使不是完全不可行，也是不实用的，因为抽取全部数据进行处理会耗费大量的时间。

让我们看一个更细节的例子。假如某一个零售商已经建立了一个倾向模型，来评估哪些客户更有可能参加某一次促销活动。这个模型通常是建立在抽样的客户数据上，可能只覆盖了几百名或者几千名客户。模型会使用对比的方法，分析历史上曾经参加过类似活动的客户与没有参加过类似活动的客户，进而建立一个评分的算法，计算出每个客户参加本次促销活动的概率。

在构建这个模型时，从数据库中抽取数据进行外部处理，这是可行的，因为这是一次性的行为，而且只涉及到部分抽样客户。当使用这个模型时，评分算法要对零售商的所有客户进行打分，这样才能精确识别那些最有可能响应促销活动的客户，这可能会涉及成千上万的客户。此外，这个评分过程通常还需要定期执行。在这种情况下，由于涉及所有的客户数据，把数据从数据库中抽取出来可能导致系统崩溃，而库内分析则可以避免这种现象的出现。

今天在数据准备与评估模型过程中，把处理过程提交给数据库执行的方法至少有4种：（1）直接提交SQL；（2）自定义函数（UDF）；（3）嵌入式过程；（4）预测建模标记语言（PMML），接下来我们将逐个进行阐述。

1．直接提交SQL

SQL是MPP系统的母语，在各种要求与场景下都有很高的执行效率。在前面我们讨论过，SQL特别适合进行各种典型的数据操作，如关联、转换、整合等。很多核心的数据处理任务都可以通过编写SQL脚本来直接实现，用户也可以使用各种分析软件，让软件自动生成SQL脚本并提交给数据库执行。常用的分析模型与算法，其评分逻辑都不是很复杂，可以很容易地转换成SQL，如线性回归模型、逻辑回归模型、决策树模型等。分析工具可以帮助用户从这些分析模型中抽取出数据处理逻辑与过程，并将其转换为SQL。或者，有些时候，模型完成后用户也可以选择自己编写SQL。但不管是哪种情况，数据准备或评分过程都是全部通过SQL完成的。

2．自定义函数（UDF）

自定义函数（User-Defined Function，UDF）是关系型数据库的一个相关的新特性。UDF的处理能力大大超越了普通的SQL。UDF可以让用户自定义一些可以重复使用的数据处理逻辑，并像SQL自带函数一样自由地使用。

例如，要查询客户的销售总额，分析专家可能会写这样的SQL：

“Select Customer, Sum(sales) …”

如果要查询客户某一项属性的评分，使用UDF的SQL可能会是这样：

“Select Customer, Attrition_Score…”

在这个SQL语句里，“Attrition_Score”是一个已经被部署在关系型数据库内的自定义函数。这个函数可以在任何时候被使用，其内部包含比纯SQL更复杂的处理逻辑。

UDF通常使用C++或Java等编程语言进行开发。使用这些编程语言，使得编程语言的某些特性嵌入了SQL中，这让SQL获得了一些新的功能，而这些功能通过SQL往往是无法实现的。UDF的一个缺陷是，不少分析专家并不了解如何使用这些编程语言开发UDF，但幸运的是，很多分析工具都已经提供了自动生成这些函数的功能。这些分析工具可以帮助分析师生成合适的UDF，并将它部署在数据库里，分析师可以直接使用这些自定义函数。

3．嵌入式过程

嵌入式过程（Embedded Process）是另一种把处理任务提交给数据库执行的方法。嵌入式过程的集成程度要比刚才提到的自定义函数高得多。自定义函数是编写一段程序，并将其部署在数据库内，让其他的SQL语句能够随意地调用它。对使用者来说，这个分析函数与其他分析工具提供的原始代码没有什么不同，都可以在数据库中并发地调用。区别在于，分析工具提供的原始代码通常不得不转换为数据库语言，以提高在数据库内的处理效率。

对于嵌入式过程，情况就完全不一样了。嵌入式过程是将分析工具的处理引擎直接运行在数据库中。嵌入式过程具备在数据库内直接运行程序的能力。嵌入式过程充分利用了那些已经被部署在数据库内的分析程序。当需要运行某一段分析程序时，为了利用数据库的并行处理能力，嵌入式过程会把分析程序运行在数据库的每一个处理单元上。嵌入式过程不需要转换脚本语言，只需要修改很少的内部代码，但部署嵌入式过程会比较困难。各个分析软件与数据库供应商们已经开始广泛地研究并应用嵌入式过程。在不久的将来，嵌入式过程将成为一种可选的处理方法。

4．预测建模标记语言（PMML）

预测建模标记语言（Predictive Modeling Markup Language，PMML），可以把模型结果从一个分析工具导入另外一个工具中。从概念上讲，PMML包集成了预测模型进行准确预测所必需的各种信息，与模型无关的信息则不包含在内。一个PMML包的内部信息通常包括模型类型、变量名称、变量格式以及必要的参数值。^〔1〕分析师可以使用任何兼容PMML的分析工具开发分析模型，当模型开发完成后，如果要把这个模型部署到另外一个兼容PMML的工具内，那么分析师只需把PMML文件直接导入新的工具，新工具内的评分模型就可以使用了。

PMML有一个不那么明显的缺点。要使用PMML在新的工具和环境下部署分析模型，前提条件是这个新环境内的变量名称和数据格式，必须和开发模型的原始环境中相应的名称和格式完全保持一致。例如，开发某一个模型时，某一个输入变量叫做“SumOfSales”，代表客户在某一段时间内的消费总额，格式是数值类型。那么，使用PMML在新的环境下部署这个模型时，就要确保在新的环境下也有“SumOfSales”这个变量，并且名称、含义、格式都完全相同。这意味着人们不得不在新系统里再次创建这个变量。

最初，很多分析专家认为，在开发模型时使用PMML，意味着他们不需要去考虑库内处理的问题。他们认为，使用分析工具开发好了模型，利用PMML就可以轻松地把模型部署到关系型数据库内了。这种想法是错误的，PMML要求不同环境下的数据变量完全一致，但事实上这不太可能出现。因此，在利用PMML部署模型前，如果分析师在数据库之外对数据进行了一些处理和转换，那么这些操作必须在数据库内完整地重复执行一遍。PMML并不负责任何数据准备的工作，它只是把同样的算法直接应用于最终数据，而PMML假定这些数据都已经被处理过了。

不要错误地理解PMML

PMML的确强化了在数据库内进行数据准备的必要性与好处。如果分析工具在数据库外部进行了任何形式的数据处理，这些过程必须在数据库内重复执行一遍，以确保PMML能正常工作。为什么要在2个环境中重复地执行数据处理过程呢？还是直接在数据库里执行吧。

PMML确实强化了库内处理的必要性。为了确保PMML高效地工作，建模所需的输入数据必须提前准备好。这些数据不能有任何变化，分析算法必须能够直接使用。只有这样，PMML生成的模型评分代码才能立刻开始工作，否则就需要在部署环境下进行数据的重新组织与二次处理。

新版的PMML已经开始具备部分特定的数据处理能力，但要彻底弥补我们提到的这个缺陷，PMML还有很长的路要走，这也限制了PMML的应用范围。

4.3.2　使用MPP系统进行数据准备与评分小结

海量并行处理平台（MPP）是当代数据分析架构中价值很高且越来越重要的一种方法。今天，大部分大型企业都已经建立了企业级的数据仓库，对企业内大量的重要数据进行集中管理，而小型企业则通常选择建立各种数据集市。越来越多的数据处理过程将在数据仓库内进行，这种趋势将会长期地持续下去。

任何希望提高自身分析能力的公司，都必须了解并使用MPP。在数据规模持续增长的今天，为了进行某项分析，除非完全不可避免，我们都不应该把数据从仓库中抽取出来。使用MPP可以给企业带来分析可扩展性的额外提升，扩大可分析数据的广度与规模。不管是传统数据、大数据还是这两类数据的混合体，均可以使用这种处理方法。

在我们结束这一小节前，还要讨论最后一个主题。当企业级数据仓库已经成为分析环境的核心主题时，许多MPP系统供应商也开始提供比数据仓库性能略低的“一体机平台”系统。这些一体机平台系统是为某一些特定目的而设计的，例如，高级分析团队希望对海量数据进行复杂的处理。区别在于，企业级数据仓库能支持许多不同类型的数据管理工作，而这些一体机平台只能支持某一种或特定的几种数据管理工作。

高级分析也是分析系统承担的一项工作，而且是很重要的一项工作。当计划使用企业级数据仓库支持高级分析时，要确保数据仓库也能同时完成其承担的其他工作，如报表或查询等，通常所有这些工作都在数据仓库中同时进行。如果数据仓库实现不了，可以考虑部署独立的一体机平台系统。这些独立的一体机平台系统的价格是可以接受的，并且遵循与MPP架构一样的设计原则。