TecNoticias, tu portal de información

Prácticas recomendadas y cosas que se deben evitar al ejecutar SQL en Google Cloud BigQuery

Foto de Jack Carter en UnsplashBigQuery es el administrado Almacén de datos servicio en plataforma de nube de google, y como la mayoría de los servicios y tecnologías, viene con un conjunto de principios que uno debe tener en cuenta al usarlo. En las próximas secciones describiremos un conjunto de mejores prácticas para evitar antipatrones comunes que suelen afectar negativamente el rendimiento en BigQuery. Aplicar las mejores prácticas es importante principalmente por dos razones: lo ayudarán escribir consultas más eficientes y al mismo tiempo, si se aplica correctamente, reduce tus costos.

Evitar SELECCIONAR *

Seleccionar todos los campos de un conjunto de resultados es un antipatrón muy común que debe evitarse siempre que sea posible. SELECCIONAR * dará como resultado escaneos completos para cada columna de la tabla, lo que significa que esta será una operación costosa de ejecutar.

Consulta solo las columnas que necesitas

Recuerde también que LIMIT no reducirá el volumen de bytes leídos y, por lo tanto, seguirá pagando por el escaneo completo de cada columna. Por lo tanto, asegúrese de consultar solo las columnas que realmente necesita. En caso de que aún necesite ejecutar SELECT *, considere particionar su tabla de modo que pueda consultar los datos que residen en una o algunas de las particiones.

Evite las uniones automáticas

Realizar una autounión sobre una mesa es otra cosa que debe evitar. Naturalmente, alguien preguntaría cuál es la diferencia entre una unión de dos tablas separadas y una autounión. Bueno, la respuesta es ninguna; es más o menos lo mismo, pero el punto aquí es que siempre que esté a punto de realizar una autounión, las posibilidades ¿Puede lograr el mismo resultado con una función de ventana que es una forma más elegante?

Evite las uniones automáticas y use funciones de ventana en su lugar

Una autounión podría aumentar la cantidad de filas de salida, lo que significa que degradará el rendimiento de la consulta y también generará una mayor cantidad de bytes procesados, lo que aumentará el costo de ejecutar dichas consultas.

Tratar con la asimetría de datos

La asimetría de datos es el fenómeno que aparece cuando sus datos se dividen en particiones de tamaño desigual. Detrás de escena, BigQuery enviará estas particiones a ranuras que son CPU virtuales que se usan para ejecutar consultas SQL de manera distribuida. Por lo tanto, las particiones no se pueden compartir entre diferentes ranuras. En caso de que haya creado particiones desequilibradas, esto significa que algunas ranuras terminarán con una carga de trabajo significativamente mayor que otras, mientras que en algunos casos extremos, las particiones de gran tamaño pueden incluso bloquear las ranuras. con mucha más frecuencia que otros, lo más probable es que termine con particiones de tamaño desigual. En tales casos, la aplicación de filtros desde el principio le ayudará a reducir este tipo de desequilibrio.

Si sus datos están sesgados, solicite filtración lo más pronto posible

Además, es posible que también tenga que volver a considerar la clave de partición. Por ejemplo, es posible que desee evitar particionar una tabla usando una clave con muchos valores NULL, ya que esto creará una partición enorme para tales filas. Una clave de partición de uso común es un campo de fecha que garantiza una distribución algo uniforme de los datos entre diferentes particiones (suponiendo que tiene aproximadamente la misma cantidad de datos por día/mes/año).

Uniones cruzadas

Las combinaciones cruzadas se utilizan para generar el producto cartesiano entre dos tablas, que es un resultado que consiste en todas las combinaciones posibles entre los registros de las tablas involucradas. En términos más simples, cada fila de la primera tabla se unirá a cada una de las filas de la segunda tabla, lo que significa que, en el peor de los casos, terminaremos teniendo un resultado que consiste en MxN filas donde M y N son los tamaños de la tabla. respectivamente.

Evite la ejecución de uniones que darán como resultado más salidas que entradas

Por lo tanto, esto significa que una unión cruzada normalmente devolverá más filas de salida que de entrada, algo que normalmente querríamos evitar. Como consejo general, en tales casos, debe considerar dos posibles soluciones alternativas: Evalúe si una función de ventana, que es mucho más eficiente que una combinación cruzada, puede ayudarlo a obtener el resultado que está buscando Realice una agregación previa utilizando GROUP BY antes de la unión

Prefiere la partición de tablas a la fragmentación

La fragmentación de tablas es un enfoque utilizado para almacenar datos en varias tablas diferentes, utilizando un prefijo de nombre como [PREFIX]_AAAAMMDD. Muchos usuarios considerarían que la técnica anterior es igual a la partición, pero en realidad esto no es cierto. La fragmentación de tablas requiere que BigQuery mantenga los metadatos y los esquemas para cada tabla; además, cada vez que se realiza una acción, la plataforma tendría que verificar los permisos. para todas las tablas individuales, lo que tiene un impacto significativo en el rendimiento.

La partición de tablas es más eficiente que la fragmentación de tablas

En general, la partición de tablas funciona mejor y, por lo tanto, debe preferirlas a las tablas fragmentadas. Además, las tablas particionadas son más fáciles de manejar cuando se trata de filtrado y reducción de costos.

No trates a BigQuery como un sistema OLTP

Como la mayoría de las soluciones de almacenamiento de datos, BigQuery también es un sistema OLAP (procesamiento analítico en línea). Lo que significa que está diseñado para ser eficiente cuando se trata de trabajar con volúmenes de datos extremadamente grandes con el uso de escaneos de tablas. Por lo tanto, se supone que las declaraciones DML en BigQuery no deben usarse para realizar a granel actualizaciones.

BigQuery es un sistema OLAP y debe tratarse como tal

El uso de declaraciones DML para realizar cambios modulares significa que intenta tratar a BigQuery como un sistema OLTP (procesamiento de transacciones en línea). Si ese es el caso, debe reconsiderar su diseño, o incluso las herramientas que está utilizando. Existe la posibilidad de que un sistema OLTP (como CloudSQL en Google Cloud Platform) sea más adecuado. Alternativamente, si su diseño involucra insertos modulares regulares, puede considerar otras tecnologías como la transmisión. Para obtener más detalles sobre las principales diferencias entre los sistemas OLAP y OLTP, puede leer uno de mis últimos artículos.

Pensamientos finales

Aplicar las prácticas recomendadas y evitar antipatrones comunes en BigQuery es extremadamente importante, ya que estos principios lo ayudarán a mejorar el rendimiento de su sistema y a reducir sus costos. En resumen, evite SELECT * y, en su lugar, asegúrese de consultar solo los campos que necesita Preferir las funciones de ventana sobre las autocombinaciones siempre que sea posible (por ejemplo, si lo que necesita calcular depende de la fila) Elija las claves de partición sabiamente para evitar la asimetría de datos. Siempre que esto no sea posible, asegúrese de aplicar los filtros lo antes posible. Evite las uniones que generarán más salidas que entradas. Prefiera la partición de tablas a la fragmentación de tablas, ya que la primera es más eficiente y rentable. Evite declaraciones DML modulares: BigQuery es un sistema OLAP y necesita ser tratado como talHazte miembro y lee todas las historias en Medium. Su cuota de membresía me apoya directamente a mí y a otros escritores que lee. También obtendrá acceso completo a todas las historias en Medium.Artículos relacionados que también te pueden gustar