Izrada reporting baze često može predstavljati izazov (veći ili manji, ovisno o poslovnim zahtjevima). Iako se na tržištu mogu naći gotova ili polu-gotova rješenja za prikupljanje evenata te obradu i transformaciju podataka, uvid u korisničku aktivnost u stvarnom vremenu predstavlja ne-trivijalan problem. Iako izmjena postojećih podataka može predstavljati problem u data warehousing sustavima (npr. slowly changing dimensions problem), često generiranje novih dimenzijskih podataka također stvara poteškoće prilikom pretvaranja evenata u „opipljive“ podatke.
Razmotrimo sljedeći slučaj: Korisnik može kreirati korisnički račun te odmah potom pristupati našem sustavu, stvarati nove profile vezane uz svoj račun i priključivati se korisničkim grupama. Svi ti podaci bi trebali biti dostupni i u referentom setu podataka za lookup i kao dimenzije u reporting bazi, no postoji određen vremenski odmak između kreiranja podataka u produkcijskoj bazi i vidljivosti istih u referentnom setu i reporting bazi. U pesimističnom scenariju, prvih nekoliko minuta (ili sati, ovisno o učestalosti sinkroniziranja ta dva sustava) korisničke aktivnosti ne može biti povezano s korisnikom, što značajno smanjuje analitičku vrijednost tih podataka.
Emitiranje eventa
Neovisno o tome implementiramo li reporting sustav u postojeće rješenje ili očekujemo izmjene u količini i vrsti prikupljenih podataka, event-driven arhitektura pruža dobar način za raspregnuti reporting sustav od postojećih aplikacija. Azure nudi dva rješenja za prikupljanje i obradu evenata – Azure Event Hubs i Azure Event Grid. Oba pristupa pružaju dobru skalabilnost, obradu evenata u stvarnom vremenu te at-least-once garanciju isporuke evenata. Azure Event Hubs dolazi uz skladištenje evenata u trajnoj pohrani i particioniranje pomoću kojeg možemo slijedno obrađivati evente te izbjeći potencijalne probleme vezane uz paralelnu obradu. Iako Event Grid može publisheru dati povratnu informaciju o primitku eventa, Azure Event Hubs predstavlja bolji izbor za reporting.
Kako proizvodi često uključuju nekoliko klijentskih aplikacija (na nekoliko različitih platformi), možemo razmotriti dva pristupa emitiranju evenata. Kod centraliziranog pristupa sve klijentske aplikacije šalju podatke o eventu na API, koji ih potom prosljeđuje u Azure Event Hubs. Ovakav pristup više opterećuje API i onemogućuje neovisno skaliranje reporting pipelinea, te također podrazumijeva slanje dva zahtjeva za jedan event (jednom s klijenta na API i jednom s API-ja na Azure Event Hubs). Decentralizirani pristup pak zahtijeva implementaciju (i održavanje) event publishera na svakoj od klijentskih aplikacija, a i postavlja se pitanje želimo li recimo analitičke podatke o korisničkoj aktivnosti ako API nije u mogućnosti obraditi korisničke zahtjeve.
Prikupljanje evenata
Kako bi podaci primljeni u eventu postali relevantni za reporting, valja ih obogatiti kontekstualnim podacima: tko je uzrokovao event? Kada? Kako i zašto? Što znamo o tom korisniku? Ovo u praksi znači obogaćivanje podataka primljenih u eventu kroz upit(e) na referentnom setu podataka. Kako bi reporting bio neovisan o postojećim aplikacijama, to se odrađuje kroz reporting pipeline.
Azure Stream Analytics
Azure Stream Analytics ima nativnu integraciju s Azure Event Hubs (i Azure IoT Hub/Azure Blob Storage) te dolazi s ugrađenim funkcionalnostima za agregaciju i analizu podataka poput tzv. windowed funkcija koje podatke mogu agregirati na razini vremenskog perioda ili, primjerice, sesije korisnika. Rezultat obrade može se zapisati u sustav za pohranu podataka po izboru (CosmosDB, Data Lake, Table/Blob storage), ali i proslijediti na drugu instancu Event Hubsa, Azure Funkcija ili izravno na Power BI (iako uz limit do 200 000 redaka). Lookup nad referentnim setom podataka je podržan; Azure Blob Storage ili Azure SQL Database (Azure- ili self-managed) mogu služiti kao izvori podataka. Kako bi se postigle bolje performanse, lookup koristi snimku stanja baze (snapshot) koju drži u memoriji.
Kako bi se dobila slika o kontekstu u kojem se event dogodio, nužno je izvući povezane podatke iz referentnog seta. Razmotrimo primjer gdje je event emitiran nakon što je korisnik prihvatio uvjete korištenja aplikacije, i taj event želimo korelirati s imenom i prezimenom korisnika te državom u kojom se nalazi. Ako se korisnik tek registrirao prije 10 sekundi, njegovi podaci nisu vidljivi u snimci stanja baze i Azure Stream Analytics ne može ispravno kontekstualizirati event. Problemu se može pokušati pristupiti češćim osvježavanjem snimke stanja, no Azure Stream Analytics ne podržava češće osvježavanje od jednom u minuti, a i potpuna sinkronizacija postaje vrlo spora porastom količine referentnih podataka. Diferencijalna sinkronizacija može poslužiti kao djelomično rješenje, no treba imati na umu da se snimka stanja baze drži u memoriji, te kod velikih referentih setova resursima koji pogone Azure Stream Analyticsu ne ostane dovoljno radne memorije za uspješno procesuirati event.
Azure Data Factory
Azure Data Factory nema izravnu integraciju s Event Hubsom, ali podržava storage-based okidač. U kombinaciji s Event Hubs Captureom, pipeline se može izvršiti nakon što Event Hubs zaprimi event te ga zapiše u trajnu pohranu (npr. Azure Data Lake Gen2).
Za razliku od Azure Stream Analyticsa, Azure Data Factory vrši upite izravno nad referentnim podacima. Ukoliko to predstavlja preveliko opterećenje za produkcijsku bazu, kao izvor se može koristiti read-only replika baze ili snimka stanja uz bazu kao sekundarnu opciju ako podaci nisu u snimci stanja. Azure Data Factory funkcionalnosti poput lookup, join, i transformation operacija omogućuju brzo i lako codeless obogaćivanje eventa relevantnim podacima te pretvaranje istih u format prilagođen reportingu. Spomenuti problem dohvaćanja punog imena i države korisnika bi se mogao riješiti ovakvim Azure Data Factory pipelineom:
Iako ovaj pristup rješava problem, je li on uistinu ispravan? Azure Data Factory kao servis namijenjen je dohvaćanju i procesiranju velikih količina podataka. Loše strane korištenja event-triggered Azure Data Factory pipelinea su:
- Izvršavanje pipelinea se naplaćuje
- Eventi se moraju zapisivati u trajnu pohranu (što podrazumijeva plaćanje te održavanje iste)
- Azure Data Factory pipeline se, ovisno o opterećenju sustava, ne izvršava odmah, što će rezultirati kaskanjem stanja u reporting bazi u odnosu na stvarno stanje.
Brzom računicom može se pokazati da cijena izvršavanja pipelinea vrlo brzo postaje prohibitivno skupa porastom broja evenata. Usporedimo cijenu izvršavanja pipelinea s alternativnim serverless rješenjima poput Azure Functions (kako se u oba slučaja naplaćuje prijenos podataka te komputacijsko vrijeme, razmotrimo samo cijenu izvršavanja):
U hipotetskom scenariju gdje dnevno obrađujemo milijun evenata te obrada u prosjeku traje 0,5 sekundi, mjesečna cijena za Azure funkcije bila bi približno 120 €. Kod ADF pipelinea, takvu cijenu možemo postići ako agregiramo evente te ih grupno obrađujemo svake minute. No, takvim pristupom udaljavamo se od event-driven arhitekture te uvodimo jednominutno zaostajanje reporting baze za stvarnim stanjem.
Transformacija podataka
Shema podataka u reporting bazi se obično razlikuje od produkcijskih, što predstavlja vrlo interesantan problem. Čak i ako smo tijekom procesiranja eventa prikupili sve relevantne podatke, moguće je da pripadni podaci ne postoje u reporting bazi. Ako uzmemo star schemu kao primjer, pripadni zapis za korisnika u UsersDimension dimenzijskoj tablici možda postoji, a možda i ne:
Azure Stream Analytics nema način za nositi se s ovakvim situacijama, dok bi Azure Data Factory pipeline mogao provjeriti postoji li zapis u dimenzijskoj tablici, i ako ne upisati ga na licu mjesta koristeći produkcijsku bazu kao izvor. Kako broj dimenzija raste, pipeline postaje sve kompleksniji i teži za održavanje usprkos tome što je codeless.
Azure funkcije
Korištenjem Azure Stream Analyticsa ne možemo osigurati da su relevantni unosi prisutni u dimenzijskim tablicama u trenutku obrade eventa. Azure Data Factory pristup zahtijeva Event Hubs Capture te podrazumijeva napuštanje event-driven arhitekture.
Korištenjem Azure funkcija s event okidačem možemo se maksimalno približiti obradi evenata u stvarnom vremenu. Pisanjem koda prilagođenog našem sustavu, možemo osigurati da se redci koji nedostaju u dimenzijskim tablicama upišu na licu mjesta, dok pravilnim korištenjem particijskog ključa možemo izbjeći dvostruko ubacivanje istog retka uslijed paralelne obrade evenata.
Razvoj vlastitog rješenja inicijalno zahtijeva više truda, no zato nudi niz prednosti:
- Kontrola nad grupiranjem evenata i paralelizacijom (Event Hubs particije, grupiranje evenata na klijentskoj strani, grupiranje i paralelna obrada unutar Azure funkcije)
- Potpuno prilagodljiv pristup ponovnom pokušaju obrade (ukoliko standardno Azure Event Hubs rješenje ne odgovara našim zahtjevima).
Loše strane ovakvog pristupa uključuju manjak windowing funkcija, no agregiranje evenata kroz određeni vremenski period moguće je implementirati spremanjem u neki oblik trajne pohrane – CosmosDB ili Azure Blob Storage, ovisno o tehničkim zahtjevima. Time se olakšava i ponovno procesiranje u slučaju pogrešaka, nedostupnosti reporting baze itd., jer su podaci iz eventa već dijelom obrađeni prije pohrane.
Svaki od predloženih pristupa dobro je rješenje za određeni scenarij
Ukoliko se referentni set podataka ne mijenja često, ili platforma sadrži nekakvu vremensku odgodu (poput ručnog odobravanja zahtjeva), Azure Stream Analytics pruža gotove implementacije niza analitičkih funkcija te brzo i jednostavno uspostavljanje sustava za obradu evenata. Azure Data Factory brzo i učinkovito obrađuje velike količine podataka, i ukoliko dobivanje informacija u stvarnom vremenu nije uvjet, agregiranje te procesiranje evenata koristeći Azure Data Factory pipeline je učinkovito i jeftino. Pipeline može primjeniti i kod jednokratnih ili planiranih aktivnosti, poput inicijalnog populiranja dimenzijskih tablica ili dnevne sinkronizacije među produkcijskom i reporting bazom. Ako za cilj postavimo uvid u dinamičan sustav u stvarnom vremenu, fleksibilnost koju pružaju Azure funkcije je naprosto nezamjenjiva.
- Event-Driven Reporting i Azure – kada DIY nije DI-why? - 01.12.2021.