DEV Community: BIX

Tutorial: IA Generativa nativa nas suas tabelas SQL com Snowflake Cortex

BIX — Fri, 21 Aug 2026 18:52:10 +0000

Até pouco tempo atrás, se você quisesse fazer análise de sentimento em 1 milhão de reviews de clientes, precisava extrair os dados do Data Warehouse, passar por um script Python, bater na API da OpenAI e devolver o resultado pro banco.

Isso é lento, caro e um pesadelo de segurança. Com o Snowflake Cortex, a IA foi trazida para o banco. Você roda modelos fundacionais (Llama 3, Mistral) usando funções SQL simples, direto na tabela.
Neste hands-on, vou mostrar 3 funções prontas para uso no seu ambiente Snowflake.

1. SNOWFLAKE.CORTEX.SENTIMENT (Análise Direta)

Sem precisar de prompt. Você joga a string de texto e ele devolve um score de -1 (negativo) a 1 (positivo).

SQL

SELECT 
    id_review,
    texto_review,
    SNOWFLAKE.CORTEX.SENTIMENT(texto_review) as score_sentimento
FROM raw_reviews
WHERE data_review = CURRENT_DATE();

2. SNOWFLAKE.CORTEX.TRANSLATE (Tradução em Batch)

Ideal para normalizar logs de sistemas globais ou tickets de suporte de diferentes idiomas para o inglês, direto na pipeline dbt.

SQL

SELECT 
    id_ticket,
    SNOWFLAKE.CORTEX.TRANSLATE(descricao_chamado, 'pt', 'en') as descricao_ingles
FROM suporte_latam;

3. SNOWFLAKE.CORTEX.COMPLETE (Inferência Customizada)

Aqui é onde a mágica do LLM acontece. Você escolhe o modelo e passa o prompt para criar categorias, resumos ou extrair JSON.

SQL

SELECT 
    nome_produto,
    SNOWFLAKE.CORTEX.COMPLETE(
        'llama3-8b', -- Escolhendo o modelo
        CONCAT('Crie uma descrição de marketing de 2 linhas para o produto: ', nome_produto)
    ) as descricao_marketing
FROM dim_produtos;

Você não precisou gerenciar chaves de API, não precisou lidar com timeout de rede e seus dados sensíveis nunca saíram do perímetro governado do seu Data Warehouse.

Como reduzir sua fatura do BigQuery em 80%: Particionamento, Clustering e BI Engine

BIX — Fri, 21 Aug 2026 18:46:29 +0000

Se você usa o Google BigQuery no seu dia a dia, sabe que a precificação baseada em bytes escaneados pode ser uma armadilha. Uma query malfeita com SELECT * numa tabela de 10TB pode custar dezenas de dólares em uma única execução.

Neste tutorial prático, vou te mostrar como paramos de queimar dinheiro implementando três estratégias:
Particionamento, Clustering e BI Engine. O ganho financeiro aqui é imediato.

O Problema (O Antes)

Temos uma tabela transacional (vendas_brutas) com 5 anos de histórico. Um analista precisa somar a receita do último mês.

SQL

-- Custo estimado: 500 GB escaneados (aprox. US$ 2.50 por execução)
SELECT SUM(valor) 
FROM dataset.vendas_brutas 
WHERE data_compra >= '2026-07-01';

1. Particionamento (Cortando o mal pela raiz)

O particionamento divide a tabela física em pedaços menores baseados em uma coluna (geralmente data). Quando você filtra pela data particionada, o BigQuery simplesmente ignora as outras partições.

SQL

-- Recriando a tabela com particionamento
CREATE OR REPLACE TABLE dataset.vendas_particionadas
PARTITION BY DATE(data_compra) AS
SELECT * FROM dataset.vendas_brutas;

-- Nova Query: Custo estimado de 8 GB escaneados (aprox. US$ 0.04)
SELECT SUM(valor) 
FROM dataset.vendas_particionadas 
WHERE DATE(data_compra) >= '2026-07-01';

2. Clustering (A sintonia fina)

Se você já particionou por data, mas os usuários frequentemente filtram por id_cliente ou regiao, o Clustering organiza fisicamente os dados dentro de cada partição para acelerar esses filtros.

SQL

CREATE OR REPLACE TABLE dataset.vendas_otimizadas
PARTITION BY DATE(data_compra)
CLUSTER BY regiao, id_cliente AS
SELECT * FROM dataset.vendas_brutas;

3. BI Engine (Para Dashboards)

Se o seu problema não é volume de dados, mas sim a concorrência (ex: 50 diretores atualizando o Looker Studio ao mesmo tempo), o BI Engine aloca os dados quentes na memória RAM do BigQuery. As queries caem de 2 segundos para milissegundos, e as leituras no BI Engine não cobram pelos bytes escaneados da tabela original.

Aplicar apenas o Particionamento reduziu a fatura dessa pipeline específica em quase 80% na nossa infraestrutura. Custo em cloud é código.

Tutorial Profundo: Rastreabilidade Total no Apache Airflow com OpenLineage

BIX — Fri, 21 Aug 2026 18:36:47 +0000

No ecossistema atual de Engenharia de Dados, a observabilidade (Data Observability) é o que separa pipelines maduros de sistemas que operam na base da esperança. Saber que uma DAG falhou no Apache Airflow é o básico; o desafio real de governança é saber instantaneamente quais tabelas no Data Warehouse, quais modelos de ML e quais dashboards de diretoria foram impactados por essa falha.

Para resolver isso sem precisar escrever logs customizados em cada task, o padrão de mercado atual é o OpenLineage: um framework open-source de observabilidade de dados. Neste tutorial prático, vamos instrumentar o Apache Airflow para emitir eventos de linhagem automaticamente para o Marquez (o servidor backend de referência do OpenLineage).

Entendendo a Arquitetura

O OpenLineage não "lê" o seu banco de dados. Em vez disso, o Airflow atua como um emissor. Sempre que uma task começa ou termina, os Extractors nativos do Airflow analisam o código SQL executado, identificam as tabelas de origem e destino (Inputs e Outputs) e disparam um evento JSON padronizado para o servidor do Marquez.

Passo 1: Subindo a infraestrutura completa (Docker-Compose)

Vamos subir um ambiente local contendo o Marquez (API e UI) e o Airflow configurado via variáveis de ambiente.

`version: '3.8'
services:
# O servidor backend que coleta e desenha a linhagem
marquez:
image: marquezproject/marquez:latest
ports:
- "5000:5000" # API do OpenLineage
- "5001:5001" # Interface Web

# Instância do Airflow configurada para apontar para o Marquez
airflow:
image: apache/airflow:2.8.0
environment:
- AIRFLOW_CORELOAD_EXAMPLES=False
- OPENLINEAGE_URL=http://marquez:5000
- OPENLINEAGE_NAMESPACE=meu_pipeline_producao
- AIRFLOWOPENLINEAGE_DISABLED=False
ports:
- "8080:8080"
command: standalone
`

Passo 2: Instalando o Provider no Airflow

O suporte ao OpenLineage é nativo nas versões modernas do Airflow, mas você precisa garantir que o provider está instalado no seu ambiente:

pip install apache-airflow-providers-openlineage

Passo 3: Criando uma DAG Rastreável

A mágica do OpenLineage é que ele requer zero alterações na lógica de negócios da sua DAG. Veja este exemplo simulando um ETL simples no PostgreSQL: Validando o Resultado

Assim que a DAG for executada com sucesso, abra o seu navegador em http://localhost:5001 (Marquez UI). Você não verá apenas logs de execução, mas um grafo visual (DAG de dados, não de tarefas) mostrando que o dataset stg_vendas.transacoes_brutas é upstream do dataset dm_vendas.faturamento_diario. Se a tabela de staging dropar, você sabe exatamente qual métrica de faturamento vai quebrar amanhã de manhã.

Implementar o OpenLineage é um quick win massivo para a engenharia: poucas linhas de configuração de infraestrutura geram um mapa de dependências que salva horas de troubleshooting no futuro.

Versão completa disponível no link.

`from airflow import DAG
from airflow.providers.postgres.operators.postgres import PostgresOperator
from datetime import datetime

default_args = {
'owner': 'data_engineering_team',
'start_date': datetime(2026, 8, 1),
}

with DAG(
'processamento_vendas_diarias',
default_args=default_args,
schedule_interval='@daily',
catchup=False
) as dag:

# O OpenLineage Extractor vai ler este SQL, dar parse no "INSERT INTO" e no "SELECT FROM",
# e criar a linhagem automaticamente relacionando as duas tabelas.
transform_data = PostgresOperator(
    task_id='transform_sales',
    postgres_conn_id='postgres_default',
    sql="""
    INSERT INTO dm_vendas.faturamento_diario 
    SELECT 
        data_venda, 
        SUM(valor) as receita_total 
    FROM stg_vendas.transacoes_brutas 
    WHERE status = 'pago'
    GROUP BY data_venda;
    """
)