¿Deberían los programadores usar SSIS y, de ser así, por qué? [cerrado]

94

Como desarrollador de .NET, ¿por qué debería preferir los paquetes SSIS a la escritura de código? Tenemos un montón de paquetes en producción donde trabajo actualmente, y son una pesadilla tanto para "escribir" (¿quizás dibujar?) Como para mantenerlos. Cada paquete parece un cuenco de espaguetis multicolores con scripts de C # y VB.NET mezclados en los puntos donde se rompen las abstracciones. Para averiguar qué hace cada "Tarea Ejecutar SQL" o "Bucle Foreach", tengo que hacer doble clic en la maldita cosa y navegar a través de un árbol de valores y expresiones literales, dispersos en múltiples pestañas.

Soy de mente abierta, así que me gustaría saber si algún otro buen desarrollador encuentra SSIS más productivo que simplemente escribir código. Si encuentra SSIS más productivo, dígame por qué.

Charles
fuente
4
No sé cómo lo hace, pero SSIS es mucho más rápido que cualquier código manual que haya escrito para crear un almacén de datos. es una herramienta diseñada para el trabajo: intente dividir las tareas en paquetes secundarios que se ejecuten desde un paquete maestro
Mr Shoubs
1
Enlace a una pregunta similar: stackoverflow.com/q/690123/327165
Ilya Berdichevsky
5
Acabo de encontrarme con esto. Estoy trabajando para mantener algunos paquetes SSIS problemáticos y escribí un descompilador para extraer el trabajo útil de ellos en un programa C #. code.google.com/p/csharp-dessist
Ted Spence
5
Desde mi experiencia, SSIS puede ser doloroso si tiene sripts "largos" y / o "complejos" o muchos scripts. Depurar una aplicación de consola es mucho más fácil. En SSIS, no puede depurar su script por sí solo. Los mensajes de error producidos debido a un script son crípticos y no puede ver la línea exacta que causó el error. En mi opinión, si las necesidades del proyecto se pueden satisfacer con componentes SSIS estándar, entonces SSIS podría ser el camino a seguir. Pero, para eso, necesita conocer las limitaciones de los componentes SSIS. Por ejemplo, este video le muestra por qué "enviar tarea de correo" es casi inútil - youtube.com/watch?v=IlUzkMPYDSk
Steam
3
esta pregunta tiene 7 respuestas, por lo que no solicitó debate, argumentos, encuestas ni discusiones extensas. ¿Por qué no dejarlo abierto?
Michael Freidgeim

Respuestas:

94

Uso SSIS todos los días para mantener y administrar un gran almacén de datos y un cubo. He sido 100% inteligencia empresarial y almacenamiento de datos durante dos años. Antes de eso, fui desarrollador de aplicaciones .NET durante 10.

El valor de SSIS es como un motor de flujo de trabajo para mover datos de un lugar a otro con quizás alguna transformación limitada y ramificación condicional en el camino. Si sus paquetes contienen una gran cantidad de secuencias de comandos, entonces su equipo está usando SSIS para las tareas incorrectas o no se siente cómodo con SQL o ha comprado la publicidad. Los paquetes SSIS son muy difíciles de depurar. Los componentes de secuencia de comandos son una pesadilla absoluta y deben usarse solo para formatear, hacer bucles o como último recurso.

  1. Mantenga sus paquetes simples, tareas SQL y tareas de flujo de datos.
  2. Haga todo el trabajo posible fuera de SSIS, preferiblemente en SQL
  3. Mantenga sus variables en un solo alcance global
  4. Mantenga su SQL en variables o procedimientos de almacenamiento, nunca en línea
  5. Mantenga los valores de sus variables en un almacén de configuración, preferiblemente una base de datos SQL
Kevin D. White
fuente
1
Con el problema que tuve con SSIS, habría dado una respuesta más sesgada (como si no pudiera decirlo por la tonalidad de mi pregunta :)). Buena respuesta, Kevin.
Charles
6
¿Cómo trabajó con .NET durante 10 años si se lanzó en 2002?
Brady Holt
7
[cita] Microsoft comenzó el desarrollo de .NET Framework a fines de la década de 1990, originalmente bajo el nombre de Servicios de Windows de próxima generación (NGWS). A finales de 2000 se lanzaron las primeras versiones beta de .NET 1.0 [/ quote] Así es como probablemente estaba trabajando con la beta.
nitefrog
La pregunta fue respondida en 2010, así que quite el BI de dos años, y luego los 10 adicionales, da 1998, dos años antes de la versión beta que menciona. De lo contrario, ¡buena respuesta! :)
finoutlook
Sí, el alcance global tiene sentido. Si lo hace local y desea acceder a él en otro lugar, entonces tiene un problema. No puede simplemente cambiar el alcance de lo local a lo global. Tienes que hacer muchos clics y eliminar en su lugar. Si tienes entre 10 y 15 locales, esto se convierte en un fastidio.
Steam
52

Intenté usar SSIS varias veces y lo abandoné. En mi opinión, es mucho más fácil hacer todo lo que necesito en C #. SSIS es demasiado complejo, tiene demasiadas 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 retorno de su entrenamiento.

Además, encontrar y mantener la funcionalidad en una solución VS es mucho más fácil. La prueba unitaria con VS es fácil. Todo lo que necesito hacer es verificar la fuente en Subversion y verificar cómo se cargó. La prueba unitaria de paquetes SSIS es muy complicada, por decirlo suavemente.

Además, hubo situaciones en las que SSIS no pudo completar silenciosamente algunas columnas en algunas filas, simplemente saltándolas sin generar excepciones. Pasamos mucho tiempo solucionando problemas y averiguando qué estaba pasando. Desarrollar una solución alternativa en C # tomó menos de una hora y funciona sin problemas durante dos años.

Alaska
fuente
Gracias por tus puntos Alex. Aquí hay un ejemplo de lo que creo que podría ser un problema: stackoverflow.com/questions/21616435/… .
Steam
2
¿Existe una lista de todos los temas de programación / C # que un desarrollador ETL DEBE conocer? P.ej. LINQ, SqlDataReader, DataTable, etc. Yo también siento que SSIS no es bueno para tareas complejas. Si tiene un proyecto / tarea fácil de "copiar y pegar", SSIS podría ser la mejor herramienta.
Steam
@blasto, ¿ha probado Rhino ETL ?: ayende.com/blog/3102/rhino-etl-2-0
AK
Alex, la respuesta de Jerome también sugirió Rhino ETL. Me parece oscuro. Por lo tanto, dudaría en usarlo por falta de documentación, soporte y tutoriales. Además, parece que solo un desarrollador está trabajando en ello. Eso disminuye mi confianza en la herramienta. Intentaría esto por diversión o por curiosidad, pero no puedo usar esto para un proyecto real. Gracias.
Steam
Si alguien quiere un tutorial sobre Rhino ETL (con C # puro) aquí hay uno: codeproject.com/Articles/34556/Write-ETL-jobs-in-pure-C
Steam
14

En mi opinión, SSIS es solo para operaciones ETL y no debe contener lógica fuera de ese alcance.

Christoph
fuente
8
ETL = Carga de transformación de extracción
Christoph
3
Así es como me siento. En nuestro caso, usamos SSIS para hacer cosas como CSV de correo electrónico (o SFTP) que contienen información de precios. Las ramificaciones, los scripts incrustados, etc. son bastante horribles. Si solo moviera algunos datos con SSIS, probablemente no sería tan malo.
Charles
1
Creo que tu respuesta podría tener más profundidad.
Steam
3
¿Puede la T en ETL no implicar algo de lógica? Solo un pensamiento ...
cs0815
Si solo está relacionado con dar forma / enrutar los datos, seguro. Pero evitaría cualquier lógica empresarial.
Christoph
11

Tuve la desafortunada experiencia de trabajar en un proyecto en el que pensamos que SSIS sería una solución suficientemente buena para agregar y combinar datos de varias fuentes. Lo desafortunado fue que funcionó muy bien al principio, pero luego los requisitos cambiaron y (eventualmente) nos dimos cuenta de que era la herramienta incorrecta.

tal vez solo lo estábamos usando incorrectamente, pero teníamos muchas dificultades si alguna vez cambiamos nuestro esquema y eventualmente simplemente reutilizamos nuestras definiciones ORM desde la interfaz para escribir una herramienta personalizada en C # para hacer esto. Debido a que ya teníamos el modelo de datos, esto fue sorprendentemente fácil. obviamente, YMMV y yo no somos de ninguna manera un experto en SSIS, pero en este caso SSIS causó muchos trabajos duplicados y dolores de cabeza cuando simplemente arremangarse y codificar a mano fue más fácil de lo esperado.

Así que pensaría mucho en la flexibilidad al considerar SSIS.

lucas
fuente
7
Comparto algunos de los mismos sentimientos. Es fácil refactorizar el código ... no tanto con un DSL visual.
Charles
Luke, ¿podrías darnos un resumen de los requisitos de tu proyecto? Gracias.
Steam
@blasto, estábamos tratando de integrar datos de varias bases de datos y usar algunas de las utilidades de comparación de cadenas probabilísticas integradas para fusionar datos de los diferentes sistemas (esencialmente bases de datos CRM). Fue hace más de 5 años, así que no recuerdo todos los detalles.
Lucas
Si tiene una tienda .net y está involucrado en el movimiento de datos con fines de almacenamiento de datos, SSIS solo lo ayudará si lo conoce lo suficientemente bien. He visto a muchas personas que son gurús de .net pero no entienden completamente SSIS (y no los culpo). Seguro que SSIS requiere una persona que lo conozca lo suficientemente bien, de lo contrario terminará escribiendo paquetes que son ineficientes y no pueden hacer lo correcto.
rvphx
6

SSIS tiene su lugar, y ese lugar no es la programación general o como reemplazo de los procedimientos almacenados. Viene de la escuela ETL (Extraer, Transformar y Cargar) y ahí es donde está su fortaleza.

El nombre antiguo (DTS, Data Transformation Services) y el nuevo nombre (SSIS, Sql Server Integration Services) dejan en claro que es un servicio (o conjunto de servicios) diseñado para manipular datos para integrar la base de datos SQL Server en procesos más grandes.

DaveE
fuente
No veo cómo esta respuesta debería obtener tantos votos a favor. No menciona por qué SSIS no puede darle el poder de un lenguaje de programación. No tiene sentido para mí. Un ejemplo de dónde SSIS no coincide con un idioma de programación es la depuración. Aparentemente, SSIS 2012 cambia eso. Entonces, puede ser, puede que sea, la herramienta está en camino de volverse más amigable para los programadores.
Steam
>> Un ejemplo de SSIS no coincide con un idioma de programación ... Estoy de acuerdo, no es un lenguaje de programación. Es una herramienta ETL decente.
DaveE
4

Si desea mover sus datos mediante programación, es posible que desee mirar Rhino ETL.

También estoy trabajando en mi propio marco, Fluent ETL , ya que SSIS me parece un poco complicado para tareas de datos simples relacionadas con el desarrollo, como cargar datos de prueba unitaria desde un archivo CSV.

Jerome
fuente
Rhino ETL es oscuro y solo tiene 24 preguntas sobre SO a partir de ahora - stackoverflow.com/questions/tagged/rhino-etl . Creo que C # sería lo suficientemente bueno para ETL, si tiene el conocimiento y la experiencia.
Steam
1
¿Existen alternativas populares a Rhino ETL?
Steam
3

SSIS no es un programa. Muchas cosas son más rápidas de hacer en SSIS, y obtienes información muy detallada sobre el progreso y los errores como administrador, lo que puede ser muy bueno en los escenarios que SSIS debe resolver, porque a veces las cosas salen mal y el administrador necesita mucho información.

Habiendo dicho eso, SSIS no es realmente tan útil si no tienes las cosas auto-explicativas - están destinadas a algo, meterse demasiado en la programación general las hace una mierda.

TomTom
fuente
2
¿Puede darnos un ejemplo de cómo SSIS puede acelerar el desarrollo en un escenario y ralentizar en los demás?
Steam