Analýza návštěvnosti fitness klubů Pracujete jako analytik v síti fitness klubů. Máte informace o návštěvách uživatelů a o zakoupených členstvích. Je třeba analyzovat efektivitu využívání členství. Vypočítejte pro každý typ členství: • celkový počet uživatelů, kteří tento typ členství využili. Zohledněte pouze unikátní user_id; • celkový počet návštěv s tímto členstvím. Zohledněte všechny návštěvy uživatelů s tímto členstvím; • podíl uživatelů tohoto členství v procentech z celkového počtu uživatelů (zaokrouhleno na jedno desetinné místo). Pro výpočet podílu použijte poměr počtu uživatelů s tímto členstvím k celkovému počtu unikátních uživatelů. Každý uživatel může mít pouze jedno členství. Seřaďte výsledek podle typu členství v abecedním pořadí. Formát vstupu Tabulka memberships: • membership_id (int) — unikátní identifikátor členství • user_id (int) — unikátní identifikátor uživatele • membership_type (text) — typ členství Tabulka visits: • visit_id (int) — unikátní identifikátor návštěvy • user_id (int) — identifikátor uživatele • visit_date (timestamp) — datum a čas návštěvy Data neobsahují chybějící nebo nesprávné hodnoty. Formát výstupu Dotaz by měl vrátit tabulku s poli v tomto pořadí: • membership_type (text) — typ členství • users_count (int) — počet unikátních uživatelů s tímto typem členství • total_visits (int) — celkový počet návštěv uživatelů s tímto členstvím • user_share (numeric) — podíl uživatelů v procentech s tímto členstvím od celkového počtu (zaokrouhleno na 1 desetinné místo) Výsledek je seřazen podle typu členství v abecedním pořadí.
Data Engineer
Znáte metodologii Domain Driven Design (DDD)? Pokud ano, podělte se o příklady jejího použití ve vašich projektech.
Jak odstranit podmodul a s ním související soubory z projektu? git submodule remove <cesta-k-podmodulu> git rm --cached <cesta-k-podmodulu>; odstranit sekci z .gitmodules; git commit git clean --submodules <cesta> git submodule delete <cesta> git remove submodule <cesta>
Během práce s git bisect jste narazili na commit, který nelze ověřit kvůli absenci potřebného prostředí. Co je třeba v této situaci udělat? - Opakujte příkaz git bisect start s jinými hashi - Přeskočte tento commit příkazem git bisect skip - Obnovte bisect příkazem git bisect reset - Označte commit jako dobrý příkazem git bisect good - Označte commit jako špatný příkazem git bisect bad
Proč následující dotaz nebude používat index, pokud byl v tabulce records (id) vytvořen běžný B-strom index na id? select * from records where id % 2 = 0 - Pro id je potřeba index typu GIN - Indexy nepracují s výrazy v WHERE - % je operace porovnání, nikoli filtrování - limit a offset jsou povinné pro optimalizaci s indexem - Dotaz odkazuje na číselné pole, nikoli na textové
Jaký výraz na místě [...] automaticky povede ke vzniku indexu? Na mobilní platformě je horizontální posuv kódu create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Vysvětlete, jak technicky funguje Git LFS a jaké výhody přináší ve srovnání se standardním Gitem při práci s velkými soubory.
Zpráva pro logistickou společnost Jste analytikem logistické společnosti, která zaznamenává operace na skladech. Musíte sestavit zprávu o efektivitě každého skladu. Pro každý sklad vypočítejte: • celkový počet operací (count_operations); • celkový počet zpracovaných zboží na skladě (sum_quantity); • průměrnou dobu zpracování operace (avg_processing_time), pouze s operacemi s uvedeným časem (ne NULL), zaokrouhlenou na celé číslo; • maximální a minimální počet zboží zpracovaného v jedné operaci (max_quantity, min_quantity); • počet operací každého typu («dodávka», «odeslání», «přesun») ve zvláštních sloupcích: supply_operations, shipment_operations, transfer_operations. Filtrovat sklady, u nichž celkový počet operací je větší než 2 a průměrná doba zpracování nepřesahuje 60 minut. Seřadit výsledek podle ID skladu vzestupně. Formát vstupu Tabulka operations: • operation_id (int) — unikátní identifikátor operace • warehouse_id (int) — ID skladu • operation_type (text) — typ operace: «dodávka», «odeslání», «přesun» • quantity (int) — počet jednotek zboží v operaci • operation_date (timestamp) — datum a čas operace • processing_time (int) — čas zpracování operace Sloupec processing_time může obsahovat hodnoty NULL. Formát výstupu Dotaz by měl vrátit tabulku se sloupci ve správném pořadí: • warehouse_id (int) — unikátní ID skladu • count_operations (int) — celkový počet operací provedených na skladu • sum_quantity (int) — celkový počet zpracovaných zboží na skladu • avg_processing_time (numeric) — průměrná doba zpracování operace (v minutách), pouze s operacemi s nenulovým časem, zaokrouhlená na celé číslo • max_quantity (int) — maximální počet zboží zpracovaného v jedné operaci • min_quantity (int) — minimální počet zboží zpracovaného v jedné operaci • supply_operations (int) — počet operací typu «dodávka» • shipment_operations (int) — počet operací typu «odeslání» • transfer_operations (int) — počet operací typu «přesun»
Byla vytvořena speciální sekvence s názvem even_sequence, která generuje pouze sudá čísla. Co je třeba vložit na místo [...], aby v případě, že hodnota even_column nebyla při vkládání uvedena, byla použita hodnota z even_sequence? create table some_table( even_column [...] ); integer computed as nextval('even_sequence') integer generated always as identity (start with 2 increment by 2) integer default nextval('even_sequence') integer unique default nextval('even_sequence') integer generated by even_sequence’
Co byste chtěli dělat v našem týmu?
Máte zkušenosti s knihovnou Langchain? Jaké úkoly jste s její pomocí řešili?
Jaký typ spojení je třeba použít, aby se do výběru dostali i ti uživatelé, kteří nemají žádné objednávky? Tabulky: users(id, name) a orders(id, user_id, created_at). CROSS JOIN RIGHT JOIN INNER JOIN FULL JOIN LEFT JOIN
Jak doporučuje Git Flow formálně zaznamenat novou verzi aplikace? - Vytvořením nové issue větve - Vytvořením hotfix větve od masteru - Vytvořením samostatné release větve od develop - Přímým commitem do větve master - Sloučením větve master přímo do develop
Které z následujících tvrzení odráží důsledky takovýchto akcí z pohledu rozšířeného Git Flow a správy historie změn?
Pracujete na nové funkci ve větvi dev. Náhle je potřeba rychle přepnout na větev main, abyste rychle opravili překlep v souboru README.md. Máte několik necommitovaných změn: v src/feature.js (neindexované) a styles/main.css (indexované). Chcete tyto změny dočasně uložit, abyste se k nim mohli později vrátit ve větvi dev. Jakou sekvenci příkazů byste měli použít k tomu? git stash save "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash push -m "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash && git checkout main && [fix] && git checkout dev && git stash apply git add . && git stash && git checkout main && [fix] && git checkout dev && git stash drop git commit -m "Temp commit" && git checkout main && [fix] && git checkout dev && git reset HEAD^
Analýza prodeje podle kategorií zboží v maloobchodě Pracujete jako analytik v maloobchodě. Vaším úkolem je sestavit zprávu o prodeji podle kategorií s následujícími výpočty: • celkový počet prodaných jednotek v kategorii (total_units_sold); • celkové tržby podle kategorie, s ohledem na slevy, kde sleva se počítá jako unit_price × units_sold × (1 − discount/100). Pokud je sleva NULL, považuje se za 0 %. Zaokrouhlete na dvě desetinná místa; • průměrný počet prodaných jednotek na jednu prodej (avg_units_per_sale), zaokrouhlený na dvě desetinná místa; • podíl prodejů bez slevy (no_discount_share) — počet prodejů s NULL nebo 0% slevou dělený celkovým počtem prodejů v kategorii, zaokrouhlený na tři desetinná místa. Seřaďte nejdříve podle celkových tržeb (total_revenue) sestupně, poté podle průměru jednotek na prodej (avg_units_per_sale) vzestupně, a nakonec podle názvu kategorie abecedně. Formát vstupu Tabulka sales: • sale_id (int) — unikátní identifikátor prodeje • product_id (int) — identifikátor produktu • category (text) — kategorie produktu • sale_date (timestamp) — datum a čas prodeje • units_sold (int) — prodané jednotky • unit_price (numeric) — cena za jednotku • discount (numeric) — sleva v procentech, může být NULL Sloupec discount může obsahovat chybějící hodnoty. Formát výstupu Dotaz by měl vrátit tabulku se sloupci ve stejné pořadí: • category (text) — kategorie produktu • total_units_sold (int) — celkový počet prodaných jednotek v této kategorii • total_revenue (numeric) — celkové tržby podle kategorie, zaokrouhlené na dvě desetinná místa • avg_units_per_sale (numeric) — průměrný počet jednotek na prodej, zaokrouhlený na dvě desetinná místa • no_discount_share (numeric) — podíl prodejů bez slevy (hodnota mezi 0 a 1), zaokrouhlený na tři desetinná místa Výsledek by měl být seřazen nejdříve podle total_revenue sestupně, poté podle avg_units_per_sale vzestupně, a nakonec podle názvu kategorie abecedně.
Objevili jste, že v historii hlavního repozitáře Git jsou commity obsahující kritická důvěrná data. Tato data je třeba úplně odstranit z celé historie repozitáře. Zhodnoťte, jak správné a bezpečné by bylo použít následující strategii: vytvořit nový commit, který odstraní důvěrná data z aktuální verze souborů, a odeslat ho do main. - Správně, ale ne optimálně. Je lepší použít git revert k vrácení commitů - Podmíněně správné. Je to dočasné řešení, dokud nebude nalezen prostředek k radikálnějšímu odstranění dat - Nesprávné a nezabezpečené. Data budou odstraněna z aktuální verze, ale zůstanou dostupná v historii repozitáře - Nesprávné. Tento commit může způsobit nové konflikty při slučování s jinými větvemi - Správné a bezpečné. Tato metoda zajišťuje, že data budou odstraněna a již se v repozitáři neobjeví
Máte zkušenosti s webovým frameworkem Gin? Povězte nám podrobněji, jaké úkoly jste s jeho pomocí řešili.
V PostgreSQL je třeba optimalizovat výkon transakcí pomocí minimální úrovně izolace, při které: • paralelní transakce mohou vidět nedokončené změny ostatních; • jsou možné "špinavé čtení" (dirty read). Jakou úroveň izolace je třeba určit pro transakci, aby bylo dosaženo tohoto cíle? špinavé čtení není v PostgreSQL možné repeatable read read uncommitted read committed serializable
Podíl botového provozu Tým proti podvodům vyvinul mechanismus pro detekci botového provozu na webu obchodu: když bot vstoupí na web, do parametrů jeho URL se přidá podřetězec "bot" (bez rozlišení velkých a malých písmen). Pokud byl user_id alespoň jednou v prosinci identifikován jako bot, měl by být vždy považován za bot. Prostudujte datovou sadu s návštěvami uživatelů na webu a vypočtěte podíl botů z celkového počtu uživatelů v prosinci 2024 (zaokrouhlete na jedno desetinné místo). Formát vstupu Tabulka visits: - event_date (date) — datum návštěvy - user_id (int) — unikátní identifikátor uživatele - url (string) — odkaz, přes který byla návštěva provedena Data neobsahují chybějící nebo nesprávné hodnoty. Formát výstupu Dotaz by měl vrátit tabulku s poli: - share (float) — podíl botů z celkového počtu uživatelů v prosinci, zaokrouhlený na jedno desetinné místo.