Questions d'entretien Ingénieur data

Je commence par comprendre le SLA : à quelle fraîcheur les données doivent-elles être, et quel est le coût d'une défaillance du pipeline en aval ? Ces deux réponses orientent chaque décision d'architecture. Pour la fiabilité, je construis des pipelines idempotents dans la mesure du possible, afin que la réexécution d'un job après une défaillance produise le même résultat sans dupliquer les données. J'utilise des checkpoints pour les jobs de longue durée afin que les défaillances ne redémarrent pas depuis le début. J'ajoute des contrôles de qualité des données à chaque étape : validation du schéma à l'ingestion, vérifications du nombre de lignes entre les étapes, et détection d'anomalies sur les métriques clés en sortie. Pour la scalabilité, je sépare le calcul du stockage afin de les scaler indépendamment, et je conçois pour un traitement incrémental plutôt que des rechargements complets. L'observabilité est intégrée dès le début : chaque pipeline émet des métadonnées d'exécution.

La qualité des données n'est pas une préoccupation séparée de la conception du pipeline ; elle en fait partie. Mon approche comporte trois couches. D'abord, la validation du schéma et des types à l'ingestion : si les données amont changent de forme de manière inattendue, je veux que le pipeline échoue bruyamment au point d'entrée plutôt que de propager silencieusement de mauvaises données. Ensuite, des vérifications de règles métier entre les étapes : des nombres de lignes qui diffèrent significativement de l'exécution précédente, des taux de null au-dessus d'un seuil dans les champs obligatoires, ou des échecs d'intégrité référentielle. Enfin, la surveillance en sortie : je suis les métriques métier clés dans le temps et alerte lorsqu'elles sortent des plages attendues. Lorsqu'un problème de qualité est détecté, je préfère mettre en quarantaine les enregistrements affectés et continuer à traiter les données propres plutôt que d'arrêter l'ensemble du pipeline.

Je commence par l'exigence métier, pas par la technologie. La question clé est : quelle est la latence maximale acceptable entre un événement et sa disponibilité pour l'analyse ? Si la réponse est des heures ou des jours, le traitement par lots est presque toujours plus simple et rentable. Si la réponse est des minutes ou des secondes, le streaming devient nécessaire. Au-delà de la latence, je considère la complexité opérationnelle : les systèmes de streaming sont significativement plus difficiles à déboguer, rejouer et maintenir que les jobs batch. Pour la plupart des cas analytiques que j'ai traités, le micro-batch (exécution toutes les quelques minutes avec Spark Structured Streaming ou Flink) offre une latence acceptable à un coût opérationnel bien inférieur. Je ne m'engage dans une vraie architecture streaming que lorsque l'exigence de latence ne peut genuinement pas être satisfaite par le micro-batch.

Les outils d'IA ont changé quelques aspects de mon flux de travail de manière pratique. Pour l'écriture et la révision de SQL, notamment les fonctions de fenêtre complexes ou les requêtes d'optimisation, l'IA m'aide à itérer plus rapidement et détecte des patterns que je pourrais manquer. Pour la rédaction de la documentation des pipelines et des entrées du dictionnaire de données, l'IA rédige un contenu que je révise et ajuste ensuite. Là où l'IA est devenue genuinement utile, c'est dans la détection d'anomalies sur les sorties des pipelines : plutôt que d'écrire des règles de seuil codées en dur, je peux utiliser des modèles statistiques pour signaler qu'une métrique se comporte de manière inhabituelle. Je fais attention à utiliser l'IA pour la conception de schémas ou les décisions de modélisation des données, car ces décisions ont des conséquences à long terme et le modèle n'a pas le contexte métier complet.

Un job ETL quotidien qui alimentait notre modèle d'attribution marketing a échoué silencieusement : il s'est terminé sans erreurs mais a produit un résultat partiel à cause d'un timeout sur l'un des appels API sources. L'équipe marketing a réalisé son analyse hebdomadaire des dépenses sur des données incomplètes et a détecté la discordance elle-même deux jours plus tard. Quand le problème a été remonté, j'ai diagnostiqué la cause racine en environ une heure : le timeout de l'API était trop bas et le job n'avait pas de validation du nombre d'enregistrements à la fin. J'ai corrigé le problème immédiat en augmentant le timeout et en réexécutant la plage de dates affectée. Ensuite j'ai ajouté une vérification du nombre de lignes en étape finale et une alerte qui se déclenche si le nombre de lignes de sortie tombe en dessous de 90 % de la moyenne sur sept jours. La partie la plus difficile a été de reconstruire la confiance avec l'équipe marketing.

Nous avons migré notre base de données transactionnelle principale d'un schéma Postgres monolithique vers un nouveau schéma supportant la multi-location, tout en maintenant le système en production. Le défi était que nos pipelines analytics, nos outils de reporting et trois microservices en aval dépendaient tous de l'ancien schéma. Mon approche a été d'exécuter les anciens et nouveaux schémas en parallèle pendant six semaines, en écrivant dans les deux et en lisant depuis l'ancien pendant que le nouveau était validé. J'ai construit un job de réconciliation qui tournait chaque nuit et comparait les nombres de lignes et les agrégats clés entre les deux schémas. La migration de chaque consommateur a été faite de manière incrémentale : analytics en premier (risque le plus faible), puis le reporting, puis les microservices. La migration complète a pris dix semaines sans perte de données ni temps d'arrêt.

Un job Spark nocturne qui agrégeait des données d'activité utilisateur prenait six heures, empiétant sur les heures de bureau et retardant les tableaux de bord dont l'équipe produit dépendait. J'ai profilé le job et trouvé trois problèmes : une jointure lourde en shuffle qui ne tirait pas parti des broadcast joins pour une petite table de lookup, un scan complet de table sur une table partitionnée car le filtre de partition était appliqué après le scan, et une étape de sortie qui écrivait des milliers de petits fichiers. J'ai remplacé la jointure par un broadcast join (la table de lookup faisait moins de 100 Mo), poussé le filtre de partition dans l'étape de lecture, et coalescé la sortie. Le temps d'exécution est passé de six heures à moins de 45 minutes. La correction du filtre de partition a contribué à l'essentiel du gain, réduisant les données scannées à environ 3 % de la table complète.

Un data warehouse stocke des données structurées et traitées, optimisées pour les requêtes analytiques. Il applique le schéma à l'écriture, ce qui signifie que les données sont transformées et validées avant d'entrer dans le warehouse. Un data lake stocke les données brutes dans leur format d'origine, structuré ou non, et applique le schéma à la lecture. Il est moins coûteux pour stocker de grands volumes et plus flexible pour l'analyse exploratoire ou les cas d'usage ML. La réponse pratique : la plupart des organisations ont besoin des deux. Le data lake contient les données brutes et intermédiaires ; le data warehouse contient les données curées, prêtes pour les analyses. Le pattern que j'ai le plus utilisé est l'architecture medallion (couches raw, clean, curated) où la couche curated est le warehouse et les couches précédentes vivent dans le stockage objet.

Je commence par comprendre qui va interroger ces données et comment. Les analystes et les outils BI veulent généralement des tables larges et dénormalisées, faciles à joindre et rapides à interroger. Les data scientists veulent souvent accéder à des tables plus granulaires. Pour la plupart des cas analytiques j'utilise un modèle dimensionnel (tables de faits et de dimensions) car il est bien compris, performant avec le stockage colonnaire, et facilite l'ajout de nouvelles dimensions sans casser les requêtes existantes. J'évite les schémas fortement normalisés dans la couche analytique car le coût des jointures ajoute de la complexité pour les analystes. Je réfléchis aussi aux dimensions à variation lente dès le début : si un client change de segment, les requêtes veulent-elles voir dans quel segment il était au moment de l'événement, ou son segment actuel ? Cette décision doit être prise au moment de la modélisation.

Je commencerais par remettre en question si cela doit vraiment être en temps réel. Si la réponse est oui, mon architecture aurait quatre couches. Ingestion : les événements circulent des systèmes sources vers une file de messages comme Kafka ou Pub/Sub, qui découple les producteurs des consommateurs et offre une capacité de replay. Traitement de stream : un job Flink ou Spark Structured Streaming lit depuis la file, applique des transformations et des agrégations, et écrit les résultats dans la couche de service. Service : un magasin analytique rapide comme ClickHouse, Druid ou BigQuery gère la charge de requêtes des tableaux de bord. Surveillance : le pipeline émet des métriques de lag et j'alerte si le lag dépasse la cible. Les parties sur lesquelles je passe le plus de temps en amont sont la conception du schéma au point d'ingestion et la décision exacte de l'état à maintenir dans le processeur de stream.