Evite escribir consultas SQL por completo en SSIS

Question

Trabajando en un proyecto de Data Warehouse, el tipo que nos dio el tutorial nos recomendó que usemos consultas SQL para definir una gran cantidad de transformaciones de flujo de datos, citando puntos como que va a consumir mucho de memoria en el cuadro de ETL, así que preferimos dejar el procesamiento en el cuadro de DB. ¿Es esto realmente recomendable? ¿Dónde está el equilibrio entre confiar en las herramientas de GUI sobre la ejecución de un conjunto de scripts SQL en su paquete de Integración?

Y, sinceramente, me gustaría evitar escribir consultas SQL tanto como pueda. (pero eso no viene al caso. Realmente me gustaría ver esto objetivamente.)

Answer 1

La respuesta es: depende, pero desea escoger uno u otro para un trabajo determinado y evitar mezclar los dos cuando sea posible.

En general, es mejor hacer todo lo posible dentro de la herramienta o hacer todo lo posible dentro del código de procedimiento almacenado. Cuando tiene cantidades significativas de lógica dividida entre capas, el sistema se vuelve más difícil de rastrear y depurar.

• Cuando la herramienta puede hacer las transformaciones sin los flujos de datos convertirse torpe y contorneado se puede utilizar la herramienta y tratar de tener poca o ninguna lógica en las consultas. Esto significa que una sola capa tiene la lógica comercial y debería ser bastante obvio dónde encontrarla. Sin embargo, las herramientas de ETL tienden a manejar transformaciones altamente complejas relativamente mal. El punto ideal para este tipo de enfoque es en los sistemas donde tiene una gran cantidad de fuentes de datos pero transformaciones relativamente simples.

• Si tiene transformaciones relativamente complejas, es mejor que ponga toda la lógica de negocios y la transformación en una capa de procedimientos almacenados. El código SQL es mejor para implementar transformaciones complejas de una manera sostenible. Tengo bastante buena autoridad de que alrededor de la mitad de todos los proyectos de almacenamiento de datos en los sectores bancario y de seguros usan este tipo de arquitectura precisamente por esa razón.
  
  En este caso, la herramienta ETL se puede utilizar para implementar copias de datos relativamente tontas. Los datos de origen pueden copiarse en áreas de escenificación esencialmente al pie de la letra y luego recogidos por un cuerpo de código de procedimiento almacenado que hace el ETL. La herramienta ETL se puede utilizar para copias de datos, operaciones de carga masiva, registro, programación y otras tareas de marco.

En cualquier caso, es mejor elegir un enfoque. De lo contrario, puede terminar con la lógica de negocios repartida entre capas de extracción, vistas de bases de datos, flujos de datos y código de procedimiento almacenado. La propagación lógica a través de múltiples capas es mucho más difícil de probar.

Cuando toda la lógica está (por ejemplo) contenida en los procedimientos almacenados o en los trabajos de transformación ETL enfocados, puede probar de forma aislada una transformación determinada. La claridad en el diseño también ayuda con el mantenimiento y la auditoría.

Answer 2

Creo que esta es una pregunta difícil; y uno interesante también.

Una razón para utilizar SSIS es mejorar el mantenimiento, en mi humilde opinión. Si empaqueta toda la lógica en las sentencias de SQL (¡y de eso se puede estar seguro!) En primer lugar, tiende a arruinar esta razón de usar SSIS. Realmente no se puede "ver el flujo de datos" más.

Por otro lado, creo que hay momentos en que una declaración SQL bien colocada tiene su valor. Por ejemplo, cuando lee datos de una tabla y por cualquier razón ya sabe, solo necesitará que las filas cumplan con la condición X. No veo el motivo para leer toda la tabla y en el paso siguiente "dividir condicional la mayor parte de ella".
Lo que no sé es lo que esto significa en términos de rendimiento, por cierto. ¿Es SSIS lo suficientemente inteligente como para ver lo que está sucediendo y cambiar "read-whole-table-and-conditional-split-it" en un "select Y from where X" sobre la marcha (o al construir/desplegar)?

La gran pregunta es dónde trazar la línea. Y esto depende en cierta medida de las personas que trabajan en su proceso de ETL. Si todos los que apoyan el proceso conocen SQL desde su inicio, pueden soportar mejor una cantidad mayor de SQL en su ETL que si tienen compañeros de trabajo (o clientes o sucesores que les importan) que apenas entienden lo que está sucediendo en todos sus SQL. , y mucho menos cambiar/mejorar/agregar a ella.

Así que creo que la conclusión es que ni usar ni hacer todo en SQL es mejor. Intente inventar algunas reglas simples que se ajusten a sus requisitos y con las que todos puedan vivir, luego síguelos. Esto le compra el mayor valor de usar SSIS.

Answer 3

Generalmente, cuando desee procesar cada fila individualmente, utilice un flujo de datos; de lo contrario, puede ser mejor utilizar un comando Sql.

Personalmente, me gustaría escribir el SQL donde pueda. Es más fácil optimizarlo más tarde y (generalmente) más rápido también. Google dará respuestas mucho más detalladas.

Otro factor a considerar es el proveedor que utiliza para sus conexiones.

Debe tomar la decisión según sus necesidades. Usamos Postgres DB, por lo que tenemos que crear una carga de tablas de etapas para algunos procesos, lo que acelera todo.

También debe tener en cuenta la caja en la que se está ejecutando, si tiene un cuadro de DB todo poderoso y un pequeño recuadro de ETL, no tendría sentido ejecutar nada.

Si hace todo el procesamiento en el cuadro ETL, también estará arrastrando una gran cantidad de datos a través de la red.

visita estos links para empezar:

ssistalk.com/categoría/SSIS/ssis-avanzadas-técnicas/

msdn.microsoft.com/en-us/library/ms141031.aspx

weblogs.sqlteam.com/jamesn/Default.aspx

Answer 4

Me parece que usar el código SQl no solo es más rápido de ejecutar, sino que es más rápido de desarrollar y mucho más fácil de mantener.

Answer 5

SQL Server hace bien algunas cosas y otras no tan bien. Uso SSIS para importar o exportar datos de SQL Server. Durante el curso del movimiento, uso SSIS donde tiene sentido. Puedo trabajar fácilmente por fila, lo cual no es muy eficiente en SQL Server (cursores). Decir que no debe usar transformaciones y flujos de datos en un cuadro de ETL, porque es demasiado caro en el cuadro de ETL es como decir 'no conduzca su automóvil demasiado rápido, porque hace que el motor funcione'. El propósito de un ETL y SSIS es tomar parte del procesamiento que SQL Sever no hace bien y moverlo a un motor que sí lo hace.

Answer 6

Tengo que usar la herramienta adecuada para el trabajo. En general, haces la mayoría de las cosas en SSIS, con ciertas cosas hechas en SQL "puro".

Por ejemplo, en los casos en los que realiza una gran ACTUALIZACIÓN (diferencia de tabla en la tabla de dimensiones en un modelo dimensional, por ejemplo), realmente no desea ejecutar una ACTUALIZACIÓN para cada fila.En este escenario, realiza una inserción regular en una tabla temporal y luego realiza la ACTUALIZACIÓN en SQL, uniéndose a las claves apropiadas.