Un banco recopila datos transaccionales de gran volumen y los transmite a Amazon Kinesis Data Streams mediante PutRecord. Se producen interrupciones de red en determinados momentos, y el ingeniero de datos necesita una semántica de entrega exactly-once en todo el pipeline de procesamiento. ¿Qué enfoque logrará esto?

La semántica exactly-once es difícil de lograr directamente con Kinesis Data Streams debido a su modelo de entrega at-least-once. La estrategia más efectiva es implementar la deduplicación a nivel de aplicación. Al incrustar un ID único (como un UUID o una combinación de ID de origen y marca de tiempo) en cada registro en el origen, la aplicación de procesamiento (por ejemplo, Apache Flink, Spark Streaming) puede identificar y descartar registros duplicados. Las otras opciones son incorrectas porque: La configuración de checkpoint de Amazon Managed Service for Apache Flink ayuda con la tolerancia a fallos y la recuperación, pero no evita la ingestión de duplicados en Kinesis Data Streams o su retransmisión por problemas de red. Diseñar la fuente de datos para evitar la ingestión múltiple es ideal, pero no aborda la posibilidad de duplicados generados por reintentos de PutRecord debido a interrupciones de red, que es el escenario planteado. Dejar de usar Kinesis Data Streams y usar Amazon EMR con Flink/Spark Streaming no resuelve inherentemente el problema de los duplicados si la fuente de datos o la ingestión a EMR también pueden introducir duplicados; la deduplicación a nivel de aplicación sigue siendo necesaria.