Según Gartner ( 2013 Cuadrante Mágico para la Integración de Datos ), Informatica PowerCenter (PWC en adelante) es la solución líder del mercado para la integración de datos a nivel empresarial. En esta serie de artículos voy a cubrir algunos de los pequeños tidbits técnicos que pueden hacer un mundo entero de la diferencia en la implementación de funcionalidades appurtenant, con suerte ayudar a un aspirante a desarrollador de ETL en el día a día los compromisos. El tema será segmentado en múltiples escenarios y un par de secuelas. Como siempre, se anima a todos los lectores a responder, cuestionar y solicitar información adicional relacionada con el tema en cuestión.
2013 Gartner
Ajuste fino de la generación y / o clasificación de números ordinales
Al implementar la lógica ETL en Informatica PowerCenter, la mejor práctica sugiere el uso exclusivo de objetos PWC como regla general. Sin embargo, a veces esta guía puede dejar el rendimiento de ejecución lógica ETL con algo que desear. Antes de entrar en áreas sombreadas, como el reemplazo de código, a veces hay una opción para implementar la funcionalidad deseada mediante el uso de objetos PWC, pero de una manera no intencionalmente. Un ejemplo de este escenario es la generación de números ordinales.
clasificación
Informatica PowerCenter ofrece la funcionalidad de Rank Transformation para facilitar la generación de números ordinales. Un enfoque alternativo, a menudo superior en términos de tiempo de ejecución y utilización de recursos, es utilizar una combinación simple de Clasificador y Transformación de expresión con puertos variables. La funcionalidad clave requerida para este enfoque es una característica inherente de PWC para inicializar los valores de los puertos en sucesión de arriba a abajo (cuando se observa en la pestaña Puertos de los objetos de transformación más comunes). ¿Cómo ayuda? Pues bien, colocar un puerto que contiene el valor de inicialización para el puerto de variable por debajo de la misma hace que dicha variable se inicialice con el valor del registro anterior y para cada registro en la tubería, excepto el primero - éste clasifica como no identificado. Esto básicamente significa que el valor de la variable es igual al valor pertinente para el registro anterior. Además, Sorter Transformation proporciona una funcionalidad de ordenación que, al final, proporciona una forma muy eficiente de clasificar registros basados en lógica arbitraria.
Voy a ilustrar con un escenario: Generar valores de número ordinales para el siguiente conjunto de datos, particionado por CUSTOMER_ID, ordenado ascendente por CHANGE_DATE_ID.
IDENTIFICACIÓN DEL CLIENTE
DIRECCION DE CASA
DIRECCIÓN DE ENVIO
NÚMERO DE TELÉFONO
CHANGE_DATE_ID
Como se mencionó, el primer paso es ordenar los datos antes de asignar el rango. Si pensamos en la funcionalidad que se está implementando en una forma de función SQL rank (), la clasificación debe hacerse en todas las columnas PARTITION BY y ORDER BY. La dirección de ordenación para el segmento PARTITION BY es irrelevante, mientras que debe ajustarse de acuerdo con los requisitos de la cláusula ORDER BY.
map1
En este caso, el registro más antiguo se clasificará como el más alto (rango = 1). Otros escenarios, incluyendo múltiples columnas en las cláusulas PARTITION BY y ORDER BY, son triviales y no serán visitados dentro de esta publicación.
Después de que nuestros datos se ordenen de la manera correcta, procedemos a asignar valores de rango. Propagamos todos los puertos necesarios a una Transformación de expresión, agregamos un puerto variable para el conjunto de datos PARTITION BY (CUSTOMER_ID), lo situamos encima del puerto de E / S dependiente y asignamos el valor.
map2
Con dicho puerto variable situado encima del puerto que mantiene el valor asignado, aseguramos la latencia entre el mismo de exactamente un registro (la contrapartida variable es un registro detrás). Finalmente, añadimos un puerto variable en el que calcularemos el valor de rango (v_Sequence en este caso) con la siguiente lógica:
map3
De esta manera, los datos se clasifican eficientemente con un rendimiento superior al de una transformación de rango proporcionada por PowerCenter.
Cambiar captura de datos (CDC) por CHECKSUM
cdc.gif
Una funcionalidad que es inherente a cada implementación de la pila de procesos ETL de DWH y dependiente es Change Data Capture o CDC para abreviar. Esto significa buscar sólo datos nuevos y / o modificados de los sistemas fuente, aplicando la lógica de transformación requerida y cargando dicho alcance de datos en DWH. Este enfoque se conoce comúnmente como carga incremental.
Ahora, la primera ya veces bastante completa tarea al implementar CDC es identificar con precisión el conjunto de datos requerido para la recuperación de los sistemas fuente. Este proceso puede ser muy fácil de implementar cuando, por ejemplo, los registros se marcan con la creación y el tiempo de cambio, sin embargo, esto no siempre es el caso. El peor de los casos es cuando no hay manera de identificar los datos nuevos y cambiados, aparte de comparar conjuntos de datos completos para las diferencias. Teniendo en cuenta los volúmenes de las cargas incrementales DWH contemporáneas y el número de columnas requeridas por objeto de datos, esta tarea puede acelerar hasta los requisitos de infraestructura y procesamiento insostenibles.
Sin embargo, existe un enfoque que puede eludir dichos escenarios a un resultado más manejable. En lugar de comparar todos los conjuntos de datos de origen y destino, se puede derivar un valor único para cada registro en los sistemas de origen y de destino y comparar los dos conjuntos de valores. Una manera fácil de facilitar este proceso es calcular un valor de suma de comprobación para cada registro que entra en la comparación. De esta manera, los valores comparados dependen de todos los valores utilizados como parámetros de entrada para el cálculo del checksum, pero la comparación final se realiza únicamente entre dos valores. En el primer caso, si el caso era donde no teníamos el atributo CHAGE_DATE_ID podríamos calcular fácilmente el valor de suma de comprobación de los siguientes parámetros de entrada:
(TO_CHAR (CUSTOMER_ID) || HOME_ADDRESS || BILLING_ADDRESS || PHONE_NUMBER)
Al comparar las sumas de comprobación de origen y de destino, se podría identificar de forma fácil y eficiente el alcance de los CDC. Hay una plétora de algoritmos para evaluar los valores de checksum - MD5 () se utiliza bastante comúnmente, pero siempre tenga en cuenta la precisión al elegir el algoritmo.
¿Actualizar? ¡No, gracias!
En los sistemas de bases de datos convencionales la actualización es una operación a menudo temida. Correctamente así - es muy caro en términos de tiempo de procesamiento y recursos. Sin embargo, una actualización puede facilitarse sin actualizar los conjuntos de datos. En otras ocasiones, puede que no haya manera de evitarlo, en cuyo caso deberían considerarse los medios óptimos para realizar una actualización. Como tal, este es un tema amplio y dentro de este post voy a revisar algunas de las posibles soluciones en diseño e implementación.
No
Siempre que hay una manera de administrar la misma funcionalidad sin realizar actualizaciones de base de datos, probablemente es mejor ir por ella. Esto puede hacerse dividiendo el proceso ETL en múltiples conjuntos con insertos exclusivamente a múltiples tablas temporales como pasos a un conjunto de datos final. El resultado final será, sin duda, una pila de procesos ETL mucho mejor.
En una nota menos trivial - el mismo proceso se puede implementar cuando se requiere, por ejemplo, refrescar datos dimensionales, lo que usualmente significa insertar nuevos y también actualizar los conjuntos de datos existentes mientras se mantiene la integridad referencial. El proceso en este escenario sería unir externamente todos los datos del sistema fuente a los datos contenidos dentro de la dimensión correspondiente y continuar con las siguientes acciones:
En el caso de registros existentes sin cambios - saltarlos o tomar todo de la dimensión
En caso de registros actualizados - tomar datos específicos de la dimensión de DWH (por ejemplo, las claves de sustitución) y tomar el resto de la fuente
En caso de nuevos registros - generar datos específicos de la dimensión y tomar el resto de la fuente
Después de eso, el curso de acción puede variar - uno podría colgar todo el conjunto de datos derivados de los tres pasos mencionados anteriormente a una tabla temporal e intercambiar la dimensión y el contenido de la tabla temporal después de la carga, ya sea por insertos o funcionalidad específica de base de datos, Declaración de partición de intercambio de Oracle. Lo anterior requeriría que la tabla temporal tuviera exactamente la misma estructura que la dimensión y que la dimensión a particionar, usualmente por un valor ficticio, igual para cada tupla contenida.
Si no hay manera de evitarlo, se puede elegir la opción de realizar una actualización de la base de datos. Esto puede hacerse después de los tres pasos mencionados anteriormente y el resultado final es una tabla temporal que contiene todo el alcance incremental o sólo el conjunto de datos que se va a usar para la actualización de la dimensión y la actualización misma que se facilita mediante la ejecución del script SQL. Esto deja de nuevo las opciones de secuencias de comandos para ser explotadas, como la sentencia MERGE en Oracle.
Todos los escenarios mencionados conducirán a mejoras de rendimiento en comparación con las asignaciones de estrategia de inserción / actualización sencillas.
Si tiene algún consejo o duda, por favor deje un comentario a continuación. Si no, nos vemos en la parte 2 de la serie, saliendo pronto.