Traitement Big Data

Nous concevons les plateformes de données en couches, avec des interfaces explicites entre elles. Une couche bronze capture fidèlement les données source ; une couche argent nettoie, conforme et joint ; une couche or expose les entités et métriques consommées par les analystes, les data scientists et les applications. Chaque couche a ses propres propriétaires, ses propres attentes en matière de qualité et ses propres règles d'évolution. La discipline est ingrate et le rendement est substantiel : un ensemble de données qui se comporte mal peut être localisé, expliqué et corrigé rapidement.

Dans chaque couche, nous utilisons les formats de stockage et les moteurs de requête les mieux adaptés à la charge de travail. Les formats Lakehouse — Apache Iceberg, Delta Lake, Apache Hudi — nous permettent de plus en plus d'exécuter des analyses de type entrepôt sur un stockage à l'économie de lac, tout en conservant les propriétés d'ingénierie (écritures ACID, voyage dans le temps, évolution des schémas) requises pour le travail de production. Lorsque des performances d'entrepôt réelles sont nécessaires au niveau or, nous sommes heureux de déposer des marts organisés dans Snowflake, BigQuery, Redshift ou Synapse.

Le streaming est traité comme un mode de livraison de première classe plutôt que comme une réflexion après coup. Nous utilisons Kafka, Kinesis ou Pub/Sub pour le transport, Flink, Spark Structured Streaming ou Beam pour le traitement, et Iceberg ou Delta pour l'atterrissage — avec les mêmes contrôles de qualité et de gouvernance que ceux dont bénéficient les pipelines par lots. Les architectures de style Lambda avec des chemins de lots et de flux parallèles sont quelque chose que nous évitons activement désormais ; le coût opérationnel est rarement justifié.

• Conception en couches Bronze / Argent / Or
• Formats de table ouverts (Iceberg, Delta, Hudi)
• Ingestion orientée streaming là où c'est rentable
• Stockage cloud-natif avec politiques de cycle de vie
• Transformations réutilisables dans dbt ou Spark
• ETL inversé vers les systèmes opérationnels

La qualité n'est pas un attribut d'un ensemble de données ; c'est un attribut du pipeline qui le produit. Nous instrumentons chaque transformation avec des attentes explicites — schéma, plages de valeurs, intégrité référentielle, fraîcheur — et traitons les violations comme des incidents de première classe avec leurs propres procédures opérationnelles. Des outils tels que Great Expectations, les tests dbt et Monte Carlo trouvent une place régulière dans nos déploiements, mais l'outillage importe moins que l'engagement culturel à corriger le producteur plutôt qu'à s'excuser auprès du consommateur.

Nous accordons une attention particulière au lignage. Chaque table importante dispose d'un diagramme de lignage généré montrant les sources amont, les transformations appliquées et les consommateurs aval. Lorsqu'un tableau de bord se déplace de manière inattendue, l'analyste peut le retracer jusqu'à une exécution de tâche spécifique plutôt que d'attendre que l'équipe de données enquête. Cette seule capacité supprime une part significative de la charge de support ad hoc des équipes de données.

Les contrôles de confidentialité coexistent avec les contrôles de qualité. Les données personnelles sont identifiées à l'ingestion, classifiées et protégées conformément à la politique qui les régit. Le masquage, la tokenisation et l'agrégation sont appliqués lorsque les données franchissent les limites des couches, de sorte que les données brutes sensibles n'atteignent jamais une surface de requête qui n'en a pas besoin. C'est la forme architecturale de la confidentialité dès la conception, et elle est bien moins chère que de la mettre en œuvre a posteriori.

Les pipelines de données qui semblent élégants en développement et fragiles en production partagent généralement la même cause profonde : ils n'ont jamais été conçus pour être exploités. Nous concevons des pipelines pour être idempotents, rejouables à partir de n'importe quel point et instrumentés de manière à faciliter le diagnostic des incidents. Les pannes sont anticipées et absorbées ; la récupération ne nécessite pas un ingénieur héroïque à trois heures du matin.

L'orchestration est centralisée — généralement dans Airflow, Dagster ou Prefect — avec des conventions partagées pour la dénomination, les réessais, les alertes et les SLA. Le cas échéant, nous superposons des objectifs de niveau de service au niveau du produit de données, de sorte que les engagements de fraîcheur et de disponibilité orientés consommateur soient explicites et mesurés plutôt qu'ambitieux.

Nous traitons le coût comme une propriété de la plateforme, et non comme quelque chose remarqué en fin de mois. Le calcul et le stockage sont profilés en continu par tâche, par équipe et par produit de données, et la visibilité qui en résulte a tendance à s'autofinancer en un trimestre. Nous avons à plusieurs reprises réduit les dépenses de données dans le cloud de vingt à quarante pour cent sans sacrifier les performances, simplement en remplaçant les schémas de gaspillage que l'équipe avait hérités et jamais mesurés.

“Un pipeline que vous ne pouvez pas exploiter est un passif, pas un actif. L'exploitabilité fait partie de la conception, pas une étape de finition.”

Une part significative de notre travail consiste à faire passer les organisations de plateformes ETL héritées — Informatica, Ab Initio, scripts shell écrits à la main, parcs SSIS obsolètes — à des piles modernes, natives du cloud. Ces migrations sont généralement contraintes par le fait que la plateforme existante, aussi maladroite soit-elle, fait fonctionner l'entreprise ; les temps d'arrêt et les régressions silencieuses ne sont pas acceptables.

Nous abordons la migration des systèmes hérités comme un programme d'ingénierie, et non comme un simple transfert. Nous cataloguons ce qui est réellement utilisé (généralement beaucoup moins que ce qui est construit), nous identifions les consommateurs, nous redessinons plutôt que de traduire, et nous exécutons les nouveaux et anciens systèmes en parallèle jusqu'à ce que la parité côté consommateur ait été vérifiée indépendamment. La tentation de tout reconstruire est résistée ; l'objectif est de migrer la valeur, pas les lignes de code.

Le cas échéant, nous intégrons la migration dans une modernisation plus large : introduction d'une couche sémantique, consolidation de la logique dupliquée, passage de la sécurité au niveau des lignes à la sécurité au niveau des colonnes, et suppression du backlog inévitable de rapports zombies. Le résultat est rarement moins cher à exploiter le premier jour, mais il est toujours moins cher à modifier, ce qui représente la majeure partie des dépenses de données.

Les engagements vont des interventions ciblées — livrer un cas d'utilisation de streaming, exécuter un programme de réduction des coûts, évaluer une migration — aux partenariats de plateforme pluriannuels. Nous sommes aussi à l'aise pour intégrer une petite équipe à votre groupe plateforme que pour prendre en charge une livraison discrète de bout en bout, et nous adaptons la structure du contrat (temps et matériel, jalons à prix fixe, service géré) au modèle le mieux adapté au travail.

Nous ne vendons pas de plateformes ni de licences, et nous n'avons pas de préférence entre les fournisseurs de cloud au-delà de ce qui convient à votre environnement. Les ingénieurs que nous déployons sont les ingénieurs que vous rencontrez. Lorsque nous identifions des lacunes que nous ne pouvons pas combler, nous le disons et vous aidons à trouver des ressources ailleurs.