Проблемы с AWS Firehose промежуточным ведром S3 и зависимостью от потока доставки

Question

1. Является ли хорошей идеей установить один контейнер s3 для нескольких потоков доставки? (например: рассмотрим два потока доставки, имеющих различную пропускную способность потока, размер буфера s3/интервал буфера ...)

2. Если два потока доставки (S1, S2) передают данные в красное смещение. S1 передает данные в T1 и S2 в T2. В T2 существует ограничение внешнего ключа на T1. Можно ли гарантировать, что, когда S2 доставляет данные (D2) до T2, все записи в T1, на которые ссылается D2, уже были доставлены S1? (Т.е. существует зависимости в потоках доставки)

BTW Я использую, чтобы подтолкнуть пожарный шланг моего журнала приложений в красное смещение для аналитики.

Answer 1

1. Ковши S3 предназначены для хранения практически бесконечных данных, поэтому ответ на ваш вопрос, безусловно, да.
2. Даже если вы можете определить внешние ключи, Redshift фактически не применяет их вообще. Из документации here,

единственность, первичный ключ и внешних ключей носят исключительно информационный характер ; они не применяются Amazon Redshift. Тем не менее, первичные ключи используются как подсказки планирования, и они должны быть , если ваш процесс ETL или какой-либо другой процесс в вашем приложении обеспечивает их целостность.

Answer 2

Предположения: T1 и T2 являются таблицами в том же кластере красного смещения.

Вы можете (практически) иметь столько ведер S3, сколько хотите. Не рекомендуется использовать один и тот же ведро S3 для двух потоков доставки, так как команда COPY, выполняемая Redshift для загрузки данных в кластер, будет искать в той же папке Manifest для обоих потоков доставки.

От Amazon Kinesis шланговой FAQ:

Q: Что такое папка проявляется в моем Amazon S3 ведро?

Для Amazon Redshift Destination Amazon Kinesis Firehose создает файлы манифеста для загрузки объектов Amazon S3 в кластер Redshift в пакетном режиме. В папке manifestests хранятся файлы манифеста, созданные Firehose.