Kai pradedi domėtis duomenų architektūra, anksčiau ar vėliau užkliūni už dviejų terminų, kurie iš pirmo žvilgsnio atrodo panašūs, bet praktikoje reiškia visiškai skirtingus dalykus. Duomenų ežeras (data lake) ir duomenų sandėlis (data warehouse) – abu skirti duomenims saugoti ir analizuoti, tačiau filosofija, dėl kurios jie egzistuoja, yra diametraliai priešinga. Ir būtent čia dažniausiai kyla painiava – tiek tarp verslo žmonių, tiek tarp jaunesnių inžinierių, kurie tik pradeda dirbti su duomenų platformomis.
Straipsnyje pabandysiu paaiškinti, kuo šie du sprendimai skiriasi, kada vienas ar kitas turi prasmę, ir kodėl paskutiniu metu vis dažniau girdime terminą „lakehouse”, kuris bando sujungti abiejų pasaulių privalumus.
Kas per skirtumas iš tikrųjų
Paprasčiausias būdas paaiškinti skirtumą – įsivaizduokite sandėlį ir garažą. Sandėlyje viskas sudėta į lentynas, sunumeruota, pažymėta etiketėmis. Rasite bet ką per kelias sekundes, nes žinote tikslią vietą. Garaže gi viskas sumesta, kaip pavyko – dviratis šalia senų baldų, dėžė su kabeliais po suoliuku. Rasti ką nors ten galima, bet reikia paieškoti, arba tiesiog žinoti, kur ieškoti pagal patirtį.
Duomenų sandėlis veikia pagal schema-on-write principą – prieš įkeliant duomenis, jau turi būti aiškiai apibrėžta struktūra: lentelės, stulpeliai, tipai, ryšiai. Duomenų ežeras veikia priešingai – schema-on-read. Duomenys sumetami tokie, kokie yra – JSON failai, CSV eksportai, vaizdo įrašai, log’ai, senzorų duomenys – o struktūra apibrėžiama tik tada, kai kažkas nori tuos duomenis panaudoti.
Ši skirtumas atrodo techninis, bet iš tikrųjų jis nulemia visą darbo su duomenimis kultūrą organizacijoje. Sandėlis reikalauja disciplinos iš anksto. Ežeras suteikia laisvę, bet ta laisvė turi kainą – jei niekas nesitvarko su chaosu, po metų ežeras tampa tuo, ką inžinieriai vadina „duomenų pelke” (data swamp).
Duomenų sandėliai – kai viskas turi savo vietą
Klasikinis duomenų sandėlis buvo ir tebėra populiarus dėl vienos priežasties – jis atsakinėja į klausimus greitai ir patikimai. Jei finansų skyriui reikia mėnesio pajamų suvestinės, ta suvestinė bus paruošta per kelias sekundes, nes duomenys jau sutvarkyti, agreguoti, patikrinti dėl kokybės.
Sandėliai remiasi ETL procesu – Extract, Transform, Load. Duomenys ištraukiami iš šaltinio, transformuojami (valomi, normalizuojami, sujungiami), ir tik tada įkeliami į galutinę saugyklą. Tai reiškia, kad kol duomenys pasiekia sandėlį, jie jau praeina nemažai apdorojimo žingsnių.
Tipiniai atstovai šioje kategorijoje – Snowflake, Amazon Redshift, Google BigQuery (nors pastarasis turi ir ežero bruožų), Microsoft Synapse. Šie sprendimai optimizuoti struktūrizuotiems duomenims ir SQL užklausoms. Jie puikiai tinka BI ataskaitoms, dashboard’ams, reguliariai vykdomiems verslo analitikos procesams.
Minusas – lankstumo trūkumas. Jei norite saugoti nestruktūrizuotus duomenis, pavyzdžiui, vartotojų elgesio įrašus programėlėje arba IoT senzorių srautus, sandėlis tam netinka arba tinka labai ribotai. Be to, ETL procesai reikalauja iš anksto žinoti, ko jums reikės – jei po metų prireiks duomenų, kurie ETL etape buvo atmesti kaip „nereikalingi”, jų tiesiog nebeliks.
Ežerai – kai metama viskas į vieną krūvą
Duomenų ežero idėja gimė iš poreikio saugoti viską, ką tik įmanoma, nesirūpinant iš anksto, kam tai bus naudinga. Big data era atnešė duomenų kiekius ir formatus, kurių tradiciniai sandėliai tiesiog nepajėgė apdoroti – vaizdo, garso, teksto, senzorių duomenis, socialinių tinklų srautus.
Technologiškai ežerai dažniausiai statomi ant objektų saugyklų – Amazon S3, Azure Data Lake Storage, Google Cloud Storage. Duomenys saugomi failų formatu (Parquet, ORC, Avro, arba tiesiog žalias JSON/CSV), o struktūra pridedama tik analizės metu, naudojant įrankius kaip Apache Spark, Presto/Trino ar Databricks.
Čia naudojamas ELT, o ne ETL – duomenys pirma įkeliami (Load), o transformacija (Transform) vyksta vėliau, prireikus. Tai suteikia milžinišką lankstumą – galite saugoti duomenis, kurių panaudojimo atveju šiuo metu net nežinote, o po metų, kai atsiras naujas mokymosi modelis ar analizės metodas, tie žali duomenys vis dar bus prieinami.
Bet čia slypi ir didžiausia rizika. Be aiškaus valdymo (data governance), ežeras greitai virsta tuo, ką jau minėjau – pelke. Niekas nebežino, kokie duomenys kur guli, kokia jų kokybė, ar jie apskritai teisingi. Mačiau ne vieną projektą, kur ežeras buvo pripildytas per porą metų, bet realiai naudojama buvo gal 10% viso turinio, nes likusi dalis tiesiog buvo nebeaišku, ką reiškia.
Lakehouse – bandymas suvienyti abu pasaulius
Pastaraisiais metais rinkoje įsitvirtino trečia sąvoka – lakehouse. Idėja paprasta: paimti ežero lankstumą (pigus saugojimas, bet kokie duomenų tipai) ir pridėti sandėlio patikimumą (transakcijos, schemos valdymas, duomenų kokybės garantijos).
Technologiškai tai realizuojama per formatus kaip Delta Lake, Apache Iceberg ar Apache Hudi, kurie prideda metaduomenų sluoksnį virš paprastų failų. Šis sluoksnis suteikia ACID transakcijas, versijų valdymą, galimybę atlikti UPDATE ir DELETE operacijas tiesiogiai ežere – dalykus, kurie anksčiau buvo tik sandėlių privilegija.
Databricks yra bene ryškiausias šios koncepcijos populiarintojas, tačiau panašias galimybes dabar siūlo ir Snowflake (per Iceberg palaikymą), ir AWS su savo Lake Formation sprendimais. Tai reiškia, kad riba tarp „ežero” ir „sandėlio” darosi vis labiau miglota – kartais tas pats fizinis saugojimas gali tarnauti abiem tikslams vienu metu.
Asmeniškai manau, kad lakehouse architektūra artimiausiu metu taps standartu daugumai naujų projektų, nes ji leidžia nedelsiant priimti sprendimą – naudoti struktūrą ar ne – vėliau, o ne visiškai iš anksto.
Kada rinktis ką – praktinis požiūris
Teorija teorija, bet realiame projekte sprendimas priimamas atsižvelgiant į konkrečius poreikius. Štai keli orientyrai, kuriais pats vadovaujuosi rekomenduodamas architektūrą klientams:
- Jei jums reikia stabilių, pasikartojančių ataskaitų finansų, pardavimų ar operacijų komandoms – sandėlis bus greitesnis ir pigesnis eksploatuoti ilgalaikėje perspektyvoje, nes SQL variklis optimizuotas būtent tokiems atvejams.
- Jei dirbate su mašininio mokymosi modeliais, kur reikia žalių, nesuformatuotų duomenų dideliais kiekiais – ežeras arba lakehouse yra vienintelė racionali alternatyva.
- Jei turite mažą komandą ir ribotus resursus valdymui – sandėlis yra saugesnis pasirinkimas, nes jis natūraliai priverčia laikytis tvarkos. Ežeras be griežto valdymo virsta chaosu greičiau, nei tikitės.
- Jei duomenų šaltiniai labai įvairūs – nuo API iki senzorių, nuo PDF failų iki video – tik ežero tipo architektūra sugebės visa tai priimti be didelių iš anksto atliekamų investicijų.
- Jei biudžetas ribotas, bet duomenų kiekiai auga eksponentiškai – objektų saugyklos kaina (S3, GCS) yra kelis kartus mažesnė nei brangaus sandėlio saugojimo kaina, tad ežeras čia laimi ekonomiškai.
Realybėje dauguma vidutinio dydžio organizacijų šiandien turi abu sprendimus vienu metu – ežeras kaip žalia duomenų talpykla, ir sandėlis (arba lakehouse sluoksnis virš ežero) analitikai ir ataskaitoms. Tai vadinama medaljonų architektūra (medallion architecture) – bronze, silver, gold sluoksniai, kur kiekvienas etapas duomenis vis labiau valo ir struktūrizuoja.
Dažniausios klaidos, kurias matau realiuose projektuose
Dirbant su skirtingomis komandomis, pastebėjau keletą pasikartojančių klaidų, kurios kainuoja laiko ir pinigų:
- Ežeras be katalogo – duomenys sukeliami, bet niekas nesukuria metaduomenų katalogo (pvz., AWS Glue Catalog ar Unity Catalog). Po pusmečio niekas nebežino, kas kur yra, kokia struktūra, kada paskutinį kartą atnaujinta.
- Perdėtas ambicingumas su sandėliu – bandymas per prievartą sutalpinti visus duomenų tipus į griežtą reliacinę schemą, nors dalis duomenų iš prigimties yra nestruktūrizuoti. Rezultatas – begalinis ETL kodo palaikymas ir nuolatinis „schema drift” problemų sprendimas.
- Duomenų kokybės kontrolės nebuvimas – tiek ežere, tiek sandėlyje, jei niekas netikrina duomenų validumo įkėlimo metu (pvz., naudojant Great Expectations ar dbt testus), klaidos plinta toliau per visą sistemą ir galiausiai pasiekia vadovybės dashboard’us kaip „teisingi” skaičiai.
- Prieigos teisių ignoravimas – ežerai dažnai kuriami su per plačiomis prieigos teisėmis „kad viskas veiktų”, o vėliau paaiškėja, kad jautrūs duomenys (asmens duomenys, mokėjimų informacija) prieinami žmonėms, kuriems tikrai neturėtų būti.
- Kaštų nekontroliavimas – ypač su BigQuery ar Snowflake, kur mokate už apdorotus duomenis. Netvarkingos užklausos, be partitioning ar clustering, gali per mėnesį sugeneruoti sąskaitą, kuri priblokš finansų skyrių.
Vietoj išvadų: ką pasakyčiau kolegai prie kavos
Jei paklaustumėte manęs tiesiai – kas geriau, ežeras ar sandėlis – atsakymas būtų nuobodus, bet teisingas: priklauso nuo situacijos, ir dažniausiai reikės abiejų. Bet jei norite konkrečių, praktiškų patarimų, kuriuos galėtumėte pritaikyti jau šiandien, štai jie:
Pirma, nepradėkite nuo technologijos, pradėkite nuo klausimo. Kokius sprendimus reikia priimti pasitelkiant duomenis? Kas juos naudos – analitikai su SQL žiniomis ar duomenų mokslininkai, rašantys Python kodą? Atsakymas natūraliai nukreips jus link vienos ar kitos architektūros.
Antra, jei renkatės ežerą, iš karto investuokite į katalogą ir governance sluoksnį. Tai ne prabanga, o būtinybė – be to per metus turėsite ne ežerą, o skaitmeninį sąvartyną, kuriame niekas nebenori dirbti.
Trečia, apsvarstykite lakehouse architektūrą kaip numatytąjį pasirinkimą naujiems projektams. 2024–2025 metų tendencijos aiškiai rodo, kad Delta Lake ir Iceberg formatai tampa pramonės standartu, o dvigubo saugojimo (atskirai ežeras, atskirai sandėlis) modelis palaipsniui nyksta, nes yra tiesiog brangesnis ir sudėtingesnis palaikyti.
Ketvirta, nepamirškite žmogiškojo faktoriaus. Geriausia architektūra be aiškių taisyklių, dokumentacijos ir atsakingų žmonių už duomenų kokybę neveiks nepriklausomai nuo to, kiek pinigų investuosite į infrastruktūrą. Technologija išsprendžia tik dalį problemos – likusi dalis yra procesai ir disciplina.
Ir galiausiai – nebijokite pradėti mažai. Nereikia iš karto statyti milžiniškos platformos su visais įmanomais sluoksniais. Pradėkite nuo konkrečios verslo problemos, pasirinkite tinkamiausią įrankį tai problemai spręsti, o architektūra augs organiškai kartu su poreikiais. Būtent taip dauguma sėkmingų duomenų platformų ir buvo sukurta – ne per vieną didelį projektą, o per daugybę mažų, apgalvotų žingsnių.
