अमेज़न SageMaker फ़ीचर स्टोर की एक नई क्षमता है अमेज़न SageMaker यह डेटा वैज्ञानिकों और मशीन लर्निंग (एमएल) इंजीनियरों को प्रशिक्षण और भविष्यवाणी वर्कफ़्लोज़ में उपयोग किए गए क्यूरेट डेटा को सुरक्षित रूप से संग्रहीत, खोज और साझा करने में मदद करता है। चूंकि संगठन एमएल का उपयोग करके डेटा-संचालित एप्लिकेशन का निर्माण करते हैं, वे लगातार अधिक से अधिक कार्यात्मक टीमों के बीच सुविधाओं को इकट्ठा और स्थानांतरित कर रहे हैं। डेटा के इस निरंतर आंदोलन से कई टीमों में फैली एमएल पहल को डिजाइन करते समय सुविधाओं में विसंगतियों और अड़चन बन सकती है। उदाहरण के लिए, एक ईकॉमर्स कंपनी के पास अपने प्लेटफ़ॉर्म के विभिन्न पहलुओं पर काम करने वाली कई डेटा साइंस और इंजीनियरिंग टीमें हो सकती हैं। कोर खोज टीम क्वेरी समझ और सूचना पुनर्प्राप्ति कार्यों पर केंद्रित है। उत्पाद सफलता टीम ग्राहकों की समीक्षाओं और प्रतिक्रिया संकेतों से जुड़ी समस्याओं को हल करती है। वैयक्तिकरण टीम व्यक्तिगत सिफारिशों के लिए एमएल मॉडल बनाने के लिए क्लिकस्ट्रीम और सत्र डेटा का उपयोग करती है। इसके अतिरिक्त, डेटा क्यूरेशन टीम जैसी डेटा इंजीनियरिंग टीम उपयोगकर्ता-विशिष्ट जानकारी को क्यूरेट और मान्य कर सकती है, जो एक आवश्यक घटक है जिसका उपयोग अन्य टीम कर सकती है। एक फीचर स्टोर इन टीमों के बीच एकीकृत इंटरफेस के रूप में काम करता है, जो एक टीम को अन्य टीमों द्वारा उत्पन्न सुविधाओं का लाभ उठाने में सक्षम बनाता है, जो टीमों में प्रतिकृति और चलती सुविधाओं के परिचालन ओवरहेड को कम करता है।
प्रोडक्शन के लिए तैयार एमएल मॉडल में आम तौर पर उन सुविधाओं के विविध सेट तक पहुंच शामिल होती है जो हमेशा उस टीम द्वारा स्वामित्व और रखरखाव नहीं करते हैं जो मॉडल का निर्माण कर रहे हैं। एमएल को लागू करने वाले संगठनों के लिए एक आम अभ्यास इन डेटा विज्ञान टीमों को व्यक्तिगत समूहों के रूप में सोचने के लिए है जो सीमित सहयोग के साथ स्वतंत्र रूप से काम करते हैं। इसका परिणाम एमएल वर्कफ़्लोज़ में बिना किसी मानकीकृत तरीके के टीमों के बीच सुविधाओं को साझा करना है, जो डेटा विज्ञान उत्पादकता के लिए एक महत्वपूर्ण सीमित कारक बन जाता है और डेटा वैज्ञानिकों के लिए नए और जटिल मॉडल बनाने में कठिन हो जाता है। एक साझा फीचर स्टोर के साथ, संगठन पैमाने की अर्थव्यवस्थाओं को प्राप्त कर सकते हैं। जैसे ही अधिक साझा सुविधाएँ उपलब्ध हो जाती हैं, टीमों के लिए नए मॉडल बनाना और बनाए रखना आसान और सस्ता हो जाता है। ये मॉडल उन सुविधाओं का पुन: उपयोग कर सकते हैं जो पहले से ही विकसित, परीक्षण और एक केंद्रीकृत सुविधा स्टोर का उपयोग करके पेश की जाती हैं।
यह पोस्ट फ़ीचर स्टोर के लिए आवश्यक क्रॉस-अकाउंट आर्किटेक्चर पैटर्न को कैप्चर करता है जिसे एक संगठन में लागू किया जा सकता है जिसमें कई डेटा इंजीनियरिंग और डेटा साइंस टीम अलग-अलग AWS खातों में काम कर रही हैं। हम चरण-दर-चरण उदाहरण के माध्यम से खातों के बीच सुविधाओं के साझाकरण को सक्षम करने का तरीका साझा करते हैं, जिसे आप अपने कोड में हमारे साथ आज़मा सकते हैं गीथहब रेपो.
SageMaker फ़ीचर स्टोर अवलोकन
डिफ़ॉल्ट रूप से, एक SageMaker फीचर स्टोर उस खाते के लिए स्थानीय है जिसमें इसे बनाया गया है, लेकिन इसे कई खातों के साथ केंद्रीकृत और साझा भी किया जा सकता है। कई टीमों के साथ एक संगठन में एक केंद्रीकृत सुविधा स्टोर हो सकता है जिसे टीमों में साझा किया जाता है, साथ ही अलग-अलग टीमों द्वारा उपयोग के लिए अलग-अलग फीचर स्टोर होते हैं। अलग-अलग स्टोर या तो फ़ीचर समूहों को पकड़ सकते हैं जो एक संवेदनशील प्रकृति के हैं या जो एक विशिष्ट एमएल वर्कलोड के लिए विशिष्ट हैं।
इस पोस्ट में, आप पहली बार के बारे में जानें केंद्रीकृत सुविधा की दुकान पैटर्न। यह पैटर्न एक केंद्रीय इंटरफ़ेस निर्धारित करता है जिसके माध्यम से टीमें नई सुविधाएँ बना और प्रकाशित कर सकती हैं, और जिनसे अन्य टीमें (या सिस्टम) सुविधाओं का उपभोग कर सकती हैं। यह यह भी सुनिश्चित करता है कि आपके पास अपने संगठन में फीचर डेटा के लिए सत्य का एक स्रोत है और संसाधन प्रबंधन को सरल बनाता है।
इसके बाद, आप के बारे में जानें संयुक्त सुविधा स्टोर पैटर्न, जो टीमों को अपने खाते में अपने स्वयं के फीचर स्टोर को स्थानीय बनाए रखने की अनुमति देता है, जबकि अभी भी केंद्रीकृत फीचर स्टोर से साझा सुविधाओं तक पहुंचने में सक्षम है। ये स्थानीय फीचर स्टोर आमतौर पर डेटा विज्ञान प्रयोग के लिए बनाए जाते हैं। स्थानीय विशेषताओं के साथ केंद्रीकृत स्टोर से साझा सुविधाओं को जोड़कर, टीमें नई बढ़ी हुई विशेषताओं को प्राप्त कर सकती हैं जो अधिक जटिल एमएल मॉडल बनाते समय मदद कर सकती हैं। आप संवेदनशील डेटा को संग्रहीत करने के लिए स्थानीय स्टोर का भी उपयोग कर सकते हैं जो नियामक और अनुपालन कारणों के लिए संगठन में साझा नहीं किया जा सकता है।
अंत में, हम फीचर डेटा की प्रतिकृति को शामिल करते हुए कुछ सामान्य पैटर्न को संक्षेप में कवर करते हैं।
केंद्रीकृत सुविधा स्टोर
जब यह केंद्रीकृत होता है तो संगठन किसी सुविधा स्टोर के लाभों को अधिकतम कर सकते हैं। केंद्रीकृत सुविधा की दुकान पैटर्न दर्शाता है कि एक से अधिक खातों से पाइपलाइनें एक केंद्रीयकृत सुविधा स्टोर को कैसे लिख सकती हैं, और कितने अन्य खाते इन सुविधाओं का उपभोग कर सकते हैं। यह मध्य-से-बड़े आकार के उद्यमों के बीच का एक सामान्य पैटर्न है जहां कई टीमें विभिन्न प्रकार के डेटा या एप्लिकेशन के विभिन्न भागों का प्रबंधन करती हैं।
एमएल मॉडल के लिए उपयुक्त प्रयोग करने योग्य डेटा में परिकल्पना, चयन और रूपांतरण की प्रक्रिया को कहा जाता है इंजीनियरिंग की सुविधा. एक सुविधा पाइपलाइन कच्चे डेटा को उपयोगी सुविधाओं में परिवर्तित करने के लिए आवश्यक फीचर इंजीनियरिंग प्रक्रिया के सभी चरणों को एनप्लाय करता है जो एमएल मॉडल भविष्यवाणियों के इनपुट के रूप में लेते हैं। फीचर पाइपलाइनों को बनाए रखना एक महंगी, समय लेने वाली और त्रुटि-प्रवण प्रक्रिया है। इसके अलावा, फ़ीचर रेसिपी और खातों में बदलाव की प्रतिकृति बनाने से फीचर विशेषताओं में असंगति और तिरछापन आ सकता है। क्योंकि एक केंद्रीकृत सुविधा स्टोर ज्ञान साझा करने की सुविधा प्रदान करता है, टीमों को हर प्रोजेक्ट में खरोंच से फीचर व्यंजनों को फिर से लिखना और पाइपलाइनों को फिर से लिखना नहीं पड़ता है।
इस पैटर्न में, खाता-विशिष्ट सुविधा स्टोर में स्थानीय रूप से सुविधाएँ लिखने के बजाय, सुविधाएँ एक केंद्रीकृत सुविधा स्टोर में लिखी जाती हैं। केंद्रीकृत स्टोर केंद्रीय तिजोरी के रूप में कार्य करता है और क्रॉस-टीम सहयोग के लिए सुविधाओं को एक्सेस करने और बनाए रखने के लिए एक मानकीकृत तरीका बनाता है। यह एआई गोद लेने के लिए एक एनबलर और एक्सेलेरेटर के रूप में कार्य करता है, जो एमएल समाधानों के लिए बाजार को कम करता है, और केंद्रीकृत शासन और एमएल सुविधाओं तक पहुंच नियंत्रण की अनुमति देता है। आप अपनी डेटा एक्सेस नीतियों को ध्यान में रखते हुए व्यक्तिगत फीचर समूहों को पढ़ने और लिखने के लिए बाहरी खातों, उपयोगकर्ताओं या भूमिकाओं तक पहुंच प्रदान कर सकते हैं। AWS केवल उन सुविधा समूहों के लिए कम से कम विशेषाधिकार प्राप्त करने की सिफारिश करता है जिन्हें आपको अपने कार्य के लिए आवश्यक है। यह अंतर्निहित द्वारा प्रबंधित किया जाता है AWS पहचान और अभिगम प्रबंधन (IAM) नीतियां। आप सुविधा समूह टैग के साथ अभिगम नियंत्रण को और परिष्कृत कर सकते हैं IAM की स्थिति यह तय करने के लिए कि कौन से प्रिंसिपल विशिष्ट कार्य कर सकते हैं। जब आप बड़े पैमाने पर एक केंद्रीकृत स्टोर का उपयोग कर रहे हैं, तो यह सुनिश्चित करना महत्वपूर्ण है कि फीचर समूहों को अच्छी तरह से डिजाइन करने के लिए उचित सुविधा शासन को लागू किया जाए, फीचर पाइपलाइनें हैं जो प्रलेखित और समर्थित हैं, और सुविधा की गुणवत्ता सुनिश्चित करने के लिए जगह में प्रक्रियाएं हैं। इस प्रकार के शासन से टीमों में फ़ीचर पुन: उपयोग के लिए आवश्यक विश्वास अर्जित करने में मदद मिलती है।
एक उदाहरण के माध्यम से चलने से पहले, आइए कुछ प्रमुख फीचर स्टोर अवधारणाओं की पहचान करें। प्रथम, सुविधा समूह आमतौर पर एक ही फीचर पाइपलाइन से उत्पन्न होने वाली सुविधाओं के तार्किक समूह हैं। एक ऑफ़लाइन स्टोर मॉडल विकास के लिए प्रशिक्षण और परीक्षण डेटा बनाने के लिए या मॉडल स्कोरिंग के लिए बैच अनुप्रयोगों द्वारा उपयोग किए जाने वाले ऐतिहासिक फीचर डेटा की बड़ी मात्रा में होते हैं। का उद्देश्य ऑनलाइन स्टोर is to serve these same features in real time with low latency. Unlike the offline store, which is append-only, the goal of the online store is to serve the most recent feature values. Behind the scenes, Feature Store automatically carries out data synchronization between the two stores. If you ingest new feature values into the online store, they’re automatically appended to the offline store. However, you can also create offline and online s
tores separately if this is a requirement for your team or project.
निम्न आरेख में तीन कार्यात्मक टीमों को दर्शाया गया है, जिनमें से प्रत्येक में एक केंद्रीकृत फीचर स्टोर में फीचर ग्रुप में अपनी स्वयं की फीचर पाइपलाइन लेखन के साथ है।
वैयक्तिकरण खाता ग्राहक-सामना करने वाले एप्लिकेशन से एकत्र किए गए उपयोगकर्ता सत्र डेटा का प्रबंधन करता है और एक फीचर पाइपलाइन का मालिक है जो सत्र डेटा से प्राप्त सुविधाओं के साथ सत्र नामक एक सुविधा समूह का उत्पादन करता है। यह पाइपलाइन सेंट्रलाइज्ड फीचर स्टोर पर जेनरेट किए गए फीचर वैल्यू को लिखता है। इसी तरह, प्रोडक्ट सक्सेस अकाउंट में एक फीचर पाइपलाइन रिव्यू फीचर ग्रुप में फीचर्स के निर्माण के लिए जिम्मेदार है, और डेटा क्यूरेशन अकाउंट यूजर्स फीचर ग्रुप में फीचर तैयार करता है।
केंद्रीयकृत सुविधा स्टोर खाता तीन उत्पादक खातों से प्राप्त सभी सुविधाएँ रखता है, तीन फीचर समूहों में मैप किया गया: सत्र, समीक्षा और उपयोगकर्ता। फीचर पाइपलाइन केंद्रीयकृत स्टोर खाते में बनाई गई एक विशिष्ट IAM भूमिका मानकर केंद्रीकृत सुविधा स्टोर को लिख सकती है। हम इस पोस्ट में बाद में इस क्रॉस-अकाउंट भूमिका को कैसे सक्षम करें, इस पर चर्चा करते हैं। बाहरी खाते भी प्रशिक्षण या अनुमान के लिए केंद्रीकृत स्टोर में फीचर समूहों से सुविधाओं को क्वेरी कर सकते हैं, जैसा कि पूर्ववर्ती वास्तुकला आरेख में दिखाया गया है। प्रशिक्षण के लिए, आप केंद्रीकृत स्टोर से IAM भूमिका ग्रहण कर सकते हैं और क्रॉस-अकाउंट चला सकते हैं अमेज़न एथेना क्वेरीज़ (चित्र में दिखाए गए अनुसार), या आरंभ करें अमेज़ॅन ईएमआर or SageMaker प्रसंस्करण प्रशिक्षण डेटासेट बनाने के लिए नौकरी। रीयल-टाइम इंट्रेंस के मामले में, आप क्रॉस-अकाउंट एक्सेस के लिए सीधे उसी समान IAM भूमिका के माध्यम से ऑनलाइन सुविधाओं को पढ़ सकते हैं।
इस मॉडल में, केंद्रीकृत सुविधा स्टोर आमतौर पर एक उत्पादन खाते में रहता है। इस स्टोर का उपयोग करने वाले एप्लिकेशन या तो इस खाते में या केंद्रीयकृत सुविधा स्टोर में क्रॉस-अकाउंट एक्सेस के साथ अन्य खातों में रह सकते हैं। आप इस पूरे ढांचे को निचले वातावरण में विकसित कर सकते हैं, जैसे कि विकास या मंचन, उत्पादन को बढ़ावा देने से पहले बुनियादी ढांचे में बदलाव के परीक्षण के लिए।
संयुक्त सुविधा स्टोर
इस खंड में, हम केंद्रीकृत फीचर स्टोर पैटर्न के एक प्रकार पर चर्चा करते हैं जिसे कहा जाता है संयुक्त सुविधा स्टोर पैटर्न। फीचर इंजीनियरिंग में, नई सुविधाओं को प्राप्त करने के लिए मौजूदा सुविधाओं को संयोजित करने के लिए एक सामान्य अभ्यास है। जब टीम अपने स्वयं के फ़ीचर स्टोर में स्थानीय सुविधाओं के साथ केंद्रीकृत स्टोर से साझा सुविधाओं को जोड़ती है, तो वे अधिक उन्नत डेटा मॉडल बनाने में मदद करने के लिए नई बढ़ी हुई विशेषताओं को प्राप्त कर सकते हैं। हम पिछले भाग से जानते हैं कि केंद्रीयकृत स्टोर किसी भी डेटा साइंस टीम के लिए बाहरी सुविधाओं का उपयोग करना और उन्हें सुविधाओं के अपने मौजूदा पूल के साथ उपयोग करना और नई सुविधाओं को विकसित करना आसान बनाता है।
सुरक्षा और अनुपालन केंद्रीयकृत स्टोर से सुविधाओं तक पहुंचने के अलावा टीम-विशिष्ट सुविधा स्टोर बनाए रखने के लिए टीमों के लिए एक और उपयोग मामला है। कई टीमों को विशिष्ट एक्सेस अधिकारों की आवश्यकता होती है जो संगठन में सभी को प्रदान नहीं किए जाते हैं। उदाहरण के लिए, संवेदनशील डेटा से निकाले गए फ़ीचरों को संगठन के भीतर केंद्रीकृत सुविधा स्टोर में प्रकाशित करना संभव नहीं है।
निम्नलिखित आर्किटेक्चर आरेख में, केंद्रीकृत सुविधा स्टोर वह खाता है जो एक केंद्रीय रिपॉजिटरी में कई फीचर पाइपलाइनों से प्राप्त सभी सुविधाओं को इकट्ठा और कैटलॉग करता है। इस उदाहरण में, संयुक्त स्टोर का खाता कोर सर्च टीम का है। यह खाता केंद्रीकृत स्टोर से साझा करने योग्य सुविधाओं का उपभोक्ता है। इसके अलावा, यह खाता ग्राहक-सामना खोज एप्लिकेशन के माध्यम से एकत्र किए गए उपयोगकर्ता कीवर्ड डेटा का प्रबंधन करता है।
यह खाता अपना स्थानीय ऑफ़लाइन और ऑनलाइन स्टोर रखता है। ये स्थानीय स्टोर उपयोगकर्ता क्वेरी कीवर्ड डेटा को निगलना और सुविधाओं को उत्पन्न करने के लिए स्थानीय स्तर पर स्थापित एक फीचर पाइपलाइन से आबाद हैं। इन सुविधाओं को कीवर्ड नाम के एक सुविधा समूह के अंतर्गत वर्गीकृत किया गया है। डिफ़ॉल्ट रूप से सुविधा स्टोर स्वचालित रूप से एक बनाता है एडब्ल्यूएस गोंद इस सुविधा समूह के लिए तालिका, जो इस खाते में AWS गोंद डेटा कैटलॉग में पंजीकृत है। इस तालिका का मेटाडेटा इस खाते के ऑफ़लाइन स्टोर में सुविधा समूह के अमेज़ॅन S3 स्थान की ओर इशारा करता है।
संयुक्त स्टोर खाता केंद्रीकृत स्टोर से फीचर समूह सत्र, समीक्षा और उपयोगकर्ता भी एक्सेस कर सकता है। आप भूमिका द्वारा क्रॉस-अकाउंट एक्सेस को सक्षम कर सकते हैं, जिसकी चर्चा हम अगले खंडों में करते हैं। डेटा वैज्ञानिक और शोधकर्ता एथेना का उपयोग स्थानीय स्तर पर बनाए गए फीचर समूहों को क्वेरी करने के लिए कर सकते हैं और डेटा साइंस प्रयोगों के लिए केंद्रीयकृत स्टोर से प्राप्त बाहरी सुविधाओं के साथ इन आंतरिक विशेषताओं में शामिल हो सकते हैं।
क्रॉस-अकाउंट एक्सेस अवलोकन
यह खंड दो खातों के बीच फ़ीचर स्टोर के लिए क्रॉस-अकाउंट एक्सेस को सक्षम करने का एक सिंहावलोकन प्रदान करता है AWS सुरक्षा टोकन सेवा (एडब्ल्यूएस एसटीएस)। AWS STS एक वेब सेवा है जो आपको IAM उपयोगकर्ताओं के लिए अस्थायी, सीमित-विशेषाधिकार क्रेडेंशियल्स का अनुरोध करने में सक्षम बनाती है। एडब्ल्यूएस एसटीएस अस्थायी सुरक्षा क्रेडेंशियल्स का एक सेट देता है जिसका उपयोग आप एडब्ल्यूएस संसाधनों का उपयोग करने के लिए कर सकते हैं जिन्हें आप सामान्य रूप से एक्सेस नहीं कर सकते हैं। इन अस्थायी क्रेडेंशियल्स में एक एक्सेस कुंजी आईडी, गुप्त एक्सेस कुंजी और सुरक्षा टोकन शामिल हैं।
इस प्रक्रिया को प्रदर्शित करने के लिए, मान लें कि हमारे पास दो खाते हैं, ए और बी, जैसा कि निम्नलिखित चित्र में दिखाया गया है।
खाता बी एक केंद्रीकृत ऑनलाइन और ऑफलाइन सुविधा स्टोर रखता है। खाता ए को खाता बी में शामिल ऑनलाइन और ऑफलाइन दोनों स्टोरों तक पहुंच की आवश्यकता है। इसे सक्षम करने के लिए, हम खाता बी में एक भूमिका बनाते हैं और खाता ए को एडब्ल्यूएस एसटीएस का उपयोग करते हुए मान लेते हैं। यह खाता ए को खाता बी की तरह व्यवहार करने में सक्षम बनाता है, जिसमें भूमिका द्वारा पहचाने जाने वाले विशिष्ट कार्यों को करने की अनुमति होती है। SWSMaker (प्रसंस्करण और प्रशिक्षण नौकरियां, समापन बिंदु) और जैसे AWS सेवाएं और AWS लाम्बा खाता A से उपयोग AWS STS क्लाइंट का उपयोग करके खाता B में बनाई गई IAM भूमिका को मान सकता है (बाद में इस पोस्ट में कोड ब्लॉक देखें)। यह उन्हें खाता बी के अंदर अमेज़ॅन एस 3, एथेना और एडब्ल्यूएस ग्लू डेटा कैटलॉग जैसे संसाधनों तक पहुंचने के लिए आवश्यक अनुमति देता है। खाता ए में सेवाओं के बाद संसाधनों के लिए आवश्यक अनुमति प्राप्त करने के बाद, वे खाते में ऑफ़लाइन और ऑनलाइन स्टोर दोनों का उपयोग कर सकते हैं। बी। आपकी सेवा की पसंद के आधार पर, आपको उस सेवा के लिए IAM निष्पादन भूमिका को खाता बी में पारगमन खाता IAM भूमिका की विश्वसनीय नीति में जोड़ने की आवश्यकता है। हम निम्नलिखित अनुभाग में इसके बारे में विस्तार से चर्चा करते हैं।
पूर्ववर्ती आर्किटेक्चर आरेख से पता चलता है कि खाता ए खाता बी से ऑनलाइन और ऑफलाइन दोनों स्टोर में पढ़ने और लिखने के लिए खाता बी से एक भूमिका कैसे मानता है। आरेख में सात चरण निम्नानुसार हैं:
- खाता बी एक भूमिका बनाता है जिसे दूसरों द्वारा (हमारे उपयोग के मामले के लिए, खाता ए) माना जा सकता है।
- खाता A, AWS STS का उपयोग करके खाता B से IAM भूमिका ग्रहण करता है। खाता A अब अस्थायी क्रेडेंशियल उत्पन्न कर सकता है जो AWS सेवा क्लाइंट बनाने के लिए इस्तेमाल किया जा सकता है जो व्यवहार करता है जैसे कि वे खाता बी के अंदर हैं।
- In Account A, SageMaker and other service
clients (such as Amazon S3 and Athena) are created using the temporary credentials via the assumed role. - खाता ए में सेवा क्लाइंट अब फीचर समूह बना सकते हैं और एडब्ल्यूएस एसडीके का उपयोग करके खाता बी के केंद्रीकृत ऑनलाइन स्टोर में फीचर मानों को पॉप्युलेट कर सकते हैं।
- खाता बी में ऑनलाइन स्टोर स्वचालित रूप से ऑफलाइन स्टोर के साथ खाता बी में भी सिंक करता है।
- एथेना सेवा क्लाइंट के अंदर खाता ए खाता बी के अंदर एथेना तालिकाओं का उपयोग कर, समूह, और भौतिक सेटों को पढ़ने के लिए क्रॉस-अकाउंट क्वेरीज़ चलाता है क्योंकि खाता बी में ऑफ़लाइन स्टोर मौजूद है, इसी एडब्ल्यूएस ग्लू टेबल, मेटाडाटा कैटलॉग प्रविष्टियाँ और एस 3 ऑब्जेक्ट्स खाता बी के भीतर सभी निवास करते हैं। खाता बी के अंदर ऑफ़लाइन सुविधाओं (एस 3 ऑब्जेक्ट्स) को क्वेरी करने के लिए एडब्ल्यूएस एसटीएस मान भूमिका का उपयोग कर सकते हैं।
- एथेना क्वेरी परिणाम खाता ए के S3 बाल्टी में फीचर डेटासेट के रूप में वापस आ जाते हैं।
अस्थायी क्रेडेंशियल AWS STS GetSessionToken API का उपयोग करते हैं और 1 घंटे तक सीमित होते हैं। आप उपयोग करके अपने सत्र की अवधि बढ़ा सकते हैं रिफ्रैशेबल क्रेडेंशियल्स, एक बोटोकोर वर्ग जो 1 घंटे की समय सीमा से परे अपने लंबे समय तक चलने वाले अनुप्रयोगों के साथ काम करने के लिए क्रेडेंशियल्स को स्वचालित रूप से ताज़ा कर सकता है। एक उदाहरण नोटबुक यह प्रदर्शन हमारे GitHub रेपो में उपलब्ध है।
क्रॉस-अकाउंट एक्सेस बनाएं
यह खंड हमारी वास्तुकला के अनुसार खाता ए और बी के बीच सुविधाओं की छटपटाहट को सक्षम करने के लिए क्रॉस-अकाउंट एक्सेस भूमिकाएं, नीतियां और अनुमतियाँ बनाने के सभी चरणों का विवरण देता है।
एक फ़ीचर स्टोर एक्सेस भूमिका बनाएँ
खाता बी से, हम एक फीचर स्टोर एक्सेस भूमिका बनाते हैं। यह खाता बी के संसाधनों तक पहुँच प्राप्त करने के लिए खाता A के अंदर AWS सेवाओं द्वारा ग्रहण की गई भूमिका है।
- नेविगेशन फलक में IAM कंसोल पर, चुनें भूमिकाओं.
- चुनें भूमिका बनाएं.
- चुनें एक और एडब्ल्यूएस खाता.
- के लिए खाता पहचान, खाता बी के 12 अंकों की खाता आईडी दर्ज करें।
- चुनें अगला: अनुमतियाँ.
- में अनुमतियाँ अनुभाग, निम्न AWS प्रबंधित नीतियों के लिए खोजें और संलग्न करें:
AmazonSageMakerFullAccess
(आप अपने उपयोग के मामले के आधार पर इसे कम से कम विशेषाधिकारों तक सीमित कर सकते हैं)AmazonSageMakerFeatureStoreAccess
- इस नई भूमिका के लिए एक कस्टम पॉलिसी बनाएं और संलग्न करें (खाता ए में एस 3 बाल्टी नाम प्रदान करें जहां खाता बी में एकत्रित एथेना क्वेरी परिणाम लिखे गए हैं):
जब आप खाता A से इस नई AWS STS क्रॉस-अकाउंट भूमिका का उपयोग करते हैं, तो यह Athena को खाता B में ऑफ़लाइन स्टोर की सामग्री के विरुद्ध चला सकता है। कस्टम नीति एथेना (खाता B के अंदर) को परिणाम बाल्टी में परिणाम वापस लिखने की अनुमति देती है। A. सुनिश्चित करें कि यह परिणाम बाल्टी A खाता बनाने से पहले बनाई जाती है ताकि आप पूर्ववर्ती नीति बना सकें।
वैकल्पिक रूप से, आप खाता बी में केंद्रीकृत सुविधा स्टोर को S3 बाल्टी में सभी एथेना क्वेरी परिणामों को बनाए रखने दे सकते हैं। इस मामले में, आपको सहेजे गए परिणाम (S3 ऑब्जेक्ट) को पढ़ने के लिए बाहरी खातों के लिए क्रॉस-खाता अमेज़न S3 पढ़ने की नीतियों को सेट करना होगा।
- आपके द्वारा नीतियों को संलग्न करने के बाद, चुनें अगला.
- इस भूमिका के लिए एक नाम दर्ज करें (उदाहरण के लिए, क्रॉस-खाता-मान-भूमिका)।
- पर सारांश निर्मित भूमिका के लिए पृष्ठ, के तहत रिश्तों पर भरोसा रखें, चुनें विश्वास संबंध संपादित करें.
- निम्न कोड में दिखाए अनुसार एक्सेस कंट्रोल पॉलिसी दस्तावेज़ संपादित करें:
पूर्ववर्ती कोड SageMaker और एथेना को प्रधान अनुभाग में सेवाओं के रूप में जोड़ता है। यदि आप इस भूमिका को संभालने के लिए अधिक बाहरी खाते या भूमिका चाहते हैं, तो आप इस अनुभाग में उनके संबंधित ARN जोड़ सकते हैं।
एक SageMaker नोटबुक उदाहरण बनाएँ
खाता ए से, IAM निष्पादन भूमिका के साथ एक SageMaker नोटबुक उदाहरण बनाएं। यह भूमिका खाता में SageMaker नोटबुक को अनुदान देती है खाता बी के अंदर सुविधा स्टोर पर कार्रवाई चलाने के लिए आवश्यक अनुमतियाँ। यदि आप SageMaker नोटबुक का उपयोग नहीं कर रहे हैं और इसके बजाय लैम्ब्डा का उपयोग कर रहे हैं, तो आपको उसी के साथ लैम्ब्डा के लिए एक भूमिका बनाने की आवश्यकता है इस धारा में दिखाए गए अनुसार संलग्न नीतियां।
डिफ़ॉल्ट रूप से, जब आप SageMaker नोटबुक के लिए एक नई निष्पादन भूमिका बनाते हैं, तो निम्न नीतियाँ संलग्न होती हैं:
AmazonSageMaker-ExecutionPolicy
AmazonSageMakerFullAccess
हमें दो अतिरिक्त कस्टम नीतियां बनाने और संलग्न करने की आवश्यकता है। सबसे पहले, निम्नलिखित कोड के साथ एक कस्टम पॉलिसी बनाएं, जो खाता ए में ऑफ़लाइन स्टोर के साथ बातचीत करने के लिए आवश्यक कुछ एस 3 क्रियाओं को करने के लिए खाता ए में निष्पादन भूमिका की अनुमति देता है:
आप AWS प्रबंधित नीति भी संलग्न कर सकते हैं AmazonSageMakerFeatureStoreAccess
, अगर आपके ऑफलाइन स्टोर में S3 बकेट नाम है SageMaker
कीवर्ड।
दूसरा, निम्नलिखित कस्टम नीति बनाएं, जो खाता ए में सेजमेकर नोटबुक को भूमिका मानने की अनुमति देता है (cross-account-assume-role
) खाता बी में बनाया गया:
We know Account A can access the online and offline store in Account B. When Account A assumes the cross-account AWS STS role of Account B, it can run Athena queries inside Account B against its offline store. However, the results of these queries (feature datasets) need to be saved in Account A’s S3 bucket in order to enable model training. Therefore, we need to create a bucket in Account A that can store the Athena query results as well as create a bucket policy (see the following code). This policy allows the cross-account AWS STS role to write and read objects in this
बाल्टी:
विश्वास संबंध नीति को संशोधित करें
क्योंकि हमने खाता A में IAM निष्पादन भूमिका बनाई है, इसलिए हम इस भूमिका के ARN का उपयोग खाता B में क्रॉस-खाता मान भूमिका के विश्वास संबंध नीति को संशोधित करने के लिए करते हैं:
सेटअप प्रक्रिया को मान्य करें
आपके द्वारा सभी भूमिकाओं और साथ की नीतियों को निर्धारित करने के बाद, आप उदाहरण में नोटबुक को चलाकर सेटअप को मान्य कर सकते हैं गीथहब रेपो। निम्न कोड ब्लॉक उदाहरण नोटबुक से एक अंश है और खाता ए के भीतर चल रहे एक SageMaker नोटबुक में चलना चाहिए। यह दर्शाता है कि आप AWS STS के माध्यम से खाता B से क्रॉस-खाता भूमिका कैसे मान सकते हैं मान लें एपीआई कॉल। यह कॉल अस्थायी क्रेडेंशियल्स का एक सेट देता है जिसका उपयोग खाता ए किसी भी सेवा क्लाइंट को बनाने के लिए कर सकता है। जब आप इन क्लाइंट का उपयोग करते हैं, तो आपका कोड ग्रहण की गई भूमिका की अनुमतियों का उपयोग करता है, और यह खाता बी के समान है। मान लेना AWS एसडीके में पायथन (बोटो 3) प्रलेखन के लिए।
जब आप खाता A में पूर्ववर्ती कोड उदाहरण के अनुसार SageMaker क्लाइंट बनाते हैं, तो आप फीचर समूह बना सकते हैं और खाता B के केंद्रीकृत ऑनलाइन और ऑफलाइन स्टोर में सुविधाओं को आबाद कर सकते हैं। सुविधा समूह कैसे बनाएं, वर्णन करें और हटाएं, इस बारे में अधिक जानकारी के लिए देखें create_feature_group Boto3 प्रलेखन में। आप भी उपयोग कर सकते हैं फीचर स्टोर रनटाइम क्लाइंट सुविधा समूहों को और से फीचर रिकॉर्ड रखना और प्राप्त करना।
ऑफलाइन स्टोर प्रतिकृति
Reproducibility एक एमएल मॉडल को फिर से बनाने की क्षमता है, इसलिए यदि आप इनपुट के समान सुविधाओं का उपयोग करते हैं, तो मॉडल मूल मॉडल के समान आउटपुट देता है। यह अनिवार्य रूप से वह है जो हम उन मॉडलों के बीच हासिल करने का प्रयास करते हैं जिन्हें हम एक शोध वातावरण में विकसित करते हैं और उत्पादन वातावरण में तैनात करते हैं। खातों में फ़ीचर इंजीनियरिंग पाइपलाइनों को फिर से भरना एक जटिल और समय लेने वाली प्रक्रिया है जो ठीक से लागू नहीं होने पर मॉडल की विसंगतियों को पेश कर सकती है। यदि प्रशिक्षण चरण के बाद एक मॉडल परिवर्तन को प्रशिक्षित करने के लिए उपयोग की जाने वाली सुविधा सेट की जाती है, तो किसी मॉडल को पुन: पेश करना मुश्किल या असंभव हो सकता है।
एडब्ल्यूएस पर रहने वाले अनुप्रयोगों में आमतौर पर कई अलग-अलग वातावरण और खाते होते हैं, जैसे कि विकास, परीक्षण, मंचन और उत्पादन। विभिन्न परिवेशों में एप्लिकेशन की स्वचालित तैनाती प्राप्त करने के लिए, हम CI / CD पाइपलाइनों का उपयोग करते हैं। संगठनों को अक्सर एक ही या अलग-अलग AWS क्षेत्रों में या अलग-अलग AWS खातों में अलग-अलग कार्य वातावरण और डेटा की कई प्रतियाँ बनाए रखने की आवश्यकता होती है। फ़ीचर स्टोर के संदर्भ में, कुछ कंपनियां ऑफ़लाइन फ़ीचर स्टोर डेटा की प्रतिकृति बनाना चाह सकती हैं। ऑफलाइन स्टोर प्रतिकृति के माध्यम से अमेज़न S3 प्रतिकृति इस मामले में एक उपयोगी पैटर्न हो सकता है। यह पैटर्न क्रॉस-अकाउंट भूमिकाओं या अनुमतियों का उपयोग किए बिना पूर्ण फ़ीचर सेट का उपयोग करके अलग-अलग वातावरण और खातों को एमएल मॉडल को फिर से सक्षम करने में सक्षम बनाता है।
निष्कर्ष
इस पोस्ट में, हमने विभिन्न आर्किटेक्चर पैटर्न जैसे कि केंद्रीकृत फीचर स्टोर, संयुक्त फीचर स्टोर, और SageMaker फीचर स्टोर के लिए अन्य डिजाइन विचार प्रदर्शित किए, जो क्रॉस-फंक्शनल डेटा साइंस सहयोग के लिए आवश्यक हैं। हमने यह भी दिखाया कि एडब्ल्यूएस एसटीएस का उपयोग करके क्रॉस-अकाउंट एक्सेस कैसे सेट किया जाए।
फ़ीचर स्टोर क्षमताओं के बारे में अधिक जानने और मामलों का उपयोग करने के लिए, देखें Amazon SageMaker Feature Store की प्रमुख क्षमताओं को समझना और निकट-वास्तविक समय में ML- समर्थित निर्णय लेने के लिए Amazon SageMaker Feature Store के साथ स्ट्रीमिंग अंतर्ग्रहण का उपयोग करना.
यदि आपके पास कोई टिप्पणी या प्रश्न हैं, तो कृपया उन्हें टिप्पणी अनुभाग में छोड़ दें।
लेखक के बारे में
अरुणाप्रसथ शंकर AWS के साथ आर्टिफिशियल इंटेलिजेंस एंड मशीन लर्निंग (AI / ML) स्पेशलिस्ट सॉल्यूशन आर्किटेक्ट है, जो वैश्विक ग्राहकों को क्लाउड में प्रभावी ढंग से और कुशलता से अपने AI समाधानों को स्केल करने में मदद करता है। अपने खाली समय में, अरुण को विज्ञान-फाई फिल्में देखने और शास्त्रीय संगीत सुनने का आनंद मिलता है।
मार्क रॉय AWS के लिए एक प्रिंसिपल मशीन लर्निंग आर्किटेक्ट है, AWS ग्राहकों को डिज़ाइन करने और AI / ML समाधान बनाने में मदद करता है। कंप्यूटर के विज़न, डीप लर्निंग और एंटरप्राइज़ में ML स्केलिंग में प्राथमिक रुचि के साथ, मार्क का काम ML उपयोग मामलों की एक विस्तृत श्रृंखला को कवर करता है। उन्होंने बीमा, वित्तीय सेवा, मीडिया और मनोरंजन, हेल्थकेयर, यूटिलिटीज और विनिर्माण सहित कई उद्योगों में कंपनियों की मदद की है। मार्क में एमएल स्पेशलिटी सर्टिफिकेशन सहित 6 एडब्ल्यूएस प्रमाणपत्र हैं। AWS में शामिल होने से पहले, मार्क एक वास्तुकार, डेवलपर, और 25 वर्षों के लिए प्रौद्योगिकी नेता थे, जिसमें वित्तीय सेवाओं में 19 साल शामिल थे।
स्टीफन नटू अमेज़न वेब सेवाओं पर सीनियर एआई / एमएल स्पेशलिस्ट सॉल्यूशन आर्किटेक्ट है। वह वित्तीय सेवाओं के ग्राहकों को एडब्ल्यूएस पर एंड-टू-एंड मशीन लर्निंग समाधान बनाने में मदद करने पर केंद्रित है। अपने खाली समय में, उन्हें पढ़ने की मशीन सीखने के ब्लॉग, गिटार बजाने और न्यूयॉर्क शहर में भोजन के दृश्य की खोज करने का आनंद मिलता है।
- त्वरक
- पहुँच
- लेखा
- कार्य
- अतिरिक्त
- दत्तक ग्रहण
- AI
- एआई गोद लेना
- वीरांगना
- अमेज़न SageMaker
- अमेज़ॅन वेब सेवा
- के बीच में
- एपीआई
- आवेदन
- अनुप्रयोगों
- स्थापत्य
- कृत्रिम बुद्धिमत्ता
- आर्टिफिशियल इंटेलिजेंस एंड मशीन लर्निंग
- स्वचालित
- एडब्ल्यूएस
- परदे के पीछे
- ब्लॉग
- निर्माण
- इमारत
- कॉल
- मामलों
- प्रमाणीकरण
- City
- ग्राहकों
- बादल
- कोड
- सहयोग
- टिप्पणियाँ
- सामान्य
- कंपनियों
- कंपनी
- अनुपालन
- अंग
- यौगिक
- Computer Vision
- उपभोग
- उपभोक्ता
- सामग्री
- साख
- ग्राहक
- तिथि
- डेटा प्राप्त करना
- डेटा विज्ञान
- ध्यान लगा के पढ़ना या सीखना
- डिज़ाइन
- विस्तार
- विकसित करना
- डेवलपर
- विकास
- ई-कॉमर्स
- अभियांत्रिकी
- इंजीनियर्स
- उद्यम
- मनोरंजन
- वातावरण
- निष्पादन
- Feature
- विशेषताएं
- वित्तीय
- वित्तीय सेवाओं
- प्रथम
- भोजन
- प्रपत्र
- पूर्ण
- समारोह
- GitHub
- वैश्विक
- शासन
- छात्रवृत्ति
- समूह
- स्वास्थ्य सेवा
- पकड़
- कैसे
- How To
- HTTPS
- आई ए एम
- पहचान करना
- पहचान
- सहित
- उद्योगों
- करें-
- इंफ्रास्ट्रक्चर
- बीमा
- बुद्धि
- ब्याज
- IT
- काम
- नौकरियां
- में शामिल होने
- रखना
- कुंजी
- ज्ञान
- बड़ा
- नेतृत्व
- जानें
- सीख रहा हूँ
- लीवरेज
- सीमित
- सूची
- सुनना
- स्थानीय
- स्थानीय स्तर पर
- स्थान
- यंत्र अधिगम
- प्रबंध
- विनिर्माण
- निशान
- बाजार
- मीडिया
- ML
- आदर्श
- चलचित्र
- संगीत
- पथ प्रदर्शन
- नई सुविधा
- नई सुविधाएँ
- न्यूयॉर्क
- न्यू यॉर्क शहर
- पुस्तिकाओं
- ऑनलाइन
- ऑनलाइन स्टोर
- परिचालन
- आदेश
- अन्य
- अन्य
- पैटर्न
- निजीकरण
- मंच
- नीतियाँ
- नीति
- पूल
- भविष्यवाणी
- भविष्यवाणियों
- उत्पादक
- एस्ट्रो मॉल
- उत्पादन
- उत्पादकता
- परियोजना
- प्रकाशित करना
- अजगर
- गुणवत्ता
- रेंज
- कच्चा
- कच्चा डेटा
- पढ़ना
- वास्तविक समय
- कारण
- व्यंजन विधि
- अभिलेख
- रिश्ते
- अनुसंधान
- संसाधन
- उपयुक्त संसाधन चुनें
- परिणाम
- रिटर्न
- समीक्षा
- रन
- दौड़ना
- sagemaker
- स्केल
- स्केलिंग
- विज्ञान
- वैज्ञानिकों
- एसडीके
- Search
- सुरक्षा
- सेवाएँ
- सेट
- Share
- साझा
- So
- समाधान ढूंढे
- कथन
- की दुकान
- भंडार
- स्ट्रीमिंग
- सफलता
- समर्थित
- सिस्टम
- टेक्नोलॉजी
- अस्थायी
- परीक्षण
- पहर
- टोकन
- प्रशिक्षण
- ट्रस्ट
- उपयोगकर्ताओं
- उपयोगिताओं
- दृष्टि
- घूमना
- वेब
- वेब सेवाओं
- अंदर
- काम
- कार्य
- लिख रहे हैं
- साल