Abrió Azure Portal para activar un área de trabajo de Databricks para el nuevo proyecto de análisis de su equipo. Veinte minutos más tarde, todavía está configurando redes virtuales, rangos de subredes y puertas de enlace NAT. Sus científicos de datos están esperando. El proyecto no ha comenzado, pero ya estás retrasado.

Esa complejidad de la infraestructura es exactamente lo que Ladrillos de datos de Azure los espacios de trabajo sin servidor eliminan. Pero para comprender por qué esto es importante, es necesario comprender qué es realmente Azure Databricks y, en primer lugar, por qué el modelo de implementación tradicional generó ese impuesto de configuración de veinte minutos.

Esta guía le explica qué son realmente Azure Databricks y las áreas de trabajo sin servidor, en qué se diferencian de las implementaciones tradicionales y cuándo debe (o no) usarlos.

¿Qué son Azure Databricks y las áreas de trabajo sin servidor?

Azure Databricks es una plataforma de análisis unificada que combina ingeniería de datos, ciencia de datos e inteligencia empresarial en un único entorno. Piense en ello como Apache Spark administrado con herramientas de colaboración adicionales, funciones de seguridad e integraciones de Azure. Ejecuta consultas SQL, crea modelos de aprendizaje automático, organiza canalizaciones ETL y analiza datos, todo sin administrar usted mismo la infraestructura subyacente de Spark.

El problema que resuelve Databricks: los equipos de datos suelen hacer malabarismos con herramientas independientes para la ingesta, la transformación, el análisis y la visualización. Los ingenieros de datos utilizan una plataforma, los científicos de datos utilizan otra y los analistas utilizan una tercera. Azure Databricks consolida esos flujos de trabajo. Su ingeniero de datos escribe una canalización en Python, su científico de datos entrena un modelo en el mismo clúster, su analista consulta los resultados a través de SQL, todo en el mismo espacio de trabajo con gobernanza y seguridad compartidas.

Esa consolidación se produce en dos modelos de implementación: tradicional y sin servidor. Comprender la diferencia requiere comprender la arquitectura de Databricks.

Arquitectura tradicional de Azure Databricks

Azure Databricks tradicional sigue un arquitectura híbrida. El plano de control(la capa de administración que incluye la aplicación web Databricks, las API de administración de clústeres, el almacenamiento de portátiles y la programación de trabajos) se ejecuta en un cuenta administrada (una suscripción de Azure propiedad de Databricks y operada por ella, no visible en su portal de Azure).

El plano de cálculo(donde se ejecutan sus cargas de trabajo reales de Spark) se implementa en su suscripción de Azure. Usted aprovisiona la red virtual, configura grupos de seguridad de red, implementa máquinas virtuales para nodos trabajadores, define rangos de subred, configura puertas de enlace NAT para conectividad saliente y administra políticas de escalado automático. Ese es el impuesto de preparación de veinte minutos del párrafo inicial.

Este modelo le brinda control total sobre las redes, la seguridad y los recursos informáticos. También le otorga total responsabilidad por su mantenimiento.

Espacios de trabajo sin servidor: la alternativa

Los espacios de trabajo sin servidor eliminan por completo el plano informático de su suscripción. Tanto el plano de control como el plano de cálculo se ejecutan en la cuenta administrada de Databricks. No aprovisiona redes virtuales. No configura grupos de seguridad. No implementas máquinas virtuales. Databricks maneja toda la infraestructura. Obtendrá un espacio de trabajo funcional en segundos en lugar de veinte minutos.

La computación proviene de grupos cálidos: máquinas virtuales preaprovisionadas y mantenidas por Databricks. Cuando ejecuta una consulta, el sistema le asigna una ranura disponible en lugar de iniciar una nueva máquina virtual. Los tiempos de inicio disminuyen de varios minutos a segundos.

Consejo profesional: consulte el documentación de disponibilidad regional antes de crear un espacio de trabajo. No todas las regiones todavía admiten la computación sin servidor.

La abstracción de infraestructura se extiende al almacenamiento. Las áreas de trabajo clásicas requieren una cuenta de almacenamiento en su suscripción de Azure para los datos del área de trabajo. Los espacios de trabajo sin servidor incluyen Almacenamiento predeterminado—almacenamiento de objetos totalmente administrado y aprovisionado automáticamente. Las tablas y volúmenes administrados de Unity Catalog se encuentran allí sin configuración.

Diferencias clave entre tradicional y sin servidor

Ahora que comprende ambos modelos, esto es lo que realmente cambia:

Comenzando con la tecnología sin servidor

Crear un espacio de trabajo sin servidor lleva unos segundos. Vaya a Azure Portal → Azure Databricks → Crear → Seleccionar Sin servidor → Implementar. Sin configuración de red virtual. Sin esperas.

Una vez implementado, cree un cuaderno. Haga clic en Conectar y verá Sin servidor como la opción de cálculo predeterminada. Sin interfaz de usuario de configuración de clúster. Sin selección de tipo de instancia. Sin políticas de escalado automático. Tú escribes código, el sistema asigna recursos.

La arquitectura utiliza Conexión de chispaque desacopla a su cliente del controlador Spark. Esto habilita el modelo sin servidor, pero crea algunas limitaciones que cubriremos en breve.

Verificación de la realidad: Spark Connect permite la tecnología sin servidor, pero crea limitaciones. No puede utilizar las API de RDD, no obtiene la interfaz de usuario tradicional de Spark y no se admiten ciertas operaciones JVM de bajo nivel.

Serverless admite tres tipos de cargas de trabajo: Cuadernos (Python y SQL interactivos), Empleos (flujos de trabajo programados sin aprovisionamiento manual), y Almacenes SQL (cómputo optimizado para BI).

Comprender el modelo de costos

Los precios sin servidor combinan la licencia de software (DBU) y la infraestructura informática en una única tarifa. Las implementaciones clásicas se cobran por separado: DBU de Databricks más costos de VM de Azure. Serverless incluye ambos en un solo cargo.

Ejemplo: SQL sin servidor puede costar 0,70 dólares por hora de DBU en las regiones de EE. UU., y cubre tanto el software como las máquinas virtuales. SQL clásico cobra $0,22 por DBU más facturación de VM por separado.

La rentabilidad depende de los patrones de carga de trabajo. Las cargas de trabajo cortas o en ráfagas suelen costar menos porque la tecnología sin servidor elimina el tiempo de inactividad. Un clúster clásico puede ejecutarse durante 60 minutos para procesar un trabajo de 5 minutos debido al lento ajuste de escala automático. Facturas sin servidor solo por los segundos utilizados.

Los trabajos de ETL de larga duración pueden ser significativamente más costosos: los estudios de referencia muestran costos entre 2 y 3 veces más altos que los clústeres clásicos optimizados para trabajos que exceden una hora.

Las políticas presupuestarias le permiten etiquetar cargas de trabajo y analizar el gasto en el system.billing.usage mesa. Puede establecer límites de gasto para evitar costos descontrolados.

Qué no admiten los espacios de trabajo sin servidor

Serverless no es un reemplazo directo para todos los escenarios:

Soporte de idiomas: Sólo Python y SQL. Por lo general, Scala y R no son compatibles.

API de chispa: La API RDD no funciona. Utilice las API de DataFrame o Dataset.

IU de chispa: La interfaz de usuario tradicional de Spark no está disponible. Usar Perfil de consulta en cambio.

Redes: si bien no administra directamente las IP públicas, la infraestructura sin servidor subyacente las utiliza para determinadas conexiones salientes. La conectividad con los recursos detrás de los firewalls requiere Configuraciones de conectividad de red sin servidor.

Bibliotecas: No hay bibliotecas con ámbito de clúster. Utilice el ámbito del cuaderno (%pip install) o dependencias a nivel de trabajo.

Advertencia: si sus flujos de trabajo dependen del código Scala, operaciones RDD o integraciones JVM profundas, la tecnología sin servidor no es viable. Validar contra el documentación de limitaciones antes de migrar.

Integración del catálogo de Unity

Espacios de trabajo sin servidor mandato Catálogo de unidad. Todo el acceso a los datos pasa por los permisos de Unity Catalog. Los patrones de transferencia de credenciales heredados se reemplazan por ubicaciones externas y entidades de servicio de Unity Catalog.

Su patrimonio de datos existente de Unity Catalog permanece accesible. Transferencia de permisos. El linaje continúa. La computación multiinquilino utiliza el espacio aislado para aislar el código de usuario, lo que garantiza que las políticas de seguridad a nivel de fila y columna se apliquen correctamente.

Cuándo utilizar espacios de trabajo sin servidor

Utilice la tecnología sin servidor para:

• Análisis de datos exploratorios.: Acceso inmediato sin demoras en infraestructura. La reducción del inicio de minutos a segundos es importante al iterar consultas.

• Formación e incorporación: Los nuevos equipos comienzan inmediatamente sin aprobaciones de VNet ni planificación de capacidad.

• Paneles de BI: La latencia de las consultas es fundamental. El uso esporádico hace que los costos de los clústeres inactivos sean un desperdicio.

• Trabajos cortos de ETL: Los trabajos de dos minutos no deberían requerir un aprovisionamiento del clúster de cinco minutos.

Evite la tecnología sin servidor para:

• ETL de producción de larga duración: Los trabajos de una hora con necesidades de recursos estables son más baratos en computación clásica con instancias Spot o capacidad reservada.

• Cargas de trabajo heredadas de Spark: No se ejecutarán RDD, Scala o personalizaciones pesadas de Java.

• Redes personalizadas complejas: reglas de enrutamiento de VNet muy específicas que aún no son compatibles con la conectividad de red sin servidor.

La elección no es binaria. Muchas organizaciones ejecutan ambos. Serverless maneja análisis interactivos y flujos de trabajo cortos. Classic maneja trabajos por lotes de larga duración.

Modos de rendimiento y redes

Los trabajos sin servidor admiten dos modos de rendimiento: Rendimiento optimizado (inicio más rápido, escalado automático agresivo) y Estándar (menor costo, latencia ligeramente mayor). Puede cambiar entre modos según si prioriza la velocidad o la rentabilidad.

Los espacios de trabajo clásicos brindan control total de la red y responsabilidad total del mantenimiento. Serverless reemplaza la configuración manual de VNet con Políticas de salida sin servidor. Las políticas de salida definen a qué puntos finales externos puede llegar la computación sin servidor. Usted crea objetos de política a nivel de espacio de trabajo que especifican destinos permitidos.

Para la conectividad con bases de datos locales o recursos de Azure Private Link, configure objetos de conectividad de red sin servidor (NCC). Estas son abstracciones administradas, no emparejamiento de VNet. Databricks maneja las redes subyacentes. Usted define reglas de conexión lógica.

El árbol de decisiones

Haga estas preguntas antes de elegir:

¿Necesita que el espacio de trabajo esté operativo en una hora? → Serverless elimina los retrasos en la configuración.

¿Cargas de trabajo principales Python o SQL? → Serverless los admite completamente. Scala y R no funcionarán.

¿Los trabajos duran menos de una hora? → Los modelos de costos sin servidor favorecen las ejecuciones cortas.

¿Requisitos de red expresables como políticas de salida? → El enrutamiento personalizado complejo necesita espacios de trabajo clásicos.

¿El equipo ya utiliza Unity Catalog? → La tecnología sin servidor lo exige, eliminando una barrera a la migración.

Si respondió “sí” a la mayoría, es probable que la tecnología sin servidor sea una buena opción. Múltiples respuestas “no” sugieren espacios de trabajo clásicos.

Próximos pasos prácticos

La forma más rápida de entender la tecnología sin servidor es crear uno. Implemente a través de Azure Portal, luego cree un cuaderno de Python y ejecute:

df = spark.read.format("delta").table("samples.nyctaxi.trips")
df.count()

Observe la ausencia de registros de aprovisionamiento del clúster. Eso es sin servidor: ejecución inmediata sin configuración de infraestructura.

Cree un trabajo programado a continuación. No hay página de configuración del clúster. Defina el código, establezca la programación, Databricks se encarga de la computación. Controlar system.billing.usage para ver el seguimiento del consumo de DBU. Comprender el modelo de costos a tiempo evita sorpresas.

La compensación sin infraestructura

Los espacios de trabajo sin servidor intercambian el control de la infraestructura por una implementación más rápida y una reducción de los gastos operativos. No son universalmente superiores: están optimizados para diferentes restricciones.

Para análisis interactivos, paneles de BI y entornos de capacitación, el modelo funciona. Para trabajos por lotes de larga duración y aplicaciones Spark heredadas, los espacios de trabajo clásicos siguen siendo necesarios. No es necesario elegir un modelo. Serverless coexiste con implementaciones clásicas. Unity Catalog abarca ambos. Utilice la tecnología sin servidor para creación rápida de prototipos y la versión clásica para ETL de producción dentro de la misma cuenta.

La parte “sin esfuerzo” no es el procesamiento de datos. Es la ausencia de tiempo de preparación entre la decisión de iniciar un proyecto y la escritura del código. Para las organizaciones donde el aprovisionamiento de infraestructura es un cuello de botella, eso es importante.