Фитнес-клубтарға келушілерді талдау Сіз фитнес-клубтар желісінде аналитиксіз. Сізде пайдаланушылардың келулері мен сатып алған абонементтері туралы ақпарат бар. Абонементтердің тиімділігін талдау қажет. Әрбір абонемент түрі бойынша есептеңіз: • Осы абонемент түрін пайдаланған бірегей пайдаланушылар саны. Тек бірегей user_id-ларды ескеріңіз; • Осы абонемент бойынша жалпы келулер саны. Бұл абонементпен пайдаланушылардың барлық келулерін ескеріңіз; • Бұл абонемент түріндегі пайдаланушылардың жалпы санына пайызбен қатынасы (бір таңбалы ондықпен дөңгелектелген). Пайызды есептеу үшін осы абонементпен пайдаланушылар саны мен барлық бірегей пайдаланушылар санының қатынасын пайдаланыңыз. Әр пайдаланушының тек бір абонементі болуы мүмкін. Нәтижені абонемент түрі бойынша алфавиттік тәртіпте сұрыптаңыз. Кіріс форматы Memberships кестесі: • membership_id (int) — абонементтің бірегей идентификаторы • user_id (int) — пайдаланушының бірегей идентификаторы • membership_type (text) — абонемент түрі Visits кестесі: • visit_id (int) — келудің бірегей идентификаторы • user_id (int) — пайдаланушының идентификаторы • visit_date (timestamp) — келу күні мен уақыты Деректерде бос мәндер немесе қате мәндер жоқ. Шығыс форматы Сұрау келесі өрістермен таблицаны қайтаруы керек: • 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 <жол> git remove submodule <жол>
Қайсы бір [...]-дің орнында қандай өрнек автоматты түрде индекс құруға әкеледі? Мобильді платформада кодтың көлденең скроллы бар create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Логистикалық компания үшін есеп беру Сіз қоймалардағы операцияларды есепке алатын логистикалық компанияда аналитиксіз. Әр қойманың тиімділігін бағалау үшін есеп беру құрастыруыңыз керек. Әр қойма үшін есептеу: • жалпы операция саны (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) — 'ауыстыру' операцияларының саны.
git bisect жұмыс процесінде сіз қажетті орта болмағандықтан тексеруге болмайтын commit-ке тап болдыңыз. Бұл жағдайда не істеу керек? - Басқа хэштермен git bisect start командасын қайта орындау - Бұл commit-ті git bisect skip командасымен өткізіп жіберу - git bisect reset командасымен bisect-ті қалпына келтіру - Commit-ті жақсы деп жариялау git bisect good командасымен - Commit-ті нашар деп жариялау git bisect bad командасымен
records (id) кестесінде id бойынша кәдімгі B-дерекқор индексі жасалды. Неліктен келесі сұрау индекс қолданбайды? select * from records where id % 2 = 0 - id үшін GIN түріндегі индекс қажет - Индекстер WHERE ішіндегі өрнектермен жұмыс істемейді - % салыстыру операциясы, сүзгі емес - шектеу және ығысу индекс оңтайландыру үшін міндетті - Сұрау сандық өріске жүгінеді, жол емес
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 әдістемесін қолданатын командада жұмыс істеп жатырсыз, оған қосымша бұтақ түрлері енгізілген. Сіздің жобаңыздың бұтақ құрылымы келесідей: - main (тұрақты шығарылымдар) - develop (ағымдағы даму) - release/* (шығарылымға дайындық) - hotfix/* (шұғыл түзетулер) - feature/* (жаңа функциялар) - experimental/* (тәжірибелік функциялар) - refactor/* (кодты қайта құру) Сіздің әріптесіңіз келесі әрекеттерді орындады: - refactor/db-constraints бұтағын develop-тен жасады - Оған 15 шағын коммит жасады, әрқайсысы дерекқордың бөлек бөлігін қайта құрады - refactor/db-constraints бұтағын develop-ке біріктірді: git merge --squash refactor/db-constraints - develop-те барлық өзгерістер туралы толық сипаттамасы бар жаңа коммит жасады - Біріктіруден кейін refactor/db-constraints бұтағын жойған жоқ Осындай әрекеттердің кеңейтілген Git Flow және өзгерістер тарихын басқару тұрғысынан салдары қандай?
Git Flow жаңа қосымшаның релизін қалай құруды ұсынады? - Жаңа issue-тармағын жасау арқылы - Master-тан hotfix-тармағын жасау арқылы - Develop-тан бөлек релиз-тармағын жасау арқылы - Тікелей master тармағына commit жасау арқылы - Master тармағын тікелей develop-қа біріктіру арқылы
Негізгі репозиторийдің тарихында маңызды құпия деректерді қамтитын commit-тер бар екенін анықтадыңыз. Бұл деректерді репозиторийдің барлық тарихынан толық жою үшін келесі стратегияны қолдану дұрыс па: ағымдағы файлдардың нұсқасынан құпия деректерді жоятын жаңа commit құрып, оны main-ге жіберу. - Дұрыс, бірақ оңтайлы емес. git revert қолданған дұрыс - Шартты түрде дұрыс. Бұл уақытша шешім, егер деректерді жоюдың басқа радикалды әдісі табылмаса - Дұрыс емес және қауіпті. Деректер ағымдағы нұсқадан жойылады, бірақ тарихта қалады - Дұрыс емес. Мұндай commit басқа тармақтармен біріктіру кезінде жаңа қақтығыстарға әкелуі мүмкін - Дұрыс және қауіпсіз. Бұл әдіс деректердің жойылуын қамтамасыз етеді және олар репозиторийде қайта пайда болмайды
Сіз dev тармағында жаңа функциямен жұмыс істеп жатырсыз. Кенеттен, README.md файлына қате жазуды тез түзету үшін негізгі тармаққа шұғыл түрде ауысу қажеттілігі пайда болды. Сізде src/feature.js (жазылмаған) және styles/main.css (жазылған) файлдарында бірнеше өзгерістер бар. Барлық өзгерістерді уақытша сақтау және кейінірек dev тармағында оралу үшін қалай әрекет ету керек?
Розница дүкеніндегі тауар санаттары бойынша сатылымды талдау Сіз аналитик ретінде жұмыс істейсіз. Сіздің міндетіңіз — сатылым туралы есепті құру, есептеулермен: • санаттағы жалпы сатылған бірліктер саны; • жеңілдіктерді ескере отырып, жалпы кіріс, мұнда жеңілдік мынадай түрде қолданылады: unit_price × units_sold × (1 − discount/100). Егер жеңілдік жоқ (NULL), оны 0% деп есептеңіз; • бір сатылымдағы орташа бірлік саны, екі ондыққа дейін дөңгелектелген; • жеңілдіксіз сатылымдардың үлесі, NULL немесе 0% жеңілдікпен сатылымдар саны жалпы сатылымдар санына бөлінген, үш ондыққа дейін дөңгелектелген. Нәтижені алдымен total_revenue бойынша төменнен жоғарыға, содан кейін орташа бірлік саны бойынша жоғарыдан төменге, соңында санат атауы бойынша алфавиттік тәртіпте сұрыптаңыз.
Gin веб-рамкасымен жұмыс тәжірибеңіз бар ма? Оның көмегімен қандай тапсырмаларды шешкеніңізді айтып беріңіз.
[аты] мәтіндегі қателер мен стильді түзді: «Сәлем! Мен [аты], сен бұрын маған Telegram-ға өтуімді өтіндің — оны «сен» түрінде, бірақ құрметпен
PostgreSQL-да транзакцияның өнімділігін оңтайландыру үшін қандай минималды оқшаулау деңгейін орнату керек, онда: • параллель транзакциялар бір-бірінің аяқталмаған өзгерістерін көре алады; • "лақтыру оқылымдары" мүмкін. Осы мақсатқа жету үшін қандай оқшаулау деңгейін көрсету керек? PostgreSQL-да лас оқылым мүмкін емес Repeatable read Read uncommitted Read committed Serializable