将数据（增量）加载到 Amazon Redshift、S3、DynamoDB 和 Insert

Question

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

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

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

无论如何，在 RedShift 中避免数据重复的最佳做法是什么？

感谢您的帮助！

Answer 1

您可以将数据写入本地磁盘上的 CSV 文件，然后运行 ​​Python/boto/psycopg2 脚本将数据加载到 Amazon Redshift。

在我的CSV_Loader_For_Redshift 中，我就是这样做的：

1. 使用boto Python 模块和分段上传将数据压缩并加载到 S3。

   conn = boto.connect_s3(AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY)
   bucket = conn.get_bucket(bucket_name)
   k = Key(bucket)
   k.key = s3_key_name
   k.set_contents_from_file(file_handle, cb=progress, num_cb=20, 
   reduced_redundancy=use_rr )
   

2. 使用psycopg2COPY 命令将数据追加到Redshift 表中。

   sql="""
   copy %s from '%s' 
   CREDENTIALS 'aws_access_key_id=%s;aws_secret_access_key=%s' 
   DELIMITER '%s' 
   FORMAT CSV %s 
   %s 
   %s 
   %s;""" % (opt.to_table, fn, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,opt.delim,quote,gzip, timeformat, ignoreheader)
   

Answer 2

虽然这里已经有一个公认的答案，但 AWS 推出了一项名为 Kinesis Firehose 的新服务，它根据用户定义的时间间隔处理聚合、临时上传到 s3 和上传 (SAVE) 到 redshift、重试和错误处理，吞吐量管理等...

这可能是最简单、最可靠的方法。

Answer 3

在这里有点自私，并准确描述事件分析平台 Snowplow 的作用。他们使用这种令人敬畏的独特方式从客户端收集事件日志并将其聚合到 S3 上。

他们为此使用 Cloudfront。您可以做的是，在其中一个 S3 存储桶中托管一个像素，并将该存储桶放在 CloudFront 分配后面作为源。为同一个 CloudFront 启用 S3 存储桶的日志。

只要您在客户端调用该像素（类似于谷歌分析），您就可以将日志作为 url 参数发送。然后可以使用 Copy 丰富这些日志并将其添加到 Redshift 数据库中。

这样就解决了日志聚合的目的。此设置将为您处理所有这些。

您还可以查看Piwik，这是一个开源分析服务，看看您是否可以根据您的需要对其进行修改。

Answer 4

最好先聚合事件日志，然后再将它们提取到 Amazon Redshift。

好处是：

• 您将更好地使用 Redshift 的并行特性； COPY 在 S3 中的一组较大文件（或来自大型 DynamoDB 表）上将比单个 INSERT 或 COPY 小文件快多。

• 您可以在将数据加载到 Redshift 之前对其进行预排序（尤其是如果排序基于事件时间）。这还可以提高您的加载性能并减少对表的 VACUUM 的需求。

您可以在多个地方累积您的事件，然后再将它们聚合并加载到 Redshift：

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

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

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

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

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

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

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

但是，您也可以在 Redshift 中执行此检查。一个好的做法是将COPY 数据放入一个临时表，然后SELECT INTO 一个组织良好且排序良好的表。

您可以实施的另一个最佳实践是每天（或每周）表分区。即使您想要一个大而长的事件表，但大多数查询都在一天（例如最后一天）运行，您也可以创建一组具有相似结构的表（events_01012014、events_01022014、events_01032014 ...）。然后您可以SELECT INTO ... WHERE date = ... 到每个表。如果要查询多天的数据，可以使用UNION_ALL。

Answer 5

要考虑的一个选项是在 DynamoDB 中创建时间序列表，您可以每天或每周在 DynamoDB 中创建一个表来编写每个用户交互。在时间段（天、小时或周）结束时，您可以将日志复制到 Redshift。

有关更多详细信息，请在 DynamoDB 时间序列表上查看此模式：http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns

还有这个博客：

http://aws.typepad.com/aws/2012/09/optimizing-provisioned-throughput-in-amazon-dynamodb.html

对于 Redshift DynamoDB 副本：http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB.html

希望这会有所帮助。