El papel fundamental de la arquitectura de datos (en un mundo centrado en el análisis)
Hay un dicho en el ejército: “Los aficionados discuten tácticas, pero los profesionales estudian logística”. Ese pensamiento puede sorprender a algunos a primera vista, cuando se piensa en la brillantez de Lee en Chancellorsville o en el genio de Aníbal durante las Guerras Púnicas; sin embargo, la historia señala que ni Lee ni Aníbal ganaron sus respectivas guerras. La razón principal fue la logística: la capacidad de mantener a un ejército abastecido con alimentos, ropa y armas en el momento adecuado y en el lugar adecuado. A pesar de las brillantes tácticas, fue la logística la que finalmente decidió la victoria. En otras palabras, la táctica te permite hacer el mejor uso de los activos que tienes en el campo, pero la logística te permite estar y permanecer en el campo en primer lugar.
Me gusta la analogía militar porque creo que tiene paralelismos con la forma en que suelen presentarse hoy en día las soluciones basadas en datos. El glamour de las “tácticas” (técnicas avanzadas de IA como aprendizaje profundo, clasificación de bosques aleatorios, aumento de gradiente, etc.) regularmente eclipsa la “logística” menos atractiva de las bases de la arquitectura de datos que posibilitan esas técnicas avanzadas.
El primer paso en una discusión sobre la arquitectura de datos es definir qué abarca el concepto de “arquitectura de datos”. Como era de esperar, la respuesta resulta ser matizada: tiene múltiples capas y facetas. Para ayudar a fundamentar el debate, es útil comenzar a pensarlo en términos del recorrido de los datos de telemetría recopilados. El diagrama a continuación muestra una canalización de datos de alto nivel, resaltando los puntos de contacto entre la canalización y la base de la arquitectura de datos.
El recorrido de cada elemento de datos comienza con su creación, a menudo seguido de una cierta cantidad de preprocesamiento antes de ser serializado y transmitido a un recopilador/agregador de datos, que normalmente reside en la nube. A continuación, el propio recopilador de datos puede (después de la deserialización y la ingestión) realizar algún procesamiento y enriquecimiento adicional antes de entregar los datos a un almacén de datos persistente y/o alimentar una canalización de análisis de datos. Finalmente, los resultados enriquecidos/analizados se ponen a disposición del consumo humano mediante una plataforma de visualización, e incluso pueden ser consumidos por sistemas automatizados en forma de entradas de retroalimentación para sistemas de circuito cerrado de autoajuste o autorremediación.
Una vez establecido el contexto de la canalización de datos, ahora podemos volver a la cuestión de comprender qué se entiende por “arquitectura de datos”. La primera respuesta, en el nivel más superficial, se centra en la sintaxis de representación y serialización de datos. Por ejemplo, si un evento de datos contiene un campo de objeto titulado "cliente", la vista sintáctica determina si esos datos se representan como una cadena, un UUID entero o algo más.
Sin embargo, si profundizamos un poco más, una segunda respuesta tiene que ver con algo más que la mera sintaxis: se trata de la semántica de los datos: tener una interpretación bien definida y consistente del contenido de los datos. Una vez más, utilizando el campo “cliente” como ejemplo, supongamos que se ha respondido la pregunta sintáctica: que, de hecho, el elemento de datos se ha definido como un campo de cadena. A continuación, la arquitectura de datos debe ser capaz de responder a la pregunta de significado/interpretación: ¿la semántica es la del nombre de una persona o la del nombre de una empresa? Si es el nombre de una persona, ¿es <apellido> o <nombre> o ambos? Cuando se combina con una sintaxis uniforme, la semántica consistente permite que el flujo de datos realice funciones como filtrado y agregación de datos de manera genérica y robusta, basándose en una interpretación lógica coherente del contenido de los datos. Además, el almacén de datos también puede realizar fácilmente consultas de datos federados en diferentes instancias del canal de creación de datos, siempre que los datos creados sigan una sintaxis y una semántica consistentes.
Por último, profundizando aún más, en muchos casos es importante tener una tercera capacidad en la arquitectura de datos: un vocabulario para contextualizar la telemetría y razonar sobre los datos en sí: el vocabulario de metadatos. Esto es especialmente importante en el contexto de los requisitos de gobernanza de datos empresariales, ya sea para cumplimiento, auditoría o incluso para flujos de trabajo internos que requieren una comprensión holística de los datos que se gestionan dentro de un almacén de datos. Los metadatos a menudo vienen en forma de anotaciones en los datos y estas anotaciones siguen el mismo tipo de consistencia sintáctica y semántica que los propios datos. Por ejemplo, los campos de metadatos probablemente se utilizarían para registrar la identidad de la fuente de datos, la línea de tiempo del procesamiento de los datos recopilados y para cumplir con el requisito legal de retención de datos.
Otra forma en que se pueden utilizar los campos de metadatos en el léxico de un esquema de descripción de datos es razonar sobre aspectos de los campos de datos en sí, como la ordinalidad de un elemento de datos o las sensibilidades de privacidad. Volviendo a nuestro ejemplo del campo de datos "cliente" una vez más, las anotaciones de metadatos en el esquema de datos pueden marcar el elemento de datos como único , mientras que las anotaciones adicionales, en el contexto de un flujo de datos (como para transacciones de compra minorista), pueden marcar elementos de datos como obligatorios y únicos; en otras palabras, los metadatos se utilizarían para indicar que el campo customerID debe ser único (utilizable como una clave de base de datos principal) y que cada evento de compra debe tener un, y exactamente un, customerID asociado. La utilidad de la totalidad de las capacidades de metadatos, dentro del contexto de la cadena de suministro de datos, es el hecho de que pueden aprovecharse para agregar anotaciones para el cumplimiento de los datos, proporcionar un léxico de enriquecimiento de datos y habilitar flujos de trabajo de gobernanza flexibles para el almacén de datos.
Así que, en resumen, la respuesta a la pregunta: “¿Qué es la arquitectura de datos?” es que, como mínimo, se trata de proporcionar un marco que permita la coherencia, tanto sintáctica como semántica, de los datos que se recopilan. Además, una arquitectura de datos robusta también debe abarcar una estrategia de metadatos que sea lo suficientemente potente no solo para especificar restricciones sobre los datos, sino que también incluya la capacidad de razonar sobre los datos en sí.
Cuando se considera un área de enfoque explícita y se ejecuta bien, una arquitectura de datos se parece mucho a una buena infraestructura logística militar. Al igual que en el contexto militar, proporciona una base que multiplica la eficiencia y robustez de todos los componentes de los sistemas que se construyen sobre ella, permitiendo que aquellos sistemas más visibles se aprovechen al máximo. En el contexto de un sistema de procesamiento de datos, la base de la arquitectura de datos proporciona las bases para modelos más flexibles y potentes para la gobernanza de datos, un intercambio de datos más sencillo entre fuentes de datos mediante un almacén de datos sólido y un enfoque más receptivo hacia la ingesta de nuevas fuentes de datos para la agilidad empresarial.