Dados – Novos Conceitos

Quanto mais tenho me dedicado a estudar e me especializar, mais tenho visto e percebido que, um dos principais problemas na grande maioria dos projetos, é o não uso dos conceitos corretos para situações e problemas específicos.

Com o avanço e constante evolução das tecnologias, mais os profissionais são forçados a focar em ferramentas.

Porém, como sempre digo em cursos e palestras, a correta aplicabilidade dos conceitos é o que faz um projeto ser ou não bem sucedido. Ferramentas são somente uma forma de conquistar um fim com base em uma arquitetura específica.

Esse post foi especificamente pensando para ajudar entender como e onde cada conceito se encaixa.


Primeiramente começemos do início com o conceitos de Business Intelligence (Inteligência de Negócios) também conhecido pela sigla BI. A idéia principal por detrás desse conceitos está em usar os dados criados pela instituição para gerar insumos para tomada de decisões. Desta forma, elimina-se a necessidade de “feeling” dos gestores e responsáveis para decisões importantes apoiando-os com dados e não somente com sentimentos (achismos).

Partimos então para os nossos conhecidos Immon e Kimball com as teórias relacionadas a Data Warehouse. Basicamente, um Data Warehouse (ou Armazem de Dados) é o repositório centralizado para o armazenamento de informações usadas para a tomada de decisões.

Com base no livro Data Warehouse Toolkit, esse (o DW) deve ser histórico e responsável por unir os dados importantes para o BI em um lugar único visando com que relatórios que usem a mesma informação não apresentem dados divergentes, tornando-se assim, a Fonte da Verdade para toma de decisões.

Esses dados são extraídos, integrados, limpos e carregados por um processo chamado Extract, Transformation and Load (Extração, Transformação e Carga) ou ETL. Um processo de ETL consiste em extrair os dados das várias fontes, trabalhá-los e depois armazená-los dentro do repositório centralizado.

Veja que os conceitos Data Warehouse e Business Intelligence são totalmente diferentes mas que, muitas vezes, são confundidos. É importante entender essa diferença para que consigamos entender melhor os conceitos a seguir.


Partindo para o próximo ponto temos o tão falado de Big Data. Bom, o famoso conceito “dado grande” teve sua origem em 1997 em uma conferência de engenharia e teve sua formação em 2001 onde tomou forma nos 3 “V”s. São eles:

  1. Variedade = Dados estruturados (CSV), semi-estruturados (JSON) e não-estruturados (Dados de vídeo e fotos, por exemplo).
  2. Velocidade = Necessidade consumo dos dados em formatos diferentes de forma mais rápida.
  3. Volume = Necessidade de armazenamento desses gigantesco desses dados de todos os tipos permitindo o seu consumo de forma performática.

O nascimento da tecnologia para o termo Big Data ocorreu em 2003 com o Google File System (para armazenamento) e o Map Reduce (como técnica de consumo de dados distribuído). Porém, o seu grande advento deu-se quando o Yahoo, com base nos white papers do google criou o Hadoop. Essa tecnologia tornou-se um projeto da Fundação Apache e hoje, os dois termos (Big Data e Hadoop) normalmente confundem-se.

Após a leitura acima é possível entender que, o termo Big Data não diz respeito a análise de dados em si, mas sim, a uma arquitetura capaz de trabalhar com grandes volumes de informações usandas-as, não somente para tomada de decisões, mas para o funcionamento da empresa ou como um todo. É o que chamamos de Data Driven.

Vamos pensar de uma maneira um pouco mais prática. Empresas hoje conseguem receber dados de sensores fazendo com que seus softwares e hardwares tomem decisões de forma autônoma. Graças a isso tivemos o advento da Industria 4.0.


Com base no abrangente conceito de Big Data foi indispensável dar forma a uma nova arquitetura de armazenamento centralizado de dados que permita a criação de uma Fonte da Verdade, não somente para áreas responsáveis pela tomada de decisões, mas para toda a empresa.

o responsável por esse conceito chamado Data Lake foi o, então CTO da Pentaho, James Dixon. O “Lago de Dados” nada mais é que um repositório central para o armazenamento de dados crús (Raw Data) de todas as origens e tipos visando com que toda a instituição use essas informações para todo o qualquer tipo de possibilidades.

O seu principal argumento para criação da arquitetura foi a extinção dos silos de dado, problema esse herdado dos conceitos de Data Mart.

Dessa forma, quando nos referimos à tomada de decisões, ainda precisaremos. (na maioria das vezes e para a maioria dos propósitos) de um Data Warehouse (Conceitualmente).


Se partirmos para a análise de dados provenientes de um Data Lake deveremos tocar em um outro importante conceito chamado ELT. Bom, o Extract, Load and Transformations tem uma aplicabilidade idêntica ao ETL já abordado acima com a diferença, não somente da ordenação das três letras: Aqui, os dados são extraídos e armazenados no Data Lake e depois, através de outras tecnologias, são transformados e apresentados.

Se pensarmos na Fonte da Verdade de dados usada não somente para uma parte da empresa, mas sim para ela como um todo, será possível entender que, ao aplicar uma regra de negócio específica e só depois armazenar esse dado, tem-se a perda da característica de Raw Data da informação. Ou seja, o processo de transformação é realizado após a inserção do “dado crú”.

A ideia do post é falar sobre conceitos, mas citarei com exemplos de ferramentas de ELT o Hive (Possibilita o uso da interface de SQL para consumo de dados dentro do HDFS usando Map Reduce) e o ApacheDrill (Tecnologia que lê dados do HDFS usando conceitos de armazenamento colunar em memória).


Bom, com base em todo o contexto criado acima, foi possível observar que, Big Data não é a evolução do Data Warehouse, e nem um substitui ou substituíra o outro. São conceitos que se complementam e que sempre terão seu espaço, todavia, em tecnologias novas.


Aproveitando o post, falarei também de dois conceitos que muito se confundem por terem uma linha muito tênue de divisão apesar de estarem muito afastados dentro de uma arquitetura de dados. São eles o Self Service BI e o Data Discovery.

Self Service BI diz-se respeito à possibilidade de consumir dados para sua análise de maneira simples e rápida. Geralmente usado por gestores para construção de insumos e indicadores sobre as informações de seu negócio sem a necessidade do uso da TI.

Ora, é importante assinalar bem o “sem o uso da TI” porque, devido a esse pensamento, as empresas tendem a criar uma ideia errônea de que seria possível a criação desses reports em cima dos dados crús sem a aplicação das regras de negócios ou, aplicando-as inconsequentemente de acordo com cada área da instituição. Essa forma de abordagem cria um dos problemas que o Data Warehouse deve ser usado para resolver: Inconsistência de dados para o mesmo tipo de informação.

Vejamos: O que seria um self service? Pensemos em um self service de comida. Entramos em um restaurante e escolhemos nosso cardápio. Colocamos no prato arroz, farofa, feijão, frango, um pouco de salada e um molho qualquer.

Agora vejamos: em algum momento entrou-se na cozinha e preparou-se o arroz, o feijão e o frango? Não, certo? Logo, Self Service BI diz-se da possibilidade de consumir informações já trabalhadas pela TI.

Agora vamos para a ideia de Data Discovery. Com o crescente aumento dos dados dia após dia gera-se cada vez mais a necessidade de cruzar as informações “locais” com dados externos possibilitando novas análises mais rebuscadas. Muitas vezes os gestores e analistas precisarão verificar onde e como cada novo dado se encaixa ao seu e, respectivamente, poderá ajudar em novos insights.

O Data Discovery consiste em possibilitar a essas pessoas o cruzamento dessas novas informações visando exatamente realizar a “Descoberta de Dados”.

Ferramentas como o Power BI da Microsoft permitem ambas as possibilidades, porém, uma arquitetura mal formulada confundindo-se os temos pode criar um problema catastrófico em uma empresa.


A ideia deste post é ajudar os profissionais de dados a realizarem uma melhor escolha da tecnologia a ser usada com base no conceito correto para o tipo de problema a ser resolvido. Espero ter ajudado. Até o próximo.

Anúncios

Deixe um comentário

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

Logotipo do WordPress.com

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

Foto do Google

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

Imagem do Twitter

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

Foto do Facebook

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

Conectando a %s