BigQuery直接导出至AlloyDB：声明式SQL实现反向ETL
有效阅读仅保存在当前浏览器，用于「为你」推荐；暂停或清除记录。
DataHot 速览
Google Cloud 宣布 BigQuery 导出到 AlloyDB 正式可用（GA），数据工程团队只需一条声明式 SQL 语句即可把数据从 BigQuery 导出到 AlloyDB，不再需要复杂的 ETL 中间件。文章以巴西电力公司 Copel 为例：其智能电表遥测数据先汇入 BigQuery 的分析层，再回写 AlloyDB 支撑低延迟客服看板、移动应用和计费系统；原先用 Airflow DAG 加 GCS 上零散 CSV 文件再加临时表的多阶段架构，存在中断风险和性能瓶颈。
为什么值得关注：反向ETL是湖仓到在线业务数据库的关键链路，本文给出厂商原生的声明式实现和真实迁移案例，对做数据集成与实时服务的数据工程师有直接参考价值。
译文
AI 逐段翻译在分析系统（OLAP）与事务型数据库（OLTP）之间架起桥梁是出了名的复杂。在两个系统之间同步数据通常被称为反向 ETL（提取、转换、加载），传统上需要繁重的中间件、暂存存储桶和复杂的编排，尤其是在企业级规模下。
我们宣布正式发布（GA）BigQuery 导出至 AlloyDB，使数据工程团队能够使用单条声明式 SQL 语句将数据从 BigQuery 导出到 AlloyDB。这种方法完全消除了对复杂 ETL 中间件的需求。
为了展示此功能的优势，我们将分享Copel（一家巴西电力供应商）如何通过迁移到高性能的内置反向 ETL，消除了一个巨大的编排瓶颈，并扩展了其智能电表遥测规模。
扩展智能电表遥测的挑战
在 Copel，管理来自数百万智能电表的遥测数据是一项关键任务。这些数据持续流式传输并汇总到 BigQuery 的分析金层中。然而，为了支撑 Copel 的“行动系统”——低延迟客户支持仪表板、移动应用和运营计费系统——这个丰富的数据集必须不断同步回其高性能事务型数据库 AlloyDB for PostgreSQL。
直到最近，Copel 还通过 Google 托管 Apache Airflow 服务中一个复杂的DAG来编排这个反向 ETL 架构。然而，在从 BigQuery 丰富并导出数亿条记录的过程中，存在多个脆弱的中间阶段：
图 1：Copel 遗留的多阶段架构，需要 Cloud Storage 文件转储和顺序执行的 gCloud 脚本。
- BigQuery 运行丰富和提取查询，将 SQL 结果转储到 Google Cloud Storage 存储桶中数十个碎片化的 CSV 文件中。
- Apache Airflow 执行 SQL 在 AlloyDB 中创建临时表，以防止生产表的写入锁定或数据损坏。
- 顺序执行的 gCloud 脚本梳理 Cloud Storage 中的 CSV 文件，将数据加载到相应的 AlloyDB 集群和分片中。
- 最后，一个 SQL 事务块安全地删除生产表，并将临时表重命名为生产表。
为了运行这个遗留架构，Copel 的团队需要维护管道、仔细管理文件暂存、跨多个服务执行复杂的 IAM 模拟，并持续监控端到端系统健康状况。
突破：内置反向 ETL
借助BigQuery 的 EXPORT DATA 至 AlloyDB，Copel 能够用一条优雅的 SQL 语句取代整个多步骤管道基础设施。
现在，BigQuery 导出通过高度优化、并行化的连接直接与 AlloyDB 实例通信——无需在 Cloud Storage 中暂存文件、无需 gCloud 脚本，也无需管理临时表！
图 2：新架构展示了 BigQuery 和 AlloyDB 之间的直接并行反向 ETL 连接。
以下是新的反向 ETL 流程在代码中的简洁样貌：
正在加载...
在导出过程中，生成的 BigQuery 值完美映射到 AlloyDB 的列，使嵌套结构在 PostgreSQL 端完全可查询和可索引。
评估性能与可扩展性
为了验证这一新架构，Copel 执行了两项大规模反向 ETL 基准测试：比较较小规模的增量反向 ETL 导出与大规模得多的全表反向 ETL 导出的性能和可扩展性。
性能结果超出了所有最初预期：
| 指标 | 测试 1：增量导出 | 测试 2：全表导出 |
| 导出的总行数 | 18,145,589 行 | 207,484,577 行 |
| 逻辑数据大小 | 2.32 GB | 188.87 GB |
| 导出吞吐量 | 约 310 万行 / 分钟 | 约 420 万行 / 分钟 |
| AlloyDB 规格 | N2（16 vCPU，128 GB RAM） | N2（16 vCPU，128 GB RAM） |
| CPU 利用率 | 稳定保持在约 85% | 稳定保持在约 85% |
关于数据摄入的专业提示：在复杂的 JSONB 遥测字段上维持约 420 万行/分钟的导出吞吐量是一项杰出的技术成就。它突显了 BigQuery 的分布式处理引擎与 AlloyDB 的高级存储层之间的底层优化。
关键要点与优势
通过采用这种声明式 SQL 方法，Copel 成功删除了数十行复杂的脚本和自定义错误处理块。他们的 Airflow DAG 现在只包含一个简化的 BigQueryInsertJobOperator 任务，用于执行导出查询。
这种内置方法带来了多项核心业务优势：
- 直接成本降低： 通过完全绕过 Cloud Storage，不再有暂存存储成本以及相关的 API 读写操作费用。
- 增强的数据安全性： 数据在 Google 的安全内部网络中直接从 BigQuery 移动到 AlloyDB，从不会被转储为可读的 CSV 文件。
- 近乎零维护： 管道错误现在包含在单条 SQL 语句中，使故障排查和日志记录变得极其简单。
- 大规模分布式写入：直接导出利用 BigQuery 的大规模并行性结合 AlloyDB 优化的 PostgreSQL 写入性能，实现了超过每分钟 400 万条记录的写入速度。
现在，数据工程团队无需再花费宝贵的工程时间监控管道故障和中间存储缓冲区，而是可以专注于真正重要的事情：为客户提供智能分析和优质体验。
立即开始：现代化您的反向 ETL
既然 BigQuery 导出至 AlloyDB 已正式发布，现在是简化数据架构的最佳时机。如果您的团队正在为将 BigQuery 数据推送到下游 OLTP 数据库的复杂多阶段管道而苦恼，我们邀请您尝试内置导出功能，适用于 AlloyDB、Bigtable、Spanner，或Pub/Sub 今天。
发布于
这篇内容对你有用吗？
反馈只用于改善内容筛选，不等同于收藏