我正在创建一个使用各种来源并将数据发送到 Big Query 的 ETL 管道。对于我的用例，Talend 无法在一项工作中同时处理关系和非关系数据库组件，所以这是我目前的做法：
JOB 1 -- 从源（SQL Server、API 等）获取数据，对其进行转换并将转换后的数据存储在分隔文件（文本或 csv）中 JOB 1 -- 使用JOB 1中分隔文件中存储的转换数据作为源，然后根据大查询将其转换并发送。
我使用分隔的文本文件/csv 作为中间数据存储来实现这一点。由于数据的机密性很重要，而且解决方案还需要可扩展以处理数百万行，我应该使用什么作为中间源。关系数据库会有帮助吗？或分隔文件是否足够好？或者其他我可以使用的东西？
PS- 我会在作业完成后立即删除这些文件，但在作业运行之前担心安全性，尽管会在安全的云架构上运行。 请分享您对此的看法。
【问题讨论】：
标签： google-bigquery etl talend
在数据仓库架构中，让暂存层保持持久性通常是一种很好的做法。这使您能够将数据沿袭追溯回源，能够在业务规则更改时从暂存点重新加载最终模型，并全面了解数据从所有数据经过的转换步骤。从登陆到报告的方式。
我还会考虑更改您的设计，让暂存层在 BigQuery 中自己的数据集下持久化，而不是在处理后删除文件。
由于这只是 ETL/ELT 的操作层，而不是最终用户报告，因此您只需支付大部分存储费用。
现在，回到您的问题并考虑您当前的设计，您可以在 Google Cloud Storage 中创建一个存储桶并将您的转换文件保存在那里。它提供您需要的所有安全性和加密，并且您可以完全控制权限。 Big Query 似乎可以与 Cloud Storage 配合使用，您甚至可以直接从 Cloud Console 从 Storage 文件中加载表。
考虑到所有因素，无论您选择哪个方向，我都建议您存储用于加载表的文件，而不是删除它们。您的最终报告迟早会出现问题/失败，您可能需要追溯到源头进行调查。
简而言之。这个过程是。
|---Extract and Transform---|----Load----|
Source ---> Cloud Storage --> BigQuery
【讨论】：
我会使用 ELT 而不是 ETL：按原样加载源数据并使用 SQL 函数在 Bigquery 中进行转换。
这允许潜在地重塑数据（转换为数组）、过滤列/行并在单个 SQL 中执行转换。
【讨论】：