我在一家中型网络公司担任数据工程师。我们每天都有一个ETL，它从我们的应用程序数据库(碰巧是Cassandra和Postgres)中提取数据，并将其存储在我们的数据仓库(Redshift)中。
我们目前的数据传输系统是以相对简单的方式设置的(对于我们的Postgres DB)：我们有一个Postgres数据库的读取副本，用于将增量数据加载到S3，然后将其复制到Redshift表。
运行此数据传输的代码位于数据团队的存储库中，与应用程序存储库完全分离。
我们经常面临以下问题：应用程序端开发人员对模式进行更改。它们更改列名、更改约束、添加列等等。它们不会通知我们这些信息。这些变化有时会破坏我们的ETL过程(在QA上，但仍然如此)，我们必须立即纠正问题，迎头赶上。
我们正在努力改善沟通，努力确保应用程序工程师意识到，他们所做的更改必须在发布前与我们沟通。然而，在我看来，必须有更好的方法来解决这个问题。有没有一种程序化的方法来解决它？我们是否可以与运行这些传输脚本的开发人员建立一个额外的共享存储库？因此，双方都必须批准这些修改才能通过。
其他组织如何解决这个问题？
这取决于数据仓库的业务目标。它是否必须包含所有详细信息、更改列类型、添加新列等——也就是说，它是否应该立即跟随应用程序数据库？
在大多数情况下不应该这样做，但数据仓库提供了不同的数据视图。因此，让我们明确地将其添加到我们的流程中：在具有固定输出模式的应用程序数据库之上创建一个视图。让应用程序工程师维护这个视图，并在更改模式时测试它是否兼容。如果视图有效，数据仓库工程师会得到一些小惊喜。
当然，数据仓库也在发展，应该定期从应用程序数据库中添加新列，等等。这些发展中的每一个都是应用程序和数据仓库工程师之间共享的一个小项目。它首先定义一个包含新数据的新视图。一旦完成了这项工作，数据仓库工程师就会拿起它，测试视图，并调整他们的流程，以使用新视图获取数据。在这样的项目中，生产代码仍然使用旧视图，一旦一切完成，生产代码就会切换到使用新视图的新代码。在那之后，旧观点就消失了。