DPF

Como conectar suas ferramentas de analytics aos dados gerenciados pelo DPF.

Visão Geral

Nesta Página

O DPF armazena seus dados transformados como tabelas Apache Iceberg e os expõe por meio de um endpoint padrão de Iceberg REST Catalog. Como o Iceberg é um formato de tabela aberto com uma API de catálogo padronizada, você pode consultar seus dados com qualquer engine compatível — sem movê-los, copiá-los ou configurar conectores proprietários. A plataforma é API-first em toda a sua extensão, então o mesmo acesso a dados e catálogo usado aqui também é o que alimenta nosso servidor MCP para agentes de IA.

Este guia aborda como conectar engines de analytics na AWS, Azure, GCP, Databricks e Snowflake às suas tabelas usando federação de catálogo, atalhos e integrações nativas de catálogo. Uma vez configurado, suas tabelas ficam detectáveis e consultáveis por meio de interfaces SQL familiares em cada ecossistema.

Para tudo que fala JDBC ou ODBC — ferramentas de BI, IDEs SQL como DBeaver, ORMs e aplicações de banco de dados existentes — o DPF também fornece um gateway de protocolo PostgreSQL em gateway.dpf-it.com:5432. Os clientes se conectam com o driver PostgreSQL padrão (sem necessidade de driver personalizado), e seu próprio banco PostgreSQL pode montar o DPF como um servidor vinculado via postgres_fdw. Veja PostgreSQL Gateway abaixo.

Acesso Somente Leitura via Federação

A federação de catálogo e os atalhos atualmente suportam operações somente leitura (SELECT, time travel). Operações de escrita (INSERT, UPDATE, DELETE) ainda não são suportadas por meio do acesso federado. Para modificar dados, use a API do DPF, o PostgreSQL Gateway (que suporta leituras e escritas) ou conecte-se diretamente via REST Catalog com um engine aberto (Spark, Trino, PyIceberg).

Cada caminho abaixo começa em suas ferramentas de analytics e termina em suas tabelas Iceberg — o que muda por plataforma é a peça no meio: AWS, Azure, BigQuery do GCP, Databricks e Snowflake conectam-se com o driver nativo do próprio fornecedor por meio de um salto de federação/atalho; Acesso SQL Direto usa o driver PostgreSQL genérico e não modificado; e Engines Abertos conectam-se diretamente ao REST catalog com as bibliotecas de cliente do próprio ecossistema Iceberg de código aberto. Escolha uma aba para ver.

Suas Ferramentas de Analytics Ferramentas de BI · IDEs SQL · ORMs · aplicativos · postgres_fdw

↓

DPF PostgreSQL Gatewaydriver PostgreSQL genérico JDBC/ODBC/libpqLeitura + Escrita

Spark · Trino · PyIcebergcliente REST catalog Iceberg de código aberto, diretoLeitura + Escrita

AthenaConsole AWS ou driver Athena JDBC/ODBC nativo

Redshiftdriver Redshift JDBC/ODBC nativo ou Query Editor

↓

↓

Glue Data Catalog
Somente leitura

SQL Server 2022 / Azure SQL MIdriver MSOLEDBSQL/ODBC nativo, servidor vinculado

Synapse Serverless SQLengine T-SQL nativo

↓

↓

Atalho Fabric OneLake
Somente leitura

BigQueryconsole/cliente BigQuery nativo

↓

BigQuery Omni
Somente leitura

Databricks SQL / Notebookcliente Databricks SQL nativo ou sessão Spark

↓

Catálogo Estrangeiro Unity Catalog
Somente leitura

Snowsight / SnowSQLdriver Snowflake JDBC/ODBC nativo ou cliente

↓

Integração de Catálogo
Somente leitura

↓

Endpoint DPF Iceberg REST Catalog Especificação Apache Iceberg REST

↓

Suas Tabelas Iceberg (Gerenciadas pelo DPF)

Conexões (Ingestão)

Conectando uma Conta AWS (S3)

Uma conexão do DPF é como o DPF autentica em uma fonte externa para puxar dados em um agendamento (um trigger). Esta é a direção oposta da seção "Consultar com AWS" abaixo — aquela é para consultar as tabelas do DPF a partir da sua conta AWS; esta é para o DPF puxar arquivos para dentro do DPF de um bucket S3 que você possui.

O DPF nunca solicita ou armazena credenciais AWS de longa duração (access keys). Em vez disso, ele usa o padrão AWS para acesso SaaS de terceiros: você cria uma IAM role na sua própria conta que confia em uma role DPF estável e dedicada, protegida por um ExternalId exclusivo que o DPF gera para sua conexão. O DPF então chama sts:AssumeRole sob demanda para obter credenciais de curta duração — você pode revogar o acesso a qualquer momento excluindo ou editando a role, sem precisar entrar em contato com o DPF.

Pré-requisitos

• Um workspace DPF ativo com acesso total
• Um bucket S3 (na sua própria conta AWS) contendo os arquivos que você deseja que o DPF puxe
• Permissões IAM para criar uma role na sua conta AWS

Configuração Passo a Passo

1. Crie a conexão Chame create-connection com type: "aws_s3" e o ARN da role que você pretende criar (ela não precisa existir ainda). O DPF gera um externalId e retorna uma trust policy pronta para uso.

   curl -X POST https://api.dpf-it.com/connections \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "create-connection",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "type": "aws_s3",
       "roleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/dpf-ingestion"
     }'
   # Response includes:
   # {
   #   "success": true,
   #   "data": {
   #     "connectionId": "...",
   #     "externalId": "3f9c2e1a-5b6d-4c7e-8f9a-0b1c2d3e4f5a",
   #     "dpfPrincipalArn": "arn:aws:iam::442707444240:role/dpf-aws-connector",
   #     "trustPolicy": { ... },
   #     "message": "..."
   #   }
   # }
   

2. Crie a IAM role na sua conta Use o trustPolicy retornado exatamente como a trust policy da role. Observe onde os dois valores do Passo 1 se encaixam: dpfPrincipalArn é o Principal da trust policy (esta é a role de conector estável do DPF — a mesma para todos os clientes do DPF), e o externalId da sua conexão vai no bloco Condition como sts:ExternalId. Essa condição é o que impede que a conexão de qualquer outro cliente do DPF assuma sua role — sem ela, qualquer pessoa que soubesse o ARN principal (que não é um segredo) poderia tentar assumi-la.

   aws iam create-role \
     --role-name dpf-ingestion \
     --assume-role-policy-document '{
       "Version": "2012-10-17",
       "Statement": [{
         "Effect": "Allow",
         "Principal": {"AWS": "arn:aws:iam::442707444240:role/dpf-aws-connector"},
         "Action": "sts:AssumeRole",
         "Condition": {"StringEquals": {"sts:ExternalId": "3f9c2e1a-5b6d-4c7e-8f9a-0b1c2d3e4f5a"}}
       }]
     }'
   

3. Anexe uma policy de permissões com escopo reduzido A trust policy acima apenas controla quem pode assumir a role — ela não concede nenhum acesso S3 por si só. Anexe uma policy de permissões separada que conceda apenas o que o DPF realmente precisa: escopo Resource para o bucket específico (e prefixo, se você estiver alimentando apenas uma subpasta) em vez de "arn:aws:s3:::*", e conceda apenas as ações que seu trigger usa. Somente leitura é mostrado abaixo; adicione s3:DeleteObject se suas regras de pós-processamento excluírem arquivos, ou s3:PutObject / s3:DeleteObject juntos se elas arquivarem (copiar + excluir) arquivos.

   aws iam put-role-policy \
     --role-name dpf-ingestion \
     --policy-name dpf-s3-read \
     --policy-document '{
       "Version": "2012-10-17",
       "Statement": [{
         "Effect": "Allow",
         "Action": ["s3:GetObject", "s3:ListBucket"],
         "Resource": [
           "arn:aws:s3:::YOUR_BUCKET",
           "arn:aws:s3:::YOUR_BUCKET/*"
         ]
       }]
     }'
   # Narrower still: scope Resource to a prefix instead of the whole bucket,
   # e.g. "arn:aws:s3:::YOUR_BUCKET/exports/daily/*", if DPF only needs one
   # subfolder — pair with a ListBucket s3:prefix condition to also keep the
   # bucket-level listing scoped to that same prefix.
   

4. Teste a conexão O DPF assume sua role e confirma que funciona antes que a conexão possa ser usada em um trigger.

   curl -X POST https://api.dpf-it.com/connections \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "test-connection",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "connectionId": "YOUR_CONNECTION_ID"
     }'
   

5. Crie um trigger para puxar em um agendamento Depois que a conexão passar no teste, crie um trigger contra ela com o bucket (e prefixo opcional) para consultar. A spec referenciada já deve ter sido analisada uma vez.

   curl -X POST https://api.dpf-it.com/job-triggers \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "create-trigger",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "type": "aws_s3",
       "specName": "web-logs",
       "connectionId": "YOUR_CONNECTION_ID",
       "s3Bucket": "YOUR_BUCKET",
       "s3Prefix": "exports/daily/",
       "frequency": {"unit": "daily", "hourOfDay": 6},
       "dedupe": true
     }'
   

Revogando Acesso

Como o DPF não mantém nenhuma credencial permanente, você pode cortar o acesso a qualquer momento pela sua própria conta AWS — exclua a IAM role, remova sua trust statement ou revogue a policy de permissões. A próxima execução agendada falhará e o DPF marcará automaticamente a conexão como não testada, bloqueando o uso até que ela passe em test-connection novamente.

Conectando via SFTP

Para uma conexão SFTP, o DPF gera um par de chaves RSA-4096 quando a conexão é criada. A chave pública é retornada para que você a instale no seu próprio servidor SFTP; a chave privada é retida pelo DPF e nunca é retornada por nenhuma chamada de API.

Pré-requisitos

• Um workspace DPF ativo com acesso total
• Um servidor SFTP que você controla, com uma conta de usuário pela qual o DPF se conectará
• Capacidade de editar o arquivo ~/.ssh/authorized_keys desse usuário no servidor

Configuração Passo a Passo

1. Crie a conexão Chame create-connection com type: "sftp", o hostname do servidor e o nome de usuário pelo qual o DPF deve se conectar (padrão sftpuser se omitido). O DPF gera o par de chaves e retorna a chave pública.

   curl -X POST https://api.dpf-it.com/connections \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "create-connection",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "type": "sftp",
       "hostname": "sftp.example.com",
       "username": "sftpuser"
     }'
   # Response includes:
   # {
   #   "success": true,
   #   "data": {
   #     "connectionId": "...",
   #     "publicKey": "ssh-rsa AAAAB3NzaC1yc2EAAA... dpf-446655440000",
   #     "message": "..."
   #   }
   # }
   

2. Se o usuário da conexão ainda não existir, crie-o Pule esta etapa se username for uma conta SFTP existente no servidor — ela já tem um diretório .ssh. Um diretório .ssh com permissão de escrita para o grupo ou para todos é comumente rejeitado pelo SSH, então as permissões importam aqui.

   sudo useradd -m sftpuser
   sudo -iu sftpuser
   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   

3. Instale a chave pública no seu servidor SFTP Como o username da conexão no servidor (ou um administrador agindo em nome desse usuário), acrescente a linha publicKey retornada exatamente como está ao arquivo authorized_keys desse usuário. Um arquivo authorized_keys com permissão de escrita para o grupo ou para todos também é comumente rejeitado.

   # As an administrator, become the connection's user (sftpuser here):
   sudo -iu sftpuser
   echo 'ssh-rsa AAAAB3NzaC1yc2EAAA... dpf-446655440000' >> ~/.ssh/authorized_keys
   chmod 600 ~/.ssh/authorized_keys
   

4. Teste a conexão O DPF se conecta com a chave privada que reteve e lista o diretório home do usuário. Um diretório vazio ainda conta como aprovação — esta etapa está apenas verificando se a autenticação funciona.

   curl -X POST https://api.dpf-it.com/connections \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "test-connection",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "connectionId": "YOUR_CONNECTION_ID"
     }'
   

5. Crie um trigger para puxar em um agendamento Depois que a conexão passar no teste, crie um trigger contra ela. A spec referenciada já deve ter sido analisada uma vez.

   curl -X POST https://api.dpf-it.com/job-triggers \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "action": "create-trigger",
       "workspaceId": "YOUR_WORKSPACE_ID",
       "type": "sftp",
       "specName": "web-logs",
       "connectionId": "YOUR_CONNECTION_ID",
       "frequency": {"unit": "daily", "hourOfDay": 6},
       "dedupe": true,
       "preRules": "Process only *.csv files under /outbound",
       "postRules": "Rename each processed file with a .done suffix"
     }'
   

Revogando Acesso

Remova a linha correspondente do arquivo authorized_keys desse usuário a qualquer momento para cortar o acesso — sem necessidade de contatar o DPF. A próxima execução agendada falhará na autenticação e o DPF marcará automaticamente a conexão como não testada, bloqueando o uso até que ela passe em test-connection novamente (o que requer a reinstalação da chave).

Acesso SQL Direto

PostgreSQL Gateway (JDBC / ODBC)

O DPF opera um gateway de protocolo PostgreSQL em gateway.dpf-it.com:5432. Para qualquer cliente, ele parece um servidor Postgres, então você se conecta com o driver PostgreSQL JDBC ou ODBC oficial e não modificado — não há driver DPF personalizado para instalar. Este é o caminho de integração para ferramentas de BI, IDEs SQL (DBeaver, DataGrip), psql, ORMs e para montar o DPF como um servidor vinculado dentro de uma aplicação de banco de dados existente.

Cada instrução SQL que você executa é encaminhada ao engine de consulta do DPF e executada diretamente contra suas tabelas Iceberg. Ao contrário dos caminhos de federação somente leitura acima, o gateway suporta leituras e escritas (SELECT, INSERT, UPDATE, DELETE), com a mesma autorização por usuário e medição de créditos da API do DPF.

Configurações de Conexão

Campo	Valor
Host	gateway.dpf-it.com
Porta	5432
Banco de Dados	Seu namespace do workspace (últimos 12 caracteres do seu workspaceId, ex.: 633def9656c1)
Schema	Sempre default
Nome de Usuário	Seu e-mail de conta do DPF
Senha	Sua senha de conta do DPF
SSL / TLS	Obrigatório (sslmode=require)

URL JDBC:

jdbc:postgresql://gateway.dpf-it.com:5432/<namespace>?sslmode=require

psql (ou qualquer outra coisa construída sobre libpq):

psql "host=gateway.dpf-it.com port=5432 dbname=<namespace> user=<email> sslmode=require"

Alternando Workspaces

Reconecte-se com um nome de banco de dados diferente ou execute USE <namespace>; em uma sessão aberta. Apenas namespaces para os quais sua conta está autorizada são permitidos.

Conectar é Gratuito

O handshake do driver, comandos SET e sondagens de catálogo/introspecção são respondidos pelo próprio gateway e nunca são medidos. Apenas o SQL real que você executa contra suas tabelas consome créditos de consulta — as mesmas tarifas da API do DPF.

Commit por Instrução — Sem Transações

O gateway opera em modo auto-commit. BEGIN / COMMIT / ROLLBACK são aceitos, mas são no-ops: cada instrução é confirmada de forma independente e não há rollback entre instruções. Se um lote de múltiplas instruções falhar no meio, o erro informa qual instrução (baseada em 1) falhou; as instruções anteriores já foram confirmadas e cabe a você desfazê-las.

Tratamento de Credenciais

A autenticação usa seu e-mail e senha do DPF, o que significa que a senha é armazenada nas configurações de conexão salvas da sua ferramenta. O TLS (sslmode=require, imposto pelo gateway) a protege apenas em trânsito — trate os arquivos de conexão salvos de acordo.

Limitações Atuais

Recurso	Status	Notas
SELECT / INSERT / UPDATE / DELETE	✅	Encaminhado ao engine de consulta; commit por instrução
Lotes de múltiplas instruções	✅	Executados da esquerda para a direita, cada instrução confirma de forma independente
Protocolo de consulta simples e estendido	✅	Tanto consultas simples quanto instruções preparadas no servidor (protocolo estendido) são totalmente suportadas
Navegação de schema (árvore de catálogo GUI, SQLTables/SQLColumns ODBC)	✅	Tabelas e colunas são servidas de um pg_catalog emulado com base em seus metadados de tabela ao vivo
Transações / rollback	❌	Apenas auto-commit (veja o destaque acima)
Tabelas temporárias, COPY, stored procedures, LISTEN/NOTIFY, cursores	❌	Rejeitados com SQLSTATE 0A000 (recurso não suportado)

Conectando DBeaver e Ferramentas de BI

Qualquer ferramenta com um conector PostgreSQL funciona com o gateway. O DBeaver é mostrado passo a passo abaixo; DataGrip, Tableau e ferramentas baseadas em ODBC seguem o mesmo padrão com as configurações de conexão da seção anterior.

Configuração do DBeaver

1. Crie uma nova conexão PostgreSQL Banco de Dados → Nova Conexão de Banco de Dados → PostgreSQL. O DBeaver oferecerá o download automático do driver JDBC oficial do PostgreSQL — aceite (qualquer versão recente funciona).
2. Preencha a aba Principal

   Campo	Valor
   Host	gateway.dpf-it.com
   Porta	5432
   Banco de Dados	Seu namespace (ex.: 633def9656c1)
   Usuário	O e-mail da sua conta DPF
   Senha	A senha da sua conta DPF

3. Exigir SSL Na aba SSL, marque Usar SSL e defina o modo SSL como exigir.
4. Teste e conecte Clique em Testar Conexão e depois em Concluir. Abra um editor SQL (Editor SQL → Novo Script SQL) e consulte suas tabelas diretamente:

   SELECT * FROM customers LIMIT 100;
   SELECT dpf_filename, COUNT(*) AS row_count
   FROM customers
   GROUP BY dpf_filename
   ORDER BY row_count DESC;
   

Navegação de Esquema Funciona

O gateway emula as consultas pg_catalog e information_schema que as ferramentas de GUI emitem, então o navegador de banco de dados do DBeaver mostra suas tabelas e colunas com seus tipos. Os metadados são fornecidos a partir da visão em cache do gateway do seu workspace (atualizada a cada poucos minutos) e nunca são cobrados como consulta. Chaves, índices e restrições aparecem vazios — tabelas Iceberg não os possuem.

Outras Ferramentas

• DataGrip / IDEs JetBrains: crie uma fonte de dados PostgreSQL com os mesmos valores e defina SSL como exigir. Nenhuma substituição de propriedade do driver é necessária.
• Tableau / Power BI / outras ferramentas de BI: use o conector genérico PostgreSQL com o mesmo host, porta, banco de dados e credenciais, com SSL exigido. A navegação de esquema e o SQL personalizado funcionam.
• ODBC (psqlODBC): use o driver ODBC Unicode PostgreSQL padrão com SSLmode=require:

  Driver={PostgreSQL Unicode};Server=gateway.dpf-it.com;Port=5432;Database=<namespace>;Uid=<email>;Pwd=<password>;SSLmode=require;
  

  O SQL de passagem e as funções de catálogo ODBC (SQLTables, SQLColumns) funcionam — aplicativos de navegação de esquema veem suas tabelas e colunas. Mantenha UseDeclareFetch no padrão de 0 (cursores do lado do servidor não são suportados).

Servidor Vinculado a partir do PostgreSQL (postgres_fdw)

Como o gateway fala o protocolo de fio do Postgres, seu próprio banco de dados PostgreSQL pode montar o DPF como um servidor estrangeiro usando a extensão integrada postgres_fdw — o equivalente Postgres de um servidor vinculado do SQL Server. Suas tabelas DPF aparecem então como tabelas estrangeiras dentro do seu banco de dados existente, consultáveis e uníveis com seus dados locais em SQL puro.

┌─────────────────────┐ │ Your PostgreSQL │ │ (existing app DB) │ └──────────┬──────────┘ │ postgres_fdw (foreign server) ▼ ┌─────────────────────────────┐ │ DPF PostgreSQL Gateway │ │ gateway.dpf-it.com:5432 │ └──────────────┬──────────────┘ │ DPF Query API ▼ ┌─────────────────────────────┐ │ Your Iceberg Tables │ └─────────────────────────────┘

Configuração

1. Habilite a extensão postgres_fdw acompanha o PostgreSQL — nenhuma instalação de terceiros é necessária.

   CREATE EXTENSION IF NOT EXISTS postgres_fdw;
   

2. Crie o servidor estrangeiro O dbname é o namespace do seu workspace (últimos 12 caracteres do seu workspaceId).

   CREATE SERVER dpf FOREIGN DATA WRAPPER postgres_fdw
       OPTIONS (host 'gateway.dpf-it.com', port '5432', dbname '633def9656c1');
   

3. Mapeie seu usuário local para sua conta DPF

   CREATE USER MAPPING FOR CURRENT_USER SERVER dpf
       OPTIONS (user 'you@example.com', password 'your-dpf-password');
   

4. Defina tabelas estrangeiras Declare as colunas para corresponder à sua tabela DPF (o esquema no lado DPF é sempre default). Você pode ver as colunas de cada tabela na interface do workspace DPF.

   CREATE FOREIGN TABLE customers (
       customer_id   text,
       name          text,
       email         text,
       dpf_filename  text,
       dpf_job       text,
       dpf_ts        timestamp
   ) SERVER dpf
     OPTIONS (schema_name 'default', table_name 'customers');
   

5. Consulte dados DPF de dentro do seu banco de dados

   -- Read DPF data like any local table
   SELECT * FROM customers WHERE dpf_ts >= '2026-06-01' LIMIT 100;
   -- Join DPF data with your application's local tables
   SELECT
       c.customer_id,
       c.name,
       o.order_id,
       o.order_total
   FROM customers c              -- foreign table (DPF)
   JOIN app.orders o             -- local table
     ON o.customer_id = c.customer_id
   WHERE o.order_total > 1000;
   

Gravação Através do Link

Tabelas estrangeiras são graváveis. Instruções INSERT e UPDATE/DELETE totalmente empurradas para baixo (“modificação direta”) são encaminhadas para o mecanismo DPF e confirmadas por instrução:

-- Insert into a DPF table from local data
INSERT INTO customers (customer_id, name, email)
SELECT id, full_name, email FROM app.new_signups;

-- Direct-modify update (whole predicate pushed down)
UPDATE customers SET email = lower(email) WHERE email <> lower(email);

-- Direct-modify delete
DELETE FROM customers WHERE dpf_filename = 'bad_batch.csv';

Mantenha Predicados de Gravação Empurráveis

UPDATE e DELETE funcionam apenas quando o PostgreSQL pode empurrar toda a instrução para o DPF (“modificação direta”): sem junções com tabelas locais na instrução de modificação e predicados usando operadores/funções comuns. Instruções que recorrem ao modo linha por linha do postgres_fdw (que depende de ctid do Postgres) são rejeitadas — tabelas Iceberg não têm ctid. As gravações são confirmadas por instrução: um grande INSERT ... SELECT se divide em lotes que cada um confirma independentemente, então uma falha no meio do lote deixa as linhas anteriores confirmadas.

Compatibilidade de Pushdown

postgres_fdw envia filtros, junções e agregações para o lado remoto quando os considera seguros. O mecanismo DPF é altamente compatível com Postgres, mas não idêntico, então uma função empurrada que ele não suporta aparecerá como erro de consulta. Mantenha os predicados de tabela estrangeira em operadores e funções comuns; se uma expressão específica der erro remotamente, reescreva-a ou aplique-a localmente sobre as linhas buscadas.

Em Breve: IMPORT FOREIGN SCHEMA

Hoje, as tabelas estrangeiras são declaradas manualmente com CREATE FOREIGN TABLE. O suporte para IMPORT FOREIGN SCHEMA "default" FROM SERVER dpf INTO ... — que gera automaticamente todas as definições de tabela a partir do catálogo DPF — está no roadmap.

Consultando com AWS

Configurando a Integração com o Glue Data Catalog

O AWS Glue Data Catalog suporta federação de catálogo para catálogos REST Iceberg remotos. Esse recurso conecta o Glue ao endpoint do catálogo DPF, sincronizando metadados no momento da consulta para que os mecanismos de análise da AWS possam descobrir suas tabelas sem qualquer movimentação de dados.

Uma vez configurado, Athena e Redshift veem suas tabelas DPF como se fossem tabelas Glue nativas — com o Lake Formation fornecendo controle de acesso refinado por cima.

Pré-requisitos

• Um workspace DPF ativo com pelo menos um trabalho de carregamento de dados concluído
• A URL do endpoint do seu catálogo REST DPF: https://api.dpf-it.com/iceberg/v1
• Credenciais de cliente OAuth2 para autenticação do catálogo (veja o Passo 1 abaixo para gerar)
• Conta AWS com permissões IAM para Glue, Lake Formation, Athena e Secrets Manager
• Uma função IAM com acesso de leitura ao local S3 onde o DPF armazena seus arquivos de dados

Configuração Única

Os passos a seguir só precisam ser executados uma vez por workspace. Após a conexão do Glue ser configurada, Athena e Redshift autenticarão automaticamente usando as credenciais armazenadas sempre que você executar uma consulta — nenhuma configuração adicional é necessária.

Obrigatório: Concluir a Configuração Entre Contas com o DPF

Os dados das suas tabelas são armazenados na conta AWS do DPF. Com a federação de catálogo do Glue, Athena e Redshift leem esses arquivos de dados diretamente do Amazon S3 usando as credenciais da sua própria conta AWS — o que significa que sua conta deve receber acesso entre contas ao armazenamento do seu workspace antes que consultas federadas possam retornar dados. A federação de metadados funciona assim que você concluir os passos abaixo, mas as leituras de arquivos de dados falharão com erro de acesso negado até que essa autorização esteja em vigor. Após criar sua função IAM no Passo 3.1 (Criar função IAM para federação do Glue), entre em contato conosco com seu ID da conta AWS, ID do workspace, seu client ID e o ARN da função IAM que você criou no Passo 3.1. Nossa equipe autorizará essa função para seu workspace específico. Este é um passo único por workspace.

Conectando diretamente com um mecanismo aberto (Spark, Trino, PyIceberg) em vez disso? Nenhuma solicitação entre contas é necessária — o catálogo REST fornece credenciais de armazenamento de curta duração e escopo limitado a esses clientes automaticamente.

Configuração Passo a Passo

1. Gere uma credencial de API a partir da API DPF Crie uma credencial de cliente OAuth2 para sua conta (Configurações → Credenciais de API na interface do DPF, ou a chamada de API abaixo). É uma credencial de nível de conta — a mesma funciona em todos os workspaces aos quais você tem acesso, não apenas neste. Esta é uma operação única — salve o clientSecret imediatamente, pois não pode ser recuperado novamente.

   # Generate an API credential (one-time)
   curl -X POST https://api.dpf-it.com/oauth/clients \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "client_name": "Glue Data Catalog Federation"
     }'
   # Response contains clientId and clientSecret (save immediately!)
   # {
   #   "success": true,
   #   "data": {
   #     "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
   #     "clientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...",
   #     "clientName": "Glue Data Catalog Federation"
   #   }
   # }
   

2. Armazene suas credenciais OAuth2 no Secrets Manager Armazene o segredo do cliente do Passo 1 no AWS Secrets Manager usando o nome da chave USER_MANAGED_CLIENT_APPLICATION_CLIENT_SECRET. O Glue usa esse nome de chave para recuperar o segredo durante a autenticação OAuth2.

   aws secretsmanager create-secret \
     --name "dpf/api-credentials" \
     --secret-string '{"USER_MANAGED_CLIENT_APPLICATION_CLIENT_SECRET":"YOUR_CLIENT_SECRET"}' \
     --region us-east-1
   

3. Crie um catálogo federado no Glue Primeiro, crie uma função IAM que o Glue possa assumir para acessar o Secrets Manager e seus dados Iceberg. Em seguida, crie a conexão e o catálogo federado.

   # 1. Create IAM role for Glue federation
   aws iam create-role \
     --role-name DPFGlueFederationRole \
     --assume-role-policy-document '{
       "Version": "2012-10-17",
       "Statement": [{
         "Effect": "Allow",
         "Principal": {"Service": "glue.amazonaws.com"},
         "Action": "sts:AssumeRole"
       }]
     }'
   # 2. Attach policy granting access to Secrets Manager and S3 data files
   aws iam put-role-policy \
     --role-name DPFGlueFederationRole \
     --policy-name dpf-federation-access \
     --policy-document '{
       "Version": "2012-10-17",
       "Statement": [
         {
           "Effect": "Allow",
           "Action": [
             "secretsmanager:GetSecretValue",
             "secretsmanager:DescribeSecret",
             "secretsmanager:PutSecretValue"
           ],
           "Resource": ["arn:aws:secretsmanager:us-east-1:ACCOUNT:secret:dpf/api-credentials*"]
         },
         {
           "Effect": "Allow",
           "Action": ["s3:GetObject", "s3:ListBucket"],
           "Resource": [
             "arn:aws:s3:::dpf-storage",
             "arn:aws:s3:::dpf-storage/*"
           ]
         },
         {
           "Effect": "Allow",
           "Action": ["glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables"],
           "Resource": ["*"]
         }
       ]
     }'
   # 3. Create the Glue connection (wait ~10s for IAM propagation)
   aws glue create-connection \
     --connection-input '{
       "Name": "dpf-catalog-connection",
       "ConnectionType": "ICEBERGRESTCATALOG",
       "ConnectionProperties": {
         "INSTANCE_URL": "https://api.dpf-it.com/iceberg/v1",
         "ROLE_ARN": "arn:aws:iam::ACCOUNT:role/DPFGlueFederationRole"
       },
       "AuthenticationConfiguration": {
         "AuthenticationType": "OAUTH2",
         "OAuth2Properties": {
           "OAuth2GrantType": "CLIENT_CREDENTIALS",
           "TokenUrl": "https://api.dpf-it.com/oauth/token",
           "OAuth2ClientApplication": {
             "UserManagedClientApplicationClientId": "YOUR_CLIENT_ID"
           }
         },
         "SecretArn": "arn:aws:secretsmanager:us-east-1:ACCOUNT:secret:dpf/api-credentials"
       }
     }' \
     --region us-east-1
   # 4. Create the federated catalog
   aws glue create-catalog \
     --name "dpf-data" \
     --catalog-input '{
       "FederatedCatalog": {
         "ConnectionName": "dpf-catalog-connection",
         "Identifier": "dpf"
       },
       "CreateDatabaseDefaultPermissions": [],
       "CreateTableDefaultPermissions": []
     }' \
     --region us-east-1
   

4. Conceda permissões do Lake Formation Conceda à sua função IAM de análise acesso ao catálogo federado para que Athena e Redshift possam consultá-lo.

   aws lakeformation grant-permissions \
     --principal '{"DataLakePrincipalIdentifier":"arn:aws:iam::ACCOUNT:role/YourAnalyticsRole"}' \
     --resource '{"Catalog":{"Id":"dpf-data"}}' \
     --permissions "ALL" \
     --region us-east-1
   

5. Verifique a descoberta de tabelas Liste os bancos de dados (namespaces) visíveis através do catálogo federado. Cada workspace DPF aparece como um banco de dados separado.

   aws glue get-databases \
     --catalog-id "dpf-data" \
     --region us-east-1
   

Mapeamento de Namespace

O DPF usa seu workspaceId como o namespace Iceberg. As tabelas de cada workspace aparecem como um banco de dados separado no catálogo federado, fornecendo isolamento multi-tenant natural.

Metadados em Tempo Real

A federação de catálogo busca metadados do Catálogo REST DPF no momento da consulta. Quando novos dados são carregados via DPF, suas tabelas ficam imediatamente visíveis sem nenhuma etapa de sincronização ou atualização.

Consultando com Amazon Athena

O Athena fornece acesso SQL serverless, pago por consulta, às suas tabelas DPF através do catálogo federado. Não há infraestrutura para provisionar — você paga apenas pelos bytes escaneados.

Somente Leitura via Federação

Ao consultar através de um catálogo federado, o Athena suporta apenas operações de leitura (SELECT, time travel). INSERT, UPDATE, DELETE e MERGE não são suportados em tabelas federadas.

Configuração

1. Abra o console do Athena Navegue até o editor de consultas do Athena. Certifique-se de ter um workgroup configurado com um local de resultados S3 para a saída da consulta.
2. Selecione o catálogo federado No editor de consultas, use o seletor de catálogo/banco de dados para escolher dpf-data e o banco de dados do seu workspace. Alternativamente, use a nomenclatura de três partes no seu SQL.
3. Execute sua primeira consulta Referencie o catálogo federado, o namespace do workspace e o nome da tabela:

   SELECT *
   FROM "dpf-data".<workspace_namespace>.<table_name>
   LIMIT 100;
   

Operações Suportadas

Operação	Suportado	Observações
SELECT	✅	SQL completo com junções, agregações, funções de janela
Time Travel	✅	Consulte snapshots históricos por timestamp
Tabelas de Metadados	✅	Consulte $snapshots, $files, $partitions
INSERT INTO	❌	Não suportado em catálogos federados
UPDATE	❌	Não suportado em catálogos federados
DELETE	❌	Não suportado em catálogos federados
MERGE INTO	❌	Não suportado em catálogos federados

Exemplos

Consulta básica com campos de auditoria DPF:

SELECT
    customer_id,
    name,
    email,
    dpf_filename,
    dpf_job,
    dpf_ts
FROM "dpf-data".my_workspace.customers
LIMIT 100;

Consulta de time travel — veja os dados como existiam em um ponto específico no tempo:

SELECT *
FROM "dpf-data".my_workspace.customers
FOR TIMESTAMP AS OF TIMESTAMP '2026-06-10 12:00:00';

Agregação por arquivo de origem:

SELECT
    dpf_filename,
    COUNT(*) AS row_count,
    MIN(dpf_ts) AS earliest_load,
    MAX(dpf_ts) AS latest_load
FROM "dpf-data".my_workspace.customers
GROUP BY dpf_filename
ORDER BY row_count DESC;

Consulte o histórico de snapshots:

SELECT *
FROM "dpf-data".my_workspace."customers$snapshots"
ORDER BY committed_at DESC;

Modelo de Custo

• US$ 5 por TB escaneado — cobrado apenas pelos dados lidos pela sua consulta
• US$ 0 quando ocioso — sem cobranças quando não estiver consultando
• Use projeções de coluna (selecione apenas as colunas necessárias) para minimizar os dados escaneados
• Tabelas particionadas podam automaticamente arquivos de dados desnecessários

Consultando com Amazon Redshift

O Amazon Redshift Serverless fornece um mecanismo de análise SQL gerenciado que pode consultar suas tabelas DPF através do catálogo federado. O Redshift é ideal para cargas de trabalho analíticas sustentadas, integração com ferramentas de BI e cenários que exigem junções complexas entre várias tabelas.

Somente Leitura via Federação

Como o Athena, o acesso do Redshift através de um catálogo federado é atualmente somente leitura. Operações de gravação não são suportadas em tabelas federadas.

Configuração

1. Crie um workgroup do Redshift Serverless Se você ainda não tiver um, crie um workgroup e um namespace no console do Redshift. Certifique-se de que a função IAM associada tenha permissões do Lake Formation no catálogo federado dpf-data.
2. Consulte usando a notação de três partes Referencie o catálogo federado diretamente no seu SQL:

   SELECT *
   FROM "dpf-data".<workspace_namespace>.<table_name>
   LIMIT 100;
   

3. Alternativamente, crie um esquema externo Para uma notação de duas partes mais simples, crie um esquema externo apontando para o banco de dados federado:

   CREATE EXTERNAL SCHEMA dpf_workspace
   FROM DATA CATALOG
   DATABASE '<workspace_namespace>'
   CATALOG_ID 'dpf-data'
   IAM_ROLE 'arn:aws:iam::ACCOUNT:role/RedshiftLakeFormationRole';
   

   Em seguida, consulte com a notação de duas partes:

   SELECT * FROM dpf_workspace.customers LIMIT 100;
   

Operações Suportadas

Operação	Suportado	Observações
SELECT	✅	SQL completo com otimizações do Redshift
Joins entre tabelas	✅	Junte tabelas DPF entre si ou com tabelas Redshift
Visões Materializadas	✅	Armazene em cache consultas frequentes para acesso mais rápido
Funções de Janela	✅	Suporte completo a funções analíticas
INSERT / UPDATE / DELETE	❌	Não suportado em tabelas federadas
MERGE	❌	Não suportado em tabelas federadas

Exemplos

Agregação por job de carga:

SELECT
    dpf_job,
    COUNT(*) AS total_rows,
    COUNT(DISTINCT dpf_filename) AS file_count,
    MIN(dpf_ts) AS job_start,
    MAX(dpf_ts) AS job_end
FROM "dpf-data".my_workspace.customers
GROUP BY dpf_job
ORDER BY job_start DESC;

Join entre tabelas DPF:

SELECT
    c.customer_id,
    c.name,
    a.account_id,
    a.balance
FROM "dpf-data".my_workspace.customers c
JOIN "dpf-data".my_workspace.accounts a
  ON c.customer_id = a.customer_id
WHERE a.balance > 10000;

Criar uma visão materializada para consultas frequentes:

CREATE MATERIALIZED VIEW mv_customer_summary AS
SELECT
    dpf_job,
    COUNT(*) AS total_rows,
    COUNT(DISTINCT dpf_filename) AS file_count
FROM "dpf-data".my_workspace.customers
GROUP BY dpf_job;

Athena vs. Redshift — Quando Usar Cada Um

Consideração	Athena	Redshift Serverless
Modelo de preço	Por consulta ($5/TB escaneado)	Por RPU-hora (~$0,375/RPU-h)
Custo ocioso	$0	Quase $0 (reduz a zero, ~30s de inicialização a frio)
Melhor para	Consultas ad-hoc, exploração de dados	Cargas de trabalho contínuas, dashboards, ferramentas de BI
Complexidade de configuração	Zero infraestrutura	Workgroup + namespace + função IAM
Recursos avançados	Time travel, consultas de metadados	Visões materializadas, joins entre bancos de dados
Suporte a escrita	❌ (via federação)	❌ (via federação)

Recomendação

Para a maioria dos usuários DPF que fazem inspeção de dados, validação e análise ad-hoc, Athena é a opção mais simples e econômica. Escolha Redshift Serverless quando precisar de consultas simultâneas sustentadas, visões materializadas ou integração com ferramentas de BI como QuickSight, Tableau ou Looker.

Precisa de Acesso de Escrita?

Para operações INSERT, UPDATE e DELETE, conecte-se através do PostgreSQL Gateway (JDBC/ODBC padrão, leitura + escrita), ou conecte-se diretamente ao DPF Iceberg REST Catalog usando um mecanismo aberto como Apache Spark, Trino ou PyIceberg.

Consulta com Azure

Configurando Atalhos do Microsoft Fabric

O Microsoft Fabric conecta-se a catálogos Iceberg externos através de Atalhos do OneLake. Um atalho cria uma referência virtualizada para suas tabelas, permitindo que cargas de trabalho do Fabric (SQL Analytics Endpoint, Lakehouse, Notebooks) consultem seus dados como se estivessem armazenados localmente no OneLake — sem copiar ou mover nada.

Uma vez configurado um atalho, suas tabelas aparecem como tabelas nativas do Fabric e podem ser consultadas com T-SQL a partir do SQL Server, Synapse ou qualquer ferramenta conectada ao Fabric SQL Analytics Endpoint.

Pré-requisitos

• Um workspace DPF ativo com pelo menos um job de carga de dados concluído
• A URL do endpoint do seu REST Catalog DPF: https://api.dpf-it.com/iceberg/v1
• Uma credencial de API OAuth2 para sua conta DPF (gere via POST /oauth/clients)
• Um workspace do Microsoft Fabric com pelo menos acesso de Contribuidor
• Um Lakehouse do Fabric criado dentro do workspace

Configuração Passo a Passo

1. Gere uma credencial de API a partir da API DPF Se você ainda não criou uma credencial de API para sua conta DPF, gere uma agora (Configurações → Credenciais de API na interface do DPF, ou a chamada de API abaixo). Ela é de nível de conta — a mesma credencial usada para a integração com AWS funciona aqui também.

   curl -X POST https://api.dpf-it.com/oauth/clients \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "client_name": "Microsoft Fabric Shortcut"
     }'
   

2. Abra seu Lakehouse do Fabric Navegue até seu workspace do Microsoft Fabric e abra o Lakehouse onde deseja expor suas tabelas. Selecione a seção Tabelas no painel do Explorer.
3. Crie um atalho de tabela Iceberg Clique em Novo atalho → selecione Apache Iceberg como tipo de origem. Preencha os detalhes da conexão:

   Campo	Valor
   URL do Catálogo	https://api.dpf-it.com/iceberg/v1
   Autenticação	OAuth2 Client Credentials
   Endpoint de token	https://api.dpf-it.com/oauth/token
   Client ID	Seu client ID DPF do Passo 1
   Client Secret	Seu client secret DPF do Passo 1
   Namespace	O namespace do seu workspace (últimos 12 caracteres do seu workspaceId, ex.: 633def9656c1)

4. Selecione as tabelas para o atalho Após conectar, o Fabric exibe as tabelas disponíveis no seu namespace. Selecione as tabelas que deseja expor (ex.: customers, accounts) e clique em Criar.
5. Verifique no Lakehouse Explorer Suas tabelas agora aparecem na seção Tabelas do Lakehouse com um ícone de atalho. Elas podem ser consultadas imediatamente via SQL Analytics Endpoint.

Mapeamento de Namespace

O namespace Iceberg é derivado do seu workspaceId — especificamente os últimos 12 caracteres. Por exemplo, se seu workspaceId é a9d4d243-d856-4558-84ba-633def9656c1, o namespace é 633def9656c1. Você pode encontrar esse valor nas configurações do seu workspace ou na resposta da API get-status do DPF.

Atualização Automática de Metadados

Os atalhos do Fabric buscam metadados Iceberg no momento da consulta. Quando novos dados são carregados via DPF, suas tabelas de atalho refletem o estado mais recente automaticamente — sem necessidade de atualização manual.

Acesso Somente Leitura

Atalhos Iceberg no Microsoft Fabric são somente leitura. Você pode consultar, agregar e unir os dados, mas INSERT, UPDATE e DELETE não são suportados através de atalhos. Para modificar dados, use a API DPF ou conecte-se diretamente via REST Catalog.

Consulta com SQL Server

O SQL Server 2022 e o Azure SQL Managed Instance podem consultar suas tabelas através de servidores vinculados apontando para um Fabric SQL Analytics Endpoint ou um pool Synapse Serverless SQL. Isso permite acesso T-SQL aos seus dados Iceberg a partir de seus bancos de dados SQL Server existentes.

Arquitetura

O SQL Server não se conecta diretamente a catálogos Iceberg. Em vez disso, ele consulta através de um intermediário que suporta nativamente Iceberg — seja o Fabric SQL Analytics Endpoint ou um pool Synapse Serverless SQL — usando uma conexão de servidor vinculado.

┌────────────────────┐ │ SQL Server 2022 │ │ (ou Azure SQL MI)│ └─────────┬──────────┘ │ Servidor Vinculado (ODBC / MSOLEDBSQL) ▼ ┌─────────────────────────────┐ │ Fabric SQL Analytics │ │ Endpoint │ │ ─── OU ─── │ │ Synapse Serverless SQL │ └──────────────┬──────────────┘ │ Atalho Iceberg / OPENROWSET ▼ ┌─────────────────────────────┐ │ Suas Tabelas (via atalho) │ └─────────────────────────────┘

Opção A: Via Fabric SQL Analytics Endpoint

Depois de criar atalhos Iceberg em um Lakehouse do Fabric, o SQL Analytics Endpoint do Lakehouse os expõe como tabelas consultáveis via T-SQL.

1. Obtenha a string de conexão do SQL Analytics Endpoint No seu Lakehouse do Fabric, clique em SQL Analytics Endpoint na barra superior. Copie o nome do servidor (ex.: xxxxxxxx.datawarehouse.fabric.microsoft.com).
2. Crie um servidor vinculado no SQL Server

   -- Create linked server to Fabric SQL Analytics Endpoint
   EXEC sp_addlinkedserver
       @server = N'DPF_FABRIC',
       @srvproduct = N'',
       @provider = N'MSOLEDBSQL',
       @datasrc = N'your-endpoint.datawarehouse.fabric.microsoft.com',
       @catalog = N'your_lakehouse';
   -- Configure authentication (Azure AD / Entra ID)
   EXEC sp_addlinkedsrvlogin
       @rmtsrvname = N'DPF_FABRIC',
       @useself = N'FALSE',
       @rmtuser = N'your-azure-ad-user@domain.com',
       @rmtpassword = N'your-password-or-token';
   

3. Consulte suas tabelas através do servidor vinculado

   -- Four-part naming: LinkedServer.Database.Schema.Table
   SELECT *
   FROM DPF_FABRIC.your_lakehouse.dbo.customers
   WHERE dpf_job = '550e8400-e29b-41d4-a716-446655440005';
   -- Aggregation across tables
   SELECT
       dpf_filename,
       COUNT(*) AS row_count,
       MIN(dpf_ts) AS earliest_load,
       MAX(dpf_ts) AS latest_load
   FROM DPF_FABRIC.your_lakehouse.dbo.customers
   GROUP BY dpf_filename;
   

Opção B: Via Synapse Serverless SQL

Alternativamente, crie um servidor vinculado apontando para um pool Synapse Serverless SQL que tenha acesso às suas tabelas.

-- Create linked server to Synapse Serverless SQL
EXEC sp_addlinkedserver
    @server = N'DPF_SYNAPSE',
    @srvproduct = N'',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'your-synapse-workspace-ondemand.sql.azuresynapse.net',
    @catalog = N'dpf_external';

-- Query your tables through Synapse
SELECT
    customer_id,
    name,
    email,
    dpf_filename,
    dpf_job
FROM DPF_SYNAPSE.dpf_external.dpf.customers
WHERE dpf_ts >= '2026-06-01';

Joins Entre Bancos de Dados

Uma vantagem importante da abordagem de servidor vinculado é que você pode unir suas tabelas Iceberg com dados existentes do SQL Server em uma única consulta:

-- Join Iceberg data with local SQL Server tables
SELECT
    c.customer_id,
    c.name,
    c.email,
    o.order_id,
    o.order_total
FROM DPF_FABRIC.your_lakehouse.dbo.customers c
INNER JOIN dbo.orders o
    ON c.customer_id = o.customer_id
WHERE c.dpf_job = '550e8400-e29b-41d4-a716-446655440005'
ORDER BY o.order_total DESC;

Dica de Performance

Ao unir tabelas Iceberg remotas com tabelas locais do SQL Server, filtre o lado remoto o mais agressivamente possível. Predicados em dpf_job, dpf_filename e colunas de partição são empurrados para a camada Iceberg, minimizando a transferência de dados através do link.

Consulta com Azure Synapse Analytics

O pool Synapse Serverless SQL do Azure pode consultar suas tabelas Iceberg via atalhos do Fabric Lakehouse. Isso fornece acesso T-SQL pago por consulta sem provisionar recursos de computação.

Acesso Somente Leitura

O Synapse Serverless SQL suporta operações somente leitura em tabelas Iceberg externas. Operações de escrita devem ser realizadas através da API DPF ou de um mecanismo aberto.

Configuração: Via Atalhos do Fabric Lakehouse

Depois de configurar os atalhos do Fabric, o Synapse pode consultar suas tabelas através do SQL Analytics Endpoint do Lakehouse. O Fabric lida com a autenticação do catálogo e a resolução de metadados automaticamente.

1. Conecte o Synapse ao workspace do Fabric No Synapse Studio, adicione um serviço vinculado apontando para seu Fabric SQL Analytics Endpoint, ou consulte diretamente usando um pool Serverless SQL com acesso entre workspaces.
2. Consulte suas tabelas

   -- Query through Fabric Lakehouse (three-part name)
   SELECT *
   FROM [your_lakehouse].[dbo].[customers]
   LIMIT 100;
   

Operações Suportadas

Operação	Suportado	Observações
SELECT	✅	T-SQL completo com joins, agregações, CTEs
Pushdown de predicados	✅	Filtros enviados ao Iceberg para poda de partições
Joins entre bancos de dados	✅	Junte suas tabelas Iceberg com outros bancos Synapse
Views / Stored Procedures	✅	Encapsule tabelas de atalho em views para abstração
INSERT / UPDATE / DELETE	❌	Não suportado em tabelas Iceberg de atalho

Exemplos

Agregação por arquivo de origem e job:

SELECT
    dpf_job,
    dpf_filename,
    COUNT(*) AS row_count,
    MIN(dpf_ts) AS load_start,
    MAX(dpf_ts) AS load_end
FROM [your_lakehouse].[dbo].[customers]
GROUP BY dpf_job, dpf_filename
ORDER BY load_start DESC;

Consulta de linhagem de dados — rastreie linhas até a origem:

SELECT
    customer_id,
    name,
    dpf_filename AS source_file,
    dpf_line AS source_row_number,
    dpf_job AS load_job_id,
    dpf_ts AS loaded_at
FROM [your_lakehouse].[dbo].[customers]
WHERE customer_id = 'CUST-12345'
ORDER BY dpf_ts DESC;

Join entre fontes — dados Iceberg com tabelas Azure SQL:

-- Join your shortcut table with a local Synapse table
SELECT
    c.customer_id,
    c.name,
    c.email,
    s.subscription_tier,
    s.renewal_date
FROM [your_lakehouse].[dbo].[customers] c
INNER JOIN dbo.subscriptions s
    ON c.customer_id = s.customer_id
WHERE c.dpf_job = '550e8400-e29b-41d4-a716-446655440005';

SQL Server vs. Synapse — Quando Usar Cada Um

Consideração	SQL Server (Servidor Vinculado)	Azure Synapse Serverless
Configuração	Servidor vinculado ao endpoint do Fabric	Atalho do Fabric via Lakehouse
Melhor para	Unir com dados existentes do SQL Server, consultas operacionais	Análises ad-hoc, ferramentas de BI, agregações em larga escala
Preço de consulta	Sem custo adicional (usa licença existente do SQL Server)	~$5/TB processado (pago por consulta)
Performance	Depende da taxa de transferência do servidor vinculado	Mecanismo distribuído, escala com o volume de dados
Materialização	SELECT INTO em tabelas locais	SELECT INTO em tabelas locais
Suporte a escrita	❌ (somente leitura via link)	❌ (somente leitura via atalhos)
Integração com BI	Direta via SSMS, SSRS	Conectores nativos Power BI, Tableau, Looker

Recomendação

Se sua equipe de análise vive no ecossistema Azure, use atalhos do Fabric para a configuração mais simples e a maior compatibilidade de ferramentas (Power BI, Synapse, SQL Server).

Precisa de Acesso de Escrita?

Para operações INSERT, UPDATE e DELETE, conecte-se através do PostgreSQL Gateway (JDBC/ODBC padrão, leitura + escrita), ou conecte-se diretamente ao DPF Iceberg REST Catalog usando um mecanismo aberto como Apache Spark, Trino ou PyIceberg.

Consulta com GCP

Configurando Integração com GCP

O BigQuery acessa suas tabelas através do BigQuery Omni, o conector entre nuvens do Google para dados no AWS. Como os dados das suas tabelas residem no armazenamento S3 do DPF, isso requer uma autorização IAM entre contas única, semelhante à integração com Glue acima.

Pré-requisitos

• Um workspace DPF ativo com pelo menos um job de carga de dados concluído
• A URL do endpoint do seu REST Catalog DPF: https://api.dpf-it.com/iceberg/v1
• Uma conexão BigQuery Omni para AWS (região aws-us-east-1) e uma conta AWS para autorizar o acesso entre contas

Obrigatório: Complete a Configuração Entre Contas com o DPF

O BigQuery Omni lê seus arquivos de dados diretamente do Amazon S3 usando uma função IAM do AWS que você autoriza. Após criar a função IAM no Passo 1 abaixo, entre em contato conosco com seu ID da conta AWS, ID do workspace e o ARN da função IAM. Nossa equipe autorizará essa função para seu workspace específico — uma etapa única por workspace.

Configuração Passo a Passo

1. Crie uma função IAM do AWS para o BigQuery Omni Siga a configuração do BigQuery Omni do Google para criar a função e a política de confiança, depois crie a conexão no BigQuery:

   bq mk --connection --connection_type=AWS \
     --properties='{"accessRole":{"iamRoleId":"arn:aws:iam::ACCOUNT:role/BigQueryOmniAccessRole"}}' \
     --location=aws-us-east-1 \
     dpf-omni-connection
   

2. Crie uma tabela externa BigLake apontando para os metadados Iceberg O BigQuery Omni lê tabelas Iceberg a partir de um ponteiro de metadados em vez de falar com o REST catalog ao vivo, então você fornece o metadata_location atual da tabela (visível na interface do workspace DPF ou via resposta do LoadTable do REST catalog):

   bq mk --table \
     --external_table_definition='@iceberg_def.json' \
     my_dataset.customers
   # iceberg_def.json
   {
     "icebergOptions": {
       "metadataLocation": "s3://dpf-storage/<workspace_namespace>/customers/metadata/00003-xxxx.metadata.json"
     },
     "connectionId": "projects/YOUR_PROJECT/locations/aws-us-east-1/connections/dpf-omni-connection"
   }
   

Atualização Manual de Metadados

Diferente dos caminhos de federação AWS/Azure, uma tabela externa Iceberg do BigQuery Omni fixa um snapshot metadata_location específico. Após novos dados serem carregados na tabela via DPF, execute novamente o comando bq mk --table (ou uma consulta agendada) com o caminho de metadados mais recente para captar novos dados.

Consulta a partir do GCP

Depois que a tabela externa BigLake estiver configurada, consulte-a como qualquer outra tabela do BigQuery:

SELECT
    customer_id,
    name,
    email,
    dpf_filename,
    dpf_job,
    dpf_ts
FROM \`my_project.my_dataset.customers\`
LIMIT 100;

Precisa de Acesso de Escrita a partir do BigQuery? As tabelas externas do BigQuery Omni são somente leitura. Para gravações a partir de uma carga de trabalho hospedada no GCP, conecte-se através do PostgreSQL Gateway, ou conecte-se diretamente ao Catálogo REST Iceberg do DPF usando um mecanismo aberto como Apache Spark, Trino ou PyIceberg.

Consulta com Databricks

Configurando a Integração com o Catálogo Unity do Databricks

O Unity Catalog suporta federação de catálogo Iceberg REST: um objeto de catálogo estrangeiro que aponta para um endpoint Iceberg REST externo. Uma vez configurado, seu workspace DPF aparece dentro do Unity Catalog como um catálogo estrangeiro, consultável a partir de warehouses SQL do Databricks e notebooks — em qualquer nuvem em que seu workspace Databricks esteja rodando.

Pré-requisitos

• Um workspace DPF ativo com pelo menos um job de carga de dados concluído
• A URL do endpoint do seu Catálogo REST DPF: https://api.dpf-it.com/iceberg/v1
• Credenciais de cliente OAuth2 para autenticação do catálogo (veja o Passo 1 abaixo para gerar)
• Um workspace Databricks com Unity Catalog habilitado
• Privilégios CREATE CONNECTION e CREATE CATALOG no metastore

Configuração Passo a Passo

1. Gere uma credencial de API a partir da API DPF Esta é a mesma credencial de nível de conta usada para as outras integrações nesta página (Configurações → Credenciais de API na interface do DPF, ou a chamada de API abaixo).

   curl -X POST https://api.dpf-it.com/oauth/clients \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "client_name": "Databricks Unity Catalog"
     }'
   

2. Crie a conexão Em um editor SQL do Databricks ou notebook, crie uma conexão descrevendo como alcançar o catálogo REST DPF:

   CREATE CONNECTION dpf_rest_connection TYPE ICEBERG_REST
   OPTIONS (
     uri 'https://api.dpf-it.com/iceberg/v1',
     token_refresh_url 'https://api.dpf-it.com/oauth/token',
     client_id 'YOUR_CLIENT_ID',
     client_secret 'YOUR_CLIENT_SECRET'
   );
   

3. Crie o catálogo estrangeiro

   CREATE FOREIGN CATALOG dpf_data
   USING CONNECTION dpf_rest_connection
   OPTIONS (catalog 'dpf');
   

4. Verifique a descoberta de tabelas Cada namespace de workspace DPF aparece como um schema sob o catálogo estrangeiro:

   SHOW SCHEMAS IN dpf_data;
   SHOW TABLES IN dpf_data.<workspace_namespace>;
   

Credenciais Fornecidas — Sem Configuração Entre Contas

O Unity Catalog obtém credenciais S3 de curta duração diretamente do Catálogo REST DPF no momento da consulta, da mesma forma que uma conexão direta Spark ou Trino faz. Diferente da integração com AWS Glue, nenhuma autorização IAM entre contas é necessária, independentemente de em qual nuvem seu workspace Databricks esteja rodando.

Somente Leitura via Federação

Como os outros caminhos de federação neste guia, consultar através do catálogo estrangeiro atualmente suporta operações somente leitura (SELECT, viagem no tempo). Para gravar, use o PostgreSQL Gateway ou conecte-se diretamente com o suporte ao catálogo REST Iceberg do PySpark.

Consultando com Databricks

Uma vez que o catálogo estrangeiro esteja configurado, consulte suas tabelas da mesma forma a partir de um warehouse SQL do Databricks ou de um notebook — ambos compartilham os mesmos metadados do Unity Catalog.

Exemplos

Consulta básica com campos de auditoria DPF:

SELECT
    customer_id,
    name,
    email,
    dpf_filename,
    dpf_job,
    dpf_ts
FROM dpf_data.my_workspace.customers
LIMIT 100;

Consulta de viagem no tempo:

SELECT *
FROM dpf_data.my_workspace.customers
TIMESTAMP AS OF '2026-06-10 12:00:00';

Junte uma tabela DPF (estrangeira) com uma tabela Delta nativa:

SELECT
    c.customer_id,
    c.name,
    o.order_id,
    o.order_total
FROM dpf_data.my_workspace.customers c
JOIN main.sales.orders o
  ON o.customer_id = c.customer_id
WHERE o.order_total > 1000;

Operações Suportadas

Operação	Suportado	Notas
SELECT	✅	SQL completo com junções, agregações, funções de janela
Viagem no tempo	✅	Consultar snapshots históricos por timestamp
Junções entre catálogos	✅	Junte tabelas DPF com Delta ou outras tabelas do Unity Catalog
INSERT / UPDATE / DELETE	❌	Não suportado em catálogos estrangeiros federados
MERGE INTO	❌	Não suportado em catálogos estrangeiros federados

Precisa de Acesso de Gravação?

Para INSERT, UPDATE e DELETE, conecte-se através do PostgreSQL Gateway (JDBC/ODBC padrão, leitura + gravação), ou conecte-se diretamente ao Catálogo REST Iceberg do DPF a partir de um notebook Databricks usando o suporte ao catálogo REST Iceberg do PySpark.

Consultar com Snowflake

Configurando a Integração com o Catálogo do Snowflake

O Snowflake lê tabelas Iceberg externas através de uma integração de catálogo do tipo ICEBERG_REST, emparelhada com um volume externo que descreve como alcançar o armazenamento subjacente. Uma vez configurado, as tabelas do seu workspace DPF podem ser expostas como tabelas Iceberg do Snowflake e consultadas com SQL padrão.

Pré-requisitos

• Um workspace DPF ativo com pelo menos um job de carga de dados concluído
• A URL do endpoint do seu Catálogo REST DPF: https://api.dpf-it.com/iceberg/v1
• Credenciais de cliente OAuth2 para autenticação do catálogo (veja o Passo 1 abaixo para gerar)
• Uma conta Snowflake na edição Enterprise ou superior (necessária para Tabelas Iceberg)
• ACCOUNTADMIN, ou uma função com privilégios CREATE INTEGRATION e CREATE EXTERNAL VOLUME

Configuração Passo a Passo

1. Gere uma credencial de API a partir da API DPF Nível de conta — Configurações → Credenciais de API na interface do DPF, ou a chamada de API abaixo.

   curl -X POST https://api.dpf-it.com/oauth/clients \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "client_name": "Snowflake Catalog Integration"
     }'
   

2. Crie a integração de catálogo

   CREATE CATALOG INTEGRATION dpf_catalog_integration
     CATALOG_SOURCE = ICEBERG_REST
     TABLE_FORMAT = ICEBERG
     REST_CONFIG = (
       CATALOG_URI = 'https://api.dpf-it.com/iceberg/v1'
       CATALOG_NAME = 'dpf'
     )
     REST_AUTHENTICATION = (
       TYPE = OAUTH
       OAUTH_TOKEN_URI = 'https://api.dpf-it.com/oauth/token'
       OAUTH_CLIENT_ID = 'YOUR_CLIENT_ID'
       OAUTH_CLIENT_SECRET = 'YOUR_CLIENT_SECRET'
     )
     ENABLED = TRUE;
   

3. Crie um volume externo para credenciais fornecidas Omita STORAGE_AWS_ROLE_ARN para que o Snowflake dependa da integração de catálogo para fornecer credenciais de armazenamento de curta duração por consulta, em vez de uma função IAM estática — nenhuma autorização entre contas é necessária.

   CREATE EXTERNAL VOLUME dpf_ext_volume
     STORAGE_LOCATIONS =
     (
       (
         NAME = 'dpf-vended'
         STORAGE_PROVIDER = 'S3'
         STORAGE_BASE_URL = 's3://dpf-storage/'
       )
     );
   

4. Crie um banco de dados vinculado ao catálogo para seu workspace Isso preenche automaticamente um banco de dados Snowflake a partir do namespace do seu workspace DPF — sem necessidade de declarar cada tabela individualmente.

   CREATE DATABASE dpf_data
     LINKED_CATALOG = (
       CATALOG = 'dpf_catalog_integration',
       CATALOG_NAMESPACE = '<workspace_namespace>'
     )
     EXTERNAL_VOLUME = 'dpf_ext_volume';
   

5. Verifique a descoberta de tabelas

   SHOW ICEBERG TABLES IN DATABASE dpf_data;
   

Mapeamento de Namespace

O DPF usa seu workspaceId como o namespace Iceberg. Defina CATALOG_NAMESPACE para o namespace do seu workspace para escopar o banco de dados vinculado às tabelas desse workspace.

Somente Leitura via Federação

Como os outros caminhos de federação neste guia, tabelas Iceberg apoiadas por uma integração de catálogo REST são atualmente somente leitura no Snowflake. Para gravar, use o PostgreSQL Gateway ou conecte-se diretamente com um mecanismo aberto.

Consultando com Snowflake

Consulte o banco de dados vinculado ao catálogo como qualquer outro banco de dados Snowflake — seu namespace de workspace aparece como um schema, e cada tabela DPF aparece como uma tabela Iceberg do Snowflake.

Exemplos

Consulta básica com campos de auditoria DPF:

SELECT
    customer_id,
    name,
    email,
    dpf_filename,
    dpf_job,
    dpf_ts
FROM dpf_data.my_workspace.customers
LIMIT 100;

Agregação por job de carga:

SELECT
    dpf_job,
    COUNT(*) AS total_rows,
    COUNT(DISTINCT dpf_filename) AS file_count,
    MIN(dpf_ts) AS job_start,
    MAX(dpf_ts) AS job_end
FROM dpf_data.my_workspace.customers
GROUP BY dpf_job
ORDER BY job_start DESC;

Junte uma tabela Iceberg DPF com uma tabela Snowflake nativa:

SELECT
    c.customer_id,
    c.name,
    s.subscription_tier,
    s.renewal_date
FROM dpf_data.my_workspace.customers c
JOIN app_db.public.subscriptions s
  ON s.customer_id = c.customer_id;

Operações Suportadas

Operação	Suportado	Notas
SELECT	✅	SQL completo com junções, agregações, funções de janela
Junções entre bancos de dados	✅	Junte tabelas Iceberg DPF com tabelas Snowflake nativas
Snowpark	✅	Leia tabelas DPF em DataFrames Snowpark como qualquer outra tabela
INSERT / UPDATE / DELETE	❌	Não suportado em tabelas Iceberg apoiadas por catálogo REST

Precisa de Acesso de Gravação?

Para INSERT, UPDATE e DELETE, conecte-se através do PostgreSQL Gateway (JDBC/ODBC padrão, leitura + gravação), ou conecte-se diretamente ao Catálogo REST Iceberg do DPF usando um mecanismo aberto como Apache Spark, Trino ou PyIceberg.

Agentes de IA (MCP)

O DPF publica um servidor Model Context Protocol (MCP) para que agentes de IA possam descobrir a API DPF, integrar novos usuários e executar fluxos de trabalho de integração de dados de ponta a ponta — registrar uma conta, criar um workspace, carregar um arquivo, construir uma especificação de dados e consultar os resultados, tudo através de chamadas de ferramentas em linguagem natural. Há duas maneiras de conectá-lo, e qual usar depende inteiramente do seu cliente.

Um Servidor, Sem Instalação

O DPF executa um único servidor MCP remoto. VS Code, Cursor, Claude Desktop/Claude.ai, Kiro IDE e o Modo Desenvolvedor do ChatGPT suportam login OAuth 2.1 real — aponte-os para a URL abaixo e um popup de login no navegador cuida do resto. Sem npm install, sem Node.js local. Clientes que não suportam esse fluxo de login no navegador (Codex CLI, Kiro CLI) usam uma credencial de API DPF em vez disso.

MCP Remoto (VS Code, Cursor, Claude, ChatGPT)

Aponte seu cliente para https://api.dpf-it.com/mcp sem credenciais configuradas. Na primeira conexão, o cliente abrirá um navegador para uma página de login real do DPF — sua senha é digitada lá, nunca dentro de um chat ou chamada de ferramenta — e, se você ainda não tiver uma conta, o fluxo de inscrição da mesma página cuida do registro e da verificação de e-mail antes de redirecionar de volta. A partir daí, o cliente armazena seu próprio token de acesso + refresh e reconecta silenciosamente; você não será solicitado a fazer login novamente, a menos que revogue o acesso ou um token de refresh em si expire.

VS Code (.vscode/mcp.json, nível de workspace ou usuário):

{
  "mcpServers": {
    "dpf": {
      "url": "https://api.dpf-it.com/mcp"
    }
  }
}

Cursor — mesma forma, nas configurações MCP do Cursor ou em seu próprio mcp.json. Clique em "Adicionar novo servidor MCP global" e cole a URL, ou use um deep link estilo "Adicionar ao Cursor" se você tiver configurado um.

Claude Desktop / Claude.ai — Configurações → Conectores → Adicionar conector personalizado → cole https://api.dpf-it.com/mcp como a URL do servidor MCP remoto. O Claude lida com o Registro Dinâmico de Cliente automaticamente.

ChatGPT (Modo Desenvolvedor) — Configurações → Apps e Conectores → Avançado → habilite o Modo Desenvolvedor, depois adicione um conector personalizado com a mesma URL e escolha OAuth como o tipo de autenticação.

Sem Armazenamento de Senha no Lado do Cliente

O servidor remoto nunca aceita uma senha como argumento de ferramenta. Se um cliente solicitar que você digite sua senha DPF diretamente em uma mensagem de chat em vez de um popup no navegador, isso não é este servidor funcionando como pretendido — pare e verifique a URL do conector.

Clientes Sem Suporte a OAuth (Codex CLI, Kiro CLI)

Codex CLI e Kiro CLI não implementam o fluxo de login OAuth no navegador do MCP que os clientes acima usam, então apontá-los para https://api.dpf-it.com/mcp sem credenciais configuradas não funcionará — não há navegador para eles abrirem. Ambos, no entanto, permitem que você anexe um cabeçalho estático Authorization à configuração de um servidor MCP remoto. As credenciais de API do DPF (as mesmas de nível de conta usadas para federação de catálogo em outras partes deste guia, criadas via Configurações → Credenciais de API ou POST /oauth/clients) são feitas exatamente para isso: um par client_id / client_secret que você troca por um token bearer você mesmo, em vez de um cliente fazê-lo interativamente em seu nome.

Como Isso Difere dos Clientes OAuth Acima

VS Code/Cursor/Claude/ChatGPT fazem login uma vez e depois atualizam silenciosamente para sempre — o cliente gerencia um token de refresh nos bastidores e você nunca mais pensa nisso. O caminho client_credentials aqui não tem token de refresh: cada troca gera um token de acesso válido por 24 horas, e nem Codex CLI nem Kiro CLI sabem como renová-lo para você. Planeje reexecutar a troca (Passo 2 abaixo) aproximadamente diariamente — o trecho no final desta seção automatiza isso.

Configuração Passo a Passo

1. Crie uma credencial de API Configurações → Credenciais de API na interface do DPF, ou via API diretamente:

   curl -X POST https://api.dpf-it.com/oauth/clients \
     -H "Authorization: Bearer YOUR_DPF_JWT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "client_name": "Codex CLI"
     }'
   # Response — save the clientSecret now, it's shown once:
   # { "success": true, "data": { "clientId": "...", "clientSecret": "...", "clientName": "Codex CLI" } }
   

2. Troque-a por um token de acesso Este é o passo que você repetirá sempre que o token expirar:

   export DPF_MCP_TOKEN=$(curl -s -X POST https://api.dpf-it.com/oauth/token \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET" \
     | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
   

3. Aponte seu cliente para o token via um cabeçalho estático Codex CLI (~/.codex/config.toml) — lê o token da variável de ambiente definida no Passo 2, então nunca toca no arquivo de configuração em si:

   [mcp_servers.dpf]
   url = "https://api.dpf-it.com/mcp"
   bearer_token_env_var = "DPF_MCP_TOKEN"
   

   Kiro CLI (config JSON do agente, ex.: .kiro/agents/*.json) — mesma ideia, via substituição de ${VAR} no valor do cabeçalho:

   {
     "mcpServers": {
       "dpf": {
         "url": "https://api.dpf-it.com/mcp",
         "headers": {
           "Authorization": "Bearer ${DPF_MCP_TOKEN}"
         }
       }
     }
   }
   

Reexecutar o Passo 2 antes de cada sessão é suficiente para uso ocasional. Para uso diário, coloque-o no seu perfil de shell para que um novo terminal sempre comece com um token ativo:

# ~/.zshrc or ~/.bashrc
export DPF_CLIENT_ID="..."
export DPF_CLIENT_SECRET="..."
export DPF_MCP_TOKEN=$(curl -s -X POST https://api.dpf-it.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=${DPF_CLIENT_ID}&client_secret=${DPF_CLIENT_SECRET}" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

Uma sessão já em execução com um token expirado começará a receber 401 s do DPF — reinicie-a após atualizar em vez de esperar que ela se recupere sozinha.

Ferramentas Disponíveis

O servidor MCP remoto expõe as seguintes ferramentas uma vez conectado:

Ferramenta	O que faz
list_my_workspaces / create_workspace	Listar ou criar workspaces para a conta autenticada
list_data / get_status / delete_data_spec	Inspecionar e gerenciar especificações de dados e jobs
submit_query	Executar SQL contra as tabelas Iceberg de um workspace
onboard_data_source → finish_data_source_onboarding	Criar uma especificação de dados, enviar um arquivo de amostra e executar inferência de schema por IA
update_data_spec → finish_data_spec_update	Alterar a configuração de uma especificação existente, opcionalmente substituindo seu arquivo de amostra
run_data_job → finish_data_job	Processar novos arquivos através de uma especificação já configurada
manage_connection / manage_trigger / setup_scheduled_pull	Configurar e gerenciar ingestão SFTP agendada
call_dpf_api	Saída de emergência para qualquer ação da API DPF sem uma ferramenta dedicada

Uploads de Arquivos São Dois Passos no Remoto onboard_data_source / update_data_spec / run_data_job retornam uma URL de upload pré-assinada em vez de fazerem o upload do arquivo por conta própria — um servidor remoto não tem acesso ao seu disco local. Se o seu cliente tiver seu próprio acesso a arquivos/shell (ex.: Cursor, VS Code), ele faz o upload do arquivo diretamente; caso contrário, anexe o arquivo no chat quando solicitado e, em seguida, chame a ferramenta finish_* correspondente para continuar.