Según mi análisis, un modelo dimensional completo para nuestro almacén de datos requerirá la extracción de más de 200 tablas de origen. Algunas de estas tablas se extraerán como parte de una carga incremental y otras serán una carga completa.
Para tener en cuenta, tenemos alrededor de 225 bases de datos de origen, todas con el mismo esquema.
Por lo que he visto, construir un flujo de datos simple en SSIS con un origen OLE DB y un destino OLE DB requiere que las columnas y los tipos de datos se determinen en el momento del diseño. Esto significa que eventualmente terminaré con más de 200 flujos de datos solo para la extracción sola.
Desde una perspectiva de mantenibilidad, esto me parece un gran problema. Si tuviera que hacer algún tipo de cambio radical en el código de extracción, tendría que modificar 200 flujos de datos diferentes.
Una opción alternativa, escribí un pequeño script que lee las bases de datos de origen, los nombres de las tablas y las columnas que quiero extraer de un conjunto de tablas de metadatos. El código se ejecuta en múltiples bucles y utiliza SQL dinámico para extraer de las tablas de origen a través de un servidor vinculado y OPENQUERY.
Según mis pruebas, esto todavía no es tan rápido como usar un flujo de datos SSIS con un origen y destino OLEDB. Así que me pregunto qué tipo de alternativas tengo. Los pensamientos hasta ahora incluyen:
- Usar EZAPI para generar paquetes SSIS mediante programación con un flujo de datos simple. Las tablas y columnas para extraer provendrían de las mismas tablas de metadatos mencionadas anteriormente.
- Compre software de terceros (componente de flujo de datos dinámico)
¿Cuál es la mejor manera de abordar esto? Cuando se trata de la programación .NET, soy un principiante, por lo que el tiempo requerido para aumentar solo con lo básico también es una preocupación.
Respuestas:
No quisiera tener 200 flujos de datos en un solo paquete. El tiempo que llevaría abrir y validar lo haría viejo antes de tiempo.
EzAPI es divertido, pero si eres nuevo en .NET y SSIS, oh, no, no quieres eso. Creo que pasará mucho más tiempo aprendiendo sobre el modelo de objetos SSIS y posiblemente lidiando con COM que realmente haciendo el trabajo.
Como soy flojo, conectaré BIML como una opción gratuita que no incluiste en la lista. De una respuesta en SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
Creo que también podría ser un enfoque para ti. Usted define su BIML que describe cómo deben comportarse sus paquetes y luego los genera. En el escenario que describe dónde realiza un cambio y tiene que arreglar N paquetes, no, arregla su definición del problema y regenera paquetes.
O si se ha familiarizado lo suficiente con el marco, use algo como EzAPI para arreglar todas las cosas rotas. Heck, ya que has etiquetado esto como 2005, también puedes probar PacMan si necesitas hacer modificaciones masivas a los paquetes existentes.
Consideraciones de diseño de SSIS
En términos generales, trato de hacer que mis paquetes se centren en resolver una sola tarea (cargar datos de ventas). Si eso requiere 2 flujos de datos, que así sea. Lo que odio heredar es un paquete del asistente de importación y exportación con muchos flujos de datos no relacionados en un solo paquete. Descompóngalos en algo que resuelva un problema muy específico. Hace que las mejoras futuras sean menos riesgosas a medida que se reduce el área de superficie. Un beneficio adicional es que puedo estar trabajando en la carga
DimProductsmientras mi secuaz se ocupa de cargar elSnowflakeFromHellpaquete.Luego use los paquetes maestros para orquestar los flujos de trabajo infantil. Sé que estás en 2005, pero el lanzamiento de SSIS de SQL Server 2012 es el pijama del gato. Me encanta el modelo de implementación del proyecto y la estrecha integración que permite entre paquetes.
TSQL vs SSIS (mi historia)
En cuanto al enfoque TSQL puro, en un trabajo anterior, utilizaron un trabajo de 73 pasos para replicar todos sus datos de Informix en SQL Server. En general, tomó alrededor de 9 horas, pero podría extenderse a 12 más o menos. Después de comprar una nueva SAN, se redujo a más de 7 horas. El mismo proceso lógico, reescrito en SSIS fue un sub 2 horas consistentes. Fácilmente, el factor más importante para reducir ese tiempo fue la paralelización "gratuita" que obtuvimos con SSIS. El trabajo del Agente ejecutó todas esas tareas en serie. El paquete maestro básicamente dividió las tablas en unidades de procesamiento (5 conjuntos paralelos de tareas serializadas de "ejecutar la tabla replicada 1", la tabla 2, etc.) donde intenté dividir los cubos en unidades de trabajo de tamaño casi igual. Esto permitió que las más o menos 60 tablas de referencia de búsqueda se rellenaran rápidamente y luego el proceso se ralentizó a medida que ingresaba en "
Otras ventajas para mí al usar SSIS es que obtengo configuración "gratuita", registro y acceso a las bibliotecas .NET para datos cuadrados que necesito para hacer un agujero redondo. Creo que puede ser más fácil mantener (pasar el mantenimiento) un paquete SSIS que un enfoque TSQL puro en virtud de la naturaleza gráfica de la bestia.
Como siempre, su kilometraje puede variar.
fuente
Usted mencionó que tiene 200 tablas de origen y 225 bases de datos. Supongo que las 200 tablas de origen son un recuento de todas las tablas de todas las 225 bases de datos (porque si tuviera 200 tablas en cada base de datos, su recuento total de tablas será de 45000). También mencionó que el esquema de la base de datos es el mismo para las 225 bases de datos.
Puede crear primero los paquetes SSIS solo para la base de datos 1 y luego, cuando programe sus trabajos, simplemente puede cambiar la cadena de conexión de la base de datos usando la configuración del paquete (si es su SQL 2005, entonces usará el modelo de implementación del paquete). Como se mencionó en las respuestas anteriores, SQL 2012 tiene nuevas formas de configurar sus parámetros utilizando el modelo de implementación del proyecto.
Puede obtener más información sobre la configuración del paquete con SSIS aquí http://www.sql-server-performance.com/2007/package-configuration-2005/
Puede obtener más información sobre el uso de los parámetros del proyecto desde aquí, /programming/15206184/how-to-configure-ssis-2012-project-to-run-under-different-environment-configurat
fuente