Cuando se trata del desarrollo ETL (extraer, transformar y cargar), el rendimiento óptimo y la escalabilidad son claves. En este artículo, os presentamos las 5 mejores prácticas de Clariba act·in | ETL Framework para lograr esta meta.
1. Estructurar es clave
A lo largo de mi carrera, he visto muchos procesos ETL y una de las cosas que me preocupaba más era que los proceso ETL no tenían una estructura. Cuando se utiliza una solución ETL como la de SAP Data Services, se pueden generar tantos Workflows y Dataflows como se requiera, ¡así que utilizadlos!
Es fácil desarrollar procesos con unos pocos Dataflows con mucha lógica. Sin embargo, estos procesos son muy difíciles de mantener y de ampliar en el momento en que los desarrolladores tengan que hacer alguna modificación en el futuro. Por ello, antes de poneros manos a la obra con vuestra ETL pensad en las posibles modificaciones que podrían requerirse.
Tal y como definimos en nuestro Clariba act·in | ETL Framework, recomendamos seguir estos simples pasos para asegurar las mejores prácticas en la estructura ETL.
a. Divide tu trabajo en 4 etapas: Administración (Admin - ADM), Inicio (Starting - STR), Montaje (Staging - STG) y Almacén Operacional de Datos (Operational Datastore - ODS)
La fase de Administración contendrá las tablas administrativas y variables que contendrán la información de auditoría del Job (errores que podrían ocurrir, notificaciones al inicio del proceso, monitorear si el proceso tiene que esperar a que otro sea ejecutado...). En la etapa de Inicio se cargarán datos de diferentes orígenes de datos de nuestro sistema. En la etapa de Montaje realizaremos las transformaciones necesarias y, una vez completado esto, ejecutaremos la etapa de Almacén Operacional de Datos y cargaremos los datos en el Datawarehouse. Podemos crear una etapa adicional al final de nuestro job para crear tablas agregadas para nuestros diferentes data marts si se requiere.
b. Utiliza una nomenclatura estándar:
Un ejemplo de formato recomendado sería: AA_BBB_CC_DDD_DESCRIPCIÓN
AA es el tipo de objeto. Por ejemplo, BJ - Batch Job (tareas de procesamiento por lotes), DF - Dataflow, WF - Workflow, AF - Abap Data flow
BBB es el Datamart en el cual estamos trabajando. Por ejemplo, FIN - Finanzas, PRO - Producto
CC es el acrónimo del Job
DDD se referirá a la etapa en la cual estamos. Por ejemplo, ADM - Administración, STR - Inicio, STG - Montaje, ODS - Almacén de Datos Operacionales
Finalmente, usa una breve descripción de concepto para indicar lo que el objeto está realizando (puedes usar cajas de texto adentro para añadir más información).
Aquí encontraréis algunos ejemplos:
Job - BJ_FIN_SO_VENTAS_ORDENES
Workflow - WF_FIN_SO_STR_CARGAR_FUENTES
Data flow - DF_FIN_SO_STR_CARGAR_SAP_FUENTE
Finalmente, si habéis hecho el esfuerzo de seguir los ejemplos anteriores, os animaría a que también apliquéis una nomenclatura a vuestras consultas y tablas usando los consejos previamente explicados.
Como podremos comprobar, este punto es muy útil cuando buscamos objetos específicos en la librería de objetos central o local ya que estos están ordenados alfabéticamente.
2. Paralelizar
Uno de los potenciadores de rendimiento clave de SAP Data Services es la paralelización. Cuando se usa correctamente, ¡mejoran mucho el tiempo de ejecución de los jobs! Sin embargo, se debe utilizar esta capacidad con cuidado. Solamente se debe utilizar el paralelismo cuando tiene sentido el hacerlo, por ejemplo, si un Dataflow es dependiente de otro, no tiene sentido ejecutarlos en paralelo.
Ejemplo de Dataflows trabajando en paralelo:
Ejemplo de Workflows ejecutándose en serie:
3. Optimizar mediante procesamiento de tipo pushdown (delegar)
Este tema, junto con la paralelización, es muy efectivo para mejorar los tiempos de ejecución. La idea es aprovechar el poder del motor de la base de datos. Esto significa que la lógica aplicada a nuestros Dataflows es delegada a la base de datos en lugar de al servidor de Job server.
Sin embargo, todo tiene un coste y el pushdown no es la excepción. En este caso, se necesita realizar investigación intensiva para saber qué funciones en SAP Data Services pueden ser delegadas a nuestra base de datos y esto aumentará la complejidad de nuestro Job. Pero creedme, el esfuerzo vale cada hora invertida. Por suerte, ¡hay muchos más blogs que cubren este tema de forma más extensa!
Así que ¿cómo podemos verificar si el proceso de nuestro Dataflow está siendo delegado a la base de datos? ¡Fácil! Dentro del Dataflow que queríais chequear, seleccionad la pestaña Validation -> Display Optimized SQL. Aparecerá un Pop-up. Si el código generado es SQL con solo un SELECT, entonces desafortunadamente vuestro flujo de datos no está delegando el código. Sin embargo, si se muestan INSERTS, UPDATES, MERGE, UPSERT, ETC entonces, ¡felicidades, habéis delegado vuestras transformaciones con éxito!
Os presentamos dos ejemplos con el mismo flujo de datos, uno con procesamiento de tipo pushdown y, el otro, sin él.
Flujo de Datos con pushdown
Flujo de Datos sin pushdown
4. Minimizar el uso de scripts para transformaciones
Los scripts son geniales cuando se trata de la inicialización de las variables y de aplicar la lógica a nuestras tareas. Sin embargo, usar scripts para transformaciones en ETL es una práctica buena práctica. Os sugerimos evitar esta práctica tanto como sea posible ya que los scripts no son fáciles de rastrear.
Imaginad un Job muy complejo con muchos scripts y flujos que insertan/actualizan/borran una tabla de hechos o una tabla de dimensiones. Si obtenemos un error de ejecución, el hecho de usar scripts hará que no sea fácil encontrar donde está el error ya que SAP Data Services solamente muestran la línea de código con el error y no dónde se encuentra el error en el Job.
Además, pensadlo de esta manera: si estáis usando una herramienta ETL, ¡aprovechad sus capacidades! Una de sus funciones principales es la habilidad de simplificar y mantener una lógica compleja al dividirla y organizarla en Workflows y Dataflows.
5. Utilizar tablas manuales para la parametrización
Nuestro último consejo sobre las mejores prácticas para mantener tareas fácilmente es utilizar tablas manuales para la parametrización.
Supongamos que en muchas de vuestras tareas estáis usando filtros estándar y la función “decode”. Si uno de estos filtros decodes cambia, ¡tendréis que cambiarlos manualmente en todas partes! Eso crea un trabajo adicional engorroso donde pueden cometerse errores manuales fácilmente.
Por lo tanto, os sugerimos que intentéis siempre aplicar este consejo. ¡Os ahorrareis todo el trabajo descrito anteriormente con update!
Ejemplo de una tabla manual usada como filtro
Naturalmente, hay muchas más prácticas que recomendamos como parte de nuestro Clariba act·in | ETL Framework. Esperamos que nuestro artículo os haya dado nuevos conocimientos ¡Y esperamos leer vuestros comentarios!