धोखाधड़ी रोकथाम और अनुशंसा जैसे रियल-टाइम आर्टिफिशियल इंटेलिजेंस/मशीन लर्निंग (AI/ML) उपयोग के मामले बढ़ रहे हैं, और फीचर स्टोर्स उन्हें सफलतापूर्वक उत्पादन में तैनात करने में महत्वपूर्ण भूमिका निभाते हैं। लोकप्रिय ओपन सोर्स फीचर स्टोर Feast के अनुसार, उनके कम्युनिटी Slack में उपयोगकर्ताओं द्वारा पूछे जाने वाले सबसे आम प्रश्नों में से एक है: Feast कितना स्केलेबल/प्रदर्शनकारी है? ऐसा इसलिए है क्योंकि रियल-टाइम AI/ML के लिए फीचर स्टोर की सबसे महत्वपूर्ण विशेषता ऑनलाइन स्टोर से ML मॉडल तक ऑनलाइन भविष्यवाणियों या स्कोरिंग के लिए फीचर सर्विंग गति है। सफल फीचर स्टोर्स कठोर विलंबता आवश्यकताओं को पूरा कर सकते हैं (मिलीसेकंड में मापा गया), लगातार (p99 सोचें) और बड़े पैमाने पर (प्रति सेकंड लाखों क्वेरीज़ तक, गीगाबाइट्स से टेराबाइट्स आकार के डेटासेट के साथ) जबकि साथ ही कम कुल स्वामित्व लागत और उच्च सटीकता बनाए रखते हैं।
जैसा कि हम इस पोस्ट में देखेंगे, ऑनलाइन फीचर स्टोर का चुनाव, साथ ही फीचर स्टोर की आर्किटेक्चर, यह निर्धारित करने में महत्वपूर्ण भूमिका निभाते हैं कि यह कितना प्रदर्शनकारी और लागत-प्रभावी है। कोई आश्चर्य नहीं कि अक्सर कंपनियां, अपने ऑनलाइन फीचर स्टोर को चुनने से पहले, यह देखने के लिए गहन बेंचमार्किंग करती हैं कि आर्किटेक्चर या ऑनलाइन फीचर स्टोर का कौन सा विकल्प सबसे अधिक प्रदर्शनकारी और लागत-प्रभावी है। इस पोस्ट में, हम DIY फीचर स्टोर्स द्वारा सफलतापूर्वक रियल-टाइम AI/ML उपयोग के मामलों को तैनात करने वाली कंपनियों और ओपन सोर्स और कमर्शियल फीचर स्टोर्स दोनों से आर्किटेक्चर और बेंचमार्क की समीक्षा करेंगे। शुरू करते हैं।
1. ओपन सोर्स Feast
आइए पहले Feast ओपन सोर्स फीचर स्टोर के बेंचमार्किंग डेटा और फिर डेटा आर्किटेक्चर पर एक नज़र डालें। Feast ने हाल ही में विभिन्न ऑनलाइन स्टोर्स (Redis बनाम Google Cloud DataStore बनाम AWS DynamoDB) का उपयोग करते समय अपनी फीचर सर्विंग विलंबता की तुलना करने के लिए एक बेंचमार्क किया। इसने फीचर निकालने के लिए विभिन्न तंत्रों की गति की भी तुलना की (जैसे Java gRPC सर्वर, Python HTTP सर्वर, लैम्ब्डा फंक्शन, आदि)। आप इस ब्लॉग पोस्ट में पूर्ण बेंचमार्क सेटअप और उसके परिणाम पा सकते हैं। निचला रेखा: Feast ने पाया कि यह Java gRPC सर्वर और Redis को ऑनलाइन स्टोर के रूप में उपयोग करके अब तक का सबसे अधिक प्रदर्शनकारी था।
ऊपर दिए गए आरेख में आप देख सकते हैं कि ऑनलाइन मॉर्गेज कंपनी Better.com ने ओपन-सोर्स Feast फीचर स्टोर का उपयोग करके अपने लीड स्कोरिंग रैंकिंग सिस्टम को कैसे लागू किया। जैसा कि Better.com के सीनियर सॉफ्टवेयर इंजीनियर विटाली सर्गे द्वारा प्रस्तुत किया गया, फीचर्स को ऑफलाइन स्टोर्स (S3, Snowflake, और Redshift) से ऑनलाइन स्टोर (Redis) में मैटेरियलाइज़ किया जाता है। इसके अलावा, फीचर्स को स्ट्रीमिंग स्रोतों (Kafka टॉपिक्स) से ऑनलाइन स्टोर में भी इनजेस्ट किया जाता है। Feast ने हाल ही में स्ट्रीमिंग डेटा स्रोतों के लिए समर्थन जोड़ा है (बैच डेटा स्रोतों के अलावा) जो वर्तमान में केवल Redis के लिए समर्थित है। स्ट्रीमिंग डेटा स्रोतों का समर्थन करना रियल-टाइम AI/ML उपयोग के मामलों के लिए बहुत महत्वपूर्ण है क्योंकि ये उपयोग के मामले ताजा लाइव डेटा पर भरोसा करते हैं।
एक उदाहरण के रूप में, Better.com के लिए लीड स्कोरिंग उपयोग के मामले में, नए लीड्स को पूरे दिन लगातार इनजेस्ट किया जा रहा है। फीचर्स कई अलग-अलग स्रोतों से आते हैं, और दोनों एंटिटीज़ (लीड्स) और उन्हें स्कोर करने के लिए उपयोग किए जाने वाले फीचर्स हर समय अपडेट होते रहते हैं, इस प्रकार लीड्स को रैंक और री-रैंक किया जाता है। जैसे ही एक नया लीड होता है, उसे इनजेस्ट किया जाता है और मॉडल द्वारा स्कोर किया जाता है। उसी समय जब इसे ऑनलाइन स्टोर में इनजेस्ट किया जाता है, हम इसे जल्द ही री-रैंक करना चाह सकते हैं। Better.com लीड्स 48 घंटों के बाद समाप्त हो जाती हैं, और इसे Redis ऑनलाइन स्टोर में केवल टाइम टू लिव (TTL) को 48 घंटे पर सेट करके लागू किया जाता है, ताकि 48 घंटों के बाद एंटिटी (लीड) और संबद्ध फीचर वेक्टर्स समाप्त हो जाएं। तो फीचर स्टोर स्वचालित रूप से खुद को साफ करता है और कोई बासी एंटिटी या फीचर मूल्यवान ऑनलाइन स्टोरेज नहीं लेते।
Feast का एक और दिलचस्प कार्यान्वयन Microsoft Azure फीचर स्टोर है। आप इसकी आर्किटेक्चर यहां देख सकते हैं। यह Azure क्लाउड पर चलता है जो कम विलंबता वाले रियल-टाइम AI/ML उपयोग के मामलों के लिए अनुकूलित है, बैच और स्ट्रीमिंग दोनों स्रोतों का समर्थन करता है, साथ ही Azure Data & AI इकोसिस्टम में एकीकरण। फीचर्स को ऑनलाइन स्टोर में बैच स्रोतों (Azure Synapse Serverless SQL, Azure Storage / ADLS) और स्ट्रीमिंग स्रोतों (Azure Event Hub) दोनों से इनजेस्ट किया जाता है। यदि आप पहले से ही Azure पर तैनात हैं या Azure इकोसिस्टम से परिचित हैं, तो यह फीचर स्टोर आपके लिए सही हो सकता है। ऑनलाइन स्टोर के लिए, यह Azure Cache for Redis का उपयोग करता है, और Azure Redis के एंटरप्राइज टियर्स के साथ, इसमें एक्टिव-एक्टिव जियो-डुप्लिकेशन शामिल है जो वैश्विक स्तर पर वितरित कैश बनाने के लिए 99.999% तक उपलब्धता के साथ होता है। इसके अलावा, एंटरप्राइज फ्लैश टियर का उपयोग करके आगे लागत में कमी प्राप्त की जा सकती है जो Redis को एक टियर्ड मेमोरी आर्किटेक्चर पर चलाता है जो डेटा स्टोर करने के लिए इन-मेमोरी (DRAM) और फ्लैश मेमोरी (NVMe या SSD) दोनों का उपयोग करता है।
2. Wix DIY फीचर स्टोर - MLOps प्लेटफॉर्म की आधारशिला
नीचे रियल-टाइम AI/ML उपयोग के मामलों को लागू करने के लिए एक अलग आर्किटेक्चर है। यह लोकप्रिय वेबसाइट निर्माण प्लेटफॉर्म Wix के फीचर स्टोर आर्किटेक्चर है। इसका उपयोग रियल-टाइम उपयोग के मामलों जैसे अनुशंसाओं, चर्न और प्रीमियम भविष्यवाणियों, रैंकिंग, और स्पैम क्लासिफायर्स के लिए किया जाता है। Wix 200M से अधिक पंजीकृत उपयोगकर्ताओं को सेवा प्रदान करता है जिनमें से केवल एक छोटा अंश किसी भी समय 'सक्रिय उपयोगकर्ता' होते हैं। इसका फीचर स्टोर के कार्यान्वयन के तरीके पर बड़ा प्रभाव पड़ा। आइए एक नज़र डालें।
नीचे दी गई जानकारी Ran Romano द्वारा दिए गए एक TechTalk प्रस्तुति पर आधारित है जब वह Wix में ML इंजीनियरिंग का नेतृत्व कर रहे थे। उनके प्रोडक्शन उपयोग के मामलों में से कुछ के लिए, उन्हें मिलीसेकंड के भीतर फीचर वेक्टर्स निकालने की आवश्यकता होती है।
कच्चा डेटा AWS पर S3 बकेट में Parquet फाइलों में संग्रहीत है, और व्यावसायिक इकाइयों (जैसे 'एडिटर्स', 'रेस्तरां', 'बुकिंग्स', आदि) द्वारा और फिर तारीख द्वारा पार्टीशन किया गया है। यह Wix डेटा प्लेटफॉर्म का हिस्सा है जिसका उपयोग इसके डेटा विश्लेषकों द्वारा किया जाता है जो Wix ML प्लेटफॉर्म से वर्षों पहले का है। एक दैनिक बिल्ड बैच प्रक्रिया में Spark, SQL का उपयोग करके (जिसमें मिनटों से घंटों लगते हैं) सभी उपयोगकर्ताओं के इतिहास फीचर्स को S3 से निकाला जाता है, पिवट किया जाता है और उपयोगकर्ता द्वारा एकत्रित किया जाता है, और ऑफलाइन स्टोर (Apache Hbase) में इनजेस्ट किया जाता है। यह अपने उपयोगकर्ताओं के इतिहास की बहुत तेज, 'उपयोगकर्ता द्वारा', लुकअप प्रदान करता है। एक बार सिस्टम द्वारा पता चलने पर कि एक उपयोगकर्ता वर्तमान में सक्रिय है, एक 'वार्मअप' प्रक्रिया शुरू हो जाती है और उस उपयोगकर्ता के फीचर्स को ऑनलाइन स्टोर (Redis) में लोड किया जाता है जो ऑफलाइन स्टोर की तुलना में बहुत छोटा है क्योंकि यह केवल सक्रिय उपयोगकर्ताओं के उपयोगकर्ता इतिहास को रखता है। यह 'वार्मअप' प्रक्रिया कई सेकंड ले सकती है। और अंत में, ऑनलाइन फीचर स्टोर में फीचर्स को उपयोगकर्ता से आने वाले प्रत्येक इवेंट के लिए स्ट्रीमिंग स्रोतों से सीधे ताजा लाइव रियल-टाइम डेटा का उपयोग करके लगातार अपडेट किया जाता है (Apache Storm का उपयोग करके)।
इस प्रकार की आर्किटेक्चर में Feast आर्किटेक्चर की तुलना में राइट्स टू रीड्स का अनुपात कम होता है, जो मैटेरियलाइज़ेशन और ऑनलाइन स्टोरेज के संदर्भ में बहुत कुशल है क्योंकि यह सभी उपयोगकर्ताओं के बजाय केवल सक्रिय उपयोगकर्ताओं के लिए ऑनलाइन स्टोर में फीचर्स स्टोर करता है। चूंकि सक्रिय उपयोगकर्ता किसी भी समय Wix के भीतर सभी पंजीकृत उपयोगकर्ताओं का एक छोटा अंश बनाते हैं, यह एक बड़ी बचत दर्शाता है। हालांकि, यह एक कीमत पर आता है। जबकि ऑनलाइन स्टोर से फीचर्स प्राप्त करना बहुत तेज है, मिलीसेकंड के भीतर, यह केवल तभी होता है जब फीचर्स पहले से ही ऑनलाइन स्टोर में मौजूद हों। रेस कंडीशन्स के कारण, क्योंकि वार्मअप प्रक्रिया कई सेकंड लेती है, यह प्रासंगिक फीचर्स को लोड करने के लिए पर्याप्त तेज नहीं होगी जब उपयोगकर्ता सक्रिय हो जाता है। इसलिए, उस उपयोगकर्ता के लिए स्कोरिंग या भविष्यवाणी केवल विफल हो जाएगी। यह तब तक ठीक है जब तक उपयोग का मामला महत्वपूर्ण प्रवाह का हिस्सा नहीं है या लेनदेन अनुमोदन या धोखाधड़ी रोकथाम जैसे मिशन-महत्वपूर्ण उपयोग के मामलों के लिए नहीं है। इस प्रकार की आर्किटेक्चर Wix के लिए भी बहुत विशिष्ट है, जिसमें किसी भी समय केवल एक छोटा अंश उपयोगकर्ता सक्रिय उपयोगकर्ता होते हैं।
3. कमर्शियल फीचर स्टोर Tecton
आइए अब कमर्शियल एंटरप्राइज फीचर स्टोर Tecton की आर्किटेक्चर पर नज़र डालें। जैसा कि हम नीचे दिए गए आरेख में देख सकते हैं, बैच डेटा स्रोतों और स्ट्रीमिंग डेटा स्रोतों के अलावा, Tecton 'आउट-ऑफ-द-बॉक्स' रियल-टाइम डेटा स्रोतों का भी समर्थन करता है। इन्हें 'रियल-टाइम फीचर्स' या 'रियल-टाइम' ट्रांसफॉर्मेशन भी कहा जाता है। रियल-टाइम फीचर्स की गणना केवल इन्फरेंस अनुरोध पर की जा सकती है। उदाहरण के लिए, संदिग्ध लेनदेन के आकार और अंतिम लेनदेन के आकार के बीच का अंतर। इसलिए, ऊपर ओपन सोर्स Feast के साथ Better.com के मामले में, Better.com ने रियल-टाइम फीचर्स के लिए समर्थन स्वयं विकसित किया। Tecton फीचर स्टोर के साथ, इसे लागू करना आसान है क्योंकि यह फीचर स्टोर द्वारा मूल रूप से समर्थित है। Feast और Wix फीचर स्टोर्स की तरह, Tecton भी रजिस्ट्री में फीचर्स को परिभाषित करता है ताकि तार्किक परिभाषा ऑफलाइन और ऑनलाइन दोनों स्टोर्स के लिए एक बार परिभाषित हो। यह ट्रेनिंग-सर्विंग स्क्यू को कम करके प्रोडक्शन में ML मॉडल की उच्च सटीकता सुनिश्चित करता है।
ऑफलाइन स्टोर, ऑनलाइन स्टोर, और बेंचमार्किंग के चुनाव के संबंध में, ऑफलाइन फीचर स्टोर के लिए Tecton S3 का समर्थन करता है, ऑनलाइन स्टोर के लिए Tecton अब अपने ग्राहकों को DynamoDB और Redis Enterprise Cloud के बीच एक विकल्प प्रदान करता है। हाल ही में एक प्रस्तुति में, Tecton CTO केविन स्टम्फ ने हाल ही में कंपनी द्वारा किए गए बेंचमार्क के आधार पर अपने ऑनलाइन फीचर स्टोर को चुनने के तरीके पर सुझाव प्रदान किए। विलंबता और थ्रूपुट को बेंचमार्क करने के अलावा, Tecton ने ऑनलाइन स्टोर की लागत को भी बेंचमार्क किया। यह क्यों महत्वपूर्ण है? उच्च थ्रूपुट या कम विलंबता उपयोग के मामलों के लिए, ऑनलाइन स्टोर की लागत पूरे MLOps प्लेटफॉर्म की कुल स्वामित्व लागत का एक बड़ा और महत्वपूर्ण हिस्सा हो सकती है, इसलिए कोई भी लागत बचत पर्याप्त हो सकती है।
Tecton के बेंचमार्किंग की निचली रेखा यह है कि Tecton के उपयोगकर्ताओं के लिए विशिष्ट उच्च थ्रूपुट उपयोग के मामलों के लिए, Redis Enterprise DynamoDB की तुलना में 3x तेज था और साथ ही 14x कम खर्चीला था।
तो कैच क्या है आप पूछ सकते हैं? यदि आपके पास केवल एक उपयोग का मामला है, और इसमें उच्च या सुसंगत थ्रूपुट नहीं है, और इसमें कोई सख्त विलंबता आवश्यकताएं नहीं हैं, तो आप DynamoDB के साथ जा सकते हैं। आप Tecton के बेंचमार्क के पूर्ण विवरण और परिणाम यहां पा सकते हैं।
4. कमर्शियल फीचर स्टोर Qwak का उपयोग करके Lightricks
नीचे फीचर स्टोर आर्किटेक्चर का एक और उदाहरण है। यह Lightricks द्वारा उपयोग किया जाता है, जो कमर्शियल फीचर स्टोर Qwak पर आधारित है। Lightricks एक यूनिकॉर्न कंपनी है जो वीडियो और इमेज एडिटिंग मोबाइल ऐप विकसित करती है, विशेष रूप से अपने सेल्फी-एडिटिंग ऐप, Facetune के लिए जानी जाती है। यह अपने अनुशंसा प्रणाली के लिए फीचर स्टोर का उपयोग करता है।
ऊपर दिए गए आरेख में दिखाए अनुसार, Tecton की तरह, Qwak फीचर स्टोर तीन प्रकार के फीचर स्रोतों का समर्थन करता है - बैच, स्ट्रीमिंग, और रियल-टाइम फीचर्स।
यह ध्यान रखना महत्वपूर्ण है कि Qwak फीचर स्टोर के साथ, फीचर्स का फीचर स्टोर में मैटेरियलाइज़ेशन कच्चे डेटा स्रोतों से सीधे ऑफलाइन स्टोर (S3 पर Parquet फाइलों का उपयोग करके) और ऑनलाइन स्टोर (Redis का उपयोग करके) दोनों के लिए किया जाता है। यह Wix, Feast, या Tecton के फीचर स्टोर उदाहरणों की तुलना में अलग है जिसमें बैच स्रोतों के लिए ऑनलाइन स्टोर का मैटेरियलाइज़ेशन ऑफलाइन स्टोर से ऑनलाइन स्टोर में किया जाता है। इसका लाभ यह है कि न केवल एक फीचर का ट्रांसफॉर्मेशन लॉजिक ट्रेनिंग और सर्विंग फ्लोज़ में एकीकृत है (ऊपर Feast, Wix, और Tecton के फीचर स्टोर्स की तरह), बल्कि वास्तविक ट्रांसफॉर्मेशन या फीचर गणना समान रूप से की जाती है, जिससे ट्रेनिंग-सर्विंग स्क्यू और कम हो जाता है। कच्चे डेटा से सीधे ऑफलाइन और ऑनलाइन के लिए एकीकृत डेटा पाइपलाइन होने में प्रोडक्शन के दौरान और भी अधिक सटीकता सुनिश्चित करने की क्षमता होती है। आप Qwak के फीचर स्टोर आर्किटेक्चर और घटकों के बारे में इस प्रस्तुति में अधिक जानकारी पा सकते हैं।
सारांश
इस पोस्ट में, हमने रियल-टाइम AI/ML के लिए कई फीचर स्टोर्स के बेंचमार्क और आर्किटेक्चर के मुख्य अंशों की समीक्षा की। पहला ओपन सोर्स Feast है, दूसरा DIY Wix फीचर स्टोर, तीसरा Tecton से, और चौथा Qwak द्वारा। हमने इन कंपनियों द्वारा यह देखने के लिए किए गए कुछ बेंचमार्क के मुख्य अंशों की भी समीक्षा की कि कौन सा ऑनलाइन स्टोर सबसे अधिक प्रदर्शनकारी और सबसे अधिक लागत-प्रभावी है। हमने यह भी खोजा कि ऑनलाइन स्टोर से फीचर्स निकालने के लिए किस तंत्र या फीचर सर्वर का उपयोग करना है। हमने देखा कि आर्किटेक्चर, समर्थित फीचर प्रकार, और चुने गए घटकों के आधार पर फीचर स्टोर्स के प्रदर्शन और लागत में महत्वपूर्ण अंतर हैं।
मूल रूप से KDnuggets में प्रकाशित।
