Big Data - preporuke

Ovako, ovih dana intenzivno razmišljam da pokrenem sopstveni startap. Da sada stavimo po strani probleme oko finansiranja i svega ostalog, interesuje me jedna stvar.

Pošto je priroda startapa takva da je neophodno da se uskladišti mnogo podataka kako bi se kasnije analizirali, imam nedoumicu kako da isprojektujem data storage mehanizam. Da odmah napomenem da dosta dobro znam SQL i imam dosta iskustva sa MySQL - om. E, tu nastaje nedoumica. Da li je neko imao slična iskustva sa MySQL - om kada je Big Data u pitanju? Da li da idem na sigurno i na provereno i da jednostavno upotrebim MySQL ili da se prebacim na nešto što je u startu pogodnije od MySQL - a, kao što su, šta znam, Hadoop i slični sistemi?

Kolika je stvarna prednost Hadoop - a i sličnih rešenja u odnosu na stari dobri MySQL? Da li je u pitanju samo glorifikovan alat ili se zaista dobija nešto što se ne dobija sa MySQL - om? Da napomenem da mi ne treba real time analiza podataka, mada se možda kasnije javi potreba za tako nečim.

Dakle, interesuje me šta mi preporučujete kao data storage soluciju, otvoren sam za sve vrste predloga.

koliko češ imati podataka za analizu?
kakvi podaci, kakve query-e češ vrtiti?

I ja imam skoro ista pitanja kao sa pocetka teme vezana za Big Data.

Potrebne su mi preporuke i saveti kako realizovati sistem za smestanje i pretragu velike kolicine podataka.

Ukratko o podacima:

- U pitanju su Apache logovi skupljeni sa stotinak servera (razliciti klienti) u periodu od 5-6-7 godina i svaki server je vozio nekoliko domena (uglavnom subdomena)
- Nad ovim logovima treba u nekoj fazi (verovatno tokom import) da se "zakaci" i GeoIP data na osnovu IP posetioca
- U opticaju je oko 75.000 fajlova, trenutno gz i bz2 zipovani
- Zipovani fajlovi zauzimaju negde oko 350GB a raspokvani (gruba racunica) oko 3.5TB
- Broj redova (takodje gruba racunica) je negde oko 22.000.000.000 tj 22 milijarde
- Na dnevnom nivou ce se dodavati novi podaci, trenutno ne znam koliko tacno ali je to verovatno drasticno manje nego sto je gore spomenuto

Ovi podaci trebaju da se koriste u analiticke svrhe i da se nad njima izvrsavaju razni upiti.

Upiti su ovog tipa:

- koliko imam poseta za neki (sub)domen u izabranom vremenskom periodu
- kakav je trend posete za izabrani domen na nekoj geografskoj lokaciji
- koliko je puta pozvana specificna URL (recimo za neki shop checkout)
- koliki je procenat gresaka (HTTP status 500) u nekom periodu za neki (sub)domen
- itd (procena je da ce biti oko 30-50 razlicitih raporta)

Front-end koji treba da prikaze ove rezultate bi bio baziran na PHP/JS.
Pozeljno je da postoji neki SQL-like jezik za upit ovakve baze podataka mada nije moranje.
Naravno, neophodno je da se nakon pozivanja upita rezultati dobiju u nekom "razumnom" vremenu, tipa 1,2,3 sekunde ali nikako duze od toga.

Skoro je izvezno da ce ovo morati da se nekako klasteruje na X servera / nodova. Da li imate procenu na koliko servera i kave specifikacije oni trebaju da budu?

Sta se za ovakve zahteve preporucuje od SW-a?
Hadoop, HBase, Hive, Hypertable?

Nov sam u ovoj BigData oblasti i jos mi nisu jasne sve cake sta se tu desava.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

A što ne bi išao na neko provereno rešenje tipa Oracle/SQL Server, nego te hadop, madop, vadop i sl. dečije igrarije koje umru kad glavni developer odluči da mu je dosadilo da se igra sa time?

Pa nisam siguran da mi je RDBM resenje dobar izbor. Ovde nemam potrebe ni za transakcijama, niti da brisem ili updejtujem podatke a zasta su RDBM uglavnom predvidjeni.
Druga stvar je naravno TCO. Oracle, MS, SAP i ekipa su papreni po tom pitanju i to klient za koga ovo treba da se radi sigurno nebi prihvatio.

Takodje ovo su analiticki podaci, nije nesto gde moram da vodim 100% racuna o svakom bajtu iz ove hrpe podataka.
Klientu je bitno da vidi recimo trend na kojoj geografskoj lokaciji mu ide najbolje prodaja kako bi se koncetrisao na to trziste tako da "ispustio" neku liniju loga i nije toliko strasno.
Mnogo je bitnije da moze da pozove neki predefinisani template za raport i da izabere ulazne parametre (period, domen itd) i da dobije brzo rezultat prikazan tabelarno ili kroz grafikone.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Cenim da ce ti 3 servera biti vise nego dovoljna. Ja bi stavio po sto vise diskova u svaki, moze nesto tipa SATA od 2-3GB, plus recimoi 64-128GB RAM. Recimo nesto tipa.

- 2U
- 2x Xeon 6-Core
- 96GB ili 128GB RAM (za 2400 ili 2600 Xeon)
- 8x 3TB SATA
- 2x1GBit Ethernet, bonded

Za punjenje Flume, za citanje HBase ili Impala. Instaliras neki CDH ili Hortoworks sistem, nema nikakvog smisla da bildas sve od nule. Definitivno nije resenje da uzmes RDBMS za non-relational data.

Probaj i Mongo. Za 3-5TB bi trebalo da bude OK, ima dobru podrsku za php. Ja vozim TokuMX aktivno u produkciji i radi sjajno.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

@nkrgovic Hvala puno. To volim, konkretan odgovor ;)

Probao sam CDH (Cloudera?) na VM i nesto je mnogo kljakavo radio, verovatno trazi mnogo vise resursa.
Hortoworks je na listi da sledece probam.

I ovaj TokuMX izgleda zanimljiv, probacu i to.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Toku ti je laksi za rad o Hadoop/Hbase i slicnih varijanti.

Sto se VM-a tice, vodi racuna: bar 32 pozeljno minimum 64GB RAM-a da to radi kako valja na nekim pristojnim test primerima. CPU mozes da optimizujes, a ocekuj da ce ti storage biti usko grlo.

Ovakve analitike po meni imaju i te kako smisla na VM-u, sa shared storage resenjem, gde imas sistem koji preko dana radi nesto (OLTP, BackOffice....) a onda nocu moze da radi analitike (OLAP) - i pri tom koristi "enterprise storage" koji koristis za dnevni rad.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Samo me je jedna stvar buni/brine a to je da li recimo pomocu MongoDB-a moram da radim neko "grupisanje" ove hrpe podataka, recimo po godini ili po serveru kako bi mi indexi bili manji.

Predpostavljam da npr necu morati da baratam uvek nad celom bazaom, npr ne moram da mesam logove (dokumente) jednog klinta sa drugim vec ce se to u najvecem broju slucajeva desavati nad nekom grupom podataka i tu bi trebalo da dobijem rezultate "odmah".

Sa druge strane imace i verovatno upita nad celom bazaom ali sam svestan da rezultat nece moci da se dobije "odmah" vec ce morati da se radi ili neki MapReduce ili vec nesto trece.

Nezgodno je sto u ovom trenutku nemam fixne zahteve kako ce baza da se query-uje nego ce to tokom vremena da se "izmislja" tj kako budu skontali koji sve operacije i analize mogu da se rade nad takvim podacima.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Trebalo bi da imaš Hadoop koji će da obradi logove, napravi statistiku kakvu želiš i smesti je u SQL a onda tu statistiku da prikazuješ / analiziraš preko front-end-a.

Realtime zezanje po logovima zaboravi, ne postoji mašinerija koja to može da izgura...

Tako je:

- Uzme podatke, parsira ih sto moze u trenutku obrade. Cilj je ne imati unstructured vec, bar, semi-structured data. Npr. ono sto kaze za GeoIP
- To strpa u neki db-like format. Mongo (toku) ili HBase - nikako samo fajlove, jer je brze za obradu.
- Onda postavlja npr. Hive ili Impala, ili JavaScript/Mongo upite nad time. Ne, nece biti real-time, ali moze da izgenerise neke podatke sumarno. Onda te sumarne podatke koristi da puni neki data warehouse / data mart , nad kojim dize reporting sistem, i nad kojim dalje moze da se radi near-real-time.

Znaci, parsiranje, obrada, generisanje mart-ova : Hadoop, ili Mongo (za dovoljno male podatke). Generisanje izvestaja Mongo, ili mozda cak RDBMS kao DataWarehouse model.

P.S. Poenta je da se podaci delimicno obrade pri unosu, da se ubrza obrada, zatim odradi generisanje podataka za razne izvestaje u klasicnom data warehouse maniru, a onda moze da se prave korelacije u real-time-u.

Ako je sumarna statistika dovoljno mala, mozes ti u realnom vremenu da manipulises njom i ako je samo izbacis kao coma separeted, uvuces u excell i napravis pivot. :) A ne znaci da nece biti, bez obzira sto se generise iz ogromnog skupa podataka.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Mozes, mozes da pravis sharding npr. po godini. To skroz lepo radi. Problem moze biti sto ces mozda morati da spojis iz vise shardova unutar istog upita, sto moze biti problem.

Sve vise mi se cini da ti se smesi data warehouse model, sa hadoop/hive/hbase cuvanjem i inicijalnim generisanjem podataka, trpanje toga u mongo (tj. bolje toku) u vidu data martova, a onda konacno generisanje izvestaja iz mongo-a. Malo vise posla :)

Ideja je da "spremis" podatke unapred, pa da radis upite nad obradjenim statistikama. Ako zatreba neka dodatna obrada, tj. neki podaci ili neka korelacija koja nije predvidjena, onda mora da se dodatno puni warehouse - i, naravno, warehouse se puni sve vreme.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Ok hvala jos jednom.

Polako dobijam "sliku" sta treba da se odradi. Daleko od toga da mi je sve jasno, bice sigurno jos pitanja ;)

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Pa generalno sumarna statistika bi trebala da bude mala, to je npr 100ak redova sa kojim cu da crtam nekakve grafikone.
Verovatno necu imati potrebe da rezultati za prikaz na front-end budu vecih gabarita, nema svrhe crtati grafikon sa milion pozicija :)

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Ja mislim da je vama ubedljivo najbolje resenje elasticsearch + kibana + logstash, logstash je za importovanje tih logova sa dodavanjem geoip field-a u svaki insert. Fantasticno radi, ekstremno se lako podesava, odlicno skalira i bas je namenjeno za to sto tebi treba. Ja sam imao skoro isti zahtev samo sa podacima koji su bili oko 80 TB logova i slicni su zahtevi korisnika. Ceo sistem sam podesio za manje od par dana sa sve custom dashboarodvima i sl. stvarcicama.

Potpis

CCIE #22192 )
https://pulsarpoint.rs

Hmm, ovo resenje sa Elasticsearch zvuci prilicno primamljivo. Potpuno drugi koncept od predhodno predlozenih resenja.

Moram malo detaljnije da izcackam sta sve ta platforma moze da radi jer ovo sto sam trazio do sad je naravno prosto preprican zahtev ali ima jos nekih tu zahteva i jos neki dodatni data source-evi i neke druge statistike (pa i operacije) koje treba da uklopim u jedinstven front-end pa mi se otvara pitanje da li mogu toliko postojeci sw da customizujem.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Ovaj elasticsearch izgleda vrlo interesantno.. Moraću da se poigram malo sa time :)

Što se tiče custom prikaza, imaš kibanu, pisana je u angularjs-u i nije teška za modifikaciju, pored toga dashboardovi mogu kompletno da se customizuju da čitaju url parametere i na osnovu toga aktiviraju odgovarajuće widget-e. Što se tice querya može mnogo toga (ne znam konkretno šta ti treba). ES je baziran na lucene-u i prilicno je to dobro napravljeno. Ja sam sad integrisao celu kibanu u neki moj custom interfejs tako da imam kompletnu user authentifikaciju i user role .. pošto kibana više ne gađa direktno es već web servis koji sluzi kao proxy i tako i autentifikuje/authorizuje korisnike.

CERN ga koristi za monitoring i analitiku nad logovima sa svih njihovih uređaja.. što je prilicno podataka :)

Potpis

CCIE #22192 )
https://pulsarpoint.rs

Probao sam elasticsearch + logstash + kibanu sa malim uzorkom logova i to radi vrlo fino!
Sutra cu upucati malo vise logova, npr 10-20m redova pa da vidm kako onda radi.

Jos jedna opcija koja mi ostaje da evaluiram je InfiniDb. Kakvo je vase misljenje o tom resenju?
Meni je to vrlo zanimljivo jer je bazirano na MySQL, column oriented, bas pogodno za analiticke svrhe ...

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

Probao sam InfiniDB engine za MySQL. To teram na "krshu" od HW, jedna VM sa 1 core na desktop racunaru sa jednim SATA diskom.

Upucao sam u jednu tablicu 10 miliona zapisa parsovanih Apache logova.

Poterao sam ovakav jedan Query:



Dakle sve se odvija nad jednom kolonom ...

Rezultat je bio ocekivano dobar i query je trajao oko 3.3 sekunde sto nije lose ali naravno to ne daje pravu sliku jer nije HW optimalan, imacu daleko vise podataka itd.

Pa onda jedan ovakav query:



To je trajalo <1s!!!

Generalno za ovakve vrste upita ovaj engine ima smisla, na RDBMS-u bi to bilo mnooooooogoooo sporije.

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator