¿Necesitamos un lago de datos? ¿Qué hacer con el almacén de datos?

Este artículo es una traducción de mi artículo sobre medio. Introducción al lago de datos, que resultó ser bastante popular, probablemente por su sencillez. Por lo tanto, decidí escribirlo en ruso y agregar un poco para dejarle claro a una persona común y corriente que no sea un especialista en datos qué es un almacén de datos (DW), qué es un lago de datos (Data Lake) y cómo llevarse bien juntos.

¿Por qué quería escribir sobre el lago de datos? He estado trabajando con datos y análisis durante más de 10 años, y ahora definitivamente estoy trabajando con big data en Amazon Alexa AI en Cambridge, que está en Boston, aunque vivo en Victoria en la isla de Vancouver y visito con frecuencia Boston, Seattle. , y en Vancouver, y a veces incluso en Moscú, doy conferencias. También escribo de vez en cuando, pero escribo principalmente en inglés y ya he escrito algunos libros, También necesito compartir tendencias analíticas de América del Norte y, a veces, escribo en telegrama.

Siempre he trabajado con almacenes de datos y desde 2015 comencé a trabajar en estrecha colaboración con Amazon Web Services y, en general, cambié a análisis en la nube (AWS, Azure, GCP). He observado la evolución de las soluciones de análisis desde 2007 e incluso trabajé para el proveedor de almacenamiento de datos Teradata y lo implementé en Sberbank, y fue entonces cuando apareció Big Data con Hadoop. Todos empezaron a decir que la era del almacenamiento había pasado y ahora todo estaba en Hadoop, y luego empezaron a hablar de Data Lake, nuevamente, que ahora definitivamente había llegado el fin del almacén de datos. Pero afortunadamente (tal vez desafortunadamente para algunos que ganaron mucho dinero configurando Hadoop), el almacén de datos no desapareció.

En este artículo veremos qué es un lago de datos. Este artículo está dirigido a personas que tienen poca o ninguna experiencia con almacenes de datos.

En la foto está el Lago Bled, este es uno de mis lagos favoritos, aunque estuve allí solo una vez, lo recordaré por el resto de mi vida. Pero hablaremos de otro tipo de lago: el lago de datos. Quizás muchos de ustedes ya hayan oído hablar de este término más de una vez, pero una definición más no hará daño a nadie.

En primer lugar, estas son las definiciones más populares de Data Lake:

“un almacenamiento de archivos de todo tipo de datos sin procesar que está disponible para que cualquier miembro de la organización pueda analizarlo” - Martin Fowler.

“Si cree que un data mart es una botella de agua, purificada, envasada y envasada para un consumo conveniente, entonces un lago de datos es una enorme reserva de agua en su forma natural. Usuarios, puedo recoger agua para mí, bucear profundamente y explorar” - James Dixon.

Ahora sabemos con certeza que un lago de datos se trata de análisis, nos permite almacenar grandes cantidades de datos en su forma original y tenemos el acceso necesario y conveniente a los datos.

A menudo me gusta simplificar las cosas, si puedo explicar un término complejo con palabras sencillas, entonces entiendo por mí mismo cómo funciona y para qué sirve. Un día estaba husmeando en la galería de fotos del iPhone y me di cuenta de que esto es un verdadero lago de datos, incluso hice una diapositiva para conferencias:

Todo es muy sencillo. Tomamos una foto en el teléfono, la foto se guarda en el teléfono y se puede guardar en iCloud (almacenamiento de archivos en la nube). El teléfono también recopila metadatos de las fotografías: lo que se muestra, etiqueta geográfica, hora. Como resultado, podemos usar la interfaz fácil de usar del iPhone para encontrar nuestra foto e incluso vemos indicadores, por ejemplo, cuando busco fotos con la palabra fuego, encuentro 3 fotos con la imagen de un incendio. Para mí, esto es como una herramienta de Business Intelligence que funciona de forma muy rápida y clara.

Y por supuesto, no debemos olvidarnos de la seguridad (autorización y autenticación), de lo contrario nuestros datos pueden acabar fácilmente en el dominio público. Hay muchas noticias sobre grandes corporaciones y nuevas empresas cuyos datos se hicieron públicos debido a la negligencia de los desarrolladores y al incumplimiento de reglas simples.

Incluso una imagen tan simple nos ayuda a imaginar qué es un lago de datos, sus diferencias con un almacén de datos tradicional y sus elementos principales:

1. Cargando datos (Ingestión) es un componente clave del lago de datos. Los datos pueden ingresar al almacén de datos de dos maneras: por lotes (cargando a intervalos) y por transmisión (flujo de datos).
2. Almacenamiento de archivos (Almacenamiento) es el componente principal del Data Lake. Necesitábamos que el almacenamiento fuera fácilmente escalable, extremadamente confiable y de bajo costo. Por ejemplo, en AWS es S3.
3. Catálogo y búsqueda (Catálogo y búsqueda): para que podamos evitar el pantano de datos (esto es cuando volcamos todos los datos en una pila y luego es imposible trabajar con ellos), necesitamos crear una capa de metadatos para clasificar los datos. para que los usuarios puedan encontrar fácilmente los datos que necesitan para el análisis. Además, puede utilizar soluciones de búsqueda adicionales como ElasticSearch. La búsqueda ayuda al usuario a encontrar los datos requeridos a través de una interfaz fácil de usar.
4. transformación (Proceso): este paso es responsable de procesar y transformar datos. Podemos transformar datos, cambiar su estructura, limpiarlos y mucho más.
5. seguridad (Seguridad): es importante dedicar tiempo al diseño de seguridad de la solución. Por ejemplo, cifrado de datos durante el almacenamiento, procesamiento y carga. Es importante utilizar métodos de autenticación y autorización. Por último, se necesita una herramienta de auditoría.

Desde un punto de vista práctico, podemos caracterizar un lago de datos por tres atributos:

1. Recoge y almacena cualquier cosa. — el lago de datos contiene todos los datos, tanto los datos sin procesar sin procesar durante cualquier período de tiempo como los datos procesados/limpiados.
2. Análisis en profundidad — un lago de datos permite a los usuarios explorar y analizar datos.
3. Acceso flexible — El lago de datos proporciona acceso flexible a diferentes datos y diferentes escenarios.

Ahora podemos hablar de la diferencia entre un almacén de datos y un lago de datos. Normalmente la gente pregunta:

• ¿Qué pasa con el almacén de datos?
• ¿Estamos reemplazando el almacén de datos por un lago de datos o lo estamos ampliando?
• ¿Es posible todavía prescindir de un lago de datos?

En resumen, no hay una respuesta clara. Todo depende de la situación específica, las habilidades del equipo y el presupuesto. Por ejemplo, migrar un almacén de datos de Oracle a AWS y crear un lago de datos por parte de una filial de Amazon - Woot - Nuestra historia del lago de datos: cómo Woot.com creó un lago de datos sin servidor en AWS.

Por otro lado, el proveedor Snowflake dice que ya no es necesario pensar en un lago de datos, ya que su plataforma de datos (hasta 2020 era un almacén de datos) permite combinar tanto un lago de datos como un almacén de datos. No he trabajado mucho con Snowflake y es verdaderamente un producto único que puede hacer esto. El precio de la emisión es otro asunto.

En conclusión, mi opinión personal es que todavía necesitamos un almacén de datos como fuente principal de datos para nuestros informes, y todo lo que no encaja lo almacenamos en un lago de datos. La función principal de la analítica es proporcionar un fácil acceso para que las empresas tomen decisiones. Digan lo que digan, los usuarios empresariales trabajan de manera más eficiente con un almacén de datos que con un lago de datos, por ejemplo en Amazon: existe Redshift (almacén de datos analíticos) y Redshift Spectrum/Athena (interfaz SQL para un lago de datos en S3 basado en Colmena/Presto). Lo mismo se aplica a otros almacenes de datos analíticos modernos.

Veamos una arquitectura típica de almacén de datos:

Esta es una solución clásica. Tenemos sistemas fuente, usando ETL/ELT copiamos datos en un almacén de datos analíticos y los conectamos a una solución de Business Intelligence (mi favorito es Tableau, ¿y el tuyo?).

Esta solución tiene las siguientes desventajas:

• Las operaciones ETL/ELT requieren tiempo y recursos.
• Como regla general, la memoria para almacenar datos en un almacén de datos analíticos no es barata (por ejemplo, Redshift, BigQuery, Teradata), ya que necesitamos comprar un clúster completo.
• Los usuarios empresariales tienen acceso a datos limpios y, a menudo, agregados, y no tienen acceso a datos sin procesar.

Por supuesto, todo depende de tu caso. Si no tiene problemas con su almacén de datos, entonces no necesita ningún lago de datos. Pero cuando surgen problemas por la falta de espacio, la potencia o el precio juega un papel clave, entonces se puede considerar la opción de un lago de datos. Por eso el lago de datos es tan popular. A continuación se muestra un ejemplo de una arquitectura de lago de datos:

Utilizando el enfoque del lago de datos, cargamos datos sin procesar en nuestro lago de datos (por lotes o en streaming) y luego procesamos los datos según sea necesario. El lago de datos permite a los usuarios empresariales crear sus propias transformaciones de datos (ETL/ELT) o analizar datos en soluciones de Business Intelligence (si el controlador necesario está disponible).

El objetivo de cualquier solución de análisis es servir a los usuarios empresariales. Por lo tanto, siempre debemos trabajar de acuerdo con los requisitos del negocio. (En Amazon este es uno de los principios: trabajar al revés).

Trabajando tanto con un almacén de datos como con un lago de datos, podemos comparar ambas soluciones:

La principal conclusión que se puede sacar es que el data warehouse no compite con el data lake, sino que lo complementa. Pero depende de usted decidir qué es lo correcto para su caso. Siempre es interesante probarlo uno mismo y sacar las conclusiones correctas.

También me gustaría contarles uno de los casos en los que comencé a utilizar el enfoque del lago de datos. Todo es bastante trivial, intenté usar una herramienta ELT (teníamos Matillion ETL) y Amazon Redshift, mi solución funcionó, pero no cumplía con los requisitos.

Necesitaba tomar registros web, transformarlos y agregarlos para proporcionar datos para 2 casos:

1. El equipo de marketing quería analizar la actividad de los bots para SEO.
2. TI quería analizar las métricas de rendimiento del sitio web

Registros muy simples, muy simples. He aquí un ejemplo:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Un archivo pesaba entre 1 y 4 megabytes.

Pero hubo una dificultad. Teníamos 7 dominios en todo el mundo y se crearon 7000 mil archivos en un día. No es mucho más volumen, sólo 50 gigabytes. Pero el tamaño de nuestro grupo Redshift también era pequeño (4 nodos). Cargar un archivo de la forma tradicional tomó aproximadamente un minuto. Es decir, el problema no se resolvió de frente. Y este fue el caso cuando decidí utilizar el enfoque del lago de datos. La solución se parecía a esto:

Es bastante sencillo (quiero señalar que la ventaja de trabajar en la nube es la sencillez). Solía:

• AWS Elastic Map Reduce (Hadoop) para potencia informática
• AWS S3 como almacenamiento de archivos con capacidad de cifrar datos y limitar el acceso
• Spark como potencia informática de InMemory y PySpark para la lógica y la transformación de datos
• Parquet como resultado de Spark.
• AWS Glue Crawler como recopilador de metadatos sobre nuevos datos y particiones
• Redshift Spectrum como interfaz SQL para el lago de datos para usuarios existentes de Redshift

El clúster EMR+Spark más pequeño procesó toda la pila de archivos en 30 minutos. Hay otros casos de AWS, especialmente muchos relacionados con Alexa, donde hay muchos datos.

Recientemente me enteré de que una de las desventajas de un lago de datos es el RGPD. El problema es que cuando el cliente solicita eliminarlo y los datos están en uno de los archivos, no podemos usar el lenguaje de manipulación de datos y la operación ELIMINAR como en una base de datos.

Espero que este artículo haya aclarado la diferencia entre un almacén de datos y un lago de datos. Si estaba interesado, puedo traducir más de mis artículos o artículos de profesionales que leo. Y también hablar sobre las soluciones con las que trabajo y su arquitectura.

Fuente: habr.com