Kafka, HBase, Solr : quand une seule ligne manquante remet en question toute la chaîne
Interne dans une grande banque française, sur des architectures CDH Cloudera : ingestion de logs, streaming, stockage distribué, indexation métier. Le jour où une ligne sur des millions a manqué, la vraie question n'était plus « est-ce que ça tourne ? » mais « peut-on faire confiance à ce que l'interface retourne ? »
Des applications envoyaient leurs logs dans des topics Kafka. Spark Streaming consommait ces messages et alimentait HBase. Les données étaient ensuite indexées vers Apache Solr, au travers de Lily HBase Indexer - le Key-Value Store Indexer de Cloudera Manager. Solr était interrogé par une UI sur mesure, utilisée pour des recherches métier, notamment par des équipes de l'Inspection Générale de la banque.
Ce dernier point change beaucoup de choses. Quand une interface sert à investiguer, la question n'est plus seulement « est-ce que le flux tourne ? ». Elle devient : « peut-on faire confiance à ce que l'interface retourne ? » Et parfois, cette confiance se joue sur une seule ligne.
HBase pour stocker, Solr pour chercher
HBase servait de stockage distribué orienté clé : adapté pour absorber des volumes importants et accéder efficacement à un enregistrement. Mais HBase n'était pas fait pour offrir une expérience de recherche riche. Pour filtrer, croiser des critères, rendre les logs exploitables dans une interface métier, Solr apportait une autre projection de la donnée.
Ce n'était pas une anomalie d'avoir la donnée à plusieurs endroits. Kafka pour découpler l'ingestion, HBase pour stocker, Solr pour chercher - chaque composant avait son rôle. Le vrai sujet n'était pas la duplication elle-même, mais ce qu'elle impliquait : latence, reprise, écarts éventuels, rejets, mapping, monitoring, et la capacité à expliquer quel système fait foi à quel moment.
Le piège du « near real time »
« Near real time » ne veut pas dire magique. Entre une écriture dans HBase et sa disponibilité dans Solr, il existe toujours une chaîne technique : réplication HBase, indexer, morphlines, mapping, écriture dans la collection Solr, rafraîchissement de l'index, puis interrogation par l'UI. La plupart du temps, cette chaîne est invisible - c'est même ce qu'on attend d'elle. Mais le jour où une donnée ne se retrouve pas là où elle devrait être, il faut être capable de remonter le fil, étape par étape.
La ligne qui manquait
Le problème le plus marquant est arrivé sur un test de complétude. Sur des millions d'indexations dans Solr, il en manquait une. Une seule. Pas un incident massif, pas un crash, pas une erreur visible dans un dashboard - juste une ligne absente de l'index.
Quand le système sert à investiguer, on ne peut pas répondre « presque tout est là ». Il faut comprendre. Pas seulement corriger.
Quand la documentation ne suffit plus
Nous avons vérifié la chaîne étape par étape : ingestion Kafka, traitement Spark Streaming, écriture dans HBase, indexation vers Solr, requête côté interface. À un moment, il a fallu aller plus loin que les logs et la documentation. Najib, notre Lead Dev Spark / Java, a fini par analyser le code source de Lily HBase Indexer pour comprendre précisément son comportement - sans le traiter comme une boîte noire définitive. C'est souvent là que se joue la différence entre une équipe qui contourne un problème et une équipe qui le comprend.
La correction est venue du positionnement d'un petit paramètre. Un détail - mais placé au mauvais endroit, suffisant à provoquer un comportement inacceptable. C'est assez représentatif des architectures distribuées : les grands choix sont visibles sur les schémas, certains comportements critiques se jouent dans des paramètres beaucoup plus discrets.
Les tests ont fait leur travail
Des tests plus superficiels auraient conclu que tout allait bien : le flux tournait, les volumes passaient, Solr était alimenté, l'UI répondait. Sur le papier, le système fonctionnait. Mais un bon test ne sert pas qu'à confirmer le scénario nominal - il sert aussi à faire apparaître les écarts que personne ne verra en ne regardant que les compteurs globaux. Le vrai signal n'était pas « nous avons indexé des millions de lignes », mais « nous sommes capables d'expliquer pourquoi une ligne manque ». C'est très différent.
Ce que cette architecture m'a appris
Indexer n'est pas stocker : HBase et Solr ne répondaient pas au même besoin, l'un portait la donnée de référence, l'autre une projection optimisée pour la recherche. La duplication n'est pas un problème si elle est assumée - elle le devient quand personne ne sait expliquer les écarts entre les systèmes. Le temps réel a toujours des compromis : reprise, latence, rejets, idempotence, monitoring, rejeu, contrôle de complétude. Les détails de configuration comptent - un paramètre mal positionné peut avoir plus d'impact qu'un beau schéma. Et une équipe forte ne se limite pas à empiler des technologies : elle sait investiguer, douter, tester, et descendre au niveau du code quand c'est nécessaire.
Les outils changent, les questions restent
Aujourd'hui, on parlerait peut-être de Flink, Kafka Streams, OpenSearch, d'un lakehouse, de CDC ou de moteurs vectoriels. Les noms changent, mais les questions restent étonnamment proches : où est la donnée de référence, quelle projection sert quel usage, quelle latence accepte-t-on, comment détecte-t-on une donnée absente, comment rejoue-t-on un flux, comment explique-t-on un écart entre stockage source et moteur de recherche, à partir de quel niveau de test peut-on réellement parler de confiance.
C'est peut-être ça, la vraie continuité entre les architectures Big Data d'hier et les architectures data d'aujourd'hui. Le métier d'architecte reste en grande partie le même : comprendre les usages, accepter les compromis, rendre les flux explicables, et ne jamais confondre « ça tourne » avec « c'est maîtrisé ».
Merci à Najib, mon Lead Dev à l'époque, dont l'analyse technique a été déterminante dans cette investigation. Merci aussi à Jérôme, notre Chef de projet, qui a su orchestrer les actions avec brio dans un contexte où chaque hypothèse devait être vérifiée proprement. Et merci à ces tests parfois ingrats, mais indispensables, qui rappellent qu'une seule ligne manquante peut raconter beaucoup de choses sur la solidité réelle d'une architecture.
Une architecture distribuée à fiabiliser ?
Cohérence des données, tests de complétude, écarts entre systèmes - échangeons.