El objetivo principal de una solución de Business Intelligence es permitir la creación de informes que, basándose en objetos visuales para comunicar los datos en los que estamos interesados, faciliten la toma de decisiones. Pero para que esto sea posible nuestro informe deberá mostrar siempre los datos más actualizados de los que se disponga. Y los responsables de esas actualizaciones son los procesos ETL.
Un proceso ETL no es un código que configuramos y se ejecuta una vez. Por el contrario, un proceso ETL puede llegar a ejecutarse decenas de miles de veces durante la vida de un informe. Por ejemplo, si una vez que hemos creado un informe en Power BI Desktop lo publicamos en el Servicio Power BI y lo configuramos de forma que se actualice de forma automática cada media hora, el Servicio Power BI va a ejecutar los procesos ETL asociados 48 veces por día, lo que supondría un total de 17.520 veces cada año. Y en cada una de esas 17.520 ejecuciones el proceso ETL se va a volver a conectar a la fuente de los datos, va a leer la tabla de que se trate y va a aplicar todas y cada una de las transformaciones que hayamos definido.
Esto es lo que permite al destinatario del informe abrirlo y confiar en que los datos que está visualizando tienen una antigüedad máxima de media hora.
Todo esto debería hacernos entender la importancia que tiene la correcta configuración de los procesos ETL. Si -como se ha comentado- cometemos la torpeza de añadir una transformación no deseada y, a continuación, otra que deshaga la anterior, estamos ejecutando dos pasos innecesarios 17.520 veces por año. Y si estamos trabajando con tablas muy grandes, los tiempos de actualización o la memoria consumida pueden aumentar enormemente hasta el punto de provocar errores durante su ejecución.
Lo mismo podríamos decir al respecto del orden en el que añadimos los pasos a los procesos ETL. Por ejemplo, si leemos una tabla con muchos campos pero solo nos interesan unos pocos, lo mejor es eliminar los campos no deseados tan pronto como sea posible.
Además, deberíamos prever posibles situaciones anómalas en los datos que puedan llegar al proceso ETL en alguna actualización futura. Por ejemplo, si en un campo recibimos nombres de países y uno de ellos es “United Kingdom”, si tuviésemos la sospecha de que, en algún momento, podría llegar “UK” (lo que sería interpretado como un nuevo país) deberíamos configurar el proceso ETL para que reemplazase los posibles “UK” por “United Kingdom” aun cuando en el momento de configurar el proceso ETL no exista ningún valor “UK” en los datos.
