Dotazy na pohovor pro ML Platform a MLOps inženýra
15 vybraných otázek na pohovor z ML platformy a MLOps, rozdělených podle úrovně seniority. Využijte je k opakování základů, praktických kompromisů a úvah pro produkční prostředí na seniorské úrovni.
1Vysvětlete, co je datová smlouva (data contract) v produkční ML (Machine Learning) platformě a proč je důležitá pro spolehlivost modelu.
V produkční ML (Machine Learning) platformě je datová smlouva formální, verzovaná dohoda mezi producenty dat (jako jsou upstreamové aplikační služby, loggery událostí nebo datové inženýrské pipeline) a konzumenty dat (jako jsou ML inženýři, feature pipeline a modely). Kromě standardních databázových schémat (názvy sloupců a primitivní typy) datová smlouva explicitně specifikuje sémantická očekávání, včetně povolených rozsahů hodnot, kategorických slovníků, omezení pro nulovatelnost, SLA (Service Level Agreement) pro aktuálnost, objemových základů a jasného týmového vlastnictví. Datové smlouvy jsou kritické pro spolehlivost ML, protože modely strojového učení selhávají tiše. Zatímco tradiční softwarové systémy často vyhazují explicitní výjimky, když se schémata poruší nebo se neočekávaně změní datové balíčky, ML pipeline a následné modely s radostí přijmou posunuté nebo špatně formátované vstupy, čímž produkují degradované predikce, skórovací halucinace nebo závažné obchodní anomálie, aniž by upozornily standardní provozní monitory. Vytvoření vymahatelných smluv zabraňuje neočekávaným lámavým změnám na hranici ingestace, minimalizuje nesoulad mezi trénováním a servírováním a prosazuje odpovědnost na straně producenta za kvalitu upstream dat.
2Vysvětlete kontroly kvality dat, které přesahují validaci schématu, a jak byste rozhodli, které kontroly by měly blokovat tréninkový nebo obslužný pipeline.
Kontroly kvality dat, které přesahují validaci schématu, ověřují statistické distribuce, obchodní sémantiku a integritu datové sady. Mezi klíčové kategorie patří:
1. Míra výskytu nulových a chybějících hodnot: Monitorování procenta chybějících hodnot oproti historickým základním liniím.
2. Omezení rozsahu a domény: Zajištění, že numerické prvky spadají do platných hranic (např. věk mezi 0 a 120, pravděpodobnost v [0, 1]) a kategorická pole patří k očekávaným slovníkům.
3. Kontroly objemu a aktuálnosti: Ověřování počtu záznamů, časových razítek příchodu oddílů a kompletnosti oddílů.
4. Referenční integrita a jedinečnost: Kontrola jedinečnosti primárních klíčů a úspěšnosti spojení cizích klíčů.
5. Statistický a distribuční drift: Měření indexu stability populace (PSI), Jensen-Shannonovy divergence nebo posunů průměru/rozptylu napříč oddíly.
Rozhodování o tom, zda má kontrola blokovat pipeline, závisí na kritičnosti selhání, rozsahu dopadu a na tom, zda se systém může elegantně zhoršit:
- Blokující kontroly (tvrdé brány): Zastaví trénink nebo ingest dat, když jsou chyby neopravitelné nebo zneplatňují matematiku modelu. Příklady: oddíly s 0 záznamy, chybějící primární klíče entit, závažné poklesy objemu (>30 %) nebo zkorumpované cílové štítky.
- Nenásilné kontroly (měkká varování / upozornění): Zaznamenávají telemetrii a spouštějí pohotovostní upozornění bez přerušení provádění pipeline, pokud jsou data stále použitelná. Příklady: mírný drift příznaků, očekávané sezónní poklesy objemu nebo nekritické zvýšení míry nulových hodnot příznaků, kde záložní výchozí hodnoty nebo imputace zachovávají tolerovatelné předpovědi modelu.
3Vysvětlete účel úložiště funkcí (feature store) a rozlište online obsluhu funkcí (online feature serving) od offline generování funkcí (offline feature generation).
Úložiště funkcí (feature store) je centralizovaná datová platforma navržená pro správu, ukládání, objevování a obsluhu funkcí strojového učení napříč trénovacími a inferenčními pracovními postupy. Její primární cíle jsou podporovat znovupoužitelnost funkcí napříč týmy, eliminovat duplicitní vývojové pipeline a zabránit rozdílům mezi daty používanými pro trénování a daty používanými pro obsluhu (train-serve skew) standardizací definic funkcí. Klíčovým architektonickým konceptem úložiště funkcí je vzor duálního úložiště:
1. **Offline úložiště (generování funkcí a trénování)**: Je postaveno na analytických mechanismech a distribuovaném úložišti (např. `Snowflake`, `BigQuery`, `S3/Parquet`, `Delta Lake`). Je optimalizováno pro dávkové zpracování s vysokou propustností, historické uchovávání dat a korektní spoje k danému časovému bodu (as-of joins). Generuje trénovací datové sady bez úniku dat (leak-free training datasets) tím, že přesně obnovuje stav funkcí tak, jak existoval v historických časových razítkách predikcí.
2. **Online úložiště (obsluha inferencí v reálném čase)**: Je postaveno na databázích klíč-hodnota s nízkou latencí a vysokou dostupností (např. `Redis`, `DynamoDB`, `Cassandra`). Je optimalizováno pro vyhledávání jednotlivých záznamů (point lookups) s latencí pod 10 ms nejnovějších hodnot funkcí, klíčovaných podle ID entit (např. `user_id`), pro obohacení požadavků na skórování modelu v reálném čase.
Úložiště funkcí sjednocuje tato prostředí udržováním jedné definice a registru funkcí a orchestrací synchronizace dat z dávkových/streamovaných ingestovacích pipeline do offline i online úložišť.
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
4Vysvětlete rozdíl mezi definicí vlastnosti, hodnotou vlastnosti, pohledem na vlastnost a klíčem entity v produkční platformě pro vlastnosti.
V moderním úložišti vlastností (feature store) nebo platformě pro vlastnosti (feature platform) představují tyto čtyři koncepty odlišné vrstvy datového modelování a návrhu systému: 1. Klíč entity (Entity Key): Primární identifikátor (nebo sada složených klíčů) reprezentující koncept domény nebo obchodní objekt (např. `user_id`, `merchant_id`). Slouží jako spojovací klíč napříč datovými zdroji a primární vyhledávací klíč během inference. 2. Definice vlastnosti (Feature Definition): Logická metadata, specifikace schématu a výpočetní logika deklarující, co je vlastnost, včetně jejího názvu, datového typu a transformační logiky (např. `user_30d_txn_sum` deklarovaná jako `FLOAT32`). 3. Pohled na vlastnost (Feature View): Logická abstrakce seskupující související definice vlastností spojené s konkrétními klíči entit a podpořené datovými zdroji (dávkové, streamované nebo na vyžádání). Definuje nastavení příjmu dat (ingestion settings), časovou sémantiku (časová značka události) a chování materializace pro offline i online úložiště. 4. Hodnota vlastnosti (Feature Value): Konkrétní, materializovaná datová instance pro konkrétní klíč entity vyhodnocená v konkrétním časovém okamžiku (např. pro `user_id = 1042` v čase `2023-10-01 12:00:00 UTC` je hodnota vlastnosti `452.10`).
5Vysvětlete provenienci dat na platformě pro strojové učení (ML) a proč je provenance důležitá pro ladění regresí kvality modelu.
Provenience dat na platformě pro strojové učení (ML) je strukturovaný záznam životního cyklu a původu dat, který dokumentuje, jak jsou surové datové sady transformovány, filtrovány, zpracovány na příznaky, kompilovány do trénovacích sad a spotřebovány konkrétními verzemi modelů. Provenience je nezbytná pro ladění regresí kvality modelu, protože degradace ML je často způsobena vadami v datech na vstupu spíše než chybami v kódu. Když výkon modelu klesne, provenience umožňuje analýzu základní příčiny zpětně: inženýři mohou sledovat zpět od degradovaného modelu, aby zkontrolovali přesnou verzi datové sady, logiku transformace příznaků, vstupní dávku dat nebo změnu schématu, která způsobila problém. Naopak, provenience umožňuje dopřednou analýzu dopadu: když je objevena poškozená partition surových dat nebo chyba v předchozí logice, inženýři mohou sledovat dopředu, aby identifikovali všechny následné trénovací sady, mezilehlé tabulky příznaků a nasazené modely, které byly kontaminovány a vyžadují přetrénování nebo návrat k předchozí verzi.
[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
6Vysvětlete, co registr modelů (model registry) poskytuje nad rámec ukládání serializovaných artefaktů modelu.
Registr modelů (model registry) je centralizovaný systém pro správu, verzování a řízení životního cyklu pro modely strojového učení. Na rozdíl od standardního úložiště artefaktů (jako je S3 bucket, GCS bucket nebo generické blob úložiště), které pouze uchovává serializované binární soubory (např. `.onnx`, `.pt` nebo `.pkl`), funguje registr modelů jako operační řídicí rovina pro modely v celé organizaci. Registr modelů poskytuje několik klíčových funkcí nad rámec prostého ukládání souborů: 1. Verzování modelů a logické seskupování: Organizuje iterace pod pojmenovanými entitami modelu se sémantickým verzováním, oddělujíc logickou definici modelu od souborů jednotlivých běhů. 2. Metadana původu a rodokmenu (Provenance and Lineage Metadata): Automaticky propojuje artefakt modelu s jeho trénovacím během, revizí kódu (Git SHA), snímkem tréninkové datové sady/verzí dat, hyperparametry, trénovacím prostředím (obraz kontejneru, verze knihoven) a autorem. 3. Metriky hodnocení a záznamy o správě: Ukládá validační metriky, audity spravedlivosti/předpojatosti, smlouvy schématu (vstupní/výstupní signatury) a modelové karty spolu s artefaktem pro ověření připravenosti k vydání. 4. Přechody životních fází: Řídí fáze propagace (např. Experimentální -> Staging -> Produkční -> Archivované) s řízením přístupu, ověřovacími branami a povinnými lidskými nebo automatizovanými schváleními. 5. Sledovatelnost nasazení a návrat k předchozí verzi (rollback): Slouží jako jediný zdroj pravdy pro CI/CD a infrastrukturu pro obsluhu, což umožňuje automatizovaná nasazení a rychlý návrat k předchozí stabilní verzi modelu během produkčních incidentů.
7Vysvětlete účel plánu pro vrácení zpět (rollback plan) při nasazování modelů a jaký stav je potřeba k bezpečnému vrácení zpět.
Účelem plánu pro vrácení zpět (rollback plan) pro nasazení modelů je zajistit spolehlivost služby, dostupnost systému a kontinuitu provozu. Pokud nově nasazený model vykazuje sníženou kvalitu predikcí, regrese latence, chyby za běhu nebo neočekávané posuny v predikcích, plán pro vrácení zpět poskytuje rychlý, deterministický postup, jak vrátit provoz do známého dobrého stavu s minimálním narušením. Pro provedení bezpečného vrácení zpět musí platforma zachovat a koordinovat několik klíčových stavů:
1. **Stav artefaktů modelu:** Předchozí váhy modelu, binární soubory a serializované objekty pipeline uložené neměnně v registru modelů nebo úložišti objektů.
2. **Prostředí pro běh a kód:** Obraz kontejneru, kód pro obsluhu inferencí a závislosti třetích stran pro běh připnuté k předchozí verzi.
3. **Stav prvků (feature) a předzpracování:** Přesné definice prvků, schémata transformací a verze úložiště prvků (feature store) kompatibilní s předchozí verzí modelu.
4. **Stav směrování provozu a konfigurace:** Dynamická pravidla směrování (např. konfigurace API gateway, load balanceru nebo service mesh), která umožňují okamžité přesměrování provozu bez přestavby infrastruktury.
5. **Záložní mechanismus:** Deterministický výchozí záložní mechanismus (např. heuristika založená na pravidlech nebo statické kešované predikce), pokud by selhaly jak nové, tak předchozí instance modelu.
8Porovnejte validaci schématu v době zápisu a v době čtení pro pipeline příznaků ve strojovém učení (ML – Machine Learning) a zdůvodněte, kdy je která preferována.
Validace schématu v době zápisu a v době čtení představuje dvě komplementární validační hranice s odlišnými provozními kompromisy:
1. Validace v době zápisu: Validuje příchozí záznamy, jak jsou generovány nebo zaváděny do centrálního úložiště (např. vstup (ingress) API – Application Programming Interface, témy streamování událostí nebo zóny pro ukládání dat v lakehouse). Vynucuje záruky rychlého selhání (fail-fast), blokuje chybně formátované záznamy dříve, než znečiští sdílené tabulky, a přiřazuje přímou odpovědnost upstream produkčním službám. Je preferována pro kritické produkční platformy, sdílená úložiště příznaků (feature stores) s více následnými spotřebiteli (downstream consumers) a online inference cesty s nízkou latencí, kde by poškozená data způsobila rozsáhlá systémová selhání.
2. Validace v době čtení: Validuje data, když spotřebitelské pipeline extrahují nebo načítají dávky (např. během generování příznaků nebo přípravy tréninkové sady). Poskytuje následným spotřebitelům jemnou kontrolu pro aplikaci filtračních pravidel specifických pro model, aniž by blokovala upstream zaváděcí pipeline nebo vyžadovala změny od produkčních týmů. Je preferována během explorativní analýzy, offline výzkumu, zavádění heterogenních dat z nekontrolovatelných třetích stran nebo při spotřebě starších datových sad, kde validace v době zápisu nebyla vynucena.
# 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
9Diagnostikujte datový pipeline, který je úspěšný, ale tiše zahazuje záznamy nebo převádí chybějící hodnoty na výchozí, které narušují predikce modelu.
Pro diagnostiku a nápravu pipeline, který je úspěšný (signalizuje zelenou), ale tiše zahazuje záznamy nebo nahrazuje poškozené výchozí hodnoty, postupujte podle strukturovaného pracovního postupu pro řešení incidentů: 1. **Audit objemu dat napříč fázemi pipeline:** Změřte počty řádků a pokrytí entit před a po každém kroku transformace (příjem surových dat -> spojení -> agregace -> tabulka příznaků). Neúmyslný `INNER JOIN` proti tabulce s chybějícími nebo zahazovanými klíči je primární příčinou tichého zahazování záznamů. 2. **Kontrola zpracování hodnot null a imputace výchozích hodnot:** Zkontrolujte transformační kód na agresivní logiku záložního řešení (např. `.fillna(0)`, `COALESCE(val, -1)` nebo neošetřené prázdné řetězce). Pokud změny schématu dat v upstreamu převedou sloupec na hodnoty null, plošné nahrazení výchozími hodnotami tiše posune celkovou distribuci příznaků. 3. **Tiché přetypování a potlačení chyb:** Hledejte mechanismy přetypování, které nezpůsobí selhání (např. `pd.to_numeric(..., errors='coerce')` nebo SQL `SAFE_CAST`), jež převádějí neparsovatelné hodnoty přímo na `NULL` bez vyvolání chyb, a následně se zapojují do imputace výchozích hodnot. 4. **Posouzení dopadu na model a náprava:** Porovnejte aktuální distribuce příznaků s historickými základními liniemi pomocí metrik PSI, průměru a četnosti null hodnot. Auditujte protokoly distribuce predikcí modelu, abyste kvantifikovali posun predikcí a posoudili obchodní dopad. Nasaďte opravy kódu s explicitními tvrzeními (assertions) a proveďte idempotentní backfill postižených historických partitionů.
# 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%}")
10Porovnejte dávkové pipeline pro příznaky a streamovací pipeline pro příznaky pro produkční případy použití strojového učení (ML) s různými požadavky na čerstvost dat, náklady a spolehlivost.
Dávkové a streamovací pipeline pro příznaky nabízejí odlišné kompromisy napříč čerstvostí dat, výpočetními náklady a provozní složitostí:
1. **Čerstvost a Latence:** Streamovací pipeline (např. Apache Flink, Spark Structured Streaming) zpracovávají události téměř v reálném čase, čímž dosahují čerstvosti příznaků v řádu milisekund až minut. To je nezbytné pro časově citlivé případy použití ML, jako je detekce podvodů v reálném čase, dynamické ceny a okamžitá doporučení založená na relacích. Dávkové pipeline (např. plánované Airflow DAGs, dbt, Spark Batch) běží podle pravidelných plánů (hodinových, denních) a produkují příznaky se zpožděním hodin až dnů, což je dostatečné pro pomalu se vyvíjející signály, jako jsou 30denní agregace uživatelů, hodnocení úvěrového rizika nebo predikce celoživotní hodnoty zákazníka.
2. **Náklady a Efektivita zdrojů:** Dávkové pipeline jsou výrazně nákladově efektivnější, protože zpracovávají velký objem dat hromadně pomocí vektorizovaných výpočtů, optimalizovaného sloupcového I/O a spotových/přerušitelných instancí. Streamovací pipeline vyžadují 24/7 zajištěnou infrastrukturu, dedikované úložiště stavu (např. RocksDB) a dimenzování kapacity pro špičkový nárazový provoz, což vede k vyšším provozním a infrastrukturním nákladům.
3. **Provozní složitost a Spolehlivost:** Dávkové pipeline jsou jednodušší na monitorování, ladění a idempotentní doplňování dat po selhání. Streamovací pipeline zavádějí komplexní režimy selhání, včetně správy stavu, vodoznakování časů událostí, zpracování událostí mimo pořadí, checkpointingu (ukládání kontrolních bodů) a záruk zpracování přesně jednou. Na zralých ML platformách je běžná hybridní architektura: streamovací pipeline v reálném čase počítají behaviorální signály s nízkou latencí, zatímco dávkové pipeline počítají náročné historické agregace, sjednocené prostřednictvím centralizovaného úložiště příznaků (feature store).
11Diskutujte o pozdě přicházejících a mimo pořadí událostech v kanálech funkcí (feature pipelines) a o tom, jak ovlivňují tréninková data, nálepky (labels) a online funkce (online features).
Při distribuovaném zpracování proudových dat a tvorbě funkcí (feature engineering) události často přicházejí mimo pořadí kvůli latenci sítě, výpadkům systému nebo opakovaným pokusům klienta. Čas události (Event time) označuje skutečné časové razítko, kdy k události došlo na klientovi nebo zdrojovém zařízení, zatímco čas zpracování (Processing time) je časové razítko, kdy ingesční nebo streamovací engine tuto událost zpracuje. Frameworky pro zpracování proudových dat používají vodoznaky (watermarks) jako časové značky pokroku pro sledování progresu událostního času a definují ohraničené okno, po kterém jsou pozdě přicházející data považována za zpožděná. Pozdě přicházející a mimo pořadí události mají významné provozní a statistické dopady napříč systémy funkcí:
1. **Tréninková data a časový únik (Temporal Leakage)**: Při generování historických tréninkových datasetů musí být funkce spojeny s predikčními událostmi přesně k časovému razítku predikční události (pomocí point-in-time nebo as-of spojů). Pokud je chybně použit čas zpracování nebo pokud funkce zahrnují budoucí data přicházející mimo pořadí, uniká budoucí informace do tréninkových sad, čímž se uměle navyšují offline metriky, zatímco dochází ke snížení výkonu v produkci.
2. **Generování nálepek (Labelů)**: Mnoho nálepek strojového učení přichází s proměnlivým zpožděním (např. přiřazení konverze, zpětné platby za podvody s reklamou). Pokud spoje nálepek nezohledňují pozdější příchody pomocí vhodných pozorovacích/atribučních oken, neúplné negativní nálepky zavedou bias falešně negativních výsledků.
3. **Online funkce (Online Features)**: V online úložištích funkcí mohou zápisy do proudu mimo pořadí způsobit poškození stavu nebo přepisy, pokud úložný backend naivně přepíše stav staršími daty. Online kanály musí používat upserty s ohledem na čas události, kontroly verzí nebo komutativní agregační funkce, aby se zabránilo přepisům zastaralého stavu.
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']])
12Vysvětlete roli front mrtvých zpráv (dead letter queues), idempotence a checkpointingu v real-time pipelinech pro zpracování rysů (features).
Real-time pipeline pro zpracování rysů (features) spoléhají na fronty mrtvých zpráv (dead letter queues), idempotenci a checkpointing, aby udržely integritu dat a odolnost proti chybám (fault tolerance) v podmínkách streamování s vysokou propustností:
1. **Checkpointing:** Streamovací enginy (jako Apache Flink nebo Spark Structured Streaming) periodicky ukládají stav pipeline (včetně agregací oken a offsetů konzumenta zdroje) do trvalého úložiště. Když worker selže nebo se restartuje, pipeline obnoví stav z nejnovějšího platného checkpointu a pokračuje ve spotřebě od zaznamenaného offsetu, čímž zaručuje zpracování alespoň jednou (at-least-once) napříč selháními.
2. **Idempotence:** Jelikož obnova z checkpointu přehrává zprávy z předchozích offsetů, downstream úložiště mohou obdržet duplicitní zápisy. Idempotentní sinky zajišťují, že použití stejné datové části události (event payload) vícekrát vede k naprosto stejnému stavu jako při jejím použití jednou. Ve feature storech je toho dosaženo pomocí unikátních ID transakcí/událostí, podmíněných aktualizací porovnávajících časové značky ($t_{incoming} > t_{stored}$) nebo atomických upsertů.
3. **Fronty mrtvých zpráv (DLQs):** Ingestion streamy se často setkávají s jedovatými zprávami (poison messages) – poškozenými záznamy, porušeními schématu nebo datovými částmi (payloads), které spouštějí neošetřené runtime výjimky. Namísto zhroucení konzumenta a zablokování zpracování partitiony v nekonečné smyčce opakování, pipeline směruje chybné záznamy do DLQ. To udržuje hlavní pipeline funkční a zároveň izoluje chybné záznamy pro inspekci, upozornění a ruční nebo automatické přehrání.
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))
13Pohovořte o strategii zpětného doplňování dat (backfill) v případě, že opravená vstupní data (upstream data) zneplatní odvozené příznaky používané produkčními modely.
Pokud jsou vstupní data (upstream data) zpětně opravena nebo zneplatněna, odvozené příznaky v offline tréninkových sadách a online úložištích příznaků se stanou nekonzistentními. Strategie zpětného doplňování dat (backfill) na seniorské úrovni vyžaduje strukturovaný, vícestupňový proces: 1. **Analýza původu dat a rozsahu dopadu:** Použijte metadata datového katalogu a automatické grafy původu dat k identifikaci všech odvozených pohledů na příznaky, navazujících offline tréninkových datových sad, online tabulek příznaků a aktivních produkčních modelů ovlivněných poškozenými vstupními daty. 2. **Izolované historické přepracování:** Znovu spusťte pipeline transformace příznaků pro postižené časové období pomocí izolovaných, vyhrazených výpočetních prostředků (např. Spark/Ray). Přepracovaná data musí být zapsána do verzovaných, neměnných historických oddílů nebo stínových přípravných tabulek, namísto mutování produkčních tabulek na místě. 3. **Validace a brány kvality:** Před propagací zpětně doplněných dat spusťte automatizované statistické kontroly a kontroly kvality dat. To zahrnuje ověření schématu, limity míry `null` hodnot a porovnání distribuce příznaků (např. Population Stability Index (PSI) nebo Wasserstein distance) mezi zpětně doplněnými daty a historickými základními hodnotami. 4. **Řízené spouštěče přeškolování:** Určete, zda modely trénované na neplatných historických příznacích vyžadují přeškolení. Pokud drift příznaků nebo následný dopad překročí předdefinované prahové hodnoty, spusťte automatizované tréninkové DAGy (Directed Acyclic Graphs) na opravené datové sadě, ověřte metriky modelu proti kandidátům na základní model a řiďte nasazení do produkce prostřednictvím stínových nebo canary fází. 5. **Přechod bez výpadku a online synchronizace:** Pro online úložiště příznaků synchronizujte zpětně doplněné hodnoty pomocí omezených zápisů (throttled writes) nebo výměn aliasových ukazatelů (např. aktualizací ukazatelů registru příznaků na novou verzi příznaku), abyste předešli saturaci databáze, následované zastaráním a likvidací (garbage collection) zastaralých oddílů.
[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
14Navrhněte online systém pro získávání rysů s nízkou latencí a vysvětlete kompromisy v ukládání, kešování, dělení (partitioning) a problému s horkými klíči (hot-key trade-offs).
Online systém pro získávání rysů (feature retrieval system) obsluhuje předem vypočítané a real-time rysy pro inferenční modely s přísnými SLA (Service Level Agreement) s nízkou latencí (typicky p99 < 5–20 ms) při vysoké propustnosti. Architektura a úložiště klíč-hodnota (Key-Value):
- Vrstva úložiště: Standardem jsou distribuovaná úložiště klíč-hodnota (Key-Value - KV) s nízkou latencí (např. Redis, DynamoDB, Cassandra, Aerospike). Redis poskytuje vyhledávání v paměti v řádu mikrosekund; DynamoDB/Aerospike nabízejí nákladově efektivní úložiště podpořené SSD (Solid State Drive) s predikovatelnou latencí v řádu jednotek milisekund.
- Denormalizace dat: Rysy pro entitu jsou často umístěny společně a serializovány (např. v Protocol Buffers, FlatBuffers nebo MessagePack) pod jediným klíčem (`entity_id:feature_view_name`), což minimalizuje síťové round-tripy a náhodné čtení z disku.
Strategie kešování a získávání:
- Víceúrovňové kešování: Lokální cache v rámci procesu (např. Caffeine/LRU (Least Recently Used) v obslužném proxy) pro extrémně často požadované entity, zálohovaná distribuovaným KV úložištěm.
- Paralelizované Multi-Get / dávkové načítání: Požadavky na inferenci zahrnující více entit (např. přeřazení 500 kandidátů) využívají dávkové operace MGET nebo asynchronní volání typu scatter-gather napříč fragmenty úložiště (storage shards).
Dělení (Partitioning) a zmírnění problému horkých klíčů (Hot-Key Mitigation):
- Konzistentní hashování: Rovnoměrně distribuuje klíče entit napříč uzly úložiště.
- Horké klíče (např. uživatelé celebrit, virální produkty, výchozí/globální záložní entity):
1. Repliky pro čtení a lokální kešování: Obsluhují horké klíče s vysokou četností čtení z lokální paměti aplikace nebo replik určených pouze pro čtení.
2. Solení klíčů (Key Salting) / Virtuální shardování: Připojte náhodné přípony (`hot_item_123#1..N`) napříč více oddíly, čímž se rozloží provoz čtení napříč fragmenty.
3. Omezení rychlosti na straně klienta a záloha (Fallback): Obsluhujte statické výchozí hodnoty nebo kešované záložní embeddingy, když dojde ke zhoršení výkonu.
# 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): ...
15Porovnejte centralizované vlastnictví prvků (feature ownership) s vlastnictvím prvků týmem domény v multi-týmové ML (Machine Learning) platformě.
V multi-týmových ML (Machine Learning) organizacích zahrnuje volba mezi centralizovaným a doménovým (decentralizovaným/federovaným) vlastnictvím prvků kompromisy v oblasti znovupoužitelnosti prvků, rychlosti vývoje, provozní odpovědnosti a řízení:
1. **Centralizované vlastnictví prvků (Vyhrazený tým pro data/prvky):**
* **Jak to funguje:** Centrální tým vytváří, vlastní a udržuje všechny pipeline prvků, katalogy úložiště prvků (feature store catalogs) a kontroly kvality dat pro konzumní ML týmy.
* **Výhody:** Vysoká standardizace, jednotné datové modely, minimální duplicita prvků napříč týmy, jasné globální standardy kvality a konzistentní optimalizace nákladů.
* **Nevýhody:** Stává se organizačním úzkým hrdlem; centrální inženýři postrádají hluboký doménový kontext pro logiku specifickou pro byznys; pomalá doba odezvy na požadavky na nové prvky.
2. **Vlastnictví prvků týmem domény (Federované / Feature-as-Code / Data Mesh):**
* **Jak to funguje:** Produktové/doménové ML týmy (např. vyhledávání, detekce podvodů, doporučení) definují a vlastní svou logiku prvků, pipeline a definice schémat. Centrální platformový tým poskytuje podkladovou infrastrukturu prvků, CI/CD, registry a nástroje pro monitorování.
* **Výhody:** Vysoká rychlost a doménová autonomie; týmy se rychle pohybují bez mezitýmových závislostí; hluboká doménová expertíza je zakotvena v prvkovém inženýrství (feature engineering).
* **Nevýhody:** Riziko duplicity prvků (např. tři týmy vytvářející mírně odlišné počty kliknutí uživatelů), fragmentované konvence pojmenování, nekonzistentní standardy kvality/SLA a výzvy v řízení.
**Doporučená moderní architektura (Federované vlastnictví s řízením platformy):** Většina vyspělých organizací přijímá model federovaného vlastnictví, kde platformový tým poskytuje jednotný Katalog prvků (Feature Catalog), CI/CD linting, automatizované ověřování schémat a nástroje pro objevování. Doménové týmy vlastní pipeline a provozní SLA, zatímco platforma vynucuje řízení, řízení přístupu a objevování duplicit.