L'essentiel, tout de suite
Toute personne travaillant avec des piles de données modernes finit par poser la même question : Core est-il toujours la meilleure façon de transformer les données dans l'entrepôt ? Dans cette revue de Core, je vais faire le tri entre le battage médiatique et examiner ce qui fonctionne brillamment, ce qui grince et qui devrait (et ne devrait pas) miser son flux de travail d'ingénierie analytique dessus.
Il s'agit d'une revue pratique, axée sur les solutions, basée sur une utilisation concrète sur les déploiements Snowflake, BigQuery, Databricks et Postgres, ainsi que sur les modèles observés dans les équipes passant d'une poignée de modèles à plusieurs milliers.
Ce que cette revue couvre
- Ce que Core fait bien, et pourquoi les analystes l'aiment
- Là où Core a du mal en 2025 (et les pièges courants)
- Quand choisir Core par rapport aux alternatives ou aux extensions
- Performances, gouvernance et flux de travail d'équipe dans le monde réel
- Recommandations pratiques et suggestions de chaînes d'outils
En cours de route, j'aborderai des sujets de longue traîne que les lecteurs recherchent souvent : Core vs Cloud, les fonctionnalités de Core, les implications en matière de tarification, la gouvernance, les tests, le réglage des performances et les conseils de migration.
Petit rappel : Qu'est-ce que Core, et qu'est-ce qu'il n'est pas ?
Core est un framework open source qui vous permet de transformer les données dans votre entrepôt en utilisant SQL et une pincée de Jinja. Vous écrivez des modèles sous forme d'instructions SELECT ; les compile en SQL spécifique à la base de données, gère les dépendances avec des DAG et gère les matérialisations (tables, vues, incrémentales). Il intègre également des tests, de la documentation, des macros et des configurations sensibles à l'environnement.
Ce que Core n'est pas : un orchestrateur, un planificateur, un catalogue de métadonnées ou une plateforme ELT à interface graphique prioritaire. C'est la couche de transformation conçue pour des flux de travail de type logiciel, conviviaux pour les analystes et contrôlés par version.
Pourquoi Core a conquis le cœur des analystes
1) Flux de travail SQL d'abord, natif du logiciel
- Traitez les transformations comme du code : contrôle de version, revue de code, contrôles CI.
- Modèle mental simple : écrivez une requête ; laissez gérer la construction.
- Les macros et les packages (par exemple, -utils) débloquent des modèles réutilisables à l'échelle de l'équipe.
2) Tests et documentation solides
- Les tests de schéma et de données détectent les dérives et les problèmes de qualité tôt.
- La documentation générée automatiquement (avec la lignée) permet de répondre à la question « Qu'est-ce qui alimente ce tableau de bord ? »
- Les contrats (de plus en plus adoptés) renforcent les garanties de schéma.
3) Portable à travers les entrepôts
- BigQuery, Snowflake, Redshift, Postgres, Databricks, et plus encore.
- Les équipes qui changent de plateforme conservent leur logique de transformation largement intacte.
4) Graphe de dépendance et lignée clairs
- Les modèles déclarent explicitement les dépendances en amont.
- Le DAG prend en charge les constructions partielles, le CI allégé et les nouvelles exécutions ciblées.
5) Communauté et écosystème dynamiques
- Des milliers d'utilisateurs, de packages et de modèles.
- Facile de trouver des exemples, des meilleures pratiques et de l'aide.
Là où Core montre son âge
Dans cette revue de Core, il est important de souligner les compromis que rencontrent les équipes matures.
1) Dispersion de l'orchestration
- Core ne planifie pas. Vous le connecterez à Airflow, Dagster, Prefect ou à votre planificateur d'entrepôt. C'est flexible, mais il y a plus de pièces mobiles.
- La complexité du service de garde augmente à mesure que les pipelines s'étendent ; la propriété peut s'estomper entre la plateforme de données et les équipes d'ingénierie analytique.
2) Python est possible, mais dogmatique
- Les modèles Python existent dans Core, mais SQL d'abord reste le centre de gravité.
- Les pipelines SQL/Python mixtes peuvent sembler inégaux par rapport aux frameworks unifiés comme les piles centrées sur Spark.
3) Performance CI/CD à l'échelle
- Les grands référentiels avec des milliers de modèles peuvent ralentir le CI allégé sans une gestion attentive de l'état et un partitionnement de la construction.
- Les suites de tests peuvent gonfler, avec des vérifications de bout en bout lentes, à moins que vous ne les catégorisiez et ne les isoliez.
4) Lacunes de gouvernance prêtes à l'emploi
- La lignée au niveau des colonnes, le balisage PII et l'application des politiques nécessitent souvent des outils supplémentaires.
- Les contrats et les expositions aident, mais de nombreuses entreprises ajoutent toujours un catalogue (par exemple, Alation, Atlan, DataHub) pour une gouvernance complète des données.
5) Modèles incrémentaux complexes
- Les matérialisations incrémentales sont puissantes, mais nécessitent de la discipline avec les clés de substitution, les stratégies de fusion et les remplissages.
- Le réglage des performances devient spécifique à l'entrepôt : ce qui hurle sur Snowflake peut ramer sur Postgres.
Core vs Cloud : Quelle est la différence ?
Une question récurrente dans toute revue de Core : devriez-vous payer pour Cloud ?
- Core : CLI open source, exécution n'importe où, contrôle total. Vous apportez l'orchestration, l'IDE (par exemple, VS Code) et le CI.
- Cloud : IDE hébergé, planification des tâches, gestion des informations d'identification, observabilité et accès facile aux métadonnées. Intégration plus rapide pour les utilisateurs non-CLI et les petites équipes.
Qui devrait préférer Core ?
- Les équipes avec des orchestrateurs établis (Airflow/Dagster/Prefect) et un DevOps mature.
- Les organisations soucieuses des coûts ou celles qui ont besoin d'une infrastructure/sécurité personnalisée.
- Les utilisateurs expérimentés qui préfèrent les IDE locaux et les flux de travail natifs de Git.
Qui devrait préférer Cloud ?
- Les petites équipes qui ont besoin d'un délai de rentabilité rapide.
- Les parties prenantes qui bénéficient d'un IDE de navigateur et d'une planification/alertes simples.
- Les organisations qui standardisent un seul volet de verre pour les opérations .
Configuration du monde réel : Une architecture pragmatique
Voici un plan de référence que nous avons vu fonctionner à plusieurs reprises pour Core en 2025 :
- Entrepôts : Snowflake ou BigQuery pour l'analyse à usage général ; Databricks SQL pour les utilisateurs de lakehouse ; Postgres pour les opérations plus petites.
- Orchestration : Dagster ou Airflow exécutant la construction en tant que tâches ; CI allégé via la comparaison d'état.
- Tests : Combinaison de tests intégrés + Great Expectations ou Soda pour des validations étendues.
- Observabilité : Elementary ou OpenLineage/DataHub pour les métadonnées d'exécution et la lignée ; alertes sur la fraîcheur du modèle et les échecs de test.
- Gouvernance : Contrats dans , balises de politique dans l'entrepôt, catalogue externe pour la gérance.
- Packaging : -utils, -expectations et macros de performance spécifiques à l'entrepôt.
Réglage des performances : Faire voler Core
La performance est un point sensible fréquemment mentionné dans toute revue approfondie de Core. Principales tactiques :
- Partitionnement et clustering
- Partitionnez les grandes tables de faits par date ; regroupez-les sur des filtres à haute cardinalité.
- Tirez parti des stratégies incrémentales (fusionner, insert_overwrite) adaptées à votre entrepôt.
- Élaguez le DAG pour le CI
- Utilisez state:modified pour n'exécuter que les modèles impactés.
- Séparez les tests d'intégration lourds des tests de schéma rapides ; exécutez les premiers toutes les nuits.
- Optimisez les jointures et les matérialisations
- Préférez les semi-jointures ou EXISTS lorsque cela est approprié.
- Mettez en cache les tables de dimension en tant que vues ou modèles éphémères pour réduire les E/S.
- Tenez compte des compromis entre table et vue par modèle de consommation.
- Profilez les requêtes par entrepôt
- Snowflake : surveillez la sur-concurrence et les paramètres de suspension/reprise automatique de la taille de l'entrepôt.
- BigQuery : Coûts d'analyse - utilisez des filtres de partition et des clauses WHERE obligatoires.
- Databricks : Z-Ordering, optimisations Delta et évitez les problèmes de petits fichiers.
- Gardez les macros honnêtes
- Comparez le SQL généré par macro avec des versions ajustées à la main.
- Évitez de trop abstraire les modèles qui masquent les opérations coûteuses.
Tests et contrats de données qui évoluent
- Commencez par les tests de schéma (unique, not_null, accepted_values) sur les dimensions et les faits clés.
- Ajoutez des écrans de qualité des données aux limites critiques (par exemple, l'ingestion vers les transitions bronze → argent si vous utilisez un modèle de lakehouse).
- Adoptez des contrats sur les marts destinés aux consommateurs pour éviter les changements cassants.
- Documentez les hypothèses dans les descriptions de modèles ; reliez les expositions aux tableaux de bord et aux modèles qui en dépendent.
Flux de travail d'équipe : Du solo à l'entreprise
Comme cette revue de Core couvre à la fois les petites et les grandes équipes, voici des playbooks par étape :
- Solo/Petite équipe (1 à 3 personnes)
- Exécutez Core localement ; planifiez via GitHub Actions ou un simple cron dans votre orchestrateur.
- Mettez l'accent sur la documentation et les tests dès le début ; votre futur moi vous remerciera.
- Équipe de taille moyenne (4 à 15 personnes)
- Introduisez une branche structurée, des revues de RP obligatoires et un CI allégé.
- Ajoutez un catalogue de données léger et des alertes sur les constructions échouées.
- Entreprise (plus de 15 personnes, plus de 1 000 modèles)
- Divisez le mono-référentiel en domaines ou appliquez une propriété et un espace de noms stricts.
- Adoptez un processus RFC formel pour les macros partagées et les changements cassants.
- Appliquez des barrières CI, des SLA de qualité et une surveillance de la fraîcheur des tableaux de bord.
Contrôle des coûts : Évitez les factures surprises
- BigQuery : Forcez les filtres de partition dans les modèles en aval ; vérifiez les slots par rapport à la demande ; surveillez les explosions cartésiennes.
- Snowflake : Dimensionnez correctement les entrepôts ; tirez parti de l'accélération des requêtes de manière stratégique ; arrêtez d'exécuter des tests lourds sur de petits entrepôts.
- Databricks : Compactez les petits fichiers ; choisissez les modes de cluster optimaux pour les charges de travail SQL.
- Général : Marquez les modèles par niveau de coût ; redirigez les constructions exploratoires vers des environnements moins chers.
Considérations de sécurité et de conformité
- Utilisez des variables d'environnement ou profiles.yml avec des gestionnaires de secrets.
- Limitez les autorisations de production aux rôles CI/CD ; accordez aux développeurs un accès en lecture seule en production.
- Suivez les informations PII à l'aide de balises natives de l'entrepôt et appliquez des vues masquées.
- Enregistrez la lignée et l'accès pour les audits à l'aide d'OpenLineage ou d'une plateforme de catalogue.
Alternatives et compléments à Core
Une revue équitable de Core devrait reconnaître les choix adjacents :
- Plateformes Transform-in-ELT : Fivetran Transformations, Matillion, Talend - GUI d'abord, moins centré sur Git.
- Orchestrateur d'abord : Dagster avec des actifs définis par logiciel (SDA) peut unifier l'ingestion, les transformations et les flux ML.
- Centré sur les notebooks : Databricks ou Hex peuvent être plus conviviaux pour les équipes fortement axées sur la science des données ; vous pouvez toujours appeler à l'intérieur.
- Couches de métriques : Couche sémantique , Transform/MetriQL ou métriques natives de l'entrepôt - à considérer pour une logique métier cohérente.
Quand Core est idéal :
- Ingénierie analytique centrée sur SQL avec un contrôle de version et des tests solides.
- Vous voulez la portabilité entre les entrepôts et un écosystème open source florissant.
Quand repenser :
- Pipelines Python/ML lourds où Spark ou Ray est l'épine dorsale.
- Gouvernance d'entreprise stricte sans ajout d'une couche de catalogue/lignée.
- Équipes allergiques aux flux de travail CLI/Git.
Core vs. Dataform vs. SQLMesh (Points clés)
- Dataform : Fort dans les magasins natifs de BigQuery avec une philosophie similaire SQL d'abord et des outils de navigateur ; écosystème plus petit que .
- SQLMesh : Met l'accent sur la gestion de l'environnement, le voyage dans le temps et les paradigmes de test ; convaincant pour les remplissages complexes et le CI robuste.
- Core : La plus grande communauté, la plus large prise en charge des entrepôts, le plus de documentation et de nombreux modèles testés au combat.
Pièges courants (et comment les éviter)
- Modèles monolithiques : Divisez les requêtes géantes en couches de staging réutilisables ; laissez le DAG faire le travail.
- Charges incrémentales illimitées : Définissez des filigranes et des fenêtres de retraitement ; planifiez des actualisations complètes périodiques.
- Tout tester de la même manière : Donnez la priorité aux modèles de chemin critique ; reléguez les tests non critiques à la nuit.
- Propriété incertaine : Ajoutez des propriétaires de modèles dans YAML ; acheminez les alertes vers les bonnes personnes.
- Surutilisation des macros : Préférez la clarté à l'intelligence ; documentez les macros comme vous le feriez pour les API publiques.
Conseils d'outillage qui font gagner des heures
- Utilisez build localement avec une analyse partielle pour des boucles de rétroaction plus rapides.
- Générez de la documentation sur chaque construction de branche principale et hébergez-la en interne.
- Adoptez des hooks de pré-commit pour la vérification de la syntaxe SQL et la validation du schéma YAML.
- Ajoutez Elementary ou similaire pour obtenir des alertes sur les échecs de test et la fraîcheur.
- Pour les utilisateurs de Databricks, préférez Delta incrémentiel + Z-Ordering pour les grands faits.
Au fait : Accélérer le flux de travail quotidien
Si vous évaluez la productivité des développeurs autour de Core, il convient de noter que les assistants IA qui comprennent les bases de code et les conventions YAML peuvent réduire les cycles de RP et aider à écrire des tests et des macros plus rapidement. Les outils qui peuvent expliquer les différences de lignée, suggérer des refactorisations de macros ou rédiger des descriptions de modèles peuvent raccourcir l'intégration pour les nouveaux ingénieurs analytiques.
Le verdict : Core est-il toujours la référence absolue ?
Réponse courte : oui - pour l'ingénierie analytique SQL d'abord dans l'entrepôt, Core reste le choix par défaut en 2025. Il est stable, profondément adopté et extensible. Mais ce n'est pas une plateforme complète. Pour l'orchestration, l'observabilité et la gouvernance, vous ajouterez probablement des outils complémentaires. Pour les équipes fortement axées sur Python ou ML, déterminez si une pile Spark d'abord ou une architecture dirigée par Dagster convient mieux à votre centre de gravité.
Considérez Core comme le moteur fiable de votre couche de transformation : ouvert, portable, prévisible. Les équipes gagnantes l'associent à un flux de travail discipliné et à une petite boîte à outils d'alliés.
Prochaines étapes réalisables
- Pilote : Commencez par un domaine ciblé (par exemple, l'analyse des revenus) et 20 à 40 modèles.
- Qualité de base : Ajoutez des tests de schéma à chaque modèle dès le premier jour ; appliquez des revues de RP.
- CI/CD : Configurez Slim CI avec une comparaison d'état ; documentez les cibles de construction et les balises.
- Observabilité : Ajoutez une couche de lignée/alertes légère dès le début (Elementary, OpenLineage ou similaire).
- Échelle : Partitionnez les faits lourds, adoptez l'incrémentiel lorsque cela est judicieux et suivez les coûts par modèle.
Principaux points à retenir
- Consensus de la revue Core : le meilleur de sa catégorie pour les transformations SQL d'abord dans l'entrepôt.
- Points forts : flux de travail des développeurs, tests, portabilité, communauté.
- Points de vigilance : dispersion de l'orchestration, performance CI à l'échelle, lacunes de gouvernance.
- Choisissez Cloud pour plus de commodité ; choisissez Core pour le contrôle.
- Le succès vient de l'association de Core avec d'excellentes pratiques, et pas seulement d'excellents outils.
FAQ
Q1 : Qu'est-ce que Core et en quoi est-il différent de Cloud ?
Core est le framework CLI open source pour les transformations et les tests basés sur SQL. Cloud est le service hébergé avec un IDE Web, une planification et des fonctionnalités de gestion superposées.
Q2 : Core est-il gratuit pour les charges de travail de production ?
Oui, Core est open source et gratuit. Vous paierez toujours pour votre entrepôt de données et tous les outils d'orchestration, d'observabilité ou de catalogue que vous adoptez.
Q3 : Quand dois-je choisir Core plutôt que Cloud ?
Choisissez Core si vous voulez un contrôle maximal, si vous avez déjà un orchestrateur et si vous préférez les IDE locaux. Choisissez Cloud pour une intégration plus rapide, une planification intégrée et un environnement géré.
Q4 : Core peut-il gérer les modèles Python et les pipelines d'apprentissage automatique ?
Core prend en charge les modèles Python, mais il est principalement optimisé pour les transformations SQL. Pour les flux de travail fortement axés sur le ML, envisagez une pile Spark d'abord ou centrée sur Dagster et appelez là où SQL convient.
Q5 : Comment puis-je améliorer les performances dans Core à l'échelle ?
Utilisez des modèles incrémentaux avec un partitionnement approprié, tirez parti de Slim CI et des constructions basées sur l'état, et ajustez les matérialisations par entrepôt. Ajoutez de l'observabilité pour détecter rapidement les modèles lents et les pics de coûts.
