我们在两种模式下构建人工智能软件:实验和产品化。在实验过程中，我们试图看到如果现代技术将解决我们的问题。如果成功了，我们就会转向产品化，大规模地建立可靠的数据管道。

当涉及到数据工程时，这就呈现出一种周期性依赖。在实验期间，我们需要可靠和可维护的数据工程管道，但不知道什么在我们完成实验之前那条管道应该没问题。在过去，我和我认识的许多数据科学家都使用过an特别的bash脚本和Jupyter notebook的组合来整理实验数据。虽然这可能是获得实验结果和模型构建的最快方式，但这确实是一笔必须在未来偿还的技术债务。

这个问题

具体来说，实验数据管道的临时方法会导致以下问题:

• 再现性:特别的实验结构会让你面临其他人无法重现的结果的风险，如果你需要更新你的方法，这可能会导致产品停机。一些简单的错误，如两次执行一个笔记本单元格或忘记给随机数生成器播种，通常都可以被捕捉到。但是可能会出现其他更隐蔽的问题，比如依赖版本之间的行为变化。
• 可读性:如果你曾经遇到过别人的实验代码，你就会知道很难找到从哪里开始。甚至有文档记录的项目也可能只是说“运行x脚本，y笔记本等”，通常不清楚数据来自哪里，也不清楚你是否在正确的轨道上。类似地，数据科学项目的代码审查通常很难阅读:它要求读者区分用于数据操作的笔记本代码和用于可视化的代码。
• 可维护性:在数据科学项目中，做一些探索性分析或生成早期结果，然后修改处理或收集数据的方式是很常见的。当所有这些步骤都是非结构化的笔记本或脚本集合时，这就变得困难和乏味了。换句话说，管道很难维护:更新或更改它需要您跟踪整个事情。
• Shareability:对于团队来说，同时处理笔记本和bash脚本的特别集合也很困难。每个成员都必须确保他们的笔记本是最新的(笔记本的版本控制不太理想)，并且他们有任何中间数据的正确副本。

进入Kedro

上面的许多问题对于软件工程学科来说并不新鲜，并且在该领域已经得到了很大程度的解决。这就是Kedro出现的原因。Kedro是一个用于构建数据工程管道的框架，其结构迫使您遵循良好的软件工程实践。通过在项目的实验阶段使用Kedro，我们建立了可维护和可重复的数据管道，产生一致的实验结果。

具体来说，Kedro让您将数据工程代码组织成一个或多个管道．每个管道由若干节点:以一些数据集和参数作为输入并产生新的数据集、模型或工件的功能单元。

这个简单但严格的项目结构被他们的数据目录:一个YAML文件，它指定输入和输出数据集如何以及在哪里被持久化。数据集可以存储在本地，也可以存储在云数据存储服务(如S3)中。

大约六个月前，我开始使用Kedro，从那时起，我就将它用于不同的实验数据管道。其中一些管道用于构建最终部署到生产中的模型，还有一些用于与团队成员的协作。下面，我将讨论我在Kedro中发现的优点和缺点，以及它如何帮助我们创建可重复、可维护的数据管道。

良好的

• 再现性我在这里说的好话都不够:他们做到了。他们的依赖管理需要一点时间来适应，但它对所有依赖都强制使用特定的版本，这非常棒。还有，打字的能力kedro安装而且kedro运行执行整个管道是非常棒的。你仍然需要记住种子随机数生成器，但即使这样也很容易记住，如果你把它放在它们的params.yml文件。
• 功能隔离Kedro的固定项目结构鼓励您考虑管道所需的逻辑步骤，并为每个步骤编写单个节点。因此，每个节点都趋向于短小(就代码行而言)和特定(就逻辑而言)。这使得每个节点易于编写、测试和稍后读取。
• 开发并行:小节点也使开发人员更容易并发工作。很容易发现互不依赖的节点，并且可以由不同的人并发地对它们进行编码。
• 中间数据:也许我最喜欢Kedro的是数据目录。只需将输出数据集的名称添加到catalog.yml然后嘭，它将被序列化到磁盘或云数据存储中。这使得构建管道变得超级简单:在一个节点上工作，提交它，执行它，并保存结果。它在团队工作时也很有用。我可以在大型GPU机器上运行一个昂贵的节点，并将结果保存到S3，另一个团队成员可以从那里开始。这都是与生俱来的。
• 代码的可重用性:我承认我看过从来没有重复使用的笔记本。我充其量只是拿出一个旧的来提醒自己是如何完成一些复杂的分析的，但即使这样，我也必须记住数据的复杂性。然而，节点的隔离使得重用它们变得很容易。还有Kedro的支持模块化的管道(例如，将管道打包到PIP包中)使得共享公共代码变得简单。我们为图像处理等常见任务创建了模块化管道。

坏

虽然Kedro已经解决了实验数据管道中的许多质量挑战，但我们注意到一些需要较少优雅工作的陷阱:

• 增量数据集:这种支持用于读取数据，但对于写入数据集缺乏这种支持。当我们有一个节点需要8-10个小时才能运行时，这影响了我们几次。如果节点中途失效，我们就失去了功。类似地，如果结果数据集不适合内存，就没有保存增量结果的好方法，因为Kedro中的写入器假设所有分区都在内存中。这个GitHub问题如果开发人员解决了这个问题，可能会修复它，但现在你必须自己管理部分结果。
• 管道的增长:管道很快就会变得难以理解，因为输入和输出只是数据目录中可能存在也可能不存在的命名变量。Kedro即这很有帮助，但是在导航器和代码之间切换有点烦人。我们还开始强制节点名称和它们的函数之间的名称一致，以及管道中的数据集名称和节点函数中的参数名称一致。最后，制作更多更小的管道也是保持理智的好方法。虽然所有这些技术都可以帮助您在精神上进行跟踪，但通过命名输入和输出来编码管道仍然需要权衡。
• 可视化: Kedro并没有真正考虑到这一点，这是我认为笔记本电脑仍然有优势的一件事。然而，Kedro使您可以很容易地在笔记本中加载Kedro上下文，因此您仍然可以启动一个来进行一些可视化。最终，我希望Kedro能够更好地支持生成持久化到08_reporting层的图形化报告。现在我们通过创建一个将笔记本电脑渲染到磁盘的节点来解决这个问题，但这充其量是一种hack。我希望能够更好地支持生成最终的、高度可视化的报告，这些报告可以像中间数据一样在数据目录中进行版本控制。

结论

那么我是Kedro的皈依者吗?是的，你说对了。它取代了我过去用于实验数据管道和模型训练的bash脚本和Python笔记本的蜘蛛网，并使我们团队之间能够更好地协作。对我来说，它不会取代完全产品化的基于流的数据管道，但它绝对确保了我的实验管道是可维护的、可复制的和可共享的。