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. Split your job in 4 phases: Administration, Starting, Staging, and Operational Data Store
The Administration phase will contain the administrative tables and variables which will contain the auditing information of the job (errors that may occur, notifications when the job starts, monitor if the job has to wait for another one to be executed...). The Starting phase will be for loading data from different sources to our system. In the Staging phase we will perform the required transformations and once completed load the data into your data warehouse in the Operational Data Store phase. We can create an additional phase at the end of our job to create aggregated tables for our different data marts – if required.
b. Always use a standard nomenclature:
An example would be: AA_BBB_CC_DDD_DESCRIPTION
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_SALES_ORDERS
Workflow - WF_FIN_SO_STR_LOAD_SOURCES
Data flow - DF_FIN_SO_STR_LOAD_SAP_SOURCE
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!