Redshift COPY命令的文档指定了两种从S3加载文件的方法,您可以提供基本路径并加载该路径下的所有文件,也可以指定包含要加载的特定文件的清单文件。 / p>
然而,在我们的情况下,我认为这很常见,S3存储桶会定期接收包含更新数据的新文件。我们希望只能加载尚未加载的文件。
鉴于有一个表stl_file_scan记录了从S3加载的所有文件,以某种方式排除那些已成功加载的文件会很好。这似乎是一个相当明显的功能,但我无法在文档或网络上找到有关如何执行此操作的任何内容。
即使是AWS Data Pipeline中的Redshift S3加载模板似乎也可以通过将所有数据(新旧)加载到临时表,然后将/ upserting与目标表进行比较来管理此方案。当我们从文件名中预先知道文件已被加载时,这似乎是一笔疯狂的开销。
我知道我们可能会移动已经加载到存储桶中的文件,但是我们无法做到这一点,这个存储桶是另一个不属于我们自己的进程的最终存储位置。
我能想到的唯一选择是运行一些其他进程来跟踪已成功加载到redshift的文件,然后定期将其与s3存储桶进行比较以确定差异,然后将清单文件写入某处之前触发复制过程。但多么痛苦!我们需要一个单独的ec2实例来运行该流程,这将使其拥有自己的管理和运营开销。
必须有更好的方法!
答案 0 :(得分:4)
这就是我解决问题的方法,
S3 - (对新创建的日志进行Lambda触发) - Lambda - Firehose - Redshift
它适用于任何规模。随着负载的增加,对Lambda的调用越来越多,要发送的数据越多,所有内容都会自动处理。
如果文件格式存在问题,您可以配置死信队列,事件将在那里发送,您可以在修复lambda后重新处理。
答案 1 :(得分:1)
在这里,我想提一些步骤,其中包括如何在redshift中加载数据的过程。
*.gz
格式,这样您就不会得到1000美元
惊喜法案:) ..在我的案例中文本文件被压缩10-20
次。*.gz
文件上传到Amazon S3存储桶。答案 2 :(得分:0)
一般来说,将加载的文件与现有的S3文件进行比较是一种不好但可能的做法。共同的"工业"实践是在实际加载数据的数据生产者和数据使用者之间使用消息队列。看看RabbitMQ与Amazon SQS等等。