More Related Content
Similar to Tesi4
Similar to Tesi4 (20)
Recently uploaded
Recently uploaded (10)
Tesi4
- 1. Progetto e sviluppo di un Search Component, nella piattaforma Apache Solr, per la classicazione semantica dei documenti Relatore interno: Laureando: Prof. Serafino Cicerone Enrico Santoro Relatore esterno: Ing. Paolo Cappuccini Università degli Studi dell’Aquila Dipartimento di Ingegneria e Scienze dell'Informazione e Matematica Tesi di Laurea Magistrale in Ingegneria Informatica e Automatica Anno Accademico 2013-2014
- 2. Azienda committente: KDM • Ha sede a Roma • Opera nel settore dell‘ICT • Offre soluzioni e servizi ▫ Knowledge Management ▫ Gestione documentale ▫ Soluzioni gestionali aziendali ▫ … • Dal 2014 ha avviato progetti con l’Università dell’Aquila 2
- 3. Il progetto assegnato • Sviluppo e implementazione di tecniche ed ontologie per Ricerche Enterprise • Svolto in team: 1. Sviluppo del componente di ricerca in Solr 2. Implementazione di un editor di Thesaurus 3
- 4. Indice • Apache Solr • Architettura di Solr • Principali funzionalità • Inverted index • Hierarchy Component • Algoritmo • Sviluppo in Solr • Test 4
- 5. Apache Solr 5 • Applicazione Web • Motore di ricerca full text • Basato su Apache Lucene ▫ Libreria Java di indicizzazione e ricerca • Open source • REST API • Client API
- 7. Panoramica delle funzionalità (1) • Pagination • Faceting • Autosuggest • Hit highlighting • Geospatial Search 7
- 8. Panoramica delle funzionalità (2) • Result grouping • Flexing query support • Importing rich document (Word, Pdf) • Database integration • Multilingual support 8
- 9. Inverted index (1) 9 Nessun risultato
- 13. Inverted index (5) 13 new AND home new OR home “new home”
- 14. Chi usa Solr? 14
- 15. Hierarchy Component • Clusterizzazione gerarchica dei documenti • Input: ▫ N documenti ▫ Thesaurus • Output: ▫ I documenti (N) raggruppati in cluster ▫ Cluster collegati semanticamente • Vincolo di linearità 15
- 18. Implementazione in Solr • Hierarchy Component = Search Component 1. Aggiunta del componente alla configurazione ▫ solrconfig.xml 2. Creazione di un nuovo request handler ▫ /search 3. Implementazione di Hierarchy Component ▫ Classe Java: HierarchyComponent.java ▫ Librerie di Solr, API Solrj 18
- 20. Hierachy in Velocity (1) 20
- 21. Hierachy in Velocity (2) 21 scienze sociali
- 22. Hierachy in Velocity (3) 22 scienze sociali -> scienze economiche
- 23. Test sulle performance (1) 23
- 24. Test sulle performance (2) 24
- 25. Conclusioni • Studio approfondito di Apache Solr • Componente di clusterizzazione gerarchica ▫ Hierarchy Component in Solr • Vincolo di linearità • Sviluppi futuri: ▫ Relazioni trasversali ▫ Relazioni di sinonimia 25
Editor's Notes
- Buongiorno a tutti, sono Enrico Santoro e sto per presentarvi il mio lavoro di tesi riguardante lo sviluppo di un componente di ricerca all’interno della piattaforma Apache Solr.
- Questo lavoro di tesi è stato svolto in azienda; l’azienda in questione è la KDM la quale ha sede a Roma ed opera nel settore dell’Information and Communication Technology. Essa offre diverse soluzioni e servizi ai propri clienti, nell’ambito del Knowledge Management, della gestione documentale come la dematerializzazione dei processi e dei procedimenti, soluzioni gestionali per le aziende e altro ancora. Dall’anno corrente la KDM ha intrapreso una collaborazione con la nostra facoltà, proponendo diversi progetti agli studenti.
- Ed è proprio in uno di questi progetti che si colloca il mio lavoro di tesi. Il progetto in questione riguarda lo sviluppo di una tecnica di ricerca basata sull’utilizzo di ontologie, e l’implementazione di uno strumento per la gestione delle ontologie stesse. Questo progetto è stato assegnato ad un team di due persone; io mi sono occupato dello sviluppo vero e proprio del componente di ricerca, mentre il mio collega Antonio Delli Carpini si è occupato della gestione dei Thesaurus utilizzati dal componente di ricerca stesso; e dei quali ce ne parlerà succesivamente.
- Dunque nel corso di questa presentazione vi parlerò prima di tutto di Apache Solr, poichè il grosso del lavoro è riguardato proprio lo studio di questa potente piattaforma di ricerca. Vi mostrerò quella che è la suaarchitettura base, le sue principali funzionalità e peculiarità; successivamente vedremo quello che è il suo principale punto di forza e ciò l’utilizzo di un indice inverso nelle operazioni di ricerca. Poi passerò ad illustrarvi il componente di ricerca sviluppato chiamato Hierarchy Component, mostrandovi l’algoritmo di funzionamento, come è stato sviluppato in Solr ed infine vedremo un esempio d’uso ed alcuni test sulle performance.
- Solr è una piattaforma di ricerca fornita come applicazione web, che rappresenta un motore di ricerca full text basato su una libreria scritta interamente in Java per l’indicizzazione e la ricerca di documenti, chiamata Apache Lucene. Quindi Lucene è una libreria di ricerca, mentre Solr è un applicazione web che utilizza la libreria Lucene. Caratteristica fondamentale è che tale piattaforma è open source. Inoltre essendo scritta interamente in Java, Solr ha il vantaggio di essere utilizzabile su qualsiasi sistema operativo. In figura vediamo un semplice utilizzo di Solr, dove un’altra web app interroga l’indice di Lucene e Solr fornisce una risposta. Ovviamente sull’indice vengono effettuate anche operazioni di aggiornamento e indicizzazione dei documenti. Solr fornisce inoltre delle rest api per richiede I propri servizi attraverso il protocollo http e restituendo la risposta in JSON o XML. Spesso gli sviluppatori preferiscono però accedere al servizio di Solr mediante delle librerie Client. A questo scopo Solr è fornito di molte librerie Client in vari linguaggi. Ad esempio per il Java sono disponibili le API Solrj che sono state utilizzate nello sviluppo di questo lavoro.
- Esploriamo meglio quella che è l’architettura di Solr… Solr può essere implementato in un qualsiasi servlet container, come ad esempio Tomcat o Jetty. Quando si effettua il download di Solr esso è preconfigurato all’utilizzo con Jetty. Solr supporta l'esecuzione di piu core, e quindi di piu indici, nello stesso ambiente Java, garantendo dunque una elevata flessibilità di utilizzo. Su ogni core possono essere effettuate operazioni di querying e updating sull’indice. Per ogni indice sono presenti due file di configurazione molto importanti che sono lo schema.xml e solrconfig.xml. Lo schema contiene tutti I dettagli riguardanti la struttura dei documenti (I campi che contengono e I loro tipi) e viene utilizzato sia durante l’indicizzazione degli stessi che durante la fase di interrogazione. Invece il file solrconfig.xml contiene I la maggior parte dei parametri per configurare Solr stesso.
- Per quanto riguarda le principali funzionalità di Solr, esse innanzitutto sono percepite in due differenti categorie: quelle riguardanti la User Experience, e quelle inerenti al data modeling. Per quanto concerne la user experience, Solr è dotato di importanti funzionalità che consentono di fornire una soluzione di ricerca che facile da utilizzare, intuitiva e performante. Tra i principali componenti di questa categoria troviamo: - pagination: utile per servire il risultato delle richieste distribuito su diverse pagine; - faceting: fornisce agli utenti gli strumenti per affinare i criteri di ricerca e scoprire ulteriori informazioni categorizzando i risultati della ricerca in sottogruppi mediante l’utilizzo delle faccette; autosuggest: permette agli utenti di vedere una lista di termini e frasi suggerite sulla base di documenti presenti nell'indice; Spell-checker: offre supporto alla correzione ortografica ed è sempre più utile nell'era dei dispositivi mobili e persone in movimento; Hit highlighting: molto utile durante la ricerca di documenti che hanno una notevole quantità di testo, opichè è possibile andare ad evidenziare sezioni specifiche di ogni documento per migliorare la leggibilità; - Geospatial Search: Solr è dotato del supporto per l'indicizzazione dei valori di longitudine e latitudine e restituisce i documenti per distanza geografica
- Per quanto riguarda invece le funzionalita di data-modeling abbiamo: - Result grouping: Solr consente di trattare piu documenti come un gruppo sulla base di alcune proprieta comuni condivise da tutti i documenti del gruppo; il classico esempio è quello delle email dove tutte le mail di risposta ad un messaggio originale possono essere raggruppate. Flexing query support: Solr offre una serie di funzionalita per le interrogazioni tra cui i classici operatori logici AND, OR e NOT; intervalli per date e numeri, utilizzare una logica fuzzy, espressioni regolari e altro ancora… Document clustering: permette di identificare gruppi di documenti che sono simili sulla base di alcune condizioni presenti in ciascun documento; - Importing rich document: Solr si integra con il progetto Apache Tika che supporta i formati di documento piu diffusi; Database integration: permette di integrare dati presenti in un database relazionale; Multilingual support: ovviamente Solr supporta tantissime lingue ed offre un rilevatore di lingua integrato
- Una importante caratteristica di Solr è data dall’utilizzo del cosiddetto indice inverso. Come detto precedentemente Solr fa uso della libreria di ricerca Apache Lucene; e questa libreria fa proprio uso di questa tecnica. Quindi Solr indirettamente fa uso di questa tecnica di ricerca. Vediamola attraverso un esempio, nel quale consideriamo dapprima l’utilizzo di database relazionali per capirne meglio le differenze: supponiamo di avere una lista di titoli di alcuni libri; e vogliamo effettuare una ricerca per trovare libri che riguardano l’acquisto di nuove case. Effettuando una query in questo modo non otteremo alcun risultato poichè nessun libro ha come titolo “buying a new home”.
- Quello che si può pensare di fare allora è di andare a ricercare le singole parole all’interno del testo; in questo caso ad esempio vogliamo che tutte e tre le parole siano presenti nel titolo del libro. In questo modo otterremo un unico risultato e verrano scartati molti libri che invece sono rilevanti.
- Allo stesso modo possiamo invece volere che almeno una delle tre parole sia presente nel titolo del libro. In questo caso otteniamo molti più risultati, alcuni dei quali però risultano essere irrilevanti ai fini della ricerca. Questo perché basta che sia presente la lettera “a” all’interno di un titolo ed esso verrà restituito. Dunque questa è una principale problematica che riguarda le basi di dati relazionali; inoltre c’è da dire che queste tipologie di query diventeranno sempre più lente man mano che la dimensione del catalogo dei libri crescerà, perche la query deve eseguire la scansione attraverso il titolo di ogni libro per trovare delle corrispondenze parziali invece.
- L'indice inverso va ad invertire questo modello effettuando l’analisi del testo e mappando ogni parola su tutti i documenti in cui essa appare. L’analisi del testo può essere fatta in diversi modi, utilizzando particolari tokenizzazioni e filtri: ad esempio qui è stata effettuata una whitespace tokenization, cioè per ogni spazio bianco viene individuato un termine, e successivamente un filtro per portare I termini tutti in lowercase.
- Quindi se supponiamo di voler interrogare l’indice alla ricerca dei termini “new” e “home”, una volta che l'elenco dei documenti corrispondenti ad ogni termini è stato trovato, Lucene eseguirà le operazioni di set per arrivare ad un adeguato set di risultati finale che corrisponde alla query. A questo punto è necessario specificare come vogliamo interrogare l'indice: - Ricerca di due differenti termini, “new"e “home", richiedendo il match di entrambi, attraverso l’operatore AND; ed in questo caso otteniamo l’intersezione tra I due insiemi. Ricerca di due differenti termini, “new"e “home", richiedendo il match di un solo termine, attraverso l’operatore OR; ed in questo caso otteniamo l’unione tra I due insiemi. - Ricerca della frase esatta “new home“; in questo caso ogni termine della frase viene ancora ricercato nell'indice individualmente, viene eseguita poi l’operazione di AND poichè entrambi I termini devono essere presenti nella frase, ed infine si fa uso di una caratteristica facoltativa chiamata term position, che ci dice la posizione relativa dei termini all'interno del documento.
- Grazie all’utilizzo dell’indice inverso di Lucene, Solr risulta essere altamente performante nelle operazioni di ricerca, e proprio per questo motivo esso è utilizzato in tantissimi siti web di caratura mondiale; come ad esempio… Questo per far capire proprio quelle che sono le potenzialità di questo strumento.
- Una volta studiata a fondo la piattaforma di ricerca, ed abbiamo visto molte delle sue funzionalità e dei suoi punti di forza, si è passati allo sviluppo del componente di ricerca commissionato dall’azienda KDM, chiamato Hierarchy Component. Innanzitutto qual’è lo scopo di questo componente? Esso deve produrre una clusterizzazione gerarchica dei documenti a seguito di una ricerca effettuata dal’utente. Cioè dati in input un certo numero di documenti indicizzati in Solr e ottenuti da una ricerca effettuata dall’utente, e un Thesaurus (che rappresenta un insieme di termini strutturati e collegati semanticamente e della cui gestione, organizzazione e indicizzazione ce ne parlerà dopo il mio collega), quello che questo componente deve produrre in output, è l’insieme dei documenti raggruppati in cluster, ogni cluster rappresenta un certo dominio semantico e in esso saranno presenti tutti I documenti di quel dominio, ed ogni cluster prodotto che venga successivamente gerarchizzato; cioè che vengano fatti dei collegamenti tra I vari cluster in modo da creare una gerarchia tra loro. Chi è che ci fornisce questa gerarchia? Il Thesaurus in uso.
- A questo punto una domanda sorge spontanea. Una piattaforma di ricerca efficace come Solr e piena di funzionalità, non ha questo componente già sviluppato? Ebbene nel suo pacchetto di funzionalita fornisce la possibilita di raggruppare dei documenti correlati mediante un componente di Clustering (di cui vi ho già accenato precedentemente); ma per quanto riguarda la clusterizzazione gerarchica non è fornito alcun algoritmo. Per precisare Solr fa uso di una piattaforma open source di nome Carrot la quale implementa 3 diversi algoritmi: abbiamo Lingo e STC che sono gratuiti ma non forniscono hierarchical clustering; poi c’è il Lingo 3G che fornisce questa funzionalità ma è a pagamento; se si acquista questo algoritmo è possibile integrarlo in Solr, ma ovviamente essendo open source non è presente nel pacchetto base. Dunque utilizzando l’algortimo di clustering di default presente in solr, e cioè Lingo, il primo step della creazione dei cluster risulta già effettuato. Ciò che manca è di andare a effettuare la gerarchizzazione di questi cluster.
- Vediamo intuitivamente come è stato realizzato ciò attraverso l’utilizzo dei thesaurus. L’algoritmo sviluppato si basa su diversi step: Al primo step si effettua una ricerca sul corpus dei documenti utilizzando il componente di clustering. L'algoritmo di clustering, cioè Lingo, fornira in output una lista di cluster che chiamiamo Lc; ogni cluster appartenente a tale lista risulterà etichettato mediante una label dall'algoritmo di clustering e conterrà un certo numero di documenti (tra quelli restituiti in output dalla ricerca effettuata). Le label rappresentative dei cluster vengono successivamente sottoposte ad un processo di stemming (riduzione della forma flessa di una parola alla sua forma radice). In tale fase inoltre la lista Lt verrà generata in maniera ordinata alfabeticamente. Si ricercano i termini presenti nella lista Lt all'interno del thesaurus indicizzato e i termini trovati costituiranno la lista Lo come output della ricerca. Tale lista sarà ordinata alfabeticamente. Ovviamente può accadere che non tutti i termini vengano trovati all'interno dell'ontologia, e in tal caso la cardinalità di Lo sarà minore di quella di Lt. Cosa importante è che il thesaurus è presente su un indice di Solr differente da quello contenente il corpus documentale; questo per mantenere separati i due insiemi di documenti: il primo costituito da documenti che sono oggetto della ricerca e il secondo costituito da documenti che rappresentano il thesaurus in uso. A questo punto si effettua un confronto tra le due liste ordinate Lt ed Lo. Tale confronto permetterà dunque di conoscere quali termini sono stati trovati nel thesaurus e quali invece non sono stati trovati. E' fondamentale che le due liste siano ordinate alfabeticamente per fare in modo che la complessità computazionale del confronto sia lineare ( O(n) ). Una volta effettuato il confronto sarà possibile associare ad ogni termine della lista risultante, la lista di documenti associati ad ogni cluster. In questo modo si legano i documenti ottenuti dalla ricerca, ai termini presenti nel Thesaurus. Poiché ogni termine presente nel Thesaurus ha una propria gerarchia (come ci verrà mostrato successivamente), i documenti risulteranno posizionati direttamente in essa. Ovviamente i termini che non sono stati trovati nel thesaurus non apparterranno a nessuna gerarchia, e quindi risulteranno semplicemente raggruppati in cluster ma non gerarchizzati. Attraverso questi step dunque si ottiene la clusterizzazione gerarchia.
- Adesso vediamo invece come tale algoritmo è stato sviluppato in Solr. Solr offre un semplice meccanismo di implementazione di nuovi componenti, chiamati Search Component. Il compito di un Search Component è quello di aggiungere informazione alla risposta di Solr quando si effettua una ricerca: nel nostro caso l'informazione aggiunta riguarda proprio la clusterizzazione gerarchica. Per creare un nuovo search component bisogna prima di tutto informare Solr del nuovo componente andandolo ad aggiungere al file di configurazione solrconfig.xml. Successivamente bisogna creare un nuovo request handler che si occuperà di richiamare il nostro componente. Cioè quando facciamo una richiesta a Solr e vogliamo che venga utilizzato il nostro componente, allora tale richiesta bisogna farla ad un determinato request handler: il quale è stato chiamato search, ed è raggiungibile mediante richiesta http. Infine bisogna scrivere il comportamento di questo componente, cioè tutti I passi dell’algortimo che abbiamo visto precedentemente, e ciò è stato fatto creando una classe Java la quale al suo interno fa uso delle librerie di Solr ed anche delle API SolrJ per effettuare richieste da client a Solr; ad esempio poichè dobbiamo interrogare l’indice in cui è presente il Thesaurus.
- Una volta che il componente è stato sviluppato, si è andati ad integrarlo all’interno di una semplice interfaccia utente di ricerca fornita da Solr, che è chiamata Velocity o anche Soliritas; essa manifesta diverse utili caratteristiche come la ricerca, il faceting, l'autocompletamento, highlighting e la ricerca spaziale. Se attivo, è possibile visualizzare anche il clustering in azione.
- Dunque si è andati ad inserire il nostro componente di ricerca Hierarchy all’interno di questa interfaccia utente per rendere navigabile l’albero dei risultati restituito dal componente stesso. Nell’esempio mostrato è stata eseguita una ricerca libera su Solr, cioè senza parametri, ed è possibile notare che delle 11 etichette mostrate nella sezione Hierarchy, 10 sono relative a label di cluster che hanno trovato una corrispondenza nel Thesaurus, mentre l'etichetta Non Match contiene tutte le label che non sono state trovate. Per navigare l’albero basta dunque cliccare su una qualsiasi delle etichette, se ad esempio cliccliamo su “scienze sociali”…
- vedremo solamente il suo contenuto. In questo caso è presente una ulteriore etichetta “scienze economiche”. Cliccando su questa nuova etichetta scendiamo ancora di livello.
- In questo esempio sotto scienze economiche sono presenti direttamente I documenti. Questo vuol dire che scienze economiche è la label di un cluster generato da Lingo, e che è stata trovata all’interno del Thesaurus. Tale termine nel thesaurus risulta figlio del termine scienze sociali. E da qui nasce appunto la gerarchizzazione dei cluster.
- Olte a garantire il corretto funzionamento del componente, un altro aspetto importante riguarda il tempo di esecuzione poichè quando si parla di ricerca I tempi di risposta del sistema sono fondamentali affinchè l’utente risulti soddisfatto. Sono stati eseguiti dunque dei test sul componente effettuando una serie di query. In questo primo grafico abbiamo sull’asse delle X il numero di documenti restituiti dalla query; ed è dunque facile notare come all’aumentare dei documenti il numero di cluster prodotti sale, e a sua volta aumenta anche il numero di cluster trovati all’interno del Thesaurus (il test è stato fatto con un Thesaurus fisso). E questo conferma era ciò che ci si attendeva e in un certo senso conferma il corretto funzionamento.
- Ma quello che ci interessa maggiormente è il tempo di esecuzione di queste query di ricerca. Osserviamo che all’aumentare dei documenti, e dunque dei cluster prodotti, il tempo di esecuzione sale. La cosa importante è che questa crescita sia lineare. E osservando dalla figura….
- In conclusione, è stato fatto uno studio approfondito della piattaforma di ricerca Apache Solr e si sono messe in mostra quelle che sono le sue principali caratteristiche, abbiamo visto come è stato realizzato il componente di clusterizzazione gerarchica in Solr commissionato dall’azienda KDM; ed infine abbiamo visto come il vincolo di linearità di tale componente sia stato rispettato. In futuro sono già stati programati alcuni step per affinare il comportamento di Hierarchy Component: considerando non sono relazioni gerarchiche padre figlio tra gli elementi di un Thesaurus ma anche relazioni trasversali che trasformeranno la struttura da albero a grafo; ed infine includendo anche relazioni di sinonimia tra diversi termini in maniera tale che il componente automaticamente raggruppi risultati che fanno parte di cluster sinonimi tra loro.