构建 ETL 以将数据加载到雪花中 - 存储 ETL 元数据答案

【问题标题】：Building ETL for loading data into Snowflake - storing ETL metadata构建 ETL 以将数据加载到雪花中 - 存储 ETL 元数据
【发布时间】：2021-04-13 20:04:23
【问题描述】：

在构建将数据加载到 Snowflake 数据仓库（在 Azure 上运行）的 ETL/ELT 流程时，我正在寻找最佳存储 ETL 元数据的位置的建议。 ETL 元数据是指编排复杂 ETL 工作流程所需的表格数据 - 例如。进程之间的依赖关系、每个进程的当前状态信息、我们可以在 ETL 中使用的“控制表”来迭代要加载的各个数据源等。

在基于 SQL Server 构建的旧版 EDW 中，我们不仅可以使用 SQL Server 存储实际的 EDW 数据，还可以存储上述元数据，我们可以使用 T-SQL 访问/操作这些元数据.

使用新的实现，Snowflake 似乎不是存储 ETL 元数据的合适位置。但是，仅为此目的启动另一个云数据库（例如 Azure SQL 数据库）将需要大量额外费用。我们计划使用 Talend Cloud 来构建我们的新 ETL，但我想无论选择哪种集成工具，都会出现有关存储 ETL 元数据的问题。

非常感谢任何反馈！

【问题讨论】：

我想存储和使用 ETL 元数据所需的性能层会非常低，在这种情况下 Azure SQL 不会那么昂贵。还有为什么雪花似乎不是一个合适的地方？
按照马塞尔的回答将其存储在雪花中，没有理由不这样做。
感谢@Nick.McDermaid 的反馈！我们的一个常见用例是我们必须进行数千次 API 调用，在本地保存 JSON 响应，然后将所有响应上传到 Snowflake 阶段。对于每个成功的 API 调用，我们都会更新控制表，这样如果作业失败，我们就不必重复所有调用。将控制表放入 Snowflake 意味着在我们发出调用时运行计算——因此需要额外的成本。此外，由于 Snowflake 不适用于此类工作负载，因此它会增加持续时间。
为这种工作负载运行 Azure SQL 每月可能需要 100 美元，这与雪花相比可能微不足道。
谢谢，@SimonDarr，就像我在另一条评论中所说的那样，在 Snowflake 中存储的问题是必须保持计算运行（因此需要额外的成本）以及在我们必须频繁发布的情况下的额外时间（例如每秒）对 ETL 元数据的查询。我提供的 API 调用场景是一个示例，还有其他示例。

标签： etl snowflake-cloud-data-platform

【解决方案1】：

我还将 Snowflake 用于所有 EDW 元数据。在我看来，这里没有理由不使用 Snowflake。

关于这个主题，我非常喜欢的另一件事是使用 Snowsight 可视化有关我的元数据的一些统计数据并创建类似于“控制仪表板”的东西。

【讨论】：

感谢@Marcel 的反馈！我指的是 ETL 元数据。示例 - 我们必须进行数千次 API 调用，在本地保存 JSON 响应，然后将所有响应上传到 Snowflake 阶段。对于每个成功的 API 调用，我们都会更新控制表，这样如果作业失败，我们就不必重复所有调用。将控制表放入 Snowflake 意味着在我们发出调用时运行计算——因此需要额外的成本。此外，这将增加流程持续时间 - 因为数千个更新语句，每个影响一行，并不是 Snowflake 设计的工作负载。
好吧，我明白你的意思了。我不知道 API 调用的那件事。

【解决方案2】：

我觉得这个问题更多是关于解决方案架构而不是任何技术问题，但可能不适合 Stack Overflow...

我遇到过这个确切的问题，一般来说，这是无服务器数据库附带的一个有趣的问题。传统上，至少根据我的经验，在规划数据库时，这些 ETL 要求中的大部分都被您加载到的数据库所吸收，这通常是成本和访问权限的问题。

通过无服务器计算，您可以尽可能紧密地批量处理工作负载，以便在您无需为浪费的计算时间付费的情况下让服务尽可能多地停机。

Active ETL Process 尤其是接近实时的系统会不断检查源系统上的更新以传播到目标数据库系统，但实际上根本不需要与目标数据库对话，除非有新数据要添加或您的对某些描述进行数据验证。

这是您提出的 ETL DB 的用武之地，除非我必须这样做，否则我不想打雪花，因为这会花费我更多，所以我如何才能在不使用雪花的情况下廉价地创建数据库来解决该要求。

我的建议是考虑您要存储的数据类型以及数据格式。

如果键值对有效，请查看 https://aws.amazon.com/dynamodb/（在价格/性能方面很难击败这就是我解决问题的方法）

此外，如果您的数据本质上并不复杂，请考虑在 ETL 服务器上使用平面文件或 SQLite 之类的东西。

【讨论】：

谢谢，这很有帮助！