[ Petar Petrović @ 02.11.2012. 13:50 ] @
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.
[ MarkoBalkan @ 04.11.2012. 12:21 ] @
koliko češ imati podataka za analizu?
kakvi podaci, kakve query-e češ vrtiti?
[ mikikg @ 22.07.2014. 09:53 ] @
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.
[ ventura @ 22.07.2014. 10:16 ] @
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?
[ mikikg @ 22.07.2014. 10:35 ] @
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.
[ nkrgovic @ 22.07.2014. 11:01 ] @
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.
[ mikikg @ 22.07.2014. 11:35 ] @
@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.
[ nkrgovic @ 22.07.2014. 12:36 ] @
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.
[ mikikg @ 22.07.2014. 14:29 ] @
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.
[ anon325 @ 22.07.2014. 15:13 ] @
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...
[ nkrgovic @ 22.07.2014. 15:57 ] @
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.
[ nkrgovic @ 22.07.2014. 16:04 ] @
Citat:
mikikg:
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.

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.
[ mikikg @ 22.07.2014. 16:26 ] @
Ok hvala jos jednom.

Polako dobijam "sliku" sta treba da se odradi. Daleko od toga da mi je sve jasno, bice sigurno jos pitanja ;)
[ mikikg @ 22.07.2014. 16:36 ] @
Citat:
nkrgovic: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.


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 :)

[ gandalf @ 22.07.2014. 17:59 ] @
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.
[ mikikg @ 22.07.2014. 19:36 ] @
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.
[ ventura @ 22.07.2014. 21:45 ] @
Ovaj elasticsearch izgleda vrlo interesantno.. Moraću da se poigram malo sa time :)
[ gandalf @ 23.07.2014. 00:45 ] @
Š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 :)
[ mikikg @ 23.07.2014. 21:47 ] @
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 ...


[Ovu poruku je menjao mikikg dana 24.07.2014. u 00:50 GMT+1]
[ mikikg @ 24.07.2014. 16:59 ] @
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:

Code:
SELECT request_method, COUNT(request_method) FROM log_entries_2012_11 GROUP BY request_method ORDER BY COUNT(request_method) DESC


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:

Code:
SELECT SUM(request_bytes_in) FROM log_entries_2012_11


To je trajalo <1s!!!

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

[ nkrgovic @ 25.07.2014. 08:30 ] @
Pazi i HBase ti je columnar storage engine, pa ti i Hive i Impala rade tako. Naravno, mozes uvek da probas i CouchDB npr. Vertica je isto fina, ali free resenje ima limit u kolicini podata - i to premali za ozbiljan rad.

Sustina je: Razmisli da ti ti vrsi posao Elastic. Nisam ga koristio, ali moram da priznam da deluje impresivno - i on ima Hadoop backend i to bi trebalo da radi sjajno, sve dok si unutar parametara koje on moze da obradi. Za apache logove, deluje kao kljuc-u-ruke resenje, tako da je verovatno sasvim dovoljan.

Ono sto sam ti ja spominjao CDH (Hadoop + HBase + Hive/Impala + sitnice ) -> TokuDB -> Reporting je genericko resenje, koje ima smisla ako ti treba full OLAP, sa nekim custom podacima. Ako ono sto logujes nije samo clickstream, vec i detaljni user data, ako hoces vise od analiza posete - npr. detaljne analize ponasanja posetilaca, neki e-commerce recomendation engine ili tako nesto, onda ovo sto sam ti ja predlozio ima smisla. Ako si siguran da ti treba samo apache log analisys - pa, ja bi, iskreno, ulozio vreme u Elastic.
[ mikikg @ 25.07.2014. 09:35 ] @
Nisam odustao od HBase i pratecih komponenti nego u ovom trenutku nemam HW za neko malo ozbiljnije testiranje. Ocekujem da mi to obezbede pa sam u meduvremenu probao ova nesto jednostvnija resenja.

InfiniDB mi je bio zgodan za probu jer sam vec napisao parser u PHP (za custom Apache log format) koji se kaci na MySQL backend pa sam brzinski to pustio u pogon.
Inace imao sam isti takav parser i u Python-u koji su pisali neki drugi momci ali ovaj moj sam tako dobro uradio da shije ~5x po brzini ovog u Python-u za kojeg su pricali da je mega brz ;)

Sad cu jos malo da se pozabavim sa Elasticsearch ali moram da udjem dublje u problematiku bas zbog ovog custom log formata pa da vidim kako to sad sve da iskombinujem za testiranje.
[ whitie2004 @ 25.07.2014. 10:15 ] @
Probaj http://it-ebooks.info/book/3280/

Nije suvoparna teorija, vise je -> koji alat za koji zanat. Koliko veliki cekic mi treba ....
[ mikikg @ 25.07.2014. 16:05 ] @
@whitie2004 Procitao sam za sad prva dva poglavlja ove knjige. Vrlo korisno pisanije!
Hvala za preporuku.
[ gandalf @ 26.07.2014. 13:29 ] @
Citat:
mikikg:

Inace imao sam isti takav parser i u Python-u koji su pisali neki drugi momci ali ovaj moj sam tako dobro uradio da shije ~5x po brzini ovog u Python-u za kojeg su pricali da je mega brz ;)


Daj link za taj python parser (ako je open source) .. bas da vidim zasto je spor :)
[ mikikg @ 28.07.2014. 08:52 ] @
@gandalf Nazalost nije open source, vlasnistvo je firme i ne smem da sherujem ...

Ukratko, caka je u citanju ulaznog fajla, oni su verovatno radili citanje linije po linije (praksa kada se radi sa velikim fajlovima) i to je uzasno sporo, mnogo I/O sa diskom. Ja sam uradio citanje po chunk-ovima od 5-10MB pa onda u memoriji nad tim podacima uradim jedan globalni RegExp i to mi je u startu drasticno ubrzalo stvari, reda 10x! Kako sam posle pisao dalje code za moj PHP parser to se naravno smanjivalo.
Recimo isto jedan zanimljiv podatak, u PHP foreach naredba/petlja je drasticno sporija nego for petlja pa sam tu isto malo dobio na ubrzanju.
Generalno Python je brzi od PHP ali ako se napise los code dzaba ta njegova prednost. Python ne znam tako dobro kao PHP tako da se drzim onoga sto najbolje znam ...