Le digna Engine : choisissez où vos données sont profilées
|
4
minute de lecture
Depuis le début, digna profile les données là où elles se trouvent : les contrôles s'exécutent dans votre propre base de données, et digna travaille avec les résultats plutôt qu'avec des copies de vos tables. Pour la plupart des connexions, c'est toujours la bonne réponse, et c'est pourquoi cela reste le comportement par défaut.
Tous les systèmes sources ne se prêtent toutefois pas à ce travail, et toutes les questions ne trouvent pas leur réponse dans une seule base de données. La Release 2026.11 répond aux deux avec le digna Engine, un second lieu où le profiling peut s'exécuter, et avec un contrôle d'intégrité référentielle qui couvre deux connexions, même lorsqu'elles pointent vers deux technologies de base de données différentes. La vidéo d'une minute présente les deux.
Un paramètre sur chaque connexion de base de données
Chaque connexion de base de données dans digna dispose désormais d'un emplacement de profiling à deux valeurs. Source Database est la valeur par défaut et fonctionne comme avant : le profiling s'exécute dans la base de données vers laquelle pointe la connexion. digna Engine déplace ce travail dans l'Engine : le système source fournit les données et l'Engine se charge du profiling. Le paramètre est disponible pour toutes les technologies sources prises en charge par digna, et comme il appartient à la connexion, vous décidez une fois par système plutôt que table par table.
Quand conserver le profiling dans la base de données source
Lorsque les contrôles s'exécutent dans la source, les données restent dans le système qui les détient, ce qui simplifie la configuration et répond aux politiques qui exigent précisément cela. Les entrepôts de données analytiques sont en outre conçus pour ce type de travail, en agrégeant de grandes tables au plus près de leur stockage. Sur une plateforme disposant de marge, le profiling sur place est donc souvent le choix le plus naturel, avec tout le travail dans un seul système et un seul endroit où consulter ce qui a tourné et quand.
Quand profiler dans le digna Engine
La situation change lorsque la source est très sollicitée. Une base de données opérationnelle qui sert des applications toute la journée, un entrepôt qui tourne à la limite de ses capacités pendant la fenêtre de traitement nocturne, ou une plateforme où chaque requête est en concurrence avec les charges de travail métier : dans tous ces systèmes, une équipe peut souhaiter que la surveillance ajoute le moins de charge possible. Basculer une telle connexion sur le digna Engine tient le travail de profiling à l'écart de la source.
L'option la plus légère dépend de la taille des tables, du réseau et de la charge de chaque source, c'est pourquoi le paramètre se règle par connexion : vous pouvez profiler sur place l'entrepôt qui dispose de capacité et utiliser l'Engine pour le système de production qui n'en a pas, au sein du même projet digna.
L'intégrité référentielle entre connexions et technologies
Dans digna Data Validation, un contrôle d'intégrité référentielle confirme que chaque clé d'un dataset a un enregistrement correspondant dans le dataset auquel elle fait référence. Au sein d'une base de données, c'est une comparaison simple, mais les patrimoines de données résident rarement dans une seule base. Un référentiel clients peut se trouver dans Oracle tandis que les commandes qui le référencent arrivent dans PostgreSQL, ou un entrepôt peut migrer de Teradata vers Snowflake un domaine après l'autre, laissant tables parents et enfants sur des plateformes différentes.
Avec la Release 2026.11, ces relations peuvent être vérifiées directement, entre des sources de données situées sur des connexions et des technologies différentes : Teradata et Snowflake, Oracle et PostgreSQL, Databricks et SQL Server, ou toute autre paire de technologies prises en charge par digna. Le contrôle fonctionne avec les deux emplacements de profiling, et lorsqu'une connexion profile dans la base de données source, seules les colonnes clés sont exportées vers l'Engine pour la comparaison. Dans le Dashboard, vous voyez quand un contrôle porte sur deux connexions, afin que toute personne qui lit le résultat sache qu'il couvre deux systèmes.
Votre infrastructure, quel que soit l'emplacement choisi
Les deux emplacements de profiling s'exécutent sur votre propre infrastructure, on-premises ou dans votre cloud privé, et le digna Engine y tourne aux côtés du reste de digna. Le choisir change l'endroit où le profiling a lieu dans votre environnement, pas le fait que vos données le quittent ou non.
La documentation sur le profiling explique en détail l'emplacement de profiling, et la documentation Data Validation couvre les contrôles d'intégrité référentielle et les autres types de règles.
Le digna Engine fait partie de la Release 2026.11, qui a également introduit digna Agentic et digna Data Reconciliation ; la présentation de la version passe en revue les trois.
Réservez une démo pour voir les deux emplacements de profiling et un contrôle d'intégrité référentielle entre technologies sur vos propres connexions.
Questions fréquentes
Qu'est-ce que l'emplacement de profiling d'une connexion de base de données ?
Un paramètre de chaque connexion de base de données qui détermine où le profiling s'exécute : Source Database, la valeur par défaut, exécute les contrôles dans la base de données elle-même, et digna Engine exécute le profiling dans le digna Engine. Il est disponible pour toutes les technologies sources prises en charge par digna.
Quel emplacement de profiling choisir ?
Cela dépend de la source. Le profiling dans la base de données source garde tout le travail au même endroit, ce qui convient aux plateformes disposant de capacité, tandis que le digna Engine soulage une source très sollicitée. Comme le paramètre se règle par connexion, vous pouvez faire un choix différent pour chaque système.
digna peut-il vérifier l'intégrité référentielle entre Teradata et Snowflake ?
Oui. digna Data Validation vérifie l'intégrité référentielle entre des sources de données situées sur des connexions et des technologies différentes, notamment Teradata et Snowflake, Oracle et PostgreSQL, ou Databricks et SQL Server, avec l'un ou l'autre emplacement de profiling.
Nos données quittent-elles notre infrastructure lorsque nous utilisons le digna Engine ?
Non. Le digna Engine s'exécute sur votre propre infrastructure, on-premises ou dans votre cloud privé, comme le reste de digna.
