Planteamiento y contexto
Un conjunto de datos relacional contiene clientes, cuentas y transferencias. El entrevistador pregunta cuándo utilizar BigQuery Graph frente a SQL recursivo y cómo diseñar un plan de migración y reversión que pueda verificarse.
Esto está dirigido a roles de ingeniería de datos, ingeniería de analítica y plataformas de datos. Asuma que los datos ya residen en BigQuery y que la funcionalidad de grafos todavía está en vista previa (Preview); no trate Preview como una promesa incondicional de producción. La tarea consiste en comparar la expresión de relaciones, la gobernanza, el costo y la compatibilidad en lugar de afirmar que un lenguaje de consulta siempre es más rápido.
Qué evalúa el entrevistador
El entrevistador quiere ver si usted clasifica la forma de la consulta antes de elegir un modelo de grafos o relacional, y si separa la semántica de negocio, los planes de ejecución y el ciclo de vida de la plataforma. Una respuesta sólida explica cómo coexiste un modelo de grafos con las tablas existentes, cuándo el SQL recursivo es más simple y cómo los mismos datos de referencia validan una migración.
Preguntas de clarificación antes de responder
- ¿El recorrido es de profundidad fija o la profundidad y los predicados de ruta cambian frecuentemente?
- ¿El resultado debe devolver nodos, aristas y rutas, o solo métricas agregadas?
- ¿Se trata de analítica por lotes (batch) o de un recorrido en línea de baja latencia?
- ¿Los resultados deben coincidir fila por fila con los reportes SQL existentes y cuánto dura la ventana de compatibilidad de Preview?
- ¿Cuáles son las restricciones de presupuesto, volumen de escaneo, concurrencia, frescura y clientes posteriores (downstream)?
Estructura de respuesta en treinta segundos
“Primero enruto según la forma de la consulta y el objetivo de entrega. Mantengo SQL para recorridos fijos de uno o dos saltos, agregaciones simples y recursos SQL existentes valiosos; evalúo BigQuery Graph cuando los patrones multisalto, los predicados de ruta y la reutilización de relaciones son frecuentes. Defino nodos, aristas, etiquetas y claves, y luego comparo GQL y SQL recursivo sobre las mismas instantáneas (snapshots) en cuanto a resultados, bytes, latencia y costo. Dado que Graph está en Preview, SQL sigue siendo la ruta principal mientras Graph se ejecuta en modo sombra (shadow mode) hasta que se superen los controles.”
Análisis detallado paso a paso
1. Traducir la pregunta relacional a un grafo
Modele Person y Account como nodos y Owns y Transfers como aristas dirigidas, con tiempo, monto e identificadores estables en cada arista. “Encontrar cuentas alcanzables en tres saltos y agregar el riesgo” es naturalmente una consulta de ruta; “sumar los montos de transferencias por día” es más fácil de auditar como una agregación relacional. El modelo debe responder a la pregunta, no a la novedad de la funcionalidad.
2. Elegir la ruta según la forma de la consulta
Para profundidad fija, columnas fijas y salidas exclusivamente de métricas, el SQL recursivo a menudo gana en legibilidad y controles de acceso existentes. Para profundidad variable, patrones de ruta reutilizables y resultados que incluyen nodos y aristas, las construcciones de GQL como GRAPH, MATCH, NEXT y RETURN expresan la intención de forma más cercana a la relación. La decisión gira en torno a la frecuencia de cambios y el costo de mantenimiento, no en reemplazar SQL por completo.
3. Modelar y fijar los límites semánticos
Defina etiquetas, dirección, propiedades anulables, tiempo de validez y manejo de aristas duplicadas. Asigne a cada relación de negocio una clave para que las cargas repetidas no inflen el conteo de rutas. Defina si un recorrido puede volver a visitar un nodo para evitar un ciclo ilimitado. La sintaxis de grafos expresa relaciones; los permisos del conjunto de datos, las políticas de columnas y las auditorías siguen protegiendo los campos confidenciales.
4. Construir una prueba comparativa de ejecución dual reproducible
Utilice instantáneas representativas y familias de consultas: vecinos de un salto, transferencias de dos saltos, rutas delimitadas por tiempo, aristas duplicadas y resultados vacíos. Proyecte tanto el SQL recursivo como GQL en IDs de nodo, IDs de arista, longitud de ruta y agregaciones antes de comparar conjuntos y conteos. Registre los bytes procesados, el uso de slots, la latencia p50/p95, los fallos y la frescura; una sola muestra de tiempo de reloj no es evidencia.
snapshot = freeze_partition(as_of)
expected = run_recursive_sql(snapshot, query_family)
candidate = run_gql_graph(snapshot, query_family)
assert canonicalize(expected) == canonicalize(candidate)
gate = error_rate < 0.01 and p95_ms <= budget and cost_per_query <= limit5. Mantener la interoperabilidad entre Graph y SQL
Cuando los reportes aún requieran entradas tabulares, proyecte los resultados del grafo en una tabla y únalos con agregaciones o dimensiones de SQL. Cuando ambas rutas usen las mismas relaciones, evite duplicar nodos y aristas. La documentación de Google describe la combinación de consultas de grafos con SQL mediante GRAPH_TABLE, de modo que la migración se puede dividir por familia de consultas en lugar de reescribir cada pipeline.
6. Evaluar el riesgo de Preview y la reversión
Registre por separado las regiones, versiones, cuotas y límites de soporte de Preview. Mantenga SQL como la ruta principal y ejecute Graph en modo sombra. Habilítelo por familia de consultas solo después de superar los controles de paridad de resultados, presupuesto, permisos y monitoreo. El desfase de esquemas (schema drift), las diferencias de resultados, los fallos de cuota o las anomalías de costo deben redirigir de vuelta a SQL mientras se preservan las instantáneas, el texto de las consultas y las métricas de ejecución.
Respuesta de muestra de alta calidad
Comenzaría con la forma de la consulta. Los reportes con profundidad fija, columnas fijas y agregaciones simples se mantienen en SQL recursivo para limitar la dependencia de Preview y el costo de migración. Evaluaría BigQuery Graph para análisis exploratorio con profundidad variable, patrones de ruta reutilizables y salidas de nodos y aristas. Modelaría clientes y cuentas como nodos, la propiedad y las transferencias como aristas dirigidas, y fijaría claves, dirección, tiempo de validez y reglas de ciclos. La migración ejecutaría ambas rutas en paralelo sobre la misma instantánea, canonicalizaría las salidas a los mismos nodos, aristas, longitudes de ruta y métricas, y luego compararía resultados, bytes, p95, fallos y costo. SQL sigue siendo la opción principal mientras Graph se ejecuta en modo sombra. Un cambio de región, cuota o versión en Preview —o cualquier control fallido— redirige de vuelta a SQL. Eso cubre expresión, gobernanza, costo y reversión en lugar de simplemente afirmar que las consultas de grafos son más rápidas.
Errores comunes
- Cambiar a un grafo tras ver varios JOINs → la agregación de profundidad fija puede no necesitar un grafo → enrute primero por la forma de la consulta.
- Comparar la latencia de una sola consulta → la caché, la instantánea y el sesgo crean resultados accidentales → utilice familias de consultas e instantáneas fijas.
- Ignorar aristas duplicadas y ciclos → los conteos de rutas se inflan o el recorrido no termina → defina claves, reglas de visita y profundidad máxima.
- Tratar Graph Preview como una dependencia estable → las regiones, cuotas y semántica pueden cambiar → mantenga SQL como principal con ejecución en sombra y controles.
- Copiar un segundo conjunto de datos de grafos durante la migración → la frescura y la gobernanza divergen → reutilice el origen y proyecte los resultados.
Preguntas de seguimiento y respuestas
¿Qué cambia si la profundidad pasa de dos saltos a una profundidad arbitraria?
La decisión puede cambiar. La profundidad arbitraria y los predicados de ruta aumentan los riesgos de mantenimiento y de recursos de SQL recursivo, por lo que la expresión de rutas de Graph se vuelve más atractiva. Aun así, establezca una profundidad máxima, un límite de visita de nodos y un control de costo; nunca acepte recorridos ilimitados.
¿Qué pasa si el negocio requiere un resultado en línea de un segundo?
Primero verifique si la analítica por lotes de BigQuery cumple con el objetivo de latencia. Si no es así, conserve un almacén de grafos en línea o un índice precalculado y use BigQuery Graph para la validación por lotes y el historial. No sacrifique el SLO en línea en favor de la uniformidad de lenguaje.
¿Cómo demuestra que GQL y el SQL recursivo son equivalentes?
Congele la misma instantánea de partición, ejecute una familia de consultas que cubra resultados vacíos, aristas duplicadas, límites de tiempo y ciclos, y luego canonicalice claves estables y agregaciones antes de comparar. Conserve el contraejemplo más pequeño, la versión de la consulta y la instantánea de datos para cada diferencia.
¿Cuándo se puede eliminar el respaldo en SQL?
Solo después de que el estado de Preview, las regiones y la compatibilidad con clientes sean estables y varios ciclos de datos superen los controles de resultados, costos, latencia, permisos y simulacros de fallos con la aprobación del propietario de los datos. De lo contrario, mantenga SQL.
¿Cómo deberían funcionar los permisos cuando las relaciones de grafos son confidenciales?
Reutilice las políticas de conjunto de datos, de columna y de fila, y luego vuelva a verificar los campos visibles en la proyección del resultado del grafo. La alcanzabilidad de un nodo o arista puede revelar una relación en sí misma, por lo que la exposición de rutas debe incluirse en los casos de prueba de auditoría.