Gobernando la DATA con Informix

Generamos en el mundo alrededor de 1 exabyte de datos por día!. Producimos datos desde que nos despertamos, y también hasta mientras dormimos. Toda actividad nuestra se monitorea, mide y registra, y la tendencia va en ascenso. Pensemos que no solamente aquellos datos que se generan a partir de los sistemas en una empresa, son los que nos van a servir para dirigir nuestro negocio.

Existen muchos otros datos que se encuentran en crudo, muchos de ellos que están almacenados pero que no se han explotado aún, pero mucho más desafiantes son aquellos otros que no se registran aún, pero que se debería si se pretende ser más competitivo . El saber gobernar los datos radica justamente en el hecho de entender que son un activo más en la empresa, y como tal tienen que administrarlo a través de su ciclo de vida, como con cualquier otro activo. Por ejemplo, supongamos el caso de una empresa que elabora un producto, dónde se piensa que nace el producto?, cuando es elaborado?... en realidad mucho antes!. Tuvo que haber pasado por etapas preliminares de análisis, diseño, prueba e implementación, previo a su confección. Luego, se producirá, almacenará, distribuirá, venderá y entregará. Como vemos pasará por muchos estadíos el producto como dato, transitando y transformándose al paso de cada etapa. Sería ilógico pensar que el mismo producto fuese denominado diferente a lo largo del camino, pero si bien parece algo simple... sucede.

Tal como todo activo, el dato tiene su ciclo de vida: planificación, especificación, activación, creación y adquisición, mantenimiento y utilización, archivado y recupero, finalmente depuración. Asimismo, para administrar ese ciclo, el dato debe ser gobernado, y en el estricto sentido en lo que su gobierno significa, el mismo debe formar parte del set de responsabilidades del Data Manager (DM). Este rol abarca varias responsabilidades: planificación, control y entrega de activos de datos e información. El DM debe conocer y cumplir con las necesidades de información de los interesados en la empresa en términos de disponiblidad, seguridad y calidad de la información. Para asistir a la gobernabilidad existen varios marcos de referencia, TOGAF, COBIT, DGI, y DAMA.

En mi opinión una buena opción es la DMBOK, ya que es un marco de referencia para la Gobernabilidad de Datos bien articulado y generado por la organización DAMAI – la DAta Management Association International fundada en 1980. DAMA Internacional es una organización de voluntarios que se rige por una Junta Directiva Ejecutiva. El DMBOK es el producto de esfuerzos colaborativos internacionales dedicados a proporcionar la tan necesaria orientación sobre cómo gobernar y administrar los datos y los activos de información. Es un framework funcional que introduce conceptos e identifica objetivos, funciones, y actividades del DM, entregables primarios, roles, principios, tecnología, y cuestiones de índole cultural y organizacional. Describe buenas prácticas comúnmente aceptadas junto a enfoques alternativos.

El modelo DMBOK se muestra en la figura siguiente:

1 - Gobernabilidad de Datos

Es el ejercicio de la autoridad y control (planeamiento, monitoreo y ejecución) sobre la gestión de los activos de datos. Es la función core del DM debido a que interactúa con, e influye en, cada una de las otras 9 funciones.

2 - Gestión de Arquitectura de Datos

Define las necesidades de datos de la empresa, y el diseño de las vistas maestras para satisfacer esas necesidades. Esta función incluye el desarrollo y mantenimiento de la arquitectura de datos empresarial, dentro del contexto de toda la arquitectura empresarial, y su conexión con las aplicaciones de sistemas y proyectos que implementen la arquitectura empresarial.

3 - Desarrollo de Datos

Diseña, implementa, y mantiene soluciones para alcanzar las necesidades de datos de la empresa. Las actividades enfocadas en datos dentro del ciclo de vida del desarrollo del software, incluyen modelamiento de datos basados en estándares, análisis de requerimientos de datos, y diseño, implementación, y mantenimiento.

4 - Gestión de las Operaciones de la Base de Datos

Planeamiento, control, y soporte a bienes de datos estructurados a través del ciclo de vida del dato, desde la creación y adquisición hasta la purga de datos.

5 - Gestión de la Seguridad de los Datos

Planeamiento, desarrollo, y ejecución de políticas de seguridad y procedimientos para proveer la adecuada autenticación, autorización, acceso, y auditoria de datos e información.

6 - Gestión de Datos Maestros y Referenciales

Planeamiento, implementación, y control de actividades para asegurar la consistencia en los valores de datos.

Referenciales: Incluye control sobre valores de dominio definidos, términos estandarizados, valores de código y otros identificadores únicos, definiciones de negocio para cada valor, relaciones de negocio dentro y a través de listas de valores de dominio, y la consistente, exacta, oportuna y relevante referencia de valores de datos para clasificar y categorizar la data.

Maestros: Ejerce control sobre valores de datos maestros para permitir un uso contextual, consistente y compartido a través de los sistemas, de la más exacta, oportuna, y relevante versión de las entidades de negocio esenciales.

7 - Gestión de DataWarehousing y de Inteligencia de Negocio

Planeamiento, implementación, y control de procesos para proveer datos de soporte a decisiones y soporte para los trabajadores del conocimiento en reporting, consultas y análisis.

8 - Gestión de Documentos y de Contenido

Planeamiento, implementación, y control de actividades para almacenar, proteger, y acceder a datos que se encuentran en archivos electrónicos y registros físicos (incluyendo texto, gráficos, imágenes, audio y video).

9 - Gestión de MetaData

Planeamiento, implementación, y control de actividades para permitir fácil acceso a metadata de alta calidad.

10 - Gestión de la Calidad de los Datos

Planeamiento, implementación, y control de actividades las cuales aplican técnicas de gestión de calidad para medir, evaluar, mejorar, y asegurar la calidad de los datos para su uso.

Hoy en día se escucha mucho hablar acerca del CDO (Chief Digital o Data Officer), estos justamente son los roles correspondientes a quienes deban desempeñarse en la tarea del DM, protegiendo la data, construyendo credibilidad y confianza. Debe ser un garante de la calidad de los datos, de la utilidad de los mismos, así como de los beneficios comerciales por su exposición y apertura.

Resulta ser que con el tema de la entrada en vigencia del GDPR (General Data Protection Regulation -- La Regulación General para la Protección de Datos) muchas empresas con sede o clientes en Europa en los últimos meses, antes del 25 de Mayo 2018, salieron a la caza de estos individuos especialistas!. En rigor de verdad, el marco regulatorio ya había comenzado dos años atrás, el 24 de Mayo 2016, pero como siempre pasa, al no haber sido hasta ahora obligatorio, todo seguía igual, pero como ahora no solo es obligatorio sino que además de no cumplir la reglamentación serían sancionados con fuertes multas, contar con gestores de datos pasó a ser de un "sería bueno tener un DM" a un "más vale tener un DM".

La responsabilidad del DM debe ser compartida entre profesionales del departamento de TI y del Negocio (Data Stewards, DS), por eso a mi en particular, me parece más apropiado CDAO, donde el CAO conoce más acerca del negocio en sí, y que es lo que hay que hacer, mientras que el CDO está del lado más técnico, y del cómo hacerlo o soportarlo. Es decir que si bien entre ambos definen el marco (adaptan el DM Framework a los procesos de la empresa), uno estará más del lado del negocio (DS) y el otro del de la infraestructura para apoyarlo (TI). Esto obviamente no significa que no lo pueda desempeñar una sola persona con exposición a ambos ambientes, comúnmente y directamente conocido como CDO, pero es recomendable que sea compartida.

El CDAO debe tener una visión tal, que le permita darle valor a los datos. El dato por sí solo, no es nada, pero comienza a tener valor cuando pasa a ser usado, cuando le damos un contexto y un significado, alcanzando a tener su mayor aprovechamiento cundo se lo pone en perspectiva, se le aplica una métrica y compara contra otros valores. Todas las etapas del ciclo de vida del dato tienen un costo asociado, pero solo la etapa "use" agrega valor al negocio.

La ventaja de poder agregarle valor a los datos es una de las cosas que más le van a permitir a la empresa diferenciarse del resto y ser más competitivo. El 80% de las grandes empresas piensan que las iniciativas alrededor de Big Data resultan en mejores negocios. Justamente se estima que anualmente las grandes empresas pierden en promedio alrededor de 10 millones de dólares por realizar malos análisis.

En estos procesos de agregar valor a los datos, van apareciendo nuevos términos que tal vez no nos sean conocidos pero que forman parte de las tendencias, como lo es el "Data Wrangling".

La pirámide de la figura grafica este nuevo término, y es el proceso de mapear o transformar el dato que se encuentra en estado "crudo" o "bruto" en su base, en otro formato más apropiado y valuable para una variedad de propósitos posteriores, como el analítico. Mientras más ascendemos en la pirámide, mayor valor y utilidad le damos al dato.

Es también la pirámide coincidente con el fin que persigue Business Intelligence. Es aquel conjunto de procedimientos, técnicas y herramientas con el objetivo de transformar los datos en información, ésta a su vez en conocimiento, que finalmente permitirán tomar las mejores decisiones y transformar ese conocimiento en planes de negocio. Parece absurdo, pero la realidad es que la mayoría de las empresas involuntariamente no toman decisiones acertadamente. Es decir que con las mejores intensiones de negocio, sus planes están basados en sucesivas iteraciones intuitivas de prueba, error y corrección, basados en planes aproximados, en vez de estar basados en la apertura y exposición de datos, transformación a información y conocimiento, para permitir la evaluación de tendencias y predicciones. Por otro lado sus decisiones están basadas en procesar aquellos datos que solamente pueden ver, y resulta ser que es como el

nivel de flotación de un iceberg, donde solamente un 20% se ve, y el 80% está por debajo. El 80% que no ven, está compuesto por datos en "bruto" que tienen almacenados y no lo explotan, o bien aquellos que inocentemente colectan pero luego desprecian y descartan, o aquellos que jamás aún se les ocurrió colectar, y que podrían ser estratégicamente valiosos comenzar a guardar.

Veamos cómo ha ido evolucionando la tecnología de BI respecto al Modelo de Madurez del Data WhereHousing Institute. Se estima que a partir del 2002 comenzó la Era Digital. Antes de éste momento, los datos que se generaban a partir de los sistemas transaccionales eran los que se almacenaban y gestionaban internamente, y ninguna inteligencia de negocio era aplicada. Este estadío corresponde a la etapa "PRENATAL", donde se producen listados estáticos utilizados para trabajos operacionales. Esta etapa termina cuando comienzan a aparecer los "SpreadMarts". Aquí es donde comienza la etapa de maduración de BI llamado "INFANT", donde cada departamento en la empresa realiza aisladamente o en silos sus análisis estadísticos, solicitándole a sistemas, sets de datos, para luego utilizando Excel como "la" herramienta más poderosa y utilizada en esta etapa, generar enormes planillas de cálculo, y así representar gráficamente datos estadísticos.

Se sabe que por un lado, cualquier solicitud de datos a sistemas tarda un tiempo considerable, e independientemente del tamaño, estructura, ubicación y distribución geográfica de la empresa y sus clientes, la entrega de datos "debería" ser aprobada por el departamento de seguridad de la información. Por otro lado, la entrega misma del archivo de datos no debe ser tomado como un tema menor, ya que según los criterios de seguridad establecidos, el peso del archivo de datos a entregar y otros, el email no suele ser el medio permitido o con capacidad suficiente para tal efecto, además de que el destinatario debería de contar con la seguridad y capacidad necesaria para su recepción y tratamiento. Este procedimiento, no solo es tedioso, sino que además desalienta de esta manera cualquier necesidad de cambio en los datos recibidos, ya que debería de atravesar por todo el proceso de extracción, aprobación y entrega nuevamente... un larguísimo y lentísimo procedimiento.

En los 90's lo más cercano al procesamiento analítico eran las herramientas de Data WareHouse ROLAP que explotaban estas planillas Excel o bases de datos relacionales. Si bien en BI algunas herramientas ya incursionaban, como Cognos, nacido en 1969 y adquirido por IBM en 2007, MicroStrategy nacido en 1989, y Qlik en 1993, el punto de inflexión fue el 2002. Tableau nació en 2003 y Power BI (a comienzos conocido como Crescent) nació en 2010.

La distribución de Cognos eligió a Informix como plataforma por defecto para el almacenamiento de su metadata (content store). La opción de instalación "Ready to Run" de Cognos incluye un motor de Informix embebido.

A partir de ese momento, las herramientas de BI comenzaron a tomar relevancia, permitiéndonos pasar a la etapa de maduración del BI llamado "CHILD". En el modelo de madurez, es muy bueno poder pasar del la utilización de las planillas estáticas Excel a reportes a medida. Obviamente, existe una enorme resistencia del usuario por abandonar las planillas, pero el tema de la carencia de la calidad de datos producida por los silos aislados de datos obligan a saltar al siguiente nivel de maduración. Asimismo, la lucha por la supremacía entre las herramientas de BI recibieron el mensaje por parte de la presión ejercida por las necesidades del mercado. Estas herramientas no debían conectarse a las bases de datos relacionales directamente, es decir que ya no era suficiente y necesitaban escalar, incorporando al procesamiento OLAP el MOLAP, mejorando al ROLAP. El modelado de datos conjuntamente pasó a requerir utilizar otra arquitectura, no solo acceder a un esquema separado del transaccional, sino también un esquema basado en el modelo columnar, ordenado y organizado adecuadamente para el procesamiento analítico, es decir un Data Mart. Nótese que dije que NO debían de conectarse al esquema productivo directamente, porque los motores transaccionales (OLTP) tampoco estaban preparados para realizar consultas analíticas simultáneamente.

Para seguir madurando a la etapa "TEENAGER" de BI, y pasar de los Data Marts aislados al Data Warehouse, hizo falta evolucionar nuevamente en las herramientas de BI, con capacidades para representar dashboards (monitores) y scorecards (tableros de control), como así también hizo falta tener dispositivos que brindaran una mayor capacidad de escalar.

Así es como surgieron nuevos productos de BI, tales como las columnar DB: Vertica (2005), Teradata, y DWH Appliances: Oracle Exalytics (2011), Neteeza (2003 -- El primer appliance).

Netezza fue adquirido por IBM en 2010, y existe un importante antecendete que vale la pena mencionar en la historia de Netezza. Peter Gyenes fue el último CEO de Informix Corporation, quién estuvo a cargo de la empresa durante el último año. Impulsado por uno de sus mayores clientes, Wall-Mart, Peter dirigió la venta de Informix a IBM en 2001. En el año 2007 Peter Gyenes pasó a formar parte del board de directores de Netezza.

Todos estos productos, son eficientes hosts para alojar los diferentes modelos de negocio o Data Marts que a su vez conforman el Data WareHouse. Para todos ellos, en sus diferentes versiones, formatos, e implementaciones necesitan tener sus bases de datos actualizadas diariamente de la misma manera, a través de ETLs (Extract Transform y Load). Todos estos productos de BI necesitan de estos costosos procesos para integrar, acumular datos de negocio no volátiles y variables en el tiempo, para poder ser posteriormente explotados por las herramientas de BI. Se estima que en todo proyecto de BI la confección de los ETLs llevan un esfuerzo estimable al 60-80% del total. Además del tiempo de desarrollo, hay que tener en cuenta el tiempo de ejecución diario. Los sistemas no son estáticos, y los ETLs como parte de estos tampoco, y necesitan ser mantenidos. Los modelos de datos cambian a lo ancho y a lo largo. A lo ancho me refiero a que nuevos atributos pueden ser agregados a la base de datos transaccional y transitivamente posteriormente a algún Data Mart. A lo largo me refiero a que se generan nuevos registros todos los días, y hasta el volumen tiende a crecer, por ende las tablas crecen. También puede suceder que nuevos procesos analíticos sean requeridos, dando lugar a nuevos ETLs.

Normalmente el Data WareHouse inicia con un Data Mart solo, correspondiente al modelado de alguna de las áreas de negocio de la empresa, y con el tiempo, se irán incorporando nuevos Data Marts. Por estas razones, los tiempos de ejecución de los ETLs tienden a alargarse y las ventanas de tiempo a achicarse. Posiblemente la ventana de tiempo disponible tenga que ser repartida entre cada vez más procesos de mantenimiento (resguardo, depuración y nuevos), que a su vez estos de mantenimiento con la dinámica de los datos vayan tomando más tiempo también. En el peor de los casos, si nuestro negocio es multinacional, la ventana de mantenimiento tiende a reducirse a cero.

Para pasar al estadío de la adultez en el modelo de la maduración de BI "Adult", las organizaciones para poder implementar iniciativas de BI, deben realizar una inversión económica considerable. Por lo cual, buscan rentabilizar lo mayor posible su retorno de inversión (Return On Investment, ROI).

En este estadío, BI se desarrolla desde un nivel táctico a uno estratégico, y toma un papel central como sistema de tecnología de la información, manejando las operaciones diarias de la empresa. Además, se comienzan a utilizar KPIs (Key Performance Indicator) para medir el rendimiento de la empresa y cumplimiento de los objetivos. Tres características importantes de este nivel son: Tienen Fuentes de datos de BI centralizadas, corresponde a aquellas empresas que han hecho el esfuerzo y sufrido el proceso de unificación de los silos de datos en un solo Data WareHouse, y que a su vez el mismo es compartido entre todos los departamentos de la empresa. Una Arquitectura de datos flexible que se adapta a los cambios de requerimientos de negocio. Técnica común utilizada es la de extraer la data sin transformar, se inserta en el área de staging del Data WareHouse, y las transformaciones se procesan off-line sin la necesidad de volver a la fuente. Esta técnica permite optimizar la ventana de procesamiento, y acelerar la activación del Data WareHouse. Otra técnica importante es crear un modelo de datos flexible utilizando capas de abstracción para que los diseñadores no necesiten escribir el modelo cada vez que la empresa reorganiza los informes, agrega o cambia productos, revisa reglas o informes comerciales. La característica final es que utilizan BI para todas las aplicaciones de misión crítica del negocio. Colectando data casi en tiempo real, dando lugar a un set de aplicaciones del tipo más operacional, también conocidas como IoT (Internet of Things), monitoreo de transporte, tráfico aéreo, optimización de ventas en call centers, sitios web, bancos, entidades financieras, y compañías de seguros. Además de la utilización de BI en monitoreo, las empresas definen métricas, indicadores claves de performance (KPI) alienando todos los objetivos comunes de negocio. Finalmente, las empresas en la adultez utilizan data mining y machine learning para predecir el futuro y aprender acerca del comportamiento de sus clientes.

En la etapa final de la evolución de maduración de BI "Sage" (Sabio), BI se convierte en un servicio completamente embebido dentro de los procesos centrales, aplicaciones y estrategias de lanzamiento al mercado de una organización. Aquí, BI se convierte en una utilidad que varias partes de una organización pueden aprovechar para resolver problemas de negocios y aprovechar las oportunidades de mercado. Como utilidad y servicio integrado, BI se transforma de un sistema informático monolítico a un servicio ágil y flexible que se adapta rápidamente a las nuevas y cambiantes condiciones de negocio. Pareciera ser irónico que de haber estado intentando desde la etapa inicial en centralizar, ahora estemos hablando de descentralizar. En realidad lo que se descentralizan son fundamentalmente las herramientas de BI a través del auto-servicio, y algunos procesos, pero la infraestructura de BI necesaria que permite una óptima performance, es decir el DW, debe seguir siendo centralizado y gobernado por TI.

En esta etapa del Modelo de Madurez de BI, las organizaciones remodelan BI en cuatro grandes formas: 1) Redistribuyen el desarrollo a los departamentos y líneas de negocio. Para poder federalizar el desarrollo, el negocio de BI tiene que estar bien normalizado y estandarizado. 2) Aprovechan los servicios web y de middleware para crear aplicaciones compuestas y combinadas. Combinar y cerrar el círculo entre la parte analítica y operacional sin cambiar el contexto de las aplicaciones, y de esta manera poder ejecutar operaciones de negocio y revisar sus resultados a la vez. 3) Incorporan modelos predictivos en aplicaciones operacionales para automatizar decisiones. Hoy en día se ha ido un paso adelante, y se embeben modelos predictivos con las aplicaciones online para evaluar o calificar los eventos a medida que suceden. 4) Aplican las capacidades de BI para ofrecer nuevos servicios de valor agregado a los clientes y proveedores. Se invierte el entorno de BI y se hace accesible al mundo externo, preferentemente hacia sus proveedores, por ejemplo Wall-Mart obtuvo una competitiva ventaja al darle a sus proveedores acceso a las ventas y al stock, haciéndolos responsables de mantener el stock mínimo.

Para el uso de BI, antes del "GULF" (1er abismo), la organización está equipada con su primer grupo de usuarios avanzados con la libertad de su departamento de TI para proporcionar información. Pero he aquí donde ocurre la brecha. Ese mismo grupo de usuarios avanzados establecidos que controlan los procesos y herramientas de BI, provoca que la organización se estanque y pierda la capacidad de empoderar verdaderamente a todos sus usuarios empresariales y no solo a los usuarios avanzados. Aunque es un estado utópico ideal a alcanzar, para superar este "CHASM" (2do abismo), las organizaciones mejoran aún más sus sistemas de incentivos para los usuarios comerciales (como el ejemplo anterior de Wall-Mart), al tiempo que proporcionan las capacidades de personalización para complementar el autoservicio. Aquí las herramientas se vuelven omnipresentes para el personal de la organización y su rendimiento aumenta.

En lo 90's Informix ya contaba con el procesamiento OLAP además del OLTP, optimizado enormemente después, a través de los AUTO* y del MULTI_INDEX_SCAN (permitiendo la utilización de más de un índice por tabla simultáneamente) para que fuera capaz de atender ambos tipos de procesamiento a la vez. Uno de los modelos más utilizados en el modelado BI es el star-join, donde la tabla de hechos referencia a múltiples tablas dimensionales. Este modelo está basado en un diseño columnar, a diferencia del modelo normalizado por filas, el cual es mucho más eficiente para el procesamiento analítico. El conjunto de todas estas tablas, forman parte del data mart que corresponde a un modelo de negocio, dentro del Data WareHouse. Entonces una consulta que involucra a la tabla de hechos y sus dimensiones podría ser acelerada enormemente si todos sus joins pudieran ser ejecutados en paralelo en forma simultánea.

Para aquellos que no conocen la historia de Informix, algunas de estas funcionalidades fueron parte un ambicioso proyecto nacido en los 90's, llamado "ArrowHead". La idea consistía en combinar el procesamiento analítico y transaccional en un solo server. La versión 11.70 en 2010, fue liberada al mercado con gran parte de estas funcionalidades analíticas... llegando hasta la actual versión 12.10 con más capacidades y mejoras.

El proyecto se completó en 2011 con la salida de Informix Warehouse Accelerator (IWA). Este producto es una base de datos columnar en memoria (IMDB), diseñada para explotar estas innovaciones asequibles en la tecnología de memoria y procesadores, y las tendencias de nuevas formas de aumentar el rendimiento de las consultas. Para optimizar la gran disponibilidad de memoria, comprime y mantiene todos los datos en memoria, eliminando la sobrecarga de I/O a disco. Para aprovechar los cachés más grandes, el acelerador optimiza sus algoritmos para paralelizar las consultas y minimizar la sincronización.

IWA cuenta con la interesante funcionalidad que permite mantener permanentemente actualizados los data marts, con aquellos INSERTs nuevos que se vayan produciendo en la base de datos. Por otro lado en vez de refrescar toda la data regularmente, soporta un refrescado particionado, es decir que se puede refrescar una dimensión o la tabla de hechos en particular sin tener que refrescar todo el data mart.

Las consultas que reciba el server Informix son evaluadas por el optimizador y redirigidas hacia el lugar dónde más eficientemente se pueda satisfacer su ejecución. De esta forma cualquiera de las herramientas de BI pueden ser utilizadas y sus consultas optimizadas a través de esta arquitectura de manera on-line. Así es como IWA maximiza el paralelismo y la velocidad, optimizando las consultas más de 100 veces en promedio, algunas hasta +700 veces. Tiene la posibilidad de escalar su capacidad horizontalmente utilizando commodity hardware.

Si bien es conveniente que los data marts sean refrescados eventualmente, no existen los tiempos enormes necesarios para confeccionar y correr los ETLs para cargar la data en los data marts. Los data marts pueden ser confeccionados utilizando una API para capturar el SQL a acelerar y generar el XML, o bien escribir el XML manualmente, y luego la data es tomada por IWA directamente desde la base de datos.

Asimismo, con la tendencia de las herramientas self-service BI y metodologías ágiles para el desarrollo de la inteligencia de negocio, promovidas por aquellas empresas ubicadas en las etapas de mayor madurez ("Adult", pero sobre todo "Sage"), ponen presión a estos procesos, que impulsan la descentralización e independencia.

Con la habilidad de poder estar continuamente refrescando la data in-memory, IWA permite tener la data siempre disponible y actualizada, posibilitando que el Data WareHousing Contínuo sea posible!.

Así es como IWA se convierte en aquel medio ideal para satisfacer estas necesidades analíticas de cara hacia la exigencias, necesidades y desafíos del futuro.

Otra característica fundamental de Informix relacionada a BI, y dentro de ésta del mundo Big Data, es aquella utilizada para los Sistemas de Misión Crítica según el estadío de madurez "Adult". Es la de contar con el mecanismo necesario para distribuir información entre los integrantes de un grupo de personas interesadas, el BlockChain.

El mundo BlockChain, es la última revolución tecnológica de las personas más vinculadas a los mercados financieros de vanguardia. Se dice que es una de las tecnologías que van a cambiar el mundo: es la columna vertebral de las criptomonedas, entre las dos más importantes: Bitcoin y Ethereum.

La naturaleza de blockchain radica en la seguridad, vendría a ser como un libro de asientos contables compartido, digno de confianza. Las entidades bancarias e hipotecarias quieren usarlo para revisar las escrituras de las propiedades y para el complicado proceso de rastrear toda la documentación.

Un ejemplo práctico de uso podría estar en la cadena de distribución a minoristas, donde sus distribuidores, empresas de logística y otros, van proporcionando información sobre el transporte de productos, desde que parten hasta que arriban al minorista. El blockchain registra la cadena de custodia para cada uno de estos envíos de bienes a medida que van transitando por los diferentes intermediarios, hasta llegar a destino.

La cadena de bloques registra cada uno de estos cambios bajo custodia, junto con la información sobre el envío(condición, temperatura, peso, etc.) en cada etapa. La información en el blockchain puede "disparar" el pago al fabricante cuando un bloque es añadido a la cadena, en respuesta a que el transporte recogió el envío en buen estado.

La información que se agrega a un blockchain es generalmente la misma que se almacenan en una organización de base de datos empresarial utilizando procesos comerciales existentes. En Informix se pueden crear Triggers Inteligentes para que automáticamente empujen datos específicos al contrato inteligente de blockchain, una vez que los datos están comiteados en la base de datos utilizando las aplicaciones de negocio normales. Por ejemplo, un proveedor que fabrica herramientas para un minorista puede crear envíos mensuales al minorista. El proveedor puede configurar un trigger inteligente para que dispare el dato necesario al blockchain del minorista tan pronto como los datos del envío están comiteados en la base de datos Informix del proveedor. Este mecanismo permite al proveedor participar en el blockchain del minorista casi sin impacto en sus procesos normales de negocios.

Otra característica más de Informix relacionado a Big Data, es que cuenta con la más eficiente tecnología para el uso de Series Temporales. A través de sus famosos DataBlades, y más de 20 años de experiencia en el tema, Informix posee la mejor arquitectura para el almacenamiento de este tipo de dato.

A mediados de los 90's Informix Corporation adquirió Illustra, y se concentró en la tecnología de base de datos relacional de objetos. Illustra, escrito por ex miembros del equipo Postgres y liderado por el pionero de la base de datos Michael Stonebraker, incluyó varias características que le permitieron devolver objetos completamente formados directamente desde la base de datos, una característica que puede reducir significativamente el tiempo de programación en muchos proyectos. Illustra también incluyó una característica conocida como DataBlades que permitía incluir nuevos tipos de datos y características en el servidor como opcionales. Estas incluyen soluciones a una serie de problemas a saber: Series Temporales, Datos Espaciales (Geodetic) y Multimedia.

En comparación a los motores con sistemas relacionales clásicos de Series Temporales, se estima que Informix ahorra entre 50-70% de espacio, la velocidad de carga e inserción de datos mejora entre 20-30 veces, y entre 70-90 veces mejora la capacidad de lectura para el tratamiento analítico/predictivo.

En los sistemas relacionales clásicos cada medición en el tiempo es un registro nuevo. Por ejemplo, en un sistema de monitoreo de ambientes en un hotel, utilizando medidores inteligentes, cada medidor tendrá su id, y a mediciones regulares a intervalos de 15 minutos tomará temperatura, nivel de monóxido de carbono (CO) y humedad. Cada medición repetirá el id y ocupará espacio para el TimeStamp, como se puede ver a continuación:

En Informix, para darle solución a éste problema, la arquitectura del DataBalde de TimeSeries, utiliza el modelado columnar o estrella. Se almacena físicamente ordenada, por lo tanto el número de registros en la tabla corresponderá al número de medidores que existan. El índice de la tabla está compuesto por el id únicamente, sin la necesidad de incluir el TimeStamp, por lo cual el espacio requerido se reduce drásticamente. Adicionalmente, al ser el índice pequeño y estar la data ordenada, se requiere menos I/O. La representación en Informix es la siguiente:

Podemos apreciar que en vez de haber un registro por cada TimeStamp o medición, hay tan solo un registro por cada meter o medidor.

Como si esto no fuera suficientemente apropiado, Informix permite utilizar TimeSeries a través de su interface Api REST

INSERT de una nueva medición:

curl -X POST 'http://myserver:27018/hoteldb/virt_ts_hotel_tbl/' -d '{"id":1,"Temp":25,"CO":0,"Hum":56}'

Sin entrar en más detalles relativos a las características de Series Temporales de Informix, la Api REST forma parte del juego del software de la capa media que habilita la comunicación entre clientes REST, MongoDB y MQTT y el server de Informix.

Big Data es Volumen de datos de gran Variedad y a gran Velocidad (3Vs), donde se entrecruzan datos estructurados y desestructurados. Mi opinión es que la base de datos no es un mero repositorio de datos estanco, eso era antes!... a partir de la era digital hubo una tendencia a pensar que las bases de datos relacionales al no poder satisfacer las nuevas necesidades de Big Data, debían ser sustituidas por las NoSQL (no es casual el origen del nombre NO SQL). Apache, en 2006 liberó su primera versión de Hadoop, inspirada en el trabajo "File System Google", publicado en 2003. Que si bien no es una base de datos, sino un framework, implementado a través del HDFS y sus técnicas de Map-Reduce, es un inmenso y distribuído FS, con la capacidad de escalar a nivel de procesamiento, y almacenamiento horizontal. No es una base de datos, porque no existe un esquema, solamente su NameNode registra en su metadata, en dónde (en qué DataNode) se encuentra físicamente cada elemento. También diría que las NoSQL, tampoco lo son. Ya partiendo desde el punto en que sus datos no son tipados, sus estructuras de datos no forman parte de ninguna metadata, y por sobre todas las cosas, sacrifican consistencia y atomicidad por sobre el particionamiento. Prefiero pensar que estos son grandes repositorios de datos, utilizados para diferentes y puntuales objetivos, para los cuales son altamente eficientes.

Los motores de base de datos relacionales libraron sus batallas y evolucionaron, así como Informix, a través de sus poderosos DataBlades, permite de manera nativa y con la arquitectura más eficiente, almacenar datos NO estructurados, y hasta no solamente poder interpretar JSON, sino además ser el reemplazo de MongoDB almacenando documentos en formato BSON, con el valor agregado de la transaccionalidad (consistencia y atomicidad). No nos olvidemos que las bases de datos NoSQL son BASE (Basically Available, Soft State, Eventually Consistent). Esto quiere decir que a través del particionamiento, se maximiza la disponibilidad o servicibilidad, manteniendo la consistencia de los datos a través de los nodos o cluster de manera eventual. No necesitan hacer JOINs, de ninguna clase, ni involucrar más de una colección o tabla de datos en la misma transacción... si lo necesitáramos hacer es porque la plataforma y modelo de datos seleccionado no es el correcto, y deberíamos de replantearnos la arquitectura elegida.

No solo hubo un resurgimiento de los motores de base de datos relacional, sino que además para Hadoop se lo hizo más amigable, y se lo complementó con herramientas de BI, tales como Hive (2010) y Spark (2014), para evitar las dificultades que significaban programar y algunas limitaciones de Map/Reduce, y además, para incorporar el lenguaje de base de datos SQL o HQL (HiveQL), tan familiar para los DBAs o simple de aprender para el resto. Este resurgimiento, significó que los motores de base de datos relacionales, comenzaran a incorporar nuevas capacidades, y en el caso de Informix, en aprovechar y optimizar sus poderosos DataBlades, que le permiten muy eficaz y eficientemente combinar procesamiento y almacenamiento de datos estructurados y desestructurados simultáneamente, mejor aún, en el mismo repositorio!.

Como mencioné anteriormente, las herramientas de almacenamiento de datos de Big Data, como Hadoop y NoSQLs, priorizan el particionamiento de datos en detrimento de la consistencia y atomicidad, y en éste sentido Informix, al ser ACID (Atomicity, Consistent, Isolation, Durability) compensa esta particularidad con una gran variedad de formas de replicación, al punto de poder transformar su arquitectura de particionamiento en BASE. La arquitectura de MongoDB se apoya en el concepto de particionamiento, y escala horizontalmente haciendo sharding de datos, asimismo Informix escala del mismo modo a través de una de sus opciones dentro de su tecnología de replicación ACTIVO-ACTIVO basado en Enterprise Replication, y de sharding para el particionamiento de datos, con el valor agregado que Informix puede escalar verticalmente.

A mediados de los 90's, el motor de Informix sufrió una gran rearquitectura, denominada DSA (Database Scalable Arquitecture), que involucró una revisión importante del core del motor, soportando el paralelismo horizontal y el paralelismo vertical, basado en un núcleo multi-threading (multi-hilo o multi-hebras) adecuado para el sistema de multiprocesamiento simétrico. Estos threads son subprocesos que corren en procesadores virtuales (VP), y a diferencia del resto de los motores relacionales existentes en el mercado, estos son invisibles al sistema operativo. Es decir que estos subprocesos, no compiten con el resto de los procesos del sistema operativo.

Administrar los datos de IoT es un Gran problema de Datos (juego de palabras en inglés -- IoT data management, is a Big Data problem). Otra característica más de Informix radica en ser la plataforma de base de datos elegida por IBM para implementar IoT (Internet of Things).

Esta tecnología puede ser aplicada con diferentes fines, tales como: Generar datos para la toma de decisiones, integrar dispositivos a diferentes sistemas y automatización de procesos.

Las proyecciones del impacto de IoT sobre Internet y la economía son impresionantes: hay quienes anticipan que en el año 2025 habrá hasta cien mil millones de dispositivos conectados a IoT.

Existen múltiples industrias apropiadas para la utilización de esta tecnología: transporte y tránsito, salud y medicina, manufactura, agricultura, energía, medio ambiente, telecomunicaciones, etc.

Dada la gran versatilidad de Informix, es capaz de formar parte de cualquiera de las tres capas dentro de la arquitectura de IoT: 1) Dispositivos Inteligentes de Generación de datos (devices), 2) En la puertas de enlace (gateway), donde se almacenan y consolidan los datos (reduciendo el tráfico de red), y 3) En el DataCentre/On-Premise o en la Nube (data systems), un servidor con procesamiento operacional transaccional recibirá y almacenará los datos, que en conjunción con IWA se podrá hacer el procesamiento analítico de toda la data.

La versatilidad de Informix está dada, entre otros, por la capacidad de invisibilidad. Cualquier SW que se embebe en un dispositivo para ser invisible, debe ser autónomo, es decir que debe poder estar siempre disponible, y para eso su administración debe ser auto-gestionada (para tunearse y sanarse).

En la misma figura anterior mostrando la arquitectura de IoT, a través del DataBlade Geodetic, se puede apreciar como en la primer capa, los camiones que representan la distribución de mercadería, Informix es la plataforma adecuada para implementar los dispositivos inteligentes para permitir realizar un seguimiento físico georeferencial del vehículo. El seguimiento puede ser adquirido si existen necesidades para usar un modelo geo-global en vez de uno plano. Es muy útil para realizar consultas analíticas de largas distancias espaciales, con el valor agregado de poder realizar cálculos muy precisos de latitud y longitud, que requieran cálculos de curvatura. Este DataBlade en combinación con el de TimeSeries, incluye la funcionalidad de permitir rastrear un objeto en movimiento capturando la información de ubicación del objeto en intervalos de tiempo regulares. Se puede usar esta extensión de búsqueda espaciotemporal para indexar los datos y luego consultar en tiempo o lugar para determinar la relación de uno a otro. Puede consultar cuándo un objeto se encontraba en una ubicación específica o dónde estaba un objeto en un momento específico. También puede encontrar la trayectoria de un objeto en movimiento en un intervalo de tiempo.

La indexación que utiliza Informix es R-Tree. Los índices R-Trees son estructuras de datos del tipo árbol, utilizados por métodos de acceso espacial, para la indexación multi-dimensional utilizadas en coordenadas geográficas, rectángulos o polígonos. Un uso común en el mundo real para un R-Tree podría ser almacenar objetos espaciales como ubicaciones de restaurantes o los polígonos de los que están hechos los mapas: calles, edificios, contornos de lagos, costas, etc. y luego encontrar respuestas rápidamente a las consultas como "Buscar todos los museos dentro de los 2 km de mi ubicación actual", "recuperar todos los segmentos de carretera dentro de los 2 km de mi ubicación", "encuentre la estación de servicio más cercana". El árbol R también puede acelerar la búsqueda del vecino más cercano para varias métricas de distancia, incluida la distancia del círculo máximo.

Resumiendo, Informix es la plataforma de datos que desde mi punto de vista se encuentra mejor calificada para conjugar el procesamiento analítico y transaccional, y en el sentido del modelo de maduración de BI, es la piedra basal para toda empresa que pretenda alcanzar el nivel “Sage”, por permitir el DW contínuo, reduciendo las ventanas de mantenimiento y expandiendo la disponibilidad del acceso distribuído de las herramientas de BI de auto servicio. Esta tecnología se apoya sobre un motor robusto, simple de administrar y poderosa capacidad de procesamiento.