Este artigo é unha tradución do meu artigo sobre medio - , que resultou ser bastante popular, probablemente pola súa sinxeleza. Polo tanto, decidín escribilo en ruso e engadir un pouco para deixar claro a unha persoa común que non é un especialista en datos o que é un almacén de datos (DW) e o que é un lago de datos (Data Lake) e como levarse ben xuntos.
Por que quería escribir sobre o lago de datos? Levo máis de 10 anos traballando con datos e analíticas, e agora definitivamente estou traballando con big data en Amazon Alexa AI en Cambridge, que está en Boston, aínda que vivo en Victoria, na illa de Vancouver e adoita visitar Boston, Seattle. , e en Vancouver, e ás veces mesmo en Moscova, falo en conferencias. Tamén escribo de cando en vez, pero escribo principalmente en inglés, e xa o teño escrito , Tamén teño a necesidade de compartir as tendencias de análise de América do Norte e ás veces escribo .
Sempre traballei con almacéns de datos e, desde 2015, comecei a traballar en estreita colaboración con Amazon Web Services, e en xeral cambiei a analítica na nube (AWS, Azure, GCP). Observei a evolución das solucións de análise desde 2007 e mesmo traballei para o provedor de almacén de datos Teradata e implementei en Sberbank, e foi entón cando apareceron Big Data con Hadoop. Todo o mundo comezou a dicir que a era do almacenamento xa pasou e agora todo estaba en Hadoop, e entón comezaron a falar de Data Lake, de novo, que agora o fin do almacén de datos chegara definitivamente. Pero afortunadamente (quizais por desgraza para algúns que gañaron moito diñeiro configurando Hadoop), o almacén de datos non desapareceu.
Neste artigo veremos o que é un lago de datos. Este artigo está destinado a persoas que teñen pouca ou ningunha experiencia cos almacéns de datos.
Na imaxe está o lago Bled, este é un dos meus lagos favoritos, aínda que só estiven alí unha vez, lembreino o resto da miña vida. Pero falaremos doutro tipo de lago: un lago de datos. Quizais moitos de vós xa escoitades falar deste termo máis dunha vez, pero unha definición máis non prexudicará a ninguén.
En primeiro lugar, aquí están as definicións máis populares de Data Lake:
"un ficheiro de almacenamento de todo tipo de datos brutos que está dispoñible para a súa análise por calquera persoa da organización" - Martin Fowler.
"Se pensas que un data mart é unha botella de auga, purificada, envasada e envasada para un consumo cómodo, entón un data lake é un enorme depósito de auga na súa forma natural. Usuarios, podo recoller auga para min, mergullarme profundamente, explorar" - James Dixon.
Agora sabemos con certeza que un data lake trata de analítica, permítenos almacenar grandes cantidades de datos na súa forma orixinal e temos o acceso necesario e cómodo aos datos.
Moitas veces gústame simplificar as cousas, se podo explicar un termo complexo con palabras sinxelas, entón entendo por min mesmo como funciona e para que é necesario. Un día, estaba mirando pola galería de fotos do iPhone, e entendín que este é un auténtico data lake, ata fixen unha diapositiva para conferencias:
Todo é moi sinxelo. Facemos unha foto no teléfono, a foto gárdase no teléfono e pódese gardar en iCloud (almacenamento de ficheiros na nube). O teléfono tamén recolle metadatos de fotos: que se mostra, etiqueta xeográfica, hora. Como resultado, podemos usar a interface amigable do iPhone para atopar a nosa foto e incluso vemos indicadores, por exemplo, cando busco fotos coa palabra lume, atopo 3 fotos cunha imaxe de lume. Para min, isto é como unha ferramenta de Business Intelligence que funciona de forma moi rápida e clara.
E por suposto, non debemos esquecernos da seguridade (autorización e autenticación), se non, os nosos datos poden acabar facilmente no dominio público. Hai moitas noticias sobre grandes corporacións e startups cuxos datos quedaron dispoñibles públicamente debido á neglixencia dos desenvolvedores e ao incumprimento de regras sinxelas.
Incluso unha imaxe tan sinxela axúdanos a imaxinar o que é un data lake, as súas diferenzas con respecto a un data warehouse tradicional e os seus elementos principais:
- Cargando datos (Inxestión) é un compoñente clave do lago de datos. Os datos poden entrar no almacén de datos de dúas formas: por lotes (carga a intervalos) e transmisión (fluxo de datos).
- Almacenamento de ficheiros (Almacenamento) é o principal compoñente do Data Lake. Necesitabamos que o almacenamento fose facilmente escalable, extremadamente fiable e de baixo custo. Por exemplo, en AWS é S3.
- Catálogo e busca (Catálogo e busca): para evitar o pantano de datos (é cando botamos todos os datos nunha pila, e despois é imposible traballar con el), necesitamos crear unha capa de metadatos para clasificar os datos. para que os usuarios poidan atopar facilmente os datos que necesitan para a súa análise. Ademais, pode usar solucións de busca adicionais como ElasticSearch. A busca axuda ao usuario a atopar os datos necesarios a través dunha interface amigable.
- Procesamento (Proceso): este paso é responsable do procesamento e transformación dos datos. Podemos transformar datos, cambiar a súa estrutura, limpalos e moito máis.
- Безопасность (Seguridade) - É importante dedicar tempo ao deseño de seguridade da solución. Por exemplo, o cifrado de datos durante o almacenamento, o procesamento e a carga. É importante utilizar métodos de autenticación e autorización. Finalmente, é necesaria unha ferramenta de auditoría.
Desde un punto de vista práctico, podemos caracterizar un lago de datos por tres atributos:
- Recolle e almacena calquera cousa — o lago de datos contén todos os datos, tanto datos en bruto sen procesar durante calquera período de tempo como datos procesados/limpados.
- Escaneo profundo — un lago de datos permite aos usuarios explorar e analizar datos.
- Acceso flexible — O lago de datos ofrece un acceso flexible para diferentes datos e diferentes escenarios.
Agora podemos falar da diferenza entre un data warehouse e un data lake. Normalmente a xente pregunta:
- E o almacén de datos?
- ¿Estamos substituíndo o data warehouse por un data lake ou estamos ampliando?
- Aínda é posible prescindir dun lago de datos?
En resumo, non hai unha resposta clara. Todo depende da situación concreta, das habilidades do equipo e do orzamento. Por exemplo, migrar un almacén de datos a Oracle a AWS e crear un lago de datos por parte dunha subsidiaria de Amazon - Woot - .
Por outra banda, o vendedor Snowflake di que xa non é necesario pensar nun data lake, xa que a súa plataforma de datos (ata 2020 era un data warehouse) permite combinar tanto un data lake como un data warehouse. Non traballei moito con Snowflake, e é realmente un produto único que pode facelo. O prezo do tema é outra cuestión.
En conclusión, a miña opinión persoal é que aínda necesitamos un almacén de datos como fonte principal de datos para os nosos informes, e o que non encaixa almacenamos nun lago de datos. Todo o papel da analítica é proporcionar un acceso sinxelo ás empresas para tomar decisións. Diga o que se diga, os usuarios empresariais traballan de forma máis eficiente cun data warehouse que cun data lake, por exemplo en Amazon: hai Redshift (almacén de datos analíticos) e Redshift Spectrum/Athena (interface SQL para un data lake en S3 baseado en Hive/Presto). O mesmo aplícase a outros almacéns de datos analíticos modernos.
Vexamos unha arquitectura típica de almacén de datos:
Esta é unha solución clásica. Temos sistemas fonte, usando ETL/ELT copiamos datos nun almacén de datos analíticos e conectámolos a unha solución de Business Intelligence (o meu favorito é Tableau, e o teu?).
Esta solución ten as seguintes desvantaxes:
- As operacións ETL/ELT requiren tempo e recursos.
- Como regra xeral, a memoria para almacenar datos nun almacén de datos analíticos non é barata (por exemplo, Redshift, BigQuery, Teradata), xa que necesitamos mercar un clúster completo.
- Os usuarios empresariais teñen acceso a datos limpos e moitas veces agregados e non teñen acceso a datos brutos.
Por suposto, todo depende do teu caso. Se non tes problemas co teu almacén de datos, non necesitas ningún data lake. Pero cando xorden problemas coa falta de espazo, enerxía ou prezo xoga un papel fundamental, podes considerar a opción dun lago de datos. É por iso que o lago de datos é moi popular. Aquí tes un exemplo dunha arquitectura de lago de datos:
Usando o enfoque do lago de datos, cargamos datos en bruto no noso lago de datos (por lotes ou en streaming) e despois procesamos os datos segundo sexa necesario. O lago de datos permite aos usuarios empresariais crear as súas propias transformacións de datos (ETL/ELT) ou analizar datos en solucións de Business Intelligence (se o controlador necesario está dispoñible).
O obxectivo de calquera solución de análise é servir aos usuarios empresariais. Polo tanto, debemos traballar sempre segundo os requisitos empresariais. (En Amazon este é un dos principios: traballar cara atrás).
Traballando tanto cun almacén de datos como cun lago de datos, podemos comparar ambas solucións:
A principal conclusión que se pode extraer é que o data warehouse non compite co data lake, senón que o complementa. Pero depende de ti decidir o que é o adecuado para o teu caso. Sempre é interesante probalo vostede mesmo e sacar as conclusións correctas.
Tamén me gustaría contarvos un dos casos nos que comecei a utilizar o enfoque do lago de datos. Todo é bastante trivial, tentei usar unha ferramenta ELT (tiñamos Matillion ETL) e Amazon Redshift, a miña solución funcionou, pero non cumpría cos requisitos.
Necesitaba tomar rexistros web, transformalos e agregalos para proporcionar datos de 2 casos:
- O equipo de marketing quería analizar a actividade do bot para o SEO
- TI quería analizar as métricas de rendemento do sitio web
Rexistros moi sinxelos, moi sinxelos. Aquí tes un exemplo:
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 ficheiro pesaba entre 1 e 4 megabytes.
Pero había unha dificultade. Tiñamos 7 dominios en todo o mundo e creáronse 7000 mil ficheiros nun día. Isto non é moito máis volume, só 50 gigabytes. Pero o tamaño do noso clúster Redshift tamén era pequeno (4 nodos). A carga dun ficheiro da forma tradicional levou aproximadamente un minuto. É dicir, o problema non se resolveu frontalmente. E este foi o caso cando decidín utilizar o enfoque do lago de datos. A solución parecía algo así:
É bastante sinxelo (quero notar que a vantaxe de traballar na nube é a sinxeleza). usei:
- AWS Elastic Map Reduce (Hadoop) para potencia informática
- AWS S3 como almacenamento de ficheiros coa capacidade de cifrar datos e limitar o acceso
- Spark como potencia informática InMemory e PySpark para a transformación de lóxica e datos
- Parquet como resultado de Spark
- AWS Glue Crawler como recopilador de metadatos sobre novos datos e particións
- Redshift Spectrum como interface SQL para o lago de datos para os usuarios existentes de Redshift
O clúster EMR+Spark máis pequeno procesou toda a pila de ficheiros en 30 minutos. Hai outros casos para AWS, especialmente moitos relacionados con Alexa, onde hai moitos datos.
Hai pouco aprendín que unha das desvantaxes dun lago de datos é o GDPR. O problema é cando o cliente pide borralo e os datos están nun dos ficheiros, non podemos usar a linguaxe de manipulación de datos e a operación DELETE como nunha base de datos.
Espero que este artigo aclarase a diferenza entre un data warehouse e un data lake. Se che interesa, podo traducir máis artigos meus ou artigos de profesionais que lin. E tamén falar das solucións coas que traballo e da súa arquitectura.
Fonte: www.habr.com