Sirven para diferentes propósitos. Pero si su objetivo es solo inyectar registros para almacenar (y transformar opcionalmente) en S3, Redshift o ElasticSearch, entonces la principal diferencia es la simplicidad .

PUT directo u otras fuentes

Permite la inyección "manual" directa de registros en la firehose contra incendios. Para la ingestión, usted o su aplicación deben usar put-record o put-record-batch .

Estas llamadas a API son muy simples y fáciles de usar, en cierto sentido, no necesita administrar la partición de registros. Porque solo les proporciona el nombre de la firehose de incendios y los registros que se escribirán. No se vuelve a adquirir nada más.

Además, firehose es básicamente sin servidor, por lo que no necesita administrar su escalamiento ni aprovisionar su rendimiento. Todo se hace automáticamente para usted.

Sin embargo, firehose no es completamente "en tiempo real" . Debido a su tiempo de espera y almacenamiento en búfer, sus registros siempre se retrasan.

Flujo de datos de Kinesis

Si enfrenta su firehose con kinesis stream , entonces debe inyectar registros en la transmisión. Para eso usas put-record y o poner registros . Si observa estas llamadas de API, son más complicadas ya que debe administrar key partitioning usted mismo. Tienes que hacerlo correctamente, ya que de lo contrario terminarás con fragmentos calientes/fríos y te preocupará cómo solucionarlo.

Además data streams no son sin servidor en el sentido de que no se escalan automáticamente . Tienes que administrar su rendimiento tú mismo. Esto significa que debe calcular y aprovisionar la cantidad de fragmentos que necesita. Si lo haces incorrectamente, tendrás problemas.

Conclusiones

Elija Direct Put to firehose si solo tiene como objetivo almacenar (transformar) sus registros en destinos de almacenamiento admitidos.

Elija usar Kinesis Data Stream frente a firehose si necesita no solo almacenar, sino también hacer otras cosas con sus registros en tiempo real . Esto se debe a que puede tener otros consumidores de flujo además de firehose que sí requieren datos en tiempo real.

La principal diferencia (asumiendo que no está adjuntando nada más a la transmisión) es que necesita un ticket de soporte para escalar Firehose.

Según los documentos :

Cuando Direct PUT está configurado como fuente de datos, cada flujo de entrega de Kinesis Data Firehose proporciona la siguiente cuota combinada para las solicitudes PutRecord y PutRecordBatch:

• Para EE. UU. Este (Norte de Virginia), EE. UU. Oeste (Oregón) y Europa (Irlanda): 5000 registros/segundo, 2000 solicitudes/segundo y 5 MiB/segundo.

• Para EE. UU. Este (Ohio), EE. UU. Oeste (Norte de California), AWS GovCloud (EE. UU. Este), AWS GovCloud (EE. UU. Oeste), Asia Pacífico (Hong Kong), Asia Pacífico (Mumbai), Asia Pacífico (Seúl), Asia Pacífico (Singapur), Asia Pacífico (Sídney), Asia Pacífico (Tokio), Canadá (Central), Europa (Fráncfort), Europa (Londres), Europa (París), Europa (Estocolmo), Oriente Medio (Bahréin) y América del Sur (São Paulo): 1000 registros/segundo, 1000 solicitudes/segundo y 1 MiB/segundo.

Para solicitar un aumento de la cuota, utilice el formulario de límites de Amazon Kinesis Data Firehose.

Los flujos de Kinesis, en comparación, le permiten controlar el escalado en función de la cantidad de fragmentos: 1000 registros por segundo o 1 MB/segundo de ingesta por fragmento. Si descubre que necesita más capacidad, puede aumentar fácilmente la cantidad de fragmentos.

Otra diferencia es que Firehose solo retiene registros durante 24 horas si el destino no está disponible, mientras que Kinesis Stream se puede configurar para retener registros hasta por una semana.

Para una arquitectura robusta, recomiendo usar una combinación de flujos de Kinesis para ingesta y Firehose para procesamiento por lotes y escritura en el destino.