Un sistema di Knowledge Discovery in Data (KDD) è composto da un insieme di componenti che tutte insieme possono identificare ed estrarre relazioni dai dati memorizzati nella base di dati che siano nuove, utili ed interessanti. Vediamo in questo articolo il componente Experimenter.

Experimenter: il tool di Weka per automatizzare le sperimentazioni

Un sistema di Knowledge Discovery in Data (KDD [1] [4]) è composto da un insieme di componenti che tutte insieme possono identificare ed estrarre relazioni dai dati memorizzati nella base di dati che siano nuove, utili ed interessanti.

Dato un Training set e delle classi definite dall‘utente, un sistema di Data Mining può costruire molte descrizioni. Alcune di queste sono più corrette di altre, cioè alcune di esse classificano meglio gli esempi sconosciuti. Una volta definita una misura di qualità  di una descrizione, la costruzione di una descrizione può essere espressa come un problema di ricerca:

 

trovare la migliore descrizione nell‘insieme delle descrizioni costruibili

 

Per questo scopo Weka[2][3] mette a disposizione l‘Experimenter: si tratta di una versione batch dell‘Explorer, e consente di impostare veri e propri esperimenti di Data Mining.
Ad esempio, è possibile effettuare una serie di analisi su vari insiemi di dati e con svariati algoritmi, ed eseguirle alla fine tutte insieme, facilitando un confronto tra i vari tipi di algoritmi, per determinare qual è il più adatto a risolvere uno specifico problema.

 

Distribuire il processo su più macchine

Una caratteristica notevole dell‘Experimenter di Weka è che può splittare un esperimento e distribuirlo su più processi. Questa caratteristica è fornita per gli utenti avanzati di Weka ed è disponibile scegliendo “Advanced” dal pannello Weka Experiment Environment.

 

Figura 1 – Dettaglio Experimenter

 

Alcuni utenti evitano di lavorare con questo pannello regolando l‘esperimento sulla versione semplice e commutando alla versione avanzata per distribuirla. Tuttavia, la distribuzione di un esperimento è una caratteristica avanzata ed è spesso difficile da realizzare.
La distribuzione dell‘esperimento funziona al meglio quando i risultati sono trasmessi ad una base di dati centrale: selezionando la base di dati con JDBC per definire la destinazione dei risultati dal pannello dell‘interfaccia dell‘experimenter.
Alternativamente, potreste conservare su ogni host i relativi risultati per poi fonderli in seguito.
Per distribuire un esperimento, ogni host deve avere Java installato, deve possedere i corretti grant sui dataset di riferimento e deve far girare il pacchetto weka.experiment (compreso nel workbench Weka).
Per iniziare un esperimento “a distanza” su una macchina ospite, è necessario copiare il file remoteExperimentServer.jar dalla distribuzione di Weka su una directory dell‘host.

“Spacchettare” il file con: java xvf remoteExperimentServer.jar

Si espande a due file: remoteEngine.jar, un jar eseguibile che contiene il server dell‘experimente, e remote.policy.

Il file remote.policy assegna il permesso all‘engine remoto per effettuare alcune operazioni, come il collegamento alle porte o l‘accesso alle directory.
Deve essere editato per specificare i percorsi corretti in alcuni dei permessi; ciò è evidente quando esaminate la file:

 

/* 
 * Necessary permissions for remote engines
 *
 * Example setup for user John Doe:
 * - home directory:
 *   /home/johndoe
 * - location of datasets:
 *   /home/johndoe/datasets/
 * - location of weka.jar:
 *   /home/johndoe/weka/weka.jar
 * - location of additional jars (e.g., for database access):
 *   /home/johndoe/jars
 * - remote engine directory (policy, start scripts, etc.):
 *   /home/johndoe/remote_engine
 *
 * Start Experimenter in directory /home/johndoe/remote_engine:
 *  java 
 *    -classpath /home/johndoe/jars/:/home/johndoe/weka/weka.jar 
 *    -Djava.rmi.server.codebase=file:/home/johndoe/weka/weka.jar 
 *    weka.gui.experiment.Experimenter
 *
 * Start remote engine on remote machine:
 * - cd to /home/johndoe/remote_engine
 * - start engine
 *   java -Xmx256m 
 *    -classpath remoteEngine.jar:/home/johndoe/jars/ 
 *    -Djava.security.policy=remote.policy 
 *    weka.experiment.RemoteEngine &
 *
 * Note:
 * replace  with actual jar filename, e.g., mysql.jar
 *
 * Version: $Revision: 1.1.2.1 $
 */

grant {

 // allow the remote engine to replace the context class loader.
 // This enables the unloading of types from the remote engine
 permission java.lang.RuntimePermission
  "setContextClassLoader";

 // file permission for data sets
 permission java.io.FilePermission
  "/home/johndoe/datasets/-", "read";

 // file permissions for downloading classes from client file url‘s
 permission java.io.FilePermission
  "/home/johndoe/-", "read";
 permission java.io.FilePermission
  "/home/johndoe/weka/weka.jar", "read";

 // connect to or accept connections from unprivaleged ports and the http port
 permission java.net.SocketPermission 
  "*:1024-65535", "connect,accept";
 permission java.net.SocketPermission
  "*:80", "connect";

 // file permission to load server classes from remoteEngine.jar.
 // only needed if RemoteEngine_Skel.class/_Stub.class are going to
 // be downloaded by clients (ie, if these files are not already in the
 // client‘s classpath). Normally this doesn‘t need to be changed.
 permission java.io.FilePermission
  "/home/johndoe/remote_engine/-", "read";

 // read write for properties
 permission java.util.PropertyPermission 
  "*", "read,write";

};

 

Di default, il file specifica la porta 80 su http da qualunque parte del web, può comunque essere impostato un URL specifico: è sufficiente scommentare l‘esempio ed inserire il path appropriato. I remote engines per funzionare correttamente hanno la necessità  di accedere al dataset usato nell‘esperimento (prima riga del file remote.policy).

I percorsi ai dataset sono specificati nell‘experimenter (cioè, il client) e gli stessi percorsi devono essere applicabili nel contesto dei remote engines.

L‘Experimenter mette a disposizione una comoda interfaccia grafica per facilitare l‘inserimento dei path relativi: è sufficiente selezionare la casella “Use relative paths” indicata nel pannello di setup dell‘experimenter.

 

Figura 2 – Dettaglio Experimenter

 

Per avviare il server del remote engine, scrivere:

java ?classpath remoteEngine.jar: 
-Djava.security.policy=remote.policy weka.experiment.RemoteEngine

 

dalla directory che contiene remoteEngine.jar.
Se tutto va bene comparirà  questo messaggio (o qualcosa di simile):

 

Host name : biancalana@dia.uniroma3.it
RemoteEngine exception: Connection refused tohost:
ml.cs.waikato.ac.nz; nested exception is:
java.net.ConnectException: Connection refused
Attempting to start rmi registry...
RemoteEngine bound in RMI registry

 

Malgrado le apparenze iniziali, questa è una buona notizia! Il collegamento è stato rifiutato perché nessun RMI registry stava funzionando su quel server e quindi il remote engine ne ha iniziato uno. Ripetere il processo su tutti gli host tenendo conto che non ha senso avviare più di un remote engine sullo stessa macchina! Avviare l‘experimenter scrivendo:

 

java -Djava.rmi.server.codebase=
weka.gui.experiment.Experimenter

 

L‘URL specifica dove i remote engine possono trovare il codice da poter eseguire, se l‘URL denota una directory anzichà© un file jar, deve terminare con il separatore di path (ad esempio “/”).
Il pannello avanzato di setup dell‘experimenter contiene un piccolo riquadro che determina se un esperimento deve essere distribuito oppure no, normalmente disabilitato.

 

Figura 3 – Dettaglio Experimenter

 

Per distribuire l‘esperimento cliccare sul check-box nominato “hosts”: comparirà  una finestra popup per inserire le macchine sulle quali distribuire l‘esperimento, i nomi degli host devono essere fully qualified (per esempio, biancalana.dia.uniroma3.it).
Una volta inseriti gli host è sufficiente utilizzare l‘Explorer nel modo usuale.
Quando l‘esperimento è avviato usando il pannello principale dell‘explorer, viene visualizzato il progresso dei sotto-esperimenti sui vari host, con i relativi messaggi di warning.
Il task della distribuzione dell‘esperimento gestisce la suddivisione in sotto-esperimenti che RMI trasmette agli host.
Gli esperimenti sono gestiti attraverso lo split del dataset: ovviamente non possono essere più ospiti che dataset. Ogni  sotto-esperimento è autonomo: l‘experimenter applica tutti gli schemi precalcolati ad un singolo dataset.

 

Figura 4 – Dettaglio Experimenter

 

Conclusioni

In questo ultimo  articolo della serie abbiamo analizzato come realizzare un sistema per distribuire il processo di Knowledge Discovery in Data (KDD) su più calcolatori. Abbiamo apprezzato l‘eleganza e la notevole flessibilità  del framework Weka per effettuare un calcolo distribuito al fine di ricercare l‘algoritmo (e il relativo tuning) ottimale per i dati forniti.

 

Riferimenti

[1] I. Witten & E. Frank, “Data Mining: Practical Machine Learning Tools and Techniques with Java Implementation”, Morgan Kauffman 2005

 

[2] Weka Home Site
http://www.cs.waikato.ac.nz/ml/weka/

 

[3] Weka Sourceforge Site
http://sourceforge.net/projects/weka/

 

[4] Paolo Giudici, “Data Mining, Metodi informatici, statistici e applicazioni”, McGraw-Hill 2005.