GCP 上的数据湖、层和 ETL 处理

Question

我来自本地/Hadoop 数据平台背景，现在想了解在 GCP 云技术上执行此操作的良好做法。

如图所示，我使用 HDFS/Hive 来存储所有 3 个层的数据：“Landing”、“Cleansed”和“Processed”。对于 ETL 过程，我使用了 Spark。这也支持不同的摄取模式：插入新记录、插入以及更新以前的数据。

对于“服务层”，我们使用了 Presto。此外，借助 DeltaLake 等新技术，可以保持几乎相同的架构，以统一的方式支持流处理和批处理。

在 GCP 上，我可以想到以下选项：

选项1：

• “登陆层”是谷歌存储。
• DataFlow“ETL过程”将数据转换并加载到“Cleansed Layer”中。“Cleansed Layer”存储为BigQuery表。
• “清理层”到“处理层”ETL 是在 BigQuery 内部完成的

选项 2：

• “登陆层”是谷歌存储。
• DataFlow/DataProc “ETL 过程”将数据转换并存储在“Cleansed Layer”中。“Cleansed Layer”存储在 Cloud Store 中。
• “清理层”到“处理层”ETL 是使用 DataFlow/DataProc 完成的，“处理层”也在 Cloud Store 中。
• “服务层”是 BigQuery 表。BigQuery 加载的“处理层”是通过非规范化完成的，以提高 BigQuery 性能。

我的问题：

1. 如选项 1 中所述：在 BigQuery 本身内部执行 ETL 是一个好习惯吗？（使用 BQ DML 语句）。我的印象是重 ETL 不应该在 BQ 中完成，因为它不是为重数据突变而设计的。
2. 在选项 2 中：如果数据摄取模式仅为插入，则可以使用 b'q load' 完成 BigQuery 加载的“处理层”。如果我们必须更新以前的数据怎么办？在这种情况下如何使用 bq-load，因为它只支持追加和替换/覆盖模式。仅仅为了更新它的一部分记录而替换一个大表是没有性能的。
3. 执行 ETL 和处理 BQ 表更新的一般良好做法是什么？

Answer 1

有很多方法可以设计此解决方案，以下是我的建议：

数据湖：
按原样将数据从源系统加载到 BigQuery，因此数据库操作将只是 INSERT。

数据中心：
在这里，您可以维护 OLTP 结构，但实现缓慢变化的维度（Type-II）。
(A) 所有新交易的插入数据
(B) 退出交易的插入也只更新操作列，如 END_DATE & ACTIVE_FLAG。因此，您可以维护记录的历史记录。

数据分析：
在这里，您可以像 Data Hub 一样使用 SCD Type-II 构建维度建模，以最大限度地减少像 UPDATE 这样的大型 DML 操作