从MongoDB到Google BigQuery的ETL流搭建替代方案咨询

以下是几种经过验证的可替代Data Fusion的落地路径：

• 基于Google Cloud Function/Cloud Run的自定义同步链路
  增量同步场景下可监听MongoDB的Change Stream事件，触发Cloud Function完成轻量数据清洗后，直接调用BigQuery流式写入接口落数。全量同步可先将MongoDB全量数据导出为JSON/Parquet格式存入Google Cloud Storage，再通过Cloud Function触发BigQuery批量加载任务。如果同步逻辑复杂、运行时较长，可替换为Cloud Run部署自定义同步服务。
• 基于Google Dataproc的大数据量同步方案
  针对TB级以上的大规模全量+增量同步场景，可在Dataproc上部署Spark作业，通过MongoDB官方Spark连接器读取源端数据，完成字段映射、格式转换、数据聚合等ETL操作后，通过谷歌官方Spark-BigQuery连接器写入目标表，同步性能远高于轻量服务方案。
• 基于开源/托管ETL工具的无代码/低代码方案
  可在GCP环境内部署开源ETL工具Airbyte，其原生同时支持MongoDB数据源和BigQuery目标端，可视化配置同步规则、增量同步策略、字段映射逻辑，无需大量编码即可快速搭建链路。预算充足的情况下也可选择托管ETL服务，无需自行维护工具集群。
• 消息中间件中转方案
  若当前架构中已部署Kafka等消息中间件，可先通过MongoDB Change Stream将数据同步到Kafka Topic，再通过Kafka Connect的BigQuery连接器直接写入目标端，该方案适合需将MongoDB数据同时同步到多个下游系统的场景。

选型参考 #

• 数据量小、同步逻辑简单优先选Cloud Function方案，成本最低，运维量最小
• 大数据量同步优先选Dataproc Spark方案，同步性能最优
• 希望减少编码工作量优先选ETL工具方案，搭建速度最快

内容的提问来源于stack exchange，提问作者Sugaan