{
  "source_file": "0930",
  "source_platform": "个人博客",
  "author": "Chip Huyen",
  "title_listed": "Self-serve feature platforms: architectures and APIs",
  "keywords": "特征平台,架构,API",
  "domain": "数据处理",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://huyenchip.com/2023/01/08/self-serve-feature-platforms.html",
  "publish_date": "2023-01",
  "corpus_stage": "推理部署",
  "notes": "自助特征平台架构设计",
  "id": "ceb8bae62204",
  "collected_at": "2026-10-02T14:14:25",
  "title": "Self-serve feature platforms: architectures and APIs",
  "body_markdown": "The last few years saw the maturation of a core component of the MLOps stack that has significantly improved the ML production workflows: feature platforms. A feature platform handles feature engineering, feature computation, and serving computed features for models to use to generate predictions.\nLinkedIn, for example, mentioned that they’ve deployed\nFeathr\n, their feature platform,\nfor dozens of applications at LinkedIn including Search, Feed, and Ads\n. Their feature platform\nreduced engineering time required for adding and experimenting with new features from weeks to days\n, while\nperformed faster than the custom feature processing pipelines that they replaced by as much as 50%.\nThis post consists of two parts. The first part discusses the evolution of feature platforms, how they differ from model platforms and feature stores. The second part discusses the core challenges of making feature platforms self-serve for data scientists and increase the iteration speed for feature engineering.\nIf you’re already familiar with feature platforms, you might want to skip Part I. To see the a list of public feature platforms referenced for this post, see\nComparison of feature platforms\n.\nPart I. Evolution of feature platforms\nThe need for feature platforms arose when companies moved from batch prediction to online prediction. Without a feature platform, online prediction at scale for many use cases would be hard, if not impossible. This doesn’t mean that a feature platform can’t support batch prediction. For many companies, a feature platform can be used to support both batch and online prediction.\nA challenge for most online prediction use cases is latency, which results from 3 types of latency (excluding network latency):\nFeature computation latency\n: time it takes to compute features from raw data. If a model only uses features that have been precomputed, this value will be none during inference.\nFeature retrieval latency\n: time it takes for the prediction service to retrieve computed features needed to compute prediction.\nPrediction computation latency\n: time it takes for a model to generate a prediction from computed features.\nPrediction computation is relatively well-researched, and many tools have been developed to optimize it. Feature platforms are designed to optimize feature computation and feature retrieval, not prediction computation latency.\nFeature platform vs. feature store\nSince the industry is still new, people might have different opinions, but generally, a feature store is part of a feature platform. The main goals of a feature store are:\nReduce feature retrieval latency\nStore computed features for reuse to reduce computation cost: multiple models that need the same feature should be able to reuse that feature without redundant computation.\nIn its simplest form, a feature store is a key-value store that stores computed features in-memory. Common key-value stores include DynamoDB, Redis, Bigtable. In its moderately more complex form, a feature store also handles persisting feature values on disk so that they can be used for training, ensuring the train-predict consistency.\nFeature platforms handle both feature retrieval and feature computation. The most notable examples of feature platforms are Airbnb’s Chronon (previously Zipline) and LinkedIn’s\nFeathr\n(open source).\nFeature stores like Feast, Amazon SageMaker Feature Store, and Vertex AI Feature Store do not handle feature computation, and therefore, are not feature platforms.\nFeature platform vs. model platform\nAs online prediction use cases mature, we see more and more companies separating their feature platform from their model platform, as they have distinct responsibilities and requirements.\nModel platform\nA model platform concerns how models are packaged and served. It usually consists of three major components:\nModel deployment API\n: how to package a trained model (e.g. serialized, versioned, tagged) with necessary dependencies. In many cases, trained models can also be automatically optimized (e.g. quantized). Ideally, model deployment should be self-serve – data scientists should be able to deploy models by themselves instead of handing them off to engineering teams.\nModel registry (model store)\n: responsible for storing and versioning a packaged model to be retrieved for predictions.\nPrediction service\n: responsible for retrieving models, allocating and scaling resources to generate predictions and to serve them to users.\nNote\n: Experimentation can be considered the fourth piece of the model platform. For many companies, model testing (shadow, A/B testing) is handled by a separate team. However, it’d be a lot easier if data scientists can configure experimentations to evaluate their models in production, and the prediction service can route traffic based on the experimentation configurations.\nFeature platform\nA feature platform concerns the whole feature engineering workflow. A feature platform consists of the following components:\nFeature API\n: how data scientists can create, deploy, discover, and experiment with features. Ideally, feature engineering should be\nself-serve\nfor data scientists, so that they can do their job without having to pair with or wait for data engineers. This can also free data engineers to focus on more interesting work.\nFeature catalog\n: a catalog to store feature definitions and metadata, so that users can discover and share features.\nComputation engines\n: the engines used to compute features, e.g. Spark, Flink.\nFeature store\n: physical storage of computed feature values.\nFor a company at a\nreasonable scale\n, a feature platform is much harder to build than a model platform for the following reasons.\nCost\n. Companies have repeatedly told me that the majority of their infrastructure cost is in feature computation and storage. For an ecommerce or a fintech company of about 10M accounts, feature computation for their anti-fraud use case alone can be between a million and 10 million USD a year.\nCross-team collaboration between data engineers and data scientists\n. For use cases in computer vision and NLP, features can be computed using a small number of data sources. However, for use cases with tabular data like fraud, recommender system, ETA, dynamic pricing, etc. features are computed from many sources, which require the feature platform to work much more closely with the data platform compared to the model platform.\nIteration speed\n. Given that there are many features for any given model, the need for a platform that enables data scientists to iterate on features quickly is important. Given the right infrastructure, the number of features can grow rapidly. We’ve seen the total number of features for a company growing 2x to 10x over the last 3 years, up to 10,000s features.\nTypes of features a feature platform can compute\nFor a feature platform to handle feature computation, it’s important to consider what types of computation it can, or should handle. In general, companies divide feature computation into three different categories:\nBatch features\nReal-time (RT) features\nNear real-time (NRT) features\nEach of these feature types require different ways to ingest data and different computation engines. Which feature types you need depend on your use cases, business logic, and latency requirements. We’ve seen an increasing number of use cases that require all three feature types. For a detailed analysis of these three different feature types, see\nAppendix: Batch features vs. real-time features vs. near real-time features\n.\nFeature type\nHow\nExample compute engines\nExample\nLatency\nPros\nCons\nBatch\nPrecomputed in a batch process\nSpark\nDaily computed embeddings\nHours, days\nEasy to set up\nStale features\nWasted computation\nNRT\nPrecomputed in a streaming process\nFlink, Spark Streaming\nAvg transaction value over last 30 mins\nSeconds*\nFresh features\nScalable\nCompanies think it's harder to set up\nRT\nComputed at time of prediction\n-\nIf transaction value > $1000\n< 1sec\nEasy to set up\nFresh features\nDoesn't scale\n*\nThe latency gap between real-time and near real-time features is closing, as near real-time feature computation is becoming faster as better streaming technology matures.\nNot all feature platforms can or should handle all feature types. For example, Robinhood’s feature platform, as of 2021, only handles batch features and real-time features. They’re not yet supporting near real-time features, but\nit’s on their roadmap\n.\nReal-time features might be sufficient for a smaller scale and simple online prediction use cases. However, it’s hard to optimize for latency and cost for real-time features, especially as the prediction traffic fluctuates or grows, and the complexity of features increases.\nAs a company onboards more online prediction use cases and their online feature space grows, supporting near real-time features is essential.\nA year ago, I discussed in the post\nReal-time machine learning: challenges and solutions\nthat\nmost companies moving batch prediction to online prediction do so in two major steps\n:\nRe-architect their prediction service to support online prediction, still using only batch features.\nRe-architect their feature platform to support streaming features.\nSince then, I’ve observed this pattern at multiple companies. For example, Instacart discussed their two-step transitions from batch to online prediction in\nLessons Learned: The Journey to Real-Time Machine Learning at Instacart\n. DoorDash’s head of ML infra Hien Luu advised that, in the journey to build out an ML platform, companies should start small, and DoorDash started with their\nhigh throughput, low latency prediction service Sybil\n(2020). After that, they introduced their feature platform\nRiviera\n(2021), then\nFabricator\n(2022).\nPart 2. Self-serve feature engineering\nChallenge: slow iteration speed for streaming features\nWorkflows for batch features are well understood – data scientists are familiar with the process of using tools like pandas, Spark. Workflows for streaming features, however, still have much to desire for.\nEven the household-name companies with high MLOps maturity we’ve interviewed have challenges with the iteration speed for streaming features.\nThe long iteration cycle for streaming features discourages data scientists from working with them, even if these features seem to show a lot of promise.\nOne of their data scientists told us that: “Instead of spending a quarter struggling with a streaming feature, I’d rather experiment with 10 batch features.”\nWe categorized the causes for the slow iteration speed into two buckets:\nlack of data scientist-friendly API\n, and\nlack of functionality for fast experimentation\n.\n1. Feature API\nStreaming is a concept from the infrastructure world. True streaming engines like Flink are built on top of JVM, a place most data scientists aren’t acquainted with. This fact is, unfortunately, often dismissed by the infra engineers who build feature platforms.\nScala or Scala-inspired interface\nWe’ve seen early generations of feature platforms adopt a Scala or Kotlin interface. The image below is just some examples. When I ask infra engineers if they find Scala API to be a challenge for users to adopt, the answer is usually no – “data scientists are engineers, they can learn a new language.” When I ask the same questions to data scientists, the answer is usually yes. Many companies that have adopted a Scala interface.\nStripe, Uber, Twitter are some of the companies that originally adopted Scala for their feature APIs\nSQL interface\nOur impression, from talking with our colleagues in streaming, is that there’s a consensus that SQL is inevitable. Almost all streaming engines have introduced their own SQL interfaces (see Flink SQL, KSQL, Dataflow SQL). Some feature platforms, therefore, adopt SQL.\nDoorDash, Snap, Gojek are some of the companies that originally adopted SQL for their feature APIs.\nThe SQL part is the transformation.\nThe rest is feature config in YAML or JSON.\nIf a company goes with SQL, the next question is which SQL dialect to support. Some companies use Flink SQL directly as their feature API. In the image above, DoorDash seems to be using Flink SQL. Snap uses Spark SQL, but the example given is too simple to determine the time semantics they support.\nUsing SQL directly as an API, however, has certain drawbacks:\nInsufficient time semantics\n, such as different window types for aggregations (e.g. tumbling / hopping / sessionization window) and point-in-time joins.\nLack of composability\n. Feature pipelines can be complex. We need a language that allows building small pieces of logic independently and stitching them together, while making the pieces reusable.\nPython interface\nWhile SQL is increasingly gaining popularity with data scientists, Python is still the lingua franca of data science. In the last couple of years, both LinkedIn and Airbnb switched to a Python interface for their feature API.\nLinkedIn and Airbnb are some of the companies that have switched to Python for their feature APIs.\nNote that while Feathr supports streaming processing, it does NOT support streaming aggregations.\nLoading…\nConsiderations for feature APIs\n1. One-off batch computation vs. ongoing stream computation\nIf you compute your feature on fixed batch data like a CSV file, it’s a one-off job. If you compute your feature on an incoming stream of data, the value needs to be continually computed with new values, which makes it a long-running job. After you’ve written a streaming feature logic, executing this logic requires starting a long-running job. Data scientists, who are used to working with notebooks, might find executing and maintaining long-running jobs challenging.\nBecause the outputs of streaming feature computation are continually generated, we need to write them somewhere. Figuring out where to write to and configuring an output schema with the correctly-formatted keys to match existing data tables can also be challenging.\nIt’d be ideal if the feature API backend also handles starting streaming jobs and output schemas.\n2. Design decision: separation of transformation logic and feature logic\nTransformation refers to the function applied on data: e.g. count of product views, mean of transaction value. A feature consists of a transformation, sources (where to apply this transformation on), and sinks (where to write the computed feature values to). Transformation logic and feature logic don’t have to be written in the same language.\nFor both DoorDash and Snap, transformation logic is in SQL, but feature logic is configured in YAML.\nFor Feathr and Airbnb, both transformation logic and feature logic are in Python.\nThe separation of transformation and feature serves two purposes:\nIt allows the reuse of transformation logic. For example, the same transformation can be applied to different sources to create different features.\nIt creates a clean abstraction that allows different personas to work together. For example, data scientists can focus on creating transformations, and if they need help configuring the long-running jobs to compute their streaming features, they can collaborate with data engineers on feature configuration.\n2. Functionality for fast experimentation\nIn this section, we’ll discuss the functionalities that can significantly speed up iteration for streaming features.\nData discoverability and governance\nFeature discoverability\n: Say, you have a new idea for a streaming feature to be used for your model. Because feature computation and storage are expensive, the first thing you might want to do is to see whether that feature is already being used by another model or another team, so that you can reuse it\nSource discoverability\n: You might want to see if this feature is actually feasible given your data setup. You might want to look up what sources are available.\nData governance\n: Talking about data discoverability, it’s important to consider that some data is sensitive and shouldn’t be accessible by everyone. It’s important to:\nAssign roles to users and configure which data should be accessible by which roles.\nAutomate masking of sensitive, PII data.\nPropagate data policy – if a feature is derived from a sensitive column, it should also be marked as sensitive.\nAutomated backfills\nSince you don’t know if this feature is helpful yet, you don’t want to deploy it to your feature store, say Redis, because it might incur high cost. You want to be able to experiment with it locally first. You want to train your model using this feature to see if it actually helps your model. Generating historical values for this streaming feature so that you can experiment with it is called backfilling. Backfilling for streaming features is hard, as it requires point-in-time correctness. For more information on time travel and backfilling, see\nIntroduction to streaming for data scientists\n.\nIn a talk in December 2021, Spotify mentioned\n3 killer features for fast iteration\nthat they wish they had. The second point is automated backfills. [The two other points are point-in-time joins and streaming ingestion, which deserve their own blog post].\nComparison of feature platforms\nFeature store\nFeature API\n(transformation - feature)\nStream comput. engine\nLinkedIn\nVenice\n,\nFedex\nPython - Python\nSamza, Flink\nAirbnb\nHBase-based\nPython - Python\nSpark Streaming\nInstacart\nScylla, Redis\n? - YAML\nFlink\nDoorDash\nRedis, CockroachDB\nSQL - YAML\nFlink\nSnap\nKeyDB\n(multithreaded fork of Redis)\nSQL - YAML\nSpark Streaming\nStripe\nIn-house, Redis\nScala - ?\nSpark Streaming\nMeta (FB)\nScala-like - ?\nXStream\n,\nVelox\nSpotify\nBigtable\nFlink SQL - ?\nFlink\nUber\nCassandra, DynamoDB\nDSL - ?\nFlink\nLyft\nRedis, DynamoDB\nSQL - YAML\nFlink\nPinterest\nIn-house, memcached\nR\nFlink\nCriteo\nCouchbase\nSQL - JSON\nFlink\nBinance\nFlink SQL - Python\nFlink\nTwitter\nManhattan\n, CockroachDB\nScala\nHeron\nGojek\nDynamoDB\nSQL - JSON\nFlink\nEtsy\nBigtable\nScala - ?\nDataflow\nReference feature platforms\n[2018]\nPaypal\n:\nData Pipelines for Real-Time Fraud Prevention at Scale\n(Mikhail Kourjanski)\nAirbnb\n:\nZipline—Airbnb’s Declarative Feature Engineering Framework\n(Nikhil Simha and Varant Zanoyan)\nZipline—Airbnb’s Declarative Feature Engineering Framework\n(2019)\n[2019]\nStripe\n:\nReproducible Machine Learning with Functional Programming\n(Oscar Boykin)\nUber\n:\nMichelangelo Palette: A Feature Engineering Platform at Uber\n(Amit Nene)\nPinterest\n:\nBig Data Machine Learning Platform at Pinterest\n(Yongsheng Wu)\n[2020]\nMeta\n:\nF3: Next-generation Feature Framework at Facebook\n(David Chung & Qiao Yang)\n“Facebook’s Feature Store”\n(Jun Wan, 2021)\nCriteo\n:\nBuilding FeatureFlow, Criteo’s feature data generation platform\n(Piyush Narang)\n[2021]\nDoorDash\n:\nBuilding Riviera: A Declarative Real-Time Feature Engineering Framework\n(Allen Wang & Kunal Shah)\nSpotify\n:\nJukebox : Spotify’s Feature Infrastructure\n(Aman Khan & Daniel Kristjansson)\nPinterest\n:\n“Streamlining the Pinterest ML Feature Ecosystem”\n(Se Won Jang & Sihan Wang)\n[2022]\nLinkedIn\n:\nOpen sourcing Feathr – LinkedIn’s feature store for productive machine learning\n(David Stein)\nDoorDash\n:\nIntroducing Fabricator: A Declarative Feature Engineering Framework\n(Kunal Shah). Fabricator subsumes DoorDash’s previous declarative feature engineering framework Riviera.\nSnap\n:\nSpeed Up Feature Engineering for Recommendation Systems\nInstacart\n:\nLessons Learned: The Journey to Real-Time Machine Learning at Instacart\n(Guanghua Shu)\nGriffin: How Instacart’s ML Platform Tripled ML Applications in a year\n(Sahil Khanna)\nCoupang Eats\n:\nEats data platform: Empowering businesses with data\n(Fred Fu, Coupang 2022)\nAirbnb\n:\nChronon - Airbnb’s Feature Engineering Framework\n(Nikhil Simha). Zipline matured into Chronon, with improved APIs. Chronon is not yet open source.\nBinance\n:\nUsing MLOps to Build a Real-time End-to-End Machine Learning Pipeline\nA Closer Look at Our Machine Learning Feature Store\nGojek\n:\nFeature Engineering at Scale with Dagger and Feast\n(Ravi Suhag)\nFaire\n:\nBuilding Faire’s new marketplace ranking infrastructure\n(Sam Kenny)\nConclusion\nSpeed matters. A well-designed feature platform can improve both the speed at which fresh data can be used to improve ML predictions and the iteration speed for data scientists to improve ML models.\nHowever, building a feature platform requires non-trivial investment. The companies that have discussed their feature platforms are reasonably large tech companies with plenty of expertise and resources. Even then, it can still take 10s of engineers multiple years to build.\nWhen I asked the tech lead of one of these platforms why it took them so long to build their platform, he said: “A lot of time could’ve been saved if we knew what we were doing.” Building a feature platform is a trial and error process, and a wrong design decision could delay the project for a year.\nAs we gain more understanding of the requirements for feature platforms and the underlying technology for streaming computation matures, this process will become more straightforward. I’m excited to see more companies successfully adopt a feature platform without significant investment.\nAcknowledgments\nI’d like to thank\nDeepyaman Datta\n,\nChloe He\n,\nZhenzhong Xu\n,\nAstasia Myers\n, and\nLuke Metz\nfor giving me feedback on the post. Thanks\nNikhil Simha\n,\nHangfei Lin\n, and many other who have generously answered many of my questions.\nAppendix\nBatch features vs. real-time features vs. near real-time features\nSee\nReal-time machine learning: challenges and solutions\nfor more detail.\nBatch features\nBatch features are the easiest to set up\n, since companies can use their existing batch pipeline and only need to add:\nA key-value store low latency retrieval.\nA mechanism to automatically push the computed batch features to the key-value store.\nTwo main drawbacks of batch features:\nFeature staleness\n. If features are computed every hour, they are up to one hour stale.\nWasted computation\n. A company told me they need to compute features for 3 million users each time, which takes them 6 hours, therefore they can refresh their features once every 6 hours. However, only 5% of these users visit their site a day, which means that 95% of the computation is actually wasted.\nReal-time features\nReal-time features are usually the next type\nto be deployed. Say, if you want to compute the number of views your product has had in the last 30 minutes in real-time, here are two of several simple ways you can do so:\nCreate a lambda function that takes in all the recent user activities and counts the number of views.\nStore all the user activities in a database like postgres and write a SQL query to retrieve this count.\nBecause features are computed at prediction time, they are fresh, e.g. in the order of milliseconds.\nWhile real-time features are easy to set up, they’re harder to scale. Because real-time features are computed upon receiving prediction requests, their computation latency adds directly to user-facing latency. Traffic growth and fluctuation can significantly affect computation latency. Complex features might be infeasible to support since they might take too long to compute.\nNear RT / streaming features\nLike batch features, near RT features are also precomputed and at prediction time, the latest values are retrieved and used. Since features are computed async, feature computation latency doesn’t add to user-facing latency. You can use as many features or as complex features as you want.\nUnlike batch features,\nnear RT feature values are recomputed much more frequently, so feature staleness can be in the order of seconds\n(it’s only “near” instead of “completely” real-time.) If a user doesn’t visit your site, its feature values won’t be recomputed, avoiding wasted computation.\nNear RT features are computed using a streaming processing engine.",
  "metadata": {
    "title": "Self-serve feature platforms: architectures and APIs",
    "description": "",
    "keywords": null,
    "author": "Chip Huyen",
    "og:title": "Self-serve feature platforms: architectures and APIs",
    "og:locale": "en_US",
    "og:description": "I work to bring AI into production. I write about AI system design.",
    "og:url": "https://huyenchip.com/2023/01/08/self-serve-feature-platforms.html",
    "og:site_name": "Chip Huyen",
    "og:image": "https://huyenchip.com/assets/pics/real-time-ml-2022/online-prediction.png",
    "og:type": "article",
    "twitter:card": "summary_large_image",
    "article:published_time": "2023-01-08T00:00:00+00:00"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [],
  "images": [
    {
      "status": "ok",
      "url": "https://huyenchip.com/assets/pics/feature-platform/latency.png",
      "bytes": 60780,
      "reused": false,
      "local_path": "attachments/ceb8bae62204/images/body-a4d8322d848e6d30ef8f.png",
      "src": "https://huyenchip.com/assets/pics/feature-platform/latency.png",
      "alt": "Causes for latency in online prediction",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://huyenchip.com/assets/pics/feature-platform/feature-platform-overview.png",
      "bytes": 188941,
      "reused": false,
      "local_path": "attachments/ceb8bae62204/images/body-b9bf992347a1beaaeb50.png",
      "src": "https://huyenchip.com/assets/pics/feature-platform/feature-platform-overview.png",
      "alt": "Where feature platforms fit into the MLOps stack",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://huyenchip.com/assets/pics/feature-platform/scala-api.png",
      "bytes": 1533270,
      "reused": false,
      "local_path": "attachments/ceb8bae62204/images/body-1d8f31f256efb7a911f5.png",
      "src": "https://huyenchip.com/assets/pics/feature-platform/scala-api.png",
      "alt": "Scala as interface for feature API",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://huyenchip.com/assets/pics/feature-platform/sql-api.png",
      "bytes": 1076369,
      "reused": false,
      "local_path": "attachments/ceb8bae62204/images/body-eec677fd342ab760babb.png",
      "src": "https://huyenchip.com/assets/pics/feature-platform/sql-api.png",
      "alt": "SQL as interface for feature API",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://huyenchip.com/assets/pics/feature-platform/python-api.png",
      "bytes": 532974,
      "reused": false,
      "local_path": "attachments/ceb8bae62204/images/body-15a63e4272640fe62ce2.png",
      "src": "https://huyenchip.com/assets/pics/feature-platform/python-api.png",
      "alt": "Python as interface for feature API",
      "downloaded": true
    }
  ],
  "audio": [],
  "videos": [
    {
      "url": "https://www.youtube.com/watch?v=-DgInoUa0uI",
      "src": "https://www.youtube.com/watch?v=-DgInoUa0uI",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair--DgInoUa0uI.mp4",
      "bytes": 45479663,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "1110.120000",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=qv2DtDvpWx8",
      "status": "ok",
      "local_path": "attachments/ceb8bae62204/videos/qv2DtDvpWx8.mp4",
      "bytes": 62856497,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "1840.801000"
    },
    {
      "url": "https://www.youtube.com/watch?v=vksWF8UgWXc",
      "src": "https://www.youtube.com/watch?v=vksWF8UgWXc",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair-vksWF8UgWXc.mp4",
      "bytes": 272775453,
      "valid": true,
      "height": 1080,
      "width": 1852,
      "duration": "5999.661000",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=DNI54vc1ALQ",
      "src": "https://www.youtube.com/watch?v=DNI54vc1ALQ",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair-DNI54vc1ALQ.mp4",
      "bytes": 97155093,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "1391.366667",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=Tg5VEMEsC-0",
      "src": "https://www.youtube.com/watch?app=desktop&v=Tg5VEMEsC-0",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair-Tg5VEMEsC-0.mp4",
      "bytes": 76887312,
      "valid": true,
      "height": 720,
      "width": 1280,
      "duration": "1555.461000",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=t_Omlhh7IJc",
      "src": "https://www.youtube.com/watch?v=t_Omlhh7IJc",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair-t_Omlhh7IJc.mp4",
      "bytes": 626358028,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "2975.381000",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=IQWvQ_VVR50",
      "src": "https://www.youtube.com/watch?v=IQWvQ_VVR50",
      "status": "download_failed",
      "kind": "single_video",
      "error": "ERROR: [youtube] IQWvQ_VVR50: This video is unavailable\n",
      "title": "",
      "retried_at": "2026-10-20T22:25:40Z"
    },
    {
      "url": "https://www.youtube.com/watch?v=gSRjTm4AHjk",
      "src": "https://www.youtube.com/watch?v=gSRjTm4AHjk",
      "status": "ok",
      "kind": "single_video",
      "local_path": "attachments/ceb8bae62204/videos/repair-gSRjTm4AHjk.mp4",
      "bytes": 85447611,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "1217.841000",
      "reused": false
    },
    {
      "url": "https://www.youtube.com/watch?v=Qiegjw4WBGU",
      "src": "https://www.youtube.com/watch?v=Qiegjw4WBGU",
      "status": "download_failed",
      "kind": "single_video",
      "error": "ERROR: [youtube] Qiegjw4WBGU: This video is unavailable\n",
      "title": "",
      "retried_at": "2026-10-20T22:25:40Z"
    }
  ],
  "links": [
    {
      "href": "https://engineering.linkedin.com/blog/2022/open-sourcing-feathr---linkedin-s-feature-store-for-productive-m",
      "label": "Feathr",
      "type": "a"
    },
    {
      "href": "https://github.com/feathr-ai/feathr",
      "label": "Feathr",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2107.07346",
      "label": "reasonable scale",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=-DgInoUa0uI",
      "label": "it’s on their roadmap",
      "type": "a"
    },
    {
      "href": "https://huyenchip.com/2022/01/02/real-time-machine-learning-challenges-and-solutions.html",
      "label": "Real-time machine learning: challenges and solutions",
      "type": "a"
    },
    {
      "href": "https://tech.instacart.com/lessons-learned-the-journey-to-real-time-machine-learning-at-instacart-942f3a656af3",
      "label": "Lessons Learned: The Journey to Real-Time Machine Learning at Instacart",
      "type": "a"
    },
    {
      "href": "https://doordash.engineering/2020/06/29/doordashs-new-prediction-service/",
      "label": "high throughput, low latency prediction service Sybil",
      "type": "a"
    },
    {
      "href": "https://doordash.engineering/2021/03/04/building-a-declarative-real-time-feature-engineering-framework/",
      "label": "Riviera",
      "type": "a"
    },
    {
      "href": "https://doordash.engineering/2022/01/11/introducing-fabricator-a-declarative-feature-engineering-framework/",
      "label": "Fabricator",
      "type": "a"
    },
    {
      "href": "https://docs.google.com/forms/d/e/1FAIpQLSdS2G0n9ACaXLlnj_0GUSbig3gzbSgKhazjFkM3OH-JNOr-wA/viewform?embedded=true",
      "label": "Loading…",
      "type": "iframe"
    },
    {
      "href": "https://huyenchip.com/2022/08/03/stream-processing-for-data-scientists.html",
      "label": "Introduction to streaming for data scientists",
      "type": "a"
    },
    {
      "href": "https://youtu.be/qv2DtDvpWx8?t=999",
      "label": "3 killer features for fast iteration",
      "type": "a"
    },
    {
      "href": "https://github.com/linkedin/venice",
      "label": "Venice",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=vksWF8UgWXc",
      "label": "Fedex",
      "type": "a"
    },
    {
      "href": "https://github.com/Snapchat/KeyDB",
      "label": "KeyDB",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=DNI54vc1ALQ",
      "label": "XStream",
      "type": "a"
    },
    {
      "href": "https://github.com/facebookincubator/velox",
      "label": "Velox",
      "type": "a"
    },
    {
      "href": "https://blog.twitter.com/engineering/en_us/a/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale",
      "label": "Manhattan",
      "type": "a"
    },
    {
      "href": "https://github.com/apache/incubator-heron",
      "label": "Heron",
      "type": "a"
    },
    {
      "href": "https://www.infoq.com/presentations/paypal-data-service-fraud/",
      "label": "Data Pipelines for Real-Time Fraud Prevention at Scale",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?app=desktop&v=Tg5VEMEsC-0",
      "label": "Zipline—Airbnb’s Declarative Feature Engineering Framework",
      "type": "a"
    },
    {
      "href": "https://www.databricks.com/session_eu19/zipline-airbnbs-declarative-feature-engineering-framework",
      "label": "Zipline—Airbnb’s Declarative Feature Engineering Framework",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=t_Omlhh7IJc",
      "label": "Reproducible Machine Learning with Functional Programming",
      "type": "a"
    },
    {
      "href": "https://www.infoq.com/presentations/michelangelo-palette-uber/",
      "label": "Michelangelo Palette: A Feature Engineering Platform at Uber",
      "type": "a"
    },
    {
      "href": "https://www.slideshare.net/Alluxio/pinterest-big-data-machine-learning-platform-at-pinterest?ref=http://featurestore.org/",
      "label": "Big Data Machine Learning Platform at Pinterest",
      "type": "a"
    },
    {
      "href": "https://www.facebook.com/watch/?v=1073947483052122",
      "label": "F3: Next-generation Feature Framework at Facebook",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=IQWvQ_VVR50",
      "label": "“Facebook’s Feature Store”",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=gSRjTm4AHjk",
      "label": "Building FeatureFlow, Criteo’s feature data generation platform",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=qv2DtDvpWx8",
      "label": "Jukebox : Spotify’s Feature Infrastructure",
      "type": "a"
    },
    {
      "href": "https://www.youtube.com/watch?v=Qiegjw4WBGU",
      "label": "“Streamlining the Pinterest ML Feature Ecosystem”",
      "type": "a"
    },
    {
      "href": "https://eng.snap.com/speed-up-feature-engineering",
      "label": "Speed Up Feature Engineering for Recommendation Systems",
      "type": "a"
    },
    {
      "href": "https://www.instacart.com/company/how-its-made/griffin-how-instacarts-ml-platform-tripled-ml-applications-in-a-year/",
      "label": "Griffin: How Instacart’s ML Platform Tripled ML Applications in a year",
      "type": "a"
    },
    {
      "href": "https://medium.com/coupang-engineering/eats-data-platform-empowering-businesses-with-data-3cc00fa9968d",
      "label": "Eats data platform: Empowering businesses with data",
      "type": "a"
    },
    {
      "href": "https://microsites.databricks.com/sites/default/files/2022-07/Introducing-Zipline_An-Open-Source-Feature-Engineering-Platform.pdf",
      "label": "Chronon - Airbnb’s Feature Engineering Framework",
      "type": "a"
    },
    {
      "href": "https://binance.com/en/blog/all/using-mlops-to-build-a-realtime-endtoend-machine-learning-pipeline-3820048062346322706",
      "label": "Using MLOps to Build a Real-time End-to-End Machine Learning Pipeline",
      "type": "a"
    },
    {
      "href": "https://www.binance.com/en/blog/all/a-closer-look-at-our-machine-learning-feature-store-3411614684128221181",
      "label": "A Closer Look at Our Machine Learning Feature Store",
      "type": "a"
    },
    {
      "href": "https://www.tecton.ai/apply/session-video-archive/feature-engineering-at-scale-with-dagger-and-feast/",
      "label": "Feature Engineering at Scale with Dagger and Feast",
      "type": "a"
    },
    {
      "href": "https://craft.faire.com/building-faires-new-marketplace-ranking-infrastructure-a53bf938aba0",
      "label": "Building Faire’s new marketplace ranking infrastructure",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/deepyaman/",
      "label": "Deepyaman Datta",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/chloe-he/",
      "label": "Chloe He",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/zhenzhong-xu-0243003",
      "label": "Zhenzhong Xu",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/astasiamyers",
      "label": "Astasia Myers",
      "type": "a"
    },
    {
      "href": "https://twitter.com/luke_metz",
      "label": "Luke Metz",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/nikhilsimha/",
      "label": "Nikhil Simha",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/hangfei",
      "label": "Hangfei Lin",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:51:52Z",
  "source_url": "https://huyenchip.com/2023/01/08/self-serve-feature-platforms.html",
  "papers": [
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2107.07346",
      "bytes": 2835760,
      "reused": false,
      "local_path": "papers/repair/b358c2c36d00517a1033.pdf"
    },
    {
      "status": "ok",
      "url": "https://microsites.databricks.com/sites/default/files/2022-07/Introducing-Zipline_An-Open-Source-Feature-Engineering-Platform.pdf",
      "bytes": 1635711,
      "reused": false,
      "local_path": "papers/repair/50860e416dac6d4acaf1.pdf"
    }
  ],
  "actual_video_files": [
    {
      "local_path": "attachments/ceb8bae62204/videos/qv2DtDvpWx8.mp4",
      "bytes": 62856497,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "1840.801000",
      "status": "ok"
    }
  ],
  "body_chars": 23810,
  "expected_body_images": 5,
  "discovery_status": "ok",
  "delivery_status": "partial",
  "missing_reason": "download_failed",
  "raw_html": "attachments/ceb8bae62204/pages/source.html",
  "local_html": "attachments/ceb8bae62204/pages/article.html",
  "body_base_path": "attachments/ceb8bae62204/pages/",
  "body_markdown_path": "attachments/ceb8bae62204/pages/article.md"
}