El almacén de blobs de Apache Flink retiene blobs sin usar 30 minutos antes de la limpieza

El almacén de BLOBs de Apache Flink contiene los archivos binarios sin los que un clúster en funcionamiento no puede operar: los JAR que los usuarios suben para ejecutar sus trabajos, los mensajes de gran tamaño que se intercambian entre tareas y los registros de los TaskManager que la interfaz web muestra a petición. Antes de la versión 1.4, ese almacén tenía tres modos de fallo que la comunidad abordó después en FLIP-19. Un mismo archivo podía acabar almacenado más de una vez. Los archivos que ninguna tarea necesitaba ya permanecían en disco. Y el contenido de los archivos podía modificarse sin que nada lo advirtiera.

Ninguno de esos problemas se anuncia por sí solo. Un JAR duplicado desperdicia espacio en silencio. Un blob huérfano solo importa cuando el disco se llena. Un archivo corrupto se manifiesta como un trabajo fallido, mucho después de que lo que lo escribió haya terminado. El rediseño, por tanto, no trataba sobre el rendimiento ni la latencia. Trataba sobre un mantenimiento que se había desviado.

Tres componentes, tres funciones

El nuevo diseño divide el trabajo en tres vías, y cada pieza tiene un cometido acotado.

Componente	Dónde se ejecuta	Función
BlobServer	De forma central, para todo el clúster	Almacena y sirve blobs desde una copia local más una copia de respaldo
BlobCache	En cada TaskManager	Sirve las lecturas locales, obtiene del BlobServer los archivos que faltan y limpia su propio almacén
BlobClient	Por cada solicitud	Abre una conexión al BlobServer, registra la solicitud y confirma la entrega

BlobServer conserva dos copias de todo: un almacén local para lecturas rápidas y un almacén de respaldo para la recuperación. Los archivos se ubican bajo una convención de rutas fija, <path>/<jobId>/<BlobKey>, de modo que el trabajo y la identidad de un blob son legibles a partir de su ubicación. Una carga va primero al almacén local y luego se sincroniza con el respaldo, lo que pretende aportar durabilidad sin interponer la escritura de respaldo en el camino del solicitante. Una lectura comprueba primero lo local y recurre al respaldo solo cuando falta el archivo.

BlobCache se ejecuta en cada TaskManager y replica la misma estructura de rutas. Puede leer el almacén de respaldo central, pero no escribir en él. Cuando necesita un archivo que no tiene, solicita una transferencia al BlobServer. Cada caché decide por sí misma cuándo eliminar los archivos que ya no necesita, lo que mantiene las decisiones de limpieza en la máquina que posee el disco.

BlobClient es el lado de las solicitudes. Abre una conexión dedicada al BlobServer por cada carga o descarga, registra la solicitud y permanece con la transferencia hasta que se confirma la entrega del archivo.

Conteo de referencias y la pausa deliberada antes de la eliminación

Eliminar un blob en el momento en que su último lector conocido termina es la forma en que un clúster pierde un archivo que otra tarea estaba a punto de obtener. FLIP-19 responde a eso con el conteo de referencias: el sistema rastrea cuántas tareas mantienen actualmente un archivo, y la eliminación espera a que el conteo llegue a cero. Incluso en cero, el archivo no desaparece. Permanece durante un intervalo configurable, y una nueva solicitud dentro de esa ventana lo mantiene vivo.

La ventana tiene un costo. Cada blob retenido es espacio en disco que el clúster no puede usar para otra cosa, y un clúster muy ocupado conserva archivos más allá de su vida útil a propósito. El valor predeterminado se ha inclinado hacia recuperar ese espacio antes: blob.retention.interval ahora tiene un valor predeterminado de 30 minutos, frente a una hora. El material de origen no ofrece cifras sobre cuánto almacenamiento libera el intervalo más corto, así que léase el número como una configuración y no como un resultado.

Distintos archivos reciben un trato distinto, y por eso un único intervalo tiene que abarcarlos a todos.

Tipo de blob	Propósito	Tiempo de vida
Archivos JAR	Código del programa de usuario	Vinculado al trabajo; se limpia una vez que el trabajo termina
Mensajes RPC	Comunicación entre tareas	Breve; se eliminan después de su uso
Archivos de registro	Monitoreo del sistema y la interfaz web	Se almacenan a petición y se limpian después de su uso

Una solicitud de registros muestra el patrón en miniatura. La interfaz web pide los registros de los TaskManager, el TaskManager los sube al BlobServer, y la interfaz los descarga desde allí y los representa. Como nadie necesita el archivo después de eso, puede limpiarse en lugar de conservarse.

Los mensajes de gran tamaño siguen la misma ruta. El emisor escribe la carga útil en el BlobServer, el receptor la descarga, y el conteo de referencias disminuye una vez que el mensaje se ha gestionado. Cuando todos los receptores han confirmado, el blob se une a la cola de limpieza y espera su pasada programada.

Sumas de verificación y el almacén de dos niveles: dónde terminan las garantías

El trabajo de integridad es la parte de FLIP-19 que aparece con menos frecuencia en la operación diaria, y la parte que más tiempo ahorra cuando lo hace. El sistema verifica una suma de comprobación cada vez que lee o copia un archivo, de modo que una modificación accidental sale a la superficie como una discrepancia en lugar de como un trabajo que muere una hora después sin causa evidente. Combinado con el orden de escritura local y luego respaldo, un solo disco perdido ya no significa que un blob que el clúster aún necesita haya desaparecido.

Vale la pena separar esas garantías de las afirmaciones que las rodean. Una suma de comprobación confirma que un archivo no ha cambiado desde que se escribió; la fuente describe la verificación como protección contra modificaciones accidentales y no la extiende a nada deliberado. La réplica protege contra una copia dañada o ausente, pero el material de origen no dice si las dos copias se comparan alguna vez entre sí, cuánto puede adelantarse el almacén local respecto al respaldo antes de que se complete una sincronización, ni qué hace un traspaso de BlobServer cuando el almacén local contiene archivos que el respaldo no ha visto.

Esa última laguna importa porque la toma de control del BlobServer se describe como un traspaso de cuatro pasos, y el material de origen no enumera los pasos. La intención detrás del rediseño es más fácil de precisar: FLIP-19 se propuso corregir problemas de concurrencia y limpieza en la arquitectura original y dejar espacio para trabajos posteriores, incluido el manejo de mensajes RPC de gran tamaño. Dónde traza la implementación su línea entre lo cubierto y lo no cubierto vive en la configuración y el código, no en una visión general.