¿Hay más paquetes SSIS en su empresa que personas capaces de entenderlos?

SSIS fue la respuesta idónea durante dos décadas de almacenes sobre SQL Server, y un parque maduro lo refleja fielmente: cientos de paquetes construidos por muchas manos a lo largo de muchos años, abriéndose de uno en uno en Visual Studio. Los paquetes aún funcionan. El problema es modificarlos.

Por qué el parque existente es difícil de modificar

• Un paquete por tabla, cada uno construido a mano. El mismo flujo de control y flujo de datos, ensamblado de nuevo para cada origen según el criterio de quien tuviera la tarea esa semana.
• Los paquetes antiguos conservan su propia configuración. Los parámetros de proyecto y los administradores de conexiones compartidos existen desde 2012; los paquetes heredados creados antes o sin ellos todavía contienen cadenas de conexión y rutas fijas en su interior.
• Un cambio de esquema es un recorrido por los paquetes. Añadir una columna al data warehouse implica abrir cada paquete que interactúe con ella. La estimación se mide en semanas porque la edición se repite en cientos de flujos de datos.
• Una columna más ancha rompe el flujo de datos. Los metadatos de los flujos de datos tienen tipos fijos asignados en tiempo de diseño, por lo que una columna de origen que crezca o cambie de tipo hace fallar el componente hasta que alguien la reasigne en Visual Studio.
• Nadie sabe exactamente qué está en producción. Los paquetes se programan desde el Agente SQL, desde SSISDB o desde otros paquetes, y nadie quiere ser quien borre el equivocado.

Nada de esto es culpa de SSIS. Un paquete es una forma adecuada de construir una carga individual, pero una forma deficiente de mantener un almacén de datos completo.

Dónde debe residir la estructura

• En un modelo, no en paquetes. Claves de negocio, relaciones y atributos declarados una sola vez, con las cargas derivadas a partir de ellos.
• Generada, para que cada carga tenga un formato idéntico. Sin variaciones según el desarrollador, sin paquetes que solo su autor sepa interpretar.
• En la plataforma que ya utiliza. SQL Server y Azure SQL son destinos de primera clase, y Fabric está disponible cuando decida dar el paso.

Qué cambia con Datavault Builder

Datavault Builder mantiene el data warehouse en un modelo visual y genera a partir de él las cargas de staging, historización y entrega, de forma nativa para SQL Server, Azure SQL y Fabric.

• El paquete por tabla desaparece. Los hubs, links, satélites y sus respectivas cargas se generan desde el modelo. No hay nada que abrir en Visual Studio.
• Una columna es solo un cambio de mapeo. Se mapea, se regenera y cada estructura dependiente se actualiza de forma coherente. Las columnas que faltan se cargan como null con una advertencia; las columnas ampliadas se ensanchan.
• Cada carga comparte exactamente la misma estructura. El generador escribe el código, evitando desviaciones de estilo y paquetes crípticos.
• El modelo es el inventario central. Qué se carga, desde dónde, hacia dónde y con qué linaje es visible en un único lugar. Se acabaron las búsquedas manuales entre trabajos del Agente SQL.
• Nada tiene que abandonar SQL Server. El almacén generado se ejecuta donde ya corrían los paquetes, y la transición a Fabric se realiza simplemente cambiando el motor de destino cuando usted lo decida.

Qué decidir

Audite el parque de paquetes y cuente cuántos existen exclusivamente para cargar una tabla desde un origen hacia el staging o el almacén. Ese recuento define el tamaño de la capa que un modelo debería generar. Ordenada por fuente de origen, esa misma lista proporciona el orden exacto para ir retirando los paquetes de forma progresiva.