Este artigo é uma tradução do meu artigo sobre meio - , que se revelou bastante popular, provavelmente pela sua simplicidade. Portanto, decidi escrevê-lo em russo e acrescentar um pouco para deixar claro para uma pessoa comum que não é especialista em dados o que é um data warehouse (DW) e o que é um data lake (Data Lake) e como eles se dar bem juntos .
Por que eu quis escrever sobre o data lake? Trabalho com dados e análises há mais de 10 anos e agora estou definitivamente trabalhando com big data na Amazon Alexa AI em Cambridge, que fica em Boston, embora eu more em Victoria, na ilha de Vancouver, e visite frequentemente Boston, Seattle , e Em Vancouver, e às vezes até em Moscou, falo em conferências. Também escrevo de vez em quando, mas escrevo principalmente em inglês, e já escrevi , também preciso compartilhar tendências analíticas da América do Norte e, às vezes, escrevo em .
Sempre trabalhei com data warehouses e desde 2015 comecei a trabalhar em estreita colaboração com Amazon Web Services, e geralmente mudei para análises em nuvem (AWS, Azure, GCP). Tenho observado a evolução das soluções analíticas desde 2007 e até trabalhei para o fornecedor de data warehouse Teradata e implementei no Sberbank, e foi aí que apareceu o Big Data com Hadoop. Todos começaram a falar que a era do armazenamento havia passado e agora tudo estava no Hadoop, e então começaram a falar sobre Data Lake, de novo, que agora o fim do data warehouse havia definitivamente chegado. Mas, felizmente (talvez infelizmente para alguns que ganharam muito dinheiro configurando o Hadoop), o data warehouse não desapareceu.
Neste artigo veremos o que é um data lake. Este artigo destina-se a pessoas que têm pouca ou nenhuma experiência com data warehouses.
Na foto está o Lago Bled, esse é um dos meus lagos preferidos, embora só tenha estado lá uma vez, lembrei dele para o resto da vida. Mas falaremos sobre outro tipo de lago - um data lake. Talvez muitos de vocês já tenham ouvido falar desse termo mais de uma vez, mas mais uma definição não fará mal a ninguém.
Em primeiro lugar, aqui estão as definições mais populares de Data Lake:
“um armazenamento de arquivos de todos os tipos de dados brutos que estão disponíveis para análise por qualquer pessoa na organização” - Martin Fowler.
“Se você pensa que um data mart é uma garrafa de água – purificada, embalada e embalada para consumo conveniente, então um data lake é um enorme reservatório de água em sua forma natural. Usuários, posso coletar água para mim mesmo, mergulhar fundo, explorar” - James Dixon.
Agora sabemos com certeza que um data lake tem a ver com análise, permite-nos armazenar grandes quantidades de dados na sua forma original e temos o acesso necessário e conveniente aos dados.
Muitas vezes gosto de simplificar as coisas, se consigo explicar um termo complexo em palavras simples, então entendo por mim mesmo como funciona e para que é necessário. Um dia, eu estava fuçando na galeria de fotos do iPhone e me dei conta, este é um verdadeiro data lake, até fiz um slide para conferências:
Tudo é muito simples. Tiramos uma foto no telefone, a foto fica salva no telefone e pode ser salva no iCloud (armazenamento de arquivos na nuvem). O telefone também coleta metadados de fotos: o que é mostrado, geo tag, hora. Com isso, podemos usar a interface amigável do iPhone para encontrar nossa foto e até vemos indicadores, por exemplo, quando procuro fotos com a palavra fogo, encontro 3 fotos com imagem de incêndio. Para mim, é como uma ferramenta de Business Intelligence que funciona com muita rapidez e precisão.
E claro, não devemos esquecer da segurança (autorização e autenticação), caso contrário os nossos dados podem facilmente acabar no domínio público. Há muitas notícias sobre grandes corporações e startups cujos dados se tornaram disponíveis publicamente devido à negligência dos desenvolvedores e ao não cumprimento de regras simples.
Mesmo uma imagem tão simples nos ajuda a imaginar o que é um data lake, suas diferenças em relação a um data warehouse tradicional e seus principais elementos:
- Carregando dados (Ingestão) é um componente chave do data lake. Os dados podem entrar no data warehouse de duas maneiras – lote (carregamento em intervalos) e streaming (fluxo de dados).
- Armazenamento de arquivo (Armazenamento) é o principal componente do Data Lake. Precisávamos que o armazenamento fosse facilmente escalonável, extremamente confiável e de baixo custo. Por exemplo, na AWS é S3.
- Catálogo e Pesquisa (Catálogo e Pesquisa) - para evitarmos o Data Swamp (é quando despejamos todos os dados em uma pilha e fica impossível trabalhar com eles), precisamos criar uma camada de metadados para classificar os dados para que os usuários possam encontrar facilmente os dados necessários para análise. Além disso, você pode usar soluções de pesquisa adicionais, como ElasticSearch. A pesquisa ajuda o usuário a encontrar os dados necessários por meio de uma interface amigável.
- Processamento (Processo) – esta etapa é responsável por processar e transformar os dados. Podemos transformar dados, alterar sua estrutura, limpá-los e muito mais.
- segurança (Segurança) - É importante dedicar tempo ao design de segurança da solução. Por exemplo, criptografia de dados durante armazenamento, processamento e carregamento. É importante usar métodos de autenticação e autorização. Finalmente, é necessária uma ferramenta de auditoria.
Do ponto de vista prático, podemos caracterizar um data lake por três atributos:
- Colete e armazene qualquer coisa — o data lake contém todos os dados, tanto dados brutos não processados para qualquer período de tempo quanto dados processados/limpos.
- Varredura profunda — um data lake permite aos usuários explorar e analisar dados.
- Acesso flexível — O data lake fornece acesso flexível para diferentes dados e diferentes cenários.
Agora podemos falar sobre a diferença entre um data warehouse e um data lake. Geralmente as pessoas perguntam:
- E o armazém de dados?
- Estamos substituindo o data warehouse por um data lake ou estamos expandindo-o?
- Ainda é possível viver sem um data lake?
Em suma, não há uma resposta clara. Tudo depende da situação específica, das competências da equipa e do orçamento. Por exemplo, migrar um data warehouse de Oracle para AWS e criar um data lake por uma subsidiária da Amazon - Woot - .
Por outro lado, o fornecedor Snowflake diz que não é mais necessário pensar em um data lake, pois sua plataforma de dados (até 2020 era um data warehouse) permite combinar um data lake e um data warehouse. Não trabalhei muito com Snowflake e é realmente um produto único que pode fazer isso. O preço da emissão é outra questão.
Concluindo, minha opinião pessoal é que ainda precisamos de um data warehouse como principal fonte de dados para nossos relatórios, e tudo o que não couber, armazenamos em um data lake. Todo o papel da análise é fornecer acesso fácil para as empresas tomarem decisões. O que quer que se diga, os usuários empresariais trabalham de forma mais eficiente com um data warehouse do que com um data lake, por exemplo, na Amazon - existe o Redshift (data warehouse analítico) e existe o Redshift Spectrum/Athena (interface SQL para um data lake em S3 baseado em Colmeia/Presto). O mesmo se aplica a outros data warehouses analíticos modernos.
Vejamos uma arquitetura típica de data warehouse:
Esta é uma solução clássica. Temos sistemas de origem, usando ETL/ELT copiamos os dados para um data warehouse analítico e conectamos a uma solução de Business Intelligence (o meu preferido é o Tableau, e o seu?).
Esta solução tem as seguintes desvantagens:
- As operações ETL/ELT requerem tempo e recursos.
- Via de regra, a memória para armazenar dados em um data warehouse analítico não é barata (por exemplo, Redshift, BigQuery, Teradata), pois precisamos comprar um cluster inteiro.
- Os usuários empresariais têm acesso a dados limpos e frequentemente agregados e não têm acesso a dados brutos.
Claro, tudo depende do seu caso. Se você não tiver problemas com seu data warehouse, então não precisará de um data lake. Mas quando surgem problemas com falta de espaço, energia ou o preço desempenha um papel fundamental, então você pode considerar a opção de um data lake. É por isso que o data lake é muito popular. Aqui está um exemplo de arquitetura de data lake:
Usando a abordagem de data lake, carregamos dados brutos em nosso data lake (lote ou streaming) e, em seguida, processamos os dados conforme necessário. O data lake permite que os usuários empresariais criem suas próprias transformações de dados (ETL/ELT) ou analisem dados em soluções de Business Intelligence (se o driver necessário estiver disponível).
O objetivo de qualquer solução analítica é atender aos usuários empresariais. Portanto, devemos trabalhar sempre de acordo com as exigências do negócio. (Na Amazon este é um dos princípios – trabalhar de trás para frente).
Trabalhando tanto com um data warehouse quanto com um data lake, podemos comparar as duas soluções:
A principal conclusão que se pode tirar é que o data warehouse não compete com o data lake, mas sim o complementa. Mas cabe a você decidir o que é certo para o seu caso. É sempre interessante experimentar você mesmo e tirar as conclusões certas.
Gostaria também de contar um dos casos em que comecei a usar a abordagem de data lake. Tudo é bastante trivial, tentei usar uma ferramenta ELT (tínhamos Matillion ETL) e Amazon Redshift, minha solução funcionou, mas não atendeu aos requisitos.
Eu precisava pegar logs da web, transformá-los e agregá-los para fornecer dados para 2 casos:
- A equipe de marketing queria analisar a atividade do bot para SEO
- A TI queria analisar as métricas de desempenho do site
Registros muito simples, muito simples. Aqui está um 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" "-" "-"Um arquivo pesava de 1 a 4 megabytes.
Mas havia uma dificuldade. Tínhamos 7 domínios em todo o mundo e 7000 mil arquivos foram criados em um dia. Não é muito mais volume, apenas 50 gigabytes. Mas o tamanho do nosso cluster Redshift também era pequeno (4 nós). Carregar um arquivo da maneira tradicional demorou cerca de um minuto. Ou seja, o problema não foi resolvido de frente. E foi esse o caso quando decidi usar a abordagem de data lake. A solução ficou mais ou menos assim:
É bastante simples (quero ressaltar que a vantagem de trabalhar na nuvem é a simplicidade). Eu usei:
- AWS Elastic Map Reduce (Hadoop) para poder computacional
- AWS S3 como armazenamento de arquivos com capacidade de criptografar dados e limitar o acesso
- Spark como poder de computação InMemory e PySpark para transformação lógica e de dados
- Parquet como resultado de Spark
- AWS Glue Crawler como coletor de metadados sobre novos dados e partições
- Redshift Spectrum como uma interface SQL para o data lake para usuários existentes do Redshift
O menor cluster EMR+Spark processou toda a pilha de arquivos em 30 minutos. Existem outros casos da AWS, principalmente muitos relacionados à Alexa, onde há muitos dados.
Recentemente, aprendi que uma das desvantagens de um data lake é o GDPR. O problema é quando o cliente pede para excluí-lo e os dados estão em um dos arquivos, não podemos utilizar a Linguagem de Manipulação de Dados e a operação DELETE como em um banco de dados.
Espero que este artigo tenha esclarecido a diferença entre um data warehouse e um data lake. Se você estiver interessado, posso traduzir mais artigos meus ou artigos de profissionais que li. E também contar sobre as soluções com as quais trabalho e sua arquitetura.
Fonte: habr.com