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. 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? 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. 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. 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. 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". Otra pregunta típica que se suele plantear es ¿los datos se tienen que almacenar siempre en localizaciones de España o pueden estar fuera de España? 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 España, a día de hoy, 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 de España, adelante, bogamos soluciones de Google, soluciones de Amazon, soluciones de Azure sin ningún tipo de problemas. Otra pregunta que solemos preguntarnos 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, a veces el cliente final quiere acceder, quiere verlo. 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. ¿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. Bueno, si una vez no responde, no deja de ser una prueba de concepto, no pasa nada. 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. ¿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 siete 24, 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 cortito. 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. 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. 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. Y con esto hemos terminado el reto de cómo montar una infraestructura Big Data.
