我有一些表是由GCP DataFlow流应用程序填充的,作为某些数据管道的一部分(除了DataFlow是半定期填充的事实外,DataFlow在这里与本文无关)流模式)。这些表供依赖于表名的下游进程使用。
我需要以生产方式改进这些表的架构。遵循BQ文档建议(https://cloud.google.com/bigquery/docs/manually-changing-schemas#option_2_exporting_your_data_and_loading_it_into_a_new_table),我打算将AVRO格式的当前表导出到GCS,然后基于新的向后兼容架构创建新表*,最后将AVRO导出加载到新表中然后覆盖原始表。
*我创建新表而不是覆盖同一表的原因是因为我需要确保在“更新”实际表之前,在协调该模式演变的多个项目中此操作成功。无论如何,我相信如果我尝试就地更新表,也会遇到同样的问题。
问题是,在我的导出开始和加载完成之间,我的DataFlow应用程序可能已经更新了原始表(它以INSERT / OVERWRITE PARTITION方式工作)。这是一个问题,因为在我处理模式更改时,我将丢失这些数据。
如何在没有批处理事务/分布式事务/表锁的情况下安全地更新我的表架构?如上述*块所述,我还有一个额外的复杂性,那就是需要使用一个间歇性的表来确保我的操作在将其处理到下游内容所依赖的表中之前可以在所有项目中正常工作。
我能想到的唯一选择是自定义实现通过锁(但要通过合作)获得的行为。即我的架构更新过程可以向DataFlow发送一条消息,告诉它推迟执行,直到完成为止。
答案 0 :(得分:0)
我将这个问题视为“如何在表具有流更新的同时安全地演化表架构”。
受架构更改影响的组件:
我建议执行以下操作,以将架构从V1迁移到V2
组件
迁移步骤
考虑回滚的迁移步骤