Descripción general del almacenamiento de BigQuery

En esta página, se describe el componente de almacenamiento de BigQuery.

El almacenamiento de BigQuery está optimizado para ejecutar consultas analíticas en conjuntos de datos grandes. También admite la transferencia de transmisión con alta capacidad de procesamiento y lecturas con alta capacidad de procesamiento. Comprender el almacenamiento de BigQuery puede ayudarte a optimizar tus cargas de trabajo.

Descripción general

Una de las características clave de la arquitectura de BigQuery es la separación del almacenamiento y el procesamiento. Esto permite que BigQuery escale el almacenamiento y el procesamiento de forma independiente, según la demanda.

Arquitectura de BigQuery
Figura 1. Arquitectura de BigQuery.

Cuando ejecutas una consulta, el motor de consultas distribuye el trabajo en paralelo entre múltiples trabajadores, que analizan las tablas relevantes en el almacenamiento, procesan la consulta y, luego, recopilan los resultados. BigQuery ejecuta consultas completamente en la memoria, mediante una red de petabits para garantizar que los datos se muevan muy rápido a los nodos trabajadores.

Estas son algunas características clave del almacenamiento de BigQuery:

  • Administrado. El almacenamiento de BigQuery es un servicio completamente administrado. No es necesario aprovisionar recursos de almacenamiento ni reservar unidades de almacenamiento. BigQuery te asigna el almacenamiento de forma automática cuando cargas datos en el sistema. Solo pagas por la cantidad de almacenamiento que usas. El modelo de precios de BigQuery cobra por el procesamiento y el almacenamiento por separado. Para obtener detalles sobre los precios, consulta Precios de BigQuery.

  • Duradero. El almacenamiento de BigQuery está diseñado para tener una durabilidad anual del 99.999999999% (11 “nueves”). BigQuery replica tus datos en varias zonas de disponibilidad para protegerlos contra la pérdida de datos debido a fallas a nivel de máquina o zonales. Para obtener más información, consulta Confiabilidad: Planificación ante desastres.

  • Encriptado. BigQuery encripta de forma automática todos los datos antes de que se escriban en el disco. Puedes proporcionar tu propia clave de encriptación o dejar que Google la administre. Para obtener más información, consulta Encriptación en reposo.

  • Eficaz. El almacenamiento de BigQuery usa un formato de codificación eficiente que está optimizado para las cargas de trabajo analíticas. Si deseas obtener más información sobre el formato de almacenamiento de BigQuery, consulta la entrada de blog Mirada al interior de Capacitor, el formato de almacenamiento en columna de última generación de BigQuery.

Datos de tabla

La mayoría de los datos que almacenas en BigQuery son datos de tabla. Los datos de la tabla incluyen tablas estándar, clonaciones de tablas, instantáneas de tablas y vistas materializadas. Se te factura por el almacenamiento que usas para estos recursos. Para obtener más información, consulta los precios de almacenamiento.

  • Las tablas estándar contienen datos estructurados. Cada tabla tiene un esquema, y cada columna del esquema tiene un tipo de datos. BigQuery almacena datos en formato de columnas. Consulta Diseño de almacenamiento en este documento.

  • Las clonaciones de tablas son copias livianas y que admiten escritura de las tablas estándar. BigQuery solo almacena el delta entre una clonación de tabla y su tabla base.

  • Las instantáneas de tablas son copias de tablas de un momento determinado. También son de solo lectura, pero puedes restablecer una tabla desde una instantánea de tablas. BigQuery solo almacena el delta entre una instantánea de tabla y su tabla base.

  • Las vistas materializadas son vistas procesadas previamente que almacenan en caché de forma periódica los resultados de la consulta de vista. Los resultados almacenados en caché se almacenan en el almacenamiento de BigQuery.

Además, los resultados de las consultas en caché se almacenan como tablas temporales. No se te cobrará por los resultados de consultas almacenados en caché en tablas temporales.

Las tablas externas son un tipo especial de tabla, en el que los datos residen en un almacén de datos externo a BigQuery, como Cloud Storage. Una tabla externa tiene un esquema de tabla, al igual que una tabla estándar, pero la definición de la tabla apunta al almacén de datos externo. En este caso, solo los metadatos de la tabla se conservan en el almacenamiento de BigQuery. BigQuery no cobra por el almacenamiento de tablas externas, aunque el almacén de datos externo puede cobrar por el almacenamiento.

BigQuery organiza las tablas y otros recursos en contenedores lógicos llamados conjuntos de datos. La forma en que agrupas tus recursos de BigQuery afecta los permisos, las cuotas, la facturación y otros aspectos de tus cargas de trabajo de BigQuery. Para obtener más información y prácticas recomendadas, consulta Organiza recursos de BigQuery.

La política de retención de datos que se usa para una tabla se determina según la configuración del conjunto de datos que contiene la tabla. Para obtener más información, consulta Retención de datos con viaje en el tiempo y seguridad ante fallas.

Metadatos

El almacenamiento de BigQuery también contiene metadatos sobre tus recursos de BigQuery. No se te cobra por el almacenamiento de metadatos.

Cuando creas cualquier entidad persistente en BigQuery, como una tabla, vista o función definida por el usuario (UDF), BigQuery almacena metadatos sobre la entidad. Esto es así incluso en los recursos que no contienen datos de tablas, como las UDF y las vistas lógicas.

Los metadatos incluyen información como el esquema de la tabla, las especificaciones de partición y agrupamiento en clústeres, los tiempos de vencimiento y otra información. Este tipo de metadatos es visible para el usuario y se puede configurar cuando creas el recurso. Además, BigQuery almacena los metadatos que usa de forma interna para optimizar las consultas. Estos metadatos no son directamente visibles para los usuarios.

Diseño de almacenamiento

Muchos sistemas de bases de datos tradicionales almacenan sus datos en un formato orientado a filas, lo que significa que las filas se almacenan juntas, y los campos de cada fila aparecen de forma secuencial en el disco. Las bases de datos orientadas a filas son eficientes en la búsqueda de registros individuales. Sin embargo, pueden ser menos eficientes cuando realizan funciones analíticas en muchos registros, ya que el sistema debe leer cada campo cuando accede a un registro.

Formato orientado a filas
Figura 2. Formato orientado a filas.

BigQuery almacena los datos de las tablas en formato de columnas, lo que significa que almacena cada columna por separado. Las bases de datos orientadas a columnas son particularmente eficientes en el análisis de columnas individuales en un conjunto de datos completo.

Las bases de datos orientadas a columnas están optimizadas para cargas de trabajo analíticas que agregan datos a una gran cantidad de registros. A menudo, una consulta analítica solo necesita leer algunas columnas de una tabla. Por ejemplo, si deseas calcular la suma de una columna en millones de filas, BigQuery puede leer esos datos de la columna sin leer cada campo de cada fila.

Otra ventaja de las bases de datos orientadas a columnas es que los datos dentro de una columna suelen tener más redundancia que los datos en una fila. Esta característica permite una mayor compresión de datos mediante el uso de técnicas como la codificación de longitud de la ejecución, que puede mejorar el rendimiento de la lectura.

Formato orientado a columnas
Figura 3. Formato orientado a columnas.

Modelos de facturación de almacenamiento

Se te puede facturar por el almacenamiento de datos de BigQuery en bytes lógicos o físicos (comprimidos), o en una combinación de ambos. El modelo de facturación de almacenamiento que elijas determinará los precios de almacenamiento. El modelo de facturación de almacenamiento que elijas no afecta el rendimiento de BigQuery. Sin importar el modelo de facturación que elijas, tus datos se almacenarán como bytes físicos.

El modelo de facturación de almacenamiento se establece a nivel del conjunto de datos. Si no especificas un modelo de facturación de almacenamiento cuando creas un conjunto de datos, la configuración predeterminada usará la facturación de almacenamiento lógico. Sin embargo, puedes cambiar el modelo de facturación de almacenamiento de un conjunto de datos después de crearlo. Una vez que cambies el modelo de facturación de almacenamiento de un conjunto de datos, debes esperar 14 días antes de poder volver a cambiar el modelo de facturación de almacenamiento.

Cuando cambias el modelo de facturación de un conjunto de datos, el cambio tarda 24 horas en aplicarse. Las tablas o particiones de tablas en el almacenamiento a largo plazo no se restablecen al almacenamiento activo cuando cambias el modelo de facturación de un conjunto de datos. El rendimiento de las consultas y la latencia de las consultas no se ven afectados cuando cambias el modelo de facturación de un conjunto de datos.

Los conjuntos de datos usan viajes en el tiempo y almacenamiento seguro para fallas para la retención de datos. El almacenamiento seguro ante fallas y viaje en el tiempo se cobran por separado según las tarifas de almacenamiento activo cuando usas la facturación de almacenamiento físico, pero se incluyen en la tarifa base que se te cobra cuando usas la facturación de almacenamiento lógico. Puedes modificar el período de viaje en el tiempo que usas para un conjunto de datos a fin de balancear los costos de almacenamiento físico con la retención de datos. No puedes modificar la ventana de seguridad ante fallas. Para obtener más información sobre la retención de datos del conjunto de datos, consulta Retención de datos con viajes en el tiempo y seguridad ante fallas. Para obtener más información sobre la previsión de tus costos de almacenamiento, consulta Predice la facturación de almacenamiento.

No puedes inscribir un conjunto de datos en la facturación de almacenamiento físico si tienes compromisos de ranura de tarifa plana heredados existentes en la misma región que el conjunto de datos. Esto no se aplica a los compromisos adquiridos con una edición de BigQuery.

Optimiza el almacenamiento

La optimización del almacenamiento de BigQuery mejora el rendimiento de las consultas y controla los costos. Para ver los metadatos de almacenamiento de la tabla, consulta las siguientes vistas INFORMATION_SCHEMA:

Para obtener información sobre la optimización del almacenamiento, consulta Optimiza el almacenamiento en BigQuery.

Carga de datos

Existen varios patrones básicos para transferir datos a BigQuery.

  • Carga por lotes: Carga tus datos de origen en una tabla de BigQuery en una sola operación por lotes. Puede ser una operación única o puedes automatizarla para que se realice en función de un programa. Una operación de carga por lotes puede crear una tabla nueva o agregar datos a una tabla existente.

  • Transmisión: Transmite de forma continua lotes de datos más pequeños, de modo que los datos estén disponibles para consultas casi en tiempo real.

  • Datos generados: Usa instrucciones de SQL para insertar filas en una tabla existente o escribir los resultados de una consulta en una tabla.

Para obtener más información sobre cuándo elegir cada uno de estos métodos de transferencia, consulta Introducción a la carga de datos. Para obtener información sobre los precios, consulta Precios de transferencia de datos.

Lee datos del almacenamiento de BigQuery

La mayoría de las veces, debes almacenar los datos en BigQuery para ejecutar consultas analíticas en esos datos. Sin embargo, a veces es posible que desees leer los registros directamente desde una tabla. BigQuery proporciona varias formas de leer datos de tablas:

  • API de BigQuery: Acceso paginado síncrono con el método tabledata.list. Los datos se leen en serie, una página por invocación. Para obtener más información, consulta Explora los datos de las tablas.

  • API de BigQuery Storage: Transmite un acceso de alta capacidad de procesamiento que también admite la proyección y el filtrado de columnas del servidor. Las lecturas se pueden paralelizar a muchos lectores mediante la segmentación en varias transmisiones inconexas.

  • Exportar: Copia asíncrona de alta capacidad de procesamiento en Google Cloud Storage, ya sea con trabajos de extracción o con la sentencia EXPORT DATA. Si necesitas copiar datos en Cloud Storage, exporta los datos mediante un trabajo de extracción o una instrucción EXPORT DATA.

  • Copia: Copia asíncrona de conjuntos de datos en BigQuery. La copia se realiza de forma lógica cuando la ubicación de origen y de destino es la misma.

Para obtener información sobre los precios, consulta Precios de extracción de datos.

Según los requisitos de la aplicación, puedes leer los datos de la tabla:

  • Lectura y copia: Si necesitas una copia en reposo en Cloud Storage, exporta los datos mediante un trabajo de extracción o una instrucción EXPORT DATA. Si solo deseas leer los datos, usa la API de BigQuery Storage. Si deseas crear una copia en BigQuery, usa un trabajo de copia.
  • Escalar: la API de BigQuery es el método menos eficiente y no debe usarse para lecturas de gran volumen. Si necesitas exportar más de 50 TB de datos al día, usa la declaración EXPORT DATA o la API de BigQuery Storage.
  • Tiempo para mostrar la primera fila: La API de BigQuery es el método más rápido a fin de mostrar la primera fila, pero solo debe usarse a fin de leer pequeñas cantidades de datos. La API de BigQuery Storage es más lenta en mostrar la primera fila, pero tiene una capacidad de procesamiento mucho mayor. Las exportaciones y copias deben finalizar antes de que se pueda leer cualquier fila, por lo que el tiempo hasta la primera fila para estos tipos de trabajos puede ser de minutos.

Eliminación

Cuando borras una tabla, los datos persisten durante al menos la duración de tu período de viaje en el tiempo. Después de esto, los datos se limpian del disco dentro del cronograma de eliminación de Google Cloud. Algunas operaciones de eliminación, como la declaración DROP COLUMN, son operaciones de solo metadatos. En este caso, el almacenamiento se libera la próxima vez que modifiques las filas afectadas. Si no modificas la tabla, no hay tiempo garantizado dentro del cual se libera el almacenamiento. Para obtener más información, consulta Eliminación de datos en Google Cloud.

¿Qué sigue?