¿Existe un lenguaje / interfaz estándar para ETL programático en SQL Server?

Actualmente estoy en el proceso de crear ETL para nuestro almacén de datos. Estamos usando SSIS 2008, pero nos encontramos con problemas, el mayor de los cuales es la dificultad para reutilizar componentes. Tenemos paquetes separados para cada tabla y cada paquete toma como entrada una serie de variables de un paquete padre. A medida que hacemos cambios en estas variables de entrada, debemos ingresar a cada paquete (tenemos 15 más o menos ahora, pero este número va a crecer significativamente) y modificar el paquete para hacer frente a esos cambios. También hay otros problemas, incluida la imposibilidad de ejecutar SQL arbitrario para nuestra extracción, capacidades de registro deficientes, etc.

Todo este proceso sería mucho más sólido si hubiera una forma de desarrollar nuestros ETL en código, permitiendo la reutilización de código, bibliotecas comunes, mejores pruebas unitarias, etc. ¿Existe un lenguaje / API ETL estándar de facto para SQL Server? Estoy buscando evitar las herramientas GUI tanto como sea posible.

Editar: debo mencionar mi fondo. No soy un DBA y no tengo entrenamiento formal (o informal) de DBA, básicamente he descubierto estas cosas a medida que avanzaba, por lo que es muy probable que esté intentando hacer cosas inapropiadas con SSIS o acercarme a este ETL proyectar desde el ángulo equivocado. Además, actualmente estoy empleado en el gobierno estatal, por lo que cualquier solución que requiera la compra de un nuevo paquete de software no está dentro de lo posible.

Aquí está una de nuestras tareas. Estamos utilizando un único paquete SSIS para cargar cada tabla en nuestro almacén. Cada paquete de hechos y paquete de dimensiones son generalmente iguales, solo difieren en

• Extracciones de la base de datos fuente
• Manipulaciones en un flujo de datos
• Se fusiona con la tabla de destino.

Lo que me gustaría poder hacer (que me resulta difícil hacer en SSIS)

• Cargue la consulta de extracción desde un archivo de texto. Cuando los desarrolladores escriben y prueban sus consultas de extracción, no debería tener que manipular su consulta de ninguna manera antes de que SSIS la ejecute y no debería tener que cortar y pegar la consulta en un objeto de origen de base de datos.
• Pruebe cada componente individualmente. Debería poder probar el proceso ETL completo para una tabla individual aislada, independiente de otras cargas de tabla.
• Realice modificaciones a la lógica compartida en un solo lugar, sin tener que editar cada paquete individual. Cada paquete carga datos en las tablas de auditoría de la misma manera, si quiero cambiar los datos que se cargan auditados, no quiero tener que editar los 15 paquetes (este número será mucho mayor con el tiempo).

Todo el proceso parece que sería mucho más fácil de implementar y más robusto si se realiza programáticamente con el uso adecuado del código compartido.

Hay una herramienta que permite esto: http://www.varigence.com/products/biml.html

Hay una versión comercial, pero también incluimos algunas de las funciones BIML en BIDS Helper, una herramienta gratuita. http://bidshelper.codeplex.com/

Me complace responder cualquier pregunta que pueda tener al respecto.

Esta es una herramienta que proporciona mi empresa.

Al leer esto, inmediatamente pensé en recomendar las herramientas de Varigence. Sin embargo, veo que uno de los principales arquitectos de Varigence, John Welch, llegó aquí antes que yo.

Las herramientas de Varigence son una capa de abstracción sobre SSIS. La ventaja que proporciona es la capacidad de definir "cosas" reutilizables, proporcionando así consistencia en múltiples paquetes. Usted define cómo deben estructurarse los paquetes y cómo difieren de forma individual: los resultados "compilados" de las herramientas de Varigence son paquetes SSIS.

Piense en ello como Dynamic SQL para paquetes SSIS. Con una GUI. Realmente genial.

Intenté usar SSIS varias veces y me di por vencido. En mi opinión, es mucho más fácil hacer todo lo que necesito en C #. SSIS es demasiado complejo, tiene muchas trampas y simplemente no vale la pena. Es mucho mejor dedicar más tiempo a mejorar las habilidades de C # que dedicar el mismo tiempo a aprender SSIS: obtendrá mucho más rendimiento de su entrenamiento. No necesito entrar en muchos detalles aquí: Ayende escribió un gran resumen al que no tengo nada que agregar .

También encontrar y mantener la funcionalidad en una solución VS es mucho más fácil. Las pruebas unitarias con VS son fáciles. Todo lo que necesito hacer es verificar la fuente en Subversion y verificar cómo se cargó. La unidad que prueba los paquetes SSIS está muy involucrada para decirlo suavemente.

Además, hubo situaciones en las que SSIS no pudo llenar silenciosamente algunas columnas en algunas filas, omitiéndolas sin generar excepciones. Pasamos mucho tiempo resolviendo problemas y descubriendo lo que está sucediendo. Desarrollar una solución alternativa en C # tomó menos de una hora y funciona sin problemas durante dos años.

También Rhino ETL parece ser realmente genial.

Hubo algunas discusiones similares sobre stackoverflow .

Personalmente, manejo la mayor parte del proceso ETL posible en SQL. Utilizo SSIS para importar fuentes de datos extrañas como sitios FTP o Excel, pero eso es solo para obtener datos sin procesar en la base de datos donde SQL hace el resto.

Mi situación actual es relativamente simple, ya que la mayoría de los datos se encuentran en otras bases de datos MS SQL, con las cuales puedo configurar servidores vinculados. Si tiene que conectarse a otras plataformas, le recomiendo usar OPENQUERYy BULK INSERT. Se pueden construir mediante programación si es necesario, y entre los dos se pueden conectar a la mayoría de los tipos de datos.

Utilizo SQL porque es lo que mejor sé, pero tiene algunas ventajas objetivas. Lo más notable es que ya se está utilizando: no hay necesidad de aprender o pagar por una nueva herramienta. Es una habilidad ampliamente disponible, que debería importarle a tu jefe si no a ti. Dado que opera en la base de datos, el registro es fácil. Se basa en código de texto plano, por lo que se puede buscar fácilmente y funciona bien con el control de origen. Es muy estable, con muy pocas posibilidades de que el proveedor cambie las cosas y rompa la compatibilidad con versiones anteriores. Probablemente sea al menos tan rápido como cualquier lenguaje RBAR.

Si necesita más, le recomiendo .NET, aunque solo sea porque se usa en SSIS y SQLCLR. Utilizo aplicaciones de C # para administrar el proceso general de ETL: iniciar subpasos, monitorear su salida y enviar correos electrónicos. Pero casi todo esto podría hacerse con el Agente SQL, dbmail, etc.

¿Hay alguna razón por la que no pueda usar SQL para su ETL? ¿Qué no ha podido hacer por ti?