Administra datos de entrada y fuentes de datos

Cuando evalúes tus datos de entrada, ten en cuenta la E/S requerida. ¿Cuántos bytes lee tu consulta? ¿Limitas de forma adecuada la cantidad de datos de entrada? ¿Tus datos están en el almacenamiento nativo de BigQuery o en una fuente de datos externa? La cantidad y la fuente de los datos leídos afectan el rendimiento y el costo de la consulta.

Puedes examinar cómo una consulta lee los datos de entrada mediante la explicación del plan de consultas.

Las siguientes recomendaciones proporcionan orientación para controlar tus datos de entrada y elegir una fuente de datos.

Controla la proyección: Evita SELECT *

Recomendación: Controla la proyección y consulta solo las columnas que necesitas.

La proyección se refiere al número de columnas que lee tu consulta. Proyectar columnas en exceso incurre en materialización (resultados de escritura) y E/S adicionales (que se desperdician).

Usar SELECT * es la forma más costosa de consultar datos. Cuando usas SELECT *, BigQuery realiza un análisis completo de cada columna en la tabla.

Si exploras datos o experimentas con ellos, usa una de las opciones de vista previa de datos, en lugar de SELECT *.

Aplicar una cláusula LIMIT a una consulta SELECT * no afecta la cantidad de datos leídos. Se te cobra por leer todos los bytes en la tabla completa y la consulta cuenta para tu cuota de nivel gratuito.

En su lugar, consulta solo las columnas que necesitas. Por ejemplo, usa SELECT * EXCEPT para excluir una o más columnas de los resultados.

Si es obligatorio consultar todas las columnas de una tabla, pero solo en un subconjunto de datos, considera las opciones siguientes:

  • Materializar los resultados en una tabla de destino y consultar esa tabla en su lugar
  • Realizar particiones en tus tablas por fecha y consultar la partición relevante; por ejemplo, WHERE _PARTITIONDATE="2017-01-01" solo analiza la partición del 1 de enero de 2017

Consultar un subconjunto de datos o usar SELECT * EXCEPT puede reducir mucho la cantidad de datos que lee una consulta. Además de ahorrar costos, se mejora el rendimiento porque se reduce la cantidad de E/S de datos y la cantidad de materialización necesaria para los resultados de la consulta.

Reduce las consultas con particiones

Recomendación: Cuando consultas una tabla particionada, debes usar la seudocolumna _PARTITIONTIME para filtrar las particiones.

Cuando consultas tablas particionadas, usa la pseudocolumna _PARTITIONTIME. Filtrar los datos con _PARTITIONTIME te permite especificar una fecha o período. Por ejemplo, la siguiente cláusula WHERE usa la seudocolumna _PARTITIONTIME para especificar particiones entre el 1 de enero de 2016 y el 31 de enero de 2016:

WHERE _PARTITIONTIME
BETWEEN TIMESTAMP("20160101")
    AND TIMESTAMP("20160131")

La consulta procesa datos solo en las particiones que indica el período, lo que reduce la cantidad de datos de entrada. Filtrar tus particiones mejora el rendimiento de las consultas y reduce los costos.

Desnormaliza los datos siempre que sea posible

Práctica recomendada: BigQuery funciona mejor cuando tus datos están desnormalizados. En lugar de preservar un esquema relacional como uno de estrella o de copo de nieve, puedes mejorar el rendimiento si desnormalizas tus datos y aprovechas los campos anidados y repetidos. Los campos anidados y repetidos pueden conservar relaciones sin el impacto en el rendimiento que produce conservar un esquema relacional (normalizado).

El ahorro de almacenamiento de datos normalizados tiene menos efecto en los sistemas modernos. Los aumentos en los costos de almacenamiento se compensan con lo que se gana en el rendimiento del uso de datos desnormalizados. Las uniones requieren coordinación de datos (ancho de banda de comunicación). La desnormalización localiza los datos en ranuras individuales para que la ejecución se pueda realizar en paralelo.

Para mantener las relaciones al desnormalizar tus datos, puedes usar campos anidados y repetidos, en lugar de compactar por completo tus datos. Cuando los datos relacionales se compactan por completo, la comunicación de red (redistribución) puede tener un impacto negativo en el rendimiento.

Por ejemplo, la desnormalización de un esquema de pedidos sin usar campos repetidos y anidados podría requerir la agrupación por campos como order_id (cuando hay una relación de uno a varios). Debido a la redistribución involucrada, agrupar los datos es menos eficaz que desnormalizarlos mediante campos repetidos y anidados.

En algunas circunstancias, desnormalizar tus datos y usar campos anidados y repetidos no genera un mayor rendimiento. Evita la desnormalización en los casos prácticos siguientes:

  • Cuando tienes un esquema en estrella con dimensiones que cambian con frecuencia
  • BigQuery complementa un sistema de procesamiento de transacciones en línea (OLTP) con mutación a nivel de fila, pero no puede reemplazarlo.

Usa campos repetidos y anidados

BigQuery no requiere una desnormalización compacta por completo. Puedes usar campos repetidos y anidados para conservar relaciones.

  • Datos anidados (STRUCT)

    • Anidar datos te permite representar entidades externas intercaladas.
    • La consulta de datos anidados usa la sintaxis de “punto” para hacer referencia a los campos de hoja, que es similar a la sintaxis que usa una unión.
    • Los datos anidados se representan como un tipo de STRUCT en SQL estándar.
  • Datos repetidos (ARRAY)

    • Crear un campo de tipo RECORD con el modo configurado como REPEATED te permite conservar una relación de 1 a varios intercalada (siempre que la relación no sea de alta cardinalidad)
    • Con datos repetidos, la redistribución no es necesaria.
    • Los datos repetidos se representan como un ARRAY. Puedes usar una función ARRAY en SQL estándar cuando consultes datos repetidos.
  • Datos repetidos y anidados (ARRAY de STRUCT)

    • La anidación y la repetición se complementan.
    • Por ejemplo, en una tabla de registros de transacciones, podrías incluir un arreglo de STRUCT de elementos de una sola línea.

Usa las fuentes de datos externas de forma adecuada

Recomendación: Si el rendimiento de las consultas es una prioridad principal, no uses una fuente de datos externa.

La consulta de tablas en el almacenamiento administrado de BigQuery suele ser mucho más rápida que la consulta de tablas externas en Cloud Storage, Google Drive o Cloud Bigtable.

Usa una fuente de datos externa para los siguientes casos prácticos:

  • Realización de operaciones de extracción, transformación y carga (ETL) cuando se cargan datos
  • Datos que cambian con frecuencia
  • Cargas periódicas, como la transferencia recurrente de datos desde Cloud Bigtable

Evita el exceso de tablas comodín

Recomendación: Cuando consultes tablas comodín, usa el prefijo más detallado posible.

Usa comodines para consultar tablas múltiples mediante instrucciones de SQL concisas. Las tablas comodín son una unión de tablas que coinciden con la expresión de comodín. Las tablas comodín son útiles si tu conjunto de datos contiene lo siguiente:

  • Múltiples tablas con nombres similares y esquemas compatibles
  • Tablas fragmentadas

Cuando consultes una tabla comodín, especifica un comodín * después del prefijo de tabla común. Por ejemplo, FROM bigquery-public-data.noaa_gsod.gsod194* consulta todas las tablas de la década de 1940.

Los prefijos más detallados funcionan mejor que los más cortos. Por ejemplo, FROM bigquery-public-data.noaa_gsod.gsod194* funciona mejor que FROM bigquery-public-data.noaa_gsod.* porque hay menos tablas que coinciden con el comodín.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.