12137

Vista previa del material en texto

Generador de arquitecturas de solución sobre el ecosistema Hadoop para
problemas de Big Data
BiDArch, Big Data Architect.
Julio Mario Sosa O.
UNIVERSIDAD DE LOS ANDES
Departamento de Ingenieŕıa de Sistemas y Computación
Bogotá D.C.
Mayo 2017
Generador de arquitecturas de solución sobre el ecosistema Hadoop para
problemas de Big Data
BiDArch, Big Data Architect.
Julio Mario Sosa O.
Tesis de Grado presentada como requisito para optar al t́ıtulo de Maǵıster en
Ingenieŕıa de Sistemas y Computación.
Director: Claudia Lućıa Jiménez Guaŕın, Ph.D
UNIVERSIDAD DE LOS ANDES
Departamento de Ingenieŕıa de Sistemas y Computación
Bogotá D.C.
Mayo 2017
Tabla de contenido
1. INTRODUCCIÓN 3
1.1. Problema a resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Objetivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Objetivo general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Objetivos espećıficos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Caracteŕısticas deseadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. ESTADO DEL ARTE 9
2.1. Big data players. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. AWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2. IBM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3. Hortonworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4. Cloudera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.5. MapR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.6. Dell EMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Arquitecturas referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1. Arquitectura Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. Arquitectura Kappa . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. Resumen y discusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. ESTRATEGIA DE SOLUCIÓN: BiDArch, Big Data Architect 25
3.1. Fase 1: Generación de un repositorio de descripción de herramientas. . . . . 28
3.1.1. Modelo de herramienta. . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.2. Repositorio ontológico de descripción de herramientas. . . . . . . . . 34
3.2. Fase 2: Caracterización de problema. . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1. Modelo de requerimiento. . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2. Modelo de problema. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3. Proceso de caracterización de problemas . . . . . . . . . . . . . . . . 40
3.3. Fase 3: Construcción de instancias de arquitecturas factibles. . . . . . . . . . 40
1
3.3.1. Modelo de arquitectura factible. . . . . . . . . . . . . . . . . . . . . . 41
3.3.2. Proceso de construcción de una instancia de arquitectura factible. . . 43
4. DISEÑO DE BiDArch 47
4.1. Consideraciones y restricciones de diseño. . . . . . . . . . . . . . . . . . . . . 47
4.2. Diseño de las ontoloǵıas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Hadoop Ecosystem Ontology . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2. Architecture Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3. Aplicación Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.2. Capa de proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.3. Capa de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4. Diseño de la arquitectura referencia empleada por BiDArch. . . . . . . . . . 60
5. DESARROLLO DE BiDArch, PRUEBAS Y RESULTADOS 63
5.1. Aportes y contribución. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.1. Ontoloǵıas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.2. Descripción de problemas. . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.3. Construcción de arquitecturas. . . . . . . . . . . . . . . . . . . . . . . 66
5.2. Detalles de implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1. Proyectos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.2. Implementación de interfaces WEB. . . . . . . . . . . . . . . . . . . . 70
5.3. Pruebas y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.1. Problemas modelados y soluciones obtenidas. . . . . . . . . . . . . . 74
5.3.2. Pruebas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.4. Discusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6. CONCLUSIONES Y TRABAJO FUTURO 89
7. BIBLIOGRAFÍA 91
8. ANEXOS 95
8.1. Atributos genéricos para instancias de problemas. . . . . . . . . . . . . . . . 95
8.2. Relación de las caracteŕısticas generales ofrecidas por las herramientas . . . . 96
2
1
INTRODUCCIÓN
Con la invención de las computadoras personales y la posterior construcción de la red
de redes, el hombre obtuvo un par de herramientas extraordinarias que han contribuido de
manera importante en el desarrollo de la humanidad en las últimas décadas. Desde entonces y
hasta la actualidad, estos dos particulares inventos han experimentado una serie de cambios
desenfrenados que trascienden del contexto tecnológico o de las máquinas y generan un
impacto innegable en la vida de todos los seres humanos, bien sea de manera directa o
indirecta.
Con la aparición de la Web como un servicio disponible a través de Internet, el hombre
empezó a generar información que le interesaba publicar para el consumo del resto de la hu-
manidad. En principio el proyecto WorldWideWeb permitió a los f́ısicos del CERN compartir
datos, documentación de proyectos y noticias. Luego con la comercialización de la misma,
cada vez más organizaciones y compañ́ıas le sacaban provecho, generando un crecimiento
importante en el volumen del contenido dispuesto. Posteriormente en el año 2002 con el salto
a su versión 2.0, cualquier individuo del planeta que tuviera acceso a ella es capaz de ge-
nerar contenido a su antojo, el cual naturalmente cuenta con una superlativa variedad y se
transfiere en flujos con altas velocidades.
Este acelerado crecimiento experimentado en el volumen de información guarda relaciones
directas con indicadores de penetración y tráfico en Internet. En la actualidad el 49 % de la
humanidad tiene acceso a Internet [1], y se espera un tráfico de datos con un valor aproximado
que exceda los 2.3 ZB (zetabytes) en el año 2020 [2]. Un factor que ha contribuido a tal
crecimiento es la existencia de una computación ubicua, que no es más que la tendencia a
colocar procesadores en cualquier dispositivo de uso diario, el cual en principio puede estar
en cualquier lugar y generar información en cualquier formato.
En este escenario en donde el hombre genera información heterogénea que puede ser
estructurada o no, a una alta velocidad, de manera masiva y en un gran volumen (con un
orden superior o igual al de los petabytes); surgen nuevos retos y problemas relacionados con el
descubrimiento, almacenamiento, procesamiento, y análisis de tal información. Para algunos
investigadores y expertos, esta problemática vista en gran escala se sale del entendimiento
humano, afirmando que el hombre se está ahogando con sus propios datos, debido a que las
máquinas no pueden ayudar lo suficiente.
Con base en el escenario anterior, un nuevo boom tecnológico y cient́ıfico emerge sobre
3
un concepto llamado big data y se interesa en un estudio de manera transversal a toda esta
problemática. Aunque no se cuenta con una definición muy clara de este concepto, lo cual
repercute en una enorme confusión y variedades de definiciones; enun alto nivel, un problema
de big data puede caracterizarse en principio en función de las siguientes tres propiedades en
los flujos de información: velocidad, variedad y volumen.
No obstante, en lo que se constituye el espacio tratable de estos problemas, se han identi-
ficado requerimientos en términos de escalabilidad, consistencia y disponibilidad en los flujos
de información para los diversos casos de uso de interés que son habilitados tras el imponente
crecimiento de la computación ubicua y de la Web.
Este asunto es de vital interés para la comunidad de cient́ıficos e ingenieros de datos, en
especial tras su posicionamiento en el pico de expectativas de la curva de Gartner de 2014 [3]
de tecnoloǵıas emergentes, y su desaparición en el año 2015. Lo anterior sin duda refleja que
ya el tema no es tratado como un estridente bombo de posibilidades futuras sino más bien
una creciente y sostenible realidad tecnológica que se encuentra en la práctica en escalas de
grandes organizaciones como Facebook, Twitter, entre otras más.
Uno de los proyectos más representativo de este boom, y con un aporte que nadie puede
desconocer, es sin duda alguna Apache Hadoop. Este proyecto que en principio era visto
como una promesa capaz de procesar escalablemente información en el orden de petabytes,
pasó de no lograr correr en más de una docena de nodos en el año 2005 a lograr demostrar
su escalabilidad en un cluster instanciado con más de mil máquinas en Yahoo en el año 2007
[4], sin embargo; el precio de lograr tal dimensión de escalabilidad en el procesamiento, para
ese entonces dejó de lado otros requerimientos importantes como la seguridad.
La existente dificultad para establecer una conexión que reduzca la brecha entre el cre-
ciente, variado y complejo dominio de problemas contextualizados como big data, y el conoci-
miento relacionado con el uso adecuado de las herramientas que en la actualidad se disponen
para satisfacer los requerimientos que presentan tales problemas, es el principal motivador pa-
ra este trabajo. Sin pasar por alto que los retos a superar en términos de diseño, arquitectura
e implementación de soluciones efectivas tienen una evidente elevada complejidad, en todos
estos procesos se presentan transversalmente requerimientos con magnitudes con una alta
demanda en dimensiones de volumen, variedad y velocidad en los flujos de información que
se manejan en general. En cuanto al volumen, los retos se relacionan con el procesamiento,
almacenamiento, y transmisión óptima de información que se encuentra en el orden inclusive
de los petabytes; por otro lado, los datos que la componen no solo provienen de sistemas
heredados donde son almacenados de manera estructurada, sino por el contrario provienen
de cualquier fuente donde cualquiera los genera en el formato que se le ocurre o le conviene,
y con la frecuencia que necesita o se le antoja.
Además, no solo se evidencia alta complejidad en el problema, también los requerimien-
tos funcionales y no funcionales que necesitan ser satisfechos con este tipo de soluciones,
impactan en la elaboración de complejas estrategias de solución que logren orquestar diver-
sos componentes relacionados con la tecnoloǵıa y las herramientas previamente seleccionadas
de un conjunto abrumador de posibles candidatos con múltiples configuraciones.
4
1.1. Problema a resolver.
La problemática tratada en este trabajo se relaciona con la complejidad que se presenta
a la hora de abordar el diseño, arquitectura e implementación de soluciones a problemas
tipo en el dominio del big data. Dentro de las caracteŕısticas más cruciales que determinan
su elevada complejidad se diferencian aspectos relacionados con elevadas proporciones en su
demanda natural de requerimientos en las dimensiones de volumen, velocidad y variedad de
los flujos de información que manejan este tipo de problemas. De la mano a este tipo de
problemas, la dif́ıcil selección en un vasto ecosistema conformado por el conjunto creciente
de herramientas que emergen con Hadoop como núcleo necesita ser orquestado de manera
adecuada para alcanzar la construcción efectiva de soluciones a tales problemas tipo. La toma
de tal decisión no resulta simple en la mayoŕıa de los casos y tiene que ir de la mano de los
objetivos propuestos a ser alcanzados con cada solución, puesto que en función de una selec-
ción determinada de múltiples opciones de configuración y parametrización se potencializa o
disminuye de manera importante diversos objetivos de interés como son el almacenamiento,
el procesamiento o la transferencia de información, entre muchos otros.
De forma natural, en este tipo de problemas resulta muy importante identificar con clari-
dad cuál es el objetivo que se busca maximizar con la solución, aśı como también tolerar que
al mejorarlo posiblemente se están debilitando las métricas de otros que resultan de interés
y están en contraposición con el principal. Por ejemplo, en el contexto donde el interés está
relacionado con el modelado y la persistencia de grandes volúmenes de datos puede resultar
no tan trivial discernir entre el uso de los gestores de almacenamiento HDFS o HBase y
la diversas opciones que ofrecen en términos de una serie de aspectos en los cuales se des-
tacan: los formatos de almacenamiento, la comprensión, multitenancy, y la administración
de metadatos. Otro ejemplo común donde se evidencia esta complejidad en la selección de
herramientas puede encontrarse en la ingestión por śı misma de los datos, en donde se tiene
que los datos provienen de una importante variedad de fuentes con velocidades distintas y las
necesidades pueden ir ligadas con interrogantes como: ¿qué tan rápido necesitan estar dispo-
nibles para ser procesados?, ¿cómo serán procesados?, ¿se requiere alguna transformación en
caliente o durante la ingestión? En general, esta complejidad aparece en todos los procesos, y
en especial en el de mayor impacto: el procesamiento de la información en todas sus facetas
y especialidades.
Esta problemática resulta de interés para una serie de roles dentro de cualquier organi-
zación que se motive en obtener soluciones construidas en la casa a problemas en el dominio
del big data que generen nuevo valor a sus procesos de negocio. Dentro de este conjunto de
roles en la organización se tienen: los grupos de desarrolladores de software que en últimas
son quienes implementan y hacen realidad dichas soluciones, los arquitectos de software que
directamente se enfrentan a tomar la decisión de qué herramientas usar y cómo deben ser
desplegadas en términos de configuración e interfaces de comunicación entre las mismas, los
administradores de recursos de infraestructura quienes deben velar por un uso eficiente de los
recursos que tienen a su cargo sin que se vean comprometidos sus servicios ofrecidos por este
nuevo tipo de soluciones. Sin embargo, no solo se ven afectados profesionales que guardan
alguna relación técnica o tecnológica con este dominio, sino también analistas que encuentran
en este tipo de soluciones habilitadores para construir modelos que aporten un valor extra
en los procesos a nivel de negocio, aśı como también de manera indirecta todos aquellos que
5
tengan la responsabilidad de tomar decisiones de negocio.
En un alto nivel, se puede fácilmente identificar tres enfoques en cuanto a alternativas de
solución para este tipo de retos. En primer lugar se tienen compañ́ıas que ofrecen soluciones
como un servicio con una penetración global del mercado, y cuentan inclusive con su propia
infraestructura distribuida en muchas partes del mundo. Este primer tipo representa un
escenario ideal para organizaciones con intereses superlativos en términos de seguridad, alta
disponibilidad, capacidad de almacenamiento y disminución de costos. Un segundo enfoque
de alternativa de solución son las organizaciones que ofrecen productos ya elaborados (y
previamente ajustados y probados)tanto a medianas como grandes empresas en despliegues
de infraestructura propietaria de sus clientes o a través de terceros. Finamente, están aquellas
compañ́ıas que cuentan con intereses innovadores o que se enfrentan a nuevas necesidades
como consecuencia de su crecimiento, y desean diseñar e implementar sus propias soluciones
a su medida en la casa, utilizando la extensa lista herramientas libres existentes en las cuales
se cimientan muchas de las soluciones de las anteriormente mencionadas. Son precisamente
este tipo de compañ́ıas, las más beneficiadas con un framework como el que se propone en
este trabajo, bien sea para un aprovechamiento netamente interno, o inclusive para construir
productos y servicios que puedan comercializar en un futuro. .
Para lograr la caracterización propuesta, se hace necesario identificar y definir expĺıcita-
mente casos de uso dentro de una muestra importante de problemas tipo en dominios donde
tiene aplicación el big data. Luego con los casos de uso identificados se establece un conjunto
de requerimientos relevantes e inherentes a cada caso de uso que necesitan satisfacerse para
alcanzar el objetivo del caso de uso en cuestión. Por lo anterior es necesario elaborar un
modelo que permita la abstracción y encapsulamiento de los problemas tipo en el dominio
mediante casos de usos y los requerimientos que definen y determinan a estos últimos.
Por otro lado, se requiere tipificar las herramientas del ecosistema alrededor de Hadoop en
conjunto con las múltiples interfaces y opciones parametrizables ofrecidas en ellas, guardando
una relación con la funcionalidad provista. También, construir modelos de configuración de
infraestructura cuando sean necesarios. Estas dos tareas se complementan con el objetivo
de orientar en el proceso de toma de decisiones relacionado con el diseño, arquitectura e
implementación de soluciones.
Finalmente resulta naturalmente pertinente la implementación de una solución de una
instancia de un problema tipo bajo las orientaciones ofrecidas por el framework.
1.2. Objetivos.
1.2.1. Objetivo general.
Construir un framework que permita generar soluciones de arquitecturas a problemas
tipo en el dominio del big data mediante una asociación entre los requerimientos relevantes
en los casos de uso t́ıpicos y las bondades ofrecidas por las tecnoloǵıas pertinentes dentro del
ecosistema de herramientas alrededor de Hadoop. De esta forma, se busca apoyar el diseño
y arquitectura de soluciones a problemas en este dominio.
6
1.2.2. Objetivos espećıficos.
Caracterizar problemas tipo en el dominio del big data en términos de requerimientos
generales y actividades requeridas por los mismos.
Definir las actividades requeridas de los problemas como la composición de una serie
de requerimientos funcionales y no funcionales que se resuelven con patrones de diseño,
arquitectura, implementación, configuración e infraestructura similares utilizando las
herramientas del ecosistema.
Construir una ontoloǵıa que describa el vasto ecosistema de herramientas que tiene a
Hadoop como núcleo en términos de sus funcionalidades individuales y la interacción
entre las mismas.
Definir un modelo de arquitectura referencia que encapsule la solución de instancias de
problemas tipo.
Construir un proceso que permita generar una instancia de arquitectura de solución en
función de los requerimientos y actividades requeridas de los problemas tipo, empleando
las herramientas en el ecosistema.
Instanciar un problema y obtener una arquitectura factible de solución generada a
partir del modelo de arquitectura referencia propuesto.
1.3. Caracteŕısticas deseadas.
El framework propuesto tiene definidos una serie de requerimientos a satisfacer que per-
mitan garantizar la efectividad y facilidad del uso de tal herramienta, para contribuir con
la construcción de arquitecturas y posterior implementación de soluciones a problemas en el
dominio del big data.
Estos requerimientos se listan a continuación:
Comprender una importante cantidad de problemas tipo en diversos dominios del big
data.
Describir claramente los problemas y sus requerimientos con un nivel alto de especifi-
cidad.
Conservar un alto indicador de completitud y profundidad en los detalles de las herra-
mientas del ecosistema alrededor de Hadoop.
Enriquecer el conocimiento de los usuarios ofreciendo justificaciones y recomendaciones
para una mejor toma de decisiones.
Navegar fácilmente entre la definición del problema y las arquitectura generada como
solución al mismo.
Mantener el mayor desacoplamiento posible en los componentes de tal manera que los
componentes de las arquitecturas se puedan remplazar fácilmente unos por otros.
7
Al considerar las caracteŕısticas deseadas presentadas anteriormente, se maximiza la pro-
babilidad que el usuario del framework encuentre una solución a su problema —tras asociarlo
a un problema similar— y logre determinar qué herramientas son necesarias para su solución
y cuáles pueden ser opcionales o reemplazables por otras.
8
2
ESTADO DEL ARTE
El proceso de diseño para la construcción de un componente que permita tratar la pro-
blemática previamente mostrada, requiere de una abstracción de los problemas tipo en el
dominio del big data mediante una identificación asertiva de casos de uso y su posterior des-
cripción en términos de una composición de requerimientos, para finalmente lograr obtener
una sugerencia de arquitecturas y consideraciones importantes en el diseño e implementación
de las soluciones. Por ello es importante realizar una revisión de las metodoloǵıas y herra-
mientas utilizadas por las grandes compañ́ıas interesadas y dedicadas en la construcción y
comercialización de productos o servicios que apuntan a resolverle este tipo de problemas a
otras organizaciones.
Algunas de estas enormes compañ́ıas, también denominadas big data players, ofrecen pro-
ductos que resuelven instancias puntuales y muy comunes de problemas en el dominio del big
data. De esta manera aprovechan un mercado muy valioso al proveer soluciones en diversos
campos como son: el análisis en tiempo real de la seguridad, la detección y control de ries-
gos en servicios financieros, la exploración automática de datos, el procesamiento de flujos
de información, la optimización en el almacenamiento de grandes volúmenes de datos, los
sistemas de recomendación, entre muchos otros más. Por otro lado, otras de estas compañ́ıas
se dedican a ofrecer servicios bien sea de infraestructura para el desarrollo y despliegue de
soluciones o de consultoŕıa para el diseño e implementación de las mismas. No obstante, y
de manera natural existen los competidores más grandes, los cuales no solo proveen infraes-
tructura auto administrable y escalable para atender los requerimientos de cualquiera de sus
clientes, sino que también cuentan con una amplia gama de productos y servicios que ofrecen
y generan un valor importante para los intereses de negocios de sus clientes.
Por lo anterior, resulta vital realizar una selección adecuada entre estas compañ́ıas con
una revisión de los problemas tipo en los dominios que manejan y los casos de uso soportados
en sus productos. No es menos importante, hacer una revisión de algunos surveys realizados
recientemente que tienen como objetivo dar a conocer herramientas libres para la construcción
de instancias particulares de problemas en el dominio del big data.
Por último, se realiza una comparación de los elementos que componen los productos
generados para resolver instancias de problemas particulares en el dominio, con los propios
de la metodoloǵıa propuesta para resolver el reto previamente planteado con base en las
caracteŕısticas deseadas previamente enunciadas
9
2.1. Big data players.
En la actualidad, los big data players conforman una serie de grandes compañ́ıas con
la capacidad de vencer todos los inconvenientes y problemas, que enfrentan muchas de las
organizacionesa quienes les interesa resolver problemas en el dominio del big data. Un grupo
importante de estas compañ́ıas cuentan con sus propias distribuciones de Hadoop en versiones
comerciales con un abanico de funcionalidades adicionales, que buscan apuntar a requerimien-
tos externos al problema en el dominio de big data de interés, pero que resultan ser factores
diferenciadores vitales para sus clientes en el momento de tomar la decisión respecto a qué
proveedor utilizar.
Entre estos elementos adicionales se encuentran: el soporte, confiabilidad y completitud.
Todas estas organizaciones que comercializan distribuciones especiales cuentan con un equipo
de profesionales capacitados para proveer asistencia y gúıa técnica, lo que le facilita a sus
clientes adoptar Hadoop para la implementación de sus tareas a nivel de negocio y aplicacio-
nes de misión cŕıtica. Además, estos vendedores responden prontamente ante eventualidades
detectadas y rápidamente ofrecen parches y mejoras continuamente que contribuyen en el
alcance de una evidente estabilidad en sus soluciones. Naturalmente, sus distribuciones van
de la mano con herramientas adicionales que representan un valor relevante para los clientes
al permitir ajustarse con una mayor precisión a los objetivos que interesan a sus clientes.
Naturalmente estas compañ́ıas no proveen de manera libre y abierta su experticia y sa-
biduŕıa en la construcción de soluciones de problemas del dominio de big data a través de
un artefacto que permita a cualquier interesado fácilmente alcanzar cierto nivel de cercańıa
a una solución efectiva y estable para sus problemas en el dominio. Por el contrario, real-
mente materializan todo ese conocimiento en productos con un objetivo de mercado puntual,
estos productos se encuentran valorizados por su capacidad para potencializar los procesos
de negocios de sus clientes y por el impacto que generan con los resultados obtenidos en sus
soluciones. De esta manera cada conocimiento y experiencia empleada para la elaboración de
las arquitecturas prototipo que permiten construir productos fácilmente replicables para sus
clientes, representa un alto porcentaje en el valor de sus soluciones y un factor diferenciador
con respecto a sus competidores.
No obstante, algunos expertos en el tema han realizado publicaciones importantes (no
necesariamente formales) que transmiten su experiencia en el uso de estas herramientas y
lecciones aprendidas relacionadas con escenarios en los que son útiles, aśı como la forma en
un alto nivel de cómo estas deben usarse. Dentro de estos se destaca la obra [4] de un grupo
de miembros de Cloudera que sirve como una gúıa de recomendación para el diseño de la
arquitectura de aplicaciones que necesiten el uso de Hadoop.
Se toma como referencia 6 (seis) de los big data players más importantes en la actualidad
que guardan relación con el objetivo de este trabajo: AWS [5] , IBM [6], HortonWorks [7],
Cloudera [8], MapR [9] y Dell EMC [10]. Cuatro de estos (IBM [6], Hortonworks [7], Cloudera
[8] y MapR [9]) tienen distribuciones que se encuentran posicionados como ĺıderes en el
cuadrante mágico de Forrester de distribuciones de Hadoop para big data del año 2016, por
su fuerte estrategia, oferta actual y presencia en el mercado [11]. Véase la figura 2.1.
10
Figura 2.1: Forrester WaveTM: Big Data Hadoop Distributions, Q1 ’16. [11]
2.1.1. AWS.
Sin duda alguna este es uno de los big data players más importante de la actualidad y dis-
pone de herramientas que soportan todas las etapas del ciclo de administración de los datos,
desde la colección de los mismos hasta el consumo de información útil o de valor. A través de
una extensa gama de servicios en la nube provee tanto frameworks con caracteŕısticas de alta
e inmediata disponibilidad y seguridad, como un ecosistema de soluciones por partners que
conforman toda una red denominada la AWS Partner Network. Este proveedor de servicios
en la nube que aprovecha la economı́a de escala, ofrece acuerdos de nivel de servicio con
indicadores exquisitos para cualquier interesado en adquirir este tipo de servicios.
Dentro de los frameworks de análisis de datos, se diferencian los que tienen como propósito
el procesamiento en batch de aquellos que están diseñados para el procesamiento en tiempo
real.
En la primera categoŕıa se encuentra el Web Service Amazon EMR (Elastic Map Reduce)
[12] que permite el procesamiento de una enorme cantidad de datos (comúnmente almace-
nados en buckets S3 o en la base de datos NoSQL DynamoDB) con Hadoop a lo largo de
un cluster de instancias EC2 de manera fácil, rápida y costo efectivo. Como alternativas a
Hadoop ofrece otros frameworks de procesamiento distribuido como Apache Spark y Presto.
Dentro de las facilidades más importantes ofrecidas en este servicio se destacan: la facilidad
11
de uso, el bajo costo en infraestructura, elasticidad y autoescalamiento del cluster, seguridad
y cifrado, y la flexibilidad obtenida por el control completo y absoluto de cada nodo en el
cluster. Dentro de sus principales casos de usos se tienen: el análisis de flujos de visitas por
medio de clicks, procesamiento de logs y la genómica.
En el procesamiento en tiempo real de flujos de información ofrece los siguientes servicios
Web:
Amazon Kinesis Firehose [13]:
Mediante este servicio Web se hace muy fácil la carga de flujos de información en
sistemas de almacenamiento o consulta de AWS como Amazon S3, Amazon RedShift
y Amazon Elastic Search y se habilita el análisis en tiempo real un orden no superior a
los dos minutos después de que los datos son enviados al servicio. Este servicio es auto-
administrable de esta manera automáticamente escala en CPU, memoria, y recursos de
red requeridos para la carga de los flujos de información necesaria. Entre sus principales
casos de usos tiene: Internet Of Things, mercadeo digital y la captura de información
móvil.
Amazon Kinesis Analytics [14]:
Permite el procesamiento cercano al tiempo real de flujos de información mediante in-
terfaces con estándares SQL, lo cual significa que no se presenta la necesidad de un
aprendizaje de nuevos lenguajes o frameworks de procesamiento e incide directamente
en su facilidad de uso. Dentro de sus funcionalidades se encuentran: los filtros, agre-
gación y enriquecimiento de la información contenida en los flujos. Este servicio es
auto-escalable y se ajusta al volumen y tasas de transferencia de la información que
ingresa al mismo.
Amazon Kinesis Streams [15]:
Es el servicio más flexible en el sentido que permite la construcción de aplicaciones
a la medida del usuario. Realiza la captura y almacenamiento desde cientos de miles
de fuentes de datos tales como: transacciones financieras, publicaciones en redes so-
ciales, IT logs y seguimiento de eventos de localización. Con la libreŕıa KCL (Kinesis
Client Library) se realiza la construcción de las aplicaciones que consumen los flujos,
la publicación resultados en dashboards, generar alertas y muchas acciones más.
La figura 2.2 presenta cómo interactúan tradicionalmente estos servicios de la platafor-
ma para el procesamiento en tiempo real flujos de información. Un caso de uso para estos
servicios lo representan las aplicaciones Web que env́ıan información de click stream para su
procesamiento en tiempo real, permitiendo la elaboración de sistemas de recomendación de
contenido personalizado entre otras aplicaciones.
12
Figura 2.2: AWS Kinesis Services. [16]
2.1.2. IBM.
IBM cuenta con la Next Generation Architecture, una arquitectura de zona diseñada para
enfrentar el reto del análisis sobre el big data y al mismo tiempo producir nuevas ideas de
negocios reduciendo el almacenamiento y los costos de mantenimiento [17]. De esta forma
ofrece a sus clientes el big data y su análisis, como herramientas que les permiten superar la
competencia, el manejo y control de riesgos, y la toma de mejores decisiones.
La arquitectura capitaliza todos los tiposde datos existentes incluyendo flujos de infor-
mación en tiempo real, y aśı extiende el análisis convencional con funcionalidades predictivas
y cognitivas, con un soporte proactivo en cuanto a la seguridad y privacidad. Estas fuentes
pueden ser aplicaciones transaccionales, información proveniente de sensores, imágenes y vi-
deos, redes sociales o aplicaciones de terceros. En la arquitectura, se soportan casos de usos
comunes bajo el concepto de zonas, algunas de estas son la zona de procesamiento y análisis
de información en tiempo real, la zona de almacenamiento y exploración de datos, la zona de
análisis profundo de datos, y la zona para asuntos relacionados con EDW (Enterprise Data
WareHouse) y Data Smart [18]. Los casos de uso más importantes para este big data player
son: la exploración de big data, la vista 360 de clientes, la seguridad (en términos de detección
de fraude y el monitoreo en tiempo real) y el análisis de las operaciones para la mejora de
procesos de negocios.
13
Figura 2.3: Arquitectura de la red IBM Next Generation Network. [17]
Los cient́ıficos de datos de esta compañ́ıa consideran la veracidad como una nueva di-
mensión o variable a considerar en el clásico grupo V3 (volumen, variedad y velocidad) en
sus soluciones. Al introducir esta dimensión, es posible determinar el nivel de confianza en
cuanto a la calidad y precisión de la información para la toma de decisiones [19].
2.1.3. Hortonworks.
Este big data player que entiende a los datos como el activo más valioso, dispone de
plataformas de datos conectadas que ayudan a sus clientes a crear flujos de procesos para
transformar sus negocios. Dentro de los principales casos de uso soportados con sus productos
se encuentran soluciones de descubrimiento de datos, construcción de vistas simples de un
negocio, el análisis predictivo en flujos de información y la optimización en bodegas de datos
empresariales [20]. Estas aplicaciones se aplican en dominios de la industria como: la genera-
ción de alertas, servicios financieros, el cuidado de la salud, seguros, las telecomunicaciones,
el sector público entre otros.
También cuenta con un grupo de expertos que ayudan a sus clientes a implementar e
integrar plataformas de datos, el despliegue de casos de usos comunes y servicios de asesoŕıa.
14
Hortonworks está más orientado a ofrecer soluciones tipo en caso de usos comunes que
le representan beneficios en determinados mercados. Mediante una suite de soluciones co-
nectadas ofrece funcionalidades de extremo a extremo para información en movimiento o
persistente. Por un lado, el producto Hortonworks DataFlow (HDF) se encarga de la captu-
ra, análisis y entrega flujos de información proveniente de diversas fuentes del IoAT (sensores,
archivos de logs, click streams y muchos oŕıgenes más).
Hortonworks Data Plattform (HDP) provee la persistencia segura de los datos y el análisis
necesario para potencializar ideas de negocios en escenarios versátiles, estos incluyen desde
el procesamiento en batch hasta el procesamiento tiempo real y el streamming [21]. Esta
plataforma también ofrece funcionalidades de seguridad, gobierno y operación idóneas para
un nivel o ambiente empresarial. La figura 2.4 presenta las herramientas de la la plataforma
HDP clasificados por actividad.
Figura 2.4: Hortonworks Data Platform. [21]
HDInsight es una solución en la nube que ofrece en alianza con el partner Microsoft una
distribución de Apache Hadoop y Apache Spark completamente auto administrable y escala-
ble. Su diseño busca la reducción de costos de administración y un alto nivel de productividad.
Este servicio cuenta con un SLA con indicadores con un valor de 99.9 %, replicas automáticas
de datos, alta disponibilidad ofrecida por 24 regiones en 140 páıses del mundo, monitoreo y
seguridad a nivel empresarial; facilidad de uso, interacción y despliegue entre soluciones en
modo on premise y en la nube [22]. Dentro de las herramientas del ecosistema alrededor de
Hadoop disponibles en este producto se encuentran: Apache HBase, Apache Storm, Apache
Hive, Apache Kafka y por supuesto Apache Spark.
2.1.4. Cloudera.
Cloudera ofrece un extenso y variado portafolio de productos y servicios a sus clientes
con distintos objetivos o funcionalidades. Todos estos productos y servicios constitutyen
15
soluciones que permiten potenciar los procesos de negocios y se enfocan en aspectos como la
reducción de costos, la privacidad de sus clientes y las ventajas competitivas.
Las soluciones propuestas abarcan casos de usos como son: la identificación y mitigación
de amenazas cibernéticas, la reducción de riesgos de negocios, el entendimiento de los clientes
de una compañ́ıa, el mejoramiento de procesos y operación, entre otros. Tales casos de usos
son aplicados en diversos dominios de la industria tales como: los servicios financieros, las
telecomunicaciones, el sector público, el cuidado de la salud, entre muchos otros más [23].
Este big data player también cuenta con un equipo de expertos que acompañan a sus
clientes a optimizar las soluciones y ofrecen soporte predictivo y proactivo a clusters con
el framework Apache Hadoop que dispongan sus clientes como elementos vitales para sus
soluciones.
Cloudera Enterprise Data Hub es el producto estrella que comercializa esta marca en
conjunto con otros como Cloudera Analytic DB, Cloudera Operational DB y Cloudera Data
Science & Engineering [24]. Mediante este portafolio soportan la integración, el procesamien-
to, almacenamiento, análisis, y publicación de flujos de información con muchas herramientas
del ecosistema Hadoop. Tales servicios se encuentran unificados y blindados con servicios pa-
ra proveer seguridad al cluster. La figura 2.5 muestra la integración de las herramientas
empleadas en la arquitectura empresarial de Cloudera para la integración, almacenamiento,
procesamiento y análisis de big data.
Figura 2.5: Arquitectura de Cloudera Enterprise. [24]
2.1.5. MapR.
Este big data player declara su plataforma MapR Converged Data Platform como capaz
de integrar el enorme poder de Apache Hadoop y Apache Spark, soportando funcionalidades
relacionadas con el flujo global de eventos, el poder de las bases de datos en tiempo real,
16
y el almacenamiento en escalas empresariales para habilitar el desarrollo y despliegue de
soluciones [25]. Esta plataforma está compuesta de una mezcla de motores open source y
motores comerciales para proveer una plataforma de servicios de almacenamiento, bases de
datos y flujos de información. La plataforma se encuentra soportada sobre una infraestructura
abierta, segura, y rápida que reduce de manera importante el costo total de la propiedad, es
decir el costo asociado con la compra, despliegue, uso, mantenimiento y retiro de la misma.
Sus soluciones tienen un objetivo que está centrado en los negocios enfocados en los datos
y su valor, y que naturalmente como es de esperarse también apoyan necesidades cŕıticas de
negocio que no pueden permitirse o tolerar perdida de información. Dentro de sus soluciones
se destacan requerimientos de disponibilidad 24x7, la recuperación inmediata de nodos y
fallas en los sitios. Estas soluciones coinciden con casos de usos comunes como el análisis
en batch de información, las consultas interactivas y los flujos de información en tiempo
real en múltiples sectores de aplicación como son: IT, mercadeo, seguridad, gobierno, salud,
telecomunicaciones y operaciones de negocio [26].
La plataforma MapR Converged Data Platform cobmina la flexibilidad y la innovación
del ecosistema que tiene como núcleo a Hadoop con una capa de servicios de datos a nivel
empresarial. [27]
Figura 2.6: Plataforma MapR Converged Data Platform. [27]
Dentro de sus componentes, uno de los más importantes es el ssistema de archivos MapR-
FS que cuenta con funcionalidades como la capacidad de no solo hacer inserciones al final
sino una capacidad de lectura-escritura completa, montablecomo un sistemas de archivos de
red NFS y que al ser escrito directamente en un lenguaje como C++ y acceder directamente
al hardware de almacenamiento mejora dramáticamente el rendimiento y la facilidad de ad-
ministración. A diferencia de otras distribuciones de Hadoop, esta no requiere el aislamiento
y diferenciación de cluster para el procesamiento de diversas fuentes como archivos distri-
buidos, tablas de bases de datos y flujos de información en tiempo real, reduciendo costos a
medida que el despliegue crece.
Un aspecto importante es la existencia de un comité que continuamente prueba y valida
los proyectos principales Apache antes de incluirlos en la plataforma, y contribuye con códigos
17
y libreŕıas disponibles a través de repositorios en Github y Maven, lo que muestra un aporte
significativo en la comunidad libre.
2.1.6. Dell EMC.
Con la asociación de dos de las franquicias mundiales más grandes en el mundo de la
tecnoloǵıa, Dell EMC habilita que los negocios se capitalicen mediante predicciones derivadas
de los datos de una manera rápida, flexible y masiva. En la actualidad permite que sus
clientes almacenen, analicen y protejan sus datos. Por otro lado ofrece predicciones que
permiten entender el comportamiento de clientes, la optimización de operaciones, el control
de riesgo [28]. En cuanto a la infraestructura, permite escalar sin interrupciones y eliminar
el aislamiento de datos en las soluciones al utilizar el enfoque de un data lake, como un
repositorio centralizado, masivo y simplificado.
Dentro de sus productos o soluciones se tienen los siguientes tres grupos:
Isilon Solutions [29]: Isilon ofrece la flexibilidad, rendimiento y escalabilidad para sopor-
tar un amplio rango de soluciones en el ambito industrial (healthcare, entretinimiento,
combustibles, etc.) y en el ambiente de las tecnologias de la información (soluciones de
almacenamiento para big data y almacenamiento compartido)
ECS [30]: La plataforma de almacenamiento de objetos de Dell EMC, Elastic Cloud
Storage (ECS) está diseñada para aplicaciones tradicionales y de tercera generación al
ofrecer simplicidad, resiliencia y eficiencia de almacenamiento. Esta plataforma puede
ser desplegada en el hardware tradicional industrial de las compañ́ıas o como un servicio
totalmente administrado en la nube. Un logro muy importante alcanzado por esta
plataforma, lo constituye su posición en el punto más alto del cuadrante mágico de
Gartner para sistemas distribuidos y almacenamiento de objetos [31].
Boomi [32]:
Reconocido también como un ĺıder en el cuadrante mágico de Gartner para plataformas
de integración empresarial como servicios 2017 [33] y como un ĺıder por Forrester pla-
taforma como servicio para la integración dinámica e h́ıbrida para compañ́ıas [34], esta
plataforma apoya la integración, la administración de APIs, la consolidación de infor-
mación maestra, el intercambio de datos electrónicos EDI y flujos de trabajo. Dentro
de sus caracteŕısticas se destacan su naturaleza 100 % orientada a la nube, la velocidad
para configurar procesos de gestión e integración de datos y su facilidad de uso.
Este competidor que está más centrado en proveer infraestructura para construir solucio-
nes, ofrece un servicio de consultoŕıa para acompañar a sus clientes en todas las etapas de las
mismas, aśı como también programas de capacitación en temas relacionados con el big data.
2.2. Arquitecturas referencia
En esta sección se presenta un par de arquitecturas referencias construidas por individuos
con una importante experiencia en el diseño de aplicaciones o sistemas en el dominio de
18
interés. La exploración de este par de arquitecturas permite conocer cómo han sido afrontados
los retos intŕınsecos de la labor de diseño de un sistema de big data que ofrezca una serie de
prestaciones fundamentales.
A continuación se exploran en el orden: la arquitectura Lambda y la arquitectura
Kappa.
2.2.1. Arquitectura Lambda
La arquitectura Lambda —diseñada por Nathan Marz— es un framework muy útil a se-
guir para el diseño de aplicaciones big data. En ella se direccionan requerimientos comunes que
presentan las aplicaciones de este tipo basándose en la experiencia que su creador ha tenido
trabajando en sistemas de procesamientos distribuidos en Twitter [35]. Estos requerimientos
comunes pueden ser descritos en términos de las propiedades deseadas para un sistema de
big data como son: robustez, tolerancia a fallos, baja latencia de lecturas y actualización,
escalabilidad, generalización, extensibilidad, depuración y mantenimiento mı́nimo [36].
El problema de computar funciones de diversa naturaleza sobre un datatset arbitrario
es un problema muy intimidante. No existe una única herramienta que permita resolverlo
completamente. Por ello, es necesario usar una variedad de herramientas y técnicas para
construir un sistema de big data completo que proporcione dicha solución [36]. La arquitectura
Lambda resuelve este problema tras descomponerlo en las siguientes tres capas: batch layer,
serving layer y speed layer.
Todos los datos que ingresan al sistema son despachados tanto a la capa batch layer
como a la capa speed layer para su procesamiento. La capa batch layer se encarga de la
administración de la información maestra —un conjunto de datos inmutable que solo permite
la inserción al final— y precomputa las vistas en batch. La capa serving layer indexa las
vistas en batch precomputadas para que puedan ser consultadas a través de un mecanismo
con baja latencia y en un sentido ad-hoc. La capa speed layer compensa la alta latencia
de las actualizaciones a la capa serving layer y maneja únicamente datos recientes o frescos.
Por el diseño de esta arquitectura, se posibilita que una consulta pueda ser respondida como
la mezcla de los resultados provenientes de las vistas en batch y de las vistas construidas
en tiempo real [36]. En la figura 2.7 se ilustra el proceso descrito anteriormente con una
perspectiva en alto nivel.
19
Figura 2.7: Perspectiva en alto nivel de la arquitectura Lambda. [37]
La sincronización entre la operación de las capas batch layer y speed layer resulta cru-
cial. El aspecto más importante de la misma ocurre cuando la capa batch layer termina su
computo y se requiere remover información redundante de la vista speed layer antes de que
sea ingresada a la capa batch layer [38].
Las funcionalidades de cada una de estas capas pueden ser implementadas usando varias
de las tecnoloǵıas existentes en el big data. Por ejemplo, los datasets de la capa batch layer
pueden ser almacenados en HDFS, mientras que las vistas en batch pueden ser creadas por
MapReduce y dispuestas a la capa serving layer, la cual puede ser implementada usando
tecnoloǵıas NoSQL como Apache HBase. Las consultas a las vistas pueden implementarse
mediante tecnoloǵıas como Apache Drill o Impala. Finalmente tanto la capa de velocidad
puede soportarse con herramientas como Apache Storm o Apache Spark Streamming [35].
Considerando lo anterior, la descripción de la arquitectura Lambda encapsula funcio-
nalidades que son comunes a todas las distribuciones de Hadoop que los big data players
—presentados en la sección 2.1— han construido. La figura 2.8 presenta una instancia con-
creta de la arquitectura Lambda ejemplificando en que herramientas se apoyan cada una de
las capas en cuestión.
20
Figura 2.8: Perspectiva en alto nivel de la arquitectura Lambda. [35]
Sin embargo, esta arquitectura también tiene sus inconvenientes o dificultades. Uno de
los más importantes radica en que, al no contar con una herramienta capaz de realizar
los dos tipos procesamiento (batch y streamming), se requiere implementar dos veces la
lógica de los procesos: una implementación que reside en la capa de batch y otra en la
capa de velocidad. Lo anterior, tradicionalmente requiere de herramientas personalizadas que
permitan la integración de las dos fuentes de datos en mención [39].Otros inconvenientes,
también relacionados con el anterior, básicamente giran alrededor de los siguientes aspectos:
la dificultad de mantener un código en dos sistemas distribuidos en los cuales se esperan
los mismos resultados, la depuración de la ejecución en śı misma y la elevada complejidad
operacional de los sistemas que la implementan [40].
2.2.2. Arquitectura Kappa
Esta arquitectura diseñada por Jay Kreps, se enfoca en algunos de los inconvenientes
asociados a la arquitectura Lambda. Es importante tener presente que la decisión de adoptar
una arquitectura u otra para un determinado caso de uso, puede convertirse en todo un reto;
y una equivocación en la misma, significar serias consecuencias en la posterior implementa-
ción de la solución. Por otro lado, hay que anotar que esta arquitectura no remplaza a la
arquitectura Lambda, debido a que existen casos de usos que pueden ser desplegados perfec-
tamente bajo la arquitectura Lambda y no se pueden migrar a este patrón de arquitectura
[41].
La arquitectura Kappa es una simplificación de la arquitectura Lambda. Este patrón de
arquitectura de software remueve la capa de procesamiento en batch presente en la arquitec-
tura Lambda. Para remplazar esta capa, los datos son simplemente introducidos al sistema de
streamming rápidamente. Su almacén canónico de datos se define como un log inmutable que
21
sólo permite inserciones al final. Desde aqúı los datos son transmitidos a almacenes auxiliares
a través de un sistema computacional [42].
Uno de los principales motivadores para su invención es evitar tener que mantener dos ba-
ses de código para el procesamiento en batch y en streamming por separado. Su idea principal
es utilizar un único sistema de procesamiento simple para manejar tanto el procesamiento en
tiempo real como el reprocesamiento continuo de datos. Como consecuencia, la arquitectura
Kappa solo presenta dos capas: stream processing layer y serving layer. La figura 2.9
presenta una perspectiva de esta arquitectura.
Figura 2.9: Perspectiva en alto nivel de la arquitectura Kappa. [41]
La arquitectura Lambda requiere ejecutar todo el tiempo las dos tareas de procesamiento,
en cambio esta arquitectura solo requiere ejecutar una segunda copia del trabajo cuando es
requerida. Sin embargo esta arquitectura demanda temporalmente dos veces el espacio de
almacenamiento con respecto a la arquitectura Lambda y una base de datos que permita
escrituras de grandes volumenes de datos [40]. No obstante, la principal ventaja de esta
arquitectura no se trata de eficiencia: el principal beneficio obtenido con este patrón se basa
en la posibilidad de ofrecer a los usuarios la capacidad de desarrollar, probar, depurar y
operar sus sistemas en lo alto de un framework de procesamiento simple.
2.3. Resumen y discusión.
La revisión del conjunto de big data players seleccionados permite identificar en los casos
de uso y aplicaciones en los sectores comunes de la industria, las caracteŕısticas y actividades
demandadas por la mayoŕıa de los problemas tipos en el dominio del big data.
La tabla 2.1 compara los big data players seleccionados que disponen de servicios o pro-
ductos que satisfacen necesidades de los mercados o sectores de la industria relacionados a
través de casos de uso tradicionales.
22
Caso de uso Amazon IBM
Big Data Exploration 7 X
Data Warehousing X X
Enhanced 360o View of the Customer 7 X
Event-driven ETL X 7
On-Demand Big Data Analytics X X
Operations Analysis X X
Security and risk management X X
Smart Applications (predictive capabilities) X X
Tabla 2.1: Caracteŕısticas generales de los big data players.
Una observación pertinente que debe manifestarse corresponde con una diferencia im-
portante en la posición o rol que juegan las más desarrolladas de estas grandes compañ́ıas
frente a los problemas en el dominio del big data. Si bien, estas organizaciones cuentan con
un grupo de expertos que tienen una gran experiencia en el diseño y solución de sistemas
distribuidos que permitan el procesamiento escalable, es claro que su principal interés es
construir productos o servicios a problemas comunes para una serie de industria o mercados.
Entre tanto, el principal objetivo de este trabajo es apoyar a los arquitectos de compañ́ıas
con algún interés en elaborar soluciones in house a problemas o mecanismos que ofrezcan un
valor agregado en los procesos de su compañ́ıa.
Paralelamente, se descubren las herramientas del ecosistema alrededor de Hadoop que
cada una de estas organizaciones dispone en sus propias distribuciones de Hadoop o plata-
formas. La tabla 2.2 plantea una comparación de las herramientas alrededor del ecosistema
que utilizan un conjunto de las distribuciones asociadas a los big data players seleccionados.
23
Herramienta HDP CDH MapR BiDArch
Apache Accumulo X X 7 7
Apache Crunch 7 7 7 X
Apache Cascading 7 7 X X
Apache Drill 7 7 X 7
Apache Flume X X 7 X
Apache HBase X X X X
Apache HDFS X X X X
Apache Hive X X X X
Apache Hue 7 X X 7
Apache Impala 7 X X X
Apache Kafka X X X X
Apache MapReduce X X X X
Apache Oozie X 7 X X
Apache Phoenix X 7 7 7
Apache Pig X X X X
Apache Solr X 7 7 7
Apache Spark X X X X
Apache Sqoop X X X X
Apache Storm X 7 X 7
Tabla 2.2: Comparación de herramientas del ecosistema empleadas.
Con la exploración de los patrones modelos de arquitectura para la elaboración de sistemas
de big data, se identifican caracteŕısticas de diseño que permiten la ejecución de una serie
de actividades requeridas por los problemas en el dominio. Finalmente, una observación de
una caracteŕıstica vital para el funcionamiento en un ambiente productivo y administrable
lo demanda la necesidad de una actividad de orquestado o flujos de trabajo de las otras
actividades.
La tabla 2.3 presenta una comparación entre los distintos modelos de arquitectura refe-
rencia y el patrón de arquitectura propuesto.
Actividad Lambda Kappa BiDArch
Almacenamiento de datos X X X
Ingestión de datos X X X
Extracción de datos 7 7 X
Procesamiento de datos X X X
Consulta de datos X X X
Orquestado 7 7 X
Tabla 2.3: Comparación de arquitecturas referencias.
24
3
ESTRATEGIA DE SOLUCIÓN: BiDArch, Big Data
Architect
El propósito del presente proyecto es facilitar el proceso de diseño y arquitectura de
solución a instancias de problemas tipo en el dominio del big data. Para conseguir tal propósito
se requiere que el framework propuesto soporte con un nivel suficiente de completitud los
casos de usos directamente asociados a los problemas tradicionales en el dominio en mención.
De manera natural, se requiere de un análisis profundo de los factores y variables intŕınse-
cas en los requerimientos que en primer lugar caracterizan una variedad de problemas tipo,
y que finalmente hacen posible determinar y ponderar la selección de herramientas en la
construcción de patrones de solución. También se necesita representar el conocimiento útil y
relevante para el diseño de arquitecturas a estos problemas de una manera expĺıcita, clara y
concisa; materializándose en la generación de una combinación apropiada de las herramien-
tas en el ecosistema existente alrededor de Hadoop. Las arquitecturas de solución deben ser
construidas con base en los requerimientos, factores y variables consideradas en la caracte-
rización realizada de un determinado problema de interés y las bondades ofrecidas por las
herramientas en el ecosistema.
Evidentemente, un análisis profundo de las herramientas más relevantes en el ecosistema
es necesario, no solo para identificar los escenarios en las cuales éstas ofrecen las mejores
ventajas o garant́ıas sino también aquellos en los cuales no es recomendable utilizarlas. Tal
estudio permite conocer cuáles herramientas son compatibles y adaptables entre śı mediante
interfaces, aśı como también reconocer cuales pueden ser remplazadas por otras. Adicional-
mente, este estudio recopila conceptos relacionados a las herramientas para enriquecerel
conocimiento inicial del usuario respecto a los elementos dispuestos en una arquitectura de
solución, aśı como también recomendaciones en los parámetros de configuración relevantes
que contribuyen en el desempeño de sus soluciones.
En la sección 1.3 se describen las caracteŕısticas y requerimientos deseados que se esperan
satisfacer con la solución propuesta. En esta sección se presenta el framework BiDArch: Big
Data Architect que sigue una estrategia de solución segmentada en las siguientes tres fases:
1. Generación y administración de una ontoloǵıa que describa las herramientas en el eco-
sistema. Dicho repositorio de descripción debe permitir la expresividad en la descripción
y la computabilidad de cada una de las caracteŕısticas asociadas.
25
2. Caracterización problemas del dominio del big data en términos de las funcionalidades
que las herramientas ofrecen. Las caracteŕısticas en cuestión deben ser cuantificables y
computables.
3. Construcción de instancias de arquitectura factibles de una solución al problema.
Las fases de la estrategia presentadas en la figura 3.1 se encuentran fundamentadas en la
interacción de una serie de procesos macro que se apoyan en modelos con distintos niveles
de abstracción.
Figura 3.1: Fases de la estrategia de solución.
En el escenario ligado a la primera fase se identifica la existencia de un actor en rol de
administrador. Éste es responsable de construir y mantener la ontoloǵıa que describe las
herramientas en el ecosistema. Por lo anterior, es necesario la existencia de un mecanismo
online de administración de la ontoloǵıa que encapsula dicho repositorio de descripción, ya
que se deben satisfacer algunos requerimientos como: la inclusión de nuevas herramientas, y
la extensión y actualización del conocimiento relacionado con las herramientas ya incluidas en
el mismo. Teniendo en cuenta que el objetivo principal de este proyecto es la construcción de
instancias de arquitecturas de soluciones a problemas en el dominio del big data, se opta por
hacer uso de una herramienta ya existente para la generación y edición offline del repositorio.
No obstante, debido a la importancia que este mecanismo online representa, se considera su
existencia desde el diseño de la estrategia de solución propuesta. En la figura 3.2 se presenta
el diagrama de casos de uso asociado a la definición funcional del mismo. La implementación
de las funcionalidades de este mecanismo está concebida de manera parcial para un segmento
importante de la ontoloǵıa y acorde a los intereses de este proyecto, al no constituir el principal
objetivo del mismo.
26
Figura 3.2: Diagrama de casos de uso de la administración del repositorio de BiDArch
Finalmente, en el escenario que sintetiza o integra las fases de caracterización de problemas
y la construcción de instancias de arquitecturas de solución, se posiciona el usuario final de
BiDArch en su rol de arquitecto. Este actor tiene las siguientes responsabilidades:
1. Caracterización del problema.
Definir los atributos genéricos o descriptores del problema.
Definir los requerimientos generales del problema.
Definir las actividades requeridas del problema y sus respectivos requerimientos
especiales.
2. Construcción de una instancia de arquitectura de solución.
3. Interacción con una instancia de arquitectura factible.
La figura 3.3 sintetiza en un diagrama de casos de uso las responsabilidades del arquitecto
de soluciones en las fases de caracterización de un problema y la construcción de una instancia
de arquitectura de solución asociada.
27
Figura 3.3: Diagrama de casos de uso de BiDArch.
A continuación se detalla cada una de las fases propuestas en términos de los procesos
que las determinan y los modelos en los cuales éstos se apoyan.
3.1. Fase 1: Generación de un repositorio de descrip-
ción de herramientas.
El mecanismo idóneo para materializar el repositorio de descripción de herramientas al-
rededor de Hadoop lo constituye el uso de una ontoloǵıa. Con el framework de descripción
de recursos RDF (Resource Description Framework) se puede representar cualquier relación
entre un par de conceptos del dominio de las herramientas a describir, a través de tripletas
de la forma (Sujeto,Relación,Objeto). El framework RDF tiene caracteŕısticas que facilitan
la fusión de datos incluso con esquemas subyacentes diferentes y proporciona un modelo
estándar para el intercambio de información en la Web [43].
Adicionalmente, al aprovechar las bondades de un motor de inferencia —acoplado a la
ontoloǵıa— que utilice los hechos o tripletas dispuestas expĺıcitamente en la ontoloǵıa, se
dispone de un nuevo conocimiento —materializado en tripletas deducidas— a partir de reglas
de inferencias definidas en el mismo bajo los lineamientos de una serie de axiomas.
Es claro que aśı no sólo se ofrece la funcionalidad trivial de persistencia ofrecida por el
almacenamiento en un archivo o un sistema de bases de datos relacional, sino por el contrario
se dispone de un artefacto versátil que permite aprovechar propiedades intŕınsecas definidas
sobre los conceptos y relaciones a modelar como son: la generalización y especialización de
conceptos, y las propiedades de simetŕıa, reflexividad y transitividad de las relaciones entre
los conceptos. De esta manera se obtiene de manera indirecta un conocimiento o informa-
ción adicional. Por ejemplo: al representar expĺıcitamente que un individuo a1 de la clase
28
Actividad depende de otro individuo a2 dela misma clase, y que el individuo a2 depende
de la actividad a3. El motor de inferencia o razonador deduce que la actividad a1 también
depende de la actividad a3, debido a la propiedad de transitividad otorgada a la relación de
dependencia entre un par de individuos de la clase o concepto Actividad.
Las relaciones de generalización y especialización plasmado entre los conceptos o clases
de la ontoloǵıa representan otro ejemplo de los beneficios de la existencia de un motor de
inferencia. Para ilustrar esto se puede considerar que expĺıcitamente en la ontoloǵıa se ha
representado:
1. El infividuo f1 corresponde a una instancia de la clase BooleanValueFeature.
2. El individuo f2 corresponde a una instancia de la clase CategoricalValueFeature.
3. La clases o conceptos BooleanValueFeature y CategoricalValueFeature son
clases hijas del concepto o clase Feature.
Con la serie de condiciones anterior, el razonador infiere de manera indirecta que tanto
el individuo f1 y f2 corresponden también a instancias del concepto Feature.
Los beneficios ofrecidos por el motor de inferencia van de la mano con la existencia de un
lenguaje de consulta del conocimiento representado en tripletas que se encuentra contenido
en la ontoloǵıa denominado SPARQL. Este lenguaje ofrece la flexibilidad y versatilidad para
lograr el acceso tanto al conocimiento plasmado expĺıcitamente como el generado indirecta-
mente por el motor de inferencia de manera transparente.
Tras un estudio y análisis profundo de la documentación oficial de una serie de herra-
mientas previamente seleccionadas, el proceso de generación de la ontoloǵıa que encapsula el
repositorio de descripción de herramientas se apoya en el modelo de herramienta descrito
en la sección 3.1.1 con el objetivo de identificar una serie de aspectos que definen a cada
uno de los elementos del repositorio en mención descrito en la sección 3.1.2. La figura 3.4
describe gráficamente el proceso para construir el repositorio ontológico de descripción
de herramientas:
29
Figura 3.4: Fase de generación del repositorio de BiDArch.
A continuacion se define el modelo de herramienta sobre el cual se apoya el proceso y
se describe el repositorio de descripción de herramientas producido en esta fase de la
estrategia de solución
3.1.1. Modelo de herramienta.
Sea h una herramienta en el ecosistema alrededor de Hadoop, h puede modelarse como
la n-tupla:
h = (A,F, PC,CR, I) (3.1)Donde:
A = {ai} es un conjunto de atributos o descriptores la herramienta.
La tabla 3.1 presenta los atributos o descriptores ai más relevantes de una herramienta:
Atributo Descripción
hid Identificador único de la herramienta
hname Nombre de la herramienta
hurl URL del sitio oficial de la herramienta.
hcontext Contexto al que pertenece la herramienta
Tabla 3.1: Atributos genéricos de una herramienta.
30
Por ejemplo, para la herramienta Apache Flume [44] se presentan sus descriptores más
relevantes en la tabla 3.2
Atributo Descripcion
hid 003
hname Apache Flume
hurl http://www.wikibooks.org
hcontext Ingestión de datos
... ...
Tabla 3.2: Atributos genéricos de Apache Flume.
F = {f} es el conjunto finito de todos los features o caracteŕısticas f que ofrece la
herramienta h.
Un feature f de una herramienta es modelado como la pareja ordenada:
f = (fname, fvalue) (3.2)
Los componentes fname y fvalue corresponden al nombre del feature ofrecido y al valor
asociado al nivel de cumplimiento de la caracteŕıstica respectivamente. El dominio de
los valores de fvalue puede ser de tipo booleano o categórico (presentándose orden o no
entre las categoŕıas según el caso).
Por ejemplo, para la herramienta Apache Flume [44] se modelan algunas de sus carac-
teŕısticas o funcionalidades principales en la tabla 3.3
Feature Value
Feature Richness VERY HIGH
Configuration-Based True
Reliable True
Data transformation True
Timeliness of data ingestion Near Real Time Decision Support
... ...
Tabla 3.3: Caracteristicas o funcionalidades ofrecidas por Apache Flume. [44]
PC = {pc} es un conjunto finito con una serie de propiedades de configuración pc
importantes para la futura implementación de la herramienta.
Una propiedad de configuración pc es modelada como la tripleta:
pc = (pcname, pcdescription, pcsuggestion) (3.3)
Los componentes pcname, pcdescription y pcsuggestion de la formula (3.3) corresponden al
nombre, descripción y sugerencia recomendada de la propiedad de configuración pc
respectivamente.
31
http://www.wikibooks.org
Por ejemplo, algunas de las recomendaciones de configuración relacionadas con la he-
rramienta Apache Flume [44] se presentan en la tabla 3.4
Property Description Suggestion
Sources Batch
sizes
The number of events in a Flu-
me batch can have dramatic ef-
fects on performance.
Start with 1,000 events in a batch
and adjust up or down from there
based on performance.
Number of sinks More sinks consuming from the
same channel will resolve bottle-
neck.
The limitation with more sinks
should be the network or the
CPU. Unless you have a really
small cluster, HDFS should never
be your bottleneck.
Sink Batch Sizes It’s therefore important to care-
fully tune batch sizes to provide a
balance between throughput and
potential duplicates.
Easy to add a post-processing
step to remove duplicate records
Flume memory
channels.
The memory channel’s ability to
buffer events in the event of
downstream failure is limited.
If performance is your primary
consideration, and data loss is not
an issue, then memory channel is
the best option.
Flume file chan-
nels.
Since the file channel persists
events to disk, it’s more durable
than the memory channel.
Configuring a file channel to use
multiple disks will help to impro-
ve performance.
... ... ...
Tabla 3.4: Propiedades de configuración disponibles en Apache Flume [44].
CR = {cr} es un conjunto finito que contiene una serie de conceptos relacionados
alrededor de la herramienta.
Un concepto relacionado cr es modelado como la pareja ordenada:
cr = (crname, crdefinition) (3.4)
Los componentes crname y crdefinition corresponden al nombre y la definición del con-
cepto relacionado cr respectivamente.
A modo de ilustración en la tabla 3.5 se presenta la definición de algunos conceptos de
la herramienta Apache Flume.
32
Concepto Definición
Source It’s where data is either pushed to Flume or where Flu-
me is pulling from another system for data.
Channel Flume channels store events until they’re consumed by
a sink
Sink Sinks are what cause your data to land in its final des-
tination
Interceptors Java class that allows for in-flight enrichment of event
data.
... ...
Tabla 3.5: Conceptos relacionados con Apache Flume [44].
I = {i} el conjunto de las interfaces i de la herramienta h que permite su integración
con otras herramientas.
Una interfaz i es modelada como la pareja ordenada:
i = (itype, iname) (3.5)
Los componentes itype e iname de la fórmula (3.5)corresponden al tipo de y nombre de la
interfaz respectivamente. El dominio de valores del componente itype corresponde al conjunto
{in, out} y permite especificar si una interfaz determinada es de entrada o de salida.
La tabla 3.6 lista algunas de las interfaces existentes en Apache Flume.
Type Interface
in Avro
in Thrift
in JMS
in Kafka
out HDFS
out Hive
out HBase
... ...
Tabla 3.6: Algunas interfaces de la herramienta Apache Flume [44].
La Figura 3.5 presenta los principales componentes y aspectos considerados en la descrip-
ción de una herramienta y su interacción con otras en el ecosistema.
33
Figura 3.5: Modelo de herramienta.
3.1.2. Repositorio ontológico de descripción de herramientas.
El conocimiento relacionado con las herramientas en el ecosistema alrededor de Hadoop se
encuentra dispuesto en el repositorio ontológico de descripción de herramientas de BiDArch.
Dicho conocimiento es modelado a través de una especificación explicita de los conceptos que
se encuentran en el dominio de las herramientas del ecosistema haciendo uso de una ontoloǵıa
extensible.
Las herramientas del ecosistema consideradas en este trabajo se encuentran en uno de los
siguientes contextos: modelado y almacenamiento de datos, ingestión y extracción de datos
(movimiento de datos), procesamiento de datos y orquestado de flujos de trabajo. Indistinto
al contexto, existen una serie de caracteŕısticas generales y comunes a tenerse en cuenta
en la descripción de cualquiera de las herramientas en el ecosistema, como por ejemplo:
escalabilidad, latencia, usabilidad, etc. También existen algunas caracteŕısticas particulares
por herramienta en cada uno de los contextos mencionados, las cuales fundamentalmente se
relacionan con la naturaleza del objetivo particular a satisfacerse en cada contexto.
Algunas de las principales caracteŕısticas y relaciones modeladas en la ontoloǵıa son lis-
tadas a continuación:
Herramientas en un contexto.
Roles que ocupan herramientas en una arquitectura.
Caracteŕısticas clasificables por dominio.
• Caracteŕısticas generales de las herramientas.
• Caracteŕısticas en un contexto o familia de herramientas.
• Caracteŕısticas particulares de herramientas.
Caracteŕısticas con un valor con tipo de dato.
• Caracteŕısticas con valor booleano.
• Caracteŕısticas con valor categórico.
34
Formatos de archivos soportados por las herramientas.
Formatos de contenido.
Interfaces disponibles en las herramientas.
Conceptos relacionados.
Recomendaciones de configuración.
La selección de herramientas contenidas en el repositorio no pretende ser extensa en anchu-
ra con respecto a la enorme y creciente cantidad de herramientas de software libre existentes
que guardan relación con Hadoop y su ecosistema, por el contrario se prioriza la profundidad
en el estudio de las herramientas más relevantes dentro del ecosistema. En la Tabla 3.7 se lis-
tan las herramientas seleccionadas y contenidas en el repositorio descripción de herramientas
de BiDArch. Es importante mencionar que la mayoŕıa de estas herramientas corresponden a
proyectos de la comunidad de software libre ASF (Apache Software Foundation).
Contexto Herramientas
Almacenamiento de datos
Apache Hadoop HDFS
Apache HBase
Ingestión de datos
Apache Flume
Apache Kafka
Apache Sqoop
Procesamiento de datos
Apache Hadoop MapReduce
Apache Spark
Apache Pig
Apache Crunch
Apache Cascading
Apache Hive
Apache Impala
Orquestado Apache Oozie
Tabla3.7: Herramientas descritas en el repositorio.
Esta selección de herramientas es realizada en consideración con los siguientes aspectos:
Madurez y estabilidad.
Cobertura e integración con el ecosistema.
Popularidad comprobable en casos de éxito.
La Figura 3.6 muestra los conceptos de alto nivel modelados en la ontoloǵıa más relevantes.
Lo anterior con el propósito de presentar una vista parcial del modelo en el que se evidencien
las relaciones entre el concepto Tool —que corresponde a las herramientas en el ecosistema—
y los diversos conceptos que se relacionan con el concepto Feature —que corresponde a las
caracteŕısticas de las herramientas— en una gráfica.
35
Figura 3.6: Vista parcial del modelo de la ontoloǵıa que describe las herramientas.
El conocimiento contenido en la ontoloǵıa está en formato RDF y puede ser accedido a
través de cualquier endpoint que soporte SPARQL como lenguaje de consulta.
3.2. Fase 2: Caracterización de problema.
El objetivo primordial de esta fase de la estrategia de solución propuesta es lograr caracte-
rizar adecuadamente cualquier problema que un usuario de BiDArch — en rol de arquitecto—
pueda definir en términos de las caracteŕısticas y funcionalidades que ofrecen las herramientas
descritas en el repositorio presentado en la sección 3.1.2. En esta fase el proceso de caracteri-
zación de un problema utiliza el modelo de problema —el cual se apoya en el modelo de
requerimiento genérico — y el repositorio de descripción de herramientas generado
en la fase anterior para construir una instancia del problema de interés.
La figura 3.7 describe gráficamente esta fase de la estrategia ilustrando la interacción del
proceso que la define con los modelos requeridos para la instancia de un problema.
36
Figura 3.7: Fase de caracterización de problemas.
A continuación se describen en detalle el par de modelos requeridos y el proceso que
construye una instancia de un problema.
3.2.1. Modelo de requerimiento.
A continuación se presenta el modelo genérico de requerimiento sobre el cual se apoya el
modelo del problema descrito en la sección 3.2.2.
Un requerimiento genérico r de un problema puede modelarse como una tripleta com-
puesta de: un feature o caracteŕıstica rf , un valor a satisfacer rv y un peso o ponderación rw
que permite establecer una relación de orden en la relevancia e importancia con respecto a
los demás requerimientos en la lista. Lo anterior puede representarse como una tripleta de la
forma:
r = (rf , rv, rw) (3.6)
El feature requerido rf corresponde a una de las caracteŕısticas o funcionalidades ofrecidas
por las herramientas descritas en el repositorio que están definidas en la fórmula (3.2) del
modelo de herramientas presentado en la sección 3.1.1. El dominio de los valores de rv puede
ser de tipo booleano o categórico (presentándose orden o no entre los valores o categoŕıas
según el caso) y se encuentra en función del feature rf que se trate. Por otro lado el valor de rw
37
satisface la restricción rw ∈ {1, 2, 3..,10} y permite incrementar la importancia que presenta
un requerimiento con respecto a los demás en el proceso de selección de las herramientas.
De esta manera los requerimientos de un problema p en el que se desee resaltar las nece-
sidades de riqueza de funcionalidades y alta escalabilidad en contraste con capacidad
de cifrado y nivel de soporte de las herramientas, a modo de ilustración, podŕıan ser
modelados como se presentan en la tabla 3.8
ri rf rv rw
r1 Scalability HIGH 8
r2 Support level MEDIUM 3
r3 Feature richness HIGH 9
r4 Encryption True 4
Tabla 3.8: Ejemplos de requisitos de un problema.
3.2.2. Modelo de problema.
Este modelo tiene como propósito realizar la descripción, representación y abstracción de
problemas tipos en diversos dominios del big data. Tal caracterización se realiza en función
de una base de requerimientos descritos en términos de features o caracteŕısticas propias de
estos problemas, y las actividades requeridas que se asocian directamente con los casos de uso
que comúnmente tienen las herramientas en el ecosistema. Lo anterior es realizado tras una
clasificación adecuada en completitud de los dominios y contextos en los cuales se encuentran
los problemas.
De manera independiente a la particularidad del problema tipo que se quiera representar,
se espera que todos los problemas dentro del espacio de problemas tratables en el domi-
nio del big data con las herramientas en el ecosistema Hadoop, puedan ser naturalmente
representados bajo el siguiente modelo.
Siendo P el espacio de problemas tratables en el dominio del big data con las herramientas
del ecosistema, AG el conjunto de atributos genéricos del problema, RG el conjunto de
requerimientos generales y AR el conjunto con las actividades requeridas por el problema.
Las instancias de problemas son modeladas aśı:
P = {p|p = (AG,RG,AR)} (3.7)
AG = {ag1, ag2, ag3, ..., agl−1, agl} (3.8)
RG = {rg1, rg2, rg3, ..., rgm−1, rgm} (3.9)
AR = {ar1, ar2, ar3, ..., arn−1, arn} (3.10)
La colección de atributos genéricos AG no es más que un conjunto de descriptores que
contienen metadata e información relevante del problema que facilita la identificación, reco-
nocimiento y consulta del mismo por parte de los usuarios de BiDArch. Entre estos atributos
se destacan:
El t́ıtulo del problema.
38
Una descripción general del problema.
El dominio en el que se encuentra.
El creador de la instancia en cuestión.
La fecha de registro de la instancia.
En el anexo 8.1 se presenta una tabla con el listado de todos los atributos genéricos
disponibles en BiDArch.
El conjunto de requerimientos generales RG contiene las necesidades o requisitos rgi que
son comunes e independientes a la particularidad de un problema en espećıfico. Este tipo de
requerimientos se construyen con base en necesidades transversales a todos los problemas que
son en últimas satisfechas por funcionalidades o caracteŕısticas comunes de las herramientas
alrededor de Hadoop. Algunas de estas funcionalidades o caracteŕısticas se clasifican en la
siguiente lista:
Generales: latencia, throughput, escalabilidad, nivel de soporte, facilidad de uso, etc.
Desarrollo: costo de desarrollo, personalización, lenguajes de programación disponibles,
etc.
Rendimiento: performance, consumo de RAM, uso de operaciones de I/O, etc.
Recuperación ante fallos: recuperación automática.
Seguridad: autenticación, autorización, cifrado, etc.
Monitoreo: debugging, profiling, monitoreo y exportación de métricas.
El anexo 8.2 presenta una tabla con la relación de las caracteŕısticas apoyadas descritas
en el repositorio de BiDArch.
Las actividades requeridas por un problema sugieren requerimientos especiales propios a
cada una de ellas. Estos se encuentran enmarcados dentro de los casos de uso que normalmente
apoyan las herramientas del ecosistema, como son: almacenamiento, movimiento (ingestión
y extracción) y procesamiento escalable —en sus múltiples facetas— de grandes volúmenes
de datos. Por ejemplo, en el modelado y almacenamiento de los datos existen requerimientos
relacionados como son la comprensión, el sharding, la forma de acceso, etc. En cuanto al
procesamiento, los requerimientos pueden estar ligados a la naturaleza de la operación a
realizar, diferenciándose dentro de estas las labores de ETL y las tareas de consulta de
información.
Cualquier actividad requerida ari de la colección de actividades AR puede representarse
como una pareja ordenada compuesta por una actividad ai directamente relacionada con los
casos de usos tradicionales que tienen las herramientas en el ecosistema y un conjunto de
requerimientos especiales REi propios de la actividad ai como se modela a continuación:
ari = (ai, REi) (3.11)
REi = {rej} (3.12)
39
La tabla 3.9 define expĺıcitamente el conjunto de actividades {ai} que son apoyadas por
herramientas descritas en el repositorio de BiDArch y se asocian a la serie de