Фитнес клубдарга бару анализи Сиз фитнес клубдар тармагында аналитик болуп иштейсиз. Сизде колдонуучулардын баруусу жана алар сатып алган абонементтер тууралуу маалымат бар. Абонементтердин эффективдүүлүгүн анализдөө керек. Ар бир абонемент түрү үчүн: • бул абонемент түрүн колдонгон уникалдуу user_idлердин жалпы саны; • бул абонемент менен жасалган жалпы баруулар саны. Бардык барууларды эске алыңыз; • бул абонемент менен барган колдонуучулардын бөлүштүрүү пайызы. Бул үчүн, бул абонемент менен барган колдонуучулардын санын жалпы уникалдуу колдонуучулардын санына бөлүңүз жана пайызда көрсөтүңүз (бир ондукка жакындатылган). Ар бир колдонуучу бир гана абонементке ээ болушу мүмкүн. Натыйжаны абонемент түрү боюнча алфавиттик тартипте сорттогуңуз. Кирүү форматы Абонементтер таблицасы: • membership_id (int) — абонементтин уникалдуу идентификатору • user_id (int) — колдонуучунун уникалдуу идентификатору • membership_type (text) — абонементтин түрү Бардык маалыматтар бош же катаал маанилерди камтыбайт. Чыгуу форматы Суроо төмөнкүдөй тартипте талаалар менен таблицаны кайтаруусу керек: • membership_type (text) — абонементтин түрү • users_count (int) — бул түрдөгү уникалдуу колдонуучулардын саны • total_visits (int) — бул абонемент менен жасалган баруулардын жалпы саны • user_share (numeric) — бул абонемент менен барган колдонуучулардын пайызы, жалпы колдонуучулардын санына карата (бир ондукка жакындатылган) Натыйжаны абонемент түрү боюнча алфавиттик тартипте сорттогуңуз.
Data Engineer
Сиз Domain Driven Design (DDD) методологиясы менен таанышсызбы? Эгер ооба болсо, анын колдонулушунун мисалдарын бөлүшүңүз.
Кандайча субмодулду жана анын байланыштуу файлдарды долбоордон алып салуу керек? git submodule remove <субмодул-жолы> git rm --cached <субмодул-жолы>; .gitmodules бөлүмүнөн алып салыңыз; git commit git clean --submodules <жол> git submodule delete <жол>
Кайсы выражение [...] ордуна автоматтык түрдө индекс түзүүгө алып келет? Мобилдик платформада коддун горизонталдык сүргүлүшү бар create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
git bisect ишинде, сиз зарурий чөйрөнүн жоктугу себебинен текшерилбеген коммит менен кезигип калдыңыз. Бул учурда эмне кылуу керек? - Башка хештер менен git bisect start командасын кайра иштетиңиз - Бул коммитти git bisect skip командасы менен өткөрүп жазыңыз - git bisect reset командасы менен bisectти кайра баштаңыз - Commitти git bisect good командасы менен жакшы деп белгилеңиз - Commitти git bisect bad командасы менен жаман деп белгилеңиз
Логистикалык компания үчүн отчет Сиз логистикалык компаниянын аналитикасыңыз, ал складдардагы операцияларды эсепке алат. Сиз ар бир складдын иштөө эффективдүүлүгү боюнча отчет түзүшүңүз керек. Ар бир склад үчүн эсептеңиз: • жалпы операциялар саны (count_operations); • сактагычта иштетилген товарлардын жалпы саны (sum_quantity); • операциянын орточо иштетүү убактысы (avg_processing_time), белгиленген убакыт менен гана операциялар үчүн (NULL эмес), бүтүн санга жакындатылган; • бир операцияда иштетилген товарлардын максималдуу жана минималдуу саны (max_quantity, min_quantity); • ар бир түрдөгү операциялардын саны («жеткирүү», «жөнөтүү», «айырмалоо») өзүнчө колонкаларда: supply_operations, shipment_operations, transfer_operations. Жалпы операциялар саны 2ден ашкан жана орточо иштетүү убактысы 60 мүнөттөн ашпаган складтарды фильтрлөө. Натыйжаны склад ID боюнча өсүүчү тартипте сорттоо. Кирүү форматы Operation таблицасы: • operation_id (int) — операциянын уникалдуу идентификатору • warehouse_id (int) — складдын идентификатору • operation_type (text) — операциянын түрү: «жеткирүү», «жөнөтүү», «айырмалоо» • quantity (int) — операциядагы товарлардын саны • operation_date (timestamp) — операциянын датасы жана убактысы • processing_time (int) — операциянын иштетүү убактысы processing_time колонки пропусктарды камтышы мүмкүн. Чыгуу форматы Суроо төмөнкүдөй багыттагы таблицаны кайтаруусу керек: • warehouse_id (int) — складдын уникалдуу идентификатору • count_operations (int) — складта жүргүзүлгөн жалпы операциялар саны • sum_quantity (int) — складта иштетилген товарлардын жалпы саны • avg_processing_time (numeric) — операциянын орточо иштетүү убактысы (минутта), NULL эмес убакыт менен операциялар үчүн, бүтүн санга жакындатылган • max_quantity (int) — бир операцияда иштетилген эң көп товар саны • min_quantity (int) — бир операцияда иштетилген эң аз товар саны • supply_operations (int) — «жеткирүү» операцияларынын саны • shipment_operations (int) — «жөнөтүү» операцияларынын саны • transfer_operations (int) — «айырмалоо» операцияларынын саны
Неге кийинки суроо индекс колдонбойт, эгер records таблицасында (id) жөнөкөй B-Tree индекси түзүлгөн болсо? select * from records where id % 2 = 0 - Id үчүн GIN түрү индекси керек - Индекстер WHERE шарттарында колдонулбайт - % салыстыру операциясы, фильтр эмес - limit жана offset индекстин оптимизациясы үчүн милдеттүү - Суроо сандык талаага кайрылат, текст эмес
Git LFS кандайча техникалык жактан иштейт жана чоң файлдар менен иштөөдө стандарттык Gitке караганда кандай артыкчылыктарды сунуштайт экенин түшүндүрүңүз.
Өзгөртүлгөн тизмектин аты even_sequence деп аталган жана ал гана жуп сандарды чыгарат. [...]-тин ордуна эмне коюлушу керек, эгер even_column мааниси киргизилбесе, анда мааниси 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’
Биздин командада эмне кылгыңыз келет?
Langchain китепканасымен иштөө тажрыйбасыңыз барбы? Анын жардамында кандай тапшырмаларды чечтиңиз?
Кайсы түрү бирикмени колдонуш керек, тактап айтканда, тандоо тизмесине заказдары жок болгон колдонуучулар да кирсин? Таблицалар: users(id, name) жана orders(id, user_id, created_at). CROSS JOIN RIGHT JOIN INNER JOIN FULL JOIN LEFT JOIN
Төмендегі қайсысы кеңейтілген Git Flow және өзгерістер тарихын басқару тұрғысынан мұндай әрекеттердің салдарын көрсетеді?
Git Flow жаңы колдонмонун чыгарылышын кандайча расмий түрдө белгилөө керектигин сунуштайт? - Жаңы issue-шакын түзүү менен - masterтен hotfix-шак түзүү менен - developтен өзүнчө release-шак түзүү менен - түздөн-түз commit кылуу менен master-shакка - master-shакты түздөн-түз develop менен бириктирүү менен
Сиз dev тармагында жаңы функция үстүндө иштеп жатасыз. Кененирээк, README.md файлынын орфографиялык катасын тезирээк оңдоо үчүн main тармагына тез өтүү керек болот. Сизде бир нече коммит жасалбаган өзгөртүүлөр бар: src/feature.js (коммиттелбеген) жана styles/main.css (коммиттелген). Бул өзгөртүүлөрдү убактылуу сактап, кийинчерээк dev тармагында аларга кайтуу каалайсыз. Бул үчүн кайсы буйруктардын тизмесин колдонушуңуз керек? 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^
Git негизги репозиторийдин тарыхында маанилүү сырдуу маалыматтарды камтыган коммиттер бар экенин аныктадыңыз. Бул маалыматтарды репозиторийдин бардык тарыхынан толугу менен алып салуу керек. Төмөнкү стратегияны колдонуу канчалык туура жана коопсуз болорун баалаңыз: файлдардын учурдагы версиясинен сырдуу маалыматтарды алып салган жаңы коммит түзүңүз жана аны mainге жөнөтүңүз. - Туура, бирок оптималдуу эмес. Commitтерди кайтаруу үчүн git revert колдонуу жакшыраак - Шарттуу туура. Бул убакыттык чечим, анткени маалыматтарды алып салуунун көбүрөөк радикалдуу чарасы табылмайынча - Туура эмес жана коопсуз эмес. Маалыматтар учурдагы версиядан алынып салынат, бирок репозиторийдин тарыхында калат - Туура эмес. Бул коммит башка тармактар менен бириктирүүдө жаңы кагылышууларды пайда кылышы мүмкүн - Туура жана коопсуз. Бул ыкма маалыматтардын алынып салынганын кепилдейт жана кайра репозиторийде көрүнбөйт
Бөлүмдөр боюнча сатуу анализи кычкылда Сиз бөлүмдөр боюнча сатуу аналитиги болуп иштейсиз. Сиздин милдетиңиз — бөлүмдөр боюнча сатуу отчетун түзүү: • бөлүмдөр боюнча сатылган жалпы бирдиктер саны (total_units_sold); • бөлүмдөр боюнча жалпы киреше, арзандатууларды эске алуу менен, анда арзандатуулар колдонулат деп эсептелет: unit_price × units_sold × (1 − discount/100). Эгерде арзандатуулары жок болсо (NULL), анда 0% деп эсептеңиз. Эки ондук белгиге чейин топтоо; • бир сатуудагы орточо сатылган бирдиктердин саны (avg_units_per_sale), эки ондук белгиге чейин топтолгон; • арзандатуусу жок сатуулардын бөлүмдөгү үлүшү (no_discount_share) — NULL же 0% арзандатуулары бар сатуулардын саны бөлүмдөгү жалпы сатуулардын санына бөлүнгөн, үч ондук белгиге чейин топтолгон: Жыйынтыкты алдымен total_revenue боюнча азайтуу менен сорттогу, андан соң орточо сатылган бирдиктердин саны (avg_units_per_sale) боюнча өсүүчү тартипте, акырында — бөлүмдүн аталышы боюнча алфавиттик тартипте сорттогу. Киргизүү форматы Сатуу таблицасы: • sale_id (int) — сатуу уникалдуу идентификатору • product_id (int) — продукттун идентификатору • category (text) — продукт категориясы • sale_date (timestamp) — сатуу датасы жана убактысы • units_sold (int) — сатылган бирдиктер саны • unit_price (numeric) — бирдиктин баасы • discount (numeric) — продуктка берилген арзандатуулар пайыздарда, NULL болушу мүмкүн discount баалуулугу пропуск болушу мүмкүн: Чыгуу форматы Суроо төмөнкүдөй багыттар менен таблица кайтаруусу керек: • category (text) — продукт категориясы • total_units_sold (int) — ошол категориядагы сатылган жалпы бирдиктер саны • total_revenue (numeric) — арзандатууларды эске алуу менен категория боюнча жалпы киреше, эки ондук белгиге чейин топтолгон • avg_units_per_sale (numeric) — бир заказдагы орточо бирдиктер саны, эки ондук белгиге чейин топтолгон • no_discount_share (numeric) — категориядагы арзандатуусу жок сатуулардын бөлүштүрүлүшү (0дан 1ге чейин), үч ондук белгиге чейин топтолгон Жыйынтык алдымен total_revenue боюнча азайтуу, андан соң — орточо сатылган бирдиктердин саны (avg_units_per_sale) боюнча өсүүчү тартипте, акырында — бөлүмдүн аталышы боюнча алфавиттик тартипте сорттогу.
Gin веб-кайнатмасын колдонуу тажрыйбасыңыз барбы? Анын жардамы менен чечкен тапшырмаларыңыз тууралуу көбүрөөк айтып бериңиз.
[аты] тексттеги катачылыктарды жана стилин оңдоду: «Салам! Мен [аты], мурдагыда Telegramга өтүүнү сурагансың» — урматтоо менен, бирок достук маанайда
PostgreSQLда транзакциялардын иштөө көрсөткүчүн оптималдаштыруу үчүн минималдуу бөлүнүү деңгээлин колдонуу керек, анда: • параллел транзакциялар бири-биринин аяктагыс өзгөртүүлөрүн көрө алат; • "кыртыштуу окуу" (dirty read) мүмкүн. Бул максатка жетүү үчүн транзакция үчүн кайсы бөлүнүү деңгээлин көрсөтүү керек? PostgreSQLда dirty read мүмкүн эмес repeatable read read uncommitted read committed serializable