首页 文章

在ETL作业中用作中间数据源的用途是什么?

提问于
浏览
0

我正在创建一个使用各种源的ETL管道,并将数据发送到Big Query . 对于我的用例,Talend无法在一个作业中处理关系数据库组件和非关系数据库组件,所以这就是我目前的工作方式:

JOB 1 - 从源(SQL Server,API等)获取数据,对其进行转换并将转换后的数据存储在分隔文件(text或csv)中作业1 - 使用JOB 1中分隔文件中存储的转换数据作为源和然后根据大查询对其进行转换并发送 .

我使用分隔文本文件/ csv作为中间数据存储来实现这一点 . 由于数据的机密性很重要,解决方案也需要可扩展以处理数百万行,我应该使用什么作为这个中间源 . 关系数据库会有帮助吗?或分隔文件是否足够好?还是我能用的其他东西?

PS-我在作业完成后立即删除这些文件,但担心安全性直到作业运行,尽管将在安全的 Cloud 架构上运行 . 请分享您对此的看法 .

2 回答

  • 1

    我会做ELT而不是ETL:按原样加载源数据并使用SQL函数在Bigquery中进行转换 .

    这允许潜在地重塑数据(转换为数组),过滤掉列/行并在单个SQL中执行转换 .

  • 0

    在Data Warehousing体系结构中,将暂存层持久化通常是一种很好的做法 . 除了其他功能之外,这还为您提供了将数据沿袭追溯到源代码的能力,能够在业务规则发生变化时从分段点重新加载最终模型,并全面了解数据从所有数据传输到的转换步骤从登陆到报告的方式 .

    我还考虑改变你的设计,让staging层在BigQuery的数据集下持久化,而不是仅仅在处理后删除文件 .

    由于这只是ETL / ELT的操作层而不是最终用户报告,因此您只需为存储支付大部分费用 .

    现在,回到您的问题并考虑您当前的设计,您可以在Google Cloud 端存储中创建一个存储桶并将转换文件保存在那里 . 它提供您所需的所有安全性和加密,并且您可以完全控制权限 . Big Query似乎与 Cloud 存储一起工作,您甚至可以直接从 Cloud 控制台加载存储文件中的表 .

    考虑到所有事情,无论您选择何种方向,我建议您存储用于加载表格而不是删除它们的文件 . 迟早会在您的最终报告中出现问题/失败,您可能需要追溯到调查来源 .

    简而言之 . 这个过程将是 .

    |---Extract and Transform---|----Load----|
      Source  ---> Cloud Storage --> BigQuery
    

相关问题