Presto – Distributed Query Engine for Big Data Environment | Concepts

Pessoal, esse post irá iniciar uma série de posts sobre o Presto. A ideia é que demos início a um conjunto de séries com conteúdo exclusivamente voltado para Big Data. Iniciaremos com essa série sobre Presto e logo em seguida, começaremos uma outra sobre Apache Kafka. Pretendo abordar também o Apache Drill, e algumas outras tecnologias do Azure para armazenamento e processamento de “Big Dados”.

O Presto, dentro do cenário de Big Data está qualificado como um ferramenta de query distribuída. Iremos aqui desde a introdução até como configurarmos e usarmos em ambientes on-premises e Azure Cloud.


O projeto do Presto foi iniciado com a equipe do Facebook em 2012. A ideia era criar uma ferramenta que fosse capaz de permitir uma performance maior em comparação, por exemplo, ao Apache Hive onde, para isso, seria necessário não mais usar o Map Reduce como mecanismo de busca. Dessa forma, o Presto trabalha apenas com memória.

Muitas pessoas confundem a ferramenta como sendo um banco de dados em memória, porém, o Presto é apenas um layer de processamento. Isso quer dizer que os dados são usados apenas em tempo de execução e são buscados de suas respectivas origens.

Um outro ponto muito interessante do Presto é que, com ele, é possível conectar em diversas fontes diferentes e realizar join entre essas fontes de dados permitindo um resultado integrado sem a necessidade de um processo de integração de dados para isso. Por exemplo: se você precisa cruzar informação do seu SQL Server On-Premises, com seu MongoDb NOSQL, com seu DataLake que está no Hadoop e em um outro repositório que está no Azure,  você poderia usar o Presto para isso.

O Presto é uma ferramenta desenhada para eficientemente trabalhar com uma grande quantidade de informações usando uma arquitetura distribuída. Com ele você pode trabalhar com terabytes ou petabytes de informações dentro do HDFS ou de outro storage layer. Ele foi desenhado para trabalhar com data warehouse e analytics: Analises de dados e agregações de grandes massas para produção de reports.

Só para termos uma ideia, em 2014 a Netflix divulgou usar o Presto para construção de análises sobre 10 petabytes de informações.


No próximo post iremos abordar conceitos e a arquitetura do funcionamento do Presto. Será possível iniciar o entendimento da ferramenta e descobrir o porquê de o Presto ser tão interessante em cenários de Big Data.

Anúncios

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.