Question

我有一个用于某些分析应用程序的redshift集群。我有传入的数据，我想添加到clicks表。假设我每秒要存储约10个新的“点击次数”。如果可能的话，我希望我的数据尽快在红移中可用。

据我所知，由于柱状存储，插入性能很差，因此您必须按批次插入。我的工作流程是将点击次数存储在redis中，每分钟，我都会将redis中的~600次点击作为批量插入红色。

我必须将一批点击插入redshift：

Multi-row insert strategy：我使用常规insert查询来插入多行。 Multi-row insert documentation here
S3 Copy strategy：我将s3中的行复制为clicks_1408736038.csv。然后我运行COPY将其加载到clicks表中。 COPY documentation here

我已经完成了一些测试（这是在已经有200万行的clicks表上完成的）：

             | multi-row insert stragegy |       S3 Copy strategy    |
             |---------------------------+---------------------------+
             |       insert query        | upload to s3 | COPY query |
-------------+---------------------------+--------------+------------+
1 record     |           0.25s           |     0.20s    |   0.50s    |
1k records   |           0.30s           |     0.20s    |   0.50s    |
10k records  |           1.90s           |     1.29s    |   0.70s    |
100k records |           9.10s           |     7.70s    |   1.50s    |

正如您所看到的，就性能而言，首先在s3中复制数据看起来我什么都没得到。 upload + copy时间等于insert时间。

问题：

每种方法有哪些优点和缺点？什么是最佳做法？我错过了什么吗？

并提出问题：是否可以通过清单自动从s3红移到COPY数据？我的意思是一旦将新的.csv文件添加到s3中，就立即复制数据？文档here和here。或者我是否必须自己创建一个后台工作程序来触发COPY命令？

我的快速分析：

In the documentation about consistency，没有提到通过多行插入加载数据。看起来首选方式是COPY来自s3的唯一对象键（s3上的每个.csv都有自己唯一的名称）...

S3 Copy strategy：
- PROS：看起来像是文档中的好习惯。
- 缺点：更多工作（我必须管理存储桶和清单以及触发COPY命令的cron ...）
Multi-row insert strategy
- PROS：减少工作量。我可以从我的应用程序代码中调用insert查询
- CONS：看起来不像是导入数据的标准方式。我错过了什么吗？

Answer 1

Redshift是一个分析数据库，它经过优化，可以查询数百万条记录。它还经过优化，允许您使用COPY命令快速将这些记录摄取到Redshift中。

COPY命令的设计是将多个文件并行加载到群集的多个节点中。例如，如果您有一个5个小节点（dw2.xl）群集，如果您的数据是多个文件数（例如20个），则可以将数据复制速度提高10倍。文件数和每个文件中的记录数之间存在平衡，因为每个文件都有一些小的开销。

这应该引导您在COPY的频率之间取得平衡，例如每5或15分钟而不是每30秒，以及事件文件的大小和数量。

需要考虑的另一点是你拥有的两种类型的Redshift节点，SSD类型（dw2.xl和dw2.8xl）和磁性节点（dx1.xl和dw1.8xl）。 SSD在摄取方面也更快。由于您正在寻找非常新的数据，您可能更喜欢使用SSD，这通常是低于500GB压缩数据的低成本。如果随着时间的推移你有超过500GB的压缩数据，你可以考虑运行2个不同的集群，一个用于＆＃34; hot＆＃34; SSD上的数据与过去一周或一个月的数据，以及一个用于＆＃34;冷和＃34;包含所有历史数据的磁盘上的数据。

最后，您并不需要将数据上传到S3，这是您的摄取时间的主要部分。您可以使用SSH COPY选项直接从服务器复制数据。请在此处查看有关此内容的更多信息：http://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html

如果您能够将Redis队列拆分为多个服务器或至少具有不同日志文件的多个队列，则可以获得每秒非常好的记录提取速度。

您可能需要考虑允许近实时分析的另一种模式是使用Amazon Kinesis（流媒体服务）。它允许以秒为延迟对数据进行分析，同时准备数据以更优化的方式复制到Redshift中。

Answer 2

如果数据负载较大，S3复制的速度会更快。当你说有数千万条记录需要加载到redshift时，s3上传+复制将比插入查询更快。

S3复制以并行模式工作。

当您创建表并执行插入时，批量大小有限制。单个SQL的最大大小为16 MB。所以你需要注意SQL Batch的大小（取决于每个插入查询的大小）

S3副本会自动为您的表应用编码（压缩）。当你的创建表和使用副本加载样本时，你可以看到压缩自动应用。

但是如果你使用insert命令开始，你会注意到没有应用压缩，这会在redshift中为表提供更多空间，在某些情况下会减慢查询处理时间。

如果您希望使用insert命令，那么创建表，每列都应用了编码，以节省空间和更快的响应时间。

Answer 3

在向Redshift执行批量上传时，可能值得实施微批处理。本文可能值得一读，因为它还包含其他可以更好地执行COPY命令的技术。

http://blogs.aws.amazon.com/bigdata/post/Tx2ANLN1PGELDJU/Best-Practices-for-Micro-Batch-Loading-on-Amazon-Redshift

Answer 4

我的测试结果略有不同。我正在从OS Windows桌面加载CSV文件到Redshift。

行插入是最慢的。
多行插入比行插入快5倍。
S3 + COPY比多排插入快3倍。

是什么促成了更快的批量S3 + COPY插入。

您不必从CSV行解析插入语句。
在将多部分上传到S3之前压缩了流。
COPY命令非常快。

我将我的所有发现编译成一个Python脚本CSV_Loader_For_Redshift

Answer 5

我的意思是将新的.csv文件添加到s3中后立即复制数据吗？

是的，可以使用AWS Lambda进行此操作，当您上传了新文件时可以触发

亚马逊红移：批量插入与来自s3的COPYing

5 个答案: