首页 文章

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

提问于
浏览 次
34

我有一个红色群集，我用于一些分析应用程序 . 我有传入的数据，我想添加到 clicks 表 . 让's say I have ~10 new '点击'我想要存储的每一秒 . 如果可能，我希望我的数据尽快在红移中可用 .

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

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

我做了一些测试（这是在一个已经有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 时间 .

Questions:

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

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

My quick analysis:

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

  • S3 Copy strategy ：

  • PROS：看起来像是文档中的好习惯 .

  • 缺点：更多工作（我必须管理存储桶和清单以及触发 COPY 命令的cron ......）

  • Multi-row insert strategy

  • PROS：减少工作量 . 我可以从我的应用程序代码中调用 insert 查询

  • CONS：看起来不像是导入数据的标准方式 . 我错过了什么吗？

amazon-s3 amazon-redshift

4 回答

  • 1

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

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

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

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

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

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

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

    回复于
  • 35

    如果数据负载较大，S3副本的工作速度会更快 . 当你说有数千万条记录需要加载到redshift时，s3上传副本比插入查询更快 .

    S3复制在并行模式下工作 .

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

    S3副本自动为您的表应用编码（压缩） . 当您的创建表并使用副本加载示例时，您可以看到自动应用压缩 .

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

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

    回复于
  • 2

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

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

    回复于
  • 2

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

    • 行插入是最慢的 .

    • 多行插入比行插入快5倍 .

    • S3 COPY比多行插入快3倍 .

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

    • 您不必从CSV行解析insert语句 .

    • Stream在多部分上传到S3之前被压缩 .

    • COPY命令非常快 .

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

    回复于

相关问题