Le blog technologique d'Uber a publié un article, Introduction au stockage hiérarchisé Kafka chez Uber, visant à maximiser la conservation des données avec moins de courtiers Kafka et moins de mémoire. Cela permet des temps de conservation des messages plus longs dans diverses applications professionnelles.

Une solution courante consiste à intégrer manuellement le stockage externe, en synchronisant périodiquement les données avec le système externe. Cependant, cela implique des efforts de développement et de maintenance importants, tels que déterminer comment sauvegarder les données, définir la fréquence de synchronisation, déclencher des processus, récupérer des données et utiliser l'indexation.

Par conséquent, Uber a proposé une solution qui encapsule la logique du stockage externe, le rendant plug-and-play avec des configurations simples. Cette fonctionnalité est développée en collaboration avec la Fondation Apache et sera disponible dans les prochaines versions.

Scénario

Il est important de comprendre que Kafka est un composant de file d'attente de messages (MQ) en ajout uniquement avec des capacités de débit très élevées. Kafka stocke les journaux sur le stockage local du courtier et les utilisateurs peuvent configurer le temps de conservation ou la taille des journaux. Dans mon ancienne entreprise (Lenovo), nous utilisions Flink pour consommer des données en continu. Un volume important de données amènerait Kafka à dépasser la limite de stockage sur disque, entraînant des échecs d'écriture de données et des erreurs commerciales. Pour réduire les coûts, au lieu de déployer davantage de machines, nous n'avons pu qu'ajuster le temps de rétention.

De plus, si chaque entreprise devait développer son propre système pour sauvegarder les données plus anciennes sur un stockage externe, cela impliquerait une énorme quantité de travail de développement. Il y aurait également de nombreux problèmes liés à la synchronisation et à la cohérence des données.

Solution

L'essence est de transformer le Broker en y ajoutant la gestion des journaux à distance et la gestion du stockage.

RemoteLogManager : gère le cycle de vie des segments de journaux distants, y compris la copie, le nettoyage et la récupération.

RemoteStorageManager : gère les actions pour les segments de journaux distants, y compris la copie, la récupération et la suppression. Les métadonnées associées aux segments de journaux distants incluent des informations sur les décalages de début et de fin du segment, les horodatages, les instantanés de l'état du producteur et les points de contrôle de l'époque principale.
RemoteLogMetadataManager garde une trace de ces métadonnées pour garantir que le système sait où commence et se termine chaque segment, ainsi que d'autres informations critiques nécessaires à la récupération et à la gestion des données.

RemoteLogMetadataManager : gère le cycle de vie des métadonnées pour les segments de journaux distants avec une forte cohérence.

Parmi eux, RemoteLogManager agit comme un composant de contrôle, se connectant directement au disque du Broker pour récupérer les données lues. Il est également chargé de rappeler les données distantes. RemoteStorageManager est l'entité qui opère sur les données et RemoteLogMetadataManager est responsable de la gestion des métadonnées.

Résumé des trois actions dans le stockage hiérarchisé Kafka

1. Copie de segments vers le stockage distant
   Un segment de journal est considéré comme éligible pour la copie sur le stockage distant si son décalage de fin (le décalage du dernier message du segment) est inférieur au dernier décalage stable de la partition.（Last-Stable-Offset (LSO) : le décalage le plus élevé pour lequel tous les messages précédents sont entièrement reconnus par toutes les répliques synchronisées, garantissant ainsi aucune perte de données.）RemoteStorageManager gère la copie des segments de journal ainsi que leurs index associés, horodatages, instantanés du producteur et cache d'époque leader.

2. Nettoyage des segments distants
   Les données distantes sont nettoyées à intervalles réguliers en calculant les segments éligibles par un pool de threads dédié. Ceci est différent du nettoyage asynchrone des segments de journaux locaux. Lorsqu'un sujet est supprimé, le nettoyage des segments de journaux distants est effectué de manière asynchrone et ne bloquera pas l'opération de suppression existante ni ne recréera un nouveau sujet.

3. Récupération de segments à partir du stockage distant
   RemoteLogManager détermine le segment distant ciblé en fonction du décalage souhaité et de l'époque leader en examinant le magasin de métadonnées à l'aide de RemoteLogMetadataManager. Il utilise RemoteStorageManager pour trouver la position dans le segment et commencer à récupérer les données souhaitées.