Data Vault – Geek BI

Publicado em 28/12/2023 por Fábio de Salles

Data Vault e Português

A língua, não a pessoa! ;-)

Em TI vivemos imersos em estrangeirismos, que é como se chama o uso de uma palavra de outra língua no nosso idioma natal.

Em si, isso não é ruim. Por exemplo, quando a palavra nativa é desajeitada ou esquisita, um termo de outra língua ajuda bastante: quebra-luz ou sustentador, as palavras em português para abajur (abat-jour) e sutiã (soutièn).

Mas em outras ocasiões isso é um problema sério. Meu exemplo favorito é leader. Traduzido como líder, a palavra não evoca nada. Ou melhor, evoca aquela pessoa destemida, à beira de um promontório, com o peito aberto para o espaço e um olhar confiante e distante.

231228_DataVaultEPortugues_01

Só que essa imagem que a palavra cria na sua cabeça está errada. Quer ver? O que é um guia?

Você deve ter pensado “é o cara que conhece o caminho, os desvios, atalhos, riscos e armadilhas”. Correto. É a pessoa que já passou por ali e vai te ajudar na travessia. É um profissional que vai tomar as decisões e vai se responsabilizar por elas, que vai delegar e cobrar o resultado, que amalgar várias pessoas, todas únicas e diferentes entre si, em uma coisa coesa, com direção firme.

E adivinhe? Leader, traduzido, significa guia.

Entendeu? Só de mudar a palavra estrangeira para seu equivalente nativo você já ganhou uma idéia melhor do que significa ser um líder. Agora você pode até avaliar se é uma pessoa para essa posição ou não, pode avaliar quem te lidera, pode escolher quem vai querer para ser seu guia. E em várias dimensões: profissional, pessoal, social…

Hub, Link and Satellite

Um Data Vault é um repositório de dados usado para construção de Data Warehouses.

Se você não conhece Data Vault, leia meu post Data Vault – Como Usar.

Vamos mudar a frase anterior: “um cofre de dados é um repositório de dados usado para construir armazéns de dados”. Notou? Só de trocar Data Vault por cofre de dados e Data Warehouse para armazém de dados as imagens na sua cabeça estão diferentes.

Traduzir Data Vault por cofre de dados não é uma boa idéia, porque um Data Vault não tem nada a ver com segurança ou inviolabilidade. Mudar DW para Armazém de Dados, porém, já ajuda.

O mesmo ocorre com as estruturas básicas de um Data Vault: hub, link e satellite. Desta forma, em inglês, elas não dizem muito. Quando estudamos cada uma dessas estruturas aprendemos que se referem a layout de tabela muito específico.

161012_datavaultcomousarerrata_001

Agora, veja como a coisa muda se traduzirmos:

Hub: Pivô;
Link: Elo;
Satellite: Satélite.

Pivô

Pivô, do francês pivot, é aquele elemento sobre o qual se faz uma rotação (pivotear) ou aquilo que fica no centro, no eixo, no qual se ligam outras partes.

231228_DataVaultEPortugues_02

A função de um hub é justamente essa: estar no centro do armazém de dados, como um conceito de negócio, no qual outras estruturas (links e satellites) vão se ligar.

Cubo, caixa, eixo, âncora – muitas outras traduções existem para hub, mas eu gostei mais de pivô. Cubo já existe em BI, eixo é esquisito. Caixa e âncora não têm significado claro neste contexto.

Elo

Em um Data Vault, link é uma tabela que liga dois ou mais pivôs (hubs). Essa é uma palavra muito usada, comum até fora da Informática: todo mundo compartilha links para todo tipo de coisa – páginas web, perfis em redes sociais, arquivos e formulários etc. etc. etc.

Não seria um problema deixar link como link (como hub também não era). Mas…

Mas existe uma palavra em português que serve muito bem para essa função e transmite a imagem mais adequada: elo. Ao invés de um caminho para alguma coisa, como nos habituamos a pensar para link web (que no mais das vezes é uma URL e não um link), a palavra elo transmite a idéia de coisas ligando-se entre si e formando algo maior. E essa é exatamente a função de um tabela elo (link): conectar, ligar dois ou mais pivôs e assim conectar todos os conceitos de negócios entre si.

231228_DataVaultEPortugues_03

Link poderia ser traduzido, também, por conexão, ligação, contato, junção, ligadura, ligamento etc. Nenhuma dessas palavras, porém, cria uma imagem tão ilustrativa do conceito de link como elo.

Satélite

Um satellite em Data Vault é a tabela que guarda contexto. É lá que ficam os atributos que podem ser atualizados e descrevem os conceitos de negócio (pivôs) e contextualiza as relações entre esses conceitos (elos).

A palavra é tão próxima do português satélite que quem usa Data Vault sempre fala “hubs, link e satélite”, misturando português e inglês como se fosse uma feijoada de frango.

E é uma palavra muito apta à sua função: ela se liga aos outros elementos e sempre apenas a um, como um corpo preso por atração gravitacional a um outro corpo (eu sou físico e satélite para mim tem uma imagem muito clara). Se eu tivesse criado o conceito de Data Vault, talvez chamasse de “context” ou “attributes” ou qualquer coisa mais óbvia (não sou um cara criativo, mind you), mas Daniel Linstedt escolheu satellite e caiu muito bem.

Assim, completando a tradução dos conceitos de Data Vault, eu vou continuar com satélite, como todo mundo.

Pivô, elo e satélite

Meio como Doc Brown, de “De Volta para o Futuro”, um dia eu tive uma epifania sobre como a língua interfere na interpretação do texto. Tudo começou com Data Mining, que depois de dez anos traduzindo como mineração de dados eu mudei para Garimpagem de Dados (e hoje eu diria Garimpagem em Dados).

Desde então eu venho testando traduzir alguns termos para verificar se em português eles mais ajudam ou mais atrapalham. E hoje eu decidi acabar de vez com hub, link e satélite. Não apenas por causa da feijoada de frango que é misturar português e inglês tão intimamente, mas porque eu quero poder ampliar a audiência do Data Vault, agora que (FINALMENTE!!!) o mundo (e o Brasil junto) o descobriu.

Então, a partir de hoje eu vou falar “pivô, elo e satélite” ao invés de “feijão, paio e frango”, digo, “hub, link e satéite”.

É isso. :-)

Publicado em 10/03/202210/03/2022 por Fábio de Salles

O Início da Engenharia de Dados

Engenharia de dados é o nome que hoje se usa para indicar todas as atividades de mover e tratar dados a fim de transformá-los em recursos para os negócios. Existem definições mais precisas que isso, mas para essa basta para o que eu vou falar aqui hoje.

O Mundo Hoje

Conforme o The Phoenix Project a TI é o negócio. Assim, uma das descrições possíveis para “empresa” é “coleção de sistemas informatizados”. São esses sistemas que dão existência às operações da empresa.

De acordo com o Fundamentos de Inteligência de Negócios, toda empresa encara dois tipos de problemas: operacional e estratégico. Problemas operacionais são resolvidos no dia-a-dia e podem ou não necessitar de dados desses sistemas. A Inteligência Operacional é a disciplina que atende esse tipo de problema.

Problemas estratégicos, ainda conforme o post Analítico ou Operacional? , são resolvidos por Inteligência de Negócios, que eu defini em Paz, Afinal – Parte III.

E esse é o estado do mundo hoje:

Sistemas informatizados são construídos para operacionalizar um empreendimento;
Os dados desses sistemas são necessários em aplicações diversas;
OI consome dados perto de tempo real, BI longe;
A fim de levar os dados dos sistemas transacionais para esses usos existe a Engenharia de Dados (que é o nome bacana para integração de dados – mais sobre a bacanização desse nome num post futuro.)

Assim Não Dá, Assim Não é Possível

Esse arranjo não é ideal, nem de longe. Ele envolve muito esforço, trabalho, retrabalho, desperdícios, sem contar resultados chochos em muitos casos. Basta lembrar a métrica de fracassos de projetos de dados do Gartner, que volta e meia alguém cita:

Qualquer analista de data mining digno do seu R2 pode ver claramente que a taxa de fracasso está aumentando, e que não é improvável bater em 100%.

Na verdade, se você parar para pensar, pode existir alguma empresa por aí que tem 100% de fracasso, ou seja, que nunca viu um projeto desse tipo dar certo. Nunca. O mesmo se pode dizer de profissionais: é perfeitamente razoável imaginar gente cuja carreira é um fieira de fracassos ininterruptos. Tipo, o cara deve ser um virgem de sucesso – nunca experimentou sucesso vida.

Solução a Curto Prazo

Eu já mostrei neste blog muitas alternativas que elevam taxas de sucesso a 100%. Se você está tendo problemas e quer uma luz, me chame – quem sabe podemos chegar a algum arranjo. ;-)

Passado esse vergonhoso momento de autopromoção (gasolina tá alta pra todo mundo!), a solução a curto prazo é simplesmente parar de modismo e começar a se preocupar com o que de fato interessa: resultado.

Data lakes, data mesh (sobre o que eu vou escrever em breve, depois de engenharia de dados), gestão de times, ferramentas etc. tudo isso nasceu de modismos insensatos (desde o início eu argumento que a idéia de data lake é pouco vantajosa, por exemplo). Isso quando a moda simplesmente não muda o nome das coisas, para ficar mais bacana (ninguém ainda demonstrou que data science não é Data Mining.)

Se você quer achar a saída para o labirinto dos seus projetos, a aplicação da Teoria das Restrições a BI pode te dar uma luz. (Eu adoraria saber se ajudou, ok? :-) )

O Longo Prazo

Agora, porque é que temos que esperar um sistema entrar em produção para só então começar a nos preocupar com os dados para análise? Porque o sistema já não vem com isso como uma funcionalidade default, automática e pronta?

Para entender a idéia eu preciso colocar uma coisa antes: Data Vault. Essa tecnologia resolve todos os problemas de integração, ingestão, consumo etc. e por isso ele é o caminho mais fácil e curto para um projeto de dados de sucesso. Graças a Data Vault, aliás, hoje é possível manter projetos de dados 100% automatizados, com uma só pessoa trabalhando.

A partir das premissas de Data Vault é possível desenvolver um Data Warehouse como um componente do sistema transacional, embutido no código, de saída. Graças aos paradigmas de Data Vault podemos construir uma extensão a um ORM, como o Hibernate, para gerar um DW ao compilar o código. Daí, a usando os padrões de refatoramento de bancos de dados do Martin Fowler e ferramentas como Liquibase, podemos automatizar evoluções de base em um pipeline CD/CI.

A idéia me veio hoje, lendo um comentário do Daniel Linstedt (pai do Data Vault) num post do Snowflake:

08/03/2022 Dan Linstedt: I predict a future where Operational Systems make the jump to Snowflake technology – where Snowflake builds a platform to enable operational application support for data scalability world-wide. Would be interesting to see for sure.

Ele implica o cenário em que um sistema transacional contrata uma solução de DW automatizada (que é uma das formas de operação do Snowflake). A ideia faz tanto sentido (e ele é tão próximo da Snowflake) que algo nesta linha provavelmente vai aparecer.

Eu tentei imaginar como isso seria e de repente a coisa toda cristalizou-se: dá para fazer um DW como código e embutir no próprio sistema transacional! Inclusive, isso daria incentivo à implementação de mecanismos de CDC direto no sistema!

E a coisa não pára nisso. Uma empresa raramente usa um só sistema e o normal é existir vários. De novo, graças aos paradigmas de um Data Vault, é muito simples integrar vários DWs-As-Code em um DW federado maior, sem perder escalabilidade e sem aumentar a complexidade. Dá para virar um padrão de indústria, até.

DW-As-Code: DWAC

CONSEGUI, INVENTEI UMA NOVA BUZZWORD, HAHAHAHA! VEM NI MIM, GARTNER!

(Pelo menos não achei nada no Google, ainda. :-)

Conclusão

No artigo What Is Disruptive Innovation?, Clayton Christensen explica como ocorre a inovação disruptiva:

Specifically, as incumbents focus on improving their products and services for their most demanding (and usually most profitable) customers, they exceed the needs of some segments and ignore the needs of others. Entrants that prove disruptive begin by successfully targeting those overlooked segments, gaining a foothold by delivering more-suitable functionality—frequently at a lower price. Incumbents, chasing higher profitability in more-demanding segments, tend not to respond vigorously. Entrants then move upmarket, delivering the performance that incumbents’ mainstream customers require, while preserving the advantages that drove their early success. When mainstream customers start adopting the entrants’ offerings in volume, disruption has occurred.

Em tradução livre e abreviada, “um desafiante, menor e com menos recursos que os maiores jogadores, escolhe focar em clientes de setores mal-servidos, onde conseguem firmar um pé ao melhorar a situação desses clientes; daí, os novatos se movem ‘mercado acima’, abocanhando setores cada vez mais valiosos, até que finalmente os clientes do mercado principal também adotam esses produtos; neste ponto dizemos que ocorreu a disrupção”.

A situação de projetos de dados hoje não é sequer uma coisa marginal – está ruim e confuso para todo mundo. Mesmo uma melhoria pequena já dá vantagens. Adicionar um DW como código a um sistema transacional é resolver um problema que nem sequer existe claramente. Fazer isso em um sistema que nem está no mercado, que está sendo desenvolvido, é ainda mais impensável.

Hoje ninguém seguirá essa direção, com certeza. Mas talvez um dia DWs sejam partes integrantes de um sistema informatizado, e o ecossistema de dados evolua para outro cenário.

E o que tem isso tudo com o nome do post, O Início da Engenharia de Dados?

Como eu disse no começo, EdD hoje é grosso modo a disciplina que monta e configura softwares e ambientes para mover dados de um lado para outro (fornecimento para análise também é mover dados de um lado para outro.) Com todo respeito, o conceito de Engenharia está para essas atividades assim como o conceito de Culinária está para bolo de caixinha. Na minha humilde e totalmente irrelevante opinião (mas minha, none the less), isso não é engenharia de dados. Para dar um exemplo, modelagem, que é uma coisa importantíssima, é um assunto marginal em EdD.

Para tentar deixar mais claro meu ponto de vista, considere o que chamamos de Engenharia de Computação, que é a carreira dentro da qual se aprende a desenvolver e programar sistemas, e compare com a Engenharia de Dados, que praticamente uma coletânea de softwares e processos.

Ao começar a tratar DW como parte de um sistema informatizado, e não como um apêndice, crescendo à parte e perpetuamente encrencado, eu entendo que estamos mudando o paradigma do campo “ETL com Python” ou talvez “Integração de Dados com Kafka”.

A partir deste ponto eu entendo que será o início de uma disciplina de Engenharia de Dados tão séria e profunda quando Engenharia de Computação.

Quem viver, verá.

Eu sempre quis dizer isso!!! :-D

Publicado em 24/03/2021 por Fábio de Salles · 2 Comentários

20 Anos Depois

Em 2000 eu pude participar de uma conferência do SAS – como empregado, nos bastidores – e ver Bill Inmon palestrar. Por essas coisas de eventos e ranks, eu não tive a oportunidade de conhecê-lo e, no fundo, não teria sido nada tão extraordinário para mim. Lembro-me de vê-lo falando e do sentimento de reverência por estar assistindo o pai do assunto, mas nada mais que isso.

Acho que deve ser o que sentimos quando vemos um jornalista da TV na rua: ah, puxa, ele é da TV, e acaba nisso. (Muito diferente, por exemplo, de assistir o show do Robert Plant e Jimmy Page no Hollywood Rock – muuuuito diferente.)

Hoje, praticamente 20 anos depois, o destino me leva para o lado do pai do DW mais uma vez. Mas agora, na mesma página:

Literalmente na mesma página, no WWDVC 2021

He, he. Agora eu me sinto no show do Led Zeppelin. :-D No palco do show, para ser exato.

Então é isso: em 2021 eu vou apresentar uma palestra ao vivo (um case) e outra pré-gravada (Data Culture) no palco do World Wide Data Vault Consortium 2021.

Este ano ele será totalmente virtual – por isso eu consegui me inscrever como palestrante. Mas isso significa que ninguém precisa mais pagar um vôo até Vermont, e hotel, para assistir a conferência!! Interessado? Acesse a página do evento e inscreva-se!

Ok, acabei de ver o Scott Ambler… eitap***a…

Publicado em 12/10/201612/10/2016 por Fábio de Salles · 3 Comentários

Data Vault: Como Usar – Errata

Meu grande amigo e co-autor do PnP, Cesar Domingos, me mandou um e-mail com duas dúvidas:

Fala Fábio,

Tudo bem?

Tô vendo uns posts seus sobre Data Vault e fiquei com dúvida em um.

https://geekbi.wordpress.com/2016/05/25/data-vault-como-usar/

Na parte do Modelo Completo, onde tem o desenho, a tabela s_l_empregados_pedidos não deveria estar linkada à tabela h_pedidos? Ou se não for na h_pedidos, não deveria existir uma tabela hub entre ela e a l_empregados_pedidos?

Fiquei meio perdido ali. Você tem algum exemplo com dados?

E uma outra pergunta. O que vai exatamente no campo Record Source? O nome da tabela de origem?

Abraços,

Cesar Domingos
Vida corrida de Cesar Domingos
Consultor Linux e BI
LPIC-3 e RHCE

Fui ver, e ele tem razão. Naquele post, a função da tabela s_l_empregados_pedidos não está clara, até porque existe um erro também. Neste post completo a explicação, explicitando o que eu queria fazer e mostro uma correção possível.

O Problema

A metodologia de modelagem de dados para Data Vault define três tipos principais de tabelas: hub, links e satélites. Hubs registram conceitos de negócio, como vendedor, cliente e produto. Links registram relacionamentos entre conceitos de negócios, ou seja, entre hubs. Por exemplo, se um vendedor cuida de um certo cliente, então podemos definir um link entre os hubs de vendedor e cliente.

Satélites guardam os atributos de hubs e links. Se o cliente é um hub, um satélite de cliente contém, por exemplo, seu endereço, sua data de nascimento, sua ocupação e outros dados.

A figura da qual o Cesar falou mostrava dois hubs, empregados e pedidos, e um link entre os dois:

Além disso, ela também mostra um satélite para hub empregados, e um para o link empregado-pedido. E isso está errado!

Sim, veja: satélites contêm atributos de um hub ou de um link. A tabela s_l_empregados_pedidos é um (s_)atélite pertencente ao (l_)ink empregados_pedidos. Mas olhe que atributos esse satélite tem:

data_pedido
pagamento_tipo

De quem são esses atributos? Data do pedido é um atributo do… pedido. E tipo de pagamento? Também! Ora, se são atributos do pedido – e não da relação entre pedido e vendedor – então esse satélite é do hub pedido, e não do link empregado-pedido! Por isso esse satélite está errado.

Para estar correto ele precisaria conter algum atributo da relação, do link. Esse modelo não é um bom caso para um exemplo de satélite de link, que era a minha intenção original.

A Solução

A mensagem que eu queria passar precisa de um modelo ligeiramente diferente:

Agora temos um novo hub, cliente. Poderíamos ter seu respectivo satélite, mas seria redundante, pois já temos um exemplo de satélite de hub.

Nesta empresa, cada cliente é atendido por um único vendedor ou gerente, que é o dono da conta, como acontece em um banco, por exemplo. Em um banco, todo cliente possui um gerente. Esse relacionamento aparece como um novo link, entre clientes e empregados.

Como dizia uma propaganda de banco, o tempo passa, o tempo voa. Um gerente muda de agência, outro muda de emprego, entram novos gerentes, chegam clientes de outras agências, clientes vão embora… Conforme o tempo passa, a relação cliente-gerente muda. Pior ainda: pode ir e voltar, ou seja, um cliente pode estar com um gerente hoje, outro daqui um mês e daí no ano seguinte volta a estar sob seu primeiro gerente.

O link não possui data de validade. Ele não possui nada além de data de criação e sistema de origem, aliás. Como, então, saber qual é o gerente atual de cada cliente? Ou que gerente teve que clientes durante um certo período?

Um satélite de link, justamente como mostrado na figura anterior, resolve essa situação: cada vez que o link sofre uma atualização, o satélite versiona sua data de validade. Resumindo:

Porque um link pode ter um satélite? Por que a relação entre dois hubs pode mudar ao longo do tempo, e a única forma de saber quais estão ativas, hoje, no sistema de origem é usando um satélite.

Evidentemente, um link pode ter outros atributos além de período de validade. Exemplo? Pense nos itens de um pedido, ou seja, os produtos que o cliente comprou naquele pedido. Esses itens são registrados no DV como um link entre o hub pedido e o hub produto. Agora, os detalhes de cada item, ou seja, a quantidade, o valor pago etc. são registrados como satélites desse link.

Record Source??

Quanto à segunda pergunta, o que vai no campo Record Source? Bom, o campo RSRC recebe o nome do sistema de origem, não da tabela. Como as tabelas, em princípio, fazem a integração dos dados, o campo indica em que sistema foi identificado aquele elemento – hub, link ou satélite – pela primeira vez. Como as tabelas hub e link são carregadas um sistema de cada vez, o campo RSRC indica, no fundo, que sistema foi carregado primeiro, já que ele não é atualizado mesmo que o campo seja encontrado em outro sistema, com o valor idêntico.

Esse campo tem um pouco mais de utilidade para satélites.

Já passei por situações em que era fundamental separar os dados dentro do satélite por sistema de origem. Foi com o Zabbix: um DV foi construído para integrar 11 Zabbixes. Como era tudo igual, tínhamos apenas uma tabela de satélite para cada item. Como o mesmo item podia aparecer em dois ou mais Zabbixes diferentes, o satélite do Zabbix 1 podia ser encerrado se o mesmo item existisse em qualquer outro Zabbix. O mesmo aconteceria com o segundo Zabbix a ser carregado e assim por diante e depois se repetindo desde o início. A única forma de resolver foi filtrando o satélite pelo RSRC, um para cada Zabbix. ;-)

Publicado em 21/09/2016 por Fábio de Salles · 1 Comentário

Nadando em Lagos de Dados

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. :-)

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 humildes¹ 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!”

;-)

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. ↩

Publicado em 17/08/201618/08/2016 por Fábio de Salles

Ladyvaulk – O Feitiço de Dataváulquila

Faz uns dois anos, e começou assim: minha mão estava coçando para testar Data Vault. Eu tinha feito alguns experimentos, tinha implementado um caso pequeno, mas ainda queria explorar mais. Queria um volume maior, mais complexidade, algo mais difícil.

Cuidado com o que você deseja, porque pode conseguir.

E eu consegui. Quem mandou desejar? Um dos softwares que o SERPRO usa é o Zabbix. Resumidamente, ele server para monitorar ativos, como roteadores, servidores e hubs, coletar métricas do parque informatizado e assim por diante. Consulte a página do projeto Zabbix para saber mais.

Como o SERPRO é uma coisa imensa, tudo está sempre no limite, no máximo, no maior volume, no mais complicado. São milhares de máquinas, dezenas, se não centenas de redes e sub-redes, kilômetros de cabos e tudo mais. Não vou entrar em detalhes técnicos para não correr o risco de falar besteira mas, resumidamente, o povo super-criativo conseguiu botar o esquema todo para a funcionar dentro do que era possível e desejável. Há um vídeo com uma apresentação sobre esse assunto neste link, feita por um dos empregados do SERPRO.

Uma das soluções adotadas passava por uma concentração de dados, que era atualizada periodicamente e servia para apresentar certos dados coletados pelo Zabbix.

Enter Linstedtman!

A pessoa responsável por essa necessidade foi aluna em um dos meus treinamentos de Pentaho, e veio me procurar imaginando se o PDI não poderia ajudar nesse caso. Afinal, consolidar dados é justamente a função dele.

As atualizações precisavam ocorrer a cada 30 minutos, no máximo, ou idealmente a cada 5 minutos ou menos. Apesar do grande espalhamento do sistema, como o volume dos dados capturados era, em si, até modesto, a baixa latência do refresh não era um problema.

O que realmente dava trabalho era a integração dos dados. Poderíamos, por exemplo, modelar os dados em uma estrela dimensional, definindo os atributos de interesse como dimensões e adotar uma fato artificial para correlacionar os dados entre si. Daria certo mas, depois de algumas mudanças nas fontes dos dados, as tabelas dimensionais acabariam ficando complicadas demais. Ou seja, logo no início do projeto daríamos de cara justamente com o ponto fraco da metodologia – a dificuldade de manutenção. Não era uma opção.

Poderíamos simplesmente replicar o layout de origem, mas isso implicaria em capturar os dados em uma granularidade confusa e, de novo, na primeira alteração na origem, quebraria todo histórico.

Não havia alternativa. Eu não queria admitir que estava usando os problemas como justificativa, mas no final, os problemas justificaram mesmo a escolha óbvia.

Usar um Data Vault. :-)

The Curse

Como havia uma certa urgência, trabalhamos em equipe: eu analisava os sistemas de origem para desenhar o Data Vault, e ia tirando dúvidas sobre os conceitos de negócio com os especialistas. Em pouco tempo (duas semanas, se não me falha a memória), foi montado o diagrama de tabelas, os modelos de transformação PDI e, com isso, um processo de ETL completo, de cabo a rabo, saiu do nada.

Como não era um grande volume de dados, a primeira carga levou coisa de uns trinta minutos, um pouco menos que isso. A partir da segunda carga, o processo de ETL terminava em menos de um minuto, graças ao fato de o DV usar CDC para tudo. Quando a rede está muito lenta, leva quase três minutos. Finalmente, por garantia, decidiu-se manter uma latência de 30 minutos (i.e. meia-hora), que dá uma boa margem para falha e recuperação, e ainda atende a necessidade.

E isso tem funcionado nesses últimos dois anos, sem parar, sem falhas, sem soluços, liso como gelo. De vez em quando aparece uma situação nova, e toca lá eu ir atrás de entender como usar Data Vault para resolver.

Um dia destes, batendo-papo e conversando sobre o projeto, a minha ficha caiu.

Sabe, eu não implementei esse lance – eu apenas desenhei um template, um gabarito de transformações para hubs, links, satélites e satélites de links. Nem tampouco desenhei o diagrama de dados: passei as regras de modelagem para a pessoa e deixei-a desenhar sozinha. Eu revisava tudo e corrigia os erros cometidos, mas eu mesmo não pus um dedo no processo de ETL!

É verdade que eu montei a configuração do PDI, configurei a captura de logs de cada transformação, e ainda montei um job que chama tudo. Mas de novo: montei na minha máquina, mandei para o projeto, expliquei como instalar no servidor e não fiz mais nada.

E tudo ia crescendo, ganhando tabelas, coletando dados… E a coisa rodando, e o monstro ficando maior, e maior e novos problemas aparecendo e eu só dizendo o que fazer. No máximo eu examinava os dados remotamente, para descobrir porque isso ou aquilo não estava dando certo, diagnosticava e, quando muito, corrigia os templates. A pessoa do projeto regerava as transformações problemáticas e tudo ia em frente.

Vocês não perceberam ainda né? Eu também demorei:

O projeto foi completamente, totalmente, 100%-mente construído, implementado e está sendo gerenciado por um profissional que não criou nada daquilo.

O projeto foi completamente, totalmente, 100%-mente construído, desenhado e planejado por um profissional que não implementou uma única transformação!

Sacaram? Eu não repeti a mesma frase duas vezes, leiam de novo.

Vou escrever ao contrário e vamos ver se fica mais claro:

O grau de automação do desenvolvimento foi tão grande, e em nível tão detalhado e profundo que a construção do modelo de dados e processo de ETL foi feito por um profissional que ignorava quase que completamente a técnica (DV) por trás.

E mais: a flexibilidade e resiliência da Metodologia de Data Vault é tão grande que foi possível desenvolver tudo – modelo e ETL – entendendo quase nada do negócio!

Nossa ignorância mútua dos problemas um do outro só não era total porque aos poucos fomos pegando partes da coisa – eu entendendo um pouco de Zabbix e o outro lado um pouco de DV e PDI. Mas nunca precisamos explicar nada sobre os detalhes de nada um ao outro!!!!!!!

:-O

Conclusão

Na esbórnia cultural que foi a década de 80, um dos filmes mais aclamados foi Ladyhawk, que contava a história de um casal amaldiçoado por um sacerdote malévolo. A maldição jogada nos dois fazia com que nunca se vissem, a não ser por uns breves segundos ao anoitecer e ao raiar do dia. Esse era o tal “Feitiço de Áquila”, que o nome do lugar: durante o dia a mulher era um gavião, e durante a noite, quando ela voltava à forma humana, o cara virava um lobo.

Preciso pedir perdão a vocẽs, porque foi mais forte que eu. Não deu para resistir.

Eu tive que brincar com isso.

A narrativa épica de um projeto de sucesso na era ágil! Quem projetou o ETL não implementou, e não sabia nada do negócio, enquanto que quem entendia tudo do negócio não sabia nada nem do modelo de dados, nem do ETL que estava implementando com as próprias mãos (e um monte de processos automatizados!)

Uma equipe que nunca se vê, um projeto conhecido metade por cada um, que ninguém sabe por inteiro! Essa é a história de…

… Ladyvaulk – O Feitiço de Dataváulquila!!!

Preciso concluir?? Não é à toa que existem, hoje, ferramentas como Wherescape e Attunity! Data Vault é uma coisa tão bombástica que um só “arquiteto”, como eu, pode cuidar de muitos projetos ao mesmo tempo, cada qual com UM – permita-me frisar: UM! – profissional de dados do outro lado.

Traduzindo: uma equipe de arquiteto mais alguns implementadores pode cuidar de muitos Data Vaults. É uma eficiência simplesmente impensável em qualquer outra metodologia!!

Claro que a realidade não é tão rósea. Para começo de conversa, os dados precisam ser extraídos do Data Vault, preparados e só então consumidos. Isso dá trabalho, mas mesmo assim nem de longe é o mesmo trabalho que dá construir um ETL para um modelo dimensional carregado diretamente a partir da fonte.

É isso. Até a próxima! :-)

Eu rio toda vez que falo Dataváulquila em voz alta. Vamos, tentem! Não me deixem pagando este mico sozinho!… :-D

Publicado em 03/08/201603/08/2016 por Fábio de Salles

Férias = Livros!

Eu sou daqueles nerds (geek, please!) que adora enfiar o nariz em um livro e sair só quando não der mais para segurar a fome ou qualquer outro chamado da natureza. Não deu para fazer isso nessas férias, claro, não consigo fazer isso desde que passei no vestibular. Mas eu consegui começar a ler vários! Achei todos muito interessantes, e recomendo!

Análise Bayesiana

Em Data Mining existem muitas técnicas para analisar dados. Uma das mais úteis é justamente a Análise Bayesiana. Sabendo disso, e tendo criado vergonha na cara, decidi ir atrás de um livro sobre o assunto. Como essa matemática toda me mete medo, eu procurei um com capa fofinha.

Não se deixe enganar pela capa fofa, esse livro morde!

Grande erro!! É um tijolo com quase 800 páginas, que além de explicar a técnica e a teoria, inclui tutoriais em R, Jags e muitas outras coisas legais. Você pode encontrar o Doing Bayesian Data Analysis na Amazon, tanto em versão física quanto eletrônica, pela bagatela de quase US$100,00.

Brincadeiras à parte, é um livro leve, divertido e inteligente.

O Que É Análise Baeysiana?

Você já leu Sherlock Holmes? Ele tinha um método peculiar para analisar cada mistério: primeiro, examinava as evidências e montava uma lista de hipóteses. Depois testava cada uma delas, tentando validá-la ou refutá-la. Ele sempre dizia que “eliminadas as hipóteses inviáveis, a que restar deve ser a resposta correta, por mais impossível que pareça” e com isso ele sempre chegava a uma resposta. Nem sempre ele acertava, claro, e nestes casos ele voltava ao começo: reexaminava as pistas, montava outras hipóteses e recomeçava.

Esse processo, de listar as possibilidades, e depois calcular as probabilidades de cada possibilidade é justamente a essência do método. Há toda uma matemática envolvida para descrever esse de ciclo, mas tudo que você precisa para entender a matemática é – segundo o autor – saber derivada e integral. Ele parece ser muito bom em te levar por esse caminho, da intuição até a formalização, sem traumas e com exemplos práticos.

Expressões Regulares

Ah, as exaltadamente malditas RegEx! Uma ferramenta tão poderosa quanto xingada! Bom, a Packt abriu gratuitamente, no Free Learning Forever o livro Mastering Python Regular Expressions e eu peguei. Ainda estou nos 50%, mas posso garantir: mudou minha vida. O autor explica a idéia de expressões regulares muito bem no primeiro capítulo. Já li bastante coisa sobre RegEx pela web, mas nunca alguém foi tão claro e conciso. O autor entende muito bem as confusões de quem não conhece nada do assunto e sabe mesmo como evitar as armadilhas de explicação. A clareza cai um pouco no segundo capítulo, mas só primeiro já valeu.

Finalmente um livro que explica bem RegEx!

Building a Scalable DV

E finalmente consegui separar um tempo para lê-lo com calma. Esse livro é o bicho, o cara, o alfa e o ômega, é tudo – e muito mais! Se você não sabe do que eu estou falando, é bom aprender. O livro é este:

Building Scalable Data Warehouse Vault - O Livro! — Building Scalable Data Warehouse Vault – O Livro!

E pode ser comprado aqui. Ele ensina como montar um EDW usando Data Vault, inteirinho, com tudo dentro – até a pia da cozinha. Não vou colocar os detalhes: baixe uma amostra e leia o sumário para ver tudo que ele inclui.

Se todos os livros do Linstedt até agora eram uma porcaria, esse aqui o redimiu.

Para montar um EDW de gente grande você precisa apenas de dois livros: este aqui e o DW Toolkit, do Kimball. E só.

Mastering Docker

E finalmente o livro que me fez desistir do Vagrant:

Aprendendo Docker. Lentamente. Mais devagar... isso... — Aprendendo Docker. Lentamente. Mais devagar… isso…

Eu ouço falar de Docker já há um bom tempo, mas nunca dei muita trela. Preconceituosamente, achava que era só mais um concorrente no espaço de virtualização. Num destes finais de semana, fuçando no site da Packt, recebi uma pesquisa para responder. No final ganhei um cupom de 75% de desconto, que eu usei para comprar esse livro por 1/4 do preço.

Bom, eu não podia estar mais enganado sobre o Docker.

Sim, ele monta ambientes por meio da virtualização de alguns recursos, mas a similaridade com máquinas virtuais acaba aí. A tecnologia do Docker, chamada de Linux Containers, permite montar ambientes de todo tipo, por uma fração do overhead de virtualização. Ainda que esta possua certas capacidades que a tornam mais apta a necessidades específicas, quase tudo pode ser muito bem resolvido com um conteiner, e o Docker é justamente o engine que movimenta isso.

E o livro? Ele é bom, falando de maneira geral. Ele foi escrito por gente que entende do assunto, não há dúvidas, mas são acadêmicos. Isso tem reflexos no estilo do livro, que é um pouco enrolão. Normalmente esperamos por alguma explicação centrada em exemplos e mais explícita, mais digerida, o que não acontece nesta obra. Pode ser só birra minha, ou pura e simples limitação intelectual (mais provável), mas as coisas importantes me pareceram estar disfarçadas sob uma grossa camada de fraseados elaborados e contorcidos como um arabesco.

No final das contas até dá para pegar as coisas importantes, como por exemplo a distinção entre contêiner e imagem (um é a execução do outro, que é o filesystem do um.) Mas se você espera uma coisa como o livro de RegEx do tópico anterior, recalibre sua expectativa.

Por uma daquelas imensas coincidências, ontem eu descobri um blog mantido por um cara que eu acho que já foi meu aluno, o Alexssandro Oliveira, que dá um excelente exemplo de como subir um servidor Pentaho com Docker. Vale a pena ler: Configurando um ambiente Dev Pentaho com Docker. Eu pretendia montar um exemplo, mas o dele está tão bem-acabado que é até besteira querer fazer melhor. E não é a única coisa boa lá, não! O blog inteiro dele é muito interessante, tanto que eu me inscrevi nele ontem mesmo.

Conclusão

Quem, em 2016, ainda compra ou empresta livros? Em uma era com tanta documentação on-line e gratuita, quem em sã consciência gastaria dinheiro e tempo com livros?

Eu. :-) E não pretendo parar tão cedo! Felizmente eu ganhei o dom de gostar de ler, o que ajuda muito a me mantar atualizado e a aprender sempre mais. Mas se você não faz o gênero CDF-óculos-fundo-de-garrafa (que eu fiz por uns 25 anos), devorador de livros, tente ler ao menos uns dois ou três por ano. Livros vão sempre mais fundo que posts, e em geral são mais fáceis de acompanhar que uma Knowledge Base.

Hoje eu mostrei alguns que vão me ocupar pelo próximo mês.

E você, o que tem lido de bom?

Até a próxima! ;-)

Publicado em 08/06/2016 por Fábio de Salles

Data Vault – Satélites?

No post Data Vault – Como Usar falei um pouco sobre a motivação, conceitos e arquitetura envolvida em um projeto de DW baseado em Data Vault. Um dos meus leitores colocou algumas perguntas muito interessantes, tão interessantes que eu decidi respondê-las em um post exclusivo. Além de ser um meio mais cômodo que um formulário de comentários, é uma forma de agradecer pela participação e mostrar o quanto eu apreciei. ;-) (Sim, eu sou fã dos meus leitores.)

Perguntas, Perguntas, Perguntas

Eis as perguntas colocadas no comentário:

1) Nos satélites, você cita um campo “Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);”. Neste ponto eu fiquei em dúvida. O ETL para estes satélites poderão realizar operação de update ou não? Ou este campo seria apenas para os casos de atributos que já tiveram uma “vigência fechada” nos OLTP (estou fazendo analogia ao SCD tipo II)?

2) Eu e um colega discutimos se o DV seriam bancos de dados para cada sistema transacional ou todo o DV corporativo estaria em um único banco de dados. Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto? No meu caso, estou falando de SAS e, consequentemente, datasets são tabelas e diretórios são bancos de dados. Então, na falta de um banco relacional como DV, eu inicialmente colocaria todo o DV num “diretório dvault”.

3) Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Vou responder uma por seção. Vamos lá.

LEDTS vs. SCD2

O ETL para estes satélites poderão realizar operação de update ou não?

Não apenas podem, como devem. Satélites guardam histórico e possuem exatamente o mesmo comportamento de uma dimensão de variação lenta do tipo 2. Ele acertou na mosca!

Hubs e links são tabelas que guardam os conceitos de negócio da organização, e as relações entre esses conceitos. Se algum dia um determinado hub ou relacionamento entre hubs existiu, o Data Vault captura e arquiva essa informação. Satélites, por outro lado, dão o contexto desses elementos.

O Cofre: Coleção ou Caverna?

A segunda pergunta é mais complexa:

Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto?

Bom, por um simples questão de integração, deveria estar tudo junto.

Buraco Negro

Até que ponto pode crescer um satélite?

Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Bom, o propósito central de um DV é acumular “todo os dados, para todo o sempre”. Logo, precisamos que a estrutura na qual os dados estão armazenados dê conta disso. Se um relacional não consegue, então precisamos recorrer a algo mais elástico. Inmon chamava essa camada de Near Line Storage, que é um armazenamento de alto volume, mas em uma mídia mais econômica. Em troca pelo preço menor por byte e durabilidade maior, a velocidade de acesso seria menor. No caso original, NLS seriam fitas magnéticas.

Conclusão

A conclusão, desta vez, é minha: do comentário e das perguntas eu posso ver que estou deixando algumas lacunas no assunto de Data Vault. Vou levar essa visão em consideração nos próximos posts sobre o assunto.

Até lá! ;-)

Publicado em 01/06/201602/06/2016 por Fábio de Salles · 2 Comentários

Projeto de Sucesso

Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.

Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.

Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?

Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?

Sucesso Não Existe

Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.

O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.

Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.

O Caminho para o Sucesso

Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:

Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.

Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!

Decisões, Decisões, Decisões

Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”

Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!

Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.

Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)

O Que Funciona?

E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?

Armazéns de Dados

Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.

Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.

Equipes

Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.

Processos

Há dois grupos de processos dentro de um projeto de BI, especificamente:

Processos de Desenvolvimento;
Processos de Atendimento.

O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.

O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.

Processo de Desenvolvimento

Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.

Processo de Atendimento

De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.

Soluções

Todo projeto de BI usa quatro tipos de soluções:

Apresentações;
Relatórios;
OLAP;
Data Mining.

As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.

E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.

Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.

Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.

Conclusão

Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.

Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.

Diagrama da Fábrica Corporativa de Informações.

Outro nome para essa abordagem é BICC – Business Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.

Não é um BICC, mas dá uma idéia de como funciona a tal "linha de produção". — Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.

O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.

É isso, até a próxima. ;-)

Publicado em 25/05/201625/05/2016 por Fábio de Salles · 13 Comentários

Data Vault – Como Usar

Um dos leitores do blog deixou este comentário em 18/5/16:

Fábio, gostaria de mais instruções sobre o data vault, como aplicar, onde aplicar e como é sua modelagem e arquitetura.

Prometi a ele que o próximo post responderia essa questão. Então aqui está: Data Vault, uma visão geral sobre onde aplicar, como modelar e em que arquitetura colocá-lo.

Do Começo, Por Favor

Data Vault é uma metodologia de desenvolvimento de Armazém de Dados Corporativo (do Inglês EDW), que inclui modelagem e processo de ETL. A versão 1.0 parava aí, já a 2.0 vai adiante, até a camada de apresentação dos dados.

Essa técnica foi inventada e desenvolvida por Daniel Linstedt para um projeto na mítica Lockheed Martin, que faz (fazia?) o mítico Blackbird SR-71, o avião dos X-Men. Baixe a amostra do Building a Scalable Data Warehouse with Data Vault 2.0 e leia o prefácio (do mítico Bill Inmon – isso aqui tá um templo grego de tanto mito!!) para ver essa história.

Perdão, mas eu precisava colocar isso aqui.

Aplicando Data Vault podemos desenvolver um Armazém de Dados com baixo custo, alta produtividade, baixo retrabalho, com processo de ETL de alta performance e altíssimo MTBF.

Volte Mais!

E porque precisamos de um Armazém de Dados mesmo? Bom, não é o assunto deste post, mas aqui vai, resumidamente:

No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.

Leia meu post Um Ponto Fita o Mundo para ver o argumento inteiro.

Vamos continuar?

Por Quê Adotar DV?

Todo EDW cumpre duas funções básicas:

Puxa dados dos vários sistemas da empresa para um repositório central;
Integra os dados dos diversos sistemas em uma visão abrangente.

Um EDW precisa puxar os dados de todos os sistemas porque qualquer se não olharmos em todos os dados da empresa nunca teremos a certeza de termos investigado tudo que há para ser examinado. É como perguntar que livro sumiu da biblioteca: só olhando todos vamos saber qual não está lá. Se o gerente financeiro pergunta “quais são todos os gastos da empresa”, precisamos olhar tudo!

Pense: se sua empresa tiver dois sistemas em MySQL, um em SQL Server, um em Postgres e outro em Oracle, como escrever um SQL que percorra todas essas bases? Não dá, não é? Os dados precisam estar em um repositório centralizado por simples limitação das atuais tecnologias de banco de dados: como em geral usamos SQL para fazer essas pesquisas, e um SELECT não consegue consultar – ao menos não de maneira fácil – dois ou três ou mais bancos de tecnologias diferentes ao mesmo tempo.

Os dados precisam estar integrados, o que significa bater os CPFs 012345678-00 com 1234567800. Quando puxamos um relatório do cliente 012.345.678-00 precisamos que ele seja identificado em todos os sistemas, não importando se na origem ele aparece como 1234567800, 012345678-00, 012.345.678-00 ou de qualquer outra forma. Dados não-integrados fornecem respostas erradas. Sem integrar os dados, seu DW não vale o HD no qual está gravado.

Há várias técnicas para construir um DW atendendo essas duas obrigações:

Copiar tudo da origem, mantendo os mesmos modelos, e integrar na hora de fazer a consulta. Frágil, trabalhoso e pesado (consome muita máquina;)
Copiar tudo da origem, gravando em um novo modelo na Terceira Forma Normal. Mais robusto e de melhor performance que o anterior, mas de evolução e manutenção tão difícil que beira o insano;
Copiar a origem em um novo modelo, como no item anterior, mas em um Modelo Dimensional. Não tão robusto, mas de boa performance, com evolução e manutenção práticas e simples no começo, mas tendendo à impossibilidade de manutenção e evolução com o tempo.

E finalmente, o Data Vault, que não sofre de nenhum destes problemas e tem todas as vantagens. Resumindo em figuras:

Os impactos das mudanças na arquitetura tradicional.

Os impactos das mudanças, agora no arquitetura com DV.

Só para ficar claro: por “nenhum impacto aqui”, no último quadro da figura acima, eu quero dizer “nenhum impacto de manutenção”, já que, obviamente, pode ser preciso criar algo novo. Não haverá impacto no que já existe, não será necessário mudar nada.

Adotar Data Vault como metodologia para desenvolvimento de um DW vai evitar os problemas que costuma comprometer os DWs da 3FN e Dimensionais.

Hoje vamos deixar só com essa afirmação, porque este é um post de visão geral, mas você pode seguir os links apresentados até agora para ler o (extenso) argumento explicando porque é assim.

Como Aplicar?

De fato, não há segredo na aplicação de Data Vault. A técnica meio que se resume em:

Quebrar o trabalho em “histórias”: quero medir isso, quero analisar aquilo;
Daí, para cada uma:
- Identificar as tabelas na origem que respondem essas perguntas
- Expandir o modelo de dados do DV com hubs, links e satélites;
- Gerar automaticamente ETL de carga do DV;
- Desenhar o ETL para a área de apresentação.

Existem padrões e técnicas para cada atividade, e a metodologia casa-se como uma luva à gestão ágil. Meu método preferido é o Scrum, e chega a ser surpreendente ver como DV adequa-se tão perfeitamente ao Scrum.

Veja meu post De Agilidade e BI para alguns comentários sobre o levantamento de requisitos para projetos ágeis.

Como É a Arquitetura?

Você já deve ter intuido a forma geral da arquitetura em uma das figuras anteriores. Reorganizando e renomeando as partes daquela figura temos uma visão mais clara:

Ou seja:

Um ETL (gerado automaticamente) traz os dados de cada origem;
Um banco de dados (preferencialmente relacional, mas um Hadoop does too) recebe e, graças ao modelo de dados do DV, integra tudo “na entrada”;
A partir deste banco um segundo processo de ETL popula as soluções;
Essas soluções podem ser de todo tipo: análises multidimensionais (OLAP), Data Mining (CRM etc.), painéis, relatórios etc. etc. etc.

Cada uma destas soluções após o segundo ETL têm suas arquiteturas particulares. No fundo a arquitetura de um DV são dois ETLs com um banco com modelo de dados DV no meio, mais nada. A partir daí, tudo fica igual à qualquer outro projeto de BI.

Modelagem

A modelagem de um Data Vault é relativamente simples, e você pode ler um pouco mais sobre ela neste post. Grosso modo, porém, resume-se ao seguinte:

Identificar chaves de negócio e criar hubs;
Encontrar relacionamentos entre chaves de negócio e criar links;
Escolher os atributos de hubs e links e criar os satélites.

Hubs

Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.

Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:

Business Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte da chave de negócios;
Source business key: chave de negócio no sistema de origem.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal do modelo. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.

Satélites

Satélites são como tabelas de dimensão: guardam os contextos de hubs e links. Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, … , An de um hub/link X possui as seguintes colunas, nem mais, nem menos:

Business Key/Link key: chave primária do hub/link
Load Date/Timestamp: data e hora da inserção do registro;
Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
Record Source: fonte dos atributos;
A1: atributo 1;
A2: atributo 2;
…
An: atributo n.

Modelo Completo

A coleção dessas tabelas e seus relacionamentos dão o modelo completo:

A etapa seguinte é construir o ETL para dentro do DV, e depois do DV para a camada de apresentação/consumo de dados.

ETL

Um DV possui duas vantagens “matadoras”: integração dos dados no modelo, ao invés de no ETL como é o mais comum, e um ETL padronizado. Graças à essa padronização o ETL de um DV inteiro pode ser gerado automaticamente: a partir de alguns gabaritos de SQL podemos construir o processo que lê e grava todos os hubs, links e satélites.

Eu sempre uso o Pentaho Data Integration (PDI) para processos de ETL, e meu curso de DV entrega ao aluno um gabarito de projeto completo – é só tirar da caixa e usar. A última versão dele traz até os SQLs para criar as tabelas no Data Vault.

Isso para o primeiro ETL, para dentro do DV. O segundo ETL, saindo do DV para a camada de apresentação, é mais particular, e não há como automatizar sua geração. Por outro lado, como todos os pontos de partida não são mais os sistemas de origem mas sim o DV, a “forma” geral desse segundo processo é mais uniforme, e alguns padrões acabam por facilitar seu desenvolvimento.

Por exemplo, dimensões são quase sempre construídas a partir de um hub e seus satélites, e tabelas fatos originam-se de links. Construídos os SQLs que lêem isso no DV (e nisso eles seguem um padrão de JOINs bem cadenciado), o passo seguinte é fazer trocas de chaves naturais por delegadas e, em caso de necessidade, limpar os dados.

Conclusão

Adoro quando um leitor pede algo, pois escolher o tema do próximo post, para mim, é como escolher roupa para sair: muito, muito difícil – e se não gostarem? e se ficar ruim? e se eu falar besteira por saber pouco? E se?…

Vimos que um Data Vault é uma metodologia que habilita a realização da visão de Bill Inmon, a Corporate Information Factory. A [CIF][cif_bitly] (até o advento do DV, outro mito) é como uma linha de produção, que ingere todos os dados da empresa e “fabrica” produtos de dados conforme as necessidades vão surgindo.

Data Vault é uma metodologia composta por uma modelagem, um processo de geração automática de ETL e outros elementos (como padrões e nomenclaturas.) O EDW se completa com um segundo processo de extração, que leva os dados para as áreas de apresentação, em formato dimensional ou não. Tudo em um processo de desenvolvimento que nasceu para ser tocado com gestão ágil (Scrum, na minha preferência), boa parte automatizada e com baixo ou nenhum retrabalho.

Não deixe de ver o post As Vantagens do Data Vault para mais sobre como um DV pode ajudar seu projeto de EDW.

É claro que nada é 100% a prova de falhas, defeitos ou problemas e eu mesmo já enfrentei minha cota de surpresas, dificuldades e maluquices nesse caminho que venho trilhando há alguns anos. Mesmo assim, hoje em dia, um Data Vault é a coisa que mais se aproxima de um método perfeito.

Fora essa babação no final, acredito que era isso. ;-)