Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.

Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.


Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.

Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.


E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.

Despensa, Cozinha e Salão

Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:

Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.

Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):

O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.

No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.

Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.

Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.

Uma Rosa por Qualquer Outro Nome

Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.

Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:

Ilustração do conceito de contexto limitado - bounded context.
Ilustração do conceito de contexto limitado – bounded context.

Agora a definição de bounded context:

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.

Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:

“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”

Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.

Conceito de UoW ilustrado: cada circunferência representa uma "unidade", que se integra a conceitos vizinhos.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.

Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:

  • A Unit of Work defines a correlated set of data;
  • A Unit of Work keep things together;
  • A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
  • UOW should be consistent with the (Enterprise wide) business keys.

Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:


Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.


Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.

Então temos três conceitos:

  • O clássico subject oriented, da área de DW;
  • O bounded context herdado da área de desenvolvimento de sistemas;
  • O misterioso Unit of Work, visto em textos de Data Vault.

E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.

Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)
Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)

Esta bela imagem foi retirada da Wikipedia.

Juliet:

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

W. Shakespeare, Romeu and Juliet

Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.

Mesmo Assim…

… Fowler comete alguns equívocos:

  • Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
  • Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
  • Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.

E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.

Conclusão

É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.

Mas o resultado final do post do Fowler é muito maior que seu conteúdo:

Data Lake Data Vault
Dados crús Dados crús
Precisa destilar para consumir Precisa destilar para consumir
Context bounded Subject oriented

PQP DE RODINHA!!!

O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:


DATA LAKE = DATA VAULT


Só o gênio dele para trazer essa relação à tona.

Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”

;-)


  1. Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. 

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s