digna Engine: elija dónde se perfilan sus datos
|
4
minuto de lectura
Desde el principio, digna ha perfilado los datos allí donde residen: las comprobaciones se ejecutan dentro de su propia base de datos y digna trabaja con los resultados, no con copias de sus tablas. Para la mayoría de las conexiones sigue siendo la opción adecuada, y por eso se mantiene como valor predeterminado.
Sin embargo, no todos los sistemas de origen son un lugar cómodo para ese trabajo, y no todas las preguntas pueden responderse dentro de una sola base de datos. Release 2026.11 aborda ambas cuestiones con el digna Engine, un segundo lugar donde puede ejecutarse el profiling, y con una comprobación de integridad referencial que abarca dos conexiones, incluso cuando apuntan a dos tecnologías de base de datos distintas. El vídeo de un minuto muestra ambas.
Un ajuste en cada conexión de base de datos
Cada conexión de base de datos en digna tiene ahora una ubicación de profiling con dos valores. Source Database es el valor predeterminado y funciona como hasta ahora: el profiling se ejecuta en la base de datos a la que apunta la conexión. digna Engine traslada ese trabajo al Engine, de modo que el sistema de origen sirve los datos y el Engine realiza el profiling. El ajuste está disponible para todas las tecnologías de origen que admite digna y, como pertenece a la conexión, se decide una vez por sistema y no tabla por tabla.
Cuándo mantener el profiling en la base de datos de origen
Cuando las comprobaciones se ejecutan en el origen, los datos permanecen dentro del sistema al que pertenecen, lo que simplifica la configuración y encaja con las políticas que exigen precisamente eso. Además, los data warehouses analíticos están diseñados para este tipo de trabajo, agregando tablas grandes cerca de donde se almacenan, así que en una plataforma con margen, perfilar in situ suele ser la opción más natural: todo el trabajo en un sistema y un único lugar donde consultar qué se ejecutó y cuándo.
Cuándo perfilar en el digna Engine
El panorama cambia cuando el origen está muy cargado. Una base de datos operativa que atiende aplicaciones todo el día, un warehouse que funciona al límite durante la ventana de procesamiento nocturno o una plataforma en la que cada consulta compite con cargas de trabajo de negocio son sistemas en los que un equipo puede querer que la monitorización añada la menor carga posible. Cambiar esa conexión al digna Engine mantiene el trabajo de profiling fuera del origen.
Qué opción resulta más ligera depende del tamaño de las tablas, de la red y de lo cargado que esté cada origen, y por eso el ajuste es por conexión: puede perfilar in situ en el warehouse con capacidad de sobra y usar el Engine para el sistema de producción que no la tiene, dentro del mismo proyecto de digna.
Integridad referencial entre conexiones y tecnologías
En digna Data Validation, una comprobación de integridad referencial confirma que cada clave de un dataset tiene un registro coincidente en el dataset al que hace referencia. Dentro de una base de datos es una comparación sencilla, pero los entornos de datos rara vez residen ya en una sola base de datos. Un maestro de clientes puede estar en Oracle mientras los pedidos que lo referencian llegan a PostgreSQL, o un warehouse puede migrar de Teradata a Snowflake área por área, dejando tablas padre e hijas en plataformas distintas.
Con Release 2026.11, esas relaciones pueden comprobarse directamente, entre fuentes de datos en conexiones y tecnologías diferentes: Teradata y Snowflake, Oracle y PostgreSQL, Databricks y SQL Server, o cualquier otra pareja de tecnologías que admita digna. La comprobación funciona con ambas ubicaciones de profiling y, cuando una conexión perfila en la base de datos de origen, solo se exportan al Engine las columnas clave para la comparación. En el Dashboard puede ver cuándo una comprobación se ejecuta entre dos conexiones, de modo que quien lea el resultado sepa que abarca dos sistemas.
Su infraestructura, elija la ubicación que elija
Ambas ubicaciones de profiling se ejecutan en su propia infraestructura, on-premises o en su nube privada, y el digna Engine se ejecuta allí junto al resto de digna. Elegirlo cambia dónde se realiza el profiling dentro de su entorno, no si sus datos salen de él.
La documentación de profiling explica en detalle la ubicación de profiling, y la documentación de Data Validation trata las comprobaciones de integridad referencial y los demás tipos de reglas.
El digna Engine forma parte de Release 2026.11, que también presentó digna Agentic y digna Data Reconciliation; el resumen de la versión recorre las tres novedades.
Reserve una demo para ver ambas ubicaciones de profiling y una comprobación de integridad referencial entre tecnologías en sus propias conexiones.
Preguntas frecuentes
¿Qué es la ubicación de profiling de una conexión de base de datos?
Un ajuste en cada conexión de base de datos que decide dónde se ejecuta el profiling: Source Database, el valor predeterminado, ejecuta las comprobaciones dentro de la propia base de datos, y digna Engine ejecuta el profiling en el digna Engine. Está disponible para todas las tecnologías de origen que admite digna.
¿Qué ubicación de profiling debemos elegir?
Depende del origen. Perfilar en la base de datos de origen mantiene todo el trabajo en un solo lugar, lo que conviene a plataformas con capacidad de sobra, mientras que el digna Engine evita cargar un origen muy ocupado. Como el ajuste es por conexión, puede elegir de forma distinta para cada sistema.
¿Puede digna comprobar la integridad referencial entre Teradata y Snowflake?
Sí. digna Data Validation comprueba la integridad referencial entre fuentes de datos en conexiones y tecnologías diferentes, como Teradata y Snowflake, Oracle y PostgreSQL, o Databricks y SQL Server, con cualquiera de las dos ubicaciones de profiling.
¿Salen nuestros datos de nuestra infraestructura cuando usamos el digna Engine?
No. El digna Engine se ejecuta en su propia infraestructura, on-premises o en su nube privada, como el resto de digna.
