Si puedo hacer los requisitos de ETL requeridos usando procedimientos almacenados, ¿tiene alguna ventaja de usar paquetes de SSIS? Mi material de ETL no es nada importante.Ventajas de usar paquetes de SSIS sobre procedimientos almacenados?
Tengo ganas de usar una tecnología antigua. Me gusta SQL. La tecnología antigua no es obsoleta ya que los procedimientos almacenados no desaparecerán en el corto plazo.
Si su ETL es en su mayoría E y L, con muy poco T, y si se puede escribir sus productos especiales para que no se basan en los cursores, y luego tomar la ruta SP sólo es probablemente muy bien.
Para procesos más complejos, en particular los que implican transformaciones pesados, que cambia lentamente dimensiones, las búsquedas de minería de datos, etc, SSIS tiene tres ventajas.
primer lugar, se administra la memoria de manera muy eficiente, lo que puede dar lugar a grandes mejoras en el rendimiento en comparación con el T-SQL solo.
En segundo lugar, la interfaz gráfica le permite crear transformaciones grandes, complejas y confiables mucho más fácilmente que T-SQL hecho a mano.
Y en tercer lugar, SSIS le permite interactuar más fácilmente con fuentes externas adicionales, que pueden ser muy útiles para cosas como la limpieza de datos.
No veo ninguna limitación técnica obvia. El procedimiento almacenado puede ser más difícil de seguir que un paquete SSIS para operaciones complejas de ETL, pero eso no será cierto en todos los escenarios. También descubrí que los paquetes (SSIS y DTS) se reconocen más fácilmente como "trabajos": los desarrolladores suelen ignorar los procedimientos almacenados que se ejecutan mediante trabajos programados porque no pueden ver los trabajos programados.
Dicho esto, he visto ETL realizado por procedimientos almacenados y paquetes DTS/SSIS por igual y siempre que el procedimiento almacenado no sea un gran lío de código enmarañado, parece apropiado. No he visto que un método funcione mejor o más confiablemente que otro (pero luego no he visto procedimientos almacenados haciendo ETL complejo).
Yo diría que depende un poco de lo que está haciendo. Sin embargo, según mi experiencia, la posibilidad de mejorar con los paquetes de SSIS es tremenda. Vimos mejoras de 10 veces en nuestro entorno de almacenamiento de datos cuando tomamos algunos de los procedimientos almacenados de gran impacto y los pusimos en paquetes de SSIS. La utilización de la memoria de SSIS (en esta situación de todos modos) hizo toda la diferencia.
Quiero reiterar que es importante saber lo que está haciendo. Por ejemplo, una declaración de SQL generalmente superará un flujo de datos de SSIS cuando la transformación de datos es de tabla a tabla en el mismo servidor.
La mejor opción es escoger un SP o dos y crearlos en SSIS y probarlos a ambos.
que parece ser la respuesta para todas las preguntas comienzan con SQL, Depende ...
estoy de acuerdo aquí - si su procedimiento almacenado ETL está tomando demasiado tiempo entonces usted desea considerar SSIS como alternativa por razones de rendimiento (es decir, más de unos pocos minutos?). :) – Mayo
que rara vez se encuentran SSIS superando a un procedimiento almacenado correctamente escrita. Por ejemplo, el inútil componente SCD en SSIS toma 20 minutos para hacer lo que se puede hacer en segundos en un procedimiento almacenado. Sin embargo, a algunas personas les puede gustar el aspecto de asistente. –
He intentado algunas de las características en SSIS y que no estaba contento con todos ellos. Decidí desactivar el flujo de datos y no estaba muy contento con el rendimiento que vi. Lo que terminé haciendo fue desarrollar un paquete de SSIS que tenía un flujo de control de tarea sql, cada uno de los cuales ejecutó un proceso almacenado.
Esto aseguró que el servidor SQL hizo la mayor parte de E, T y L. Creo que cuando utiliza el componente de flujo de datos, los datos realmente se mueven desde el servidor sql a la máquina ejecutando el paquete que hace que no sea tan eficiente.
Habiendo dicho eso, creo que habría intentado optimizar la cuestión de Dataflow (ha pasado un tiempo desde que trabajé en ella) si tuviera que interactuar con aplicaciones/bases de datos/sistemas de DW de terceros.
he vivido en la tierra de ETL procedimiento almacenado para un almacén de datos de SQL Server de varios terabytes. Esta decisión se tomó en 2001 cuando .NET era 1.0, por lo que VB6 era la alternativa del lenguaje de programación, y SSIS aún no existía: era DTS. Puedo decirte que hubo ventajas y desventajas, como cualquier otra cosa.
Algunas consideraciones:
BTW - después de salir de esa empresa, finalmente actualizaron la base de datos de SQL 2000 a 2008 y lentamente pasaron de los procesos almacenados a SSIS. En mi nueva compañía, somos propietarios de SSIS pero después de usarlo, todos acordamos que nuestro ETL .NET escrito a medida es más adecuado para nuestros propósitos. Todos toman su propia ruta. La decisión tiene que equilibrar el mantenimiento y el rendimiento y el conjunto de habilidades de su equipo y el conjunto de habilidades del grupo de trabajos en su área.
estoy trabajando en mi primer trabajo profesional y estoy tratando con el equilibrio de los procedimientos almacenados y ssis. Y estoy experimentando cada una de estas consideraciones. – eddiecubed
El rendimiento será más rápido de lo normal sp. No es necesario crear tablas temporales complejas, Cursor, indexación para recuperar datos.
de limpieza de datos es ventaja de SSIS.
El manejo incremental solo es posible en ssis.
Podemos crear el archivo de configuración del paquete y desplegarlo en cualquier servidor. El usuario puede proporcionar los detalles del servidor y la información de inicio de sesión.
Interfaz gráfica de usuario.
registro, gestión de errores es mejor en SSIS.
No estoy de acuerdo con todos estos puntos. ¿Qué te hace pensar que solo puedes hacer cargas incrementales en SSIS? –
SSIS hace falta alguna funcionalidad básica, que no tiene un paquete del tipo de Informatica que permita el desarrollo de una instrucción SQL para ejecutar en archivos de texto primas y del servidor SQL profundamente carece de diagnósticos del sistema LMD como Oracle. Realmente pensé cuando Microsoft anunció la adición de la declaración Merge que, por supuesto, implementarían el cubo de error, que es una de sus características más importantes, así que adivine de nuevo. El procesamiento de errores en el nivel de línea es importante y si está utilizando una instrucción SQL para agregar lotes de datos si falla un registro, se revierte todo el lote.
He visto algunas mejoras tremenosas en el rendimiento al utilizar SSIS, es especialmente bueno si tiene procedimientos almacenados que utilizan servidores vinculados, ya que esto consume más potencia de procesamiento y los servidores vinculados tienden a pasar toda la tabla a la memoria antes de limitar el filas necesarias para una unión. Teníamos un procedimiento almacenado que tardaba más de 7 horas en ejecutarse, lo dividí en datos de cada servidor y luego establecí un origen de datos local para cada uno en SSIS, lo que permite que el procesamiento se realice localmente para cada fuente de datos como apposed a través del servidor vinculado. el trabajo ahora tarda 6 minutos en ejecutarse, yo diría que es una ganancia enorme.
Caralyn
Estamos método combinado usign para conseguir lo mejor de dos mundos: Utilizamos SSIS para obtener datos de fuentes externas y cargarlo en paralelo en base de datos provisional A continuación, utilizar paquetes SSIS para orquestar las tuberías y el gatillo apropiados SP dentro del flujo de control.
Cualquier lógica de transformación se incaplulated en SP como flujos de datos son difíciles de manejar/modificar y no da ninguna ventaja significativa: 1) Es más fácil de modificar y solucionar problemas de SP que un paquete 2) No hay manera de facilidad reutilizar componentes en SSIS excepto llamar a paquetes externos 3) SVN diff de SP funciona, diff del paquete SSIS es horrible :)
Además, usamos SSIS para ejecutar SP en paralelo para aumentar el rendimiento general.
Estoy en el medio de deshacerse de nuestros paquetes de SSIS y el uso de procedimientos almacenados. Para nosotros, los procesos almacenados son tremendamente mejores: 1) Son mucho más fáciles de mantener, no necesitamos ofertas, no necesitamos crear proyectos e importar paquetes a las ofertas, por lo tanto hay menos pasos para realizar simples cambios de proceso almacenados. 2) Todos nuestros paquetes actuales básicamente truncan datos en una tabla, y luego vuelven a llenar desde otras tablas en el mismo servidor con asignaciones directas. Muy fácil Insertar/seleccionar SQL para escribir. 3) Se ejecutan mucho más rápido. No tenemos cursores, estructuras sin bucles, solo SQL directo. 4) No tenemos que gastar todo nuestro tiempo haciendo clic derecho y trabajando en pequeñas ventanas tratando de seguir el flujo de la lógica. Todos conocemos el TSQL básico y eso es suficiente para nuestras tareas.
Para proyectos pequeños, si tiene habilidades sólidas de sql y una comprensión de los requisitos comerciales, ¡adelante!
De lo contrario, si se enfrenta a la extracción de datos complejos, las tareas de transformación pesadas. SSIS u otra herramienta ETL será suficiente.
aplausos
Para las transferencias de datos entre servidores SQL utilizan SSIS por encima de los SP Puede enfrentar fácilmente una mejora del factor 10 como se mencionó anteriormente Pasamos de 6-7 horas transferencias a un marco de tiempo más manejable mediante la incorporación de la SP en un paquete SSIS
en una nota: SSIS es básicamente un montón de archivos XML que pueden ser utilizados manipulan/de diferentes maneras (por ejemplo, para la documentación)
he estado trabajando con SQL Server desde la versión 6.5 - ¡Eso es un largo tiempo! Y desde mi experiencia más ETL es bastante simple que funciona de T-SQL funciona perfectamente bien y no sólo, pero funciona muy bien - rápido, programación estructurada fiable, sencilla. Creo que cualquier cosa que se pueda hacer en SSIS se puede hacer en T-SQL por alguien que sepa lo que están haciendo.
La mayoría de las personas que están a favor de la pesada SSIS, de nuevo en mi experiencia, son los desarrolladores inexpertos que han crecido con herramientas gráficas y realmente no saben programar.
Yo sólo uso de SSIS si va a mover los datos de una instancia a otra, o si desea que su ETL de escalar fácilmente de esa manera. Si está haciendo ETL en diferentes bases de datos en la misma instancia, lo mantendría simple y usaría T-SQL. Principalmente uso SSIS como un motor de flujo de trabajo para mover datos de un lugar a otro y luego llamar a los procedimientos de T-SQL. –