Alcance y limitaciones

Para realizar las pruebas en SparkLP, inicialmente se contaba con un conjunto de datos1 proveniente de la red social Weiboo 2. Del mismo podemos mencionar algunas de sus características principales:

Tamaño total de archivo: 776,4 MBytes Cantidad total de usuarios: 1.944.589 Cantidad total de interacciones: 50.655.143

Dicho conjunto de datos contiene únicamente un archivo histórico de interacciones entre usuarios «usuario que sigue a usuario», con el siguiente formato:IDseguidor→IDseguido Al comienzo de la etapa de experimentación se probó ejecutar el algoritmo de Common Neighbors de diferentes formas y con diversas restricciones de memoria. La primera al- ternativa evaluada consistió en tomar muestras del dataset para no tener que sobrecargar

1_{https://www.kaggle.com/c/kddcup2012-track1/data} 2_{www.weibo.com}

la memoria del programa driver como en un principio sucedió. El sistema continuó pre- sentando fallas, arrojando los siguientes errores:

java.lang.OutOfMemoryError: GC Overhead limit exceeded

La causa de este error se da cuando tareas lo suficientemente demandantes de me- moria hacían uso intensivo de esta sin llegar a agotarla en su totalidad, pero sí de- jando muy poco espacio en heap disponible para el alojamiento de nuevos objetos. En estos casos el Garbage Collector (GC), es activado contínuamente intentando li- berar memoria. Cuando una tarea (proceso Java) gasta más del 98 % de tiempo de ejecución recolectando objetos basura, y el umbral de recolección de memoria es menor del 2 % del tamaño total del heap, entonces este mecanismo de error deten- drá la ejecución. En estas circunstancias, se puede decir que la tarea queda bloquea- da sin poder continuar su ejecución por falta de memoria. Si bien Spark es tolerante a fallos no controla los fallos provocados por la JVM.

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

La causa de este error se identificó como un intento de Spark de crear resultados de una tarea, que exceden las capacidades de memoria física de las que la JVM puede disponer.

java.lang.IllegalArgumentException: Size exceeds Integer.MAX_VALUE

La causa de este error es parecida a la mencionada anteriormente, sólo que en con- textos donde Spark intenta de antemano crear RDDs que superan los 2GB de espa- cio para una tarea. Esto nos da un indicio que el particionado propuesto al dataset trabajado, no es lo suficientemente grande para poder manejar los conjuntos de resultados.

OutOfMemoryError: Java heap space

En casos en que pudimos finalmente traer mediante collects, información al pro- grama driver, pero esta información excede la memoria física disponible en dicha locación. También ocurrió cuando en casos donde las tareas eran muy grandes, se calculaban muchos arcos faltantes del grafo social y de forma muy rápida sin dar tiempo a iniciar el GC.

Es común ponernos a pensar cuál es la causa por la que Spark no está siendo capaz de po- der procesar un dataset, que a simple vista no parecengrandes datos sociales.La respuesta a esta pregunta responde a la siguiente cuestión. Teniendo aproximadamente cincuenta millones de interacciones, y un promedio de dos millones de usuarios, definiremos dos situaciones que se darán en el proceso de obtención de recomendaciones:

1. Hit: «usuario de la red social ya existe en la lista de seguidores».Este es el caso ideal de ejecución puesto que solo se realiza una comparación y no se crean objetos nuevos, el resultset de la tarea no tendrá una recomendación nueva.

2. Fail:«usuario de la red social no existe en la lista de seguidores».Se crea un nuevo objeto de tipo tupla y se guarda en él una copia del usuario observado y el usuario de la red que no existe en seguidores.Este es el peor caso de ejecución (computacional- mente), debido a que además de realizar una comparación por existencia, también se crearan tres objetos nuevos y luego agregados al resultset de la tarea.

Y ahora podemos evaluar dos posibles escenarios.

1. El grafo social es muy conexo, es decir, la cantidad de arcos faltantes es, a lo sumo, la cantidad de arcos ya existente. En este contexto podemos decir que el predictor de enlaces en cada tarea, experimentará mas situaciones de hit. Por lo tanto, este escenario implica un menor consumo de memoria principal.

2. El grafo social es poco conexo, es decir, posee usuarios que han interactuado poco (seguir a otros usuarios). Hablando en términos de procesamiento, este escenario es el más costoso, ya que se producirán más situaciones defailllevando a uso intensivo de memoria. La cantidad de memoria a usar estará determinada por el grado de conectividad de ese usuario en la red social. Cuanto más bajo sea este valor, mayor será el tiempo de cómputo requerido y la memoria necesaria.

Teniendo en cuenta lo antes planteado, definimos al grado de interacción como:

GI(u) = Seguidores(u) + Seguidos(u)

TotalRed social

Definido el grado de interacción, el dataset original posee una mediana muy cercana al cero, lo cual nos da una noción de la baja interacción entre usuarios en dicho grafo. Clara- mente podemos concluir que predominan los valores muy cercanos al cero. Por todos los problemas de memorias anteriormente mencionados, fue imposible procesar con Spark el dataset propuesto. Por lo que fue estrictamente necesario realizar una reducción del con- junto de prueba debido a la gran limitación tecnológica con la que se contó al momento de la experimentación.

Entonces, la alternativa a seguir es la siguiente: plantear una estrategia que nos permita operar sobre un conjunto de datos más reducido que se adapte a las posibilidades de cómputo de nuestro clúster.

5.1.1. Reducción del conjunto de datos

La alternativa a seguir fue tomar una muestra aleatoria de nuestro dataset, mediante un algoritmo escrito en lenguaje Scala. En este experimento se trató de obtener un total de 25000 usuarios al azar (sin repeticiones), y luego del dataset original, extraer todas las tuplas correspondientes cuyos valores de clave y valor pertenezcan a la lista de usuarios previamente obtenida.

Este experimento nos arrojó una muestra bastante representativa con respecto a la origi- nal, con las siguientes características:

Tamaño total de archivo: 116.7 MBytes Cantidad total de usuarios: 25.000

Cantidad total de interacciones: 7.636.756

Analizando esta muestra del conjunto de datos, puede verse la nueva distribución del grado de interacción de usuarios en el histograma de la figura 5.1. Sigue dándonos nú- meros muy bajos de interacción, pero al ser más pequeño en cantidad de usuarios e inter- acciones, estamos en condiciones computacionales de ponerlo a prueba y ver qué sucede con la predicción de enlaces.