Podiel botovského prenosu Tím na boj proti podvodom vyvinul mechanizmus na detekciu botovského prenosu na stránke obchodu: keď bot vstúpi na stránku, do parametrov jeho URL sa pridá podreťazec "bot" (bez rozlíšenia veľkých a malých písmen). Ak bol user_id aspoň raz v decembri identifikovaný ako bot, mal by byť vždy považovaný za bot. Preskúmajte súbor údajov o návštevách používateľov na stránke a vypočítajte podiel botov z celkového počtu používateľov v decembri 2024 (zaokrúhlite na jedno desatinné miesto). Formát vstupu Tabuľka visits: - event_date (date) — dátum návštevy - user_id (int) — jedinečný identifikátor používateľa - url (string) — odkaz, cez ktorý bola návšteva vykonaná Dáta neobsahujú chýbajúce alebo nesprávne hodnoty. Formát výstupu Dopyt by mal vrátiť tabuľku s poliami: - share (float) — podiel botov z celkového počtu používateľov v decembri, zaokrúhlený na jedno desatinné miesto.
Data Engineer
Ako obnoviť prácu z vzdialenej vetvy, ak pri pokuse o `git checkout hotfix/missing-footer` dostanete chybové hlásenie, že vetva nebola nájdená?
Existujú dve transakcie. Najskôr prvá transakcia vykoná príkaz. Potom druhá transakcia vykoná príkaz. Následne prvá transakcia pokračuje. Aká sekvencia povedie k vzájomnému zablokovaniu? ```sql -- prvá transakcia update accounts set balance = balance + 100 where id = ?; -- druhá transakcia update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
V PostgreSQL je potrebné optimalizovať výkon transakcií pomocou minimálnej úrovne izolácie, pri ktorej: • paralelné transakcie môžu vidieť nedokončené zmeny iných; • sú možné "špinavé čítania" (dirty read). Akú úroveň izolácie je potrebné určiť pre transakciu, aby sa dosiahol tento cieľ? špinavé čítanie nie je v PostgreSQL možné repeatable read read uncommitted read committed serializable
Štruktúra tabuliek uvedená na obrázku bola vytvorená. Je potrebné vykonať dotaz uvedený na obrázku. Aký typ joinu je potrebné použiť na mieste [...], aby vo výsledku boli pre záznamy s type = 'table_aw' vyplnené stĺpce 'naming', a pre záznamy s type = 'table2' — stĺpce 'serial_number'? create table multirelation( type varchar not null, entity_id integer not null ); create table table_aw( id integer primary key, naming varchar not null ); create table table2( id integer primary key, serial_number varchar not null ); -- štruktúra tabuliek select m.type,m.entity_id, ta.naming, t2.serial_number from multirelation m [...] join table_aw ta on m.entity_id = ta.id and m.type='table_aw' [...] join table2 t2 on m.entity_id = t2.id and m.type='table2'; -- dotaz Nechajte prázdne inner cross right left
Analýza aktivity používateľov v reklamných kampaniach Spoločnosť vedie evidenciu udalostí súvisiacich s reklamnými kampaňami. Vstupné tabuľky sú: • campaigns — zoznam reklamných kampaní s ich identifikátormi a názvami; • events — udalosti používateľov podľa kampaní s informáciami o type udalosti (napríklad 'click' (klik na reklamu)) a čase. Je potrebné vytvoriť správu pre každú reklamnú kampaň s nasledujúcimi ukazovateľmi: • Celkový počet udalostí. • Počet jedinečných používateľov, ktorí vykonali udalosti. • Čas prvého a posledného udalosti podľa kampane. • Poradie kampane podľa zostupného počtu celkových udalostí. Riadok — číslo, ktoré sa priraďuje každej riadku v výslednom súbore na základe zadaného poradia údajov. Ak majú dve alebo viac riadkov rovnakú hodnotu, dostanú rovnaké poradie, ale nasledujúce poradie sa preskočí. Do správy sa zahrnú iba kampane, ktoré mali udalosti: kampane bez udalostí sa nezohľadňujú. Konečný prehľad by mal byť najskôr zoradený podľa poradia kampane vzostupne, a potom podľa campaign_name v abecednom poradí. Formát vstupu • campaign_name (string) — názov reklamnej kampane • start_date (timestamp) — dátum a čas začiatku reklamnej kampane • end_date (timestamp) — dátum a čas ukončenia reklamnej kampane Tabuľka events: • event_id (int) — jedinečný identifikátor udalosti • user_id (int) — jedinečný identifikátor používateľa, ktorý vykonal udalosť • campaign_id (int) — jedinečný identifikátor reklamnej kampane • event_type (string) — typ udalosti, napríklad 'click' (klik na reklamu) alebo 'conversion' (konverzia — úspešná akcia, napríklad nákup) • event_time (timestamp) — dátum a čas vykonania udalosti Dáta neobsahujú medzery alebo nesprávne hodnoty. Formát výstupu Dopyt by mal vrátiť tabuľku s poľami v takom poradí: • campaign_name (string) — názov reklamnej kampane • total_events (int) — celkový počet udalostí súvisiacich s kampaňou • unique_users (int) — počet jedinečných používateľov, ktorí vykonali udalosti • first_event_time (timestamp) — dátum a čas prvého udalosti kampane • last_event_time (timestamp) — dátum a čas posledného udalosti kampane • campaign_rank (int) — poradie kampane podľa zostupného počtu celkových udalostí Dáta zoradiť podľa poradia kampane podľa vzostupu, a potom podľa campaign_name v abecednom poradí.
Čo treba urobiť, ak chcete zmeniť vetvu, na ktorú ukazuje podmodul? - Podmoduly nepodporujú zmenu vetvy - Odstráňte podmodul a pridajte ho znova s požadovanou vetvou - Zmeňte vetvu v podmodule a vykonajte commit v hlavnom repozitári - Spustite git checkout na požadovanej vetve v podmodule a zaznamenajte zmeny v hlavnom repozitári - Spustite git submodule update --branch s uvedením novej vetvy
Prečo v súčasnosti zvažujete pracovné ponuky?
Veta feature obsahuje niekoľko commitov s nesprávne commitnutým súborom config.yaml, ktorý bol neskôr opravený. V dôsledku toho sa tím rozhodol úplne odstrániť všetky zmeny súboru z histórie, aby zabránil zverejneniu dôverných nastavení. Pôvodný stav vetvy (výstup príkazu git log --oneline): 1 a4b5c67 (HEAD -> feature) Refaktoroval logiku služby 2 d9f0a11 Opravil preklep v config.yaml 3 7c1d3f2 Pridal dočasný config.yaml 4 e3a98cd Počiatočný commit 5 Po prepísaní histórie na odstránenie súboru config.yaml sa výstup git log --oneline zmenil na: 6 b9e7d42 (HEAD -> feature) Refaktoroval logiku služby 7 41f3b60 Počiatočný commit Akú operáciu tím vykonal? - Spustil git revert na commite s config.yaml - Spustil git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Spustil git rebase -i odstránením commitov obsahujúcich zmeny v súbore - Spustil git commit --amend a git push --force - Použil git cherry-pick na vytvorenie novej vetvy bez config.yaml
Prosím, povedzte nám, prečo vás zaujala táto pozícia.
Čo sa stalo a ako obnoviť prácu?
Ktorý príkaz z koreňového adresára projektu by mal byť použitý na aktualizáciu submodulu docs/ na najnovšiu verziu z vzdialeného repozitára a na prípravu tejto zmeny na commit? git fetch docs/ && git merge docs/FETCH_HEAD git pull --recurse-submodules git submodule update --remote docs/ cd docs/ && git pull && cd .. && git commit -am "Aktualizácia" git submodule update --init docs/
Tabuľka notifications obsahuje pole status, ktorého hodnoty sú: 'sent', 'delivered', 'read'. Ktorý z dopytov je správny? select * from notifications where status like '%sent%' order by created_at desc limit 5 select * from notifications where status = 'read' order by created_at desc limit 5 select * from notifications order by status desc limit 5 select * from notifications where status not in ('sent', 'delivered') order by created_at asc limit 5 select * from notifications where status in ('sent', 'delivered') order by created_at desc limit 5
Analýza návštevnosti fitness klubov Pracujete ako analytik v sieti fitness klubov. Máte informácie o návštevách používateľov a o zakúpených členstvách, ktoré si kupujú. Je potrebné analyzovať efektívnosť využívania členstiev. Pre každý typ členstva vypočítajte: • celkový počet používateľov, ktorí tento typ členstva využili. Zohľadnite iba unikátne user_id; • celkový počet návštev tohto typu členstva. Zohľadnite všetky návštevy používateľov s týmto členstvom; • podiel používateľov tohto typu členstva v percentách z celkového počtu všetkých používateľov (zaokrúhlené na jedno desatinné miesto). Pre výpočet podielu používateľov použite pomer medzi počtom používateľov s týmto členstvom a celkovým počtom unikátnych používateľov. Každý používateľ môže mať iba jedno členstvo. Usporiadajte výsledok podľa typu členstva abecedne. Vstupný formát Tabuľka memberships: • membership_id (int) — unikátne identifikátor členstva • user_id (int) — unikátny identifikátor používateľa • membership_type (text) — typ členstva Tabuľka visits:
V PostgreSQL hlavička verzie riadku obsahuje parameter xmax. Akú úlohu zohráva v riadení transakcií? - Na vytvorenie jedinečného identifikátora riadku v tabuľke - Na kontrolu viditeľnosti riadku inými transakciami - Na označenie čísla transakcie, ktorá riadok odstránila alebo aktualizovala - Na zablokovanie riadku pred súčasnými zmenami viacerými transakciami - Na určenie maximálnej hodnoty, ktorá môže byť zapísaná do číselného stĺpca
Rýchlo musíte vrátiť niekoľko súborov na verziu z posledného commitu, nezasahujúc do ostatných zmien. Ako postupovať? git reset --hard HEAD Odstráňte a znovu vytvorte súbory manuálne git fetch a git merge git revert HEAD git checkout HEAD^ <súbor1> <súbor2>
Čo sa stalo a ako chcete vrátiť prácu?
Na akých projektoch v Scala ste pracovali skôr? Podeľte sa o konkrétne úlohy a úspechy v tejto technológii.
Čo možno povedať o správnosti nasledujúcej požiadavky? select * from sessions where ended_at is null and status != 'pending';
Správa pre logistickú spoločnosť Ste analytik v logistickej spoločnosti, ktorá zaznamenáva operácie na skladoch. Musíte vypracovať správu o efektívnosti každého skladu. Pre každý sklad vypočítajte: • celkový počet operácií (count_operations); • celkový počet spracovaných tovarov na sklade (sum_quantity); • priemerný čas spracovania operácie (avg_processing_time), pričom zohľadňujte iba operácie s určeným časom (nie NULL), zaokrúhlený na celé číslo; • maximálny a minimálny počet tovarov spracovaných v jednej operácii (max_quantity, min_quantity); • počet operácií každého typu («dodávka», «odoslanie», «presun») v samostatných stĺpcoch: supply_operations, shipment_operations, transfer_operations. Filtrovať sklady, ktorých celkový počet operácií je viac ako 2 a priemerný čas spracovania nepresahuje 60 minút. Usporiadať výsledok podľa ID skladu vzostupne. Formát vstupu Tabuľka operations: • operation_id (int) — jedinečný identifikátor operácie • warehouse_id (int) — ID skladu • operation_type (text) — typ operácie: «dodávka», «odoslanie», «presun»