Linaje de datos de Spark SQL: Linaje de columnas para canalizaciones de Spark

Linaje de datos de Spark SQL es el mapa a nivel de columna de cómo se mueven los datos a través de su código Spark SQL: qué columnas de origen alimentan cada tabla escrita por un CREAR TABLA ... COMO SELECCIONAR o INSERTAR SOBREESCRIBIRy a través de la cual se realizan vistas temporales, uniones, funciones y filtros en el proceso. Flujo de SQL de Gudu Crea ese mapa analizando estáticamente tu Spark SQL con un analizador de dialecto Spark dedicado; no se requiere instrumentar el clúster, conectar ningún listener ni ejecutar ningún trabajo. Pega el SQL y obtén el diagrama de linaje.

Oyentes en tiempo de ejecución frente a análisis estático: dos maneras de obtener el linaje de Spark

En el mundo de Spark existen dos enfoques fundamentalmente diferentes para el linaje, y la mayoría de los equipos acaban necesitando ambos.

Linaje en tiempo de ejecución El enfoque adoptado por OpenLineage y su integración con Spark adjunta un oyente a la sesión de Spark y emite eventos de linaje a medida que se ejecuta cada trabajo. Cumple su función a la perfección: registra qué se ejecutó, cuándo y con qué conjuntos de datos, con metadatos a nivel de ejecución que el análisis estático no puede conocer. Si su pregunta es "¿qué afectó realmente la canalización de anoche?", el linaje en tiempo de ejecución responde a esa pregunta.

Linaje estático — El enfoque de SQLFlow — analiza el texto SQL en sí y deduce el linaje del código, como lo haría un compilador. Esto cubre todo lo que la captura en tiempo de ejecución no puede hacer estructuralmente:

• SQL que aún no has ejecutado. Una nueva canalización en una solicitud de extracción, un script heredado de otro equipo, una lista de tareas pendientes programadas trimestralmente: ninguna de estas acciones genera eventos en tiempo de ejecución hasta que se ejecutan, posiblemente contra datos de producción.
• Revisión de código. Los revisores pueden ver el gráfico completo de dependencias a nivel de columna de un cambio antes de aprobarlo, en lugar de descubrir el impacto después de la implementación.
• Auditorías de migración. Cuando trasladas cargas de trabajo a Spark, normalmente desde Hive, necesitas el gráfico de dependencias de la completo código fuente, incluyendo tareas que solo se ejecutan a fin de mes. El análisis estático lo lee todo en una sola pasada.

	Oyentes en tiempo de ejecución (OpenLineage)	Análisis estático (SQLFlow)
Linaje capturado	Por cada ejecución del trabajo, a medida que se ejecuta	Desde el texto SQL, antes de que se ejecute nada
Requiere	Listener configurado en la sesión de Spark; los trabajos deben ejecutarse	Los archivos SQL, más metadatos de esquema opcionales.
Cubre el código no ejecutado	No, sin carrera no hay evento.	Sí, solicitudes de extracción, tareas pendientes, trabajos que se ejecutan con poca frecuencia.
Metadatos de ejecución (tiempos, versiones)	Sí	No, solo a nivel de código.
Uso típico	Observabilidad operativa de oleoductos en funcionamiento	Análisis de impacto, revisión de código, auditorías de migración, documentación de cumplimiento

Son complementarias, no contradictorias. El linaje en tiempo de ejecución indica qué sucedió; el linaje estático indica qué hace el código. Los adaptadores de exportación de SQLFlow para DataHub, Microsoft Purview y OpenMetadata permiten ubicar el linaje derivado estáticamente en el mismo catálogo donde se almacenan los eventos en tiempo de ejecución, de modo que ambas vistas coexisten.

Ejemplo: una cadena de vistas temporales en un CTAS

El patrón que frustra las herramientas de linaje ingenuas en Spark SQL es la cadena de vistas temporales. Los notebooks y los trabajos rutinariamente preparan la lógica a través de CREAR O REEMPLAZAR VISTA TEMPORAL pasos antes de un final CREAR TABLA ... COMO SELECCIONARAquí tienes un ejemplo conciso pero realista:

CREATE OR REPLACE TEMP VIEW clean_events AS SELECT CAST(event_time AS TIMESTAMP) AS event_ts, user_id, lower(event_name) AS event_name, amount FROM raw.events WHERE event_date >= date_sub(current_date(), 30); CREATE OR REPLACE TEMP VIEW user_daily AS SELECT user_id, to_date(event_ts) AS event_day, SUM(amount) AS daily_spend FROM clean_events WHERE event_name = 'purchase' GROUP BY user_id, to_date(event_ts); CREATE TABLE analytics.user_spend_30d USING PARQUET AS SELECT u.user_id, u.segment, d.event_day, d.daily_spend FROM user_daily d JOIN dim.users u ON u.user_id = d.user_id;

Pregunta "¿dónde está? análisis.gasto_del_usuario_30d.gasto_diario ¿De dónde vienen?” y la respuesta honesta requiere resolver dos capas de visión: gasto_diario es SUMA(clean_events.amount), y clean_events.amount es cantidad.de.eventos.en brutoSQLFlow realiza exactamente esa resolución y renderiza la cadena completa. cantidad.de.eventos.en bruto a través de eventos limpios y usuario_diario en la mesa final, con el SUMA agregación adherida al borde donde ocurre.

También capta lo que la mayoría de las herramientas omiten por completo: linaje indirectoLas columnas fecha_del_evento, nombre_del_eventoy la clave de unión ID de usuario nunca aparecen en gasto_diario, sin embargo, los tres dan forma a su valor: cambiar el filtro de 30 días o el 'compra' El predicado y cada número en la salida cambian. SQLFlow los modela como un tipo de relación distinto y conmutable, lo que permite visualizar el flujo de datos puro o la superficie de impacto completa. Para una revisión de cambios de esquema, la superficie de impacto es la vista que realmente se necesita.

Construcciones de Spark SQL que SQLFlow resuelve

SQLFlow incluye un analizador de dialecto de Spark SQL, uno de los 39 analizadores específicos de dialecto, no una gramática ANSI genérica con palabras clave de Spark añadidas. En Spark SQL específicamente, maneja las sentencias que contienen linaje:

• CREAR TABLA ... COMO SELECCIONAR (CTAS) — el componente fundamental de las canalizaciones por lotes de Spark; cada columna de salida se rastrea hasta sus orígenes a través de la consulta SELECT completa.
• INSERTAR EN y INSERTAR SOBREESCRIBIR — incluyendo la asignación de columnas posicionales entre la lista SELECT y el esquema de la tabla de destino.
• CREAR O REEMPLAZAR VISTA TEMPORAL — Las vistas temporales se resuelven y encadenan, por lo que el linaje fluye a través de las capas de preparación en lugar de detenerse en ellas.
• CTEs, subconsultas y SELECCIONAR * — Las referencias a columnas se resuelven mediante expresiones de tabla comunes y subconsultas anidadas, y las expresiones con asterisco se expanden a columnas reales cuando se dispone de metadatos del esquema.
• Funciones, conversiones y operadores de conjuntos — el linaje de cada columna de salida registra las transformaciones por las que pasó, por lo que gasto_diario no es solo “de la cantidad” sino “de cantidad a través de SUMA“.

En el fondo, se trata del motor General SQL Parser, un compilador SQL comercial desarrollado desde mediados de la década de 2000 y validado con aproximadamente 13 600 conjuntos de pruebas por dialecto. La calidad del linaje es, ante todo, un problema de análisis sintáctico, y ese corpus es lo que evita que la sintaxis de Spark en casos límite genere errores de forma silenciosa.

Dónde encaja el linaje de datos de Spark SQL en su pila

Spark rara vez funciona de forma aislada. Sus tablas suelen estar en un metastore de Hive, y una proporción cada vez mayor de cargas de trabajo de Spark se ejecuta en Databricks. SQLFlow las trata como dialectos de primera clase, analizados por separado:

• ¿Migrando trabajos de Hive a Spark? Analice el HQL heredado con el Analizador de linaje de datos de Hive y los trabajos reescritos con el analizador Spark, y comparar los dos gráficos de dependencia para verificar que no se haya omitido nada en la traducción.
• ¿Funcionando con Databricks? Analizador de linaje de datos de Databricks Cubre el dialecto SQL de Databricks, que se ha diferenciado del Spark SQL de código abierto de maneras que una única gramática compartida no maneja correctamente.
• ¿Estado mixto? SQLFlow analiza los 39 dialectos compatibles en un repositorio de linaje, por lo que un trabajo de Spark que lee una tabla producida por una tarea de Snowflake aparece como un gráfico continuo. Consulte la Descripción general de la herramienta de linaje de datos SQL para obtener la imagen completa.

Las opciones de entrada son flexibles: pegar código SQL, cargar archivos, obtener metadatos mediante JDBC o importar un manifiesto dbt para proyectos dbt-on-Spark. La salida es un diagrama interactivo con posibilidad de exploración en profundidad, además de exportaciones en formato JSON, CSV y PNG, y una API REST para la automatización; por ejemplo, analizar el código SQL modificado en una solicitud de extracción como paso de integración continua.

Despliegue y escalabilidad

SQLFlow Cloud tiene un nivel gratuito para uso interactivo; el premium cuesta $49.99/mes. Los equipos cuyo SQL no puede salir de la red ejecutan SQLFlow local Docker o Kubernetes, compatible con entornos aislados, $500/mes o $4,800 pago único por tipo de base de datos seleccionado. En ambos casos, SQLFlow realiza análisis estático únicamente del código SQL: nunca lee las filas de las tablas. Las implementaciones empresariales escanean por lotes conjuntos de más de 100 bases de datos y más de un millón de columnas con escaneos incrementales y un repositorio de linaje persistente.

Preguntas frecuentes

¿Necesito un clúster de Spark en funcionamiento para obtener el linaje?

No. SQLFlow analiza el texto de Spark SQL de forma estática. Puedes analizar un script que nunca se ha ejecutado en ningún lugar (una solicitud de extracción, una entrega de un proveedor, una lista de tareas pendientes de migración) y obtener el mismo linaje a nivel de columna que obtendrías del código de producción.

¿En qué se diferencia esto de la integración de Spark de OpenLineage?

OpenLineage captura el linaje en tiempo de ejecución mediante un oyente en la sesión de Spark, lo que resulta excelente para observar qué hicieron realmente los trabajos en ejecución. SQLFlow deriva el linaje del propio código SQL, por lo que también abarca el código que no se ha ejecutado, admite la revisión previa a la fusión y las auditorías de migración, y no requiere acceso al clúster. Ambas herramientas son complementarias; SQLFlow puede exportar a DataHub, Purview u OpenMetadata junto con el linaje en tiempo de ejecución.

¿Puede SQLFlow rastrear el linaje a través de vistas temporales?

Sí. Cadenas de CREAR O REEMPLAZAR VISTA TEMPORAL Las sentencias se resuelven de principio a fin, por lo que una columna en un CTAS final traza un recorrido a través de cada vista intermedia hasta la tabla de origen física, con las funciones y agregaciones aplicadas en cada paso.

¿Databricks SQL es lo mismo que Spark SQL en este caso?

No, SQLFlow los analiza con analizadores de dialecto independientes. Databricks SQL tiene sus propias extensiones de sintaxis, por lo que utiliza su propia gramática. Si ejecuta en Databricks, use el dialecto de Databricks; para clústeres de código abierto como Spark, EMR o autogestionados, use el dialecto de Spark SQL.

¿SQLFlow lee mis datos?

No. Analiza el código SQL y, opcionalmente, los metadatos del esquema (definiciones de tablas y columnas). Nunca se accede a los datos de las filas. Con la instalación local, incluso el texto SQL permanece dentro de su red.

¿Cuánto cuesta la integración de Spark SQL con SQLFlow?

SQLFlow Cloud comienza gratis; la versión premium cuesta $49.99/mes. La versión local cuesta $500/mes o $4,800 por única vez por tipo de base de datos seleccionado, instalable en dos servidores. Ver precios Para más detalles.