feature store ऐसी कौन सी समस्या हल करता है जो एक अच्छी data pipeline से हल नहीं होती?

वह training और serving की एकरूपता हल करता है। एक ही feature को ट्रेनिंग के लिए batch history से और serving के लिए ताजा डेटा से कम latency पर निकालना पड़ता है, और जब ये दो अलग implementations होते हैं तो वे खिसक जाते हैं। feature store feature को एक बार परिभाषित करता है, उसे ट्रेनिंग डेटा के लिए offline store में और millisecond lookups के लिए online store में materialize करता है, और point in time सही joins देता है।

समस्या यह है कि एक ही feature की दो जिंदगियां होती हैं। ट्रेनिंग के लिए मुझे किसी पुराने timestamp पर उसकी वैल्यू चाहिए, ऐसे join के साथ जिसमें उसके बाद हुई कोई बात गलती से न घुसे। serving के लिए मुझे वह अभी चाहिए, दस millisecond से कम में, entity के हिसाब से। अगर ये दो codebases हैं, और शुरुआत हमेशा दो codebases से ही होती है, तो वे खिसक जाते हैं। कोई training job में window तीस दिन से अट्ठाईस कर देता है, serving वाले रास्ते को कोई छूता नहीं, और अब मॉडल उन features पर score कर रहा है जिन पर वह कभी ट्रेन ही नहीं हुआ। यह खिसकाव चुपचाप होता है, और यही इसे महंगा बनाता है। feature store आपको एक परिभाषा देता है जो ट्रेनिंग के लिए offline table में और serving के लिए online key value store में materialize होती है, साथ में point in time joins ताकि पुरानी query भविष्य को लीक न कर सके। कहा जाए तो दो मॉडल वाली टीम के लिए मैं इसे खड़ा नहीं करूंगा। खर्च असली है, और ज्यादातर फायदा आपको एक साझा transformation library और cache में लिखने वाली एक scheduled job से मिल जाता है। managed feature store की तरफ मैं तब जाऊंगा जब कई टीमें features साझा करने लगें, क्योंकि तभी दोहरी परिभाषाएं बढ़ने लगती हैं।