Mejores prácticas para la integración de datos Oracle en tiempo real

Como con cualquier proyecto de TI, la integración de datos en tiempo real en un almacén de datos pueden beneficiarse de las mejores prácticas. Afortunadamente, muchas de las recomendaciones que sirven para el almacenamiento de datos son también aplicables a la integración de datos en tiempo real y siguen algunas reglas de sentido común.

Establecer la organización del proyecto desde el principio. La gestión de proyectos es fundamental cuando se trata de la integración de datos. Oracle Data Integrator (ODI) ofrece muchas herramientas que ayudan a organizar el trabajo de desarrollo y el ciclo de vida del proyecto, incluyendo perfiles de seguridad, proyectos de desarrollo, carpetas, marcadores, control de versiones, importación y exportación, e impresión de documentación en PDF, todo lo que cabe en la gestión de proyectos. Es importante revisar y utilizar todas las herramientas y funciones para la gestión del proyecto. Desde el inicio del proyecto, definir las directrices y la organización, las convenciones de nomenclatura y todo lo que evitará el caos y hará cumplir las mejores prácticas.

Asegurarse de que los profesionales de TI comprendan la topología y los contextos de la plataforma. En el mundo de Oracle, la topología de la ODI y sus contextos asociados son dos de las características más importantes para hacer funcionar artefactos en tiempo de diseño o en tiempo de ejecución, en diversos entornos. ODI se ejecuta sobre una arquitectura lógica (esquemas lógicos, agentes lógicos) que se resuelve en un contexto determinado para una arquitectura física y agentes ODI de tiempo de ejecución. Los contextos definen las conexiones entre los datos y su arquitectura subyacente, tal como bases y servidores de datos, y permiten a los diseñadores cambiar la ejecución de los artefactos de un ambiente a otro.

La clave está en comprender plenamente las diferencias entre las arquitecturas lógicas y físicas y entender cómo el concepto de contexto afecta al diseño y a la transformación de la información. Entender eso ayuda a evitar algunos errores comunes de contexto, tales como no realizar correctamente las asignaciones de arquitectura lógica o física en un contexto dado. Un error como este lleva a ejecuciones que no funcionan en un determinado contexto. Otro error será forzar contextos en situaciones en las que no se justifica. Los contextos innecesarios desperdician ciclos de reloj y añaden latencia al proceso de integración de datos. El contexto solo debe ser forzado cuando haya una razón funcional para ello. 

Incorporar diseño independiente del contexto. Aquí los artefactos ODI (de procedimiento, variables, interfaces) no tienen elementos codificados de forma rígida. El principal error será forzar la codificación de las expresiones y código, que incorpora nombres de objetos. Si tales nombres no están atentos al contexto, entonces los nombres o las variables de esquema serán incorrectos cuando se apliquen a un entorno bajo un contexto diferente. Los nombres de esquema se definen en la topología y los contextos obtienen un diferente nombre de esquema en función del contexto de ejecución. Cuando trabaje a través de contextos, utilice un método de codificación de sustitución.

Utilice procedimientos solo cuando sea necesario. Los procedimientos le permiten realizar acciones complejas, como las consultas SQL, y utilizan conexiones de origen y de destino, así como el enlace de datos. Los procedimientos le permiten mover datos, pero no deberían mover y transformar datos. Las interfaces deben llevar a cabo estas operaciones, mal que les pese a los desarrolladores que se sienten cómodos usando SQL.

El problema con los procedimientos es que contienen código de instrucciones que necesita ser mantenido manualmente. Y más aún, los procedimientos no mantienen referencias cruzadas a otros artefactos ODI como almacenes y modelos de datos, lo cual hace que su mantenimiento sea complicado, sobre todo si se compara con el mantenimiento de las interfaces.

Exigir calidad de los datos. Los gerentes de proyecto a menudo no tienen en cuenta la calidad de sus datos. Esto es un gran error, ya que el proceso de integración de datos puede mover y transformar datos basura y propagarlos a través de las aplicaciones. Afortunadamente, ODI le permite favorecer la calidad de los datos de origen mediante controles estáticos. También le permite utilizar controles de flujo para determinar la calidad de los datos antes de ser empujados hacia un objetivo. Con ambos controles, usted puede asegurarse de que la calidad de los datos será mejorada o favorecida cuando los datos son movidos o transformados. Asegúrese de hacer siempre valer la calidad de los datos utilizando controles tanto estáticos como de flujo.

Abordar el procesamiento de errores. Con ODI puede abordar los casos de errores en paquetes, lo cual le permite secuenciar cualquier cantidad de pasos. Cada paso en un paquete puede fallar por alguna razón; por ejemplo, la base de datos de destino o de origen está caída, o se detectan demasiados errores en una interfaz. Cuando se construyen paquetes, tenga en cuenta los diferentes tipos de errores que pueden surgir y causar una falla. Con ODI, este es un caso simple que consiste en definir el camino a seguir para obtener un estado OK, lo cual indica éxito, o un KO, que significa fracaso. Tales definiciones de ruta harán que los paquetes sean invulnerables.

Elegir el módulo de conocimiento correcto. La elección del módulo de conocimiento (KM) es fundamental en el diseño de interfaces. La elección del KM determinará qué funciones estarán disponibles y cómo será el rendimiento de la interfaz. Los principiantes a menudo cometen errores con los KM. Los nuevos diseñadores suelen elegir un KM avanzado o complicado para conseguir que las interfaces entren rápidamente en funcionamiento y pasan por alto todos los requisitos necesarios para un KM. Por ejemplo, si elige KM de tecnología específica usando gestores, la interfaz no funcionará si la configuración del cargador no es la correcta. La mejor apuesta es comenzar a trabajar con KM genéricos (habitualmente SQL). Después de diseñar sus primeras interfaces, se puede cambiar a KM específicos –pero lea primero sus descripciones– y aprovechar todas sus características.

Los KM con características adicionales pueden perjudicar el rendimiento. Una inserción sencilla es más rápida de realizar que una actualización incremental. Si va a borrar los datos en el destino antes de la integración, no utilice una actualización incremental. Eso es exceso de ingeniería y causará una pérdida de rendimiento. Utilice el KM que se ajuste a sus necesidades. De manera similar, activar o desactivar algunas de las características del KM puede agregar pasos adicionales que perjudiquen el rendimiento. Las opciones por defecto de los KM son suficientes para que éstos funcionen. Después de ejecutarlo con las opciones predeterminadas, revise las opciones para determinar si alguna de ellas puede ser cambiada para adaptarse a sus necesidades. El KM y las descripciones de las opciones son una buena documentación para comprender cómo utilizar mejor los KM. Éstos ofrecen un marco potente que se puede utilizar en cualquier momento durante un flujo de integración en ODI. Muchos KM están listos para usar y toleran un gran número de funciones de base de datos.

Las mejores prácticas pueden ahorrar incontables horas en un proyecto de integración de datos, y obedecerlas cuando se trabaja con ODI generará éxito y ayudará a establecer un marco de trabajo para la integración de datos.