Consideraciones y limitaciones

Rendimiento: si utiliza Direct PUT como origen para entregar datos en las tablas de Apache Iceberg, el rendimiento máximo por flujo es de 5 MIB/segundo en las regiones Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Oregón) y Europa (Irlanda), y de 1 MIB/segundo en todas las Regiones de AWS. Si desea insertar datos en las tablas de Iceberg sin actualizaciones ni eliminaciones, y desea aumentar el rendimiento del flujo, puede utilizar el Formulario de límites de Firehose para solicitar un aumento del límite de rendimiento.

También puede establecer el indicador AppendOnly en True para insertar datos únicamente y no realizar actualizaciones ni eliminaciones. Si establece el indicador AppendOnly en True, Firehose se amplía automáticamente para adaptarse al rendimiento. Por ahora, solo se puede establecer este indicador con la operación de API CreateDeliveryStream.

Si un flujo Direct PUT sufre una limitación debido a volúmenes de ingesta de datos más altos que superan la capacidad de rendimiento de un flujo de Firehose, este aumenta automáticamente el límite de rendimiento del flujo hasta que se contenga la limitación. Según el aumento del rendimiento y la limitación, Firehose podrá tardar más en aumentar el rendimiento de un flujo hasta los niveles deseados. Por este motivo, continúe reintentando los registros de ingesta de datos fallidos. Si espera que el volumen de datos aumente en cantidades grandes y repentinas, o si su nuevo flujo necesita un rendimiento superior al límite del predeterminado, solicite aumentar el límite de rendimiento.

Transacciones por segundo (TPS) de S3: si desea optimizar el rendimiento de S3 con Kinesis Data Streams o Amazon MSK como origen, recomendamos segmentar el registro de origen con una clave de partición adecuada. De este modo, los registros de datos que se enrutan a la misma tabla de Iceberg se asignan a uno o pocos segmentos de origen conocidos como particiones. En lo posible, distribuya los registros de datos que pertenezcan a diferentes tablas de Iceberg de destino en diferentes segmentos o particiones, de modo que pueda utilizar todo el rendimiento agregado disponible en todos los segmentos o particiones del tema o flujo de origen.

Columnas: para los nombres y valores de las columnas, Firehose solo toma el primer nivel de nodos de un JSON anidado de varios niveles. Por ejemplo, Firehose selecciona los nodos que están disponibles en el primer nivel, incluido el campo de posición. Los nombres de las columnas y los tipos de los datos de origen deben coincidir con los de las tablas de destino para que Firehose los entregue correctamente. En este caso, Firehose espera que, en las tablas de Iceberg, haya una columna de tipo de datos de estructura o de mapa que coincida con el campo de posición. Firehose admite 16 niveles de anidación. A continuación, se muestra un ejemplo de un JSON anidado.

{
   "version":"2016-04-01",
   "deviceId":"<solution_unique_device_id>",
   "sensorId":"<device_sensor_id>",
   "timestamp":"2024-01-11T20:42:45.000Z",
   "value":"<actual_value>",
   "position":{
      "x":143.595901,
      "y":476.399628,
      "z":0.24234876
   }
} 

Si los nombres de las columnas o los tipos de datos no coinciden, Firehose genera un error y envía los datos al bucket de errores de S3. Si todos los nombres de las columnas y los tipos de datos coinciden en las tablas de Apache Iceberg, pero hay un campo adicional en el registro de origen, Firehose omite el nuevo campo.

Un objeto JSON por registro: solo puede enviar un objeto JSON en un registro de Firehose. Si agrega y envía varios objetos JSON dentro de un registro, Firehose genera un error y envía los datos al bucket de errores de S3. Si agrega registros con KPL e ingiere datos en Firehose con Amazon Kinesis Data Streams como origen, Firehose se desagrega automáticamente y usa un objeto JSON por registro.

Optimización de la compactación y el almacenamiento: cada vez que escribe a las tablas Iceberg con Firehose, este archiva y genera instantáneas, archivos de datos y elimina archivos. Tener varios archivos de datos aumenta la sobrecarga de metadatos y afecta al rendimiento de lectura. Para obtener un rendimiento eficaz de las consultas, puede considerar una solución que recoja periódicamente archivos de datos pequeños y los reescriba en un menor número de archivos de datos más grandes. Este proceso se denomina compactación. AWS Glue Data Catalog admite la compactación automática de las tablas de Apache Iceberg. Para obtener más información, consulte Administración de compactación en la Guía del usuario de AWS Glue. Para obtener más información, consulte Compactación automática de tablas de Apache Iceberg. Por otro lado, puede ejecutar el comando de Athena Optimize para realizar la compactación de forma manual. Para obtener más información sobre el comando Optimize, consulte Athena Optimize.

Además de compactar los archivos de datos, también puede optimizar el consumo de almacenamiento con la declaración VACUUM, que realiza el mantenimiento de las tablas de Apache Iceberg, como la caducidad de las instantáneas y la eliminación de un archivo huérfano. Como alternativa, puede utilizar AWS Glue Data Catalog que también permite optimizar las tablas gestionadas de Apache Iceberg, ya que elimina automáticamente los archivos de datos, los archivos huérfanos y las instantáneas caducadas que ya no se necesitan. Para obtener más información, consulte esta entrada del blog sobre Optimización del almacenamiento de las tablas de Apache Iceberg.

No se permite la compatibilidad con el origen Amazon MSK Serverless para las tablas de Apache Iceberg como destino.

En una operación de actualización, Firehose genera un archivo de eliminación seguido de una operación de inserción. La generación de archivos de eliminación conlleva cargos por parte de Amazon S3.

Firehose no recomienda utilizar varios flujos de Firehose para escribir datos en la misma tabla de Apache Iceberg. Esto se debe a que Apache Iceberg se basa en el control de concurrencia optimista (OCC). Si varios flujos de Firehose intentan escribir simultáneamente en una sola tabla de Iceberg, solo un flujo conseguirá confirmar los datos en un momento dado. Los otros flujos que no se confirmen se deshabilitan y vuelven a intentar la operación de confirmación hasta que el tiempo de reintento configurado caduce. Una vez agotado el tiempo de reintento, los datos y las claves del archivo de eliminación (rutas de Amazon S3) se envían al prefijo de error de Amazon S3 configurado.

La versión compatible de la biblioteca de Iceberg con Firehose es la 1.5.2.

En una entrega de datos cifrados a las tablas de Amazon S3, debe configurar los parámetros de AWS Key Management Service en las tablas de Amazon S3 y no en la configuración de Firehose. Si configura los parámetros de AWS Key Management Service en Firehose para entregar datos cifrados a las tablas de Amazon S3, Firehose no podrá usarlos para realizar el cifrado. Para obtener más información, consulte Uso del cifrado en el servidor con las claves de AWS KMS.

Los flujos de Firehose solo permiten la entrega a bases de datos y tablas que se crean a través de la API de GlueCatalog de Iceberg. No se permite la entrega a bases de datos y tablas que se crean mediante Glue SDK. Recuerde que un guión (-) no es un carácter compatible con la base de datos y el nombre de la tabla en la biblioteca de Iceberg. Para obtener más información, consulte las expresiones regulares de la base de datos de Glue y expresiones regulares de la tabla de Glue que son compatibles con la biblioteca de Iceberg.

Todos los archivos escritos por Firehose se calculan con los segmentos que se encuentran en el registro. Esto también es válido para los archivos eliminados. No se permiten las eliminaciones globales, como la escritura de archivos de eliminación sin segmentos para una tabla segmentada.