Artificial Intelligence1 min read

From Data Silos to Feature Serving: How We Unified Fragmented Data for Training, Inference, and Reuse

By · Published by Everything Blog

In short

HubSpot's feature store architecture is organized into a discovery catalog, an online store, and an offline data lake. Apache HBase delivers low-latency lookups for real-time model inferences, while Apache Iceberg maintains the offline repository for batch training. A Spark streaming pipeline captures HBase updates and stages them on S3, allowing a daily loader to generate wide point-in-time rows in Iceberg that eliminate complex joins during training.

Key points

  • Teams can access existing SQL tables, microservices, and CRM properties directly through…: Teams can access existing SQL tables, microservices, and CRM properties directly through a single unified interface without duplicating raw data.
  • Automated synchronization captures HBase write events to ensure consistent feature values…: Automated synchronization captures HBase write events to ensure consistent feature values across both training models and production inference.
  • Daily loader jobs generate wide point-in-time entity rows within Iceberg to bypass resour…: Daily loader jobs generate wide point-in-time entity rows within Iceberg to bypass resource-heavy joins during model training runs.

Sources checked by our analysis pipeline: 1

Written by Leena Bhandari, Senior Software Engineer II, Andrea Cicalese, Senior Software Engineer II, and Durai Ramasubramanian, Senior Software Engineer II at HubSpot.

Why is fragmented data a bottleneck for engineering teams?

Every machine learning model runs on features which are signals it learns from and reasons over. In a large organization they are scattered across operational databases, warehouse tables, event streams, and the pipelines that individual teams have built. An ML engineer starting a new model first has to find the signals they need, make sense of the data, then write one-off code to extract and transform it. The next team that needs an overlapping signal builds it all over again. This makes shipping a new functionality slow and hard. The need for a unified store has sharpened as teams build LLM and agent powered features needing a shared, trustworthy place to find and serve context at scale.

A Feature store is a central layer where features are defined once, then discovered and reused across teams and across the training-to-serving boundary. But in a large organization, most of that…

Artificial Intelligence