O Guia (semi) definitivo para Data Lakes
5 coisas que ninguém te conta sobre Projetos e Estruturação de Data Lakes.
Menos buzzword que Big Data, porém muito menos abstrato também, o conceito de Data Lake ainda se perde em muitas definições diferentes. Não é pra menos! Toda tecnologia nova demora um tempo até que pesquisadores e especialistas entrem num consenso de até onde vai cada conceito.
Com pouca prática e pouco entendimento de áreas correlatas à Nuvem, como Governança e Processos de Ciência de Dados e Práticas de Dev/DataOps, muita gente está perdida quando o assunto é Data Lake
Nesse artigo, vou passar por 5 pontos que são sempre negligenciados em projetos de estruturação de Data Lakes, seja por ignorância ou por “falta de tempo/recursos” e ainda te dar dicas do que não esquecer pra não fazer do seu Lake um Data Swamp!
Se você tá sem tempo, vá direto para a última dica. Vale a pena :)
1. Que Data Lake não é só storage!
Sempre que se fala em Data Lake, a primeira coisa que vem a cabeça é Storage pra segurar uma montanha de dados de forma barata e de simples acesso. Mas não é só isso…
Como a figura mostra, há diversas camadas a serem escaladas nessa montanha até o tão sonhado topo: Decision Making!
Atualmente temos diversas ferramentas que trabalham bem o topo da pirâmide. Mas e a base? O que fazer com essa área que é essencialmente onde se tem todo volume de dados para exploração?
Para se manter bem organizada a base da pirâmide, a solução de storage não é suficiente. Como mostro mais abaixo, Governança e Catálogo são essenciais para se manter Data Lake explorável pelos Analistas e Cientistas de Dados.
Não só isso: há de se ter, ao menos, uma noção de quais ferramentas são ideais para o consumo desse Storage, quais serão as camadas de transição de dados antes mesmo da implementação do projeto do Lake.
2. Que segurança é mais difícil em um Data Lake!
Quando falamos de SGBDs ou de Data Warehouses, estamos seguros. Há anos tais ferramentas vem sendo massivamente utilizadas em aplicações críticas: desde Instituições Financeiras até Sistemas de Tráfego Aéreo. E quando falo “segurança” estou falando de Acesso, Autenticidade e Confidencialidade até Resiliência e Recuperação de Desastres.
Contudo em um Data Lake, mais especificamente nas camadas de Storage do Lake comumente utilizadas, como Hadoop, S3 e GFS, nada disso vem junto.
Cabe a você, como Arquiteto e/ou Engenheiro agregar e programar ferramentas para fazê-lo. Para Hadoop, por exemplo, temos o Apache Ranger. Já no S3, deve-se dominar o IAM para controlar as policies de acesso a cada um dos buckets.
Quais os princípios que devo levar em conta para Segurança em Data Lakes?
- TODO acesso ao Lake, leitura, escrita e deleção, deve ser logado em trilhas de auditoria.
No S3 é algo muito simples, só habilitar nas configurações do bucket. No Hadoop isso é possível pelo Apache Ranger.
- TODO usuário deve ser de um Grupo, com políticas de acesso mínimas necessárias
Novamente: não tem isso plug’n’play nem no S3. Você deve controlar as políticas de acesso via AWS IAM.
- TODOS os dados devem ser criptografados, desde o envio, trânsito até o repouso.
Lembre-se que um storage distribuído não te dá garantia alguma de que alguém possa, por ventura, espetar um pendrive no rack do Data Center e pegar parte de seus dados de lá. Criptografe seus dados! No S3, basta habilitar nas configurações do bucket. Para envio e exposição de dados, use sempre HTTPS com autenticação ou outro mecanismo mais seguro.
- TODAS credenciais de acesso devem ser temporárias.
Nada de dar uma API Key eterna pra um Cientista de Dados acessar um — ou pior, todos eles ¬¬’ — bucket. Sempre rotacione as chaves ou use um serviço de Secret Management (também conhecido em português como Cofre de Senhas), como o Vault ou o AWS STS para gerenciar credenciais de acesso temporária, tanto ao Lake, quanto aos serviços de consumo, como Streams e APIs.
3. Que Governança e Catálogo são as chaves para o sucesso!
A maior característica de um Data Swamp é falta de Catálogo dos Dados. Ninguém sabe qual dado é aquele, de quanto em quanto tempo ele é atualizado, qual a definição de negócio e sua política de acesso e ciclo de vida. Pior ainda é quando não há nem a Governança deste dado: o dado fica lá, jogado, muitas vezes misturado com outros que não fazem parte daquele domínio… um caos!
Quais os princípios que devo levar em conta para Governança/Catálogo?
- Crie diferentes políticas de cíclo de vida para seus dados
Dados Raw e da Landing Zone nem sempre são de consumo frequente. Desta forma, você deve implementar um Ciclo de Vida automático para seus dados, de forma a diminuir (ainda mais) seus custos com Storage. Isso é facilmente configurado no Amazon S3, via Lifecycle Policies. O ideal é que essas políticas sejam padronizadas para cada uma das Áreas do Lake, dependendo do seu Use Case.
- Mantenha o Data Lineage de todos dados que passam pelo Lake
O dado no Lake transita pela pirâmide mostrada lá no início do post até entregar valor para alguém. Para manter a característica de Single Source of Truth, você deve ser capaz de rastrear cada linha do seu relatório até a sua chegada, na Landing Zone ou no Raw Data.
Ferramentas como Airflow, Dremio (na versão enterprise) e Apache NiFi mantem esse Linhagem. Na AWS, somente se você usar o Data Pipeline para todas as transformações/transições que isso é possível. Ainda não temos ferramentas abertas parecidas que trackeam os dados dentro de uma camada Realtime, em ferramentas como Kafka ou Kinesis. Só soluções pagas — e ainda caras- como Alooma e Stitch Data conseguem este tipo de linhagem.
4. Coleta
Quais os princípios que devo levar em conta para Coleta?
- Procure usar soluções de coleta multi-plataformas
Eu costumo chamar isso de Coletor Universal. É uma plataforma que consegue fazer coleta de diversas fontes diferentes, desde Bancos de Dados SQL e NoSQL, até dispositivos de IoT e plataformas da Internet. Obviamente, mesmo sendo universal, possivelmente este coletor não vai suprir todos os requisitos de coleta para todas as fontes, mas tenha em mente que você precisa de uma solução-base e de fácil assimilação.
O ideal é que a Coleta, assim como a exploração dos dados no Lake, seja democratizada, logo aumentar o número de plataformas só iria dificultar e embairreirar seus times de alimentar o Data Lake. Já falei sobre como usar, por exemplo, o Logstash como coletor universal nessa palestra abaixo.
Outra alternativa, seria o Apache NiFi, principalmente para times que tenham mais experiência com o paradigma Data Flow Programming (de ferramentas como Talend e Pentaho).
- Crie um Catálogo/Wiki sobre suas fontes e coletores de dados
Seus analistas e cientistas de dados devem saber características das fontes que desaguam no Lake. Qual formato da fonte? Qual dispositivo coleta e qual é a periodicidade da coleta? Se a coleta falhar, que eu faço ou com quem entro em contato? Nada melhor que usar uma Wiki pra documentar isso. Uma das soluções de dados que eu mais amo, o Dremio tem caminhado nessa direção. Numa pegada mais inovadora, o Knowledge Repo também pode suprir essa demanda, divulgando Notebooks com EDAs com amostras das fontes e explicando as formas de conexão.
5. TAKEWAY: Que Data Lake é um marketplace de valor atráves dos dados!
O Data Lake não é só um repositório imenso de dados. Não é a toa que você sai do mundo mais fácil do Estruturado, pra lidar com dado que vem em qualquer formato, que vai dar um trampo enorme — como você deve ter percebido, se leu tudo até aqui.
Data Lake deve ser visto como uma Feira de Dados. Um marketplace, onde Cientistas e Analistas têm a liberdade de achar dados, desde seu estado mais cru, até mais processados e prontinhos pra consumo.
Termino com o exemplo do Projeto Andes, Data Lake da Amazon.com. Olha que incrível! Abaixo você vê como é sua interface: exatamente do maior marketplace do mundo, a própria Amazon!
Os Cientistas exploram os DataSets no Andes como você explora Produtos na Amazon, tendo informações como tamanho, periodicidade e nível de qualidade, além da “descrição detalhada do produto”.
Desta forma força o “Vendedor” a manter seus SLAs e corresponder aos níveis mínimos de qualidade de dados e convida o “Comprador” a participar ativamente na revisão e governança dos dados.
Pra finalizar e reafirmar o último ponto, trago o gráfico de ideação do projeto, uma comparação de como a Amazon modela seu Data Lake de forma a seguir os mesmos princípios de Customer Experience e Cadeia de Valor da empresa:
Achou legal, curta e compartilhe! Tem alguma crítica ou acha que eu escrevi só abobrinha, comente!
Alguns amigos especialistas em dados e eu estamos criando e compilando vários recursos sobre como desenvolver projetos de Engenharia e Ciência de Dados de forma eficiente. Se quiser saber mais, dá uma olhada no sprintdedados.com.br e se inscreva para receber o material de graça!
Vamos tirar esse estigma de buzz do mundo de dados! Abraços e até a próxima!
