De BigQuery a Databricks: un marco estratégico

Migración como una evolución estratégica

Muchas organizaciones admiten hoy en día una variedad de cargas de trabajo de datos y análisis en BigQuery, pero están explorando formas de integrar las cargas de trabajo de BI, ETL y de inteligencia artificial multi-modelo en un modelo operativo y de gobernanza unificado. Un open Lakehouse con una capa de gobernanza unificada puede ayudar a simplificar las operaciones, optimizar el cumplimiento en materia de datos e inteligencia artificial, ofrecer un rendimiento predecible a medida que crecen las necesidades y crear una base para nuevos casos de uso impulsados por la inteligencia artificial.

Una migración exitosa requiere algo más que copiar tablas. Exige una estrategia por fases: trasladar los datos a formatos abiertos en servicios como Google Cloud Storage, transformar la lógica cuidadosamente y validar los resultados con herramientas automatizadas. Esta guía describe un marco de migración basado en tres pilares (Proceso, Tecnología y Personas) para navegar esa transición con una interrupción mínima y un impacto empresarial medible.

Proceso: El recorrido de la migración y la evolución de la gobernanza

El pilar de Proceso define cómo se realiza la migración. El éxito depende de elegir el punto de entrada correcto y gestionar el período de transición de manera eficaz.

Evaluar

El recorrido de la migración sigue una secuencia: evaluar el patrimonio, elegir un punto de entrada, migrar, validar en operación dual y, por último, dar de baja. La evaluación va antes que todo lo demás: no se puede elegir el punto de entrada correcto sin saber qué se ejecuta actualmente. Analiza primero el patrimonio de BigQuery (conjuntos de datos, historial de consultas y consumo de ranuras) para descubrir qué cargas de trabajo generan costos, qué paneles se utilizan realmente y qué consultas nunca se realizan en las tablas. Lakebridge, el conjunto de herramientas de migración de código abierto de Databricks Labs, incluye un perfilador de BigQuery que automatiza este descubrimiento, por lo que las oleadas de migración se planifican en torno a lo que realmente se usa en lugar de lo que simplemente existe.

Elegir la estrategia

• Enfoque en BI (BI-first): Da prioridad a los paneles que los tomadores de decisiones ven todos los días. Esta ruta es adecuada para equipos cuyos paneles o productos de datos necesitan escalar y cuyos analistas desean funciones de inteligencia artificial. Reconstruye los paneles más utilizados en Databricks, leyendo los datos de BigQuery en el mismo lugar al principio, y cambia a los equipos de un caso de uso a la vez, demostrando la paridad lado a lado. Los beneficios se ven desde el primer día: paneles más rápidos y preguntas y respuestas en lenguaje natural con Genie.
• Enfoque en ETL (ETL-first): Prioriza el backend cuando el objetivo es consolidar las cargas de trabajo de transformación en el motor Photon/Spark de Databricks y optimizar el costo y el rendimiento. Esta ruta es ideal para los equipos que desean establecer primero una base de datos lista para inteligencia artificial y permitir que los consumidores posteriores, como los paneles y las aplicaciones, los sigan. El compromiso es la visibilidad: los usuarios empresariales notan pocos cambios hasta que las tuberías están listas, así que publica métricas de eficiencia y tiempo de ejecución con cada oleada. En caso de duda, deja que la evaluación decida: un alto uso de los paneles apunta a un enfoque en BI; las cargas de trabajo de transformación pesadas apuntan a un enfoque en ETL.

Elijas el punto de entrada que elijas, migra en oleadas, no de golpe. Un cambio repentino concentra todo el riesgo en un solo momento y, si algo falla, también lo hace la confianza en todo el programa. Las oleadas mantienen el radio de impacto pequeño: clasifica las cargas de trabajo en dos ejes (el valor para la organización, es decir, cuán visible es para el liderazgo, qué tan directo es su impacto en los ingresos, qué tan urgente es el plazo de cumplimiento que lo respalda y cuántas personas dependen de él en el día a día; y la complejidad de la migración) y comienza donde el valor sea alto y la complejidad baja. Cada oleada ofrece entonces un éxito empresarial visible, se reconcilia antes de que comience la siguiente y deja el manual del equipo listo más rápidamente para la siguiente. Reserva el cambio repentino para el raro caso de un patrimonio pequeño y de bajo riesgo en el que ejecutar dos plataformas cueste más de lo que protege. 

Ejecutar

1. Migración directa (Lift and shift): Migra la lógica SQL existente "tal como está" a Databricks Lakehouse. Esto establece rápidamente una base funcional y permite a los equipos validar la paridad antes de optimizar.
2. Modernizar: Una vez que esté estable, refactoriza las tuberías de alto valor en Lakeflow Spark Declarative Pipelines para lograr una orquestación automatizada, calidad de datos integrada y un marco unificado para procesamiento por lotes y en tiempo real (streaming).

La mayoría de las organizaciones pasan por una fase de Operación Dual utilizando Lakehouse Federation para "replicar" cargas de trabajo con fines de validación. La clave para obtener el ROI es establecer "criterios de éxito" claros (por ejemplo, una paridad del 99.9 %) para activar la baja inmediata de las tuberías heredadas, eliminando así el costo de ejecutar dos plataformas.

La operación dual funciona en ambas direcciones, y el puente adecuado depende de tu punto de entrada. Los equipos con enfoque en BI utilizan Lakehouse Federation para que Databricks pueda leer BigQuery mientras los paneles se trasladan primero. Los equipos con enfoque en ETL hacen lo contrario: trasladan la ingesta y la transformación a Databricks, depositan las tablas curadas en formatos abiertos y permiten que BigQuery siga dando servicio a los paneles y aplicaciones existentes desde esa misma copia única (sin tuberías de doble escritura, sin trabajos de exportación y sin una segunda copia que reconciliar). 

Migrar en oleadas mantiene esta ventana de operación dual corta y limitada: solo las cargas de trabajo de la oleada actual soportan el costo de ejecutarse en dos plataformas a la vez, por lo que la factura de la operación dual se mantiene proporcional a lo que está realmente en marcha, no a todo el patrimonio. Trata a BigQuery como una capa de servicio temporal en lugar de un destino: las tablas externas son de solo lectura en el lado de BigQuery y tienen limitaciones como la actualización manual del esquema después de los cambios en el mismo, así que planifica la transición de la capa de servicio a Databricks Lakehouse como el paso final del recorrido.

Gobernar

Unity Catalog transforma la gobernanza de ser un obstáculo a convertirse en un motor estratégico. Ofrece una asignación fluida de 3 niveles (Proyecto → Catálogo, Conjunto de datos → Esquema, Tabla → Tabla) que replica los permisos de BigQuery al tiempo que añade un linaje automático de extremo a extremo y trata a los modelos de inteligencia artificial como ciudadanos de primera clase.

La asignación va más allá de la jerarquía de objetos. Unity Catalog te ofrece la misma protección detallada de forma nativa: los filtros de filas restringen el acceso fila por fila, y las máscaras de columnas y las etiquetas gestionan la seguridad a nivel de columna, de modo que la protección viaja con los datos en lugar de tener que reconstruirse desde cero. Y una regla de secuenciación de campo: migra los permisos antes que los datos, de modo que la transición de cada oleada cambie el lugar donde reside una tabla, pero nunca quién puede verla.

Tecnología: construyendo la base abierta

El pilar técnico se centra en trasladar los datos a formatos abiertos en servicios como Google Cloud Storage, migrar la lógica a Databricks SQL y Spark, y validar los resultados. 

Migrar de BigQuery a Databricks implica tres flujos de trabajo: Migración de datos, Migración de lógica y Validación.

Migración de datos

Elige la ruta según el volumen y la frescura de los datos. El historial masivo se traslada más rápido mediante la exportación de BigQuery a Parquet en Google Cloud Storage, que suele ser la opción más económica a escala, y la exportación sirve también como una copia estática en un momento dado que simplifica la validación. Las tablas que se actualizan continuamente se leen a través del conector de Storage API o se redirigen en el origen, y los conjuntos de datos pequeños que cambian con frecuencia pueden seguir siendo consultables mediante federación hasta que llegue su turno. Todo llega en formatos abiertos, listo para las capas de medallón (medallion layers).

Migración de lógica

Nunca conviertas un patrimonio manualmente. Tres niveles lo cubren: transpilación basada en reglas (por ejemplo, Lakebridge) para la mayor parte del SQL rutinario, conversión asistida por LLM para las particularidades de los dialectos e ingenieros reservados para los casos verdaderamente complejos. La orquestación sigue el mismo patrón: las consultas programadas y los DAG de Composer se asignan a Lakeflow Jobs.

Validación

Presupuesta para la validación con la misma seriedad que para la migración en sí; en el campo, a menudo consume un esfuerzo comparable. Ejecútala en tres niveles: integridad (recuento de filas), consistencia (esquemas y tipos) y precisión (reconciliación de agregados más hash a nivel de fila), automatizada con Lakebridge reconcile, que es compatible con BigQuery como origen nativo. Una lección de campo: las pequeñas diferencias en las funciones integradas entre los dos dialectos SQL pueden romper las comparaciones de hash; investiga las discrepancias antes de asumir que hubo pérdida de datos. La paridad aquí es lo que activa la baja de los sistemas anteriores en el recorrido del Proceso.

Formatos de tabla abierta

Los cimientos abiertos dan frutos incluso antes de que termine la migración. Como Delta Lake y Apache Iceberg son formatos abiertos, las tablas que guardas en Google Cloud Storage pueden ser leídas por más herramientas además de Databricks: BigQuery lee Delta a través de tablas externas de BigLake e Iceberg mediante tablas externas de Iceberg, y la federación de catálogos entre Unity Catalog y BigQuery (actualmente en versión preliminar) permite que ambas plataformas gobiernen y consulten las mismas tablas sin necesidad de copiarlas. El almacenamiento está desacoplado del motor: una copia de los datos y muchos motores. Dicha interoperabilidad no es un beneficio secundario; es la capacidad que respalda los patrones de transición de bajo riesgo descritos en la sección Proceso.

Personas: Organización del equipo moderno de datos e IA

El tercer pilar ofrece el ROI definitivo de una migración: una fuerza laboral más capacitada y unificada.

Poner fin a la cultura de transferencias. En las arquitecturas heredadas, la brecha entre los analistas de SQL y los científicos de datos genera silos. En Databricks, los Notebooks compartidos permiten que todo el equipo trabaje en el mismo espacio de trabajo, lo que reduce los problemas de comunicación.

Desarrollo de nuevas habilidades. Genie actúa como un puente para los equipos que usan principalmente SQL. Los analistas pueden usar lenguaje natural para generar código en Python o Spark, lo que convierte a los analistas tradicionales en profesionales de datos versátiles sin una curva de aprendizaje compleja. Combina esta asistencia de IA diaria con capacitación estructurada, cursos de Databricks Academy y certificaciones basadas en roles para que las nuevas habilidades se adopten en toda la organización en lugar de depender solo de unos pocos entusiastas autodidactas.

Rigor en la ingeniería. Los equipos pasan de "escribir consultas" a "crear productos de datos" mediante la adopción de prácticas recomendadas de ingeniería de software como Unity Catalog, la integración con Git y CI/CD.

Lecciones de la experiencia

Se repiten seis patrones en las migraciones exitosas a BigQuery según nuestra experiencia en proyectos de migración:

• Crea perfiles antes de planificar. En la mayoría de los entornos, un porcentaje significativo de las tablas de BigQuery rara vez o nunca se consultan. Analizar primero el historial de consultas y el uso de los slots significa que migras las cargas de trabajo que importan y retiras el resto.
• Define los criterios de paridad antes de iniciar la ejecución dual. Acuerda el umbral de éxito de antemano (por ejemplo, una reconciliación del 99.9% entre recuentos de filas, agregados y hashes); sin esto, el periodo de prueba no tiene una condición de salida.
• No conviertas SQL manualmente. La transpilación basada en reglas junto con la conversión asistida por IA se encarga de la mayor parte del entorno; reserva a los ingenieros para lo que sea genuinamente complejo.
• Asigna la gobernanza de uno a uno primero y moderniza después. La asignación de proyecto a catálogo, de conjunto de datos a esquema y de tabla a tabla en Unity Catalog conserva los permisos existentes —incluidas las políticas a nivel de fila y columna— desde el primer día; las etiquetas más avanzadas, los controles basados en atributos y la gobernanza basada en linaje se pueden incorporar después del cambio definitivo.
• Trata BI-first como un proyecto de gestión del cambio. La tecnología suele ser la mitad más sencilla; los analistas cuyos paneles de control se trasladan necesitan capacitación, defensores internos y un ciclo de retroalimentación.
• Ajusta el tamaño de tu infraestructura. Una vez que las cargas de trabajo se validen en Databricks, retira el procesamiento duplicado para evitar ejecutar y pagar por el mismo trabajo en dos lugares ("gasto doble"). Celebra las migraciones completadas, no solo los lanzamientos.

Conclusión

Migrar a Databricks no es un solo salto; es una secuencia de decisiones que puedes planificar: qué punto de entrada se adapta a tu equipo, cómo organizar las fases para que cada una consiga un éxito antes de que comience la siguiente, y qué puente mantiene a BigQuery y Databricks funcionando en paralelo hasta que el último panel de control se migre por completo. Si aciertas con esta secuencia, el proceso, la tecnología y las personas se refuerzan mutuamente: la migración de datos, la transformación de la lógica y la validación retiran el entorno anterior por un lado, mientras que los analistas que consultan en lenguaje natural con Genie y los ingenieros que entregan productos de datos gobernados construyen sobre él por el otro.

El resultado es un lakehouse abierto, una migración en la que tu organización puede confiar fase tras fase y un equipo listo para aprovechar al máximo lo que tiene disponible.

¿Todo listo para planificar tu migración? Explora el centro de migración de Databricks, evalúa tu entorno con el kit de herramientas de código abierto Lakebridge o ponte en contacto con tu equipo de cuentas de Databricks para solicitar una evaluación de migración.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original