Le blob store d'Apache Flink conserve les blobs inutilisés pendant 30 minutes avant nettoyage

Le store BLOB d'Apache Flink contient les fichiers binaires dont un cluster en fonctionnement ne peut pas se passer : les JAR que les utilisateurs téléversent pour exécuter leurs jobs, les messages surdimensionnés échangés entre tâches, et les logs des TaskManager que l'interface Web affiche à la demande. Avant la version 1.4, ce store présentait trois modes de défaillance que la communauté a ensuite traités dans FLIP-19. Un même fichier pouvait finir stocké plus d'une fois. Les fichiers dont plus aucune tâche n'avait besoin restaient sur le disque. Et le contenu des fichiers pouvait être modifié sans que rien ne le remarque.

Aucun de ces problèmes ne se manifeste de lui-même. Un JAR dupliqué gaspille de l'espace en silence. Un blob orphelin ne devient problématique que lorsque le disque se remplit. Un fichier corrompu se manifeste par un job en échec, longtemps après que ce qui l'a écrit a terminé. La refonte, donc, ne portait pas sur le débit ni sur la latence. Elle portait sur un entretien qui avait dérivé.

Trois composants, trois rôles

La nouvelle conception répartit le travail en trois, et chaque pièce a un périmètre étroit.

Composant	Où il s'exécute	Rôle
BlobServer	De manière centralisée, pour tout le cluster	Stocke et sert les blobs à partir d'une copie locale et d'une copie de sauvegarde
BlobCache	Sur chaque TaskManager	Sert les lectures locales, récupère les fichiers manquants depuis BlobServer, vide son propre store
BlobClient	À chaque requête	Ouvre une connexion à BlobServer, suit la requête, confirme la livraison

BlobServer conserve deux copies de tout : un store local pour des lectures rapides et un store de sauvegarde pour la récupération. Les fichiers arrivent sous une convention de chemin fixe, <path>/<jobId>/<BlobKey>, de sorte que le job et l'identité d'un blob sont lisibles depuis son emplacement. Un téléversement va d'abord dans le store local puis se synchronise vers la sauvegarde, ce qui est censé apporter de la durabilité sans placer l'écriture de sauvegarde sur le chemin de l'appelant. Une lecture vérifie d'abord le local et ne recourt à la sauvegarde que lorsque le fichier est manquant.

BlobCache s'exécute sur chaque TaskManager et reproduit la même structure de chemins. Il peut lire le store de sauvegarde central mais pas y écrire. Lorsqu'il a besoin d'un fichier qu'il ne possède pas, il demande un transfert à BlobServer. Chaque cache décide lui-même quand effacer les fichiers dont il n'a plus besoin, ce qui maintient les décisions de nettoyage sur la machine qui possède le disque.

BlobClient est le côté requête. Il ouvre une connexion dédiée à BlobServer pour chaque téléversement ou téléchargement, enregistre la requête, et accompagne le transfert jusqu'à ce que la livraison du fichier soit confirmée.

Le comptage de références et la pause délibérée avant la suppression

Supprimer un blob au moment où son dernier lecteur connu a terminé, c'est ainsi qu'un cluster perd un fichier qu'une autre tâche s'apprêtait à récupérer. FLIP-19 y répond par le comptage de références : le système suit combien de tâches détiennent actuellement un fichier, et la suppression attend que le compte atteigne zéro. Même à zéro, le fichier ne disparaît pas. Il demeure pendant un intervalle configurable, et une nouvelle requête durant cette fenêtre le maintient en vie.

La fenêtre a un coût. Chaque blob conservé représente de l'espace disque que le cluster ne peut pas utiliser pour autre chose, et un cluster occupé conserve des fichiers au-delà de leur durée de vie utile, délibérément. La valeur par défaut a évolué vers une récupération plus rapide de cet espace : blob.retention.interval vaut désormais 30 minutes par défaut, contre une heure auparavant. La source ne donne aucun chiffre sur la quantité de stockage libérée par l'intervalle plus court, il faut donc lire ce nombre comme un réglage et non comme un résultat.

Des fichiers différents reçoivent des traitements différents, ce qui explique pourquoi un intervalle unique doit tous les couvrir.

Type de blob	Objet	Durée de vie
Fichiers JAR	Code du programme utilisateur	Lié au job ; nettoyé une fois le job terminé
Messages RPC	Communication entre les tâches	Brefs ; supprimés après usage
Fichiers de log	Surveillance système et interface Web	Stockés à la demande, nettoyés après usage

Une requête de log montre le schéma en miniature. L'interface Web demande les logs d'un TaskManager, le TaskManager les téléverse vers BlobServer, et l'interface les télécharge depuis là et les affiche. Comme plus personne n'a besoin du fichier ensuite, il peut être nettoyé plutôt que conservé.

Les messages volumineux suivent le même chemin. L'émetteur écrit la charge utile vers BlobServer, le destinataire la télécharge, et le compteur de références diminue une fois le message traité. Quand tous les destinataires ont confirmé, le blob rejoint la file de nettoyage et attend sa passe programmée.

Sommes de contrôle et store à deux niveaux : où s'arrêtent les garanties

Le travail sur l'intégrité est la partie de FLIP-19 qui se manifeste le moins souvent dans l'exploitation quotidienne, et celle qui fait gagner le plus de temps lorsqu'elle se manifeste. Le système vérifie une somme de contrôle chaque fois qu'il lit ou copie un fichier, de sorte qu'une modification accidentelle se traduit par une discordance plutôt que par un job qui meurt une heure plus tard sans cause évidente. Combiné à l'ordre d'écriture local puis sauvegarde, un seul disque perdu ne signifie plus qu'un blob dont le cluster a encore besoin a disparu.

Ces garanties méritent d'être distinguées des affirmations qui les entourent. Une somme de contrôle confirme qu'un fichier n'a pas changé depuis son écriture ; la source décrit la vérification comme une protection contre les modifications accidentelles et ne l'étend pas à quoi que ce soit de délibéré. La mise en miroir protège contre une copie endommagée ou manquante, mais la source ne dit pas si les deux copies sont jamais comparées l'une à l'autre, ni jusqu'où le store local peut prendre de l'avance sur la sauvegarde avant qu'une synchronisation s'achève, ni ce que fait une reprise de BlobServer lorsque le store local contient des fichiers que la sauvegarde n'a pas vus.

Cette dernière lacune compte parce que la reprise de BlobServer est décrite comme un transfert en quatre étapes, et la source n'énumère pas ces étapes. L'intention derrière la refonte est plus facile à cerner : FLIP-19 visait à corriger des problèmes de concurrence et de nettoyage dans l'architecture d'origine et à laisser de la place à des travaux ultérieurs, notamment la gestion des messages RPC volumineux. L'endroit où l'implémentation trace la frontière entre ce qui est couvert et ce qui ne l'est pas réside dans la configuration et le code, pas dans une vue d'ensemble.