Version Control untuk Data

Pada chapter sebelumnya kita membekukan data sebagai salinan potret dan mencatat seed — tetapi pembekuan hanya berguna bila kita bisa membuktikan bahwa berkas hari ini memang berkas yang sama dengan yang kemarin. Kebutuhan itu mempertemukan kita dengan version control, praktik melacak perubahan dari waktu ke waktu. Kode kita seharusnya sudah biasa dilacak dengan Git; bab ini menambahkan dua hal yang sering ditinggalkan: data juga perlu terlacak versinya, dan identitas sebuah berkas bisa dibuktikan dengan checksum. Tanpa keduanya, pertanyaan sederhana “analisis Januari itu memakai data yang mana?” hanya bisa dijawab dengan menebak.

Git untuk Kode, dan Kenapa Data Berbeda #

Git dirancang untuk berkas teks: setiap perubahan disimpan sebagai beda antarbaris, sehingga riwayat analisis.py bisa dibaca siapa pun — kapan baris itu ditambah, kapan diubah, dan siapa yang mengubahnya. Kebiasaan ini wajib berlaku untuk seluruh kode proyek data science: pipeline, skrip analisis, dan berkas konfigurasi. Komit yang rutin dengan pesan yang jujur (“ganti imputasi median jadi modus pada kolom menu”) adalah bentuk paling murah dari dokumentasi teknis.

Data menuntut perlakuan berbeda. Berkas data berukuran besar, sering berbentuk biner (parquet, Excel), dan berubah total setiap pembaruan — beda antarbaris tidak lagi informatif. Memasukkan data mentah ratusan megabita ke repositori Git membuat riwayat membengkak berkali lipat setiap pembaruan, dan banyak layanan hosting menolak berkas di atas batas ukuran tertentu. Prinsipnya satu kalimat: kode di Git, data di tempat lain — beserta catatan identitasnya di Git.

DVC: Version Control untuk Berkas Data #

Kebutuhan melacak data tanpa menimbun Git dijawab alat khusus, dan yang paling dikenal adalah DVC (Data Version Control). Idé utamanya sederhana dan layak dipahami sebagai konsep meski kita belum memasangnya:

1. Saat berkas data ditambahkan, DVC menghitung checksum isinya, menyalin berkas ke penyimpanan data (folder khusus di proyek atau penyimpanan awan), lalu membuat satu berkas kecil berekstensi .dvc yang memuat checksum dan informasi penunjuk.
2. Berkas .dvc yang kecil itulah yang masuk ke Git. Riwayat Git kini mencatat “pada komit ini, analisis memakai data dengan checksum sekian” — tanpa menyimpan datanya sendiri.
3. Saat kita kembali ke komit lama, DVC membaca penunjuknya dan mengunduh versi data yang persis cocok dari penyimpanan.

Dengan begitu, git checkout pada komit bulan lalu bersama dvc checkout memulihkan pasangan kode-plus-data yang tepat — analisis lama bisa dijalankan ulang dengan data yang sama beserta kode yang sama. Penyimpanan data itu sendiri bisa berupa folder bersama di jaringan kantor atau layanan awan, terpisah dari repositori Git.

# Kode: lacak di Git sejak awal proyek
git init
git add pipeline.py analisis.py
git commit -m "Pipeline pembersihan transaksi tahap 1"

# Data: kunci versinya lewat DVC (konsep - berkas .dvc masuk Git)
dvc add data/transaksi_2026.csv
git add data/transaksi_2026.csv.dvc
git commit -m "Kunci data transaksi Januari 2026"

Blok perintah di atas tidak kita jalankan di bab ini — cukup dipahami sebagai pola: git add untuk kode dan berkas .dvc, dvc add untuk berkas data.

Checksum: Sidik Jari Berkas Data #

Di balik seluruh alat version control data berdiri satu mekanisme sederhana yang bisa kita pakai langsung: checksum. Fungsi hash seperti SHA-256 membaca seluruh isi berkas dan menghasilkan sidik jari sepanjang 64 karakter; isi berkas yang sama selalu menghasilkan sidik jari sama, dan perubahan satu angka saja menghasilkan sidik jari yang sama sekali berbeda. Kita praktikkan menjaga integritas salinan data beku kita:

import hashlib

def checksum(isi: str) -> str:
    "Sidik jari SHA-256 (16 karakter pertama) dari isi berkas."
    return hashlib.sha256(isi.encode("utf-8")).hexdigest()[:16]

awal = ("tanggal,pelanggan,total\n"
        "2026-01-05,Budi,24000\n"
        "2026-01-05,Siti,18000\n"
        "2026-01-06,Dewi,28000\n")

# saat analisis dimulai, salinan beku dicatat sidik jarinya
manifest = {"transaksi_beku.csv": checksum(awal)}
print("manifest tersimpan  :", manifest)

# pekan berikutnya, berkas kerja ternyata berubah satu angka
berubah = awal.replace("24000", "29000")
print("berkas sekarang     :", checksum(berubah))
print("cocok dengan catatan:", checksum(berubah) == manifest["transaksi_beku.csv"])

# salinan beku yang asli tidak tersentuh perubahan itu
print("salinan beku        :", checksum(awal))
print("salinan masih utuh  :", checksum(awal) == manifest["transaksi_beku.csv"])

Output yang Dihasilkan:

manifest tersimpan  : {'transaksi_beku.csv': 'c231aee709d147e6'}
berkas sekarang     : 79060bc495e77fbf
cocok dengan catatan: False
salinan beku        : c231aee709d147e6
salinan masih utuh  : True

Mari kita bedah mekanismenya:

1. hashlib.sha256(...).hexdigest() membaca isi berkas sebagai aliran byte dan menghasilkan sidik jari heksadesimal; kita cuplik 16 karakter pertama agar laporan mudah dibaca — dalam praktik, 64 karakter penuh yang dicatat.
2. Satu angka berubah — 24000 menjadi 29000 — dan sidik jari berubah total: c231... menjadi 7906.... Hash tidak menunjukkan apa yang berubah, tetapi pasti memberi tahu bahwa sesuatu berubah. Bandingkan mencocokkan dua berkas dengan membukanya satu per satu.
3. manifest adalah bentuk paling sederhana dari apa yang dilakukan DVC: kamus nama-berkas → sidik jari, disimpan sebagai teks di repositori Git. Pemeriksaan identitas cukup membandingkan sidik jari berkas hari ini dengan catatan itu — baris False adalah alarm bahwa berkas kerja sudah menyimpang dari salinan beku, dan baris True meyakinkan bahwa salinan beku tidak tersentuh.

Apa Dilacak di Mana #

Dengan Git, DVC, dan checksum di tangan, kita bisa membagi aset proyek sesuai tempat pelacakannya:

Baris “data antara” sering mengejutkan pemula: hasil pembersihan tidak perlu dilacak karena pipeline dapat membangkitkannya ulang dari data mentah kapan pun. Menyimpan data antara justru membuka risiko dua salinan yang tidak sinkron; melacaknya lewat kode yang membangkitkannya lebih murah dan lebih jujur.

Rangkuman #

• Git untuk kode, data di penyimpanan terpisah dengan catatan identitasnya di Git — menimbun data besar di repositori Git adalah kekeliruan struktural.
• DVC memisahkan penyimpanan data dari riwayat Git: berkas kecil berisi checksum dan penunjuk yang dilacak Git, sementara berkas datanya tinggal di penyimpanan data.
• Checksum SHA-256 adalah mekanisme dasarnya: sidik jari isi berkas yang berubah total oleh perubahan sekecil apa pun, cukup untuk membuktikan identitas berkas.
• Data antara tidak perlu dilacak — pipeline membangkitkannya ulang dari data mentah; melacak kode pembangkitnya lebih murah daripada menyimpan salinannya.

Identitas data kini bisa dibuktikan dan riwayatnya bisa dipulihkan. Satu jenis artefak proyek masih berjalan tanpa jejak: eksperimen — puluhan kombinasi model dan parameter yang kita coba demi satu angka terbaik. Cara mencatatnya agar tidak menjadi kabut adalah pembahasan chapter berikutnya: Eksperimen dan Pencatatan .