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.
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.
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.
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.