Cómo transformar una compañía(III): Profundizando en la arquitectura de referencia

En entradas anteriores, comentamos la importancia de definir y priorizar casos de uso para transformar una compañía, y veíamos cómo la arquitectura de referencia es la expresión tecnológica de esos casos de uso. En este post, profundizaremos en la estructura de la arquitectura de referencia y qué aspectos técnicos deben tenerse en cuenta en su definición.

¿Cómo se estructura la arquitectura de referencia?

Independientemente de las herramientas y soluciones seleccionadas para componer la arquitectura, ésta requiere la configuración de capas de servicios que estructuren funcionalmente la arquitectura con vistas a su operación. De este modo, el diseño de la arquitectura de datos debe considerar las siguientes capas de servicios:

*Figura 1. Estructura de la arquitectura de referencia para análisis de datos*

Fuentes de datos: en esta capa se sitúan los sistemas, aplicaciones, dispositivos y bases de datos que constituyen el origen de datos que se emplean posteriormente en los procesos relacionados con la analítica de datos. Los datos de esta capa pueden encontrarse internamente en la organización (como en el caso de datos del CRM, información transaccional u operacional o las reclamaciones de los clientes); o fuera de la organización (como por ejemplo, opiniones en redes sociales, información Open Data o bases de datos adquiridas). En las arquitecturas de referencia Big Data, se permite la incorporación de cualquier tipo de datos, independientemente de su naturaleza.

Plataforma de datos: en la plataforma se dispone el conjunto de componentes que permiten a perfiles de análisis de datos e ingenieros, así como, a las soluciones de explotación el acceso, transformación y análisis de los datos en el momento en el que se requiera. En la plataforma se incorporan componentes de los siguientes tipos:
- Ingesta de datos: estos componentes aprovisionan las fuentes de datos contempladas en el diseño de la arquitectura, que en el caso de arquitecturas Big Data son de diversa naturaleza y características.
- Repositorios de datos: los componentes de almacenamiento mantienen los datos en la plataforma para su potencial uso o acceso posterior y pueden variar desde bases de datos y repositorios de información estructurada hasta Data Lakes que permiten el almacenamiento de información altamente desestructurada.
- Procesamiento de datos: estos componentes ejecutan tareas de limpieza, transformación de datos (para adecuarlos a las características exigidas para los tipos de análisis para los que se diseña la arquitectura) y entrenamiento de modelos. En el contexto de Big Data, el procesamiento de datos implica el tratamiento masivo y distribuido de datos por parte de componentes específicos para este fin.
- Gobierno del dato: los componentes de gobierno del dato permiten gestionar el dato a lo largo de su ciclo de vida, mejorando su seguridad y su calidad. Entre este tipo de componentes se encuentran los de monitorización y administración, que permiten gestionar los distintos servicios, componentes y datos de una forma eficiente y útil, y los de seguridad y privacidad, necesarios para evitar, entre otras cosas, el acceso a la plataforma por usuarios desautorizados o la divulgación de información sensible o confidencial.

Adicionalmente, la arquitectura de referencia debe incorporar funciones para orquestar la ejecución de procesos por parte de sus componentes, buscando la racionalización y optimización de las cargas de trabajo y del aprovisionamiento de recursos. Estas funciones son especialmente críticas en los escenarios típicos de Big Data, cuando se elevan las cargas de procesamiento y las exigencias de calidad de servicio.

Explotación: en esta capa se muestran los resultados técnicos y analíticos de una forma interactiva para lanzar, por ejemplo, las correspondientes acciones de negocio o estrategias. Así, un dashboard con los principales indicadores de negocio de un área determinada sería un ejemplo de solución de visualización perteneciente a la capa de explotación. Además, la capa de explotación también puede incorporar los interfaces con aplicaciones y sistemas que recogen los datos de la plataforma de datos para utilizarlos en su operación o enriquecer otros repositorios de datos.

On-premise o cloud, ¿dónde implementar la arquitectura de referencia?

Uno de los primeros pasos a la hora de diseñar e implantar una arquitectura de referencia consiste en decidir si el despliegue de la arquitectura se realizará en la infraestructura local de la compañía, en el cloud, o en una combinación de ambos (nube híbrida). De este modo, los aspectos a tener en cuenta en la elección de proveedores de servicios y componentes para la arquitectura varían en función del tipo de implementación.

Implementaciones on-premise

En el caso de implementaciones on-premise, donde la arquitectura se instala en la infraestructura local, una definición clara del roadmap de casos de uso es clave en la elección del hardware y componentes tecnológicos, debido a la alta inversión inicial en tecnología que requiere. De este modo, para asegurar la amortización de la tecnología, la totalidad de los casos de uso debe requerir el uso de alguno de los componentes tecnológicos de la arquitectura.

Por otro lado, si no se posee de una definición específica de casos de uso, será necesario ir hacia una distribución de Hadoop que permita una aproximación más generalista a la arquitectura de referencia ya que poseen la mayor parte de los componentes necesarios.

Implementaciones cloud

En el caso del Cloud, la abstracción tecnológica permite un nivel mayor de flexibilidad en la elección de tecnología para la construcción de los casos de uso. Aunque es una buena práctica la elección de un stack tecnológico estándar para la compañía, el despliegue en entornos Cloud facilita la configuración de servicios específicos fuera de la arquitectura de referencia para la construcción de casos de uso muy concretos, incluso provenientes de proveedores Cloud diferentes (entornos multicloud). De este modo, se facilita la definición de una solución de arquitectura de referencia concreta para cada caso de uso.

Criterios para elegir el tipo de implementación

A la hora de decantarse por un tipo de implementación u otro, el nivel de madurez de la arquitectura, el tipo de casos de uso a desarrollar y el método de explotación previsto de la arquitectura son muy relevantes.

Así, salvo casos de sensibilidad excepcional en los datos y volumetrías elevadas, el uso de entornos Cloud hace más fácil y rápida la exploración de datos para pruebas de concepto, y simplifica el modelo de outsourcing. De este modo, la compañía puede simplemente dar acceso al proveedor externo a los datos y éste se encarga de la configuración de la arquitectura y de la construcción de la prueba de concepto. En caso de éxito, el escalado a la arquitectura de la compañía es más sencillo si ya está en el Cloud, ya que sólo requiere el traspaso de las cuentas o dominios del proveedor en el Cloud.

En otro caso, como en el de arquitecturas on-premise, se requerirá la definición de directrices de operativización para que la solución y resultados de la prueba de concepto se transfiera del Cloud del proveedor externo a la infraestructura local de la empresa con las garantías necesarias.

Figura 2. Proceso de análisis y dimensionamiento de la arquitectura de referencia para análisis de datos

Los detalles técnicos importan, ¿qué hay que tener en cuenta?

Una vez identificados los requerimientos funcionales de la arquitectura de referencia, que vienen definidos por los casos de uso, es necesario plantear la definición de los requerimientos técnicos.

Sin un correcto diseño técnico e implementación de la arquitectura, los servicios desplegados no pueden entregar el valor para el que se conciben.

En la definición de estos requerimientos, se debe considerar:

Orígenes de datos: el número de fuentes de datos, su velocidad (RT, NRT, Batch) y la complejidad de ingesta tienen su impacto sobre los servicios que se han de desplegar.
Volumetría de datos: el volumen de datos a tratar define la capacidad de almacenamiento que requiere la plataforma, teniendo en cuenta las tasas de crecimiento derivadas de la implementación de los casos de uso.
Tipo de procesamiento: la exigencia de procesamiento en tiempo real para la ejecución de casos de uso analíticos impacta en la arquitectura a nivel de componentes y de dimensionamiento.
Requisitos en seguridad: los niveles de seguridad exigidos a la información, especialmente en el caso de datos sensibles, deben tenerse en cuenta de cara al almacenamiento y procesamiento de datos.
Entornos disponibles: en el diseño de la arquitectura, deben definirse el número de entornos diferenciados para el cumplimiento de los SLA de la compañía, y el tipo de separación que desea realizarse entre ellos (física o lógica). Como mínimo, se recomienda el uso de un entorno para desarrollo y otro para producción.
Distribución de la información: en la definición y construcción de la estructura de almacenamiento del Data Lake, se debe determinar el número de zonas de datos (landing, staging, golden area).
Frameworks y herramientas: en la definición de la arquitectura deberá determinarse si se plantea utilizar una distribución comercial de plataformas, sobre las que se certifica el funcionamiento de componentes concretos preinstalados sobre el clúster, o se plantea la configuración de los diferentes servicios desde cero.

Parámetros para el dimensionamiento de la arquitectura de referencia

Dimensionar la arquitectura de referencia puede encerrar una gran complejidad, especialmente en los casos donde el nivel de abstracción física de la arquitectura es menor (caso de arquitecturas on-premise). El dimensionamiento de la arquitectura de referencia tiene además gran dependencia del tipo de trabajos que quieren ejecutarse sobre ella (tareas de data engineering, analytics, o soportar un operacional). En todos los casos, para evitar desviaciones significativas respecto de las necesidades tecnológicas reales, se recomienda concretar en primer lugar la definición de los casos de uso a soportar por la arquitectura, realizar pruebas de concepto y escalar de forma progresiva el tamaño de la arquitectura.

El dimensionamiento de los clúster sobre los que se soporta la arquitectura de referencia tiene en cuenta los siguientes parámetros:

Tipo de nodo: Los diferentes nodos de un clúster se estructuran en base al rol que desempeñan en el mismo, y en el caso de arquitecturas on-premise, condicionan el tipo de servicios que pueden desplegarse sobre ellos. En el caso del Cloud, la configuración en base a servicios determina implícitamente los tipos de nodos necesarios para desplegar cada servicio.

Los diferentes tipos de nodos que se consideran en el dimensionamiento de clústeres de plataforma son:

Nodos máster: se encargan de gestionar el conjunto de servicios operando a lo largo del clúster distribuido.
Nodos worker: los servicios desplegados en estos nodos realizan la mayoría del trabajo de computación del clúster.
Nodos Edge: en estos nodos residen las configuraciones y servicios que actúan como enlace con el resto de la red de sistemas corporativa y entre nodos del clúster. De este modo, sirven como punto final para llamadas por REST API y conexiones de tipo JDBC/ODBC con, por ejemplo, un sistema informacional que actúa como fuente de datos.
Nodos de servicio: se encargan de alojar las consolas de administración de los distintos servicios de gestión del clúster, logs centralizados, planificación de trabajos, etc.
Nodos de seguridad: se despliegan los servicios de encriptación, autorización y autenticación.

Número de nodos: El número de nodos determina la capacidad de trabajo en paralelo del clúster y la fiabilidad de su sistema de replicación. En arquitecturas on premise, como mínimo, los clústeres de la plataforma deben contar con 2 nodos de tipo máster y 3 nodos worker para asegurar la replicación de los datos y el funcionamiento ante fallos eventuales del nodo. En el caso del Cloud, la configuración de la arquitectura en base a servicios permite la abstracción de la elección del número de nodos, teniendo en cuenta además que en ocasiones no se requiere alta disponibilidad en los escenarios de negocio. Por otro lado, las funciones de escalado automático en el Cloud permiten que el número de nodos crezca o decrezca en función de las necesidades.
Procesador: entre las características del procesador, se encuentran el número de cores de procesamiento y el tipo y gama del procesador.
Memoria: define las características de la capacidad de memoria RAM de la máquina.
Disco: hace referencia al número y características de disco duro que integra la máquina, definido por su capacidad de almacenamiento, tipo de disco, velocidad de transmisión y velocidad de rotación.
Tarjeta de red: hace referencia a la velocidad de transmisión del interfaz bajo el estándar Ethernet, tipo de componentes de red (switch, stack) y velocidad de comunicación entre racks de servidores para realizar el balanceo de carga.

En conclusión, el diseño de la arquitectura de referencia, estructurada en capas de servicios, está fuertemente condicionada por los casos de uso y el tipo de implementación elegido, donde la definición de los parámetros técnicos es clave para que la arquitectura entregue el valor esperado por el negocio.

Escrito por: Jesús Montoya Sánchez de Pablo y Óscar Lozano Colodra.

Todos los post de la serie «Cómo transformar una compañía»:

Movistar Prosegur Alarmas: La nueva Living App que muestra cómo ofrecer experiencias a través de la TVVideo Post #20: Datos para aprender