1700432170
1700432171
让我们看一个更细节的例子。假如某一个零售商已经建立了一个倾向模型，来评估哪些客户更有可能参加某一次促销活动。这个模型通常是建立在抽样的客户数据上，可能只覆盖了几百名或者几千名客户。模型会使用对比的方法，分析历史上曾经参加过类似活动的客户与没有参加过类似活动的客户，进而建立一个评分的算法，计算出每个客户参加本次促销活动的概率。
1700432172
1700432173
在构建这个模型时，从数据库中抽取数据进行外部处理，这是可行的，因为这是一次性的行为，而且只涉及到部分抽样客户。当使用这个模型时，评分算法要对零售商的所有客户进行打分，这样才能精确识别那些最有可能响应促销活动的客户，这可能会涉及成千上万的客户。此外，这个评分过程通常还需要定期执行。在这种情况下，由于涉及所有的客户数据，把数据从数据库中抽取出来可能导致系统崩溃，而库内分析则可以避免这种现象的出现。
1700432174
1700432175
今天在数据准备与评估模型过程中，把处理过程提交给数据库执行的方法至少有4种：（1）直接提交SQL；（2）自定义函数（UDF）；（3）嵌入式过程；（4）预测建模标记语言（PMML），接下来我们将逐个进行阐述。
1700432176
1700432177
1．直接提交SQL
1700432178
1700432179
SQL是MPP系统的母语，在各种要求与场景下都有很高的执行效率。在前面我们讨论过，SQL特别适合进行各种典型的数据操作，如关联、转换、整合等。很多核心的数据处理任务都可以通过编写SQL脚本来直接实现，用户也可以使用各种分析软件，让软件自动生成SQL脚本并提交给数据库执行。常用的分析模型与算法，其评分逻辑都不是很复杂，可以很容易地转换成SQL，如线性回归模型、逻辑回归模型、决策树模型等。分析工具可以帮助用户从这些分析模型中抽取出数据处理逻辑与过程，并将其转换为SQL。或者，有些时候，模型完成后用户也可以选择自己编写SQL。但不管是哪种情况，数据准备或评分过程都是全部通过SQL完成的。
1700432180
1700432181
2．自定义函数（UDF）
1700432182
1700432183
自定义函数（User-Defined Function，UDF）是关系型数据库的一个相关的新特性。UDF的处理能力大大超越了普通的SQL。UDF可以让用户自定义一些可以重复使用的数据处理逻辑，并像SQL自带函数一样自由地使用。
1700432184
1700432185
例如，要查询客户的销售总额，分析专家可能会写这样的SQL：
1700432186
1700432187
“Select Customer, Sum(sales) …”
1700432188
1700432189
如果要查询客户某一项属性的评分，使用UDF的SQL可能会是这样：
1700432190
1700432191
“Select Customer, Attrition_Score…”
1700432192
1700432193
在这个SQL语句里，“Attrition_Score”是一个已经被部署在关系型数据库内的自定义函数。这个函数可以在任何时候被使用，其内部包含比纯SQL更复杂的处理逻辑。
1700432194
1700432195
UDF通常使用C++或Java等编程语言进行开发。使用这些编程语言，使得编程语言的某些特性嵌入了SQL中，这让SQL获得了一些新的功能，而这些功能通过SQL往往是无法实现的。UDF的一个缺陷是，不少分析专家并不了解如何使用这些编程语言开发UDF，但幸运的是，很多分析工具都已经提供了自动生成这些函数的功能。这些分析工具可以帮助分析师生成合适的UDF，并将它部署在数据库里，分析师可以直接使用这些自定义函数。
1700432196
1700432197
3．嵌入式过程
1700432198
1700432199
嵌入式过程（Embedded Process）是另一种把处理任务提交给数据库执行的方法。嵌入式过程的集成程度要比刚才提到的自定义函数高得多。自定义函数是编写一段程序，并将其部署在数据库内，让其他的SQL语句能够随意地调用它。对使用者来说，这个分析函数与其他分析工具提供的原始代码没有什么不同，都可以在数据库中并发地调用。区别在于，分析工具提供的原始代码通常不得不转换为数据库语言，以提高在数据库内的处理效率。
1700432200
1700432201
对于嵌入式过程，情况就完全不一样了。嵌入式过程是将分析工具的处理引擎直接运行在数据库中。嵌入式过程具备在数据库内直接运行程序的能力。嵌入式过程充分利用了那些已经被部署在数据库内的分析程序。当需要运行某一段分析程序时，为了利用数据库的并行处理能力，嵌入式过程会把分析程序运行在数据库的每一个处理单元上。嵌入式过程不需要转换脚本语言，只需要修改很少的内部代码，但部署嵌入式过程会比较困难。各个分析软件与数据库供应商们已经开始广泛地研究并应用嵌入式过程。在不久的将来，嵌入式过程将成为一种可选的处理方法。
1700432202
1700432203
4．预测建模标记语言（PMML）
1700432204
1700432205
预测建模标记语言（Predictive Modeling Markup Language，PMML），可以把模型结果从一个分析工具导入另外一个工具中。从概念上讲，PMML包集成了预测模型进行准确预测所必需的各种信息，与模型无关的信息则不包含在内。一个PMML包的内部信息通常包括模型类型、变量名称、变量格式以及必要的参数值。〔1〕分析师可以使用任何兼容PMML的分析工具开发分析模型，当模型开发完成后，如果要把这个模型部署到另外一个兼容PMML的工具内，那么分析师只需把PMML文件直接导入新的工具，新工具内的评分模型就可以使用了。
1700432206
1700432207
PMML有一个不那么明显的缺点。要使用PMML在新的工具和环境下部署分析模型，前提条件是这个新环境内的变量名称和数据格式，必须和开发模型的原始环境中相应的名称和格式完全保持一致。例如，开发某一个模型时，某一个输入变量叫做“SumOfSales”，代表客户在某一段时间内的消费总额，格式是数值类型。那么，使用PMML在新的环境下部署这个模型时，就要确保在新的环境下也有“SumOfSales”这个变量，并且名称、含义、格式都完全相同。这意味着人们不得不在新系统里再次创建这个变量。
1700432208
1700432209
最初，很多分析专家认为，在开发模型时使用PMML，意味着他们不需要去考虑库内处理的问题。他们认为，使用分析工具开发好了模型，利用PMML就可以轻松地把模型部署到关系型数据库内了。这种想法是错误的，PMML要求不同环境下的数据变量完全一致，但事实上这不太可能出现。因此，在利用PMML部署模型前，如果分析师在数据库之外对数据进行了一些处理和转换，那么这些操作必须在数据库内完整地重复执行一遍。PMML并不负责任何数据准备的工作，它只是把同样的算法直接应用于最终数据，而PMML假定这些数据都已经被处理过了。
1700432210
1700432211
不要错误地理解PMML
1700432212
1700432213
PMML的确强化了在数据库内进行数据准备的必要性与好处。如果分析工具在数据库外部进行了任何形式的数据处理，这些过程必须在数据库内重复执行一遍，以确保PMML能正常工作。为什么要在2个环境中重复地执行数据处理过程呢？还是直接在数据库里执行吧。
1700432214
1700432215
PMML确实强化了库内处理的必要性。为了确保PMML高效地工作，建模所需的输入数据必须提前准备好。这些数据不能有任何变化，分析算法必须能够直接使用。只有这样，PMML生成的模型评分代码才能立刻开始工作，否则就需要在部署环境下进行数据的重新组织与二次处理。
1700432216
1700432217
新版的PMML已经开始具备部分特定的数据处理能力，但要彻底弥补我们提到的这个缺陷，PMML还有很长的路要走，这也限制了PMML的应用范围。
1700432218
[
上一页 ]
[ :1.70043217e+09 ]
[
下一页 ]