A entrega de streams do Amazon Data Firehose para tabelas Apache Iceberg no Amazon S3 está em versão prévia e está sujeita a alterações.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Lidar com falhas na entrega de dados

Cada destino do Amazon Data Firehose tem seu próprio tratamento de falhas na entrega de dados.

Ao configurar um stream do Firehose, para muitos destinos, como OpenSearch Splunk e HTTP endpoints, você também configura um bucket S3 em que os dados que não foram entregues podem ser copiados. Para obter mais informações sobre como o Firehose faz backup dos dados em caso de falhas nas entregas, consulte as seções de destino relevantes nesta página. Para obter mais informações sobre como conceder acesso aos buckets do S3 nos quais os dados que não foram entregues podem ser copiados, consulte Grant Firehose Access to an Amazon S3 Destination. Quando o Firehose (a) falha em entregar dados ao destino do stream e (b) falha em gravar dados no bucket S3 de backup devido a entregas malsucedidas, ele efetivamente pausa a entrega do stream até que os dados possam ser entregues ao destino ou gravados no local de backup do S3.

Amazon S3

A entrega de dados para o bucket do S3 pode apresentar falha por vários motivos. Por exemplo, o bucket pode não existir mais, a IAM função que o Amazon Data Firehose assume pode não ter acesso ao bucket, a rede falhou ou eventos similares. Sob essas condições, o Amazon Data Firehose continua tentando novamente por até 24 horas até que a entrega seja bem-sucedida. O tempo máximo de armazenamento de dados do Amazon Data Firehose é de 24 horas. Se a entrega de dados apresentar falha por mais de 24 horas, os dados serão perdidos.

Amazon Redshift

Para um destino do Amazon Redshift, você pode especificar uma duração de nova tentativa (0 a 7200 segundos) ao criar um stream do Firehose.

A entrega de dados ao cluster provisionado do Amazon Redshift ou ao grupo de trabalho do Amazon Redshift Sem Servidor pode falhar por vários motivos. Por exemplo, você pode ter uma configuração de cluster incorreta do seu stream do Firehose, um cluster ou grupo de trabalho em manutenção ou uma falha na rede. Sob essas condições, o Amazon Data Firehose tenta novamente pelo período de tempo especificado e ignora esse lote específico de objetos do Amazon S3. As informações dos objetos ignorados são entregues no bucket do S3 como um arquivo manifesto na pasta errors/, que você pode usar para alocação manual. Para obter informações sobre como armazenar COPY dados manualmente com arquivos de manifesto, consulte Usando um manifesto para especificar arquivos de dados.

Amazon OpenSearch Service e OpenSearch Serverless

Para o destino OpenSearch Service e OpenSearch Serverless, você pode especificar uma duração de nova tentativa (0 a 7200 segundos) durante a criação do stream do Firehose.

A entrega de dados para seu cluster OpenSearch de serviços ou coleção OpenSearch sem servidor pode falhar por vários motivos. Por exemplo, você pode ter uma configuração incorreta de cluster de OpenSearch serviços ou coleção OpenSearch Serverless do seu stream Firehose, um cluster de OpenSearch serviços ou coleção OpenSearch Serverless em manutenção, uma falha na rede ou eventos semelhantes. Sob essas condições, o Amazon Data Firehose tenta novamente pelo período de tempo especificado e, em seguida, ignora essa solicitação de índice específica. Os documentos ignorados são entregues no bucket do S3 na pasta AmazonOpenSearchService_failed/, que você pode usar para alocação manual.

Para OpenSearch Serviço, cada documento tem o seguinte JSON formato:

{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Service)",
    "errorMessage": "(error message returned by OpenSearch Service)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "esDocumentId": "(intended OpenSearch Service document ID)",
    "esIndexName": "(intended OpenSearch Service index name)",
    "esTypeName": "(intended OpenSearch Service type name)",
    "rawData": "(base64-encoded document data)"
}

Para o OpenSearch Serverless, cada documento tem o seguinte formato: JSON

{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Serverless)",
    "errorMessage": "(error message returned by OpenSearch Serverless)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "osDocumentId": "(intended OpenSearch Serverless document ID)",
    "osIndexName": "(intended OpenSearch Serverless index name)",
    "rawData": "(base64-encoded document data)"
}
                    

Splunk

Quando o Amazon Data Firehose envia dados para o Splunk, ele espera por uma confirmação do Splunk. Se ocorrer um erro ou a confirmação não chegar dentro do período de tempo limite da confirmação, o Amazon Data Firehose iniciará o contador de duração de novas tentativas. Ele continuará tentando novamente até a duração da nova tentativa expirar. Depois disso, o Amazon Data Firehose considera isso uma falha na entrega de dados e faz o backup dos dados em seu bucket do Amazon S3.

Toda vez que o Amazon Data Firehose envia dados para o Splunk, seja na tentativa inicial ou em uma nova tentativa, ele reinicia o contador de tempo limite de confirmação. Em seguida, ele aguarda pela chegada de um reconhecimento do Splunk. Mesmo que a duração da nova tentativa expire, o Amazon Data Firehose ainda espera pela confirmação até recebê-la ou até que o tempo limite da confirmação seja atingido. Se a confirmação expirar, o Amazon Data Firehose verifica se ainda há tempo no contador de tentativas. Se houver tempo restante, ele tentará executar novamente e repetirá a lógica até receber um reconhecimento ou determinará que o tempo de tentar novamente expirou.

Uma falha em receber uma confirmação não é o único tipo de erro de entrega de dados que pode ocorrer. Para obter informações sobre outros tipos de erros de entrega de dados, consulte Erros de entrega de dados do Splunk. Qualquer erro de entrega de dados dispara a lógica de novas tentativas se a duração é maior que 0.

Veja a seguir um exemplo de registro de erro.

{
  "attemptsMade": 0,
  "arrivalTimestamp": 1506035354675,
  "errorCode": "Splunk.AckTimeout",
  "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.",
  "attemptEndingTimestamp": 13626284715507,
  "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==",
  "EventId": "49577193928114147339600778471082492393164139877200035842.0"
}

HTTPdestino do endpoint

Quando o Amazon Data Firehose envia dados para um destino de HTTP endpoint, ele espera por uma resposta desse destino. Se ocorrer um erro ou a resposta não chegar dentro do período de tempo limite de resposta, o Amazon Data Firehose inicia o contador de duração de novas tentativas. Ele continuará tentando novamente até a duração da nova tentativa expirar. Depois disso, o Amazon Data Firehose considera isso uma falha na entrega de dados e faz o backup dos dados em seu bucket do Amazon S3.

Toda vez que o Amazon Data Firehose envia dados para um destino de HTTP endpoint, seja a tentativa inicial ou uma nova tentativa, ele reinicia o contador de tempo limite de resposta. Em seguida, ele espera que uma resposta chegue do destino do HTTP endpoint. Mesmo que a duração da nova tentativa expire, o Amazon Data Firehose ainda espera pela resposta até recebê-la ou até que o tempo limite de resposta seja atingido. Se o tempo de resposta expirar, o Amazon Data Firehose verifica se ainda há tempo no contador de novas tentativas. Se restar algum tempo, ele tentará novamente e repetirá a lógica até receber uma resposta ou determinar que o período de novas tentativas expirou.

Deixar de receber confirmação não é o único tipo de erro de entrega de dados que pode ocorrer. Para obter informações sobre os outros tipos de erros de entrega de dados, consulte HTTPEndpoint Data Delivery Errors

Veja a seguir um exemplo de registro de erro.

{
	"attemptsMade":5,
	"arrivalTimestamp":1594265943615,
	"errorCode":"HttpEndpoint.DestinationException",
	"errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", 
	"attemptEndingTimestamp":1594266081318,
	"rawData":"c2FtcGxlIHJhdyBkYXRh",
	"subsequenceNumber":0,
	"dataId":"49607357361271740811418664280693044274821622880012337186.0"
}                   

Snowflake

Para o destino Snowflake, ao criar um stream do Firehose, você pode especificar uma duração opcional de nova tentativa (0 a 7200 segundos). O valor padrão para a duração da nova tentativa é 60 segundos.

A entrega de dados para sua tabela do Snowflake pode falhar por vários motivos, como configuração incorreta de destino do Snowflake, interrupção do Snowflake, falha na rede etc. A política de repetição não se aplica a erros não recuperáveis. Por exemplo, se o Snowflake rejeitar sua JSON carga porque ela tinha uma coluna extra que está faltando na tabela, o Firehose não tentará entregá-la novamente. Em vez disso, ele cria um backup para todas as falhas de inserção devido a problemas de JSON carga no seu bucket de erros do S3.

Da mesma forma, se a entrega falhar devido a uma função, tabela ou banco de dados incorretos, o Firehose não tentará novamente gravar os dados em seu bucket do S3. A duração da nova tentativa só se aplica a falhas devido a um problema no serviço Snowflake, falhas transitórias na rede etc. Sob essas condições, o Firehose tenta novamente pelo período de tempo especificado antes de entregá-los ao S3. Os registros com falha são entregues na pasta snowflake-failed/, que você pode usar para preenchimento manual.

Veja a seguir um exemplo JSON para cada registro que você entrega ao S3.

{
    "attemptsMade": 3,
    "arrivalTimestamp": 1594265943615,
    "errorCode": "Snowflake.InvalidColumns",
    "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation",
    "attemptEndingTimestamp": 1712937865543,
    "rawData": "c2FtcGxlIHJhdyBkYXRh"
}