Pitanja za ML Platform and MLOps Engineer intervju
15 često postavljanih pitanja za ML Platform / MLOps intervju. Pitanja pokrivaju različite nivoe, a odgovore možete vežbati naglas u našem treneru za intervjue.
1Objasnite šta je ugovor o podacima (data contract) u produkcionoj platformi za ML (Machine Learning) i zašto je važan za pouzdanost modela.
U produkcionoj ML platformi, ugovor o podacima predstavlja formalni, verzionisani sporazum između proizvođača podataka (kao što su izvorni servisi aplikacija, sistemi za beleženje događaja ili data engineering tokovi podataka) i potrošača podataka (kao što su ML inženjeri, tokovi za pripremu obeležja i modeli). Pored standardnih šema baze podataka (nazivi kolona i primitivni tipovi), ugovor o podacima eksplicitno definiše semantička očekivanja, uključujući dozvoljene opsege vrednosti, kategoričke rečnike, ograničenja na vrednosti koje ne mogu biti null, SLA ugovore o svežini, osnovne nivoe zapremine podataka i jasnu odgovornost timova. Ugovori o podacima su ključni za pouzdanost ML sistema jer modeli mašinskog učenja otkazuju nečujno (silent failure). Dok tradicionalni softverski sistemi često izbacuju eksplicitne izuzetke kada se šeme naruše ili se struktura tereta neočekivano promeni, ML tokovi i modeli rado prihvataju pomerene ili neispravne ulaze, generišući degradirane predikcije, halucinacije u ocenjivanju ili ozbiljne poslovne anomalije bez oglašavanja standardnih operativnih alata za praćenje. Uvođenje izvršivih ugovora sprečava neočekivane promene koje lome kompatibilnost na samom ulazu podataka, minimizuje razmimoilaženje između treninga i produkcije (training-serving skew) i osigurava odgovornost proizvođača za kvalitet izvornih podataka.
2Objasnite provere kvaliteta podataka koje prevazilaze validaciju šeme i kako biste odlučili koje provere treba da blokiraju pipeline za treniranje ili serviranje modela.
Provere kvaliteta podataka koje prevazilaze validaciju šeme verifikuju statističke distribucije, poslovnu semantiku i integritet skupa podataka. Ključne kategorije obuhvataju:
1. Stope nedostajućih (null) vrednosti: Praćenje procenta nedostajućih vrednosti u odnosu na istorijske referentne vrednosti (baselines).
2. Ograničenja opsega i domena: Osiguravanje da numeričke karakteristike (features) budu unutar važećih granica (npr. starost između 0 i 120, verovatnoća u rasponu [0, 1]) i da kategorijalna polja pripadaju očekivanom rečniku.
3. Provere obima i svežine: Verifikacija broja zapisa, vremenskih oznaka prispeća particija i kompletnosti particija.
4. Referencijalni integritet i jedinstvenost: Provera jedinstvenosti primarnih ključeva i uspešnosti spajanja (join match rate) spoljnih ključeva.
5. Statističko odstupanje i pomeranje distribucije: Merenje indeksa stabilnosti populacije (PSI), Jensen-Shannon divergencije ili pomeranja srednje vrednosti/varijanse kroz particije.
Odluka o tome da li provera treba da blokira pipeline zavisi od kritičnosti greške, dometa uticaja (blast radius) i sposobnosti sistema za postepenu degradaciju (graceful degradation):
- Blokirajuće provere (Hard Gates): Zaustavljaju treniranje ili unos karakteristika kada su greške nepopravljive ili poništavaju matematičku ispravnost modela. Primeri: particije sa 0 zapisa, nedostajući primarni ključevi entiteta, drastičan pad obima podataka (>30%) ili oštećene ciljne oznake (target labels).
- Neblokirajuće provere (Soft Warnings / Alerts): Beleže telemetriju i šalju upozorenja dežurnom timu bez prekidanja izvršavanja pipeline-a kada su podaci i dalje upotrebljivi. Primeri: blago odstupanje karakteristika, očekivani sezonski padovi obima ili povećanje stope null vrednosti za nekritične karakteristike gde podrazumevane vrednosti ili imputacija omogućavaju prihvatljiva predviđanja modela.
3Objasnite svrhu skladišta karakteristika (feature store) i razliku između serviranja karakteristika u realnom vremenu (online feature serving) i generisanja karakteristika van mreže (offline feature generation).
Skladište karakteristika (feature store) je centralizovana platforma za podatke dizajnirana za upravljanje, skladištenje, pronalaženje i serviranje karakteristika mašinskog učenja kroz radne tokove obučavanja i inferencije. Njeni primarni ciljevi su podsticanje ponovnog korišćenja karakteristika između timova, eliminisanje dupliranih inženjerskih cevovoda i sprečavanje odstupanja između obučavanja i serviranja (train-serve skew) standardizacijom definicija karakteristika. Osnovni arhitektonski koncept skladišta karakteristika je obrazac dvostrukog skladištenja:
1. Offline skladište (generisanje karakteristika i obučavanje): Zasnovano je na analitičkim endžinima i distribuiranim skladištima (npr. Snowflake, BigQuery, S3/Parquet, Delta Lake). Optimizovano je za paketnu obradu visoke propusnosti (batch processing), istorijsko čuvanje podataka i vremenski tačna (point-in-time / as-of) spajanja. Ono generiše skupove podataka za obučavanje bez curenja podataka rekreiranjem stanja karakteristika tačno onako kako je postojalo u istorijskim trenucima predikcije.
2. Online skladište (serviranje za inferenciju u realnom vremenu): Zasnovano je na bazama podataka tipa ključ-vrednost niske latencije i visoke dostupnosti (npr. Redis, DynamoDB, Cassandra). Optimizovano je za pojedinačna očitavanja najnovijih vrednosti karakteristika ispod 10 ms po identifikatoru entiteta (npr. user_id) radi obogaćivanja zahteva za bodovanje modela u realnom vremenu.
Skladište karakteristika objedinjuje ova okruženja održavanjem jedinstvene definicije i registra karakteristika, orkestrirajući sinhronizaciju podataka iz cevovoda za unos (paketnih i striming) i u offline i u online skladište.
Feature Definition: `user_30d_transaction_count`
|
+---------------+---------------+
| |
v v
[Offline Store] [Online Store]
- Tech: BigQuery, Iceberg, S3 - Tech: Redis, DynamoDB
- Workload: High-throughput batch - Workload: Low-latency point lookups
- Retention: Multi-year history - Retention: Latest entity state
- Usage: Point-in-time training - Usage: Real-time inference scoring
4Objasnite razliku između definicije obeležja (feature definition), vrednosti obeležja (feature value), prikaza obeležja (feature view) i ključa entiteta (entity key) u produkcionoj platformi za rad sa obeležjima.
U savremenom skladištu obeležja (feature store) ili platformi za obeležja, ova četiri koncepta predstavljaju različite slojeve modelovanja podataka i dizajna sistema: 1. Ključ entiteta (Entity Key): Primarni identifikator (ili skup složenih ključeva) koji predstavlja koncept domena ili poslovni objekat (npr. `user_id`, `merchant_id`). Služi kao ključ za spajanje (join key) kroz izvore podataka i primarni ključ za pretragu tokom inferencije. 2. Definicija obeležja (Feature Definition): Logički metapodaci, specifikacija šeme i računarska logika koji definišu šta obeležje jeste, uključujući njegov naziv, tip podataka i logiku transformacije (npr. `user_30d_txn_sum` deklarisan kao `FLOAT32`). 3. Prikaz obeležja (Feature View): Logička apstrakcija koja grupiše povezane definicije obeležja pridružene određenim ključevima entiteta i podržane izvorima podataka (batch, streaming ili na zahtev). Definiše podešavanja unosa, vremensku semantiku (vremensku oznaku događaja odnosno event timestamp) i ponašanje materijalizacije i za offline i za online skladišta. 4. Vrednost obeležja (Feature Value): Konkretna, materijalizovana instanca podatka za određeni ključ entiteta evaluirana u određenom trenutku (npr. za `user_id = 1042` u trenutku `2023-10-01 12:00:00 UTC`, vrednost obeležja je `452.10`).
5Objasnite poreklo i tok podataka (data lineage) u ML (Machine Learning) platformi i zašto je praćenje porekla važno za otklanjanje regresija u kvalitetu modela.
Poreklo i tok podataka (data lineage) u ML platformi predstavlja strukturiranu evidenciju životnog ciklusa i izvora podataka, dokumentujući kako se sirovi skupovi podataka transformišu, filtriraju, inženjerski pretvaraju u obeležja (features), kompajliraju u skupove za obuku i koriste u specifičnim verzijama modela. Praćenje toka podataka je od suštinskog značaja za otklanjanje regresija u kvalitetu modela jer je degradacija ML performansi često uzrokovana defektima u ulaznim podacima, a ne greškama u programskom kodu. Kada performanse modela opadnu, praćenje toka omogućava analizu uzroka unazad: inženjeri mogu pratiti tok unazad od degradiranog modela kako bi proverili tačnu verziju skupa podataka, logiku transformacije obeležja, ulazni paket podataka ili promenu šeme koja je uvela problem. Suprotno tome, praćenje toka omogućava analizu uticaja unapred: kada se otkrije oštećena particija sirovih podataka ili greška u logici u ranijim fazama, inženjeri mogu pratiti uticaj unapred da bi identifikovali sve zavisne skupove za obuku, međutabele obeležja i produkcione modele koji su kontaminirani i zahtevaju ponovnu obuku ili vraćanje na prethodnu verziju.
[Degraded Model v3.1]
└── Trained on: [Dataset: training_set_2025_04_01]
└── Built from: [Feature View: user_features_v2 @ git_sha: abc1234]
└── Source Table: [raw_user_events @ batch_2025_03_31]
└── Issue Found: Logging bug produced 40% zero-filled values
6Objasnite šta registar modela (model registry) pruža osim skladištenja serijalizovanih artefakata modela.
Registar modela je centralizovani sistem za upravljanje, verzionisanje i praćenje životnog veka modela mašinskog učenja. Za razliku od standardnog skladišta artefakata (kao što su S3 bucket, GCS bucket ili opšte skladište binarnih objekata) koje samo čuva serijalizovane binarne fajlove (npr. `.onnx`, `.pt` ili `.pkl`), registar modela služi kao operativna kontrolna ravan za modele u celoj organizaciji. Registar modela pruža nekoliko ključnih mogućnosti van pukog skladištenja fajlova:
1. Verzionisanje modela i logičko grupisanje: Organizuje iteracije pod imenovanim entitetima modela uz semantičko verzionisanje, odvajajući logičku definiciju modela od pojedinačnih fajlova sa izvršavanja.
2. Metapodaci o poreklu i rodoslovu (lineage): Automatski povezuje artefakt modela sa pokretanjem treninga, komitom koda (Git SHA), verzijom skupa podataka za obuku, hiperparametrima, okruženjem za obuku (kontejnerska slika, verzije biblioteka) i autorom.
3. Metrike evaluacije i zapisi o upravljanju: Čuva metrike validacije, provere pravičnosti i pristrasnosti, ugovore o šemi (ulazno-izlazne signature) i kartice modela (model cards) uz sam artefakt radi provere spremnosti za produkciju.
4. Tranzicije faza životnog veka: Upravlja fazama napredovanja (npr. Experimental -> Staging -> Production -> Archived) uz kontrolu pristupa, kapije validacije i obavezna ručna ili automatizovana odobrenja.
5. Sledljivost raspoređivanja i vraćanje unazad (rollback): Služi kao jedinstveni izvor istine za CI/CD i infrastrukturu za posluživanje modela, omogućavajući automatizovano raspoređivanje i brzo vraćanje na prethodnu stabilnu verziju modela tokom incidenata u produkciji.
7Objasnite svrhu plana vraćanja na prethodnu verziju (rollback plan) za puštanje modela u rad i stanja neophodna za bezbedno vraćanje.
Svrha plana vraćanja na prethodnu verziju (rollback plan) za puštanje modela u rad jeste obezbeđivanje pouzdanosti servisa, dostupnosti sistema i kontinuiteta poslovanja. Kada novi model u produkciji pokaže pad kvaliteta predviđanja, regresiju u kašnjenju (latency), greške tokom izvršavanja ili neočekivana odstupanja u predviđanjima, plan vraćanja pruža brz i deterministički postupak za preusmeravanje saobraćaja na poznato ispravno stanje uz minimalne smetnje. Da bi se izvršilo bezbedno vraćanje na prethodnu verziju, platforma mora da sačuva i uskladi nekoliko ključnih stanja:
1. Stanje artefakata modela: Prethodne težine modela, binarne datoteke i serijalizovani objekti pipeline-a trajno i nepromenljivo sačuvani u registru modela ili skladištu objekata.
2. Izvršno i kodno okruženje: Slika kontejnera (container image), kod za serviranje zaključivanja (inference serving) i zavisnosti izvršnog okruženja trećih strana fiksirani na prethodno izdanje.
3. Stanje obeležja (feature) i pretprocesiranja: Tačne definicije obeležja, šeme transformacije i verzije skladišta obeležja (feature store) koje su kompatibilne sa prethodnom verzijom modela.
4. Stanje usmeravanja saobraćaja i konfiguracije: Pravila dinamičkog usmeravanja (npr. konfiguracije API (Application Programming Interface) mrežnog prolaza (API gateway), raspoređivača opterećenja (load balancer) ili servisne mreže (service mesh)) koja omogućavaju trenutno preusmeravanje saobraćaja bez ponovne izgradnje infrastrukture.
5. Mehanizam rezervnog rešenja (fallback): Determinističko podrazumevano rezervno rešenje (npr. heuristika zasnovana na pravilima ili statička keširana predviđanja) ukoliko i nova i prethodna instanca modela dožive otkaz.
8Uporedite validaciju šeme pri upisu i pri čitanju za ML (Machine Learning) tokove obrade obeležja i obrazložite kada je koji pristup poželjniji.
Validacija šeme pri upisu i pri čitanju predstavljaju dve komplementarne granice validacije sa različitim operativnim kompromisima: 1. Validacija pri upisu (Write-Time Validation): Validira dolazne zapise čim se generišu ili unesu u centralno skladište (npr. ulazni API, strimovi događaja ili lakehouse prihvatne zone). Obezbeđuje fail-fast garancije, blokira neispravne zapise pre nego što naruše deljene tabele i uspostavlja direktnu odgovornost uzvodnih servisa proizvođača. Poželjnija je za kritične produkcione platforme, deljene feature store sisteme sa više nizvodnih potrošača i onlajn tokove inferencije niske latencije gde bi neispravni podaci izazvali široke sistemske otkaze. 2. Validacija pri čitanju (Read-Time Validation): Validira podatke kada potrošački tokovi obrade izdvajaju ili učitavaju pakete (npr. tokom generisanja obeležja ili pripreme skupa za obučavanje). Daje nizvodnim potrošačima granularnu kontrolu za primenu pravila filtriranja specifičnih za model bez blokiranja uzvodnih tokova unosa ili zahtevanja izmena od timova koji proizvode podatke. Poželjnija je tokom eksploratorne analize, oflajn istraživanja, unosa heterogenih podataka od strane eksternih izvora koji se ne mogu kontrolisati ili pri radu sa nasleđenim skupovima podataka gde validacija pri upisu nije bila primenjena.
# 1. Write-Time Validation: Reject or quarantine bad records before landing in Feature Store
def write_to_feature_store(raw_records, schema_validator, feature_table, dlq_publisher):
valid_records = []
for record in raw_records:
if schema_validator.is_valid(record):
valid_records.append(record)
else:
dlq_publisher.publish(record, reason="write_time_validation_failed")
feature_table.append_batch(valid_records)
# 2. Read-Time Validation: Consumer pipeline applies defensive model-specific checks
def load_training_features(feature_table, model_schema):
df = feature_table.read_partition("2023-10-01")
# Model-specific consumer gate: drops non-conforming rows without halting upstream ingestion
clean_df = df[model_schema.validate_row_mask(df)]
return clean_df
9Kako biste dijagnostikovali data pipeline koji se uspešno izvršava, ali tiho odbacuje zapise ili pretvara nedostajuće vrednosti u podrazumevane vrednosti koje kvare predikcije modela?
Da biste dijagnostikovali i otklonili problem u pipeline-u koji se završava sa statusom uspeha dok tiho odbacuje zapise ili unosi neispravne podrazumevane vrednosti, primenite strukturisan proces trijaže incidenta:
1. Revizija obima podataka kroz faze pipeline-a: Izmerite broj redova i pokrivenost entiteta pre i posle svakog koraka transformacije (unos sirovih podataka -> spajanja -> agregacije -> tabela obeležja). Nenamerni `INNER JOIN` sa tabelom koja ima nedostajuće ili odbačene ključeve primarni je uzrok tihog odbacivanja zapisa.
2. Inspekcija obrade null vrednosti i imputacije podrazumevanih vrednosti: Pregledajte kôd transformacije u potrazi za agresivnom logikom zamene (npr. `.fillna(0)`, `COALESCE(val, -1)` ili neobrađeni prazni stringovi). Ako promene u šemi izvornih podataka pretvore kolonu u null vrednosti, neselektivna zamena podrazumevanim vrednostima će tiho pomeriti celokupnu distribuciju obeležja.
3. Tiha konverzija tipova i potiskivanje grešaka: Potražite mehanizme kastovanja koji ne prijavljuju greške (npr. `pd.to_numeric(..., errors='coerce')` ili SQL `SAFE_CAST`), koji nečitljive vrednosti direktno pretvaraju u `NULL` bez bacanja izuzetaka, što se zatim prosleđuje u imputaciju podrazumevanih vrednosti.
4. Procena uticaja na model i sanacija: Uporedite trenutne distribucije obeležja sa istorijskim baznim linijama koristeći PSI (Population Stability Index), srednju vrednost i udeo null vrednosti. Pregledajte logove distribucije predikcija modela da biste kvantifikovali odstupanje (prediction drift) i procenili poslovni uticaj. Primenite ispravke koda sa eksplicitnim proverama (assertions) i izvršite idempotentno naknadno popunjavanje (backfill) pogođenih istorijskih particija.
# Anti-Pattern: Succeeds green but corrupts feature data
# 1. Inner join silently drops users with missing profiles
# 2. errors='coerce' turns string typos into NaNs
# 3. fillna(0) injects artificial 0-values into feature distribution
df_corrupt = df_events.merge(df_profiles, on="user_id", how="inner")
df_corrupt["credit_score"] = pd.to_numeric(df_corrupt["raw_score"], errors="coerce").fillna(0)
# Robust Implementation: Explicit checks and observable failure
df_clean = df_events.merge(df_profiles, on="user_id", how="left")
join_match_rate = df_clean["user_id"].notna().mean()
if join_match_rate < 0.98:
raise RuntimeError(f"Severe join drop detected! Match rate: {join_match_rate:.2%}")
raw_nulls = df_clean["raw_score"].isna().mean()
if raw_nulls > 0.05:
raise ValueError(f"Anomalous raw_score missingness: {raw_nulls:.2%}")
10Uporedite paketne protočne linije obeležja (batch feature pipelines) i striming protočne linije obeležja (streaming feature pipelines) za produkcione ML (Machine Learning) primene sa različitim zahtevima za svežinom podataka, cenom i pouzdanošću.
Paketne (batch) i striming (streaming) protočne linije obeležja nude različite kompromise u pogledu svežine podataka, računskih troškova i operativne složenosti: 1. Svežina i kašnjenje: Striming protočne linije (npr. Apache Flink, Spark Structured Streaming) obrađuju događaje u skoro realnom vremenu, postižući svežinu obeležja od podsekunde do nivoa minuta. Ovo je od suštinskog značaja za vremenski osetljive ML primene kao što su detekcija prevara u realnom vremenu, dinamičko određivanje cena i neposredne preporuke zasnovane na sesiji. Paketne protočne linije (npr. raspoređeni Airflow DAG-ovi, dbt, Spark Batch) izvršavaju se prema periodičnim rasporedima (svakog sata, dnevno), generišući obeležja sa kašnjenjem od nekoliko sati do nekoliko dana, što je dovoljno za signale koji se sporo menjaju, kao što su 30-dnevni agregati korisnika, procena kreditnog rizika ili predviđanje životnog veka korisnika. 2. Troškovi i efikasnost resursa: Paketne protočne linije su znatno isplativije jer obrađuju velike količine podataka odjednom koristeći vektorizovano računanje, optimizovani kolonski I/O i spot/preemptible instance. Striming protočne linije zahtevaju infrastrukturu obezbeđenu 24/7, namensko skladište stanja (npr. RocksDB) i dimenzionisanje kapaciteta za vršni saobraćaj, što dovodi do viših operativnih i infrastrukturnih troškova. 3. Operativna složenost i pouzdanost: Paketne protočne linije su jednostavnije za nadgledanje, otklanjanje grešaka i idempotentno naknadno popunjavanje (backfill) u slučaju neuspeha. Striming protočne linije uvode složene oblike otkazivanja, uključujući upravljanje stanjem, vodene žigove za vreme događaja (event-time watermarking), obradu događaja koji stižu van redosleda, kreiranje tačaka provere (checkpointing) i garancije obrade tačno jednom (exactly-once processing). U zrelim ML platformama uobičajena je hibridna arhitektura: striming protočne linije računaju signale ponašanja niske latencije, dok paketne protočne linije računaju teške istorijske agregate, objedinjene kroz centralizovano skladište obeležja (feature store).
11Analizirajte kasno prispele događaje i događaje koji stižu van redosleda u tokovima obrade obeležja (feature pipelines) i kako oni utiču na podatke za obuku, labele i onlajn obeležja.
U distribuiranoj obradi tokova podataka i inženjeringu obeležja, događaji često pristižu van redosleda usled mrežnog kašnjenja, prekida u sistemu ili ponovnih pokušaja klijenata. Vreme događaja (event time) odnosi se na stvarni vremenski žig kada se događaj desio na klijentskom ili izvornom uređaju, dok je vreme obrade (processing time) vremenski žig kada endžin za prijem ili striming obradi taj događaj. Okviri za obradu tokova koriste vodene žigove (watermarks) kao markere vremenskog napretka kako bi pratili protok vremena događaja i definisali ograničeni prozor nakon kog se kasno prispeli podaci smatraju zakasnelim.
Kasno prispeli događaji i događaji koji stižu van redosleda imaju značajne operativne i statističke uticaje na sisteme obeležja:
1. Podaci za obuku i vremensko curenje (temporal leakage): Pri generisanju istorijskih skupova podataka za obuku, obeležja moraju biti spojena sa događajima predviđanja striktno prema vremenskom žigu događaja predviđanja (koristeći point-in-time ili as-of spajanja). Ako se greškom koristi vreme obrade ili ako obeležja uključe buduće podatke koji stižu van redosleda, buduće informacije cure u skupove za obuku, što veštački uvećava oflajn metrike dok dovodi do degradacije performansi u produkciji.
2. Generisanje labela: Mnoge labele u mašinskom učenju stižu sa promenljivim kašnjenjem (npr. atribucija konverzije, storniranja usled prevara sa oglasima). Ako spajanja labela ne uzmu u obzir kasne dolaske korišćenjem odgovarajućih prozora posmatranja/atribucije, nepotpune negativne labele će uneti pristrasnost lažno negativnih rezultata.
3. Onlajn obeležja: U onlajn skladištima obeležja (feature stores), neuređeni upisi iz toka mogu izazvati oštećenje stanja ili prepisivanje podataka ako serversko skladište naivno prepiše stanje starijim podacima. Onlajn tokovi moraju koristiti ažuriranja svesna vremena događaja (event-time-aware upserts), provere verzija ili komutativne funkcije agregacije kako bi sprečili prepisivanje zastarelim stanjem.
import pandas as pd
# Prediction events (e.g., ad impressions at inference time)
observations = pd.DataFrame({
'user_id': [101, 102],
'pred_time': pd.to_datetime(['2023-10-01 10:00:00', '2023-10-01 10:30:00'])
})
# Feature updates with event-time timestamps
user_features = pd.DataFrame({
'user_id': [101, 101, 102],
'feature_time': pd.to_datetime([
'2023-10-01 09:30:00',
'2023-10-01 10:15:00', # Occurs after observation 1 pred_time
'2023-10-01 10:00:00'
]),
'click_count_1h': [3, 5, 1]
})
# Backward as-of join guarantees only feature state known at pred_time is joined
training_set = pd.merge_asof(
observations.sort_values('pred_time'),
user_features.sort_values('feature_time'),
left_on='pred_time',
right_on='feature_time',
by='user_id',
direction='backward'
)
print(training_set[['user_id', 'pred_time', 'feature_time', 'click_count_1h']])
12Objasnite ulogu redova za neuspele poruke (DLQ - Dead Letter Queue), idempotentnosti i kreiranja tačaka provere (checkpointing) u protočnim obradama za obradu feature-a u realnom vremenu.
Protočne obrade za obradu feature-a u realnom vremenu oslanjaju se na redove za neuspele poruke, idempotentnost i tačke provere (checkpointing) kako bi očuvale integritet podataka i otpornost na otkaze u uslovima strimovanja visoke propusnosti:
1. **Kreiranje tačaka provere (Checkpointing):** Pogoni za strimovanje (kao što su Apache Flink ili Spark Structured Streaming) periodično čuvaju stanje protočne obrade (uključujući agregacije po prozorima i ofsete izvornih potrošača) u trajnom skladištu. Kada radni čvor otkaže ili se ponovo pokrene, protočna obrada obnavlja stanje iz najnovije validne tačke provere i nastavlja obradu od sačuvanog ofseta, garantujući obradu barem jednom (at-least-once) uprkos otkazima.
2. **Idempotentnost:** Pošto oporavak putem tačaka provere ponovo šalje poruke od prethodnih ofseta, nizvodna skladišta mogu primiti duplirane upise. Idempotentni ciljevi (sinks) osiguravaju da primena istog sadržaja događaja više puta rezultira potpuno istim stanjem kao i primena samo jednom. U skladištima feature-a (feature stores) ovo se postiže jedinstvenim ID-jevima transakcija/događaja, uslovnim ažuriranjima upoređivanjem vremenskih oznaka ($t_{incoming} > t_{stored}$) ili atomičnim upsert operacijama.
3. **Redovi za neuspele poruke (DLQ):** Tokovi unosa često nailaze na neispravne poruke (poison messages) — oštećene zapise, narušavanja šeme ili sadržaje koji izazivaju neobrađene izuzetke tokom izvršavanja. Umesto da dođe do pada potrošača i zastoja u obradi particije usled beskonačne petlje ponovnih pokušaja, protočna obrada usmerava neispravne zapise u DLQ. Time se održava zdravlje glavnog toka, dok se pogrešni zapisi izoluju radi analize, obaveštavanja i ručnog ili automatizovanog ponovnog puštanja u obradu.
def update_user_feature(redis_client, user_id: str, new_feature_val: float, event_timestamp: int):
lua_script = """
local current_ts = redis.call('HGET', KEYS[1], 'last_updated')
if not current_ts or tonumber(ARGV[1]) > tonumber(current_ts) then
redis.call('HSET', KEYS[1], 'feature_val', ARGV[2], 'last_updated', ARGV[1])
return 1
end
return 0
"""
# Atomic check-and-set: older replayed events are ignored
return bool(redis_client.eval(lua_script, 1, f"user:{user_id}", event_timestamp, new_feature_val))
13Objasnite strategiju naknadnog popunjavanja podataka (backfill) kada ispravljeni izvorni podaci ponište izvedene atribute koje koriste produkcioni modeli.
Kada se izvorni podaci retroaktivno isprave ili ponište, izvedeni atributi u oflajn skupovima za treniranje i onlajn skladištima atributa postaju neusklađeni. Napredna strategija naknadnog popunjavanja podataka zahteva strukturisan proces u više faza: 1. Analiza porekla podataka i opsega uticaja: Iskoristite metapodatke kataloga podataka i automatizovane grafove porekla da biste identifikovali sve izvedene prikaze atributa, nizvodne oflajn skupove za treniranje, onlajn tabele atributa i aktivne produkcione modele na koje utiču oštećeni izvorni podaci. 2. Izolovana istorijska ponovna obrada: Ponovo izvršite pipeline-ove za transformaciju atributa nad pogođenim vremenskim opsegom koristeći izolovane, namenske računarske resurse (npr. Spark/Ray). Ponovo obrađeni podaci moraju se upisivati u verzionisane, nepromenljive istorijske particije ili privremene tabele iz senke umesto direktne izmene produkcionih tabela na licu mesta. 3. Validacija i kontrolne tačke kvaliteta: Pokrenite automatizovane statističke provere i provere kvaliteta podataka pre promovisanja naknadno popunjenih podataka. Ovo uključuje verifikaciju šeme, granice učešća null vrednosti i poređenja raspodele atributa (npr. Population Stability Index (PSI) ili Vaserštajnova distanca) između naknadno popunjenih podataka i istorijskih osnovnih vrednosti. 4. Kontrolisani okidači za ponovno treniranje: Utvrdite da li modeli trenirani na nevažećim istorijskim atributima zahtevaju ponovno treniranje. Ako odstupanje atributa ili uticaj na nizvodne sisteme pređe unapred definisane pragove, pokrenite automatizovane DAG-ove za treniranje nad ispravljenim skupom podataka, validirajte metrike modela u odnosu na osnovne kandidate i kontrolišite prelazak u produkciju putem faza u senci ili kanarinac raspoređivanja. 5. Prelazak bez prekida rada i onlajn sinhronizacija: Za onlajn skladišta atributa, sinhronizujte naknadno popunjene vrednosti pomoću prigušenih upisa ili zamene pokazivača alijasa (npr. ažuriranje pokazivača u registru atributa na novu verziju atributa) kako bi se izbeglo preopterećenje baze podataka, nakon čega sledi proglašavanje zastarelim i brisanje prevaziđenih particija.
[Upstream Data Correction Event]
|
v
[1. Lineage Traversal] --------> Identifies: FeatureView_A, TrainingDataset_B, Model_C
|
v
[2. Isolated Reprocessing] ----> Writes to isolated staging: `features_v2_backfill`
|
v
[3. Validation Gate] ----------> Validates: Schema match, Null checks, PSI < 0.05
|
v
[4. Cutover & Retrain Trigger]-> Online: Atomic alias swap (`feature_v1` -> `feature_v2`)
Offline: Retrain Model_C on corrected historical split
14Projektujte sistem za dohvatanje funkcija u realnom vremenu sa niskim kašnjenjem i objasnite kompromise koji se tiču skladištenja, keširanja, particionisanja i vrućih ključeva.
Sistem za dohvatanje funkcija u realnom vremenu isporučuje unapred izračunate i funkcije u realnom vremenu modelima za inferenciju pod strogim ugovorima o nivou usluge (SLA - Service Level Agreement) za nisko kašnjenje (obično p99 < 5–20 ms) uz visoku propusnost. Arhitektura i skladište ključ-vrednost: - Sloj za skladištenje: Distribuirana skladišta ključ-vrednost sa niskim kašnjenjem (npr. Redis, DynamoDB, Cassandra, Aerospike) predstavljaju standard. Redis pruža očitavanja u memoriji ispod jedne milisekunde; DynamoDB/Aerospike nude isplativo skladištenje na SSD-ovima sa predvidljivim jednocifrenim milisekundnim kašnjenjem. - Denormalizacija podataka: Funkcije za određeni entitet se često čuvaju zajedno i serijalizuju (npr. u Protocol Buffers, FlatBuffers ili MessagePack) pod jednim ključem (`entity_id:feature_view_name`), čime se minimizuju mrežni prenosi i nasumična čitanja sa diska. Strategije keširanja i dohvatanja: - Višeslojno keširanje: Lokalni keš unutar procesa (npr. Caffeine/LRU u proksiju za posluživanje) za entitete sa izuzetno frekventnim zahtevima, uz distribuirano skladište ključ-vrednost u pozadini. - Paralelizovano višestruko dohvatanje / grupno dohvatanje: Zahtevi za inferenciju koji uključuju više entiteta (npr. ponovno rangiranje skupa od 500 kandidata) koriste grupne MGET operacije ili asinhrone pozive po principu raspršivanja i sakupljanja (scatter-gather) preko particija skladišta. Particionisanje i ublažavanje problema sa vrućim ključevima: - Konzistentno heširanje: Ravnomerno raspoređuje ključeve entiteta preko čvorova skladišta. - Vrući ključevi (npr. poznate ličnosti, viralni proizvodi, podrazumevani/globalni rezervni entiteti): 1. Replike za čitanje i lokalno keširanje: Posluživanje vrućih ključeva sa intenzivnim čitanjem iz lokalne memorije aplikacije ili replika samo za čitanje. 2. Dodavanje soli ključevima / virtuelno particionisanje: Dodavanje nasumičnih sufiksa (`hot_item_123#1..N`) preko više particija, čime se saobraćaj čitanja raspoređuje preko više fragmenata. 3. Ograničavanje brzine na strani klijenta i rezervni mehanizmi: Vraćanje statičkih podrazumevanih vrednosti ili keširanih rezervnih ugradnji (embeddings) kada dođe do degradacije sistema.
# Conceptual Online Feature Client with Local LRU + Batched KV Fetch
import functools
from typing import List, Dict, Any
class OnlineFeatureClient:
def __init__(self, remote_kv_store, local_cache):
self.remote_kv = remote_kv_store
self.local_cache = local_cache
def get_online_features(self, entity_keys: List[str], feature_names: List[str]) -> Dict[str, Dict[str, Any]]:
results = {}
missing_keys = []
# 1. Check local in-memory L1 cache (mitigates hot-keys)
for key in entity_keys:
cached = self.local_cache.get(key)
if cached:
results[key] = cached
else:
missing_keys.append(key)
# 2. Batched async retrieval for missing keys from distributed store (e.g., Redis/DynamoDB)
if missing_keys:
fetched_records = self.remote_kv.mget(missing_keys)
for key, serialized_val in zip(missing_keys, fetched_records):
parsed_val = self._deserialize(serialized_val) # Proto/Msgpack
results[key] = parsed_val
self.local_cache.set(key, parsed_val, ttl=30) # Short TTL L1 cache
return results
def _deserialize(self, data): ...
15Uporedite centralizovano vlasništvo nad obeležjima (features) sa vlasništvom domenskih timova na ML (Machine Learning) platformi sa više timova.
U organizacijama sa više ML timova, izbor između centralizovanog i domenskog (decentralizovanog/federativnog) vlasništva nad obeležjima nosi kompromise u pogledu ponovne upotrebljivosti obeležja, brzine razvoja, operativne odgovornosti i upravljanja sistemom:
1. Centralizovano vlasništvo nad obeležjima (posvećeni tim za podatke/obeležja):
- Kako funkcioniše: Centralni tim razvija, poseduje i održava sve pipeline-ove obeležja, kataloge u skladištu obeležja (feature store) i provere kvaliteta podataka za korisničke ML timove.
- Prednosti: Visok nivo standardizacije, jedinstveni modeli podataka, minimalno dupliranje obeležja među timovima, jasni globalni standardi kvaliteta i dosledna optimizacija troškova.
- Mane: Postaje organizaciono usko grlo; centralni inženjeri nemaju dubok domenski kontekst za specifičnu poslovnu logiku; sporo vreme isporuke zahteve za novim obeležjima.
2. Vlasništvo domenskih timova nad obeležjima (federativni model / Feature-as-Code / Data Mesh):
- Kako funkcioniše: Proizvodni/domenski ML timovi (npr. pretraga, prevencija prevara, preporuke) definišu i poseduju svoju logiku obeležja, pipeline-ove i definicije šema. Centralni platformski tim obezbeđuje osnovnu infrastrukturu za obeležja, CI/CD, registre i alate za praćenje.
- Prednosti: Velika brzina i domenska autonomija; timovi napreduju brzo bez zavisnosti od drugih timova; duboka domenska ekspertiza ugrađena u inženjering obeležja.
- Mane: Rizik od dupliranja obeležja (npr. tri tima grade neznatno različita brojanja klikova korisnika), fragmentisane konvencije imenovanja, neujednačeni standardi kvaliteta/SLA ugovora i izazovi u upravljanju podacima.
Preporučena moderna arhitektura (federativno vlasništvo uz platformsko upravljanje):
Većina zrelih organizacija usvaja model federativnog vlasništva gde platformski tim pruža jedinstveni katalog obeležja (Feature Catalog), CI/CD linting, automatsku validaciju šema i alate za pronalaženje postojećih obeležja. Domenski timovi poseduju pipeline-ove i operativne SLA ugovore, dok platforma sprovodi pravila upravljanja, kontrolu pristupa i pronalaženje duplikata.