Data Engineer
Sarcina Kafka: producătorul trimite modificări ale prețului produsului (200 de ruble, apoi 300 de ruble), consumatorul este replicat în 3 pods. Vor exista probleme în configurația implicită?
Furnizăm metadate la intrare, iar acesta creează un flux pe baza acestor metadate — cum va permite acest lucru transferul rapid al fluxurilor existente de pe sistemele vechi pe cele planificate?
Care este pericolul shuffle-ului în Spark?
Care sunt riscurile legate de calitatea datelor?
Cum compari tabelul original ("live") și tabelul țintă dacă sursa se schimbă constant?
Ce este partiționarea datelor și cum ajută la evitarea scanării complete a tabelului?
Descrie funcțiile de fereastră în cea mai extinsă formă posibilă: ce cuvinte cheie sunt utilizate și pentru ce servește fiecare.
Ce s-a întâmplat și cum se poate recupera munca?
Ce este tiparea rață (duck typing)?
Vorbește-mi despre partiționare. Ce operații interesante a trebuit să faci?
Ce tipuri de partiții există?
Ce este o cheie primară în ClickHouse și cum diferă de o cheie primară în bazele de date obișnuite?
Aveți experiență în optimizarea interogărilor SQL? Oferiți un exemplu.
Ce este o alăturare broadcast în Spark?
Ce este optimizatorul Catalyst în Spark și ce exemple specifice de optimizări face (de exemplu, predicate pushdown)?
Detaliați algoritmul de captare a incrementului de la sursă pentru a nu pierde nimic atunci când se schimbă frecvența de încărcare.
Cum să urmăriți în ce rulare a DAG a apărut o linie specifică în Data Vault?
Ai descoperit că în istoricul depozitului principal Git există commit-uri care conțin date confidențiale critice. Aceste date trebuie eliminate complet din întreg istoricul depozitului. Evaluează cât de corect și sigur ar fi să folosești următoarea strategie: creează un nou commit care să elimine datele confidențiale din versiunea curentă a fișierelor și să îl trimiți în main. - Corect, dar nu optim. Este mai bine să folosești git revert pentru a anula commit-urile - Condiționat corect. Este o soluție temporară până când se găsește o metodă mai radicală de eliminare a datelor - Incorect și nesigur. Datele vor fi eliminate din versiunea curentă, dar vor rămâne accesibile în istoria depozitului - Incorect. Acest commit poate duce la conflicte noi la fuziunea cu alte ramuri - Corect și sigur. Această metodă garantează că datele vor fi eliminate și nu vor mai apărea în depozit
Ce strategie ar fi eficientă pentru eliminarea vulnerabilității în toate ramurile cu riscul minim de perturbare a funcționării proiectului? - Crearea unei serii de commit-uri de revert pentru commit-ul problematic și toate commit-urile care l-au corectat parțial, apoi crearea unui nou commit cu corectarea completă - Crearea unei ramuri hotfix dintr-un punct anterior commit-ului problematic, efectuarea corecțiilor și unirea acestei ramuri cu toate ramurile afectate - Crearea unui singur commit de corectare folosind git revert abc123 pe ramura principală și apoi cherry-pick-ul acestui commit pe toate ramurile de lansare - Utilizarea git bisect pentru a determina exact codul problematic, crearea unui patch și aplicarea acestuia pe toate ramurile cu git am - Utilizarea git rebase -i pentru a edita commit-ul problematic în fiecare ramură, urmată de un push forțat (force-push)
Care a fost ultima sarcină în Python pe care ai rezolvat-o în producție?