Big data y mi ordenador portatil no se llevan bien Que hago?

Desde hace tiempo, mi interes sobre la aplicacion del analisis econometrico combinado con las tecnicas multivariantes del Machine Learning guian mis pasos de la consultoria sobre un terreno no apto para impacientes ya que todo parece un camino sin salida toda vez que clientes, alumnos, y mis seguidores tratan de manejar cantidades enormes de datos sin las herramientas ni la preparacion adecuada.

Pero empecemos por definir que es cada cosa y luego expondremos que soluciones reales tenemos al momento de ser consultores o investigadores apasionados al analisis de grandes bases de datos.

BIG DATA? disculpe, ESO SE COME?

Si, se come, se come los pocos recursos informaticos que tengas a disposicion, es mas voraz que una pirana en el rio Amazonas, imaginemos a la pirana yendo a toda la velocidad que pueda, a por la comida, que puede ser un TOAD, o un Apache disfrazado de SERVER, un anarquista disfrazado de R, una Python, etc.

Las consultas a la base de datos por mas simples que sean, dependen de una maquina, con un hardware limitado por el presupuesto que invertimos en el, y que tiene un software que comparte los recursos fisicos de esa maquina,(memoria, CPU, disco, red) con todas las aplicaciones que esten corriendo a la vez. Asi las instrucciones que ejecutemos en la consola, generan una serie de efectos fisicos que consumen los recursos que utilizaran para devolver los resultados que estemos pidiendo; inmediatamente la memoria empieza a ser devorada y con ella su amiga la CPU, por si eso no bastara el disco sufre tambien lo suyo, (Es un buen recurso la Intel Optane H10 con almacenamiento SSD?) ya que programas como R, pueden utilizan parte del disco como "memoria" para incrementar la resistencia a la voracidad de hambre por RAM que necesitan los programas de analisis: como la comida a la pirana, los datos a la memoria.

Entonces que se entiende y que tan grande es un conjunto de datos (valga la redundancia) "grande" y que los equipos que estamos manejando ahora soporte esa magnitud de requerimientos?

Podemos categorizar grandes conjuntos de datos que R maneja segun estas categorias:

• Medium sized archivos que se pueden cargar en R (dentro del limite de memoria, pero el procedimiento es engorroso (normalmente en el rango de 1-2 GB)

• Archivos grandes que no se puede cargar debido a limitaciones de R / OS como se menciono anteriormente. podemos dividir este grupo en 2 subgrupos

• Large files -- (tipicamente 2 -- 10 GB) que todavia se pueden procesar localmente usando algunas soluciones de trabajo con ordenadores de alta gama.

• Very Large files -- (> 10 GB) que necesita la computacion a gran escala distribuida, y necesita memoria de procesamiento. (es lo que tenemos)

Como ven, un archivo que supere la memoria convencional de equipos que normalmente estan en nuestros hogares o en la oficina que con suerte llegan a 8G de RAM, no es suficiente.

Hay tres opciones para procesar conjuntos de datos muy grandes (> 10 GB) en R.

• Utilizar paquetes de entorno integrado como Rhipe para aprovechar el marco Hadoop MapReduce.

• Utilizar RHadoop directamente en el sistema distribuido hadoop.

• Almacenar archivos grandes en bases de datos y conectarse a traves de DBI/ODBC llamadas desde R tambien es una opcion que vale la pena considerar (aunque con petabytes ya es otro historia).

• Utilizar R-Spark (Super Avanzado)

Recomiendo que para estas opciones hay que crear el entorno, en UNIX/LINUX que es la tendencia por la seguridad, facilidad y versatilidad de procesamiento que tiene, y que tengamos por supuesto un ordenador con mas memoria (entre 16G minimo y 32G para adelante como lo mas optimo), ya que R (y otros programas que le imitan) procesa en memoria los datos, hay formas de hacer mas facil el cargado como la de leer de un dispositivo externo como un buen disco duro y tratar de ejecutar en paralelo.

ENTONCES COMO CONFIGURO MI ARQUITECTURA?

Este post esta orientado a un usuario individual, entusiasta con el Big Data, por lo cual supongo que no todos pueden tener algo como...

https://youtu.be/avP5d16wEp0

Bueno no tanto, pero una configuracion tipica desde hace unos anos es que el nodo esclavo tenga una configuracion similar a:

• Discos duros: 12x2TB SATA (sin RAID, configuracion JBOD)

• Red: 4x1Gb o 1x10Gb

• Procesador: 2x6 cores

• Memoria: 64GB o 96GB

Ahora mismo, esa configuracion seria la basica en laptops (portatiles), sin mencionar marcas.

(Para una actualizacion o consultoria de la infraestructura mas moderna pueden escribirme al correo info@todoeconometria.es)

MAQUINAS VIRTUALES.

Por otro lado podemos contratar servicios completos en la nube, 3 gigantes pugnan por el mercado.

AWS la solucion de AMAZON. https://aws.amazon.com/es/pricing/?nc2=h_ql_pr

Asure la solucion de Microsoft.

https://azure.microsoft.com/es-es/pricing/details/virtual-machines/windows/

GOOGLE CLOUD PLATFORM la solucion de Google. https://cloud.google.com/solutions/big-data/?hl=es

Y AHORA COMO ME COMUNICO ENTRE BIG DATA Y LA MAQUINA.

Todos los usuarios actuales (07/06/2019) parecen consensuar entre ETL's como Talend, Oracle Data Integrator, Pentaho, SAS Data Integration Studio, SQL Server Integrated Service, y programas de analisis como RapidMiner Studio, IBM SPSS, Pyton o R.

Por otro lado estan las herramientas REALES de tratamiento de BIG DATA, como Hadoop, Spark, Talend Open Studio, Pentaho, RapidMiner, Storm, H2O, MongoDB, Cludera.

El preferido (por la mayoria de los Data Scientist) Hadoop se sustenta en la forma en la que almacena y accede a los datos. Hadoop esta formado por HDFS y MapReduce. La combinacion de estos dos permite que los datos estan replicados y distribuidos por N nodos beneficiando la capacidad de acceso a grandes volumenes de datos, consultas y calculos analiticos. Cuando queremos ejecutar alguna operacion sobre estos datos como estan distribuidos en diferentes nodos, Hadoop se encarga de procesar cada porcion de los datos en el nodo que los contiene, aprovechando la localidad de tener los datos cerca de donde se van a procesar y permite escalar de forma casi lineal. Si queremos crecer en capacidad, anadimos mas nodos y listo. Del almacenamiento se encarga HDFS y del procesamiento MapReduce.

No nos olvidemos de algunas herramientas como emEdit, Utra Edit, CSVed o el mismo Sublime Text, para leer los archivos en formato csv o txt.

No olviden de compartir y opinar.

Saludos y buen analisis!