Feature Store

সমস্যাটা কী?

একটা বড় company-তে অনেকগুলো ML team থাকে — কেউ fraud detection-এ কাজ করছে, কেউ recommendation-এ, কেউ credit scoring-এ। সবারই একটা common জিনিস দরকার: "user-টি গত ৩০ দিনে মোট কত টাকা খরচ করেছে।" এখন যদি প্রতিটি team আলাদাভাবে এই হিসাব করে, তিনটে সমস্যা হয়:

১. একই কাজ তিনবার হয় (অপচয়)। ২. তিন team তিন রকম হিসাব করে — কেউ refund বাদ দেয়, কেউ দেয় না (inconsistency)। ৩. সবচেয়ে বিপজ্জনক — training-এর সময় এক হিসাব, serving-এর সময় আরেক হিসাব হয়ে train/serve skew তৈরি হয়।

এই বিশৃঙ্খলা সামলাতেই এসেছে feature store।

মূল ধারণা

Feature store হলো একটি কেন্দ্রীয় data system যেখানে ML feature-গুলো একবার সংজ্ঞায়িত ও তৈরি হয়, এরপর training ও serving উভয় কাজে নির্ভরযোগ্যভাবে পুনঃব্যবহৃত হয়।

প্রথমে বুঝি feature কী। Feature হলো raw data থেকে বানানো একটা সংখ্যাসূচক signal যা model-কে শেখায়। যেমন raw data হলো "user-এর সব order-এর তালিকা", আর feature হতে পারে "গত ৭ দিনের গড় order মূল্য" বা "শেষ login থেকে কত ঘণ্টা পার হয়েছে।" Model এই feature দেখেই সিদ্ধান্ত নেয়।

Feature store মূলত একটা "library"-র মতো — যেখানে প্রতিটি feature-এর একটা নাম, একটা সংজ্ঞা, আর একটা compute করার নিয়ম লেখা থাকে। যে কেউ সেই নাম দিয়ে feature টেনে নিতে পারে, নতুন করে বানাতে হয় না।

কীভাবে কাজ করে

দুই ধরনের store

Feature store-এর হৃদয়ে দুটি storage থাকে, দুটোর কাজ ভিন্ন:

বৈশিষ্ট্য	Offline Store	Online Store
কাজ	training-এর জন্য historical feature	serving-এর জন্য সর্বশেষ feature
প্রযুক্তি	data warehouse (BigQuery, S3)	key-value DB (Redis, DynamoDB)
Latency	সেকেন্ড/মিনিট চললেও সমস্যা নেই	কয়েক মিলিসেকেন্ড লাগে
Data পরিমাণ	মাস/বছরের পুরো ইতিহাস	শুধু সর্বশেষ মান
পড়ার ধরন	বিশাল batch read	একটা একটা lookup

Consistency ও point-in-time correctness

Training-এর সময় একটা সূক্ষ্ম বিপদ আছে — data leakage। ধরো ১ জানুয়ারির একটা prediction-এর জন্য তুমি ভুল করে ৫ জানুয়ারির feature মান ব্যবহার করলে। তখন model "ভবিষ্যৎ দেখে ফেলছে," যা production-এ সম্ভব না। Feature store point-in-time join করে নিশ্চিত করে যে প্রতিটি training row-এ ঠিক সেই সময়ের feature মানই বসছে।

Freshness

Feature কত তাজা সেটাও জরুরি। "user এই মুহূর্তে cart-এ কী রেখেছে" — এই feature কয়েক সেকেন্ড পুরোনো হলেই অকেজো (streaming feature)। আবার "গত ৬ মাসের আয়" প্রতিদিন একবার update করলেই চলে (batch feature)। Feature store দুই ধরনের freshness-ই সামলায়।

কৌশল

Feature store ব্যবহারে কিছু সাধারণ pattern:

1. Materialization: offline-এ হিসাব করা feature নিয়মিত online store-এ "ঠেলে দেওয়া" হয় যাতে serving-এ দ্রুত পাওয়া যায়।
2. Feature versioning: feature-এর সংজ্ঞা বদলালে নতুন version বানানো হয়, পুরোনো model যেন না ভাঙে।
3. Shared registry: একটা কেন্দ্রীয় তালিকা যেখানে কোম্পানির সব feature খুঁজে পাওয়া যায় — reuse-এর মূল চাবি।

কখন ব্যবহার করবে / করবে না

Feature store দরকার যখন:

• একাধিক team বা model একই feature ব্যবহার করে।
• training আর real-time serving — দুটোই লাগে।
• train/serve skew বড় সমস্যা হয়ে দাঁড়িয়েছে।

দরকার নেই যখন:

• ছোট একটা project, একটাই model, শুধু batch prediction।
• feature-এর সংখ্যা হাতে গোনা আর কেউ reuse করছে না।

বাস্তব উদাহরণ

Uber-এর "Michelangelo" platform-এ feature store ধারণাটা জনপ্রিয় হয়। তাদের ride-pricing, ETA prediction, fraud — সব model একই feature pool থেকে টানে, যেমন "এই এলাকায় গত ১ ঘণ্টায় কতগুলো trip হয়েছে।"

Open-source জগতে Feast সবচেয়ে পরিচিত — এটি offline store হিসেবে BigQuery/Snowflake আর online store হিসেবে Redis/DynamoDB ব্যবহার করে, একই feature definition থেকে দুই জায়গায় feature serve করে। আর Tecton হলো এর managed, enterprise সংস্করণ যেটি streaming feature, freshness আর monitoring সহ একটা সম্পূর্ণ সমাধান দেয়। দুটোরই মূল প্রতিশ্রুতি একই — "define once, use everywhere, no skew."