Blog

Oživimo podatke koristeći Continuous Applications

Ako u svojoj organizaciji imate distribuciju podataka koja traje satima, a poslovni proces zahtijeva obradu informacija ASAP (as soon as possible), onda imate pravi big data problem. Kako je moguće taj problem riješiti jednom tehnologijom?
, 19.07.2017.

Ne biste vjerovali, ali iza nas je vrijeme kada smo imali potrebu informacije analizirati jedanput dnevno, a još uvijek čujemo kako postojeći BI servisi rade na mjesečnoj analitici. Možemo li si danas kada konkurencija ne spava dopustiti da temeljimo zaključke na podacima koji su stari gotovo mjesec dana? OK, razumijemo, imate želju i volju to popraviti, optimizirati. Raspitujete se kod omiljenog konzultanta za BI rješenja i shvaćate da nemate budžete za super jaki HW i/ili vrijeme za optimizaciju postojećeg rješenja koja traje u nedogled da biste izvršavanje obrade smanjili za 10–20%. Takvu situaciju želite svakako izbjeći, zar ne?

Također, danas imate zahtijevane poslovne procese, npr. Fraud Detection, koji mora raditi gotovo u stvarnom vremenu. Vidite, još uvijek neki naši BI servisi rade na mjesečnoj analitici, nismo se uspjeli kompletno prebaciti na dnevnu analitiku, a već se zahtijevaju obrade u gotovo stvarnom vremenu. Da bismo uopće mogli razgovarati o obradi podataka u stvarnom vremenu, prvo moramo razjasniti da postojeće tehnologije u tradicionalnim BI rješenjima ne drže vodu. Definitivno moramo promijeniti smjer i način razmišljanja i implementirati nova tehnološka rješenja koja rade na posve drukčiji način i koja su razvijena baš za ovakav tip procesiranja. Dakle, imamo streaming analytics tehnologije nove generacije nadohvat ruke već neko vrijeme.

Streaming ili ne?

Već neko vrijeme postoje tehnologije za obradu podataka u stvarnom vremenu, ali takva tehnologija radi efektivno samo s malom i limitiranom količinom podataka. U praksi je stvar zapravo drukčija jer stream proces prilikom izračuna treba i analitiku i podatke temeljene na povijesti. Do sada u svijetu nije poznato end-to-end rješenje koje se 100% “hrani” samo iz streama. Npr., da bismo detektirali fraud u realnom vremenu tijekom autorizacije transakcije, razvojni inženjeri i arhitekti u Fraud detection sustavima moraju graditi zaključke na povijesnoj statistici od npr. tjedan dana, mjesec dana ili čak i par godina. E sad zamislite situaciju u kojoj u trenutku autorizacije vaše transakcije fraud sustav mora provjeriti na tisuće rulova nad vašim povijesnim podacima od jedne godine u trenutku provlačenja kartice u POS uređaju. Dok provlačite karticu i kvrckate noktima o pult, trgovkinja vam govori status. “Evo, dragi kupče, sad smo na 300-tom ruleu provjere ispravnosti vaše kartice” 🙂

U stvarnosti fraud sustav tako ne funkcionira. U ovom slučaju moramo razviti aplikaciju koja će za svaku transakciju iz autorizacijskog sustava “otići” u analitičku bazu i izračunati statistiku nad milijunskim tablicama u realnom vremenu. Dakle, u većini su slučajeva takvi sustavi i aplikacije svojevrsni hibridi te moraju kombinirati tehnologije za obradu podataka u realnom vremenu (stream) i tehnologije za obradu podataka u dužem periodu (batch) koje po prirodi rade na potpuno različite načine. Mi takve aplikacije nazivamo Continuous Applications.


Continuous Applications je relativno mlad pojam. Konkretno se misli na sustav koji u realnom vremenu obrađuje velike količine podataka.


Lambda arhitektura kao prvo rješenje problema>

Dakle, svi se slažemo da ukoliko želimo informaciju imati ODMAH kada se neki događaj dogodi, to nameće integraciju analitike i evenata koji se događaju u stvarnom vremenu. U svijetu big data tehnologija mnoge tehnologije za streaming djelomično su pokušale ubaciti funkcionalnosti batcha i obrnuto, ali takve tehnologije ne zadovoljavaju enterprise potrebe jer se zahtijeva puna podrška batch obrada kao i puna podrška streaming obrada. Enterprise rješenja taj su problem riješila Lambda arhitekturom.


Lambda arhitektura razvijena je kako bi omogućila dizajn data-processing okruženja za obradu velike količine podataka u stvarnom vremenu.


Osnovna je ideja Lambda ahitekture imati nezavisni Batch layer s tehnologijom koja najviše odgovora batch procesingu, npr. Hadoop, Spark i dr., dok bi Speed Layer omogućio rad s tehnologijom koja najviše odgovara streaming procesu (CEP, event procesing, micro-batch i dr.) kao što su IBM Streams, Apache Storm, Apache Flink, Apache Spark Streaming i dr. Da bismo mogli koristiti prednost oba layera, moramo osigurati Serving Layer koji obuhvaća rezultate batch (Batch view) i stream procesiranja (Real-time view). Kao što vidimo, ovdje se spajaju podaci iz oba svijeta.

Glasni kritičari Lambda arhitekture u pravu su kada kažu da je takvu arhitekturu izrazito teško izgraditi i održavati. Evo primjera: zamislite da imate komplicirani JOIN između dva layera ili npr. da u aplikaciju morate ugraditi neke funkcionalnosti prediktivne analize ili strojnog učenja. Uočavate li ključan problem? Takve funkcionalnosti često morate implementirati na oba layera i bitno zakomplicirati tzv. Serving Layer, u kojem morate definirati kada koji od layera konzumirati. Dakle, Lambda arhitektura nasljeđuje kompleksnost pojedinih layera i limitira korištenje istog. Isti kod morate razvijati i održavati barem dvaput i kontinuirano sinkronizirati promjene. Da ne govorimo kako su naša dva ključna layera pisana različitim programskim jezicima. 😮 Također, većina alata je open source i s vremenom se adaptiraju na ključne probleme, što opet nameće kontinuirani reinženjering, refractoring koda i sl. Možda se u ovom trenutku pitate zašto pišemo, naglašavamo i reklamiramo kompleksnost takvog sustava. Kao prvo, želim vam prenijeti poruku da takav proces nikako nije trivijalan koliko god jednostavno izgledao prilikom čitanja prvih paragrafa. Želimo reći da postoji rješenje koje možda ne rješava apsolutno sve probleme, ali možemo garantirati da su u ovom trenu dostupni dobri temelji koji mogu bitno smanjiti kompleksnost, tj. imati sustav koji doslovce može biti dostupan svakome. Trebam li spomenuti da je tehnologija free? 🙂

Apache Spark kao temelj za end-to-end real-time aplikacije

Korištenjem Apache Spark druge generacije in-memory MPP (massively parallel processing) platforme možemo bitno smanjiti ovaj nesrazmjer tehnologija i procesa jer osigurava jedinstveno programsko sučelje za razvoj Continuous Applications sustava. Dakle, ne moramo imati dva neovisna sustava koji nisu svjesni jedan drugoga, kao što smo opisali u prethodnom paragrafu. Ne treba nam kompleksna Lambda arhitektura.

Apache Spark korištenjem Structured Streaming API-a može izraditi gore spomenute batch, speed i serving layere koristeći jedan jedini API. Osnovna ideja Structured Streaminga nije ništa drugo nego stream shvatiti kako jednu običnu virtualnu tabelu. Tko se sjeća WITH “tabela” u SQL-u? 🙂 Apache Spark sa Structured Streaming API-em omogućuje nam funkcionalnosti koje trenutačno niti jedan API za Continous Application ne podržava, a to su:

  1. Garantira konzistentnost s batch jobom i omogućuje automatsko inkrementalno računanje u streamu
  2. Transakcijsko svojstvo sa sustavima pohrane.
  3. Ovaj API usko je vezan s ostalim funkcionalnim API-ima unutar Sparka.

Ultimativni cilj Apache Sparka je kreirati jedan jedinstveni API za Continuous Applications.

                                                                                                         Matei Zaharia, glavni autor Sparka


“Continuous application means: Not just streaming anymore!”

Prevencija frauda je idealan slučaj za našeg novog ljubimca (Spark 2.x) jer ujedinjuje batch i streaming, pri tome ne narušavajući konzistenciju podataka, jer ako podatak nije konzistentan, Spark će inicirati pogrešku u runtimeu. Divno! Spomenuti sustav za prevenciju frauda može se samostalno unaprijediti korištenjem jobova za strojno učenje (ML pipeline, MLib). Možete li zamislite sustav koji sam može naučiti što je to fraud? 🙂 … a da pri tome sve to kontrolirate kroz jednu jedinu aplikaciju/sustav (standalone + streaming) na brz i interaktivan način. Na prvu, može vam izgledati nemoguće, ali ako uzmete u obzir da imate alate i tehnologije nove generacije koji su dizajnirani i razvijeni da rješavaju takav tip izazova, više to ne djeluje tako nemoguće. Probajte, izazovite i iznenadite se. 🙂

Treba uzeti u obzir da je jedna od bitnih primjena Sparka razvoj Continuous Applications sustava kao što su npr. recommended apps ili spomenuti sustavi za fraud detection. Ovo nisu jedini primjeri sustava gdje je fokus na procesiranju svih podataka (big data) i potreba za oplemenjivanjem podataka koji utječu na procese u realnom vremenu. U realnom okruženju imamo bezbroj primjera (ne stane u ovaj članak): od pametnog i interaktivnog grada ili države, nadzor prometa, optimizacija logstike, nadzor kriminalnih radnji ili u financijskim institucijama credit scoring, customer intelligence (call log, sentiment analiza, socijalne mreže…). Sve su to realni primjeri nad kojima možemo primijeniti Continuous Application. Do sada su se takve stvari rješavale kroz tzv. Lambda arhitekturu što je bilo izrazito kompleksno i teško za razviti, a još teže održavati i deployati. Nakon što se pojavio Spark druge generacije možemo konstatirati da je Lambda arhitektura samo hack Sparka druge generacije ili neki most dok ne dođe pouzdana i stabilna tehnologija 🙂 Jesam li spomenuo da je Spark Open Source? 🙂

Mi u CROZ-u aktivno pratimo i pilotiramo Spark na mnogim poslovnim slučajevima. Pilotirali smo nekoliko aplikacija gdje smo višesatne obrade za DWH smanjili na nekoliko sekundi nad 700 milijuna zapisa. Doslovce mjesečne DWH/BI obrade zamijenjene su aplikacijama koje rade interaktivno u nekoliko sekundi. Počeli smo tako davne 2014. i imamo pozitivna iskustva. Slobodno nas pozovite na kavu i ćakulu ako se vidite u ovoj lijepoj priči. Rado ćemo vam pokazati, pilotirati ili vas educirati na ovoj tehnologiji u našem edukacijskom centru.

Fraud Detection u bližoj budućnosti!

Fraud Detection sustavi nove generacije automatski će se prilagoditi situacijama i mogućim novim prevarama, tj. sami će zaključivati što je to fraud ili potencijalni fraud. Algoritmi i funkcionalnosti strojnog učenja (machine learning) sazrijevaju. Kognitivni algoritmi postoje i rade u produkciji (Koje se godine ono pojavio Watson koji je pobijedio u kvizu?). 2011. Da, vrlo vjerojatno će nas u bližoj budućnosti napustiti sustavi za Fraud Detection koji rade na principima rule engine sustava. Kako bi to izgledalo, najbolje pokazuje sljedeća slika, koja kaže da ćemo metode i model strojnog učenja imati implementirane na historijskim podacima jednako kao i na živim podacima. Pri tome će se modeli kontinuirano trenirati kako bi se prilagodili novim situacijama i anomalijama, i to uživo. Dakle, fraud sustav nove generacije u budućnosti će zbilja učiti sam sebe na temelju novih prevara koje ljudsko oko i ljudski mozak ne mogu tako brzo interpretirati. Kada ćemo se smijati starim ručno unesenim rulovima, čudno načinjenim kartezijevim produktima na serving layeru i analitici na bazi jednog tjedna, to vam, nažalost, ipak ne mogu reći. Ali s nestrpljenjem čekam taj trenutak.

Zašto je u Apache Spark developerima budućnost već stigla? Ili Continuous Application is ON AIR

Spark je jedan od prvih unificiranih engina za procesiranje podataka u klasteriranom i distribuiranom sustavu koji integrira funkcionalne API-e. Spark će na tim temeljima graditi nova API sučelja. U tvornici Sparka dosta se radi na streamingu (Engine Latnacy ) i strojnom učenju (Machine Learning) kako bi osigurali 24/7 operativne procese prilikom izgradnje Continuous Applications sustava. Definitivno nas u Sparku čeka svijetla budućnost, kako je najavio tvorac Sparka Matei Zaharia i ostvarivanje ultimativnog cilja, a to je stvoriti jedan API za razvoj Continuous Application sustava. Sparkov Structured Streaming API vani je već nekoliko mjeseci (Apache Spark 2.0.), što znači da ga development zajednica itekako aktivno pilotira. U zadnjoj distribuciji (Apache spark 2.1.) Structural streaming API spreman je za produkcijska okruženja te je dograđen funkcionalnostima kao što su: izvršavanje paralelnih upita nad streamom: Multiple aggregation, Sessionization, watermarks, late date te integracija osnovnih funkcionalnosti strojnog učenja kao i mnoge druge funkcionalnosti. U budućnosti možemo od Sparka očekivati samo još više “computation semantics” funkcionalnosti. Pratimo, pilotiramo i željno iščekujemo vidjeti prve implementacije u produkciji. Pridružite nam se.

Tagovi:
Povratak