AWS Kinesis Firehose не вставляет данные в Redshift

Ответ 1

В конце концов, я сделал это, удалив и заново создав поток Firehose: -/ Вероятно, повторное редактирование через веб-консоль сделало эту вещь нестабильной.

Но вот рекомендации по устранению неполадок:

• Хорошей отправной точкой является эта процедура: http://docs.aws.amazon.com/firehose/latest/dev/troubleshooting.html
• Проверьте, что данные поступают в S3
  • Для доставки пожарного шланга должна быть роль IAM с доверительными отношениями между службой пожарного шланга и этой ролью
  • Эта роль IAM должна иметь политику доступа S3
  • См. политику jsons здесь: http://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3
• На этом этапе показатель "DeliveryToS3 Success" в мониторинге Firehose должен быть ненулевым
• Кластер Redshift должен быть общедоступным (см. веб-консоль кластера)
• Группа безопасности кластера должна разрешать входящий трафик с IP-адресов Firehose: Firehose в настоящее время использует один блок CIDR для каждого доступного региона AWS:
  • 52.70.63.192/27 для Востока США (Северная Вирджиния)
  • 52.89.255.224/27 для США, Запад (Орегон)
  • 52.19.239.192/27 для ЕС (Ирландия)
• Дважды проверьте имя пользователя и пароль красного смещения, которые вы дали Firehose

• На этом этапе вы должны увидеть попытки подключения в журналах Redshift:

  select * from stl_connection_log where remotehost like '52%' order by recordtime desc;  
  

• Убедитесь, что у пользователя Redshift, используемого Firehose, достаточно прав для целевой таблицы:

  select tablename, 
     HAS_TABLE_PRIVILEGE(tablename, 'select') as select,
     HAS_TABLE_PRIVILEGE(tablename, 'insert') as insert,
     HAS_TABLE_PRIVILEGE(tablename, 'update') as update,
     HAS_TABLE_PRIVILEGE(tablename, 'delete') as delete, 
     HAS_TABLE_PRIVILEGE(tablename, 'references') as references 
  from pg_tables where schemaname='public' order by tablename;
  

• Затем вы можете проверить, запущена ли команда COPY:

  select * from stl_query order by endtime desc limit 10;
  

• Затем проверьте ошибки загрузки или ошибки сервера:

  select * from stl_load_errors  order by starttime desc;
  select * from stl_error where userid!=0 order by recordtime desc;
  

• Если у вас есть проблемы с форматированием в ваших данных, или в параметрах COPY, или несоответствие между вашими данными и целевыми столбцами, вы должны как минимум увидеть попытки COPY и некоторые ошибки загрузки.

• Если вы все еще застряли, и в этих таблицах журналов ничего не появляется, попробуйте удалить и заново создать весь поток пожарных шлангов, поскольку могут быть некоторые ошибки, связанные с веб-консолью. (Этот шаг работал для меня)

Ответ 2

Перейдите к роли IAM (firehose_delivery_role), автоматически созданной во время настройки Kinesis Firehose, и убедитесь, что к ней добавлены следующие роли:

AmazonS3FullAccess
AmazonRedshiftFullAccess
AmazonKinesisFullAccess
AmazonKinesisFirehoseFullAccess

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

Также убедитесь, что вы действительно видите файлы данных, накапливающиеся в S3.

Ответ 3

Хотел опубликовать мое дело для тех, кто проиграл здесь.

Мы применяли вызовы шифрования на стороне сервера в нашем ведомом S3 по направлениям, размещенным здесь: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html

Проблема с использованием этой политики в ведре, используемом Firehose, заключается в том, что Firehose создает незашифрованные файлы манифеста, а также зашифрованные файлы данных. Если эта политика установлена, файлы манифеста не будут созданы на S3 и, таким образом, не будут запускать загрузки Redshift. Таким образом, наше поведение показало данные, поступающие в ведро, но без файлов манифеста, ergo не загружает данные.

Ответ 4

Во время настройки Kinesis Firehos используйте учетные данные Redshift masteruser. Любой другой пользователь не будет работать.