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 consultes una tabla con particiones, usa la seudocolumna _PARTITIONTIME para filtrar las particiones.

Cuando consultes tablas con particiones, usa la seudocolumna _PARTITIONTIME. Filtrar los datos con _PARTITIONTIME te permite especificar una fecha o período. Por ejemplo, la siguiente cláusula WHERE usa la pseudocolumna _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

Recomendación: BigQuery funciona mejor cuando tus datos están desnormalizados. En vez de conservar un esquema relacional como un esquema en estrella o en copo de nieve, desnormaliza tus datos y aprovecha los campos repetidos y anidados. Los campos repetidos y anidados pueden conservar relaciones sin el impacto en el rendimiento de conservar un esquema relacional (normalizado).

Los ahorros de almacenamiento de datos normalizados no son tan importantes en los sistemas modernos. Los aumentos en los costos de almacenamiento se compensan con lo que se gana en rendimiento gracias a la desnormalización de datos. 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.

Si necesitas conservar relaciones mientras desnormalizas tus datos, usa campos repetidos y anidados en lugar de compactarlos por completo. 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 repetidos y anidados podría no dar como resultado un mayor rendimiento. Evita la desnormalización en los casos prácticos siguientes:

  • 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 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 cardinalidad elevada)
    • 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.