Obiectivul temelor de casă este reprezentat de implementarea unui sistem informatic performant şi scalabil pentru gestiunea resurselor unei societăți comerciale de dimensiuni mari. În acest an universitar, organizaţia pentru care se va proiecta şi dezvolta acest pachet de programe este un lanț de restaurante.

Se va realiza implementarea mai multor module din cadrul aplicației ERP, pe parcursul a trei etape independente.

În cadrul acestei etape se va dezvolta o aplicaţie distribuită care va rula pe mai multe maşini, în condiţiile în care volumul de date pe care trebuie să îl gestioneze organizaţia implică timpi de execuţie inacceptabili pentru un utilizator care o interoghează.

După rezolvarea temei de casă, studentul va fi capabil să:

• proiecteze o bază de date distribuită, având o structură dinamică şi un număr foarte mare de înregistrări;
• utilizeze paradigma de programare MapReduce pentru a gestiona eficient partiţiile unei probleme care pot fi procesate concomitent;
• realizeze o aplicaţie distribuită ce conţine mai multe sarcini, dintre care unele vor fi rulate secvenţial, iar altele în paralel.

Cunoştinţele necesare pentru rezolvarea temei de casă sunt:

• programarea în limbajul Java;
• manipularea unei bazele de date distribuite HBase (atât prin shell-ul specific cât şi prin API);
• paradigma de programare MapReduce;
• accesarea sistemului distribuit de fișiere HDFS;
• proiectarea și dezvoltarea unei aplicații folosind platforma Hadoop.

Întrucât numărul de înregistrări stocat în baza de date relaţională determină ca timpul de răspuns pentru operaţiile de raportare (ce implică volume mari de date, istorice) să nu respecte constrângerea cu privire la operarea în timp real a unei aplicaţii integrate pentru întreprinderi, la nivelul executiv al unui lanț de restaurante s-a luat decizia migrării spre o soluţie distribuită, pentru care a decis achiziţionarea unui cluster format din maşini larg disponibile în comerț (având un cost redus, fără performanțe deosebite).

Pentru generarea rapoartelor statistice, în baza de date distribuite vor fi reținute informații istorice cu privire la meniurile disponibile pentru fiecare dată calendaristică, precum și cu privire la comenzile realizate de utilizatori.
Astfel, pentru fiecare dată calendaristică se reține meniul, identificat printr-o denumire și o descriere. Un meniu este format din mai multe feluri de mâncare. Un fel de mâncare este caracterizat - pe lângă denumire și descriere - de un tip (aperitiv, fel principal, desert) și de un preț. Un utilizator (identificat în mod unic prin combinația dintre nume și prenume) poate plasa comenzi pentru diferite meniuri. O comandă poate conține unul sau mai multe meniuri (de tipuri diferite), pentru fiecare dintre acestea specificându-se și cantitatea (pentru un meniu de același tip).

Pe baza informațiilor din bazele de date distribuite, se vor genera următoarele rapoarte:

1. un raport cu privire la activitatea utilizatorilor, astfel încât să se realizeze fidelizarea acestora; pentru fiecare utilizator se va determina valoarea comenzilor înregistrate în sistemul informatic precum și numărul de meniuri achiziționate, indiferent de tipul acestora; rezultatul va fi plasat în cadrul unui fișier din sistemul distribuit de fișiere HDFS:

raport_utilizatori

NUME UTILIZATORk, Prenume Utilizatork = valoare_comenzi, numar_meniuri

2. un raport cu privire la adresabilitatea unui fel de mâncare, astfel încât pe baza acestora să se creeze meniuri în funcție de cerințele utilizatorilor; pentru fiecare fel de mâncare, se va determina suma generată, pe baza comenzilor; raportul va conține și tipul pentru fiecare fel de mâncare, rezultatul fiind de asemenea plasat în cadrul unui fișier din sistemul distribuit de fișiere HDFS:

raport_feluri_de_mancare

fel de mancarek, tip fel de mancarek = suma generată

Se recomandă ca pentru implementarea temei de casă să folosiţi mașina virtuală pusă la dispoziţie în cadrul laboratorului sau să folosiţi aceleaşi versiuni / proprietăţi de configurare ca în cadrul acesteia, întrucât corectarea se va realiza pe o astfel de platformă. Cu alte cuvinte, veţi utiliza Hadoop 2.6.1 şi HBase 1.1.2.

Este suficient ca în portarea bazei de date să preluaţi DOAR acele tabele necesare pentru rezolvarea cerinţelor și DOAR câmpurile care se vor regăsi în cadrul rapoartelor generate. Întrucât procesul de populare implică mai multe comenzi HBase pentru o singură înregistrare, se recomandă şi implementarea unui program pentru generarea scriptului care realizează această operaţie. Nu este necesară includerea acestei aplicații în arhiva temei de casă, este suficient să includeți scriptul pentru popularea bazei de date.

Nu este necesară includerea unui script pentru crearea unei arhive jar conţinând aplicaţia dezvoltată, întrucât operaţia este realizată de plugin-ul Hadoop pentru Eclipse, acesta fiind responsabil şi de transmiterea sarcinii, permiţând totodată consultarea informaţiilor din sistemul de fişiere distribuit HDFS.

Nu este permisă utilizarea unui obiect de tip org.apache.hadoop.hbase.client.Scan decât ca parametru pentru clasele care realizează sarcini de tip MapReduce, întrucât operaţiile realizate de acesta, în contextul unei singure maşini, implică resurse de procesare şi memorie care depreciază timpul de execuţie al unei aplicaţii.

Într-o anumită dată calendaristică, pot fi definite unul sau mai multe meniuri. Un utilizator nu poate comanda feluri de mâncare individuale, ci numai meniuri. O comandă poate conține numai meniuri din cadrul aceleiași date calendaristice. Coerența informațiilor stocate în baza de date distribuite va fi controlată numai prin intermediul script-ului prin care va fi realizată instalarea tabelelor (creare + populare) și nu va fi verificată în cadrul codului sursă.

BONUS. Se pot obţine punctaje suplimentare, astfel:

• 0,50p – predarea temei până la 18.01.2016, ora 23:55;
• 0,25p – filtrarea rezultatelor (pentru ambele rapoarte) în funcție de un interval de timp, precizat printr-o dată de început sau printr-o dată de sfârșit; datele calendaristice respective pot fi precizate sub formă de constante în codul sursă sau pot fi preluate din linia de comandă;
• 0,50p - definirea unei sarcini map-reduce distincte, pentru determinarea celui mai profitabil fel de mâncare din fiecare tip, astfel încât pe baza acesteia să se definească meniul care are cea mai mare probabilitate de a genera mai multe vânzări; rezultatul va fi plasat într-un fișier care va conține tipul felului de mâncare precum și felul de mâncare precum și suma generată;
• 0,25p - modificarea rapoartelor, astfel încât rezultatele să fie plasate în cadrul unor tabele dintr-o bază de date distribuită (în loc de fișiere plasate în contextul sistemului distribuit de fișiere HDFS).

Tema va fi realizată individual şi va fi prezentată în cadrul laboratorului, până la sfârşitul semestrului. Neprezentarea temei de casă sau un rezultat nesatisfăcător al prezentării (necunoașterea funcționalității aplicației / codului sursă, imposibilitatea de a răspunde la întrebări) atrag după sine anularea punctajului corespunzător acesteia. În cadrul prezentării veţi specifica succint funcţionalităţile pe care le-aţi dezvoltat şi veţi răspunde la întrebări cu privire la modul de implementare al acestora.

Tema va trebui transmisă sub forma unui mesaj la adresa de poștă electronică aipi2015@andreirosucojocaru.ro sub forma unei arhive de tip .zip (având denumirea Grupa34XCX_NumePrenume_Tema3.zip) care să conţină script-ul pentru crearea şi popularea tabelelor din baza de date, sursele aplicaţiei şi un README în care să prezentaţi definiţia bazei de date (tabele, familii de coloane şi structura lor), explicând cum aţi proiectat sarcinile de tip map şi reduce. Subiectul utilizat va fi [Tema3][Grupa34XCX][NumePrenume]. Temele care nu respectă convențiile de nume indicate nu vor fi luate în considerare. Prezentarea se poate face numai după ce tema a fost predată sub această formă.

Trimiterea temei în format electronic nu este redundantă, temele vor fi comparate prin aplicaţii specializate pentru a se depista eventualele fraude. În această situaţie, întreg punctajul pe parcursul semestrului va fi anulat, studenţii implicaţi (atât originalul, cât şi copia / copiile) fiind obligaţi să repete disciplina – cu taxă – în anul universitar următor.