T-SQL con Python: Fabric Data Warehouse habilita funciones externas en vista previa

Microsoft habilitó en vista previa una integración entre Fabric Data Warehouse y Fabric User Data Functions que permite crear funciones externas de T-SQL apuntando a funciones de Python alojadas en un ítem de User Data Functions dentro de Fabric. En la práctica, un equipo de datos puede llamar código Python desde sentencias habituales como SELECT, INSERT o UPDATE, sin necesidad de construir una aplicación o un pipeline separado para esa lógica.

Qué se anunció

El anuncio describe un mecanismo de delegación: cuando una consulta invoca la función externa, Data Warehouse traslada la ejecución al runtime de Fabric User Data Functions y devuelve el resultado a la consulta. El objetivo declarado es extender T-SQL con capacidades que le son ajenas o engorrosas, aprovechando el ecosistema de librerías de Python.

Los escenarios que Microsoft enumera como habilitados son concretos:

• Llamar APIs de Fabric o externas, y enviar correos, mensajes de Teams o notificaciones.
• Leer formatos como Excel, XML, PDF y otros archivos mediante librerías de Python.
• Acceder a datos en OneLake y leer o escribir en bases de datos de Fabric, Azure Cosmos DB y warehouses de otros workspaces.
• Recuperar secretos y valores de configuración desde Azure Key Vault o desde las librerías de variables de Fabric, para parametrizar la lógica personalizada.
• Cifrar, descifrar o enmascarar columnas sensibles con lógica propia y claves administradas por la organización.
• Enriquecer y validar datos: geocodificar direcciones, verificar números de VAT o IBAN, o puntuar registros con un modelo de machine learning.

El ejemplo técnico que acompaña la publicación es ilustrativo: clasificar eventos de red IPv6 por prefijo usando la librería estándar de Python, una tarea de parseo y aritmética binaria que resulta compleja de escribir directamente en T-SQL.

Por qué importa

La distancia entre el lugar donde viven los datos y el lugar donde se ejecuta la lógica siempre ha sido una fuente de fricción. Tradicionalmente, cuando un equipo de analítica necesitaba algo que SQL no resolvía bien —parsear un PDF, validar un identificador tributario, llamar un servicio externo, aplicar un modelo— aparecía un componente adicional: un script, un pipeline, un servicio intermedio, un proceso programado. Cada pieza nueva agrega superficie operativa, credenciales que rotar y puntos de falla.

Hecho verificado: la integración permite invocar funciones de Python desde T-SQL en Data Warehouse, en vista previa, con escenarios de APIs, archivos, OneLake, secretos y enmascaramiento.

Análisis: lo relevante no es solo la capacidad técnica, sino la reducción de arquitectura. Si una transformación puede resolverse dentro de la consulta, se elimina un salto de integración y se acerca el dato al resultado. Para organizaciones con equipos pequeños, eso puede significar menos infraestructura que mantener.

También hay una señal de dirección de producto: Microsoft está empujando un modelo donde el warehouse no es un destino final pasivo, sino un punto de ejecución que se conecta con servicios externos, almacenes de secretos y otras bases de datos. Es una convergencia entre analítica y automatización que conviene seguir.

Implicaciones para PYMES de América Latina

Menos piezas para el mismo resultado

Muchas PYMES de la región operan con equipos de datos de dos o tres personas, o incluso con un único perfil híbrido entre analista y desarrollador. La posibilidad de resolver validaciones, enriquecimiento o notificaciones dentro de la capa de consulta reduce la necesidad de mantener servicios intermedios y simplifica el gobierno de credenciales al centralizarlas en Key Vault o en librerías de variables.

Escenarios de alto valor local

Los ejemplos que menciona el anuncio conectan bien con problemas frecuentes en la región: validar dígitos verificadores de identificadores fiscales, normalizar direcciones para análisis logístico, enmascarar documentos de identidad o datos financieros antes de exponerlos a áreas no autorizadas, y disparar avisos por correo o Teams cuando una consulta detecta una anomalía. Todo eso hoy suele requerir desarrollo a medida.

Un puente entre el analista SQL y el científico de datos

Los perfiles que dominan Python y los que dominan SQL no siempre son la misma persona. La integración crea una interfaz contractual entre ambos: una función publicada con entradas y salidas claras que el equipo SQL puede consumir sin reescribir la lógica.

Advertencia sobre el costo y la disciplina operativa

Análisis: llamar funciones externas fila por fila, o dentro de consultas sobre grandes volúmenes, puede cambiar por completo el perfil de rendimiento y de consumo. En modelos de facturación por capacidad, ese patrón merece medición previa. La recomendación práctica es reservar la integración para operaciones acotadas —validaciones, enriquecimiento puntual, notificaciones— y no para transformaciones masivas que SQL resuelve mejor de forma nativa.

Limitaciones y riesgos

• Es una vista previa. El anuncio no indica disponibilidad general, ni compromisos de nivel de servicio, ni una fecha de estabilización. Cualquier diseño que dependa de ella debería aislarse para poder reemplazarse.
• No se detallan métricas de rendimiento ni latencia. No hay cifras públicas sobre el costo de la delegación al runtime de Python; sería un error asumir que es despreciable en consultas de alto volumen.
• No se especifican precios ni regiones de disponibilidad. Que el servicio opere en Azure no garantiza latencia o disponibilidad equivalentes para operaciones desde Colombia o el resto de América Latina.
• La superficie de seguridad se amplía. Una función que lee secretos y llama APIs externas desde una consulta amplía lo que un usuario con permisos de escritura en SQL podría llegar a ejecutar. La gestión de permisos sobre las funciones y sobre los almacenes de secretos pasa a ser un control crítico, no un detalle.
• Riesgo de fuga de lógica sensible. La lógica de enmascaramiento o cifrado queda en código Python versionado; su gobierno debe tratarse con el mismo rigor que un esquema de base de datos.
• El ejemplo de IPv6 es ilustrativo, no evidencia de desempeño ni un caso de negocio validado.
• No se verificó la disponibilidad de esta integración en las suscripciones específicas que usan las empresas de la región, ni sus interacciones con configuraciones de red privada.

La lectura razonable es que se trata de una capacidad prometedora para equipos con madurez intermedia en Fabric, que conviene probar en un entorno controlado antes de incorporarla a procesos críticos.