მონაცემთა ერთ-ერთი პლატფორმა: მონაცემთა პლატფორმების დიზაინი მასშტაბური განზრახვით [ნაწილი 2]

[ ] ICYMI წაიკითხეთ ნაწილი 1 Unscalable მონაცემთა პლატფორმა დღეს ბევრი მონაცემთა პლატფორმა შექმნილია ქვემოდან ზევით, დაწყებული მონაცემების შეგროვებით, რომელიც „შეიძლება მოგვიანებით იყოს სასარგებლო“ და საჭიროებისამებრ გადაწყვეტილებების თანდათანობით შესწორებით. ეს მიდგომა აუცილებლად იწვევს ფრაგმენტულ განხორციელებას, მზარდ ღირებულებებს და ტექნიკურ დავალიანებას. მონაცემთა სისტემის დიზაინი მოითხოვს სპეციალიზებულ გამოცდილებას მონაცემთა მოდელირების, განაწილებული სისტემების, უსაფრთხოებისა და შესაბამისობის სფეროში. კომპანიების უმეტესობას უბრალოდ არ შეუძლია შეიძინოს ერთგულ მონაცემთა ინფრასტრუქტურის გუნდები ადრეულ დღეებში და უნდა შექმნან და ადაპტირდნენ თავიანთი მონაცემთა სისტემების ზრდასთან ერთად. თუმცა, არსებული სისტემების განვითარების გზა შეიძლება საკმაოდ რთული იყოს. გუნდებს ხშირად უწევთ არჩევანის გაკეთება ხანგრძლივ მიგრაციას შორის მრავალი დუბლიკატი სისტემის შენარჩუნებისას, ან ძვირადღირებული სრული სისტემის შეწყვეტას შორის. Netscape-ის გადაწყვეტილებამ გადაეწერა ბრაუზერის ძრავა 1997 წელს და დაუჯდა მათ ბრაუზერის ბიზნესი და ბაზარზე დომინირება Internet Explorer-ს, რადგან ისინი ვერ გაუწევდნენ კონკურენციას Internet Explorer-ის სწრაფი ფუნქციების გამოშვებას, რაც საბოლოოდ გამოიწვია მათი ბაზრის წილის შემცირება. ბევრი კომპანია იწყებს საბაჟო გადაწყვეტილებებს და იზრდება გამყიდველის პლატფორმებზე; თუმცა, იმ მასშტაბითაც კი, როდესაც კომპანიებს შეუძლიათ იყიდონ გამყიდველის პლატფორმები, ისინი შეიძლება მაინც არ მოერგოს მათ გამოყენებას და შიდა მომხმარებლებმა უნდა მოერგონ ახალ სამუშაო პროცესებს. ბევრი კომპანია საბოლოოდ აშენებს პერსონალურ გადაწყვეტილებებს გამყიდველის პლატფორმების თავზე, რადგან ისინი აგრძელებენ მასშტაბურობას. შიდა ინფრასტრუქტურის გუნდებს ახლა უწევთ თავიანთი ორიგინალური სისტემების შენარჩუნება, გამყიდველის პლატფორმების ფუნქციონირება და ამ პლატფორმების თავზე მორგებული იმპლემენტაციების მხარდაჭერა — ამასთან, მომხმარებლებს ასწავლიან სხვადასხვა ინსტრუმენტებს და ამუშავებენ უსაფრთხოებას და ინტეგრაციას მრავალ სისტემაში. დაგეგმვისა და ბიზნესის მასშტაბის ორგანული პროგრესის არარსებობის გამო, რაც დაიწყო, როგორც იაფი გადაწყვეტა, მნიშვნელოვნად უფრო ძვირი და რთული ფუნქციონირება ხდება. მონაცემთა პლატფორმების დაპროექტება, რომელსაც შეუძლია ბიზნესის ზრდასთან ერთად მასშტაბირება, დღეს უფრო მიღწევადია, ვიდრე ადრე. გასული ათწლეულის განმავლობაში, ბევრმა ორგანიზაციამ დაადგინა მონაცემთა გამოყენების მკაფიო შაბლონები - პროდუქტის გუნდებს სჭირდებათ მომხმარებლის ქცევის მონაცემები, მარკეტინგის გუნდები თვალყურს ადევნებენ კამპანიის შესრულებას, ფინანსური ჯგუფები აკონტროლებენ შემოსავლების მეტრიკას და უსაფრთხოების გუნდები აანალიზებენ საფრთხის შაბლონებს. ეს საერთო გამოყენების შემთხვევები კარგად არის ჩამოყალიბებული იმ თვალსაზრისით, თუ რა მონაცემები სჭირდებათ მათ და რამდენად სწრაფად სჭირდებათ ისინი. იმის ნაცვლად, რომ აღმოაჩინოთ მოთხოვნები ძვირადღირებული მიგრაციისა და გამყიდველის გადაწყვეტილებების გაუმჯობესების გზით, შესაძლებელია მონაცემთა პლატფორმის შექმნა, რომელსაც შეუძლია მდგრადი მასშტაბირება ღირებულებისა და ოპერაციული ეფექტურობის თვალსაზრისით. მონაცემთა პლატფორმების დიზაინი თავის არსში, მონაცემთა პლატფორმა შეიძლება განისაზღვროს ორი ფუნდამენტური კომპონენტით: რა მონაცემები გჭირდებათ (მონაცემთა მოდელები) და რამდენად სწრაფად გჭირდებათ ეს (დაყოვნების მოთხოვნები). ცალსახად განსაზღვრული გამოყენების შემთხვევაშიც კი, ამ ორი კომპონენტის გაგება საშუალებას გვაძლევს სისტემატურად მივიღოთ მონაცემთა შეგროვების მექანიზმი და ინფრასტრუქტურის საჭიროებები. მაგალითად, მიიღეთ თაღლითობის რისკის გამოვლენა. როგორც წესი, თაღლითობის რისკი მოითხოვს მონაცემთა სამ კომპონენტს: იდენტურობა, ტრანზაქცია და საქმის მართვა. მონაცემთა თითოეული კომპონენტი შეიძლება დაფიქსირდეს ინფრასტრუქტურაში შეყოვნების საჭიროებებზე დაყრდნობით. პირადობისა და ტრანზაქციის დადასტურება საჭიროებს ნაკადის დამუშავებას რეალურ დროში თაღლითობის აღმოჩენისთვის, მონაცემთა ბაზის დამუშავება ამუშავებს მიმდინარე მონიტორინგს და სიგნალიზაციას და მონაცემთა ტბებს, რათა მხარი დაუჭიროს უფრო გრძელვადიან ამოცანებს, როგორიცაა ნიმუშის ანალიზი და მოდელის ტრენინგი. მონაცემთა მოდელები მონაცემთა მოდელი განსაზღვრავს, თუ როგორ უნდა იყოს ორგანიზებული და სტანდარტიზებული მონაცემები. იგი განსაზღვრავს ველების ერთობლიობას და მათ მახასიათებლებს - თითოეული ველის ფორმატს, ტიპს და წესებს. სქემები იძლევა მონაცემთა აღმოჩენის საშუალებას, ხოლო ცალკეული ველების განმარტებები განსაზღვრავს მმართველობის პოლიტიკას და შესაბამისობის მოთხოვნებს. კარგად განსაზღვრული მონაცემთა მოდელები საშუალებას იძლევა სტანდარტიზებული მონაცემთა შეგროვება და დამუშავება ორგანიზაციის მასშტაბით. მაგალითისთვის ავიღოთ მომხმარებლის მონაცემები – მარკეტინგს ეს სჭირდება კამპანიის თვალყურის დევნისთვის, მომხმარებელთა მომსახურება საქმის მენეჯმენტისთვის, პროდუქტის გუნდები ქცევის ანალიტიკისთვის და რისკის გუნდები თაღლითობის გამოვლენისთვის. მომხმარებლის მონაცემების საერთო მოდელის გარეშე, ყველა გუნდი აშენებს მომხმარებლის პროფილებისა და თვალთვალის ლოგიკის საკუთარ ვერსიას. საბოლოოდ გუნდები ქმნიან რთულ ინტეგრაციას მომხმარებლის მონაცემების სისტემებს შორის გადაჭრისა და შეჯერების მიზნით. მონაცემთა გაზიარებული მოდელი, რომელიც ჭეშმარიტების ერთი წყაროა, ამარტივებს მონაცემთა შეგროვებას და განხორციელებას, ხოლო თანმიმდევრული სტანდარტები უსაფრთხოებისა და შესაბამისობის მართვას ბევრად აადვილებს. ყოვლისმომცველი მონაცემთა მოდელების განსაზღვრა ხშირად რთულია ცალკეული გუნდებისთვის, რადგან ისინი, როგორც წესი, ფოკუსირდებიან მათ უშუალო საჭიროებებზე. მარკეტინგის გუნდები ყურადღებას ამახვილებენ კამპანიასთან დაკავშირებულ სფეროებზე, ხოლო რისკის გუნდები ყურადღებას ამახვილებენ პირადობის დადასტურების ატრიბუტებზე. ჰოლისტიკური ხედვის გარეშე, თუ როგორ ემსახურება ერთი და იგივე მონაცემები სხვადასხვა ფუნქციებს, გუნდები ხშირად ქმნიან არასრულ ან ვიწრო ფოკუსირებულ მონაცემთა მოდელებს, რომლებიც საჭიროებენ შემდგომ დამუშავებას და სისტემებს შორის ინტეგრაციას. დროის მოთხოვნები დროის მოთხოვნები განსაზღვრავს, თუ რამდენად სწრაფად უნდა მოხდეს მონაცემების დამუშავება და ხელმისაწვდომობა. დამუშავების ფანჯრები მერყეობს რეალურ დროში (წამები) დაუყოვნებელი გადაწყვეტილებებისთვის, თითქმის რეალურ დროში (წუთები) მონიტორინგისთვის, ჯგუფური დამუშავების (საათები) ანალიტიკისთვის და AI/ML აპლიკაციებისთვის. დროის ეს მოთხოვნები ეხება კონკრეტულ ინფრასტრუქტურულ არჩევანს - ნაკადი რეალურ დროში, მონაცემთა ბაზები თითქმის რეალურ დროში და მონაცემთა ტბები სერიული დამუშავებისთვის. ჩარჩოს გარეშე, პროდუქტის გუნდები ხშირად აშენებენ ზედმეტ ინფრასტრუქტურას მსგავსი საჭიროებისთვის - ერთმა გუნდმა შეიძლება გამოიყენოს კაფკა, ხოლო მეორე გამოიყენოს MSK სტრიმინგისთვის, ან ერთმა გუნდმა შეიძლება აირჩიოს DynamoDB, ხოლო მეორე გამოიყენოს Cassandra მონაცემთა ბაზებისთვის. ეს ქმნის არასაჭირო სირთულეს, რადგან გუნდები ინარჩუნებენ მრავალ სისტემას უსაფრთხოების დუბლიკატი კონტროლით და ინტეგრაციით. ინფრასტრუქტურის კომპონენტების სტანდარტიზაციით, პროდუქტის გუნდებს აღარ სჭირდებათ საკუთარი ინფრასტრუქტურის განლაგება და პლატფორმის გუნდებს შეუძლიათ შეამცირონ ოპერატიული ხარჯები ნაკლები სისტემების შენარჩუნებით. ეს სტანდარტიზაცია ასევე იძლევა უსაფრთხოების უკეთეს კონტროლს, გამარტივებულ ინტეგრაციას, გამარტივებულ დაკვირვებადობას და ოპტიმიზებულ ხარჯებს. ზოგადი მონაცემთა პლატფორმა მონაცემთა პლატფორმის არქიტექტურის ჩარჩო საშუალებას გვაძლევს სისტემატურად მივიღოთ მონაცემთა შეგროვების სპეციფიკაციები, ინფრასტრუქტურის მოთხოვნები, უსაფრთხოების კონტროლი და ინტეგრაციის შესაძლებლობები. ეს პირდაპირ ეხება სირთულესა და ხარჯების სპირალს, რომელსაც დღეს ბევრი ორგანიზაცია აწყდება. იმის ნაცვლად, რომ გუნდებმა შექმნან ცალკეული სისტემები, რომელთა მხარდაჭერასაც პლატფორმის გუნდები უჭირთ, თანმიმდევრული ჩარჩო ამარტივებს უსაფრთხოებას, შესაბამისობას, ინტეგრაციას და ხარჯების მენეჯმენტს ორგანიზაციის მასშტაბით. თანმიმდევრული განხორციელების გარეშე, პლატფორმის გუნდებს მუდმივად სთხოვენ არჩევანის გაკეთებას არსებული სისტემების შენარჩუნებას, ძვირადღირებულ მიგრაციას ან ახალი ფუნქციების შექმნას შორის. პლატფორმის გუნდები დროის უმეტეს ნაწილს ხარჯავენ განსხვავებული სისტემების შენარჩუნებასა და მიგრაციაზე, ბიზნესის კრიტიკული შესაძლებლობების მიწოდების ნაცვლად. ჩარჩოზე ორიენტირებული მიდგომა საშუალებას აძლევს ორგანიზაციებს გააფართოვონ თავიანთი მონაცემთა პლატფორმები დამღუპველი მიგრაციის გარეშე. მცირე ორგანიზაციებს შეუძლიათ დაიწყონ საჭირო კომპონენტებით და გაფართოვდნენ მათი ზრდისას, ხოლო უფრო დიდ ორგანიზაციებს შეუძლიათ თავიანთი არსებული სისტემების სტანდარტიზაცია ერთხელ მუდმივი გადაწერის გარეშე. მომავალი შემდეგი მე-3 ნაწილში ჩვენ განვიხილავთ, თუ როგორ შეიძლება ამ ჩარჩოს დანერგვა პრაქტიკულ დონეზე. ჩვენ განვიხილავთ, თუ როგორ შეიძლება შეიკრიბოს მონაცემთა პლატფორმის საერთო კომპონენტები, როგორიცაა ნაკადი, მონაცემთა ბაზები, მონაცემთა საწყობი და მონაცემთა ტბა, რათა მხარი დაუჭიროს სხვადასხვა ბიზნეს გამოყენების შემთხვევებს უსაფრთხოებისა და შესაბამისობის კონტროლის თანმიმდევრული კონტროლით. როგორც იზრდება ორგანიზაციები, ეს მოდულური მიდგომა საშუალებას აძლევს გუნდებს დამოუკიდებლად გააფართოვონ ინდივიდუალური კომპონენტები და შეინარჩუნონ სტანდარტიზებული ინტერფეისები და კონტროლი, რაც გამორიცხავს მუდმივი მიგრაციის საჭიროებას. მონაცემთა პლატფორმის არქიტექტურის მკაფიო ჩარჩოთი, ორგანიზაციებს შეუძლიათ შექმნან მონაცემთა აპლიკაციები, რომლებიც იზრდებიან თავიანთ ბიზნესთან ერთად, ვიდრე შეზღუდონ იგი. „One Off to One Data Platform“ სერიის