Боттордун трафигинин үлүшү Кылмыштуулукка каршы команда сайттагы боттордун трафигин аныктоо үчүн механизм иштеп чыкты: бот сайтка киргенде, анын URL параметрлерине "bot" (бири-бири чоң жана кичи тамгаларга карабастан) субсөзү кошулат. Эгер user_id декабрда кеминде бир жолу бот катары аныкталган болсо, ал дайыма бот катары каралышы керек. Колдонуучулардын сайтка жасаган визиттеринин топтомун карап чыгып, 2024-жылдын декабрында жалпы колдонуучулардын санына салыштырмалуу боттордун үлүшүн эсептеңиз (бир ондук орунга жакындатыңыз). Кирүү форматы Table visits: - event_date (date) — визиттин датасы - user_id (int) — уникалдуу колдонуучу идентификатору - url (string) — өтүү үчүн колдонулган шилтеме Маалыматтарда жетишпеген же ката маанилер жок. Чыгуу форматы Суроо төмөнкү талаалар менен таблицаны кайтаруусу керек: - share (float) — декабрда жалпы колдонуучулардын санына салыштырмалуу боттордун үлүшү, бир ондук орунга жакындатылган.
Data Engineer
PostgreSQLда транзакциялардын иштөө көрсөткүчүн оптималдаштыруу үчүн минималдуу бөлүнүү деңгээлин колдонуу керек, анда: • параллел транзакциялар бири-биринин аяктагыс өзгөртүүлөрүн көрө алат; • "кыртыштуу окуу" (dirty read) мүмкүн. Бул максатка жетүү үчүн транзакция үчүн кайсы бөлүнүү деңгээлин көрсөтүү керек? PostgreSQLда dirty read мүмкүн эмес repeatable read read uncommitted read committed serializable
Эки транзакция бар. Биринчи транзакция команда аткарат. Андан кийин экинчи транзакция команда аткарат. Андан кийин биринчи транзакция улантат. Кайсы тартип өз ара блоктоого алып келет? ```sql -- биринчи транзакция update accounts set balance = balance + 100 where id = ?; -- экинчи транзакция update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
Алыстагы тармактан ишти кантип калыбына келтирсе болот, эгер сиз `git checkout hotfix/missing-footer` деп аракет кылганда тармак табылбаганын билдирген катаны алсаңыз?
Колдонуучулардын активдүүлүгүн талдоо жарнамалык кампанияларда Компания жарнамалык кампаниялар менен байланышкан окуяларды эсепке алат. Кирүү таблицалары: • campaigns — жарнамалык кампаниялардын тизмеси, алардын идентификаторлору жана аталыштары менен; • events — кампаниялар боюнча колдонуучулардын окуялары, окуянын түрү (мисалы, 'click' (жарнамага басуу)) жана убактысы тууралуу маалыматтар. Ар бир жарнамалык кампания үчүн төмөндөгүлөр менен отчет түзүү керек: • Бардык окуялардын саны. • Окуяларды жасаган уникалдуу колдонуучулардын саны. • Кампания боюнча биринчи жана акыркы окуянын убактысы. • Жалпы окуялардын саны боюнча кампаниянын рангин төмөндөтүү менен. Ранг — берилген маалыматтардын тартиби боюнча ар бир сапка берилүүчү сан. Эгер эки же андан көп сап бирдей мааниге ээ болсо, алар бирдей ранг алат, бирок кийинки ранг өткөрүлүп кетет. Тек окуялары болгон кампаниялар гана отчетко киргизилет: окуялары жок кампаниялар эсепке алынбайт. Жыйынтык отчет биринчи ранг боюнча өсүүчү тартипте, андан соң campaign_name боюнча алфавиттик тартипте сорттолуучу. Кирүү форматы • campaign_name (string) — жарнамалык кампаниянын аты • start_date (timestamp) — жарнамалык кампаниянын башталыш убактысы • end_date (timestamp) — аяктоо убактысы Окуялар таблицасы: • event_id (int) — окуянын уникалдуу идентификатору • user_id (int) — окуяны жасаган колдонуучунун уникалдуу идентификатору • campaign_id (int) — жарнамалык кампаниянын уникалдуу идентификатору • event_type (string) — окуянын түрү, мисалы 'click' (басуу) же 'conversion' (айлануу — ийгиликтүү аракет, мисалы сатып алуу) • event_time (timestamp) — окуянын жасалган убактысы Маалыматтар бош эмес жана туура эмес маанилерди камтыбайт. Чыгуу форматы Суроо төмөнкүдөй багыттар менен таблицаны кайтаруусу керек: • campaign_name (string) — жарнамалык кампаниянын аты • total_events (int) — кампания менен байланышкан жалпы окуялардын саны • unique_users (int) — уникалдуу колдонуучулардын саны, окуяларды жасаган • first_event_time (timestamp) — биринчи окуянын убактысы • last_event_time (timestamp) — акыркы окуянын убактысы • campaign_rank (int) — жалпы окуялардын саны боюнча кампаниянын рангин төмөндөтүү Маалыматтарды ранг боюнча өсүүчү тартипте, андан соң campaign_name боюнча алфавиттик тартипте сорттолуучу.
Эгер сиз субмодулдун көрсөтүп жаткан филиалын өзгөртүүнү кааласаңыз, эмне кылышыңыз керек? - Субмодулдар филиалды өзгөртүүнү колдобойт - Субмодулду өчүрүп, кайра кошуп, керектүү филиал менен кошуңуз - Субмодулда филиалды өзгөртүп, негизги репозиторийде Commit жасаңыз - Керектүү филиалда git checkout жүргүзүп, өзгөртүүлөрдү негизги репозиторийде каттаңыз - git submodule update --branch буйругун иштетип, жаңы филиалды көрсөтүңүз
Неге азыр жумуш сунуштарын карап жатасыз?
Команда кай амалдарды аткарды? - git revert командасын config.yaml менен болгон коммитке колдонду - git filter-branch --index-filter "git rm --cached config.yaml" -- --all командасын иштетти - git rebase -i командасын иштетип, файлга өзгөртүүлөрдү камтыган коммиттерди өчүрдү - git commit --amend жана git push --force командасын иштетти - git cherry-pick командасын колдонуп, config.yaml жок жаңы бутак түздү
Неге болду жана ишти кантип калыбына келтирсе болот?
Өтінемін, бұл вакансияға неге кызығасыз деп айтып бериңиз.
PostgreSQLде, саптын версиясынын башы xmax параметрин камтыйт. Ал транзакцияларды башкарууда кандай роль ойнойт? - Жолдун уникалдуу идентификаторун түзүү үчүн - Башка транзакциялар тарабынан саптын көрүнүмдүүлүгүн текшерүү үчүн - Жолду өчүргөн же жаңарткан транзакциянын номерин белгилөө үчүн - Бир нече транзакциялар тарабынан бир убакта жасалган өзгөртүүлөрдөн сапты коргоо үчүн - Сандык тилкеде жазылуучу максималдуу маанини көрсөтүү үчүн
notifications jadvali status maydoni mavjud bo'lib, uning qiymatlari: 'sent', 'delivered', 'read'. Qaysi so'rov to'g'ri? 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
Сүрөттөгү көрсөтүлгөн таблица түзүмү түзүлдү. Сүрөттөгү суроону аткаруу керек. [...]-тин ордуна кайсы join түрүн колдонуш керек, натыйжада type = 'table_aw' үчүн 'naming' багыты толтурулсун, жана type = 'table2' үчүн '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 ); -- таблица түзүмү 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'; -- суроо Бос калтырып коюңуз inner cross right left
Көптөгөн файлдарды тез арада акыркы коммиттин версиясына кайтаруу керек, башка өзгөртүүлөргө таасир этпестен. Кантип иштөө керек? git reset --hard HEAD Файлдарды өчүп, кайра түзүңүз git fetch жана git merge git revert HEAD git checkout HEAD^ <файл1> <файл2>
Жобанын негизги папкасынан кайсы буйрук docs/ субмодулун акыркы версиясына жаңылоо жана бул өзгөрүүнү коммитке даярдоо үчүн колдонулушу керек? 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 "Жаңылоо" git submodule update --init docs/
Фитнес клубдарындагы келүүчүлөрдүн анализи Сиз фитнес клубдар тармагында аналитик болуп иштейсиз. Колдонуучулардын келүүчүлөрү жана алар сатып алган абонементтери тууралуу маалыматтар бар. Абонементтердин эффективдүүлүгүн анализдөө керек. Ар бир абонемент түрү үчүн төмөндөгүлөрдү эсептөө: • Бул түрдөгү абонементти колдонгон жалпы колдонуучулардын саны. Тек гана уникалдуу user_idлерди караңыз; • Бул абонемент менен жасалган жалпы келүүчүлөрдүн саны. Бардык ушул абонемент менен байланышкан колдонуучулардын келүүчүлөрүн караңыз; • Бул абонементтин колдонуучуларынын жалпы санына пайыздык катышы (бир ондук бөлүккө чейин жакшыртылган). Колдонуучулардын катышын эсептөө үчүн, бул абонементти колдонгон колдонуучулардын санын жалпы уникалдуу колдонуучулардын санына бөлүңүз. Ар бир колдонуучу бир гана абонементке ээ боло алат. Натыйжаны абонемент түрү боюнча алфавиттик тартипте сорттогула. Кирүү форматы Таблица memberships: • membership_id (int) — абонементтин уникалдуу IDси • user_id (int) — колдонуучунун уникалдуу IDси • membership_type (text) — абонементтин түрү Таблица visits:
Неге болду жана ишти кайтаруу жолдору кандай?
Төмендегі сұраудың дұрыстығы туралы не айтуға болады? select * from sessions where ended_at is null and status != 'pending';
Эмнесе Scala долбоорлорунда иштегенсиз? Бул технологияда тактикалык тапшырмалар жана жетишкендиктер менен бөлүшүңүз.
Сизде эки байланышкан таблица бар: first_table жана second_table. Сиз TRUNCATE TABLE second_table CASCADE; командасын ишке ашыргыңыз келет; бул second_table таблицасынан бардык саптарды жана ага көз каранды болгон бардык маалыматтарды өчүрөт. Бул команда аткарылгандан кийин кандай кесепеттер болушу мүмкүн? create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - second_table_id_seq последовательности баштапкы мааниге кайтарылат. - second_table менен тышкы ачкыч аркылуу байланышкан first_table ичиндеги бардык жазуулар өчүрүлөт. - Бардык бар индекстер second_table үчүн өчүрүлүп, автоматтык түрдө кайра түзүлөт. - Кийинки кошулмаларда second_table ичинде id үчүн алдын ала белгиленген мааниси туура эмес мааниден башталат. - Хата пайда болот, анткени CASCADE командасы тышкы ачкычтары бар таблицалар үчүн тыюу салынган.