_____________________________________________________________________________
COMPARACIÓN DEL FUNCIONAMIENTO DEL ALGORITMO C4.5 EN
UN MODELO DE PERSISITENCIA RELACIONAL CONTRA UN
MODELO NO RELACIONAL
Nicolás Lagos Ruiz
_____________________
Facultad de Ingeniería, Proyecto Curricular de Ingeniería de Sistemas Bogotá D.C., Colombia
COMPARACIÓN DEL FUNCIONAMIENTO DEL ALGORITMO C4.5 EN
UN MODELO DE PERSISITENCIA RELACIONAL CONTRA UN
MODELO NO RELACIONAL
Nicolás Lagos Ruiz
Trabajo de grado presentado como requisito para optar al
Título de:
Ingeniero de Sistemas
Director:
M.Sc. NANCY GELVEZ GARCÍA
Codirector:
ESP. JOHN FREDDY PARRA PEÑA
Línea de Investigación:
Ingeniería de Software
Universidad Distrital Francisco José de Caldas Facultad de Ingeniería
Nota de aceptación:
________________________________
________________________________ ________________________________ ________________________________ ________________________________ _______________
Firma del Director del Trabajo de Grado
_________________________________
Firma del jurado
_________________________________
Dedicatoria
A mis padres y mis hermanos del alma por estar siempre.
Por su apoyo incondicional, su ayuda y amor
Agradecimientos
A Dios por darme la oportunidad de concretar este importante proyecto y paso en mi vida.
A mis padres por su paciencia, acompañamiento, consejo, compresión, amor y guía infinitos.
A mi hermano Andrés por el acompañamiento y ayuda durante el proceso de elaboración.
A mi directora de Tesis el M.Sc. Nancy Gelvez Garcia y mi codirector ESP. John Freddy Parra Peña por sus enseñanzas y su acompañamiento.
A Andrés Hamir Cobos Prada por su asesoría técnica y acompañamiento.
A Daniel Felipe Garzón Triana por su ayuda en la redacción.
A mis hermanos del alma por su apoyo incondicional.
A la universidad Distrital Francisco José de Caldas por la educación y formación recibidas a lo largo de mi carrera.
Resumen
La minería de datos ha tomado relevancia en los últimos años, lejos de ser un tema nuevo, es un tema que gana popularidad por ciertos periodos de tiempo, haciéndose evidente la necesidad que tienen las organizaciones por convertir en información útil la gran cantidad de datos que reciben en la actualidad.
Dentro de las herramientas existentes en el espectro de la minería de datos existe un enfoque llamado árboles de decisión, usado para construir un árbol de relaciones entre diferentes conjuntos de datos de manera probabilística, y haciendo uso de la entropía de la información y otras técnicas.
En este documento se implementa un algoritmo generador de árboles de decisión, utilizando dos enfoques similares pero con distinto propósito; modelos de persistencia relacional y no relacional, ambos modelos considerados dentro de un ambiente clusterizado.
Dentro de la implementación del algoritmo C4.5, algoritmo generador, se construyó un modelo de persistencia relacional utilizando PostgreSQL como motor de base de datos y Pgpool como gestor del clúster. En contraparte, la implementación del modelo de persistencia no relacional se construyó utilizando Hadoop, solución clusterizada por definición y su sistema de archivos HDFS.
Finalmente, se ejecutan ambas implementaciones sobre un conjunto de datos de control y un conjunto de datos “real”, comparando sus resultados por medio de una métrica, mostrándolos y proponiendo posibles trabajos futuros.
Abstract
Data mining has been a trending topic in recent years, but far from being a new trend, it gains some popularity by time to time, making evident that data analytics’ and data storage is a must today for every organization.
There are a lot of tools for data mining. One of them is decision trees, used to make a relationship tree among different data sets in a probabilistic way and making use of entropy of information and another informatics tools.
This document shows two different approaches of decision tree, using the relational model and the non-relational model; both of them using a clustered environment.
Using C4.5 as the algorithm to make the decision tree, PostgreSQL, a free source database, was selected as the relational solution, and Pgpool as cluster manager. On the other hand, Hadoop was used as non-relational solution, clustered by default and its powerful data processor HDFS as storage technique.
Finally, the results of running both implementations, using a test set and another with “real life data”, making a comparison by the use of a metric were shown, besides future works.
Tabla de contenido
Introducción ... 13
Formulación del Problema ... 14
Justificación ... 15
Objetivos ... 16
Objetivo General... 16
Objetivos Específicos ... 16
Estado del arte y marco de referencia ... 16
Bases de datos relacionales... 16
Comparación de algunas bases de datos relacionales ... 19
Bases de datos no relacionales... 19
Comparación de algunas bases de datos no relacionales ... 20
Comparación bases de datos relacionales contra bases de datos no relacionales ... 21
Hadoop... 22
MapReduce ... 23
PgPool II ... 25
Algoritmo C4.5 ... 26
Implementación C4.5 ... 31
Precondiciones y Postcondiciones ... 31
Procesamiento Hadoop ... 32
Procesamiento PostgreSQL ... 34
Cálculo entropía y llamado recursivo... 35
Diagrama de clases algoritmo C4.5... 37
Mapred-site ... 42
Yarn-site ... 43
Clúster PostgreSQL ... 45
Elaboración Conjunto de Datos ... 46
Elaboración Métrica ... 49
Pruebas y Resultados ... 52
Conjunto Depurado ... 53
Weather ... 57
Conclusiones y Trabajo Futuro ... 59
Lista de Figuras
Figura 1 Esquema MapReduce. Fuente: elaboración propia ... 24
Figura 2 Estructura MapReduce. Fuente: elaboración propia ... 24
Figura 3 Algoritmo C4.5. Fuente: elaboración propia ... 27
Figura 4 Diagrama MapReduce operación inicial. Fuente: elaboración propia ... 33
Figura 5 Diagrama MapReduce operación final. Fuente: elaboración propia ... 34
Figura 6 Estructura datos C4.5 Fuente: elaboración propia ... 36
Figura 7 Diagrama de clases implementación Hadoop. Fuente: elaboración propia ... 38
Figura 8 Diagrama de clases implementación PostgreSQL. Fuente: elaboración propia ... 38
Figura 9 Configuración core-site.xml. Fuente: elaboración propia ... 41
Figura 10 Configuración hdfs-site.xml Fuente: elaboración propia ... 42
Figura 11 Configuración mapred-site.xml Fuente: elaboración propia ... 42
Figura 12 Configuración yarn-site.xml Fuente: elaboración propia ... 43
Figura 13 Archivo de configuración Hosts. Fuente: Elaboración propia ... 44
Figura 14 Información Nodos. Fuente: Elaboración propia ... 44
Figura 15 Información Datanode. Fuente: Elaboración propia ... 45
Figura 16 Configuración PgPool. Fuente: Elaboración propia ... 46
Figura 17 Resultado Conjunto Depurado-2, implementación Hadoop. Fuente: Elaboración propia ... 53
Figura 18 Resultado Conjunto Depurado-2, implementación Pgpool. Fuente: Elaboración propia ... 54
Figura 19 Resultado Conjunto Depurado-2, Hadoop vs Pgpool. Fuente: Elaboración propia ... 54
Figura 20 Resultado Conjunto Depurado-4, implementación Hadoop. Fuente: Elaboración propia ... 55
Figura 21 Resultado Conjunto Depurado-4, implementación Pgpool. Fuente: Elaboración propia ... 56
Figura 22 Resultado Conjunto Depurado-4, Hadoop vs Pgpool. Fuente: Elaboración propia ... 57
Figura 23 Resultado Conjunto Weather, implementación Hadoop. Fuente: Elaboración propia . 57 Figura 24 Resultado Conjunto Weather, implementación Pgpool. Fuente: Elaboración propia .. 58
Lista de ecuaciones
Lista de tablas
Tabla 1 Comparación de bases de datos relacionales. Fuente: elaboración propia ... 19
Tabla 2 Comparación bases de datos no relacionales. Fuente: elaboración propia ... 21
Tabla 3 Bases relacionales VS No relacionales, tomada de mongoDB.com adaptada por el autor ... 22
Tabla 4 Ejemplo archivo de entrada. Fuente: elaboración propia ... 32
Tabla 5 Ejemplo tabla Atributos PostgreSQL. Fuente: elaboración propia... 35
Tabla 6 Características clúster. Fuente: elaboración propia ... 40
Tabla 7 Atributos conjunto de datos. Fuente: Elaboración propia... 47
Tabla 8 Conjunto de datos depurado. Fuente: Elaboración propia ... 48
Tabla 9 Conjunto de datos Weather. Fuente: http://storm.cis.fordham.edu/~gweiss/data-mining/weka-data/weather.nominal.arff ... 49
Tabla 10 Tamaños muestras. Fuente: Elaboración propia ... 50
Introducción
Los temas relacionados con las tecnologías de la información están a la orden del día, cuando
se habla de innovación y el mejoramiento de los procesos productivos en ámbitos, tanto
académicos como empresariales, es un tema imperdible, todos quieren sacar provecho de estas
tecnologías y desean tener la vanguardia de las mismas, buscando obtener ventajas estratégicas
sobre sus pares.
De la mano de las tecnologías de la información, necesariamente se trata el tema de la
persistencia, empezando por el ya clásico enfoque relacional hasta llegar a enfoques más recientes
como Big Data, Minería de Datos, bases de datos no relacionales, entre otros.
En lo referente a la persistencia, el solo hecho de guardar datos, mantener su integridad y
seguridad ya no es suficiente. Dentro de estos datos se esconde información valiosa que no se
puede ver “a simple vista” y se hace necesaria la utilización de herramientas para extraer la misma,
recordando que la información es el activo más valioso para cualquier organización. [1]
Gracias al uso de ambas tecnologías de persistencia relacional y no relacional, las
organizaciones cuentan con herramientas para almacenar datos, recopilar información, y tomar
decisiones.
Con este trabajo se pretende mostrar ambos modelos, ofreciendo una comparación en aspectos
muy específicos de tecnologías de persistencia; esperando dar al lector una idea del potencial de
Formulación del Problema
Actualmente se generan grandes volúmenes de información de fuentes muy diversas, como lo son las transacciones de las organizaciones, las redes sociales, los sensores de los diferentes aparatos electrónicos, el internet de las cosas, entre muchos otros. Estos datos deben ser capturados y almacenados, dependiendo de su fuente se puede crear su persistencia de diferentes maneras, si los datos son estructurados, se pueden almacenar fácilmente en un sistema de bases de datos relacional, pero si por el contrario carecen de estructura, será recomendable usar alguna de las múltiples tecnologías no relacionales, no solo para reducir los costos de persistencia, sino que también para no perder información en la restructuración de los datos.
Cuando se trabaja con cualquier modelo, sin duda lo más importante es la información que se puede adquirir del mismo. Esta información puede ser utilizada de diferentes maneras, dependiendo la lógica con la que trabaje el negocio. Existen diferentes técnicas para adquirir, organizar y explotar los datos usando herramientas muy variadas.
Dentro de las técnicas de procesamiento de la información, existe una con el fin de realizar predicciones, conocida como árboles de decisión. Esta busca, partiendo de un conjunto de datos, de los cuales se conocen sus entradas y salidas, llamado conjunto de entrenamiento, poder predecir la salida de otro conjunto de datos de los cuales solo se conoce la entrada. Dentro de esta categoría existe un algoritmo llamado C4.5 [2].
Al trabajar con el algoritmo C4.5 surge la pregunta ¿en qué modelo de persistencia se obtendrán mejores resultados para el algoritmo C4.5?, ¿relacional o no relacional?
conjunto de datos, y bajo una misma implementación, para después, por medio de una métrica verificar en qué tipo de estructura de datos se obtuvieron los mejores resultados.
Justificación
En el contexto de la persistencia es necesario llegar más allá que el simple hecho de capturar y almacenar datos, aunque con esto se puede llegar a satisfacer las necesidades del negocio, es necesario aprovechar el potencial de la información, considerado por muchos autores como el activo más importante con el que cuentan las organizaciones hoy en día [1]. Para esto, además de la infraestructura para capturar los datos y almacenarlos, es necesario utilizar técnicas que permitan extraer de los mismos, información que se escape a simple vista o a la lógica del negocio de la organización. Con esto se busca inferir patrones y comportamientos que escapen a la intuición humana.
En el caso concreto de esta problemática, se encuentran ejemplos como: realizar predicciones con datos que permitan facilitar la toma de decisiones, realizar predicciones de esparcimiento de una epidemia, patrones de comportamiento humano, entre un sinfín más de aplicaciones que tiene el campo en mención.
Sin embargo, utilizar el algoritmo para operar un conjunto de datos no garantiza su éxito, es necesario evaluar las características del conjunto de entrada y la forma en la que fueron indexadas y almacenadas en la tecnología de persistencia que se utilizó para posteriormente comparar y verificar su efectividad contra un conjunto de prueba, evaluando a su vez que tan sensible es el proceso con respecto al origen y la forma en la que se almacenaron los datos.
Finalmente, con los resultados obtenidos y evaluados por medio de la métrica se expondrán las conclusiones y se harán recomendaciones en lo referente al tema.
Objetivos
Objetivo General
Implementar el algoritmo de clasificación de árboles de decisión C4.5 basado en un modelo de datos relacional y en uno no relacional en un clúster, para posteriormente, por medio de una métrica, evaluar su efectividad sobre un conjunto de datos.
Objetivos Específicos
Implementar el algoritmo C4.5 basado en un modelo de persistencia relacional.
Implementar el algoritmo C4.5 basado en un modelo de persistencia no relacional.
Aplicar una métrica para evaluar los resultados en ambos modelos de persistencia.
Estado del arte y marco de referencia
El siguiente apartado contiene conceptos y definiciones claves para ayudar al lector a comprender el contenido de este trabajo.
Bases de datos relacionales
Una base de datos relacional [3] sigue el modelo relacional que tiene su base en el álgebra de conjuntos y almacena su información en tablas con columnas y filas. Una tabla es una relación que tiene sentido en las columnas para objetos del mismo tipo, en este caso las filas. Este modelo cuenta con un alto grado de madurez y es el modelo más popular de persistencia.
colecciones de grupo. Una tercera regla de integridad involucra el concepto de valor nulo, el cual indica que el valor no existe y que es diferente de un valor en blanco o en cero, donde dos valores nulos no son considerados iguales.
Las reglas de Codd [4] son un conjunto de reglas que, de acuerdo a Edgar Codd, debe cumplir un sistema de bases de datos relacional para serlo. A continuación las reglas de Codd.
Regla 1 (regla de la información): Toda la información contenida en la base de datos
debe estar almacenada en tablas y filas, tanto la información del usuario como la
meta información del sistema de bases de datos.
Regla 2 (acceso garantizado): Para cada elemento atómico de datos debe ser
garantizado el acceso lógico con una combinación de tabla, llave primaria y nombre
del atributo.
Regla 3 (tratamiento sistemático del valor nulo): Los valores nulos deben recibir un
tratamiento sistemático y uniforme.
Regla 4 (Catalogo activo): La descripción de la estructura de la base de datos debe
estar almacenada en un catálogo conocido como el diccionario de datos, el cual solo
puede ser accedido por usuarios autorizados, los usuarios pueden acceder al
catálogo por un lenguaje de consultas, que se usa para también para acceder a la
base de datos.
Regla 5 (Lenguaje de datos comprensivo): A la base de datos solo se puede acceder
usando un lenguaje con una sintaxis lineal que soporte definición, manipulación y
aplicación, si se accede a la base de datos sin ayuda de este lenguaje se considera
una violación.
Regla 6 (Regla de la actualización): Todas las vistas de la base de datos que puedan
ser actualizadas deben ser actualizables también por el sistema.
Regla 7 (Inserción, actualización y eliminación de alto nivel): El sistema de bases
de datos debe soportar las operaciones de alto nivel y no deben estar limitadas a una
sola fila, deben soportar los operadores de unión, intersección entre otras
operaciones de conjuntos.
Regla 8 (Independencia física de los datos): El almacenamiento de los datos debe
ser independiente del acceso a las aplicaciones, ningún cambio en la estructura
física de la base de datos debe tener efectos en como son accedidos los datos por
aplicaciones externas.
Regla 9 (Independencia lógica de los datos): La composición lógica de los datos
debe ser independiente del punto de vista de la aplicación, cualquier cambio en la
lógica de los datos no debe afectar las aplicaciones que las usan.
Regla 10 (Independencia de la integridad): La base de datos debe ser independiente
de la aplicación que la usa, su estructura debe poder modificarse sin necesidad de
modificar la aplicación.
Regla 11 (Independencia de distribución): Debe ser transparente para el cliente la
distribución física de los datos, para el usuario debe verse como si todo estuviera
Regla 12 (No subversiones): No se debe poder modificar el sistema de bases de
datos accediendo con lenguajes de más bajo nivel.
Comparación de algunas bases de datos relacionales
En la tabla 1 se muestra una comparación de las características de algunos motores de bases de datos relacionales. [5]
Microsoft SQL Server
PostgreSQL Oracle
Licencia Propietaria Open source Propietaria
Sistema Operativo Windows Windows, OS X, Linux, BSD, Unix,
Tablas y vistas Tablas temporales, vistas materializadas
Tablas temporales, vistas materializadas
Tablas temporales, vistas materializadas
Objetos Cursor, Trigger,
Funciones, Tabla 1 Comparación de bases de datos relacionales. Fuente: elaboración propia
Bases de datos no relacionales
Tipos de bases no relacionales
Documentos: Relaciona cada llave con una compleja estructura de datos conocida
como documento, un documento contiene varias tuplas de llaves que son
almacenadas en documentos.
Almacenamiento en grafos: Son usadas para almacenar información relacionada
con redes, como por ejemplo conexiones sociales o redes de epidemias.
Almacenamiento de llave: Cada tupla tiene una llave asociada, donde el tipo de
valor puede ser de diferente tipo de dato.
Columnas horizontales: Son bases de datos optimizadas para almacenamiento en
grandes conjuntos de datos utilizando columnas en vez de filas.
Tipos de bases no relacionales
Comparadas con las bases de datos relacionales, las bases de datos no relacionales ofrecen más escalabilidad y tienen un rendimiento mejor, su modelo de datos resuelve problemas que las bases de datos relacionales no pueden. Permiten almacenar grandes volúmenes de datos estructurados, semiestructurados y no estructurados, además de iteraciones rápidas, agilidad superior; programación nativa orientada a objetos flexible y fácil de usar; eficiente, escalamiento fuera de la arquitectura, haciéndolas más eficientes que el modelo monolítico arquitectural del modelo relacional.
Comparación de algunas bases de datos no relacionales
Cassandra MongoDB Berkeley DB -Licencia apache.
-Protocolo CQL3, muy parecido a SQL pero con algunas limitaciones por ejemplo sin joins o funciones de agregado
-Búsqueda por llave o rangos de llave. -Los datos pueden tener fecha de
-Es posible escribir triggers en Java.
-Protocolo BSON.
-Soporta indicies tanto
primarios como memoria o disco duro como se requiera.
-Función de encriptado. -Replicación del tipo maestro, esclavo.
Tabla 2 Comparación bases de datos no relacionales. Fuente: elaboración propia
Comparación bases de datos relacionales contra bases de datos no relacionales
Para entender las características y diferencias entre ambas tecnologías, en la tabla 3 se hace una comparación de ambas, tomada de mongoDB [6] y adaptada por el autor.
Relacional No relacional
Tipos SQL con pequeñas variaciones. Gran variedad incluyendo bases de datos documentales, de grafos entre otras.
Modelo de almacenamiento
Registros individuales, almacenados como filas en tablas, almacenando información específica del registro, es necesario cruzar las diferentes tablas del datos orientadas a documentos almacenan los registros en una estructura llamada documento en formatos como JSON o XML.
Escalamiento Vertical, cada servidor debe ser bastante potente para lidiar con la demanda creciente, se pueden crear bases de datos distribuidas pero el costo aumenta de manera significativa.
Horizontal, para aumentar la potencia tan solo es necesario añadir más nodos, la base de datos automáticamente se encarga del resto.
Esquemas Cuenta con un esquema fijo, para almacenar nueva información en necesario modificar el esquema.
Generalmente es dinámico, puede añadirse nueva información en caliente, a diferencia de las bases de datos SQL.
Por medio de un lenguaje de query especifico y derivado de SQL.
Por medio de APIs orientadas a objetos.
Consistencia Fuerte nivel de consistencia. Depende de la lógica del negocio. Tabla 3 Bases relacionales VS No relacionales, tomada de mongoDB.com adaptada por el autor
Hadoop
Hadoop [8] es un proyecto de software libre destinado para la computación distribuida de manera confiable y escalable. Hadoop es un framework que facilita la computación distribuida de grandes conjuntos de datos a través de clústeres de computadores, usando un modelo simple de programación. Está diseñado para escalar desde una simple máquina a miles de ellas, cada una ofreciendo computación y almacenamiento.
clúster, adicionalmente, manejando el control de fallos de los diferentes nodos, ofreciendo un mejor desempeño.
Hadoop incluye las siguientes funcionalidades:
Hadoop Common: Núcleo del framework en el cual se basan las demás
funcionalidades.
Hadoop Distributed File System: Sistema de archivos que proporciona gran
flexibilidad sobre conjuntos de datos grandes.
Hadoop YARN: Agente encargado del manejo de las diferentes tareas y su
distribución en los diferentes componentes del clúster.
Hadoop MapReduce: Sistema basado en YARN para el procesamiento de grandes
cantidades de datos.
MapReduce
Es un algoritmo creado por Google [9] para procesar grandes conjuntos de datos por medio de computación distribuida, usando computadores de bajo costo, siendo de los más populares. Este modelo está compuesto de dos funciones: Map y Reduce. La labor principal de MapReduce es dividir los datos en diferentes bloques lógicos; como entrada y salida se utilizan tuplas del tipo llave/valor.
Figura 1 Esquema MapReduce. Fuente: elaboración propia
Por lo general, la función Reduce tiene una salida binaria, los programas que implementan MapReduce se pueden ejecutar en los siguientes modos.
Autónomo: se ejecuta en tan solo un solo equipo, es decir un clúster con solo un nodo.
Pseudo-distribuido: se crean nodos virtuales en una sola máquina, es un clúster con nodos
virtuales.
Distribuido: modo completamente funcional con múltiples maquinas funcionando como
nodos dentro del clúster.
Finalmente la estructura de MapReduce es mostrada en la Figura 2.
PgPool II
PgPool, según la wiki oficial de los desarrolladores [10], es un middleware que funciona entre los servidores de PostgreSQL y los clientes de la base de datos. Cuenta con licencia BSD y provee las siguientes características.
Pool de conexiones: Pgpool almacena las conexiones utilizadas para acceder a los
diferentes servidores PostgreSQL, y en caso de que las credenciales de conexión
de otra solicitud sean idénticas a las existentes, reutiliza las existentes, evitando la
creación innecesaria de conexiones.
Replicación: PgPool puede manejar múltiples servidores de PostgreSQL, usando
la función de replicación se tiene la posibilidad de replicar dos o más discos físicos,
evitando de esta manera la interrupción del servicio en caso de falla de algún disco
en los nodos.
Balance de carga: En caso de que la base de datos sea replicada, al ejecutar una
operación de tipo SELECT se deben obtener los mismos resultados. Aprovechando
este hecho, PgPool distribuye las operaciones SELECT en los diferentes servidores
PostgreSQL para mejorar la velocidad con la que se realizan las consultas, este
beneficio se ve más claramente si la consulta regresa gran cantidad de tuplas y si
se cuenta con gran número de nodos.
Limite en el número de conexiones: PostgreSQL tiene un máximo número de
conexiones simultáneas, una vez alcanzado este tope regresa un error impidiendo
logre el máximo número de conexiones, la solicitud se pone en esperar en vez de
generar error.
PgPool funciona como un puente entre el cliente y los diferentes servidores PostgreSQL, estableciendo un canal de comunicación entre los dos. Adicionalmente los clientes y los servidores no hacen distinción entre PgPool y una instancia más de PostgreSQL, por lo que no es necesario ningún desarrollo adicional en ninguna de las plataformas implicadas.
Algoritmo C4.5
El algoritmo C4.5 [2] desarrollado por Ross Quinlan es un algoritmo para generar árboles de decisión, es una mejora del algoritmo ID3 del mismo autor. El algoritmo C4.5 usa un conjunto de entrenamiento para construir el árbol de decisiones, usando el concepto de entropía de la información. El conjunto de entrenamiento está compuesto por n instancias ya clasificadas, donde cada instancia es un vector de Xn características, donde cada x1, x2,…, xn es un atributo o atributos de la instancia. A cada vector c1, c2,…, cn de características se le conoce como la clase a la cual pertenece cada instancia.
En cada nodo del árbol, el algoritmo elige un atributo de los datos que los divida de la manera más efectiva en un subconjunto, buscando diferenciar de la mejor manera las diferentes clases, el criterio que usa es la ganancia de información de los resultados de elegir un atributo u otro, el atributo con la mayor ganancia será escogido para realizar la división.
Adicionalmente, el algoritmo maneja algunos casos base:
Todas las muestras pertenecen a la misma clase: en este caso simplemente se crea
Ninguna de las características proporciona ganancia de información: en este caso
se crea un nodo hacia arriba del árbol con el valor esperado.
Se encuentra una clase no vista antes: en este caso se crea un nodo hacia arriba del
árbol usando el valor esperado.
A continuación en la Figura 3 el pseudocódigo del algoritmo.
Figura 3 Algoritmo C4.5. Fuente: elaboración propia
Cálculo de la entropía y la ganancia
El cálculo de la entropía y de la ganancia de información se hace como se enseña en las Ecuaciones 1 y 2.
E:(S)= ∑ - Pr(Ci) * log2Pr(Ci)
n
i=1
Ecuación 1 Entropía
G:(S,A)= E(S) - ∑ Pr(Ai) E(𝑆𝐴𝑖) 𝑚
i=1
Ecuación 2 Ganancia
Donde los valores son los siguientes: S – conjunto de datos.
E(S) – entropía de S.
G(S,A) – ganancia de S después de hacer un división en el atributo A.
n – número de clases en S.
Pr(Ci) – frecuencia de la clase Ci en S.
m – número de valores del atributo A en S.
Pr(Ai) – frecuencia de los casos que tiene Ai en S
El cálculo de estos valores junto con el llamado recursivo del algoritmo constituye la parte esencial del C4.5.
Casos de éxito del algoritmo C4.5
A continuación se citan algunos trabajos realizados con el algoritmo C4.5. Reconocimiento facial con el algoritmo C4.5 extendido. [12]
El reconocimiento facial es un ejemplo típico de evaluación de datos basados en la
sensibilidad, uno de los mayores problemas son las dificultades con la ambigüedad
y el procesamiento de los objetivos en la búsqueda de una clave de identificación
efectiva. En este trabajo se propuso un mecanismo de reconocimiento de imágenes
con una versión extendida del algoritmo C4.5 como mecanismo de identificación,
utilizando una métrica para verificar las salidas con buenos resultados.
Procesamiento de diabetes tipo 2 con maximización de la expectativa y el algoritmo
C4.5. [13]
Está investigación utilizó el algoritmo C4.5 y EM para elaborar un sistema de
procesamiento de datos de diabetes tipo 2. Tomando como fuente de datos casi
14000 muestras de múltiples fuentes, de varias dimensiones y una serie de
experimentos de minería de datos anteriores. Con esa cantidad de datos se descubrió
un comportamiento patológico de la diabetes tipo 2, donde se puede corroborar que
el árbol de decisión obtenido es casi idéntico con la lista clínica de factores de riesgo
de la diabetes. Adicionalmente, los positivos positivos, (personas sanas), fue del
80.9% y los negativos positivos, (personas con la enfermedad), fueron 92.05%, este
Conservación de la privacidad sobre datos particionados de manera horizontal con
el algoritmo C4.5. [14]
La conservación de la privacidad en un entorno de computación distribuida es lo
que se busca con la implementación del algoritmo C4.5. En un escenario donde se
busca elaborar un árbol de decisión con datos distribuidos en diferentes nodos de
una plataforma de computación distribuida, el objetivo es que los nodos no
compartan información sensible, utilizando técnicas de seguridad multi-party de
computación, permitiendo elaborar el árbol de decisión, tanto con valores discretos
como continuos, y garantizando la privacidad al mismo tiempo.
Minería de datos con el algoritmo C4.5 y virtualización de cartografía interactiva.
[15]
Considerando la utilización de técnicas del descubrimiento del conocimiento en
bases de datos, se busca combinar varias de estas técnicas para crear clasificación
de objetos espaciales por medio de mapas. Con los mapas se busca tanto la
preparación de los datos como la interpretación de los mismos.
Detectando errores de software con el algoritmo C4.5. [16]
Las métricas de detección de defectos en el software generalmente están
relacionadas con el proceso de creación del mismo, en vez de enfocarse al momento
de puesta en producción. Sin embargo, aún existe el problema de utilizar una técnica
de predicción de fallos en este tipo de ambiente. En este trabajo se propone un una
técnica de predicción de errores por medio del algoritmo C4.5, con pruebas
Implementación C4.5
Este capítulo abarca todo lo relacionado con el desarrollo del algoritmo C4.5, usando como lenguaje base Java™ y combinándolo con las diferentes tecnologías de persistencia propuestas para llevar a cabo este proyecto. Es importante destacar que ambas implementaciones, Hadoop, PostgreSQL, no se utilizan tan solo para guardar datos, sino que también buscan entrelazarse con la funcionalidad del algoritmo, buscando tanto beneficios como desventajas que ofrecen las tecnologías mencionadas anteriormente.
Precondiciones y Postcondiciones
Para el caso de las dos implementaciones se contempla que tengan tanto la misma entrada como la misma salida, esto con el fin de darle homogeneidad al problema y facilitar de esta manera cálculos en tiempos de ejecución y otros aspectos a tener en cuenta en el momento de evaluar el algoritmo.
La fuente de entrada de información de la implementación del algoritmo será un archivo plano (.txt) que contiene información de los diferentes atributos asociados y su valor de clase correspondiente, cada valor se da en una línea, para que de esa manera se interprete cada una de las líneas del archivo como un valor de atributo asociado a su vez a un valor de clase. De igual forma, los valores de cada línea contendrán el valor de atributo y su posición indicará a que atributo hace referencia, los valores de los distintos atributos están separados por coma (,) y el valor final de cada línea será el valor de clase asociado a la combinación de valores de atributo que le anteceden, esta manera de organizar el conjunto de entrada fue inspirada en la manera en la que se realiza en Weka. En la Tabla 4 se muestra un ejemplo del conjunto de entrada.
sunny,hot,high,FALSE,no
sunny,hot,high,TRUE,no
overcast,hot,high,FALSE,yes
rainy,mild,high,FALSE,yes
rainy,cool,normal,FALSE,yes
Atributo 1: outlook, posibles valores (sunny, overcast, rainy).
Atributo 2: temperature, posibles valores (hot, mild, cool).
Atributo 3: humidity, posibles valores (high, normal).
Atributo 4: windy posibles valores (TRUE, FALSE).
Valor de clase: posibles valores (yes, no)
Tabla 4 Ejemplo archivo de entrada. Fuente: elaboración propia
La salida del algoritmo, en ambos casos, es un árbol de decisión creado con base en los datos del conjunto de entrada. Este árbol se presenta de manera plana como una estructura de datos, sin representación visual.
Procesamiento Hadoop
Figura 4 Diagrama MapReduce operación inicial. Fuente: elaboración propia
Figura 5 Diagrama MapReduce operación final. Fuente: elaboración propia
El archivo plano generado después de aplicar las funciones de Hadoop será el utilizado para realizar el cálculo de la entropía.
Procesamiento PostgreSQL
De manera similar al procesamiento en Hadoop, PostgreSQL toma el conjunto de datos inicial y los transforma para realizar las operaciones del algoritmo, tomando los datos del archivo plano y pasándolos a la base de datos.
Id Valor Fila Clase
0 sunny 0 no
0 sunny 1 no
0 overcast 2 yes
1 hot 0 no
1 hot 1 no
1 mild 3 yes
Tabla 5 Ejemplo tabla Atributos PostgreSQL. Fuente: elaboración propia
La tabla generada a partir del archivo plano será la base para el cálculo de la entropía.
Cálculo entropía y llamado recursivo
En ambos casos (Hadoop y PostgreSQL) se toman sus salidas después de procesar el conjunto de datos del archivo plano y se almacena en una estructura temporal para su procesamiento en Java, las cuales son abstraídas por medio de 3 objetos Java (clases) para su procesamiento.
Atributo: clase que contiene la información que se puede generar de un atributo
(valores del conjunto de datos (ValorAtributo), la entropía del atributo y su
identificador).
ValorAtributo: clase que contiene la información asociada a los diferentes valores
que toma un atributo (nombre del valor de atributo, valor de clase que tomó el valor
ValorClase: clase que contiene la información asociada al valor de clase que
pueden tomar los valores de atributo (nombre clase, cantidad de ocurrencias de ese
valor de clase).
Toda la abstracción necesaria para ejecutar el algoritmo C4.5 de manera correcta se logra utilizando listas de los 3 tipos de clases mencionados anteriormente, donde la clase Atributo contiene listas de la clase ValorAtributo y esta a su vez contiene listas de la clase ValorClase como se ilustra en la Figura 6.
Una vez generada la estructura de datos con base en la salida, se procede a iterar cada uno de los valores para calcular su entropía como se describe en la sección cálculo de la entropía, lo cual genera un valor de ganancia por atributo y una entropía general del conjunto de atributos, donde se procederá a hacer una comparación de las diferentes ganancias para elegir el atributo que
Atributo
aporte más información. Una vez elegido el atributo de mayor ganancia se procede a comparar con un límite de ganancia aceptable, el cual es parametrizable. De ser mayor al límite aceptable, el Atributo elegido se toma para realizar la siguiente partición.
El proceso anterior se repite de manera recursiva a medida que se eligen los atributos ganadores, creando un subconjunto del conjunto de entrada original, tomando como divisor los valores que puede tomar el atributo ganador en cada división y repitiendo los pasos con este subconjunto; en caso de que la ganancia aceptable sea mayor que la ganancia de todos los atributos del conjunto o no sea posible seguir haciendo subconjuntos, se detiene el proceso recursivo y se da por terminado el algoritmo.
Diagrama de clases algoritmo C4.5
Figura 7 Diagrama de clases implementación Hadoop. Fuente: elaboración propia
Figura 8 Diagrama de clases implementación PostgreSQL. Fuente: elaboración propia
Universidad.distrital.c45
Paquetería general y contenedora de las clases C4.5 y Entropía encargadas de realizar las tareas del algoritmo como se explicó en la sección cálculo de la entropía y llamado recursivo.
Universidad.distrital.c45.estructura
Universidad.distrital.c45.mapper
Contiene las clases que realizan las actividades de map en la implementación de Hadoop explicadas en la sección prepocesamiento Hadoop.
Universidad.distrital.c45.reducer
Contiene las clases que realizan las actividades de reduce en la implementación de Hadoop explicadas en la sección prepocesamiento Hadoop.
Universidad.distrital.c45.sql
Contiene las clases que realizan las actividades de mapeo en la implementación de Hadoop explicadas en la sección prepocesamiento PostgreSQL y una clase conexión encargada de manejar la conexión del algoritmo a la base de datos.
Elaboración Clúster
Adicionalmente a la implementación del algoritmo C4.5, el objetivo general de este trabajo involucra la ejecución del mismo en un clúster, en este caso, compuesto por tres nodos conectados en una red LAN. Realizar la ejecución en un ambiente clusterizado proporciona mayor fiabilidad y velocidad de procesamiento al momento de ejecución, ventaja que se hace más evidente a medida que aumenta el conjunto de datos a procesar.
Una de las ventajas que ofrecen las soluciones en clúster es tener mayor capacidad de procesamiento con diferentes tipos de hardware, facilitando de esta manera el escalamiento de soluciones sin necesidad de un presupuesto amplio. Para la ejecución del algoritmo C4.5 se usó un clúster con las siguientes características, mostradas en la Tabla 6:
Maestro Intel Core
i7-Tabla 6 Características clúster. Fuente: elaboración propia
Aunque ambas soluciones (Hadoop, PostgreSQL) usan el mismo hardware, la configuración del clúster no es la misma para ambos casos, en el caso de Hadoop se debe configurar un ambiente distribuido y en el de PostgreSQL se utilizará PgPool II, como se explica en las siguientes secciones. Sin embargo, ciertas configuraciones son comunes, es necesario contar con Java 7 o superior, (ya que la implementación está construida en esta versión del lenguaje), y como medio de comunicación en ambas soluciones se usa el protocolo SSH, siendo este un medio seguro y confiable de comunicación entre los diferentes nodos del clúster.
Clúster Hadoop
Adicionalmente a la instalación de Hadoop es necesaria la configuración de sus diferentes nodos donde varía la configuración dependiendo si el nodo es esclavo o maestro, donde el nodo maestro tendrá la responsabilidad de gestionar los recursos del clúster y si se desea también, el procesamiento de datos, de lo contrario, se delega el procesamiento de datos a los nodos esclavos del clúster. Esta decisión se toma dependiendo de los recursos con los que se cuente. En el caso de esta implementación el nodo maestro también procesará datos.
configuraciones en estos archivos, Hadoop tomará las configuraciones por defecto, su configuración se muestra a continuación.
Core-site
Contiene la configuración asociada al core de Hadoop como la configuración de entrada y salida, entre otras configuraciones comunes a HDFS y a MapReduce, en este caso se especifica que el core se encuentra en el nodo maestro como se ve en la Figura 9.
Hdfs-site
Contiene la configuración de los demonios del HDFS, el NameNode, el Seconday NameNode y los DataNodes. En este archivo de configuración se puede especificar el número de bloques de replicado, los permisos sobres HDFS, el número de replicaciones entre otros. Para el clúster se especificó el factor de replicación (3), la ruta donde se encuentra el DataNode y la ruta donde se encuentra el NameNode como se ve en la figura 10.
Figura 10 Configuración hdfs-site.xml Fuente: elaboración propia
Mapred-site
Contiene la configuración de los demonios del MapReduce, el JobTracker y los TaskTrackers. Para el clúster se indica que el JobTracker será el del nodo maestro y que el framework del MapReduce será Yarn como se ve en la figura 11.
Yarn-site
Contiene toda la configuración asociada al manejo del yarn. En el caso del clúster se establecen los servicios auxiliares, la ruta del JobTracker, la ruta del scheduler y la ruta del ResourceManager, en ese caso todas apuntan al nodo maestro como se muestra en la figura 12.
Figura 12 Configuración yarn-site.xml Fuente: elaboración propia
Figura 13 Archivo de configuración Hosts. Fuente: Elaboración propia
Si se realizó de manera correcta la configuración Hadoop, se debe ver todos los nodos del clúster cuando se acceda al administrador del sitio como se muestra en la Figura 14.
Figura 14 Información Nodos. Fuente: Elaboración propia
Figura 15 Información Datanode. Fuente: Elaboración propia
Clúster PostgreSQL
Elaboración Conjunto de Datos
El conjunto de datos se creó buscando que fuera homogéneo para las dos implementaciones del algoritmo C4.5. También se buscó que fueran tan solo datos nominales (pues la implementación no soporta entradas del tipo numérico aunque el algoritmo original sí) y adicionalmente, que un valor del conjunto de datos fuera destacado, de tal manera que se pudiera elegir como valor de clase al cual estarán referenciados los demás valores.
Se decidió utilizar un conjunto de datos del servicio general de administración de los Estados Unidos (Data.gov) [17] debido a la gran variedad de datos con los que cuenta y adicionalmente la cantidad de los mismos. El conjunto de datos usado lleva por nombre Consumer Complaint Database (base de datos de quejas de consumidores), el cual contiene datos de las quejas de los usuarios del servicio bancario en Estados como se muestra en la Tabla 7.
Dato Tipo
Información del cliente Texto
Respuesta publica de la entidad Texto
Entidad Texto
Estado (USA) Texto
Código Zip Texto
Tags Texto
Consentimiento del cliente Texto
Medio por el cual se realizó la queja Texto
Día envió queja Fecha
Respuesta de la entidad Texto
Respuesta efectuada a tiempo Booleano
Replicación del cliente Booleano
Id Numérico
Tabla 7 Atributos conjunto de datos. Fuente: Elaboración propia
Se eligió como valor de clase el campo Entidad porque los valores que puede tomar se repiten con regularidad sin perder la variedad de valores posibles, y adicionalmente, se ve como una asociación natural de los demás campos, debido a que los demás atributos se pueden representar como características asociadas al servicio que prestan las diferentes entidades bancarias. En adición, los campos Fecha Recibido, Subproducto, Subproblema, Información Cliente, Tags, Consentimiento del Cliente, Día envío de la Queja, e Id, fueron removidos ya que no cumplían con las condiciones necesarias para ser procesados por el algoritmo, o estaban incompletos, o no aportaban ganancia de información. El conjunto de datos depurado es como se indica en la Tabla 8.
Dato Tipo
Producto Texto
Problema Texto
Estado (USA) Texto
Código Zip Texto
Medio por el cual se realizó la queja Texto
Respuesta de la entidad Texto
Respuesta efectuada a tiempo Booleano
Replicación del cliente Booleano
Entidad Texto
Tabla 8 Conjunto de datos depurado. Fuente: Elaboración propia
entrada valida en la implementación. El conjunto de datos cuenta con 569.495 tuplas de los valores mencionados en la Tabla 8 y asociaos a Entidad como valor de clase.
Por otra parte, se utiliza el conjunto de datos Weater, disponible en los conjuntos de muestra de Weka, el cual tiene una serie de factores climáticos que determinan si es posible o no salir a jugar. El conjunto se muestra en la Tabla 9. El conjunto cuenta con 14 tuplas.
Dato Tipo
Outlook Texto
Temperature Texto
Humidity Texto
Windy Texto
Play Texto
Tabla 9 Conjunto de datos Weather. Fuente: http://storm.cis.fordham.edu/~gweiss/data-mining/weka-data/weather.nominal.arff
Elaboración Métrica
con los conjuntos de datos mencionados en la sección elaboración conjuntos de datos, variando su tamaño como se muestra en la Tabla 10.
Conjunto de datos Tamaño
Depurado-2 x1
Depurado-2 x0.5
Depurado-2 x0.7
Depurado-2 x2
Depurado-2 x3
Depurado-4 x1
Depurado-4 x0.5
Depurado-4 x0.7
Depurado-4 x2
Depurado-4 x3
Weather x1
Weather Tamaño depurado (569.495 tuplas – 3) este ajuste se debe hacer para no perder el orden
de tuplas del conjunto original
Weather Tamaño depurado x0.5
Weather Tamaño depurado x0.7
Weather Tamaño depurado x2
Weather Tamaño depurado x3
El nombre Depurado-4 y Depurado-2 hace referencia al conjunto Depurado original restando ciertas filas, en el caso de - 2 se removió Estado (USA), Código Zip, y en el caso de - 4 se removió Estado (USA), Código ZIP, Respuesta de la Entidad, Respuesta efectuada a tiempo y Replicación del Cliente; debido a que la ejecución del conjunto total tomaba más de 72 horas y no era viable la realización de prueba con ese tiempo de ejecución, pues no se podía garantizar la estabilidad de la red y el suministro eléctrico del clúster por tanto tiempo.
En adición a estos valores, se varía el número de nodos del clúster (1, 2, 3), con el fin de medir la diferencia de rendimiento entre las implementaciones a medida que aumenta el tamaño del conjunto de datos y varían los nodos del clúster. La variación de los nodos se hace quitando primero el Esclavo2 (máquina con menos potencia), luego el Esclavo1 y por ultimo con solo el nodo maestro. Finalmente, la variación del conjunto depurado de datos se hará tomando alguna porción al azar del conjunto y dividiéndola según se crea conveniente, las siguientes subdivisiones se tomarán del mismo conjunto de datos para conservar uniformidad en el proceso, mientras que con el conjunto Weather se amplió al tamaño del conjunto depurado y se modificó acorde al mismo.
En el caso de usarse una muestra más grande que el conjunto de datos, se multiplicara el mismo obteniendo n veces el conjunto de datos. Es importante resaltar que al ampliar el conjunto de datos no se afecta el resultado del algoritmo, ya que al estar repetidas las tuplas se llega a un sesgo donde no se aporta más información que en el caso del conjunto original.
Se harán pruebas con base en lo anteriormente mencionado, como se muestra en la Tabla 11.
3
Tamaños conjunto depurado Tamaños conjunto Weather
2
Tamaños conjunto depurado Tamaños conjunto Weather
1
Tamaños conjunto depurado Tamaños conjunto Weather
Tabla 11 Esquema de pruebas a realizar métrica. Fuente: Elaboración propia
Pruebas y Resultados
Conjunto Depurado
Figura 17 Resultado Conjunto Depurado-2, implementación Hadoop. Fuente: Elaboración propia
En la Figura 17 se observa una ligera disminución en general en tiempos de ejecución a medida que se aumenta el número de nodos, con el tiempo de ejecución más largo en 6912 segundos y el tiempo más corto en 4505 segundos.
0 1000 2000 3000 4000 5000 6000 7000 8000
1 Nodo 2 Nodos 3 Nodos
Depurado-2
Hadoop
Figura 18 Resultado Conjunto Depurado-2, implementación Pgpool. Fuente: Elaboración propia
En la Figura 18 los tiempos de ejecución tienen una variación mínima en cuanto al número de nodos, se puede evidenciar que el tiempo de ejecución crece a medida que se agregan tuplas al conjunto de datos, el tiempo más largo de ejecución fue de 27215 segundos y el más corto fue de 20510 segundos.
Figura 19 Resultado Conjunto Depurado-2, Hadoop vs Pgpool. Fuente: Elaboración propia
En la Figura 19, la comparación entre ambas implementaciones se puede observar una diferencia considerable entre los tiempos de ejecución en general, tomando más tiempo para realizar la ejecución la solución en Pgpool.
Figura 20 Resultado Conjunto Depurado-4, implementación Hadoop. Fuente: Elaboración propia
En la Figura 20 nuevamente se evidencia un cambio en tiempos de ejecución donde la tendencia a disminuir es notable en a medida que aumentan los nodos, el tiempo más largo fue de 5119 segundos y el tiempo más corto fue de 3495 segundos.
0 1000 2000 3000 4000 5000 6000
1 Nodo 2 Nodos 3 Nodos
Depurado-4
Hadoop
Figura 21 Resultado Conjunto Depurado-4, implementación Pgpool. Fuente: Elaboración propia
En la Figura 21 se hacen más marcadas las diferencias en tiempos de ejecución con respecto al conjunto anterior sin embargo no es un diferencia considerable a medida que varían los nodos del clúster, siendo el tiempo de ejecución más corto de 19745 segundos y el más largo de 23201 segundos.
18000 19000 20000 21000 22000 23000 24000
1 Nodo 2 Nodos 3 Nodos
Depurado-4
Pgpool
Figura 22 Resultado Conjunto Depurado-4, Hadoop vs Pgpool. Fuente: Elaboración propia
En la Figura 22 se puede observar nuevamente una diferencia considerable en tiempos de ejecución de ambas implementaciones, donde la complejidad de los datos no afecta directamente los tiempos de ninguna de las dos implementaciones.
Weather
Figura 23 Resultado Conjunto Weather, implementación Hadoop. Fuente: Elaboración propia
En la figura 23 se observa un comportamiento constante en tiempos de ejecución con pequeñas diferencias a medida que aumenta el número de nodos, haciéndose evidente que la cantidad de datos no es una variable que afecte los tiempos de ejecución en comparación con ejercicios anteriores.
Figura 24 Resultado Conjunto Weather, implementación Pgpool. Fuente: Elaboración propia
En la Figura 24 se observa un comportamiento directamente proporcional al número de tuplas que tiene cada conjunto de datos, con incrementos en a medida que se añaden nodos al clúster.
0 500 1000 1500 2000 2500 3000 3500 4000 4500
1 Nodo 2 Nodos 3 Nodos
Weather
Pgpool
Figura 25 Resultado Conjunto Weather, Hadoop vs Pgpool. Fuente: Elaboración propia
En la figura 25 se puede observar que la implementación en Pgpool logra ser más veloz con el menor número de datos, sin embargo una vez sobre pasa el tiempo de Hadoop (aproximadamente 470 segundos) se hace más lento a medida que se aumenta el conjunto de datos.
Conclusiones y Trabajo Futuro
Con base en el trabajo realizado y con los resultados obtenidos, se llegó a las siguientes conclusiones.
La solución que usa Hadoop no experimenta cambios drásticos en tiempos de ejecución a
medida que aumenta el conjunto de datos, lo anterior por la utilización de HDFS como
sistema de almacenamiento y teniendo en cuenta que incluso el conjunto más grande
utilizado como muestra no es considerado de gran tamaño en el enfoque Big Data.
El conjunto de datos no es lo suficientemente grande para ejecutar el paralelismo de manera
óptima en Hadoop, no se logró paralelismo total ni realizando las configuraciones indicadas
por el proveedor (forzando los bloques de datos de HDFS a tamaño de 16 megas y forzando
la ejecución de múltiples tareas por pequeñas que sean en todos los nodos del clúster).
Usando un conjunto de datos considerado pequeño en Big Data, no se evidencia mejora en
tiempos de ejecución a medida que aumentan los nodos del clúster.
El algoritmo C4.5 en la solución de Hadoop, ve afectados sus tiempos de ejecución
directamente por la cantidad de información que posee el conjunto de datos.
En la solución que usa Pgpool se observa un incremento en tiempos de ejecución a medida
que se incrementa el número de tuplas.
A medida que aumenta el número de nodos en Pgpool el costo de mantener los nodos
sincronizados aumenta, resultando en tiempos de ejecución más largos.
La utilización de Pgpool como software de clusterización mejora los tiempos de ejecución
de consultas. Sin embargo, mantener los diferentes nodos del clúster sincronizado es muy
costoso en tiempos de ejecución.
La utilización de Pgpool resulta útil como solución para infraestructura de persistencia. Sin
embargo, para obtener mejores resultados se requiere de un hardware más potente.
La solución que utiliza Pgpool presenta mejor rendimiento con pocas tuplas
independientemente de la información que posean los datos, pero a medida que aumenta el
La solución que usa Pgpool toma más tiempo pre procesando los datos que la solución que
usa Hadoop.
Ninguna de las dos soluciones presenta mejoras en tiempos de ejecución a medida que
aumenta el número de nodos del clúster, en medida por el conjunto de datos elegido
(tamaño vs complejidad).
Como trabajo futuro se podría adicionar valores continuos al algoritmo C4.5 para observar
los cambios en tiempos de ejecución que requiere este procesamiento adicional. Así mismo,
adicionar más nodos para evaluar un conjunto de datos mayor y variando los modelos de
Bibliografía
[1] R. Federico, «medium.com,» 2016. [En línea]. Available:
https://medium.com/@fg_rega/the-age-of-data-and-why-information-is-the-most-valuable-asset-d5d9c57620e1#.fsrye6b0n. [Último acceso: 11 junio 2016].
[2] Q. Roos, C4.5: Programs for Machine Learning, Kluwer Academic Publishers, 1993. [3] Oracle, «A Relational Database Overview (The Java™ Tutorials > JDBC(TM) Database
Access > JDBC Introduction),» 19 Agosto 2015. [En línea]. Available:
https://docs.oracle.com/javase/tutorial/jdbc/overview/database.html. [Último acceso: 14 Junio 2016].
[4] «tutorials point,» 19 Agosto 2015. [En línea]. Available: http://www.tutorialspoint.com/dbms/dbms_codds_rules.htm. [5] «Wikipedia,» 20 Agosto 2015. [En línea]. Available:
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems. [6] «mongoDB,» 15 Agosto 2015. [En línea]. Available:
https://www.mongodb.com/nosql-explained.
[7] K. Kovacs, «kkovacs,» 26 Agosto 2015. [En línea]. Available: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis.
[8] S. h. R. Shankar Ganes h Manikandan, «Big Data Analysis using Apache Hadoop». [9] S. G. Jeffrey Dean, «Google Research Publications,» Diciembre 2004. [En línea].
Available: http://research.google.com/archive/mapreduce.html. [Último acceso: 14 junio 2016].
[10] «Pgpool Wiki,» 2016 Junio 17. [En línea]. Available:
http://www.pgpool.net/mediawiki/index.php/Main_Page. [Último acceso: 1 Julio 2016]. [11] «octavian's blog,» 25 03 2011. [En línea]. Available:
https://octaviansima.wordpress.com/2011/03/25/decision-trees-c4-5/. [Último acceso: 2016 junio 16].
[12] K. Yamada, A. Ohuchi y M. Oda, «Face image retrieval method using extended C4.5,» de Systems, Man, and Cybernetics, 1997. Computational Cybernetics and Simulation., 1997 IEEE International Conference, Orlando, FL, 1997.
[13] G. Juan, L. Sen-Lin, J. Hong-bo, Z. Tie-mei y H. Yi-wen, «Type 2 diabetes data processing with EM and C4.5 algorithm,» de Complex Medical Engineering, 2007. CME 2007. IEEE/ICME International Conference, Beijing, 2007.
[14] X. Ming-Jun, K. Han y H. Liu-Sheng, «Privacy Preserving C4.5 Algorithm Over
Fifth International Conference, Hunan, 2006.
[15] G. Andrienko y N. Andrienko, «Data mining with C4.5 and interactive cartographic visualization,» de User Interfaces to Data Intensive Systems, 1999. Proceedings, Los Alamitos, CA, 1999.
[16] B. Li, B. Shen, J. Wang, Y. Chen, T. Zhang y J. Wang, «A Scenario-Based Approach to Predicting Software Defects Using Compressed C4.5 Model,» de Computer Software and Applications Conference (COMPSAC), 2014 IEEE 38th Annual, Vasteras, 2014.
[17] «Data.gov,» 2015 Septiembre 26. [En línea]. Available:
