Belajar MLOps - Data Versioning & Pipelines

#Pendahuluan

Setelah di episode 5 eksperimen tercatat rapi, masih ada satu variabel yang belum terkunci: data. Model kalian dilatih di atas dataset tertentu — dan dataset itu berubah: kolom baru, baris baru, perbaikan labeling. Tanpa versioning data, run yang tercatat di MLflow tidak bisa direproduksi karena data yang sama tidak bisa ditemukan lagi.

Mengapa data versioning begitu penting di MLOps? Karena model adalah fungsi dari data. Dataset v1 dan v2 yang terlihat "hampir sama" bisa menghasilkan model dengan akurasi berbeda — dan tanpa tahu dataset mana yang dipakai run tertentu, seluruh hasil eksperimen kehilangan maknanya. Episode ini mengunci lapisan kedua dari triple reproducibility: code, environment, data.

#Mengapa Git Tidak Cukup untuk Data

Git dirancang untuk file teks kecil. Dataset ML berukuran GB sampai TB — kalian tidak bisa (dan tidak seharusnya) meletakkannya di repository git. Masalahnya juga bukan hanya ukuran: kalian butuh menghubungkan versi data ke versi kode sehingga sebuah commit kode bisa mengarah ke dataset yang persis.

Di sinilah DVC (Data Version Control) masuk: ia memberikan semantik git untuk data — hash, riwayat, branch, dan revert — tanpa menyimpan datanya di git. Git menyimpan pointer kecil; data asli tinggal di object storage (S3, GCS, atau disk lokal).

#DVC dalam Praktik

Mulai dengan menginisialisasi DVC di project yang sudah ter-structure dari episode 3:

pip install dvc
dvc init
git add .dvc .dvcignore && git commit -m "chore: init dvc"

Sekarang daftarkan dataset agar di-version:

dvc add data/raw/churn.csv
git add data/raw/churn.csv.dvc data/raw/.gitignore
git commit -m "data: add churn v1.0"

Yang terjadi di belakang layar: DVC menghitung hash (MD5) konten churn.csv, lalu membuat file kecil churn.csv.dvc berisi hash itu. Git menyimpan pointer; data asli tidak masuk git. Untuk membagikan dataset antar mesin, atur remote storage dulu:

dvc remote add -d storage s3://mlops-bucket/dvc
dvc push

Di mesin lain, cukup git clone + dvc pull untuk mendapat dataset dengan hash yang persis sama.

#Menghubungkan Data ke Eksperimen

Kekuatan sebenarnya muncul ketika DVC bertemu MLflow. Catat hash data di setiap run:

import subprocess
import mlflow
 
data_hash = subprocess.run(
    ["dvc", "data", "status"], capture_output=True, text=True
).stdout.strip()
 
with mlflow.start_run():
    mlflow.log_param("data_version", data_hash)
    # ... training seperti biasa ...

Sekarang setiap run bisa menjawab "model ini dilatih di atas dataset hash berapa". Ini adalah jejak lineage paling dasar — yang akan kita lengkapi di episode 11 (model registry) dan 15 (governance).

#LakeFS: Git untuk Data Lake

LakeFS mengambil pendekatan berbeda: ia membuat branch data lake dengan semantik git di atas object storage. Kalian bisa checkout cabang data, melakukan perubahan, dan merge — lengkap dengan atomic commit dan rollback.

lakectl branch create lakefs://repo@experiment/v2
lakectl fs upload lakefs://repo@experiment/v2/churn.csv -s ./churn.csv
lakectl merge lakefs://repo@experiment/v2 lakefs://repo@main

Kapan memilih DVC vs LakeFS?

Untuk belajar MLOps, DVC lebih relevan karena bekerja di level project ML. LakeFS muncul di organisasi yang sudah punya data lake besar — bisa kalian pelajari nanti sebagai pengayaan.

#Feature Store: Menjembatani Data dan Model

Saat ini cukup kenalan dengan konsepnya; detail penuh ada di episode 14. Feature store (Feast, Tecton) menyimpan fitur — hasil transformasi data mentah — agar bisa dipakai konsisten untuk training dan serving.

Masalah yang dipecahkan: data scientist menghitung fitur dengan kode sendiri, dan kode itu sering tidak konsisten antara training dan produksi (training-serving skew). Feature store menyediakan:

• Offline store — fitur historis untuk training.
• Online store — fitur terbaru untuk inference real-time.
• Konsistensi — logika fitur sama untuk keduanya.

Kita akan membedah konsep ini secara penuh di episode 14 dengan Feast.

#Common Pitfalls

• Data besar masuk git → repo membengkak dan tak terkendali; pakai DVC + remote.
• Lupa mencatat versi data di eksperimen → run tidak reproducible; catat hash data.
• File .dvc tidak di-commit → data tidak ter-version di git.
• Mengubah dataset tanpa dvc add → pointer lama, status tidak sinkron.
• Tanpa remote storage → DVC hanya bekerja lokal; set remote sejak awal.

#Penutup

Pada episode 6 ini, kalian telah mengontrol data seperti mengontrol kode.

Inti yang harus dibawa pulang:

• DVC memberi semantik git untuk data: hash, riwayat, revert, dan branch.
• Kaitkan hash data ke setiap run MLflow untuk lineage yang bisa dilacak.
• LakeFS cocok untuk data lake TB+ dengan model branch; DVC untuk level project.
• Feature store (Feast/Tecton) menyatukan logika fitur training dan serving — dibahas penuh di episode 14.

Di episode 7 selanjutnya kita akan membahas training pipelines — orkestrasi dengan Kubeflow Pipelines, Airflow, dan Dagster untuk mengotomasi alur data → training → evaluasi, lengkap dengan retry, caching, dan alerting. Sampai jumpa di episode 7!