Apache Flink veut cesser de copier les données à chaque opérateur. C'est la partie facile

Chaque fois que des données passent entre deux opérateurs chaînés du runtime de streaming d'Apache Flink, le runtime les copie. Ce comportement a été intégré délibérément, pour éviter les problèmes liés aux objets mutables lorsque les backends d'état stockent des objets sur le tas. La copie garantit que ce qu'un opérateur transmet ne sera pas modifié sous les pieds de quiconque pointe encore dessus.

La copie que Flink effectue à chaque opérateur

FLIP-21, une proposition de changement actuellement en discussion, vise à supprimer la majeure partie de ce coût sans renoncer à la garantie. Sa note de synthèse énumère quatre problèmes liés à l'approche actuelle. La copie est coûteuse pour les types complexes tels qu'Avro, Thrift et JSON. Les opérations à clé qui s'exécutent après un shuffle n'ont jamais eu besoin de cette copie, car elles se trouvent en tête de chaîne. L'API DataSet ne copie pas à chaque étape, si bien que les deux moitiés de Flink suivent des règles différentes pour les mêmes données. Et l'option qui contrôle l'ensemble du comportement, enableObjectReuse(), porte un nom trompeur, puisqu'elle ne réutilise pas réellement les objets.

La note décrit ces coûts en termes qualitatifs et n'y associe aucun chiffre de benchmark, de sorte que la proposition n'établit pas combien un pipeline typique perd à cause des copies. Deux des quatre griefs concernent les développeurs plutôt que le débit, et ils comptent pour une raison plus discrète. Deux API dans un même projet qui traitent différemment l'identité des objets rendent difficile le raisonnement sur ce que signifie une référence à un moment donné d'un job. Un flag dont le nom promet la réutilisation mais fait autre chose est pire, car il installe un mauvais modèle mental sur la durée de validité d'une référence.

Trois modes, et le commutateur qui les contrôle

Plutôt que de désactiver partout la copie, FLIP-21 définit trois modes et laisse les utilisateurs choisir leur position sur l'axe sécurité/performance.

Mode	Ce qu'il fait	Ce qu'il coûte
DEFAULT	Crée de nouveaux objets uniquement lors de la désérialisation, puis les transmet sans les copier	Proposé pour devenir la nouvelle norme des API DataStream et DataSet
COPY_PER_OPERATOR	Copie les données entre chaque opérateur	Le comportement actuel de Flink ; sûr, mais plus lent
FULL_REUSE	Réutilise les objets partout où c'est possible	L'option la plus rapide ; exige le plus de vigilance de la part du code utilisateur

DEFAULT est le mode dont la proposition attend qu'il devienne la nouvelle norme pour les API DataStream et DataSet. Il confine la seule copie inévitable à un seul point, la désérialisation, et laisse ensuite les objets circuler sans être touchés. Les deux autres modes l'encadrent. COPY_PER_OPERATOR correspond à ce que fait Flink aujourd'hui. FULL_REUSE pousse la réutilisation aussi loin que possible, en gagnant en rapidité tout en transférant la charge de la gestion des références partagées aux fonctions qui reçoivent les objets. Le risque est inégal : COPY_PER_OPERATOR est lent mais indulgent, tandis que FULL_REUSE échoue de manière dépendante du soin apporté à l'écriture du code environnant.

Un commutateur de configuration associé, pipeline.object-reuse, vaut false par défaut. Le passer à true permet à Flink de réutiliser des objets en interne pour la désérialisation et pour transmettre des données aux fonctions utilisateur. Les notes de la proposition sur ce commutateur se lisent comme une version abrégée du compromis : il réduit la création d'objets et la charge du ramasse-miettes, mais les fonctions doivent gérer correctement les objets réutilisés, les références ne sont pas garanties de rester valides après le retour d'un appel de fonction, et le réglage exige des tests approfondis avant d'approcher la production.

Migration : rupture nette ou rétrocompatibilité

La question plus difficile est de savoir comment les pipelines existants atteignent un nouveau défaut. Deux approches de migration sont sur la table. La communauté penche pour la première, le changement le plus important d'emblée mais le résultat le plus propre ensuite.

La seconde inquiétude porte sur le sort des applications qui s'appuient déjà sur le comportement de copie actuel. La proposition considère ce groupe comme restreint et note que ces utilisateurs peuvent conserver l'ancien mode via la configuration, si bien qu'il n'est pas compté comme un obstacle majeur. La discussion sur la liste de diffusion a été globalement positive. Aucun objectif de disponibilité ni date de publication n'a été fixé.

Pour les équipes qui exploitent Flink aujourd'hui, le changement immédiat est proche de zéro. Jusqu'à l'arrivée d'un nouveau défaut, la règle de copie à chaque opérateur tient et pipeline.object-reuse reste désactivé. Un réglage de sécurité par défaut peut continuer de coûter longtemps après que les conditions qui le justifiaient ont changé. Il ne bouge que lorsque quelqu'un mesure la facture et plaide pour le changement.