Eu sempre implico com nomes “da moda” porque, na minha opinião, eles desvalorizam o profissional sedimentado, experiente, abandonando expressões que funcionam por um palavreado mais colorido. Ocasionalmente a coisa muda, claro, e esses nomes precisam mudar junto, mas em TI há uma competição disfarçada para ver quem vem com a próxima buzzword. No final essa disputa acaba por atrapalhar a vida da TI porque tanta mudança forçada impede a construção de senso comum e de uma cultura particular.
Pergunte a um engenheiro mecânico o que é um carburador, ou se eles usam “camâras adiabáticas para oxiredução explosiva”. Ou para um financista se ele fala juros compostos, ou “taxa de interesse recursiva”.
Entendeu a idéia? Para quê mudar uma expressão se ela adequa-se perfeitamente?
Pior: uma pessoa errada, mas com muita certeza, vai levar outros a errar também. É preciso estar de posse de um conhecimento sólido para poder resistir à pressão do hype corrente.
Big Data, Hiper Hype
Nestas últimas semanas eu tenho escrito sobre BigData, mas ontem eu não tinha assunto. Eu não sabia sobre o que postar, e depois de um dia cheio e tela em branco, eu simplesmente desisti.
Sem inspiração? Que tal tocado como gado?
Hoje eu acordei e olhei de novo para minhas anotações e achei este rascunho aqui, sobre a Revista Exame, e vi um bom fechamento para a série. Junte-se a isso que eu repeti minha palestra sobre BigData para a Fatec Zona Sul, cujo foco era desfazer confusões antes de começarem.
Leia a reportagem, é interessante. Entretanto, lá no meio, quando tudo estava indo bem, algo dá errado:
“O big data não se resume a um processo de automação. Seu objetivo é entender melhor o que acontece numa empresa, o que os clientes querem e, assim, modificar o negócio”, diz Jorge Sanz, diretor do Centro de Business Analytics da Universidade Nacional de Singapura, um dos grandes centros de big data da Ásia. Esse processo requer softwares capazes de captar os dados relevantes — e, acima de tudo, pessoas treinadas para interpretá-los.
Eu copiei o parágrafo inteiro como está. Releia. Releu? Entendeu? De novo, devagar:
“O big data não se resume a um processo de automação.”
“O” big data? Agora é uma coisa só, um objeto que anda por aí, e não mais uma tecnologia, mas um objeto. Ok, vamos dar uma colher de chá, já que muitos profissionais ainda chamam BI de “O” BI.
“Não se resume a um processo”: então “big data” é um processo? Se ele diz “não se resume”, então ele já classificou o assunto como um processo; apenas vai adiante e diz que não é apenas um processo – mas implica que é um de qualquer forma. Ou seja, passou de tecnologia-objeto (que demanda o tal do artigo definido masculino singular, “O”) para uma coisa que também é um processo. Mais uma confusão, mas vamos relevá-la de novo, em favor da prosa da reportagem.
“De automação”: e de onde veio isso? Do parágrafo anterior no artigo, onde ele começa associando computadores a automação. Até são coisas relacionadas, mas chamar Hadoop de automação é um pouco demais. Mas mesmo assim, vamos em frente.
E aqui o assunto descarrilha de vez:
“Seu objetivo é entender melhor o que acontece numa empresa”
É um repórter competetente, entrevistando um executivo relevante de uma enorme instituição financeira nacional. Quer dizer, não é um par de manés, não! São profissionais experientes, gabaritados e entendidos no assunto…
… que meteram os pés pelas mãos. Há décadas existe um termo que usa como definição justamente essa frase – Seu objetivo é entender melhor o que acontece numa empresa: Inteligência de Negócios, vulgo BI.
O que ele fez foi chamar uma coisa de outra. Foi vender banana anunciando carambola, já ambas são compridas, amarelas, tem casca, são frutas… Só que não são a mesma coisa! É um esforço feito para dar ribalta a uma expressão da moda, dando um gancho (sigam este link, é hilário!) em outra!
Fora, Inteligência de Negócios! Agora queremos “o big data”!
Existe uma outra explicação, que é dizer que ele não sabia mesmo do que estava falando, mas isso é um pouco demais para aceitarmos. Afinal, é a maior revista de negócios do Brasil, não um panfleto de bairro. Não atribuiriam a um repórter uma tarefa que ele não conseguisse desempenhar adequadamente. Isso feriria a reputação de ambos – revista e repórter. A menos, claro, que seu público não fosse capaz de perceber a confusão, mas aí é demais para aceitarmos porque estamos falando de um público qualificado, líderes, executivos e profissionais de todos os ramos, conhecedores de assuntos mil…
Entenderam como funciona? Ninguém tem bem certeza do que é algo. Aí a moda vem, avassaladoramente, e sacode tudo junto. No final fica parecendo aquela piada:
O bêbado entra no ônibus, passa a roleta e vai para trás. De lá, grita:
Do lado direito todo mundo é palmeirense! Do lado esquerdo todo mundo é corintiano!
Ao ouvir isto, levanta um do lado direito e fala:
Eu não sou palmeirense!!!
E todo os passageiros começaram a xingar o bêbado e ameaçando cobri-lo de bolacha. O motorista, para evitar confusão, freia bruscamente e todos caem. Um dos passageiros se levanta, pega o bêbado pelo colarinho e pergunta:
Fala de novo, safado! Quem é palmeirense e quem é corintiano?!
Agora eu não sei mais. Misturou tudo…
Não dá mais para saber quem é quem, porque o jornalismo especializado misturou tudo.
Conclusão
A reportagem segue nesse mesmo ritmo, dando novos nomes a coisas já estabelecidas. Por exemplo, em certo momento ele diz que os cientistas de dados têm remuneração superior à dos técnicos, que até o surgimento do big data eram os responsáveis por cuidar da manutenção dos bancos de dados. Ele misturou DBAs com analistas de DW/ETL, com Analistas de Data Mining, com Hadoop, com Bancos Relacionais… Em metade de um parágrafo, em menos de 30 palavras, causou-se estrago para pelo menos três áreas:
DBAs fazem a mesma coisa que cientistas de dados se você não usar “big data”;
Cientistas de Dados são DBAs para “big data”;
A manutenção de um Hadoop, uma plataforma de clusterização escrita em Java, é feita por um cientista de dados, enquanto que a de um Oracle, um banco de dados relacional, é feita por um técnico, e são a mesma coisa do ponto de vista funcional;
E Data Mining?
Esse tipo de artigo confunde um número de conceitos complexos para uma audiência em geral leiga nestes mesmos tópicos. Por ser um veículo de projeção nacional e respeitado, bem-conceituado, muitos tomam o que sai ali por fato, por verdade canônica. Aos poucos essas confusões tomam o lugar das verdades nas empresas, impactando planejamento, contratações, e até debates. Como é que um cara qualquer, um joão-ninguém como eu pode argumentar com o “repórter da Exame”? A quem acreditam vocês que o público atribui maior conhecimento? :-)
E pior ainda: como é que um profissional recém-formado pode querer colaborar com a empresa, se tudo que ele fala é contestado pelo chefe que viu tudo diferente na revista de negócios mais famosa do Brasil?
Tem mais razão e está mais certo que fala com mais convicção? Não, né? Repasso aqui o conselho que dei àqueles alunos das FATECs:
Use sua inteligência para filtrar. Critique e questione tudo. ;-)
Trabalho na indústria de BI há 16 anos. Hoje em dia dá-se muito destaque a um tipo de dados considerados especiais, até meio místicos, como se guardassem a chave para as respostas de todas as perguntas não-formuladas. São os tais dos chamados dados não-estruturados.
Não vou debater semântica, ou nomenclatura, mas o fato é que esse tipo de dado existe desde sempre. Tanto é assim que há um campo inteiro dedicado a produzir conhecimento a partir de fontes hoje ditas “não-estruturadas”. Esse campo chama-se Text Mining, uma extensão do conceito de Data Mining. São as técnicas aplicadas em, por exemplo, soluções de análise de sentimento.
Assim como eu tenho algumas ressalvas com todo o hype em volta de BigData, também tenho minhas reservas quanto ao endeusamento desse tipo de dado. A minha bronca é que essa atitude não raro decorre de modismos, em geral carentes de significado mais concreto, cunhados a fim de encher a cabeça do cliente e ocasionalmente levá-lo a comprar alguma coisa.
Compra quem quer, deixa-se levar por modismos quem quer. Longe de mim atrapalhar a liberdade que cada um tem de se deixar convencer! Entretanto, eu não posso deixar de tocar no assunto. Encare este post como mais um argumento em um longo debate em busca da verdade. ;-)
A maior parte dos dados úteis para análises são justamente os que refletem algum processo, e por isso são capturados em sistemas transacionais ordinários. São dados que vivem em tabelas ou, no máximo, arquivos com algum layout padronizado. Já os tais dos dados não-estruturados não possuem “nenhuma” regularidade. Então tá, se sairmos desse domínio – se deixarmos os sistemas transacionais e suas tabelas padronizadas para trás – o que temos?
Vou ver um exemplo para ficar mais claro.
O Governo Federal tem a missão de gastar o dinheiro da melhor forma possível. Suponha que decidiu-se estabelecer a relação entre o atendimento do Bolsa-Família (BF) e a melhoria da educação. Isso é importante para permitir que a geração seguinte à suportada pelo BF possa almejar empregos de qualidade e melhorar de vida.
Como correlacionar esses dados? Uma opção é avaliar a relação entre demografia e os índices de escolaridade e frequência, e a cobertura geográfica do BF.
De onde virão esses dados? Dos sistemas de gestão escolar, por certo. Logo, esses dados são 100% estruturados. Estamos falando de capturar as listas de chamada, as notas, o resultado do ENEM, da Provinha Brasil, da concessão de BFs, de mapas… São todos dados estruturados. Mesmo que não venham de um único sistema, quiçá de uma única entidade, todos esses dados “vivem” em estruturas regulares. Com esses dados obtemos o conhecimento mais valioso que existe nos processos de gestão escolar.
Permitam-me colocar de outra forma: obtemos uma informação valiosa sem precisarmos de nenhum dado não-estruturado. E isso vale para a maioria do que está por aí, aguardando ser descoberto.
O dado não-estruturado serve para situações muito específicas, em condições muito particulares. É um nicho naturalmente pequeno – basta pensar quantas empresas/organizações grandes o bastante existem para puxar alguma inteligência dessas fontes, e o tamanho que essas fontes precisam ter para atribuir alguma confiança, estatisticamente falando, aos resultados.
Analiso Ergo Estruturo
Por outro lado, quais fontes de dados não-estruturadas existem por aí?
Textos (web e e-mail;)
Textos (posts em mídias sociais;)
Textos (documentos;)
Vértices de grafos (URLs – textos.)
Um punhado de dados não-estruturados.
Eu com certeza ignoro algumas outras categorias de dados não-estruturados, mas quais? Repassei a lista mas tudo que eu pensava tinha alguma estrutura mais ou menos óbvia, fixa:
Objetos XML: têm estrutura;
Transações entre empresas, como SWIFT: além de privados, têm estrutura;
Mapas: têm estrutura;
Etc…
Ora, o que é uma análise? Pode ser desde uma contagem ou uma média (quantas palavras o post possui, quantas palavras existe, em média, nos posts de cada autor?) a uma coisa mais sofisticada (qual é a chance, para cada assunto, de o autor possuir relação íntima com o dado assunto de seus textos?) Responder a essas perguntas envolve analisar frequências, distribuições, distâncias – números, números, números! Sempre precisamos quantificar em números e qualificar com uma descrição tudo aquilo que desejamos analisar.
Bom, mesmo o exemplo dado na figura 1 (e em geral naqueles elencados no início da sessão) possui alguma estrutura. Por exemplo:
Data e hora de publicação;
Ocasionalmente data e hora de criação e edição;
Versão (1, 2, 3… quando alguém edita o conteúdo e republica o item – doc, post etc.;)
Autor, e todos seus dados;
Tamanho;
Tipo de conteúdos (só texto, só imagem, mistura;)
Relacionamentos;
E, finalmente, o conteúdo em si.
O mesmo punhado de dados, estruturados.
Veja que, ignorando o conteúdo, podemos puxar muita coisa só olhando o restante! Dá para montar grafos diversos, por exemplo, acompanhando o timestamp e relacionamentos entre publicações em blogs e redes sociais. Dá para analisar o sentimento de um conjunto em relação a um assunto.
Análise impõe estrutura: para conduzir uma análise, os dados precisam ser estruturados de alguma forma. Se os dados não possuem estrutura, então não podem ser organizados e, imperiosamente, não permitem análise.
Logo, se os dados podem ser analisados, então eles possuem alguma estrutura. Isso gera confusão com o jargão de TI, que costuma chamar de “estrutura” um container ou padrão de armazenamento digital (isto é, que guarda os dados de uma forma mais ou menos organizada, como uma tabela, uma planilha ou um arquivo texto, representados por sequências de bytes em alguma mídia.)
Conclusão
O meu ponto é chamar a atenção para o hype em volta de dados não-estruturados. Afinal, para podermos conduzir qualquer análise é preciso poder representá-los matematicamente. Quero dizer, é preciso que eles possuam alguma estrutura, por mais incomum ou exótica que seja essa estrutura, ou por mais “escondida” que ela esteja.
Essa tabela mostra o exemplo da estrutura de dados do post em emu Facebook que aparece nas figuras anteriores:
Mesmo dados arquivados sob formatos exóticos (textos, e-mails, páginas web) possuem um mínimo de estrutura matemática apta a análises. Vem daí a afirmação que dá título a este post:
Todo dado (que seja útil para análise) é estruturado, de uma forma ou de outra.
Isso implica em dizer que não existem dados não-estruturados? Pode ser, tanto que esse era o título original deste post. Mas ainda não consigo afirmar isso com certeza.
Há tanto sendo escrito e falado e mostrado sobre BigData por aí que eu simplesmente não tenho muito o que agregar. Mesmo assim, nestas duas últimas semanas eu acabei fazendo posts sobre BigData:
O primeiro define BigData a partir de sua evolução, seguindo o caminho que a tecnologia percorreu até os dias atuais. Já o segundo é a minha opinião sobre o caminho que o assunto – não a tecnologia – vai tomar.
Eu sinto, porém, que há um último tópico a ser “passado a limpo”: a confusão entre o meio e a meta.
O Meio
A história toda começou com várias empresas e organizações buscando uma forma de aumentar a performance da indexação da World Wide Web, ou simplesmente “A Internet”. Esse esforço culminou no surgimento do Hadoop.
As possibilidades do Hadoop aguçaram os visionários de plantão e logo houve o big-bang do BigData. A coisa atingiu a mídia e o hype foi às alturas – tudo era BigData, BigData pra cá, BigData pra lá, BigData no almoço, café e jantar…
Isso dá samba :-)
BigData pra cá, BigData pra lá, BigData no almoço, café e jantar.
E essas possiblidades apareceram graças ao surgimento do Hadoop, que em si é uma arquitetura de ingestão e acesso de dados com limites muito superiores às que existiam até então. Cargas de dados, que requeriam caras combinações de hardware e software, puderam ser tratadas com investimentos muito menores, o que permitiu atacar problemas cuja soluções eram exclusividade de grandes empresas.
A Meta
Existem duas categorias de problemas solucionáveis pelo Hadoop:
Ingestão de dados;
Análises de dados.
Empresas como Facebook, Twitter, Amazon.com etc. são organizações que lidam, naturalmente, com um grande volume de dados, que surge e se modifica muito rapidamente. Capturar esses dados depende de uma infra-estrutura capaz de ler e estocar os dados disponíveis antes de novos dados aparecerem, ou a coisa toda vai por água abaixo.
Por outro lado, não surgiu nada de realmente novo em termos de análises de dados. Tudo que temos hoje foi inventado há décadas. Um ou outro algoritmo sofreu evolução, apareceu uma ou outra técnica mais esotérica, mas o grosso da caixa de ferramentas de análises de dados tem um bom tempo de estrada.
Como exemplo tome uma métrica famosa em Marketing, o Lifetime Value, que estima o valor que um cliente representa para o fornecedor ao longo da sua vida como consumidor. Saber o Customer Lifetime Value (CLV) de cada cliente ajuda, entre outras coisas, a decidir se vale a pena o esforço de mantê-lo, e quanto esse esforço pode ser.
As estimativas mais precisas do CLV são feitas usando-se o conceito de valor atual líquido, ou Net Present Value em inglês. Bom, o uso dessa metodologia remonta ao Século XIX: até mesmo Karl Marx citou esse conceito, cuja popularização aconteceu em 1907 – ou seja, o conceito ficou famoso no início do Século XX!
That Confounded Bridge
Vocês sabem o que acontece quando misturamos gente que fala muito, com coisas que não entendem? Isso mesmo: temos um palavrório que soa como se fizesse muito sentido, mas nem sempre faz. BigData é uma dessas coisas que nem todo mundo entende, mas sobre a qual muitos querem falar. O resultado é que, vira e mexe, alguém solta um “a tecnologia BigData permitirá estimar o valor do cliente para a empresa”.
Pronto: agora você não vai se confundir mais. ;-)
Ora bolas, essa estimativa é feita desde o século XIX! Como assim “o BigData permitirá”? Não permitirá porcaria nenhuma – não tem nada a ver! Ele está misturando alhos com bugalhos!
Dando o crédito a uma eventual notícia dessas, pode ser que o uso de Hadoop vá baratear o cálculo do CLV a tal ponto que permita aumentar sua precisão ou incluir dados de outras fontes no algoritmo. Mas, em si, essa medida já existia, já era feita e não é nenhuma novidade, muito menos algo trazido pelo Hadoop e menos ainda coisa de “BigData”!!!
Conclusão
Hadoop é a tecnologia que deu origem ao mercado de BigData, e o centro dele ainda hoje. Hadoop não tem absolutamente nada a ver com Data Mining, que é um processo de extrair modelos matemáticos e outros quejandos dos dados. O casamento do Hadoop com as técnicas de Data Mining rende muito, mas…
Não confunda as coisas. Ou os Coisas. Que coisa confusa…
Desta feita o Jorge havia convidado luminares de Data Mining, de BigData e eu, vosso modesto (ha-ha) escriba. Antes de mim falaram Sérgio Blum e João Gutheil, e depois falou o Irio Musskopf. Vou apresentá-los a vocês e contextualizar a discussão que vinha sendo feita e logo depois eu coloco o ponto que eu levantei no debate.
Casa cheia!
Sérgio Adriano Blum
Instrutor, gestor de projetos e consultor em Tecnologia da Informação pela White Cube, ele apresentou um painel com opções tecnológicas, ferramentas, cases e cenários do mundo BigData/Data Mining. Sigam este link para o post do Jorge, onde vocês podem baixar o material que ele disponibilizou em PPT. Você também pode entrar em contato com o Sérgio por meio de sua página LinkedIn
Um apanhado geral das tecnologias associadas a BigData.
João Gutheil
O João é um conhecido meu de longa data – já batemos papo desde o começo de 2015. A apresentação do Gutheil ligou BigData com Data Mining, detalhando abordagens, valor entregue em diferentes áreas e segmentos de mercado, ferramentas e plataformas, fechando com cenários para futuro próximo.
Vale destacar que ele é um dos vice-coordenadores do Grupo de Usuários de BI (GUBI) da SUCESU-RS. Ou seja, o cara não é fraco, não.
Minha fala foi logo depois da dele, e eu usei o que ele explicou como ponto de partida. Mas segure aí – vamos terminar os convidades e eu já volto.
Irio Musskopf
O Irio é uma daquelas pessoas que tem a rara oportunidade de fazer algo de concreto e impactante para seu país. Ele falou sobre o desafio do uso de Machine Learning na Operação Serenata de Amor, que usa mineração de dados para mapear e destacar anomalias nas prestações de contas de políticos. Para custear esse projeto foi aberto uma conta na Catarse – não deixe de conhecer, é impressionante.
Usando Data Mining e Robôs para pegar malfeitos!
A CodeLand é uma empresa de desenvolvimento web ágil, especializada na liberação de novos negócios digitais.
Explodindo o BigData e Mostrando o Creeper!
Bom, quando eu entrei o Irio seria o próximo, e o João Gutheil tinha acabado de mostrar como BigData e Data Mining poderiam ser usados para resolver problemas reais, concretos, de empresas.
Eu falei sobre minha apresentação do dia anterior, na FATEC, quando eu fiz justamente uma introdução ao assunto. Comentei, então, que na minha opinião BigData é a mesma coisa que Hadoop e que é uma tecnologia útil para resolver problemas com um volume burral de dados – um volume que não cabe dentro de uma só máquina.
Eu coloquei minha primeira pergunta: onde está a maior parte dos dados que giram pelas empresas no Brasil?
Sabemos que a maior parte dos empregos, no Brasil, estão em empresas de médio e pequeno porte, e até menores. Será que o volume de dados tratado por essas empresas também se distribui segundo essa regra? Intuitivamente eu suspeito que não. Eu desconfio que a maior parte das empresas no Brasil recolhem apenas uma pequena parcela dos dados transacionados no país.
Daí eu comecei a levantar outros pontos, que há coisa de um ano começaram a despertar minha curiosidade:
Certos usos dos dados não se dão bem com o modelo de operação em lote (batch) do Hadoop. Cubos OLAP são um caso, relatórios são outro. Até porque uma coisa é coletar um volume monstruoso de dados, e outra é usar parte desse volume como fonte para um cubo;
Um volume muito grande de dados pode ser tratado usando-se algumas outras tecnologias, como por exemplo clusters de bancos de dados relacionais, e até mesmo clusters de bancos de dados colunares. Esse tipo de tecnologia cabe na descrição de “BigData” mas ainda não é Hadoop, e se presta a coisas como, de novo, cubos OLAP, que são um ponto fraco do Hadoop ainda;
Por fim, o volume de dados que justifica a adoção de Hadoop é realmente uma coisa fora-do-comum. Quantas empresas existem que lidam, que captam um volume de dados deste porte?
Mais ainda: das empresas que coletam um volume gargantuesco de dados crús, quantas possuem problemas que requerem uma parcela tão grande desses dados que esse subconjunto seja, por si sói, um problema de BigData?
Vocês hão de concordar comigo – como de fato concordaram na hora – que não é a maioria das empresas que possuem um volume de dados que sirvam para alguma coisa e que estejam na casa do Hadoop.
Minha intenção, eu expliquei, era conseguir deles a concordância para o seguinte ponto: “não é toda empresa que precisa usar Hadoop”. Eles concordaram, já que eu havia colocado uma dúvida razoável quanto à tecnologia necessária para o tratamento de dados na maior parte das empresas – se a maior parte de empresas de um país são pequenas e médias, e elas lidam com volumes de dados que dispensam Hadoop, então não é a maior parte de empresas que precisa de Hadoop. Simples e razoável, não?
Neste momento pedi ao Jorge que colocasse esse e-mail para a platéia:
Como resolver o problema de Hadoop dos seus usuários…
Notaram como ele 1) presume que você tinha um problema de BigData que foi resolvido e 2) assume que ele não deu totalmente certo, porque ainda existe gente reclamando que não está vendo o que queria? Esse “now what?” é bem chatinho! Como assim, e agora o quê? Oras, de onde ele tirou a associação entre usuários finais e Hadoop? Quem disse que Hadoop resolveria 100% dos problemas de BI de uma empresa?
É muito chute em tão pouco espaço.
Outro ponto: contei-lhes que na apresentação da FATEC eu tive muitos espectadores de cursos hardcore de TI, como Análise de Sistemas, e Hardware. Mas eu tive a presença de vários alunos de Secretariado!
Me digam, pedi a eles, não é estranho que um curso tão “humanas” coloque no espírito do aluno inquietude o bastante para ele se arriscar em uma palestra técnica sobre Hadoop/BigData?
Mais: a lotação foi muito maior que a sala comportava, e era uma sala quase do tamanho da do TechnoTaks. Já não tinha mais espaço nem para sentar-se no chão… do corredor!! Era muita gente querendo ouvir sobre um treco que, ao cabo e ao fim, tem um uso muito restrito.
Tem uso mais restrito que Data Mining, aliás. Quase toda empresa pode se beneficiar de Data Mining. Mas poucas têm uso real para Hadoop, BigData e outros quejandos deste porte!
Vestido para detonar! Kkkkk…
Eu participei do TT remotamente. No plano original eu estaria em um Hangout com a turma em Porto Alegre, e poderia ser visto. Por isso, considerando-se o que eu estava tramando soltar, vesti-me a caráter: com uma camiseta de Minecraft. Claro, pois se eu pretendia detonar boa parte do nosso senso-comum, nada tinha mais significado que me vestir de Creeper.
“Ora”, falei, me encaminhando para o fechamento:
“Se existe tanta propaganda sobre BigData/Hadoop, a ponto de mobilizar muita gente, e de áreas pouco relacionadas; se o assunto sempre vai estar restrito a um conjunto pequeno de empresas, com um subconjunto ainda menor de problemas aplacáveis com BigData/Hadoop, então essa exposição toda não passa de hype, de propaganda, de vapor. E se for isso mesmo, não há como sustentar o atual ritmo de destaque na mídia.”
Logo, na minha opinião,
O BigData vai sumir. Não vai demorar muito e tudo isso sobre o qual falamos não será mais um assunto tão quente, e essas tecnologias estarão de volta ao nicho de Data Mining ao qual pertencem.
Conclusão
Acabou, era só isso. Frustante? Pouco?
Eu queria ter estado lá, porque pelo pouco que eu percebi, remotamente, tinha gente louca de vontade para falar. Soube que algumas cabeças balançavam afirmativamente, outras meneavam e algumas sacudiam-se.
Só para dar um grau, eis um comentário que eu recebi no dia seguinte:
Quando começaste a falar, pensei: “o que esse maluco está dizendo?”, mas conforme foste expondo teus argumentos, vi que concordo contigo. Atualmente eu trabalho na Procergs, onde está se tentando utilizar sistemas de Big Data para análise e esse, sim, é um caso atipico, de governo, onde se processa notas fiscais de vários estados. Para se ter ideia, todas as notas fiscais são armazenadas e processadas em banco relacional SQL Server e possuem um volume de Terabytes de dados, mas que ainda assim a tecnologia que está no mercado há anos, dá conta. Parabéns pela iniciativa, conseguiste passar a mensagem! E obrigado, vou aproveitar o material. Abraço, Rodrigo Batista
E você, o que acha? Pirei de vez na batatinha? Concorda comigo? ;-)
(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. ↩↩
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.
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.
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:
Arquitetura Data Vault.
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.
Uma tabela hub.
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.
Links
Links tão tabelas que guardam o relacionamento entre dois hubs. Uma tabela link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:
Link Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte do relacionamento;
BK1: business key do hub 1;
BK2: business key do hub 2;
…
BKn: business key do hub n.
Uma tabela link.
Ela também não sofrem atualização: novos relacionamentos são inseridos, antigos são ignorados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.
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.
Uma tabela satélite.
Modelo Completo
A coleção dessas tabelas e seus relacionamentos dão o modelo completo:
As tabelas combinadas no modelo.
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. ;-)
Meu perfil no site da Latinoware. Preciso melhorar essa foto…
Minha palestra será “Inteligência Institucional para o Governo Digital”:
Minha palestra na grade: 10H00min @ 15/10/15.
Eu vou mostrar como as tecnologias atuais – com 100% de Software Livre – habilitam a construção de um Armazém de Dados de proporções continentais. Por falta de nome melhor ele chama-se Armazém de Dados Governamental (ADG ou GDW) e pode ser construído para qualquer esfera de poder: municipal, estadual ou federal.
Consegue imaginar 27 ADGs estaduais integrados? É como construir a Matriz: vai estar tudo lá dentro!!
Semana que vem, dia 15/10/2015 às 11H00min (logo após a palestra), a apresentação estará disponível em PDF aqui no blog.
Mês passado (julho/2015) a Editora Packt conduziu uma pesquisa entre profissionais de TI para tentar entender como o conhecimento e habilidades desses profissionais influenciaram o sucesso em suas carreiras e seus salários. Receberam mais de 20.000 participações.
Isso é tanta gente que bateu todas as outras pesquisas do genêro. Para você ter uma idéia, se pegarmos só os respondentes dos Estados Unidos já dá mais participantes que a mesma pesquisa feita pela StackOverflow algum tempo antes. Uau!
E o que a Packt fez com isso? Lembre-se: eles não são uma instituição de caridade, eles querem é vender mais. ;-) Bom, eles analisaram todos esses dados e chegaram à some fascinating findings. Baseado nas conclusões das pesquisas, às quais você pode ter acesso por este link, a Packt montou pacotes de livros pensados para trazer ao leitor justamente os conhecimentos que podem gerar maior vantagem profissional nos próximos anos!
Falassério!!! Genial!!!
A empresa usa seu alcançe com leitores de todos os países e ramos da TI para pesquisar o que está fazendo diferença na vida deles. Daí estuda esses dados e monta uma campanha para ajudar seus leitores a escolher seus livros!
“Ah, Fábio, como você é inocente! Eles estão fazendo isso para ganhar mais dinheiro!”
SIM!! Ou você acha que o Pão de Açúcar faz promoção de queijos e vinhos apenas para o nosso deleite? Pense: nós, leitores, estamos ganhando com o conhecimento deles, já que nada nos impede de buscar livros de outras editoras.
A idéia não seria ruim, até, se não fosse pela segunda metade do pacote: neste link você tem acesso aos pacotes que eles montaram para vários tipos de profissionais. Por exemplo:
Aprendendo e dominando processamento de dados com Hadoop (“BigData”.)Data Mining (“Data Science” – pfff, buzzwords…) com R e Python, trilha completa.Hoje nada é completo sem “mobile”: eis um pacote para desenvolvimento Android.
E como isso se isso não fosse o bastante, a Packt deu um passo além: se você quiser montar um pacote específico, que você entenda como útil na sua carreira, você pode: escolhendo qualquer conjunto de 5 livros, você paga apenas US$25,00 por eles!!
Falassério, Parte 2!!!
Ah, você não achou 5 livros? Quer um ou dois? Ou apenas um vídeo para completar seus conhecimentos? Fácil: até o final da promoção, que é em 7 de agosto, todos os livros e vídeos estão por US$10,00 cada!
É isso. Quer saber o que nossos colegas de TI estudam, e que conhecimentos eles acham que vai ser importante nos próximos anos? Acesse a pesquisa. Acha que precisa estudar um pouco mais, sobre alguma coisa? Até 7 de agosto, neste link você pode montar um pacote de até 5 livros por US$25,00 – ou comprar qualquer livro ou vídeo por US$10,00.
E qual é o meu interesse em fazer essa pusta propaganda no meu blog?
Meu amigo da Packt me pediu ajuda para divulgar a campanha. Só o afago no meu ego já seria o bastante (a Packt acha que eu sou importante? Uau!)
Francamente, é uma promoção boa demais para não divulgar. Em um país com tanta necessidade de conhecimento e educação, qualquer oportunidade de aprender a um custo menor é muito valiosa para manter segredo.
Normalmente eu ganho um livro ou dois por ajudar a divulgar uma promoção ou fazer uma resenha. Só que desta vez isso não vai me fazer diferença: eu já ganhei tantos livros em troca de resenhas e divulgação que eu simplesmente não tenho mais o que pedir…
Até agora eu não consegui “fazer o caso” contra ou a favor da terceirização da infra-estrutura de soluções de BI – a.k.a. DW/BI “na nuvem”. Há pouco tempo, numa destas promoções da Amazon.com, eu consegui uma cópia gratuita do livro Getting Started with Amazon Redshift sobre o serviço homônimo, editado pela Packt em 2013.
Nome adequado!
O nome Redshift é uma referência ao deslocamento para o vermelho sofrido pela luz emitida de um corpo que está se afastando do observador. É um efeito observado no nosso Universo, que sugere que ele está se expandindo, ficando maior.
Ainda estou na metade, mas o que eu vi já é o suficiente para me esclarecer algumas coisas.
Para começo de conversa, a maior vantagem de infraestrutura “em nuvem” é, sem dúvida, a capacidade de escala normalmente disponível. O Redshift têm algumas opções de tamanho e preço, todas estupidamente potentes para a maioria das empresas:
Recurso
Nó XL
Nó 8XL
CPU Cores (Xeon E5)
2
16
RAM (GB)
15
120
Disco
3 HDs, 2TB
24 HDs, 16TB
E/S de Disco (GB/s)
0.5
4
Cada um destes nós é precificado em dois modelos:
Por hora: paga pelo uso, enquanto usar;
Por reserva: paga por um período, independente de usar ou não.
Tabela de preços em 2015: igual à de 2013, mas com Dense Computing.
No formato por hora, como podemos ver na tabela acima, cada nó XL sai por US$0,85/hora, e um nó 8XL por US$6,80/hora.
Agora, se você fechar um contrato com eles por um tempo determinado, o custo por hora chega a sair por até 25% do preço cheio! Considerando-se que uma empresa não traça estratégias por períodos muito menores que um ano, especialmente em termos de BI, um nó Redshift XL básico sai por US$0,49/hora para o contrato de um ano, e US$0,213/hora para contratos por três anos.
Colocando ao contrário: seu custo de infraestrutura para manter um DW com 2TB por três anos é US$83,00/mês. No Brasil de hoje isso mal paga a eletricidade das máquinas, quanto mais custos de software, instalação e suporte!
Conclusão: montar um servidor de DW no Redshift, com DOIS TERABYTES de armazenamento e 15 GB de RAM, em dois cores Xeons, parece muito mais barato que montar uma estrutura local. Só isso, para mim, já vale uma investigação mais detida do assunto. Este post vai olhar o lado do DW em nuvem e em um post futuro eu tratarei dos outros aspectos, como servidor de exploração, custos de transferência etc.
A Casa d’Irene
A casa d’Irene si canta si ride
C’e gente che viene, c’e gente che va
A casa d’Irene bottiglie di vino
A casa d’Irene stasera si va
Veja, Armazéns de Dados são como a casa da Irene: é gente que vai e vem, o tempo todo, e é desse fluxo que dependemos para as coisas acontecerem. Se você não consegue manter um fluxo de dados suficiente na carga, seu DW vai levar muito tempo para ser atualizado, estourando os tempos de ETL, entupindo a rede. Da mesma forma, se a vazão de dados entre o disco e a CPU não for o suficiente, as consultas vão demorar demais porque grande parte do tempo vai ser gasto pelo servidor trazendo os dados do disco para memória.
Disco <-> RAM
Quando temos um servidor de DW na nuvem, precisamos passar os dados dos sistemas da empresa primeiro pela Internet, para dentro do cluster Redshift. Depois, quando formos consultar, os dados precisam fluir rapidamente do disco para a RAM.
Este segundo aspecto é garantido pela Amazon em 0,5GB/s no caso mais barato. Uma fato de 1.000.000.000 (isso, um bilhão de linhas), com 400 bytes por linha (dez chaves delegadas de 8 bytes cada e mais 10 métricas de 32 bytes) totaliza pouco mais de 370GB. Ler tudo isso leva uns 12 minutos no cluster mais simples. No cluster mais rápido dá um minuto e meio. Nada mal, mas isso é um caso extremo, já que são raras as fato que atingem esse volume e ainda servem cubos OLAP, que é a aplicação que demanda mais velocidade. Para fatos com dez milhões de linhas, por exemplo, o menor cluster Redshift consegue varrê-lo completamente em pouco menos de 8 segundos.
Ou seja, I/O dentro do Redshift não é uma preocupação.
Origem <-> Redshift
Mas o caminho dos dados até os nós Redshift é.
Uma técnica tradicional de ETL consulta os sistemas transacionais e o DW simultaneamente, batendo um contra o outro e carregando no DW apenas as novidades. Essa arquitetura tem um impacto insignificante quando os sistemas ficam todos na mesma rede, que em geral está geograficamente muito próximo. Porém, quando o DW tem uma Internet no meio do caminho, cheia de firewalls, roteadores etc., a coisa muda de figura e se torna inviável. O round-trip time, que é o tempo entre uma leitura de um lado receber a resposta do outra, fica muito alto e, mesmo que o processamento seja rápido, o overhead de transmissão mata a performance do processo de ETL.
A solução é diminuir o uso da rede entre o sistema de origem e o DW no Redshift o máximo possível. Por exemplo, podemos selecionar apenas as linhas que tiveram atualização na origem e despachá-las compactadas para um armazenamento na mesma rede do Redshift.
Isso não é um cenário exótico, afinal, pois empresas que possuem centros de dados dispersos por vários territórios já lidam com essa preocupação rotineiramente.
Redshift <-> Soluções de BI
Quando resolvermos a questão da carga do DW, restará a exploração desses dados. Podemos consumir esses dados em dois modos:
On-line: aplicações cujas consultas precisam retornar em segundos;
Off-line: aplicações que podem esperar minutos ou horas por uma resposta.
O primeiro caso engloba painéis, análises OLAP e alguns tipos de relatórios. O segundo caso é mais comum em projetos de Data Mining e relatórios renderizados em plano de fundo, que sabidamente tomam muito tempo.
Qualquer que seja o caso, porém, sempre estaremos preocupados com o volume de dados que flui entre os dois servidores. Consultas para o Redshift são feitas com SQL normal, já que ele é um derivado Postgres, e isso raramente passa de alguns kilobytes.
A volta, do Redshift para o cliente que fez a consulta, é quando a porca torce o rabo. Em alguns casos o SQL retorna umas poucas linhas, com dados já totalmente agregados. Em outras situações, o retorno pode ser grandes datasets, que serão processados no servidor de exploração (o Mondrian, servidor OLAP usado pelo Pentaho BA Server, se encaixa neste caso.)
A solução é desconfortavelmente simples: a melhor forma de evitar gargalo de rede entre o servidor de exploração e seu DW Redshift é colocar o servidor de exploração dentro da Amazon, como outro serviço!
Uma das configurações mais “confortáveis”, com menos gargalos potenciais, é montar tudo dentro da Amazon.com.
Chutando Tudo
Quanto custa o hardware e software da categoria XL mais simples, e quanto sai um Redshift dessa categoria por um ano?
Se fosse medir isso para minha empresa, eu tomaria um cuidado enorme, começando por pedir cotações de vários fornecedores, custos de instalação, fretes, softwares, suporte etc. etc. etc. Mas eu quero apenas saber se os valores são comparáveis ou não. Para mim, comparáveis são valores que têm uma diferença de no máximo 10% entre si.
Hardware
Eu fiz uma busca por um Intel Xeon E5 e, logo nos primeiros resultados, achei isso:
Ele tem um quadro grande de especificações, mas nos interessa apenas essa:
Fonte: Cougar
Potência: 500 Watts
Tensão de entrada: 110/220V
Software
Depois eu verifiquei o preço de um HP Vertica para três nós, até 1TB: gratuito, assim como um sistema operacional (o Vertica funciona em algumas versões de Linux, que podem ser instaladas sem custo de licença.)
PostgreSQL colunar para três nós e 1TB: na faixa!
Infraestrutura
Vamos lá: no mínimo precisamos de um departamento de TI para tomar conta da máquina:
Profissional de TI: R$ 5,000.00/mês de salário;
Mais R$ 5.000,00 de encargos trabalhistas;
Trabalhando 8×5;
Menos um mês de serviço por ano (por férias);
Mais riscos diversos (acidentes doenças, paternidade, “ser roubado” por outra empresa etc. etc. etc.) que reduzem a disponibilidade dele.
Podemos argumentar que um profissional não vai ficar 100% do tempo dele só com um produto – servidor de DW – e que ele vai fazer muitas outras coisas. Concordo. Para efeitos de proporção, então, vamos dizer que apenas um décido do serviço dele é gasto com esse recurso. Se por mês gastamos R$ 10.000,00, então R$ 1.000,00 é a parcela de custo do servidor de DW.
Servidor que, aliás, precisa ficar ligado 24×7. Os preços de eletricidade em São Paulo, SP, hoje (julho/2015 antes do aumento de 1/7/15) são:
A fonte consome 500 Watts, que eu suspeito que seja Watt-hora. Por mês, ligado o tempo todo gastaria: (500 Watts x 24 horas x 30 dias)/1000 = 360 kWh/mês;
Em São Paulo a tarifacomercial está em R$ 0,25625/kWh;
Total mensal de R$ 92,25 e anual de R$ 1.107,00.
Somando os dois temos R$ 1.092,25/mês de custo de infraestrutura.
Comparando Alhos com Bugalhos
Resumindo, com a infraestrutura interna gastamos anualmente um mínimo de:
Item
Valor
Máquina
R$ 9.553,93
Software
R$ 0,00
Serviços
R$ 13.107,00
Total
R$ 22.660,93
Contra o valor integral da modalide de reserva, que você pode conferir na tabela adiante:
Para um ano: US$ 4.295,00 * R$ 3,14 = R$ 13.486,30 ;
Para três anos: US$ 5.605,00 * R$ 3,14 = R$ 17.599,7, ou R$ 5.866,56.
Tabela de preços da modalidade reserva.
Conclusão
Se você conseguir comprar um servidor, fazê-lo ser entregue sem frete, instalar-se e conectar-se a tudo sozinho, nunca der pau e nem precisar ficar em algum lugar no mundo físico – como uma sala, que paga aluguel, luz, IPTU etc. etc. etc., então um servidor Redshift sai por no mínimo R$ 9.174,63 a menos, por um ano. Aliás, com o que você gastaria em um servidor físico (em um cenário irreal) você poderia pagar TRÊS ANOS de Redshift equivalente, e ainda sobraria dinheiro!
Tudo muito lindo, tudo muito bacana, mas toda análise que joga luz sobre algo, projeta sombras sobre outras coisas. Olhe de novo para minha análise e se pergunte: o que é que não está dito ali?
Algumas coisas não são ditas:
Uma instância Redshift XL é algo muuuuito grande para os padrões de uma empresa média. Bom, isso eu disse, mas isto não: uma empresa desse porte pode ser virar com um servidor muuuito menos potente (por exemplo, com 1TB de disco e 8GB de RAM, CPU i7), na faixa de R$ 5.000,00 ou menos;
Existem outros custos associados a manter um Redshift que eu não contei. Um destes é o balde S3. Um balde S3 ajuda no transporte dos dados dos sistemas de origem para o nó Redshift, e ele consome outro tanto de dinheiro – incluindo custo de transferência de dados, medidos em gigabytes/mês. Veja aqui esses valores e faça uma conta;
Eu disse que o Redshift funciona melhor com toda estrutura na Amazon, incluindo o servidor de exploração e ETL. Isso representa no mínimo uma nova máquina online, com custos de disco, memória e transferência que precisam ser levados em conta;
Trocar um ambiente local por um “na nuvem” requer um conjunto habilidades ainda raro no mercado brasileiro. Esse caminho pode ser um beco sem saída em termos de mão-de-obra;
Acesso à Internet e a própria Internet viram um fator a ser levado em conta no planejamento. A empresa vai precisar de links de respeito para usufruir da potência desse servidor.
O que o livro me trouxe foi um pouco mais de conhecimento técnico sobre o assunto, que por sua vez me permitiu entender que uma arquitetura de BI/DW em nuvem é viável desde que, pelo que tudo indica, a solução fique completamente na nuvem. Se hoje eu fosse contratado para montar um DW em uma empresa, eu consideraria muito seriamente a montagem de tudo na Amazon.com, o que fatalmente me levariam a considerar as mesmas opções em outros serviços “de nuvem”.
Este post é dedicado à memória de minha querida tia Irene Michelette. Na casa de Irene se canta e se ride! :-)
O problema que define a nossa época corrente, em BI, é o grande volume de dados. Parece que todo o restante é um problema secundário quando alguém joga as palavras BigData na sala.
Como reinar sobre eles? Como manter uma vida pessoal, ser um profissional de BI de sucesso e mesmo assim conseguir atender às necessidades gasgantuescas de acúmulo de dados e – pior ainda – análise desses?
Conseguindo uma Big Fragging Gun for BI. ;-)
BFG
Quem é velho (ou novo) o bastante para ter jogado muito video-game vai se lembrar de um jogo chamado Doom. Nele havia uma arma, a Bio Force Gun, ou BFG, que disparava o tiro mais poderoso do jogo. Ninguém nunca a chamava de Bio-Force Gun, mas sim de Big F****** Gun, por que ela arrasava (hehe) tudo no caminho. Nada resistia à ela.
Big Fragging Gun!
Quando você tem um problema muito grande, você o resolve com ferramentas ainda maiores.
Em 28/04/2015 eu proferi uma palestra no SERPRO exatamente sobre isso: como resolver um problema do tamanho do governo federal brasileiro?
Usando uma ferramenta maior. >:-)
O Tamanho da Bagaça
A IBM é uma das maiores empresas do mundo, e tem cerca de 400.000 empregados em 2015. A esfera federal do governo brasileiro emprega mais de 1.900.000 pessoas.
Permitam-me frisar: UM MILHÃO E NOVECENTAS MIL pessoas. Dá quase cinco IBMs (e olhe que uma IBM existe no mundo inteiro. Estamos falando de quase cinco dessas, circunscritas ao Brasil.)
Se cada uma dessas 1.9M pessoas gerar duas linhas de dados por dia, dá quase quatro milhões de dados só sobre o próprio governo, por dia.
Quatro milhões? Pff, dirão meus leitores, que sabem que eu chamo fato com 10 milhões de linhas de pequena (pequena, para mim, era um milhão, mas é um número tão carne de vaca – qualquer coisinha já gera um milhão de linhas – que eu precisei atualizar esse meu patamar.)
Bom, uma parte considerável desse contingente todo – quase 2 milhões de pessoas – opera os sistemas que movem o governo federal, e que fazem o governo federal mover as coisas no Brasil. É um mundaréu de gente e dados: começa por orgãos como a Receita Federal, o Tesouro Nacional e o Ministério do Planejamento, que detêm o grosso do trabalho informatizado, vai até fundações como a Biblioteca Nacional e diversos museus, e passa por universidades, hospitais, todas as forças-armadas, ONGs etc. etc. etc.
Não há Teradata que aguente, na boa.
O Tamanho do Problema
Preciso dizer mais?? Cada empresa já sofre um parto para montar um punhado de estrelas para análises, imagine cruzar dados entre empresas! E fazer isso oferece capacidade real e imediata de ganhos para nós, pagadores de impostos.
Se um ministério tem um custo de infra-estrutura, e todos os ministérios tem custos semelhantes, temos muito a ganhar em gestão entendendo esses gastos e buscando oportunidades de economia. Aproveitando um tema que anda pela moda, o potencial de terceirização – com ganhos de produtividade, qualidade e custos – são gigantescos!
Mas não compre ainda!
Como uma mega-instituição, complexa, pesada, coisas mais sutis passam completamente despercebidas! Você consegue imaginar a quantidade de perdas, desperdícios, erros e fraudes que pode acontecer em um sistema composto por tantos sistemas, e cada um com sabe-se lá quantas partes móveis? Todos esses dados, consolidados, integrados e deduplicados, se analisados com critério, podem mostrar muitas oportunidades de melhorias.
E se pudéssemos integrar os dados financeiros aos dados do DNIT? E se pudéssemos colocar lado-a-lado os dados das polícias de todo país e dos hospitais? Pense nos dados dos ministérios da Saúde, do Trabalho, da Fazenda, unidos! O que isso não poderiam nos dizer?
Como se não bastasse, de onde saem os parâmetros para definição de políticas? De onde tiramos que um projeto social está dando o resultado desejado, ou uma política de estado está tendo o efeito planejado?
Para arrematar, no meio de todos esses dados operacionais do Governo Federal existem os nossos dados, aos quais a Lei de Acesso nos granjeia acesso livre e imediato.
Conseguem ter uma noção da monstruosidade que é coletar e integrar todos esses dados, quiçá analisá-los??
Inteligência Institucional
Eu diria que ser um Governo Eletrônico é ser capaz de fazer mais que informatizar e automatizar os processos. Ser um Governo Eletrônico é ser capaz consumir esse planeta de dados para melhorar a si mesmo e para entregar serviços melhores. (Oceano de dados agora me parece uma coisa muito pequena. Já, já eu vou estar falando de Sistema Solar de Dados, ou Pequena Nuvem de Magalhães de Dados, hehe.)
Malgrado as dificuldades do mundo real, conseguir a capacidade de acumular e analisar esses dados é um imperativo para qualquer instituição, e um imperativo ainda mais forte para uma instituição tão central a um nação quanto seu Governo Federal.
Soluções
Tradicionalmente, uma solução de BI que analise os dados da empresa inteira tem esta aquitetura:
Arquitetura tradicional de EDW.
Ou seja, existe um banco de dados (relacional, quase sempre) que serve como Enterprise Data Warehouse (EDW ou Armazém de Dados Corporativo.) Quase sempre, também, esse EDW armazena os dados em um modelo dimensional, composto por uma coleção de estrelas (conjuntos de tabelas dimensão ligadas a uma fato.) Cada estrela representa um assunto dentro da empresa, e as estrelas são integradas via um barramento de dimensões conformadas.
Finalmente, um processo de ETL cuida de ler os dados na origem, limpá-los, arrumá-los, integrá-los e finalmente depositá-los no banco de dados, no EDW.
Uma empresa de porte médio, talvez até grande, pode conseguir viver com um EDW assim. Mas o modelo dimensional funciona bem para analisar, para explorar os dados, não para armazená-los eternamente, muito menos para integrá-los. Tanto é assim que a integração é feita pelo processo de ETL.
A partir de um certo ponto, essa estrutura colapsa sobre o próprio peso e se torna impossível de receber manutenção. Em bom informatiquês, torna-se imanutenível.
E esse não é o único galho dessa abordagem, não senhor! Que tamanho você acha que um banco de dados relacional, por mais parrudo que seja, consegue atingir? Você consegue imaginar uma tabela em um Postgres ou Oracle ou Teradata recebendo gigabytes e gigabytes diariamente, por meses, anos, décadas?? Nem eu!
Mas há soluções para cada um destes problemas.
A mais fácil é o volume de dados. Um cluster Hadoop consegue armazenar uma quantidade razoavelmente (petabytes) grande de dados, com performance de consulta aceitável, a um custo viável por gygabyte. Não vou entrar em detalhes aqui pois há muito sobre isso na web.
Sobrou a outra ponta: acumular e integrar esses dados.
A solução não fácil, ou mágica, mas existe: Data Vault. Veja essa arquitetura:
Arquitetura de EDW adequada a mega-empresas.
Ela propõe um EDW baseado em Data Vault, armazenado em um cluster Hadoop.
Isso resolve dois grandes problemas de uma vez:
Integração: o modelo de dados de um Data Vault integra os dados. Quando uma nova fonte é incorporada ao EDW do Governo, o GDW (Government-sized Data Warehouse), os dados redundantes já entram nas tabelas pré-existentes e apenas os dados novos entram em tabelas novas. O processo de ETL, por outro lado, passa a ser completamente “burro”, pois vai apenas mover os dados novos dos sistemas de origem para dentro do EDW;
Manutenção: a inclusão, alteração e remoção de fontes de dados, bem como a integração entre as fontes, passa a ser uma atividade padronizada, organizada e repetível. Acaba o pesado de inconsistência entre dimensões “parecidas mas diferentes”, comuns em DWs dimensionais.
Fábrica de Dados
A minha proposta nada mais é que a reedição do conceito de Fábrica de Informações Corporativas do Bill Inmon, com um Data Vault no meio, e com dados gravados em um cluster Hadoop. Isso mesmo: nada de novo. Já poderia ter sido feito há anos. Talvez até há mais de uma década, já que outra vantagem do Data Vault é a relativa facilidade de migração de fontes de dados. Ainda teria havido um bom retrabalho passar de um Data Vault 1.0, típico em bases relacionais, para o Data Vault 2.0, adequado ao Hadoop, mas nada teria sido intransponível.
Ao invés de cada orgão ter que atender à demandas em separado, um único centro de dados do Governo faria isso;
Novas demandas de inclusão passam a ser tratadas uma única vez, em um único ponto: se um orgão pode atender seus pedidos de acesso à dados com dados já capturados por conta de outra demanda dos mesmos dados;
O pedido de novos dados, ainda não coletados, entra em uma linha de produção muito mais previsível e estável que a loucura tradicional de montar um serviço para cada demanda, em cada orgão.
E é claro, essa integração daria um poder fantástico ao gestor público.
Conclusão
Você pode baixar o PDF da apresentação clicando aqui e ver um pouco mais de argumentação. Esse material nunca foi aproveitado para nada dentro do SERPRO, e foi criado por mim mesmo por puro diletantismo, em meus períodos de lazer. Eu cheguei a propor como um produto, mas haviam outras coisas mais interessantes ou urgentes.
Pensando um pouco, acho que essa solução não precisa se limitar à esfera federal. Seria relativamente simples construir o mesmo em esferas estaduais e municipais, e integrá-las.
Geek BI 