Una solución de alto rendimiento para alimentar un almacén de datos con datos en tiempo real, Parte 1: Integración de InfoSphere Replication Server e InfoSphere DataStage

Alimente por goteo a su almacén de datos

Alimentar un almacén de datos con cambios a partir de la base de datos de origen puede ser muy costoso. Si la extracción se hace solamente con SQL, no hay forma de identificar fácilmente las filas que han sido cambiadas. El IBM® InfoSphere® Replication Server puede detectar los datos cambiados leyendo solamente el log de la base de datos. Esta serie de artículos ilustra cómo puede usarse el InfoSphere Replication Server para extraer eficientemente sólo los datos cambiados, y luego pasar los cambios a IBM InfoSphere DataStage® para alimentar el almacén de datos. Ésta serie de artículos consta de dos partes. En la Parte 1 se brinda un resumen de los productos y de cómo éstos pueden operar en forma conjunta. En la Parte 2, se pueden explorar dos opciones diferentes de integración: mediante tablas temporarias o mediante mensajes MQ.

Anand Krishniyer, Staff Software Engineer, IBM

Anand Krishniyer es ingeniero de planta permanente en la organización de desarrollo InfoSphere Replication. Como miembro del equipo admin, sus responsabilidades incluyen el desarrollo de ítems de líneas y brindar asistencia técnica a clientes respecto de la instalación, montaje y configuración del Replication Server. Previo a su cargo actual, Anand trabajó como líder de proyecto para el equipo de Integración y Herramientas de una empresa de gestión de procesos, Savvion (actualmente parte de Progress Software).



Tony Lee, Senior Certified IT Specialist, IBM

Tony Lee es especialista senior certificado en IT del InfoSphere Replication Center of Competency (COC), un equipo dentro de la organización de desarrollo InfoSphere Replication. Como miembro del COC, Tony ha brindado asistencia técnica a clientes y socios sobre las tecnologías de replicación InfoSphere. Tony tiene muchos años de experiencia consultiva sobre diversas tecnologías de replicación IBM, incluyendo replicación SQL, replicación Q y, más recientemente, InfoSphere Change Data Capture. Previo a su cargo actual, Tony proveyó consultoría técnica en Gestión de Información a clientes y socios durante casi una década, abarcando una amplia gama de temas, desde ajustes de DB2 hasta Gestión de Servidores de Información y Datos Master. Antes de ser consultor, Tony trabajó en muchos cargos diferentes dentro del área de Gestión de Información, abarcando desde la gestión hasta el desarrollo.



James Yau, Technical Solution Architect, IBM

James Yau 的照片James Yau es arquitecto senior certificado en soluciones del producto InfoSphere Information Server DataStage. Actualmente forma parte de la organización InfoSphere Technology Enablement, responsable del desarrollo y la entrega de contenidos del Information Server Boot Camp. James tiene muchos años de experiencia consultiva en el paquete de productos Information Server Suite, que incluye InfoSphere DataStage, QualityStage, Information Analyzer y FastTrack. Previo a su cargo actual, James formó parte del equipo Business Partner Technical Enablement, en el cual era gerente técnico de programas para el InfoSphere Information Server. Su actividad incluía el desarrollo y la entrega del contenido de cursos con varias modalidades, tales como dirigidos por un instructor, cursos en línea y aprendizaje auto-regulado. Anteriormente, James trabajó en muchos cargos distintos, desde desarrollador de software hasta gerente de marketing, tanto dentro como fuera de IBM.



21-01-2011

Introducción

En el vertiginoso mundo de hoy, el éxito o el fracaso de un negocio frecuentemente depende de cuán rápido puede éste reaccionar a los cambios. Ya sea que esto signifique que un minorista puede responder dinámicamente a los cambios a través de los niveles de inventario o que una institución financiera reacciona a los cambios a través de la tasa de interés, el negocio que puede detectar y responder más rápidamente al cambio, tendrá una ventaja competitiva. El método tradicional de la inteligencia en negocios (BI), donde los datos transaccionales son recolectados, transformados y luego cargados en bloque a un almacén de datos en forma periódica (por ejemplo, diariamente), ya no es suficiente para satisfacer la demanda en tiempo real de un negocio "a pedido". Por otra parte, a medida que aumenta la cantidad de datos transaccionales, la ventana de lotes para llevar a cabo una carga tradicional del almacén de datos se ve acortada, haciendo que el proceso de lotes sea menos viable para los requisitos de datos en tiempo real.

El método básico para alimentar un almacén de datos típicamente consiste en tres fases: E (Extracción), T (Transformación) y C (Carga).

Extracción
Consiste en leer los datos de origen a partir de diversas fuentes de datos transaccionales, tales como IBM DB2®, Oracle o archivos de texto plano. El método tradicional a menudo requeriría leer toda una base de datos transaccionales con el predicado de filtrar sólo las filas de interés desde la última vez que se realizó la alimentación. Esto significa que si en una base de datos transaccionales de 100GB se cambió sólo el 5% de los datos (5GB) desde la última carga, la fase de extracción aún deberá leer todos los 100GB de datos a fin de extraer los 5GB de datos cambiados.
Transformación
Consiste en transformar los datos transaccionales -los cuales a menudo se presentan altamente desnormalizados- al formato de almacén utilizable para un análisis BI, tal como un esquema en estrella. Esto puede incluir la búsqueda de códigos, la unión de datos a través de sistemas transaccionales, la limpieza de datos, la conversión de datos a datos dimensionales, y más aún. (Ver publicaciones sobre almacenes de datos en Recursos, IBM Redbooks®.)
Carga
Luego de que los datos han sido transformados, se cargan en el almacén, generalmente con SQL o con la función nativa importar/cargar de la base de datos del almacén.

En este artículo se explica cómo el uso del InfoSphere Replication Server puede reducir drásticamente el tiempo que dura la fase de extracción e, integrando la información de salida del Replication Server con el InfoSphere Information Server (el principal componente usado aquí es DataStage), llevar a cabo las fases de transformación y de carga. Todo el proceso ETL puede ser acortado significativamente, al punto en que puede realizarse BI en tiempo real.


Resumen de la tecnología

Las dos tecnologías claves tratadas en este artículo son InfoSphere Replication Server e InfoSphere DataStage (uno de los componentes del InfoSphere Information Server). El InfoSphere Replication Server proporciona la función de extracción; el InfoSphere DataStage proporciona las funciones de transformación y de carga.

InfoSphere Replication Server

La clave para lograr un alto rendimiento durante la extracción de datos con el InfoSphere Replication Server es el hecho de que todas las principales bases de datos relacionales usan un log para registrar los cambios en la base de datos. Por ejemplo, si se inserta un registro en una tabla, en el log de la base de datos se escribe un registro log que almacena los datos insertados de manera que puedan utilizarse para fines de recuperación. En forma similar, las actualizaciones y eliminaciones también se registran con los datos necesarios para fines de recuperación. El InfoSphere Replication Server entiende cómo leer el log para recoger los cambios en la base de datos (permite la lectura del log nativo de DB2 y Oracle hoy día). Por lo tanto, en lugar de examinar toda una base de datos (de 100GB, por ejemplo) para hallar los registros insertados/actualizados/eliminados, el InfoSphere Replication Server sólo necesita leer los datos de registro que han sido cambiados (siguiendo con este ejemplo, 5GB de datos de registro, si sólo se cambió el 5%).

Componentes principales de la arquitectura del InfoSphere Replication Server:

  • Capture: Este componente es responsable de la lectura del log de la base de datos y de capturar los cambios. Este componente se ejecuta típicamente en la misma máquina donde reside la base de datos de origen, aunque para algunas bases de datos también puede ejecutarse en forma remota desde la base de datos de origen.
  • Apply: Este componente es responsable de la aplicación de los cambios capturados por el componente de captura y de escribir luego los cambios en una base de datos de destino. Pueden realizarse varias transformaciones (tales como subagrupar filas y columnas). Pueden usarse diversos tipos de tablas de destino (por ejemplo, la tabla de destino puede ser muy similar a la tabla de origen), o puede especificarse una tabla de destino para insertar una fila nueva por cada cambio (por ejemplo, en lugar de eliminar la fila de destino cuando se elimina la fila de origen, insertar una nueva fila en la tabla de destino indicando que ésa es una "eliminación" que registra los datos eliminados en la nueva fila).
  • Admin: Este componente proporciona una interfaz para configurar y administrar el InfoSphere Replication Server. Se dispone tanto de una interfaz UI como de una basada en líneas de comandos.

Opciones de arquitectura:

  • SQL Replication: Ésta era la arquitectura original de replicación. SQL Capture emplea tablas temporarias llamadas tablas CD (Changed Data: Datos Cambiados) para almacenar los cambios capturados que lee del log. SQL Apply proveería SQL para leer las tablas CD, y luego proveería SQL para escribir los cambios en las tablas de destino. Si bien es más lento en cuanto a rendimiento, SQL Replication funciona muy bien en algunos escenarios tales como el de la distribución de datos de origen en un gran número de destinos.

    La Figura 1 muestra al componente Capture haciendo uso de tablas CD para almacenar cambios capturados a partir de los logs, y al componente Apply leyendo esas tablas y luego escribiendo los cambios en las tablas de destino.

    Figura 1. Arquitectura de InfoSphere SQL Replication
    Arquitectura de InfoSphere SQL Replication
  • Q replication: Esta es la arquitectura más nueva, donde en lugar de escribir los datos capturados en tablas CD, Q Capture escribe los datos capturados en listas de espera MQ WebSphere. La lista de espera MQ luego pasa a ser el mecanismo de transporte, donde Q Apply, ejecutándose en la máquina de destino y leyendo del extremo de recepción de la lista de espera, volvería a ejecutar la transacción y a escribir los cambios en los destinos. Q Replication es por lo tanto una replicación de datos en tiempo real, con un rendimiento mucho mayor, latencia inferior a un segundo, y una capacidad de procesamiento extremadamente alta.

    La Figura 2 muestra a Q Capture obteniendo datos a partir de los logs y escribiéndolos en listas de espera MQ, y a Q Apply leyendo de la lista de espera y escribiendo los cambios en las tablas de destino.

    Figura 2. Arquitectura de InfoSphere Q Replication
    Arquitectura de InfoSphere Q Replication
  • Publicación de eventos: Esencialmente, la publicación de eventos consiste en ejecutar Q Capture sin Q Apply. En otras palabras, en lugar de ejecutar Q Apply para leer la lista de espera de recepción en busca de cambios, los cambios capturados son escritos por Q Capture en un formato documentado (XML o CSV, con valores separados por comas), de manera que uno puede escribir su propio programa para leer la información de salida directamente de la lista de espera de recepción. Más adelante en este artículo se discute cómo ésta es una opción viable para la integración con InfoSphere DataStage, ya que InfoSphere DataStage puede consumir directamente los cambios a partir de la lista de espera de recepción MQ y saltear el Q Apply de más arriba.

    La Figura 3 muestra una aplicación de usuario leyendo de la lista de espera MQ y escribiendo en un archivo de usuario o una tabla de usuario.

    Figura 3. Arquitectura InfoSphere de publicación de eventos
    Arquitectura InfoSphere de publicación de eventos

Véase la sección Recursos para mayor información relacionada con el InfoSphere Replication Server.

InfoSphere DataStage

InfoSphere DataStage es una poderosa herramienta ETL que permite la construcción gráfica de una tarea para ejecutar funciones ETL sin escribir ningún código. Este producto viene empaquetado como parte del producto InfoSphere Information Server. InfoSphere DataStage incluye docenas de funciones de transformación integradas llamadas escenarios. Por ejemplo, existe un escenario para leer a partir de una tabla de una base de datos, un escenario para unir datos, un escenario para transformar datos de entrada, un escenario para limpiar datos, etc. Los escenarios pueden arrastrarse gráficamente desde la paleta hacia el área de trabajo del diseñador, para luego conectar la información de salida de un escenario de forma que se convierta en la información de entrada de otro escenario. Cada escenario incluye propiedades personalizables (por ejemplo, nombre de tabla de entrada, definición de columnas, fórmula de transformación, etc.). Luego se compila una tarea, lo cual genera una tarea ejecutable en el lenguaje de propiedad de InfoSphere DataStage. Cuando se ejecuta la tarea, los datos son extraídos, transformados y cargados de acuerdo a las definiciones de los escenarios. Una de las características más sobresalientes de InfoSphere DataStage es que está construido sobre un motor paralelo altamente configurable, junto con una exclusiva estructura de archivos paralelos. Estas características paralelas hacen que DataStage alcance un rendimiento muy elevado.

La Figura 4 muestra un ejemplo de tarea de InfoSphere DataStage en el cliente de InfoSphere DataStage Designer.

Figura 4. Ejemplo de tarea de InfoSphere DataStage presentado en el InfoSphere DataStage Designer
Ejemplo de tarea de InfoSphere DataStage presentado en el InfoSphere DataStage Designer

Además de permitir el diseño del flujo de datos, InfoSphere DataStage también permite el diseño visual del flujo de trabajo, como se muestra en la Figura 5:

Figura 5. Ejemplo de secuencia de flujo de de trabajo en InfoSphere DataStage
Ejemplo de secuencia de flujo de de trabajo en InfoSphere DataStage

Véase la referencia de InfoSphere DataStage en la sección de Recursos para más detalles.


Integración de InfoSphere Replication Server con InfoSphere DataStage

Resumen

Si bien InfoSphere DataStage tiene escenarios para acceder a los datos desde diferentes bases de datos, no tiene la capacidad de capturar sólo los datos cambiados leyendo los logs de la base de datos. InfoSphere Replication Server, por otro lado, puede capturar sólo los cambios a partir de la base de datos, pero no tiene la gran capacidad de transformación de InfoSphere DataStage. Veamos las diferentes opciones de integración entre estas dos tecnologías.

Básicamente existen dos enfoques de arquitectura para integrar InfoSphere Replication Server con InfoSphere DataStage:

  • En tiempo real: Los datos cambiados son consumidos directamente por InfoSphere DataStage, sin escenarios intermedios.
  • Datos en escenario: Los datos cambiados son aterrizados, como un archivo o en una tabla relacional. InfoSphere DataStage luego lee esos datos aterrizados.

InfoSphere Replication Server puede integrarse con InfoSphere DataStage con cualquiera de estas arquitecturas.

Integración en tiempo real

Con la integración en tiempo real, los cambios realizados en las tablas de origen son capturados por el componente Q Capture del InfoSphere Replication Server, y luego se escriben a una lista de espera MQ. Sin embargo, en lugar de usar Q Apply para leer los cambios a partir de la lista de espera MQ en el destino y luego aterrizar los cambios en una tabla temporaria, uno simplemente deja que la tarea InfoSphere DataStage lea directamente de la lista de espera MQ y procese los cambios con la función de publicación de eventos del InfoSphere Replication Server.

La publicación de eventos permite usar dos formatos de mensajes MQ—XML o valores separados por comas (CSV). Si bien XML es altamente transportable y flexible, CSV presenta un mejor rendimiento. InfoSphere DataStage tiene un escenario MQ Connector que puede utilizarse en una tarea para leer los mensajes fuera de la lista de espera. La tarea luego puede analizar el mensaje según el formato de mensaje elegido y realizar las transformaciones necesarias. (La Parte 2 de esta serie muestra un ejemplo detallado.)

Tal como se ilustra en la Figura 6, Q Capture lee los logs y envía los cambios a la lista de espera MQ. Los datos luego son enviados a la DB de destino (ODS) donde son analizados, escritos a conjuntos de datos, transformados y enviados a la DB del almacén.

Figura 6. Detalles de la integración en tiempo real
Detalles de la integración en tiempo real

Véase la sección Recursos para más información relacionada al InfoSphere Replication Server.

El mejor rendimiento lo brinda la integración en tiempo real, ya que evita el I/O y la sobrecarga de procesamiento que implica el aterrizaje de los datos cambiados. Sin embargo, dado que Q Capture constantemente impulsará los cambios a MQ, la tarea de transformación de InfoSphere DataStage deberá poder consumir y transformar los cambios capturados en forma lo suficientemente rápida como para no ir detrás de Q Capture. Una de las ventajas de usar MQ como el mecanismo de transporte de Q Replication es que MQ puede almacenar temporariamente los cambios si la tarea de InfoSphere DataStage no da abasto. Pero, obviamente, la tarea finalmente debe ponerse al corriente. La integración en tiempo real puede no ser la mejor opción de integración si la transformación que se necesita implica operar con una cantidad de datos mayor que la disponible en tiempo real (por ejemplo, en la agregación de un grupo), en cuyo caso la tarea de transformación puede todavía necesitar almacenar temporariamente los datos para que sean independientes de la técnica de replicación. En tal caso, la opción de integración de "datos temporarios" puede ser la solución correcta.

Integración de datos temporarios

En lugar de dejar que la tarea de transformación del InfoSphere DataStage consuma los cambios directamente a partir de la lista de espera MQ, el método de los datos temporarios escribe los cambios a una tabla de destino, la cual a su vez es leída por la tarea de transformación del InfoSphere DataStage. Esta tabla temporaria puede residir, por ejemplo, en un ODS (Operational Data Store: Centro de Datos Operativos), donde también pueden agruparse otros datos necesarios para la tarea de transformación. En el InfoSphere Replication Server, esta tabla temporaria se llama tabla de Datos Consistentes Cambiados (CCD). (Para quienes están familiarizados con la replicación SQL Capture, la tabla CCD de destino es similar a la tabla CD de origen, la cual de hecho también puede usarse si la tarea de transformación de InfoSphere DataStage puede ejecutarse en el servidor de origen donde reside la tabla CD, sorteando la necesidad de ejecutar SQL Apply.) Es verdad tanto para la tabla CD como la CCD que los cambios del log son siempre insertados directamente en la tabla temporaria con una columna indicando si la operación en el log fue una inserción, una actualización o una eliminación. Esta información, por lo tanto, puede ser usada en forma inmediata por la tarea del InfoSphere DataStage para realizar la transformación.

La Figura 7 muestra un ejemplo de tabla CCD que contiene el logmarker y las columnas de operación.

Figura 7. Instantánea de un ejemplo de tabla CCD
Instantánea de un ejemplo de tabla CCD

Veamos más en detalle algunas de las columnas en la Figura 7.

  • IBMSNAP_INTENTSEQ: Éste es un LSN (Log Sequence Number: Número de Secuencia del Log) contínuamente creciente que identifica unívocamente cada registro del log. Esta información puede ser utilizada por la replicación para determinar si un registro del log ha sido procesado o no.
  • IBMSNAP_COMMITSEQ: Este LSN es único para cada transacción. En este ejemplo hay cuatro transacciones con cinco cambios: las dos últimas actualizaciones pertenecen a la misma transacción (x'…1101213D'). El InfoSphere Replication Server garantiza la consistencia transaccional en el destino. Por lo tanto, si una transacción tiene múltiples operaciones, o bien todas las filas correspondientes a las operaciones serán escritas a la CCD, o no aparecerá ninguna.
  • IBMSNAP_OPERATION: Esto identifica si este registro es una inserción, una actualización o una eliminación en el origen. Esta información puede usarse dentro de la tarea del InfoSphere DataStage para determinar qué transformación debe hacerse. Por ejemplo, si el valor es una 'D', escriba la información a un archivo de auditoría, registrando que esta fila ha sido eliminada, pero no elimine los datos del almacén.

Con los datos temporarios en la CCD, la tarea del InfoSphere DataStage puede programarse periódicamente (por ejemplo, cada hora) para leer la CCD y realizar la transformación, ahora sobre un conjunto de datos mucho más grande que el que es posible con la integración EP en tiempo real. Sin embargo, puesto que ahora Apply se está insertando en la tabla CCD con nuevas filas en forma asincrónica respecto de la tarea de transformación que está leyendo la CCD, debemos asegurarnos de poder individualizar cuáles filas de la CCD ya han sido procesadas, a distinción de aquéllas que han llegado recién. La técnica para individualizar cambios difiere entre la replicación SQL y la replicación Q.

Replicación SQL

Con la replicación SQL, las tablas a ser replicadas se definen por un "conjunto de suscripción" utilizado por SQL Apply. Los datos sólo son replicados por SQL Apply cuando un conjunto de suscripción periódicamente "se despierta" y realiza un ciclo simple de procesamiento de replicación. Un conjunto de suscripción puede configurarse para despertar como resultado de una señal de evento o de acuerdo a intervalos temporizados (entre un minuto y horas). Esto quiere decir que durante el intervalo, cuando un conjunto de suscripción está dormido, los contenidos de la tabla CCD son estáticos. Si se configura el conjunto de suscripción solamente para realizar un ciclo de suscripción cuando la tarea del InfoSphere DataStage no se está ejecutando, puede hacerse lo siguiente en la tarea del InfoSphere DataStage (nótese que esta tarea será programada para ejecutarse periódicamente):

  1. Leer toda la tabla CCD
  2. Realizar la transformación sobre los datos
  3. Eliminar todo el contenido de la tabla CCD
  4. Emitir una señal de evento para despertar al conjunto de suscripción de manera que pueda poblar la tabla CCD con nuevos datos

Alternativamente, el conjunto de suscripción puede programarse para despertar a un momento distinto del cual la tarea del InfoSphere DataStage está programada para ejecutarse. Por supuesto, si por algún motivo la tarea del InfoSphere DataStage y el ciclo de replicación se ejecutan al mismo tiempo, el peligro aquí es que pueden obtenerse resultados incorrectos.

Figura 8. Arquitectura de integración de datos temporarios, incluyendo el ciclo de suscripción
Arquitectura de integración de datos temporarios, incluyendo el ciclo de suscripción

(La Parte 2 de esta serie muestra un ejemplo detallado.)

Replicación Q

Q Apply, a diferencia de SQL Apply, se ejecuta continuamente. Por lo tanto, no se tiene la opción de programar la tarea del InfoSphere DataStage para ejecutarse en el momento en que la tabla CCD no está siendo cambiada por Apply. Alternativamente, se dispone de tres opciones:

  • Ejecutar Q Apply con la opciónAPPLYUPTO=CURRENT TIMESTAMP(opción nueva en 97FP2): El parámetro APPLYUPTO es una opción de Q Apply que le ordena a Q Apply aplicar los cambios a la CCD sólo hasta cierto momento, y luego detenerse.

    Los siguientes cambios tienen lugar dentro de la tarea del InfoSphere DataStage:

    1. Leer toda la tabla CCD.
    2. Realizar la transformación sobre los datos.
    3. Eliminar todo el contenido de la tabla CCD.
    4. Iniciar Q Apply con APPLYUPTO=CURRENT TIMESTAMP de manera que Q Apply pueda poblar la tabla CCD con cambios que han sido capturados desde la última vez que Q Apply fue ejecutado.
    5. Esperar que se complete Q Apply.
    6. Iterar a partir del Paso 1.

    Q Apply, por lo tanto, sólo se ejecuta cada vez que la tarea de transformación ha terminado, y puebla la tabla CCD con nuevos cambios a ser procesados en el siguiente ciclo de la tarea del InfoSphere DataStage. Nótese que esta técnica sólo es posible si el ciclo entre las ejecuciones de la tarea del InfoSphere DataStage es lo suficientemente breve como para que los cambios acumulados durante este tiempo puedan ser almacenados temporariamente por MQ (ya que Q Apply no se estará ejecutando).

  • Detener/Iniciar Q Apply: Esta opción es similar a la anterior, excepto que en lugar de sólo ejecutar Q Apply una vez luego de cada ciclo de tarea del InfoSphere DataStage, se mantiene Q Apply ejecutándose, aunque se detiene durante la tarea de transformación.
    1. Detener Q Apply.
    2. Leer toda la tabla CCD.
    3. Realizar la transformación sobre los datos.
    4. Eliminar todo el contenido de la tabla CCD.
    5. Iniciar Q Apply.

    Esto evita el problema de que Q Apply esté detenido durante el ciclo de tarea del InfoSphere DataStage. Q Apply estará ejecutándose en forma continua independientemente del tiempo entre los ciclos de tarea del InfoSphere DataStage.

  • Registrar las marcas de agua bajas/altas de la CCD: Almacenar los valores IBMSNAP_COMMITSEQ mínimos y máximos al comienzo de la tarea de InfoSphere DataStage, leer solamente los contenidos de la CCD entre estos valores mínimos y máximos y, cuando se completa la tarea, actualizar estas marcas de agua mín/máx para leer el siguiente conjunto de cambios. Q Apply nunca se detiene. Durante el proceso de transformación que lleva a cabo InfoSphere DataStage, la tabla CCD continuará acumulando cambios, pero éstos no impactarán en el proceso de la tarea de InfoSphere DataStage, ya que los nuevos registros estarán fuera del rango de procesamiento.

    La única complejidad con esta solución es que InfoSphere DataStage (edición paralela, la cual es InfoSphere Information Server) no permite el uso de variables globales para registrar estos valores mín/máx. Para que estos valores persistan, hay que escribirlos a un archivo de texto plano o a una tabla relacional. Con una tabla relacional, el valor puede usarse en un escenario Conector DB2 como predicado para leer la tabla CCD. Con un archivo de texto plano, sin embargo, dado que los valores no pueden usarse dentro de la declaración SQL de un Conector DB2 (restricción con el escenario Connector DB2), se requiere usar una técnica diferente para leer la tabla CCD con el predicado. Una posibilidad es invocar el DataStage utilizando dsjob y pasar el valor synchpoint como un parámetro de tiempo de ejecución interno.

    1. Establecer GLOBAL_MINSYNCHPT=MIN(IBMSNAP_COMMITSEQ)-1 a partir de la tabla CCD (inicializacion solamente).
    2. Establecer GLOBAL_MAXSYNCHPT=MAX(IBMSNAP_COMMITSEQ) a partir de la tabla CCD.
    3. Leer la tabla CCD para cada fila con IBMSNAP_COMMITSEQ > GLOBAL_MINSYNCHPT y <=GLOBAL_MAXSYNCHPT.
    4. Realizar la transformación sobre los datos leídos.
    5. Establecer GLOBAL_MINSYNCHPT=GLOBAL_MAXSYNCHPT.
    6. Repetir en el Paso 2.

    Nota: A diferencia de las otras opciones, ésta no elimina los contenidos de la tabla CCD como parte de la ejecución de la tarea de InfoSphere DataStage. Por lo tanto, el recorte de la tabla CCD es un proceso separado que se encuentra fuera del alcance del InfoSphere DataStage. Por supuesto, esto presenta la ventaja de que la CCD ahora puede utilizarse para otros fines (tales como auditoría).

Figura 9. Arquitectura de integración en tiempo real con los datos que fluyen al almacén, con y sin ODS
Arquitectura de integración en tiempo real con los datos que fluyen al almacén, con y sin ODS
Tabla 1. Comparación entre las opciones de integración
ConsideracionesTiempo realDatos temporarios
Publicación de eventosReplicación SQLReplicación Q
Iniciar/detener Q ApplyRegistrar posiciones en CCD
Latencia (tiempo que le lleva a un cambio que ocurre en origen el alcanzar la tarea del InfoSphere DataStage)La más rápida replicación continua, sin sobrecarga para Q Apply. La tarea del InfoSphere DataStage, sin embargo, debe realizarse lo suficientemente rápido como para consumir los cambios. Si los cambios son gobernados por eventos, se replican solamente a continuación del ciclo de procesamiento de la tarea de InfoSphere DataStage cuando el evento es disparado. Si son gobernados por intervalos de tiempo, los cambios se replican luego de cada intervalo de tiempo especificado. Cambios replicados continuamente por Q Apply, excepto durante el procesamiento de la tarea de InfoSphere DataStage. Cambios replicados continuamente por Q Apply.
Donde se almacenan temporariamente los cambios cuando la tarea del InfoSphere DataStage no ha procesado los cambiosEn la lista de espera MQEn la tabla CCDEn la tabla CCDEn la tabla CCD
Sobrecarga del admin1. Monitor MQ - asegúrese de que la lista de espera MQ no desborde
2. Monitor Q Capture
1. Monitor SQL Capture
2. Monitor SQL Apply
1. Monitor Q Capture
2. Monitor MQ
3. Monitor Q Apply
1. Monitor Q Capture
2. Monitor MQ
3. Monitor Q Apply
Datos cambiados utilizables por otras aplicacionesSi InfoSphere DataStage emplea una lectura no destructiva de la lista de espera, otra aplicación puede leer la lista de espera.No. Los datos CCD se eliminan luego del procesamiento de la tarea del DS. Puede crear una suscripción aparte para otras aplicaciones.No. Los datos CCD se eliminan luego del procesamiento de la tarea del InfoSphere DataStage. Puede crear una suscripción aparte para otras aplicaciones.Sí. Los datos CCD no son eliminados luego del procesamiento de la tarea del InfoSphere DataStage.
Consideraciones sobre el ajuste previoRequiere la asignación de mensaje MQ a definiciones de columnaLas usuales consideraciones de ajuste previo para replicación SQLLas usuales consideraciones de ajuste previo para replicación QRequiere recorte manual de la tabla CCD

Conclusión

Este artículo explicó las tecnologías de los productos InfoSphere Replication Server e InfoSphere DataStage y las diferentes formas de integrar ambos para alimentar el almacén de datos. También se vieron las ventajas y desventajas de las diferentes opciones de integración. La Parte 2 de esta serie detallará dos opciones específicas de integración: con tablas temporarias o con mensajes MQ. También abarcará el ajuste inicial y la configuración, con capturas de pantalla e instrucciones "paso a paso".

Recursos

Aprender

Obtener los productos y tecnologías

  • Construya su próximo proyecto de desarrollo con software de prueba IBM, disponible para descargar directamente de developerWorks.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=619101
ArticleTitle=Una solución de alto rendimiento para alimentar un almacén de datos con datos en tiempo real, Parte 1: Integración de InfoSphere Replication Server e InfoSphere DataStage
publish-date=01212011