Construyendo un Data Lake en GCP: Módulo 2

Introducción a Data Lake

Antes de hablar sobre los Data Lakes, es necesario conocer los componentes de un ecosistema de ingeniería de datos. Estos son:

• Fuentes de datos (Data Sources)
• Piscina de Datos (Data sinks)

Repositorio Central del Data Lake

Data Warehouse

• Data pipelines, ya sea por lote (batch) o transmisiones (streaming)
• Flujos de trabajo de orquestación de alto nivel

En la siguiente figura se puede observar un ejemplo de esta arquitectura utilizando los recursos que brinda Google Cloud Platform. Las fuentes de datos están encerradas en rojo, los data lake en azul, los data warehouse en verde y los data pipelines en negro.

Data Lake es un término usado para describir un lugar en donde es almacenado de manera segura varios tipos de datos de todas las escalas, para procesamiento y análisis. Los Data Lakes son usados para llevar a cabo análisis de datos, ciencia de datos y cargas de trabajo de machine learning.

En la imagen a continuación se observan los productos de Google Cloud Platform y principalmente en que son utilizados. Para este módulo (Data Lake) se utilizará Google Cloud Storage y Google Cloud SQL.

Es necesario señalar las diferencias entre los Data Lakes y los Data Warehouses.

Un Data Lake es donde se va a capturar” todos los aspectos de las operaciones del negocio. Estos datos son almacenados en su formato nativo o crudo (raw). Además, soporta todos los tipos de datos y usuarios, se adapta a cambios fácilmente y tiende a ser específico para una aplicación.

Por otra parte, un Data Warehouse provee insights más rápido, solo puede ser cargado cuando su uso está definido, es necesario procesar, organizar y transformar los datos antes de que sean almacenados. Además, tiende a ser más estructurado, organizado y puesto en un formato que sea más conductivo para hacer un query y análisis.

Almacenamiento de Datos y opciones ETL en GCP

Data lake soluciona tus problemas de almacenamiento, para ello tienes Cloud Storage como un llamado Catch-all, Cloud SQL y Cloud spanner para datos relacionales, además Cloud firestore y Cloud Bigtable para datos NoSQL.

La ruta que tiene la data para llegar a la nube depende de donde están ahora, del tamaño de estos, a donde irán, no hay que olvidarse de tomar en cuenta cuanta cantidad de proceso y transformación necesita la data antes de que sea útil para algún usuario.

¿Hago el procesamiento antes de cargarlo en mi Data Lake o después antes de que sea enviado a otro lugar?

El primer método para cargar los datos en la nube depende de la cantidad de transformaciones necesarias para que los datos tengan el formato final deseado, poniendo un ejemplo un dato en formato Avro y desea almacenarlo en BigQuery por que para su necesidad es el ideal, entonces lo que simplemente hace es extraer y cargar lo que nos indica que podemos importar datos “tal cual” en un sistema. Algunos ejemplos son la importación de data desde una Base de Datos donde el origen y el destino tienen el mismo esquema, ahora la diferencia con BigQuery es que puedes terminar no siempre cargando los datos en BigQuery pero puedes consultar fuera de ella, ahora Avro, ORC y archivos de paquetes son soportados por consultas federadas.

El segundo método para cargar los datos en la nube es el ELT (Extract Load Transform), cuando los datos cargados en el producto de la nube no son los que tienen el formato final deseado tal vez se requiera limpiarlos, o transformarlos, incluso corregirlos de alguna manera, el proceso sería extraer del sistema local, cargar la data en la nube y finalmente realizar la transformación de la data. Este proceso es idóneo cuando la cantidad de transformaciones de la data es muy baja.

El tercer método para cargar datos se denomina ETL (Extract Transform Load), en este proceso los datos extraídos se les aplica un montón de procesamiento según sus necesidades y cuando ya tenga los datos finales se procede a cargarlos en la nube, principalmente se la usa cuando se requiere transformar la data en el proceso o es indispensable la transformación de la data, como por ejemplo si usted posee los datos en forma binaria y desea subir los datos a la nube con otro formato, usted realizará una transformación de los datos antes de subirlos.

Construir un Data Lake usando Cloud Storage

Es el servicio de almacenamiento para trabajar con datos, datos no estructurados en la nube.

• Su persistencia va más allá de la duración de las máquinas virtuales.
• Es relativamente barato en comparación con el costo de la computación.
• Cloud Storage es un almacén de objetos, por lo que recupera y almacena objetos binarios sin datos contenidos en estos objetos.
• Proporciona compatibilidad de archivos y puede hacer que los objetos se vean y funcionen como si fuesen archivos dentro y fuera de ella.
• Sus datos son durables y disponibles al instante.
• Puede compartir datos globalmente, pero están cifrados y controlados.
• Tienen una latencia moderada y un alto rendimiento.

Como ejemplo que necesite que una aplicación no siempre se ejecute resulta útil guardar el estado de la aplicación en el almacenamiento de la nube y apagar la máquina.

Para saber cómo trabaja cloud storage definiremos dos entidades importantes en este campo, una son los buckets y otra son los objects

• Los buckets son contenedores de objects (datos)
• Los objects existen dentro de los buckets no fuera de ellos.
• Los buckets tienen un único nombre global, sólo si elimina el bucket el nombre queda disponible.
• Fácil localización de un bucket en particular.
• Un bucket se crea y se asocia a una región cercana donde los datos serán procesados, reduciendo la latencia.

Cuando se almacena un objeto, Cloud Storage replica el objeto, esté supervisa las réplicas y en caso de existir un error en ellas se las reemplaza con una nueva copia del objeto.

Para un bucket en varias regiones, los objects se replican en varias regiones, y en caso de tener un bucket en una sola región los objects se replican en las zonas de esa región. De esta forma se accede a la réplica más cercana y produce una baja latencia, logrando también que varios usuarios accedan a las réplicas de otras zonas diferentes teniendo así un alto rendimiento.

Los objects se almacenan con metadatos que poseen información de estos, su característica es que este hecho para fines como control de acceso, compresión, cifrado y gestión del ciclo de vida.

La ubicación del bucket se establece el momento en que se crea y no es posible cambiarla posteriormente, si se desea cambiar su ubicación se deberá copiar todo el contenido a la nueva ubicación y pagar los cargos de salida de la red, por lo tanto, se debe elegir la ubicación con cuidado esta puede ser de una sola región o también multi región todo dependerá del alcance que desea obtener si tiene usuarios en otra región en bueno tener el bucket ubicado tanto en su región como en la región de sus usuarios de interés. Otra forma de buscar la región puede ser al momento de evitar desastres naturales si usted vive en una región de desastres naturales se puede ubicar el bucket en diferentes regiones para tener un respaldo de la información en caso de cualquier daño.

Cloud Storage utiliza el nombre del bucket y el nombre del object para simular un archivo de sistema, funciona de la siguiente manera, el nombre del bucket es el primer término del URI, le sigue una barra diagonal y se concatena con el nombre del object. El nombre del object soporta el carácter” /”, logrando una similitud con una ruta del sistema que comúnmente observamos.

Por ejemplo, en nombre del bucket es “declass”, y el nombre del object es “de/modules/02/script.sh”, se puede ver que tiene la forma de directorios anidados empezando por “declass”.

Se recomienda evitar el uso de información confidencial como parte de los nombres de los buckets dado que estos están en un espacio global, además los datos de los buckets pueden mantenerse en privado.

Cloud Storage tiene muchas características de administración de objetos. Por ejemplo, se puede establecer una política de retención en todos los objetos en el depósito; los objetos deben expirar después de 30 días.

También puede usar el control de versiones, para que se rastreen varias versiones de un objeto y activarlo si es necesario. Incluso se puede configurar la administración del ciclo de vida, para automáticamente mover objetos a los que no se haya accedido en 30 días a una línea cercana y después de 90 días a una coldline.

Asegurando Cloud Storage

Cloud Storage implementa dos métodos completamente separados pero superpuestos de control de acceso a objetos. Política de Cloud IAM y listas de control de acceso. Cloud IAM es estándar en Google Cloud Platform. Se establece a nivel de cubo y se aplica reglas de acceso uniformes a todos los objetos dentro de un cubo. Las listas de control de acceso pueden ser aplicados a nivel de cubo o en objetos individuales. Por lo tanto, proporciona más grano fino en el control de acceso.

Todos los datos en Google Cloud se cifran en reposo y en tránsito. No Hay forma de encender el cifrado desactivado.

Google realiza el cifrado utilizando las claves de cifrado que administramos: Google claves de cifrado gestionadas o GMEK. Utilizamos dos niveles de cifrado: primero, los datos se cifran mediante un cifrado de datos llave. Luego, la clave de cifrado de datos se cifra utilizando una clave de cifrado de clave o KEK.

Los KEK se rotan automáticamente en un horario y el KEK actual se almacena en Cloud KMS, servicio de gestión de claves. No tienes que hacer nada, ya que este comportamiento es automático.

Si desea administrar el KEK, en Google administre la clave de cifrado, puede controlar la creación y existencia del KEK que se utiliza. Esto se denomina claves de cifrado administradas por el cliente o CMEK.

Se puede evitar Cloud KMS por completo y proporcionar su propio cifrado y mecanismo de rotación a esto se lo conoce como CSEK o claves de cifrado administradas por el cliente. La opción de encriptación de datos que use depende de la actividad comercial, legal y reglamentaria.

La cuarta opción de cifrado es el cifrado del lado del cliente, simplemente significa que ha cifrado los datos antes de que sean cargados y tiene que descifrar los datos uno mismo antes de usarlos.

Cloud Storage aún realiza el cifrado GMEK, CMEK o CSEK en el objeto. No tiene conocimiento de la capa adicional de cifrado que puede haber agregado.

Cloud Storage admite el registro de acceso de datos, y estos registros son inmutables. Además de los registros de auditoría de la nube y los registros de acceso al almacenamiento en la nubes, hay varias retenciones y bloqueos que puede colocar en los datos.

Para fines de auditoría, puede retener un objeto y todas las operaciones que podrían cambiar o eliminar el objeto se suspenden hasta que se libera la retención, también puede bloquear un depósito y no se pueden realizar cambios ni eliminaciones hasta que se libere el bloqueo.

Finalmente, existe la política de retención bloqueada discutida anteriormente. Y si sigue este permanecerá vigente y evitará la eliminación, ya sea que haya bloqueo de depósito o una retención de objetos en forzar o no.

Almacenamiento de todo tipo de datos

No se desea utilizar Cloud Storage para cargas de trabajo transaccionales. A pesar de la latencia del almacenamiento en la nube es la baja, no es lo suficientemente baja como para admitir escrituras de alta frecuencia. Para cargas de trabajo transaccionales, hay que usar Cloud SQL o Firestore dependiendo de si desea usar SQL o No-SQL.

Los sistemas de transaccionales son 80% escrituras y 20% lecturas: La razón por la que se trata estos casos de uso de manera diferente es que los sistemas transaccionales son escribir mucho. Estos tienden a ser sistemas operativos. Por ejemplo, los datos del catálogo de minorista requieren actualización cada vez que el minorista agrega un nuevo artículo o cambio el precio. Será necesario actualizar los datos del inventario cada vez que el minorista venda un artículo. Esto se debe a que los sistemas de catálogo e inventario deben mantener una instantánea del negocio.

Los sistemas analíticos son 20% de escrituras y 80% de lecturas: Los sistemas analíticos se pueden poblar periódicamente de los sistemas operativos. Se podría usar esto una vez al día para generar un informe de artículos en nuestro catálogo cuyas ventas están aumentando, pero cuyos niveles de inventario son bajos. Tal informe tendrá que leer un montón de datos, pero no tendrá que escribir mucho. Los sistemas OLAP están centrados en la lectura.

Los sistemas analíticos se pueden poblar periódicamente a partir de sistemas operativos; los ingenieros de datos construyen las tuberías para poblar el sistema OLAP desde el OLTP.

Una forma simple podría ser exportar la base de datos como un archivo y cargarla en los datos almacén. Esto se conoce como EL.

En Google Cloud, el almacén de datos tiende a ser BigQuery. Hay un límite para el tamaño de los datos que puede cargar directamente a BigQuery. Esto se debe a que su red podría ser un cuello de botella.

En lugar de cargar los datos directamente en BigQuery, puede ser mucho más conveniente primero hay que cargarlo a Cloud Storage y luego a Cloud Storage BigQuery. Esto se debe a que Cloud Storage admite cargas reanudables de subprocesos múltiples. Solo hay que proporcionar la opción -m a gsutil. La carga desde el almacenamiento en la nube también será más rápida debido al alto rendimiento que ofrece.

Una característica reciente implementada en BigQuery, es la de consultar archivos de datos en Gooogle Cloud Storage, directamente, sin necesidad de tener esos archivos en archivos locales. A esto se le conoce como consulta federada o una conexión de fuente de datos externas. Se usa en archivos CSV, Avro, Parquet y Apache ORC.

Elegir del Almacenamiento de la Nube de Datos para análisis de Workloads: En este modo la opción predeterminada es Cloud SQL, sin embargo se puede usar Cloud Spanner para una base de datos distribuida globalmente, es decir donde se ejecuten en diferentes regiones geográficas, por su capacidad y estabilidad, se puede usar True Time de Spanner, este usa Cloud SQL porque es más rentable.

BigQuery es la opción predeterminada para el análisis de Workloads. Sin embargo, es recomendable utilizar Bigtable, ya que posee un mayor rendimiento (más millones de filas por segundo). Aunque BigQuery es más rentable.

Almacenamiento de todo tipo de datos

Otro beneficio de las instancias de Cloud SQL es que son accesibles por otros servicios GCP e incluso servicios externos. Puede usar Cloud SQL con App Engine usando controladores estándar como Connector / J para Java o MySQLdb para Python. Cloud SQL también admite otras aplicaciones y herramientas a las que podría estar acostumbrado, como SQL Workbench, Toad y otras aplicaciones externas que usan controladores MySQL estándar.

Los datos del cliente de Cloud SQL se cifran cuando se encuentran en las redes internas de Google y cuando se almacenan en tablas de bases de datos, archivos temporales y copias de seguridad. Además Google gestiona las copias de seguridad.

Cloud SQL se encarga de almacenar de forma segura sus datos respaldados y le facilita la restauración desde una copia de seguridad y realizar una recuperación en un punto en el tiempo a un estado específico de una instancia.

Cloud SQL retiene hasta 7 copias de seguridad para cada instancia, que se incluye en el costo de su instancia. Esta escala hasta 64 núcleos de procesador y más de 100 GB de RAM. Horizontalmente, puede escalar rápidamente con réplicas de lectura. Google Cloud SQL admite tres escenarios de réplica de lectura:

• Instancias de Cloud SQL que se replican desde una instancia maestra de Cloud SQL
• Instancias de Cloud SQL que se replican desde una instancia maestra externa
• Instancias externas de MySQL que se replican desde un maestro de Cloud SQL

Las instancias de Cloud SQL se pueden configurar con una réplica de conmutación por error en una zona diferente en la misma región. Después, los datos de Cloud SQL se replican en zonas dentro de una región para mayor durabilidad. Todos los cambios realizados en los datos en el maestro se replican a la conmutación por error

Cuando hay una interrupción en la instancia maestra, Cloud SQL falla automáticamente en la réplica. Si el maestro tiene problemas no causados ​​por una interrupción de la zona, no se produce la conmutación por error. Pero también se puede iniciar la conmutación por error manualmente

Algunas advertencias:

1. Considerar que la réplica de conmutación por error se cobra como una instancia separada.
2. Cuando se produce una interrupción de zona y su maestro falla en su réplica de conmutación por error, se cierran las conexiones existentes a la instancia. Se puede retornar a la conexión usando la misma IP.
3. Después de la conmutación por error, la réplica se convierte en la maestra y Cloud SQL crea automáticamente una nueva réplica de conmutación por error en otra zona. Si se reconoce su instancia de Cloud SQL para estar cerca de otros recursos, se puede reubicar la instancia de Cloud SQL a su zona original cuando la zona esté disponible, sino no es necesario reubicar la instancia.

Servicios como BigQuery, Cloud Pub/Sub, Cloud Storage, no poseen servidor. Una de las cosas únicas de Google Cloud es que puede construir una tubería de procesamiento de datos de componentes bien diseñados, todos los cuales son completamente sin servidor.

Dataproc, por otro lado, está completamente administrado. Le ayuda a ejecutar cargas de trabajo de Spark y Hadoop sin tener que preocuparse por la configuración.

Cuando se debe escoger algún servicio en igualdad de condiciones, es preferible tomar el que no tiene servidor.

Autores:

• Steve Acosta
• Matías Idrobo
• Williams Ortiz
• Paúl Ramírez

Módulo 1: Data Analytics en AWS

Módulo 3: Building a Data Warehouse

Módulo 4: Procesamiento — AWS IOT CORE

Módulo 6: Serverless Data Processing with Dataflow

Conoce más: bootcampai.org/di