Mapper des sources S3 et Atlas vers un espace de noms virtuel

Dans Atlas Data Federation, la configuration du stockage est un document JSON qui définit deux éléments : les magasins (l’emplacement des données brutes — compartiments S3 et clusters Atlas) et les bases de données/collections (l’espace de noms virtuel interrogé par les applications). L’association entre ces éléments indique au moteur de requêtes quel magasin lire lorsque vous interrogez une collection virtuelle.

La définition d’un magasin S3 nomme le magasin, indique la région AWS et le nom du compartiment, puis l’associe à des identifiants IAM (par l’intermédiaire d’un rôle d’accès du fournisseur cloud Atlas). Vous pouvez également définir un delimiter et un prefix afin de limiter la portée du magasin à un préfixe S3 particulier. Une même instance fédérée peut comporter plusieurs magasins pointant vers différents compartiments ou régions.

Un magasin de cluster Atlas connecte une instance fédérée à un jeu de réplicas Atlas actif. Vous le référencez à l’aide du nom du cluster au sein du même projet Atlas. Vous pouvez ainsi écrire des chaînes de traitement qui lisent les collections opérationnelles actives du cluster en parallèle de données S3 archivées, ce qui permet d’effectuer des requêtes hybrides sans aucune duplication de données.

Une collection virtuelle est associée à un magasin et à un modèle de chemin. Le chemin est un modèle global qui indique à Data Federation quels objets S3 appartiennent à cette collection. Le modèle peut inclure des segments de chemin littéraux ou des caractères génériques. Le moteur de requêtes analyse tous les objets correspondants lorsque la collection est interrogée.

Les attributs de partition encodent les métadonnées directement dans le chemin S3 à l’aide de la syntaxe avec accolades : {year int}/{month int}/{day int}/. Lorsqu’une requête filtre sur year, month ou day, Data Federation élimine — ignore — tous les objets S3 dont le chemin ne correspond pas aux valeurs du filtre. Ce mécanisme est comparable au partitionnement Hive et réduit considérablement le nombre d’octets analysés.

Une même collection virtuelle peut être associée à plusieurs sources de données — par exemple, une archive S3 et une collection Atlas active. Les requêtes fusionnent les résultats de toutes les sources de manière transparente. Cette approche est utile pour une collection d’« historique complet » dont les données récentes se trouvent dans Atlas et les données plus anciennes dans S3, tandis que les applications interrogent les deux par l’intermédiaire d’un seul espace de noms.

Vous pouvez définir une collection générique (*) qui associe tous les fichiers d’un préfixe S3 à des collections virtuelles nommées dynamiquement. Lorsque vous interrogez un nom de collection correspondant au motif générique, Data Federation déduit le chemin à partir du nom de la collection. Cette approche est utile pour les lacs de données partitionnés contenant des milliers de « tables » fondées sur des préfixes, qu’il est impossible d’énumérer entièrement dans la configuration.

Vous pouvez mettre à jour la configuration du stockage à tout moment via l’interface utilisateur Atlas, l’API d’administration Atlas ou mongosh. Les modifications prennent effet immédiatement : vous n’avez pas besoin de redémarrer l’instance fédérée. Vous pouvez ainsi ajouter de nouveaux chemins S3, associer des collections à d’autres magasins ou ajouter de nouvelles sources de clusters Atlas sans aucune interruption de service.

Après avoir défini la configuration du stockage, testez-la en vous connectant à l’instance fédérée avec mongosh et en listant les bases de données et les collections. Utilisez show dbs, show collections et un simple find() pour vérifier que le mappage est correct. Vérifiez que les bons fichiers sont lus en examinant les premiers documents renvoyés.

Atlas Data Federation accède à S3 via AWS IAM. L’approche recommandée consiste à utiliser un rôle IAM délégué au compte AWS d’Atlas (accès au fournisseur cloud Atlas), plutôt qu’à stocker des paires de clés d’accès et de clés secrètes. Le rôle reçoit un accès en lecture au compartiment S3 via une stratégie IAM, puis Atlas assume ce rôle lors de l’exécution des requêtes. Cette méthode est plus sécurisée que des clés d’accès à longue durée de validité.

Vous pouvez créer plusieurs collections virtuelles qui pointent vers le même préfixe S3 sous-jacent, avec des motifs de chemin différents, ce qui revient à créer plusieurs vues des mêmes données. Par exemple, une collection peut exposer toutes les données, une autre uniquement la partition de l’année en cours, et une troisième uniquement les fichiers Parquet en excluant les fichiers JSON. Vous pouvez ainsi contrôler ce que voit chaque niveau de votre application.

Dans cette leçon, vous avez appris que les magasins définissent l’emplacement des données brutes (compartiments S3 ou clusters Atlas), tandis que les bases de données et collections virtuelles définissent l’espace de noms interrogé par les applications, que les attributs de partition dans les chemins S3 permettent l’élagage et réduisent considérablement le nombre d’octets analysés, et qu’une seule collection virtuelle peut fusionner simultanément des données provenant de plusieurs magasins. Nous allons maintenant écrire des pipelines d’agrégation intersources.