Chaque outil de qualité des données intègre un choix architectural : où se fait la vérification ? Déplacer les données hors de la base de données pour exécuter les contrôles de qualité à l'extérieur introduit une latence réseau, une couche de traitement supplémentaire, des coûts d'egress et une surface de sécurité qui n'existait pas auparavant. 

À mesure que les volumes de données augmentent, ce choix s'amplifie. Extraire un million d'enregistrements par jour pour les valider à l'extérieur est gérable. Extraire cent millions d'enregistrements d'un environnement Snowflake soumis à des obligations de résidence des données, d'un système Teradata dans une institution réglementée, d'un environnement Databricks traitant des données d'événements en temps réel, est une tout autre affaire. Les coûts d'extraction, la latence et l'exposition en matière de Compliance augmentent tous avec le volume de données. Le contrôle de qualité lui-même n'a pas besoin de le faire. 

L'exécution de la qualité des données dans la base de données exécute toute la logique de qualité à l'intérieur du moteur de base de données, là où les données résident déjà, évitant chacun de ces coûts. Cet article explique ce que cela signifie en pratique et quand ce choix compte le plus. 

Qu'est-ce que l'exécution de la qualité des données dans la base de données ? 

L'exécution de la qualité des données dans la base de données signifie que les contrôles de qualité, la détection d'anomalies, la surveillance du schéma et la logique de validation s'exécutent sous forme d'inspections basées sur SQL à l'intérieur du moteur de base de données source. La plateforme de qualité se connecte, émet des requêtes d'inspection, évalue les métriques résultantes et écrit les indicateurs de qualité dans son propre schéma. Aucun enregistrement ne quitte la base de données. 

La distinction par rapport aux architectures de pipeline externes est architecturale, pas cosmétique. Un pipeline externe extrait les données de la source, les déplace vers un environnement séparé où les contrôles de qualité s'exécutent, puis abandonne ou conserve la copie. La logique de qualité s'exécute sur la copie. La source continue d'évoluer pendant que la copie vieillit. L'exécution dans la base de données élimine complètement cette tension. 

Le passage d'ETL à ELT reflète exactement cette idée. Selon les recherches sur les pipelines de données dans les documents ScienceDirect, le modèle ELT a supplanté ETL parce qu'effectuer la logique de transformation à l'intérieur de l'entrepôt, là où le calcul et les données résident déjà, est plus rapide et plus propre sur le plan architectural. La même logique s'applique à la qualité des données : pourquoi extraire les données pour les vérifier alors que le moteur de base de données dispose déjà de tout ce qui est nécessaire pour exécuter le contrôle ? 

Les limites des pipelines externes de qualité des données que l'exécution dans la base de données évite 

Les pipelines externes de qualité des données comportent quatre limitations structurelles que les architectures dans la base de données évitent. 

• Latence et obsolescence : les contrôles de qualité s'exécutent sur des copies extraites. Au moment où le contrôle se termine, les données source ont peut-être déjà changé. Dans les environnements avec des mises à jour fréquentes ou une ingestion en continu, les pipelines externes travaillent toujours sur un instantané déjà en retard par rapport à l'état actuel. 

  
  

• Exposition à la sécurité et risque de Compliance : chaque déplacement de données constitue une surface d'attaque. L'extraction des enregistrements nécessite un transit réseau, des identifiants aux deux extrémités et une couche de stockage secondaire qui doit être sécurisée et auditée. Pour les organisations soumises au GDPR, à HIPAA, à BCBS 239 ou aux réglementations de résidence des données, l'extraction elle-même peut nécessiter une justification explicite. L'exécution dans la base de données évite cela parce qu'aucune donnée ne franchit une frontière système. 

  
  

• Surcharge opérationnelle et coût de maintenance : les pipelines externes nécessitent une infrastructure pour extraire, transporter et traiter les données séparément de la source. Ils exigent une orchestration, une surveillance, une gestion de la capacité et une gestion des échecs pour le pipeline d'extraction lui-même, indépendamment de la logique de contrôle de qualité. Selon les notes de DQOps dans leur analyse de l'architecture de qualité des données, les deux approches introduisent des coûts de maintenance qui augmentent à mesure que le nombre de contrôles se multiplie, liant la logique de qualité aux cycles d'exécution du pipeline. 

  
  

• Coût de passage à l'échelle à haut volume : dans les environnements d'entrepôt de données cloud comme Snowflake, Databricks ou Azure Synapse, l'egress des données entraîne un coût financier direct. À l'échelle des volumes de données d'entreprise, ces coûts s'accumulent. L'exécution dans la base de données utilise le calcul déjà alloué à la base de données, sans egress. 

Avantages en matière de performance et de sécurité de la qualité des données dans la base de données sur Snowflake et les entrepôts modernes 

Les entrepôts de données cloud modernes sont conçus pour l'exécution SQL à grande échelle avec traitement parallèle natif, stockage en colonnes et optimisation des requêtes. Lorsque les contrôles de qualité des données s'exécutent sous forme d'inspections SQL à l'intérieur de ces moteurs, ils bénéficient des mêmes avantages architecturaux : parallélisme, élagage des requêtes et exécution native sur le format de stockage dans lequel les données résident déjà. 

L'avantage de performance n'est pas marginal. Un contrôle de complétude sur une table d'un milliard de lignes exécuté en SQL dans Snowflake s'appuie sur un stockage en colonnes compressé avec élagage des micro-partitions. Le même contrôle dans un environnement Python externe traite les enregistrements décompressés séquentiellement, sans les optimisations natives de l'entrepôt. 

L'avantage en matière de sécurité est catégorique. Les recherches publiées dans le Journal of Big Data identifient les déplacements de données entre environnements comme un risque majeur de governance, notant que les politiques exigeant que tout traitement reste dans un environnement contrôlé sont alignées sur l'EU AI Act et le GDPR. L'exécution dans la base de données satisfait à ces exigences parce que les données ne quittent jamais l'environnement régi par ces réglementations. 

Pour Snowflake en particulier, tous les calculs de métriques, la détection d'anomalies, la validation et la surveillance du schéma s'exécutent à l'intérieur de l'environnement Snowflake sous forme de SQL natif. L'instance de la plateforme digna réside dans l'infrastructure propre du client. Seuls les résultats agrégés des métriques, et non les données au niveau des enregistrements, sont renvoyés au schéma d'observability de digna. 

Comment la qualité des données dans la base de données fonctionne dans les environnements modernes d'entrepôt de données 

La plateforme de qualité se connecte à la base de données via un connecteur standard, lance des requêtes d'inspection basées sur SQL sur les tables et vues configurées, reçoit les valeurs de métriques résultantes, les compare à des références apprises ou à des seuils définis, et écrit l'état de qualité dans son propre schéma au sein du même environnement. 

Ce modèle découple entièrement la surveillance de la qualité du déplacement des données. Le pipeline qui charge les données dans l'entrepôt s'exécute indépendamment de l'inspection de qualité. L'inspection lit les tables que le pipeline a déjà alimentées, sans intercepter ni modifier le flux de données ni exiger de modifications de la manière dont les données sont chargées. 

digna met en œuvre cela sur Snowflake, Databricks, Teradata, PostgreSQL, Oracle, MS SQL Server et Azure Synapse : digna Data Anomalies apprend des références comportementales à partir de calculs de métriques dans la base de données. digna Data Validation applique les règles métier via une inspection au niveau des enregistrements basée sur SQL. digna Schema Tracker surveille les changements structurels en interrogeant directement les métadonnées de la base de données. digna Timeliness surveille les horodatages d'arrivée des données depuis l'intérieur de la base de données. digna Data Analytics calcule des métriques de tendance à partir des données d'observability dans la base de données. Aucune ne nécessite que les données quittent le moteur de base de données. 

Quand choisir la qualité des données dans la base de données plutôt que des approches de pipeline externes 

L'argument en faveur de l'exécution dans la base de données est le plus fort dans quatre contextes qui décrivent la majorité des environnements de données d'entreprise. 

• Secteurs réglementés avec des exigences de résidence ou de sensibilité des données : les institutions financières, les organisations de santé et les entreprises soumises au GDPR, à HIPAA ou aux réglementations de souveraineté des données font face à des obligations documentées concernant l'endroit où les données peuvent être traitées. L'exécution dans la base de données maintient la surveillance de la qualité dans l'environnement contrôlé par conception, sans extraction ni accès externe à justifier auprès d'un auditeur. 

  
  

• Environnements à haut volume où le coût d'extraction n'est pas négligeable : à l'échelle des volumes de données d'entreprise, les coûts d'egress dans les entrepôts cloud, la consommation de bande passante et le calcul de traitement externe augmentent tous avec la taille des données. L'exécution dans la base de données évolue avec le propre calcul de l'entrepôt, qui est déjà provisionné. 

  
  

• Environnements où la latence de détection compte : une analyse de 2024 portant sur plus de 1 000 pipelines de données par Datachecks a révélé que 72 % des problèmes de qualité des données ne sont découverts qu'après avoir affecté les décisions métier. Les contrôles d'exécution dans la base de données s'exécutent sur l'état le plus récent de l'entrepôt, et non sur une copie extraite qui peut avoir plusieurs heures. 

  
  

• Équipes qui ont besoin d'une surveillance de la qualité sans modifier les pipelines : la surveillance de la qualité dans la base de données ne nécessite aucune modification de la manière dont les données sont chargées ni de la structure des pipelines existants. Elle s'installe comme une couche d'observation sur les tables existantes, éliminant le couplage entre la surveillance de la qualité et les cycles de développement des pipelines. 

Idée finale : l'architecture de la qualité doit correspondre à l'architecture des données 

Le passage de l'industrie vers ELT a été la reconnaissance que le calcul de transformation existe déjà à l'intérieur de l'entrepôt, et que l'extraction des données pour les transformer ailleurs était une habitude architecturale antérieure à l'infrastructure cloud moderne. La même reconnaissance s'applique à la qualité des données. Le calcul nécessaire pour vérifier la qualité existe déjà à l'intérieur de la base de données. Déplacer les données vers l'extérieur pour les vérifier introduit des coûts, de la latence et des risques que le modèle architectural n'exige pas. 

Une étude Forrester citée par Acceldata a révélé que 30 % des dirigeants ont déclaré avoir perdu des clients à cause d'inexactitudes dans les données. Les organisations qui détectent les inexactitudes le plus tôt sont celles dont la surveillance de la qualité est la plus proche des données. L'exécution dans la base de données rend cette proximité systématique. 

Les contrôles de qualité doivent s'exécuter là où résident les données.

Découvrez la qualité des données dans la base de données sur votre propre environnement. 

digna exécute tous les contrôles de qualité, la détection d'anomalies, la surveillance du schéma et la validation à l'intérieur de votre moteur de base de données. Aucune donnée ne quitte votre environnement. Aucun pipeline externe requis. Cinq modules, tous exécutés dans la base de données sur Snowflake, Databricks, Teradata, PostgreSQL et plus encore. 

Réserver une démonstration personnalisée Explorer l'architecture de la plateforme