iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Sí: Kafka puede transportar los bytes originales de un PDF, ZIP u otro archivo. Para conservar también su nombre, envíalo por separado como metadato del record —por ejemplo, en un header— y recupéralo explícitamente al consumir. El nombre no se añade automáticamente al contenido binario.
Qué conserva Kafka: los bytes y el nombre son datos distintos
En el protocolo de Kafka, el valor del record es el contenido del mensaje representado como una secuencia opaca de bytes; no tiene que ser texto legible. La guía del protocolo de Apache Kafka lo describe como “The value is the actual message contents as an opaque byte array.” Por eso, un productor puede enviar el contenido de un archivo como value sin convertirlo en texto.
Ese value, por sí solo, no identifica el nombre original del archivo. Incluye el nombre en un metadato separado y acuerda una convención que productor y consumidor entiendan. Un header llamado filename es una opción; otra es un envelope estructurado que contenga el nombre y los bytes, aunque en ese caso habrá que definir cómo se representa el contenido binario.
Recommended Free Tools
Cómo diseñar los metadatos del archivo
Además del nombre, considera incluir solo los campos que el consumidor necesita. Una convención puede contemplar:
#1 Best Overall
filename: nombre original, sin asumir que una ruta local del productor sea válida en el destino.content-type: tipo MIME si la aplicación necesita conocerlo.content-length: tamaño esperado para validar la escritura.checksumofile-id: útiles para verificar integridad o correlacionar el archivo con otros eventos.
Define cómo se tratarán nombres Unicode, separadores de ruta, caracteres especiales y nombres duplicados. Un nombre recibido debe considerarse metadato no confiable: valida qué nombres y ubicaciones puede crear el consumidor, en vez de usarlo sin restricciones como una ruta de escritura.
Kafka admite headers de record. En Kafka Connect, las transformaciones InsertHeader y HeaderFrom permiten insertar headers o copiar/mover campos entre el valor, la clave y los headers, según la configuración. KIP-440 explica que los headers también pueden llevar metadatos como el tipo de contenido. Consulta la documentación de headers y transformaciones de Kafka Connect y KIP-440.
Flujo de envío y recepción
- Productor: lee el archivo como bytes, sin decodificarlo como texto, y publica ese byte array como value del record.
- Metadatos: añade el nombre original en un header como
filename, o usa un envelope definido por la aplicación. Mantén la misma convención en todos los productores y consumidores. - Consumidor: obtiene el value como bytes y lee el header o campo del envelope para conocer el nombre. Escribe los bytes en un destino autorizado, aplicando validación de nombre y ruta.
- Validación: compara el tamaño y, si se incluyó, el checksum del archivo antes y después de la transferencia. Esta comprobación debe implementarla la aplicación; no se realiza automáticamente por el hecho de usar Kafka.
Si el flujo usa Kafka Connect, revisa el converter y cada SMT concretos de ambos extremos. Que Kafka admita headers no demuestra que cualquier combinación de connector y converter los conserve de extremo a extremo: verifica esa configuración con un mensaje representativo.
Cuándo una conversión a Base64 cambia lo que recibe el consumidor
No conviertas bytes a una cadena solo para facilitar el transporte. La transformación Cast de Kafka Connect convierte un valor binario a string mediante Base64. El resultado es una representación textual codificada, no el archivo original en forma de texto legible. Si el consumidor espera los bytes originales, evita una cadena de conversiones o transformaciones que altere su representación, o decodifica Base64 explícitamente en el extremo que corresponda.
Rank #3
La documentación de transformaciones de Kafka Connect describe este comportamiento. Comprueba el converter, la transformación y el tipo que finalmente recibe la aplicación: no basta con que el archivo haya empezado como un byte array.
Límites de tamaño: comprueba productor, topic, broker y consumo
El tamaño permitido depende de la configuración y la versión. En la documentación de configuración de broker para Apache Kafka 4.1, message.max.bytes tiene un valor predeterminado de 1,048,588 bytes. El límite puede configurarse para un topic mediante max.message.bytes. Estos valores documentados no deben asumirse para otras versiones ni para un servicio administrado; consulta la configuración efectiva de tu cluster.
Rank #4
- Metamorphosis: Franz Kafka (Little Clothbound Classics)
La misma documentación de Kafka 4.1 da a replica.fetch.max.bytes un valor predeterminado de 1 MiB como objetivo de fetch. Aclara también que, para permitir el progreso, el primer batch de records de una partición puede devolverse aunque sea mayor. Por tanto, ese parámetro no equivale necesariamente a un rechazo absoluto del mensaje. Revisa la configuración de broker de Kafka 4.1 junto con los límites del productor, del topic y de los consumidores.
Para diagnosticar fallos, comprueba qué componente rechaza o no puede procesar el record: productor, broker, replicación, connector o aplicación consumidora. Alinea sus límites y considera también memoria, concurrencia y retención. No hay un tamaño “seguro” universal: el efecto depende del cluster, el cliente, la compresión y el patrón de consumo.
Best Value
¿Enviar los bytes por Kafka o publicar una referencia?
Para archivos pequeños, poco frecuentes y que caben en los límites efectivos de la instalación, un record con bytes y metadatos puede ser una solución sencilla. Si los archivos son grandes o frecuentes, evalúa guardarlos en almacenamiento de objetos y publicar en Kafka una referencia durable con los metadatos necesarios. No existe un umbral universal que determine cuándo conviene cambiar de opción; la decisión depende del workload y debe validarse en la instalación concreta.
Al comparar ambos diseños, considera:
- tamaño y frecuencia de los archivos, y latencia que exige la aplicación;
- facilidad de reintento y de reensamblaje cuando falla una parte del flujo;
- retención y replicación de datos en Kafka frente al ciclo de vida y el acceso al objeto externo;
- coste de almacenamiento y consumo de ancho de banda;
- cómo garantizar la coherencia entre el objeto almacenado y el evento Kafka que lo referencia, incluidos errores parciales y reintentos.
Son factores de arquitectura, no resultados que puedan resolverse con un único valor de configuración. Prueba el diseño con tamaños, frecuencias, fallos y condiciones de consumo representativos.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
