Migración de Amazon Redshift a BigQuery: Descripción general

Este documento proporciona una guía sobre la migración de Amazon Redshift a BigQuery y se enfoca en los siguientes temas:

  • Estrategias para la migración
  • Prácticas recomendadas para la optimización de consultas y el modelado de datos
  • Sugerencias para solucionar problemas
  • Orientación para la adopción de usuarios

Los objetivos de este documento son los siguientes:

  • Proporcionar orientación de alto nivel a las organizaciones que migran de Amazon Redshift a BigQuery, incluida la ayuda para reinventar tus canalizaciones de datos existentes a fin de aprovechar BigQuery al máximo.
  • Ayudarte a comparar las arquitecturas de BigQuery y Amazon Redshift para que puedas determinar cómo implementar las funciones existentes durante la migración. El objetivo es mostrarte las nuevas funciones disponibles para tu organización a través de BigQuery, no asignar características uno a uno con Amazon Redshift.

Este documento está dirigido a arquitectos empresariales, administradores de bases de datos, desarrolladores de aplicaciones y especialistas en seguridad de TI. Suponemos que estás familiarizado con Amazon Redshift.

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. SQL de Amazon Redshift es compatible por completo con ambos servicios de traducción de SQL.

Tareas previas a la migración

Para ayudar a garantizar una migración exitosa al almacén de datos, comienza a planificar tu estrategia de migración al comienzo del cronograma del proyecto. Este enfoque te permite evaluar las funciones de Google Cloud que se adaptan a tus necesidades.

Planificación de la capacidad

BigQuery usa ranuras para medir la capacidad de procesamiento de las estadísticas. 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 según demanda: En el caso de los precios según demanda, 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, todos los proyectos de Google Cloud están limitados a un máximo de 2,000 ranuras. BigQuery puede sobrepasar este límite para acelerar las consultas, pero no se garantiza el aumento de actividad.
  • 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. Puedes usar Looker Studio (este es un ejemplo de código abierto de un panel de Looker Studio) o Looker para visualizar los datos de registro de auditoría de BigQuery, específicamente los del uso de ranuras en consultas y proyectos. También puedes usar los datos de tablas del sistema de BigQuery para supervisar el uso de ranuras en trabajos y reservas (este es 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 con la consola de Google Cloud o la herramienta de línea de comandos de bq. Para obtener más detalles sobre la administración de cargas de trabajo, la ejecución de consultas y la arquitectura de BigQuery, consulta Migración a Google Cloud: una vista en profundidad.

Seguridad en Google Cloud

En las siguientes secciones, se describen los controles de seguridad comunes de Amazon Redshift y cómo puedes ayudar a garantizar que tu almacén de datos permanezca protegido en un entorno de Google Cloud.

Administración de identidades y accesos

La configuración de los controles de acceso en Amazon Redshift implica escribir políticas de permisos de la API de Amazon Redshift y adjuntarlas a las identidades de Identity and Access Management (IAM). Los permisos de la API de Amazon Redshift proporcionan acceso a nivel de clúster, pero no proporcionan niveles de acceso más detallados que el de clúster. Si deseas obtener acceso más detallado a recursos como tablas o vistas, puedes usar cuentas de usuario en la base de datos de Amazon Redshift.

BigQuery usa IAM para administrar el acceso a los recursos en un nivel más detallado. Los tipos de recursos disponibles en BigQuery son organizaciones, proyectos, conjuntos de datos, tablas, columnas 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 de IAM 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:

  • Roles predefinidos, que están destinadas a brindar compatibilidad con patrones de control de acceso y casos de uso comunes.
  • Roles personalizados, que proporcionan acceso detallado en función de una lista de permisos especificada por el usuario.

En IAM, BigQuery proporciona control de acceso a nivel de tabla. Los permisos a nivel de tabla determinan los usuarios, grupos y cuentas de servicio que pueden acceder a una tabla o vista. Puedes otorgar a un usuario acceso a tablas o vistas específicas sin que tenga acceso al conjunto de datos completo. Para obtener un acceso más detallado, también puedes consultar la implementación de uno o más de los siguientes mecanismos de seguridad:

Encriptación de disco completo

Además de la administración de identidades y accesos, la encriptación de datos agrega una capa adicional de defensa para proteger los datos. En el caso de la exposición de datos, los datos encriptados no son legibles.

En Amazon Redshift, la encriptación de los datos en reposo y en tránsito no está habilitada de forma predeterminada. La encriptación de los datos en reposo debe habilitarse de forma explícita cuando se inicia un clúster o cuando se modifica un clúster existente para que use la encriptación de AWS Key Management Service. La encriptación de los datos en tránsito también debe estar habilitada de manera explícita.

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) si deseas 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 los informes sobre la encriptación de datos en reposo y la encriptación de datos en tránsito.

En el caso de los datos en tránsito en Google Cloud, los datos se encriptan y autentican cuando se mueven fuera de los límites físicos controlados por Google o en nombre de Google. Dentro de estos límites, los datos en tránsito suelen estar autenticados, pero no siempre están encriptados.

Prevención de pérdida de datos

Los requisitos de cumplimiento pueden limitar qué datos se pueden almacenar en Google Cloud. Puedes usar la protección de datos sensibles para analizar las tablas de BigQuery para detectar y clasificar datos sensibles. Si se detectan datos sensibles, las transformaciones de desidentificación de protección de datos sensibles pueden enmascarar, borrar o, de otro modo, ocultar esos datos.

Migración a Google Cloud: Conceptos básicos

Usa esta sección para obtener más información sobre el uso de herramientas y canalizaciones para ayudar con la migración.

Herramientas de migración

El Servicio de transferencia de datos de BigQuery proporciona una herramienta automatizada para migrar los datos del esquema y de Amazon Redshift directamente a BigQuery. En la siguiente tabla, se enumeran las herramientas adicionales para ayudar en la migración de Amazon Redshift a BigQuery:

Herramienta Purpose
Servicio de transferencia de datos de BigQuery Realiza una transferencia por lotes automatizada de tus datos de Amazon Redshift a BigQuery con este servicio completamente administrado.
Servicio de transferencia de almacenamiento Importa con rapidez los datos de Amazon S3 en Cloud Storage y establece un programa de repetición para la transferencia de datos mediante este servicio completamente administrado.
gcloud Copia los archivos de Amazon S3 en Cloud Storage con esta herramienta de línea de comandos.
Herramienta de línea de comandos de bq Interactúa con BigQuery mediante esta herramienta de línea de comandos. Las interacciones comunes incluyen crear esquemas de tablas de BigQuery, cargar datos de Cloud Storage en tablas y ejecutar consultas.
Bibliotecas cliente de Cloud Storage Copia los archivos de Amazon S3 en Cloud Storage mediante tu herramienta personalizada, compilada a partir de la biblioteca cliente de Cloud Storage.
Bibliotecas cliente de BigQuery Interactúa con BigQuery mediante tu herramienta personalizada, compilada a partir de la biblioteca cliente de BigQuery.
Programador de consultas de BigQuery Programa consultas de SQL recurrentes mediante esta función integrada de BigQuery.
Cloud Composer Organiza las transformaciones y los trabajos de carga de BigQuery con este entorno de Apache Airflow completamente administrado.
Apache Sqoop Envía trabajos de Hadoop mediante Sqoop y el controlador JDBC de Amazon Redshift para extraer datos de Amazon Redshift en HDFS o Cloud Storage. Sqoop se ejecuta en un entorno de Dataproc.

Para obtener más información sobre el uso del Servicio de transferencia de datos de BigQuery, consulta Migra el esquema y los datos de Amazon Redshift.

Migra mediante canalizaciones

Tu migración de datos de Amazon Redshift a BigQuery puede tomar diferentes rutas según las herramientas de migración disponibles. Si bien la lista de esta sección no es exhaustiva, proporciona una idea de los diferentes patrones de canalización de datos disponibles cuando se mueven los datos.

Para obtener información de alto nivel sobre la migración de datos a BigQuery mediante canalizaciones, consulta Migra canalizaciones de datos.

Extracción y carga (EL)

Puedes automatizar completamente una canalización de EL mediante el Servicio de transferencia de datos de BigQuery, que puede copiar de manera automática los esquemas y los datos de las tablas del clúster de Amazon Redshift a BigQuery. Si deseas tener más control sobre los pasos de la canalización de datos, puedes crear una canalización mediante las opciones que se describen en las siguientes secciones.

Usa los extractos de archivo de Amazon Redshift
  1. Exporta datos de Amazon Redshift a Amazon S3.

  2. Copia los datos de Amazon S3 a Cloud Storage mediante cualquiera de las siguientes opciones:

  3. Carga los datos de Cloud Storage en BigQuery mediante cualquiera de las siguientes opciones:

Usa una conexión JDBC de Amazon Redshift

Usa cualquiera de los siguientes productos de Google Cloud para exportar datos de Amazon Redshift con el controlador JDBC de Amazon Redshift:

Extracción, transformación y carga (ETL)

Si deseas transformar algunos datos antes de cargarlos en BigQuery, sigue las mismas recomendaciones de canalización que se describen en la sección Extracción y carga (EL) y agrega un elemento adicional a fin de transformar tus datos antes de cargarlos en BigQuery.

Usa los extractos de archivo de Amazon Redshift

  1. Exporta datos de Amazon Redshift a Amazon S3.

  2. Copia los datos de Amazon S3 a Cloud Storage mediante cualquiera de las siguientes opciones:

  3. Transforma y, luego, carga tus datos en BigQuery mediante cualquiera de las siguientes opciones:

Usa una conexión JDBC de Amazon Redshift

Usa cualquiera de los productos descritos en la sección Extracción y carga (EL) y agrega un paso adicional para transformar los datos antes de cargarlos en BigQuery. Modifica tu canalización para ingresar uno o más pasos y transformar tus datos antes de escribirlos en BigQuery.

Extracción, carga y transformación (ELT)

Puedes transformar tus datos con BigQuery mediante cualquiera de las opciones de Extraer y cargar (EL) para cargar los datos en una tabla de etapa de pruebas. Luego, debes transformar los datos en esta tabla de etapa de pruebas mediante consultas de SQL que escriben sus resultados en la tabla de producción final.

Captura de datos modificados (CDC)

La captura de datos modificados es uno de los diversos patrones de diseño de software que se usan para realizar un seguimiento de los cambios en los datos. A menudo, se utiliza en el almacenamiento de datos porque el almacén de datos se usa para recopilar y hacer un seguimiento de los datos y sus cambios desde varios sistemas de origen a lo largo del tiempo.

Herramientas para socios de migración de datos

Hay varios proveedores en el espacio de extracción, transformación y carga (ETL). Consulta el sitio web de socios de BigQuery para obtener una lista de los socios clave y sus soluciones proporcionadas.

Migración a Google Cloud: una vista en profundidad

Usa esta sección para obtener más información sobre cómo la arquitectura del almacén de datos, el esquema y el dialecto de SQL afectan la migración.

Comparación de arquitecturas

BigQuery y Amazon Redshift se basan en una arquitectura de procesamiento paralelo masivo (MPP). Las consultas se distribuyen en varios servidores para acelerar su ejecución. Con respecto a la arquitectura del sistema, Amazon Redshift y BigQuery difieren en gran medida en cómo se almacenan los datos y cómo se ejecutan las consultas. En BigQuery, el hardware y las configuraciones subyacentes se abstraen. El almacenamiento y el procesamiento permiten que el almacén de datos crezca sin que tú debas intervenir.

Procesamiento, memoria y almacenamiento

En Amazon Redshift, la CPU, la memoria y el almacenamiento en disco están vinculados a través de nodos de procesamiento, como se ilustra en este diagrama de la documentación de Amazon Redshift. El rendimiento del clúster y la capacidad de almacenamiento están determinados por el tipo y la cantidad de nodos de procesamiento, que se deben configurar. Para cambiar el procesamiento o almacenamiento, debes cambiar el tamaño de tu clúster a través de un proceso (que dura desde un par de horas o hasta dos días o más) que crea un clúster nuevo y transfiere los datos a él. Amazon Redshift también ofrece nodos RA3 con almacenamiento administrado que ayudan a separar el procesamiento y el almacenamiento. El nodo más grande de la categoría RA3 limita los 64 TB de almacenamiento administrado para cada nodo.

Desde el principio, BigQuery no vincula el procesamiento, la memoria y el almacenamiento, sino que trata a cada uno por separado.

El procesamiento de BigQuery se define mediante ranuras, una unidad de capacidad de procesamiento necesaria para ejecutar consultas. Google administra toda la infraestructura que encapsula una ranura, lo que elimina todo lo demás, excepto la tarea de elegir la cantidad de ranuras adecuada para tus cargas de trabajo de BigQuery. Consulta Planificación de la capacidad a fin de obtener ayuda para decidir cuántas ranuras comprarás para tu almacén de datos. La memoria de BigQuery se proporciona a través de un servicio distribuido remoto conectado a las ranuras de procesamiento mediante la red de petabytes de Google, y Google administra todo.

BigQuery y Amazon Redshift usan almacenamiento en columnas, pero BigQuery usa variaciones y avances en un almacenamiento en columnas. Mientras se codifican las columnas, se conservan varias estadísticas sobre los datos y luego se usan durante la ejecución de la consulta para compilar planes óptimos y elegir el algoritmo de entorno de ejecución más eficiente. BigQuery almacena tus datos en el sistema de archivos distribuido de Google, en el que se comprimen, encriptan, replican y distribuyen de forma automática. Todo esto se logra sin afectar la potencia de procesamiento disponible para las consultas. Separar el almacenamiento del procesamiento te permite escalar hasta decenas de petabytes en el almacenamiento sin problemas, sin necesidad de recursos de procesamiento adicionales costosos. También existen otros beneficios de separar el procesamiento y el almacenamiento.

Aumenta o reduce la escala verticalmente

Cuando el almacenamiento o el procesamiento se limitan, los clústeres de Amazon Redshift deben cambiar el tamaño mediante la modificación de la cantidad o los tipos de nodos en el clúster.

Cuando cambias el tamaño de un clúster de Amazon Redshift, hay dos enfoques:

  • Cambio de tamaño clásico: Amazon Redshift crea un clúster al que se copian los datos, un proceso que puede tardar desde un par de horas o hasta dos días o más para grandes cantidades de datos.
  • Cambio de tamaño elástico: Si cambias solo el número de nodos, las consultas se detienen temporalmente y las conexiones se mantienen abiertas si es posible. Durante la operación de cambio de tamaño, el clúster es de solo lectura. El cambio de tamaño elástico suele tardar entre 10 y 15 minutos, pero puede que no esté disponible para todas las opciones de configuración.

Debido a que BigQuery es una plataforma como servicio (PaaS), solo tienes que preocuparte por la cantidad de ranuras de BigQuery que deseas reservar para tu organización. Debes reservar las ranuras de BigQuery en la sección de reservas y, luego, asignas proyectos a estas reservas. Si deseas obtener información para configurar estas reservas, consulta Planificación de la capacidad.

Ejecución de las consultas

El motor de ejecución de BigQuery es similar a Amazon Redshift en el aspecto de que ambas organizan tu consulta dividiéndola en pasos (un plan de consulta), ejecutando los pasos (de manera simultánea) y volviendo a ensamblar los resultados. Amazon Redshift genera un plan de consultas estáticas, pero BigQuery no lo hace porque optimiza de forma dinámica los planes de consulta a medida que se ejecuta tu consulta. BigQuery redistribuye los datos con su servicio de memoria remota, mientras que Amazon Redshift redistribuye los datos con la memoria del nodo de procesamiento local. Para obtener más información sobre el almacenamiento de los datos intermedios de BigQuery de las etapas de tu plan de consulta, consulta Ejecución de consultas en memoria en Google BigQuery.

Administración de cargas de trabajo en BigQuery

BigQuery ofrece los siguientes controles para la administración de cargas de trabajo (WLM):

  • Consultas interactivas, que se ejecutan lo antes posible (esta es la configuración predeterminada).
  • Consultas por lotes, que están en cola en tu nombre y comienzan en cuanto los recursos inactivos estén disponibles en el grupo de recursos compartidos de BigQuery.

  • Reservas de ranuras a través de precios basados en la capacidad. En lugar de pagar por las consultas a pedido, puedes crear y administrar de forma dinámica los buckets de ranuras llamados reservas y asignar proyectos, carpetas u organizaciones a estas reservas. Puedes comprar compromisos de ranuras de BigQuery (desde un mínimo de 100) en compromisos flexibles, mensuales o anuales para ayudar a minimizar los costos. De forma predeterminada, las consultas que se ejecutan en una reserva usan ranuras inactivas de otras reservas de forma automática.

    Como se ilustra en el siguiente diagrama, supongamos que compraste una capacidad de compromiso total de 1,000 ranuras para compartir en tres tipos de cargas de trabajo: ciencia de datos, ELT e inteligencia empresarial (IE). Para admitir estas cargas de trabajo, puedes crear las siguientes reservas:

    • Puedes crear la reserva ds con 500 ranuras y asignar todos los proyectos de ciencia de datos de Google Cloud a esa reserva.
    • Puedes crear la reserva elt con 300 ranuras y asignar los proyectos que usas para las cargas de trabajo de ELT a esa reserva.
    • Puedes crear la reserva bi con 200 ranuras y asignar los proyectos conectados a tus herramientas de IE a esa reserva.

    Esta configuración se muestra en el siguiente gráfico:

    Cómo funcionan en conjunto los compromisos de ranuras, las reservas y las asignaciones.

    En lugar de distribuir reservas a las cargas de trabajo de la organización, por ejemplo, a producción y pruebas, puedes elegir asignar reservas a equipos o departamentos individuales, según tu caso de uso.

    Para obtener más información, consulta Administración de cargas de trabajo mediante reservas.

Administración de cargas de trabajo en Amazon Redshift

Amazon Redshift ofrece dos tipos de administración de cargas de trabajo (WLM):

  • Automático: Con la WLM automática, Amazon Redshift administra la simultaneidad de consultas y la asignación de memoria. Se crean hasta ocho colas con los identificadores de clase de servicio 100–107. La WLM automática determina la cantidad de recursos que las consultas necesitan y ajusta la simultaneidad en función de la carga de trabajo. Para obtener más información, consulta Prioridad de las consultas.
  • Manual: En cambio, la WLM manual requiere que especifiques valores para la simultaneidad de consultas y la asignación de memoria. La configuración predeterminada para la WLM manual es la simultaneidad de cinco consultas, y la memoria se divide de manera equitativa entre las cinco.

Cuando el escalamiento de simultaneidad está habilitado, Amazon Redshift agrega capacidad de clústeres adicional de forma automática cuando la necesitas para procesar un aumento en las consultas de lectura simultáneas. El escalamiento de simultaneidad tiene ciertas consideraciones respecto de la región y las consultas. Para obtener más información, consulta Candidatos de escalamiento de simultaneidad.

Conjuntos de datos y configuraciones de tablas

BigQuery ofrece varias formas de configurar tus datos y tablas, como la partición, el agrupamiento en clústeres y la localidad de datos. Esta configuración puede ayudar a mantener tablas grandes y reducir la carga de datos general y el tiempo de respuesta para las consultas, lo que aumenta la eficiencia operativa de las cargas de trabajo de datos.

Partición

Las tablas particionadas se dividen en segmentos, denominados particiones, que facilitan la administración y la consulta de los datos. Por lo general, los usuarios dividen las tablas grandes en varias particiones más pequeñas, y cada partición contiene datos de un día. La administración de particiones es un factor clave determinante en el rendimiento y el costo de BigQuery cuando se consulta un período específico, ya que ayuda a BigQuery a analizar menos datos por consulta.

Hay tres tipos de partición de tablas en BigQuery:

Una tabla particionada por tiempo basada en columnas elimina la necesidad de supervisar las particiones independientemente del filtrado de datos existente en la columna vinculada. Los datos escritos en una tabla particionada por tiempo basada en columnas se entregan automáticamente a la partición adecuada según el valor de los datos. Del mismo modo, las consultas que expresan filtros en la columna de partición pueden reducir los datos generales analizados, lo que puede mejorar el rendimiento y el costo de las consultas para las consultas a pedido.

La partición basada en columnas de BigQuery es similar a la partición basada en columnas de Amazon Redshift con una motivación un poco diferente. Amazon Redshift usa la distribución de claves basada en columnas para intentar mantener juntos los datos relacionados almacenados en el mismo nodo de procesamiento, lo que minimiza la redistribución de datos que ocurre durante las uniones y agregaciones. BigQuery separa el almacenamiento del procesamiento, por lo que aprovecha la partición basada en columnas para minimizar la cantidad de datos que las ranuras leen del disco.

Una vez que los trabajadores de las ranuras leen sus datos desde el disco, BigQuery puede determinar de forma automática una fragmentación de datos más óptima y volver a particionar los datos con rapidez mediante el servicio de redistribución de memoria en BigQuery.

Para obtener más información, consulta Introducción a las tablas particionadas.

Claves de agrupamiento en clústeres y de ordenamiento

Amazon Redshift admite la especificación de columnas de tablas como claves de orden compuestas o intercaladas. En BigQuery, puedes especificar claves de orden compuestas porque agrupa en clústeres tu tabla. Las tablas agrupadas en BigQuery mejoran el rendimiento de las consultas porque los datos de la tabla se ordenan automáticamente según el contenido de hasta cuatro columnas especificadas en el esquema de la tabla. Estas columnas se usan para colocar datos relacionados. El orden de las columnas de agrupamiento en clústeres que especificas es importante porque determina el orden de clasificación de los datos.

El agrupamiento en clústeres puede mejorar el rendimiento de ciertos tipos de consultas, como las consultas que usan cláusulas de filtro y las que agregan datos. Cuando los datos se escriben en una tabla agrupada en clústeres a través de un trabajo de consulta o de carga, BigQuery ordena automáticamente los datos mediante los valores de las columnas de agrupamiento en clústeres. Estos valores se usan con el fin de organizar los datos en diferentes bloques en el almacenamiento de BigQuery. Cuando envía una consulta que contiene una cláusula que filtra datos según las columnas de agrupamiento en clústeres, BigQuery usa los bloques ordenados para eliminar análisis de datos innecesarios.

De la misma manera, cuando envías una consulta que agrega datos en función de los valores de las columnas de agrupamiento en clústeres, el rendimiento mejora, ya que los bloques ordenados ubican filas con valores similares.

Usa el agrupamiento en clústeres en las siguientes circunstancias:

  • Las claves de orden compuestas se configuran en tus tablas de Amazon Redshift.
  • El filtrado o la agregación se configura en columnas particulares de tus consultas.

Cuando usas el agrupamiento en clústeres y la partición al mismo tiempo, tus datos se pueden particionar por fecha, marca de tiempo o columna de números enteros y, luego, agruparse en un conjunto de columnas diferente (hasta cuatro en columnas agrupadas en total). En este caso, los datos en cada partición se agrupan en clústeres según los valores de las columnas de agrupamiento en clústeres.

Cuando especificas claves de orden en tablas en Amazon Redshift, según la carga en el sistema, Amazon Redshift inicia el ordenamiento de forma automática con la capacidad de procesamiento de tu propio clúster. Es posible que debas ejecutar el comando VACUUM de forma manual si deseas ordenar los datos de tu tabla por completo lo antes posible, por ejemplo, después de una gran carga de datos. BigQuery controla automáticamente este ordenamiento y no usa tus ranuras de BigQuery asignadas, por lo que no afecta el rendimiento de ninguna de tus consultas.

Para obtener más información sobre cómo trabajar con tablas agrupadas, consulta la Introducción a las tablas agrupadas.

Claves de distribución

Amazon Redshift usa claves de distribución para optimizar la ubicación de los bloques de datos a fin de ejecutar sus consultas. BigQuery no usa claves de distribución porque determina y agrega etapas en un plan de consulta de forma automática (mientras se ejecuta la consulta) para mejorar la distribución de datos en todos los trabajadores de consulta.

Fuentes externas

Si usas Amazon Redshift Spectrum para consultar datos en Amazon S3, puedes usar de manera similar la función de fuente de datos externa de BigQuery para consultar datos directamente desde archivos en Cloud Storage.

Además de consultar datos en Cloud Storage, BigQuery ofrece funciones de consultas federadas para consultar directamente desde los siguientes productos:

  • Cloud SQL (MySQL o PostgreSQL completamente administrado)
  • Bigtable (NoSQL completamente administrado)
  • Google Drive (CSV, JSON, Avro, Hojas de cálculo)

Localidad de datos

Puedes crear tus conjuntos de datos de BigQuery en ubicaciones regionales y multirregionales, mientras que Amazon Redshift solo ofrece ubicaciones regionales. BigQuery determina la ubicación para ejecutar los trabajos de carga, consulta o exportación según los conjuntos de datos a los que se hace referencia en la solicitud. Consulta las consideraciones de ubicación de BigQuery para obtener sugerencias sobre cómo trabajar con conjuntos de datos regionales y multirregionales.

Asignación de tipos de datos en BigQuery

Los tipos de datos de Amazon Redshift difieren de los tipos de datos de BigQuery. Para obtener más información sobre los tipos de datos de BigQuery, consulta la documentación oficial.

BigQuery también admite los siguientes tipos de datos, que no tienen un equivalente directo en Amazon Redshift:

Comparación de SQL

GoogleSQL admite el cumplimiento del estándar de SQL 2011 y tiene extensiones que admiten consultas de datos anidados y repetidos. SQL de Amazon Redshift se basa en PostgreSQL, pero tiene varias diferencias que se detallan en la documentación de Amazon Redshift. Para obtener una comparación detallada entre la sintaxis y las funciones de Amazon Redshift y GoogleSQL, consulta la guía de traducción de SQL de Amazon Redshift.

Puedes usar el traductor de SQL por lotes para convertir secuencias de comandos y otros códigos SQL de tu plataforma actual a BigQuery.

Después de la migración

Debido a que migraste secuencias de comandos que no se diseñaron con BigQuery en mente, puedes optar por implementar técnicas para optimizar el rendimiento de las consultas en BigQuery. Para obtener más información, consulta Introducción a la optimización del rendimiento de las consultas.

¿Qué sigue?