amazon-web-services - 将数据(增量)加载到 Amazon Redshift、S3 与 DynamoDB 与插入

Question

我有一个 Web 应用程序需要发送有关其使用情况的报告，为此我想使用 Amazon RedShift 作为数据仓库，
我应该如何收集数据？

每次，用户与我的应用程序交互时，我都想报告..那么我应该什么时候将文件写入 S3 ？有多少？
我的意思是:
- 如果不立即发送信息，那么我可能会因为连接丢失而丢失它，或者在收集信息并准备发送到 S3 时由于我的系统中的某些错误...
- 如果我在每次用户交互时将文件写入 S3，我最终会得到数百个文件(每个文件的数据最少)，需要在复制到 RedShift 后对其进行管理、排序和删除。喜欢一个很好的解决方案。

我错过了什么？我应该改用 DynamoDB，还是应该使用简单的插入 Redshift 来代替!？
如果我确实需要将数据写入 DynamoDB，我是否应该在复制后删除保留表.. 最佳实践是什么？

在任何情况下，避免 RedShift 中数据重复的最佳实践是什么？

感谢帮助!

Answer 1

首选聚合事件日志，然后再将它们提取到 Amazon Redshift 中。

好处是:

您将使用 平行 Redshift的性质更好； COPY S3 中的一组较大文件(或来自大型 DynamoDB 表)将是 多比单个小文件的 INSERT 或 COPY 快。

您可以 预排序 在将数据加载到 Redshift 之前，您的数据(特别是如果排序基于事件时间)。这也提高了您的负载性能并减少了对 VACUUM 的需求。你的 table 。

在将事件聚合并加载到 Redshift 之前，您可以在多个位置累积事件:

本地文件到 S3 - 最常见的方法是在客户端/服务器上聚合您的日志，每 x MB 或 y 分钟将它们上传到 S3。有许多支持此功能的日志附加程序，您无需对代码进行任何修改(例如， FluentD 或 Log4J )。这只能通过容器配置来完成。不利的一面是您可能会丢失一些日志，并且可以在上传之前删除这些本地日志文件。

DynamoDB - 正如@Swami 所描述的，DynamoDB 是一种非常好的累积事件的方法。

Amazon Kinesis - 最近发布的服务也是一种以快速可靠的方式将您的事件从各种客户端和服务器流式传输到中心位置的好方法。事件按插入顺序排列，这使得稍后将其加载到 Redshift 中很容易。事件在 Kinesis 中存储 24 小时，您可以安排每小时从 kinesis 读取和加载到 Redshift，例如，以获得更好的性能。

请注意，所有这些服务(S3、SQS、DynamoDB 和 Kinesis)都允许您 直接推送事件来自最终用户/设备，而无需通过中间 Web 服务器。这可以显着提高您的服务的高可用性(如何处理增加的负载或服务器故障)和系统成本(您只需为使用的内容付费，而无需仅为日志而使用未充分利用的服务器)。

例如，在此处查看如何为移动设备获取临时安全 token : http://aws.amazon.com/articles/4611615499399490

允许与这些服务直接交互的另一组重要工具是各种 SDK s。例如 Java , .NET , JavaScript , iOS和 Android .

关于 重复数据删除要求;在上面的大多数选项中，您可以在聚合阶段执行此操作，例如，当您从 Kinesis 流读取时，您可以检查您的事件中是否没有重复，但在放入之前分析大量事件缓冲区进入数据存储。

但是，您也可以在 Redshift 中进行此检查。一个好的做法是 COPY将数据放入临时表，然后 SELECT INTO一张井井有条的 table 。

您可以实现的另一个最佳实践是拥有每日(或每周)表分区。即使您想要一个大的长事件表，但您的大部分查询都在一天(例如最后一天)运行，您也可以创建一组具有相似结构的表(events_01012014、events_01022014、events_01032014 ……)。那么你可以 SELECT INTO ... WHERE date = ...到每个表。当你想查询多天的数据时，可以使用 UNION_ALL .