Lakehouse

Lakehouse je savremena arhitektura podataka koja pokušava da spoji dve velike ideje: fleksibilnost Data Lake sistema i pouzdanost Data Warehouse pristupa. U najjednostavnijem smislu, Lakehouse je okruženje u kome možemo čuvati velike količine različitih podataka, ali ih istovremeno koristiti za izveštavanje, analitiku, SQL upite, mašinsko učenje, kontrolu kvaliteta i poslovno odlučivanje.

Da bismo razumeli zašto je Lakehouse nastao, korisno je najpre razumeti ograničenja ranijih pristupa. Data Warehouse je odličan za uređene, modelovane i poslovno proverene podatke. On je pouzdan, stabilan i pogodan za izveštaje, KPI pokazatelje i poslovnu analitiku. Međutim, često je skuplji, strože strukturisan i manje pogodan za čuvanje sirovih, polustrukturisanih i nestrukturisanih podataka.

Data Lake je, sa druge strane, nastao kao fleksibilno skladište za velike količine sirovih podataka. U njega se mogu smestiti fajlovi, logovi, slike, JSON dokumenti, CSV podaci, senzorski zapisi, podaci iz aplikacija, API servisa i različitih sistema. Data Lake je veoma koristan za istraživanje, data science i čuvanje podataka u izvornom obliku, ali bez jasnih pravila može lako postati neuređeno jezero podataka u kome se teško pronalazi ono što je zaista važno.

Lakehouse pokušava da pomiri ta dva sveta. On želi da zadrži otvorenost i skalabilnost Data Lake sistema, ali da uvede pouzdanost, organizaciju, transakcije, verzionisanje, kvalitet podataka i analitičku upotrebljivost koja se tradicionalno vezuje za Data Warehouse. Zato se često kaže da Lakehouse predstavlja most između sirovog skladištenja podataka i uređenog poslovnog znanja.

Osnova Lakehouse arhitekture najčešće je objektno skladištenje, odnosno object storage. To je način čuvanja podataka koji je pogodan za velike količine fajlova i distribuirane sisteme. Umesto da podatke posmatramo samo kao tabele u klasičnoj bazi, u Lakehouse arhitekturi često radimo sa fajlovima koji su organizovani u foldere, particije, skupove podataka i tabele opisane metadata slojem.

Važnu ulogu imaju otvoreni formati podataka. Formati kao što su Parquet i ORC omogućavaju efikasno kolonsko skladištenje, što znači da se podaci čuvaju tako da analitički upiti mogu brzo da čitaju samo potrebne kolone. To je posebno važno kada radimo sa velikim skupovima podataka, jer nije praktično svaki put učitavati sve podatke ako nas zanima samo nekoliko atributa.

Međutim, sami fajlovi nisu dovoljni. Da bi Lakehouse bio pouzdan analitički sistem, potreban je metadata sloj. Metadata opisuje gde se podaci nalaze, koje kolone postoje, kakav je njihov tip, kako su podaci particionisani, koje verzije postoje i kako se promenama upravlja. Bez metadata sloja, imali bismo samo mnogo fajlova. Sa metadata slojem, ti fajlovi postaju smisleno organizovane analitičke tabele.

Posebno važan deo Lakehouse sveta čine savremeni table formati, kao što su Delta Lake, Apache Iceberg i Apache Hudi. Njihova uloga je da nad fajlovima i objektim skladištenjem omoguće ponašanje slično tabelama u ozbiljnim analitičkim sistemima. Oni uvode transakcije, praćenje promena, verzionisanje, podršku za upis i izmenu podataka, optimizaciju i mogućnost da se podaci koriste pouzdanije nego u običnom folderu sa fajlovima.

Jedna od najvažnijih osobina Lakehouse sistema jesu ACID transakcije. ACID označava skup principa koji pomažu da se podaci menjaju pouzdano i dosledno. U praksi to znači da se smanjuje rizik od delimično upisanih, oštećenih ili međusobno neusaglašenih podataka. To je veoma važno kada više procesa istovremeno čita i upisuje podatke ili kada se velike količine podataka redovno osvežavaju.

Lakehouse često omogućava i time travel, odnosno povratak na prethodna stanja podataka. To znači da analitičar ili inženjer podataka može da vidi kako je tabela izgledala u ranijem trenutku, da proveri promene, pronađe grešku ili ponovi analizu nad istom verzijom podataka. Takva mogućnost je korisna za audit, reproduktivnost analiza, kontrolu kvaliteta i sigurniji razvoj data pipeline procesa.

U ovom tutorijalu govorićemo i o ingestiji podataka. Ingestija je proces ulaska podataka u sistem. Podaci mogu dolaziti periodično, kroz batch obradu, ili neprekidno, kroz streaming obradu. Batch pristup je pogodan kada se podaci učitavaju jednom dnevno, jednom na sat ili u drugom periodičnom ritmu. Streaming je važan kada podaci stalno pristižu, kao kod logova, događaja, senzora, aplikacija ili korisničkih aktivnosti.

Jedan od praktičnih modela organizacije podataka u Lakehouse arhitekturi jeste podela na Bronze, Silver i Gold slojeve. Bronze sloj najčešće čuva sirove ili skoro sirove podatke, onako kako su stigli iz izvora. Silver sloj sadrži očišćene, standardizovane i povezane podatke. Gold sloj sadrži poslovno spremne podatke, agregacije, KPI pokazatelje, data mart poglede i skupove koji su spremni za izveštavanje i odlučivanje.

Ova podela je veoma korisna za početnike, jer pokazuje da podaci ne postaju odmah savršeni. Oni prolaze put. Najpre ih primamo, zatim razumemo, čistimo, proveravamo, povezujemo, obogaćujemo i tek onda koristimo za ozbiljne poslovne uvide. Lakehouse nam daje arhitekturu u kojoj taj put može biti jasno organizovan i ponovljiv.

Lakehouse nije važan samo za tehničke timove. On je važan i za poslovne korisnike, jer omogućava da se nad velikim skupovima podataka koriste poznati alati i poznati jezici, naročito SQL. Analitičari mogu da pišu upite, prave izveštaje, povezuju BI alate, grade dashboarde i prate KPI pokazatelje, dok se u pozadini podaci čuvaju u otvorenom i skalabilnom skladištu.

U drugom delu praktikuma posvetićemo pažnju data catalog sistemima. Data Catalog pomaže korisnicima da pronađu podatke, razumeju šta znače, ko je za njih odgovoran, odakle dolaze i kako se koriste. U velikim organizacijama nije dovoljno da podaci postoje. Ljudi moraju znati gde su, šta predstavljaju, koliko su pouzdani i da li smeju da ih koriste.

Data lineage je još jedna važna tema. Lineage pokazuje poreklo podataka i put kojim su prošli od izvora do konačnog izveštaja, tabele ili modela. Kada korisnik vidi neki broj na dashboardu, važno je da se može proveriti iz kog izvora je došao, kroz koje transformacije je prošao i koja poslovna pravila su primenjena. Bez toga je teško graditi poverenje u analitiku.

Kvalitet podataka u Lakehouse sistemu mora biti jasno kontrolisan. Velika količina podataka sama po sebi ne znači veliku vrednost. Ako su podaci duplirani, nepotpuni, netačni, zastareli ili loše povezani, rezultati mogu biti pogrešni. Zato ćemo govoriti o proverama, pravilima, validaciji, standardizaciji i načinu na koji se poverenje u podatke gradi kroz proces, a ne kroz pretpostavku.

Data governance je neophodan zato što Lakehouse često čuva različite vrste podataka: poslovne, tehničke, korisničke, finansijske, operativne i istraživačke. Mora se znati ko sme da vidi koje podatke, ko sme da ih menja, ko je odgovoran za njihovo značenje i kako se prati njihova upotreba. Dobra arhitektura podataka nije samo brza i velika, već i odgovorna, kontrolisana i razumljiva.

Posebno mesto u Lakehouse arhitekturi ima mašinsko učenje. Data science timovima su potrebni veliki, raznovrsni i često sirovi podaci, ali su im istovremeno potrebni kvalitet, praćenje verzija, ponovljivost eksperimenata i stabilan pristup podacima. Lakehouse može da poveže svet analitike i svet mašinskog učenja, jer omogućava da isti podaci budu dostupni za SQL upite, izveštaje, feature engineering i treniranje modela.

Upoznaćemo i pojam Feature Store. Feature Store je organizovan prostor u kome se čuvaju osobine, odnosno pripremljene promenljive koje se koriste u modelima mašinskog učenja. Umesto da svaki tim iznova računa iste osobine, one se mogu pripremiti, proveriti, dokumentovati i ponovo koristiti. To pomaže da modeli budu dosledniji, a razvoj brži i pouzdaniji.

U završnom delu praktikuma radićemo praktične primere i mini projekte. Krenućemo od primera prodaje, logova i korisničkog ponašanja. Pokazaćemo kako se podaci mogu organizovati kroz Bronze, Silver i Gold slojeve, kako se pripremaju za analitiku, kako se povezuju sa dashboardima i kako mogu postati osnova za mašinsko učenje. Cilj je da Lakehouse ne ostane apstraktna arhitektura, već razumljiv radni model.

Cilj ovog tutorijala nije samo da zapamtimo definiciju Lakehouse arhitekture. Cilj je da razumemo zašto se savremeni svet podataka kreće ka arhitekturama koje su otvorene, skalabilne, proverljive i korisne za više namena. Lakehouse povezuje skladištenje, obradu, analitiku, upravljanje i mašinsko učenje u jednu širu podatkovnu platformu. Kada je dobro osmišljen, on ne čuva samo podatke, već gradi put od sirovog zapisa do pouzdanog znanja.