Práctica de clustering
Preparación de los ficheros binarios Para operar los ficheros binarios se ha utilizado una aplicación en Delphi que permite montar los ficheros ".arff" que usa Weka. La aplicación abre los ficheros como registros (estructuras) para después volcarlos en forma de texto sobre un segundo fichero con la estructura concreta del formato arrf. El formato arff no es más que un fichero csv (valores separados por comas y una entrada por fila) con una cabecera concreta que indica los nombres y tipos de los atributos. Se ha aprovechado el recorrido secuencial que realiza esta aplicación sobre los datos para operar ciertos valores para su normalización y para descartar directamente ciertos atributos. He realizado el descarte de atributos directamente desde esta aplicación en lugar que desde Weka debido a que Weka, al trabajar con los segmentos enteros, tiene un gran consumo de memoria (cerca de 2Gb) y así se reducía algo la carga del programa. Selección de información Filtrado Atributos escogidos TimeStamp: Se trata de la hora guardada en segundos desde el Epoch, esta hora está adaptada a la hora GMT por lo que para obtener la hora local en la zona de la toma de muestra tendremos que sumarle 2 horas. La fecha no es interesantes puesto que todas hacen referencia al 12 de Junio del 98 pero la hora si nos será de utilidad. Server: Indica los datos del servidor que recibió la petición lo que es un indicador de la zona desde la que se emitió esta. ObjectID: Indica el objeto de la página que han solicitado los clientes lo que es un indicador de cuáles son las partes más visitadas de la página. Atributos descartados: clientid, method, status, type. clientid: Identificador único del cliente. Cada cliente tiene un identificador diferente y arbitrario por lo que no es especialmente útil conocerlo. Method: Especifica el tipo de petición (Ej. get). Status: Especifica el tipo de http que se ha solicitado y el resultado de la petición. Type: Especifica el tipo de objeto que se ha solicitado, URL, imagen, etc. Ya que una única página por si mismo ya suele contener información muy diversa no parece especialmente útil saber que tipo de objeto concreto esta demandando el cliente en una petición concreta. Normalizar Timestamp: Hemos operado los para descartar la fecha y quedarnos con la hora modificada para la zona local. Para esto en primer lugar hemos sumado a los valores la cifra de dos horas en segundos (Valor + 7200), en segundo lugar hemos operado los valores para obtener el resto de la división por el total de segundo de un día (Valor mod 86400).
Server: Los 3 primeros bits representan la zona del servidor, los 5 siguientes el servidor concreto. Puesto que conocer que servidor concreto ha respondido la petición no resulta especialmente útil se ha seleccionado solo los tres primeros bits para conocer la zona. Para esto se ha realizado la división entera del valor entre 2 5 (Valor div 32). ObjectID: Al ser un valor arbitrario que representa la parte de la página se ha conservado el valor intacto. Categorización Interpretación Las entradas referentes a la hora están extrañamente distribuidas de una manera completamente uniforme lo cual parece bastante ilógico ya que no se explica que haya el mismo tráfico en plena tarde que en mitad de la madrugada mientras nos encontramos en una única zona horaria (O más de una muy cercanas). El tráfico de zonas esta divido entre algunas zonas concretas sin abarcar todos los valores disponibles. Si bien tampoco es el resultado más deseable esto podría explicarse con el hecho de que los segmentos de trazas se hubieran recopilado ordenados por servidor y no por fecha. El objectid representa una distribución más plausible. Las entradas abarcan todo su posible rango de valores y estás están distribuidas de manera desigual dejando en evidencia que algunas partes de la página fueron más solicitadas que otras lo que es un comportamiento típico. Estos valores me hacen pensar que puede haber algún tipo de problema con los datos de entrada o su codificación sin embargo he revisado varias veces el código y probado diferentes segmentos de trazas y no he podido dar con él. Debido a la falta de tiempo para más pruebas me he visto obligado a realizar el clustering a pesar de las sospechas de que los valores sean erroneos. Clustering Después de realizar varias pruebas con diferentes tamaños de segmentos he comprobado que, al menos con esta selección de atributos, realizar un clustering para el segmento completo no sería posible en unos tiempo asumibles. Finalmente realicé el clustering sobre dos segmentos de 100.000 y 50.000..
Primeras 100.000 entradas del segmento wc_day47_7 === Run information === Scheme:weka.clusterers.EM -I 100 -N -1 -M 1.0E-6 -S 100 Relation: World Cup Instances: 100000 Attributes: 3 Test mode:evaluate on training data EM == Number of clusters selected by cross validation: 4 Cluster Attribute 0 1 2 3 (0.19) (0.09) (0.63) (0.09) ============================================================== ============== mean 43109.6111 66089.2956 42972.1898 20857.8817 std. dev. 25121.4767 12362.3475 24677.9763 13525.061 mean 1667760110.7836 580939541.8682 1983001437.7855 557185135.3566 std. dev. 1023101307.9308 442385711.2725 922030451.3193 418954581.4261 mean 3 1.0184 1 1.0081 std. dev. 0.7865 0.166 0.7865 0.1264 Time taken to build model (full training data) : 2882.65 seconds Clustered Instances 0 19033 ( 19%) 1 15855 ( 16%) 2 47642 ( 48%) 3 17470 ( 17%) Log likelihood: -34.3787
Server-ObjectId Timestamp-ObjectId Timestamp-Server Cluster 0 Cluster 1 Cluster 2 Cluster 3 Comentarios El cluster 0 engloba todas los accesos desde la zona 3 (), sin embargo, más allá de ahí, se encuentra totalmente diseminado tanto en tiempo como en accesos a partes de la página por lo que no podemos decir nada más de este cluster. De esto deducimos que la gente que accedía desde la zona 3 lo hacía a cualquier intervalo horario y para acceder a cualquier zona de la página. El cluster 1 es una parte de los accesos desde la zona 2, de este grupo podemos deducir que: Existe un conjunto de gente que, únicamente accedió a ciertas zonas de la página (las que tienen un id más bajo) y además lo hizo desde las 12 del medio día hasta las 12 de la noche. El cluster 2 engloba acessos desde las zonas 0, 1 y 2, este grupo únicamente accedió a unas partes concretas de la página (concretamente las que tenía un identificador superior) y lo hizo de manera uniforme a lo largo del día. El cluster 3, aunque no se puede apreciar muy bien en el gráfico debido a los colores, está completamente alojado en la zona 1, accedieron únicamente a las mismas zonas de la página que en el cluster 2 pero en este caso los accesos se realizaraón desde las 12 de la noche hasta las 12 del medio día. El likelihood de -34.3787 parece un indicador de que no se han encontrado unos grupos excesivamente óptimos y las divisiones entre ellos no están del todo claras. Deducciones Una vez descartada la información que, recopilada, resulta irrelevante, podríamos hacer atribuciones a las preferencias de la población de cada zona en este día. A los usuarios que accedieron desde la zona 0 y 1 únicamente les interesó una parte concreta de la página, mientras que, a los que accedieron desde las zonas 1 y 3 les interesó todo el conjunto. Resulta extraño que no se pueda extraer ningún valor útil de la hora por lo que de nuevo me inclino a pensar que, al menos con esta, debe haber algún problema de cómputo.
Primeras 50.000 entradas del segmento wc_day47_8 === Run information === Scheme:weka.clusterers.EM -I 100 -N -1 -M 1.0E-6 -S 100 Relation: World Cup Instances: 50000 Attributes: 3 Test mode:evaluate on training data EM == Number of clusters selected by cross validation: 3 Cluster Attribute 0 1 2 (0.5) (0.13) (0.36) ============================================================ mean 62174.2541 45284.3991 21937.3541 std. dev. 14247.0664 24004.7379 12077.9817 mean 1623310904.1963 1650906500.7308 1614794953.4144 std. dev. 1046484322.1591 1048286746.1166 1049345365.4894 mean 0.9986 3 1 std. dev. 0.0517 0.6818 0.6818 Time taken to build model (full training data) : 902.31 seconds Clustered Instances 0 31649 ( 63%) 1 6700 ( 13%) 2 11651 ( 23%) Log likelihood: -33.12088
Server-ObjectId Time-ObjectId Time-Server Cluster 0 Cluster 1 Cluster 2 Comentarios El cluster 0 engloba todos los accesos desde la zona 1, estos accesos se realizaron en un cierto intervalo de tiempo en torno a las 7am y las 12 am. Por otro lado consultaron por igual todo la página. El cluster 1 engloba todos los accesos desde la zona 3, estos accesos se realizaron repartidos entre todas las horas del día y consultaron la página completa. El cluster 2 engloba la mayoría de accesos que se realizaron entre las las 12 de la noche y las 7am y realizados desde las zonas 0 y 2. Accedieron de forma uniforme a toda la página. El likelihood de -33.12088 parece un indicador de que no se han encontrado unos grupos excesivamente óptimos y las divisiones entre ellos no están del todo claras. Deducciones En este caso podríamos la hacer algunas atribuciones interesantes: La mayoría de los habitantes de la zona 1 accedieron a la página a partir de las 7am hasta las 12 de la noche. La mayoría de los habitantes de la zona 0 accedieron a la página antes de las 7am. Los habitantes de la zona 3 no poseen ningún patrón concreto de comportamiento y accedieron por igual a todas las zonas de la página a todas las horas. Los accesos realizados en este segmento se realizaron de forma indiscriminada a todas las zonas de la página sin que se vieran ningún patrón de comportamiento concreto. Aunque en este ejemplo puede verse algún patrón de comportamiento respecto a la hora resulta desconcertante que haya un patrón regular de horas en las que no haya ninguna entrada.