Migración de Oracle a BigQuery
En este documento, se proporciona una orientación de alto nivel sobre cómo migrar de Oracle a BigQuery. Se describen las diferencias fundamentales entre las arquitecturas y se sugieren formas de migración desde almacenes de datos y data marts que se ejecutan en Oracle RDBMS (incluido Exadata) a BigQuery. En este documento, se proporcionan detalles que se pueden aplicar a Exadata, ExaCC y Oracle Autonomous Data Warehouse, ya que usan software compatible con Oracle.
Este documento está dirigido a arquitectos empresariales, DBA, desarrolladores de aplicaciones y profesionales de seguridad de TI que desean migrar de Oracle a BigQuery y resolver desafíos técnicos en el proceso de migración.
También puedes usar la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva para traducir consultas ad hoc. Oracle SQL, PL/SQL y Exadata son compatibles con ambas herramientas en la versión preliminar.
Antes de la migración
Para garantizar una migración exitosa al almacén de datos, comienza a planificar tu estrategia de migración al comienzo del cronograma del proyecto. Para obtener información sobre cómo planificar el trabajo de migración de forma sistemática, consulta Qué y cómo migrar: el framework de migración.
Planificación de la capacidad de BigQuery
De forma interna, la capacidad de procesamiento de análisis en BigQuery se mide en ranuras. Una ranura de BigQuery es la unidad de capacidad de procesamiento patentada de Google que se requiere para ejecutar consultas de SQL.
BigQuery calcula de forma continua cuántas ranuras se requieren para las consultas a medida que se ejecutan, pero asigna ranuras a las consultas en función de un programador justo.
Puedes elegir entre los siguientes modelos de precios cuando planifiques la capacidad de las ranuras de BigQuery:
Precios on demand: En el caso de los precios on demand, BigQuery cobra por la cantidad de bytes procesados (tamaño de datos) por lo que solo pagas por las consultas que ejecutas. Para obtener más información sobre cómo BigQuery determina el tamaño de los datos, consulta Cálculo del tamaño de los datos. Debido a que las ranuras determinan la capacidad de procesamiento subyacente, puedes pagar el uso de BigQuery según la cantidad de ranuras que necesites (en lugar de bytes procesados). De forma predeterminada, los proyectos de Google Cloud están limitados a un máximo de 2,000 ranuras.
Precios basados en la capacidad: Con los precios basados en la capacidad, compras reservas de ranuras de BigQuery (un mínimo de 100) en lugar de pagar por los bytes procesados de las consultas que ejecutes. Recomendamos los precios basados en la capacidad para las cargas de trabajo de los almacenes de datos empresariales, que suelen ver muchas consultas simultáneas de informes y de extracción-transformación-carga (ELT) con un consumo predecible.
Para ayudar con la estimación de ranuras, recomendamos configurar la supervisión de BigQuery mediante Cloud Monitoring y analizar los registros de auditoría con BigQuery. Muchos clientes usan Looker Studio (por ejemplo, ve un Ejemplo de código abierto de un Panel de Looker Studio), Looker o Tableau como frontends para visualizar datos de registro de auditoría de BigQuery, específicamente para el uso de ranuras en consultas y proyectos. También puedes aprovechar los datos de tablas del sistema de BigQuery para supervisar el uso de ranuras en trabajos y reservas. Para ver un ejemplo, consulta un ejemplo de código abierto de un panel de Looker Studio.
Supervisar y analizar el uso de ranuras con regularidad te ayuda a estimar la cantidad total de ranuras que necesita la organización a medida que creces en Google Cloud.
Por ejemplo, supongamos que primero reservas 4,000 ranuras de BigQuery para ejecutar 100 consultas de complejidad media de forma simultánea. Si observas tiempos de espera altos en los planes de ejecución de tus consultas y tus paneles muestran un uso alto de ranuras, esto podría indicar que necesitas ranuras adicionales de BigQuery para ayudar a las cargas de trabajo. Si deseas comprar ranuras tú mismo a través de compromisos anuales o de tres años, puedes comenzar a usar las reservas de BigQuery mediante la consola de Google Cloud o la herramienta de línea de comandos de bq.
Si tienes preguntas relacionadas con tu plan actual y las opciones anteriores, comunícate con tu representante de ventas.
Security in Google Cloud
En las siguientes secciones, se describen los controles de seguridad comunes de Oracle y cómo puedes asegurarte de que tu almacén de datos permanezca protegido en un entorno de Google Cloud.
Identity and Access Management (IAM)
Oracle proporciona usuarios, privilegios, roles y perfiles para administrar el acceso a los recursos.
BigQuery usa IAM para administrar el acceso a los recursos y proporciona una administración de acceso centralizada a los recursos y las acciones. Los tipos de recursos disponibles en BigQuery son organizaciones, proyectos, conjuntos de datos, tablas y vistas. En la jerarquía de políticas de IAM, los conjuntos de datos son recursos secundarios de los proyectos. Una tabla hereda los permisos del conjunto de datos que la contiene.
Para otorgar acceso a un recurso, asigna uno o más roles a un usuario, un grupo o una cuenta de servicio. Los roles de organización y proyecto afectan la capacidad para ejecutar trabajos o administrar el proyecto, mientras que los roles de conjunto de datos afectan la capacidad para acceder a los datos dentro de un proyecto o modificarlos.
IAM proporciona estos tipos de roles:
- Los roles predefinidos están destinados a brindar compatibilidad con patrones de control de acceso y casos de uso comunes. Los roles predefinidos proporcionan acceso detallado a un servicio específico y los administra Google Cloud.
Entre los roles básicos se incluyen los de propietario, editor y visualizador.
Los roles personalizados proporcionan acceso detallado según una lista de permisos especificada por el usuario.
Cuando asignas roles predefinidos y básicos a un usuario, los permisos otorgados son una unión de los permisos de cada rol individual.
Seguridad a nivel de la fila
La seguridad de etiquetas de Oracle (OLS) permite restringir el acceso a los datos fila por fila. Un caso de uso típico para la seguridad a nivel de fila es limitar el acceso de un vendedor a las cuentas que administra. Cuando implementas la seguridad a nivel de las filas, obtienes un control de acceso detallado.
Para lograr la seguridad a nivel de las filas en BigQuery, puedes usar las vistas autorizadas y las políticas de acceso a nivel de fila. Para obtener más información sobre cómo diseñar e implementar estas políticas, consulta Introducción a la seguridad a nivel de fila de BigQuery.
Encriptación de disco completo
Oracle ofrece encriptación de datos transparente (TDE) y encriptación de red para encriptación en datos y en tránsito. La TDE requiere la opción de Seguridad avanzada, que tiene una licencia por separado.
BigQuery encripta todos los datos en reposo y en tránsito de forma predeterminada, sin importar la fuente o cualquier otra condición, y esto no se puede desactivar. BigQuery también admite claves de encriptación administradas por el cliente (CMEK) para usuarios que deseen controlar y administrar claves de encriptación de claves en Cloud Key Management Service. Para obtener más información sobre la encriptación en Google Cloud, consulta Encriptación en reposo predeterminada y Encriptación en tránsito.
Enmascaramiento y ocultamiento de datos
Oracle usa el enmascaramiento de datos en Real Application Testing y el ocultamiento de datos, que te permite enmascarar los datos que se muestran en las consultas que emiten las aplicaciones.
BigQuery admite el enmascaramiento dinámico de datos a nivel de columna. Puedes usar el enmascaramiento de datos a fin de ocultar de manera selectiva los datos de las columnas para grupos de usuarios y, al mismo tiempo, permitir el acceso a la columna.
Puedes usar la protección de datos sensibles para identificar y ocultar información de identificación personal (PII) sensible en BigQuery.
Comparación entre BigQuery y Oracle
En esta sección, se describen las diferencias clave entre BigQuery y Oracle. Estos aspectos destacados te ayudan a identificar obstáculos de migración y a planificar los cambios necesarios.
Arquitectura del sistema
Una de las principales diferencias entre Oracle y BigQuery es que BigQuery es un EDW en la nube sin servidores con capas de almacenamiento y procesamiento independientes que pueden escalar según las necesidades de la consulta. Debido a la naturaleza de la oferta sin servidores de BigQuery, no estás limitado por las decisiones de hardware; en su lugar, puedes solicitar más recursos para tus consultas y usuarios a través de reservas. BigQuery tampoco requiere la configuración del software y la infraestructura subyacentes, como el sistema operativo (SO), los sistemas de red y los sistemas de almacenamiento, incluido el escalamiento y la alta disponibilidad. BigQuery se encarga de las operaciones administrativas, de escalabilidad y de administración. En el siguiente diagrama, se ilustra la jerarquía de almacenamiento de BigQuery.
Conocer la arquitectura de procesamiento de consultas y el almacenamiento subyacente, como la separación entre el almacenamiento (Colossus) y la ejecución de consultas (Dremel) y cómo Google Cloud asigna recursos (Borg) puede ser útil para comprender las diferencias de comportamiento y optimizar el rendimiento de las consultas y la rentabilidad. Si deseas obtener más detalles, consulta las arquitecturas del sistema de referencia para BigQuery, Oracle y Exadata.
Arquitectura de almacenamiento y datos
La estructura de datos y almacenamiento es una parte importante de cualquier sistema de análisis de datos porque afecta el rendimiento, el costo, la escalabilidad y la eficiencia de las consultas.
BigQuery separa el almacenamiento y el procesamiento de datos y almacena datos en Colossus, en los que los datos se comprimen y se almacenan en un formato de columna llamado Capacitor.
BigQuery opera directamente con datos comprimidos sin descomprimir mediante Capacitor. BigQuery proporciona conjuntos de datos como el nivel más alto de abstracción para organizar el acceso a las tablas como se muestra en el diagrama anterior. Se pueden usar esquemas y etiquetas para una mayor organización de tablas. BigQuery ofrece particiones para mejorar el rendimiento y los costos de las consultas, y administrar el ciclo de vida de la información. Los recursos de almacenamiento se asignan a medida que los consumes, y su asignación se anula a medida que quitas datos o eliminas tablas.
Oracle almacena datos en formato de fila con el formato de bloque de Oracle organizado en segmentos. Los esquemas (que son propiedad de los usuarios) se usan para organizar tablas y otros objetos de base de datos. A partir de Oracle 12c, se usa la arquitectura multiusuario a fin de crear bases de datos conectables dentro de una instancia de base de datos para lograr un aislamiento adicional. La partición se puede usar para mejorar el rendimiento de las consultas y las operaciones del ciclo de vida de la información. Oracle ofrece varias opciones de almacenamiento para bases de datos independientes y de Real Application Clusters (RAC), como ASM, un sistema de archivos del SO y un sistema de archivos del clúster.
Exadata proporciona una infraestructura de almacenamiento optimizada en servidores de celda de almacenamiento y permite que los servidores de Oracle accedan a estos datos con transparencia mediante el uso de ASM. Exadata ofrece opciones de Compresión híbrida en columnas (HCC) para que los usuarios puedan comprimir tablas y particiones.
Oracle requiere capacidad de almacenamiento aprovisionada previamente, tamaños precisos y configuraciones de incremento automático en segmentos, archivos de datos y espacios de tabla.
Ejecución y rendimiento de las consultas
BigQuery administra el rendimiento y escala el nivel de la consulta para maximizar el rendimiento del costo. BigQuery usa muchas optimizaciones, por ejemplo:
- Ejecución de consultas en memoria
- Arquitectura de árbol de varios niveles basada en el motor de ejecución Dremel
- Optimización automática del almacenamiento en Capacitor
- 1 petabit por segundo de ancho de banda de bisección total con Jupiter
- Administración de recursos con ajuste de escala automático para proporcionar consultas rápidas a escala de petabytes
BigQuery recopila estadísticas de columnas mientras se cargan los datos y, además, incluye información del plan de consultas y el tiempo de diagnóstico. Los recursos de consulta se asignan de acuerdo con el tipo de consulta y complejidad. Cada consulta usa una cierta cantidad de ranuras, que son unidades de procesamiento que incluyen una cantidad determinada de CPU y RAM.
Oracle proporciona trabajos de recopilación de estadísticas de datos. El optimizador de la base de datos usa estadísticas para proporcionar planes de ejecución óptimos. Es posible que se necesiten índices para realizar búsquedas de filas rápidas operaciones de unión. Oracle también proporciona un almacén de columnas en memoria para el análisis en memoria. Exadata proporciona varias mejoras de rendimiento, como el análisis inteligente de celdas, los índices de almacenamiento, la caché flash y las conexiones de InfiniBand entre los servidores de almacenamiento y los de bases de datos. Real Application Clusters (RAC) se puede usar para lograr una alta disponibilidad del servidor y escalar aplicaciones con uso intensivo de CPU de la base de datos mediante el mismo almacenamiento subyacente.
La optimización del rendimiento de las consultas con Oracle requiere una consideración cuidadosa de estas opciones y parámetros de base de datos. Oracle proporciona varias herramientas, como el historial de sesiones activas (ASH), el monitor automático de diagnóstico de bases de datos (ADDM), los informes del repositorio de carga de trabajo automático (AWR), el asesoramiento de supervisión y ajuste de SQL y los Asesores de ajuste de memoria y deshacer para ajustar el rendimiento.
Analítica ágil
En BigQuery, puedes habilitar proyectos, usuarios y grupos diferentes para consultar conjuntos de datos en diferentes proyectos. La separación de la ejecución de consultas permite que los equipos autónomos trabajen dentro de sus proyectos sin afectar a otros usuarios y proyectos, ya que separa las cuotas de ranuras y consulta la facturación de otros proyectos y los que alojan los conjuntos de datos.
Alta disponibilidad, copias de seguridad y recuperación ante desastres
Oracle proporciona Data Guard como una solución de recuperación ante desastres y replicación de bases de datos. Real Application Clusters (RAC) se pueden configurar para la disponibilidad del servidor. Las copias de seguridad de Administrador de recuperación (RMAN) se pueden configurar para las copias de seguridad de la base de datos y el registro, y también se pueden usar en las operaciones de restablecimiento y recuperación. La función Base de datos flashback se puede usar para que los flashbacks de la base de datos la reviertan a un momento específico. Deshacer el espacio de tabla conserva instantáneas de tabla. Es posible consultar instantáneas anteriores con la consulta de flashback y cláusulas de consulta "as of" según las operaciones de DML/DDL realizadas antes y la configuración de retención de deshacer. En Oracle, toda la integridad de la base de datos debe administrarse dentro de los espacios de tabla que dependen de los metadatos del sistema, deshacer y los espacios de tabla correspondientes, ya que la coherencia sólida es importante para la copia de seguridad de Oracle y los procedimientos de recuperación deben incluir datos principales completos. Puedes programar exportaciones a nivel de esquema de tabla si la recuperación de un momento determinado no es necesaria en Oracle.
BigQuery es completamente administrado y diferente de los sistemas de base de datos tradicionales en su funcionalidad de copia de seguridad completa. No necesitas tener en cuenta el servidor, las fallas de almacenamiento, los errores del sistema y los daños en los datos físicos. BigQuery replica los datos en diferentes centros de datos según la ubicación del conjunto de datos para maximizar la confiabilidad y la disponibilidad. La funcionalidad multirregional de BigQuery replica los datos en diferentes regiones y protege contra la falta de disponibilidad de una zona única dentro de la región. La funcionalidad de una sola región de BigQuery replica los datos en diferentes zonas dentro de la misma región.
BigQuery te permite consultar instantáneas históricas de tablas hasta siete días y restablecer tablas borradas dentro de dos días mediante el viaje en el tiempo.
Puedes copiar una tabla borrada (para restablecerla) con la sintaxis de instantáneas (dataset.table@timestamp). Puedes exportar datos de las tablas de BigQuery para necesidades adicionales de copia de seguridad, como recuperarse de las operaciones accidentales de los usuarios. La estrategia de copia de seguridad comprobada y los programas que se usan para los sistemas de almacén de datos (DWH) existentes se pueden usar para las copias de seguridad.
Las operaciones por lotes y la técnica de captura de instantáneas permiten diferentes estrategias de copia de seguridad para BigQuery, por lo que no es necesario exportar tablas y particiones sin cambios con frecuencia. Una copia de seguridad de exportación de la partición o la tabla es suficiente después de que finaliza la operación de carga o ETL. Para reducir el costo de las copias de seguridad, puedes almacenar archivos de exportación en Nearline Storage o Coldline Storage de Cloud Storage y definir una política del ciclo de vida para borrar archivos después de un período determinado, según los requisitos de retención de datos.
Almacenamiento en caché
BigQuery ofrece caché por usuario y, si los datos no cambian, los resultados de las consultas se almacenan en caché durante aproximadamente 24 horas. Si los resultados se recuperan de la caché, la consulta no cuesta nada.
Oracle ofrece varias cachés para datos y resultados de consultas, como la caché de búfer, la caché de resultados, la caché flash de Exadata y el almacén de columnas en memoria.
Conexiones
BigQuery controla la administración de conexiones y no requiere que realices ninguna configuración del servidor. BigQuery proporciona controladores de JDBC y ODBC. Puedes usar la consola de Google Cloud o la bq command-line tool para consultas interactivas. Puedes usar las APIs de REST y las bibliotecas
cliente para
interactuar con BigQuery de manera programática. Puedesconectar
Hojas de cálculo de Google
directamente con BigQuery y usar controladores de ODBC y JDBC
para conectarse a Excel. Si buscas un cliente de escritorio, existen herramientas gratuitas
como DBeaver.
Oracle proporciona objetos de escucha, servicios, controladores de servicios, varios parámetros de configuración y ajuste, y servidores compartidos y dedicados para controlar las conexiones de la base de datos. Oracle proporciona controladores de JDBC, JDBC Thin, ODBC, y conexiones de TNS y Oracle Client. Los objetos de escucha de análisis, las direcciones IP de análisis y el nombre de análisis son necesarios para las configuraciones de RAC.
Precios y licencias
Oracle requiere tarifas de licencia y asistencia basadas en los recuentos de núcleos de las ediciones de Database y las opciones de Database, como RAC, multiusuario, Active Data Guard, partición, en memoria, Real Application Testing, GoldenGate, y Spatial and Graph.
BigQuery ofrece opciones de precios flexibles según el uso de inserción, almacenamiento y consulta. BigQuery ofrece precios basados en la capacidad para los clientes que necesitan un costo predecible y una capacidad de ranuras en regiones específicas. Las ranuras que se usan para inserciones y cargas de transmisión no se cuentan en la capacidad de ranuras del proyecto. A fin de decidir cuántas ranuras deseas comprar para tu almacén de datos, consulta Planificación de la capacidad de BigQuery.
BigQuery también reduce los costos de almacenamiento de forma automática a la mitad para los datos no modificados almacenados durante más de 90 días.
Etiquetado
Los conjuntos de datos, las tablas y las vistas de BigQuery se pueden etiquetar con pares clave-valor. Las etiquetas se pueden usar para diferenciar los costos de almacenamiento y las devoluciones de cargos internas.
Supervisión y registro de auditoría
Oracle proporciona diferentes niveles y tipos de opciones de auditoría de la base de datos y auditoría de Vault y funciones de firewall de base de datos, cuyas licencias se adquieren por separado. Oracle proporciona Enterprise Manager para la supervisión de la base de datos.
En BigQuery, los Registros de auditoría de Cloud se usan para los registros de acceso a los datos y los registros de auditoría, que están habilitados de forma predeterminada. Los registros de acceso a los datos están disponibles durante 30 días, y los otros eventos del sistema y los registros de actividad del administrador están disponibles durante 400 días. Si necesitas una retención más larga, puedes exportar los registros a BigQuery, Cloud Storage o Pub/Sub, como se describe en Estadísticas de registros de seguridad en Google Cloud. Si se necesita una integración con una herramienta de supervisión de incidentes existente, Pub/Sub se puede usar para exportaciones y el desarrollo personalizado debe realizarse en la herramienta existente a fin de leer registros de Pub/Sub.
Los registros de auditoría incluyen todas las llamadas a la API, las instrucciones de consulta y los estados de los trabajos. Puedes usar Cloud Monitoring para supervisar la asignación de ranuras, los bytes analizados en las consultas y el almacenamiento, además de otras métricas de BigQuery. El plan de consulta y el cronograma de BigQuery se pueden usar para analizar las etapas y el rendimiento de las consultas.
Puedes usar la tabla de mensajes de error para solucionar problemas de trabajo de consulta y errores de la API. A fin de distinguir las asignaciones de ranuras por consulta o trabajo, puedes usar esta utilidad, que es beneficiosa para clientes que usan precios basados en la capacidad y tienen muchos proyectos distribuidos en varios equipos.
Mantenimiento, actualizaciones y versiones
BigQuery es un servicio completamente administrado y no requiere que realices ningún mantenimiento o actualización. BigQuery no ofrece diferentes versiones. Las actualizaciones son continuas y no requieren tiempo de inactividad ni obstaculizan el rendimiento del sistema. Para obtener más información, consulta Notas de la versión.
Oracle y Exadata requieren que apliques parches, actualizaciones y mantenimiento a nivel de base de datos e infraestructura subyacente. Hay muchas versiones de Oracle y se planea lanzar una nueva versión principal cada año. Aunque las versiones nuevas son retrocompatibles, el rendimiento de las consultas, el contexto y las funciones pueden cambiar.
Puede haber aplicaciones que requieran versiones específicas, como 10g, 11g o 12c. Planificar y probar con cuidado para realizar actualizaciones de bases de datos principales. La migración desde diferentes versiones puede incluir diferentes necesidades de conversión técnica en las cláusulas de consulta y los objetos de la base de datos.
Cargas de trabajo
Oracle Exadata admite cargas de trabajo mixtas, incluidas las cargas de trabajo de OLTP. BigQuery está diseñado para las estadísticas y no para manejar cargas de trabajo de OLTP. Las cargas de trabajo OLTP que usan el mismo Oracle se deben migrar a Cloud SQL, Spanner o Firestore en Google Cloud. Oracle ofrece opciones adicionales, como Advanced Analytics y Spatial and Graph. Es posible que estas cargas de trabajo deban volver a escribirse para su migración a BigQuery. Para obtener más información, consulta Opciones de migración de Oracle.
Parámetros y configuración
Oracle ofrece y exige que muchos parámetros se configuren y ajusten en los niveles de SO, base de datos, RAC, ASM y Objeto de escucha para diferentes cargas de trabajo y aplicaciones. BigQuery es un servicio completamente administrado y no requiere que configures ningún parámetro de inicialización.
Límites y cuotas
Oracle tiene límites estrictos y flexibles en función de la infraestructura, la capacidad del hardware, los parámetros, las versiones de software y las licencias. BigQuery tiene cuotas y límites para acciones y objetos específicos.
Aprovisionamiento de BigQuery
BigQuery es una plataforma como servicio (PaaS) y un almacén de datos de procesamiento con paralelismo masivo de la nube. Su capacidad aumenta o disminuye sin intervención del usuario, ya que Google administra el backend. Como resultado, a diferencia de muchos sistemas de RDBMS, BigQuery no necesita aprovisionar recursos antes de su uso. BigQuery asigna recursos de almacenamiento y consulta de forma dinámica según los patrones de uso. Los recursos de almacenamiento se asignan a medida que los consumes, y su asignación se anula a medida que quitas datos o tablas. Los recursos de consulta se asignan de acuerdo con el tipo de consulta y complejidad. Cada consulta usa ranuras. Se usa un programador de equidad eventual, por lo que puede haber períodos breves en los que algunas consultas tengan un porcentaje más alto de ranuras, pero el programador lo corregirá con el tiempo.
En términos de VMs tradicionales, BigQuery te brinda el equivalente de ambos:
- Facturación por segundo
- Escalamiento por segundo
Para realizar esta tarea, BigQuery hace lo siguiente:
- Mantiene grandes recursos implementados para evitar tener que escalar con rapidez.
- Usa recursos multiusuario para asignar fragmentos grandes de forma instantánea a los segundos a la vez.
- Asigna recursos de manera eficiente entre los usuarios con economías de escala.
- Te cobra solo por los trabajos que ejecutas, en lugar de los recursos implementados, por lo que pagas por los recursos que usas.
Para obtener más información sobre los precios, consulta Información sobre el escalamiento rápido y los precios simples de BigQuery.
Migración del esquema
Para migrar datos de Oracle a BigQuery, debes conocer los tipos de datos de Oracle y las asignaciones de BigQuery.
Tipos de datos de Oracle y asignaciones de BigQuery
Los tipos de datos de Oracle difieren de los de BigQuery. Para obtener más información sobre los tipos de datos de BigQuery, consulta la documentación oficial.
Para obtener una comparación detallada entre los tipos de datos de Oracle y BigQuery, consulta la guía de traducción de SQL de Oracle.
Índices
En muchas cargas de trabajo analíticas, se usan tablas de columnas en lugar de almacenes de filas. Esto aumenta en gran medida las operaciones basadas en columnas y elimina el uso de índices para el análisis por lotes. BigQuery también almacena datos en formato de columnas, por lo que los índices no son necesarios en BigQuery. Si la carga de trabajo de análisis requiere un solo conjunto pequeño de acceso basado en filas, Bigtable puede ser una mejor alternativa. Si una carga de trabajo requiere procesamiento de transacciones con coherencia relacional sólida, Spanner o Cloud SQL pueden ser mejores alternativas.
En resumen, no se necesitan índices y se ofrecen en BigQuery para el análisis por lotes. Se pueden usar particiones o agrupaciones en clústeres. Para obtener más información sobre cómo ajustar y mejorar el rendimiento de las consultas en BigQuery, consulta Introducción a la optimización del rendimiento de consultas.
Vistas
Al igual que en Oracle, BigQuery permite crear vistas personalizadas. Sin embargo, las vistas en BigQuery no admiten declaraciones DML.
Vistas materializadas
Las vistas materializadas se usan generalmente con el fin de mejorar el tiempo de renderización de informes en los tipos de informes y cargas de trabajo de escritura única y lecturas múltiples.
Las vistas materializadas se ofrecen en Oracle para aumentar el rendimiento de las vistas con solo crear y mantener una tabla que contenga el conjunto de datos de resultados de consultas. Existen dos maneras de actualizar las vistas materializadas en Oracle: según confirmación y on demand.
La funcionalidad de vista materializada también está disponible en BigQuery. BigQuery aprovecha los resultados procesados antes de las vistas materializadas y, siempre que sea posible, lee solo los cambios delta de la tabla base para calcular los resultados actualizados.
Las funciones de almacenamiento en caché en Looker Studio o en otras herramientas de IE modernas también pueden mejorar el rendimiento y eliminar la necesidad de volver a ejecutar la misma consulta, lo que ahorra costos.
Partición de tablas
La partición de tablas se usa mucho en los almacenes de datos de Oracle. A diferencia de Oracle, BigQuery no admite la partición jerárquica.
BigQuery implementa tres tipos de partición de tablas que permiten que las consultas especifiquen filtros de predicado basados en la columna de partición a fin de reducir la cantidad de datos analizados.
- Tablas particionadas por tiempo de transferencia: las tablas se particionan en función del tiempo de transferencia de los datos.
- Tablas particionadas por columna: las tablas se particionan en función de una columna
TIMESTAMPoDATE. - Tablas particionadas por rango de números enteros: las tablas se particionan en función de una columna de números enteros.
Para obtener más información sobre los límites y las cuotas que se aplican a las tablas particionadas en BigQuery, consulta Introducción a las tablas particionadas.
Si las restricciones de BigQuery afectan la funcionalidad de la base de datos migrada, considera usar la fragmentación en lugar de la partición.
Además, BigQuery no admite EXCHANGE PARTITION, SPLIT PARTITION ni convierte una tabla no particionada en una particionada.
Agrupamiento en clústeres
El agrupamiento en clústeres ayuda a organizar y recuperar de manera eficiente los datos almacenados en varias columnas a las que se accede a menudo juntas. Sin embargo, Oracle y BigQuery tienen diferentes circunstancias en las que el agrupamiento en clústeres funciona mejor. En BigQuery, si una tabla se suele filtrar y agregar con columnas específicas, usa el agrupamiento en clústeres. El agrupamiento en clústeres se puede considerar para migrar tablas particionadas por listas u organizadas por índices de Oracle.
Tablas temporales
Las tablas temporales a menudo se usan en canalizaciones ETL de Oracle. Una tabla temporal contiene datos durante una sesión de usuario. Estos datos se borran de forma automática al final de la sesión.
BigQuery usa tablas temporales para almacenar en caché los resultados de las consultas que no se escriben en una tabla permanente. Una vez que finaliza una consulta, las tablas temporales existen durante un máximo de 24 horas. Las tablas se crean en un conjunto de datos especial y se les asigna un nombre al azar. También puedes crear tablas temporales para tu propio uso. Para obtener más información, consulta Tablas temporales.
Tablas externas
Al igual que en Oracle, BigQuery te permite consultar fuentes de datos externas. BigQuery admite la consulta de datos directamente desde las fuentes de datos externas, incluidas las siguientes:
- Amazon Simple Storage Service (Amazon S3)
- Azure Blob Storage
- Bigtable
- Spanner
- Cloud SQL
- Cloud Storage
- Google Drive
Modelado de datos
Los modelos de datos de estrella o copo de nieve pueden ser eficientes para el almacenamiento de analítica ay se suelen usar para almacenes de datos en Oracle Exadata.
Las tablas desnormalizadas eliminan las operaciones de unión costosas y, en la mayoría de los casos, proporcionan un mejor rendimiento para la analítica en BigQuery. Los modelos de datos de estrella y copo de nieve también son compatibles con BigQuery. Para obtener más detalles sobre el diseño del almacén de datos en BigQuery, consulta Diseña un esquema.
Comparación entre el formato de fila y los límites de formato de columna y de servidor frente a la computación sin servidores
Oracle usa un formato de fila en el que la fila de la tabla se almacena en bloques de datos, por lo que las columnas innecesarias se recuperan dentro del bloque para las consultas analíticas, según el filtrado y la agregación de columnas específicas.
Oracle tiene una arquitectura con todo compartido, con dependencias de recursos de hardware fijas, como la memoria y el almacenamiento, asignadas al servidor. Estas son las dos fuerzas principales subyacentes en muchas técnicas de modelado de datos que evolucionaron para mejorar la eficiencia del almacenamiento y el rendimiento de las consultas analíticas. Los esquemas de estrella y copo de nieve y el modelado de almacén de datos son algunos de estos.
BigQuery usa un formato de columnas para almacenar datos y no tiene límites de almacenamiento ni de memoria fijos. Esta arquitectura te permite desnormalizar y diseñar esquemas según las necesidades de lectura y negocio, lo que reduce la complejidad y mejora la flexibilidad, la escalabilidad y el rendimiento.
Desnormalización
Uno de los objetivos principales de la normalización de las bases de datos relacionales es reducir la redundancia de datos. Si bien este modelo es más adecuado para una base de datos relacional que usa un formato de fila, es preferible la desnormalización de datos para las bases de datos de columnas. Para obtener más información sobre las ventajas de desnormalizar los datos y otras estrategias de optimización de consultas en BigQuery, consulta Desnormalización.
Técnicas para compactar tu esquema existente
La tecnología de BigQuery aprovecha una combinación de acceso y procesamiento de datos en columnas, almacenamiento en la memoria y procesamiento distribuido para proporcionar un rendimiento de consulta de calidad.
Cuando diseñas un esquema DWH de BigQuery, crear una tabla de hechos en una estructura de tabla plana (consolidar todas las tablas de dimensiones en un solo registro en la tabla de hechos) es mejor para el uso del almacenamiento que usar varias dimensiones de DWH tablas. Además de un menor uso de almacenamiento, tener una tabla plana en BigQuery genera un menor uso de JOIN. En el siguiente diagrama, se muestra un ejemplo de compactación de tu esquema.
Ejemplo de compactación de un esquema en estrella
En la figura 1, se muestra una base de datos de administración de ventas ficticia que incluye cuatro tablas:
- Tabla de pedidos y ventas (tabla de hechos)
- Tabla de empleados
- Tabla de ubicación
- Tabla de clientes
La clave primaria de la tabla de ventas es OrderNum, que también contiene claves externas para las otras tres tablas.
Figura 1: Datos de ventas de muestra en un esquema en estrella
Datos de muestra
Contenido de la tabla de pedidos o hechos
| OrderNum | CustomerID | SalesPersonID | cantidad | Ubicación |
| O-1 | 1234 | 12 | 234.22 | 18 |
| O-2 | 4567 | 1 | 192.10 | 27 |
| O-3 | 12 | 14.66 | 18 | |
| O-4 | 4567 | 4 | 182.00 | 26 |
Contenido de la tabla de empleados
| SalesPersonID | FName | LName | título |
| 1 | Alex | Smith | Agente de ventas |
| 4 | Lisa | Pérez | Agente de ventas |
| 12 | José | Pérez | Agente de ventas |
Contenido de la tabla de clientes
| CustomerID | FName | LName |
| 1234 | Amanda | Lee |
| 4567 | Matt | Ryan |
Contenido de la tabla de ubicaciones
| Ubicación | city | city | city |
| 18 | Bronx | NY | 10452 |
| 26 | Mountain View | CA | 90210 |
| 27 | Chicago | IL | 60613 |
Consulta para compactar los datos mediante LEFT OUTER JOIN
#standardSQL INSERT INTO flattened SELECT orders.ordernum, orders.customerID, customer.fname, customer.lname, orders.salespersonID, employee.fname, employee.lname, employee.title, orders.amount, orders.location, location.city, location.state, location.zipcode FROM orders LEFT OUTER JOIN customer ON customer.customerID = orders.customerID LEFT OUTER JOIN employee ON employee.salespersonID = orders.salespersonID LEFT OUTER JOIN location ON location.locationID = orders.locationID
Resultado de los datos compactados
| OrderNum | CustomerID | FName | LName | SalesPersonID | FName | LName | cantidad | Ubicación | city | final | zipcode |
| O-1 | 1234 | Amanda | Lee | 12 | José | Doe | 234.22 | 18 | Bronx | NY | 10452 |
| O-2 | 4567 | Matt | Ryan | 1 | Alex | Smith | 192.10 | 27 | Chicago | IL | 60613 |
| O-3 | 12 | José | Doe | 14.66 | 18 | Bronx | NY | 10452 | |||
| O-4 | 4567 | Matt | Ryan | 4 | Lisa | Doe | 182.00 | 26 | Montaña
Ver |
CA | 90210 |
Campos anidados y repetidos
Para diseñar y crear un esquema DWH a partir de un esquema relacional (por ejemplo, esquemas de estrella y copo de nieve que contienen tablas de dimensiones y hechos), BigQuery presenta la funcionalidad de campos anidados y repetidos. Por lo tanto, las relaciones se pueden preservar de manera similar a un esquema DWH relacional normalizado (o normalizado de forma parcial) sin afectar el rendimiento. Para obtener más información, consulta las prácticas recomendadas de rendimiento.
Para comprender mejor la implementación de campos anidados y repetidos, consulta un esquema relacional simple de una tabla CUSTOMERS y una tabla ORDER/SALES. Son dos tablas diferentes, una para cada entidad, y las relaciones se definen con una clave como una clave primaria y una clave externa como el vínculo entre las tablas mientras se consulta con JOINs. Los campos anidados y repetidos de BigQuery te permiten conservar la misma relación entre las entidades en una sola tabla. Esto se puede implementar si tienes todos los datos de clientes, mientras que los datos de pedidos están anidados para cada uno de los clientes. Para obtener más información, consulta Especifica columnas anidadas y repetidas.
Para convertir la estructura plana en un esquema anidado o repetido, anida los campos de la siguiente manera:
CustomerID,FName,LNameanidados en un campo nuevo llamadoCustomer.SalesPersonID,FName,LNameanidados en un campo nuevo llamadoSalesperson.LocationID,city,stateyzip codeanidados en un campo nuevo llamadoLocation.
Los campos OrderNum y amount no están anidados, ya que representan elementos únicos.
Deseas que tu esquema sea lo suficientemente flexible como para permitir que cada pedido tenga más de un cliente: uno principal y uno secundario. El campo del cliente se marca como repetido. El esquema resultante se muestra en la figura 2, en el que se ilustran campos anidados y repetidos.
Figura 2: Representación lógica de una estructura anidada
En algunos casos, la desnormalización con campos anidados y repetidos no genera mejoras en el rendimiento. Para obtener más información sobre las limitaciones y restricciones, consulta Especifica columnas anidadas y repetidas en esquemas de tablas.
Claves subrogadas
Es común identificar filas con claves únicas dentro de las tablas. Las secuencias se suelen usar en Oracle para crear estas claves. En BigQuery, puedes crear claves subrogadas con las funciones row_number y partition by. Para obtener más información, consulta BigQuery y claves subrogadas: un enfoque práctico.
Haz un seguimiento de los cambios y el historial
Cuando planifiques una migración de DWH de BigQuery, considera el concepto de dimensiones que cambian lentamente (SCD). En general, el término SCD describe el proceso de realizar cambios (operaciones DML) en las tablas de dimensiones.
Por varios motivos, los almacenes de datos tradicionales usan diferentes tipos para manejar los cambios de datos y mantener los datos históricos en dimensiones que cambian con lentitud. Estos usos de tipos son necesarios para los límites de hardware y los requisitos de eficiencia mencionados antes. Debido a que el almacenamiento es mucho más económico que el procesamiento y es escalable de manera infinita, se recomienda la redundancia y la duplicación de datos si da como resultado consultas más rápidas en BigQuery. Puedes usar técnicas de captura de datos en las que todos los datos se cargan en particiones diarias nuevas.
Vistas específicas del rol y del usuario
Usa vistas específicas de las funciones y de los usuarios cuando estos pertenecen a equipos diferentes y deben ver solo los registros y resultados que necesitan.
BigQuery es compatible con la seguridad a nivel de la columna y de fila. La seguridad a nivel de la columna proporciona acceso detallado a columnas sensibles con etiquetas de políticas o clasificación basada en tipos de datos. La seguridad a nivel de las filas te permite filtrar datos y habilita el acceso a filas específicas en una tabla, según las condiciones de usuario aptas.
Migración de datos
En esta sección, se proporciona información sobre la migración de datos de Oracle a BigQuery, incluida la carga inicial, la captura de datos modificados (CDC) y los enfoques y las herramientas de ETL/ELT.
Actividades de migración
Se recomienda realizar la migración en fases mediante la identificación de los casos prácticos adecuados para la migración. Existen varias herramientas y servicios disponibles para migrar datos de Oracle a Google Cloud. Si bien esta lista no es exhaustiva, proporciona una idea del tamaño y el alcance del esfuerzo de migración.
Exporta datos fuera de Oracle: Para obtener más información, consulta Carga inicial y CDC y transferencia de transmisión de Oracle a BigQuery. Las herramientas de ETL se pueden usar para la carga inicial.
Etapa de pruebas de datos (en Cloud Storage): Cloud Storage es el lugar de destino recomendado (área de etapa de pruebas) para los datos exportados desde Oracle. Cloud Storage está diseñado para una transferencia rápida y flexible de datos estructurados o no estructurados.
Proceso ETL: Para obtener más información, consulta Migración de ETL/ELT.
Carga datos directamente en BigQuery: puedes cargar datos en BigQuery directamente desde Cloud Storage, a través de Dataflow o mediante la transmisión en tiempo real. Usa Dataflow cuando se requiera la transformación de datos.
Carga inicial
La migración de los datos iniciales del almacén de datos de Oracle existente a BigQuery puede ser diferente de las canalizaciones incrementales de ETL/ELT según el tamaño de los datos y el ancho de banda de la red. Se pueden usar las mismas canalizaciones de ETL/ELT si el tamaño de los datos es un par de terabytes.
Si los datos son hasta unos pocos terabytes, volcar los datos y usar gcloud storage para la transferencia puede ser mucho más eficiente que usar una metodología de extracción de bases de datos programáticas similar a JdbcIO, ya que los enfoques programáticos pueden necesitar un ajuste del rendimiento mucho más detallado. Si el tamaño de los datos es más de unos pocos terabytes y los datos se almacenan en la nube o en el almacenamiento en línea (como Amazon Simple Storage Service [Amazon S3]), considera usar el Servicio de transferencia de datos de BigQuery Para transferencias a gran escala (especialmente transferencias con ancho de banda de red limitado), Transfer Appliance es una opción útil.
Restricciones de la carga inicial
Cuando planifiques la migración de datos, ten en cuenta lo siguiente:
- Tamaño de datos de Oracle DWH: El tamaño de origen de tu esquema tiene un peso significativo en el método de transferencia de datos elegido, en especial cuando el tamaño de los datos es grande (terabytes y superiores). Cuando el tamaño de los datos es relativamente pequeño, el proceso de transferencia de datos se puede completar en menos pasos. Tratar con tamaños de datos a gran escala hace que el proceso general sea más complejo.
Tiempo de inactividad: decidir si el tiempo de inactividad es una opción para tu migración a BigQuery es importante. Para reducir el tiempo de inactividad, puedes cargar de forma masiva los datos históricos estables y tener una solución de CDC a fin de ponerse al día con los cambios que ocurren durante el proceso de transferencia.
Precios: en algunos casos, es posible que necesites herramientas de integración de terceros (por ejemplo, ETL o herramientas de replicación) que requieran licencias adicionales.
Transferencia de datos inicial (por lotes)
La transferencia de datos mediante un método por lotes indica que los datos se exportarían de forma coherente en un solo proceso (por ejemplo, si se exportan los datos del esquema de Oracle DWH a archivos CSV, Avro o Parquet o si se importan a Cloud Storage para crear conjuntos de datos en BigQuery). Todas las herramientas y conceptos de ETL que se explican en Migración de ETL/ELT se pueden usar para la carga inicial.
Si no deseas usar una herramienta de ETL/ELT para la carga inicial, puedes escribir secuencias de comandos personalizadas a fin de exportar datos a archivos (CSV, Avro o Parquet) y subir esos datos a Cloud Storage mediante gcloud storage, el Servicio de transferencia de datos de BigQuery o Transfer Appliance. Para obtener más información sobre el ajuste del rendimiento de las transferencias de datos grandes y las opciones de transferencia, consulta Transfiere tus conjuntos de datos grandes. Luego, carga los datos de Cloud Storage en BigQuery.
Cloud Storage es ideal para controlar el destino inicial de los datos. Cloud Storage es un servicio de almacenamiento de objetos duradero y con alta disponibilidad sin limitaciones en la cantidad de archivos. Solo pagas por el almacenamiento que usas. El servicio está optimizado para funcionar con otros servicios de Google Cloud, como BigQuery y Dataflow.
CDC y transferencia de transmisión de Oracle a BigQuery
Hay varias formas de capturar los datos modificados de Oracle. Cada opción tiene compensaciones, principalmente en el impacto en el rendimiento en el sistema de origen, los requisitos de desarrollo y configuración, y los precios y las licencias.
CDC basados en registros
Oracle GoldenGate es la herramienta recomendada de Oracle para extraer registros de rehacer, y puedes usar GoldenGate para macrodatos a fin de transmitir registros a BigQuery. GoldenGate requiere licencias por CPU. Para obtener información sobre el precio, consulta la Lista de precios globales de Oracle Technology. Si Oracle GoldenGate está disponible en los macrodatos (en caso de que ya se hayan adquirido licencias) con GoldenGate, puede ser una buena opción crear canalizaciones de datos para transferir datos (carga inicial) y, luego, sincronizar toda la modificación de datos.
Oracle XStream
Oracle almacena cada confirmación en los archivos de registro de rehacer, y estos archivos de rehacer se pueden usar para los CDC. Oracle XStream Out se basa en LogMiner y se proporciona con herramientas de terceros como Debezium (a partir de la versión 0.8) o comercialmente con herramientas como Striim. El uso de las APIs de XStream requiere comprar una licencia para Oracle GoldenGate, incluso si Golden Gate no está instalado ni se usa. XStream te permite propagar mensajes de transmisiones entre Oracle y otro software de manera eficiente.
Oracle LogMiner
No se requiere una licencia especial para LogMiner. Puedes usar la opción LogMiner en el conector de la comunidad de Debezium. También está disponible de forma comercial con herramientas como Attunity, Striim o StreamSets. LogMiner puede tener un impacto en el rendimiento en una base de datos de origen muy activa y debe usarse con cuidado en casos en los que el volumen de cambios (el tamaño del rehacer) sea superior a 10 GB por hora según la CPU, la memoria y la capacidad y el uso de E/S del servidor.
CDC basado en SQL
Este es el enfoque de ETL incremental en el que las consultas de SQL sondean continuamente las tablas de origen en busca de cualquier cambio según una clave que aumenta monótonamente y una columna de marca de tiempo que contiene la última fecha de modificación o insertada. Si no hay una clave que aumenta monótonamente, usar la columna de marca de tiempo (fecha de modificación) con una precisión pequeña (segundos) puede causar registros duplicados o datos faltantes según el operador de volumen y comparación, como > o >=.
Para superar estos problemas, puedes usar una precisión más alta en las columnas de marca de tiempo, como seis dígitos fraccionarios (microsegundos, que es la precisión máxima admitida en BigQuery), o puedes agregar tareas de anulación de duplicación en la canalización de ETL/ELT, según las claves empresariales y las características de los datos.
Debe haber un índice en la columna de clave o marca de tiempo para extraer mejor el rendimiento y reducir el impacto en la base de datos de origen. Las operaciones de eliminación son un desafío para esta metodología, ya que deben manejarse en la aplicación de origen de una manera de eliminación no definitiva, como colocar una marca borrada y actualizar last_modified_date. Una solución alternativa puede registrar estas operaciones en otra tabla mediante un activador.
Activadores
Se pueden crear activadores de bases de datos en tablas de origen para registrar cambios en las tablas del diario paralelo. Las tablas del diario pueden contener filas completas para hacer un seguimiento de cada cambio de columna, o solo pueden mantener la clave primaria con el tipo de operación (insertar, actualizar o borrar). Luego, se pueden capturar los datos modificados con un enfoque basado en SQL que se describe en la CDC basada en SQL. El uso de activadores puede afectar el rendimiento de las transacciones y duplicar la latencia de la operación de DML de una sola fila si se almacena una fila completa. Almacenar solo la clave primaria puede reducir esta sobrecarga, pero en ese caso, se requiere una operación JOIN con la tabla original en la extracción basada en SQL, que pierde el cambio intermedio.
Migración de ETL/ELT
Existen muchas posibilidades de controlar ETL/ELT en Google Cloud. La orientación técnica sobre las conversiones de cargas de trabajo de ETL específicas no está dentro del alcance de este documento. Puedes considerar un enfoque lift-and-shift o volver a diseñar la plataforma de integración de datos según las restricciones, como el costo y el tiempo. Para obtener más información sobre cómo migrar tus canalizaciones de datos a Google Cloud y muchos otros conceptos de migración, consulta Migra canalizaciones de datos.
Enfoque lift-and-shift
Si tu plataforma existente es compatible con BigQuery y deseas seguir usando tu herramienta de integración de datos existente, haz lo siguiente:
- Puedes mantener la plataforma ETL/ELT tal como está y cambiar las etapas de almacenamiento necesarias con BigQuery en tus trabajos de ETL/ELT.
- Si también deseas migrar la plataforma ETL/ELT a Google Cloud, puedes preguntar a tu proveedor si su herramienta tiene licencia en Google Cloud y, si es así, puedes instalarla en Compute Engine o verificar Google Cloud Marketplace.
Para obtener información sobre los proveedores de soluciones de integración de datos, consulta Socios de BigQuery.
Rediseña la plataforma de ETL/ELT
Si deseas volver a diseñar tus canalizaciones de datos, te recomendamos que consideres usar los servicios de Google Cloud.
Cloud Data Fusion
Cloud Data Fusion es un CDAP administrado en Google Cloud que ofrece una interfaz visual con muchos complementos para tareas como los desarrollos de arrastrar y soltar y desarrollos de canalización. Cloud Data Fusion se puede usar para capturar datos de muchos tipos diferentes de sistemas de origen y ofrece capacidades de replicación de transmisión y por lotes. Los complementos de Oracle o Cloud Data Fusion se pueden usar para capturar datos de un Oracle. Se puede usar un complemento de BigQuery para cargar los datos en BigQuery y controlar las actualizaciones del esquema.
No se define ningún esquema de resultado en los complementos de origen y de receptor, y también se usa select * from en el complemento de origen para replicar columnas nuevas.
Puedes usar la función Wrangle de Cloud Data Fusion para la limpieza y preparación de datos.
Dataflow
Dataflow es una plataforma de procesamiento de datos sin servidores que puede realizar ajustes de escala automáticos y procesamiento de datos por lotes y de transmisión. Dataflow puede ser una buena opción para los desarrolladores de Python y Java que deseen codificar sus canalizaciones de datos y usar el mismo código para cargas de trabajo de transmisión y por lotes. Usa la plantilla de JDBC a BigQuery para extraer datos de tus bases de datos relacionales de Oracle y otras cargas, y cargarlos en BigQuery.
Cloud Composer
Cloud Composer es el servicio de organización de flujos de trabajo completamente administrado de Google Cloud compilado en Apache Airflow. Te permite crear, programar y supervisar canalizaciones que abarcan entornos de nube y centros de datos locales. Cloud Composer proporciona operadores y contribuciones que pueden ejecutar tecnologías de múltiples nubes para casos de uso, incluidas la extracción y carga, y las transformaciones de ELT y llamadas a la API de REST.
Cloud Composer usa grafos acíclicos dirigidos (DAG) para programar y organizar flujos de trabajo. Para comprender los conceptos generales de Airflow, consulta Conceptos de Airflow. Para obtener más información sobre los DAG, consulta Escribe DAG (flujos de trabajo). Para conocer las prácticas recomendadas de ETL con Apache Airflow, consulta las prácticas recomendadas de ETL con el sitio de documentación de Airflow. En ese ejemplo, puedes reemplazar el operador de Hive por el operador de BigQuery, y se aplicarán los mismos conceptos.
El siguiente código de muestra es una parte de alto nivel de un DAG de muestra para el diagrama anterior:
default_args = {
'owner': 'airflow',
'depends_on_past': False,
'start_date': airflow.utils.dates.days_ago(2),
'email': ['airflow@example.com'],
'email_on_failure': False,
'email_on_retry': False,
'retries': 2,
'retry_delay': timedelta(minutes=10),
}
schedule_interval = "00 01 * * *"
dag = DAG('load_db1_db2',catchup=False, default_args=default_args,
schedule_interval=schedule_interval)
tables = {
'DB1_TABLE1': {'database':'DB1', 'table_name':'TABLE1'},
'DB1_TABLE2': {'database':'DB1', 'table_name':'TABLE2'},
'DB1_TABLEN': {'database':'DB1', 'table_name':'TABLEN'},
'DB2_TABLE1': {'database':'DB2', 'table_name':'TABLE1'},
'DB2_TABLE2': {'database':'DB2', 'table_name':'TABLE2'},
'DB2_TABLEN': {'database':'DB2', 'table_name':'TABLEN'},
}
start_db1_daily_incremental_load = DummyOperator(
task_id='start_db1_daily_incremental_load', dag=dag)
start_db2_daily_incremental_load = DummyOperator(
task_id='start_db2_daily_incremental_load', dag=dag)
load_denormalized_table1 = BigQueryOperator(
task_id='load_denormalized_table1',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,tN.* except (ID)
from `ingest-project.ingest_db1.TABLE1` as t1
left join `ingest-project.ingest_db1.TABLEN` as tN on t1.ID = tN.ID
''', destination_dataset_table='datamart-project.dm1.dt1', dag=dag)
load_denormalized_table2 = BigQueryOperator(
task_id='load_denormalized_table2',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,t2.* except (ID),tN.* except (ID)
from `ingest-project.ingest_db1.TABLE1` as t1
left join `ingest-project.ingest_db2.TABLE2` as t2 on t1.ID = t2.ID
left join `ingest-project.ingest_db2.TABLEN` as tN on t2.ID = tN.ID
''', destination_dataset_table='datamart-project.dm1.dt2', dag=dag)
load_denormalized_table_all = BigQueryOperator(
task_id='load_denormalized_table_all',
use_legacy_sql=False,
write_disposition='WRITE_TRUNCATE',
allow_large_results=True,
trigger_rule='all_done',
bql='''
#standardSQL
select
t1.*,t2.* except (ID),t3.* except (ID)
from `datamart-project.dm1.dt1` as t1
left join `ingest-project.ingest_db1.TABLE2` as t2 on t1.ID = t2.ID
left join `datamart-project.dm1.dt2` as t3 on t2.ID = t3.ID
''', destination_dataset_table='datamart-project.dm1.dt_all', dag=dag)
def start_pipeline(database,table,...):
#start initial or incremental load job here
#you can write your custom operator to integrate ingestion tool
#or you can use operators available in composer instead
for table,table_attr in tables.items():
tbl=table_attr['table_name']
db=table_attr['database'])
load_start = PythonOperator(
task_id='start_load_{db}_{tbl}'.format(tbl=tbl,db=db),
python_callable=start_pipeline,
op_kwargs={'database': db,
'table':tbl},
dag=dag
)
load_monitor = HttpSensor(
task_id='load_monitor_{db}_{tbl}'.format(tbl=tbl,db=db),
http_conn_id='ingestion-tool',
endpoint='restapi-endpoint/',
request_params={},
response_check=lambda response: """{"status":"STOPPED"}""" in
response.text,
poke_interval=1,
dag=dag,
)
load_start.set_downstream(load_monitor)
if table_attr['database']=='db1':
load_start.set_upstream(start_db1_daily_incremental_load)
else:
load_start.set_upstream(start_db2_daily_incremental_load)
if table_attr['database']=='db1':
load_monitor.set_downstream(load_denormalized_table1)
else:
load_monitor.set_downstream(load_denormalized_table2)
load_denormalized_table1.set_downstream(load_denormalized_table_all)
load_denormalized_table2.set_downstream(load_denormalized_table_all)
El código anterior se proporciona con fines de demostración y no se puede usar tal como está.
Dataprep by Trifacta
Dataprep es un servicio de datos inteligente que permite limpiar, preparar y explorar de manera visual datos estructurados y sin estructurar para el análisis, la elaboración de informes y el aprendizaje automático. Puedes exportar los datos de origen en archivos JSON o CSV, transformarlos con Dataprep y cargarlos con Dataflow. Por ejemplo, consulta Datos de Oracle (ETL) a BigQuery mediante Dataflow y Dataprep.
Dataproc
Dataproc es un servicio de Hadoop administrado por Google. Puedes usar Sqoop para exportar datos de Oracle y muchas bases de datos relacionales a Cloud Storage como archivos de Avro y, luego, cargar archivos Avro en BigQuery mediante bq tool. Es muy común instalar herramientas de ETL, como CDAP en Hadoop, que usen JDBC para extraer datos y Apache Spark o MapReduce para transformaciones de datos.
Herramientas para socios de migración de datos
Hay varios proveedores en el espacio de extracción, transformación y carga (ETL). Los líderes del mercado de ETL, como Informatica, Talend, Matillion, Infoworks, Stitch, Fivetran y Striim, se integraron profundamente en BigQuery y Oracle, y pueden ayudar a extraer, transformar, cargar y administrar datos flujos de trabajo de procesamiento.
Las herramientas de ETL existen desde hace muchos años. Para algunas organizaciones, puede resultar conveniente aprovechar una inversión existente en secuencias de comandos de ETL de confianza. Algunas de nuestras soluciones clave de socios se incluyen en el sitio web de socios de BigQuery. Saber cuándo elegir herramientas de socios en lugar de utilidades integradas de Google Cloud depende de tu infraestructura actual y de la comodidad de tu equipo de TI con el desarrollo de canalizaciones de datos en código Java o Python.
Migración de herramientas de inteligencia empresarial (IE)
BigQuery es compatible con un conjunto flexible de soluciones de inteligencia empresarial (IE) para la generación de informes y el análisis que puedes aprovechar. Para obtener más información sobre la migración de herramientas de IE y la integración de BigQuery, consulta Descripción general de las estadísticas de BigQuery.
Traducción de consultas (SQL)
GoogleSQL de BigQuery admite el cumplimiento del estándar de SQL 2011 y tiene extensiones que admiten consultas de datos anidados y repetidos. Todas las funciones y los operadores de SQL que cumplen con ANSI se pueden usar con modificaciones mínimas. Para obtener una comparación detallada entre la sintaxis y las funciones de Oracle y BigQuery SQL, consulta la referencia de traducción de Oracle a BigQuery SQL.
Usa la traducción de SQL por lotes para migrar tu código de SQL de forma masiva o la traducción de SQL interactiva a fin de traducir consultas ad hoc.
Migra opciones de Oracle
En esta sección, se presentan recomendaciones arquitectónicas y referencias para convertir aplicaciones que usan funciones de Oracle Data Mining, R y Spatial and Graph.
Opción Advanced Analytics de Oracle
Oracle ofrece opciones de analítica avanzada para la extracción de datos, los algoritmos de aprendizaje automático (AA) fundamentales y el uso de R. La opción Advanced Analytics requiere licencias. Puedes elegir de una lista completa de productos de IA y AA de Google según tus necesidades, desde el desarrollo hasta la producción a gran escala.
Oracle R Enterprise
Oracle R Enterprise (ORE), un componente de la opción Advanced Analytics de Oracle, hace que el lenguaje de programación estadística R de código abierto se integre en la base de datos de Oracle. En las implementaciones de ORE estándar, R está instalado en un servidor de Oracle.
Para grandes escalas de datos o enfoques de almacenamiento, la integración en R con BigQuery es una opción ideal. Puedes usar la biblioteca R de código abierto bigrquery para integrar R en BigQuery.
Google se asoció con RStudio a fin de que las herramientas de vanguardia del campo estén disponibles para los usuarios. RStudio se puede usar para acceder a terabytes de datos en modelos de BigQuery en TensorFlow y ejecutar modelos de aprendizaje automático a gran escala con AI Platform. En Google Cloud, R se puede instalar en Compute Engine a gran escala.
Oracle Data Mining
Oracle Data Mining (ODM), un componente de la opción Advanced Analytics de Oracle, permite a los desarrolladores compilar modelos de aprendizaje automático con el desarrollador de Oracle PL/SQL en Oracle.
BigQuery ML permite a los desarrolladores ejecutar muchos tipos diferentes de modelos, como regresión lineal, regresión logística binaria, regresión logística multiclase, agrupamiento en clústeres de k-means e importaciones de modelos de TensorFlow. Para obtener más información, consulta Introducción a BigQuery ML.
La conversión de trabajos de ODM puede requerir la reescritura del código. Puedes elegir de la amplia oferta de productos de IA de Google, como BigQuery ML, las APIs de IA (Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, la API de Cloud Natural Language, Cloud Vision, la API de Timeseries Insights y más), o Vertex AI.
Vertex AI Workbench se puede usar como un entorno de desarrollo para científicos de datos y Vertex AI Training se puede usar para ejecutar cargas de trabajo de entrenamiento y puntuación a gran escala.
Opción Spatial and Graph
Oracle ofrece la opción Spatial and Graph para consultar geometría y grafos, que requiere licencias. Puedes usar las funciones de geometría en BigQuery sin licencias ni costos adicionales, y usar otras bases de datos de grafos en Google Cloud.
Espacial
BigQuery ofrece funciones y tipos de datos de estadísticas geoespaciales. Para obtener más información, consulta Trabaja con datos de estadísticas geoespaciales. Las funciones y los tipos de datos de Oracle Spatial se pueden convertir en funciones de geografía en SQL estándar de BigQuery. Las funciones de geografía no agregan costos por sobre los precios estándar de BigQuery.
Gráfico
JanusGraph es una solución de base de datos de grafos de código abierto que puede usar Bigtable como backend de almacenamiento. Para obtener más información, consulta Ejecuta JanusGraph en GKE con Bigtable.
Neo4j es otra solución de base de datos de grafos que se entrega como un servicio de Google Cloud que se ejecuta en Google Kubernetes Engine (GKE).
Oracle Application Express
Las aplicaciones de Oracle Application Express (APEX) son exclusivas de Oracle y deben reescribirse. Las funciones de informes y visualización de datos se pueden desarrollar con Looker Studio o BI engine, mientras que las funciones a nivel de la aplicación, como la creación y edición de filas, se pueden desarrollar sin programación en AppSheet con Cloud SQL.
¿Qué sigue?
- Aprende a optimizar las cargas de trabajo para la optimización del rendimiento general y la reducción de costos.
- Aprende a optimizar el almacenamiento en BigQuery.
- Para conocer las actualizaciones de BigQuery, consulta las notas de la versión.
- Consulta la Guía de traducción de SQL de Oracle.