DPF

Cómo conectar tus herramientas de analítica a los datos gestionados por DPF.

Resumen

En esta página

DPF almacena tus datos transformados como tablas Apache Iceberg y los expone a través de un endpoint estándar de Iceberg REST Catalog. Dado que Iceberg es un formato de tabla abierto con una API de catálogo estandarizada, puedes consultar tus datos con cualquier motor compatible, sin moverlos, copiarlos ni configurar conectores propietarios. La plataforma es API-first en todo momento, por lo que el mismo acceso a datos y catálogo que se usa aquí es también el que impulsa nuestro servidor MCP para agentes de IA.

Esta guía cubre cómo conectar motores de analítica en AWS, Azure, GCP, Databricks y Snowflake a tus tablas mediante federación de catálogos, accesos directos (shortcuts) e integraciones nativas de catálogo. Una vez configurado, tus tablas son detectables y consultables a través de interfaces SQL familiares en cada ecosistema.

Para todo lo que hable con JDBC u ODBC (herramientas de BI, IDEs SQL como DBeaver, ORMs y aplicaciones de base de datos existentes), DPF también proporciona una puerta de enlace con protocolo wire de PostgreSQL en gateway.dpf-it.com:5432. Los clientes se conectan con el driver PostgreSQL estándar (sin necesidad de driver personalizado), y tu propia base de datos PostgreSQL puede montar DPF como servidor vinculado mediante postgres_fdw. Consulta PostgreSQL Gateway más abajo.

Acceso de Solo Lectura mediante Federación

La federación de catálogos y los accesos directos (shortcuts) admiten actualmente operaciones de solo lectura (SELECT, time travel). Las operaciones de escritura (INSERT, UPDATE, DELETE) aún no se admiten a través del acceso federado. Para modificar datos, usa la API de DPF, la PostgreSQL Gateway (que admite lecturas y escrituras), o conéctate directamente mediante el REST Catalog con un motor abierto (Spark, Trino, PyIceberg).

Cada ruta a continuación comienza en tus herramientas de analítica y termina en tus tablas Iceberg. Lo que cambia según la plataforma es la pieza intermedia: AWS, Azure, BigQuery de GCP, Databricks y Snowflake se conectan con el driver nativo propio de cada proveedor a través de un salto de federación/shortcut; Acceso SQL Directo usa el driver PostgreSQL genérico sin modificar; y Motores Abiertos se conectan directamente al catálogo REST con las bibliotecas cliente propias del ecosistema Iceberg de código abierto. Elige una pestaña para verlo.

Tus Herramientas de Analítica Herramientas de BI · IDEs SQL · ORMs · aplicaciones · postgres_fdw

↓

DPF PostgreSQL Gateway driver PostgreSQL genérico JDBC/ODBC/libpq Lectura + Escritura

Spark · Trino · PyIceberg cliente REST de catálogo Iceberg de código abierto, directo Lectura + Escritura

Athena Consola de AWS o driver nativo Athena JDBC/ODBC

Redshift driver nativo Redshift JDBC/ODBC o Query Editor

↓

↓

Glue Data Catalog
Solo lectura

SQL Server 2022 / Azure SQL MI driver nativo MSOLEDBSQL/ODBC, servidor vinculado

Synapse Serverless SQL motor nativo T-SQL

↓

↓

Fabric OneLake Shortcut
Solo lectura

BigQuery consola/cliente nativo de BigQuery

↓

BigQuery Omni
Solo lectura

Databricks SQL / Notebook cliente nativo Databricks SQL o sesión de Spark

↓

Unity Catalog Foreign Catalog
Solo lectura

Snowsight / SnowSQL driver o cliente nativo Snowflake JDBC/ODBC

↓

Catalog Integration
Solo lectura

↓

Endpoint DPF Iceberg REST Catalog Especificación Apache Iceberg REST

↓

Tus Tablas Iceberg (Gestionadas por DPF)

Conexiones (Ingesta)

Conexión de una Cuenta de AWS (S3)

Una conexión de DPF es la forma en que DPF se autentica ante una fuente externa para extraer datos según un programa (un trigger). Esta es la dirección opuesta a la sección "Consultar con AWS" más abajo: esa es para consultar las tablas de DPF desde tu cuenta de AWS; esta es para que DPF extraiga archivos hacia DPF desde un bucket de S3 que te pertenece.

DPF nunca solicita ni almacena credenciales AWS de larga duración (access keys). En su lugar, usa el patrón estándar de AWS para acceso SaaS de terceros: creas un rol de IAM en tu propia cuenta que confía en un rol DPF estable y dedicado, protegido por un ExternalId único que DPF genera para tu conexión. DPF entonces llama a sts:AssumeRole bajo demanda para obtener credenciales de corta duración. Puedes revocar el acceso en cualquier momento eliminando o editando el rol, sin necesidad de contactar con DPF.

Requisitos previos

• Un workspace de DPF activo con acceso completo
• Un bucket de S3 (en tu propia cuenta de AWS) que contenga los archivos que quieres que DPF extraiga
• Permisos de IAM para crear un rol en tu cuenta de AWS

Configuración Paso a Paso

1. Crea la conexión Llama a create-connection con type: "aws_s3" y el ARN del rol que pretendes crear (no es necesario que exista todavía). DPF genera un externalId y devuelve una política de confianza lista para usar.

   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. Crea el rol de IAM en tu cuenta Usa el trustPolicy devuelto tal cual como política de confianza del rol. Observa dónde van los dos valores del Paso 1: dpfPrincipalArn es el Principal de la política de confianza (este es el rol de conector estable de DPF, el mismo para todos los clientes de DPF), y el externalId de tu conexión va en el bloque Condition como sts:ExternalId. Esa condición es lo que impide que la conexión de cualquier otro cliente de DPF asuma tu rol; sin ella, cualquiera que conociera el ARN del principal (que no es un secreto) podría intentar asumirlo.

   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. Adjunta una política de permisos restringida La política de confianza anterior solo controla quién puede asumir el rol; por sí sola no concede ningún acceso a S3. Adjunta una política de permisos separada que conceda solo lo que DPF realmente necesita: limita Resource al bucket específico (y prefijo, si solo estás alimentando una subcarpeta) en lugar de "arn:aws:s3:::*", y concede solo las acciones que usa tu trigger. A continuación se muestra solo lectura; añade s3:DeleteObject si tus reglas de post-procesamiento eliminan archivos, o s3:PutObject / s3:DeleteObject juntos si archivan (copiar + eliminar) archivos.

   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. Prueba la conexión DPF asume tu rol y confirma que funciona antes de que la conexión pueda usarse en un 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. Crea un trigger para extraer según un programa Una vez que la conexión haya superado la prueba, crea un trigger contra ella con el bucket (y prefijo opcional) a sondear. La especificación referenciada ya debe haberse analizado una 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
     }'
   

Revocación del Acceso

Dado que DPF no conserva ninguna credencial permanente, puedes cortar el acceso en cualquier momento desde tu propia cuenta de AWS: elimina el rol de IAM, quita su declaración de confianza o revoca la política de permisos. La siguiente ejecución programada fallará y DPF marcará automáticamente la conexión como no probada, bloqueando su uso hasta que supere test-connection de nuevo.

Conexión mediante SFTP

Para una conexión SFTP, DPF genera un par de claves RSA-4096 cuando se crea la conexión. La clave pública se devuelve para que la instales en tu propio servidor SFTP; la clave privada la conserva DPF y nunca la devuelve ninguna llamada a la API.

Requisitos previos

• Un workspace de DPF activo con acceso completo
• Un servidor SFTP que controles, con una cuenta de usuario con la que DPF se conectará
• Capacidad para editar el archivo ~/.ssh/authorized_keys de ese usuario en el servidor

Configuración Paso a Paso

1. Crea la conexión Llama a create-connection con type: "sftp", el hostname del servidor y el nombre de usuario con el que DPF debe conectarse (por defecto sftpuser si se omite). DPF genera el par de claves y devuelve la clave 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. Si el usuario de la conexión no existe ya, créalo Omite este paso si username es una cuenta SFTP existente en el servidor; ya tiene un directorio .ssh. Un directorio .ssh con escritura mundial o de grupo suele ser rechazado directamente por SSH, así que los permisos importan aquí.

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

3. Instala la clave pública en tu servidor SFTP Como el username de la conexión en el servidor (o un administrador que actúe en nombre de ese usuario), añade la línea publicKey devuelta tal cual al archivo authorized_keys de ese usuario. Un archivo authorized_keys con escritura mundial o de grupo también suele ser rechazado directamente.

   # 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. Prueba la conexión DPF se conecta con la clave privada que conservó y lista el directorio home del usuario. Un directorio vacío sigue contando como aprobado: este paso solo verifica que la autenticación 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. Crea un trigger para extraer según un programa Una vez que la conexión haya superado la prueba, crea un trigger contra ella. La especificación referenciada ya debe haberse analizado una 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"
     }'
   

Revocación del Acceso

Elimina la línea correspondiente del archivo authorized_keys de ese usuario en cualquier momento para cortar el acceso, sin necesidad de contactar con DPF. La siguiente ejecución programada fallará al autenticarse y DPF marcará automáticamente la conexión como no probada, bloqueando su uso hasta que supere test-connection de nuevo (lo que requiere que la clave se reinstale).

Acceso SQL Directo

PostgreSQL Gateway (JDBC / ODBC)

DPF opera una puerta de enlace con protocolo wire de PostgreSQL en gateway.dpf-it.com:5432. Para cualquier cliente parece un servidor Postgres, por lo que te conectas con el driver oficial PostgreSQL JDBC u ODBC sin modificar: no hay ningún driver personalizado de DPF que instalar. Esta es la vía de integración para herramientas de BI, IDEs SQL (DBeaver, DataGrip), psql, ORMs y para montar DPF como servidor vinculado dentro de una aplicación de base de datos existente.

Cada sentencia SQL que ejecutas se reenvía al motor de consultas de DPF y se ejecuta directamente contra tus tablas Iceberg. A diferencia de las vías de federación de solo lectura anteriores, la puerta de enlace admite tanto lecturas como escrituras (SELECT, INSERT, UPDATE, DELETE), con la misma autorización por usuario y medición de créditos que la API de DPF.

Ajustes de Conexión

Campo	Valor
Host	gateway.dpf-it.com
Puerto	5432
Base de datos	Tu namespace del workspace (últimos 12 caracteres de tu workspaceId, p. ej. 633def9656c1)
Esquema	Siempre default
Usuario	El email de tu cuenta de DPF
Contraseña	La contraseña de tu cuenta de DPF
SSL / TLS	Obligatorio (sslmode=require)

URL JDBC:

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

psql (o cualquier otra cosa construida sobre libpq):

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

Cambio de Workspaces

Vuelve a conectarte con un nombre de base de datos diferente o ejecuta USE <namespace>; en una sesión abierta. Solo se permiten los namespaces para los que tu cuenta está autorizada.

Conectarse es Gratis

El intercambio de mensajes del handshake del driver, los comandos SET y las sondas de catálogo/introspección las responde la propia puerta de enlace y nunca se miden. Solo el SQL real que ejecutas contra tus tablas consume créditos de consulta, con las mismas tarifas que la API de DPF.

Confirmación por Sentencia: Sin Transacciones

La puerta de enlace funciona en modo auto-commit. BEGIN / COMMIT / ROLLBACK se aceptan pero son no-ops: cada sentencia se confirma de forma independiente y no hay rollback entre sentencias. Si un lote de varias sentencias falla a mitad de camino, el error indica qué sentencia (basada en 1) falló; las sentencias anteriores ya se han confirmado y debes deshacerlas tú.

Gestión de Credenciales

La autenticación usa tu email y contraseña de DPF, lo que significa que la contraseña se almacena en los ajustes de conexión guardados de tu herramienta. TLS (sslmode=require, impuesto por la puerta de enlace) la protege solo en tránsito: trata los archivos de conexión guardados en consecuencia.

Limitaciones Actuales

Característica	Estado	Notas
SELECT / INSERT / UPDATE / DELETE	✅	Reenviado al motor de consultas; confirmación por sentencia
Lotes de varias sentencias	✅	Ejecutados de izquierda a derecha, cada sentencia se confirma de forma independiente
Protocolo de consulta simple y extendido	✅	Tanto las consultas simples como las sentencias preparadas del lado del servidor (protocolo extendido) son totalmente compatibles
Exploración de esquemas (árbol de catálogo de GUI, SQLTables/SQLColumns de ODBC)	✅	Las tablas y columnas se sirven desde un pg_catalog emulado respaldado por tus metadatos de tabla en vivo
Transacciones / rollback	❌	Solo auto-commit (ver nota anterior)
Tablas temporales, COPY, procedimientos almacenados, LISTEN/NOTIFY, cursores	❌	Rechazados con SQLSTATE 0A000 (característica no compatible)

Conexión de DBeaver y Herramientas de BI

Cualquier herramienta con un conector PostgreSQL funciona con la puerta de enlace. DBeaver se muestra paso a paso a continuación; DataGrip, Tableau y las herramientas basadas en ODBC siguen el mismo patrón con los ajustes de conexión de la sección anterior.

Configuración de DBeaver

1. Crear una nueva conexión PostgreSQL Base de datos → Nueva conexión de base de datos → PostgreSQL. DBeaver ofrecerá descargar automáticamente el controlador JDBC oficial de PostgreSQL — acéptalo (cualquier versión reciente funciona).
2. Completa la pestaña Principal

   Campo	Valor
   Host	gateway.dpf-it.com
   Puerto	5432
   Base de datos	Tu namespace (p. ej. 633def9656c1)
   Usuario	El correo de tu cuenta DPF
   Contraseña	La contraseña de tu cuenta DPF

3. Requerir SSL En la pestaña SSL, marca Usar SSL y configura el modo SSL en require.
4. Probar y conectar Haz clic en Probar conexión y luego en Finalizar. Abre un editor SQL (Editor SQL → Nuevo script SQL) y consulta tus tablas directamente:

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

La exploración de esquemas funciona

La puerta de enlace emula las consultas pg_catalog y information_schema que emiten las herramientas gráficas, por lo que el navegador de bases de datos de DBeaver muestra tus tablas y columnas con sus tipos. Los metadatos se sirven desde la vista en caché de tu espacio de trabajo (actualizada cada pocos minutos) y nunca se facturan como consulta. Las claves, índices y restricciones aparecen vacíos — las tablas Iceberg no los tienen.

Otras herramientas

• DataGrip / IDE de JetBrains: crea una fuente de datos PostgreSQL con los mismos valores y configura SSL en require. No se necesitan anulaciones de propiedades del controlador.
• Tableau / Power BI / otras herramientas de BI: usa el conector genérico PostgreSQL con el mismo host, puerto, base de datos y credenciales, con SSL requerido. Tanto la exploración de esquemas como el SQL personalizado funcionan.
• ODBC (psqlODBC): usa el controlador ODBC Unicode estándar de PostgreSQL con SSLmode=require:

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

  Tanto el SQL de paso directo como las funciones de catálogo ODBC (SQLTables, SQLColumns) funcionan — las aplicaciones de exploración de esquemas ven tus tablas y columnas. Mantén UseDeclareFetch en su valor predeterminado de 0 (no se admiten cursores del lado del servidor).

Servidor vinculado desde PostgreSQL (postgres_fdw)

Debido a que la puerta de enlace habla el protocolo wire de Postgres, tu propia base de datos PostgreSQL puede montar DPF como un servidor externo usando la extensión integrada postgres_fdw — el equivalente de Postgres a un servidor vinculado de SQL Server. Tus tablas DPF aparecen entonces como tablas externas dentro de tu base de datos existente, consultables y combinables con tus datos locales en SQL simple.

┌─────────────────────┐ │ Tu PostgreSQL │ │ (base de datos de app existente) │ └──────────┬──────────┘ │ postgres_fdw (servidor externo) ▼ ┌─────────────────────────────┐ │ Puerta de enlace PostgreSQL DPF │ │ gateway.dpf-it.com:5432 │ └──────────────┬──────────────┘ │ API de consulta DPF ▼ ┌─────────────────────────────┐ │ Tus tablas Iceberg │ └─────────────────────────────┘

Configuración

1. Habilita la extensión postgres_fdw se incluye con PostgreSQL — no se necesita instalación de terceros.

   CREATE EXTENSION IF NOT EXISTS postgres_fdw;
   

2. Crea el servidor externo El dbname es el namespace de tu espacio de trabajo (últimos 12 caracteres de tu workspaceId).

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

3. Asigna tu usuario local a tu cuenta DPF

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

4. Define tablas externas Declara las columnas para que coincidan con tu tabla DPF (el esquema en el lado DPF siempre es default). Puedes ver las columnas de cada tabla en la interfaz del espacio de trabajo 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. Consulta datos DPF desde dentro de tu base de datos

   -- 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;
   

Escritura a través del enlace

Las tablas externas son escribibles. Las sentencias INSERT y las sentencias UPDATE/DELETE completamente enviadas ("modificación directa") se reenvían al motor DPF y se confirman por sentencia:

-- 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';

Mantén los predicados de escritura enviables

UPDATE y DELETE funcionan solo cuando PostgreSQL puede enviar la sentencia completa a DPF ("modificación directa"): sin uniones con tablas locales en la sentencia de modificación, y predicados que usen operadores/funciones comunes. Las sentencias que recurren al modo fila por fila de postgres_fdw (que depende de los ctid de Postgres) se rechazan — las tablas Iceberg no tienen ctid. Las escrituras se confirman por sentencia: un INSERT ... SELECT grande se divide en lotes que se confirman de forma independiente, por lo que una falla a mitad de lote deja las filas anteriores confirmadas.

Compatibilidad de envío

postgres_fdw envía filtros, uniones y agregaciones al lado remoto cuando los considera seguros. El motor DPF es altamente compatible con Postgres pero no idéntico, por lo que una función enviada que no admite aparecerá como un error de consulta. Mantén los predicados de tablas externas en operadores y funciones comunes; si una expresión específica da error de forma remota, reescríbela o aplícala localmente sobre las filas obtenidas.

Próximamente: IMPORT FOREIGN SCHEMA

Hoy las tablas externas se declaran manualmente con CREATE FOREIGN TABLE. El soporte para IMPORT FOREIGN SCHEMA "default" FROM SERVER dpf INTO ... — que genera automáticamente todas las definiciones de tablas desde el catálogo DPF — está en la hoja de ruta.

Consultar con AWS

Configuración de la integración con Glue Data Catalog

AWS Glue Data Catalog admite federación de catálogos para catálogos remotos Iceberg REST. Esta función conecta Glue al endpoint del catálogo DPF, sincronizando metadatos en tiempo de consulta para que los motores de análisis de AWS puedan descubrir tus tablas sin ningún movimiento de datos.

Una vez configurado, Athena y Redshift ven tus tablas DPF como si fueran tablas Glue nativas — con Lake Formation proporcionando control de acceso detallado encima.

Requisitos previos

• Un espacio de trabajo DPF activo con al menos un trabajo de carga de datos completado
• La URL del endpoint de tu catálogo REST DPF: https://api.dpf-it.com/iceberg/v1
• Credenciales de cliente OAuth2 para la autenticación del catálogo (consulta el Paso 1 a continuación para generarlas)
• Cuenta de AWS con permisos IAM para Glue, Lake Formation, Athena y Secrets Manager
• Un rol IAM con acceso de lectura a la ubicación S3 donde DPF almacena tus archivos de datos

Configuración única

Los siguientes pasos solo deben realizarse una vez por espacio de trabajo. Después de configurar la conexión Glue, Athena y Redshift se autenticarán automáticamente usando las credenciales almacenadas cada vez que ejecutes una consulta — no se necesita configuración adicional.

Requisito: completar la configuración entre cuentas con DPF

Los datos de tus tablas se almacenan en la cuenta de AWS de DPF. Con la federación de catálogos de Glue, Athena y Redshift leen esos archivos de datos directamente desde Amazon S3 usando las credenciales de tu propia cuenta de AWS — lo que significa que tu cuenta debe tener acceso entre cuentas otorgado al almacenamiento de tu espacio de trabajo antes de que las consultas federadas puedan devolver datos. La federación de metadatos funciona tan pronto como completes los pasos a continuación, pero las lecturas de archivos de datos fallarán con un error de acceso denegado hasta que esta autorización esté en su lugar. Después de crear tu rol IAM en el Paso 3.1 (Crear rol IAM para la federación de Glue), contáctanos con tu ID de cuenta de AWS, ID de espacio de trabajo, tu ID de cliente y el ARN del rol IAM que creaste en el Paso 3.1. Nuestro equipo autorizará ese rol para tu espacio de trabajo específico. Este es un paso único por espacio de trabajo.

¿Te conectas directamente con un motor abierto (Spark, Trino, PyIceberg)? No se necesita solicitud entre cuentas — el catálogo REST entrega credenciales de almacenamiento limitadas y de corta duración a esos clientes automáticamente.

Configuración paso a paso

1. Genera una credencial de API desde la API DPF Crea una credencial de cliente OAuth2 para tu cuenta (Configuración → Credenciales de API en la interfaz DPF, o la llamada a la API a continuación). Es una credencial a nivel de cuenta — la misma funciona en todos los espacios de trabajo a los que tienes acceso, no solo en este. Esta es una operación única — guarda el clientSecret inmediatamente, ya que no se puede recuperar de nuevo.

   # 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. Almacena tus credenciales OAuth2 en Secrets Manager Almacena el secreto de cliente del Paso 1 en AWS Secrets Manager usando el nombre de clave USER_MANAGED_CLIENT_APPLICATION_CLIENT_SECRET. Glue usa este nombre de clave para recuperar el secreto durante la autenticación 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. Crea un catálogo federado en Glue Primero, crea un rol IAM que Glue pueda asumir para acceder a Secrets Manager y a tus datos Iceberg. Luego crea la conexión y el 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. Otorga permisos de Lake Formation Otorga a tu rol IAM de análisis acceso al catálogo federado para que Athena y Redshift puedan consultarlo.

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

5. Verifica el descubrimiento de tablas Lista las bases de datos (namespaces) visibles a través del catálogo federado. Cada espacio de trabajo DPF aparece como una base de datos separada.

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

Mapeo de namespaces

DPF usa tu workspaceId como el namespace Iceberg. Las tablas de cada espacio de trabajo aparecen como una base de datos separada en el catálogo federado, proporcionando aislamiento multiinquilino natural.

Metadatos en tiempo real

La federación de catálogos obtiene metadatos del catálogo REST DPF en tiempo de consulta. Cuando se cargan nuevos datos a través de DPF, tus tablas son visibles inmediatamente sin pasos de sincronización o actualización.

Consultar con Amazon Athena

Athena proporciona acceso SQL sin servidor y de pago por consulta a tus tablas DPF a través del catálogo federado. No hay infraestructura que aprovisionar — pagas solo por los bytes escaneados.

Solo lectura a través de la federación

Al consultar a través de un catálogo federado, Athena admite solo operaciones de lectura (SELECT, viaje en el tiempo). INSERT, UPDATE, DELETE y MERGE no se admiten en tablas federadas.

Configuración

1. Abre la consola de Athena Navega al editor de consultas de Athena. Asegúrate de tener un grupo de trabajo configurado con una ubicación de resultados S3 para la salida de consultas.
2. Selecciona el catálogo federado En el editor de consultas, usa el selector de catálogo/base de datos para elegir dpf-data y la base de datos de tu espacio de trabajo. Alternativamente, usa nombres de tres partes en tu SQL.
3. Ejecuta tu primera consulta Haz referencia al catálogo federado, al namespace del espacio de trabajo y al nombre de la tabla:

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

Operaciones admitidas

Operación	Admitida	Notas
SELECT	✅	SQL completo con uniones, agregaciones, funciones de ventana
Viaje en el tiempo	✅	Consulta instantáneas históricas por marca de tiempo
Tablas de metadatos	✅	Consulta $snapshots, $files, $partitions
INSERT INTO	❌	No admitida en catálogos federados
UPDATE	❌	No admitida en catálogos federados
DELETE	❌	No admitida en catálogos federados
MERGE INTO	❌	No admitida en catálogos federados

Ejemplos

Consulta básica con campos de auditoría DPF:

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

Consulta de viaje en el tiempo — ve los datos como existían en un punto específico en el tiempo:

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

Agregación por archivo fuente:

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;

Consulta del historial de instantáneas:

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

Modelo de costos

• $5 por TB escaneado — solo se cobra por los datos leídos por tu consulta
• $0 cuando está inactivo — sin cargos cuando no se consulta
• Usa proyecciones de columnas (selecciona solo las columnas necesarias) para minimizar los datos escaneados
• Las tablas particionadas podan automáticamente los archivos de datos innecesarios

Consultar con Amazon Redshift

Amazon Redshift Serverless proporciona un motor de análisis SQL administrado que puede consultar tus tablas DPF a través del catálogo federado. Redshift es ideal para cargas de trabajo analíticas sostenidas, integración con herramientas de BI y escenarios que requieren uniones complejas entre múltiples tablas.

Solo lectura a través de la federación

Al igual que Athena, el acceso a Redshift a través de un catálogo federado es actualmente solo lectura. Las operaciones de escritura no se admiten en tablas federadas.

Configuración

1. Crea un grupo de trabajo Redshift Serverless Si aún no tienes uno, crea un grupo de trabajo y un namespace en la consola de Redshift. Asegúrate de que el rol IAM asociado tenga permisos de Lake Formation en el catálogo federado dpf-data.
2. Consulta usando notación de tres partes Haz referencia al catálogo federado directamente en tu SQL:

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

3. Alternativamente, crea un esquema externo Para una notación de dos partes más simple, crea un esquema externo que apunte a la base de datos federada:

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

   Luego consulta con notación de dos partes:

   SELECT * FROM dpf_workspace.customers LIMIT 100;
   

Operaciones admitidas

Operación	Compatible	Notas
SELECT	✅	SQL completo con optimizaciones de Redshift
Joins entre tablas	✅	Une tablas DPF entre sí o con tablas de Redshift
Vistas materializadas	✅	Almacena en caché consultas frecuentes para un acceso más rápido
Funciones de ventana	✅	Soporte completo de funciones analíticas
INSERT / UPDATE / DELETE	❌	No compatible en tablas federadas
MERGE	❌	No compatible en tablas federadas

Ejemplos

Agregación por trabajo 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 tablas 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;

Crear una vista materializada para consultas frecuentes:

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 — Cuándo usar cada uno

Consideración	Athena	Redshift Serverless
Modelo de precios	Por consulta ($5/TB escaneado)	Por hora-RPU (~$0.375/RPU-hora)
Costo en inactividad	$0	Casi $0 (se reduce a cero, ~30s de arranque en frío)
Ideal para	Consultas ad-hoc, exploración de datos	Cargas de trabajo sostenidas, paneles, herramientas de BI
Complejidad de configuración	Cero infraestructura	Workgroup + namespace + rol IAM
Funciones avanzadas	Time travel, consultas de metadatos	Vistas materializadas, joins entre bases de datos
Soporte de escritura	❌ (vía federación)	❌ (vía federación)

Recomendación

Para la mayoría de los usuarios de DPF que realizan inspección de datos, validación y análisis ad-hoc, Athena es la opción más simple y rentable. Elige Redshift Serverless cuando necesites consultas concurrentes sostenidas, vistas materializadas o integración con herramientas de BI como QuickSight, Tableau o Looker.

¿Necesitas acceso de escritura?

Para operaciones INSERT, UPDATE y DELETE, conéctate a través del PostgreSQL Gateway (JDBC/ODBC estándar, lectura + escritura), o conéctate directamente al DPF Iceberg REST Catalog usando un motor abierto como Apache Spark, Trino o PyIceberg.

Consulta con Azure

Configuración de accesos directos de Microsoft Fabric

Microsoft Fabric se conecta a catálogos Iceberg externos mediante OneLake Shortcuts. Un acceso directo crea una referencia virtualizada a tus tablas, permitiendo que las cargas de trabajo de Fabric (SQL Analytics Endpoint, Lakehouse, Notebooks) consulten tus datos como si estuvieran almacenados localmente en OneLake — sin copiar ni mover nada.

Una vez configurado un acceso directo, tus tablas aparecen como tablas nativas de Fabric y pueden consultarse con T-SQL desde SQL Server, Synapse o cualquier herramienta conectada al Fabric SQL Analytics Endpoint.

Requisitos previos

• Un workspace de DPF activo con al menos un trabajo de carga de datos completado
• La URL de tu endpoint del REST Catalog de DPF: https://api.dpf-it.com/iceberg/v1
• Una credencial API OAuth2 para tu cuenta de DPF (generada vía POST /oauth/clients)
• Un workspace de Microsoft Fabric con al menos acceso de Colaborador
• Un Lakehouse de Fabric creado dentro del workspace

Configuración paso a paso

1. Genera una credencial API desde la API de DPF Si aún no has creado una credencial API para tu cuenta de DPF, genera una ahora (Configuración → Credenciales API en la interfaz de DPF, o la llamada API a continuación). Es a nivel de cuenta — la misma credencial utilizada para la integración con AWS funciona aquí también.

   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. Abre tu Lakehouse de Fabric Navega a tu workspace de Microsoft Fabric y abre el Lakehouse donde deseas mostrar tus tablas. Selecciona la sección Tables en el panel del Explorador.
3. Crea un acceso directo de tabla Iceberg Haz clic en New shortcut → selecciona Apache Iceberg como tipo de origen. Completa los detalles de conexión:

   Campo	Valor
   Catalog URL	https://api.dpf-it.com/iceberg/v1
   Autenticación	OAuth2 Client Credentials
   Token endpoint	https://api.dpf-it.com/oauth/token
   Client ID	Tu client ID de DPF del Paso 1
   Client Secret	Tu client secret de DPF del Paso 1
   Namespace	El namespace de tu workspace (últimos 12 caracteres de tu workspaceId, p. ej. 633def9656c1)

4. Selecciona las tablas para el acceso directo Después de conectarte, Fabric muestra las tablas disponibles en tu namespace. Selecciona las tablas que deseas mostrar (p. ej., customers, accounts) y haz clic en Create.
5. Verifica en el Explorador del Lakehouse Tus tablas ahora aparecen en la sección Tables del Lakehouse con un ícono de acceso directo. Son consultables inmediatamente a través del SQL Analytics Endpoint.

Mapeo de Namespace

El namespace de Iceberg se deriva de tu workspaceId — específicamente los últimos 12 caracteres. Por ejemplo, si tu workspaceId es a9d4d243-d856-4558-84ba-633def9656c1, el namespace es 633def9656c1. Puedes encontrar este valor en la configuración de tu workspace o desde la respuesta de get-status de la API de DPF.

Actualización automática de metadatos

Los accesos directos de Fabric obtienen los metadatos de Iceberg en el momento de la consulta. Cuando se cargan nuevos datos vía DPF, tus tablas de acceso directo reflejan el estado más reciente automáticamente — sin necesidad de actualización manual.

Acceso de solo lectura

Los accesos directos de Iceberg en Microsoft Fabric son de solo lectura. Puedes consultar, agregar y unir los datos, pero INSERT, UPDATE y DELETE no son compatibles a través de accesos directos. Para modificar datos, usa la API de DPF o conéctate directamente vía el REST Catalog.

Consulta con SQL Server

SQL Server 2022 y Azure SQL Managed Instance pueden consultar tus tablas mediante servidores vinculados que apuntan a un Fabric SQL Analytics Endpoint o a un pool de Synapse Serverless SQL. Esto permite acceso T-SQL a tus datos de Iceberg desde tus bases de datos SQL Server existentes.

Arquitectura

SQL Server no se conecta directamente a catálogos Iceberg. En su lugar, consulta a través de un intermediario que soporta Iceberg de forma nativa — ya sea el Fabric SQL Analytics Endpoint o un pool de Synapse Serverless SQL — usando una conexión de servidor vinculado.

┌────────────────────┐ │ SQL Server 2022 │ │ (o Azure SQL MI)│ └─────────┬──────────┘ │ Servidor vinculado (ODBC / MSOLEDBSQL) ▼ ┌─────────────────────────────┐ │ Fabric SQL Analytics │ │ Endpoint │ │ ─── O ─── │ │ Synapse Serverless SQL │ └──────────────┬──────────────┘ │ Acceso directo Iceberg / OPENROWSET ▼ ┌─────────────────────────────┐ │ Tus tablas (vía acceso directo) │ └─────────────────────────────┘

Opción A: Vía Fabric SQL Analytics Endpoint

Una vez que hayas creado accesos directos de Iceberg en un Lakehouse de Fabric, el SQL Analytics Endpoint del Lakehouse los expone como tablas consultables con T-SQL.

1. Obtén la cadena de conexión del SQL Analytics Endpoint En tu Lakehouse de Fabric, haz clic en SQL Analytics Endpoint en la barra superior. Copia el nombre del servidor (p. ej., xxxxxxxx.datawarehouse.fabric.microsoft.com).
2. Crea un servidor vinculado en 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. Consulta tus tablas a través del 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;
   

Opción B: Vía Synapse Serverless SQL

Alternativamente, crea un servidor vinculado que apunte a un pool de Synapse Serverless SQL que tenga acceso a tus tablas.

-- 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 bases de datos

Una ventaja clave del enfoque de servidor vinculado es que puedes unir tus tablas de Iceberg con datos existentes de SQL Server en una sola 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;

Consejo de rendimiento

Al unir tablas remotas de Iceberg con tablas locales de SQL Server, filtra el lado remoto de la manera más agresiva posible. Los predicados en dpf_job, dpf_filename y columnas de partición se empujan hacia la capa de Iceberg, minimizando la transferencia de datos a través del enlace.

Consulta con Azure Synapse Analytics

El pool de Synapse Serverless SQL de Azure puede consultar tus tablas de Iceberg mediante accesos directos de Fabric Lakehouse. Esto proporciona acceso T-SQL de pago por consulta sin aprovisionar recursos de cómputo.

Acceso de solo lectura

Synapse Serverless SQL soporta operaciones de solo lectura en tablas externas de Iceberg. Las operaciones de escritura deben realizarse a través de la API de DPF o un motor abierto.

Configuración: Vía accesos directos de Fabric Lakehouse

Una vez que hayas configurado los accesos directos de Fabric, Synapse puede consultar tus tablas a través del SQL Analytics Endpoint del Lakehouse. Fabric maneja la autenticación del catálogo y la resolución de metadatos automáticamente.

1. Conecta Synapse al workspace de Fabric En Synapse Studio, agrega un servicio vinculado que apunte a tu Fabric SQL Analytics Endpoint, o consúltalo directamente usando un pool de Serverless SQL con acceso entre workspaces.
2. Consulta tus tablas

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

Operaciones compatibles

Operación	Compatible	Notas
SELECT	✅	T-SQL completo con joins, agregaciones, CTEs
Empuje de predicados	✅	Filtros empujados a Iceberg para poda de particiones
Joins entre bases de datos	✅	Une tus tablas de Iceberg con otras bases de datos de Synapse
Vistas / Procedimientos almacenados	✅	Envuelve tablas de acceso directo en vistas para abstracción
INSERT / UPDATE / DELETE	❌	No compatible en tablas de Iceberg de acceso directo

Ejemplos

Agregación por archivo fuente y trabajo:

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 linaje de datos — rastrea filas hasta su origen:

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 fuentes — datos de Iceberg con tablas de 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 — Cuándo usar cada uno

Consideración	SQL Server (Servidor vinculado)	Azure Synapse Serverless
Configuración	Servidor vinculado al endpoint de Fabric	Acceso directo de Fabric vía Lakehouse
Ideal para	Unir con datos existentes de SQL Server, consultas operativas	Análisis ad-hoc, herramientas de BI, agregaciones a gran escala
Precio de consultas	Sin costo adicional (usa la licencia existente de SQL Server)	~$5/TB procesado (pago por consulta)
Rendimiento	Depende del rendimiento del servidor vinculado	Motor distribuido, escala con el volumen de datos
Materialización	SELECT INTO en tablas locales	SELECT INTO en tablas locales
Soporte de escritura	❌ (solo lectura vía enlace)	❌ (solo lectura vía accesos directos)
Integración con BI	Directa vía SSMS, SSRS	Conectores nativos de Power BI, Tableau, Looker

Recomendación

Si tu equipo de análisis vive en el ecosistema de Azure, usa accesos directos de Fabric para la configuración más simple y la mayor compatibilidad de herramientas (Power BI, Synapse, SQL Server).

¿Necesitas acceso de escritura?

Para operaciones INSERT, UPDATE y DELETE, conéctate a través del PostgreSQL Gateway (JDBC/ODBC estándar, lectura + escritura), o conéctate directamente al DPF Iceberg REST Catalog usando un motor abierto como Apache Spark, Trino o PyIceberg.

Consulta con GCP

Configuración de la integración con GCP

BigQuery accede a tus tablas mediante BigQuery Omni, el conector entre nubes de Google para datos alojados en AWS. Dado que los datos de tus tablas residen en el almacenamiento S3 de DPF, esto requiere una autorización IAM de cuenta cruzada única, similar a la integración con Glue descrita anteriormente.

Requisitos previos

• Un workspace de DPF activo con al menos un trabajo de carga de datos completado
• La URL de tu endpoint del REST Catalog de DPF: https://api.dpf-it.com/iceberg/v1
• Una conexión de BigQuery Omni a AWS (región aws-us-east-1) y una cuenta de AWS para autorizar el acceso entre cuentas

Requisito: Completa la configuración de cuenta cruzada con DPF

BigQuery Omni lee tus archivos de datos directamente desde Amazon S3 usando un rol IAM de AWS que autorizas. Después de crear el rol IAM en el Paso 1 a continuación, contáctanos con tu ID de cuenta de AWS, ID de workspace y el ARN del rol IAM. Nuestro equipo autorizará ese rol para tu workspace específico — un paso único por workspace.

Configuración paso a paso

1. Crea un rol IAM de AWS para BigQuery Omni Sigue la configuración de BigQuery Omni de Google para crear el rol y la política de confianza, luego crea la conexión en 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. Crea una tabla externa de BigLake que apunte a los metadatos de Iceberg BigQuery Omni lee tablas de Iceberg desde un puntero de metadatos en lugar de hablar con el REST catalog en vivo, por lo que debes proporcionar el metadata_location actual de la tabla (visible en la interfaz del workspace de DPF o vía la respuesta de LoadTable del 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"
   }
   

Actualización manual de metadatos

A diferencia de las rutas de federación de AWS/Azure, una tabla externa de Iceberg de BigQuery Omni fija un snapshot específico de metadata_location. Después de cargar nuevos datos en la tabla vía DPF, vuelve a ejecutar el comando bq mk --table (o una consulta programada) con la ruta de metadatos más reciente para recoger los nuevos datos.

Consulta desde GCP

Una vez configurada la tabla externa de BigLake, consúltala como cualquier otra tabla de BigQuery:

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

¿Necesitas acceso de escritura desde BigQuery? Las tablas externas de BigQuery Omni son de solo lectura. Para escrituras desde una carga de trabajo alojada en GCP, conéctate a través de la Puerta de enlace PostgreSQL, o conéctate directamente al Catálogo REST de Iceberg de DPF usando un motor abierto como Apache Spark, Trino o PyIceberg.

Consultar con Databricks

Configuración de la integración con Unity Catalog de Databricks

Unity Catalog admite federación de catálogos Iceberg REST: un objeto de catálogo externo que apunta a un endpoint REST de Iceberg externo. Una vez configurado, tu espacio de trabajo de DPF aparece dentro de Unity Catalog como un catálogo externo, consultable desde los almacenes SQL de Databricks y los notebooks por igual, en cualquier nube en la que se ejecute tu espacio de trabajo de Databricks.

Requisitos previos

• Un espacio de trabajo de DPF activo con al menos un trabajo de carga de datos completado
• La URL del endpoint de tu Catálogo REST de DPF: https://api.dpf-it.com/iceberg/v1
• Credenciales de cliente OAuth2 para la autenticación del catálogo (consulta el Paso 1 a continuación para generarlas)
• Un espacio de trabajo de Databricks con Unity Catalog habilitado
• Privilegios de CREATE CONNECTION y CREATE CATALOG en el metastore

Configuración paso a paso

1. Genera una credencial de API desde la API de DPF Esta es la misma credencial a nivel de cuenta que se usa para las otras integraciones de esta página (Configuración → Credenciales de API en la interfaz de DPF, o la llamada a la API a continuación).

   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. Crea la conexión En un editor SQL de Databricks o un notebook, crea una conexión que describa cómo llegar al catálogo REST de 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. Crea el catálogo externo

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

4. Verifica el descubrimiento de tablas Cada espacio de nombres del espacio de trabajo de DPF aparece como un esquema dentro del catálogo externo:

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

Credenciales emitidas: sin configuración entre cuentas

Unity Catalog obtiene credenciales S3 de corta duración directamente del Catálogo REST de DPF en el momento de la consulta, de la misma manera que lo hace una conexión directa de Spark o Trino. A diferencia de la integración con AWS Glue, no se necesita autorización IAM entre cuentas, independientemente de la nube en la que se ejecute tu espacio de trabajo de Databricks.

Solo lectura mediante federación

Al igual que las otras rutas de federación en esta guía, consultar a través del catálogo externo admite actualmente operaciones de solo lectura (SELECT, viaje en el tiempo). Para escribir, usa la Puerta de enlace PostgreSQL o conéctate directamente con el soporte de catálogo REST de Iceberg de PySpark.

Consultar con Databricks

Una vez configurado el catálogo externo, consulta tus tablas de la misma manera desde un almacén SQL de Databricks o un notebook; ambos comparten los mismos metadatos de Unity Catalog.

Ejemplos

Consulta básica con campos de auditoría de DPF:

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

Consulta de viaje en el tiempo:

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

Unir una tabla de DPF (externa) con una tabla 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;

Operaciones admitidas

Operación	Admitida	Notas
SELECT	✅	SQL completo con uniones, agregaciones, funciones de ventana
Viaje en el tiempo	✅	Consulta instantáneas históricas por marca de tiempo
Uniones entre catálogos	✅	Une tablas de DPF con tablas Delta u otras de Unity Catalog
INSERT / UPDATE / DELETE	❌	No admitida en catálogos externos federados
MERGE INTO	❌	No admitida en catálogos externos federados

¿Necesitas acceso de escritura?

Para INSERT, UPDATE y DELETE, conéctate a través de la Puerta de enlace PostgreSQL (JDBC/ODBC estándar, lectura + escritura), o conéctate directamente al Catálogo REST de Iceberg de DPF desde un notebook de Databricks usando el soporte de catálogo REST de Iceberg de PySpark.

Consultar con Snowflake

Configuración de la integración con el catálogo de Snowflake

Snowflake lee tablas Iceberg externas a través de una integración de catálogo de tipo ICEBERG_REST, junto con un volumen externo que describe cómo llegar al almacenamiento subyacente. Una vez configurado, las tablas de tu espacio de trabajo de DPF pueden exponerse como tablas Iceberg de Snowflake y consultarse con SQL estándar.

Requisitos previos

• Un espacio de trabajo de DPF activo con al menos un trabajo de carga de datos completado
• La URL del endpoint de tu Catálogo REST de DPF: https://api.dpf-it.com/iceberg/v1
• Credenciales de cliente OAuth2 para la autenticación del catálogo (consulta el Paso 1 a continuación para generarlas)
• Una cuenta de Snowflake en la edición Enterprise o superior (requerida para tablas Iceberg)
• ACCOUNTADMIN, o un rol con privilegios de CREATE INTEGRATION y CREATE EXTERNAL VOLUME

Configuración paso a paso

1. Genera una credencial de API desde la API de DPF A nivel de cuenta: Configuración → Credenciales de API en la interfaz de DPF, o la llamada a la API a continuación.

   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. Crea la integración 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. Crea un volumen externo para credenciales emitidas Omite STORAGE_AWS_ROLE_ARN para que Snowflake dependa de la integración de catálogo para emitir credenciales de almacenamiento de corta duración por consulta, en lugar de un rol IAM estático; no se requiere autorización entre cuentas.

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

4. Crea una base de datos vinculada al catálogo para tu espacio de trabajo Esto rellena automáticamente una base de datos de Snowflake desde el espacio de nombres de tu espacio de trabajo de DPF; no es necesario declarar cada tabla individualmente.

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

5. Verifica el descubrimiento de tablas

   SHOW ICEBERG TABLES IN DATABASE dpf_data;
   

Asignación de espacios de nombres

DPF usa tu workspaceId como el espacio de nombres de Iceberg. Establece CATALOG_NAMESPACE al espacio de nombres de tu espacio de trabajo para limitar la base de datos vinculada a las tablas de ese espacio de trabajo.

Solo lectura mediante federación

Al igual que las otras rutas de federación en esta guía, las tablas Iceberg respaldadas por una integración de catálogo REST son actualmente de solo lectura en Snowflake. Para escribir, usa la Puerta de enlace PostgreSQL o conéctate directamente con un motor abierto.

Consultar con Snowflake

Consulta la base de datos vinculada al catálogo como cualquier otra base de datos de Snowflake: el espacio de nombres de tu espacio de trabajo aparece como un esquema, y cada tabla de DPF aparece como una tabla Iceberg de Snowflake.

Ejemplos

Consulta básica con campos de auditoría de DPF:

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

Agregación por trabajo 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;

Unir una tabla Iceberg de DPF con una tabla nativa de Snowflake:

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;

Operaciones admitidas

Operación	Admitida	Notas
SELECT	✅	SQL completo con uniones, agregaciones, funciones de ventana
Uniones entre bases de datos	✅	Une tablas Iceberg de DPF con tablas nativas de Snowflake
Snowpark	✅	Lee tablas de DPF en DataFrames de Snowpark como cualquier otra tabla
INSERT / UPDATE / DELETE	❌	No admitida en tablas Iceberg respaldadas por catálogo REST

¿Necesitas acceso de escritura?

Para INSERT, UPDATE y DELETE, conéctate a través de la Puerta de enlace PostgreSQL (JDBC/ODBC estándar, lectura + escritura), o conéctate directamente al Catálogo REST de Iceberg de DPF usando un motor abierto como Apache Spark, Trino o PyIceberg.

Agentes de IA (MCP)

DPF publica un servidor de Protocolo de Contexto de Modelo (MCP) para que los agentes de IA puedan descubrir la API de DPF, incorporar nuevos usuarios y ejecutar flujos de trabajo de integración de datos de extremo a extremo: registrar una cuenta, crear un espacio de trabajo, cargar un archivo, construir una especificación de datos y consultar los resultados, todo mediante llamadas a herramientas en lenguaje natural. Hay dos formas de conectarlo, y cuál usar depende por completo de tu cliente.

Un solo servidor, sin instalación

DPF ejecuta un único servidor MCP remoto. VS Code, Cursor, Claude Desktop/Claude.ai, Kiro IDE y ChatGPT Developer Mode admiten el inicio de sesión real con OAuth 2.1: apúntalos a la URL a continuación y una ventana emergente de inicio de sesión en el navegador se encarga del resto. Sin npm install, sin Node.js local. Los clientes que no admiten ese flujo de inicio de sesión en el navegador (Codex CLI, Kiro CLI) usan una credencial de API de DPF en su lugar.

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

Apunta tu cliente a https://api.dpf-it.com/mcp sin credenciales configuradas. En la primera conexión, el cliente abrirá un navegador en una página de inicio de sesión real de DPF: tu contraseña se escribe allí, nunca dentro de un chat o una llamada a una herramienta, y, si aún no tienes una cuenta, el flujo de registro de la misma página gestiona el alta y la verificación por correo electrónico antes de redirigir de vuelta. A partir de entonces, el cliente almacena su propio token de acceso y de actualización y se reconecta silenciosamente; no se te pedirá que inicies sesión de nuevo a menos que revoques el acceso o que un token de actualización expire por sí mismo.

VS Code (.vscode/mcp.json, a nivel de espacio de trabajo o de usuario):

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

Cursor: misma forma, en la configuración de MCP de Cursor o en su propio mcp.json. Haz clic en "Add new global MCP server" y pega la URL, o usa un enlace profundo de estilo "Add to Cursor" si has configurado uno.

Claude Desktop / Claude.ai: Configuración → Conectores → Añadir conector personalizado → pega https://api.dpf-it.com/mcp como la URL del servidor MCP remoto. Claude gestiona el registro dinámico de clientes automáticamente.

ChatGPT (Developer Mode): Configuración → Apps y conectores → Avanzado → habilita Developer Mode, luego añade un conector personalizado con la misma URL y elige OAuth como tipo de autenticación.

Sin almacenamiento de contraseña en el cliente

El servidor remoto nunca acepta una contraseña como argumento de herramienta. Si un cliente te pide que escribas tu contraseña de DPF directamente en un mensaje de chat en lugar de una ventana emergente del navegador, ese no es el funcionamiento previsto de este servidor: detente y verifica la URL del conector.

Clientes sin soporte de OAuth (Codex CLI, Kiro CLI)

Codex CLI y Kiro CLI no implementan el flujo de inicio de sesión en navegador de MCP OAuth que usan los clientes anteriores, por lo que apuntarlos a https://api.dpf-it.com/mcp sin credenciales configuradas no funcionará: no hay navegador que puedan abrir. Sin embargo, ambos te permiten adjuntar un encabezado Authorization estático a la configuración de un servidor MCP remoto. Las credenciales de API de DPF (las mismas a nivel de cuenta que se usan para la federación de catálogos en el resto de esta guía, creadas mediante Configuración → Credenciales de API o POST /oauth/clients) están diseñadas exactamente para eso: un par client_id / client_secret que intercambias por un token de portador tú mismo, en lugar de que un cliente lo haga de forma interactiva en tu nombre.

En qué se diferencia de los clientes OAuth anteriores

VS Code/Cursor/Claude/ChatGPT inician sesión una vez y luego se actualizan silenciosamente para siempre: el cliente gestiona un token de actualización en segundo plano y nunca vuelves a pensar en ello. La ruta de client_credentials aquí no tiene token de actualización: cada intercambio genera un token de acceso válido durante 24 horas, y ni Codex CLI ni Kiro CLI saben cómo renovarlo por ti. Prevé volver a ejecutar el intercambio (Paso 2 a continuación) aproximadamente a diario; el fragmento al final de esta sección automatiza ese proceso.

Configuración paso a paso

1. Crea una credencial de API Configuración → Credenciales de API en la interfaz de DPF, o directamente a través de la API:

   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. Intercámbiala por un token de acceso Este es el paso que repetirás cada vez que el token expire:

   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. Apunta tu cliente al token mediante un encabezado estático Codex CLI (~/.codex/config.toml): lee el token de la variable de entorno establecida en el Paso 2, por lo que nunca toca el archivo de configuración en sí:

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

   Kiro CLI (JSON de configuración del agente, p. ej., .kiro/agents/*.json): misma idea, mediante sustitución de ${VAR} en el valor del encabezado:

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

Volver a ejecutar el Paso 2 antes de cada sesión es suficiente para un uso ocasional. Para uso diario, colócalo en tu perfil de shell para que una nueva terminal siempre comience con un token activo:

# ~/.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'])")

Una sesión ya en ejecución con un token caducado comenzará a recibir 401 de DPF: reiníciala después de actualizar el token en lugar de esperar que se recupere por sí sola.

Herramientas disponibles

El servidor MCP remoto expone las siguientes herramientas una vez conectado:

Herramienta	Qué hace
list_my_workspaces / create_workspace	Lista o crea espacios de trabajo para la cuenta autenticada
list_data / get_status / delete_data_spec	Inspecciona y gestiona especificaciones de datos y trabajos
submit_query	Ejecuta SQL contra las tablas Iceberg de un espacio de trabajo
onboard_data_source → finish_data_source_onboarding	Crea una especificación de datos, sube un archivo de muestra y ejecuta la inferencia de esquema con IA
update_data_spec → finish_data_spec_update	Cambia la configuración de una especificación existente, opcionalmente reemplazando su archivo de muestra
run_data_job → finish_data_job	Procesa archivos nuevos a través de una especificación ya configurada
manage_connection / manage_trigger / setup_scheduled_pull	Configura y gestiona la ingesta SFTP programada
call_dpf_api	Vía de escape para cualquier acción de la API de DPF sin una herramienta dedicada

Las cargas de archivos son de dos pasos en remoto onboard_data_source / update_data_spec / run_data_job devuelven una URL de carga prefirmada en lugar de subir un archivo ellos mismos — un servidor remoto no tiene acceso a tu disco local. Si tu cliente tiene su propio acceso a archivos/shell (por ejemplo, Cursor, VS Code), sube el archivo directamente; de lo contrario, adjunta el archivo en el chat cuando se te solicite y luego llama a la herramienta correspondiente finish_* para continuar.