如何在模式上同步应用程序工程师(Postgres)和数据工程师(Redshift)

Question

我是一家中型网络公司的数据工程师。我们有一个每日ETL，它从我们的应用程序数据库(恰好是Cassandra和Postgres)中提取数据，并将其存储在我们的数据仓库(Redshift)中。

我们当前的数据传输系统是以相对简单的方式设置的(对于我们的Postgres DB)：我们有Postgres DB的读取副本，用于将增量数据加载到S3，然后将其复制到Redshift表。

运行此数据传输的代码位于数据团队的存储库中，与应用程序存储库完全分开。

我们经常面临以下问题:应用程序端开发人员对模式进行了更改。它们更改列名，更改约束，添加列，等等。它们不会通知我们这些。这些变化有时会破坏我们的ETL过程(在QA上，但仍然)，我们必须立即纠正问题，迎头赶上。

我们正在努力改善沟通，试图确保应用程序工程师意识到他们所做的更改必须在他们发布之前传达给我们。然而，在我看来，必须有更好的方法来解决这个问题。有没有一种程序化的方法来解决它？我们可以与运行这些传输脚本的开发人员建立一个额外的共享存储库吗？因此，双方都必须批准这些变化才能通过。

其他组织如何解决此问题？

Answer 1

这取决于数据仓库的业务目标。它是否必须包含所有详细信息、更改列类型、添加新列等--即它是否应该紧跟在应用程序数据库之后？

在大多数情况下不应该这样做，但是数据仓库提供了不同的数据视图。因此，让我们显式地将其添加到我们的流程中:在具有固定输出模式的应用程序数据库之上创建一个视图。让应用程序工程师维护此视图，并在更改模式时测试其兼容性。如果视图正常工作，数据仓库工程师几乎不会感到惊讶。

当然，数据仓库也在发展，应该定期从应用程序数据库中添加新的列，等等。这些发展中的每一个都是在应用程序和数据仓库工程师之间共享的一个小项目。它首先定义一个包含新数据的新视图。完成此操作后，数据仓库工程师将其提取出来，测试视图，并调整他们的流程以使用新视图摄取数据。在这样的项目中，生产代码仍然使用旧视图，一旦一切都完成了，生产代码将切换到使用新视图的新代码。在那之后，旧的观点就失效了。