ფიტნეს კლუბების ვიზიტების ანალიზი თქვენ მუშაობთ ფიტნეს კლუბების ქსელში ანალიტიკოსად. გაქვთ ინფორმაცია მომხმარებლების ვიზიტებზე და მათ მიერ შეძენილ აბონემენტებზე. საჭიროა აბონემენტების ეფექტიანობის ანალიზი. გაანგარიშეთ თითოეული აბონემენტის ტიპისთვის: • ამ ტიპის აბონემენტს გამოყენებული უნიკალური user_id-ების საერთო რაოდენობა; • ამ აბონემენტთან დაკავშირებული ვიზიტების საერთო რაოდენობა; • ამ აბონემენტის მომხმარებლების წილი საერთო მომხმარებელთა რაოდენობის პროცენტში (დასკვნითი ერთ ციფრზე). გამოთვლისთვის გამოიყენეთ ამ აბონემენტით გამოყენებული მომხმარებლების რაოდენობა საერთო უნიკალური მომხმარებლების რაოდენობასთან მიმართებაში. ყოველ მომხმარებელს შეიძლება ჰქონდეს მხოლოდ ერთი აბონემენტი. შედეგი sort-ით დაალაგეთ აბონემენტების ტიპის მიხედვით, ალფაბეტურ წესრიგში. შესავალი მონაცემები აბონემენტების სია: • membership_id (int) — უნიკალური აბონემენტის ID • user_id (int) — მომხმარებლის ID • membership_type (text) — აბონემენტის ტიპი ვიზიტების სია: • visit_id (int) — ვიზიტის უნიკალური ID • user_id (int) — მომხმარებლის ID • 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 bisect-ის პროცესში, თქვენ შეხვდით კომიტს, რომელიც ვერ შემოწმდება საჭირო გარემოს არარსებობის გამო. რა უნდა გააკეთოთ ამ სიტუაციაში? - გაიმეორეთ git bisect start ბრძანება სხვა ჰეშებით - გამოტოვეთ ეს კომიტი git bisect skip ბრძანებით - განაახლეთ bisect ბრძანებით git bisect reset - მონიშნეთ კომიტი როგორც კარგი git bisect good ბრძანებით - მონიშნეთ კომიტი როგორც ცუდი git bisect bad ბრძანებით
რომელი გამოთქმა [...] ადგილზე ავტომატურად გამოიწვევს ინდექსის შექმნას? მობილური პლატფორმაზე კოდის ჰორიზონტალური სლაიდი არსებობს create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
რატომ არ გამოიყენებს შემდეგი შეკითხვა ინდექსს, თუ records ცხრილში (id) შექმნილია ჩვეულებრივი B-Tree ინდექსი? select * from records where id % 2 = 0 - Id-ისთვის საჭიროა GIN ტიპის ინდექსი - ინდექსები არ მუშაობენ WHERE-ში გამოთვლებთან - % არის შედარების ოპერაცია, არა ფილტრაცია - limit და offset აუცილებელია ინდექსით ოპტიმიზაციისთვის - შეკითხვა მიმართავს რიცხვობრივ ველს, არა ტექსტს
გთხოვთ, ახსნათ, როგორ მუშაობს ტექნიკურად Git LFS და რა სარგებელს აძლევს მას სტანდარტული Git-ის შედარებით, როდესაც მუშაობთ დიდ ფაილებთან.
ანგარიში ლოჯისტიკური კომპანიისთვის თქვენ ხართ ლოჯისტიკური კომპანიის ანალიტიკოსი, რომელიც აკონტროლებს საწყობებზე ოპერაციების აღრიცხვას. თქვენ გჭირდებათ თითოეული საწყობის ეფექტიანობის შესახებ ანგარიში მოამზადოთ. თითოეული საწყობისთვის გამოთვალეთ: • საერთო ოპერაციების რაოდენობა (count_operations); • საწყობში დამუშავებული საქონლის საერთო რაოდენობა (sum_quantity); • ოპერაციის საშუალო დრო (avg_processing_time), მხოლოდ მითითებული დროის ოპერაციებისთვის (NULL არ უნდა იყოს), მთელი რიცხვამდე მოხაზული; • ერთ ოპერაციაში დამუშავებული საქონლის მაქსიმალური და მინიმალური რაოდენობა (max_quantity, min_quantity); • თითოეული ტიპის ოპერაციების რაოდენობა («მიწოდება», «გადაზიდვა», «გადანაწილება») ცალკეულ სვეტებში: supply_operations, shipment_operations, transfer_operations. ფილტრეთ საწყობები, სადაც საერთო ოპერაციების რაოდენობა მეტია 2-ზე და საშუალო დრო არ აღემატება 60 წუთს. შედეგი sort-ის მიხედვით დაალაგეთ საწყობის ID-ის მიხედვით ზრდადობით. შესავალი ფორმატი ოპერაციების სია: • 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) — «გადანაწილების» ოპერაციების რაოდენობა
სპეციალური თანმიმდევრობა შექმნილია სახელწოდებით 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-ს ახალი ვერსიის ოფიციალურად ფორმალიზება? - ახალი issue-შაქრის შექმნით - hotfix-შაქრის შექმნით master-დან - განახლების ცალკე შაქრის შექმნით develop-დან - პირდაპირ commit-ით master-შაქარში - პირდაპირ merge-ით master-შაქარი develop-თან
რომელი ქვემოთ მოცემული განცხადება ასახავს ამგვარი მოქმედებების შედეგებს გაფართოებული Git Flow-ის და ცვლილებების ისტორიის მართვის კუთხით?
თქვენ მუშაობთ ახალი ფუნქციის վրա dev დარგში. მოულოდნელად, საჭიროა სწრაფად გადახვიდეთ main დარგზე, რათა სწრაფად გამოასწოროთ წარწერის შეცდომა README.md ფაილში. გაქვთ რამდენიმე უცნობი ცვლილება: 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^
გაყიდვების ანალიზი კატეგორიების მიხედვით საცალო მაღაზიაში თქვენ მუშაობთ ანალიტიკოსად საცალო მაღაზიაში. თქვენი დავალებაა შეადგინოთ გაყიდვების ანგარიში კატეგორიების მიხედვით: • კატეგორიაში გაყიდული ერთეულების საერთო რაოდენობა (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 ფართო მონაცემი შეიძლება შეიცავდეს გამოტოვებულ მნიშვნელობებს: გამოსვლის ფორმატი საკითხი უნდა დააბრუნოს ცხრილი შემდეგი ველებით: • category (text) — პროდუქტის კატეგორია • total_units_sold (int) — საერთო გაყიდული ერთეულების რაოდენობა • total_revenue (numeric) — საერთო შემოსავალი კატეგორიის მიხედვით, განთავსებული ფასდაკლებებით, ორნიშნა დამდგმელი; • avg_units_per_sale (numeric) — საშუალო ერთეულების რაოდენობა ერთ შეკვეთაში, ორნიშნა დამდგმელი; • no_discount_share (numeric) — ფასდაკლებით არ გაყიდული გაყიდვების წილი, სამნიშნა დამდგმელი შედეგი პირველ რიგში დაალაგეთ შემცირებად total_revenue-ის მიხედვით, შემდეგ ზრდადობით საშუალო ერთეულების რაოდენობის (avg_units_per_sale), ბოლოს — კატეგორიის სახელის მიხედვით ალფავიტურად.
გიტის ძირითადი საცავის ისტორიაში არსებობს კომიტები, რომლებიც შეიცავენ კრიტიკულად მნიშვნელოვანი საიდუმლო მონაცემებს. ამ მონაცემების სრული ამოღება უნდა მოხდეს მთელი ისტორიისგან. შეაფასეთ, რამდენად სწორია და უსაფრთხოა შემდეგი სტრატეგიის გამოყენება: შექმენით ახალი კომიტი, რომელიც ამოიღებს საიდუმლო მონაცემებს მიმდინარე ფაილების ვერსიიდან და გამოაგზავნეთ მას main-ზე. - სწორია, მაგრამ არა ოპტიმალური. უკეთესია, გამოიყენოთ git revert კომიტების გასაფართოებლად - პირობითად სწორია. ეს დროებითი გადაწყვეტილებაა, სანამ არ იპოვით უფრო რადიკალურ საშუალებას მონაცემების ამოსაღებად - არასწორია და არასაიმედოა. მონაცემები ამოიღება მიმდინარე ვერსიიდან, მაგრამ დარჩება ხელმისაწვდომი ისტორიის განმავლობაში - არასწორია. ეს კომიტი შეიძლება გამოიწვიოს ახალი კონფლიქტები სხვა ფილიალებთან შერწყმის დროს - სწორია და უსაფრთხოა. ეს მეთოდი უზრუნველყოფს, რომ მონაცემები ამოიღება და აღარ გამოჩნდება რეპოზიტორიაში
გინ ვებ-ფრემვორკთან მუშაობის გამოცდილება გაქვთ? გთხოვთ, დეტალურად გვიამბოთ, რა დავალებებს აძლევდით მასთან ერთად.
PostgreSQL-ში ტრანზაქციების შესრულების ეფექტურობის გასაუმჯობესებლად საჭიროა მინიმალური იზოლაციის დონე გამოიყენოს, სადაც: • პარალელური ტრანზაქციები ხედავენ ერთმანეთის დასრულებამდე ცვლილებებს; • შესაძლებელია "დამაბნეველი კითხვა" (dirty read). რომელი იზოლაციის დონე უნდა მითითდეს ტრანზაქციისთვის, რათა მიაღწიოს ამ მიზანს? დამაბნეველი კითხვა შეუძლებელია PostgreSQL-ში repeatable read read uncommitted read committed serializable
ბოტების ტრეფიკის წილი ანტიფროდ გუნდი შეიმუშავა მექანიზმი ბოტების ტრეფიკის გამოვლენისათვის მაღაზიის საიტზე: როდესაც ბოტი შედის საიტზე, მის URL-ის პარამეტრებში ემატება ქვესრია "bot" (დიდა და პატარა ასოების განსხვავება არ არის). თუ user_id ერთდროულად მინიმუმ ერთხელ დეკემბერში არის დადგენილი როგორც ბოტი, ის ყოველთვის უნდა განიხილებოდეს როგორც ბოტი. შეისწავლეთ მომხმარებლების ვიზიტების მონაცემთა ნაკრები და გამოითვალეთ ბოტების წილი საერთო მომხმარებელთა რაოდენობის მიმართ დეკემბერში 2024 (დაწვრილებით ერთ ციფრამდე). შესავალი ფორმატი ტაბლია visits: - event_date (date) — ვიზიტის თარიღი - user_id (int) — უნიკალური მომხმარებლის იდენტიფიკატორი - url (string) — ბმული, რომლის მეშვეობითაც განხორციელდა ვიზიტი მონაცემები არ შეიცავს გამოტოვებულ ან არასწორ მნიშვნელობებს. გამოსვლის ფორმატი საკითხი უნდა დაბრუნდეს ცხრილი შემდეგ ველებით: - share (float) — ბოტების წილი საერთო მომხმარებელთა რაოდენობის მიმართ დეკემბერში, ერთ ციფრამდე დაწვრილებით.