L’image du data lake est facile : garder les données détaillées dans un grand réservoir, puis laisser les analystes y puiser. Le stockage distribué permet de conserver fichiers, logs et exports sans les transformer immédiatement en tables de rapport. Cette souplesse devient utile seulement si on sait ce que chaque objet contient.

Je séparerais au moins trois zones. La zone brute reçoit une copie immuable de la source. La zone préparée contient formats nettoyés, types et clés. La zone publiée contient des jeux approuvés pour un usage. Les traitements ne modifient pas la source; ils produisent une nouvelle version avec une provenance.

Le trajet d’un fichier de ventes

Un lot quotidien pourrait suivre ces étapes :

1. recevoir ventes_2013-06-14.csv avec taille et somme SHA;
2. enregistrer source, heure, encodage et version de schéma;
3. parser dans une zone temporaire;
4. rejeter les lignes sans clé ou avec montant invalide;
5. dédupliquer selon magasin, ticket et ligne;
6. écrire un format préparé partitionné par date;
7. publier seulement si les contrôles rapprochent la source.

Le manifeste garde lignes reçues, acceptées, rejetées et total monétaire. Si la source contient 1 000 000 $ et le jeu préparé 960 000 $, le pipeline ne doit pas devenir vert parce qu’il a réussi techniquement. La zone de quarantaine conserve les rejets avec une raison et un propriétaire.

Le partitionnement par date évite de relire des années pour une journée. Trop de petits fichiers ralentissent néanmoins les métadonnées et le lancement des tâches; un compactage regroupe les lots. Le schéma peut évoluer : ajouter une colonne optionnelle est plus simple que changer le sens d’un montant. Chaque version doit être lisible et documentée.

Un lac partagé exige des frontières

Les données brutes peuvent contenir noms, adresses et jetons présents par erreur dans les logs. Les accès sont accordés par zone et usage, pas à tout le cluster. Les données sensibles sont chiffrées, masquées pour l’analyse et supprimées selon une rétention. Les clés et audits vivent hors des comptes ordinaires.

La découverte demande un catalogue : propriétaire, description des champs, période couverte, qualité, fraîcheur et traitements en aval. Sans catalogue, les analystes copient le fichier qu’ils comprennent le moins mal et construisent une autre définition.

Une reprise doit pouvoir rejouer depuis le brut. Le code, les paramètres et les données de référence sont versionnés. Rejouer ne doit pas dupliquer les partitions; on écrit dans une nouvelle version puis on bascule un pointeur après validation.

Publier un contrat de jeu de données

La zone publiée devrait exposer un schéma machine-readable, des exemples et des attentes de fraîcheur. Un consommateur lit la version, vérifie les colonnes requises et refuse un changement incompatible. Le pipeline producteur compare l’ancien et le nouveau schéma avant de publier, puis envoie un événement aux abonnés. Une colonne ajoutée reste optionnelle pendant la transition; retirer ou changer le type demande une nouvelle version. Le catalogue enregistre les consommateurs connus afin d’évaluer l’impact. Ce contrat transforme un répertoire de fichiers en interface de données et ajoute clairement les familles de mécanisme qui relient source, traitement, stockage et usage.

Je commencerais avec un domaine et une question. Si on peut partir d’un fichier reçu, expliquer chaque transformation, retrouver les rejets et reproduire le jeu publié, le lac possède une rive. Accumuler des téraoctets sans ce trajet ne fait que reporter le ménage.