构建Snowflake中的近实时数据摄取管道

构建Snowflake中的近实时数据摄取管道

照片来源：Paul Teysen on Unsplash

虽然外部表功能强大，但在灵活性和性能上仍不及Snowflake的内部表。Snowflake以其高度的灵活性和快速的数据处理能力著称，但使用时需注意错误监控。作为一项较新技术，Snowflake在某些方面可能还存在功能缺失，需要寻找合适的解决方案。

本文将重点讨论数据仓库或数据湖构建过程中的“加载”环节，尤其是如何使用Snowflake高效地每天处理数十亿条记录。

在深入探讨之前，先明确几个关键属性：系统的稳定性、数据的及时更新、无限的数据容量、高性能以及对企业需求的无缝适应。这些特性中，成本效益尤为关键，但也是市场上的大多数大规模并行处理（MPP）平台难以同时满足的。

背景介绍当每日数据量达到数十亿级别时，数据处理的规模问题变得尤为突出。通常，这些数据被存储在数据湖中，以减少存储成本。然而，企业可能需要访问超过一年的历史数据，这就需要一种既能节省成本又能保证数据可访问性的解决方案。

传统的ETL模式往往在ETL处理前完成数据加载，然后再进行数据刷新。这种方法在处理流式数据时显得效率低下，尤其是在数据每两分钟到达一次的情况下。因此，我们需要探索Snowflake提供的工具，以寻找更优解。

解决方案概述

Snowflake的外部表可以视为运行在对象存储（如S3）上的Presto引擎，允许用户像操作普通表一样查询存储在数据湖中的数据。这种灵活性使其成为连接数据湖与数据仓库的理想选择。

为了使所有数据可用，可以使用外部表将数据湖中的数据导入Snowflake，实现数据的即时同步。相较于使用COPY命令，这种方式在加载大量数据时更为高效。

保持数据最新合理的分区策略对于维持外部表的查询性能至关重要。若分区优化不当，可能导致全表扫描，增加成本和查询时间。尽管如此，外部表的性能依旧无法超越内部表。

Snowpipe简介

Snowpipe是一种无服务器的数据加载服务，支持按需付费模式。与使用Lambda函数相比，Snowpipe不仅减少了延迟，还提高了数据加载的可靠性。其最大延迟约为40秒，且未出现文件丢失的情况。

优势与局限使用Snowpipe，数据可以近乎实时地加载到Snowflake表中，无需额外的计算资源，成本较低。然而，其管道管理功能尚不完善，且在处理大量小文件时可能会产生较高的费用。

摄取管道的选择选择最适合的摄取管道取决于具体的业务场景。例如，如果S3作为主要数据湖，且需要最新的数据追加，同时考虑到数据的大小和成本，推荐的架构如下：

此架构确保数据同步时间不超过40秒，同时降低了维护成本，支持热/冷数据存储策略，并允许企业使用熟悉的工具访问数据。

潜在的妥协该方案依赖于基于日期的分区策略，若查询未能有效利用分区，性能将大打折扣。此外，对于包含更新操作的数据模型，可能需要对架构进行调整。

实施步骤

1. 创建外部表: 确保数据按照老化列进行分区，良好的分区键设计有助于提高查询性能。

2. 创建内部表: 可以创建一个简单的表结构用于复制列，根据需要添加或删除列。

3. 创建Snowpipe: 设置自动连续加载，必要时在加载过程中对数据进行转换。

4. 定义数据加载起点: 根据数据的时间范围，选择合适的加载方法。

5. 创建视图: 将外部表和内部表的数据合并，形成统一的数据视图。

6. 监控使用情况: 关注查询性能，确保大多数查询能在内部表中高效执行。

总结Snowflake提供了多种工具帮助管理和接收数据。虽然每种实现方式都有其优缺点，但结合使用Snowpipe和外部表，可以为大多数数据摄取场景提供有效的解决方案。