Data mesh pada chapter sebelumnya memecah kepemilikan data ke banyak domain, dan pecahan tersebut menambah jumlah tempat data bersemayam. Kenyataannya, bahkan organisasi yang tidak menerapkan mesh pun sudah lama hidup dengan silo: data warehouse untuk analitik, data lake untuk data mentah, database aplikasi untuk transaksi, dan puluhan SaaS yang masing-masing menyimpan datanya sendiri. Data fabric menawarkan pendekatan yang tidak menuntut pemindahan data: biarkan data tetap di tempatnya, lalu satukan akses dan pemahamannya lewat satu lapisan metadata aktif. Bab ini membedah cara kerja fabric, komponen pembangunnya, dan posisinya terhadap mesh.
Masalah: Data Tersebar di Banyak Silo #
Silo tidak lahir karena tim suka membangun gudang terpisah; silo lahir karena setiap sistem tumbuh demi kebutuhannya sendiri. Database transaksional dioptimalkan untuk konsistensi, lake untuk biaya per terabyte, dan SaaS untuk kecepatan adopti — tidak ada yang salah dengan masing-masing. Masalah muncul ketika konsumen data harus bekerja lintas silo setiap hari:
- Mencari satu dataset berarti bertanya ke orang yang tepat — tidak ada katalog yang bisa diandalkan.
- Menelusuri asal sebuah angka melintasi tiga sistem harus dilakukan manual karena lineage tidak tersambung.
- Kebijakan akses berbeda di tiap sistem, sehingga permintaan akses menjadi pekerjaan administratif yang lambat.
- Integrasi baru selalu berarti memindahkan data lagi — proyek ETL yang tidak pernah selesai.
Fabric menjawab masalah tersebut dengan satu tesis: yang perlu bergerak adalah metadata, bukan datanya. Bila katalog, lineage, dan kebijakan dari semua sistem terhimpun dalam satu tempat, konsumen cukup memakai satu pintu.
Active Metadata sebagai Perekat #
Kata kunci fabric adalah aktif. Katalog metadata pasif — sekadar buku alamat dataset yang diisi manual — cepat tidak terawat dan kehilangan kepercayaan pemakainya. Active metadata bekerja sebaliknya: hub metadata menyerap informasi secara otomatis dari pipeline, query log, dan kebijakan akses, membangun semacam knowledge graph tentang data perusahaan, lalu memakai pengetahuan tersebut untuk mengotomatiskan pekerjaan.
Perhatikan arah panah pada diagram: yang mengalir dari sumber ke hub adalah metadata (schema, statistik, kebijakan), bukan baris data. Sebaliknya, tiga layanan keluaran — pipeline terpadu, federated query, dan katalog — memakai hub sebagai otak bersama. Semakin kaya metadata yang terserap, semakin tepat rekomendasi dan otomasi yang bisa diberikan.
Komponen Utama Data Fabric #
Sebuah fabric yang berfungsi biasanya tersusun dari lima komponen yang saling terhubung. Tabel berikut memetakan peran masing-masing komponen sekaligus materi pendukung di course ini yang membahasnya secara mendalam:
| Komponen | Peran dalam fabric | Materi pendukung |
|---|---|---|
| Katalog dan pencarian | menemukan dataset tanpa bertanya ke orang | Data Catalog |
| Lineage | menelusuri asal angka lintas sistem | Data Lineage dan Provenance |
| Federated query | menggabungkan sumber tanpa memindahkan data | Federated Query |
| Otomasi pipeline | usulan integrasi dari pola metadata | Data Pipeline Engineering |
| Kebijakan akses terpadu | satu kebijakan untuk semua sistem | Role-Based Access Control |
Tidak ada satu standar terbuka tunggal yang mendefinisikan fabric; istilah ini dipopulerkan vendor analitik untuk menyebut kumpulan kapabilitas di atas. Contoh komponen nyata di ekosistem open source adalah schema registry yang menyimpan dan menegakkan metadata schema antar sistem — seperti Confluent Schema Registry yang sudah kita pakai pada section Streaming Data.
Otomasi yang Ditumbuhkan Metadata #
Pembeda fabric dari sekadar “katalog plus federated query” adalah otomasi yang lahir dari metadata itu sendiri. Ketika knowledge graph tahu bahwa tabel A di lakehouse memiliki kolom yang sama dengan tabel B di warehouse, fabric dapat mengusulkan penggabungan. Ketika fabric mendeteksi sebuah pipeline berubah schema, konsumen downstream bisa diberi tahu sebelum query mereka rusak.
Dua contoh otomasi yang paling sering dipakai: deteksi perubahan schema yang menyiagakan konsumen sebelum pipeline rusak, dan usulan pemberian akses ketika peran pengguna dan klasifikasi kolom sudah cocok dengan kebijakan.
Kualitas otomasi mengikuti kualitas metadata. Knowledge graph yang tidak lengkap menghasilkan usulan yang keliru, sehingga fabric selalu dimulai dari kerapian metadata dasar — bukan dari membeli mesin rekomendasi.
Satu Pintu bagi Konsumen #
Pengalaman konsumen adalah ujian sesungguhnya sebuah fabric. Analis mencari “pesanan”, katalog menampilkan data product pesanan_harian beserta pemilik, freshness, dan kolomnya. Lineage memperlihatkan bahwa angka tersebut bersumber dari bronze_checkout di lakehouse. Permintaan akses diteruskan ke policy engine yang menyetujui otomatis karena klasifikasi kolom mengizinkan peran analis — semuanya tanpa memindahkan satu byte data antar sistem.
Pengalaman semacam itu tidak menuntut satu pun proses ETL baru. Yang dibutuhkan adalah metadata yang lengkap dan kebijakan yang terhubung — persis pekerjaan yang dikerjakan fabric di belakang layar.
Kapan Fabric Layak Dipertimbangkan #
Fabric paling terasa manfaatnya ketika sebagian besar kondisi berikut terpenuhi:
- Jumlah sistem sumber sudah banyak — warehouse, lake, database aplikasi, SaaS — dan setiap integrasi baru menjadi proyek tersendiri.
- Konsumen data menghabiskan waktu lebih banyak untuk mencari dan memahami data daripada mengolahnya.
- Kebijakan akses harus konsisten lintas sistem karena tuntutan regulasi atau klasifikasi data.
- Tim data terlalu kecil untuk memindahkan seluruh data ke satu tempat, sehingga integrasi metadata jadi satu-satunya jalan realistis.
Sebaliknya, organisasi dengan satu warehouse dan sedikit sumber belum membutuhkan fabric; katalog sederhana dan disiplin dokumentasi sudah cukup untuk skala tersebut.
Fabric versus Mesh #
| Aspek | Data Mesh | Data Fabric |
|---|---|---|
| Arah | desentralisasi ke domain | integrasi dari pusat metadata |
| Fokus utama | kepemilikan dan kontrak | konektivitas dan otomasi |
| Perubahan organisasi | besar | relatif kecil |
| Ketergantungan kunci | disiplin tim domain | kematangan metadata |
Jalur Adopsi Bertahap #
Fabric tidak dibangun sekaligus. Jalur yang paling sering berhasil menempatkan komponen termurah lebih dulu:
- Katalog — daftarkan sistem sumber dan pemiliknya; nilai langsung terasa saat orang berhenti bertanya satu sama lain.
- Lineage — sambungkan hubungan antar tabel dari tool orchestration yang sudah dipakai.
- Federated query — hidupkan satu mesin query lintas sumber untuk kasus integrasi yang paling sering diminta.
- Otomasi — baru setelah tiga komponen stabil, tambahkan deteksi perubahan dan usulan akses otomatis.
Setiap tahap menghasilkan nilai yang bisa dipakai sendiri, sehingga proyek tidak menanggung risiko big bang yang harus berhasil semuanya sekaligus.
Ukuran keberhasilannya pun sederhana: berapa orang yang kembali memakai katalog dan federated query pada bulan berikutnya — bukan berapa fitur fabric yang menyala.
Mesh maupun fabric sama-sama menuntut jawaban atas satu pertanyaan mendasar: bagaimana menentukan batas domain yang tepat? Kosakata dan metode untuk menjawabnya sudah lama tersedia di dunia rekayasa perangkat lunak. Chapter Domain-Driven Data Architecture membawanya ke arsitektur data.