Então na Arquitetura acima temos as seguintes tecnologias:

• Toda Stack em Containers.
• Apache Hop Para ingestão dos dados.
• DBT para Transformação e validação dos dados.
• Postgres para DW.
• Jenkins como CI/CD e Orquestração.

Agora imagine o seguinte cenário: seu gerente prefere uma solução em nuvem. Em vez de armazenar os dados no PostgreSQL, você os coloca no armazenamento da cloud escolhida.

Se for Google Cloud, usamos o Hop para gravar no Cloud Storage e o dbt atua sobre o BigQuery.

Se for AWS, gravamos no S3 e podemos usar Athena ou Redshift.

Se for Snowflake ou Databricks, a stack continua a mesma — já que ambas se integram nativamente com os storages das três principais clouds.

Todo o restante da Stack não mudaria.

Exemplo prático com SnowFlake

Snowflake tem integração com as três principais Clouds:

• AWS.
• Google Cloud.
• Azure.

Para este exemplo iremos gravar os dados no S3 da Amazon, porém o processo seria exatamente o mesmo para as demais clouds.

Para começar, usamos o Apache Hop para ler dados de um banco PostgreSQL e gravá-los no S3, em formato Parquet.

Cada tabela possui sua respectiva pasta e arquivos:

A partir daqui temos duas formas de acessar esses dados do Snow, Utilizando Python ou SQL.

Com Python teriamos um Script para ler esses dados e gravar em tabelas nativas do Snowflake.

Mas se você não tem muita habilidade com Python, fique tranquilo pois é possível fazer este processo todo utilizando somente SQL.

Para isso será necessário Criar um Stage informando alguns dados da sua conta da AWS ou da sua Cloud que utiliza na sua empresa.

Dessa forma já conseguimos acessar os nossos dados do S3 dentro do Snowflake.

Agora, ao criar um Arquivo SQL, vamos poder manipular esses dados.

Uma alternativa seria criar a tabela já com os seus devidos campos, mas se no amanhã é adicionado novas colunas nesses arquivos do S3, teriamos que alterar aqui também.

Então uma prática que resolvi adotar foi criar a tabela com uma única coluna para armazenar os dados.

E na camada Silver tratar esses dados, mas isso será feito lá no DBT.

Camada Bronze -> raw_orders.

Camada Silver -> stg_orders

/* 
SELECT    
          data:customer_id::VARCHAR AS customer_id,
          data:employee_id::INT AS employee_id,
          data:freight::DECIMAL(10, 2) AS freight,
          data:order_date::TIMESTAMP AS order_date,
          data:order_id::INT AS order_id,
          data:required_date::TIMESTAMP AS required_date,
          data:ship_address::VARCHAR AS ship_address,
          data:ship_city::VARCHAR AS ship_city,
          data:ship_country::VARCHAR AS ship_country,
          data:ship_name::VARCHAR AS ship_name,
          data:ship_postal_code::VARCHAR AS ship_postal_code,
          data:ship_via::INT AS ship_via,
          data:shipped_date::TIMESTAMP AS shipped_date 
FROM {{ source('bronze', 'raw_orders') }}
*/

Com o arquivo stg_orders.sql criado ao executar o comando dbt run.

A Tabela foi criada com sucesso.

E assim temos a nossa tabela de pedidos na camada silver.

E ao gerar a documentação do DBT, temos a linhagem de dados.

Com o Apache Hop fazendo a ingestão dos dados, DBT para transformação e o DW no Snowflake, aonde entraria o Jenkins neste processo?

O Jenkins é uma peça vital nessa Arquitetura mas ele entra no final, utilizamos ele em duas etapas:

• Orquestração de todo o Pipeline.
• CI/CD.

No Link abaixo gravei um vídeo demonstrando como funciona na prática o processo de CI/CD desde o commit da Branch até o deploy.

Como funciona o CI/CD com Jenkins na prática

O vídeo foi gravado com a Stack original utilizando o Postgres como DW, mas o processo seria praticamente o mesmo com Snowflake.

Veja que na nossa Arquitetura do Data Speed, você pode ter o seu DW num banco postgres, mas também seu DW pode estar na Cloud, como acabamos de demonstrar nesse artigo, porém todo o restante não muda em nada.

Caso já utiliza AWS e prefere disponibilizar os seus dados na Amazon temos um artigo parecido com este mas utilizando S3 e Athena.

Replicando a Stack Data Speed na AWS

Quer aprender a implementar essa Stack do zero?

Conheça o projeto Data Speed e leve seus projetos a um outro  nível:

https://dataforspeed.arrudaconsulting.com.br/

Muito Obrigado.

Até o próximo artigo

Rafael Arruda

Então na Arquitetura acima temos as seguintes tecnologias:

• Toda Stack em Containers.
• Apache Hop Para ingestão dos dados.
• DBT para Transformação e validação dos dados.
• Postgres para DW.
• Jenkins como CI/CD e Orquestração.

Agora imagine o seguinte cenário: seu gerente prefere uma solução em nuvem. Em vez de armazenar os dados no PostgreSQL, você os coloca no armazenamento da cloud escolhida.

Se for Google Cloud, usamos o Hop para gravar no Cloud Storage e o dbt atua sobre o BigQuery.

Se for AWS, gravamos no S3 e podemos usar Athena ou Redshift.

Se for Snowflake ou Databricks, a stack continua a mesma — já que ambas se integram nativamente com os storages das três principais clouds.

Todo o restante da Stack não mudaria.

Exemplo prático com AWS

Para começar, usamos o Apache Hop para ler dados de um banco PostgreSQL e gravá-los no S3, em formato Parquet.

Cada tabela possui sua respectiva pasta e arquivos:

Com os dados no S3, agora já conseguimos consultá-los usando o Athena, que é um serviço serverless da AWS que permite consultas SQL diretamente sobre arquivos no S3.

Tanto Athena quanto Redshift possuem integração nativa com dbt.

Veja abaixo os dados sendo consultados no Athena:

Conclusão

Em vez de utilizar o PostgreSQL, conseguimos criar um Data Lake na AWS, mantendo exatamente a mesma stack do Data Speed.

A grande vantagem é que nos preocupamos apenas com o processamento. O armazenamento e a consulta são administrados pela AWS.

E o que mais encarece um projeto na nuvem geralmente é o processamento contínuo. Neste caso, você só paga pelo que rodar — e se estiver usando máquinas locais, nem esse custo terá.

Muito Obrigado.

Rafael Arruda

Na pasta models, podemos inserir todos os arquivos diretamente nela ou organizá-los em subpastas. Independentemente da estrutura adotada, é possível criar um arquivo .yml de documentação para cada subpasta, facilitando a separação por domínio ou área. Caso prefira, também é válido manter um único arquivo .yml na raiz da pasta models, centralizando a documentação de todos os modelos.

Após essa organização, ao editar o arquivo .yml, podemos indicar os modelos presentes no projeto, referindo-nos diretamente a cada arquivo .sql da pasta models. Em seguida, é possível documentar o nome das tabelas, suas colunas e, quando necessário, definir testes de integridade como not_null, unique, accepted_values e relationships.

Como podemos ver na imagem acima, primeiro definimos o nome da tabela — que deve ser o mesmo nome do arquivo .sql (sem a extensão) — e em seguida adicionamos a descrição da tabela. Essa descrição já serve como documentação e pode indicar, por exemplo, a área de negócio à qual ela pertence (como Financeiro, RH, Logística, etc.), os tipos de dados que ela armazena e outras informações relevantes sobre seu uso.

Logo abaixo, passamos a descrever as colunas da tabela, preenchendo uma a uma. Para cada coluna, também é possível adicionar uma descrição e definir testes automatizados. Entre os testes mais comuns estão:

• not_null: garante que a coluna não contenha valores nulos
• Unique: assegura que os valores sejam únicos na coluna
• accepted_values: restringe os valores possíveis a uma lista predefinida: values: [‘PF’, ‘PJ’]
• Relationship: verifica se a coluna está relacionada corretamente a outra tabela, como uma chave estrangeira: to: ref(‘dim_loja’) field: id_loja

A opção not_null faz com que o dbt verifique se existe algum valor nulo em uma coluna que deve conter obrigatoriamente dados, ajudando a garantir a integridade da informação.

A opção unique garante que todos os valores da coluna sejam únicos, ou seja, que não haja repetições — algo essencial em colunas que representam chaves primárias, por exemplo.

A opção accepted_values permite definir uma lista de valores válidos para a coluna, o que é especialmente útil para capturar possíveis erros de entrada vindos da fonte de dados, como valores inesperados ou fora do padrão.

A opção relationships é utilizada quando um modelo faz referência a outro modelo. Com ela, o dbt verifica se todos os valores da coluna referenciada realmente existem no modelo de destino, funcionando como uma verificação de integridade referencial — semelhante a uma chave estrangeira em bancos de dados relacionais.

Depois de definir os testes em seus modelos, você pode executá-los com o comando: dbt test –select silver.ft_venda, você também pode executar os testes de toda uma pasta ao usar apenas o nome da pasta: (dbt test –select silver) Isso irá rodar todos os testes definidos dentro dos modelos presentes na pasta silver.

Com isso, podemos verificar que os testes de dados foram aplicados corretamente.

Após configurar todas essas etapas — que já contribuem significativamente para a documentação do projeto — podemos executar o comando dbt docs generate. Esse comando irá gerar um arquivo .json contendo todas as informações de modelos, colunas, descrições e testes definidos.

Em seguida, para visualizar essa documentação de forma interativa em um navegador, basta executar dbt docs serve –port 9000.

O parâmetro –port é opcional; se não for especificado, o dbt utilizará a porta padrão 8080. Após iniciar o servidor local, você poderá acessar a documentação do projeto diretamente pelo navegador.

Além disso, ao acessar a documentação gerada pelo dbt, podemos clicar no botão azul no canto inferior direito da tela para visualizar a linhagem dos dados (data lineage). Essa funcionalidade permite entender, de forma gráfica e interativa, como os modelos se conectam entre si — desde as fontes até as tabelas finais — facilitando o rastreamento de dependências e o entendimento do fluxo de dados no projeto.

Agora, nosso projeto conta com testes automatizados para validação dos dados, está totalmente documentado e ainda oferece a possibilidade de disponibilizar essa documentação de forma acessível a todos, diretamente pelo navegador.

Se quiser ter acesso a um conteúdo mais detalhado combinando DBT com outras ferramentas como Apache Hop, Jenkins, Git e Postgres, se inscreva no evento.

E com certeza os seus projetos irão mudar de patamar após este rico conteúdo.

Link Evento

Muito Obrigado.

E até o próximo artigo.

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.

Ao utilizarmos uma infraestrutura de dados moderna, é comum realizarmos diversas transformações por meio de SQL, aproveitando a alta performance dos bancos de dados mencionados. No entanto, à medida que o projeto cresce, torna-se difícil manter o controle dos scripts, mesmo com os recursos nativos dessas plataformas. Além disso, a documentação dessas transformações tende a ser negligenciada ou difícil de manter, o que pode comprometer a governança e a escalabilidade do projeto.

Ao iniciarmos um projeto no dbt, temos a pasta models, onde podemos criar várias subpastas para organizar nossos modelos SQL. Essa estrutura modular facilita a manutenção e leitura do código, especialmente em projetos maiores com múltiplas áreas de negócio ou etapas de transformação.

Após termos nosso modelo desenvolvido, podemos começar a realizar a documentação do mesmo, e a melhor parte? A documentação fica na mesma pasta do model, em um arquivo .yml, no exemplo acima, fica no arquivo de dw.yml.

Como podemos ver neste arquivo, estou definindo o nome e a descrição da tabela, além de documentar o nome e a descrição de cada coluna. Também estou adicionando alguns testes de dados — como, por exemplo, na coluna id_venda — para garantir que os dados tenham o tipo e o retorno esperados durante a transformação.

Além disso, o dbt permite configurar múltiplas conexões no arquivo profiles.yml, conhecidas como targets. Isso significa que, com a adição de uma simples flag no comando de execução, é possível alternar o ambiente onde o script será executado, como entre produção, homologação ou desenvolvimento.

Se alterarmos o comando de execução de dbt run para dbt run –target dw_prod, o dbt utilizará a nova conexão definida no profiles.yml, criando automaticamente o schema correspondente (caso ainda não exista) e executando as transformações, incluindo a criação das tabelas no novo destino.

Isso nos permite separar ambientes como dev, homologação e produção, garantindo maior controle e segurança durante o ciclo de desenvolvimento. Além disso, como o dbt organiza as transformações em arquivos SQL dentro de um projeto estruturado, podemos versioná-lo em plataformas como GitHub ou GitLab.

Isso facilita o trabalho colaborativo entre desenvolvedores, promovendo revisões de código, controle de mudanças e aumento significativo da produtividade da equipe.

Ao finalizar o ciclo de desenvolvimento, podemos rodar o comando dbt docs generate, onde o dbt vai gerar a documentação do projeto com base nas nossas configurações. Logo depois, podemos usar o comando dbt docs serve, onde essa documentação vai ficar disponível pela porta 8080 (padrão) do navegador, podendo alterar a porta com o comando –port para não ter conflito com demais aplicações.

Também podemos ver a linhagem dos dados, para saber quais tabelas foram utilizadas para gerar a de destino como mostra na imagem abaixo.

Dessa forma, temos um projeto documentado e colaborativo.

Muito Obrigado.

Time Arruda Consulting

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

• Tratar os dados por coluna.
• Tratar os dados por tipo de dados.

Quando tratamos os dados por coluna, no nosso ETL informamos o valor de cada coluna que iremos substituir, caso tenha algum valor nulo, se semana que vem a área de negócio adiciona duas colunas a mais na fonte de dados, somos obrigados a adicionar essas duas colunas no nosso fluxo.

Já quando trabalhamos com tipos de dados para valores nulos, a vantagem que não tem muitos tipos de dados, e se é adicionado essas duas colunas, o nosso fluxo vai estar preparado para receber essas novas informações e aplicar o tratamento de forma correta.

Vamos ver isso na prática.

Começamos com um Data Grid.

Temos duas colunas, uma do tipo de dados Int e a outra com o tipo de dados String, então iremos utilizar o Step: “If Null”

Começamos pela opção de fazer pelas colunas, escolhendo cada coluna e qual o valor que irá substituir os valores nulos.

E agora iremos fazer pelo tipo de dados.

Como neste exemplo estou utilizando duas colunas, não muda muito mas imagina que fosse 30, 60 colunas, já mudaria algo, quase sempre vamos ter menos tipos de dados do que colunas, então trabalhando com tipo de dados ganhamos uma certa produtividade.

Agora iremos fazer o seguinte teste, ao incluir uma coluna Status do tipo Integer, como o nosso null estamos trabalhando com tipo de dados, meu processo já estará preparao para aplicar o tratamento mesmo assim.

Embora sistemas operacionais como Linux (com o cron) ou Windows (com o Agendador de Tarefas) ofereçam mecanismos nativos de agendamento, essas abordagens muitas vezes carecem de recursos importantes, como:

• Controle de histórico de execuções;

• Logs detalhados e organizados;

• Facilidade para gerenciar múltiplas tarefas e pipelines em um único painel;

• Integração com sistemas de versionamento como Git.

É aí que o Jenkins entra como uma excelente alternativa para o agendamento de tarefas de forma robusta e centralizada.

O Jenkins é uma ferramenta open-source amplamente utilizada para automação, integração contínua (CI) e entrega contínua (CD), atuando também como um eficiente agendador de tarefas (jobs). Quando utilizado para agendamento, o Jenkins permite definir rotinas automáticas por meio de expressões cron, facilitando a execução periódica e pontual das tarefas.

No nosso exemplo, como o nosso Apache Hop está num container, o comando iremos chamar o container e executar o comando do Hop-Run.

Seja no Agendador do Windows, ou no Jenkins, podemos utilizar o Hop-run que irá executar um Workflow ou Pipeline por linha de comando, no link abaixo tem um artigo detalhando melhor como funciona o Hop-Run.

Automatizando o seu pipeline no Apache Hop.

Para projetos menores, o agendador do windows irá lhe atender, porém ao projeto crescer vai chegar uma hora que um Orquestrador como o Jenkins começa a ser fundamental.

Além disso, o Jenkins armazena o histórico de cada execução, mantendo logs detalhados sobre os comandos executados. Essa funcionalidade auxilia no monitoramento, auditoria e diagnóstico de eventuais problemas.

Outro diferencial é o controle por usuários. O Jenkins registra quem realizou login no sistema e quem criou ou modificou os jobs, proporcionando maior segurança e controle sobre o ambiente.

Por fim, o Jenkins dispõe de diversos plugins que expandem suas funcionalidades, permitindo adaptar a plataforma às necessidades específicas de cada equipe ou projeto.

Cada vez mais temos vistos projetos que utilizam Apache Hop sendo orquestrados pelo Jenkins, e cada vez mais iremos ver este cenário.

Muito Obrigado e até o próximo artigo.

O Apache Hop é uma excelente solução para implementar um Data Warehouse ou um Data Lake, seja em um ambiente On-Prem ou na Cloud, e uma etapa importante nessa etapa é a validação dos dados.

E é justamente esste tema que iremos abordar nesse artigo.

Você já ouviu falar do Step: Data Validator?

Próprio nome já diz, é um step aonde conseguimos criar algumas validações, ou condições se o fluxo irá seguir adiante ou não.

Imagina que a sua principal coluna está com alguns dados nulos, o que é melhor carregar esses dados errado mesmo? ou receber algum email ou alerta com os dados que precisa tratar, os dados que estiverem corretos, serão carregados normalmente.

A validação dos dados é uma etapa muito importante em qualquer projeto na área de dados.

Não basta apenas disponibilizar os dados, a informação precisa estar verificada e confiável também.

Para este exemplo, iremos utilizar duas colunas:

Ao adicionar o Step Data Validator, iremos clicar em “New Validation”, ao soliticar o nome dessa verificação iremos colocar: cod_null.

Iremos desabilitar a opção “Null allowed”, ou seja essa coluna cod, não pode receber dados nulos

Ao executar o nosso pipeline, verificamos que a validação funcionou, como temos um registro nulo na coluna cod, o pipeline deu erro, e não seguiu adiante.

O Step error nós poderíamos configurar para enviar um e-mail ou alerta para a área responsável corrigir o dado direto no sistema de origem. Já o Step pass, permitiria que o dado seguisse adiante no fluxo de dados.

Esse foi apenas um exemplo simples do poder do Data Validator. Com ele, é possível criar pipelines mais seguros, confiáveis e inteligentes.

Quer aprender outros Steps do Apache Hop?

Então veja a nossa aula com 2 horas de conteúdo de Apache Hop.

Link Live

Muito obrigado e até o próximo artigo.

Rafael Arruda.

Caso você ainda não tenha o Knime Analytics Platform instalado na sua máquina, acesse o nosso artigo para aprender a instalar o Knime no seu computador.

Aprenda os Termos Básicos do KNIME

Antes de começar a usar o KNIME, é importante conhecer alguns termos chave que serão usados ao longo deste guia. Aqui estão os principais:

• Workflow (Fluxo de Trabalho): É o “mapa” do seu processo, um conjunto de passos conectados que formam seu projeto. Pense nele como o seu processo de análise de dados completo.
• Node (Nó): Cada node no KNIME representa uma ação ou etapa específica do seu fluxo de trabalho. É nele que você configura as transformações ou análises dos dados.
• Connector (Conector): São as linhas que conectam os nodes. Elas indicam a sequência e o fluxo de dados entre as etapas do seu workflow.
• KNIME Hub → Um Repositório online com exemplos de workflows e extensões. É como se fosse uma pasta (ou drive) onde pessoas do mundo todo publicam seus trabalhos para divulgação ou para ajudar outras pessoas que queiram resolver problemas parecidos.

Como funciona a Interface do KNIME Analytics Platform

Agora que você já sabe o mínimo sobre as nomenclaturas, podemos partir para a área de trabalho do KNIME. Ela é composta por 2 layouts, o clássico (presente nas versões antigas) e o moderno, que vamos utilizar nesse artigo.

PS: Você pode ocasionalmente intercalar entre os dois layouts conforme sua preferência, mas a nossa explicação focará no Layout “moderno”.

Ao abrir o KNIME Analytics Platform, você verá a interface dividida em várias seções. O layout é moderno e fácil de usar, com as seguintes partes principais:

• Navegador de Ambiente: Aqui você pode acessar os seus projetos locais e explorar os workflows públicos no KNIME Hub. Para acessar os workflows do Hub, é necessário criar uma conta e fazer login.
• Painel de Exemplos: Mostra workflows prontos para que você possa começar rapidamente ou buscar inspiração.
• Criar Workflow: A partir desta opção, você pode criar um novo workflow para começar seu projeto.
• Workflows Recentes: Aqui você encontra os projetos que você acessou ou editou recentemente.

Ao criar ou acessar um Workflow, a janela de edição é habilitada na interface, trazendo as opções abaixo:

• Navegador de Abas: Permite alternar entre diferentes workflows que você tenha aberto (clique em “+” para adicionar um novo Workflow rapidamente).
• Guias laterais:

1. 1. • Info: Acesse a descrição do workflow ou componente selecionado.
      • Nodes: Centraliza todos os nodes disponíveis no KNIME Analytics Platform, com uma busca inteligente, fica fácil você encontrar o que precisa e simplesmente arrastar para a área de edição.
      • Explorer: Navegue pelas pastas que estão dentro do seu diretório local do KNIME ou então acesse os diretórios do Hub da comunidade.
      • Monitor:Verifique, monitore e acesse alertas e possíveis erros que podem impedir seu workflow de rodar corretamente.

• Help, Preferences e Menu: Acesse materiais de apoio, faça configurações avançadas e instale novas extensões.

• Workflow Editor: Área de trabalho para desenvolvimento do Workflow ativo. Adicione novos nodes arrastando e conectando eles.

• Node Monitor: Mostra os resultados do node selecionado e também o valor das variáveis ativas.

Como criar e editar Workflows no KNIME Analytics Platform

Para trabalhar com um workflow podemos criar um novo, acessar um antigo, abrir um exemplo ou até mesmo explorar os workflows da comunidade (em breve faremos um artigo falando só disso). Isso pode ser feito de 3 formas:

1. Clicando em “New Workflow” na tela inicial do KNIME;
2. Acessando os Workflows recentes também na página inicial;
3. Clicando em + no navegador de abas presente na tela de Edição de Workflow (quando houver um workflow aberto);

Dentro desse novo Workflow, você pode começar seu desenvolvimento clicando e arrastando nos nodes que se encontram no painel lateral na guia de nodes.

Como são estruturados os Nodes

Os nodes são o coração do desenvolvimento no KNIME, é através dele que você pode ler/gravar arquivos de diversos formatos, operar transformações, operações matemáticas, sequências lógicas e de automação em diversos níveis, além de criação de gráficos e uma infinidade de outras funções, incluindo scripts de programação, algoritmos estatísticos e machine learning.

Como é estrutura de um node:

• Tipo do Node: O título principal que você vai encontrar logo acima do node fala sobre o tipo de node que ele é, isso facilita tanto na hora de você buscar nodes novos quanto na hora de você fazer a manutenção dos nodes já inseridos no seu Workflow, facilitando a documentação e identificação dos processos.
• (Input port) Porta de Entrada: É onde você conecta a tabela de dados que serão processados.
• (Output Port) Porta de Saída: Nela está presente o resultado do processamento do node atual. Conecte ela a uma porta de entrada de outro node para dar continuidade no processo. Também é possível através da seção “node monitor” verificar o resultado dos dados processados.
• (Node Annotation) Comentário do node: Essa descrição curta pode ser editada manualmente para facilitar a documentação ou guardar informações curtas sobre o que está sendo feito no node.
• (Node Status) Status do node: Este farol pode ter 4 resultados específicos, são eles:

1. Not configured/Não configurado – O node ainda não foi configurado ou não possui dado conectado a ele;
2. Configured/Configurado – O node está devidamente configurado e aguardando a execução;
3. Executed/Executado – O node foi processado com sucesso e pode ter seus resultados visualizados na parte inferior da tela (o node monitor);
4. Error/Erro – O node foi executado mas algo deu errado.

Há 3 situações em que o Status de um node pode mudar, ao configurar, executar ou resetar um node. Todas essas ações podem ser encontradas:

• Quando você passa o mouse sobre um nó, uma barra de ações aparece, oferecendo as seguintes opções “Configure”, “Execute”, “Cancel” (para nodes em execução) e “Reset”.

• Ao clicar com o botão direito em um node, você pode selecionar as opções no “menu de contexto”:

• Com os atalhos do teclado:
  • Tecla “delete”: excluir o node
  • Tecla F6: Configurar o node (também disponível com um duplo clique do mouse)
  • Tecla F8: Resetar o node
  • Tecla F9: Cancelar e interromper (quando em processamento) a execução de um node
  • Tecla F7: Executar o node
  • Tecla F2: Editar o comentário do node

Como configurar um node

Para configurar um node, basta ajustar as configurações na sua caixa de diálogo de configuração.

Você pode abrir a caixa de diálogo de configuração de um node de várias formas:

• Dando um duplo clique sobre o node
• Clicando no botão Configurar na barra de ações do node
• Clicando com o botão direito no node e selecionando Configurar no menu de contexto
• Selecionando o node e pressionando F6

Como executar um node
Alguns nodes já chegam com o status “configurado” quando são criados. Esses nodes podem ser executados sem a necessidade de ajustes nas configurações padrão.

Para executar o node, você tem as seguintes opções:

• Clicar no botão Executar na barra de ações do node
• Clicar com o botão direito no node e selecionar Executar
• Selecionar o node e pressionar F7

Se a execução for bem-sucedida, o status do node passa para “executado”, o que é representado pelo farol verde. Caso a execução falhe o farol vai mostrar o status de erro, e as configurações e entradas do node precisarão ser ajustadas conforme necessário.

Cancelar a execução de um node
Para cancelar a execução de um node, clique no botão Cancelar na barra de ações do node, clique com o botão direito no node e selecione Cancelar, ou selecione o node e pressione F9.

Como Resetar um node
Para resetar um node, clique no botão Resetar na barra de ações do node, clique com o botão direito no node e selecione Resetar, ou selecione o node e pressione F8.

Resetar um node também resetará todos os nodes na sequência do workflow. O status do node(s) voltará de “executado” para “configurado”, e as saídas do node serão zeradas.

Como funcionam as portas dos nodes no KNIME Analytics Platform
Cada node pode ter várias portas de entrada e saída. Quando conectamos vários nodes em sequência, utilizando as portas de entrada à esquerda e as portas de saída à direita, formamos o workflow. As portas de entrada dos nodes à esquerda consomem os dados das saídas dos nodes à direita, ou seja, as portas de saída fornecem dados aos nodes que vêm em seguida.

Além de tabelas de dados, as portas de entrada e saída podem fornecer outros tipos de entradas e saídas. Para cada tipo, o par de portas de entrada e saída será diferente.

Uma porta de saída só pode ser conectada a uma porta de entrada do mesmo tipo — dados para dados, modelo para modelo, e assim por diante.

Algumas portas de entrada podem ser vazias, como a porta de entrada de dados do Árvore de Decisão. Isso significa que a entrada é opcional, e o node pode ser executado mesmo sem ela. Já as entradas obrigatórias, indicadas por portas de entrada preenchidas, precisam ser fornecidas para que o node possa ser executado.

Como adicionar nodes ao Workflow
Existem 3 formas de adicionar nodes ao workflow:

• Arraste e solte um node do repositório de nodes
• Dê um duplo clique sobre um node dentro do repositório de nodes
• Use o painel de adição rápida de nodes. Clique duas vezes no canvas ou arraste e solte uma porta de node (entrada ou saída) no canvas para abrir o painel de adição rápida de nodes. Esse painel contém até 12 nodes recomendados, ou você pode buscar no painel pelo node desejado e, em seguida, clicar sobre ele para adicioná-lo ao canvas.

Como usar o painel de adição rápida de nodes

Para utilizar a adição rápida de nodes, você precisa permitir que o KNIME colete os dados anônimos de uso. Isso pode ser feito ao iniciar o KNIME Analytics Platform ou após mudar de workspace, selecionando Sim na caixa de diálogo “Ajude a melhorar o KNIME”.

Como substituir nodes em um workflow
Os nodes podem ser movidos no editor de workflow arrastando-os. Para copiar nodes entre workflows, selecione os nodes desejados, clique com o botão direito na seleção e escolha Copiar no menu. No workflow de destino, clique com o botão direito no editor de workflow e selecione Colar no menu.

Para selecionar um node no editor de workflow, basta clicar sobre ele uma vez, e ele será cercado por uma borda. Para selecionar múltiplos nodes, desenhe um retângulo sobre os nodes com o mouse ou segure a tecla Ctrl enquanto clica nos nodes desejados.

Comentários e anotações
Dentro do seu Workflow você tem duas opções para documentação:

• Comentário do node — Adicione um comentário a um node individual dando um duplo clique no campo de texto abaixo do node (Add a comment) e editando o texto.

• Anotação do workflow (Workflow Annotation)— Adicione um comentário geral ao workflow clicando com o botão direito no editor de workflow e selecionando “New workflow annotation”. Um campo de texto aparecerá no editor de workflow.

Para adicionar uma nova anotação, você também pode mudar para o modo de anotação clicando no ícone 16 no canto superior direito da interface do usuário e selecionando Modo de Anotação, ou pressionando T para entrar no modo de anotação.

Como formatar o texto das anotações

Clique duas vezes na anotação do workflow para adicionar texto e formatá-lo. Você pode mudar a cor do contorno da anotação e usar a barra de formatação ou aplicar a seguinte sintaxe:

• Para criar um título, adicione sinais de número (#) seguidos de um espaço, antes de uma palavra ou frase. O número de sinais de número corresponde ao nível de título (<h1> a <h6>).
• Para criar uma lista com marcadores, adicione um asterisco (*) seguido de um espaço.
• Para criar uma lista numerada, adicione um número seguido de um ponto (1.), seguido de um espaço.
• Para deixar o texto em negrito, itálico ou sublinhado, selecione o texto e pressione CTRL+b, CTRL+i, CTRL+u.

Dicas e Hacks gerais

• Adicione nós (nodes) arrastando da Node Repository para o canvas.
• Conecte nodes clicando e arrastando da porta de saída de um node até a porta de entrada de outro.
• Alguns nodes possuem portas dinâmicas (+) nas laterais que você pode adicionar clicando e escolhendo o tipo.
• Para inserir um node entre dois já conectados, basta arrastá-lo para o meio da conexão.
• Pesquise nodes pelo campo de busca no topo da Node Repository.
• Clique ou passe o mouse sobre um node para acessar a descrição, funções e portas disponíveis.
• Use o painel lateral para ver detalhes da configuração do node.
• Adicione ou edite a descrição do workflow clicando no ícone de caneta no painel lateral.
• Utilize o Assistente AI para te ajudar a criar workflows ou tirar dúvidas (Acesso via KNIME Hub – é necessário login). Ela pode ser usada em dois modos:
  • Q&A Mode: Faça perguntas sobre KNIME e receba respostas detalhadas.
  • Build Mode: Expande seu workflow automaticamente com base em um prompt
• Resetar um node apaga os dados processados, mas mantém a configuração.
• Reduza o tamanho dos seus arquivos: antes de salvar, resete o workflow se o dado puder ser acessado novamente.

Esses foram os primeiros passos para entender como funciona o KNIME Analytics Platform, a proposta da ferramenta é ser acessível para quem busca otimizar a análise e o tratamento de dados sem a necessidade de saber programar. Sua interface intuitiva e visual facilita o entendimento das etapas de um projeto, desde a extração até a geração de insights. Ao dominar os conceitos de workflows, nodes e suas funcionalidades, você vai conseguir explorar melhor a plataforma e criar soluções para diversos cenários.

Nos próximos conteúdos, vamos mergulhar ainda mais nas possibilidades que o KNIME oferece.

Conheça um pouco mais do KNIME na prática assistindo a nossa Live que rolou dia 11 de Março:

Por hoje é isso, não se esqueça de acompanhar nossos conteúdos para ficar por dentro das novidades sobre o KNIME Analytics Platform.

Até a próxima pessoal!