UiPath და Snowflake ორმხრივად ერთიანდება — მონაცემის კოპირება აღარ სჭირდება

|ავტორი: QUASA-ს სარედაქციო გუნდი|5 წთ საკითხავი| 2
UiPath და Snowflake ორმხრივად ერთიანდება — მონაცემის კოპირება აღარ სჭირდება

2026 წლის 30 სექტემბერს UiPath-მა და Snowflake-მა ორმხრივი ინტეგრაციის გაფართოება და Snowflake Marketplace-ში UiPath-ის განთავსება გამოაცხადეს; Snowflake-ის ვიცე-პრეზიდენტმა ბალა კასივისვანათანმა მონაცემის როლი ასე აღწერა: “AI agents are only as good as the data and context behind them.” ახალი კავშირით UiPath-ის ავტომატიზაციას Snowflake-ში დაცული მონაცემის გამოყენება შეუძლია, ხოლო ავტომატიზაცია უშუალოდ Snowflake-იდან შეიძლება დაიწყოს. კომპანიების განცხადებით, ამ მოქმედებებისთვის ძირითადი მონაცემის მეორე სისტემაში კოპირება საჭირო არ არის.

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

რომელი მიმართულებით მიდის მოთხოვნა

მონაცემისკენ მიმართული გზა UiPath Data Fabric-ით იწყება. ის Snowflake-ში არსებულ ინფორმაციას კითხულობს და ავტომატიზაციისთვის გამოსადეგ კონტექსტად აყალიბებს ისე, რომ საწყისი ჩანაწერების მუდმივი ასლი UiPath-ში არ შეიქმნას. ეს მნიშვნელოვანია იმ პროცესისთვის, რომელსაც გადაწყვეტილების მისაღებად მიმდინარე მონაცემი სჭირდება: მონაცემის ცალკე საცავში წინასწარ გადატანა და შემდეგ მისი განახლება ამ წაკითხვის აუცილებელი ნაწილი აღარ არის.

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

კავშირს კიდევ ერთი სამუშაო ფენა აქვს: UiPath Integration Service-ის საშუალებით Snowflake Cortex-თან დაკავშირება Delegate-სა და Cartographer-ს Snowflake-ში არსებული მონაცემის აღმოჩენისა და ანალიზის საშუალებას აძლევს პროცესის შექმნისას და მუშაობის დროს. UiPath Maestro სხვადასხვა მოქმედების ორკესტრირებისთვის გამოიყენება. ამ კომპონენტებს განსხვავებული როლი აქვთ: მონაცემის პოვნა, პროცესის დაწყება და შესრულების მართვა სხვადასხვა ადგილას ხდება, რაც უფლებებისა და მოვლენების კვალის გაყოფასაც ნიშნავს.

რას ფარავს მონაცემის უკოპიროდ წაკითხვა

Zero-copy ამ შემთხვევაში წყაროს ჩანაწერების შენახვის წესს ეხება. ფედერირებული წვდომისას Data Fabric მონაცემს მოთხოვნის დროს კითხულობს Snowflake-იდან; წყაროს მთელი ნაკრების მუდმივი დუბლიკატი UiPath-ში არ ჩნდება. მოთხოვნის პასუხი მაინც უნდა მივიდეს ავტომატიზაციამდე, ხოლო პროცესმა შეიძლება საკუთარი შედეგი ან შესრულების ჩანაწერი შექმნას. ამდენად, ძირითადი მონაცემის უკოპიროდ წაკითხვა სისტემებს შორის ინფორმაციის ყოველგვარი გაცვლის გაუქმებას არ ნიშნავს.

UiPath-ის Data Fabric-ის ტექნიკური აღწერა ფედერირებულ ერთეულს განმარტავს როგორც მხოლოდ წაკითხვის ხედს, რომელიც ყოველი მოთხოვნისას წყაროს მიმართავს და საკუთარ ჩანაწერებს არ ინახავს; ადგილობრივი, ანუ Native, ერთეული კი მონაცემს UiPath-ში ინახავს. ფედერირებულ ერთეულში შეიძლება Snowflake-ის ველებთან ერთად UiPath-ის ადგილობრივი ერთეულის ველებიც გამოჩნდეს. ერთიანი ხედი ამ მონაცემების საერთო საცავში გადატანას არ მოითხოვს, თუმცა ადგილობრივ ერთეულში შენახული ჩანაწერი მაინც UiPath-ში რჩება.

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

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

სად რჩება წვდომისა და აუდიტის კონტროლი

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

Data Fabric-ის ერთეულების ტიპებს კონტროლის განსხვავებული წესები აქვთ. ფედერირებულ ერთეულზე UiPath-ის ჩანაწერის დონეზე როლებზე დაფუძნებული წვდომის კონტროლი არ ვრცელდება, რადგან ჩანაწერები წყაროში ინახება; ასეთი ერთეულების ჩანაწერები UiPath Insights-შიც არ იტვირთება. ეს დეტალი განსაკუთრებით მნიშვნელოვანია მაშინ, როცა გუნდი UiPath-ის ადგილობრივი ერთეულის უფლებებს Snowflake-იდან წაკითხულ ხედზეც ავტომატურად მოქმედად მიიჩნევს. ფედერირებული მონაცემის შეზღუდვა წყაროს უფლებებსა და კავშირის კონფიგურაციაში უნდა აისახოს.

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

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

ხელმისაწვდომობა და პირველი საბაზრო რეაქცია

UiPath Snowflake Marketplace-ში უკვე არის წარმოდგენილი, ხოლო ახალი შესაძლებლობები კომპანიებმა არსებული პარტნიორობის გაფართოებად წარმოადგინეს. Marketplace-ში ჩანაწერის გამოჩენა საერთო პროდუქტის ხელმისაწვდომობის ფაქტია, მაგრამ ცალკეული კომპონენტების ჩართვის უფლებებს, ორგანიზაციის ლიცენზიასა და მონაცემის წყაროს კონფიგურაციას არ აღწერს. Data Fabric-ის დოკუმენტაციით, გარე სისტემებთან კავშირი Automation Cloud-ის გარემოსთვის არის ხელმისაწვდომი; მიწოდების სხვა ვარიანტებზე იგივე შესაძლებლობა ავტომატურად არ ვრცელდება.

30 სექტემბრის Quiver Quantitative-ის საბაზრო მიმოხილვამ UiPath-ის აქციის დაახლოებით 4,8%-იანი დღიური ზრდა აღწერა და ინტეგრაციის ანონსი შესაძლო მამოძრავებელ მიზეზად მიიჩნია. მიმოხილვა სხვა ბოლოდროინდელ პროდუქტის სიახლეებსაც ასახელებს, ამიტომ ფასის მოძრაობიდან ახალი კავშირის გამოყენების მასშტაბი ან ტექნიკური შედეგი არ გამოითვლება. ტექნიკური და ოპერაციული გუნდებისთვის უფრო მნიშვნელოვანი შემდეგი კონკრეტული დეტალია, როგორ განისაზღვრება CoCo-დან გამოძახებული მოქმედების უფლება და როგორ ებმება მისი შესრულების ჩანაწერი Snowflake-ში წაკითხულ მონაცემს.

ასევე წაიკითხეთ:

გაზიარება:

გამოიწერეთ ჩვენი ბიულეტენი

მიიღეთ უახლესი ამბები Web3-ის, AI-სა და კრიპტოს შესახებ პირდაპირ თქვენს ელფოსტაზე.

0