გვჭირდება მონაცემთა ტბა? რა ვუყოთ მონაცემთა საწყობს?

ეს სტატია არის ჩემი სტატიის თარგმანი მედიუმზე - მონაცემთა ტბის დაწყება, რომელიც საკმაოდ პოპულარული აღმოჩნდა, ალბათ მისი სიმარტივის გამო. ამიტომ გადავწყვიტე დამეწერა რუსულად და ცოტა დავამატო, რომ ჩვეულებრივი ადამიანისთვის, რომელიც არ არის მონაცემთა სპეციალისტი, ნათლად გამეგო, რა არის მონაცემთა საწყობი (DW) და რა არის მონაცემთა ტბა (Data Lake) და როგორ. ერთად გავერთიანდეთ.

რატომ მინდოდა დამეწერა დათა ტბაზე? მე ვმუშაობ მონაცემებთან და ანალიტიკასთან 10 წელზე მეტი ხნის განმავლობაში და ახლა ნამდვილად ვმუშაობ დიდ მონაცემებთან Amazon Alexa AI-ში კემბრიჯში, რომელიც მდებარეობს ბოსტონში, თუმცა ვცხოვრობ ვიქტორიაში, ვანკუვერის კუნძულზე და ხშირად ვსტუმრობ ბოსტონს, სიეტლში. და ვანკუვერში და ზოგჯერ მოსკოვშიც კი ვსაუბრობ კონფერენციებზე. მეც დროდადრო ვწერ, მაგრამ ძირითადად ინგლისურად ვწერ და უკვე დავწერე ზოგიერთი წიგნიმე ასევე მჭირდება ჩრდილოეთ ამერიკიდან ანალიტიკური ტენდენციების გაზიარება და ზოგჯერ ვწერ ტელეგრამა.

მე ყოველთვის ვმუშაობდი მონაცემთა საწყობებთან და 2015 წლიდან დავიწყე მჭიდრო თანამშრომლობა Amazon Web Services-თან და ზოგადად გადავედი ღრუბლოვან ანალიტიკაზე (AWS, Azure, GCP). მე ვაკვირდები ანალიტიკური გადაწყვეტილებების ევოლუციას 2007 წლიდან და ვმუშაობდი მონაცემთა საწყობის გამყიდველ Teradata-შიც კი და განვახორციელე იგი Sberbank-ში და სწორედ მაშინ გამოჩნდა Big Data with Hadoop. ყველამ დაიწყო იმის თქმა, რომ შენახვის ეპოქა გავიდა და ახლა ყველაფერი Hadoop-ზე იყო, შემდეგ კი ისევ მონაცემთა ტბაზე დაიწყეს საუბარი, რომ ახლა მონაცემთა საწყობის დასასრული ნამდვილად დადგა. მაგრამ საბედნიეროდ (შესაძლოა, ზოგიერთისთვის, ვინც დიდი ფული გამოიმუშავა Hadoop-ის შექმნისას), მონაცემთა საწყობი არ გაქრა.

ამ სტატიაში განვიხილავთ რა არის მონაცემთა ტბა. ეს სტატია განკუთვნილია იმ ადამიანებისთვის, რომლებსაც აქვთ მცირე ან არანაირი გამოცდილება მონაცემთა საწყობებთან.

სურათზე ბლედის ტბაა, ეს ჩემი ერთ-ერთი საყვარელი ტბაა, თუმცა იქ მხოლოდ ერთხელ ვიყავი, მთელი ცხოვრება მახსოვდა. მაგრამ ჩვენ ვისაუბრებთ სხვა ტიპის ტბაზე - მონაცემთა ტბაზე. შესაძლოა ბევრ თქვენგანს უკვე არაერთხელ გსმენიათ ამ ტერმინის შესახებ, მაგრამ კიდევ ერთი განმარტება არავის ზიანს არ მიაყენებს.

უპირველეს ყოვლისა, აქ არის მონაცემთა ტბის ყველაზე პოპულარული განმარტებები:

"ყველა ტიპის ნედლეული მონაცემების ფაილების შენახვა, რომელიც ხელმისაწვდომია ნებისმიერი ორგანიზაციის ანალიზისთვის" - მარტინ ფაულერი.

”თუ ფიქრობთ, რომ მონაცემთა მარტი არის წყლის ბოთლი - გაწმენდილი, შეფუთული და შეფუთული მოსახერხებელი მოხმარებისთვის, მაშინ მონაცემთა ტბა არის წყლის უზარმაზარი რეზერვუარი მისი ბუნებრივი ფორმით. მომხმარებლებო, მე შემიძლია საკუთარი თავისთვის წყლის შეგროვება, ღრმად ჩაძირვა, გამოკვლევა“ - ჯეიმს დიქსონი.

ახლა ჩვენ ზუსტად ვიცით, რომ მონაცემთა ტბა ეხება ანალიტიკას, ის გვაძლევს საშუალებას შევინახოთ დიდი რაოდენობით მონაცემები თავდაპირველ ფორმაში და გვაქვს საჭირო და მოსახერხებელი წვდომა მონაცემებზე.

ხშირად მიყვარს საგნების გამარტივება, თუ რთული ტერმინის ახსნა შემიძლია მარტივი სიტყვებით, მაშინ მე მესმის, როგორ მუშაობს და რისთვის არის საჭირო. ერთ დღეს, iPhone-ის ფოტო გალერეაში ვზივარ და გამთენიისას, ეს ნამდვილი მონაცემთა ტბაა, კონფერენციებისთვის სლაიდიც კი გავაკეთე:

ყველაფერი ძალიან მარტივია. ვიღებთ ფოტოს ტელეფონში, ფოტო ინახება ტელეფონში და შეიძლება შეინახოს iCloud-ში (ფაილის ღრუბლოვანი შენახვა). ტელეფონი ასევე აგროვებს ფოტო მეტამონაცემებს: რა არის ნაჩვენები, გეო ტეგი, დრო. შედეგად ჩვენ შეგვიძლია გამოვიყენოთ iPhone-ის მოსახერხებელი ინტერფეისი ჩვენი ფოტოს საპოვნელად და ინდიკატორებსაც კი ვხედავთ, მაგალითად, როდესაც ვეძებ ფოტოებს სიტყვა ცეცხლით, ვპოულობ 3 ფოტოს ცეცხლის გამოსახულებით. ჩემთვის ეს არის ბიზნეს დაზვერვის ინსტრუმენტი, რომელიც მუშაობს ძალიან სწრაფად და ზუსტად.

და რა თქმა უნდა, არ უნდა დავივიწყოთ უსაფრთხოება (ავტორიზაცია და ავტორიზაცია), წინააღმდეგ შემთხვევაში ჩვენი მონაცემები ადვილად შეიძლება მოხვდეს საზოგადოებრივ დომენში. ბევრი სიახლეა მსხვილ კორპორაციებსა და სტარტაპებზე, რომელთა მონაცემებიც საჯარო გახდა დეველოპერების დაუდევრობისა და მარტივი წესების შეუსრულებლობის გამო.

ასეთი მარტივი სურათიც კი გვეხმარება წარმოვიდგინოთ რა არის მონაცემთა ტბა, მისი განსხვავებები მონაცემთა ტრადიციული საწყობისგან და მისი ძირითადი ელემენტები:

1. იტვირთება მონაცემები (გადაყლაპვა) არის მონაცემთა ტბის ძირითადი კომპონენტი. მონაცემთა საწყობში შეყვანა შესაძლებელია ორი გზით - პარტიული (ჩატვირთვა ინტერვალებით) და ნაკადი (მონაცემთა ნაკადი).
2. ფაილის შენახვა (საცავი) არის მონაცემთა ტბის მთავარი კომპონენტი. ჩვენ გვჭირდებოდა საცავი, რომ ყოფილიყო ადვილად მასშტაბირებადი, უკიდურესად საიმედო და დაბალი ღირებულება. მაგალითად, AWS-ში ეს არის S3.
3. კატალოგი და ძებნა (კატალოგი და ძებნა) - იმისათვის, რომ თავიდან ავიცილოთ Data Swamp (ეს არის ის, როდესაც ჩვენ ყველა მონაცემს ერთ გროვაში ვყრით და შემდეგ შეუძლებელია მასთან მუშაობა), უნდა შევქმნათ მეტამონაცემების ფენა, რათა მოხდეს მონაცემების კლასიფიკაცია. რათა მომხმარებლებმა ადვილად იპოვონ ანალიზისთვის საჭირო მონაცემები. გარდა ამისა, შეგიძლიათ გამოიყენოთ დამატებითი საძიებო გადაწყვეტილებები, როგორიცაა ElasticSearch. ძებნა მომხმარებელს ეხმარება მოძებნოს საჭირო მონაცემები მოსახერხებელი ინტერფეისის საშუალებით.
4. დამუშავება (პროცესი) - ეს ნაბიჯი პასუხისმგებელია მონაცემთა დამუშავებასა და ტრანსფორმაციაზე. ჩვენ შეგვიძლია მონაცემთა გარდაქმნა, მისი სტრუქტურის შეცვლა, გაწმენდა და მრავალი სხვა.
5. უსაფრთხოების (უსაფრთხოება) - მნიშვნელოვანია დროის დახარჯვა გადაწყვეტის უსაფრთხოების დიზაინზე. მაგალითად, მონაცემთა დაშიფვრა შენახვის, დამუშავებისა და ჩატვირთვის დროს. მნიშვნელოვანია ავთენტიფიკაციისა და ავტორიზაციის მეთოდების გამოყენება. და ბოლოს, საჭიროა აუდიტის ინსტრუმენტი.

პრაქტიკული თვალსაზრისით, ჩვენ შეგვიძლია დავახასიათოთ მონაცემთა ტბა სამი ატრიბუტით:

1. შეაგროვეთ და შეინახეთ ყველაფერი — მონაცემთა ტბა შეიცავს ყველა მონაცემს, როგორც დაუმუშავებელ დაუმუშავებელ მონაცემებს დროის ნებისმიერი პერიოდისთვის, ასევე დამუშავებულ/გასუფთავებულ მონაცემებს.
2. ღრმა სკანირება — მონაცემთა ტბა მომხმარებლებს საშუალებას აძლევს შეისწავლონ და გააანალიზონ მონაცემები.
3. მოქნილი წვდომა — მონაცემთა ტბა უზრუნველყოფს მოქნილ წვდომას სხვადასხვა მონაცემებსა და სხვადასხვა სცენარებზე.

ახლა ჩვენ შეგვიძლია ვისაუბროთ განსხვავებაზე მონაცემთა საწყობსა და მონაცემთა ტბას შორის. როგორც წესი, ხალხი ეკითხება:

• რაც შეეხება მონაცემთა საწყობს?
• ვცვლით მონაცემთა საწყობს მონაცემთა ტბით თუ ვაფართოვებთ მას?
• ჯერ კიდევ შესაძლებელია მონაცემთა ტბის გარეშე?

მოკლედ, მკაფიო პასუხი არ არსებობს. ეს ყველაფერი დამოკიდებულია კონკრეტულ სიტუაციაზე, გუნდის უნარებსა და ბიუჯეტზე. მაგალითად, მონაცემთა საწყობის მიგრაცია Oracle-ში AWS-ზე და მონაცემთა ტბის შექმნა Amazon-ის შვილობილი კომპანიის მიერ - Woot - ჩვენი მონაცემთა ტბის ისტორია: როგორ ააშენა Woot.com-მა სერვერის გარეშე მონაცემთა ტბა AWS-ზე.

მეორეს მხრივ, გამყიდველი Snowflake ამბობს, რომ აღარ გჭირდებათ მონაცემთა ტბაზე ფიქრი, რადგან მათი მონაცემთა პლატფორმა (2020 წლამდე ეს იყო მონაცემთა საწყობი) საშუალებას გაძლევთ დააკავშიროთ როგორც მონაცემთა ტბა, ასევე მონაცემთა საწყობი. Snowflake-თან ბევრი არ მიმუშავია და ეს მართლაც უნიკალური პროდუქტია, რომელსაც ამის გაკეთება შეუძლია. საკითხის ფასი სხვა საკითხია.

დასასრულს, ჩემი პირადი აზრია, რომ ჩვენ ჯერ კიდევ გვჭირდება მონაცემთა საწყობი, როგორც მონაცემთა ძირითადი წყარო ჩვენი მოხსენებისთვის, და რაც არ ჯდება, ჩვენ ვინახავთ მონაცემთა ტბაში. ანალიტიკის მთელი როლი არის ბიზნესისთვის მარტივი წვდომის უზრუნველყოფა გადაწყვეტილების მისაღებად. რაც არ უნდა ითქვას, ბიზნეს მომხმარებლები უფრო ეფექტურად მუშაობენ მონაცემთა საწყობთან, ვიდრე მონაცემთა ტბაზე, მაგალითად ამაზონში - არის Redshift (ანალიტიკური მონაცემთა საწყობი) და არის Redshift Spectrum/Athena (SQL ინტერფეისი მონაცემთა ტბისთვის S3-ზე დაყრდნობით. Hive/Presto). იგივე ეხება სხვა თანამედროვე ანალიტიკურ მონაცემთა საწყობებს.

მოდით შევხედოთ მონაცემთა საწყობის ტიპურ არქიტექტურას:

ეს არის კლასიკური გადაწყვეტა. ჩვენ გვაქვს წყაროს სისტემები, ETL/ELT-ის გამოყენებით ვაკოპირებთ მონაცემებს ანალიტიკურ მონაცემთა საწყობში და ვუკავშირდებით მას Business Intelligence-ის გადაწყვეტას (ჩემი ფავორიტი არის Tableau, რაც შეეხება თქვენსას?).

ამ გამოსავალს აქვს შემდეგი უარყოფითი მხარეები:

• ETL/ELT ოპერაციებს დრო და რესურსები სჭირდება.
• როგორც წესი, ანალიტიკურ მონაცემთა საწყობში მონაცემთა შესანახი მეხსიერება არ არის იაფი (მაგალითად, Redshift, BigQuery, Teradata), რადგან ჩვენ გვჭირდება მთელი კლასტერის ყიდვა.
• ბიზნეს მომხმარებლებს აქვთ წვდომა გასუფთავებულ და ხშირად გაერთიანებულ მონაცემებზე და არ აქვთ წვდომა ნედლეულ მონაცემებზე.

რა თქმა უნდა, ეს ყველაფერი დამოკიდებულია თქვენს შემთხვევაზე. თუ არ გაქვთ პრობლემები თქვენს მონაცემთა საწყობთან, მაშინ მონაცემთა ტბა საერთოდ არ გჭირდებათ. მაგრამ როდესაც პრობლემები წარმოიქმნება სივრცის ნაკლებობის, სიმძლავრის ან ფასის ნაკლებობასთან დაკავშირებით, მაშინ შეგიძლიათ განიხილოთ მონაცემთა ტბის ვარიანტი. სწორედ ამიტომ არის მონაცემთა ტბა ძალიან პოპულარული. აქ მოცემულია მონაცემთა ტბის არქიტექტურის მაგალითი:

მონაცემთა ტბის მიდგომის გამოყენებით, ჩვენ ვტვირთავთ ნედლეულ მონაცემებს ჩვენს მონაცემთა ტბაში (სერიული ან ნაკადი), შემდეგ ვამუშავებთ მონაცემებს საჭიროებისამებრ. მონაცემთა ტბა საშუალებას აძლევს ბიზნეს მომხმარებლებს შექმნან მონაცემთა საკუთარი ტრანსფორმაციები (ETL/ELT) ან გააანალიზონ მონაცემები Business Intelligence გადაწყვეტილებებში (თუ საჭირო დრაივერი ხელმისაწვდომია).

ნებისმიერი ანალიტიკური გადაწყვეტის მიზანია მოემსახუროს ბიზნეს მომხმარებლებს. ამიტომ, ჩვენ ყოველთვის უნდა ვიმუშაოთ ბიზნესის მოთხოვნების შესაბამისად. (ამაზონში ეს არის ერთ-ერთი პრინციპი - უკუღმა მუშაობა).

როგორც მონაცემთა საწყობთან, ასევე მონაცემთა ტბასთან მუშაობისას, ჩვენ შეგვიძლია შევადაროთ ორივე გამოსავალი:

მთავარი დასკვნის გამოტანა არის ის, რომ მონაცემთა საწყობი კონკურენციას კი არ უწევს მონაცემთა ტბას, არამედ ავსებს მას. მაგრამ თქვენი გადასაწყვეტია, რა არის სწორი თქვენი საქმისთვის. ყოველთვის საინტერესოა საკუთარი თავის გამოცდა და სწორი დასკვნების გამოტანა.

ასევე მინდა გითხრათ ერთ-ერთი შემთხვევა, როდესაც დავიწყე მონაცემთა ტბის მიდგომის გამოყენება. ყველაფერი საკმაოდ ტრივიალურია, მე შევეცადე გამომეყენებინა ELT ინსტრუმენტი (ჩვენ გვქონდა Matillion ETL) და Amazon Redshift, ჩემი გამოსავალი მუშაობდა, მაგრამ არ შეესაბამება მოთხოვნებს.

მე მჭირდებოდა ვებ ჟურნალების აღება, მათი გარდაქმნა და მათი გაერთიანება, რათა მომეწოდებინა მონაცემები 2 შემთხვევისთვის:

1. მარკეტინგის გუნდს სურდა ბოტების აქტივობის ანალიზი SEO-სთვის
2. IT-ს სურდა ვებსაიტის მუშაობის მეტრიკის ნახვა

ძალიან მარტივი, ძალიან მარტივი ჟურნალები. აი მაგალითი:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

ერთი ფაილი იწონიდა 1-4 მეგაბაიტს.

მაგრამ იყო ერთი სირთულე. ჩვენ გვქონდა 7 დომენი მთელს მსოფლიოში და ერთ დღეში შეიქმნა 7000 ათასი ფაილი. ეს არ არის ბევრად მეტი მოცულობა, მხოლოდ 50 გიგაბაიტი. მაგრამ ჩვენი Redshift კლასტერის ზომა ასევე მცირე იყო (4 კვანძი). ერთი ფაილის ტრადიციული გზით ჩატვირთვას დაახლოებით ერთი წუთი დასჭირდა. ანუ პრობლემა არ მოგვარებულა პირდაპირ. და ეს იყო შემთხვევა, როდესაც გადავწყვიტე გამომეყენებინა მონაცემთა ტბის მიდგომა. გამოსავალი ასე გამოიყურებოდა:

ეს საკმაოდ მარტივია (მინდა აღვნიშნო, რომ ღრუბელში მუშაობის უპირატესობა არის სიმარტივე). Მე გამოვიყენე:

• AWS Elastic Map Reduce (Hadoop) გამოთვლითი სიმძლავრისთვის
• AWS S3, როგორც ფაილის საცავი, მონაცემთა დაშიფვრის და წვდომის შეზღუდვის შესაძლებლობით
• Spark როგორც InMemory გამოთვლითი ძალა და PySpark ლოგიკისა და მონაცემთა ტრანსფორმაციისთვის
• პარკეტი სპარკის შედეგად
• AWS Glue Crawler, როგორც მეტამონაცემების შემგროვებელი ახალი მონაცემებისა და დანაყოფების შესახებ
• Redshift Spectrum, როგორც SQL ინტერფეისი მონაცემთა ტბაზე Redshift არსებული მომხმარებლებისთვის

ყველაზე პატარა EMR+Spark კლასტერმა დაამუშავა ფაილების მთელი დასტა 30 წუთში. არის AWS-ის სხვა შემთხვევები, განსაკუთრებით ბევრი დაკავშირებულია Alexa-სთან, სადაც ბევრი მონაცემია.

ახლახან გავიგე, რომ მონაცემთა ტბის ერთ-ერთი მინუსი არის GDPR. პრობლემა ის არის, როდესაც კლიენტი ითხოვს მის წაშლას და მონაცემები ერთ-ერთ ფაილშია, ჩვენ არ შეგვიძლია გამოვიყენოთ მონაცემთა მანიპულირების ენა და DELETE ოპერაცია, როგორც მონაცემთა ბაზაში.

იმედი მაქვს, ამ სტატიამ განმარტა განსხვავება მონაცემთა საწყობსა და მონაცემთა ტბას შორის. თუ გაინტერესებთ, შემიძლია ვთარგმნო მეტი ჩემი სტატია ან პროფესიონალების სტატიები, რომლებიც წავიკითხე. და ასევე გითხრათ გადაწყვეტილებების შესახებ, რომლებთანაც ვმუშაობ და მათ არქიტექტურაზე.

წყარო: www.habr.com