pmml_再访PMML

pmml

嗨伙计！从今年年初开始，就有了重新设计Drools PMML模块的计划。

在这篇文章中，我将描述我们将如何处理它，目前的状态，未来发展的想法等，等等……敬请期待！

背景

PMML是一个标准，旨在“ 为分析应用提供一种描述和交换由数据挖掘和机器学习算法产生的预测模型的方法。 ” PMML标准定义了一系列受管理的模型，我们将其称为“模型”。

换句话说，这可能不是那么明显的结果是，PMML可以被认为是不同预测模型的协调器 ，每个预测模型都有不同的要求。 Drools有其自己的PMML实现。它的原始设计是基于100％流口水引擎的，但是从长远来看，这对所有模型都不令人满意，因此决定采用不同的方法来实现新版本。现在，这里的故事开始了……

要求

简而言之，PMML实现应允许：

加载PMML文件（xml格式）
提交输入数据
返回预测值

听起来很简单，不是吗？

方法

拟议的体系结构旨在遵循“清洁体系结构”原则以模块化方式满足要求。

为了实现这一点，定义了清晰的边界和可见性的组件。总体思路是，存在与核心功能严格相关的特定任务，而其他“外部”功能则应保持不可知。任何想深入研究此问题的人都可以阅读RC Martin撰写的“ Clean Architecture”一书，但从本质上讲，将good-ol的设计原则应用于整个体系结构只是一个问题。明确定义此目标后，实现该目标所需的步骤为：

识别核心逻辑和实施细节（特定于模型）
在“独立”模块中实现核心逻辑
为特定于模型的模块编写代码

我们选择实现插件模式以将核心逻辑绑定到特定于模型的实现，主要有两个原因：

增量开发和整体代码管理：核心模块本身不依赖于任何特定于模型的实现，因此可以增量地提供/更新/替换后者，而不会对核心产生任何影响
可以用自定义的实现替换提供的实现
我们还预见到了可能会根据原始PMML结构在运行时选择实现的可能性（例如，根据给定PMML的大小使用其他实现可能是有意义的）

（我作弊：那是三个）

这是原始PMML模型的Kie表示形式的定义。
对于每个实际模型，都有特定的实现，并且可以是任何类型的对象（java映射，drools规则等）。

我们可以避免吗？也许。我们可以使用由规范的xsd直接生成的模型。但这是为了描述所有预测模型而设计的，尽管它们中的任何一个都可能以不同的方式和不同的约定使用它。因此，此内部视图将准确表示每个特定模型所需的内容。

组件

我们确定了以下主要功能组件：

编译器
组装工
执行者

编译器

该组件读取原始PMML文件并将其翻译为我们的内部格式。

它的核心方面只是将xml数据解组到Java对象中。然后，它使用Java SPI检索特定于给定PMML模型的模型编译器（如果找不到模型编译器，则将PMML忽略）。

最后，检索到的模型编译器会将原始PMML模型“转换”为我们特定于模型的表示形式（ KiePMMLModels ）。

该组件的核心部分不直接依赖于任何特定的Model Compiler实现 ，甚至不依赖于任何Drools / Kie –因此，它基本上是一个轻量级/独立的库。如果该组件的执行不是很费时，则可以在运行时 （即，在客户项目的执行期间）或在kjar的编译期间（例如，对于流口水实现的模型）调用该组件。

组装工

由编译器内KIE知识库创建该组件存储KiePMMLModels。 其他组件都不应该对此组件有任何依赖性/知识。

反过来，它必须对实际没有任何依赖性/知识/引用 模型编译器实现。

该组件负责PMML模型的实际执行。它接收PMML输入数据，检索特定于输入数据的KiePMMLModel并计算输出。

对于每个模型，都有一个特定的“执行器”，以根据模型类型允许不同类型的执行实现（drool，外部库等）。它的核心端仅接收输入数据并检索特定于给定PMML模型的模型执行器（如果找不到，则将忽略PMML）。最后，检索到的模型执行者将基于输入数据评估预测。该组件的核心部分不直接依赖于任何特定的Model Executor实现，但是当然严格依赖于Drool运行时。

模型实施

基于Drools的模型

一些模型将委托给drools引擎，以在重载下实现最佳性能。以下是有关此类实现的一般方案的一些详细信息。

编译器在生成kjar时（或在运行时热加载PMML文件时）被调用
编译器读取PMML文件并将其转换为“ descr”对象（请参见BaseDescr ， DescrFactory ， DescrBuilderTest ）
不管如何调用模型编译 器，都必须在调用drools编译器后立即对其进行调用，以使基于descr对象生成Java类
汇编器将生成的类放在kie base中
执行程序加载生成的“ drools模型”，并使用输入参数调用它

DRL详细信息

对于DataDictionary中的每个字段，必须定义一个特定的DataType
对于树的每个分支/叶子，必须生成全路径规则（即具有到达路径的规则-例如，“晴天”，“晴天温度”，“晴天温度湿度”）
创建了一个“状态持有者”对象，该对象包含已触发规则的值–更改该值将触发与之匹配的子分支/叶规则（例如，规则“ sunny”将触发“ sunny_temperature”，而后者又将触发） “ sunny_temperature_humidity”）
此类“状态持有人” 可能包含评估的信息/部分结果，最终将在需要结果组合的地方使用
价值缺失策略可以在身份持有者内部实施，也可以作为爆炸规则

测试中

对于每个模型，都会有一组标准的单元测试，以主要验证各个代码单元。除此之外，在特定于模型的模块内（是的，它是绕口令），将有一个集成测试子模块。后者将验证不同或多或少复杂的PMML文件的整体正确执行，以尽可能模拟实际场景中可能发生的情况。

回归

回归模型是第一个实现的模型。由于其固有的简单性，我们选择为其提供纯基于Java的实现。目前，它仍处于PR之下，并且正在添加新的完整测试。

树

在评估了所有优点/缺点之后，我们认为该模型可以作为采用基于流口水的方法来实施的很好的候选者。作为一个易于遵循的简单模型，我们选择将其用作流口水方法的第一个测试。

待办事项

这是尚未实现的，与特定模型没有严格关联的缺失功能的列表。在开发过程中将对其进行更新：

设置基准框架项目（请参阅Drools基准）
管理扩展标签（请参阅xsdElement_Extension ）
管理SimpleSetPredicate标记（请参阅SimpleSetPredicate ）
在细分中实现VariableWeight （动态替代静态“权重”值）

不用说，任何评论（尤其是好的评论）和建议将不胜感激。

接下来的几天再回来看看下一步！

再见！

翻译自: https://www.javacodegeeks.com/2020/02/pmml-revisited.html