详细内容或原文请订阅后点击阅览
我认为数据工程只是编写脚本。我错了。
我尝试让我的 ETL 管道投入生产。三件事坏了。每个人都教会了我一些仅靠脚本编写永远无法完成的东西。我认为数据工程只是编写脚本的帖子。我错了。首先出现在《走向数据科学》上。
来源:走向数据科学ETL 管道，我认为我已经很好地掌握了数据工程的实际含义。您从某个地方提取数据，清理它，然后将其加载到有用的地方。 ETL。够简单的。
就上下文而言，我是一名试图转型为数据工程的数据分析师。我一直在公开记录这段旅程，从今年早些时候整理的为期 12 个月的自学路线图开始。该旅程的最新一步是使用 GitHub API 从头开始构建我的第一个 ETL 管道，我在 TDS 上对此进行了介绍。该管道有效。它提取数据、清理数据并将其保存到 CSV 中。我很高兴。
因此，我决定进一步推动它，使其更加“可用于生产”，正如互联网上所说的那样。接下来发生的事情确实让我感到惊讶。不是因为事情破裂了，而是因为破裂所揭示的内容。
原始管道
最初的管道是基本的，这很好，因为这就是重点。从 GitHub API 提取数据，进行一些清理，将所有内容保存到 CSV 文件。它完美地发挥了它的作用：一次学习练习。但 CSV 文件和一次性脚本并不是数据工程在现实世界中的工作方式。我想找出“现实世界”在实践中到底意味着什么，所以我决定进一步推动管道，看看会发生什么。
对于没有读过上一篇文章的人来说，这是完整的原始管道：
简单、可读且有效。但当你尝试多次运行它，或者第二天再次运行它时，裂缝就开始显现出来。
第一墙：管道没有记忆
第一次升级很简单。我没有将数据保存到 CSV 文件，而是将数据加载到 SQLite 数据库中。 SQLite 仍然只是一个文件，但它的行为就像一个真正的数据库。您可以查询它，检查其中已有的内容，并在其基础上正确构建。感觉就像一个小小的改变。事实并非如此。
我运行了一次管道并获得了 22 个存储库。然后我在没有更改任何内容的情况下第二次运行它并检查数据库。