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.

Um comentário sobre “Presto – Distributed Query Engine for Big Data Environment | Concepts

  1. Pingback: Presto – Distributed Query Engine for Big Data Environment | On-Premises Installation – Arthur Luz | Data's Light

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