Presto – Distributed Query Engine for Big Data Environment | Azure Cloud

Pessoal, no post anterior da série foi possível descobrir em um passo a passo como realizar a configuração de um cluster de Starburst Presto em ambiente On-Premises.

Neste post você aprenderá como realizar a mesma configuração em Azure Cloud dentro de uma infraestrutura de PaaS (Platform as a Services) do HDInsight.


Platform as a Services (PaaS) é uma maneira de você fornecer um ambiente de infraestrutura mais simplificado eliminando vários passos de manutenção se comparado a um ambiente On-Premises / de Infrastructure as a Services  (IaaS).

A plataforma do HDInsight foi criada pela Microsoft visando exatamente essa simplificação que a ideologia de PaaS trás com a nuvem, porém mantendo a robustez das tecnologias de Big Data Open Source. Dessa forma, você paga apenas pela utilização das máquinas do Cluster.

Com o HDInsight você não terá somente a infraestrutura simplificada como também toda a instalação dos softwares utilizados.

Se você acompanhou o post anterior pôde perceber que não é tão simples configurar e manter um ambiente On-Premises para tecnologias de Big Data e, não somente isso, também deve ter percebido que não é barato. Ora, imagine um ambiente com um cluster de 10 nós de Presto. Em teoria, seriam 10 máquinas (virtualizadas ou não) com uma memória considerável. E é exatamente essa simplificação que o Azure fornece.


Para que você possa testar o ambiente é possível criar uma conta de Azure Gratuita usando a plataforma do MSDN. Basta acessar Esse Link e entrar com sua conta Microsoft. Aceite o termo e ative o seu crédito de azure.

Ao entrar no Portal do Azure você deverá ir em Create a Resource e pesquisar por HDInsight. Após isso irá selecionar a primeira opção.

Em baixo da tela após selecionar a opção deverá pressionar a opção Create. Em Basic Configurations você irá preencher conforme imagem abaixo:

Como você está, além do Starburst Presto, instalando toda a infra estrutura do Hadoop, é necessário realizar algumas configurações de storage (levando em conta que o HDFS é armazenado em disco) para subir seu cluster de Starburst Presto. Dessa forma, em configurações de Storage, configure conforme a imagem abaixo e selecione a opção Next:

Na próxima tela, escolha Edit na opção Applications:

Pesquise por Starburst Presto dentro da barra de pesquisa Available applications e selecione a opção disponibilizada para a ferramenta:

Escolha o size do cluster em Choose node sizes. É possível ver o custo total da solução em valores estimados por hora. Neste caso deixarei o valor padrão. São 4 data Nodes e 1 Head Node (Nomeclatura do Hadoop). Portanto clique em Next.

Após isso clique em Next para Script actions e em Create na próxima tela de configuração.

Feito isso, o Azure criará toda a infraestrutura de Hadoop com todas as ferramentas do ecossistema + o Starburst Presto. Claro, caso você já use uma arquitetura de HDInsight, é possível somente adicionar a aplicação dentro do cluster já existente.


Agora que você já tem um cluster de HDInsight rodando, será possível conectar-se ao Superset para realizar queries dentro do Starburst Presto.

Primeiro, abra o cluster que você acabou de criar, selecione a opção Applications e depois a aplicação de presto que foi instalada e configurada dentro do HDInsight.

Você terá 3 opções. serão elas:

PrestoDB Web App – Aplicação web para que você possa verificar as queryes que estão rodando, nós ativos no cluster, e demais opções as quais iremos abordar posteriormente na série.

PrestoDB Set App – Aqui você terá acesso ao Superset. é uma aplicação web que permite a você realizar queryes de maneira mais intuitiva utilizando as ferramentas de Big Data.

SSH Endpoint – Você poderá conectar-se ao cluster de presto e usar o Presto CLI para realizar suas queryes.


No próximo post da série você aprenderá sobre como configurar conectores nos seus dados, permitindo assim que o Presto seja capaz de realizar queries em diversas origens diferentes.

Anúncios

Presto – Distributed Query Engine for Big Data Environment | On-Premises Installation

Pessoal, no post anterior da série foi possível entender sobre os conceitos por detrás do Presto e também como funciona a arquitetura de um cluster da solução. Neste você entenderá o que é a Starburst e aprenderá a instalar a a ferramenta em ambiente On-Premises.


O Presto foi criado, como já vimos no primeiro post da série, pela equipe do Facebook na tentativa de substituir o Map Reduce e o Hive (que na época ainda não possuia o LLAP). Muitos dos participantes do projeto de criação do Presto criaram a empresa Starburst para, não somente fornecer aos clientes uma versão da ferramenta com suporte, mas também uma versão com melhorias.

A principal das melhorias com relação à versão open source é o Cost Based Optimizer (CBO). Antes dessa implementação O Presto com relação ao Hive LLAP e Spark se tornava a ferramenta menos performática do grupo devido ao fato de não conseguir realizar um plano de execução inteligente para a busca dos dados. é possível entender melhor sobre o TCP Benchmark DS lendo o artigo do link a seguir: https://azure.microsoft.com/en-us/blog/hdinsight-interactive-query-performance-benchmarks-and-integration-with-power-bi-direct-query/.

Após a implementação do Cost Based Optimizer, o Presto, seguindo o mesmo padrão de análise do TCP Benchmark DS anterior, foi categorizado pelo Principal Program Manager do Azure HDInsight da Microsoft Ashish Thapliyal usando as seguintes palavras: “If interactive SQL analytics are needed, Presto is the best fit” / “Se query analítica interativa é o que você precisa, Presto é a melhor solução“. 


Agora vamos iniciar a configuração necessária para instalação do Starburst Presto em ambiente On-Premises. Usaremos nessa sessão um cluster de 4 máquinas, todas as elas com Linux CentOS 7. (É possível configurar em apenas um nó. Porém, para que você consiga verificar o verdadeiro potencial da solução iremos usar essa infraestrutura na série).

É necessário como pré-requisito que um usuário tenha acesso às todas as máquinas do cluster via ssh, e, claro, para isso, as máquinas devem estar em um mesmo ambiente de rede. É necessário também que seja adicionada uma regra no  Firewalld permitindo essa conexão (Ou que o Firewalld seja desativado).

É necessário ter instalado os seguintes pacotes em todos os nós: Python 2.7, tar, libffi, openssl, openssh, openssh-clients, openssh-server, net-tools, sudo (when presto-admin connects as non-root user via SSH).

A instalação e configuração do cluster de Presto é realizada através de uma ferramenta chamada Presto-Admin. Com ela, através de uma configuração simples, é realizado o download e configuração da ferramenta em todos os nós do cluster, indicando se esse nó é coordinator, worker, ou scheduler, quanto de memória será utilizada dessa máquina para o serviço do Presto, quanto cada nó poderá usar de memória para execução de cada query e etc. (Faremos um post específico para explicação dessas configurações).


Para realizar o download, use o usuário root e depois acesso o diretório /root. depois, acesso o LINK e clique em Download Now. Faça o cadastro, pegue o link para download na opção prestoadmin-2.5-offline-el7.tar.gz e dentro do nó principal com acesso ssh em todos os outros nós, use o comando wget <link>.

Realize a descompactação do arquivo utilizando o comando:

tar -zxvf ./prestoadmin-2.5-offline-el7.tar.gz.

Após isso entre no diretório /root/prestoadmin e execute o comando:

sudo ./install-prestoadmin.sh

Após a execução do comando, verifique que nesse diretório havará agora o arquivo presto-admin. para testar a instalação use o comando:

./presto-admin --help.

Agora que você já possui o Presto Admin instalado no servidor vamos realizar a criação do arquivo de configuração para que seja possível realizar o deploy do cluster de Starburst Presto.

Primeiramente é necessário acessar o diretório /root/.prestoadmin/. Use o comando vi config.json para realizar a criação do arquivo de configuração que será utilizado pelo Presto Admin para configuração do Cluster.

Dentro desse arquivo, adicione as informações abaixo:

{
    "username": "root",
    "port": "22",
    "coordinator": "<coordinator_server_ip>",
    "workers": [
        "<worker_server_ip_01>",
        "<worker_server_ip_02>",
        "<worker_server_ip_03>",
        "<worker_server_ip_N>"
    ]
}

salve o arquivo no diretório. e execute o comando:

/root/prestoadmin/presto.admin server install <version> -p <user_password>}

O parâmetro -p precisa ser utilizado somente se o usuário root não tiver acesso passwordless aos demais servidores.

Esse comando realiza o download e instalação dos componentes necessários para execução dos serviços do cluster em todos os nós (coordinator, scheduler e workers). Para que ele funcione corretamente é preciso dizer a versão do Presto (estamos atualmente usando a 0.213) e  o password para sudo e ssh do user (aqui estamos usando o root).

Após realizado isso alguns arquivos serão criados dentro do diretório/root/.prestoadmin dentro das pastas coordinador, workers e catalog. Vá até o diretório /root/.prestoadmin/coordinator/ e edite o arquivo ./config.properties. edite as opções:

query.max-memory = soma de 60% do total de memória de todos os nós workers. Por exemplo, se você possuir 3 nós, cada um com 10 gb de memória o valor é ser adicionado é 18.

query.max-memory-per-node = 60% da memória que pode ser usado em cada máquina. No mesmo exemplo acima o valor seria 6.

query.max-total-memory-per-node = 60% da memória que pode ser usado em cada máquina. No mesmo exemplo acima o valor seria 6.

discovery.uri = O servidor Coordinator e Scheduler (discutidos no post anterior) dentro da infraestrutura de Presto ficam dentro do mesmo nó. ou seja, o preenchimento desse parâmetro é <ip_servidor_coordinator>:<porta>. Por padrão a porta utilizada é 8080. Caso ela já esteja em uso, altere essa propriedade e a propriedade http-server.http.port.

Irei criar um post mais a frente na série explicando sobre as configurações desses parâmetros.

Agora você precisará alterar o valor dentro do segundo parâmetro do arquivo jvm.config no mesmo diretório de acordo com o exemplo abaixo:

-Xmx10G = Total de memória de cada servidor. No exemplo dado anteriormente esse valor seria 10.

Você alterou os arquivos no diretório /root/.prestoadmin/coordinator. Faça a mesma alteração nos arquivos com mesmo nome no diretório /root/.prestoadmin/workers.


Feito isso, você precisará realizar o deploy das alterações realizadas nos arquivos de configuração dentro de todos os nós configurados para o cluster. Para isso use o comando:

/root/prestoadmin/presto-admin configuration deploy

Agora você pode confirmar o update das configurações utilizando o comando:

/root/prestoadmin/presto-admin configuration show

Utilize o comando abaixo para iniciar o cluster de Presto no seu ambiente On-Premises:

/root/prestoadmin/presto-admin server start

Utilize o comando abaixo para validar se todos os nós estão funcionando dentro do ambiente:

/root/prestoadmin/presto-admin server status

Se tudo estiver correto, o seu cluster estará disponível e você já tera o seu ambiente de Big Data Distributed Query Engine pronto para uso.


No próximo post da série você aprenderá como realizar a instalação do Presto dentro do Azure Cloud para ambientes de nuvem. No post seguinte será possível descobrir como configurar os Catalogs para busca de dados e a usar o presto-cli para executar queries distribuídas.

Presto – Distributed Query Engine for Big Data Environment | Concepts

PessoALL, no post anterior da série conhecemos um pouco sobre o que é o Presto e, teoricamente, onde podemos usá-lo em um ambiente de Big Data. Neste post iremos adentrar em alguns conceitos que são necessários para que consigamos instalá-lo, usá-lo e configurá-lo. Aqui, Nesta etapa não falaremos somente de conceitos, entenderemos também sobre a Arquitetura por detrás dessa fantástica ferramenta.


Vamos iniciar entendendo sobre os tipos de Servidores dentro de uma infraestrutura de Presto. Existem três tipos de servers:

  1. Coordinator Server – Responsável pela análise dos comandos, planejamento do plano de execução das queries e gerenciamento dos nós disponíveis dentro do cluster. Ele é o “cérebro” da infraestrutura. Sempre é necessário ter pelo menos um coordinator ativo. Após os dados serem processados pelos Work Servers o Coordinator é responsável por capturar o resultado final e retorná-lo ao usuário.
  2. Worker Server – Responsável pelo processamento dos dados.
  3. Scheduler Server – Responsável por capturar quais Work Servers estão disponíveis e apontá-los para o Coordenador.

Após entender os tipos de Servidores, é necessário entender o que são os Conectores. Segundo a própria documentação do Presto, você pode entender os connectors como drivers de conexão.

É possível criar conectores para várias fontes de dados como por exemplo bancos de dados relacionais, bancos de dados NoSQL, bancos de dados na nuvem e file system distribuídos através do Hive Metastore (Serviço do Hadoop responsável por criar para os arquivos uma estrutura tabelar dando traduzindo-os de forma estruturada através de linhas, colunas e tipos de dados).

Cada origem de dados é entendido pelo Presto como um Catalog. Você pode entender um Catalog como um Banco de Dados dentro de um Servidor do SQL Server. Por sua vez, cada Catalog é associado a um connector.

É possível usar o mesmo Connector para vários Catálogos diferentes. Por exemplo, você pode querer se conectar a vários bancos de dados do SQL Server em vários servidores diferentes.

Se temos como comparar o Catalog a um banco de dados dentro de um servidor, podemos comparar o Schema ao esquema do SQL Server (para o SQL Server, por default, o dbo. Para o PostgreSQL o public). Da mesma forma, uma table a uma tabela de um relational database.

Para o Presto, Statement são comandos (SELECT, FROM, WHERE) e Queries são conjuntos de comandos (SELECT <col1>, <col2> FROM <table> WHERE <col1> = 10).

Quando o Presto realiza a execução de uma query ela é quebrada em várias execuções lógicas diferentes dentro de um conjuntos de estágios hierárquicos (Tasks). Ele trabalha com o conceito de Árvore Binária: se você pede um resultado que virá de um GROUP BY o serviço irá receber a query, analisá-la, decidir em quantos servidores irá executá-la e, após a execução de todos os pedaços ele separará uma task root para agregar o resultado encontrado em um retorno final.

Dentro do Presto, todas as execuções possuem um estágio root que é responsável por agregar os resultados recebidos dos outros estágios (ainda que exista apenas um estágio filho).


Acima estão os entendimentos mínimos para dar continuidade ao aprendizado. No decorrer dos posts, caso se faça necessário, entraremos em outros conceitos mais aprofundados da ferramenta.

Agora você irá entender como funciona a Arquitetura de execução de um Cluster de Presto.

  1. O Client realiza uma solicitação ao serviço. O Coordinator Server é quem recebe essa solicitação.
  2. O Coordinator Server realiza o entendimento da solicitação, cria um plano de execução (veremos mais a frente porque usar a distribuição Starbust) e solicita ao Scheduler Server quais os nós de Worker se encontram disponíveis. o Scheduler Node devolve os nós e então o Coordinador demanda o as Tasks aos Worker Servers.
  3. Os Workers Servers usam os Connectores para buscarem os dados das diversas origens utilizadas na query.
  4. Os dados são trabalhados e passados para a Root Task para que a mesma realize a agregação dos dados entregues pelos Worker Nodes.
  5. O Root Worker devolve para o Coordinator Server o resultado e o mesmo devolve o retorno para o Client.

No próximo post você descobrirá o que é a Starburst, por que utilizá-la e como instalar a ferramenta em ambiente On-Premises.

PASS Chapter DF – Arquitetura Lambda na prática – On-Premise e Azure Cloud | Parte 1

PessoALL, ontem tive o prazer de estar no 43˚ encontro do SQL Server DF Data Group. Dessa vez fizemos uma imersão no passo a passo para criar um cenário de Big Data do zero.

Foram 3 horas de conversa onde passamos pelas principais configurações o observações para instalar e utilizar o Hortonworks HDP Confluent Kafka e após tudo configurado utilizar o Power BI para consumir os dados do Datalake utilizando o Apache Hive.

Nesse post irei disponibilizar os links de download de todas as ferramentas utilizadas e deixar o caminho do meu GitHub onde será possível realizar o download de todos os arquivos de configuração utilizados.


Começemos com a configuração do PostgreSQL, base Beltrano S/A e Wal2Json. AQUI será possível fazer o download versão 9.6 do PostgreSQL (Versão usada para demonstração na palestra). AQUI será possível realizar o download e configuração da Base de Dados OLTP da Beltrano S/A. E AQUI será possível seguir o passo a passo para instalação e configuração do Wal2Json.

Para instalação do Ambari e do pacote Hortonworks HDP basta seguir o passo a passo da própria documentação. Após a instalação do Ambari será possível realizar o deploy do cluster de HPD. Na apresentação usei apenas os serviços do Apache Zookeeper, Apache HDFS, Apache Tez, Apache YARN, Apache MapReduce2 e Apache Hive (Server e HCatalog).

Feito isso, é necessário realizar a instalação do Kafka da Confluent. Segue o Link para download e link para configurações necessárias. Se preferirem, podem usar os arquivos de configuração que estou disponibilizando no GitHub mais abaixo no link.

É necessário realizar o download e configuração do Kafka Connector para o Debezium. Essa ferramenta é utilizada para permitir a conexão entre o Kafka e a replicação dos dados do PostgreSQL através do Wal2Json. Para mais informações sobre O Debezium clique AQUI. Para realizar a instalação e configuração do Kafka Connector use o Confluent Hub.

O Confluent Hub é uma ferramenta do pacote da Confluent instalado a parte para realizar a configuração de conectores que não vem dentro do pacote inicial. Para instalação e configuração do Confluent Hub basta seguir o passo a passo localizado NESTE LINK. Para instalação e configuração do Confluent Debezium Source Connector Utilize ESSE LINK. recomendo que os jars baixados sejam movidos para um diretório dentro de $CONFLUENT_HOME/share/java.

O Starburst Presto não foi utilizado na arquitetura demonstrada mas, se você quiser saber mais sabre ele, acompanhe a SÉRIE de posts que está em construção. Nesta série iremos adentrar em TODOS os aspectos da configuração e instalação dessa ferramenta em ambiente On-Premises e Azure Cloud.

É necessário também a instalação e configuração do ODBC para o Apache Hive. Será através dele que o Power BI irá se conectar e utilizar os dados para criação dos reports. NESTE LINK será possível seguir o passo a passo para instalação e configuração.

Para instalação do Power BI Desktop basta clicar AQUI.

O link para o GitHub com todos os arquivos de configuração utilizados segue a seguir: https://github.com/arthurjosemberg/lambda-architecture.

Para download do .ppt da apresentação, clique na imagem abaixo:

Espero que vocês se divirtam tanto quanto eu!


Abaixo seguem algumas fotos do evento.

Presto – Distributed Query Engine for Big Data Environment | Introduction

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.

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.

SQL Saturday #804 – São Paulo

Pessoal, no último sábado ocorreu mais uma edição do SQL Saturday em São Paulo. Tive mais uma vez a honra de estar dentre esses profissionais de altíssimo nível que disponibilizam do seu tempo para disseminar conteúdo.

Agradeço de todo coração aos organizadores do evento pelo grandioso trabalho e pelo evento de grande qualidade.

Neste ano palestrei sobre O Ecossistema de BI no Azure. Falei um pouco sobre a arquitetura de BI com base das metodologias de Kimball e, além disso, explorei de maneira robusta sobre as formas de implementar um projeto do zero usando a núvem da Microsoft em modelo IaaS ou PaaS.

Seguem abaixo o slide da palestra.

Não percam as próximas edições em Salvador (clique no link para ter acesso à grade de palestras) e No Rio de Janeiro.