TL;DR
Data mesh adalah pendekatan pengelolaan data yang memindahkan kepemilikan data dari satu tim pusat ke tiap divisi yang paling paham datanya. Empat prinsipnya: kepemilikan per domain, data diperlakukan sebagai produk, platform layan-mandiri, dan tata kelola federasi. Pendekatan ini cocok buat organisasi dengan banyak tim data dan ratusan sumber. Buat perusahaan dengan satu tim data di bawah 10 orang, gudang data terpusat masih lebih murah dan lebih cepat.
Data mesh adalah pendekatan mengelola data yang memindahkan kepemilikan dari satu tim pusat ke tiap divisi yang paling paham datanya. Tim data pusat berubah jadi penyedia platform, bukan lagi tukang jahit semua permintaan.
Istilah ini muncul dari tulisan Zhamak Dehghani tahun 2019, dan sejak itu kepakai di banyak konferensi.
Pertanyaan yang lebih penting buat kamu: perusahaan tempat kamu kerja beneran butuh atau enggak?
Data mesh adalah cara mengatur organisasi data yang membagi tanggung jawab per domain bisnis, bukan per tahapan teknis. Tiap divisi yang menghasilkan data juga bertanggung jawab menyajikannya dalam bentuk yang siap dipakai divisi lain. Tim pusat menyediakan alat dan aturan main, lalu memastikan definisi bersama tetap konsisten.
Bandingin sama pola lama. Di pola terpusat, tim data yang isinya 6 orang harus paham data penjualan, keuangan, gudang, dan pemasaran sekaligus.
Mereka nggak akan pernah sepaham orang gudang soal kenapa ada kolom "status_retur" yang isinya lima kode aneh. Jadi antrean permintaan numpuk dan kualitas datanya tetap goyah.
Tulisan asli data mesh principles di situs Martin Fowler menyebut empat prinsip. Ini versi bahasa manusianya.
1. Kepemilikan data per domain. Divisi penjualan yang punya data penjualan, termasuk tanggung jawab atas kualitasnya. Bukan tim data pusat.
2. Data sebagai produk. Data yang kamu terbitkan punya nama, pemilik, dokumentasi, jaminan kesegaran, dan kontak kalau rusak. Sama kayak produk software.
3. Platform layan-mandiri. Tim domain nggak boleh dipaksa bikin pipeline dari nol. Tim platform nyediain perkakas standar biar orang finance bisa nerbitin data tanpa jadi data engineer.
4. Tata kelola federasi. Definisi bersama kayak "pelanggan aktif" disepakati wakil dari tiap domain, lalu ditegakkan otomatis lewat pengujian. Bukan lewat rapat bulanan.
Prinsip keempat ini yang paling sering dilewatin, dan itu yang paling mahal akibatnya.
| Aspek | Terpusat | Data mesh |
|---|---|---|
| Pemilik data | Tim data pusat | Tiap domain bisnis |
| Kecepatan awal | Cepat | Lambat, butuh koordinasi |
| Skala ke 20 tim | Antrean menumpuk | Lebih tahan |
| Biaya orang | Rendah | Tinggi, tiap domain butuh orang data |
| Risiko definisi bercabang | Rendah | Tinggi kalau tata kelolanya lemah |
| Cocok untuk | Di bawah 3 tim penghasil data | Di atas 5 tim dengan produk berbeda |
Perhatiin baris biaya orang. Data mesh butuh minimal satu orang yang ngerti data di tiap domain.
Kalau perusahaan kamu susah cari satu data analyst aja, prinsip pertama udah nggak bisa jalan sejak hari pertama.
Aku pakai daftar cek ini waktu ditanya klien. Kalau jawabannya "ya" untuk 4 dari 6 poin, baru layak dibahas serius.
Dari pengalaman aku ngobrol sama tim data di beberapa perusahaan Jakarta dan Surabaya, poin 4 dan 6 yang paling sering gagal.
Banyak yang pengin data mesh karena kepengin arsitekturnya kelihatan modern. Padahal masalah aslinya cuma satu: nggak ada yang bertanggung jawab kalau angka salah.
Dan masalah itu bisa dipecahkan tanpa merombak arsitektur.
Aku pernah bantu jaringan minimarket dengan 34 cabang di Jawa Tengah. Tim datanya 3 orang, sumber datanya 7 sistem.
Keluhan awalnya klasik: laporan omzet mingguan selalu telat 2 hari, dan angka dari tim keuangan sering beda sama angka dari tim operasional.
Waktu aku telusuri, selisihnya rata-rata 4,7 persen. Penyebabnya bukan arsitektur. Tim keuangan ngitung omzet setelah retur, tim operasional ngitung sebelum retur.
Perbaikannya nggak butuh data mesh. Cuma butuh tiga hal:
Query pengujiannya sesederhana ini.
SELECT order_id, COUNT(*) AS jumlah
FROM dp_penjualan_harian
GROUP BY order_id
HAVING COUNT(*) > 1;Kalau ada baris yang keluar, berarti ada transaksi kegandaan dan laporan pagi itu ditahan.
Selisih 4,7 persen tadi turun jadi di bawah 0,3 persen dalam 6 minggu. Tanpa mengubah satu pun komponen infrastruktur.
Itu yang aku maksud waktu bilang kebanyakan perusahaan Indonesia belum butuh data mesh. Yang mereka butuh adalah kontrak data dan pemilik yang jelas.
Empat prinsip tadi bisa dipinjam sebagian. Ini yang paling murah dan paling cepat kerasa.
Tempelkan nama pemilik di tiap tabel penting. Satu kolom di katalog, isinya nama orang. Bukan nama tim.
Bikin kontrak data sederhana. Tiga janji aja cukup: kunci unik, kolom wajib nggak boleh kosong, dan batas keterlambatan muat data.
SELECT MAX(tanggal_muat) AS terakhir_dimuat
FROM dp_penjualan_harian;Kalau umurnya lebih dari 24 jam, kirim peringatan.
Sepakati definisi metrik secara tertulis. Simpan di satu tempat yang bisa dilihat semua orang, dan catat tanggal perubahannya.
Otomatiskan pengujian. Data quality yang dicek manual bakal berhenti dicek dalam 3 minggu.
Empat langkah itu ngambil sekitar 80 persen manfaat data mesh dengan sekitar 10 persen biayanya.
Nganggap data mesh itu produk yang bisa dibeli. Nggak ada vendor yang bisa jual data mesh, karena isinya pembagian tanggung jawab.
Ngedesentralisasi tanpa tata kelola. Tiap domain bikin definisi metric sendiri, lalu angka di rapat direksi nggak pernah cocok.
Mindahin beban ke domain tanpa mindahin orangnya. Tim marketing disuruh punya data product tapi nggak dikasih tambahan orang. Hasilnya data product yang nggak pernah diperbarui.
Lupa ETL tetap harus jalan. Data mesh nggak menghapus pekerjaan pemindahan dan pembersihan data. Cuma memindahkan siapa yang ngerjain.
Ngukur sukses dari jumlah data product. Yang layak diukur itu berapa lama waktu tunggu permintaan data dan berapa sering angkanya salah.
Data mesh adalah cara mengelola data dengan memberi tiap divisi tanggung jawab penuh atas data yang mereka hasilkan, lalu mewajibkan mereka menyajikannya sebagai produk yang bisa dipakai divisi lain. Tim pusat berubah peran jadi penyedia platform dan penjaga aturan bersama, bukan lagi pihak yang ngerjain semua permintaan data.
Data warehouse itu soal teknologi penyimpanan terpusat. Data mesh itu soal siapa yang bertanggung jawab atas datanya. Kamu tetap bisa pakai warehouse di dalam data mesh, bedanya tiap domain punya wilayahnya sendiri dan bertanggung jawab atas kualitas isinya. Jadi dua istilah ini bukan pilihan yang saling meniadakan.
Patokan kasarnya, kalau kamu punya lebih dari 3 tim yang bikin data sendiri dan tim data pusat udah jadi antrean panjang, baru masuk akal. Di bawah itu, koordinasinya lebih mahal daripada masalah yang dipecahkan. Perusahaan dengan satu tim data di bawah 10 orang hampir selalu lebih untung pakai warehouse terpusat.
Nggak ada tool yang bikin kamu otomatis punya data mesh, karena ini soal pembagian tanggung jawab, bukan produk. Yang biasanya dibutuhkan adalah katalog data, sistem kontrol versi buat definisi metrik, dan pengujian otomatis. Semua itu bisa dibangun pakai perkakas yang mungkin udah kamu punya sekarang.
Definisi metrik jadi bercabang. Tiap divisi bikin versi omzet dan pelanggan aktifnya sendiri, lalu angka di rapat direksi nggak pernah cocok. Ini kebalikan dari tujuan awalnya. Pencegahannya ada di prinsip keempat, tata kelola federasi, yang mewajibkan definisi bersama disepakati dan diuji otomatis.
Data mesh menjawab masalah organisasi besar: tim data pusat jadi leher botol waktu jumlah domain tumbuh.
Kalau perusahaan kamu punya 3 tim dan 7 sumber data, masalahmu kemungkinan besar bukan itu. Di kasus minimarket 34 cabang tadi, selisih 4,7 persen hilang cuma dengan satu dokumen definisi dan lima query pengujian.
Pinjam prinsipnya, tunda arsitekturnya. Pemilik yang jelas, kontrak data, dan pengujian otomatis udah nutup sebagian besar rasa sakitnya.
Mau mulai dari query pengujian pertama? Latihan nulisnya ada di NgulikSQL. Lanjut baca juga cara nyusun ringkasan eksekutif satu halaman biar temuanmu kepakai di rapat.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.