Linaje de datos de BigQuery: Linaje a nivel de columna para Google BigQuery SQL

Linaje de datos de BigQuery es el mapa de cómo se mueven los datos a través de su proyecto de BigQuery: qué tablas y columnas de origen alimentan cada tabla derivada, vista y consulta programada, y qué expresiones transforman los datos en el proceso. Dataplex de Google captura automáticamente el linaje de los trabajos de BigQuery a nivel de tabla; para ver qué columnas Para saber qué funciones y uniones usar, tienes que analizar el propio SQL. Flujo de SQL de Gudu hace exactamente eso, con un analizador de dialectos de BigQuery dedicado que resuelve anidados ESTRUCTURA campos, DESANIDO, expansión en estrella y visualización de cadenas hasta la granularidad de columna.

Por qué el linaje de BigQuery es más difícil de lo que parece

El SQL de BigQuery no es SQL ANSI genérico. Tres características en particular rompen con las herramientas de linaje que se basan en una gramática única para todos:

• Columnas anidadas y repetidas. Una sola columna de BigQuery puede ser una ESTRUCTURA que contiene otros campos, o un FORMACIÓN de estructuras. El verdadero linaje tiene que llegar al interior: pedidos.cliente.correo electrónico es un nodo de linaje diferente que pedidos.cliente.país, aunque ambos viven en una misma columna física.
• DESANIDO. Aplanar un campo repetido convierte una fila en muchas e introduce una relación derivada en medio de la consulta. Un analizador que no modela DESANIDO Se pierde la conexión entre el alias aplanado y el campo de matriz del que proviene.
• Expansión estelar. SELECCIONAR * El uso de una cadena de vistas implica que las columnas de salida no se escriben en ninguna parte del texto de la consulta. Para resolverlas, se requieren las definiciones de la tabla y la vista, no solo la instrucción que tiene delante.

SQLFlow incluye un analizador específico de BigQuery (uno de 39 analizadores sintácticos específicos de cada dialecto en el producto, no una sola gramática genérica) que maneja los tres. Resuelve cada referencia de columna a través de CTEs, subconsultas, vistas y expansión en estrella, y modela anidados ESTRUCTURA campos como nodos de linaje de primera clase.

Dataplex te proporciona el linaje de trabajos a nivel de tabla. ¿Y luego qué?

Dataplex (la capa de gobernanza de datos de Google Cloud) es realmente bueno en lo que hace: observa los trabajos de BigQuery mientras se ejecutan y registra qué tablas leyó y escribió cada trabajo. Si desea saber qué tablas llena una consulta programada dw.ingresos_diarios de pedidos crudosDataplex ya te lo dice.

Lo que la observación del trabajo en tiempo de ejecución no puede revelar es la lógica de transformación entre esas tablas: qué columnas de origen alimentan qué columnas de salida, a través de qué expresiones, filtros y uniones. Esa información solo existe en el texto SQL, por lo que extraerla requiere analizar SQL. Los dos enfoques responden a preguntas diferentes:

Pregunta	Linaje de trabajos de Dataplex	Linaje analizado por SQLFlow
¿Qué tablas afecta este trabajo?	Sí, automáticamente, por cada ejecución de trabajo.	Sí, desde SQL
¿Qué columnas alimentan? ingresos_diarios.total?	No — granularidad de la tabla	Sí, por columna de salida
¿Qué expresión calcula cada columna de salida?	No	Sí: funciones, conversiones, agregaciones
¿Qué columnas solo filtran o unen (linaje indirecto)?	No	Sí, como una capa independiente que se puede activar o desactivar.
Linaje de SQL que aún no se ha ejecutado (revisión de código, migración)	No, necesita un trabajo ejecutado	Sí, análisis estático del texto SQL.

Los equipos suelen usar ambos: Dataplex para el inventario de trabajos siempre activo y el análisis SQL cuando necesitan responder a preguntas como "¿qué falla si cambio esta columna?" o "¿de dónde proviene exactamente este número?" con precisión de columna.

Ejemplo práctico: CREATE TABLE AS SELECT con UNNEST

Aquí hay un patrón típico de BigQuery: construir una tabla de ingresos plana a partir de una tabla de pedidos con una repetición artículos de línea estructura.

CREATE TABLE dw.order_line_revenue AS SELECT o.order_id, o.customer.email AS customer_email, li.product_id, li.qty * li.unit_price AS line_revenue FROM raw.orders AS o, UNNEST(o.line_items) AS li WHERE o.status = 'COMPLETE';

Introduzca esto en SQLFlow y el linaje a nivel de columna que produce es:

• correo electrónico_del_cliente_ingresos_de_línea_de_pedido proviene del campo anidado correo electrónico.de.cliente.de.pedidos.en bruto — un miembro de la estructura, no el conjunto cliente columna.
• ingresos_línea_pedido.ingresos_línea proviene de raw.orders.line_items.qty y raw.orders.line_items.unit_price, a través del DESANIDO alias li y una multiplicación. Ambos campos de origen se encuentran dentro de una estructura repetida; SQLFlow realiza un seguimiento del aplanamiento.
• estado.de.pedidos.crudos aparece como linaje indirecto: nunca llega a la salida, pero el DÓNDE El filtro implica que se da forma a cada fila del resultado. SQLFlow modela el flujo de datos directo y la influencia indirecta (columnas WHERE, JOIN, GROUP BY) como tipos de relaciones distintos que se pueden activar o desactivar por separado en el diagrama, una distinción que la mayoría de las herramientas de linaje no hacen en absoluto.

El linaje indirecto importa más de lo que parece a primera vista. Si alguien cambia los valores de enumeración en estadoSegún una herramienta de linaje puramente directo, ingresos de línea no se ve afectado. No es así: cada cifra de ingresos posteriores cambia. El análisis de impacto sin linaje indirecto es un análisis de impacto con puntos ciegos.

Seguimiento de consultas programadas y cadenas de vistas

En la mayoría de los entornos de BigQuery, el linaje interesante no se resume en una sola instrucción, sino en una cadena: tablas sin procesar, luego una capa de vistas, después una consulta programada que materializa una tabla de informes y, finalmente, más vistas. Cualquier enlace individual es fácil de leer; la ruta completa desde una columna de origen hasta un campo del panel de control, no lo es.

SQLFlow analiza todo el conjunto en conjunto. Proporciónele el DDL de la vista más el SQL de la consulta programada (pegar, cargar archivos, metadatos en vivo a través de JDBC, un manifiesto dbt o extracción de metadatos de Grabit) y une la cadena: las referencias de vista en vista se resuelven, SELECCIONAR * Se expande en función de los esquemas reales en cada capa, y el diagrama resultante permite hacer clic en cualquier columna de salida y recorrer todas las vistas intermedias hasta las columnas de origen en las tablas originales. La exportación se realiza en formato JSON, CSV o PNG, o mediante programación a través de la API REST; las implementaciones empresariales envían el linaje a DataHub, Microsoft Purview u OpenMetadata.

Diagramas ER de restricciones NO APLICABLES

BigQuery admite claves primarias y foráneas solo como NO SE APLICA Restricciones: se declaran en el DDL para el optimizador y para la documentación, pero nunca se verifican al escribir el código. Debido a que no se aplican, muchos equipos asumen que son metadatos inútiles. No lo son; son precisamente las declaraciones de relaciones que necesita un diagrama ER.

La inferencia ER de SQLFlow entiende BigQuery NO SE APLICA Modismo PK/FK: ejecute su DDL a través de él y dibujará el diagrama entidad-relación a partir de restricciones como AGREGAR CLAVE PRIMARIA (order_id) NO ES OBLIGATORIO y la coincidencia CLAVE EXTRANJERA ... REFERENCIAS ... NO SE APLICAN declaraciones. El resultado es un modelo ER de su almacén generado directamente a partir del DDL que ya tiene, para esquemas cuya documentación de relaciones probablemente no exista en ningún otro lugar.

¿Para qué utilizan los equipos el linaje de datos de BigQuery?

• Análisis de impacto antes de los cambios de esquema: encuentra cada consulta programada, vista e informe que una columna realmente alimenta, incluyendo a través de DESANIDO y el acceso a la estructura, antes de cambiarle el nombre o volver a escribirla.
• Corrección de errores numéricos: Recorra la cadena de vistas en sentido inverso, desde una métrica del panel de control, hasta los campos y expresiones de origen exactos que la generaron.
• Planificación de la migración: Al mover elementos hacia o desde BigQuery, el gráfico de dependencias le indica en qué orden mover los elementos y qué puede dejar atrás de forma segura. SQLFlow crea el mismo gráfico a nivel de columna para Copo de nieve y Amazon RedshiftDe esta forma, las migraciones entre almacenes de datos se pueden mapear en ambos lados con una sola herramienta.
• Cumplimiento y auditoría: Demostrar qué campos de origen se incorporan a una salida regulada con la granularidad de columna que solicitan los auditores, generada a partir del SQL en lugar de mantenerse manualmente.

Privacidad, implementación y precios

SQLFlow realiza análisis estático del código SQL y metadatos del esquema únicamente. Nunca lee las filas de sus tablas de BigQuery y no necesita una cuenta de servicio con acceso a datos: el texto SQL y DDL son suficientes. SQLFlow Cloud tiene un nivel gratuito (el premium cuesta $49.99/mes). Para entornos regulados, SQLFlow local Se ejecuta en Docker o Kubernetes dentro de su propia red, aislado de la red si es necesario, a $500/mes o $4,800 por única vez por tipo de base de datos seleccionado; los detalles completos están en el página de preciosLas implementaciones empresariales realizan escaneos por lotes de entornos con 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

¿Acaso Dataplex no me proporciona ya el linaje de BigQuery?

Sí, a nivel de tabla. Dataplex registra automáticamente qué tablas lee y escribe cada trabajo de BigQuery, lo que constituye un inventario de trabajos muy completo. Sin embargo, no extrae la lógica de transformación interna del SQL (qué columnas alimentan qué, mediante qué expresiones). Para ello, se necesita una herramienta que analice el SQL, como hace SQLFlow.

¿Puede SQLFlow rastrear el linaje a través de columnas STRUCT y ARRAY?

Sí. El analizador de BigQuery modela los campos de estructura anidados como nodos de linaje individuales, por lo que correo electrónico del cliente y cliente.país tienen linaje separado y rastrea campos a través de DESANIDO aplanamiento de columnas repetidas.

¿Cómo maneja SQLFlow la instrucción SELECT * en las vistas de BigQuery?

Las expresiones de estrella se expanden contra las definiciones reales de tabla y vista, por lo que cada columna implícita obtiene un linaje explícito. Esto funciona a través de cadenas de vistas de varias capas, donde las columnas detrás de una SELECCIONAR * Puede definirse desde varias perspectivas anteriores.

¿Puede mapear el linaje a través de consultas y vistas programadas de forma conjunta?

Sí. Analice la consulta SQL programada y vea el DDL como un solo trabajo y SQLFlow une la cadena de extremo a extremo, de modo que pueda rastrear una columna de informe a través de la consulta de materialización y cada vista intermedia hasta las columnas de origen sin procesar.

¿SQLFlow necesita acceso a mis datos de BigQuery?

No. Se trata de un análisis estático: texto SQL más metadatos de esquema opcionales. Los datos de las filas de la tabla nunca se leen. Con la instalación local, incluso el texto SQL permanece dentro de su red.

¿Cuánto cuesta SQLFlow?

SQLFlow Cloud es gratuito; las cuentas premium cuestan 49,99 € al mes. SQLFlow On-Premise cuesta 500 € al mes o 4800 € por única vez según el tipo de base de datos seleccionado, y se puede instalar en dos servidores.