Transformaciones PowerCenter, Activas

BI Geek / Business Intelligence  / Transformaciones PowerCenter, Activas
bigeek_blog_720

Transformaciones PowerCenter, Activas

Continuamos en esta entrada profundizando en las características de las principales transformaciones activas. Siempre desde el punto de vista de la volumetría, se analizan las excepciones que confirman la regla, y se recomiendan buenas prácticas de uso que nos ayudarán a conseguir mejores desarrollos y a entender el funcionamiento de PowerCenter.

En cualquier proceso encontraremos sin duda, alguno de los siguientes elementos:

  • Aggregator

Obligatoria cuando se deben realizar sumas, medias, ponderaciones, máximos o mínimos, etc. Mediante la opción Group by establecemos los campos que conformarán la clave de agregación. Debemos también crear los campos de salida que realizarán la operación necesaria (SUM, MAX, MIN, etc) sobre los campos de entrada, generalmente importes, tasas, ratings o fechas.

Según esto, es obvio decir que si existen varios registros con la misma clave de agregación, se agregarán en uno único que contendrá los cálculos realizados para esa clave. Vemos de esta manera como el flujo es susceptible de sufrir un cambio, y en el caso del agregador, este será siempre una disminución.

El aggregator o agregador se utiliza también para contar los registros que tiene un flujo de información. Para esto, basta con NO agregar por ninguna clave y crear un campo de salida con la operación COUNT(1). De esta manera, el agregador contará todos los registros y devolverá una sola fila con el número total de registros que ha procesado.

Esta operativa se suele realizar para monitorización de errores, donde hay que ofrecer estadísticas y detalles de la ejecución, por ejemplo, registros procesados, registros rechazados, registros correctos, etc.


  • Filter

Como su propio nombre indica, esta transformación se utiliza para filtrar o rechazar un determinado flujo de información en base a una o varias condiciones.

Se trata de una transformación muy sencilla en la que únicamente tenemos que determinar el filtro, formado por condiciones de sus campos, que determinará que registros son válidos. Esto se configura en la cláusula Filter Condition dentro de Properties.

De igual manera a como sucede con el aggregator,  la volumetría de salida será siempre menor, reduciéndose esta en la medida en que los registros no cumplan las condiciones del filtro.

Como buena práctica y con el fin de mejorar el rendimiento se recomienda, en el caso de condiciones complejas, realizar el cálculo en una expression y crear una variable dicotómica (1,0) que será la usada en el filtro para determinar si el registro es válido o no.

Cuando necesitemos separar dos flujos de información válidos con condiciones distintas, pasaremos a utilizar un router en lugar de dos filtros (se detalla el mismo más adelante).


  • Joiner

Para atender a una explicación detallada del funcionamiento del joiner, podemos dirigirnos al capítulo correspondiente sobre esta transformación.

Como ya se ha explicado anteriormente, esta transformación se utiliza para realizar cruces de datos entre diferentes flujos de información. Siguiendo el interés que persigue este artículo, cabe destacar que un joiner siempre puede suponer una variación de volumetría, positiva o negativa, independientemente del tipo de joiner que decidamos utilizar para satisfacer el requerimiento.

Con el objetivo de conseguir resultados consistentes y mejorar la eficiencia en los desarrollos, resulta crucial evitar el duplicado indeseado de registros. Para ello, debemos prestar especial atención a los campos de cruce, puesto que estos deben garantizar la unicidad de los flujos que se van a relacionar.

 

  • Rank

Habitualmente en un segundo plano tras el agregador, sería injusto obviar las importantes alternativas que ofrece respecto al primero. Utilizado también para realizar agregaciones (marcaremos los campos claves en la agregación mediante Group by), permite recuperar uno o varios registros, con todas sus variables, que respondan al máximo o mínimo de uno de sus campos, el cual determinaremos como campo Rank. Por el contrario, esta transformación no permite realizar cálculos, del tipo que sea, a partir de campos input.

Es decir, en una agregación recuperaremos un único registro por clave de agregación, y si deseamos recuperar a la salida algún campo que no sea clave, deberemos realizar sobre el mismo alguna operación, la que se adapte al requisito, puesto que si no perderíamos coherencia en el dato.

Sin embargo, con rank podemos agregar por la misma clave y recuperar por ejemplo, los tres registros con la fecha de entrada más reciente. No podemos realizar una suma o una ponderación, como tampoco se puede utilizar más de un campo Rank. Esta transformación provocará, al igual que su homóloga, una disminución en la volumetría. Puede resultar de gran utilidad cuando tenemos flujos historificables y debemos recuperar, para un determinado Contrato u Operación, el registro más reciente o el de mayor o menor saldo.

Vemos por tanto, como incluso con funcionalidades similares, encontraremos casos de aplicación en los que rank resolverá de manera más sencilla y eficiente aquello que el agregador no puede de manera natural.


  • Router

Como se ha avanzado anteriormente, el router resulta imprescindible cuando tenemos que separar un conjunto de datos en subconjuntos para aplicar un tratamiento diferente a cada uno de ellos. Por ejemplo, en función del campo País, cada registro debe cargarse en un target o destino diferente.

Los casos prácticos que pueden llevar a la utilización de esta transformación pueden ser muy variados, desde realizar cruces o agregaciones para un determinado subconjunto de datos que otros no necesitan hasta separar del flujo los registros erróneos para obtener estadísticas de la ejecución.

Desde el punto de vista de la volumetría, el router recibe un flujo de entrada que será dividido en grupos en su salida. Según esto, podemos pensar que la volumetría total en la salida es la misma que en la entrada pero repartida en varios grupos. Pues bien, esto no es cierto ya que la suma de las salidas del router no tiene porqué ser igual a la entrada, si puede ser superior o inferior.

Como bien sabemos, el router cuenta con el grupo Default, por el cuál recuperamos aquellos registros que no se adecúan a las condiciones de ningún grupo, recuperando así la totalidad de registros entrantes. Este grupo es a veces ignorado con la intención de rechazar datos, sufriendo en este caso una disminución en la volumetría. Lo que es posible que no sepamos, es que los grupos de un router no son excluyentes entre sí, es decir, un registro puede cumplir las condiciones de dos grupos y formar por tanto, parte de varios subconjuntos de datos. Sufriríamos en este caso un aumento sobre la volumetría de entrada.

Se recomienda prestar especial atención a los grupos y condiciones que creamos, si bien puede parecer absurdo, los mapeos adquieren muy a menudo una gran complejidad. De no ser así, podemos incurrir en la duplicación de registros no deseados, que suelen ser difíciles de encontrar.

Igual a como se comentó en la sección del filtro, conviene utilizar variables o indicadores que contengan todas las condiciones de los grupos del router, mejorando así la eficiencia y rendimiento en la ejecución. Así, se puede crear en una expression previa, un indicador que tome el valor 1 para registros nuevos, 2 para actualizaciones, 3 para borrados y 4 para descartados, por ejemplo. De esta forma, el enrutamiento será más rápido teniendo el router que comprobar solo el valor de esta variable.


  • Sorter

Como se avanzó en el capítulo previo, tenemos aquí una excepción que confirma la regla. Su comportamiento natural es pasivo, si bien es cierto que existe una propiedad que puede convertir al sorter en una transformación activa.

Su principal funcionalidad es la ordenación de un flujo de datos por uno o varios campos. Puede elegirse si la ordenación de cada campo será ascendente o descendente.

Siempre que se manejan grandes volúmenes de datos, el uso del sorter es altamente recomendado para mejorar el rendimiento y evitar cuellos de botella. Marcar la opción Sorted Input de determinadas transformaciones como el aggregator, joiner o rank, usando sorters para ordenar sus correspondientes flujos de entrada, suavizará el “esfuerzo” de estas transformaciones, que consumirán menos caché y tardarán considerablemente menos en procesar los datos.

Sin embargo, dentro del menú Properties encontramos la opción Distinct. Al marcar esta opción el sorter eliminará cualquier registro duplicado en su totalidad. Todos los campos serán claves de ordenación ascendente y cualquier registro cuyo predecesor sea exactamente igual será eliminado, causando la correspondiente disminución en el número de registros.

Este es el motivo por el cual se incluye esta transformación, generalmente pasiva, en el grupo de las activas.


  • Source Qualifier

Presente siempre con cada Source del desarrollo, puede presentar un comportamiento activo o pasivo en función del tipo de entrada. Esta es la otra excepción mencionada con anterioridad.

Si bien cuando se trata de un fichero de texto es meramente una transformación pasiva que no ofrece ninguna funcionalidad reseñable, cuando se trata de una tabla en base de datos puede hacer la función de sorter, filter, aggregator o incluso joiner.

Esto es así porque en el segundo caso (la entrada es una tabla) es posible utilizar filtros o queries que ataquen directamente la base de datos, reduciendo el volumen en la medida en que las cláusulas SQL (WHERE, GROUP BY, etc) afectan a la información.

Como se ha mencionado, se puede usar el SQ como joiner realizando un cruce directamente en base de datos entre dos o más tablas. Para este efecto, debemos utilizar los sources de las tablas que queramos cruzar mapeándolos a un único SQ. De esta forma y realizando la query correctamente y conforme al requerimiento que queramos satisfacer, conseguimos reproducir el funcionamiento de un joiner con la consiguiente variación de volumetría.

También se ha indicado la posibilidad de realizar ordenaciones a través de un SQ. Ya sea mediante la cláusula ORDER BY en una query o a través de la propiedad Number of Sorted Ports del menú Properties de la transformación, no requiere especial atención puesto que desde el punto de vista de la variación de flujo no implica ningún cambio.


Esto es todo en cuanto a la caracterización de las transformaciones activas desde el punto de vista de la volumetría. Como conclusión y de carácter general, podemos tomar como válido que las transformaciones activas realizan operaciones entre registros.

Si deseas volver al capítulo introductorio pincha aquí.