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

Posted 2023-03-31

【中文标题】如何在架构上同步应用程序工程师 (Postgres) 和数据工程师 (Redshift)

【英文标题】：How to sync application engineers (Postgres) with data engineers (Redshift) on schema

【发布时间】：2019-01-04 19:07:22

【问题描述】：

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

我们当前的数据传输系统是通过以下相对简单的方式设置的（对于我们的 Postgres 数据库）：我们有一个 Postgres 数据库的只读副本，用于将增量数据加载到 S3，然后将其复制到 Redshift表。

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

我们经常会遇到以下问题：应用端开发者对schema进行修改。他们更改列名，更改约束，添加列等。他们没有通知我们这些。这些更改有时会破坏我们的 ETL 流程（在 QA 上，但仍然如此），我们必须立即解决问题，赶上进度。

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

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

【问题讨论】：

看看Liquibase或Flyway

【参考方案1】：

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

在大多数情况下不应该，但数据仓库提供了不同的数据视图。因此，让我们明确地将其添加到我们的流程中：在具有固定输出模式的应用程序数据库之上创建一个视图。让应用程序工程师维护此视图并在更改架构时测试它是否兼容。如果视图正常工作，数据仓库工程师几乎不会有什么意外。

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

【讨论】：

谢谢，这听起来可能正是我们所需要的。您对具体如何实施固定输出模式有什么建议吗？

您是否有运行查询测试的基础设施，这些测试在应用程序开发人员进行更改时运行？我将创建一个执行视图并验证列类型的查询测试。注释此测试，如果有类型更改，则需要更新视图。不要在视图定义中使用 * - 使用明确的字段名称，这会检测字段重命名等问题。