O Amazon Data Firehose era conhecido anteriormente como Amazon Kinesis Data Firehose
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á.
Entenda a entrega de dados do Amazon Data Firehose
Depois que os dados são enviados para o stream do Firehose, eles são automaticamente enviados para o destino que você escolher.
Importante
Se você usar a Kinesis Producer Library (KPL) para gravar dados em um fluxo de dados do Kinesis, poderá usar agregação para combinar os registros gravados. Se você então usar esse stream de dados como fonte para seu stream do Firehose, o Amazon Data Firehose desagregará os registros antes de entregá-los ao destino. Se você configurar seu stream do Firehose para transformar os dados, o Amazon Data Firehose desagregará os registros antes de entregá-los. AWS Lambda Para obter mais informações, consulte Developing Amazon Kinesis Data Streams Producers Using the Kinesis Producer Library e Aggregation no Amazon Kinesis Data Streams Developer Guide.
Tópicos
- Configurar formato de entrega de dados
- Entenda a frequência de entrega de dados
- Lidar com falhas na entrega de dados
- Configurar o formato de nome de objeto do Amazon S3
- Configurar a rotação do índice para o OpenSearch Serviço
- Entenda a entrega em todas AWS as contas e regiões
- Registros duplicados
- Pausar e retomar um stream do Firehose
Configurar formato de entrega de dados
Para entrega de dados ao Amazon Simple Storage Service (Amazon S3), o Firehose concatena vários registros de entrada com base na configuração de buffer do seu stream do Firehose. Depois, entrega os ao Amazon S3; como um objeto do S3;. Por padrão, o Firehose concatena dados sem delimitadores. Se quiser ter novos delimitadores de linha entre os registros, você pode adicionar novos delimitadores de linha ativando o recurso na configuração do console Firehose ou no parâmetro da API.
Para entrega de dados ao Amazon Redshift, o Firehose primeiro entrega os dados recebidos em seu bucket do S3 no formato descrito anteriormente. Em seguida, o Firehose emite um comando do Amazon COPY Redshift para carregar os dados do seu bucket do S3 para o cluster provisionado do Amazon Redshift ou para o grupo de trabalho Amazon Redshift Serverless. Certifique-se de que, após o Amazon Data Firehose concatenar vários registros recebidos em um objeto do Amazon S3, o objeto do Amazon S3 possa ser copiado para seu cluster provisionado do Amazon Redshift ou grupo de trabalho Amazon Redshift Serverless. Para obter mais informações, consulte Parâmetros de formato de dados do comando COPY do Amazon Redshift.
Para entrega de dados para OpenSearch Service e OpenSearch Serverless, o Amazon Data Firehose armazena registros de entrada com base na configuração de buffer do seu stream Firehose. Em seguida, ele gera uma solicitação em massa de OpenSearch serviço ou OpenSearch sem servidor para indexar vários registros em seu cluster de OpenSearch serviços ou coleção sem OpenSearch servidor. Certifique-se de que seu registro esteja codificado em UTF-8 e nivelado em um objeto JSON de linha única antes de enviá-lo para o Amazon Data Firehose. Além disso, a rest.action.multi.allow_explicit_index opção para seu cluster de OpenSearch serviços deve ser definida como verdadeira (padrão) para receber solicitações em massa com um índice explícito definido por registro. Para obter mais informações, consulte OpenSearch Service Configure Advanced Options no Amazon OpenSearch Service Developer Guide.
Para entrega de dados ao Splunk, o Amazon Data Firehose concatena os bytes que você envia. Se você quer delimitadores em seus dados, como um caractere de nova linha, deve inseri-los. Certifique-se de que o Splunk é configurado para analisar quaisquer delimitadores.
Ao entregar dados para um endpoint HTTP de propriedade de um provedor de serviços terceirizado compatível, você pode usar o serviço Amazon Lambda integrado para criar uma função para transformar os registros recebidos no formato que é esperado ela integração do provedor de serviços. Entre em contato com o provedor de serviços terceirizado cujo endpoint HTTP você escolheu como destino para saber mais sobre o formato de registro que ele aceita.
Para entrega de dados ao Snowflake, o Amazon Data Firehose armazena internamente os dados em buffer por um segundo e usa as operações da API de streaming do Snowflake para inserir dados no Snowflake. Por padrão, os registros que você insere são liberados e confirmados na tabela do Snowflake a cada segundo. Depois de fazer a chamada de inserção, o Firehose emite uma CloudWatch métrica que mede quanto tempo levou para que os dados fossem confirmados no Snowflake. Atualmente, o Firehose suporta apenas um único item JSON como carga útil de registro e não oferece suporte a matrizes JSON. Certifique-se de que sua carga de entrada seja um objeto JSON válido e esteja bem formada sem aspas duplas, aspas ou caracteres de escape extras.
Entenda a frequência de entrega de dados
Cada destino do Firehose tem sua própria frequência de entrega de dados. Para ter mais informações, consulte Entenda as dicas de buffer.
Lidar com falhas na entrega de dados
Cada destino do Amazon Data Firehose tem seu próprio tratamento de falhas na entrega de dados.
- 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 função do IAM que o Amazon Data Firehose presume 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 COPIAR manualmente os dados com arquivos de manifesto, consulte Uso de 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 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 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 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 novas 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" } - Destino do endpoint HTTP
-
Quando o Amazon Data Firehose envia dados para um destino de endpoint HTTP, 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 endpoint HTTP, seja a tentativa inicial ou uma nova tentativa, ele reinicia o contador de tempo limite de resposta. Depois, ele espera a chegada de uma resposta do destino de endpoint HTTP. 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 outros tipos de erros de entrega de dados, consulte HTTP Endpoint 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" } - Destino 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 carga JSON 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 carga JSON em 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 de 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" }
Configurar o formato de nome de objeto do Amazon S3
Quando o Firehose entrega dados para o Amazon S3, o nome da chave do objeto S3 segue o <evaluated prefix><suffix>formato, onde o sufixo tem o formato - - - - - - - - - - <Firehose stream name><Firehose stream version><year><month><day><hour><minute><second><uuid><file extension><Firehose stream version>começa com 1 e aumenta em 1 para cada alteração de configuração do stream do Firehose. Você pode alterar as configurações de stream do Firehose (por exemplo, o nome do bucket do S3, dicas de buffer, compactação e criptografia). Você pode fazer isso usando o console Firehose ou a operação da UpdateDestinationAPI.
Para<evaluated prefix>, o Firehose adiciona um prefixo de hora padrão no formato. YYYY/MM/dd/HH Esse prefixo cria uma hierarquia lógica no bucket, em que cada barra (/) cria um nível na hierarquia. Você pode modificar essa estrutura especificando um prefixo personalizado que inclui expressões que são avaliadas em tempo de execução. Para obter informações sobre como especificar um prefixo personalizado, consulte Prefixos personalizados para objetos do Amazon Simple Storage Service.
Por padrão, o fuso horário usado para prefixo e sufixo de hora está em UTC, mas você pode alterá-lo para um fuso horário de sua preferência. Por exemplo, para usar o horário padrão do Japão em vez do UTC, você pode configurar o fuso horário para Ásia/Tóquio na configuração de parâmetros da AWS Management Console API (). CustomTimeZone A lista a seguir contém fusos horários compatíveis com o Firehose para a configuração do prefixo S3.
A seguir está uma lista de fusos horários que o Firehose suporta para a configuração do prefixo S3.
<file extension>Você não pode alterar o campo de sufixo, exceto. Quando você ativa a conversão ou a compactação do formato de dados, o Firehose anexa uma extensão de arquivo com base na configuração. A tabela a seguir explica a extensão de arquivo padrão anexada pelo Firehose:
| Configuração | Extensão de arquivo |
|---|---|
| Conversão de formato de dados: Parquet | .parquete |
| Conversão de formato de dados: ORC | .orc |
| Compressão: Gzip | .gz |
| Compressão: Zip | .zip |
| Compressão: Snappy | .snappy |
| Compressão: Hadoop-Snappy | .hsnappy |
Você também pode especificar uma extensão de arquivo de sua preferência no console ou na API do Firehose. A extensão do arquivo deve começar com um ponto (.) e pode conter caracteres permitidos: 0-9a-z! -_.*' (). A extensão do arquivo não pode exceder 128 caracteres.
nota
Quando você especifica uma extensão de arquivo, ela substitui a extensão de arquivo padrão que o Firehose adiciona quando a conversão ou compactação do formato de dados está ativada.
Configurar a rotação do índice para o OpenSearch Serviço
Para o destino do OpenSearch serviço, você pode especificar uma opção de rotação de índice com base no tempo a partir de uma das cinco opções a seguir: NoRotationOneHour,OneDay,OneWeek, ouOneMonth.
Dependendo da opção de rotação escolhida, o Amazon Data Firehose acrescenta uma parte da data e hora de chegada UTC ao nome do índice especificado. Ele alterna o time stamp anexado adequadamente. O exemplo a seguir mostra o nome do índice resultante em OpenSearch Serviço para cada opção de rotação do índice, onde está o nome do índice especificado myindex e a data e hora de chegada. 2016-02-25T13:00:00Z
| RotationPeriod | IndexName |
|---|---|
NoRotation |
myindex |
OneHour |
myindex-2016-02-25-13 |
OneDay |
myindex-2016-02-25 |
OneWeek |
myindex-2016-w08 |
OneMonth |
myindex-2016-02 |
nota
Com a opção OneWeek, o Data Firehose cria índices automaticamente usando o formato <ANO>-w <NÚMERO DASEMANA>(por exemplo,2020-w33), em que o número da semana é calculado usando o horário UTC e de acordo com as seguintes convenções dos EUA:
-
A semana começa no domingo
-
A primeira semana do ano é a primeira semana que contém um sábado naquele ano
Entenda a entrega em todas AWS as contas e regiões
O Amazon Data Firehose oferece suporte à entrega de dados para destinos de endpoints HTTP em todas as contas. AWS O stream do Firehose e o endpoint HTTP que você escolhe como destino podem pertencer a contas diferentes. AWS
O Amazon Data Firehose também oferece suporte à entrega de dados para destinos de endpoints HTTP em todas as regiões. AWS Você pode entregar dados de um stream do Firehose em uma AWS região para um endpoint HTTP em outra região. AWS Você também pode entregar dados de um stream do Firehose para um destino de endpoint HTTP fora das AWS regiões, por exemplo, para seu próprio servidor local, definindo a URL do endpoint HTTP como o destino desejado. Nesses cenários, taxas adicionais de transferência de dados são adicionadas aos seus custos de entrega. Para obter mais informações, consulte a seção Transferência de dados
Registros duplicados
O Amazon Data Firehose usa at-least-once semântica para entrega de dados. Em algumas circunstâncias, como quando a entrega de dados expira, novas tentativas de entrega pelo Amazon Data Firehose podem introduzir duplicatas se a solicitação original de entrega de dados eventualmente for concluída. Isso se aplica a todos os tipos de destino compatíveis com o Amazon Data Firehose.
Pausar e retomar um stream do Firehose
Depois de configurar um stream do Firehose, os dados disponíveis na fonte do stream são continuamente entregues ao destino. Se você se deparar com situações em que o destino do fluxo esteja temporariamente indisponível (por exemplo, durante operações de manutenção planejadas), pode ser que queira pausar temporariamente a entrega de dados e continuar quando o destino estiver disponível novamente. As seções seguintes mostram como fazer isso:
Importante
Ao usar a abordagem descrita abaixo para pausar e retomar um stream, depois de retomar o stream, você verá que poucos registros são entregues ao bucket de erros no Amazon S3, enquanto o resto do stream continua sendo entregue ao destino. Essa é uma limitação conhecida da abordagem e ocorre porque um pequeno número de registros que não puderam ser entregues anteriormente ao destino após várias tentativas é rastreado como falhado.
Entendendo como o Firehose lida com falhas de entrega
Ao configurar um stream do Firehose, para muitos destinos, como OpenSearch Splunk e endpoints HTTP, 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 Tratamento de falhas na entrega de dados. 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.
Pausando um stream do Firehose
Para pausar a entrega do stream no Firehose, primeiro remova as permissões para que o Firehose grave no local de backup do S3 em caso de falhas nas entregas. Por exemplo, se quiser pausar o stream do Firehose com OpenSearch um destino, você pode fazer isso atualizando as permissões. Para obter mais informações, consulte Conceder acesso ao Firehose a um destino de OpenSearch serviço público.
Remova a permissão "Effect": "Allow" para a ação s3:PutObject e adicione explicitamente uma instrução que aplique a permissão Effect": "Deny" à ação s3:PutObject para o bucket do S3 usado para fazer backup de entregas com falha. Em seguida, desative o destino do stream (por exemplo, desative o OpenSearch domínio de destino) ou remova as permissões para que o Firehose grave no destino. Para atualizar as permissões para outros destinos, consulte a seção do seu destino em Controlando o acesso com o Amazon Data Firehose. Depois de concluir essas duas ações, o Firehose deixará de fornecer streams e você poderá monitorar isso usando CloudWatch métricas do Firehose.
Importante
Ao pausar a entrega do stream no Firehose, você precisa garantir que a origem do stream (por exemplo, no Kinesis Data Streams ou no Managed Service for Kafka) esteja configurada para reter os dados até que a entrega do stream seja retomada e os dados sejam entregues ao destino. Se a fonte for DirectPut, o Firehose reterá os dados por 24 horas. Poderá ocorrer uma perda de dados se você não retomar o fluxo de entregar os dados antes da expiração do período de retenção de dados.
Retomando um stream do Firehose
Para retomar a entrega, primeiro reverta a alteração feita anteriormente para o destino do stream ativando o destino e garantindo que o Firehose tenha permissões para entregar o stream ao destino. Depois, reverta as alterações feitas anteriormente nas permissões aplicadas ao bucket do S3 de backup de entregas com falha. Remova a permissão "Effect": "Allow" para a ação s3:PutObject e remova a permissão "Effect": "Deny" para a ação s3:PutObject para o bucket do S3 usado para backup das entregas com falha. Por fim, monitore usando CloudWatch métricas do Firehose para confirmar se o stream está sendo entregue ao destino. Para visualizar e solucionar erros, use o monitoramento do Amazon CloudWatch Logs para Firehose.
