Ao criarmos um modelo e realizarmos a primeira carga de dados, pode não ser vantajoso executar uma carga completa (full load) a cada atualização, especialmente em projetos com grande volume de dados. É justamente nesse ponto que o modo incremental do dbt se torna extremamente útil.

Como exemplo, vamos considerar o SELECT que gera a tabela ft_venda. Inicialmente, ela estaria configurada para realizar uma carga completa dos dados. Porém, se adicionarmos no início do nosso arquivo .sql a instrução:

{{ config(

materialized=’incremental’,

unique_key=[‘id_venda’, ‘id_detalhe_venda’]

) }}

E incluirmos ao final do SELECT uma cláusula de filtro para capturar apenas os dados novos, como:

{% if is_incremental() %}

WHERE cv.data_venda > (SELECT MAX(data_venda)  FROM {{ this }})

{% endif %}

Então o dbt será capaz de identificar e atualizar apenas os registros mais recentes, tornando o processo de carga muito mais eficiente.

Vamos entender melhor o que esses comandos fazem.

Quando definimos no início do arquivo a configuração materialized=’incremental’, estamos informando ao dbt que, no final do script, haverá uma cláusula WHERE responsável por filtrar apenas os dados novos ou alterados. Essa filtragem pode ser ignorada caso optemos por realizar uma carga completa (full refresh), utilizando o parâmetro –full-refresh no comando de execução.

A configuração unique_key é utilizada para definir a chave que o dbt deve considerar ao realizar atualizações (updates). Ou seja, o dbt será capaz tanto de inserir novos registros que ainda não existem no nosso Data Warehouse quanto de atualizar registros já existentes, conforme a chave especificada.

Já o comando {{ this }} é uma referência dinâmica ao modelo atual que está sendo executado. No exemplo dado, ao utilizarmos (SELECT MAX(data_venda) FROM {{ this }}), estamos pedindo ao dbt para buscar a data máxima da tabela destino (o próprio modelo), garantindo que apenas dados mais recentes sejam processados na próxima execução incremental.

Para finalizar, podemos verificar na pasta target, no arquivo run_results.json, se a nossa carga incremental foi realizada corretamente.

No meu caso, a tabela original possuía cerca de 120 mil linhas, e o modelo incremental precisava apenas selecionar as 96 novas linhas e realizar a inserção. É exatamente isso que o arquivo run_results.json nos mostra: a confirmação de que apenas as novas linhas foram processadas e inseridas com sucesso.

Sendo assim, podemos observar a capacidade do dbt de realizar não apenas inserções, mas também atualizações durante nossas cargas de dados, evidenciando o poder e a eficiência dessa ferramenta na construção de pipelines de dados modernos e escaláveis.

Muito Obrigado.

Até o próximo artigo.

No Jenkins, temos a opção de configurar um endereço de e-mail para receber notificações sempre que uma build falhar (ou em outras situações). Para isso, precisamos fazer algumas configurações. No meu caso, vou utilizar um endereço do Gmail.

No Jenkins, vá até o painel de controle, selecione Gerenciar Jenkins e, em seguida, procure pela opção Configurar o Sistema.

Em seguida, na opção Configurar o Sistema, procure pelo campo E-mail do administrador e preencha com o endereço de e-mail desejado. No meu caso, vou colocar o meu próprio e-mail.

Depois, procure pela opção Extended E-mail Notification, onde vamos configurar o servidor SMTP e a porta. Como estou usando o Gmail, vou preencher com:
smtp.gmail.com:465

Antes de seguirmos, precisamos gerar uma senha de aplicativo. Senhas de aplicativo são utilizadas como uma camada extra de segurança quando aplicações precisam acessar sua conta de e-mail. Como estou utilizando o Gmail, vou mostrar o passo a passo específico para ele.

Na sua conta do Gmail, clique no ícone da sua foto no canto superior direito, depois em Gerenciar sua conta Google e vá até a aba Segurança.
Encontre a seção Verificação em duas etapas, habilite essa opção, e depois vá em Senhas de aplicativo para gerar uma nova senha.

IMPORTANTE: Não perca essa senha, pois não será possível visualizá-la novamente depois que a janela for fechada.

Finalizado esse processo, vamos voltar para o Jenkins. Na mesma seção Configurar o Sistema em que estávamos, role até o final e clique em Avançado dentro da opção Extended E-mail Notification.

Lá, você deverá preencher os seguintes campos:

• SMTP Server: smtp.gmail.com

• Porta: 465

• Usuário: seu e-mail completo (ex: seuemail@gmail.com)

• Senha: a senha de aplicativo que você acabou de gerar

• Marque a opção Usar SSL

Depois de preencher tudo, você pode enviar um e-mail de teste marcando o checkbox correspondente e clicando em Testar configuração para verificar se tudo está funcionando corretamente.

Após finalizar as configurações de e-mail, agora podemos configurar o envio automático ao final das execuções dos jobs.

Na etapa de pós-construção do seu job, adicione a ação Editable Email Notification (ou Notificação de E-mail Personalizável, dependendo do idioma).

Nessa seção, você pode definir o(s) destinatário(s) e configurar o envio de e-mails especificamente para quando uma build falhar — basta selecionar a opção Failure no campo Trigger.

Assim, você será notificado automaticamente sempre que algo der errado, sem precisar abrir o console todos os dias para verificar manualmente.

Após a finalização, agora no final de nossa construção, na etapa de pos-construção, podemos habilitar envio de e-mail para construções falhas.

Dessa forma, caso não chegue um e-mail falando que seu JOB falhou, você pode ficar tranquilo pois todos rodaram com sucesso.

Muito Obrigado.

Até o próximo artigo

E uma das dúvidas que surgiram, foi entender como o cliente acessa esses dados, uma vez que processamos os dados com o Spark.

Para facilitar o entendimento vou deixar um tutorial abaixo desde a ingestão dos dados na camada bronze utilizando o Jupyter Notebook e como acessar os dados via Trino.

Então neste exemplo iremos acessar os dados de duas maneiras:

• Jupyter utilizando Pyspark.
• Trino utilizando Querys SQL.

Na nossa Arquitetura acima, temos as nossas camadas bronze, silver e gold armezando todos os nossos dados em formato Delta, aproveitando toda a integração entre Spark & Delta, como por exemplo:

• Time Travel.
• ACID.
• CDF.

Bom vamos lá…

Ao criar um novo Notebook iremos começar pelas configurações do Spark e também do Minio que é aonde armazenamos os nossos dados neste projeto dos Sparkanos.

import pyspark
from pyspark.sql import SparkSession
import logging
spark = SparkSession.builder \
.appName("ELT Full Postgres to Landing AdventureWorks") \
.config("spark.hadoop.fs.s3a.endpoint", "http://minio:9000") \
.config("spark.hadoop.fs.s3a.access.key", "chapolin") \
.config("spark.hadoop.fs.s3a.secret.key", "mudar@123") \
.config("spark.hadoop.fs.s3a.path.style.access", True) \
.config("spark.hadoop.fs.s3a.impl", "org.apache.hadoop.fs.s3a.S3AFileSystem") \
.config("spark.hadoop.fs.s3a.aws.credentials.provider", "org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider") \
.config("hive.metastore.uris", "thrift://metastore:9083") \
.config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
.config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
.getOrCreate()

Agora iremos ler os dados do Minio

E aqui começamos a ler os dados no Jupyter.

Agora iremos gravar os dados desta tabela na camada bronze

Ingestão dos dados feita com sucesso na camada bronze

Agora iremos acessar esses dados via SQL utilizando o Trino, no Dbeaver.

E para acessarmos esses dados precisamos criar os metadados e depois mapear a nossa tabela com o diretório que se encontra os nossos dados:

Comandos SQL no Trino

E agora já conseguimos analisar os dados via SQL

E aqui poderíamos fazer joins com outras tabelas, filtrar dados, agrupar dados basicamente utilizando SQL.

Então nessa arquitetura utilizamos o Spark para processamento dos dados, porém para analisar os dados podemos utilizar basicamente SQL.

E uma vez que os dados chegam no Trino, podemos conectar diversas Ferramentas de Dataviz como: Power BI, Tableau, Qlik e claro as versões Open Sources como Superset e Metabase.

Espero que este artigo tenha te ajudado a entender melhor a sequência e como integramos Spark, Minio e Trino para implementar um Pipeline de dados Robusto e altamente escalável.

Caso queira aprender mais sobre Apache Spark, recentemente fizemos uma Aula de 2 horas de Hand-ons.

Link Aula

Muito Obrigado e até o próximo Artigo.

Rafael Arruda

Recentemente, explorei o uso do Apache Hop, uma poderosa ferramenta de ETL (Extração, Transformação e Carga) que facilita a automação e gestão de processos complexos de integração de dados.

Neste post, quero compartilhar um pouco sobre como o Apache Hop pode transformar seu processo de integração de dados, especialmente quando se trata de automatizar tarefas que exigem precisão e eficiência, como a extração de dados de fontes externas, por exemplo, APIs.

No exemplo fiz para um único CNPJ, mas daria também para ler os cnpjs de uma base SQL e iterar sobre eles.

PASSO 1: Criar uma transform Data Grid (ideal para criar conjuntos de dados estáticos para testes)

PASSO 2:  Clique duas vezes para editar o Data Grid e na aba Meta incluir uma variável endereco.  Na aba  Data incluir a url da receita federal e um cnpj de consulta: http://receitaws.com.br/v1/cnpj/60316817000103

Documentação da API:  https://developers.receitaws.com.br/#/operations/queryCNPJFree

Passo 3: Incluir uma transform Json Input e conectar a transform Data Grid na transform Json Input.

Passo 4: Clique 2 vezes para abrir a transform Json Input e marque a caixa source is from… para dizer a ele que a origem dos dados vem de uma transform anterior.

Em select Field selecione a variável endereco.

Em read source…, marca a caixa, indicando que o json será obtido da internet.

Passo 5: Na aba Fields incluir os campos que você quer capturar, presumindo que já olhou a documentação e conhece a  estrutura do json.

Passo 6: Clique em Executar Pipeline ou Preview e veja os dados do cnpj capturado.

Durante a apresentação, demonstrei como o Apache Hop pode ser utilizado para recuperar dados diretamente da Receita Federal, exemplificando o uso de uma API pública de consulta de CNPJ. A facilidade com que o Apache Hop permite criar pipelines de dados, desde a definição de um simples conjunto de dados estáticos para testes, até a conexão e manipulação de dados JSON vindos de uma API, é algo que pode acelerar significativamente o desenvolvimento de soluções de integração.

A utilização de transformações como o Data Grid, que cria conjuntos de dados estáticos para testes, e o Json Input, que lê e processa dados JSON diretamente da web, exemplifica o quão versátil e eficiente o Apache Hop é para tarefas de ETL. Com poucos cliques, é possível estruturar e transformar dados em informações valiosas para qualquer tipo de análise ou integração.

O Apache Hop se destaca não apenas pela sua flexibilidade, mas também pela facilidade de uso, permitindo que tanto iniciantes quanto profissionais experientes possam configurar pipelines complexos de forma intuitiva. Se você está lidando com grandes volumes de dados ou precisa integrar várias fontes de dados em um fluxo único, o Apache Hop é uma ferramenta que merece sua atenção.

Este é apenas um exemplo do poder e da versatilidade do Apache Hop. Em um cenário onde a qualidade e a integridade dos dados são fundamentais, investir em uma solução robusta como essa pode fazer toda a diferença para o sucesso do seu projeto.

Muito Obrigado.

Nilson Braga

Gostou deste post? Conecte-se comigo no linkedin

Hoje vamos ter uma Super-Live!

Iremos demonstrar um case que implementamos de um Data Lake 100% Open Source em uma grande empresa aqui em Portugal.

Para toda a etapa de Processamento e tratamento dos dados utilizamos o Apache Spark para processar, criando uma Solução robusta e escalável.

Quer saber mais detalhes?

Assista a nossa Live!!!

https://links.arrudaconsulting.com.br/livesparkanoswhats

Obrigado.

E ao criar um DW, provavelmente que iremos ter esse tratamento de dados em alguns etl, como nas seguintes dimensões:

• Dim_Funcionarios.
• Dim_Clientes.
• Dim_Leads.

Em todas dimensões mencionadas acima teriamos que fazer um mesmo tratamento, que é concatenar as colunas: First_Name e Last_Name.

O objetivo deste artigo é compartilhar uma funcionalidade que aprendi esses dias, que basicamente teríamos um etl para fazer este procedimento e chamaríamos este etl nas três dimensões informadas no início do artigo.

Então vamos para o nosso Hand-ons.

Primeiro, iremos criar o pipeline que as dimensões irá chamar.

Então com Mapping Input iremos informar exatamente os mesmos campos que são utilizados nas dimensões:

Com o Concat fields, criamos uma nova coluna, concatenando as duas colunas mencionadas acima numa nova coluna chamada name.

Importante utilizarmos um espaço, como separador.

E finalizamos este pipeline com o Mapping Output, não é necessário fazer nenhuma configuração neste step.

Agora salvamos este pipeline, e iremos começar o etl que irá chamar este pipeline que acabamos de criar.

Neste ETL iremos ler uma tabela de funcionários, e iremos chamar o pipeline que criamos para ler os dados de first_name e last_name e fazer o concat pra nós.

Já imaginou subir o teu ambiente de Desenvolvimento em 1 min na Cloud? Pois bem eu achava que isso era algo muito distante, algo que somente programadores ou profissionais de Devops poderiam fazer, acho que me enganei mais uma vez.

Nos últimos 2 anos temos tido quase que uma imersão em projetos Google Cloud, somente neste momento temos 5 projetos acontecendo ao mesmo tempo, um começando outro sendo entregue, mas é uma quantidade considerada de projetos numa mesma Cloud.

Isso falando somente da nossa empresa, o curioso que em nenhum projeto a Arquitetura é igual a outra, pois cada empresa é única e cada projeto é único.

Recentemente fomos contratado para criar a Infra-estrutura de um projeto que será implantado o Data Lake, até aqui tranquilo, porém tinha que ser feito em Terraform.

Terraform é uma ferramenta de código aberto desenvolvida pela HashiCorp que é usada para automatizar a implantação e a gestão de infraestrutura como código (IaC).

Com ele podemos criar toda uma Infra-estrutura nas nuvens da Google Cloud, AWS ou Azure utilizando scripts, seja para criar Servidores, Bucket, bancos de dados, entre diversos outros recursos.

Desafio aceito, segue abaixo de um vídeo demonstrando como Subimos o nosso ambiente de DEV na Arruda Consulting, utilizando Terraform.

Muito Obrigado.

Rafael Arruda.

Tudo bem contigo?

Hoje venho trazer uma dica que se soubesse desde o início teria ganho boas horas de sono, pois bem.

Quantas vezes você já teve problemas de carga no seu ETL, imagina que está carregando um milhão de registros na sua tabela e por causa de um erro em um registro toda a carga foi comprometida, é um cenário que principalmente quando estamos começando pode acontecer, se Você utiliza o Pentaho / Apache Hop eu tenho uma boa notícia pra ti…

É possível identificar os registros que tiveram erro, e todos os demais registros serem carregados com sucesso, vamos ver como podemos fazer este process…

No exemplo abaixo estamos implemetando uma dimensão de clientes, estamos lendo os dados da Stage, tratando os dados e carregando para o nosso DW, o famoso ETL.

Ao executar este Pipeline, tivemos o seguinte erro:

Aqui temos um exemplo claro de estouro de caractér, e sorte nossa que o log nos ajuda nisso, informando exatamente qual o campo que temos que aumentar o limite de caractér, essa foi fácil é só aumentar o tamanho do campo e pronto.

Mas imagina que amanha seja outro campo, vai ser mais um dia com erro no ETL, e isso não é legal, então temos uma tratativa para isso, utilizando o Error Handling.

Ao ligar o step Text File output por exemplo, todos os registros que derem erro no step de inserir os dados na dim_customer serão encaminhados para este arquivo

Então neste caso se minha carga for de um milhão de registros e apenas duas linhas estiverem com erro todos os outros registros serão carregados com sucesso, é muito mais simples tratar dois registos do milhões de linhas.

Ao executar o nosso Pipeline percebemos que não tivemos erro e que 90 registros foram inseridos na tabela e um registro foi encaminhado para o arquivo texto.

E aqui temos exatamente o registro que deu erro na carga inicial e sabemos que a palavra “NAO INFORMADO” tem mais de 9 caracteres por isso o estourou o limite do campo.

Espero que essa dica tenha sido útil pra ti!!

Caso queira aprender outros steps do Apache Hop, Assista o nosso Webinar.

Muito Obrigado e até o próximo artigo!!

Introdução

Dentro do universo dos sistemas de gerenciamento de bancos de dados (SGBDs), como PostgreSQL, a ferramenta EXPLAIN ANALYSE desempenha um papel crucial na otimização e eficiência das consultas SQL. Este artigo detalha o uso do EXPLAIN ANALYSE, fornecendo exemplos práticos e orientações sobre a interpretação dos resultados.

O que é EXPLAIN ANALYSE?

EXPLAIN ANALYSE é um comando SQL usado para analisar o plano de execução de consultas SQL. Ele executa a consulta e fornece estatísticas detalhadas sobre o tempo e recursos utilizados, indo além do que o EXPLAIN simples oferece.

Quando Utilizar

1. Análise de Desempenho de Consultas
2. Otimização de Consultas
3. Indexação Eficaz
4. Depuração

Exemplos de Comandos e Interpretação dos Resultados

Exemplo 1: Consulta Simples

Comando:

Resultado:

Interpretação:

• Seq Scan: Indica que foi feita uma varredura sequencial na tabela clientes.
• Cost: Estima o custo da operação (custo inicial..custo total).
• Rows: Número de linhas que o PostgreSQL espera processar.
• Actual time: Tempo real de execução (início..fim).
• Rows Removed by Filter: Quantidade de linhas descartadas pelo filtro.
• Planning/Execution Time: Tempo de planejamento e execução da consulta.

Exemplo 2: Consulta com Join

Comando:

Resultado:

Interpretação:

•  Hash Join (cost=4.27..8.31 rows=100 width=384) (actual time=0.026..0.027 rows=100 loops=1)
  
  O PostgreSQL está realizando um Hash Join entre duas tabelas, pedidos e clientes. O cost=4.27..8.31 indica o custo estimado dessa operação, começando de 4.27 e indo até 8.31. rows=100 sugere que o otimizador espera que 100 linhas sejam retornadas, e width=384 indica o tamanho médio de cada linha em bytes. Na prática, essa operação levou de 0.026 a 0.027 milissegundos (actual time) e foi executada uma vez (loops=1), retornando 100 linhas (rows=100).O PostgreSQL juntou as tabelas pedidos e clientes rapidamente, esperando encontrar cerca de 100 linhas, o que realmente aconteceu.
• Hash Cond: (pedidos.cliente_id = clientes.id)
  
  Esta é a condição do join. O PostgreSQL usou o campo cliente_id da tabela pedidos e o campo id da tabela clientes para juntar as duas tabelas.
• Seq Scan on pedidos (cost=0.00..2.00 rows=100 width=148) (actual time=0.006..0.007 rows=100 loops=1)Aqui, o PostgreSQL fez uma varredura sequencial (Seq Scan) na tabela pedidos. Estimou um custo de 0.00 a 2.00, esperando encontrar 100 linhas (rows=100) com um tamanho médio de linha de 148 bytes (width=148). Na prática, essa varredura levou de 0.006 a 0.007 milissegundos e encontrou 100 linhas.
• Hash (cost=2.20..2.20 rows=120 width=236) (actual time=0.012..0.012 rows=120 loops=1)Este processo levou exatamente 0.012 milissegundos (actual time) e foi realizado uma vez (loops=1), processando 120 linhas (rows=120) como previsto.
• Buckets: 1024 Batches: 1 Memory Usage: 26kBEstes detalhes referem-se à operação de hash mencionada acima.
• Buckets: 1024: indica o número de compartimentos utilizados na estrutura de hash.
• Batches: 1 significa que a operação de hash foi realizada em um único lote.
• Memory Usage: 26kB: mostra a quantidade de memória utilizada para a operação de hash.
• Planning Time: 0.065 msEste é o tempo que o PostgreSQL levou para planejar a execução da consulta. Neste caso, foram 0.065 milissegundos.
• Execution Time: 0.076 msEste é o tempo total que o PostgreSQL levou para executar a consulta, incluindo o join e as varreduras nas tabelas. O tempo foi de 0.076 milissegundos.

Melhores Práticas

• Use em ambiente de testes.
• Compare os planos de execução antes e depois das otimizações.
• Utilize como forma de definir melhor estratégia para suas consultas, definindo pela melhor performance.
• Realize análises periódicas.

Conclusão

O EXPLAIN ANALYSE é essencial para a otimização de consultas em SGBDs. A compreensão dos resultados pode levar a melhorias significativas no desempenho, tornando-se uma ferramenta valiosa para profissionais da área de dados.

Hoje estamos aqui para compartilhar um projeto que estamos desenvolvendo para um dos nossos clientes, e um tema muito importante, automatização de processos.

Atualmente é muito comum pensarmos em projetos de BI, Big Data mas o teu cliente já tem os processos automatizados?

Pois não adianta querer Criar uma solução de BI se as áreas que geram as informações para o BI, tem um excessivo trabalho manual todos os dias, você pode fazer um grande trabalho e é muito provavém que não irão dar o devido valor ao seu trabalho.

Mas Porque isso aconteceria? Como eles tem tarefas repititivas  eles estarão ocupados com isso.

Agora se começamos em automatizar essas tarefas manuais, o cliente irá ver um resultado a curto prazo e isso dará mais confiança e mais receptivo para um projeto de BI ou até de Big Data, são etapas.

Iremos começar por Vendas, então criamos um ETL no Pentaho para ler dados de Vendas por representante e cliente, iremos fazer alguns tratamentos e poder enviar esses dados todos os dias para cada supervisor da empresa.

Sendo assim, todos os dias irão saber O total de vendas realizadas e vendas pendentes, tudo isso de forma automática.

Imagina que essa tarefa era realizado todo dia por um ou mais analistas, a lógica é que as pessoas utilizem o seu tempo para analisar os dados, para preparar temos o Pentaho, aonde fazemos um fluxo uma única vez e agendamos para executar de forma automática.

E quando falamos em automatizar processos na empresa é isso, para nós pode parecer uma tarefa simples, mas só depois de fazer que vemos o impacto que isso gera numa área, agora se fazemos isso em outras áreas impactos toda a empresa.

O Próximo passo seria utilizar o Metabase para explorar os dados e criar relatórios e até Dashboards.

O Metabase é uma solução incrível e gratuita para criação de relatórios e Dashboards.

E assim utilizando soluções robustas e gratuitas como Pentaho e Metabase podemos criar soluções de BI para diversas empresas.

Quer conhecer mais sobre essa solução, então não perca a nossa próxima live no dia 22/08 as 19:00.

Neste Webinar iremos explorar como podemos criar uma Plataforma de Dados de forma 100% Gratuita, utilziando Pentaho e Metabase.

Iremos tratar alguns dados e depois explorar esses mesmos dados para gerar insights, e como conseguimos ter um BI quase que real-time.

Este é o nosso trabalho capacitar vocês e impactar as empresas utilizando os dados.

Link: Criando uma Solução de BI 100% Gratuita – YouTube

Muito Obrigado.

Rafael Arruda