Postgresql 如何在模式上同步应用程序工程师（Postgres）和数据工程师（Redshift）

我在一家中型网络公司担任数据工程师。我们每天都有一个ETL，它从我们的应用程序数据库（碰巧是Cassandra和Postgres）中获取数据，并将其存储在我们的数据仓库Redshift中

我们当前的数据传输系统是以相对简单的方式为Postgres DB建立的：我们有一个Postgres DB的读取副本，用于将增量数据加载到S3，然后将其复制到红移表

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

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

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

---

其他组织如何解决这个问题

这取决于数据仓库的业务目标。是否必须包含所有详细信息、更改列类型、添加新列等，即是否应立即跟踪应用程序数据库

在大多数情况下不应该这样做，但数据仓库提供了不同的数据视图。所以，让我们明确地将此添加到我们的流程中：使用固定的输出模式在应用程序数据库的顶部创建一个视图。让应用程序工程师维护此视图，并在更改模式时测试它是否兼容。如果视图正常工作，数据仓库工程师就不会感到意外

---

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

看看或者谢谢你，这听起来可能正是我们需要的。对于如何具体实施固定输出模式，您有什么建议吗？您有运行查询测试的基础结构吗？这些测试是在应用程序开发人员进行更改时运行的？我只需要创建一个执行视图并验证列类型的查询测试。注释此测试，如果存在类型更改，则需要更新视图。不要在视图定义中使用*-使用显式字段名，这会检测字段重命名等问题。