O título é uma típica aliteração em inglês, “dedaom ov dedeidadam”. Além de ser mais diverto (fale em voz alta, para ver), em Português ele não tem lá muito sentido:
A Aurora da Represa de Dados
Essa foi uma idéia que nasceu durante um almoço que eu tive com o grande Flávio Daher, da PRODESP, em 7 de junho de 2017.
E ela é muito simples. ;-)
O que é um Data Lake? É só um reservatório no qual desaguam dados. Ele não agrega valor, per si, mais do que uma caixa d’água agrega valor a uma casa. Para que os dados que estão ali forneçam alguma vantagem competitiva, eles precisam ser bombeados para fora, tratados e levados para o consumo do usuário final. Por fim, este o cliente final usa a água de dados para cozinhar, lavar, produzir etc. A lista de metáforas hídricas é interminável, hehe.
Jogávamos conversa fora, Eu e o Flávio, brincando e troçando com essa idéia, quando o Flávio comentou:
É, mas os dados para terem algum valor, alguma utilidade, não podem ficar sentados ali, parados, eles têm que girar, que produzir algo, como numa represa…
Ele mal terminou de falar e eu congelei. Foi automático: represa de dados!!!
SHAZAM!!!!
AAAAHHHHHHHHH!!!!!
Ele ficou rindo e eu fiquei pulando e sacudindo os braços, berrando que nem um doido varrido, aaaaaaaaaaahhhhhhhh aaaaaaaaaaahhhhhhhh aaaaaaaaaaahhhhhhhh DATA DAM!!! DATA DAM!!!!
E foi assim. No meio do restaurante. Verdade! :-D Dentro da minha cabeça, ao menos. (Por fora eu fiquei olhando para o nada, mas isso não é engraçado…)
Então é isso: se você tiver algo mais importante para fazer agora, vá. Se não, pode ficar, porque o que vem a seguir é uma genuína e autêntica viagem na maionese(tm). Nem precisa de muito café para ficar: vai ser rapidinho.
What The Devil is a Data Dam?
E que diabos é uma represa de dados? No quê ela difere de um “lago de dados”?
Vista de Itaipu, uma das maiores usinas hidrelétricas do mundo.
Uma represa é feita para acumular água. Logo, semelhantemente mas ao mesmo tempo diferentemente de um Data Lake, uma Data Dam acumula um fluxo de água que inunda a área ao redor, que sobe de nível continuamente. Ainda que um lago evoque a imagem de rios formando um corpo hídrico maior, de dados acumulando-se em um ponto central, mais baixo que os OLTPs, uma represa evoca uma idéia de estrutura humana, construída para domar o poder das águas. É uma analogia muito mais forte;
Um lago pode ser consumido ou usado para fins domésticos. Não se bebe a água de um lago, mas apenas “pescamos” nele ou usamos porções modestas do líquido disponível, em escala doméstica. Uma represa, não: tudo é grande, maior que o Homem.
Um lago é uma obra da Natureza, que está lá e só. Quando muito, um lago artificial é feito para emular a Natureza, em geral para dar a sensação de se estar na Natureza. Em uma represa, não: a água que ali ficou apresada está lá para trabalhar por nós;
Um lago produz, quando muito, água potável e viveiros de aves e peixes. Uma repressa produz energia elétrica. É de represas hidrelétricas que o nosso país puxa um insumo indispensável para funcionar, diariamente, continuamente.
O poder de uma represa é muito superior a de um lago, e mais: é um poder plácido, contemplativo, mas de imenso potencial para o bem, se usada corretamente, e para a destruição, se liberado de uma vez;
De onde vem o poder de uma represa? Uma roda d’água, uma turbina, um moinho… Esses termos servem para ilustrar como os dados podem ser usados para alimentar de energia a Economia da Informação, a era em que estamos entrando.
Usando água para gerar energia elétrica.
Levando essa analogia mais longe ainda, podemos inventar que as equipes que montam refinarias de dados são equipes-turbinas, pois são elas que convertem aquele potencial preso nos dados crus em insumo para tudo. Tal como energia elétrica, que serve para tudo! Desde cozinhar, produzir e lavar, até qualquer outra coisa, já que eletrecidade, hoje, é mais versátil que a água. Diabos, com energia suficiente podemos até produzir água do ar!
Hmmm… Não… São equipes de “engenheiros hidáudicos” (mistura de hidráulico com dados). Daí, cada ETL que disponibiliza dados para o consumo é que é uma turbina. Logo, seriam ETL-Turbina. Extração-Turbinação-Carga? Extração-Turbina-Transmissão? Extração-Turbina-Consumo, sim, daí mantemos ETC e adotamos um novo significado. :-) Hoje eu tô a todo vapor! Affff! Vapor!!! :-D
E como isso se traduz em softwares e processos?
Nada de novo, aí: da mesma forma que em todas as outras analogias. O termo é só uma outra metáfora para as coisas que já existem há dez, vinte anos: um repositório de dados que alimenta o trabalho de uma organização. A novidade, mesmo, é forma de encarar, as imagens que ela evoca, muito mais poderosas e versáteis que um mero lago de dados.
Nothing But The BICC
E como funcionam “as coisas que já existem”? Melhor dizendo, como podem funcionar?
Como um BICC.
BICC é a sigla em Inglês para Centro de Competência de Inteligência de Negócios. Um BICC é como um departamento-mercearia: o cliente chega, vai até o balcão e pede alguma coisa – um dataset. Um dataset de tal e qual conformação, com esta e aquela agregação, que possa ser consumido por uma aplicação X para fazer Y – um conjunto de dados qualquer.
Daí o cara do balcão pode apontar o cliente para um produto qualquer, que já está na prateleira, e explicar como usá-lo. Ou pode se virar para dentro e berrar “Oh pá! Cá está um gajo a pediere um dataset de bugalhos! Faças e tragas cá, já!”
Tenho amigos, ídolos, em Portugal. Pelamordedeus, é só uma brincadeira com a nossa cultura!
Dali um tempo sai um moleque com o novo dataset, quentinho, que o cliente põe embaixo do braço (acidentalmente tostando o sovaco, kkkk) e vai-se embora feliz. Logo atrás dele entra outro cliente e o processo se reinicia: se o que este novo cliente precisa já existe pronto, ele pega e sai com ele, na hora; se não, espera um pouco e alguém da mercearia prepara especialmente para ele. Aos poucos, vai se acumulando uma lista de coisas já realizadas, como um catálogo de produtos.
Na minha opinião, uma Data Dam é uma boa metáfora para um BICC – se vocês mesmo questão de achar uma analogia. É uma estrutura que acumula água (dados) continuamente, que pode então ser usada para rodar turbinas (datasets) que vão alimentar algo com energia (resolver um problema.) Sempre que alguém precisa de tensão (voltagem) e frequência diferente, o time de engenheiros prepara uma nova turbina e instala um nova linha de eletricidade (ETC – Extração para Turbina e Consumo, hehe.)
Levando a analogia às últimas consequências, um cliente pode pedir os dados crus. Para atender essa demanda basta que o operador da represa abra as comportas de by-pass e está feito: lá fora vai aparecer toda água que nosso cliente puder consumir, tratar, usar como bem entender. Mais uma vez extrapolando, se as comportas forem completamente escancaradas, tudo rio abaixo será destruído. Essa é outra boa metáfora: inundação de dados não produz valor, apenas destrói o que já existe.
Novo Mesmo?
Aparentemente, outros já chegaram no termo ou perto dele. Por exemplo, tem o blog Big Data Dam/:
Página Sobre do blog Big Data Dam.
E tem até algum componente chamado Data Dam, para alguma coisa chamda Rhino:
Componente Data Dam do projeto Gafanhoto, para o Rhino. Eita…
Fora isso, não achei nada de muito significativo, de modo que pode ser que desta vez eu tenha criado algo ainda inédito.
Conclusão
Sorria: você acabou de testemunhar o nascimento de uma nova buzzword:
The Data Dam!!
Acabou, é só isso mesmo. O que virá a seguir, só Deus sabe. ;-)
Eu dedico este post à minha querida mãe, que hoje, 18 de julho de 2017, está completando 80 anos. Feliz Aniversário, Mãe! ;-)
(Este post deveria ter sido publicado em 19/10/16, no dia seguinte ao evento. Não deu para completá-lo no dia, e para não ficar sem nada saiu apenas os links para download. Em todo caso, as referências a datas serão mantidas. Amanhã o blog volta ao ritmo normal.)
O conjunto das FATECs de São Paulo, capital, faz um congresso de tecnologia anual. Nesta semana está ocorrendo a décima oitava edição do evento, ao qual eu fui convidado para palestrar. A coordenação do evento me deixou livre para propor o tema e acabamos ficando com BigData. A apresentação foi ontem, 18/10/16, às 10H00min, com boa presença dos alunos e até mesmo de professores (!!). Conforme prometido a todos eles, eis aqui os links para download dos slides e notas, ambos em PDF:
Você pode clicar nestes links para download direto ou, se estiver lendo em papel ou outro meio não-digital, basta copiar os bit.lys no seu navegador. Ambos arquivos estão hospedados em uma conta [DropBox][dropbox_bitly] e, por causa disso, pode ser que apareça uma tela requisitando seu login para fazer o download. Não caia nessa! Não é preciso fazer login para baixar os arquivos: examine a tela com atenção que você vai acabar descobrindo algum texto do tipo “não obrigado, leve-me ao download”. O DropBox usa qualquer opoturnidade para ampliar sua base e por isso ele fica com essas “pegadinhas”.
O post de hoje é um resumo da apresentação. Bom proveito!
De Onde Veio?
Quando a Profa. Célia me convidou para participar do fórum ela me deixou à vontade para escolher o tema. Uau, que responsa…
Como a FATEC é uma escola técnica, de tecnologia, e voltada para o mercado profissional, eu propus apresentar um pouco sobre BigData, que tem sido um assunto “quente”. Acredito que uma palestra sobre esse tema possa abrir horizontes para vocês, alunos.
Vocês podem encontrar, pela web, toneladas de vídeos, livros e textos explicando o que é BigData, como montar uma fazenda Hadoop, porque Storm é o máximo e que Social Analytics é o bicho.
De que valeria um profissional do ramo vir até aqui e alugá-los por sessenta minutos para ler powerpoint e repetir o que existe por aí? Vocês não precisam de ninguém para se virar sozinhos, não é mesmo?
Minha meta, hoje, é dar a vocês uma visão calibrada do quê, de fato, essa tecnologia significa para o mercado de TI, o que ela pode fazer e para onde eu, Fábio, acredito que esse barco vai.
Com isso eu espero dar a vocês uma vantagem em sua vida profissional, em sua busca por emprego, que – todo mundo está careca de saber – não está fácil para ninguém, certo? ;-)
Notem que, exceto pela minha certificação Pentaho, eu não tenho nenhum diploma de BI ou pós-graduação em DW nem nada do gênero. O que eu vou contar aqui eu aprendi na lida diária, no contato com problemas e soluções que afligem toda empresa moderna.
Eu vou mostrar os conceitos do Hadoop em alto nível, sem entrar nos detalhes técnicos, e daí explorar as possibilidades que surgiram, que promessas estão sendo feitas e o quê é besteira nisso tudo.
O Céu é o Limite
Todo computador funciona da mesma forma: lê dados de algum lugar, realiza alguma operação e manda o resultado para algum outro lugar.
Computador conceitual.
Um computador nada mais é que um circuito eletrônico. Aliás, era mecânico, daí a a válvula foi inventada e deu origem ao computador eletrônico. Mais tarde ela foi substituída por transístores, que foram combinados em circuitos integrados (CI), que começaram grandes, com poucos componentes. Conforme a eletrônica se sofisticou, a quantidade de transístores por CI aumentou, elevando a velocidade de processamento.
Exemplo de circuito integrado: o famoso 555.
Essa tendência poderia ir adiante para sempre, se não fosse um porém: a Física, a própria Natureza, interpõe certos limites.
A resistividade de um condutor aumenta conforme sua secção diminui. Logo, com circuitos integrados na casa dos milhões de transístores em menos de um centímetro quadrado, os circuitos ficam muito pequenos, o que faz com a corrente através desses circuitos gere cada vez mais calor. Para piorar, o aquecimento em si também afeta a condutividade, “somando agressão à injúria”1. No final das contas, a redução de escala é barrada por um limite prático.
E mesmo que o problema de condutividade seja resolvido usando, digamos, supercondutores, efeitos quânticos limitam o tamanho dos transístores.
Se mesmo assim conseguíssemos superar essa barreira, lá no fim acabaremos trabalhando com átomos individuais, e não dá para ficar menor que um átomo. Dá para usar átomos menores, claro, mas trocar o material do chip nunca vai remover essa barreira, vai apenas empurrá-la para mais longe. E mesmo que pudéssemos avançar ininterruputamente crescendo o poder da CPU, estaríamos limitados velocidade de acesso de RAM, discos, redes.
Todo computador sempre terá um limite de capacidade e velocidade de processamento.
Os maiores computadores monolíticos, ou seja, cujo software é executado integralmente na mesma CPU, são os mainframes. O SERPRO usa mainframes para quase todos os processamentos de altos volumes, como tratamento do IR e o SISCOMEX (o sistema aduaneiro da RFB.)
Mainframes são o limite da máquina monolítica.
Entretanto, enquanto a capacidade de cada máquina ficava cada vez maior, com valores proporcionais, tecnologias que se tornavam mais ordinárias se tornavam cada vez mais baratas. Ou seja, as grandes máquinas continuam caras como sempre, mas as máquinas baratas estão ficando cada vez mais poderosas, e isso abre uma possíbilidade interessante: paralelizar.
Custo do poder de processamento não cresce linearmente.
Superman & Batatas
Pense no seguinte: o Super-Homem é o cara mais forte e rápido do mundo. (Please, deixem o Flash fora disso…)
Suponha que um homem normal leva um minuto para descarcar uma batata, e que o Super-Homem leva, vai, um segundo. Isso quer dizer que ele pode descascar sessenta batatas no tempo que um homem normal descasca uma – e só! Nada além disso! Ele não consegue ficar mais rápido.
Bom, basta juntarmos 120 homens normais e teremos o dobro da velocidade do Super-Homem! Super-homens não existem por aí dando sopa, mas temos sete bilhões de humanos normais. Isso significa que, botando todos para descascar batatas, temos uma velocidade média de 116 milhões de batatas descascadas por segundo (million-peeled-potatoes-per-second, ou mppps kkkk…) Considerando-se que a produção mundial de batatas é de mais ou menos 1,88 trilhões de batatas (dados de 2013, supondo 200g de peso médio por batata), levaríamos aproximadamente 16.200 segundos para descascar tudo, ou quase cinco horas – menos de um dia de trabalho. A mesma tarefa feita pelo Super-Homem levaria mais de 520 milhões de horas, sem parar, ou quase um milhão e meio de anos!!
O mesmo pode ser feito com o processamento de dados: se uma máquina, sozinha, levaria um tempo X para realizar um processamento qualquer, duas máquinas iguais realizariam o dobro do processamento no mesmo tempo, ou poderiam completar a tarefa na metade do tempo.
Se podemos fazer isso, então nosso problema muda de figura: já não é mais como construir um computador super-rápido, mas sim como dividir nosso trabalho em pedaços iguais e processar esses pedaços em muitos computadores medianamente rápidos.
Construa seu próprio supercluster!
Bom, Bonito & Barato
E foi nesse problema que vários pesquisadores passaram a trabalhar na década de 2000. Em 2003, para vocês terem um idéia, ainda não existia nenhum “kit” pronto para processamento distribuído. Já existiam clusters, claro, mas eram coisas como o Beowulf, que nada mais eram que um monte de máquinas na mesma rede e alguns pacotes de software para ajudar a paralelizar a execução de determinado programa.
Nesse cenário o Internet Archive e a University of Washington se lançaram à busca de uma tecnologia que melhorasse a indexação de páginas web. Depois de algum tempo a equipe conseguiu produzir uma arquitetura clusterizada que dava uma performance superior em indexação, ainda que bem mequetrefe e instável, que acabou sendo chamada de Nutch. Segundo eles, era preciso uma pessoa ficar literalmente ao lado da aplicação o tempo todo, consertando os erros e defeitos.
… mas ao mesmo tempo outra empresa, uma com ainda poucos anos de vida, investia pesado em coisa semelhante.
Essa empresa, que não era ninguém menos que a Google, lançou dois papers, em 2003 e 2004, que se tornaram a fundação do que viria a ser o ecossistema de BigData. O primeiro falava sobre um cluster de sistemas de arquivo massivo, automatizado, o Google File System. O segundo propunha um modelo de programação para processamento paralelo, e expandia conceitos de uma tecnologia chamada programação funcional, desenvolvida no final da década de 1950 a partir dos conceitos de Cálculo Lambda, que por sua vez é da década de 1930. Esses conceitos resultaram em um framework, que é o segundo paper publicado, chamado de MapReduce. Esse paper mostrava como usar as operações funcionais de map() para distribuir a operação e reduce() para consolidar os resultados.
O gênio saíra da garrafa. :-)
A história toda é bem interessante, e vale a pena conhecer: clique aqui para ler a história inteira.
Eram os primeiros anos do Google, e uma outra empresa dominava então: o Yahoo. Buscadores de web (Google, Yahoo etc.) ganham dinheiro vendendo links e anúncios. Quanto mais páginas indexadas, maior sucesso nas buscas, e com maior sucesso, mais gente aparece querendo buscar. Quanto maior o público, a venda de anúncios cresce em número e valor.
Mais gente usando = maiores oportunidades de negócio.
Para aumentar o público, melhore seu produto = indexe mais.
Em 2006 o Yahoo investiu na reconstrução de seu motor de busca e começaram um projeto que incluíu os criadores da tecnologia que o Internet Archive estava desenvolvendo, o Nutch. O Nutch, que ainda existe aliás, era montado usando os conceitos do GFS e MapReduce. Quando o Yahoo encampou o projeto eles decidiram dividi-lo em dois pedaços: um webcrawler, que permaneceu com o nome Nutch, e uma infra-estrutura de clusterização, que englobava os pedaços trazidos do GFS e MapReduce. Já que eram tecnologias essencialmente diferentes, essa separação fazia todo sentido.
E que nome dar a este projeto?
Doug Cutting, que assumiu o projeto no Yahoo, nomeou-o a partir do elefante de pelúcia que seu filho chamava de, adivinhou, hadoop. Segundo Cutting, esse foi um bom nome porque era simples, sonoro, fácil de lembrar e sem nenhum significado em particular.
Ti fofu!!!! Had’oop!
E o Que é BigData?
BigData é Hadoop, Hadoop é BigData. Ao menos no contexto geral, comercial, essa é a relação entre a tecnologia e o conceito: a tecnologia Hadoop ajudou a firmar o conceito de BigData, que por sua vez ganhou relevância conforme o Hadoop era aplicado em mais e mais casos de uso.
Em outras palavras, a maturação do Hadoop trouxe solução a uma classe de problemas normalmente fora do alcance. Esse sucesso turbinou o comércio dessas soluções, que acabaram sendo chamadas de BigData.
Hadoopen! Haduken! Shoriuken! Spining Round Kick-u-ken! Barbie e Ken!
A certa altura o Hadoop ganhou status de cool, de pop, e caiu no gosto tanto dos capitalistas de risco. Daí surgiu uma leva de startups focadas em Hadoop, seus serviços, usos e todo o ecossistema tecnológico. E também caiu na graça da imprensa de tecnologia, que achou um nicho cheio de jargões fresquinhos e enigmas suficiente para uma década de reportagens.
Estamos agora em 2016 e, finalmentem, a força das buzzwords BigData/Hadoop está começando a esmaecer. Será preparação do palco para as próximas, como IoT?
O primeiro uso da expressão BigData foi em 1997, no artigo Application-controlled demand paging for out-of-core visualization para designar dados que não cabiam na memória do computador ou mesmo no disco. O resto é história: Hadoop acabou irreparavelmente associado ao termo. Apesar disso houve (e há) outras tecnologias para resolver problemas de “dados que não cabem na memória” do computador (e quase todas giram ao redor de clusterização.)
Por exemplo, existem bancos de dados especiais para aplicações computacionais intensas (muita conta e muito dado), como o Vertica e o Teradata. Ambos armazenam os dados de maneira diferente da de um banco relacional ordinário, e montam-se em clusters. Isso permite que distribuam as contas pelos nós, usando conjuntos locais de dados que depois se integram nos resultados em um nó mestre – que é exatamente a mesma idéia do Hadoop.
Pelo que vimos do histórico na primeira seção, existe um limite para o aumento da capacidade de processamento monomáquina, e portanto existe uma categoria de problemas que não pode ser tratada, dentro de tempos razoáveis, por esta arquitetura.
Resumindo:
Sempre que sua necessidade de processar dados extrapole a capacidade de uma só máquina e um tempo razoável, você está com um problema de BigData.
Podemos colocar de uma forma mais prática:
BigData é uma tecnologia de cluster de máquinas COTS2 para coleta e processamento de um grande volume de dados, dentro de um tempo razoável.
“Grande” é impreciso: qualquer coisa maior do que uma máquina simples consegue dar conta;
“Tempo Razoável”: mais imprecisão. Um tempo tal que os resultados são obtidos antes de tornarem-se inúteis.
Por exemplo, pode ser que os dados caibam todos no maior HD que você pode comprar, mas levariam anos sendo processados só para obter a primeira resposta – imagine as seguintes. Se você precisa da resposta em meses, anos é muito tempo. Se precisa de horas, semanas é muito tempo, e assim por diante.
Só que essa definição não é comercial, ela não “vende”. Foi quando começaram a surgir os acrônimos, sempre em tuplas de Vs, com cada vez mais vês: 3, 4, 5…
Alguns adicionaram um novo V, de veracidade, que queria dizer “qualidade”. Ou seja, não bastava acumular lixo, tinham que ser dados verdadeiros.
Outro colocou um V para valor, chegando a 5Vs, argumentando que se você não extrair valor dos dados, então não era BigData. E assim por diante.
Eu não consigo para de associar VVV com vai e volta, viu?, he he, ou com as variações. Por exemplo, meu primo usava 5 Vs: vai e volta voando, viu v******* ? :-D
Essa é a parte chata do mundo de TI, que tenta transformar conceitos e softwares em produtos com o mero balançar de beiços. Não caiam nessa! Só porque alguém escreveu uns slides (como eu fiz), montou um produto e está vendendo (que é quase o mesmo que estou fazendo…) não significa que ele está transmitindo um fato novo, uma verdade inegável ou algo supimpa. Use sua inteligência para filtrar o mundo.
No fundo tudo isso queria dizer a mesma coisa: problemas tão grandes que precisam de mais capacidade que uma só máquina pode fornecer.
Mas, ora vejam vocês, existem muitas opções para atender essa categoria de problemas!! Para começo de conversa existem máquinas SMP e multi-core. Existem clusters de bancos de dados, existem tecnologias de bancos de dados alternativos (como o Teradata ou o Vertica, que são colunares.)
Hadoop é uma destas tecnologias, que acabou ganhando fama por que seus limites situam-se muito acima dessas outras opções. (Mais imprecisão…)
Se precisássemos classificar os problemas pela capacidade de processamento requerido para resolvê-los, teríamos algo como isso:
Problemas normais: monomáquina;
Problemas grandes: Clusters de bancos (tradicionais e depois colunares;)
Problemas extremos: Hadoop.
Confuso? Complicado? Então guardem apenas isso:
BigData = Hadoop
Hadoop = BigData
BigData é a tecnologia de cluster de máquinas COTS2 para armazenamento e processamento de um volume de dados maior que cabe em uma só máquina, antes de o resultado ficar inútil.
Como sempre, essa definição é a minha, a partir do que eu aprendi. Você pode contestá-la (adoraria ouvir) ou achar outras. Como quase tudo em BI, vale a que você preferir. ;-)
Botando Para Rodar
Daí vem você e me diz: “Fábio, entendi patavinas do que você falou. Por analogia, algum destes temas tem a ver com o Hadoop/BigData?”
Inteligência de Negócios? Não mais que um banco de dados normal;
Armazém de Dados? De novo, mesma resposta (sem contar que projetos de DW incluem qualidade de dados e valor;)
PostgreSQL, Oracle etc? Esses são os famosos bancos relacionais, o que são bem diferentes – a começar pela forma de operação;
Sistemas transacionais (OLTP)? Os sistemas, em si, usam bancos transacionais. Como Hadoop é, grosso modo, um sistema que opera em lote, a resposta é não;
Linguagens de Programação? Não, nada a ver. Você pode implementar rotinas de MapReduce em algumas linguagens, mas Hadoop não é uma linguagem. Só para constar, programas MapReduce nativos são escritos em Java;
A Nuvem? De uma forma oblíquoa e não-relacionada, talvez. De maneira direta, nada a ver;
A Nuvem é BigData? Mesma resposta.
Se você precisa montar uma analogia para entender, meu caro, você está no sal, porque não existia nada como Hadoop antes. Pelo menos nada que fosse comum o bastante para ser um senso-comum. Sabe o que é Lustre? Já ouviu falar em MPI ou Beowulf? Pois é, Hadoop é uma mistura dessas coisas. ;-)
E todo mundo precisa de Hadoop? Ou de BigData? Não, claro que não. São raras as tecnologias que são aproveitadas indistintamente por qualquer organização. Hadoop não é uma dessas. Hadoop/BigData é uma tecnologia de nicho.
Veja que Hadoop(=BigData) é totalmente implementando com Software Livre. Logo qualquer um pode usar como e para o quê quiser, sem custos de licenças.
Como saber se você precisa? Fácil: sua organização enfrenta algum problema causado pelo mero volume dos dados? Se tem, pode ser que precise. Se não, então nem se dê ao trabalho. Simples assim.
Claro que podem existir problemas que você ainda não sabe que tem, e que podem vir a ser tratados com Hadoop, mas esses fazem parte de um conjunto mais ou menos pequeno. Vejamos um pouco sobre isso.
É Online?
Hadoop foi projetado para ser operado por meio de programas MapReduce. Isso é qualquer coisa, menos online. Problemas online, em geral, dizem respeito a registrar transações e hoje a melhor opção para isso ainda são bancos de dados relacionais. Em alguns casos, um mainframe é a única solução.
Por exemplo, caixas do Pão de Açúcar eram operadas por mainframe. Não sei como é hoje, mas até meados da década passada cada checkout do Pão de Açúcar era ligado a um mainframe, com operações de enorme volume de dados acontecendo em tempo real.
Isso não quer dizer que essa possibilidade está barrada ao Hadoop. Muito pelo contrário: existe muita pesquisa e desenvolvimento sendo conduzido para reduzir e até eliminar os overheads do Hadoop e colocá-lo em “modo online”. Em última análise, esse caminho vai nos levar até o ponto de processamento transacional, operacional.
Mas, hoje e pelos futuro próximo, Hadoop é algo que opera em batches, não online.
Se você precisa de operações online em grande volume (OLTP), como ERP, invista em grandes computadores e até mesmo em mainframes. Por enquanto, Hadoop não é uma tecnologia para esse tipo de aplicação. Um dia, quem sabe?
DataLake?
Esse é um conceito idealizado pela própria Pentaho. A meta deles era popularizar o uso do Hadoop, e com isso alavancar o consumo de Pentaho, já que esse tem enormes facilidades para lidar com Hadoop.
Em tese, DL é um substituto para um Data Warehouse, um armazém de dados. O problema é que, hoje, Data Lake é uma coisa bagunçada e crua. Para a empresa consumir os dados de um Data Lake é preciso que um profissional trabalhe os dados que estão lá e construa outras estruturas, normalmente fora do Hadoop, que serão consultadas pela comunidade de usuários da organização.
Só que ao fazer isso caímos de novo no modelo de Armazém de Dados, que faz exatamente a mesma coisa.
E se a dita empresa quiser se livrar desse profissional intermediário, ela terá que deixar cada cliente, cada usuário, construir seus próprios usos. O que vai requerer que esses usuário conheça não apenas o negócio, mas também conheça intimamente os dados – ou nada vai sair!
No fundo, DL, tal como se apresenta hoje, é uma tentativa de criar um produto comercial, de linha de frente, com um insumo que só funciona bem em certas situações, mas não em todas. Atualmente eu não vejo nenhuma vantagem nele – especialmente se considerarmos Data Vault.
Machine Learning
O termo Machine Learning é um tipo de expressão guarda-chuva para acomodar um monte de tecnologias. Grosso modo, Machine Learning, ou Knowledge Discovery etc., são termos relacionados à área de Data Mining.
Data Mining é o processo – não o software! o processo! – de examinar dados em busca de um modelo matemático que permita usar o passado para prever o futuro.
Um exemplo simples é a previsão do tempo: depois de analisar os dados meteorológicos acumulados por décadas, fomos capazes de construir uma equação – um modelo matemático – que dá a probabilidade de ocorrer ou não chuva em um determinado lugar, em um determinada dia e hora.
Podemos aplicar o mesmo tipo de técnica a coisas mais prosaicas como sugerir um produto para nosso cliente, oferecer um desconto para ajudá-lo a fazer uma compra ou negar qualquer desconto. Podemos analisar os dados de tráfego em uma cidade e descobrir uma sequência de acionamento de semáforos para reduzir congestionamentos. Podemos analisar os caminhos produtivos de uma fábrica e mudar seu layout para reduzir custos, aumentar a produtividade ou prevenir defeitos.
Machine Learning é justamente uma técnica de descoberta de um modelo que explique os dados. Como volume é uma variável crítica para o sucesso de técnicas de ML, Hadoop e BigData têm sido associados a ML, mas não são, de forma alguma, sinônimos.
NoSQL?
NoSQL já foi descrito como not SQL e mais recentemente como not only SQL, e refere-se de maneira geral ao mecanismo de consulta de uma base de dados. Hoje entende-se por NoSQL como uma expansão nas técnicas de manuseio de dados em bancos para além de mero SQL.
Hadoop, que é alimentado por operações de transferência de arquivos e consultado por MapReduce, é considerado uma tecnologia NoSQL. Entretanto, NoSQL não é sinônimo de Hadoop, da mesma forma que não é sinônimo de MonetDB, CouchDB e outros famosos bancos NoSQL.
Curiosamente, há um grande esforço para conseguir “equipar” Hadoop com SQL! Vai entender…
IoT?
Internet das Coisas, pelo que tudo indica, é a próxima BuzzWord a estourar nas paradas. E aí, qual é a relação entre IoT e Hadoop/BigData?
A visão trazida pelo conceito IoT diz que todos os eletrodomésticos e traquitanas terão, cada um, seu próprio IP e trocarão dados entre si e com computadores. Para que propósito, exatamente, é um tópico à parte. O que nos interessa, hoje, é notar que o volume de dados estima-se que será gerado é muito (muito (muito!)) maior que as maiores plataformas atuais trabalham. Logo, analisar esses dados será tarefa para Hadoop – até mesmo transacioná-los talvez venha a ser feito por uma plataforma similar.
Logo, IoT não é sinônimo de BigData, ainda que com certeza possuam uma forte ligação.
Que Problemas Resolve?
Vocês hão de concordar comigo que essa pergunta é um pouco boba. Afinal, se BigData trata de processar dados que não cabem na RAM ou no disco local, então BigData (que é o mesmo que falar “Hadoop”) resolve problemas… com dados demais!
O critério para saber se você – sua empresa, sua organização – precisa de uma solução de BigData não é o tipo de negócio, o porte da organização ou o alcance dela. O critério é ter coisa demais para processar e, mesmo com uma máquina maior, ainda continuar a ser coisa demais, ou nunca ser rápido o bastante.
Por isso, se algum fornecedor te pestear para oferecer BigData, ponha um pé atrás. Assista a apresentação dele e pergunte-se sempre, o tempo todo, “não dava para fazer com ( ) um banco tradicional? ( ) um banco colunar? ( ) um cluster? ( ) alguma outra coisa mais fácil ou barata? ( ) etc?”.
Voltando ao ponto, graças a paralelização massiva, Hadoop/BigData arquiva e processa dados com uma grande velocidade. Que categoria de problemas conhecemos, ao menos em BI, que causa grande processamento?
Relatório? Não, nem de de longe.
OLAP? Mais ou menos, talvez, mas via de regra, não.
Painéis? Menos ainda…
Data Mining?
Isso mesmo: Hadoop barateia Data Mining. Sempre que você precisar de Data Mining, e a performance do seu parque estiver abaixo do que você precisa, adotar Hadoop pode melhorar sua vida com uma relação custo-benefício sensivelmente melhor que outras tecnologias. Mas cuidado: melhor relação custo benefício olhando apenas hardware e software! Sem mão-de-obra qualificada, pode ser que seja tão difícil montar e operar um cluster Hadoop que outras soluções mais caras podem ter, no final, uma relação custo-benefício mais interessante!
SEMPRE considere a necessidade, o custo e a disponibilidade de mão-de-obra especializada!! SEMPRE!!!
E, claro, Hadoop é uma boa opção toda vez que for preciso arquivar um grande volume de qualquer coisa que não seja usado online, como arquivos, históricos, logs etc.
Profissional de BigData?
Gostou do que viu? Tem interesse em saber no quê trabalha, quanto ganha e que sofrimento passa um profissional dessa área? Enfim, é a sua vida… ;-)
Há duas grandes áreas: Infra-estrutura e Aplicação em si.
Como o próprio nome diz, montar e sustentar a infraestrutura de um cluster Hadoop requer conhecimento multidisciplinar: redes, sistemas operacionais, Linux (fundamental!) e assim por diante. Até ajuda saber programar Java, ou no mínimo entender o assunto, mas não é um pré-requisito. Invista em cursos de qualidade, começando por um sobre Hadoop e depois avançando nos sub-tópicos. Isso vai te dar capacidade para entender os problemas que assolam ambientes Hadoop e a fazer otimizações mais sofisticadas, te distinguindo no mercado de trabalho.
Agora, você gosta mesmo é de sujar as mãos escovando bit até deixar um algoritmo tinindo de brilhante, seu caminho no Hadoop é praticamente o mesmo de um Analista de Data Mining: é obrigatório conhecer bem e ter experiência com Estatística e Matemática. A partir daí é necessário saber transformar esse conhecimento em modelos matemáticos a partir dos dados disponíveis, o que é feito usando-se o ferramental de Data Mining, como R, RapidMiner, SAS Enterprise Miner, SPSS, Python e/ou similares.
Mas todo esse conhecimento é apenas para sua fundação. O profissional que vai fazer a diferença, que vai elevar seu salário à estratosfera é aquele que tiver visão de negócio e habilidades de desenvolvedor. É aquele que souber entender o negócio da empresa e traduzir aquilo em perguntas aos dados, e a moldar as respostas em conceitos que possam ser transformados em algoritmos.
Esse sempre foi, é e sempre vai ser O cara. ;-)
Hoje em dia essa função leva um nome vistoso, para o qual eu sempre torço o nariz: Cientista de Dados. No fundo, porém, o mesmo de sempre: Analista de Data Mining.
Conclusão
Meu propósito era ajudar os alunos da FATEC a entrar com o pé direito no tema. Não tenho como avaliar o resultado e saber se eu atingi ou não esse objetivo. O feedback dos alunos foi bastante positivo, e a recepção foi boa. No mínimo, portanto, eu atendi a um anseio deles.
Uma coisa que me chamou a atenção foi o fato de ter ali não apenas cursos de TI em geral, mas também alunos do curso de Secretariado Executivo. Porquê? Oras, se tem uma coisa que é distante de BigData, em uma empresa, é a disciplina de administração/secretariado/gestão em geral. Mesmo que se argumente que BigData é o futuro e que logo a estratégia da empresa vai estar calcada em resultados obtidos graças à essas tecnologias, me parece um exagero colocar o assunto em uma faculdade tão distante de TI quanto Secretariado. Na minha opinião, é o mesmo que ensinar bancos de dados transacionais para o pessoal de Biblioteconomia porque usam sistemas OLTP.
Essa observação alimentou minha palestra seguinte, na PUC do Rio Grande do Sul. Mas isso é o assunto do próximo post.
Até lá! ;-)
Uma expressão inglesa, “to add insult to injury” ↩
Common-Of-The-Shelf, ou “de prateleira”. Significa coisas padronizadas, baratas – algo como uma commodity. ↩↩
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.
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.
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.
‘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!”
;-)
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. ↩
Mostrei meu post Lago ou Pântano? a um colega de trabalho e ele matou a pau. O comentário dele foi tão interessante que eu resolvi publicá-lo aqui, como uma lição para todos nós.
Mas eu não vou entregar assim de graça, vocês vão ter que ler até lá. ;-)
Data Lake
Você pode ler sobre o conceito direto do pai dele, James Dixon, neste post. Em resumo, DL é uma tecnologia que captura “tudo”, direto para um repositório Hadoop, e que fica disponível para quem quiser usar. Esse paradigma coloca uma série de questões. Por exemplo:
Se dados no Hadoop não aceita updates, como lidar com incrementos?
Devemos capturar as fontes de dados e seus metadados?
Como arquivar as evoluções de layout da origem?
Como tratar tempo-real?
E assim por diante. Essas questões, dirão vocês, provavelmente foram resolvidas na cabeça do Dixon, ou então são partes das dores evolutivas de uma nova tecnologia. Não discordo de nenhum destes argumentos. Em TI nada nasce completo, e faz parte do ciclo de vida de cada nova tecnologia se aprimorar e se apurar a cada nova versão.
Estudando para escrever este post eu acabei assistindo este vídeo, que mostra como injetar dados em um Hadoop automaticamente. Preciso admitir que é impressionante. Na verdade, estou morrendo de vontade de testar, mas para um caso de uso muito específico: stage!
O Problema de um Data Lake
Se aqueles detalhes são apenas isso, detalhes técnicos, e não são problemas, quais são os problemas que um Data Lake coloca?
Ora, muito simples. Se ele é mesmo uma réplica de todos os dados de todos os sistemas de uma organização, então ele carrega os mesmos problemas de usar os dados na origem:
Sujos;
Não-integrados;
Não-documentados;
Inconstantes.
São exatamente os problemas resolvidos por um projeto de DW, que mira em entregar dados prontos para uso a partir de várias origem. Ou seja, um projeto de DW promete entregar:
Dados limpos, prontos para consulta;
Integrados;
Com uma explicação clara sobre sua função e origem;
Imutáveis.
Portanto, ou o projeto de Data Lake incorpora, por definição, um subprojeto de DW, ou o usuário final deve fazer isso tudo sozinho!
Posso ouvi-los cantando meu nome:
“Fábio, Fábio, Fábio, homem de pouca fé! É óbvio que o cliente não está sozinho!”
Não? Então os usuários de Data Lake vão trazer apoio para entender e integrar os dados… De onde? Do sistema de origem, dos próprios DBAs e tals? Bom, se essa é a solução, ok, quem sou eu para desdizer!
Estou zoando, mas a questão é séria. O usuário vai até o DL e, sozinho, escolhe as fontes de dados? Como ele vai saber qual daqueles arquivos contém o dado que ele precisa, ou que é que significa cada uma daquelas colunas e tabelas? E como saber de que forma cada tabela se liga com outras tabelas?
Não tem como se virar sozinho, 100% sozinho, em um curto espaço de tempo. Raramente a informação sobre os dados existe empacotada em algum lugar, à disposição de quem precisar. Geralmente esse conhecimento todo está espalhado em documentos de sistema, na cabeça de DBAs e na cabeça de usuários de cada sistema. Se virar sozinho com o Data Lake implica em gastar muito tempo e, mesmo assim, provavelmente gastaria esse tempo perguntando coisas a quem sabe.
Lembrando que cada novo consumidor deste Data Lake vai repetir os mesmos caminhos. Depois de recuperar os dados, ainda precisa tratá-los de alguma forma – limpando-os e integrando-os – para depois carregar em alguma estrutura que permita a consulta dos dados, o uso destes dados para um propósito qualquer.
É como se trocássemos uma padaria, na qual compramos o que precisamos, por um grande silo que visitamos para comprar o trigo, e depois em casa convertê-lo em pão, macarrão, biscoito etc.
Já pensou que terror??
Manhê! Dá um Negresco?
Peraí, filhote…
Mas mãe, faz duas semanas que você diz “peraí”… Esse biscoito num assa nunca?
Assar, até assa, meu filho. E fazer o chocolate para misturar com a farinha para fazer o biscoito, nem foi tão difícil. O diacho é secar o tacho de caldo-de-cana para conseguir o açúcar mascavo para conseguir o açúcar refinado para fazer o recheio com o leite que seu pai trouxe lá da fazenda da Parmalat… E nem pense em pedir bife à parmeggiana de novo!!!
:-D
Até parece Minecraft…
Só para constar, o mundo já foi assim. Naquele tempo alguém percebeu que poderia fazer algum dinheiro transformando o trigo em farinha, e outro percebeu que poderia vender macarrão com a farinha do fulano, e assim por diante, até chegarmos neste nosso mundo de Pães de Açúcar, padarias e postos de gasolinha em todas as esquinas.
JÁ PENSOU TER QUE REFINAR PETRÓLEO EM CASA???? :-O
Conclusão
Eis a conversa com meu amigo, regalem-se:
(09:15:36) Fábio: Você entendeu, não?
(09:16:09) Colega/DEPTO: o super-herói precisará entender todas as regras de todas as bases de origem
(09:16:44) Fábio: ISSO!!!!! :-D
(09:17:25) Fábio: É tão bem colocado que eu vou fazer um take dois!
(09:17:26) Colega/DEPTO: vai lá procurar uma orquídea dentro de um pantano!
(09:17:44) Colega/DEPTO: o jacaré vai te comer
(09:17:58) Fábio: quá quá quá!
(09:18:23) Fábio: O nome desse próximo post vai ser A Orquídea, O Pântano e o Jacaré.
Vamos destacar, imprimir e pendurar na parede:
Sobre Data Lakes:
O [usuário] super-herói precisará entender todas as regras de todas as bases de origem. Vai lá procurar uma orquídea dentro de um pântano! O jacaré vai te comer.
Vitor Rosan
Savan Extraordinaire
Falou pouco mas disse tudo! ;-)
10/10/2016 08:10:41 – Complemento
Cheguei no trabalho, abri meu IM e pulou:
(05-10-2016 17:14:06) Vitor: boa tarde (05-10-2016 17:14:20) Vitor: está ocorrendo aquilo que você profetizou no seu blog, sobre o datalake (05-10-2016 17:14:55) Vitor: tem muitas pessoas tentando obter dados da base do dw recorrendo a mim para explicar como achar o caminho no meio do pântano
Reparem que ele comenta sobre a minha “professia” do Data Lake, mas depois fala do DW. Eu não entendi na hora, mas a explicação é simples: ainda nem entrou o Data Lake no ar, nem começou, e o problema de entender os dados já está acontecendo em um DW normal, com gerenciamento insuficiente.
Há duas regras que eu procuro respeitar nos meus posts: não publico nada que eu mesmo não gostaria de ler e nunca repito algo que já foi publicado por aí. Entretanto, em alguns casos o assunto que já foi publicado é tão relevante, e está tão bem escrito, que eu me sinto na obrigação de dividir meu achado, e este é o caso do post de hoje.
Eu havia planejado dois posts sobre o conceito de Data Lake, tal qual eu fiz com Data Discovery. Ao começar a pesquisa eu topei com um artigo do Gartner falando justamente sobre esse assunto: Gartner Says Beware of the Data Lake Fallacy. Eles colocaram o problema de uma forma tão simples, clara e lúcida que se meter a querer fazer algo melhor seria uma pretensão muito maior que o meu normal – e olhe que eu sou um cara pretensioso pra chuchu! Devo ser o cara mais pretensioso mundo, mas felizmente minha modéstia também é enorme, o que me salva.
:-DEntão, ao invés de refazer o trabalho eu vou apresentar o artigo do Gartner.
A Questão
Em 2010, James Dixon publicou um post num blog Pentaho apresentando a motivação e o conceito de um Data Lake:
Motivação
James Dixon conversou com várias empresas que usam Hadoop e descobriu que cerca de 80-90% deles usam dados estruturados ou semi-estruturados, mas não “desestruturados”, sendo que a fonte desses dados é quase sempre um só sistema transacional. Mesmo assim nem tudo é dado transacional, e apesar de várias perguntas sobre esses dados serem conhecidas, muitas mais – desconhecidas – podem vir a ser formuladas no futuro. Em geral existe mais que uma ou algumas comunidades de usuários interessados nestes dados, que são gerados ou processados em um passo muito superior ao que um SGBDR aguenta.
Definição
Se você pensar que um data mart como um armazém de água engarrafada, que foi limpa e empacotada para consumo, um Lago de Dados (aka Data Lake) é o corpo de água em um estado mais natural. O conteúdo dos sistemas de origem fluem para dentro do Data Lake, e vários usuários do lago podem vir examiná-lo, mergulhar nele ou levar amostras.
Francamente, para mim é o mesmo que dizer que você pode comprar farinha pronta no supermercado, mas ir até a fazenda comprar grãos direto do armazém. Enfim, adiante.
A partir daí o hype tomou conta do debate, e tudo passou pelo processo de “binguificação corporativa”, que é aquele mecanismo em que os chavões da hora vão parar em tudo que é reunião de estratégia, documento de intenções, briefings, pings para manter as coisas in the loop blá bláh blah yadda yadda yadda.
Resultado? Em 2016 não se acham Data Lakes “na natureza”, nos grandes espaços selvagens do mundo corporativo. Traduzindo: ninguém ainda veio a público dizer que implementou um e que resultados está tirando deles.
Mais ou menos a mesma coisa pela qual passou Mobile BI, Business Discoveryt/Data Discovery, e em boa parcela o mesmo pelo qual BigData ainda passa. Mas BigData é outro assunto, para outro dia, outro post.
Fiat Lux!
E aí vem o artigo do Gartner. Não quero repetir palavra por palavra, do contrário eu prestaria a vocês um serviço melhor só informando o link ao invés de escrever meu próprio post. Vou colocar as minhas críticas e depois o que o artigo do Gartner fala, e então bater os dois.
Seis por Cinco e Meio
Meu primeiro cisma com DL (Data Lake) é o fato de que ele não trazer algo de realmente novo: muitos outros projetos fazem cópias simples dos dados de um sistema para outro repositório. Na verdade, é a abordagem de praticamente todos que assumem um projeto de DW sem estudar o assunto antes. Como não sabem o que vão fazer, começam fazendo o óbvio: copiam tudo, e geram os produtos de dados a partir deste dump.
Vejam o que o Gartner coloca:
Nick Heudecker, research director at Gartner(…) “The idea is simple: instead of placing data in a purpose-built data store, you move it into a data lake in its original format. This eliminates the upfront costs of data ingestion, like transformation. Once data is placed into the lake, it’s available for analysis by everyone in the organization.”
However, while the marketing hype suggests audiences throughout an enterprise will leverage data lakes, this positioning assumes that all those audiences are highly skilled at data manipulation and analysis, as data lakes lack semantic consistency and governed metadata.
Em Português é mais ou menos isso:
Nick Heudecker, diretor de pesquisa no Gartner: “A idéia é simples: ao invés de colocar os dados em uma estrutura construída com especificamente para arquivar os dados, você move-os para dentro do Data Lake em seu formato original. Isso elimina os custos iniciais de ingestão e processamento dos dados de origem. Uma vez que esteja no lago, o dado fica disponível para todos na organização.”
Entretanto, se o hype dá a entender que as comunidades de usuários por toda empresa vão aproveitar um DL, então ele está sugerindo que todas essas comunidades são altamente habilidosas com manipulação de dados e análise, já que um DL não traz consistência, uniformidade e gestão dos metadados.
E nós sabemos que isso não é verdade. Eles vão adiante na questão e terminam (resumindo:)
Um DL tenta resolver dois problemas, um velho e outro novo. O velho é acabar com silos de dados: ao invés de ter várias fontes controladas de dados, jogamos tudo num só repositório, sem modificações. A consolidação, teoricamente, traria um maior uso dos dados enquanto reduz custos com licenças e servidores.
O novo tem mais a ver com BigData: pela própria disparidade das fontes, nem sempre dá para catalogar o dado na chegada e acomodá-lo em um SGBDR pode limitar futuras análises.
Atacar esses dois problemas com certeza beneficia a TI no curto prazo, no sentido de que reduz o trabalho para acomodar os dados, segundo o Sr. White. Porém, achar valor nestes dados permace tarefa do usuário final. Mas por mais que a aplicação de ferramentas ajude nisso, sem um mínimo de gestão tudo que conseguiremos é um monte de dados desconexos arquivados no mesmo lugar.
Bingo! E logo em seguida ele fala dos riscos de transforma um DL em um pântano se não houver um mínimo de gestão sobre ele. Ou seja, ao trocar um DW normal por um Data Lake arriscamos perder mais que ganhar. Arriscamos? Não, nós vamos perder, se não houver um mínimo de governança em cima desta infra-estrutura.
O Barato Sai Caro
Qualquer um que já passou pela frustrante experiência de manter um projeto de DW baseado em dumps sabe que a promessa de economia de tempo e recursos desse formato nunca se realiza. Fazer um dump pode até ser mais rápido que, por exemplo, desenhar um Data Mart e seu ETL. Porém, mais tarde, esses projetos batem com problemas que desperdiçam muito mais tempo que o rápido início economizou.
Um destes problemas é justamente racionalizar o uso dos recursos para poupar carregar o banco inteiro a cada atualização. A solução que sempre encontram é capturar um “delta”: comparar o sistema de origem com o dump no “DW” e trazer apenas as diferenças.
Mesmo assim há um custo em hardware e tempo inevitável. À esse custo os adeptos do DL respondem com a velocidade de carga do Hadoop, invariavelmente o miolo de DLs.
Outro problema é que a cada demanda do usuário por uma análise ou relatório, um novo ETL pós-dump precisa ser produzido. Até aí tudo bem, porque qualquer projeto de DW enfrenta isso. O problema é que qualquer alteração na origem “quebra” tudo que depende do dump e do nada surge uma montanha de retrabalho.
Ao que os seguidores do DL contrapõe outro argumento: self-service! Só que explorar um Data Lake não é para qualquer por dois motivos:
A pilha (stack) de tecnologia necessário é imensa. Um profissional especializado teria dificuldades, imagine um cara do Marketing?!
É preciso entender os dados e como eles “funcionam” para poder extrair valor deles. Nem mesmo todos os DBAs de uma empresa costumam saber tudo sobre os dados, quanto mais um leigo… do departamento de Marketing!!!
Entender muito de uma coisa faz com que tendamos a entender menos de outras. Marketing é uma ciência que se aproxima da arte, assim como muitas outras funções em uma empresa, e o custo de saber tanto do negócio da empresa é a tendência a saber menos de coisas como TI e BI. Não tenho nada contra “o Marketing”, só acho um bom exemplo do conflito entre a necessidade da informação e a capacidade de manuseio das ferramentas.
Viram o tanto que eu gastei de letras para explicar a idéia? Olhem e aprendam com quem sabe o que faz:
“The fundamental issue with the data lake is that it makes certain assumptions about the users of information,” said Mr. Heudecker. “It assumes that users recognize or understand the contextual bias of how data is captured, that they know how to merge and reconcile different data sources without ‘a priori knowledge’ and that they understand the incomplete nature of datasets, regardless of structure.”
While these assumptions may be true for users working with data, such as data scientists, the majority of business users lack this level of sophistication or support from operational information governance routines. Developing or acquiring these skills or obtaining such support on an individual basis, is both time-consuming and expensive, or impossible.
Sintético, completo, preciso! Elegante! Em tradução livre:
“A questão fundamental que um DL traz é que partimos de certos pressupostos sobre os usuários da informação”, disse o Sr. Heudecker. “Assume-se que os usuários reconhecem ou entendem o viés contextual de como os dados são capturados, que eles sabem como juntar esses dados e reconciliar diferentes fontes de dados sem um conhecimento prévio e que eles compreendem a natureza de incompletude dos conjuntos de dados, independentemente da estrutura.”
Ainda que esses pressupostos possam ser verdade para usuários que trabalham com dados, como cientistas de dados, a maioria dos usuários de negócios não possui esse nível de sofisticação ou apoio dos procedimentos de governança de informações operacionais. Desenvolver ou adquirir essas habilidades ou obter tal suporte em uma base individual e caro e demorado, ou impossível.
Eles vão no miolo da questão: propor um Data Lake presume que os usuários são de um tipo que quase não existe, e que transformar um usuário comum nesta figura de super-usuário é caro, se não impossível.
Outros Casos
O artigo segue adiante para discutir outros aspectos e riscos presentes em uma iniciativa de DL, mas o fulcro é sempre o mesmo: a falta de gestão do repositório, e a excessiva dependência do usuário final para geração de valor.
A certa altura vem este comentário (tradução livre:)
DL normalmente começa com repositórios de dados sem “governo”. Atender as necessidades de uma audiência mais ampla requer repositórios organizados, controlados, consistentes e com controle de acesso – elementos já disponíveis em um DW.
Conclusão
E o que tiramos disso tudo? O Gartner é bem simpático (tradução livre:)
White: Sempre há valor a ser encontrado nos dados, mas a questão que sua organização deve atacar é esta: “nós permitimos e até encorajamos análises que ocorrem uma única vez, autônomas, de dados que estão em silos ou em um Data Lake, unindo esses dados para aquela análise apenas, ou nós formalizamos esse esforço até certo ponto, e tentamos sustentar as habilidades que geram valor?” Se vamos endossar o herói, o agente solitário, um Data Lake com certeza possui um grande apelo. Se estamos mais tendentes à alternativa, um uso mais formalizado, então é melhor deixar o DL para trás e seguir para adotar uma estratégia baseada em DW.
Eu, bom, eu sou mais marrento mesmo, então as conclusões a que eu chego são:
Data Lake parece mais um conceito experimental que um produto ou serviço concreto e acabado;
Ainda não existe um caso de uso claro, ou mesmo nublado, que sirva para uma organização decidir-se pela adoção de um DL;
O conjunto de riscos e dificuldades associados a um DL supera de longe quaisquer prováveis benefícios.
Eu sempre digo que BI é uma disciplina, mais que ferramentas ou técnicas. Sempre que aparece uma tendência de mercado como o Data Lake (e Data Discovery, Cientista de Dados etc. etc. etc.), eu fico com o pé atrás, pois parece muito mais um tipo de Marketing do que uma tecnologia nova.
Talvez um dia evolua e torne-se uma peça valiosa do arsenal de BI. Mas por enquanto, por mais que adore a Pentaho e o Pentaho (e eu gosto muito dos dois, por enquanto), eu não vejo motivo para investir em um DL. Na verdade, eu vejo um alto risco de um projeto de DL acabar em problemas caros, ou até mesmo fracasso total.
Geek BI 