迷航10 |无服务器架构：S3数据加载

S3数据加载

有多种方法可以将数据从生产者传输到最终源。 S3和Lambda表示一种非常简单且低成本的方法，也可以扩展为非常强大的方法。如果您需要真正的实时可见性，那是不合适的，但这是一个相对的术语。如果您可以接受大约15至60秒的延迟，那么这是一个很好的解决方案，它比使用Kinesis的真正实时方法要简单得多。

数据生产者（即网络应用或客户端系统）以其最基本的形式将数据定期以某种平面文件格式推送到S3。此S3事件触发一个Lambda函数，该函数处理数据并将其推入最终目的地（例如Redshift，另一个SQL数据库），或者可能以某种存档的形式返回到S3。

The Redshift COPY command, invoked in the Lambda function, is a straightforward and efficient way to load the data into Redshift. AWS outlined this in more detail in 这个很棒的博客文章.

To make this approach more robust, we always make sure to move the files from some /incoming folder in S3 to a /processed folder after a successful load. This makes it easy to identify and reprocess failures, and you can add an S3生命周期规则 to the /processed folder to archive or delete the raw data after some period.

当然，此简单版本有一些限制：

数据生产者必须负责缓冲和批处理数据，以便可以将间歇文件发送到S3。从应用程序的角度来看，这是更多的努力，而不是从生产者（即应用程序）的角度来看更可取的“解雇”方案。

如果有很多数据生产者，并且它们不能以可预测的一致方式发送数据，则大量数据可能会使数据库超载，因为Lambda将以几乎无限的并发率触发。

更坚固的设计

我们可以发展这种基本模式来解决这两个问题。要解决＃1，我们只需将Kinesis Firehose放在中间。 Kinesis Firehose是一个完全托管的流数据队列，用于处理数据的缓冲和批处理并将其推入S3。您可以通过API推送数据，也可以使用Linux代理连续监视一组文件，并让该代理处理将新数据发送到Kinesis的过程。

为了解决＃2，我们需要引入一个集中式队列。有几种方法可以做到这一点。一种是我们上面讨论的Kinesis Firehose方法……由于单个系统正在完成所有缓冲和批处理工作，因此这个“许多装载机”问题就消除了。但是这种方法可能并不理想。如果需要FIFO，则可以使用实际队列，例如SQS（宽松FIFO）或Dynamo或Redis。但是在大多数情况下，FIFO并不重要，您可以简单地将S3用作队列。该过程如下所示：

Data producers drop files into S3 /incoming folder

预定的Lambda函数每分钟运行一次（或更短的时间运行），并在S3中列出文件 /incoming

Lambda函数开始加载最多X个文件，其中X被确定为您的数据源不会使系统超载。对于典型的数据源，此加载应是迭代的，但对于Redshift，您可以使用单个COPY命令并行加载它们以最大化性能。

Lambda函数发送带有未处理文件数量（步骤2中列出的文件数减去步骤3中处理的文件数）的自定义Cloudwatch指标。

如果此指标增长得太高或没有下降，Cloudwatch警报会向您发出警告，表明您可能需要增加X和数据源的写入容量。