独家 | 攀登数据科学家和数据工程师之间的隔墙
- 2020 年 4 月 7 日
- 筆記
作者：Byron Allen
翻译：陈丹
校对：吴振东
本文约2400字，建议阅读10分钟
本文为大家介绍了数据科学家和数据工程师之间的鸿沟，并提供了Production ML作为解决方案。
标签：机器学习
机器学习的教育和研究重点往往集中在数据科学过程的模型构建、训练、测试和优化等方面。要使这些模型投入使用，需要一套工程专长和组织结构，对于其中的标准尚不存在。有一个架构可以指导数据科学和工程团队相互协作，从而将机器学习模型部署到终端用户，这篇文章能让你了解更多关于这一方面的信息。
来源：Chris Conzales。
今天机器学习中最令人兴奋的事情之一，并不是深入学习或强化学习的前沿，至少我是这样认为。相反，更多有意思的事情是如何管理模型，以及数据科学家和数据工程师如何像一支团队般高效协作。朝这些方向前行可以引导组织更有效、可持续地应用机器学习。
可悲的是，“科学家”和“工程师”之间有一道鸿沟，可以说是一堵墙。Databricks的联合创始人兼产品副总裁Andy Konwinski等人，指出了近日一篇关于MLFlow的博客文章中存在一些关键障碍。Databricks说：“构建生产性机器学习应用程序具有挑战性，是因为没有标准的方法来记录实验、确保可重复运行以及管理和部署模型。”。
当今应用机器学习的许多主要挑战（无论是技术上的、商业上的还是社会上的）的起因，是随着时间的推移，数据与机器学习部件的管理以及利用之间存在不平衡。一个模型可以表现得非常好，但是如果底层数据漂移、部件没有被用来评估性能，那么您的模型将无法很好地概括总结，也无法适当地更新。这个问题属于一个与数据科学家和工程师都相关的灰色地带。
来源：burak kostak
换言之，问题的症结在于机器学习中缺少CI/CD的主体。如果您的环境发生了变化（如输入数据），并且模型没有在其构建目的的上下文中定期进行评估，从而导致模型随着时间的推移而失去相关性和价值，那么您是否能够创建一个真正好的“黑盒”模型并不重要。这是一个很难解决的问题，因为提供数据的人——工程师，以及设计模型的人——科学家，双方没有形成最令人愉快的组合。
这一挑战有一些具体的例子。想想有多少机器学习的笨蛋预言希拉里·克林顿将在大选中获胜。从自动驾驶汽车杀死无辜的行人，到有偏见的人工智能系统，都有一些重大的失误，我认为这些失误通常起因于数据科学和工程之间的灰色地带。
来源：Kayla Velasquez
也就是说，无论是消极的还是积极的，机器学习都会影响到我们的社会。举一个更积极、更少商业化的例子，比如说electricity map使用机器学习来绘制全世界电力对环境的影响图；机器学习在癌症研究中目前正帮助我们更早、更准确地发现几种癌症类型；人工智能驱动的传感器为农业赋能，以满足全球粮食需求的飙升。
两者之间的隔墙
考虑到这一点，获得机器学习的成果，更具体点，模型管理是至关重要的。然而，回到正题，数据科学家和数据工程师并不总是能互相理解。
对于一个数据科学家来说，不了解他们的模型应该如何存在于一个不断吸收新数据、集成新代码、被终端用户调用、并可能不时地以各种方式（即在生产环境中）失败，这样的情况并不少见。另一方面，许多数据工程师对机器学习的理解不够，不足以使他们明白投入生产的内容以及对组织的影响是什么。。
尽管这两个角色占据了同一空间，但他们在操作时往往没有足够地考虑对方的那一方面。“那不是我的工作”不是正确的方法。要生产出可靠、可持续和适应性强的产品，这两个角色必须更有效地协同工作。
攀墙
理解对方的第一步是建立一个共同的词汇表——对语义学进行某种标准化，并因此讨论挑战或者说是相切合的挑战是怎样的。当然，其中充满挑战——只要问几个不同的人什么是数据湖，如果你得到的不是多个答案的话，至少也会得到是两个不同的答案。
我开发了共同的参考点，称之为ProductionML价值链和ProductionML框架。
我们将生产性机器学习的过程分解为五个重叠的概念，这些概念常常被单独考虑。虽然引入这样一个整体框架似乎会增加复杂性和相互依赖性——实际上，这些复杂性和相互依赖性已经存在——如果忽略它们的话只会把问题推到最后。
通过在生产性机器学习管道的设计中考虑相邻的概念，您将开始引入难以捉摸的可靠性、可持续性和适应性。
ProductionML 框架
ProductionML价值链是对操作数据科学和工程团队所需内容的高级描述，目的是将模型部署到终端用户。自然会有更为技术性和详细的理解——我称之为ProductionML框架（有些人可能称之为连续智能）。
ProductionML 框架
这个框架是在商业性MLOps工具、开源选项和内部PoC开发的几轮实验之后开发的。它旨在指导production ML项目的未来开发，特别是ProductionML中需要数据科学家和工程师输入的方面。
数据科学是橙色的，数据工程/DevOps是蓝色的。
如果您不熟悉这些方面，请参阅橙色标记的数据科学和蓝色标记的数据工程/DevOps。
如您所见，“训练性能跟踪”机制（例如，MLFlow）和管理机制位于该体系结构的中心。这是因为每个部件，包括度量、参数和图形，都必须在培训和测试阶段存档。此外，所谓的模型管理从根本上与利用这些部件的模型管理方式有关。
管理机制将部件和业务规则结合起来，提升优化合适的模型（或更确切地说，是估计器）以适应生产，同时根据用例特定的规则来标记其他模型。这也称为模型版本控制，但术语“管理”用于避免与版本控制混淆，并强调该机制在监督模型管理中的中心作用。
黄金枪？
我们都一起前行。我们都在努力攀登这堵墙。有很多很棒的工具进入市场，但迄今为止，没有人有一把黄金枪…
来源：Mrgarethm-Golden Gun-国际间谍博物馆。
在我看来，MLFlow迈出了巨大的一步，它回答了关于模型管理和工件归档的某些问题。其他产品同样解决了相对特定的问题——尽管它们的优势可能在ProductionML价值链的其他部分。这些可以在Google Cloud ML引擎和AWS Sagemaker中看到。最近，GCP提供了AutoML Tables beta的beta版本，但即使如此，尽管它确实更接近了，但它也不能提供所需的所有现成的东西。
考虑到这种持续的差异，在科学家和工程师之间建立一个共同的词汇和框架是至关重要的。
这堵墙太高了吗？根据我的经验，答案是否定的，但这并不是说ProductionML不复杂。
詹姆斯·邦德：
M：所以如果我没听错的话，斯卡拉曼加逃走了——坐在一辆长出翅膀的车里！
Q：哦，那完全可行，先生。事实上，我们现在正在制造一辆。
也许你应该这样翻过那堵墙…
原文标题：
Scaling the Wall Between Data Scientist and Data Engineer
原文链接：
https://www.kdnuggets.com/2020/02/scaling-wall-data-scientist-data-engineer.html
编辑：于腾凯
校对：洪舒越
译者简介
陈丹，复旦大学大三在读，主修预防医学，辅修数据科学。对数据分析充满兴趣，但初入这一领域，还有很多很多需要努力进步的空间。希望今后能在翻译组进行相关工作的过程中拓展文献阅读量，学习到更多的前沿知识，同时认识更多有共同志趣的小伙伴！
