Εξετάζοντας δηµόσια δεδοµένα µε τη βοήθεια του Elastic Search

(1)

ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ

ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ

ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ

ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ

Εξετάζοντας δηµόσια δεδοµένα µε τη βοήθεια του Elastic Search

Δηµήτριος Π. Σπυρόπουλος

Επιβλέπων: Αλέξης Δελής,Καθηγητής

ΑΘΗΝΑ ΑΥΓΟΥΣΤΟΣ 2017

(2)

Εξετάζοντας δηµόσια δεδοµένα µε τη βοήθεια του Elastic Search

Δηµήτριος Π. Σπυρόπουλος Α.Μ. : 1115201200170

Επιβλέπων: Αλέξης Δελής, Καθηγητής

(3)

ΠΕΡΙΛΗΨΗ

Η επιστήµη των δεδοµένων είναι ο κλάδος της πληροφορικής που έχει σηµειώσει τα µεγαλύτερα άλµατα την τελευταία δεκαετία. Μπορεί να βρει εφαρµογή σε ποικίλους τοµείς και επιστήµες όπως οι επιχειρήσεις, η βιολογία ,η αστροφυσική κ.α. Η παρούσα εργασία έχει σα σκοπό να εξετάσει δηµόσια δεδοµένα από τον κυβερνητικό ιστοχώρο Διαύγεια µε την βοήθεια της βάσης δεδοµένων Elastic Search.

Το πρόγραµµα Διαύγεια ξεκίνησε την λειτουργία του τον Οκτώβριο του 2010 στον ιστοχώρο diavgeia.gov.gr και στοχεύει στην µέγιστη δυνατή δηµοσιοποίηση του έργου της κυβέρνησης και της τοπικής αυτοδιοίκησης. To Elastic search είναι µια µηχανή αναζήτησης πραγµατικού χρόνου που χτίστηκε πάνω στην open-source πλατφόρµα ανάκτησης πληροφορίας Lucene. Η παρούσα εργασία µελετά τις αποφάσεις εγκρίσεων δαπανών του Εθνικού και Καποδιστριακού Πανεπιστηµίου Αθηνών κατά την περίοδο Ιανουάριος-Ιούνιος 2017 και µέσω της πλατφόρµας Elastic εξάγει και οπτικοποιεί αποτελέσµατα αναφορικά µε την κίνηση των οικονοµικών λογαριασµών του ΕΚΠΑ, τα άτοµα που υπέγραψαν τις αποφάσεις καθώς και τα ερευνητικά προγράµµατα που έλαβαν την µεγαλύτερη χρηµατοδότηση.

Τα κύρια βήµατα που ακολουθήθηκαν για την ανάπτυξη της εφαρµογής είναι τα κάτωθι:

-

Ανάκτηση των αποφάσεων από τον ιστοχώρο Διαύγεια.

-

Εφαρµογή προγραµµάτων καθαρισµού και εξαγωγής γνώσης από τα δεδοµένα που αντλήθηκαν.

-

Εισαγωγή των δεδοµένων στην βάση και διενέργεια των ερωτηµάτων.

-

Οπτικοποίηση των αποτελεσµάτων.

Τα αποτελέσµατα όπως αυτά απεικονίζονται από τα διαγράµµατα είναι άκρως ενδιαφέροντα. Τα περισσότερα χρήµατα αφαιρέθηκαν από τον “ειδικό λογαριασµό κονδυλίων και έρευνας του ΕΚΠΑ”. Οι περισσότερες αποφάσεις υπογράφηκαν από τον τρέχοντα αντιπρόεδρο της επιτροπής ερευνών και το ερευνητικό έργο που έλαβε την µεγαλύτερη χρηµατοδότηση του εξαµήνου ήταν αυτό µε κωδικό 9994.

ΘΕΜΑΤΙΚΗ ΠΕΡΙΟΧΗ: Συστήµατα Βάσεων Δεδοµένων

ΛΕΞΕΙΣ ΚΛΕΙΔΙΑ: crawling, elasticSearch, kibana, Διαύγεια, pdf parsing

(4)

Data science is the section of informatics that has made the most progress in the last decade. It has applications to a variety of sciences like management, biology, astrophysics etc. The basic purpose of my thesis is to examine public data from the greek governmental website Diavgeia with the help of Elastic Search.

Diavgeia went online(www.diavgeia.gov.gr ) on October 2010 and its aim is to publish decisions of the government and the municipalities. Elastic Search is a real-time search- engine based on the open-source platform Lucene. My thesis deals with decisions of expenditure of the National and Kapodistrian University of Athens(NKUA) during the first semester of 2017 (January to June). Through Elastic Platform it extracts and visualizes results regarding the university’s accounts, the signers and the research projects that received the highest financing.

The basics steps followed during the implementation are:

-

Download of decisions from website Diavgeia.

-

Data cleaning and knowledge extraction.

-

Data import to Elastic Database and queries.

-

Query visualization.

The results, as seen on the visualizations are very interesting. Most money was spent from the “special account for research of NKUA”. The majority of decisions was signed by the current vice-chairman of the reasearch committee and the research project which received the most money during the last six months was the one with code 9994.

SUBJECT AREA: Database Systems

KEYWORDS: crawling, elasticSearch, kibana, Diavgeia, pdf-parsing

(5)

ΠΕΡΙΕΧΟΜΕΝΑ

ΠΡΟΛΟΓΟΣ 1

1. ΕΙΣΑΓΩΓΗ 8

2.CRAWLING 9

2.1 Σχετική δουλειά πάνω σε crawling της Διαύγειας 10 2.2 Λίγα λόγια για το Scrapy Framework της Python 11 2.3 Ο crawler που αναπτύχθηκε για τις ανάγκες της εφαρµογής 12

3. ΕΠΕΞΕΡΓΑΣΙΑ ΔΕΔΟΜΕΝΩΝ 14

3.1 Μετατροπή και επεξεργασία εγγράφων αποφάσεων 14

3.2 Υπολογισµός ολικού ποσού 16

3.3 Συνένωση αρχείων και προετοιµασία για εισαγωγή 16

4. ΕΡΩΤΗΜΑΤΑ ΣΤΗ ΒΑΣΗ ELASTIC SEARCH 18

4.1 Σύντοµη περιγραφή Elastic Search 18

4.2 Εισαγωγή δεδοµένων 19

4.3 Λίγα λόγια για το Search_API 20

4.4 Ερωτήµατα 20

5. ΟΠΤΙΚΟΠΟΙΗΣΕΙΣ 23

5.1 Διαγράµµατα αποτελεσµάτων 23

6. ΣΥΜΠΕΡΑΣΜΑΤΑ 26

ΠΙΝΑΚΑΣ ΟΡΟΛΟΓΙΑΣ 27

ΣΥΝΤΜΗΣΕΙΣ-ΑΡΚΤΙΚΟΛΕΞΑ-ΑΚΡΩΝΥΜΙΑ 28

ΑΝΑΦΟΡΕΣ 29

(6)

Εικόνα 1: Τυπική Δοµή ενός Web Crawler………9

Εικόνα 2: Αρχιτεκτονική και ροή πληροφορίας σκελετού Scrapy……… 11

Εικόνα 3: Αντικείµενο απόφασης Διαύγειας………12

Εικόνα 4: Στάδια επεξεργασίας και εξόρυξης πληροφορίας……… 14

Εικόνα 5: Χρήση jq ………16

Εικόνα 6: Αρχιτεκτονική Elastic Search……… 18

Εικόνα 7: Πρώτο Ερώτηµα……… 21

Εικόνα 8: Δεύτερο Ερώτηµα……… 21

Εικόνα 9: Τρίτο Ερώτηµα……… 22

Εικόνα 10: Pie-Char λογαριασµών ΕΚΠΑ……… 24

Εικόνα 11: Bar-Chart Top3 υπογραφόντων ΕΚΠΑ……… 24

Εικόνα 12: Bar-Chart Top10 Ερευνητικών έργων……… 25

(7)

ΠΡΟΛΟΓΟΣ

Η εργασία αυτή διεξάγει µια λεπτοµερή έρευνα πάνω στις αποφάσεις εγκρίσεως δαπανών του ΕΚΠΑ του τελευταίου εξαµήνου όπως αυτές δηµοσιεύονται στον ιστοχώρο diavgeia.gov.gr.

Πιο συγκεκριµένα, διενεργείται ως πτυχιακή εργασία στο Εθνικό και Καποδιστριακό Πανεπιστήµιο Αθηνών στο τµήµα Πληροφορικής και Τηλεπικοινωνιών της σχολής των Θετικών Επιστηµών. Τον ρόλο του επιβλέπων καθηγητή ανέλαβε ο καθηγητής του τµήµατος Αλέξης Δελής τον οποίο και ευχαριστώ προσωπικά για την πολύτιµη συµβολή που προσέφερε στην διεκπεραίωση του παρόντος έργου.

(8)

1. ΕΙΣΑΓΩΓΗ

Η διαφθορά στην Ελλάδα είναι ένα σύγχρονο πρόβληµα πολιτικών διαστάσεων. Η κακοδιοίκηση και η ευνοιοκρατία αποτελούν τροχοπέδη για την οικονοµική ανάπτυξη της χώρας µας. Η καταπολέµηση των παραπάνω θα αποτελέσει τις γερές βάσεις για την επιστροφή στην ανάπτυξη και την ευηµερία. Η ανάγκη για δηµόσια διαφάνεια είναι λοιπόν κάτι παραπάνω από επιβεβληµένη στην Ελλάδα του σήµερα.

Ήδη η ελληνική κυβέρνηση από το 2010, έχει δηµιουργήσει το πρόγραµµα Διαύγεια για την ελεύθερη πρόσβαση και έλεγχο του έργου, αυτής και της τοπικής αυτοδιοίκησης, από τον πολίτη. Η παρούσα εργασία αποσκοπεί να εξετάσει λεπτοµερώς αποφάσεις που αφορούν σε εγκρίσεις δαπανών του ΕΚΠΑ.

Αρχικά, χρησιµοποιώντας προγράµµατα άντλησης πληροφοριών από το Διαδίκτυο (2) λαµβάνει τις πανεπιστηµιακές αποφάσεις και τις επεξεργάζεται (3). Έπειτα χρησιµοποιώντας την µη-σχεσιακή βάση δεδοµένων elastic search εκτελεί 3 ερωτήµατα (4) και τελικώς χρησιµοποιώντας το λογισµικό Kibana της ίδιας εταιρείας οπτικοποιεί τα αποτελέσµατα (5).

(9)

2.CRAWLING

Η άντληση των αποφάσεων από τον ιστοχώρο του Διαύγεια έγινε µε την µέθοδο του web crawling/scraping. Ένας web crawler, ή αράχνη όπως συχνά καλείται, είναι ένα πρόγραµµα το οποίο παίρνει σαν όρισµα κάποια αρχικά URL τα οποία και επισκέπτεται αντλώντας την πληροφορία που του έχει ζητηθεί και στην συνέχεια πηγαίνει στις επόµενες σελίδες των ιστοχώρων όπως αυτές υποδηλώνονται από τους υπερσυνδέσµους.

Στην παραπάνω εικόνα φαίνεται λεπτοµερώς η αρχιτεκτονική της πλειοψηφίας των crawlers του Διαδικτύου. Αρχικά ο crawler επισκέπτεται τις ιστοσελίδες που του δόθηκαν σαν όρισµα. Κάθε µια από αυτές τοποθετείται σε µια ουρά. Κάθε στοιχείο αυτής της ουράς, µέσω του εσωτερικού προγραµµατιστή ωθείται στον downloader του crawler ο οποίος φέρει εις πέρας το έργο της µεταφοράς της πληροφορίας από το Διαδίκτυο στον τοπικό υπολογιστή. Η διαδικασία αυτή επαναλαµβάνεται µέχρις ότου τελειώσουν τα URL’s της ουράς, όπως αυτά ορίζεται από την εκάστοτε πολιτική επιλογής του crawler

Δ. Σπυρόπουλος P9

Εικόνα 1: Τυπική Δοµή ενός Web Crawler

(10)

2.1 Σχετική δουλειά πάνω σε crawling της Διαύγειας

Έπειτα από σχετική έρευνα στο Διαδίκτυο βρέθηκε ότι ένας web crawler για το diavgeia.gov.gr είχε ήδη αναπτυχθεί από το 2015. Το όνοµα αυτού που το προγραµµάτισε είναι Ζαχαρίας Τζερµιάς [2]. Ο συγκεκριµένος crawler είναι γραµµένος πάνω σε έναν σκελετό(framework) της γλώσσας προγραµµατισµού Python και σαν κύριο έργο είχε να κατεβάζει τα πληροφοριακά δεδοµένα(metadata) καθώς και τα έγγραφα (σε µορφή PDF) των αποφάσεων από τον ιστοχώρο Διαύγεια.

Πιο συγκεκριµένα, ήταν µια γενική αράχνη η οποία χρησιµοποιώντας σαν αρχική ιστοσελίδα την ιστοσελίδα του πιλοτικού συστήµατος “https://test3.diavgeia.gov.gr/

luminapi/opendata" έπαιρνε δεδοµένα πληροφορίας , όπως για παράδειγµα τον αριθµό διαδικτυακής ανάρτησης και τον υπογράφοντα της απόφασης, για αποφάσεις παντός τύπου και κατέβαζε τοπικά τα αντίστοιχα έγγραφα τους. Εκτός από τον κωδικό του υπογράφοντα της εκάστοτε απόφασης ο συγκεκριµένος crawler προσέφερε την παράλληλη δυνατότητα ανάκτησης των στοιχείων του υπογράφοντα( όπως το ονοµατεπώνυµο) από τον ιστοχώρο της Διαύγειας. Επίσης, µπορούσε να δεχθεί πληθώρα ορισµάτων που εξειδίκευαν περαιτέρω την αναζήτηση όπως ο τύπος της απόφασης, ο κωδικός του οργανισµού που µετείχε/εξέδωσε την απόφαση και η ηµεροµηνία δηµοσίευσης της.

Παρ’ όλα αυτά όµως, ο συγκεκριµένος crawler ήταν απαρχαιωµένος αφενός σε σχέση µε τις ανάγκες της παρούσας εργασίας και αφετέρου σε σχέση µε το ίδιο το σύστηµα της Διαύγειας. Θυµίζουµε ότι οι ανάγκες της εργασίας ήταν η ανάκτηση αποφάσεων του ΕΚΠΑ , τύπου έγκρισης δαπάνης(Β.2.1), στους τελευταίους έξι µήνες (Ιανουάριος- Ιούνιος 2017). Ακόµα, ο crawler χρειαζόταν πληθώρα αλλαγών για να αντιµετωπίσει την µορφή αποφάσεων Β.2.1 καθώς και να παίρνει τις πληροφορίες από το βασικό σύστηµα του Διαύγεια και όχι από το πιλοτικό. Όµως, το συγκεκριµένο πρότυπο χρησιµοποιήθηκε σαν οδηγός για την υλοποίηση του crawler που ακολουθεί στην συνέχεια και θα ήθελα να ευχαριστήσω τον Ζαχαρία Τζερµιά για την δουλειά του. 

(11)

2.2 Λίγα λόγια για το Scrapy Framework της Python

Το Scrapy είναι ένας σκελετός(framework) γραµµένος στην γλώσσα προγραµµατισµού Python που ως σκοπό έχει να επιτελεί crawling πάνω σε ιστοσελίδες άλλα και να εξάγει δεδοµένα µε καθορισµένη µορφή. Παρόλο που αρχικά σχεδιάστηκε για ανάκτηση πληροφοριών από ιστοσελίδες, πλέον χρησιµοποιείται σε πληθώρα εφαρµογών όπως στην εξόρυξη και επεξεργασία πληροφοριών(data mining).

Η αρχιτεκτονική του Scrapy οµοιάζει αρκετά µε την τυπική δοµή ενός web crawler.

Όπως φαίνεται στην παραπάνω εικόνα το Scrapy αποτελείται από διάφορα συστατικά στοιχεία. Αυτά είναι η µηχανή (Scrapy Engine) η οποία είναι υπεύθυνη για την ροή των δεδοµένων στα υπόλοιπα κοµµάτια του. Δεν µπορεί κανείς να αµελήσει τους ρόλους του χρονοπρογραµµατιστή (Scheduler), ο οποίος λαµβάνει τα πολυάριθµα αιτήµατα από την µηχανή και τα τοποθετεί σε µια ουρά, και του downloader ο οποίος κατεβάζει τις ιστοσελίδες που του ζητήθηκαν και τις παραδίδει στην µηχανή.

Το τελευταίο και ίσως το σηµαντικότερο χαρακτηριστικό του framework είναι οι αράχνες(spiders). Πρόκειται για κλάσεις στοιχείων που προγραµµατίζονται από τους χρήστες της εφαρµογής και ο στόχος του είναι να καθορίζουν τον τρόπο που θα γίνεται η ανάκτηση των αντικειµένων, που οι χρηστές έχουν ορίσει, από τις ιστοσελίδες. Για να επιτευχθεί αυτό µε την µέγιστη δυνατή συνέπεια και ευκολία παρέχονται οι διοχετευτείς αντικειµένων (Item Pipelines), οι οποίοι επεξεργάζονται και αποθηκεύουν τα αντικείµενα µόλις ανακτηθούν.

Η ροή των δεδοµένων όπως φαίνεται στην παραπάνω εικόνα ελέγχεται εξ ολοκλήρου από την µηχανή του Scrapy. Αρχικά η µηχανή λαµβάνει τα πρώτα αιτήµατα από τον Spider, τα οποία στέλνει στον χροπρογραµµατιστή ο οποίος µε την σειρά του τα τοποθετεί στην ουρά και επιστρέφει τα επόµενα στην µηχανή. Αυτή µε την σειρά της προωθεί τα αιτήµατα στον downloader ο οποίος κατεβάζει την ιστοσελίδα που του ζητήθηκε επιστρέφοντας την στην µηχανή. Η µηχανή λαµβάνει την απάντηση και την προωθεί στην αράχνη, η οποία µε την σειρά της την επεξεργάζεται, σύµφωνα µε τους κανόνες και τα πρότυπα που ορίστηκαν από τον χρήστη κατά την φάση υλοποίησης, και επιστρέφει τα ανακτηθέντα αντικείµενα καθώς και επόµενα αιτήµατα στην µηχανή. Αυτή

Εικόνα 2: Αρχιτεκτονική και ροή πληροφορίας σκελετού Scrapy

(12)

στέλνει τα αντικείµενα που µόλις ανακτήθηκαν στους διοχετευτείς αντικειµένων και επαναλαµβάνει την διαδικασία για τα νέα αιτήµατα που παρέλαβε.

2.3 Ο crawler που αναπτύχθηκε για τις ανάγκες της εφαρµογής

O crawler που υλοποιήθηκε στο Scrapy framework έπαιρνε σαν όρισµα δυο ηµεροµηνίες, την ηµεροµηνία αρχής και την ηµεροµηνία τέλους. Στην συνέχεια, έψαχνε για αποφάσεις τύπου Β.2.1, δηλαδή αποφάσεις εγκρίσεως δαπάνης, του οργανισµού µε κωδικό 99203020, που είναι το αναγνωριστικό του ΕΚΠΑ. Η αρχική ιστοσελίδα που κοιτούσε ήταν η πρώτη απάντηση του server(εξυπηρέτης) του Διαύγεια(https://

diavgeia.gov.gr/luminapi/opendata/) , σε µορφή xml, στο ερώτηµα που διατυπώθηκε παραπάνω. Κάθε σελίδα απάντησης ρυθµίστηκε από την αράχνη να έχει εκατό αποφάσεις, ώστε η σελίδα να αλλάζει υποβάλλοντας νέο αίτηµα µέσω της µηχανής Scrapy. Το είδος των αντικειµένων που η αράχνη αναλάµβανε να αντλήσει και να επεξεργαστεί φαίνεται στην παρακάτω εικόνα. Τα αποτελέσµατα αποθηκεύονταν σε ένα αρχείο τύπου json, το όνοµα του οποίου δίνονταν στα ορίσµατα του crawler. Όπως θα φανεί και στην συνέχεια, επιλέξαµε να εστιάσουµε σε πεδία που είχαν ενδιαφέρον για τις ανάγκες της έρευνας µας όπως ο κωδικός του υπογράφοντα, ο κωδικός του εµπλεκόµενου φορέα κ.α.

Στο σηµείο αυτό αξίζει να τονιστεί η ιδιαιτερότητα των πεδίων extraFieldValues. Κάθε απόφαση που λαµβάνονταν από την µηχανή στην αράχνη, περιείχε µια λίστα των ανωτέρω πεδίων. Το διαφορετικό µε τα υπόλοιπα πεδία του DiavgeiaItem είναι ότι τα πεδία sponsor_names, sponsor_afms, sponsor_amounts και sponsor_cpvs είχαν πολλαπλές τιµές. Αυτό συνέβαινε διότι αυτά τα πεδία σχετίζονταν µε τα στοιχεία αναδόχων(ονοµατεπώνυµα, ΑΦΜ προσώπων, χρηµατικά ποσά που έλαβαν, και κωδικός δαπάνης που καταχωρείται το ποσό αντίστοιχα). Και ο αριθµός των αναδόχων, όπως είναι λογικό, σε κάθε απόφαση ήταν µεταβλητός. Συνεπώς, κατασκευάστηκε επιπρόσθετη συνάρτηση για την άντληση και την επεξεργασία αυτής της σύνθετης λίστας στοιχείων. Η συνάρτηση αυτή έπαιρνε σαν όρισµα την ιστοσελίδα και ένα

Εικόνα 3: Αντικείµενο απόφασης Διαύγειας

(13)

αντικείµενο τύπου Diavgeia_Item και γέµιζε µε πληροφορία τα συγκεκριµένα πεδία, καταχωρώντας τα στοιχεία σε πίνακες της python.

Για κάθε απόφαση που είχε αναρτηµένο κάποιο έγγραφο στο Διαύγεια, ενεργοποιούνταν ο διοχετευτής αρχείου(Item Pipeline) που αφορούσε το κατέβασµα του εγγράφου από τον ιστοχώρο. Επιλέχθηκε να διατηρηθεί ο αλγόριθµος που δηµιουργήθηκε στο πρότζεκτ του κ.Τζερµιά. Πρόκειται για ένα σύστηµα που επιτελούσε την λήψη των εγγράφων µέσω δεκαπέντε παράλληλων νηµάτων(threads). Η αστυνόµευση της διαδικασίας γινόταν από έναν Scheduler ο οποίος λάµβανε τα URL των αποφάσεων από τον crawler, τα τοποθετούσε σε µια ουρά και ακολούθως τα έδινε στα νήµατα. Η χρησιµότητα που είχαν τα έγγραφα για τις ανάγκες τις εργασίας θα φανεί στο επόµενο κεφάλαιο.

Τέλος, αξίζει να γίνει µια µικρή αναφορά στον ρυθµό µε τον οποίο έγινε η άντληση της πληροφορίας. Υπό τον κίνδυνο ενδεχόµενου DDΟS Ban από τους εξυπηρέτες(servers) του ιστοχώρου της Διαύγειας, έπρεπε να τροποποιηθεί ο ρυθµός µε τον οποίο γινόταν η εξαγωγή των δεδοµένων. Αυτός ρυθµίστηκε να είναι στις έξι αποφάσεις το λεπτό.

Δεδοµένου του όγκου των αποφάσεων που χρειαζόµασταν, περί τις 19000 το εξάµηνο(περίπου 3000 τον µήνα), δαπανήθηκαν περίπου τρεις ηµέρες για να γίνει η λήψη των στοιχείων από δυο υπολογιστικά µηχανήµατα.

(14)

3. ΕΠΕΞΕΡΓΑΣΙΑ ΔΕΔΟΜΕΝΩΝ

Τα δεδοµένα και τα έγγραφα των αποφάσεων από το αρχικό αρχείο του crawler περνούν από διάφορα στάδια επεξεργασίας µέχρι να είναι σε θέση να εισαχθούν στην βάση Elastic. Τα στάδια αυτά, εκτείνονται από την επεξεργασία των εγγράφων µέχρι την τροποποίηση του τελικού αρχείου έτσι ώστε να µπορεί να εισαχθεί µέσω µιας και µόνο εντολής στην βάση. Στην εικόνα 4 φαίνεται η ρουτίνα σε κέλυφος bash(bash shell routine) που συνοψίζει όλα τα βήµατα για τον καθορισµό και την επεξεργασία των αρχείων και των δεδοµένων που εξόρυξε ο crawler. Έτσι, µε µια κλήση της ρουτίνας αυτής µε βασικότερα ορίσµατα, τον φάκελο του συστήµατος που είχε τα έγγραφα των αποφάσεων και το json αρχείο που παρήγαγε ο crawler, δηµιουργούσε στην έξοδο το τελικό αρχείο (σε µορφή json) που θα προωθούνταν στην βάση.

3.1 Μετατροπή και επεξεργασία εγγράφων αποφάσεων

Τα έγγραφα που έγιναν λήψη µέσω του crawler ήταν σε µορφή pdf. Τέτοιου τύπου αρχεία µπορεί µε την πρώτη µατιά να φαίνονται σαν αρχεία κειµένου, στην πραγµατικότητα όµως είναι γραφικές αναπαραστάσεις και σύνολα εντολών που ορίζουν ρητά το τι, το που και το πως θα τοποθετηθούν τα στοιχεία που περιέχουν. Γι’ αυτό, το έργο της απευθείας επεξεργασίας ενός pdf είναι δύσκολο και χρονοβόρο.

Ο βασικός λόγος που χρειαζόταν να γίνει συντακτική ανάλυση στα έγγραφα των αποφάσεων ήταν ότι περιείχαν πληροφορίες, όπως ο κωδικός του επιστηµονικού έργου, το όνοµα του επιστηµονικού υπευθύνου όπως επίσης και του υπογράφοντα, απαραίτητες για την πλειοψηφία των ερωτηµάτων που θέλαµε να κάνουµε και οι οποίες δεν µπορούσαν να ληφθούν άµεσα µέσω του crawler. Η λύση που καταλήξαµε ήταν σε πρώτη φάση τα αρχεία να µετατρέπονται από µορφή pdf σε µορφή txt, µια µορφή που κάνει εφικτό το έργο της συντακτικής και εννοιολογικής ανάλυσης του κειµένου. Σε δεύτερη φάση θα λάµβανε χώρα η προαναφερθείσα ανάλυση.

Εικόνα 4: Στάδια επεξεργασίας και εξόρυξης πληροφορίας

(15)

Για την φάση της µετατροπής χρησιµοποιήθηκε το πρόγραµµα-µετατροπέας PDFMiner που κατασκευάστηκε το 2014 από τον Yusuke Shinyama [4]. Αυτό το εργαλείο σε αντίθεση µε άλλα παρόµοια που υπάρχουν, εστιάζει στην εξόρυξη δεδοµένων κειµένου από το έγγραφο. Μάλιστα καθιστά δυνατή την εξόρυξη της ακριβούς τοποθεσίας του κειµένου προς αναζήτηση καθώς και µορφολογικά στοιχεία όπως το µέγεθος της γραµµατοσειράς. Είναι γραµµένος σε Python και µπορεί να αντιµετωπίσει ακόµα και έγγραφα γραµµένα στις γλώσσες CJK( Chinese-Japanese-Korean). Το βασικό του µειονέκτηµα όµως είναι η ταχύτητα, µιας και όπως σχολιάζει ο δηµιουργός του είναι περίπου είκοσι φορές πιο αργό από άλλα παρόµοια προγράµµατα που είναι γραµµένα στη γλώσσα C. Το µειονέκτηµα αυτό δεν έκανε αισθητή την παρουσία του µιας και στην συντριπτική πλειοψηφία το πρόγραµµα ήταν αντιµέτωπο µε αρχεία pdf µιας σελίδας και χωρίς εικόνες.

Πιο συγκεκριµένα, έπρεπε πρώτα να µετατραπεί κάθε αρχείο pdf του αρχικού καταλόγου σε µορφή txt. Αυτό γίνονταν από το πρόγραµµα κελύφους

“pdf_converter.sh”, το οποίο έπαιρνε σαν είσοδο το µονοπάτι(path) του καταλόγου λήψης και για κάθε ένα έγγραφο καλούσε το πρόγραµµα pdf2txt.py από το PDFMiner για να γίνει η µετατροπή. Τα καινούργια αρχεία κειµένου αποθηκεύονταν στον κατάλογο που δίνονταν σαν δεύτερο όρισµα το προγράµµατος.

Μετά την ολοκλήρωση της µετατροπής, σειρά είχε η άντληση της πληροφορίας από κάθε αρχείο κειµένου του κωδικού του επιστηµονικού έργου, του ονοµατεπώνυµο του επιστηµονικού υπευθύνου και του υπογράφοντα της απόφασης. Για τα πρώτα δυο πεδία χρησιµοποιήθηκε η βιβλιοθήκη re της python [9]. Χρησιµοποιώντας την συγκεκριµένη βιβλιοθήκη ο χρήστης µπορεί να δηµιουργήσει µοτίβα κανονικών εκφράσεων(regular expression patterns) και στην συνέχεια να εντοπίσει τα σηµεία του κειµένου που υπάρχουν και να εξορύξει την αντίστοιχη πληροφορία.

Στην ρουτίνα “EpYpeuthinoi.py” που καλείται στο βήµα 2, όπως φαίνεται στην εικόνα 4 φτιάχνονται τα µοτίβα και ελέγχονται όλα τα αρχεία τύπου txt του καταλόγου για την ύπαρξη αυτών. Σε περίπτωση που στην απόφαση δεν αναγράφεται κωδικός επιστηµονικού έργου ή ο επιστηµονικός υπεύθυνος , εκτυπώνεται ο χαρακτήρας ‘-‘ σαν αποτέλεσµα. Αυτό όπως διαπίστωσα µπορεί να συµβαίνει αν οι αποφάσεις αφορούν κληροδοτήµατα ή δωρεές στο πανεπιστήµιο και λοιπές κατηγορίες δαπανών.

Εκτός από τις πληροφορίες επιστηµονικών έργων το άνωθεν πρόγραµµα εντοπίζει το ονοµατεπώνυµο του εκάστοτε υπογράφοντα. Η λογική που ακολουθείται εδώ είναι διαφορετική µε προηγουµένως. Η βασική διαφορά είναι ότι στην περίπτωση του υπογράφοντα, τα στοιχεία πληροφορίας του βρίσκονται πάντα στο τέλος του εγγράφου, δηλαδή στις τελευταίες δυο µε τρεις λέξεις. Συνεπώς, πολύ εύκολα και γρήγορα µπορούν να αντληθούν, αντιµετωπίζοντας το κείµενο σαν bag of words και παίρνοντας τις τελευταίες δυο-τρεις λέξεις του(στη περίπτωση σηµείου στίξης).

Το αρχείο αποτελεσµάτων φέρει το όνοµα που επιλέγει ο χρήστης στο δεύτερο όρισµα του προγράµµατος και είναι και αυτό σε µορφή json. Περιέχει τέσσερα πεδία δεδοµένων. Το πρώτο πεδίο είναι ο αριθµός διαδικτυακής ανάρτησης της απόφασης στο Διαύγεια. Ο σκοπός της ύπαρξης αυτού του πεδίου είναι να διευκολύνει την συνένωση(join) των δυο αρχείων json, όπως θα εξηγηθεί στην συνέχεια. Τα υπόλοιπα τρία πεδία(“signer_name, ka, episthmonikos_ypeuthinos”) φέρουν την πληροφορία που αναφέρθηκε παραπάνω.

(16)

3.2 Υπολογισµός ολικού ποσού

Εκτός από την επεξεργασία των εγγράφων για την άντληση των στοιχείων που προαναφέρθηκαν χρειαζόταν και η επεξεργασία του αρχείου που δηµιούργησε ο crawler από τις αποφάσεις που σύλλεξε. Το αποτέλεσµα αυτής της επεξεργασίας ήταν η προσθήκη ενός επιπλέον πεδίου σε κάθε καταχώρηση απόφασης του αρχείου. Αυτό το πεδίο έφερε τον τίτλο “full_amount” και ήταν ένα νούµερο που συµβόλιζε τα συνολικά χρήµατα(σε ευρώ) που αναφέρονται στην απόφαση πως δαπανήθηκαν., πληροφορία άκρως χρήσιµη για τα ερωτήµατα που επιλέχθηκαν να γίνουν στην βάση.

Ο υπολογισµός αυτός γινόταν από το πρόγραµµα Python “sum_amounts.py”, που για το αρχείο αποφάσεων που έπαιρνε στο πρώτο όρισµα δηµιουργούσε ένα αρχείο αποτελεσµάτων. Πέρα από την προφανή άθροιση των εκάστοτε ποσών, αυτά έπρεπε πρώτα να µετατραπούν σε νούµερα µιας και ο crawler τα αντιµετώπιζε σαν συµβολοσειρές.

3.3 Συνένωση αρχείων και προετοιµασία για εισαγωγή

Μέχρι το σηµείο αυτό έχουµε δυο αρχεία json. Το πρώτο είναι το αρχείο που σχηµάτισε η αράχνη µας εµπλουτισµένο µε το πεδίο full_amount. Το δεύτερο είναι το αρχείο που παρήχθη από την επεξεργασία των εγγράφων των αποφάσεων και περιέχει τα στοιχεία των ερευνητικών έργων και των υπογραφόντων.

Προφανώς το επόµενο βήµα είναι η συνένωση των δυο παραπάνω αρχείων σε ένα, το οποίο για κάθε αριθµό απόφασης θα περιέχει όλα τα στοιχεία που έχουν αντληθεί.

Για να υλοποιηθεί η συνένωση χρησιµοποιήθηκε το πρόγραµµα jq, το οποίο φτιάχτηκε από τον Stephen Dolan [5]. Το πρόγραµµα jq είναι ένα πρόγραµµα επεξεργασίας, από τη γραµµή εντολών, αρχείων σε µορφή json. Μπορεί να τροποποιεί, να φιλτράρει και να µετασχηµατίζει αυτόν τον τύπο αρχείων, όπως µερικά βασικά προγράµµατα του Unix(sed, awk, grep κλπ). Είναι γραµµένο στη γλώσσα προγραµµατισµού C.

Εικόνα 5: Χρήση jq

(17)

Το jq είναι ένας εφαρµογός φίλτρων. Αυτό σηµαίνει ότι σε κάθε κλήση του, παίρνει ένα σύνολο φίλτρων τα οποία εφαρµόζει σε ένα αρχείο εισόδου και παράγει µια έξοδο.

Μάλιστα υποστηρίζεται η τεχνική της διοχέτευσης(pipeline), µε σκοπό να εξασφαλιστεί όσο το δυνατόν µεγαλύτερη ταχύτητα. Τα φίλτρα του jq εκτείνονται σε ένα ευρύ φάσµα και συνεχώς προστίθενται νέα. Έτσι, κάποιος µπορεί να βρει και να εφαρµόσει από πολύ απλά φίλτρα , όπως την εκτύπωση του περιεχοµένου του αρχείου εισόδου στην έξοδο, µέχρι συνδυασµούς σύνθετων όπως αυτά που φαίνονται στην εικόνα 5 και θα εξηγηθούν παρακάτω.

Στη γραµµή 48 του προγράµµατος bash, της παραπάνω εικόνας, εφαρµόζεται το φίλτρο

“flatten” του jq στο αρχείο, τύπου json, των αποφάσεων του Διαύγεια που προέκυψε από το προηγούµενο βήµα(εµπλουτισµένων µε το ολικό ποσό). Το φίλτρο flatten δέχεται σαν είσοδο έναν πίνακα πινάκων αντικειµένων, στη περίπτωση µας έναν πίνακα πινάκων από εγγραφές json, και επιστρέφει έναν πίνακα στον οποίο όλοι οι υποπίνακες έχουν αντικατασταθεί από τις τιµές τους. Το αποτέλεσµα αυτού του φίλτρου αποθηκεύεται στο αρχείο ‘$final_decision’ που δίνεται σαν όρισµα.

Η επόµενη και πιο ουσιώδης επεξεργασία που γίνεται είναι η συνένωση του προηγούµενου αρχείου µε το αρχείο που περιέχει εγγραφές json για το επιστηµονικό έργο και τον υπογράφοντα της απόφασης. Το αποτέλεσµα που αποθηκεύεται στο αρχείο µε όνοµα “$to_import”, που δίνεται και αυτό σαν όρισµα στο πρόγραµµα, είναι το αποτέλεσµα της διοχέτευσης τριών φίλτρων όπως φαίνεται στη γραµµή 53 της εικόνας 5 .Η τριάδα των φίλτρων παίρνει σαν όρισµα 2 αρχεία στα οποία αρχικά εφαρµόζει το φίλτρο flatten που περιγράφηκε παραπάνω. Στην πορεία εφαρµόζεται στα αρχεία το φίλτρο “group_by” το οποίο οµαδοποιεί τα δεδοµένα τους σύµφωνα µε τον αριθµό διαδικτυακής ανάρτησης απόφασης(“.ada”). Συνεπώς, έχουµε έναν πίνακα αποτελούµενο από επιµέρους πίνακες εγγραφών. Κάθε επιµέρους πίνακας έχει δύο εγγραφές, µια εγγραφή json µε τα πεδία του crawler και “full_amount” και ακόµα µια εγγραφή json µε τα πεδία που αντλήθηκαν από τα έγγραφα των αποφάσεων.

Τελικώς θα εφαρµοστεί στα αποτελέσµατα η συνάρτηση “map()” µε είσοδο το φίλτρο

“reduce .[] as $x ({}; . * $x)”. Η συνάρτηση map τρέχει το φίλτρο που της δόθηκε σαν όρισµα , για κάθε εγγραφή του πίνακα, και δίνει στην έξοδο έναν νέο πίνακα στοιχείων json(~αποτέλεσµα της εφαρµογής του φίλτρου). Το φίλτρο reduce είναι αυτό που πραγµατοποιεί το join, αφού για κάθε έναν πίνακα εγγράφων json που σχηµάτισε το φίλτρο group_by συνενώνει τις εγγραφές σε µια.

Με την ανωτέρω µέθοδο έχουµε στο αρχείο εξόδου ένα πίνακα εγγραφών json µε όλα τα πεδία που χρειαζόµαστε. Το τελευταίο βήµα είναι να φέρουµε το αρχείο στη µορφή που καταλαβαίνει το API της συσσωρευµένης εισαγωγής στοιχείων του Elastic Search(bulk_API). Αυτό γίνεται προσθέτοντας σε κάθε εγγραφή του αρχείου µια επικεφαλίδα που δηλώνει ρητά σε ποιον κατάλογο και τύπο του Elastic θα τοποθετηθεί.

Αυτό γίνεται και πάλι µε την βοήθεια του jq όπως φαίνεται στην εικόνα 5, στην γραµµή 58 του προγράµµατος. Τα API του Elastic Search θα σχολιαστούν εκτενέστερα στο επόµενο κεφάλαιο.

(18)

4. ΕΡΩΤΗΜΑΤΑ ΣΤΗ ΒΑΣΗ ELASTIC SEARCH

4.1 Σύντοµη περιγραφή Elastic Search

To Apache Lucene είναι ένα δωρεάν λογισµικό ανοιχτού κώδικα για ανάκτηση πληροφορίας. Δηµιουργήθηκε από τον Doug Cutting το 1999 και είναι γραµµένο σε Java. Μπορεί να ανταποκριθεί στις ανάγκες οποιασδήποτε εφαρµογής αφορά αποθήκευση και έρευνα πάνω σε δεδοµένα κειµένου. Το Elastic Search είναι µια µηχανή αναζήτησης ανοιχτού κώδικα που βασίστηκε πάνω στο Lucene. Αναπτύχθηκε σε Java το 2010 από τον Shay Bannon και χρόνο µε τον χρόνο πείθει όλο και περισσότερες εταιρείες να το χρησιµοποιήσουν στις εφαρµογές τους. Διάσηµοι χρήστες του είναι το Facebook, η Mozilla και το Cern. Το πλεονέκτηµα του είναι ότι παρέχει ένα κατανεµηµένο περιβάλλον διαχείρισης και full-text αναζήτησης, σε πραγµατικό χρόνο µέσω αιτηµάτων πάνω στο πρωτόκολλο HTTP, εγγράφων σε µορφή json. Όλες οι παραπάνω δυνατότητες που προσφέρει έγκεινται στην αρχιτεκτονική πάνω στην οποία βασίστηκε.

Η βασική µονάδα πληροφορίας του Elastic Seach είναι τα έγγραφα(documents) σε µορφή json. Κάθε document είναι ένα σύνολο ζευγών πεδίων-κλειδιών. Το επόµενο χρήσιµο κοµµάτι είναι οι αντιστοιχίες(mappings). Οµοιάζουν µε τα σχήµατα βάσης δεδοµένων(database schemas) στις σχεσιακές βάσεις δεδοµένων. Ο σκοπός του είναι να περιγράψουν το είδος των πεδίων των εγγράφων και τον τρόπο µε τον οποίο πρέπει να αποθηκευτούν από το Lucene. Πολλά documents µαζί, σε συνδυασµό µε το mapping τους συγκροτούν έναν τύπο(type). Ο τύπος είναι το αντίστοιχο του Elastic Search για τους πίνακες των σχεσιακών συστηµάτων οργάνωσης βάσεων δεδοµένων. Πολλά types µαζί συγκροτούν έναν κατάλογο(index) δηλαδή την αντίστοιχη “βάση δεδοµένων”. Μια ακόµα χρήσιµη δυνατότητα που προσφέρεται είναι η δυνατότητα διαίρεσης του indeχ σε κοµµάτια που καλούνται θρύµµατα(shards). Αυτό επιτρέπει στις λειτουργίες να παραλληλοποιούνται κατά µήκος των shards, τα οποία µεγαλώνουν οριζοντίως όσο αυξάνονται τα δεδοµένα, αυξάνοντας τελικά την απόδοση του συστήµατος.

Όπως φαίνεται στην εικόνα 6 ένας κόµβος(node) είναι ένας εξυπηρέτης(server) ο οποίος αποθηκεύει και µπορεί να εκτελέσει ερωτήµατα πάνω σε indices του Elastic Search. Πολλοί κόµβοι µαζί συγκροτούν µια συστάδα(cluster). Όλοι µαζί οι κόµβοι της συστάδας περιέχουν όλα τα δεδοµένα της εφαρµογής. Η οργάνωση σε συστάδες προσφέρει δυνατότητες καταχώρησης και αναζήτησης σε όλους του κόµβους που την απαρτίζουν. Κατ’ αυτόν τον τρόπο λοιπόν εξασφαλίζεται η ‘ενιαία’ διαχείριση σε δεδοµένα κατανεµηµένα σε διαφορετικούς κόµβους.

Εικόνα 6: Αρχιτεκτονική Elastic Search

(19)

4.2 Εισαγωγή δεδοµένων

Το Elastic Search είναι όπως ειπώθηκε παραπάνω µια µηχανή αναζήτησης σε σχεδόν πραγµατικό χρόνο που στηρίζεται στην αρχιτεκτονική REST Το Rest(Representational State Transfer) αποτελεί ένα σύνολο αρχών σχεδίασης µιας υπηρεσίας που επικεντρώνεται στα δεδοµένα του συστήµατος. Η µεταβολή της κατάστασης των δεδοµένων του συστήµατος περιγράφεται και µεταφέρεται στο σύστηµα µέσω του πρωτοκόλλου HTTP. Δηµιουργήθηκε το 2000 από τον Roy Fielding [10].

Τα βασικά χαρακτηριστικά του είναι δυο. Πρώτον, ότι για την επικοινωνία µεταξύ χρήστη και συστήµατος χρησιµοποιούνται αποκλειστικά HTTP αιτήµατα. Μάλιστα, η βασική του λογική είναι να υπάρχει ένα-προς-ένα αντιστοιχία µεταξύ των HTTP µεθόδων και των λειτουργιών CRUD(Create Read Update Delete). Έτσι, για την δηµιουργία ενός πόρου στο σύστηµα χρησιµοποιούµε την µέθοδο POST, για το διάβασµα ενός πόρου τη GET, για την ενηµέρωση ή την επεξεργασία του την µέθοδο PUT και για την διαγραφή την µέθοδο DELETE. Δεύτερον, η συγκεκριµένη αρχιτεκτονική θεωρείται stateless, µε την έννοια ότι δεν υπάρχει οποιαδήποτε εξάρτηση µεταξύ δυο REST κλήσεων.

To Elastic Search είναι οργανωµένο σε API’s(application programming interfaces), δηλαδή σε σύνολα συναρτήσεων και εξειδικευµένα εργαλεία που το καθένα επιτελεί κάποιο συγκεκριµένο σκοπό. Στο παρόν κεφάλαιο θα γίνει αναφορά στο BULK_API του Elastic Search. Το BULK_API επιτρέπει να γίνουν πολλαπλές πράξεις εισαγωγής/

διαγραφής/ενηµέρωσης σε µια κλήση του API. Αυτό έχει σαν συνέπεια την αύξηση της ταχύτητας της ευρετηρίασης(indexing speed). Η δοµή που πρέπει να έχει ένα αρχείο ακολουθεί την εξής µορφή : Για κάθε εγγραφή που βρίσκεται σε µια γραµµή του αρχείου πρέπει ακριβώς από πάνω της να βρίσκεται µια γραµµή που ορίζει σαφώς τι πράξη θα πραγµατοποιηθεί και που. Υποχρεωτικά στο τέλος κάθε γραµµής του αρχείου πρέπει να υπάρχει ο χαρακτήρας αλλαγής γραµµής “\n”.

Όσον αφορά την εισαγωγή των δεδοµένων λαµβάνοντας υπόψιν ότι είχαµε να εισάγουµε περί τις 19000 αποφάσεις η χρήση του συγκεκριµένου API ήταν κάτι παραπάνω από επιτακτική. Έτσι, κάθε µία εγγραφή json των έξι αρχείων που δηµιουργήθηκαν από την επεξεργασία(βλ. κεφάλαιο 3), ένα για κάθε µήνα, ενηµερώθηκε µε µια επικεφαλίδα που όριζε ρητά σε ποιον index και type πρέπει να ευρετηριαστεί. Κάθε αρχείο αποφάσεων εισήχθη τελικά στην βάση µέσω µιας κλήσης στο BULK_API του Elastic Search µέσω της µεθόδου HTTP_POST (“curl -s -XPOST localhost:9200/_bulk --data-binary @<filename.json>”).

(20)

4.3 Λίγα λόγια για το Search_API

Μπορεί κάποιος χρησιµοποιώντας την γλώσσα ερωτηµάτων του Elastic Search (Query DSL, Domain Specific Language) και το Search API να διατυπώσει ερωτήµατα στη βάση.

Η Query DSL χρησιµοποιεί json για να ορίσει τα ερωτήµατα που θα γίνουν στην βάση.

Οµοιάζει µε ένα αφαιρετικό συντακτικό δέντρο( AST Tree) αποτελούµενο από δύο τύπους:

α) Τα ερωτήµατα φύλλα, που ερευνούν για µια συγκεκριµένη τιµή το πεδίο που δόθηκε όπως ερωτήµατα ταιριάσµατος(match) και εύρους(range), και

β) Και τα σύνθετα ερωτήµατα, που συνδυάζουν πολλά ερωτήµατα σε ένα εξάγοντας πιο πολύπλοκα αποτελέσµατα.

Το αποτέλεσµα που επιστρέφει είναι µια εγγραφή json που στο πρώτο τµήµα της περιέχει πληροφορίες για την επιτυχία/αποτυχία της διαδικασίας στα διάφορα shards του cluster και την ποσότητα των στοιχείων που εξετάστηκαν και στην συνέχεια τα αποτελέσµατα σε µορφή πεδίου-κλειδιού.

Το Search API είναι η διεπαφή που επιτρέπει την εκτέλεση των ερωτηµάτων που έχουν γραφτεί στη γλώσσα Query DSL. Μπορεί να εφαρµοστεί σε πολλούς τύπους(types) του ίδιου καταλόγου(index) όπως επίσης και σε πολλούς καταλόγους(indices) κατά µήκος της συστάδας(cluster).

4.4 Ερωτήµατα

Όπως έχει αναφερθεί παραπάνω η βάση µας στο Elastic Search περιέχει τις αποφάσεις εγκρίσεως δαπανών του ΕΚΠΑ που έχουν δηµοσιευτεί στην Διαύγεια στο διάστηµα Ιανουάριος-Ιούνιος 2017. Τα ερωτήµατα που υλοποιήθηκαν στην παρούσα εργασία είναι τα παρακάτω:

-Ερώτηµα 1:Πόσα χρήµατα δαπανήθηκαν από κάθε λογαριασµό του ΕΚΠΑ την περίοδο του εξαµήνου;

Στο αριστερό τµήµα της εικόνας 7 φαίνεται το ακριβές ερώτηµα που έγινε στον index

“diavgeia_decisions_final”. Η ταυτότητα του λογαριασµού που σχετίζονταν µε κάθε απόφαση βρισκόταν στο πεδίο “org_name”. Συνεπώς το ερώτηµα που υποβλήθηκε υπό µορφή json, έκανε την γνωστή από την γλώσσα SQL οµαδοποίηση(group_by) των διαφορετικών τιµών του πεδίου “org_name”. Στην συνέχεια, για κάθε µια οµάδα, δηλαδή για κάθε έναν λογαριασµό, µετρούσε τα ποσά σε ευρώ των αποφάσεων της οµάδας, µέσω του aggregation στις σειρές 13-17, που ήταν επιφορτισµένο µε την άθροιση(για κάθε οµάδα )του πεδίου “full_amount” που συµβόλιζε το ποσό που ξοδεύτηκε στην εκάστοτε απόφαση. Πρέπει να τονιστεί ότι η γραµµή “size”:0, δηλώνει ότι στην έξοδο δεν επιθυµούµε να εµφανιστεί κανένα έγγραφο. Τελικά, στην έξοδο εκτυπώνονταν σε φθίνουσα σειρά, ως προς τα χρήµατα που ξοδεύτηκαν, τα ονόµατα των λογαριασµών του ΕΚΠΑ. Αυτό επαληθεύεται στο δεξί τµήµα της εικόνας 7, όπου βλέπουµε το αποτέλεσµα σε µορφή json document. Στην αρχή, το σύστηµα µας δίνει µερικές πληροφορίες για τον αριθµό των εγγράφων του καταλόγου που εξετάστηκαν και στην συνέχεια εκτυπώνονται τα στοιχεία που αναζητήσαµε(όνοµα λογαριασµού και ποσό που ξοδεύτηκε), όπως και ο αριθµός των εγγράφων που ανήκουν σε κάθε µια οµάδα (bucket).

(21)

-Ερώτηµα 2: Ποιοι είναι οι 3 υπογράφοντες αποφάσεων που έχουν υπογράψει τις περισσότερες;

Εικόνα 7: Πρώτο ερώτηµα

Εικόνα 8: Ερώτηµα 2

(22)

Το δεύτερο ερώτηµα είναι απλούστερο από το πρώτο. Εδώ, κάνουµε οµάδες(buckets) σύµφωνα µε το όνοµα του υπογράφοντα, πεδίο το οποίο αντλήθηκε κατά την επεξεργασία των δεδοµένων(Κεφάλαιο 3). Το αποτέλεσµα, που φαίνεται στο αριστερό τµήµα της εικόνας 8, περιλαµβάνει µόνο τους πρώτους τρεις υπογράφοντες λαµβάνοντας υπόψιν τον αριθµό των αποφάσεων που υπέγραψαν.

-Ερώτηµα 3: Ποια είναι τα 10 ερευνητικά έργα τα οποία έλαβαν την υψηλότερη χρηµατοδότηση;

Στην παρακάτω εικόνα φαίνεται το ερώτηµα 3 και η έξοδος του. Η λογική του είναι εντελώς παρόµοια µε το πρώτο ερώτηµα µε την διαφορά ότι εδώ οι οµάδες σχηµατίζονται σύµφωνα µε το πεδίο “ka”, που συµβολίζει τον κωδικό του ερευνητικού έργου. Ένα ακόµα σηµείο που πρέπει να δοθεί προσοχή είναι η γραµµή 50,

“exclude”:”-“, που λέει στο Search_API να µην δηµιουργήσει οµάδα για το ερευνητικό έργο µε κωδικό την παύλα. Ο λόγος για αυτό είναι πως µέσα στις 18469 αποφάσεις που ήταν στον κατάλογο, πολλές από αυτές δεν έφεραν κωδικό ερευνητικού έργου, µιας και αφορούσαν δωρεές ή λοιπές δαπάνες του πανεπιστηµίου. Συνεπώς, δεν υπήρχε κάποιος λόγος να συµπεριληφθούν στα αποτελέσµατα. Τέλος, ορίστηκε ρητά µέσω της µεταβλητής “size”(γραµµή 51, εικόνα 9), στο αποτέλεσµα να επιστραφούν τα 10 πρώτα ερευνητικά έργα.

Εικόνα 9: Ερώτηµα 3

(23)

5. ΟΠΤΙΚΟΠΟΙΗΣΕΙΣ

Για την οπτικοποίηση χρησιµοποιήθηκε το Kibana [8]. Το Kibana είναι ένα πρόγραµµα οπτικοποίησης και data analytics που σχεδιάστηκε από την ίδια οµάδα που ανέπτυξε και το Elastic search. Μπορεί πολύ εύκολα κανείς να επεξεργαστεί και να οπτικοποιήσει δεδοµένα πραγµατικού χρόνου τεράστιου µεγέθους(big data), από το πρόγραµµα περιήγησης του υπολογιστή του, µέσω του Kibana.

5.1 Διαγράµµατα αποτελεσµάτων

Αρχικά για να µπορέσουµε να παράγουµε τις οπτικοποιήσεις των παραπάνω ερωτηµάτων χρειάστηκε να πληροφορήσουµε το kibana για τον κατάλογο που θα κοιτάξει. Κατά τον καθορισµό του κεντρικού καταλόγου οπτικοποίησης δηλώσαµε ποια πεδία του είναι χρονικά, έτσι ώστε να καταστεί εφικτή η δηµιουργία διαγραµµάτων συµπεριλαµβανοµένης της χρονικής συνιστώσας.

Αφού καθορίσαµε τον index που θα κοιτάζει το Kibana, επόµενο βήµα ήταν να επιλεγεί τ ο ε ί δ ο ς τ ω ν δ ι α γ ρ αµ µά τ ω ν τ ω ν α π ο τ ε λ ε σµά τ ω ν α π ό τ η ν κ α ρ τ έ λ α Visualize(οπτικοποίηση). Οι επιλογές που προσφέρει το συγκεκριµένο πρόγραµµα εκτείνονται από την απλή απεικόνιση ενός µετρητή µέχρι την real-time γεωγραφική αναπαράσταση µεταβλητών. Για τα ερωτήµατα που έγιναν στην βάση µας επιλέχθηκε να χρησιµοποιηθούν τα διαγράµµατα pie-chart(διάγραµµα πίτα) και bar- chart(ραβδόγραµµα). Παρακάτω φαίνονται οι αναπαραστάσεις για κάθε ερώτηµα.

Για το πρώτο ερώτηµα χρησιµοποιήθηκε το παρακάτω pie-chart. Μάλιστα προτιµήθηκε η πιο µοντέρνα αναπαράσταση που οµοιάζει µε ντόνατ. Κάθε τµήµα της πίτας έχει διαφορετικό χρώµα για κάθε λογαριασµό και το µέρος της περιφέρεια που καταλαµβάνει εξαρτάται από το πόσα χρήµατα ξοδεύτηκαν από κάθε λογαριασµό. Κάνοντας κάποιος hover µε το ποντίκι του πάνω από την επιφάνεια µπορεί να δει το ακριβές ποσό που αφαιρέθηκε από τον λογαριασµό.

(24)

Για τους υπογράφοντες χρησιµοποιήθηκε το παρακάτω bar-chart. Οι ράβδοι εδώ είναι οριζόντιοι. Το µήκος καθενός εξαρτάται από την ποσότητα των αποφάσεων που υπέγραψε ο εκάστοτε υπογράφων.

Εικόνα 11 : Bar-Chart Τοπ3 υπογραφόντων ΕΚΠΑ Εικόνα 10 : Pie-Chart Λογαριασµών ΕΚΠΑ

(25)

Για το τρίτο ερώτηµα χρησιµοποιήθηκε η παρακάτω αναπαράσταση. Σε αντίθεση µε πριν που θέλαµε τα ονοµατεπώνυµα µόνο τριών ανθρώπων εδώ ζητάµε τους κωδικούς δέκα ερευνητικών έργων. Για το λόγο αυτό χρησιµοποιήθηκαν κατακόρυφες ράβδοι.

Στον οριζόντιο άξονα είναι οι κωδικοί των ερευνητικών έργων και στον κατακόρυφο τα ποσά σε ευρώ. Το ύψος καθεµιάς ράβδου είναι ανάλογο των χρηµάτων που κάθε έργο έλαβε το πρώτο εξάµηνο του 2017.

Εικόνα 12: Bar-Chart Top10 Ερευνητικών εργών

(26)

6. ΣΥΜΠΕΡΑΣΜΑΤΑ

Από τα διαγράµµατα προκύπτουν αρκετά ενδιαφέροντα συµπεράσµατα. Συνοπτικά, τα περισσότερα χρήµατα που αφορούσαν εγκρίσεις δαπανών το πρώτο εξάµηνο του 2017 έφυγαν από τον λογαριασµό κονδυλίων και έρευνας του πανεπιστηµίου. Τις περισσότερες υπογραφές τις έβαλε ο αντιπρόεδρος της επιτροπής ερευνών του ΕΚΠΑ.

Σηµαντικά λιγότερες αποφάσεις έχει υπογράψεις ο αναπληρωτής πρύτανης ερευνητικής πολιτικής και ανάπτυξης. Τέλος, πρώτο και µάλιστα µε διαφορά, χρηµατοδοτούµενο έργο είναι αυτό µε κωδικό 9994 και επιστηµονικό υπεύθυνο του τον πρόεδρο της επιτροπής ερευνών. Ακολουθεί µε σχεδόν τα µισά χρήµατα το έργο ενός καθηγητή του οικονοµικού τµήµατος του ΕΚΠΑ µε κωδικό αριθµό 3173, ο οποίος µετέχει στη συγκεκριµένη κατάταξη και µε το έργο 7335. Την τρίτη θέση κατέλαβε το έργο του πρύτανη του ΕΚΠΑ µε κωδικό 0847.

Σκοπός της εργασίας αυτής ήταν να δείξει ένα τρόπο εξαγωγής γνώσης µέσα από την µελέτη δηµόσιων δεδοµένων του προγράµµατος Διαύγεια της Ελληνικής κυβέρνησης. Η οικογένεια Elastic προσφέρει ένα σύνολο πολύ ισχυρών προγραµµάτων ικανών να επεξεργαστούν τεράστιες ποσότητες κατανεµηµένων δεδοµένων που αλλάζουν συνεχώς. Σε αυτή την απόκριση πραγµατικού χρόνου έρχεται να προστεθεί το Kibana, ένα ενηµερωµένο και πολύ σύγχρονο πρόγραµµα οπτικής αναπαράστασης, ικανό να εκφράσει τόσο καλαίσθητα όσο και εύστοχα, αποτελέσµατα που είναι προϊόν πολύπλοκων αναζητήσεων, στον µέσο χρήστη. Ταυτόχρονα, κανείς δεν µπορεί να παραλείψει τα ισχυρά προγράµµατα άντλησης δεδοµένων από το Διαδίκτυο όσο και τις συνεχώς εξελισσόµενες δυνατότητες των γλωσσών προγραµµατισµού για την επεξεργασία φυσικής γλώσσας.

Η παρούσα εργασία µπορεί να πάρει πολλές επεκτάσεις. Μερικές από αυτές είναι η µελέτη αποφάσεων και άλλων πανεπιστηµίων της χώρας ή και φορέων όπως υπουργεία και όργανα της τοπικής αυτοδιοίκησης. Η βασική λογική παραµένει η ίδια και οι αλλαγές που χρειάζονται είναι λίγες. Έτσι, µπορούν να φτιαχτούν και άλλες εφαρµογές για την εξέταση των δηµόσιων δεδοµένων όπως αυτά αναρτώνται στο Διαδίκτυο. Η ύπαρξη τέτοιων εφαρµογών είναι ακόµα πιο επιτακτική στις µέρες µας, αφενός λόγω της ανάγκης για ελεύθερη κυκλοφορία των δηµόσιων δεδοµένων και αφετέρου λόγω της ανάγκης για διαφάνεια των κυβερνητικών φορέων αλλά και των φορέων τοπικής αυτοδιοίκησης της χώρας µας, εξαιτίας των δύσκολων ηµερών που βιώνει . Έτσι ώστε να µπορεί ο πολίτης ανά πάσα στιγµή να κάνει έλεγχο σε αυτά που γίνονται για αυτόν, λαµβάνοντας υπόψιν τα ελεύθερα και ανοιχτά δεδοµένα. 

(27)

ΠΙΝΑΚΑΣ ΟΡΟΛΟΓΙΑΣ

Ξενόγλωσσος όρος Ελληνικός όρος

Cluster Συστάδα

Thread Νήµα

Node Κόµβος

Index Κατάλογος

Type Τύπος

Mapping Αντιστοιχία

Replica Αντίγραφο

Shard Κοµµάτι/Θρύµµα

Pie-Chart Διάγραµµα πίτα

Bar-Chart Ραβδόγραµµα

Server Εξυπηρέτης

Framework Σκελετός

(28)

ΣΥΝΤΜΗΣΕΙΣ-ΑΡΚΤΙΚΟΛΕΞΑ-ΑΚΡΩΝΥΜΙΑ

ΕΚΠΑ Εθνικό και Καποδιστριακό Πανεπιστήµιο

Αθηνών

URL Uniform Resource Locator

PDF Portable Document Format

XML eXtensible Markup Language

DDOS Distributed Denial of Service

JSON JavaScript Object Notation

CJK Chinese Japanese Korean languages

API Application Programming Interface

HTTP HyperText Transfer Protocol

REST REpresentational State Transfer

CRUD Create Read Update Delete

DSL Domain Specific Language

AST Abstract Syntax Tree