La performance est souvent négligée lors du lancement d'améliorations de la qualité des données. Les approches non performantes ont généralement des effets inverses lorsque l'initiative prend de l'ampleur et que les coûts de l'entrepôt de données commencent à augmenter.

Qu'est-ce que la « performance » en matière de qualité des données ?

Dans le contexte de la qualité des données, la performance fait référence à l'efficacité, l'économie de coûts et la capacité d'exécution des vérifications — en termes de calcul, de latence, d'utilisation des ressources et de coût de l'entrepôt. Une mauvaise performance entraîne des factures élevées, des goulots d'étranglement et une confiance réduite dans votre système de qualité.

Ce blog décrit les mesures de performance de Soda et vous guide à travers les considérations que nous avons mises dans la construction de notre produit. Sans optimisation de la performance, vous êtes forcé de choisir entre une qualité des données complète et le contrôle des coûts. L'approche de Soda élimine cette contrainte grâce à quatre stratégies clés décrites ci-dessous.

1. Offrir une configurabilité complète

Notre philosophie est de donner le plein contrôle aux ingénieurs pour opérer les vérifications de la qualité des données et de combiner cela avec des valeurs par défaut judicieuses. Tous les aspects de la gestion de la qualité des données peuvent être gérés dans les fichiers de configuration YAML par les ingénieurs. Ces aspects incluent les détails techniques sur les données qui sont scannées automatiquement, la manière dont les données sont scannées, les vérifications spécifiques qui sont effectuées, sur quels filtres et ainsi de suite.

Exemple checks.yaml :

checks for dim_customer:
  - invalid_count(email_address) = 0:
          valid format: email
          name: Ensure values are formatted as email addresses
  - missing_count(last_name) = 0:
          name: Ensure there are no null values in the Last Name column
  - duplicate_count(phone) = 0:
          name: No duplicate phone numbers
  - freshness(date_first_purchase) < 7d:
          name: Data in this dataset is less than 7 days old
  - schema:
          warn:
            when schema changes: any
          name

La gestion de la qualité des données en tant que code par des ingénieurs offre ce contrôle. Le principe des valeurs par défaut judicieuses garantit qu'une configuration minimale est nécessaire dans les cas les plus courants. En même temps, le contrôle est disponible sous forme d'options de configuration. Avec ces options de configuration, les ingénieurs peuvent ajuster la sémantique ou le comportement des vérifications et ainsi rester en contrôle complet de la manière dont et où les vérifications sont exécutées. Les solutions de boîte noire ne peuvent pas fournir le contrôle nécessaire pour garder les coûts sous contrôle lorsque la qualité des données est étendue à l'ensemble de l'équipe de données.

Un avantage supplémentaire est que le contrôle offre un meilleur rapport signal/bruit. Sans les contrôles de configuration avancés disponibles pour ajuster, cela peut devenir coûteux ou entraîner une fatigue d'alerte.

2. Vérifiez uniquement ce qui est important

Pour réduire les coûts de qualité des données, vous devez vous assurer que les vérifications ne sont exécutées que sur les parties de données qui comptent. Si un travail Airflow produit un lot quotidien de nouvelles données, il est logique que toutes ou presque toutes les vérifications soient effectuées sur ces nouvelles données uniquement et non sur l'ensemble de données historique.

Outre le partitionnement temporel, le mécanisme de filtre générique de Soda peut être utilisé pour réduire encore la taille des données vérifiées en exécutant des vérifications uniquement sur tout autre groupe comme par client ou région.

checks for fact_internet_sales:
  - group by:
      group_limit: 10
      name: average discount
      query: |
        SELECT sales_territory_key, AVG(discount_amount) as average_discount
        FROM fact_internet_sales
        GROUP BY sales_territory_key
      fields:
        - sales_territory_key
      checks:
        - average_discount:
            fail: when > 40
            name

3. Regrouper les métriques dans des requêtes uniques

Soda guide les utilisateurs à effectuer autant de vérifications que possible dans une exécution de scan unique. C'est parce que pour chaque exécution de scan, toutes les métriques ne seront calculées qu'une seule fois ! Et autant de métriques que possible seront exécutées sur une seule requête. Illustrons cela par un exemple.

Il existe plusieurs vérifications sur l'ensemble de données dim_customers. Elles peuvent provenir de différents intervenants :

• Il devrait y avoir entre 10 000 et 30 000 clients

• La moyenne dans employee_count ne devrait pas changer de plus de 15% jour après jour

• Pas de catégories invalides (haut, moyen, bas), en ignorant les valeurs manquantes NULL et 'N/A'

Dans SodaCL (Soda Checks Language), cela se traduit par :

checks for dim_customers:
   - row_count between 10000 and 30000
   - change percent for avg(employee_count) between -15 and +15
   - invalid_count(category) = 0:
       valid values: ['high', 'medium', 'low']
       missing values: ['N/A'

Lisez la référence complète de configuration SodaCL

Chacune de ces vérifications sera basée sur des métriques et chaque métrique sera traduite par Soda en une expression SQL. Pour les vérifications ci-dessus, les métriques seront :

L'approche directe serait d'exécuter des requêtes individuelles pour ces différentes métriques. Étant donné que Soda utilise un concept de fichiers de vérification et de scan, nous permettons l'optimisation pour calculer toutes les métriques pour un ensemble de données dans une requête unique. Cela économise de nombreuses passes sur les données dans le moteur SQL, économisant ainsi de nombreux coûts indirects que la qualité des données peut potentiellement générer dans l'entrepôt de données.

La requête unique résultante devient :

SELECT
   COUNT(*) as row_count
   AVG(cst_size) as avg_cst_size,
   COUNT(CASE WHEN NOT (cat IS NULL OR cat IN ('N/A')) 
	   AND NOT (cat IN ('high','medium','low')) 
	   THEN 1 END) as invalid_count_category
FROM

À mesure que le nombre de vérifications et de métriques augmente, les économies de coûts augmenteront également. Pour s'assurer que cela évolue (les moteurs SQL ont une limite de longueur de requête), nous avons intégré un point de coupure à 50 métriques par requête.

Lisez plus sur les vérifications définies par l'utilisateur utilisant la configuration SQL.

4. Tirer parti des fonctionnalités spécifiques du moteur de calcul

Lors de la traduction des métriques en requêtes, nous utilisons également les optimisations spécifiques au moteur SQL. Par exemple, Snowflake a un cache de requête qui stocke les résultats de requête pendant un certain temps afin que si la même requête est effectuée, elle soit chargée depuis le cache au lieu d'être recalculée. Nous tirons parti de cela dans le calcul du profilage des données.

Conclusion

Soda est conçu et mis en œuvre pour assurer qu'il peut optimiser et fournir le contrôle nécessaire aux ingénieurs. Donner le contrôle aux ingénieurs leur permet de régler les paramètres chaque fois que les valeurs par défaut judicieuses ne sont pas suffisantes.

Avec l'approche axée sur la configuration de Soda, vous maintenez un contrôle granulaire sur :

• Ce qu'il faut scanner (colonnes, tables ou partitions spécifiques)

• Quand scanner (fréquence de planification et déclencheurs)

• Comment scanner (taux d'échantillonnage, délais de requête)

• Où scanner (sélection d'entrepôt de calcul)

Cette configurabilité signifie que vous pouvez équilibrer la couverture de la qualité des données avec l'optimisation des coûts de l'entrepôt en fonction de vos besoins spécifiques.

Limiter les données vérifiées à celles qui sont nécessaires réduit le coût et augmente la vitesse. Regrouper autant de métriques que possible dans des requêtes uniques fournit des économies de coûts significatives, en particulier lors de l'élargissement de la qualité des données à une équipe plus large.

Ensemble, ces mesures s'additionnent et vous aident à garder vos coûts d'entrepôt de données sous contrôle.

Lisez notre documentation pour voir Comment Soda fonctionne.

Besoin d'aide ?

• Que peut faire Soda pour vous ? Demandez une démonstration.

• Rejoignez la communauté Soda sur Slack.