Amazon Data Firehose se conocía anteriormente como Amazon Kinesis Data Firehose
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Conozca la entrega de datos de Amazon Data Firehose
Una vez que los datos se envían a tu transmisión Firehose, se envían automáticamente al destino que elijas.
importante
Si utiliza Kinesis Producer Library (KPL) para escribir datos en un flujo de datos de Kinesis, puede utilizar la agregación para combinar los registros que escriba en ese flujo de datos de Kinesis. Si, a continuación, utiliza esa transmisión de datos como fuente para la transmisión de Firehose, Amazon Data Firehose desagrega los registros antes de entregarlos al destino. Si configura la transmisión de Firehose para transformar los datos, Amazon Data Firehose desagrega los registros antes de entregarlos a ellos. AWS Lambda Para obtener más información, consulte Developing Amazon Kinesis Data Streams Producers Using the Kinesis Producer Library y Aggregation en la Guía para desarrolladores de Amazon Kinesis Data Streams.
Temas
- Configure el formato de entrega de datos
- Comprenda la frecuencia de entrega de datos
- Gestione los errores en la entrega de datos
- Configurar el formato de nombre de objeto de Amazon S3
- Configura la rotación del índice para el servicio OpenSearch
- Comprenda la entrega en todas las AWS cuentas y regiones
- Registros duplicados
- Pausa y reanuda una transmisión de Firehose
Configure el formato de entrega de datos
Para el envío de datos a Amazon Simple Storage Service (Amazon S3), Firehose concatena varios registros entrantes en función de la configuración de almacenamiento en búfer de la transmisión de Firehose. A continuación, entrega los registros en Amazon S3 como un objeto de Amazon S3. De forma predeterminada, Firehose concatena los datos sin ningún delimitador. Si desea disponer de nuevos delimitadores de línea entre los registros, puede añadir nuevos delimitadores de línea activando la función en la configuración de la consola Firehose o en el parámetro de API.
Para el envío de datos a Amazon Redshift, Firehose entrega primero los datos entrantes al bucket de S3 en el formato descrito anteriormente. A continuación, Firehose emite un comando de Amazon COPY Redshift para cargar los datos del bucket de S3 en el clúster aprovisionado de Amazon Redshift o en el grupo de trabajo Amazon Redshift Serverless. Asegúrese de que, después de que Amazon Data Firehose haya concatenado varios registros entrantes a un objeto de Amazon S3, el objeto de Amazon S3 se pueda copiar en el clúster aprovisionado de Amazon Redshift o en el grupo de trabajo Amazon Redshift Serverless. Para obtener más información, consulte Amazon Redshift COPY Command Data Format Parameters.
Para la entrega de datos a OpenSearch Service y OpenSearch Serverless, Amazon Data Firehose almacena en búfer los registros entrantes en función de la configuración de almacenamiento en búfer de la transmisión de Firehose. A continuación, genera una solicitud masiva de OpenSearch Service o OpenSearch Serverless para indexar varios registros en su clúster de servicios o en su colección Serverless. OpenSearch OpenSearch Asegúrese de que el registro esté codificado en UTF-8 y aplanado en un objeto JSON de una sola línea antes de enviarlo a Amazon Data Firehose. Además, la rest.action.multi.allow_explicit_index opción de su clúster de OpenSearch servicios debe estar establecida en true (valor predeterminado) para recibir solicitudes masivas con un índice explícito establecido por registro. Para obtener más información, consulta las opciones avanzadas de configuración de OpenSearch servicios en la Guía para desarrolladores de Amazon OpenSearch Service.
Para la entrega de datos a Splunk, Amazon Data Firehose concatena los bytes que usted envía. Si desea delimitadores en los datos, como, por ejemplo, un carácter de nueva línea, debe insertarlos usted mismo. Asegúrese de que Splunk esté configurado para analizar dichos delimitadores.
Al entregar datos en un punto de conexión HTTP que pertenece a un proveedor de servicios de terceros admitido, puede usar el servicio Amazon Lambda integrado para crear una función que transforme los registros de entrada en el formato que coincida con el formato que espera la integración del proveedor de servicios. Póngase en contacto con el proveedor de servicios de terceros cuyo punto de conexión HTTP haya elegido como destino para obtener más información sobre el formato de registro aceptado.
Para la entrega de datos a Snowflake, Amazon Data Firehose almacena internamente los datos durante un segundo y utiliza las operaciones de la API de streaming de Snowflake para insertar datos en Snowflake. De forma predeterminada, los registros que se insertan se vacían y se archivan en la tabla de Snowflake cada segundo. Tras realizar la llamada de inserción, Firehose emite una CloudWatch métrica que mide el tiempo que tardaron los datos en enviarse a Snowflake. Firehose actualmente solo admite un elemento JSON como carga útil de registro y no admite matrices JSON. Asegúrate de que la carga útil de entrada sea un objeto JSON válido y esté bien formada sin comillas dobles, comillas ni caracteres de escape adicionales.
Comprenda la frecuencia de entrega de datos
Cada destino de Firehose tiene su propia frecuencia de entrega de datos. Para obtener más información, consulte Comprenda las sugerencias de almacenamiento en búfer.
Gestione los errores en la entrega de datos
Cada destino de Amazon Data Firehose tiene su propia gestión de errores en la entrega de datos.
- Amazon S3
-
La entrega de datos al bucket de S3 podría generar errores por varias razones. Por ejemplo, es posible que el bucket ya no exista, que la función de IAM que Amazon Data Firehose asume no tenga acceso al bucket, que la red haya fallado o se produzcan eventos similares. En estas condiciones, Amazon Data Firehose volverá a intentarlo durante un máximo de 24 horas hasta que la entrega se realice correctamente. El tiempo máximo de almacenamiento de datos de Amazon Data Firehose es de 24 horas. Si, una vez transcurridas esas 24 horas, no se pueden entregar los datos, estos se pierden.
- Amazon Redshift
-
Para un destino de Amazon Redshift, puede especificar una duración de reintento (de 0 a 7200 segundos) al crear una transmisión de Firehose.
La entrega de datos en su clúster aprovisionado de Amazon Redshift o grupo de trabajo de Amazon Redshift sin servidor puede fallar por varios motivos. Por ejemplo, es posible que tengas una configuración de clúster incorrecta en tu transmisión de Firehose, un clúster o grupo de trabajo en mantenimiento o un fallo de red. En estas condiciones, Amazon Data Firehose lo vuelve a intentar durante el tiempo especificado y omite ese lote concreto de objetos de Amazon S3. La información de los objetos ignorados se entrega al bucket de S3 en forma de archivo de manifiesto, en la carpeta
errors/, que puede utilizar para reposiciones manuales. Para obtener más información acerca de cómo usar el comando COPY para copiar datos manualmente con archivos de manifiesto, consulte Uso de un manifiesto para especificar archivos de datos. - Amazon OpenSearch Service y OpenSearch Serverless
-
Para el destino OpenSearch Service y OpenSearch Serverless, puedes especificar una duración de reintento (de 0 a 7200 segundos) durante la creación de la transmisión de Firehose.
La entrega de datos al clúster de OpenSearch servicios o a la recopilación OpenSearch sin servidor puede fallar por varios motivos. Por ejemplo, es posible que tengas una configuración incorrecta de un clúster de OpenSearch servicio o colección OpenSearch sin servidor de tu transmisión de Firehose, OpenSearch un clúster de servicio OpenSearch o una colección sin servidor en mantenimiento, un fallo de red o eventos similares. En estas condiciones, Amazon Data Firehose lo vuelve a intentar durante el tiempo especificado y, a continuación, omite esa solicitud de índice concreta. Los documentos ignorados se entregan al bucket de S3 en forma de archivo de manifiesto, en la carpeta
AmazonOpenSearchService_failed/, que puede utilizar para reposiciones manuales.En el OpenSearch caso de Service, cada documento tiene el siguiente 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)" }En el OpenSearch caso de Serverless, cada documento tiene el siguiente 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
-
Cuando Amazon Data Firehose envía datos a Splunk, espera el acuse de recibo de Splunk. Si se produce un error o el acuse de recibo no llega dentro del tiempo de espera del acuse de recibo, Amazon Data Firehose inicia el contador de duración de los reintentos. Continúa intentándolo hasta que se agota el tiempo de reintento. Después de eso, Amazon Data Firehose considera que se trata de un error en la entrega de datos y realiza una copia de seguridad de los datos en su bucket de Amazon S3.
Cada vez que Amazon Data Firehose envía datos a Splunk, ya sea en el intento inicial o en un reintento, reinicia el contador de tiempo de espera de confirmación. A continuación, espera a que llegue una confirmación desde Splunk. Incluso si la duración del reintento vence, Amazon Data Firehose seguirá esperando el acuse de recibo hasta que lo reciba o se agote el tiempo de espera del acuse de recibo. Si se agota el tiempo de espera de la confirmación, Amazon Data Firehose comprueba si queda tiempo en el contador de reintentos. Si queda tiempo, vuelve a intentarlo y repite la lógica hasta que recibe una confirmación o determina que el tiempo de reintento se ha agotado.
Un error de recepción de una confirmación no es el único tipo de error de entrega de datos que puede producirse. Para obtener información sobre los demás tipos de errores de entrega de datos, consulte Errores de entrega de datos relacionados con Splunk. Cualquier error de entrega de datos desencadenará la lógica de reintentos si el tiempo de reintento es mayor que 0.
A continuación se muestra un ejemplo de registro de error.
{ "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 de punto de conexión HTTP
-
Cuando Amazon Data Firehose envía datos a un destino de punto final HTTP, espera una respuesta de este destino. Si se produce un error o la respuesta no llega dentro del tiempo de espera de la respuesta, Amazon Data Firehose inicia el contador de duración de los reintentos. Continúa intentándolo hasta que se agota el tiempo de reintento. Después de eso, Amazon Data Firehose considera que se trata de un error en la entrega de datos y realiza una copia de seguridad de los datos en su bucket de Amazon S3.
Cada vez que Amazon Data Firehose envía datos a un destino de punto final HTTP, ya sea el intento inicial o un reintento, reinicia el contador de tiempo de espera de respuesta. A continuación, espera a que llegue una respuesta del destino de punto de conexión HTTP. Incluso si vence la duración del reintento, Amazon Data Firehose seguirá esperando la respuesta hasta que la reciba o se agote el tiempo de espera de la respuesta. Si se agota el tiempo de espera de la respuesta, Amazon Data Firehose comprueba si queda tiempo en el contador de reintentos. Si queda tiempo, vuelve a intentarlo y repite la lógica hasta que recibe una respuesta o determina que el tiempo de reintento se ha agotado.
Un error de recepción de una respuesta no es el único tipo de error de entrega de datos que puede producirse. Para obtener información sobre los demás tipos de errores de entrega de datos, consulte HTTP Endpoint Data Delivery Errors.
A continuación se muestra un ejemplo de registro de error.
{ "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 en forma de copo de nieve
-
Para el destino Snowflake, al crear una transmisión de Firehose, puedes especificar una duración de reintento opcional (de 0 a 7200 segundos). El valor predeterminado para la duración del reintento es de 60 segundos.
La entrega de datos a la tabla de Snowflake puede fallar por varios motivos, como una configuración de destino incorrecta de Snowflake, un fallo de red, etc. La política de reintentos no se aplica a los errores no recuperables. Por ejemplo, si Snowflake rechaza tu carga JSON porque hay una columna adicional que falta en la tabla, Firehose no intentará volver a entregarla. En su lugar, crea una copia de seguridad de todos los errores de inserción debidos a problemas de carga de JSON en el depósito de errores de S3.
Del mismo modo, si se produce un error en la entrega debido a un rol, tabla o base de datos incorrectos, Firehose no lo vuelve a intentar y escribe los datos en el bucket de S3. La duración del reintento solo se aplica a los errores debidos a un problema con el servicio de Snowflake, a fallos transitorios de la red, etc. En estas condiciones, Firehose lo vuelve a intentar durante el tiempo especificado antes de entregarlos a S3. Los registros fallidos se entregan en la carpeta snowflake-failed/, que puede utilizar para rellenarlos manualmente.
El siguiente es un ejemplo de JSON para cada registro que entregue a 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 el formato de nombre de objeto de Amazon S3
Cuando Firehose entrega datos a Amazon S3, el nombre de la clave del objeto S3 sigue el formato <evaluated prefix><suffix>, donde el sufijo tiene el formato: - - - - - - - - - <Firehose stream name><Firehose stream version><year><month><day><hour><minute><second><uuid><file extension><Firehose stream version>comienza por 1 y aumenta en 1 por cada cambio de configuración de Firehose Stream. Puedes cambiar las configuraciones de transmisión de Firehose (por ejemplo, el nombre del bucket de S3, las sugerencias de almacenamiento en búfer, la compresión y el cifrado). Puedes hacerlo mediante la consola Firehose o la operación UpdateDestinationAPI.
Para<evaluated prefix>, Firehose añade un prefijo de hora predeterminado en el formato. YYYY/MM/dd/HH Este prefijo crea una jerarquía lógica en el depósito, en la que cada barra inclinada (/) crea un nivel en la jerarquía. Puede modificar esta estructura especificando un prefijo personalizado que incluya expresiones que se evalúan en tiempo de ejecución. Para obtener información sobre cómo especificar un prefijo personalizado, consulte Prefijos personalizados para objetos de Amazon Simple Storage Service.
De forma predeterminada, la zona horaria utilizada como prefijo y sufijo es UTC, pero puede cambiarla por la zona horaria que prefiera. Por ejemplo, para usar la hora estándar de Japón en lugar de UTC, puede configurar la zona horaria en Asia/Tokio en la configuración de parámetros de la AWS Management Console API (). CustomTimeZone La siguiente lista contiene las zonas horarias que Firehose admite para la configuración del prefijo S3.
A continuación se muestra una lista de las zonas horarias que Firehose admite para la configuración del prefijo S3.
<file extension>No puede cambiar el campo de sufijo excepto. Al habilitar la conversión o compresión de formatos de datos, Firehose añadirá una extensión de archivo en función de la configuración. En la siguiente tabla se explica la extensión de archivo predeterminada adjunta por Firehose:
| Configuración | Extensión de archivo |
|---|---|
| Conversión de formato de datos: Parquet | .parquet |
| Conversión de formato de datos: ORC | .orc |
| Compresión: Gzip | .gz |
| Compresión: Zip | .zip |
| Compresión: rápida | .snappy |
| Compresión: Hadoop-Snappy | .hsnappy |
También puedes especificar la extensión de archivo que prefieras en la consola o la API de Firehose. La extensión del archivo debe empezar con un punto (.) y puede contener los caracteres permitidos: 0-9a-z! -_.*' (). La extensión del archivo no puede superar los 128 caracteres.
nota
Al especificar una extensión de archivo, esta anulará la extensión de archivo predeterminada que Firehose añada cuando esté habilitada la conversión o compresión de formatos de datos.
Configura la rotación del índice para el servicio OpenSearch
Para el destino del OpenSearch servicio, puede especificar una opción de rotación de índices basada en el tiempo entre una de las cinco opciones siguientes:NoRotation,OneHour, OneDayOneWeek, oOneMonth.
Según la opción de rotación que elija, Amazon Data Firehose añade una parte de la marca horaria de llegada UTC al nombre de índice especificado. También rota la marca de tiempo añadida en consecuencia. El siguiente ejemplo muestra el nombre del índice resultante en OpenSearch Service para cada opción de rotación del índice, donde es el nombre del índice especificado myindex y la marca de tiempo de llegada. 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
Con la opción OneWeek, Data Firehose crea índices automáticamente con el formato <AÑO>-w<NÚMERO DE LA SEMANA> (por ejemplo, 2020-w33), donde el número de la semana se calcula según la hora UTC y las siguientes convenciones de EE. UU.:
-
Una semana comienza el domingo
-
La primera semana del año es la primera semana que contiene un sábado de este año
Comprenda la entrega en todas las AWS cuentas y regiones
Amazon Data Firehose admite la entrega de datos a destinos de punto final HTTP en todas las AWS cuentas. La transmisión Firehose y el punto final HTTP que elijas como destino pueden pertenecer a cuentas diferentes AWS .
Amazon Data Firehose también admite la entrega de datos a destinos de punto final HTTP en AWS todas las regiones. Puede entregar datos desde una transmisión de Firehose en una AWS región a un punto final HTTP en otra AWS región. También puede entregar datos desde una transmisión Firehose a un destino de punto final HTTP fuera de AWS las regiones, por ejemplo, a su propio servidor local, configurando la URL del punto de enlace HTTP en el destino deseado. En estos casos, se agregan cargos de transferencia de datos adicionales a los gastos de entrega. Para obtener más información, consulte la sección Transferencia de datos
Registros duplicados
Amazon Data Firehose utiliza la at-least-once semántica para la entrega de datos. En algunas circunstancias, como cuando se agota el tiempo de espera para la entrega de datos, los reintentos de entrega por parte de Amazon Data Firehose podrían introducir duplicados si finalmente se aprueba la solicitud de entrega de datos original. Esto se aplica a todos los tipos de destinos compatibles con Amazon Data Firehose.
Pausa y reanuda una transmisión de Firehose
Después de configurar una transmisión Firehose, los datos disponibles en la fuente de transmisión se envían continuamente al destino. Si se produce alguna situación en la que el destino del flujo no esté disponible temporalmente (por ejemplo, durante las operaciones de mantenimiento planificadas), puede que desee pausar temporalmente la entrega de datos y reanudarla cuando el destino vuelva a estar disponible. En las siguientes secciones se muestra cómo hacerlo:
importante
Si utiliza el enfoque que se describe a continuación para pausar y reanudar una transmisión, después de reanudarla, verá que se envían pocos registros al depósito de errores de Amazon S3, mientras que el resto de la transmisión continúa enviándose al destino. Esta es una limitación conocida del enfoque y se debe a que se registra como fallido un número reducido de registros que antes no se podían entregar al destino tras varios reintentos.
Entender cómo Firehose gestiona los fallos de entrega
Cuando configuras una transmisión Firehose, para muchos destinos, como OpenSearch Splunk y puntos de conexión HTTP, también configuras un bucket de S3 en el que se pueden hacer copias de seguridad de los datos que no se puedan entregar. Para obtener más información sobre cómo Firehose hace copias de seguridad de los datos en caso de entregas fallidas, consulte Gestión de errores en la entrega de datos. Para obtener más información sobre cómo conceder acceso a los buckets de S3 donde se pueden hacer copias de seguridad de los datos que no se puedan entregar, consulte Otorgar a Firehose Access to an Amazon S3 Destination. Cuando Firehose (a) no entrega los datos al destino de la transmisión y (b) no escribe los datos en el depósito S3 de respaldo en caso de entregas fallidas, detiene la entrega de la transmisión hasta que los datos puedan entregarse al destino o escribirse en la ubicación de S3 de respaldo.
Pausar una transmisión de Firehose
Para pausar la entrega de transmisiones en Firehose, primero elimine los permisos para que Firehose escriba en la ubicación de respaldo de S3 en caso de entregas fallidas. Por ejemplo, si quieres pausar la transmisión de Firehose con un OpenSearch destino, puedes hacerlo actualizando los permisos. Para obtener más información, consulte Otorgar a Firehose acceso a un destino de OpenSearch servicio público.
Elimine el permiso "Effect": "Allow" de la acción s3:PutObject y agregue de forma explícita una declaración que aplique el permiso Effect": "Deny" en la acción s3:PutObject para el bucket de S3 que se utiliza para hacer copias de seguridad de las entregas con errores. A continuación, desactiva el destino de la transmisión (por ejemplo, desactiva el OpenSearch dominio de destino) o quita los permisos para que Firehose escriba en el destino. Para actualizar los permisos de otros destinos, consulte la sección correspondiente a su destino en Controlling Access with Amazon Data Firehose. Tras completar estas dos acciones, Firehose dejará de emitir transmisiones y podrás monitorizarlo mediante CloudWatch las métricas de Firehose.
importante
Al pausar la entrega de transmisiones en Firehose, debe asegurarse de que la fuente de la transmisión (por ejemplo, en Kinesis Data Streams o en Managed Service for Kafka) esté configurada para conservar los datos hasta que se reanude la entrega de la transmisión y los datos se entreguen al destino. Si la fuente es DirectPut, Firehose conservará los datos durante 24 horas. Se pueden producir pérdidas de datos si no se reanuda el flujo y no se entregan los datos antes de que venza el periodo de retención de datos.
Reanudación de una transmisión de Firehose
Para reanudar la entrega, primero revierta el cambio realizado anteriormente al destino de la transmisión activando el destino y asegurándose de que Firehose tenga los permisos para entregar la transmisión al destino. A continuación, revierta los cambios llevados a cabo anteriormente en los permisos aplicados al bucket de S3 para hacer copias de seguridad de las entregas con errores. Es decir, aplique el permiso "Effect": "Allow" a la acción s3:PutObject y elimine el permiso "Effect": "Deny" de la acción s3:PutObject para el bucket de S3 que se utiliza para hacer copias de seguridad de las entregas con errores. Por último, monitorea el uso de CloudWatch métricas de Firehose para confirmar que la transmisión se entrega al destino. Para ver y solucionar los errores, utiliza la supervisión de Amazon CloudWatch Logs para Firehose.
