New RunLLM response generated: >>>*# Question* I have a more general question pertaining to Feature Stores vs Orchestrators with Caches: For a web application (exploratory analysis dashboard / BI and decision workflow tracking), that shall make use of DataFrame-like tables with • raw data, • as well as refined features from those … what makes more sense to use? An orchestrator like Flyte or a Feature Store, if on-demand (lazy) access of these data by the app is the main goal, so processing resources are used conservatively but well defined and up-to-date refined data is available to the app? # Answer For a web application focused on exploratory analysis and BI, where on-demand access to DataFrame-like tables is crucial, a Feature Store like Feast is more suitable. Feature Stores are designed to manage and serve features efficiently, ensuring consistent and up-to-date data access across different use cases. They provide a unified serving layer, reducing duplication of effort and ensuring data consistency (source). Flyte, as an orchestrator, excels in managing long-running workflows and batch processing tasks, but it is not optimized for real-time or on-demand data access scenarios (source). Flyte's caching mechanisms can help with reusing results of expensive computations, but it does not replace the need for a feature store when it comes to efficient, on-demand data retrieval. Would you like more detail on how Flyte and Feast can be integrated for specific use cases? Sources: - https://flyte.org/blog/bring-ml-close-to-data-using-feast-and-flyte/ - https://discuss.flyte.org/t/12919770/hello-not-sure-if-this-is-the-right-forum-i-was-wondering-if/ Slack Link https://flyte-org.slack.com/archives/CP2HDHKE1/p1724111974.287549 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.