Ejemplos de linaje de datos: 6 escenarios reales con SQL y diagramas

A ejemplo de linaje de datos Muestra, para una parte concreta de SQL, qué tablas y columnas de origen alimentan qué columnas de salida, y a través de qué transformaciones pasan los datos en el proceso. Los seis ejemplos resueltos a continuación cubren las situaciones con las que se encuentran realmente los ingenieros de datos: una simple INSERTAR-SELECCIONARSe incluyen ejemplos como una transformación multi-CTE, una cadena de vistas, un procedimiento almacenado con SQL dinámico, una cadena de modelos dbt y un flujo ETL entre bases de datos. Cada ejemplo proporciona el código SQL y describe con precisión el aspecto del grafo de linaje.

Cómo leer estos ejemplos

Cada grafo de linaje contiene dos tipos de aristas. A directo El borde significa que los datos fluyen físicamente desde una columna de origen a una columna de destino, posiblemente a través de una función o agregación. indirecto borde significa que una columna da forma al resultado sin aterrizar en él: columnas utilizadas en DÓNDE, UNIRSE, y AGRUPACIÓN POR cláusulas. Ignorar los bordes indirectos es la forma en que el análisis de impacto falla, porque eliminar una columna de filtro rompe un informe con la misma seguridad que eliminar una seleccionada. Si estos términos son nuevos, comience con ¿Qué es el linaje de datos? y Cómo funciona el linaje a nivel de columna, luego regresa.

Ejemplo 1: un ejemplo sencillo de linaje de datos INSERT-SELECT

El punto de partida para cualquier debate sobre linajes: una declaración que escriba datos agregados en una tabla resumen.

INSERTAR EN sales_summary (region, total_amount) SELECCIONAR c.region, SUMA(o.amount) DE orders o UNIR clientes c EN o.customer_id = c.id DONDE o.status = 'completed' AGRUPAR POR c.region;

El gráfico de linaje tiene tres tablas (pedidos, clientes, resumen_de_ventas) y estos bordes a nivel de columna:

Columna objetivo	Columna de origen	Tipo de borde	A través de
resumen_de_ventas.región	clientes.región	Directo	copia sin formato
resumen_de_ventas.importe_total	pedidos.cantidad	Directo	SUMA()
resumen_de_ventas.*	estado de los pedidos	Indirecto	DÓNDE filtrar
resumen_de_ventas.*	pedidos.id_cliente, clientes.id	Indirecto	UNIRSE condición

Observa lo que el gráfico ya te muestra y que una vista a nivel de tabla no te mostraría: clientes.email y todas las demás columnas intactas no juegan ningún papel aquí, y estado de los pedidos Importa aunque nunca aparezca en el resultado. Muchas herramientas de linaje omiten por completo ese último aspecto; SQLFlow modela el linaje directo e indirecto como tipos de relación separados y configurables.

Ejemplo 2: transformación multi-CTE

Es donde empiezan a situarse los diagramas de linaje dibujados a mano, porque cada CTE es una relación temporal por la que debe pasar el gráfico sin perder de vista las fuentes originales.

WITH daily AS ( SELECT order_date, customer_id, SUM(amount) AS day_total FROM orders GROUP BY order_date, customer_id ), ranked AS ( SELECT customer_id, day_total, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY day_total DESC) AS rn FROM daily ) SELECT customer_id, day_total AS best_day_revenue FROM ranked WHERE rn = 1;

El gráfico de linaje se muestra a diario y clasificado como nodos intermedios, por lo que la ruta completa de la columna interesante es: pedidos.cantidad → SUMA() → total_diario → clasificado.total_día → mejores_ingresos_del_díaLa función de ventana crea una cadena más sutil: rn se calcula a partir de ID del cliente (partición) y total_del_día (ordenar), y luego DONDE rn = 1 marcas rn una entrada indirecta a cada columna de salida. Entonces pedidos.cantidad influencias mejores_ingresos_del_día De dos maneras: directamente a través de la suma e indirectamente a través de la clasificación que decide qué fila se conserva. Un solucionador que solo compara patrones de nombres de columna no puede ver esa segunda vía.

Ejemplo 3: una cadena de opiniones

Las vistas se acumulan. En un almacén de datos maduro, un informe suele estar a tres o cuatro definiciones de vista de distancia de las tablas físicas, y la pregunta "¿de dónde viene realmente este número?" requiere recorrer toda la cadena.

CREATE VIEW v_active_customers AS SELECT id, name, email FROM customers WHERE status = 'active'; CREATE VIEW v_customer_revenue AS SELECT a.id, a.name, SUM(o.amount) AS revenue FROM v_active_customers a JOIN orders o ON o.customer_id = a.id GROUP BY a.id, a.name;

El gráfico muestra v_ingresos_clientes.ingresos trazando a través del límite de la vista de regreso a pedidos.cantidad, con estado de los clientes adjunta como una arista indirecta heredada del filtro de la primera vista. También expone algo útil en la otra dirección: v_clientes_activos.correo electrónico es seleccionada por la primera vista pero no es consumida por nada posterior. Las columnas muertas como esta son exactamente lo que se desea encontrar antes de una limpieza o migración, y son invisibles a nivel de tabla. Cuando las definiciones de vista utilizan SELECCIONAR *SQLFlow expande el asterisco contra el esquema para que cada columna heredada siga resolviéndose a su origen físico.

Ejemplo 4: procedimiento almacenado con SQL dinámico

Este es el ejemplo que distingue a las herramientas de linaje, ya que el nombre de la tabla de destino ni siquiera existe como texto literal en el código. Aquí hay un procedimiento de SQL Server que crea una instantánea mensual a través de una tabla temporal y una tabla ensamblada dinámicamente. INSERTAR:

CREATE PROCEDURE dbo.load_monthly_snapshot @month VARCHAR(7) AS BEGIN SELECT o.customer_id, SUM(o.amount) AS month_total INTO #monthly FROM dbo.orders o WHERE CONVERT(VARCHAR(7), o.order_date, 126) = @month GROUP BY o.customer_id; DECLARE @sql NVARCHAR(MAX) = N'INSERT INTO dbo.snapshot_monthly (customer_id, month_total) ' + N'SELECT customer_id, month_total FROM #monthly'; EXEC sp_executesql @sql; END

El gráfico de linaje correcto supera ambos obstáculos: pedidos.cantidad → SUMA() → #mensual.total_mes → instantánea_mensual.total_mes, con pedidos.fecha_del_pedido como un borde indirecto a través del DÓNDE cláusula y la @mes parámetro rastreado como una entrada para ese filtro. Para llegar allí se requiere un analizador procedimental T-SQL real (no un divisor de sentencias), seguimiento de tabla temporal a través de sentencias y resolución de la cadena SQL entregada a sp_executesqlSQLFlow cuenta con analizadores procedimentales específicos para SQL Server T-SQL y Oracle PL/SQL, resuelve SQL dinámico dentro de los procedimientos y, además, genera un gráfico de llamadas que muestra qué procedimientos invocan a cuáles, lo que permite visualizar el linaje entre procedimientos. El SQL dinámico es el punto ciego más común en las herramientas de linaje; si evalúa alguna herramienta, pruébela primero con este patrón.

Ejemplo 5: cadena de modelos dbt

dbt te ofrece linaje a nivel de modelo listo para usar a través de árbitro()Pero la pregunta interesante es a nivel de columna: ¿qué campo de origen alimenta qué columna del almacén de datos, a través de qué cambios de nombre en la zona de preparación?

-- models/staging/stg_orders.sql SELECT id AS order_id, customer_id, amount, status FROM {{ source('raw', 'orders') }} -- models/marts/fct_customer_revenue.sql SELECT customer_id, SUM(amount) AS lifetime_revenue FROM {{ ref('stg_orders') }} WHERE status = 'completed' GROUP BY customer_id

Importa el manifiesto dbt del proyecto en SQLFlow y el gráfico resolverá las referencias de plantilla en una cadena de columnas concreta: cantidad.de.pedidos.crudos → stg_orders.amount → SUMA() → fct_ingresos_clientes.ingresos_de_vida, con el cambio de nombre identificación → ID de pedido conservado en el salto de etapa y estado Se transmite como una arista indirecta desde el filtro del almacén. Dado que el manifiesto vincula los modelos con los objetos del almacén que crean, el mismo gráfico concilia el linaje administrado por dbt con todo lo demás que toca esas tablas fuera de dbt.

Ejemplo 6: ETL entre bases de datos

El sector inmobiliario abarca diversos motores. Un flujo típico consiste en extraer una base de datos operativa de SQL Server a un almacenamiento en la nube, cargarla en el entorno de pruebas de Snowflake y, posteriormente, transformarla en un esquema analítico. El proceso de carga y transformación se ve así:

-- Snowflake COPIAR EN staging.orders_raw DESDE @s3_extract/orders/; INSERTAR EN analytics.fct_orders (order_id, customer_id, amount_usd) SELECCIONAR r.order_id, r.customer_id, r.amount * fx.rate DESDE staging.orders_raw r UNIR staging.fx_rates fx EN fx.currency = r.currency;

Dentro del lado de Copo de Nieve, el gráfico muestra cantidad_USD como una columna calculada con dos padres directos, cantidad_bruta_de_pedidos y fx_rates.rate, unidos mediante la expresión aritmética, más divisa como un borde indirecto de la condición de unión. Para cubrir toda la canalización, se alimentan ambos lados de SQLFlow en sus propios dialectos: la lógica de extracción T-SQL analizada con el analizador de SQL Server y los scripts de Snowflake analizados con el analizador de Snowflake, de un total de 39 analizadores específicos de dialecto. En implementaciones empresariales, los resultados se almacenan en un repositorio de linaje persistente que escanea por lotes conjuntos de más de 100 bases de datos y más de un millón de columnas, de modo que la imagen de extremo a extremo de SQL Server a Snowflake reside en un solo gráfico y se puede exportar a DataHub, Microsoft Purview u OpenMetadata.

Lo que tienen en común los seis ejemplos

Cada gráfico anterior se derivó exclusivamente del texto SQL y los metadatos del esquema. Ese es el método principal detrás de Linaje de datos basado en SQLDado que la lógica de transformación ya reside en SQL, el análisis estático de ese SQL reconstruye el linaje sin agentes, sin acceso al registro de consultas y sin leer jamás una sola fila de sus datos. Las diferencias entre los ejemplos radican únicamente en la dificultad del análisis, desde un único INSERTAR-SELECCIONAR para SQL dinámico dentro de un procedimiento.

Ejemplo	Lo que hace	La parte difícil
1. INSERTAR-SELECCIONAR	bordes directos versus indirectos	Modelado DÓNDE/UNIRSE columnas como linaje
2. CTE múltiple	Relaciones intermedias	Entradas de la función de ventana; ruta de filtrado por rango
3. Ver cadena	Definiciones anidadas	Expansión estelar; detección de columnas muertas
4. Procedimiento almacenado	Código de procedimiento	Tablas temporales y resolución SQL dinámica
5. Cadena dbt	SQL con plantillas	Resolviendo árbitro()/fuente() a objetos reales
6. ETL entre bases de datos	Múltiples dialectos	Integración de gráficos por motor en un único repositorio

Preguntas frecuentes

¿Qué es un diagrama de linaje de datos?

Un diagrama de linaje de datos es un grafo dirigido en el que los nodos representan tablas, vistas o columnas, y las aristas muestran cómo fluyen los datos entre ellas mediante transformaciones SQL. Los diagramas a nivel de columna, como los descritos en esta página, dibujan una arista por cada relación entre una columna de origen y una de destino, anotada con la función o cláusula que la creó.

¿Puedo reproducir estos ejemplos yo mismo?

Sí. Pegue cualquiera de los fragmentos SQL anteriores en el Visualizador SQLFlow gratuitoSeleccione el dialecto correspondiente y el diagrama interactivo aparecerá en segundos. La edición en la nube tiene una versión gratuita.

¿Cuál es la diferencia entre linaje directo e indirecto?

El linaje directo significa que los datos fluyen desde una columna de origen a una columna de destino, por ejemplo SUMA(pedidos.cantidad) alimentación cantidad_total. El linaje indirecto significa que una columna influye en el resultado sin aparecer en él, como por ejemplo una DÓNDE filtro o UNIRSE clave. SQLFlow realiza un seguimiento de ambos como tipos de borde separados y conmutables; la mayoría de las herramientas solo capturan el flujo directo.

¿Es posible extraer el linaje de procedimientos almacenados y SQL dinámico?

Sí, pero necesita un analizador procedimental, no solo un analizador de consultas. SQLFlow cuenta con analizadores específicos para Oracle PL/SQL y SQL Server T-SQL, rastrea el linaje a través de parámetros y tablas temporales, resuelve cadenas SQL construidas dentro de procedimientos y dibuja el gráfico de llamadas entre procedimientos.

¿Las herramientas de código abierto manejan estos ejemplos?

Parcialmente. Bibliotecas como sqllineage y sqlglot Son realmente eficaces analizando consultas individuales y manejan bien los ejemplos 1 y 2. Los ejemplos que vale la pena probar antes de confirmar son del 4 al 6: código procedimental con SQL dinámico, linaje indirecto como un tipo de arista independiente y la integración de un conjunto de dialectos en un gráfico interactivo. Ejecute su procedimiento almacenado más complejo con cualquier herramienta que evalúe y compare los resultados.

¿Con qué dialectos SQL funcionan estos ejemplos?

SQLFlow incluye 39 analizadores sintácticos específicos para distintos dialectos, como Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL y Trino. Los ejemplos anteriores utilizan sintaxis SQL genérica, T-SQL, SQL con plantillas dbt y Snowflake, y cada una se analiza con su propia gramática en lugar de una genérica ANSI.