36-წუთიანი სამუშაო სესია მონაცემების ანალიტიკურ მხარეზე: რატომ სჭირდება ანალიტიკას საკუთარი საცავი, საწყობი vs ტბა vs ლეიკჰაუსი, განზომილებრივი მოდელირება და ვარსკვლავური სქემა, რატომ ახდენენ ანალიტიკოსები დენორმალიზაციას განზრახ, და თანამედროვე სტეკი, რომელიც მონაცემებს იღებს, გარდაქმნის და აწვდის.
თქვენი აპლიკაციის ბაზა მორგებულია იმაზე, რომ სწრაფად წაიკითხოს და ჩაწეროს რამდენიმე სტრიქონი — ერთი კლიენტი, ერთი შეკვეთა. ანალიტიკა საპირისპირო კითხვას სვამს: დაასკანირე მილიონობით სტრიქონი და შეაჯამე. გაუშვით ეს ცოცხალი აპლიკაციის ბაზაზე და რეალურ მომხმარებლებს შეანელებთ, პასუხებსაც ნელა მიიღებთ. გამოსავალი მეორე, სპეციალურად ამისთვის აგებული საცავია.
სტრიქონულ და სვეტოვან საცავებს შიგნიდან Databases & SQL-ში განვიხილავდით; აქ იმას ვაგრძელებთ. მოკლედ: ანალიტიკური საწყობები სვეტოვანია — თითოეულ სვეტს ერთად ინახავენ, ამიტომ შეკითხვა, რომელიც 200-იდან 3 სვეტს ეხება, მხოლოდ იმ 3-ს კითხულობს და ძლიერად კუმშავს.
ორი საცავი, ორი სამუშაო. პაიპლაინი მონაცემებს აპის ბაზიდან საწყობში აკოპირებს, რომ ანალიტიკა პროდაქშენს არასდროს შეეხოს.
ჰგავს დატვირთულ სარესტორნო სამზარეულოს (OLTP) ბუღალტრის უკანა ოფისთან (OLAP) შედარებით: წლის ანგარიშს სადილის პიკის დროს სამზარეულოში არ ავსებთ.
სანამ რამეს დაამოდელირებთ, ირჩევთ, სად ინახება ანალიტიკური მონაცემები. სამი ვარიანტი ერთმანეთის მოწინააღმდეგე რელიგია არაა — ისინი ერთ ხაზზე დგანან: სტრუქტურირებული & მართული-დან ღია & მოქნილი-მდე, ხოლო ლეიკჰაუსი ორივეს მიღწევის თანამედროვე მცდელობაა.
მარცხნიდან მარჯვნივ: სუფთა ცხრილები, რომლებიც უნდა ჩატვირთოთ; ნედლი ფაილები, სადაც ყველაფრის ჩაყრა შეიძლება; და ლეიკჰაუსი — ცხრილების შრე, რომელიც ტბის ღია ფაილებს სტრუქტურასა და ტრანზაქციებს მატებს.
მონაცემები განსაზღვრულ ცხრილებსა და სვეტებში იტვირთება მანამ, სანამ შეკითხვას დასვამთ (schema-on-write). შენახვის ფორმატს ძრავა ფლობს, ამიტომ SQL სწრაფია და მართვა მარტივი.
გამოიყენეთ, როცა თქვენი ანალიტიკა ძირითადად ცხრილოვანია და ოპერაციული თავსატეხი მინიმალური გინდათ — ჩვეულებრივი საწყისი წერტილი.
ჩაყარეთ ნებისმიერი რამ ობიექტურ საცავში (S3, GCS, Azure Blob) და სტრუქტურა მოგვიანებით, წაკითხვისას გადაწყვიტეთ (schema-on-read). შესანიშნავია მოცულობისა და მრავალფეროვნებისთვის; სუსტია ad-hoc SQL-სა და თანმიმდევრულობაში.
გამოიყენეთ, როცა გაქვთ უზარმაზარი ან ნახევრად სტრუქტურირებული მონაცემები (მოვლენები, ფაილები) და ML/კვლევითი დატვირთვები.
ღია ცხრილის ფორმატი — Apache Iceberg ან Delta Lake — დგას ტბაში არსებულ Parquet ფაილებზე და თვალს ადევნებს, რომელი ფაილი რომელ ცხრილს ეკუთვნის, პლუს ტრანზაქციების ლოგს. იღებთ ACID-ის მსგავს ტრანზაქციებს, სქემის ევოლუციასა და დროში მოგზაურობას ღია საცავზე, რომელსაც ბევრი ძრავა კითხულობს.
გამოიყენეთ, როცა გინდათ მონაცემების ერთი ღია ასლი, რომელიც SQL ანალიტიკასაც ემსახურება და ML-საც, დუბლირებაში გადახდის გარეშე.
აპლიკაციის ბაზები დუბლირების თავიდან ასაცილებლადაა მოდელირებული. ანალიტიკა კი მოდელირდება გასაგებობისა და სისწრაფისთვის: სამყარო გაყავით მოვლენებად, რომლებსაც ზომავთ და იმად, რის მიხედვითაც ჭრით. სწორედ ეს გაყოფაა განზომილებრივი მოდელირება, მისი ფორმა კი ვარსკვლავური სქემაა — Kimball-ის მეთოდი, რომელიც BI-ში დღემდე დომინირებს.
ეს არის ვარსკვლავი: შუაში ერთი ფაქტების ცხრილი, წვეროებზე — განზომილებების ცხრილები. ყოველი join არის ფაქტი → განზომილება, ერთი ნაბიჯი.
გრანულარობა არის ის, თუ რას ნიშნავს ფაქტების ცხრილის ერთი სტრიქონი — "ერთი პოზიცია ერთ შეკვეთაში" თუ "ერთი პროდუქტის გაყიდვები ერთ მაღაზიაში ერთ დღეს". აირჩიეთ ის აშკარად და ადრე: დანარჩენი ყველაფერი (რომელი განზომილებები მიება, რომელ საზომებს აქვს აზრი) გრანულარობიდან გამომდინარეობს, სხვადასხვა გრანულარობის ერთ ცხრილში შერევა კი მოდელირების კლასიკური ბაგია.
დაიწყეთ რეალური პროცესით, რომელიც ბიზნესს აინტერესებს — შეკვეთები, გზავნილები, რეგისტრაციები, მხარდაჭერის თიქეთები. თითოეული პროცესი ცალკე ფაქტების ცხრილად იქცევა. ნუ დაამოდელირებთ "მთელ კომპანიას" ერთბაშად; კარგად დაამოდელირეთ ერთი პროცესი.
გრანულარობა ერთი წინადადებით თქვით: ერთი სტრიქონი შეკვეთის ერთ პოზიციაზე. ჩვეულებრივ ყველაზე წვრილი პრაქტიკული გრანულარობაა საუკეთესო — უფრო მსხვილ ხედამდე ყოველთვის შეგიძლიათ შეაჯამოთ, მაგრამ წინასწარ აგრეგირებული სტრიქონის უკან დაშლა ვეღარასდროს მოახერხებთ.
ჩამოწერეთ, როგორ აღწერენ და ფილტრავენ ადამიანები მოვლენას: თარიღით, პროდუქტით, კლიენტით, მაღაზიით, არხით. თითოეული ხდება განზომილების ცხრილი, გასაღებით ფაქტში ჩამაგრებული. თუ ის პასუხობს კითხვას "რის მიხედვით?", ეს განზომილებაა.
ჩამოწერეთ რიცხვითი საზომები იმ გრანულარობაზე — რაოდენობა, თანხა, ფასდაკლება, გადასახადი. კარგი საზომები შეჯამებადია: ისინი სწორად იკრიბება ყველა განზომილების გასწვრივ. შეფარდებები და პროცენტები შეკითხვისას გამოითვლება, არ ინახება.
Databases & SQL-ში ვთქვით: ნორმალიზება ზედმეტობის მოსაკლავად, დენორმალიზება მხოლოდ მაშინ, როცა გაზომილი წაკითხვის პრობლემა გაიძულებთ. ანალიტიკა ამ ნაგულისხმევს აბრუნებს. წაკითხვა აქ მთავარი აზრია, ჩაწერა კი პარტიულად კონტროლდება, ამიტომ ცხრილებს განზრახ ვაფართოებთ, რომ შეკითხვები მარტივი და სწრაფი იყოს.
dim_product-შია). თოვლის ფანტელის სქემა განზომილებებს ქვეცხრილებად ნორმალიზებს (პროდუქტი → კატეგორია → დეპარტამენტი). ვარსკვლავი გარკვეულ ზედმეტობას ნაკლებ join-ებში ცვლის; ანალიტიკაში ეს გარიგება ჩვეულებრივ ღირს.კატეგორიის ტექსტი არსად დუბლირდება — სამაგიეროდ ყოველი შეკითხვა თავიდან აერთებს სამ ცხრილს, რომ ერთი პროდუქტის კატეგორია წაიკითხოს.
კატეგორიაც და დეპარტამენტიც პირდაპირ განზომილებაშია. ერთი join, სვეტოვანი შეკუმშვა კი გამეორებას თითქმის უფასოდ აქცევს.
ზოგი გუნდი კიდევ უფრო შორს მიდის და ფაქტს განზომილებებთან ერთად წინასწარ აერთებს ერთ One Big Table-ად (OBT / "ფართო ცხრილი") — ერთი სტრიქონი ერთ მოვლენაზე, ყველა აღწერითი სვეტით უკვე მიბმული. შეკითხვისას join-ები საერთოდ არაა; BI ინსტრუმენტებს ეს უყვართ. ფასი კი ზედმეტობა და ხელახლა აგებაა განზომილების ცვლილებისას — რაც არაუშავს, რადგან ხელახლა აგებას გარდაქმნის შრე (შემდეგი სექცია) ფლობს.
OBT join-ებს აგების ეტაპზე გადაისვრის, ისე რომ შეკითხვას საერთოდ არ რჩება.
საწყობი ცენტრია, მაგრამ არა მთელი სურათი. მის გარშემო დგას შრეების უკვე სტანდარტული ნაკრები — "თანამედროვე მონაცემთა სტეკი". მონაცემების გადატანის მექანიკა ETL & ELT Pipelines-ში განვიხილეთ; აქ ვნახავთ, როგორ ეწყობა ეს ნაწილები საწყობის ირგვლივ.
კონექტორები ნედლს შემოიტანენ; dbt საწყობის შიგნით ნედლს → სტეიჯინგად → მარტებად აქცევს; BI და ML მარტებს კითხულობენ. ყველაფერი "ნედლის" შემდეგ არის SQL ვერსიების კონტროლში.
dbt არის ის ადგილი, სადაც მე-3 ნაწილის ვარსკვლავური სქემა რეალურად შენდება. თქვენ წერთ SELECT გამოსახულებებს; dbt მათ ცხრილების/ხედების დამოკიდებულების გრაფად მართავს, ტესტებითა და დოკუმენტაციით. გავრცელებული დაშრევება: staging (წყაროების მსუბუქად გაწმენდილი ასლები) → marts (ფაქტები და განზომილებები, რომლებსაც ანალიტიკოსები ეკითხებიან). ზოგი გუნდი ამ საფეხურებს bronze / silver / gold-ს ეძახის — იგივე აზრია.
ref() დამოკიდებულებებს აბამს, ასე რომ dbt-მ იცის აგების რიგი.ref() დამოკიდებულებებს აშკარას ხდის; dbt თვითონ ითვლის აგების რიგს და შედეგის ტესტირებაც შეუძლია.
სტეკის ცენტრი საწყობი ან ძრავაა. 2026 წელს ბაზრის დიდ ნაწილს ხუთი სახელი ფარავს, თითოეულს კი მკაფიო ძლიერი ადგილი აქვს. შემდეგ მოდის dbt მოდელირებისთვის და BI ინსტრუმენტი, რომ ეს ყველაფერი ადამიანებს თვალწინ დაუდოს.
დადებითი — საცავს გამოთვლისგან აცალკევებს, მართვა მარტივია, ძლიერი გაზიარება და მმართველობა; უსაფრთხო ნაგულისხმევი არჩევანი SQL ანალიტიკისთვის.
უარყოფითი — მოხმარებაზე მიბმული ფასი უყურადღებო შეკითხვებთან ერთად იზრდება; ეს მართული სერვისია, რომელსაც თვითონ ვერ დაიჰოსტავთ.
დადებითი — სრულად სერვერლესი: კლასტერების ზომას არ არჩევთ, მყისიერად მასშტაბირდება, ღრმა ინტეგრაცია Google Cloud-სა და ML-თან.
უარყოფითი — მოთხოვნისამებრ ფასი დასკანირებულ ბაიტზეა, ამიტომ SELECT *-ის ჩვევა ძვირი ჯდება; და GCP-ზეა ორიენტირებული.
დადებითი — მომწიფებული, მჭიდროდ ინტეგრირებული AWS-თან; კარგია, როცა თქვენი მონაცემები და გუნდი უკვე AWS-ში ცხოვრობს.
უარყოფითი — სერვერლეს ვარიანტებზე მეტ კლასტერის დაყენებას ითხოვს; ისტორიულად მეტი სამართავი პარამეტრი აქვს.
დადებითი — ლეიკჰაუსის ლიდერი (Delta Lake + Spark): ერთი პლატფორმა SQL-ის, დიდი მონაცემებისა და ML-ისთვის ღია ფაილებზე.
უარყოფითი — სუფთა საწყობზე უფრო ფართო და რთულია; მხოლოდ SQL-ის გუნდს მეტი ცნების სწავლა მოუწევს.
დადებითი — უკიდურესად სწრაფი ღია კოდის სვეტოვანი ძრავა; შესანიშნავია დიდი მოცულობის, დაბალი შეყოვნების ანალიტიკისა და მომხმარებლისთვის ხილული დაშბორდებისთვის.
უარყოფითი — გარდაქმნებში, join-ებსა და ეკოსისტემაში უფრო მწირია; ის უფრო შეკითხვების ძრავაა, ვიდრე სრული მართული საწყობი.
დადებითი — საწყობში მოდელირების სტანდარტი: ვერსიაკონტროლირებული SQL ტესტებით, დოკუმენტაციითა და lineage-ით; მას ანალიტიკოსები ფლობენ.
უარყოფითი — მხოლოდ გარდაქმნა — არ იღებს, არ ინახავს და არ განრიგებს; ის საწყობის თავზე დგას.
BI ინსტრუმენტი საწყობის ცხრილებს დაშბორდებად და თვითმომსახურე კვლევად აქცევს. გავრცელებული არჩევანი: Looker (მართული სემანტიკური მოდელი — მეტრიკების ცენტრალური განსაზღვრებები, ძლიერია დიდი ორგანიზაციებისთვის), Metabase (მსუბუქი, ღია კოდის, გუნდებს სწრაფად ამუშავებს თვითმომსახურებაზე) და Tableau / Power BI (მდიდარი ვიზუალური ანალიზი, ფართოდ დანერგილი კორპორაციებში).
ავაგოთ საცალო გაყიდვების ვარსკვლავი თავიდან ბოლომდე: განვსაზღვროთ ფაქტი, მივაბათ განზომილებები და შემდეგ დავსვათ რეალური ბიზნეს-კითხვა ერთი სუფთა შეკითხვით.
ერთი ფაქტი, სამი ერთნაბიჯიანი join, ორი ფილტრი, ერთი group-by. სწორედ ეს წაკითხვადობაა განზომილებრივი მოდელირების მთელი აზრი.
"მონაცემები ისე დაამოდელირეთ, როგორც ხალხი სვამს კითხვებს, და არა ისე, როგორც აპლიკაცია ინახავს."
— მთელი მოხსენება, შეკუმშული
ხუთი სწრაფი კითხვა OLAP-ზე, საცავის არჩევანზე, განზომილებრივ მოდელირებასა და თანამედროვე სტეკზე — მყისიერი პასუხი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში