ETL Diseño y rendimiento del procesamiento

Question

Estoy trabajando en un proceso ETL para un almacén de datos que utiliza C#, que admite SQL Server y Oracle. Durante el desarrollo, he estado escribiendo procedimientos almacenados que sincronizarían datos de una base de datos a otra. El código de procedimientos almacenados es bastante feo porque involucra SQL dinámico. Necesita construir cadenas de SQL ya que tenemos un nombre de base de datos dinámico.

Mi jefe de equipo quiere utilizar el código C# para hacer el ETL. Tenemos generación de código que genera automáticamente nuevas clases cuando cambia la definición de la base de datos. Esa también es la razón por la que decidí no usar Rhino ETL.

Éstos son los pros y los contras:

procedimiento almacenado:

Pros:

• rápido proceso de carga, todo es manejado por la base de datos
• despliegue fácil, se necesita ninguna compilación

Contras

• sea difícil de leer debido a la dinámica de SQL
• necesidad de mantener tanto T-SQL y secuencias de comandos PL/SQL cuando definición de base de datos cambia
• Desarrollo lento porque hay intelisense al escribir SQL dinámico

C# Código :

Pros:

• más fácil de desarrollar el proceso de ETL porque tenemos intellisense de nuestra clase generada
• más fácil de mantener debido a la clase generada
• mejor registro y control de errores

Contras:

• rendimiento lento comparar con el procedimiento almacenado

Preferiría usar el código de la aplicación para hacer el proceso ETL, pero el perf ormance era horrible comparar con los procedimientos almacenados. En una prueba cuando intento actualizar 10.000 filas. Los procedimientos almacenados tomaron solo 1 segundo, mientras que mi código ETL tardó 70 segundos. Incluso de alguna manera logré reducir la sobrecarga, el 20% de los 70 están llamando puramente a la declaración de actualización desde el código de la aplicación.

¿Podría alguien darme sugerencias o comentar cómo acelerar el proceso de ETL utilizando el código de la aplicación?

Mi siguiente idea es intentar hacer un proceso ETL paralelo abriendo múltiples conexiones de bases de datos y realizar la actualización e inserción.

Gracias

Answer 1

Usted dice que tiene la generación de código que genera automáticamente nuevas clases - ¿Por qué no tiene generación de código que generan automáticamente los nuevos procedimientos almacenados?

Eso debería darte lo mejor de dos mundos; encapsularlo en unas pocas clases agradables que puedan inspeccionar la base de datos y actualizar cosas según sea necesario y puede, así no aumentar la legibilidad, pero ocultarlo (no necesitaría actualizar los SP manualmente)

Además, la diferencia no debería ser tan grande, suena como si no estuvieras haciendo algo bien (reutilizando conexiones, moviendo datos innecesarios del servidor a la aplicación o procesando datos en lotes más pequeños, ¿fila por fila?).

Además, en lo que respecta a una mejor explotación forestal, ¿es necesario profundizar en eso? También puede iniciar sesión en la capa de la base de datos, o puede diseñar sus SP para que la capa de la aplicación pueda hacer el registro.

Answer 2

Puede considerar actualizar su aplicación.

Algunos trucos de la mina:

• No utilice connection.Open() y conenction.Close() demasiado.
• Im algunos casos LINQ se ralentizar las cosas
• utilizar un procedimiento y pasar más parámetros al cargar a reducir el número de llamadas, por ejemplo, proc_load_to_table(p1 text) cambio a proc_load_to_table(p1 text, p2 text, p3 text, p4 tex, p5 text)

Answer 3

Si su código C# ya es lento con 10.000 filas, no puedo imaginarlo en un entorno real ...

La mayoría de los ETL se realizan dentro de la base de datos (stored procedures, paquetes o incluso compilados dentro de la base de datos (PL/SQL, Java para Oracle)). Pueden manejar millones de filas.

O se pueden utilizar algunas herramientas profesionales (Informatica u otras), pero seguirá siendo más lento que los procedimientos almacenados, pero más fácil de administrar.

Así que mi conclusión es: si quiere acercarse a las actuaciones de procedimientos almacenados, tendrá que codificar una aplicación tan buena como las profesionales en el mercado, que tardó años en desarrollarse y madurar ... ¿Usted ¿Crees que puedes?

Además, si tiene que manejar diferentes tipos de bases de datos (SQL Server, Oracle), NO PUEDE hacer una aplicación genérica Y optimizarla al mismo tiempo, es una opción. Porque Oracle no funciona de la misma forma que el servidor SQL  .

Para que tenga una idea, en ETL para Oracle, se utilizan sugerencias (como las sugerencias de Ejecución en paralelo), y también algunos índices pueden perderse o la integridad deshabilitarse temporalmente para optimizar el ETL.

No hay forma de que yo sepa exactamente lo mismo en SQL   Server (pueden tener opciones similares, pero sintaxis diferente). Entonces, "un ETL para todas las bases de datos" difícilmente se puede hacer sin perder eficiencia y velocidad.

Así que creo que sus pros y contras son muy precisos; debe elegir entre velocidad y facilidad de desarrollo, pero no ambos.