Microsoft的一组专家撰写的一篇引人入胜的愿景论文“多云DBMS的机会很大”，着眼于机器学习从主要是大规模，大批量消费应用程序的领域到其成为不可或缺的一部分的过渡 日常企业应用程序。
当要在企业应用程序中利用ML时，尤其是在受监管的环境中，数据处理，模型公平性，用户隐私和可调试性的审查级别将大大高于第一波ML应用程序中的级别。
在本文中，这种新兴的应用程序类别称为EGML应用程序：企业级机器学习。 而且会有很多！
每个行业的企业都在制定战略，以数字方式转变其各个层面的业务。核心思想是持续监控业务的各个方面，使用高级数据分析（包括ML）积极解释观察结果，并将学习成果整合到可以改善业务成果的适当行动中。我们预测，在未来十年中，成千上万的小型团队将构建数百万个注入ML的应用程序-大多数只是中等程度的重复性，但具有巨大的集体价值。
EGML要求
他们之间有“在生产环境中使用机器学习技术的丰富经验”。导致的关键见解是ML模型是从数据派生的软件。机器学习系统结合了软件的特性，例如对CI / CD管道和数据的需求，例如需要追踪血统。模型开发本身通常不代表大多数项目的20％。
与ML的Web规模平台使用相比，企业应用程序往往是由具有更深的领域专业知识，却没有更深的算法或系统专业知识的较小的团队构建的。在企业环境中，尤其是在受监管的领域中，平台要求在审核，安全性，隐私，公平性和偏见方面趋于更加严格。许多软件工程学科和控制需要被带入ML上下文。
（EG）ML的典型应用程序是由规模较小，经验不足的团队构建的，但它们有更严格的要求。
对GitHub上的项目的分析表明，那里有大量的ML软件包，但也有一些领导者出现。因此，旨在支持EGML的系统需要提供广泛的覆盖范围，但是可以优化一组ML软件包。
在功能集方面，我们可以借鉴领先的机器学习公司的经验作为指导。 下表细分了六个系统中三个主要领域的功能：培训和审计，服务和部署以及数据管理。
据此，作者得出两个结论：
成熟的专有解决方案为数据管理提供了更强大的支持，并且
提供完整且可用的第三方解决方案并非易事（否则云供应商已经做到了）。
最后，对机器学习研究方向的分析揭示了以下时间变化：培训系统，评分系统，AutoML，然后是负责任的AI。
最近，对偏见，公平和负责任地使用机器学习的兴趣激增，尽管仅存在有限的解决方案……我们得出结论，数据平台在实现快速可靠的培训和评分中起着关键作用，而明确的元数据管理和出处跟踪是基础适用于负责任的AI和AutoML解决方案。
三大赌注
退一步，EGML系统需要三个主要领域的支持：模型开发/培训，模型评分（推理）和模型管理/治理。也许隐含在模型开发/培训中，但是我认为值得一提的一个重要方面是培训数据本身的管理和管理，正如我们上次查看Software 2.0时所看到的那样。
这是与作者引用的三个主要领域一致的三大方向性押注：
我们将在云中进行培训，在这种情况下，可以充分利用托管基础架构来适应大量数据，尖峰资源使用以及对最新硬件的访问。
推理（评分）引擎将被部署到任何地方，并且ML评分将被深度集成到DBMS中，“作为关系代数的基础扩展，并且是SQL查询优化器和运行时的组成部分”。
治理将无处不在，“数据库社区迫切需要在安全数据访问，版本管理以及出处跟踪和治理方面加强工作。”
在云中进行培训以及对更好的治理的需求都是毫无争议的方向。但是，将模型推理迁移到DBMS是一个大胆的预测。从观察中可以看出，DBMS是要求安全性，细粒度访问控制，审计，高可用性等高价值数据的自然存储库。如果那是数据存在的地方，那么随之而来的就是我们也要进行评分的地方。我们之前看过“在RDBMS上进行声明式递归计算”，它也建议在此处进行培训！
Flock
Flock是Microsoft的参考架构，旨在探索这些想法。
Flock将ML模型视为从数据中获取的软件工件。
将ML视为软件，我们希望ML和软件工程社区向我们提供自动化，工具和工程最佳实践– ML将成为DevOps生命周期的组成部分。将ML模型视为派生数据，数据库界必须解决数据发现，访问控制和数据共享，管理，验证，版本控制和出处的问题。
模型本身必须经过严格审查，其存储和查询/评分的安全性和可审计性。出于一致性原因，在更复杂的应用程序中，可能需要对模型（以及跨多个模型）进行事务性更新。这是支持数据库内评分的另一个论点。一个不错的副作用是，数据库中的评分也可以很快：早期的实验表明，数据库中模型评分可以比独立的最新方法快5到24倍。
DBMS中的推论
模型仅在用于推理，创造见解和做出决策的范围内具有价值。
EGML应用程序可能会使用多个模型，并且您可以像对待数据流中的处理步骤一样思考每个模型。因此，可能需要自动更新模型的组合。在DBMS中将模型视为一流的数据类型，可以将数据库事务用于模型更新。然后，可以将DBMS内部的通用模型类型进行推理，而无需任何外部调用，这可以作为关系查询处理的扩展。从处理的角度来看，模型有点像过程，因为它需要大量输入，执行计算并产生输出。因此，类似于存储过程，我们将调用存储在数据库存储模型中的模型吗？我们会比存储过程更喜欢它们吗？
Microsoft通过在SQL Server中集成ONNX运行时来进行DBMBS内推。实验的结果在第二篇CIDR’20论文中进行了报道：“用ML推理扩展关系查询处理”
模型的输出只是业务流程中下一阶段的输入。我看不出为什么对业务流程阶段的输入恰好来自模型这一事实有什么特别之处，但是作者认为需要一种新型的策略模块，以帮助将模型预测转化为策略模块在模型输出之上应用业务约束，连续监视ML模型的输出，并在对应用程序域采取任何操作之前应用指定的策略。
数据管理
作者在GitHub上分析了超过400万个Jyputer notebooks，发现令他们惊讶的是，实际上只有很少几个人真正使用了数据库访问库。我可以从个人经验中确认，有一些在数据科学和机器学习领域有悠久历史的高水平从业者，他们仅具备SQL的基本知识。当一分钱下降时，我也感到惊讶。这些笔记本用什么代替？从平面文件加载的Pandas DataFrames。
这种最先进的技术令人非常不满意：几乎没有数据发现支持……更糟的是，在此范式中数据版本化很大程度上未得到解决……更根本地讲，文件不是训练数据的基本单位。因此，我们认为对可查询的数据抽象，沿袭跟踪和存储技术的开放需求可以涵盖异构，版本化和持久性数据。
DBMS为此提供了一个很好的起点，但是只要您有一些数据管理，并不是所有的数据管理都必须存在。
数据版本控制是基础，之后就需要跨管道跟踪源信息以了解生成的模型及其预测。在“羊群”中，可通过三个主要模块来捕获来源：
- 基于Apache Atlas的目录用于存储出处信息SQL来源模块从SQL查询（影响输出的输入表和列，连接建模为图形）中捕获粗粒度的来源信息。 它基于Apache Calcite构建。
- Python来源模块通过“标准静态分析技术和我们维护的ML API知识库”的组合来解析python脚本并识别与特征提取和模型训练相对应的代码行。
- 通过将SQL Provenance模块的输出连接到Python Provenance模块，可以端到端地跟踪模型沿袭。
若有收获，就点个赞吧
0 人点赞
