Fizinio klubų lankomumo analizė Jūs dirbate kaip analitikas fitneso klubų tinkle. Turite informacijos apie naudotojų lankomumą ir jų įsigytas narystes. Reikia analizuoti narystės efektyvumą. Apskaičiuokite kiekvieno narystės tipo: • bendrą naudotojų, naudojusių šį narystės tipą, skaičių. Laikykitės tik unikalių user_id; • bendrą vizitų skaičių su šia naryste. Laikykitės visų naudotojų vizitų su šia naryste; • naudotojų, turinčių šią narystę, dalį procentais nuo visų naudotojų skaičiaus (apvalinta iki vieno skaitmens po kablelio). Skaičiuokite naudodami santykį tarp naudotojų su šia naryste ir visų unikalių naudotojų. Kiekvienas naudotojas gali turėti tik vieną narystę. Rezultatą rūšiuokite pagal narystės tipą abėcėlės tvarka. Įvesties formatas Narystės lentelė: • membership_id (int) — unikalus narystės identifikatorius • user_id (int) — naudotojo identifikatorius • membership_type (text) — narystės tipas Lankymosi lentelė: • visit_id (int) — lankymosi unikalus identifikatorius • user_id (int) — naudotojo identifikatorius • visit_date (timestamp) — lankymosi data ir laikas Duomenys neturi tuščių ar klaidingų reikšmių. Išvesties formatas Užklausa turi grąžinti lentelę su laukais tokiu tvarką: • membership_type (text) — narystės tipas • users_count (int) — unikalių naudotojų, turinčių šį narystės tipą, skaičius • total_visits (int) — bendras lankymosi įvykių skaičius su šia naryste • user_share (numeric) — naudotojų dalis procentais nuo bendro naudotojų skaičiaus (apvalinta iki 1 skaitmens po kablelio) Rezultatas rūšiuojamas pagal narystės tipą abėcėlės tvarka.
Data Engineer
Ar pažįstate Domain Driven Design (DDD) metodologiją? Jei taip, pasidalinkite jos taikymo pavyzdžiais savo projektuose.
Kaip pašalinti submodulį ir su juo susijusius failus iš projekto? git submodule remove <submodulio-kelias> git rm --cached <submodulio-kelias>; pašalinkite sekciją iš .gitmodules; git commit git clean --submodules <kelias> git submodule delete <kelias>
Dar proceso de trabajo con git bisect, jūs susidūrėte su commit, kurį neįmanoma patikrinti dėl trūkstamos reikalingos aplinkos. Ką turite daryti šioje situacijoje? - Pakartokite komandą git bisect start su kitais hash'ais - Praleiskite šį commit naudodami komandą git bisect skip - Nustatykite iš naujo bisect naudodami komandą git bisect reset - Pažymėkite commit kaip gerą naudodami komandą git bisect good - Pažymėkite commit kaip blogą naudodami komandą git bisect bad
Kodėl sekančiu užklausa nepanaudos indekso, jei lentelėje records (id) yra sukurtas įprastas B-Tree indeksas pagal id? select * from records where id % 2 = 0 - GIN tipo indeksas reikalingas id - Indeksai neveikia su išraiškomis WHERE - % yra palyginimo operacija, ne filtravimas - limit ir offset yra privalomi optimizacijai su indeksu - Užklausa kreipiasi į skaitmeninį lauką, o ne į tekstinį
Kokia išraiška vietoje [...] automatiškai sukurs indeksą? Mobiliojoje platformoje yra horizontali kodo slinktis create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Paaiškinkite, kaip techniškai veikia Git LFS ir kokias pranašumus jis suteikia, palyginti su standartiniu Git, dirbant su dideliais failais.
Ataskaita logistikos įmonei Jūs esate logistikos įmonės analitikas, kuris stebi sandėlių operacijų apskaitą. Jums reikia paruošti ataskaitą apie kiekvieno sandėlio efektyvumą. Kiekvienam sandėliui apskaičiuokite: • bendrą operacijų skaičių (count_operations); • sandėlyje apdorotų prekių bendrą kiekį (sum_quantity); • vidutinį operacijos apdorojimo laiką (avg_processing_time), įskaitant tik operacijas su nurodytu laiku (ne NULL), suapvalintą iki sveiko skaičiaus; • didžiausią ir mažiausią prekių kiekį, apdorotą vienoje operacijoje (max_quantity, min_quantity); • kiekvieno tipo operacijų skaičių („pateikimas“, „siuntimas“, „perdavimas“) atskirose stulpeliuose: supply_operations, shipment_operations, transfer_operations. Filtruokite sandėlius, kurių bendras operacijų skaičius yra didesnis nei 2 ir vidutinis apdorojimo laikas neviršija 60 minučių. Rodyti rezultatą pagal sandėlio ID didėjimo tvarka. Įvesties formatas Operacijų lentelė: • operation_id (int) — unikalus operacijos identifikatorius • warehouse_id (int) — sandėlio identifikatorius • operation_type (text) — operacijos tipas: „pateikimas“, „siuntimas“, „perdavimas“ • quantity (int) — prekių kiekis operacijoje • operation_date (timestamp) — operacijos data ir laikas • processing_time (int) — operacijos apdorojimo laikas Stulpelis processing_time gali būti tuščias. Išvesties formatas Užklausa turi grąžinti lentelę su laukais tokia tvarka: • warehouse_id (int) — sandėlio unikalus identifikatorius • count_operations (int) — bendras atliktų operacijų skaičius sandėlyje • sum_quantity (int) — bendras apdorotų prekių kiekis sandėlyje • avg_processing_time (numeric) — operacijos vidutinis apdorojimo laikas (minutėmis), įskaitant tik ne NULL laikus, suapvalintą iki sveiko skaičiaus • max_quantity (int) — didžiausias apdorotų prekių kiekis vienoje operacijoje • min_quantity (int) — mažiausias apdorotų prekių kiekis vienoje operacijoje • supply_operations (int) — „pateikimo“ operacijų skaičius • shipment_operations (int) — „siuntimo“ operacijų skaičius • transfer_operations (int) — „perdavimo“ operacijų skaičius
Ypatinga seka, pavadinta even_sequence, buvo sukurta, kad generuotų tik lyginius skaičius. Ką reikėtų įrašyti vietoje [...], kad, jei įterpiant nebuvo nurodyta even_column reikšmė, ji būtų paimta iš 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’
Ką norėtumėte daryti mūsų komandoje?
Ar turite patirties dirbant su biblioteką Langchain? Kokius uždavinius sprendėte su jos pagalba?
Kokio tipo jungties reikia naudoti, kad į atranką įtrauktų ir tuos vartotojus, kurie neturi užsakymų? Lentelės: users(id, name) ir orders(id, user_id, created_at). CROSS JOIN RIGHT JOIN INNER JOIN FULL JOIN LEFT JOIN
Kaip Git Flow rekomenduoja oficialiai formuoti naują programos leidimą? - Sukuriant naują issue šaką - Sukuriant hotfix šaką nuo master - Sukuriant atskirą release šaką nuo develop - Tiesiogiai įrašant į master šaką - Tiesiogiai sujungiant master šaką su develop
Kuris iš žemiau pateiktų teiginių atspindi tokių veiksmų pasekmes iš išplėstinio Git Flow ir pakeitimų istorijos valdymo perspektyvos?
Dirbate dirbate naują funkciją dev šakelyje. Staiga atsiranda poreikis greitai perjungti į main šaką, kad greitai ištaisytumėte rašybos klaidą README.md faile. Jūs turite keletą necommitintų pakeitimų: src/feature.js (neįvardyti) ir styles/main.css (įvardyti). Norite laikinai išsaugoti visus šiuos pakeitimus, kad vėliau galėtumėte grįžti prie jų dev šakelyje. Kokį komandų seką turėtumėte naudoti tam? 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^
Pardavimų analizė pagal prekių kategorijas mažmeninės prekybos parduotuvėje Jūs dirbate analitiku mažmeninės prekybos parduotuvėje. Jūsų užduotis – sudaryti pardavimų ataskaitą pagal prekių kategorijas su skaičiavimais: • bendras parduotų vienetų skaičius kategorijoje (total_units_sold); • bendros pajamos pagal kategoriją, įskaitant nuolaidas, kur nuolaida taikoma kaip unit_price × units_sold × (1 − discount/100). Jei nuolaida nėra (NULL), laikykite ją 0%. Apvalinti iki dviejų skaitmenų po kablelio; • vidutinis parduotų vienetų skaičius vienai pardavimui (avg_units_per_sale), apvalintas iki dviejų skaitmenų po kablelio; • nuolaidų neturinčių pardavimų dalis (no_discount_share) – pardavimų, kurių nuolaida yra NULL arba 0%, skaičius padalintas iš bendro pardavimų skaičiaus kategorijoje, apvalintas iki trijų skaitmenų po kablelio: Pirmiausia rezultatą rūšiuokite mažėjimo tvarka pagal total_revenue, tada didėjimo tvarka pagal vidutinį vienetų skaičių (avg_units_per_sale), ir galiausiai pagal kategorijos pavadinimą abėcėlės tvarka: Įvesties formatas Pardavimų lentelė: • sale_id (int) – unikalus pardavimo identifikatorius • product_id (int) – produkto identifikatorius • category (text) – produkto kategorija • sale_date (timestamp) – pardavimo data ir laikas • units_sold (int) – parduotų vienetų skaičius • unit_price (numeric) – vieneto kaina • discount (numeric) – nuolaida produkto procentais, gali būti NULL Nuolaidos stulpelis gali turėti praleidimų: Išvesties formatas Užklausa turi grąžinti lentelę su laukais tokia tvarka: • category (text) – produkto kategorija • total_units_sold (int) – bendras parduotų vienetų skaičius šioje kategorijoje • total_revenue (numeric) – bendros pajamos pagal kategoriją, įskaitant nuolaidas, apvalintos iki dviejų skaitmenų po kablelio • avg_units_per_sale (numeric) – vidutinis vienetų skaičius vienam užsakymui, apvalintas iki dviejų skaitmenų po kablelio • no_discount_share (numeric) – nuolaidų neturinčių pardavimų dalis kategorijoje (nuo 0 iki 1), apvalinta iki trijų skaitmenų po kablelio Rezultatas turi būti rūšiuojamas pirmiausia pagal mažėjimą total_revenue, tada didėjimą pagal avg_units_per_sale, ir galiausiai pagal kategorijos pavadinimą abėcėlės tvarka.
Atradote, kad pagrindinio Git saugyklos istorijoje yra commit'ų, kuriuose yra kritinių konfidencialių duomenų. Šiuos duomenis reikia visiškai pašalinti iš visos saugyklos istorijos. Įvertinkite, kaip teisinga ir saugu būtų naudoti šią strategiją: sukurti naują commit'ą, kuris pašalins konfidencialius duomenis iš dabartinės failų versijos ir išsiųsti jį į main. - Teisinga, bet ne optimalu. Geriau naudoti git revert, kad atšaukti commit'us - Laikinai teisinga. Tai laikinas sprendimas, kol bus rastas radikalesnis būdas pašalinti duomenis - Neteisinga ir nesaugu. Duomenys bus pašalinti iš dabartinės versijos, bet liks prieinami saugyklos istorijoje - Neteisinga. Šis commit'as gali sukelti naujų konfliktų su kitomis šakomis - Teisinga ir saugu. Šis metodas garantuoja, kad duomenys bus pašalinti ir daugiau nebepasirodys saugykloje
Ar turite patirties dirbant su Gin žiniatinklio karkasu? Papasakokite išsamiau, kokius užduotis sprendėte naudodami jį.
PostgreSQL reikia optimizuoti transakcijų našumą naudojant minimalų izoliacijos lygį, kuriame: • paralelios transakcijos gali matyti nebaigtus pakeitimus vieni kitų; • įmanoma "nešvarių skaitymų" (dirty read). Kokį izoliacijos lygį reikia nurodyti transakcijai, kad pasiekti šį tikslą? nešvarių skaitymų PostgreSQL nėra įmanoma repeatable read read uncommitted read committed serializable
„Botų srauto dalis Antifraud komanda sukūrė mechanizmą, skirtą aptikti botų srautą parduotuvės svetainėje: kai botas įeina į svetainę, į jo URL parametrus pridedama subeilutė "bot" (neatsižvelgiant į didžiąsias ir mažąsias raides). Jei user_id buvo bent kartą nustatytas kaip botas gruodžio mėnesį, jis visada turi būti laikomas botu. Tyrinėkite naudotojų apsilankymų duomenų rinkinį svetainėje ir apskaičiuokite botų dalį pagal bendrą naudotojų skaičių 2024 m. gruodį (suapvalinkite iki vieno skaitmens po kablelio). Įvesties formatas Lentelė visits: - event_date (date) — apsilankymo data - user_id (int) — unikalus naudotojo identifikatorius - url (string) — nuoroda, per kurią įvykdytas apsilankymas Duomenys neapima trūkstamų ar klaidingų reikšmių. Išvesties formatas Užklausa turi grąžinti lentelę su laukais: - share (float) — botų dalis pagal bendrą naudotojų skaičių gruodį, suapvalinta iki vieno skaitmens po kablelio.