我们在两种模式:构建人工智能软件实验和随笔。在实验中,我们想看到的如果现代技术会解决我们的问题。如果是这样,我们继续大规模随笔和构建可靠的数据管道。

这提出了一个周期性依赖时数据工程。我们需要可靠的和可维护的数据工程管道在实验过程中,但不知道什么管道应做之前我们已经完成了实验。过去,我和许多我知道的科学家们使用了一个数据特别的bash脚本和Jupyter笔记本争论实验数据。虽然这可能是最快的方法实验结果和模型构建,这真是一个技术债务需要支付。

这个问题

具体来说,实验数据管道导致疼痛的特别方法分:

• 再现性:特别的实验结构使你处于危险的结果,其他人不能繁殖,从而导致产品停机时间如果或当你需要更新你的方法。简单的错误执行一个笔记本电池的两倍或忘记种子一个随机数发生器通常可以抓住。但其他更阴险的问题发生,如行为依赖版本之间的变化。
• 可读性:如果你曾经遇到另一个人的实验代码,你知道很难找到从哪里开始。甚至记录项目可能会说“脚本运行x, y笔记本等”,这是经常不清楚的数据从何而来,如果你在正确的轨道上。同样,代码评审数据科学项目通常是难以阅读:它要求很多读者区分笔记本数据操作的代码和代码可视化。
• 可维护性:这是常见的在科学项目做一些探索性数据分析或生成初步结果,然后修改你的数据处理或聚集。这变得困难和乏味当所有这些步骤都是一个非结构化的笔记本或脚本。换句话说,管道是很难维持:更新或改变它需要你跟踪整个事情。
• Shareability:特别的笔记本一个团队和bash脚本也难以同时工作。每个成员必须确保他们的笔记本电脑是最新的笔记本并不理想(版本控制),和他们有正确的任何中间数据的副本。

进入Kedro

上面的很多问题不是新软件工程学科和很大程度上解决了空间。这就是Kedro出现的原因。Kedro是一个框架,用于构建数据工程管道的结构迫使你遵循好的软件工程实践。通过使用Kedro实验阶段的项目,我们构建可维护和可再生的数据管道产生一致的实验结果。

具体来说,Kedro你组织数据工程代码到一个或多个管道。每个管道由许多节点:一个功能单位,需要一些数据集和参数作为输入并生成新的数据集,模型或工件。

这个简单但严格的项目结构是增强的数据目录:YAML文件指定输入和输出数据集是如何以及在哪里被持久化。数据集可以存储在本地或在云数据存储服务如S3。

我开始使用Kedro大约六个月前,此后利用不同的实验数据管道。这些管道是用于构建模型,最终被部署到生产,和一些与团队成员合作。下面,我将讨论的好的和坏的事情我发现Kedro以及它如何帮助我们创建可再生的、可维护的数据管道。

良好的

• 再现性:我不能说足够好的东西:他们钉。他们的依赖关系管理的习惯,但部队所有依赖项的特定版本,这是可怕的。同样,只要输入的能力kedro安装和kedro运行执行整个管道是奇妙的。你仍然要记得种子随机数生成器,但即便如此,很容易记住如果你把它放在他们的params.yml文件。
• 功能隔离:Kedro的固定项目结构鼓励你想想逻辑步骤是必要的管道,并编写单个节点的每一个步骤。因此,每个节点往往是短(行代码而言)和特定的方面(逻辑)。这使得每个节点易于编写,测试,和阅读。
• 开发并行:小节点也同时方便开发人员一起工作。很容易看到节点不会相互依赖,他们可以被不同的人同时编码。
• 中间数据Kedro:也许我最喜欢的地方是数据目录。只是添加一个输出数据集的名称catalog.yml和繁荣,它会被序列化到磁盘或您的云数据存储。这很容易建立管道:你在一个节点上工作,提交它,执行它,并保存结果。它还方便当工作在一个团队。我可以运行一个昂贵的GPU大机器上的节点,将结果保存到S3,和另一个团队成员可以从那里开始。这都是烤的。
• 代码的可重用性:我承认我从来没有重用一个笔记本。充其量我停在了一个老一提醒我如何实现一些复杂的分析,但即使这样我不得不记住复杂的数据。然而,孤立的节点可以方便地重用它们。同时,Kedro支持模块化的管道(即。,packaging a pipeline into a pip package) makes it simple to share common code. We’ve created modular pipelines for common tasks such as image processing.

坏

虽然Kedro解决了许多质量挑战实验数据管道,我们已经注意到一些问题,需要不到优雅的工作个队伍:

• 增量数据集:这个支持存在读取数据,但它写数据的缺乏。这影响了我们几次当我们有一个节点需要8 - 10小时。我们失去了工作,如果节点失败的一部分。同样,如果结果数据集不适合在内存中,没有一个很好的方式保存增量结果自作家Kedro假定所有分区都在内存中。这GitHub的问题可以修复它,如果开发人员解决这个问题,但是现在你必须自己管理部分结果。
• 管道的增长:管道很快就会难以理解,因为只是指定变量的输入和输出数据中可能或不可能存在的目录。Kedro即帮助,但这有点烦人的导航器和代码之间的切换。我们也开始执行名称节点名称及其功能之间的一致性,以及管道的数据集名称和参数名称的节点功能。最后,制造更多,规模较小的管道也是一个好方法让你的理智。尽管这些技术帮助你精神上跟踪,它仍然是你做出的权衡编码命名管道的输入和输出。
• 可视化:这不是真的认为Kedro,,是有一件事我想说笔记本还有一条腿上。Kedro使您易于负载Kedro上下文笔记本,不过,你仍然可以火一个做一些可视化。最后,虽然我很想看到更好的支持在Kedro生产图形报告被持久化到08年_reporting层。现在我们在这工作通过一个节点,它显示一个笔记本到磁盘,但这是一个黑客。我想更好地支持生成最终,高度可视化报告,可以在数据目录版本就像中间数据。

结论

所以我是个Kedro转换吗?是的,那还用说。它取代bash脚本的蜘蛛网和Python笔记本我使用用于实验数据管道和模型训练,并允许更好的我们的团队之间的协作。它不会取代完全productionalized基于流数据管道对我来说,但它绝对确保我的实验管道维护,可再生的、可共享的。