Kursusel oli kokku 9 moodulit, kus iga juurde anti ka ports kohustuslikku kirjandust lugeda. Loomulikult sel ajal ma seda ei jõudnud lugeda, kuid võtan nüüd eesmärgiks kuu aega järjest lugeda. Vaatame, kuhu jõuame. Lugemine suvalises järjekorras.
montecarlo.ai: What is data pipeline architecture? moodulist 1: andmeinseneeria alused. Artikkel annab hea ajaloolise ülevaate ning tutvustab ka suuroganisatsioonides kasutusel olevaid andmearhidektuuri. Kui peaks ühe põhjuse lugemiseks valima, siis selle seitsme andmetoru arhitektuuri põhimõtete pärast.
Andmetoru arhidektuur kavandab protsessi andmete teekonnast algallikast kuni nende tarbimiskihini. See hõlmab andmete eraldamist (extract), liitmist teiste andmetega või formaadi muutust (transform) ja laadimist andmebaasi/faili/andmehoidlasse (loading). Kogu teekond ei pruugi olla lineaarne protsess. Andmeinseneri töö ongi andmetoru ehitamine, mis vastaks 5V nõudmistele: suur andmemaht erinevas formaadis peab olema täpne, kvaliteetne ja õige ning kiirelt (mõnikord reaalajas) kätte saadav ning andma kasulikku väärtust otsuste tegemiseks.
Hadoop ajastu 2011-2017. Andmete säilitamine kohapealses ja mitteskaleeritavas andmebaasis. Kuigi võimalused hajus - ja paralleelsüsteemideks eksisteerisid, oli andmeinseneride peamiseks ülesandeks mudelite loomine ja päringute optimeerimine. Andmete normaliseerimine, puhastamine ja muutmine toimus enne kui need laaditi andmebaasi. Muudatuste tegemiseks tuli need teha koodis. Arvutusvõimsus maksis.
ELTi kaasaeg 2017 - tänaseni. Märksõnadeks pilveandmetöötlus ja erinevad andmehoidlad (aidad, järved, jm). Andmete eraldamine, hoidmine ja alles seejärel sobivale kujule töötlemine. Ehk teisendamine toimub pilves, kus on piisavalt arvutusvõimsust.
Striimimine. Eelnevalt sobis partii-põhine andmetöötlus. Andmeteadlaste töös ja masinõppes vaja töödelda andmeid reaal-aja põhiselt. Sellist võimalus pakub, nt Apache Kafka. Kasutatakse peamiselt kahte lahendust: toorandmed kohe rakendusse või siis enne andmejärve, siis andmelattu ja sealt rakendusse. Miinuseks küsitavused andmekvaliteedi - ja mudeli valiidsuse osas.
Mitte ETL (zero ETL) lahendus on veidi eksitava nimetusega. Andmete puhastamine, normaliseerimine toimub enne nende laadimist. Andmed asuvad andmejärves ja sinna tehakse rakendusest päringuid. Andmelao kiht puudub. Mitte-ETL lahendust saab kasutada, kui tehingute andmebaas (transactional database) ja andmejärv asuvad sama teenusepakkuja juures.
Andmete jagamisel Snowflake ja Databricks pioneerideks. ETL puudub, aga on õiguste-põhine ligipääs andmetele.
RAG (Retrieval-Augmented Generation) ja vektorotsing (Vector Retrieval) abil antakse tehisintellektile struktureerimata andmetest juurde asjakohane kontekst. Nii saab AI talle antud ülesannet paremini täita. Struktureerimata info jagatakse väiksemateks osadeks (chunks), mis mahuvad keelemudel konteksti aknasse (context window). "Koer on koduloom.", siis see teisendatakse vektoriteks [0.81, 0.101, 0.23..], mis näitab semantilist mõtet ehk sisu ja tähendust. Tehisaru otsibki vektorite lähedust ja tõlgib selle tagasi tekstiks. "Kas ka kass on koduloom?" võiks tähendusena maanduda sama "kodulooma" vektori lähedusse. Sõnad on küll erinevad, aga mõte sama.
Artiklis on ära toodud tänaste andmelahenduste arhitektuur ja pakkujate paljusus. Aga kõik need toetuvad suures plaanis samadele printsiipidele: andmete hoiustamine, töötlemine (Snowflake, Databricks) - andmete sissevõtt (Kafka, Spark) - orkestratisoon (Airflow, Dagster) - transformatsioon (dbt) - BI (Tabelau, PowerBi, Looker) - jälgimine (observability) - andmekataloog (metadata tabelite kohta) - õiguste haldamine.
7 head andmetoru arhidektuuri põhimõtet
- Kaardista andmesõltuvused - põlvnemised (lineage) ning mõista neid. Proovi automatiseerida, sest dokumenteerimine võib ühe hetkel ebaregulaarseks muutuda ning see või kaasa tuua andmetoru katki minemist või mitte töötamist.
- Jaota andmetoru väikesteks osadeks ja et oleks võimalikult käsitöö-vaba. Andmeinseneri töös on tihti vaja teha muudatusi. Väikestes komponentides (modulaarus) on lihtsam teha ja tead, kus muutsid, kui kohe andmetoru jälle tööle ei lähe. Lisaks arenduskuludele on ka hoolduskulud. Ehk muudatusi võivad tingida ka ärivajaduste muutumine.
- Sõlmi SLAd (teenustaseme kokkulepped) vastava andmetoru lõppkasutajaga. Kõigile oleks üheselt selge, kui kiirelt, millise kvaliteediga peavad andmed kättesaadavad olema; kui tihti neid uuendatakse ja millised on süsteemi nõudmised.
- Andmed määraku, millist andmearhidektuuri kasutatakse. Kuidas on andmeid kõige paremini töödelda vastavalt kasutaja vajadusele?
- Käsitle andmeid kui toodet. Tavaliselt tabelid, juhtlauad, mis loovad ettevõttele väärtust. Need peavad olema leitavad (discoverable), turvalised (secure), hallatud ja reguleeritud (governed), usaldusväärsed (trustworthy) ehk kõrge andmekvaliteediga, ühilduvad ja koostalitlusvõimelised (interoperable) teiste süsteemidega. Mõtteviisi muutus, et andmeinsenerid koguvad andmed kokku analüütikutele. Vaid andmed ise on väärtus, millel peab olema omanik, kvaliteedinõuded ja kasutajatele mugav ligipääs.
- Jälgi ja optimeeri kulusid pidevalt.
- Idempotentsus. Andmetoru korduval käivitamisel ei laeta olemasolevaid andmeid topelt ja andmetoru töö ei peatu. Kohustuslik omadus andmetoru juures.
Allikas: https://montecarlo.ai/blog-data-pipeline-architecture-explained