我在一家中型Web公司担任数据工程师。我们每天都有一个ETL，可以从应用程序数据库（恰好是Cassandra和Postgres）中获取数据并将其存储在我们的数据仓库（Redshift）中。
我们当前的数据传输系统以相对简单的以下方式（对于Postgres DB）进行设置：我们拥有Postgres DB的只读副本，可用于将增量数据加载到S3，然后将其复制到Redshift表。
运行此数据传输的代码位于数据团队的存储库中，与应用程序存储库完全分开。
我们经常面临以下问题：应用程序端开发人员对架构进行更改。他们更改列名，更改约束，添加列，等等。它们不会将这些通知我们。这些更改有时会破坏我们的ETL流程（但仍在质量保证上），并且我们必须立即解决问题，追赶上来。
我们正在努力改善沟通，以确保应用工程师意识到他们所做的更改必须在出去之前告知我们。但是，在我看来，必须有更好的方法来解决此问题。有程序化的方法可以解决吗？我们是否可以与运行这些传输脚本的开发人员共享一个额外的存储库？因此，双方都必须批准更改才能通过。
其他组织如何解决此问题？
答案 0 :(得分：1)
这取决于数据仓库的业务目标。它是否必须包含所有详细信息，更改列类型，添加新列等-即应立即跟随应用程序数据库吗？
在大多数情况下不应这样做，但是数据仓库提供了不同的数据视图。因此，让我们将其明确添加到我们的流程中：在具有固定输出模式的应用程序数据库之上创建一个视图。让应用程序工程师维护此视图，并在更改架构时测试它是否兼容。如果该视图有效，那么数据仓库工程师将不会感到惊讶。
当然，数据仓库也在不断发展，并应定期从应用程序数据库中添加新列，等等。这些演化中的每一个都是应用程序和数据仓库工程师之间共享的一个小项目。首先定义一个包含新数据的新视图。完成此操作后，数据仓库工程师将其选中，测试视图并调整其过程以使用新视图来摄取数据。在这样的项目中，生产代码仍在使用旧视图，完成所有操作后，生产将切换到使用新视图的新代码。此后，旧视图将退役。