Feature Store & Data Versioning

#Pendahuluan

Data engineer tidak hanya bertanggung jawab atas pipeline analitik. Di perusahaan yang sudah membangun model machine learning (ML), kalian juga bertanggung jawab menyediakan fitur (features) yang konsisten dan data yang dapat di-trace ke model yang berjalan di production.

Dua konsep yang menjawab kebutuhan ini adalah feature store dan data versioning. Feature store adalah pusat penyimpanan fitur yang bisa dipakai bersama oleh tim data science; data versioning memastikan setiap dataset, model, dan kode dapat dikembalikan ke kondisi sebelumnya dengan jejak yang jelas.

#Apa itu Feature Store?

Feature store adalah layer yang menyimpan fitur yang sudah dihitung (computed features) agar bisa dipakai ulang oleh banyak model dan digunakan secara konsisten antara training dan serving.

Kata kunci di sini adalah training-serving skew: saat fitur dihitung dengan kode berbeda di training dan di serving, model menghasilkan prediksi yang berbeda untuk data yang sama. Feature store menghapus masalah ini karena fitur dihitung sekali, disimpan, lalu dipakai dari sumber yang sama di kedua fase.

- Titik penyimpanan tunggal fitur yang sudah jadi (computed feature)
- API konsisten untuk training dan real-time serving
- Konsistensi definisi fitur antara online dan offline store
- Metadata: siapa membuat fitur, dari sumber apa, versi berapa
- Lineage dari raw data sampai fitur siap pakai

#Offline Store vs Online Store

Saat model dilatih, ia butuh jutaan baris riwayat fitur — itu dari offline store. Saat model melayani prediksi, ia butuh nilai fitur terkini untuk satu user dalam hitungan milidetik — itu dari online store.

Mari lihat bagaimana sebuah definisi fitur disatukan:

from feast import Entity, FeatureView, Field
from feast.types import Float32, Int64
from feast.infra.offline_stores.bigquery.source import BigQuerySource
 
user = Entity(
    name="user",
    join_keys=["user_id"],
)
 
user_features = FeatureView(
    name="user_order_velocity",
    entities=[user],
    schema=[
        Field(name="order_count_7d", dtype=Int64),
        Field(name="avg_basket_size_7d", dtype=Float32),
    ],
    source=BigQuerySource(
        table="dwh.fact_orders",
        timestamp_field="event_timestamp",
    ),
    ttl=...,
)

#Kenapa Data Engineering Butuh Data Versioning?

Dataset berubah setiap hari: kolom bertambah, data diperbaiki, atau sumber berubah. Tanpa versioning, model yang sudah dilatih kemarin tidak bisa di-reproduksi karena datanya sudah berubah hari ini.

Data versioning menjawab tiga pertanyaan penting:

• Kapan dataset ini dibuat, dan dari sumber apa?
• Apa yang berubah antara versi sebelumnya dan sekarang?
• Bagaimana cara mengembalikan eksperimen ke versi data yang sama persis?

Konsep kunci yang dipakai adalah snapshot: data diimobilisasi pada titik waktu tertentu dengan identitas unik (hash). Karena data bisa sangat besar, snapshot biasanya menyimpan metadata + referensi ke file, bukan salinan penuh.

# menandai versi data saat ini
dvc add data/orders.csv
 
# commit jejak versi ke git
git add data/orders.csv.dvc && git commit -m "feat: snapshot orders 2026-08-15"
 
# menarik versi lama kapan pun
git checkout v1.0 && dvc checkout

#Tooling yang Sering Dipakai

Berikut pembagian alat yang umum di industri:

Feature Store:
  - Feast / Tecton / Databricks Feature Store
  - Amazon SageMaker Feature Store
  - Feast (open source, paling banyak dipakai komunitas)
 
Data Versioning:
  - DVC (Data Version Control) - berbasis Git
  - LakeFS - versioning di atas object storage
  - Delta Lake - ACID + time travel di data lake
  - Pachyderm - versioning berbasis pipeline

Delta Lake layak disorot karena menyatu dengan Spark: setiap tulis menghasilkan versi baru, dan kalian bisa membaca data pada versi tertentu dengan time travel.

-- membaca data pada versi 5
SELECT * FROM orders
VERSION AS OF 5;
 
-- membaca data pada timestamp tertentu
SELECT * FROM orders
TIMESTAMP AS OF '2026-08-15T06:00:00Z';

#Menghubungkan Feature Store dan Data Versioning

Feature store dan data versioning saling melengkapi. Data mentah di-version oleh DVC/Delta Lake; dari data tersebut fitur dihitung dan disimpan di feature store dengan versinya sendiri.

Saat sebuah model mengalami regresi performa, tim bisa menelusuri: fitur mana yang dipakai, versi data dari mana, dan perubahan apa yang terjadi di antara keduanya. Lineage inilah yang mengubah debugging model dari tebakan menjadi investigasi yang terstruktur.

#Penutup

Feature store dan data versioning adalah pilar dari sistem ML yang dapat dipercaya. Feature store memastikan fitur konsisten antara training dan serving, sementara data versioning memastikan setiap eksperimen dapat di-reproduksi dan setiap kegagalan model dapat ditelusuri.

Di episode berikutnya kita akan membahas bagaimana semua layer ini dijalankan di cloud dengan praktik Data Lakehouse yang skalabel.