TECNOLOGÍAS E INFRAESTRUCTURAS

En esta ocasión vamos a explicar todo lo relacionado a tecnologías e infraestructuras Big Data, donde
vamos a entrar en el ecosistema Hadoop, y en todas las soluciones y componentes incorporados dentro
de este tipo de soluciones.

GENERACIÓN MASIVA DE DATOS, ¿POR QUÉ BIG DATA?

Vamos a imaginarnos el concepto Big Data, y

vamos a intentar explicar qué es Big Data. Para
ello, nos tenemos que imaginar la masividad de
datos que vamos a generar en el día a día.
Hoy en día, las redes sociales, los móviles, nos
permiten generar datos de una manera
exponencial. Podemos observar que cada minuto
se están generando tuits, unos cientos de miles de
tuits en el mundo.

Se están generando en redes sociales como

YouTube, como Facebook, como Twitter, como
comunidades de Google, todos esos son datos que
son tan válidos como cualquier otro dato que
genera cualquier tipo de periódico, solamente es
cuestión de explotar.

De todos esos datos que estamos generando el

80%, según los estudios realizados, suelen ser
datos no estructurados, datos que no tienen forma
alguna, pueden ser texto, imágenes, vídeos, pero
que en realidad tienen información. Nuestro
objetivo en este caso no es solo recopilar
información, sino también coger esos datos que no
tienen forma, organizarlos y estructurarlos y sacar
información. He ahí por lo que necesitamos Big
Data.
Los datos que se observan en la imagen son datos
reales, son ceros y unos a una velocidad
estrepitosa, una velocidad real. ¿Somos capaces
de ver información ahí? En realidad, no.
Necesitamos de alguna herramienta que nos
permita extraer esa información. La excusa es
usar Big Data. Vamos a dejar que nuestros datos
hablen, vamos a dejar que nos trasmitan la
información que está ahí contenida y que está
oculta. Ahí empieza el término de lo que es Big
Data.
tenemos una serie de definiciones como puede ser
la de Brian Hopkins, uno de los creadores de Big
Data, donde nos comenta que el gran problema de
Big Data es obtener el valor de la manera más
rápida posible con el menor coste y con la mayor
agilidad. Pero, la mejor definición es una creada
por uno mismo por ejemplo mi definición es: Big
Data es aquello cuya escala, diversidad y
complejidad requiere de nuevas arquitecturas,
técnicas y algoritmos para poder gestionarlo y
permita extraer valor y conocimiento que existe en
nosotros, pero que aparentemente está oculto.
Bien. Una vez que ya tenemos la definición de lo que es Big Data, vamos a ver cómo lo definen desde el
punto de vista de negocio en las empresas.
Normalmente, las definiciones son como el iceberg
típico como el que vemos en la imagen. Un iceberg
donde todo el tamaño de este son los datos. Sin
embargo, lo que nosotros podemos ver es solo la
parte de arriba, y debajo realmente hay
muchísimo más conocimiento que aparentemente
no se ve, pero realmente es información igual de
válida que la parte de arriba.
Si bien, esta ilustración puede ser muy
interesante, esta se queda un poco corta. ¿Por
qué?
Porque hoy en día la tecnología va muchísimo más rápida de lo que nosotros estamos preparados. La
asociación de Big Data podría ser como una ola gigantesca. Una ola que no solo trae información, sino
que trae tecnología también. Va muchísimo más rápido de lo que nosotros esperamos.
Esos datos se están generando de una manera tan rápida y tan inmensa que, si nos descuidamos, los
perdemos. Y la tecnología va tan rápida que, si nos descuidamos, estamos obsoletos. Por ello, el hecho de
ser un surfista y poder surfear a través de los datos y entre las distintas aplicaciones, nos va a permitir
de alguna manera extraer ese conocimiento a partir de la masividad de datos, con las tecnologías de hoy
en día.
Si bien, un surfista que está preparado para esto, muchas veces fracasa y se cae, pero vuelve a levantarse
y No pasa nada. Los datos se pierden, no pasa nada.
Por eso vamos a preparar las infraestructuras para que los datos no se pierdan y se vayan almacenando
de la manera más ágil, eficiente y rápida. Si perdemos una tecnología tenemos que recuperar los datos
con una nueva tecnología. Podemos hacer algo porque los datos los tenemos en origen, los procesamos,
los analizamos y sacamos conclusiones de nuevo. He ahí por lo que usamos en este caso el concepto de
una ola gigantesca o un tsunami, como el concepto de Big Data.

CONCEPTOS DE BIG DATA

A partir de ahora, nos adentramos en el mundo

Big Data, para lo cual es necesario tener claro
ciertos conceptos básicos sobre lo que es Big Data
y en lo que este se basa.

Uno de los primeros conceptos es el concepto de sistemas distribuidos. ¿Y qué es un sistema distribuido?
Un sistema distribuido está compuesto por n máquinas que dependiendo de la necesidad de las
aplicaciones que vayan a ejecutarse, se colocan unas u otras máquinas. Los sistemas distribuidos tienen
la característica de que son nodos independientes que están intercomunicados por la misma red, de
tal manera que, aunque cada máquina tiene su sistema operativo, por encima de ese sistema operativo
se tiene un software que se denomina middleware que permite intercomunicar y saber el estado de cada
una de las máquinas.
De esa manera, el sistema operativo hace su trabajo, pero las máquinas están comunicadas entre sí
mediante el middleware para poder transferir información, transferir procesos o cualquier otra orden que
sea necesaria.
Por encima del middleware se ejecutan las aplicaciones en una o n máquinas, dependiendo de la
necesidad. Es importante destacar que, de cara al usuario que está entrando al sistema distribuido, la
visión que tiene ese usuario es de una sola máquina, a pesar de que internamente tenga varias máquinas.
Se tiene que tener en cuenta que un sistema distribuido es un sistema complejo, es un sistema en donde
hay que tener en cuenta conceptos como replicación de datos, así como accesibilidad. Si uno de los
nodos (máquinas) deja de funcionar, es importante que el sistema siga funcionando. E incluso
escalabilidad. Es muy importante que, si el número de máquinas es insuficiente para las aplicaciones
que se están ejecutando, se permita de alguna manera escalar y ampliar el número de máquinas sin que
ello conlleve a la parada del resto de máquinas o a la incapacidad de poder responder por parte del
usuario.
 El siguiente concepto a tener en cuenta es el de
las 5Vs. Si bien la literatura a veces habla de las
cuatro o de las tres V, en nuestro caso queremos
hablar de las 5 Vs por la importancia de cada una
de ellas. Vamos a destacar cada una de las cinco
de manera muy breve.
El volumen, que es cantidad de datos que se
están obteniendo en plataformas Big Data.
La velocidad, en la que se están generando esos
datos.
personales, para lo que sea. Por lo tanto, el valor
es otro carácter muy importante.

La variedad, porque vamos a poder almacenar datos de distintos tipos, texto, imágenes, videos, audios,
cualquier tipo de número.
La veracidad, es algo muy interesante, porque los datos no tienen por qué están 100% seguros, pueden
ser opiniones, pueden ser datos que no están 100% seguros, puede haber anomalías, puede haber
outlaiers.
El valor, porque es muy importante saber que detrás de todo esto que estamos haciendo lo que intentamos
obtener es valor para nuestro negocio, para nuestros intereses.

Otro concepto que vamos a analizar es el de Map

Reduce. Es un concepto muy sencillo que lleva
existiendo desde hace muchos años, pero que también
se podría denominar divide y vencerás. Dado un
problema muy complejo muy difícil solucionar en un
tiempo razonable, lo que hacemos es dividir ese
problema en pequeños problemitas, actuamos sobre
esos pequeños problemitas, obteniendo pequeñas
soluciones, y luego agregamos esas pequeñas
soluciones, obteniendo la solución global.

En el ejemplo que vamos a poner, la idea es intentar contar el número de palabras. Imagina que tenemos
un conjunto de millones y millones y millones de palabras. Es muy costoso contar esas palabras. Pues el
concepto de Map Reduce lo que nos va a ayudar es a contar esas palabras de una manera muy sencilla.
Primero que todo, dividimos por frases. Por filas. Vamos a contabilizar, vamos a hacer un map que lo que
hace básicamente es preparar las palabras de manera individual y contabilizar esas palabras. Vamos a
agregar y vamos a juntar todas las palabras que son iguales. Y luego hacemos un reduce que lo que hace
es sumar, en este caso. Agregamos una información y devolvemos la suma de todas las palabras. Y ahí
un problema que es muy complejo, el simplificarlo lo máximo posible para obtener al final el resultado
que queríamos en un tiempo razonable. ¿Por qué? Porque hemos divido el problema en pequeños
subproblemas. Y esos problemas los hemos paralelizado, hemos contabilizado de manera paralela. Si bien
unimos los conceptos que estamos hablando, sistemas distribuidos y Map Reduce, podemos empezar a
intuir por dónde va el mundo de Big Data.

A continuación, vamos a ver el concepto del CAP

Theorem. EL CAP Theorem son tres conceptos en
realidad que son muy relacionados a cualquier
sistema distribuido y específicamente a las
soluciones Big Data.
El primer concepto de la C es consistencia. ¿Qué
quiere decir esto? Si yo accedo a un dato, y los
datos son de una manera determinada, y vuelvo a
acceder a ese dato, el dato debería de ser
exactamente igual.
Por otro lado, la accesibilidad, availability. Que
básicamente lo que dice es, si yo quiero acceder al
sistema para obtener un dato, el sistema tiene que
responder.
Y por último, Partition Tolerance, que básicamente es, independientemente del número de máquinas que
tenga mi infraestructura Big Data, si yo pierdo uno de los nodos, si yo pierdo una de las máquinas, el
sistema debería de funcionar. ¿Por qué debería de funcionar? Pues obviamente porque hemos replicado
los datos, hemos replicado los procesos y, por lo tanto, no pasa nada porque se pierda un nodo, porque
el sistema sigue funcionando con toda la información.
La unión de esos tres conceptos es lo que se denomina una plataforma Big Data perfecta, con una
accesibilidad del 100%. La realidad es que nunca un sistema de Big Data está accesible al 100%. Aunque
nos vamos aproximando cada vez más, 99,999%. Vamos por el buen camino, aunque, claro, nunca es
100% perfecto.

Uno de los conceptos clave son los datos. ¿Qué

tipologías de datos hay? Pues los datos pueden
venir de distintos tipos. Pueden venir de la base
de datos, pueden venir de un sistema de ficheros,
pueden venir de emails, pueden venir de websites,
pueden venir de redes sociales, pueden venir de
dispositivos o sensores IOT, pueden venir de
cualquier sistema multimedia, cámaras de video,
cualquier generador de video, audio, imagen.
Todas esas fuentes son aptas para poder generar
datos y poderse adaptar en nuestra plataforma
Big Data. Y esos datos pueden ser de tipo
estructurado, que significa que tiene una
estructura fija con una serie de columnas que
definen cada una de las características de
nuestros datos.
Pueden ser no estructurados, no está definida su estructura como, por ejemplo, las imágenes, los textos,
los videos, que no está definida claramente su estructura.
O puede ser una mezcla de ambas partes, estructurado, no estructurado, una mezcla conjunta es lo que
se denomina semiestructurado.
Prueba de ello son soluciones en las que tienes un conjunto de datos estructurado, como puede ser una
tabla, y uno de los campos de esa estructura es un campo de texto libre. Eso define una inestructuración
dentro de una estructura final de datos. Los datos se pueden generar de dos maneras, o bien ya los tienes
generados de antemano y esos datos simplemente puedes acceder cuando quieras, no se generan
dinámicamente, sino que ya están generados, a lo que eso se denomina batch. O los datos se generan
dinámicamente en tiempo real, a eso se le denomina accesibilidad o generación de manera streaming.

EL DATA LAKE

Uno de los conceptos más importantes a lo que

está orientado el mundo de Big Data es el
almacenamiento y gestión de los datos, o lo que
denominamos en su momento el "Data Lake" o el
Lago de Datos.

Para entender la necesidad del Data Lake es

importante hacernos una serie de preguntas, por
ejemplo:

¿dónde guardamos los datos?, ¿quién puede acceder a esos datos?, ¿quién puede almacenar los datos?,
¿quién puede modificar esos datos?, ¿cuándo podremos acceder a ellos?, ¿en algún momento, esos datos
modificados van a permitir de alguna manera poder llegar a los datos originales?
Todas esas preguntas requieren una respuesta y es ahí cuando se creó el concepto del Data Lake.

El Data Lake lo que nos va a permitir es almacenar

y obtener el dato en una estructura organizativa,
en una empresa, en un colegio, en una
universidad, donde queramos.

Es importante destacar que el Data Lake está

pensado para estructuras organizativas muy
grandes, tan grandes que no hay escala definida,
es interminable.
Por ello, el almacenamiento de datos es interminable, es totalmente escalable y por ello, es muy importante
organizar bien este almacenamiento de datos.
Para ello, creamos pequeños silos o denominados también "repositorios", que lo que nos permite es crear
zonas donde vamos a poder trabajar para una funcionalidad o una operativa determinada. Esa operativa
está definida "a priori", es decir, hay una necesidad determinada, tomamos esos datos que necesitamos,
los llevamos a nuestros repositorios, hacemos la operación que sea necesaria y, sin ningún problema,
como ese repositorio, está definido para eso, podemos trabajar con ese repositorio independientemente
del origen de los datos, ese origen de los datos queda guardado, sin ningún tipo de problema. ¿Qué pasa?
Que, con esos datos, podemos hacer varias operaciones. Creamos repositorios, un repositorio por cada
funcionalidad o cada operación que queramos hacer sobre los datos.
Lo importante es tener claro qué es lo que vamos a hacer, tomar los datos que vamos a necesitar y
copiarlos sobre los distintos repositorios.

Una de las características fundamentales del Data

Lake es que el contenido parece estar
centralizado, igual que en un sistema distribuido.
Nosotros tenemos la transparencia de que el
sistema parece único y que está todo centralizado,
de igual manera los datos parecen estar
almacenados en un solo sistema y estar todo
centralizado.
Pero en realidad, el Data Lake lo que nos permite
es tener los datos totalmente desubicados.
Otra de las características fundamentales del
Data Lake es la escalabilidad. Como hemos dicho
anteriormente, la escalabilidad es indefinida.
Podemos añadir cuantos datos queramos y está preparado el Lago de Datos para ser ampliado cuantas
veces queramos. Es importante también tener en cuenta que esa escalabilidad supone redundancia de
datos, replicación de datos y división de datos. Para eso están las plataformas Big Data, para permitir ese
tipo de cosas.
Y, por último, algo super importante es el control de acceso distribuido. Como es transparente el acceso,
tú no sabes en qué máquina estás accediendo. Pero lo que está claro es que cuando yo accedo, tiene que
estar controlado que yo voy a poder acceder a esos datos porque tengo permiso de acceder a ellos,
independientemente de en qué máquina esté y donde está el dato.

Nuestra recomendación en un Lago de Datos es

generar tres zonas. Esas tres zonas están
definidas según la necesidad de preparación sobre
los datos. La primera zona es "Landing". El
Landing llena los datos tal cual los obtenemos de
la fuente origen, y a eso se lo denomina los "datos
en crudo". Ahí se almacenan los datos y se
recomienda no tocarlos porque en cualquier
momento vamos a poder necesitar los datos desde
crudo para procesarlos u operarlos de cualquier
manera. Cuando los datos los operamos, los
procesamos, llevamos los datos de "Landing" a
"Staging".
¿Qué significa eso? La operación puede ser desde una simple normalización, anonimización, limpieza,
detección de outliers, cualquier tipo de operación. Esa operación, lo que nos dice es "ya no puede estar el
dato en Landing, sino que tenemos que llevarlo a Staging", pero en realidad seguimos teniendo el dato en
crudo en Landing y el dato procesado en Staging.
Ese dato procesado realmente no tiene la calidad que nosotros esperamos. La calidad que nosotros
deseamos, sólo la podemos conseguir si hacemos un procesamiento mucho más limpio, mucho más
preparado, con mucha más fuerza. Ese procesado, una vez hecho, la pasamos a la zona Gold. Los datos
ya están preparados y los consideramos de valor. Un dato de valor es aquel que me va a dar valor en mi
compañía para una solución determinada. ¿Qué quiere decir eso? Que el dato en crudo, normalmente,
pasa por el paso de la zona Landing, lo limpiamos, preparamos, etcétera, y lo dejamos en la zona Staging,
y luego lo preparamos para que tenga calidad, y esa calidad es lo que denominamos la zona Gold.
¿Puede un dato llegar de la zona Landing y automáticamente con un procesador, pasar a la zona Gold?
Por supuesto, no hay ningún tipo de restricción. Pero lo importante es que tengamos esa organización
para saber por qué zonas debería estar un dato.
Muchas compañías lo que hacen es que la zona Staging la usan para, simplemente, cumplir la normativa
LOPD (Ley Orgánica de Protección de Datos). Lo que hacen es anonimizar el dato, una vez que está
anominizado el dato lo pasan a Staging, y saben que sólo en la zona Landing va a estar el dato en crudo,
sin anonimizar. Por lo tanto, un dato que no está anonimizado es mucho más sensible y hay que tener
muchísimo cuidado con él. No damos acceso a la zona del dato en crudo a nadie, o prácticamente a nadie,
solo a los administradores y sólo dejamos acceso a la zona Staging. Obviamente, cuando el dato está
preparado para sacarle valor, no vamos a ir a la zona Staging, vamos a ir a la zona Gold.

¿Qué requisitos debería cumplir un Data Lake?

Como se estarán imaginando, la seguridad es una
de las características fundamentales. Como he
dicho antes, no deberíamos de dejar acceso a un
dato que está en crudo, sin anonimizar. ¿Vamos a
permitir acceder? No. Necesitamos de seguridad,
necesitamos de asegurar que no podemos acceder
nunca sobre un dato que está sin anonimizar.
¿Cómo podemos controlar eso? Existen distintos
componentes de Big Data, que luego lo veremos,
que nos permite controlar la seguridad.
Por otro lado, los esquemas organizativos. Como he dicho, esto está pensado para grandes empresas, por
tanto, esas grandes empresas que ya tienen un esquema organizativo preparado, ya tienen un esquema
de cómo trabajan en el día a día, qué perfiles hay, quién depende de quién, qué jerarquía existe, esos
esquemas organizativos también se pueden aplicar a la filosofía del Data Lake. De tal manera, que esos
perfiles podríamos crearlos también en el Data Lake y saber perfectamente esas jerarquías y esos
esquemas organizativos qué permisos van a tener para acceso a los datos.
Otro detalle es el "linaje". ¿Qué es el linaje? Básicamente, es el camino que recorre el dato desde que se
obtienen hasta la fase final. Cada uno de los pasos que se realicen sobre ese dato, operaciones,
transformaciones, anonimización, todos esos pasos deberían quedar almacenados en algún sitio. Lo
importante en ese caso, es tener almacenado esos metadatos de cada uno de los pasos. A eso se denomina
linaje y es una de las características fundamentales de una plataforma de almacenamiento de datos o
Data Lake.
Y por último la "gobernanza". La gobernanza es otra característica fundamental de la data Lake. ¿Por qué?
Porque de alguna manera, yo digo que un determinado dato que procede de un origen determinado, sólo
va a poder permitir un acceso a unas determinadas características o a unas determinadas operaciones
de una determinada persona. Creo un gobierno, básicamente es el gobierno del dato. ¿Cómo voy a permitir
acceder al dato? ¿Por quién? ¿De qué manera? Y ¿hasta dónde? Estas son las cuatro características que
definen un Data Lake. En definitiva, el Data Lake es fundamental para los sistemas Big Data porque es
donde vamos a almacenar todos los datos, donde nos va a permitir gestionarlos y donde, finalmente,
vamos a saber qué dato merece la pena, qué dato no, qué dato tiene valor y que dato no.

ECOSISTEMA HADOOP

Vamos a adentrarnos en el mundo de Big Data, y

como sabrán, en el mundo del Big Data hay más
de 700 aplicaciones asociadas.
Es un mundo inexplorado al día de hoy. Como
bien dije antes, una ola inmensa que, si nos
damos cuenta, ha pasado sin haber detectado
todas las tecnologías existentes, pero vamos paso
a paso. En primer lugar, vamos a ver lo
fundamental.

El elefante. El elefante que no deja de ser el

símbolo de la base de la filosofía de Big Data. Es
Hadoop.

Hadoop es un framework, es un software open

source que me va a permitir acceder a datos de
manera distribuida y a procesarlos.
Vamos a ver un poco la historia en la que se creó
Hadoop.
 En primer lugar, se inventó un software que se
denominaba NATS, que era un software que
permitía indexar millones de datos y permitía
buscarlos. Estaba basado en plataformas LUFS.
Entre tanto que se inventó el sistema NATS,
Google inventó el concepto de MapReduce, que lo
habíamos visto anteriormente. Ese concepto
permitió empezar a trabajar con filosofías de
divide y vencerás sobre plataformas con datos de
manera masiva. Una de las personas que cogió la
filosofía de Google es Doug Cutting que cogió esa
filosofía y la aplicó en un nuevo sistema de
ficheros que se llamaba DFS. Aplicó la filosofía
MapReduce con sistema de fichero DFS para
obtener datos utilizando la NATS.
Empezaron a trabajar hasta que llegó el 2006, y en el 2006 Yahoo no tuvo más remedio que contratar a
este hombre. Crearon un spin-off que se denominaba Hadoop.
Entre tanto, siguieron trabajando, se planteó una iniciativa: "¿Por qué no aplicamos esta filosofía de uso
en MapReduce con infraestructura Big Data, infraestructura con el ecosistema Hadoop, en un caso real?".
Lo plantearon en el New York Times con cuatro teras de información que, para ser del 2007, es muchísima
información. Para ello, pusieron 100 máquinas a trabajar de manera paralela en el almacenamiento y
procesado de datos. Fue un éxito, un éxito total que continuaron trabajando. Y empresas como Yahoo o
como Facebook plantearon el uso de Big Data con plataformas Hadoop. A principios del 2008, empezó
Facebook a plantearse el uso de manera interna y de manera externa de Hadoop. Yahoo planteaba casos
reales de uso de 3,5 terabytes para lanzamiento de datos, pero lo importante es que, a finales de 2008, se
creó Cloudera.
Cloudera es la base, la distribución Hadoop más importante que existe hoy en día en el mercado, y desde
el 2008 hasta ahora, lo único que hemos hecho ha sido crecer, crecer, crecer, crecer, hasta que llega un
momento en el que hemos creado esas 705 aplicaciones Big Data.

¿En qué se basa la filosofía Hadoop?

Existe un sistema de fichero que se llama HDFS,
Hadoop Data File System. Hadoop lo que hace es
coger un fichero muy grande de datos, y lo divide
en pequeñas piezas. Esas pequeñas piezas se
llaman chunks, y lo que hace es distribuir esos
chunks entre las distintas máquinas de un
sistema distribuido. Claro, no manda una pieza
solo a una máquina, manda una pirza a 10
máquinas, lo que se denomina replicación. ¿Por
qué? Porque si perdemos una máquina, ese dato
no lo perdemos, lo tenemos replicado en otras
máquinas.

También tenemos la filosofía de almacenamiento replicado, lo que supone que, si más de una máquina
falla, la accesibilidad al dato nos lo da 100% seguro. Dependiendo de cuál sea el nivel de replicación,
tendremos que indicar el número de máquinas de la infraestructura Big Data. Esos chunks que están
divididos, en realidad, la forma de acceder a ellos es de igual manera que una filosofía MapReduce. Yo leo
de manera paralela cada uno de los chunks y obtengo los chunks, los uno y creo el fichero final, que es
lo que nos tenemos como objetivo.

¿Cómo se crea esto? ¿Dónde se encuentra cada

chunk? Es trabajo de un nodo de una máquina
que le vamos a llamar Name Node. Esa máquina
va a tener los metadatos de dónde se encuentra
cada pieza del fichero, dónde se encuentra cada
fragmento del dato, pero los datos en realidad no
se almacenan en el Name Node, se almacenan en
otros nodos que se denominan Data Node. De tal
manera que la operación es la siguiente.
Voy a consultar al Name Node: "Oye, ¿dónde se encuentra este dato?". El Name Node me dice: "Recórrete
este, este y este nodo", que son Data Node, y acceso de manera paralela a las distintas piezas del dato,
para luego agregarlos y obtener el dato que deseo.

La filosofía o el diseño de la arquitectura Big Data

que lo hemos visto anteriormente. ¿Cómo se
plantea dentro de Hadoop? Pues, muy fácil.

Lo primero de todo como base, un sistema de

fichero distribuido HDFS. Por encima del HDFS,
necesito de un orquestador que va a saber cómo
se encuentran mis máquinas y cuál es la
capacidad de reacción que tiene. Aparte tenemos
ingestadores de datos y el streaming. Por otro
lado, necesitamos al sistema que permite
almacenar datos no estructurados, que no tiene
por qué estar almacenado en un sistema de datos
estructurado. Vamos a permitirlo también. Por
otro lado, mecanismos para poder acceder a los
datos.
Podemos acceder mediante SQL, podemos acceder mediante scripting, podemos utilizar Machine Learning
para ello, podemos incluso hacer un work flow de tareas para realizar una operación determinada sobre
un dato, y todo esto desde una visión transparente que me va a permitir, a través de incluso un navegador
web, acceder sobre los datos, y todo esto obviamente también controlado por un cuidador. El cuidador de
los animales, el que va a encontrarme todas las aplicaciones de una plataforma Hadoop.

Hoy en día, ¿qué distribuciones existen? Pues,

existen ya infinidades de distribuciones. De
manera open source como Hortonworks y de
manera de pago como MapR.
¿Cuál es la más usada? Pues, si nos fijamos en los
datos del tercer quarter del 2016, vemos que la
más descargada son las plataformas estándar
Hadoop, pero en realidad solo es la más
descargada, porque está contabilizando los
pequeños componentes que genera Apache de
manera separada. En realidad, la distribución
más usada hoy en día es Cloudera.
Cloudera tiene una característica, y es que casi todo es open source, salvo una serie de aplicaciones y el
soporte que son de pago. La solución que está ofreciendo Cloudera al día de hoy como paquete con una
serie de componentes o aplicaciones ya preparadas, interconectadas, configuradas, etcétera, es lo que se
denomina CDH, y la versión que se está utilizando a día de redacción de este documento es la 5.2.
Frente a Cloudera, el siguiente competidor es Hortonworks, una solución completamente open source, no
tiene forma de pago, todo es gratuito. Lo único que ofrece Hortonworks es un soporte. que normalmente
es un soporte cuando tienes que hilar fino, cuando necesitas una aplicación que no está soportada con
Hortonworks, pero que necesita soporte porque la necesitas para algún motivo. En ese caso, Hortonworks
ofrece otro tipo de distribución o un paquetito diferente que se denomina HDP. La versión actual es la
2.6.
¿Qué característica hay entre ambos? Pues, en realidad, la base es la misma. Es ecosistema Hadoop. Lo
que pasa es que, por encima de cara al usuario, utiliza distintas vertientes porque se enfocan en distintas
soluciones. Uno le da más importancia al acceso al dato de la manera más eficiente posible con uso de
memoria, como es el caso de Cloudera, y otro le da más importancia a las soluciones desde el punto de
seguridad, porque quiere asegurar que el dato está, de por sí, seguro. que es la solución Hortonworks.
Existen otras soluciones como MapR, que quizás son más completas, pero claro, desde el minuto cero son
de pago, y supone un gasto bastante fuerte.

COMPONENTES BIG DATA

Comenzamos analizando cada uno de los

componentes o aplicaciones que nos ofrecen las
soluciones Big Data. Para empezar, como hemos
comentado anteriormente, el ecosistema Hadoop
ofrece una serie de aplicaciones por defecto,
soluciones como pueda ser HDFS. Existen otras
aplicaciones, podemos ver en el gráfico una serie
de símbolos o iconos que nos representan esas
aplicaciones, como podrán ser el símbolo de la
aplicación de Hive, el símbolo de la aplicación de
Flume, Sqoop, etcétera. Vamos a ir a verlos de
manera organizada. En primer lugar, todo lo que
tiene que ver con almacenamiento de datos.

Tenemos el componente Hive, que nos permite

almacenar los datos de manera estructurada, lo
que nos permite no solo es almacenarlo de manera
estructurada, sino también incluso consultar de
manera estructurada. Esto es muy sencillo para
gente que viene de anteriores versiones de
Business Intelligence o incluso de soluciones
Oracle, MySQL, etcétera, puesto que para ellos no
supone un cambio desde el punto de vista de
desarrollo, pero en realidad, por detrás está
funcionando un sistema Big Data con sistemas
distribuidos, almacenamiento, replicación,
etcétera.

Frente a Hive, tenemos soluciones como Accumulo, una situación que también es compatible con
Cloudera y con Hortonworks. Podemos observar cómo en la diapositiva indico una C o una H, que lo que
quiere decir es si es compatible o no es compatible, y si se da soporte o no en cada una de las dos
distribuciones más importantes, cuando pone C solamente o H solamente, es que solo dan soporte en ese
tipo de distribuciones. Accumulo en este caso es una solución tan potente como Hive, pero menos usada
que Hive, que ofrece también acceso de una manera sencilla a los datos sin necesidad de tener muchos
conocimientos en los sistemas distribuidos.
Frente a Accumulo o Hive, ofrecemos soluciones no SQL, HBase es una solución no SQL que viene incluso
previa a la creación de Hive, que lo que permite es almacenar los datos de una manera sencilla como
clave-valor. No tiene ninguna complicación, yo almaceno con una clave un determinado valor, y ese valor
puede tener la forma que queramos, un dato, una imagen, un vídeo, lo que queramos.
HCatalog es básicamente un catálogo que nos permite controlar todas las bases de datos de una manera
unificada. Es muy potente porque nos permite acceder de una manera muy sencilla a distintos sistemas
o aplicaciones de almacenamiento de base de datos distribuidas como puede ser Hive y HBase a la vez, y
HAWQ, HAWQ es una solución pivotal, de ahí viene la P, entre paréntesis, es una solución muy parecida
a Hive, pero con un pequeño detalle, y es que tiene la posibilidad de poder ejecutar en memoria. Es muy
parecido a lo que vamos a ver más adelante, que se llama Impala, una solución de Cloudera. También
otro potencial de HAWQ en este caso, es que nos permite ejecutar código DR dentro de la propia consulta
SQL, a lo cual nos permite generar incluso analítica a la vez que acceso al dato.

Desde el punto de vista de acceso al dato, existen

distintas soluciones, HiveSQL es la parte de Hive
de consulta SQL, también con soporte a Cloudera
y a Hortonworks.
Impala es una solución de Cloudera que permite
acceder optimizando la consulta, usando la
memoria, hablamos de memoria individual de
cada nodo que, a su vez, si se tuviera una memoria
distribuida compartida, podría usarse a la vez.
Es una solución muy potente, y hasta hace muy poco, era la solución más óptima que existía en soluciones
BigData, hasta que salió otro concepto, otra aplicación que se llama Spark.
Pig es una solución basada en scripting no tiene más que una consulta muy parecida al resto de scripts
de acceso a dato, si bien esos accesos se parecen mucho a la estructura de una SQL, difiere en algunos
aspectos, para lo cual, si una persona no sabe ejecutar bien un script en Pig, nuestra recomendación es
siempre utilizar con Pig otra aplicación que se llama Tez. ¿Qué es lo que hace Tez? Coge la consulta hecha
en Pig, la analiza y la optimiza, la reorganiza, la complica y la modifica para que sea una ejecución de la
más óptima posible. Podemos ver el ejemplo donde una consulta donde aparentemente sabemos cómo se
hace, Tez se da cuenta de que la consulta no es óptima, la modifica, la cambia para que sea óptima y el
tiempo de ejecución sea el menor posible, es una solución muy práctica cuando queremos utilizar
soluciones Pig cada vez.
SparkSQL. Si tenemos solución Spark, que vamos a ver más adelante, lo que nos va a permitir SparkSQL
es acceder a los datos en memoria utilizando SQL, es una solución súper potente cuando queremos
utilizar soluciones Spark, que veremos más adelante.
Kite es otra solución muy parecida a SQL que está todavía en incubación por parte de Apache, pero que
ya dan soporte tanto Cloudera como Hortonworks.

A continuación, vamos a ver los componentes no

SQL de almacenamiento no estructurado. Si bien
ya habíamos hablado de una solución que era
HBase, una solución bastante antigua y más bien
poco usada, existen otras soluciones bastante
más orientadas a la necesidad de la ejecución o
del análisis. En primer lugar tenemos a
Cassandra, una solución basada en consulta por
clave-valor, una solución muy rápida y muy usada
hoy en día, que tiene soporte en Cloudera y en
Hortonworks.

Por otro lado, la solución MongoDB, que la utilizan muchas aplicaciones web, soluciones basadas en
almacenamiento de datos por documentos o JSON, una solución que, si bien la escalabilidad no es muy
buena, en realidad MongoDB ha sido muy usado y es muy famoso.
Soluciones tipo REDIS de clave-valor, donde lo más importante de REDIS es el rendimiento y la rapidez
en la que se obtiene un dato. En muchas ocasiones se utiliza REDIS como base de datos tipo caché, ¿qué
quiere decir eso? Para no tener que acceder continuamente a un dato que estamos accediendo, lo más
fácil es coger ese dato, llevarlo a una solución tipo REDIS, y tenerlo en REDIS para que el acceso al dato
sea lo más rápido posible, no tener que consultar sobre la base de datos original, que pueda ser un Hive,
sino que directamente podamos consultar sobre esa REDIS y obtener unos tiempos de respuesta muy
rápidos.
Neo4J. Neo4J ofrece soluciones orientada en grafos. Muchas veces los datos tienen relaciones entre sí, y
a mí lo que me interesa es poder navegar por esas relaciones, para eso se inventaron las bases de datos
de tipo grafo. Neo4J es una de las soluciones más potentes y más adaptadas para este tipo de
problemáticas.
GraphX es la solución que está ofreciendo Spark para brindar base de datos de tipo grafos. Es una
solución igual de buena que Neo4J, y encima está totalmente cogida por soluciones Apache.
CouchDB es una solución bastante potente, y está ideada para tener soluciones de caché y soluciones de
almacenamiento a largo tiempo. Lo bueno de CouchDB es que está pensado para dispositivos IET, ¿qué
quiere decir eso? Muchas veces los dispositivos IET pierden la conectividad, y no pueden transmitir los
datos a una base de datos global, para ello se instalan pequeñas instancias de bases de datos de
CouchDB, que vayan almacenando los datos, y que automáticamente, sin necesidad de nada, se
sincronizarán con la base de datos global cuando se tenga conectividad, y, mientras tanto, tienen un
almacenamiento local que está totalmente sincronizado cuando se vuelve a tener la conectividad.
Elastic. Elastic es una solución de almacenamiento, indexación y búsqueda de datos de tipo documental,
almacena los datos por palabras, indexa los datos por palabra, y lo importante en este caso es poder hacer
consultas de una manera muy rápida. No solo tiene proceso de almacenamiento y consulta, sino que
también tiene pequeñas aplicaciones que permiten procesar el texto, como poder hacerle matización,
nombres propios y otros similares. Lo importante de Elastic es que no solo tiene una solución de
indexación sino también tiene una solución de visualización, una que se llama Kibana, una solución de
análisis de logs, que es muy potente, y que es una solución completa que, si bien no están ofreciendo
Cloudera y Hortonworks de manera directa, sí que tienen conexión directa con ellos.
Kudu, una solución totalmente nueva, está en incubación a día de hoy, una solución de Apache, que
demuestra que puede ser muchísimo más rápida en almacenar y en obtener el dato que cualquiera de las
otras soluciones, está por ver a día de hoy todavía porque está en incubación.
Desde el punto de vista de almacenamiento del dato, tenemos soluciones para almacenamiento de tipos
"batch", como es Sqoop, que lo que hace es conectar nuestras bases de datos MySQL, Oracle, etcétera, y
volcar la información a nuestro "data lake" famoso.
Existen soluciones "streaming" que lo que hacen
es asegurarte que se van a ir obteniendo los datos
a medida que se vayan generando de nuestra
fuente, como son Flume y Storm, Flume en
soluciones Cloudera, Storm en soluciones
Hortonworks. Hay una cosa importante cuando se
están generando los datos de manera "streaming",
y es la organización, cuando llega un dato
tenemos que saber que ese dato llega en ese
momento, y antes de otro dato y después de otro
dato, y asegurarnos de que ese dato no lo
perdemos. Para ello, usamos un orquestador, que
se denomina Kafka, que nos permite enganchar
con Flume o con Storm para ir cogiendo el dato y
de manera organizada almacenándolo, crea una
ventana de tiempo y va ajustando esos tiempos
para ir almacenando los datos.
Otras soluciones que nos permiten también hacer procesamiento en tiempo real son las soluciones que
ofrece Spark con Spark Streaming y la solución Flink,, que es la competidora de Spark, que también tiene
su solución Flink Streaming.
Apex, que también está en incubadora y que también está ofreciendo una solución en "batch" y en
"streaming" de procesamiento del dato. Promete mucho, aunque todavía está en incubadora.

Desde el punto de vista en navegación de una

manera visual, es decir, mediante la "web",
tenemos el componente Hue, que es un
componente que existe tanto en Cloudera como en
Hortonworks, y una solución que se denomina
Cloudera Navigator que, como su nombre indica,
procede de la solución Cloudera.
Desde el punto de vista de consulta de datos
mediante consulta búsquedas, tenemos la
solución Elastic, que ya habíamos hablado
anteriormente, una solución muy parecida a
Lucene que se llama Solr que, si bien antes no la
usaba Cloudera, ahora ya la ha implantado.
Previamente, Cloudera tenía una que se llamaba
Cloudera Search, que se ha demostrado que era
menos potente que la solución Solr, de ahí que se
implantara.

Desde el punto de vista de seguridad, ofrecen

soluciones diferentes, tanto Cloudera como
Horton. Cloudera ofrece una solución Sentry que
es una solución global de control, acceso y
"gateway" para controlar el acceso a ese dato y, sin
embargo, Horton tiene dos soluciones, tres
soluciones en realidad, Knox, Ranger y Kerberos.
Knox nos está asegurando la conectividad desde
el punto de vista de red, Ranger, la accesibilidad
al dato, y Kerberos, la seguridad del dato, es decir,
encriptación del dato.

Desde el punto de vista de qué es lo que está produciendo, qué es lo que está ocurriendo sobre cada una
de las máquinas, cómo es el estado de las máquinas, si está apagada, si está encendida, si está hasta
arriba, si no, si tiene mucha memoria usada, si no, se utilizan varias soluciones, en Horton, Ambari, en
Cloudera, Cloudera Director. Tener en cuenta que Cloudera Director es una solución de pago por lo que
hay que tener que intentar, de alguna manera, configurar Ambari dentro de una distribución Cloudera.
Y una cosa súper interesante es CloudBreak. CloudBreak, lo que nos va a permitir es controlar clusters
de clusters, es decir, si yo tengo una solución Hadoop basada en Hortonworks y una solución Cloudera,
¿por qué no unificarlas en una sola visión que es la visión global de CloudBreak?, donde me va a decir
cómo va a estar el estado del cluster de Cloudera y cómo está el estado del cluster Hortonworks.

Desde el punto de vista de orquestación, como

hemos dicho antes, Yarn nos va a controlar qué
procesos se están ejecutando, cuál es el estado de
esos procesos, qué cola de procesos faltan,
cuántos recursos se van a usar en nuestro
sistema o infraestructura, y cuál es el estado
futuro de nuestras máquinas. Es muy importante
que Yarn tenga la visión de todos los recursos de
nuestro sistema, porque si no tiene visión, no lo
estamos usando. Yarn es el que dice, "se puede
usar" o "no se puede usar". Desde el punto de vista
de flujo de trabajo, existe una solución Oozie que
se utiliza también en sistemas de producción, que
es como un "workflow" de trabajos.

No deja de ser un "script" que va ejecutando cada uno de los procesos, pero nos sirve muchísimo el hecho
de poder tenerlo configurado en sistemas Big Data porque, de manera automática, se van a ejecutar esos
procesos. Es verdad que como es una solución "scripting" es poco amigable, para ello inventaron una
solución que se llama Nifi que es, mediante una interfaz gráfica, poder ir creando nodos, que van
interconectados entre sí mediante flechitas que permite hacer ciertas operaciones, una detrás de otra. Si
bien es muy intuitivo, no es válido para utilizar en producción, puesto que Nifi, que está basado en Java,
es muy lento y muy pesado. Zookeeper, como hemos definido antes, es nuestro cuidador del zoo que lo
que nos define es la alta disponibilidad de cada una de las aplicaciones de nuestra infraestructura Big
Data. ¿Qué quiere decir eso? Nos asegura de alguna manera que, cuando queramos acceder a una
aplicación o a un software de nuestra plataforma, ese va a responder porque Zookeeper se va a encargar
de que responda, le va a dar palos hasta que responda, básicamente. Y luego, soluciones de gobernanza
del dato, que bien habíamos hablado previamente. Existe la solución Atlas y existe la solución Falcon.
Atlas tiene soporte tanto en Cloudera como en Hortonworks y Falcon sólo en Hortonworks.

Por último, la parte de analítica, la parte más

abierta de todas, donde más se ha desarrollado. Si
bien es la que más se ha desarrollado, también es
la que más abierta hemos dejado desde el punto
de vista de futuro, porque cada día se crean
nuevas tecnologías, cada día obtienes nuevas
aplicaciones y cada día está de moda una
aplicación u otra. Mahout es una solución que se
ha quedado anticuada, aunque a día de hoy sigue
existiendo, de "machine learning".

ScikitLearn y Weka, otras soluciones de "machine learning" en Python o en Java que se han quedado un
poco obsoletas también. Soluciones Deep Learning hay cientos, las más importantes, Theano, TensorFlow,
Keras, etcétera, H2O, son soluciones para ejecución de algoritmos de "deep learning" o de redes
neuronales. Spark ML es la librería de Spark que me permite ejecución de "machine learning" en
distribuído, y es más amplia que la de Spark MLlib, es una solución que inventaron desde los orígenes de
Spark con soluciones "machine learning" procesadas, pero cuatro algoritmos procesados de manera
distribuida. Si tuviéramos que recomendar una librería en este caso, nos basaríamos siempre en Spark
ML. H2O es una solución que no sólo tiene la parte del "deep learning", sino otros algoritmos también
distribuidos como pueda ser Random Forest. Y, por último, MADLib que es una solución que está
enganchada de manera directa con Pivotal, es una solución que pudieras ejecutar analítica mediante
Python, mediante Java o mediante R, dentro de la propia SQL de consulta del dato.

IAAS, PAAS Y SAAS

Hasta ahora hemos visto los componentes Big Data que nos permiten obtener una infraestructura. Ahora
vamos a tomar decisiones desde el punto de vista de ¿dónde almacenamos nuestra infraestructura Big
Data, en nuestras oficinas o fuera en la nube? Vamos a ver cada una de las características que contempla
el tenerlo en nuestra casa, ventajas y pros, a tenerlo fuera de nuestra casa.
 En primer lugar, quiero proponerles cinco motivos
por los cuales deberían de irse fuera de nuestra
casa. Es verdad que los costes son mayores, pero
cuando tú contratas un servicio fuera eso a la
larga es mejor pues también es verdad que a la
larga mantener una infraestructura en nuestra
casa supone muchos más gastos. Luego vamos a
hablar de gastos, pero que quede claro que la
solución puede ser ambas y que nuestra
recomendación es contratarla en la nube.
1. Nos da visión. Nos da visibilidad al resto del
mundo si la tenemos en la nube. ¿Por qué?
Porque esa solución, que ya la tenemos fuera,
puede ser accesible a otros lados del mundo.
2. Permite de una manera muy sencilla la colaboración. Si bien yo tengo una oficina aquí y tengo que
trabajar con otra oficina que se encuentra en China, el uso del cloud nos lo va a facilitar
tremendamente.
3. Otro de los motivos por el cual vamos a usar soluciones cloud, o proponemos el uso de soluciones
cloud, es la posibilidad de ir variando e ir añadiendo soluciones de negocio a nuestra infraestructura
cloud. De pronto, un proveedor nos ofrece una solución. De pronto, se genera otro tipo de soluciones
que es compatible con la solución del proveedor anterior. Eso nos lo va a permitir interconectar con
nuestra infraestructura Big Data solo si estamos en la nube, de otra manera sería mucho más
complicada.
4. Nos permite la posibilidad de crear nuevas soluciones, nuevos productos e incluirlas en nuestra
infraestructura cloud.
5. Pero lo más importante es que al final somos mucho más eficientes, reducimos costes y permitimos
movilidad. Si yo cierro esta oficina, no pasa nada, mi infraestructura va a seguir funcionando. Me
puedo mudar sin ningún problema. No requiere de ciertos perfiles, ciertos recursos para el
mantenimiento de mi infraestructura. Y a la larga, la infraestructura se va degradando, se va
quedando antigua y supone tirarla y volver a comprarla.

Si analizamos los gastos que se están produciendo

en una infraestructura on-premise, vemos que
hay ciertos costes que vamos a tener que asumir
que no tendríamos en la otra solución, en cloud.
Costes del personal de IT, costes del
mantenimiento, costes del entrenamiento, porque
la gente no tiene por qué conocer infraestructuras
Big Data. Tenemos que entrenar, tenemos que
formarle de alguna manera. Todo ese coste junto
con la degradación del hardware, con su
antigüedad y las posibles reparaciones que vaya
teniendo ese hardware supone un coste que es del
77% del coste final, que en soluciones cloud nos
ahorramos.
Que la solución final parece más costosa, porque cuando pagamos un servicio cloud sale muchísimo más
caro que cuando estamos comprando la máquina y la mantenemos. Pero lo que pasa es que no estamos
teniendo en cuenta otros gastos que deberíamos de tener en cuenta, ese 77% de gastos.

Dando por hecho que hemos elegido la solución de

servicios cloud, me gustaría comentar que existen
tres tipos de servicios a tener en cuenta,
soluciones IaaS, soluciones PaaS y soluciones
SaaS.
Las soluciones IaaS, que son Infrastructure as a
Service o infraestructuras como servicios, lo que
nos está ofreciendo son soluciones de tipo
máquinas que ya están virtualizadas y que están
accesibles. Que de lo único que nos tenemos que
preocupar es de instalar nuestro sistema
operativo, nuestro middleware, nuestra
infraestructura Big Data y arrancamos a trabajar
sin tenernos que preocupar de mantenerla. Está
pensado para arquitectos Big Data.
Las soluciones PaaS, soluciones Platform as a Service, o plataformas como servicios, no solo nos están
dando la solución IaaS, es decir, infraestructuras, sino también nos están ofreciendo soluciones ya
compactas de servicios cloud, servicios como, por ejemplo, un MR, una solución cluster, cluster donde
nos ofrecen ya el servicio Big Data. No nos tenemos que preocupar de instalar sistema operativo, no nos
tenemos que preocupar de instalar soluciones middleware, de componentes Big Data. ya lo tenemos
instalado y configurado. Simplemente ya lo tenemos todo preparado para ejecutar. ¿Para quién está
destinado este tipo de soluciones? Para gente de desarrollo, gente que va a crear una aplicación que
almacena datos, que procesa datos, que hace analítica.
Un paso más allá son las soluciones SaaS, soluciones Software as a Service, o software como servicio.
Que son un paso más allá porque no solo te ofrecen la infraestructura, nos olvidamos de la infraestructura
esta ya no existe. Nos olvidamos de que eso es un cluster pues es transparente. Para nosotros, lo que nos
ofrece es el servicio, el servicio de limpieza de datos, el servicio de anonimización, el servicio de analítica.
Un servicio que nos va a ayudar a nosotros a obtener un resultado de una manera muy sencilla. Bien.
Este tipo de soluciones está destinado a personas, a usuarios finales. A personas que no tienen
conocimientos ni en desarrollo ni en arquitectura, sino más bien hacia negocios.

En este gráfico, podemos observar cada una de las

capas que se suelen tener en cuenta cuando
estamos en on-premise, cuando estamos en cloud
y dentro del cloud, en cada uno de los servicios
que ofrecemos. Si bien en la solución de IaaS nos
quedamos hasta la capa de sistema operativo, en
la de PaaS subimos más allá, hasta el punto de
tener infraestructura con sistema operativo, con
soluciones de software, middleware y hasta la
opción de ejecución. Y en la parte de SaaS,
tenemos ya incluso la posibilidad de ciertas
aplicaciones que nos van a dar ese servicio e
incluso datos que internamente ya tiene la
plataforma.

Existen IaaS, PaaS y SaaS. ¿Existen más? Sí.

Podemos ver IaaS, que por poner ejemplos
podríamos decir que IaaS podría ser Amazon EC2,
las máquinas EC2 de AWS, soluciones ACENS de
infraestructuras que te ofrecen como servicio.
CaaS es contenedores como servicios. Una
filosofía de contenedor es, no virtualices toda la
máquina, solo virtualiza las aplicaciones. Con eso
nos estamos ahorrando almacenamiento y acceso
al sistema operativo.
Si yo virtualizo un sistema operativo dentro de otro sistema operativo, estoy degradando los sistemas. Si
yo no virtualizo el sistema operativo, sino solo lo esencial para que mi aplicación funcione y las llamadas
sean las del anterior sistema operativo, estoy ahorrando en recursos. Y es una solución muy óptima para
crear microservicios. Soluciones como AWS de ECS de contenedores, es una solución práctica igual que
Azure, igual que Kubernetes o Docker.
Frente a CaaS nos encontramos ya a los PaaS, que son los platform, que son soluciones EMR de Amazon
o soluciones OpenShift o soluciones de Azure HDInsight.
Existe luego un paso más allá, que son Functions as a Service. Son funciones como servicios que cuando
yo ejecuto esa función, se realiza cierta operativa que ya tengo programada trasparente completamente al
usuario. Soluciones como Amazon Lambda, soluciones como Google Cloud Functions o Azure Function
son soluciones que se adaptan a este tipo de servicios.
Y las soluciones finales, servicios finales, que son las SaaS. Que pueden ser soluciones que ofrece
Salesforce, soluciones que ofrece SAP, soluciones que ofrece Google y soluciones que poco a poco van
ofreciendo las distintas empresas grandes como Google, Azure o Amazon.
 Si bien las soluciones SaaS son amplias, en
verdad nos tenemos que quedar con las más
importantes. Vamos a ver que lo fundamental en
SaaS, aquello por lo cual merece la pena SaaS es
por la eficacia desde el punto de vista de tiempo.
Por la eficiencia desde el punto de vista de que no
se queda anticuado nuestro software, no se queda
anticuado nuestro desarrollo, sino que va
prosperando a lo largo del tiempo sin costes
nuestros. No necesitamos un desarrollador ni su
conocimiento, sino simplemente la necesidad de
poder ejecutar ese servicio. El servicio nos lo
ofrecen, ejecutamos y obtenemos el resultado.
Sin contar con que teniendo en cuenta problemas de soluciones para escalabilidad, porque no solo me lo
están ofreciendo a mí, se lo están ofreciendo al mundo entero. Entonces, el hecho de que me respondan
a mí ayuda y el hecho de que mis datos pueden ayudar también a otro tipo de soluciones y eso puede
generar nuevos negocios.

¿Hoy en día cuáles son los mejores proveedores de

servicios IaaS, PaaS y SaaS?
Si bien hoy en día en SaaS el ganador sin duda es
Google por la solución Google Suite, pero en SaaS
no está todavía claro unos servicios en Big Data y
falta todavía madurar esa parte. Sin embargo, en
IaaS y en PaaS está claro quién es el vencedor. Sin
duda Amazon con las soluciones AWS gana por
encima de todos los demás.

Y hasta aquí los problemas encontrados en dónde

nos vamos a cloud, dónde nos vamos a on-
premise, qué diferencias hay entre IaaS, SaaS,
PaaS, y por qué ofrecemos soluciones cloud y por
qué tendemos hacia soluciones SaaS.

COMO ENFRENTARSE A UN RETO DE INFRAESTRUCTURAS

Ahora, entramos en el reto. ¿Cómo monto una

infraestructura Big Data? ¿Qué necesito saber
para montarla? Obviamente, con todos los
conocimientos que hemos tenido previamente, no
es suficiente. Tenemos que hacernos una serie de
preguntas para ser capaces de reaccionar y tomar
una serie de decisiones.
Vamos a plantear esas preguntas.
1. En primer lugar, ¿para qué vamos a necesitar
la infraestructura?, ¿va a ser para
almacenamiento de datos?, ¿va a ser para
procesarlos?, ¿va a ser para analítica?, ¿va a
ser para obtener un "dashboard"?, ¿para qué
vamos a necesitar esos datos?
2. La segunda pregunta que se nos ocurre siempre es ¿qué tamaño van a tener esos datos?, ¿qué
volumetría?, ¿van a ser megas, gigas? Obviamente, si son megas, no vamos a una solución Big Data.
Vamos a una solución Big Data cuando hablamos de teras de información. Pero ¿cuántos teras, dos,
cinco, diez, cien? Dependiendo de esa volumetría tenemos que escalar la infraestructura Big Data y,
por tanto, ver un tipo de solución u otra.
3. Está claro que también la tipología de datos nos va a ayudar a saber si elegimos soluciones no SQL o
soluciones SQL. ¿Qué datos vamos a almacenar?, ¿son imágenes, es video, es texto, son números,
son letras, datos categóricos, datos numéricos? ¿Qué datos vamos a almacenar? Y conforme a eso,
usaremos un tipo de componentes u otros.
4. Otro tipo de soluciones que vamos a ver son cómo vamos a acceder a esos datos, cómo vamos a
obtenerlos y cómo vamos a acceder a ellos. ¿Los datos se van a generar de manera "batch"?, es decir,
 ya están obtenidos y, simplemente, los vamos a volcar en infraestructura o ¿se van a ir generando
dinámicamente? Y cuando se van a ir generando dinámicamente, ¿los vamos a ir procesando en ese
momento, en tiempo real, o los vamos a almacenar en un sitio como caché, vamos a procesarlos
después y vamos a hacer analítica? Ese tipo de detalles son importantes porque los tiempos de
respuesta son fundamentales cuando estamos en "streaming". Obviamente, cuando estamos en
"batch" la cosa es mucho más sencilla.
5. Otro aspecto a tener en cuenta es el nivel de sensibilidad de los datos. ¿Estamos trabajando con datos
sensibles, desde el punto de vista de protección de datos, o no? Si los datos que vamos a trabajar son
datos personales, requieren anonimización. Dependiendo de esos datos personales, vamos a necesitar
una anonimización más robusta y más fuerte o una anonimización más suave. El acceso a ese dato
requiere de unos mecanismos de seguridad. Por ello, es importante saber a priori con qué datos, con
qué tipología de datos vamos a jugar y qué nivel de sensibilidad tiene, para poder poner una serie de
aplicaciones u otras y medir de manera adecuada el "cluster".
6. Otra pregunta típica que se suele plantear es ¿los datos se tienen que almacenar siempre en
localizaciones de nuestro territorio o pueden estar fuera? Parece una pregunta rara, pero ni mucho
menos. Cuando estamos planteando soluciones de tipo "cloud" como Amazon, como Azure o como
Google, es importante tener en cuenta ese detalle, porque si los datos no pueden salir de nuestro
territorio ninguna de esas soluciones "cloud" podría ser soluble. No es una solución válida para
almacenar esos datos. Sin embargo, si los datos pueden salir fuera bogamos soluciones de Google,
soluciones de Amazon, soluciones de Azure sin ningún tipo de problemas.
7. Otra pregunta que solemos realizarnos es ¿quién va a acceder a esta plataforma? ¿Van a ser analistas,
van a ser ingenieros, van a ser desarrolladores, va a ser el cliente final? A veces ocurre que el cliente
final quiere acceder. Tenemos que permitir acceder a esa plataforma, obviamente, es el cliente, tiene
que verlo. Pero, obviamente, le vamos a dejar ver lo que tiene que ver, no le vamos a dejar acceder
hasta la cocina. Vamos a dejar un acceso limitado, protegido y con seguridad para que vea lo que
nosotros queramos que vea y dar accesos a las personas según sus roles. Por ello, es necesario tener
en cuenta esta pregunta para meter los mecanismos necesarios de seguridad, para lo cual es necesario
definir claramente la infraestructura Big Data.
8. ¿Se necesita alta disponibilidad? Pues esta pregunta va relacionada sobre todo al tipo de soluciones
que vas a hacer con esta infraestructura de Big Data. La primera pregunta de todas, ¿qué es lo que
vas a hacer? Porque si vas a hacer una prueba de concepto, obviamente, no es requerido que tengas
alta disponibilidad. ¿Qué significa alta disponibilidad? Que siempre, en el cien por cien de los casos,
tu aplicación va a responder. Lo que supone alta disponibilidad es duplicar los recursos de la
infraestructura Big Data. ¿Es necesario para una prueba de concepto duplicar? Pues, quizá no, se
nos suba en costes. Por ello, si es una prueba de concepto, reducimos costes. Pero hay que saberlo
anticipadamente, porque si sabemos, de primera mano, si se requiere alta disponibilidad o no, eso
puede repercutir en el diseño y, por tanto, en gastos.
9. ¿En qué tiempos tiene que estar disponible la infraestructura? Parece una pregunta extraña, pero, en
realidad no lo es. Cuando tenemos la solución implantada en soluciones AWS, Amazon, Azure o
Google, podemos tener la opción de pagar 24/7, podemos tener la opción de pagar por uso, o podemos
tener soluciones de ejecución múltiples, es decir, millones, y millones y millones de nodos de cómputo
en un tiempo muy corto. Dependiendo de cuál sea la necesidad y cuál sea el tiempo de acceso, nosotros
podemos ir a un tipo de solución u otra y conlleva a un tipo de gastos u otro. Es importante tenerlo
en cuenta y no cambiar en esa decisión, porque ese cambio puede suponer multiplicar por cinco, por
diez, por 20, hasta por 100 el coste de la infraestructura.
10. Hay que conectarlo con sistemas de otros, de terceros, por ejemplo. Un cliente tiene una
infraestructura Big Data, pero lo importante para él es que tenga acceso a la unidad organizativa de
Windows Server. Vaya por Dios, es complicado. Hay que tener en cuenta que lo que tenemos que
conectar es mi infraestructura Big Data con soluciones Active Directory de Windows. Para tenerlo en
cuenta hay que crear un nodo especial, un nodo que tenga visión de la parte de Active Directory, que
sea compatible con Azure, probablemente, pagar unas licencias, una serie de cosas que hay que
tenerlas en cuenta a priori cuando diseñamos una infraestructura Big Data.
11. Y, por último, ¿cuánto tiempo tenemos para implantar este sistema? No, lo queremos para mañana.
Bueno, si es para mañana, seguramente, tengamos que ir a soluciones PAS, es decir, AWS EMR, que
ya en 20 minutos te levanta una infraestructura Big Data, y no a soluciones muy complejas de llave
en mano, donde vamos definiendo con detalle y configurando con detalle cada una de las aplicaciones.

Dependiendo de cuál sea la necesidad, y dependiendo del tiempo que tengamos y, sobre todo, del coste
que tengamos, tenemos que ir a un tipo de decisiones u otras.
En definitiva, hay que tener en cuenta la
volumetría, la tipología de los datos, el nivel de
seguridad de los datos, la ubicación donde se
tienen que encontrar esos datos, el tiempo en el
que va a estar disponible la infraestructura Big
Data, el tipo de disponibilidad y, por último, qué
componentes son necesarios en nuestra
infraestructura Big Data.