Big Query: Módulo 4
Diseño de Esquemas
Diseñar esquemas a escala, un trabajo del equipo de data engineering. Big Query almacena centenares de datos y esquemas públicos para explorar y utilizarlos como lecturas de metrología diarias, registros de taxis, datos de salud, etc.
Revisando las tablas de datos podemos ver los datos se organizaron visualmente tal vez en una hoja de cálculo pero ahora pensemos en que deseamos operar esos datos, pregúntate cuál será la forma mas efectiva de hacerlos procesarlos por columnas o tal vez por filas o una combinación híbrida podría ser la solución pero recuerde que todo esto desempeña un papel importante en la consulta, los datos originales se pueden almacenar de diversas formas y una de las más convenientes en normalizarlos, es decir, los convertimos en un sistema relacional asegurando una gran eficiencia a la hora de almacenarlos y además que las consultas y tareas sean de forma directa.
La desnormalización es una estrategia para permitir valores duplicados de un campo para una columna en una tabla, estos datos se repiten en lugar de ser relacionales. Los datos aplanados requieren mayor almacenamiento teniendo un mayor rendimiento ya que se puede procesar en paralelo y utilizar un tratamiento por columnas, en sí la desnormalización de los datos permite a BigQuery distribuir de manera más eficiente el procesamiento entre ranuras y trabajar con procesos paralelos.
Existen excepciones al momento de desnormalizar los datos hay casos que este proceso resulta en un mal rendimiento, por ejemplo, al agrupar una columna con una relación de 1 a varios, esto provoca que se solicite mucha información teniendo así a los servidores trabajando al máximo y como consecuencia la transferencia de los datos es lenta.
BigQuery admite columnas con datos anidados y repetidos, como ejemplo una tabla aplanada desnormalizada se con una tabla que se ha desnormalizado pero el sistema aprovecha los campos anidados y repetidos, como se observa orderID es un campo repetido, BigQuery puede almacenar y procesar los datos respetando parte de la organización original de estos.
Todos los datos de la orden se encuentran en dicho casillero lo q es una forma muy eficiente de obtener esos datos, las columnas anidadas se pueden entender como una forma de campo repetido estas conservan los datos relacionales y esquemas originales. Convertir la relación en un campo anidado o repetido mejora el rendimiento de BigQuery.
Campos Anidados y Repetidos
GOJEK un negocio que se ejecuta en GCP, un servicio de reservas con sede en Indonesia, este procesa más de 13 Petabytes de datos en BigQuery al mes a partir de consultas para apoyar a las decisiones empresariales como el rastreo de un nuevo cliente cuando hace un pedido, dicha orden se almacena en una tabla de pedidos donde cada pedido tiene un lugar de recogida un lugar de entrega y otros datos relevantes, ahora… ¿cómo puedes almacenar estos datos de forma eficiente?
Se puede almacenar con la normalización ruta típica de los sistemas relacionales o también se puede optar por el modelo totalmente desnormalizado en ruta y simplemente almacenar todos los niveles en una tabla más grande, un identificador de pedido como ‘123’ repetido en una fila para cada evento que sucede en ese orden ¿Cuáles son los inconvenientes?
Para esquemas relacionales(normalizados), en tablas muy grandes donde los rdBMS se basan en registros por lo que tiene que abrir cada uno por completo y sacar la clave de unión de cada tabla donde existe un partido y todo esto suponiendo que usted sabe todas las tablas que se necesitan ser unidas, como esta información va creciendo se van presentando inconvenientes, usted puede pre-unir todas sus mesas en una masiva tabla que hace lectura de datos de forma rápida pero hay que tener cuidado con los datos en los diferentes niveles, por ejemplo cada dato de la orden estaría en un nivel por ello si se plantea esta solución hay que ser muy cuidadosos con las agregaciones para no duplicar o triplicar los datos de las órdenes.
Una solución común en los esquemas de almacenamiento de datos es aprovechar los campos anidados y repetidos. Puede tener una fila para cada pedido y valores repetidos dentro de esa fila para que los datos se encuentren en un nivel más granular, por ejemplo, tener un array de marcas de tiempo como sus eventos.
Un arreglo o array es un tipo de dato ideal para manejar este valor repetido y mantener todos los beneficios de almacenar esos datos en una sola fila. El espacio gris entre filas, se debe a que esas celdas están en un nivel más profundo de granularidad, es decir que hay múltiples repetidos valores para estos eventos por cada pedido.
Los campos de tipo de datos de estructura en SQL como evento, recogida, y destino, son estructuras que se pueden considerar como tablas unidas previamente dentro de una tabla. Entonces, en lugar de tener una mesa separada para EVENTOS, RECOGIDAS y DESTINOS, simplemente los anidan dentro de su mesa principal.
Se puede profundizar en un solo campo y hacer que sea más granular que el resto utilizando un tipo de datos ARRAY como se ve en la figura para STATUS y TIME.
También se puede tener esquemas realmente ANCHOS mediante el uso de ESTRUCTAS que le permiten tener múltiples campos del mismo tipo de datos o diferente. El principal beneficio de STRUCT es que los datos ya se han unido conceptualmente, por lo que es mucho más rápido consultarlos.
Hay que recordar que BigQuery es un almacenamiento basado en columnas no basado en registros cuando se almacenan datos en el disco. Si solo hiciera un COUNT (order_id) aquí para obtener sus pedidos totales, a BigQuery ni siquiera le importaría tener otras 99 columnas, algunas de las cuales son más granulares con los tipos de datos ARRAY.
Cabe recalcar que los tipos de datos STRUCT y ARRAY en SQL pueden ser independientes entre sí. Es decir, que una columna regular en SQL, sea una columna ARRAY que no tiene nada que ver con ningún STRUCT. La ventaja de usarlos juntos es que el ARRAY permite que cierto campo profundice la granularidad, y STRUCT organiza los campos útiles en contenedores lógicos.
Se pueden consultar el documento técnico de Dremel publicado en 2010 por Google. Dremel es el motor masivo paralelo de SQL que impulsa el BigQuery. Los diagramas del documento explican cómo se almacena la estructura de BigQuery cuando se usa el almacenamiento orientado en columnas. Las columnas pueden almacenar valores, definiciones, y niveles de repetición.
Es preferible los campos anidados y repetidos hallados en tablas desnormalizadas, que las combinaciones. En BigQuery, es mucho más eficiente si se almacena cada pedido en una fila y tiene una columna anidada y repetida llamada Dato1, por ejemplo. Las matrices son un tipo nativo en BigQuery.
En lugar de combinaciones, aproveche los campos anidados y repetidos en tablas desnormalizadas.
Se debe mantener una tabla de dimensiones al menos de 10 GB normalizada, excepto cuando la tabla pare por las operaciones UPDATE y DELETE.
Se debe desnormalizar una tabla de dimensiones mayor a 10 GB, excepto cuando la manipulación de datos o los costos superen los beneficios de las consultas óptimas.
Optimizar con Particionamiento (Partitioning) y Agrupamiento (Clustering)
Una forma de optimizar las tablas en un data warehouse es reduciendo el costo y la cantidad de datos leídos al particionar las tablas.
Por ejemplo, asumir que se ha particionado la tabla de la figura, por la columna de eventDate. BigQuery cambiará su almacenamiento interno para que las fechas sean almacenadas en diferentes fragmentos.
En una tabla particionada por una fecha o una columna de estampa de tiempo, cada partición contiene un día de datos. Cuando los datos son almacenados BigQuery asegura todos los datos en un bloque que pertenece a una única partición. Esto requerirá que BigQuery mantenga más metadatos que una tabla no particionada.
Al hacer un query con una cláusula WHERE, que busque datos entre un intervalo de fechas, BigQuery solo leerá ⅖ de todo la base de datos.
El usuario permite el particionamiento durante el proceso de creación de tablas. A medida que nuevos registros son agregados a la tabla, estos son puestos en la partición correcta. BigQuery crea nuevas particiones basadas en datos automáticamente y sin necesidad de mantenimiento.
Aunque se deben mantener más metadatos, asegurando que los datos están particionados
globalmente, BigQuery puede estimar con mayor precisión los bytes procesados por un query antes de ejecutarlo. Este cálculo de costo proporciona un límite superior sobre el costo final de la consulta.
El agrupamiento puede mejorar el desempeño de ciertos tipos de queries. Cuando los datos son escritos a una tabla agrupada BigQuery organiza los datos usando los valores en las columnas agrupadas. Estos valores son usados para organizar los datos en bloques múltiples en el almacenamiento de BigQuery. Al enviar un query que contiene una cláusula que filtra datos basados en columnas agrupadas, BigQuery usa los bloques organizados para eliminar el escaneo de datos innecesarios.
De manera similar, al enviar un query que agrega datos basados en los valores en las columnas agregadas, el desempeño es mejorado debido a que los bloques organizados co-localizan filas con valores similares.
Las columnas especificadas en el agrupamiento son usados para co-localizar datos relacionados. Al agrupar una tabla usando múltiples columnas, el orden de las columnas que se especifica son importantes. El orden de las columnas especificadas determina el orden de clasificación de los datos.
Al pasar el tiempo el grado con el que los datos es clasificada comienza a debilitarse y la tabla se convierte en una parcialmente clasificada. Actualmente, BigQuery hace un reagrupamiento periódico. El reagrupamiento automático es gratis y ocurre automáticamente en el fondo.
Por el momento, BigQuery soporta agrupamiento antes que particionamiento de tablas.
Sus datos ya están particionados en DATE o TIMESTAMP o Integer Range. Comúnmente usa filtros o agregación contra columnas particulares en sus consultas.
Actualmente, BigQuery admite la agrupación en clúster sobre una tabla particionada.
La agrupación de tablas es compatible tanto para tablas particionadas en tiempo de ingestión como para tablas particionado en una fecha o columnas de fecha y hora. Actualmente, la agrupación no es compatible con Tablas no particionadas.
Cuando utiliza la agrupación y la partición juntas, los datos pueden ser particionados por un columna de fecha o marca de tiempo y luego agrupada en un conjunto diferente de columnas. En este caso, los datos en cada partición se agrupan en función de los valores de la agrupación columnas El particionamiento proporciona una forma de obtener estimaciones de costos precisas para consultas. Tenga en cuenta si no tiene columnas particionadas y desea los beneficios de agrupación puede crear una columna fake_date de tipo DATE y tener todos los valores ser NULO.
Vista previa: Transformación de lotes y datos de transmisión
¿Qué pasa si sus datos entrantes no son utilizables en su forma cruda? Aprenderemos a lidiar con esta situación en el próximo curso sobre procesamiento de datos.
Una cartera típica de productos GCP que admiten ETL
Hace unos años hubiera sido fácil poner este esquema en un diagrama. La tecnología y el mercado han evolucionado significativamente desde entonces, haciendo que sea difícil captura todo en un diagrama.
Este no es un esquema consistente o completo, pero le da una idea de cómo Todo encaja. Puedes ver los 7 servicios: los principales árboles entre bosque: eso lo ayudará a encontrar las rutas a través de la nube necesarias para los datos Ingenieria.
Cloud Pub / Sub envía datos de transmisión a Cloud Dataflow. Cloud Dataflow almacena el datos y los transforma en BigQuery o en Cloud Bigtable. El almacenamiento en la nube contiene lotes datos y los envía a Cloud Dataproc o a Cloud Dataflow.
Esto describe las soluciones de procesamiento de datos. Luego agregas Inteligencia Artificial servicios y finalmente, el usuario y las interfaces comerciales.
datos, Google Cloud tiene varias herramientas para ayudar a procesar eso. Estos son principalmente Cloud Pub / Sub, Cloud Dataflow y Cloud Bigtable.
¿Qué pasa si sus datos llegan de forma continua y sin fin?
Si tiene un flujo continuo de datos, Google Cloud tiene varias herramientas para ayudar a procesar eso. Estos son principalmente Cloud Pub / Sub, Cloud Dataflow y Cloud Bigtable.
Puede transmitir datos en tiempo real directamente a BigQuery o procesarlos primero con Cloud Flujo de datos. Las secuencias son ilimitadas, lo que significa que no hay un final definido. Esto crea un especial desafío para algoritmos que normalmente dependen del final de los datos para activar alguna acción. Esta discusión continúa en el curso sobre procesamiento de datos de transmisión.
La transmisión no es un trabajo de carga. Más bien, es un método de BigQuery separado llamado “insertos de transmisión”. Este método le permite insertar un elemento a la vez en una tabla. Se pueden crear nuevas tablas a partir de una tabla de plantilla que identifica el esquema a ser copiado Por lo general, los datos están disponibles en segundos. Los datos entran en un búfer de transmisión, donde se mantiene brevemente hasta que se pueda insertar en la mesa.
La disponibilidad de datos y la coherencia son consideraciones para la transmisión de datos. Candidatos para la transmisión son análisis o aplicaciones que toleran datos tardíos o faltantes o datos que llegan fuera de servicio o duplicados. La transmisión puede pasar por otros servicios, introduciendo latencia adicional y la posibilidad de errores.
Debido a que la transmisión de datos no tiene límites, debe considerar las cuotas de transmisión. Hay un límite diario y un límite de tasa concurrente. Puedes encontrar más información sobre estos en la documentación en línea.
¿Cuándo debería ingerir una secuencia de datos en lugar de utilizar un enfoque por lotes para cargar ¿datos? Cuando la disponibilidad inmediata de los datos es un requisito de solución. En la mayoría casos, la carga de datos por lotes no se cobra. La transmisión está cargada. Usar carga por lotes o carga repetida de lotes en lugar de transmisión, a menos que sea un requisito de solicitud.
Autores:
- Steve Acosta
- Matías Idrobo
- Williams Ortiz
- Paúl Ramírez
Revisa los siguientes post
Módulo 1: Introduction to Data Engineering
Módulo 2: Construyendo un Data Lake en GCP
Módulo 3: Building a Data Warehouse
Módulo 6: Serverless Data Processing with Dataflow
Conoce más: http://bootcampai.org/di
