Consideraciones y limitaciones

Rendimiento: si utiliza Direct PUT como fuente para entregar datos a las tablas de Apache Iceberg, el rendimiento máximo por transmisión es de 5 MiB/second en las regiones EE.UU. Este (Norte de Virginia), EE.UU. Oeste (Oregón) y Europa (Irlanda) y 1 MiB/second en todas las demás. Regiones de AWS Si quieres insertar datos en las tablas de Iceberg sin actualizaciones ni eliminaciones y quieres aumentar el rendimiento de tu transmisión, puedes utilizar el formulario Firehose Limits para solicitar un aumento del límite de rendimiento.

También puede establecer esta opción True si solo desea insertar datos y no realizar actualizaciones ni eliminaciones. AppendOnly Al configurar el AppendOnly indicador enTrue, Firehose escala automáticamente para adaptarse a tu rendimiento. Actualmente, solo puedes configurar este indicador con la operación de la CreateDeliveryStreamAPI.

Si una transmisión Direct PUT sufre una limitación debido a volúmenes de ingesta de datos más altos que superan la capacidad de rendimiento de una transmisión Firehose, Firehose aumenta automáticamente el límite de rendimiento de la transmisión hasta que se contenga la limitación. Dependiendo del aumento del rendimiento y la regulación, Firehose puede tardar más en aumentar el rendimiento de una transmisión hasta los niveles deseados. Por este motivo, siga intentando volver a intentar los registros de ingesta de datos fallidos. Si espera que el volumen de datos aumente en ráfagas grandes y repentinas, o si su nueva transmisión necesita un rendimiento superior al límite de rendimiento predeterminado, solicite aumentar el límite de rendimiento.

Transacciones por segundo (TPS) de S3: para optimizar el rendimiento de S3, si utiliza Kinesis Data Streams o Amazon MSK como fuente, le recomendamos que particione el registro de origen con una clave de partición adecuada. De esta forma, los registros de datos que se enrutan a la misma tabla de Iceberg se asignan a una o varias particiones de origen conocidas como fragmentos. Si es posible, divida los registros de datos que pertenezcan a diferentes tablas de Iceberg de destino en diferentes tablas. partitions/shards, so that you can use all the aggregate throughput available across all the partitions/shards of the source topic/stream

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 datos de los datos de origen deben coincidir exactamente con los de las tablas de destino para que Firehose se 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 depósito 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 agregas y envías varios objetos JSON dentro de un registro, Firehose genera un error y envía los datos al depósito 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 escribes en Iceberg Tables con Firehose, este archiva y genera instantáneas, archivos de datos y elimina archivos. Tener muchos archivos de datos aumenta la sobrecarga de metadatos y afecta al rendimiento de lectura. Para obtener un rendimiento de consultas eficiente, quizás desee 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 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. Como alternativa, puede ejecutar el comando Athena Optimize para realizar la compactación manualmente. 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 instrucción VACUUM, que realiza el mantenimiento de las tablas de Apache Iceberg, como la caducidad de las instantáneas y la eliminación de los archivos huérfanos. Como alternativa, puede utilizar esta herramienta AWS Glue Data Catalog que también permite optimizar las tablas de Apache Iceberg mediante la eliminación automática de los archivos de datos, los archivos huérfanos y las instantáneas caducadas que ya no sean necesarias. Para obtener más información, consulte esta entrada del blog sobre Optimización del almacenamiento de las tablas de Apache Iceberg.

No admitimos el origen Amazon MSK Serverless para Apache Iceberg Tables como destino.

Para una operación de actualización, Firehose coloca un archivo de borrado seguido de una operación de inserción. La eliminación de archivos conlleva cargos por venta de Amazon S3.

Firehose no recomienda utilizar varios flujos de Firehose para escribir datos en la misma tabla de Iceberg de Apache. 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. Las demás secuencias que no se confirmen se desactivan y vuelven a intentar la operación de confirmación hasta que venza el tiempo de reintento configurado. Una vez agotado el tiempo de reintento, los datos y las claves de eliminación de archivos (rutas de Amazon S3) se envían al prefijo de error de Amazon S3 configurado.

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

Para entregar datos cifrados a Amazon S3 Tables, debe configurar AWS Key Management Service los parámetros en Amazon S3 Tables y no en la configuración de Firehose. Si configura AWS Key Management Service parámetros en Firehose para entregar datos cifrados a Amazon S3 Tables, Firehose no podrá usar esos parámetros para cifrar. Para obtener más información, consulte Uso del cifrado del lado del servidor con claves. AWS KMS

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