Data Mart Adalah: Beda dengan Data Warehouse dan Kapan Dipakai

Data mart adalah potongan dari data warehouse yang disiapkan khusus buat satu tim atau satu topik analisis. Isinya lebih sedikit tabel, udah diringkas, dan strukturnya dirancang biar query harian tim itu jalan cepat.

Data warehouse nampung data seluruh perusahaan. Data mart nampung irisan yang beneran dipakai tiap hari.

Di dataset ngulikdata, satu query dashboard marketing yang tadinya 38 detik turun jadi 1,7 detik setelah pindah ke data mart. Isinya query yang sama persis, cuma tabelnya beda.

Apa itu data mart?

Data mart adalah kumpulan tabel yang berisi data siap analisis buat satu fungsi bisnis, misalnya marketing, keuangan, atau operasional. Data mart biasanya diambil dari data warehouse, lalu difilter, diagregasi, dan disusun ulang supaya pertanyaan rutin tim itu bisa dijawab tanpa gabung banyak tabel besar.

Bentuk fisiknya bisa tabel biasa, materialized view, atau skema terpisah di database yang sama.

Yang bikin dia disebut mart bukan teknologinya, tapi cakupannya. Satu tim, satu topik, satu set pertanyaan yang berulang.

Isi tabelnya biasanya udah diringkas ke level yang dipakai. Tim marketing jarang butuh data per transaksi. Mereka butuh angka per hari, per kanal, per kategori.

Apa bedanya data mart dan data warehouse?

Data warehouse nyimpen data terintegrasi dari seluruh sistem perusahaan dengan cakupan luas dan riwayat panjang. Data mart cuma nyimpen irisan yang relevan buat satu tim, dengan data yang udah diringkas dan periode yang lebih pendek. Warehouse dibangun sekali buat semua, mart dibangun berkali-kali sesuai kebutuhan tiap tim.

Aspek	Data warehouse	Data mart
Pengguna	Seluruh perusahaan	Satu tim atau satu fungsi
Cakupan data	Semua domain bisnis	Satu domain
Tingkat detail	Detail per transaksi	Sering udah diringkas
Riwayat	Bertahun-tahun	Umumnya 12-24 bulan
Waktu bangun	Bulanan sampai tahunan	Hari sampai minggu
Jumlah tabel	Puluhan sampai ratusan	Beberapa saja
Tujuan utama	Satu sumber kebenaran	Kecepatan query harian

Dua-duanya diisi lewat proses ETL yang sama. Bedanya cuma di titik akhir dan seberapa jauh datanya diolah.

Apa jenis-jenis data mart?

Ada tiga jenis berdasarkan dari mana datanya datang.

1. Dependent data mart. Datanya ditarik dari data warehouse yang udah ada. Ini pilihan paling rapi karena definisi angkanya otomatis konsisten sama tim lain.
2. Independent data mart. Datanya ditarik langsung dari sistem sumber tanpa lewat warehouse. Cepat dibangun, tapi rawan bikin tiap tim punya versi angka sendiri.
3. Hybrid data mart. Gabungan keduanya. Sebagian dari warehouse, sebagian dari sumber lain yang belum masuk warehouse.

Kalau perusahaanmu belum punya warehouse dan tim marketing butuh angka minggu depan, independent mart masuk akal sebagai langkah sementara. Catat aja utangnya, karena rekonsiliasi angka antar tim bakal jadi kerjaan tambahan nanti.

Kapan sebaiknya bikin data mart?

Bikin data mart waktu muncul dua gejala sekaligus: query dashboard makin lambat sampai ngeganggu kerja, dan beberapa tim nulis ulang logika perhitungan yang sama dengan hasil yang beda tipis. Sebelum dua gejala itu muncul, view biasa dan index yang benar biasanya udah cukup.

Tanda lain yang cukup jelas.

• Satu query dashboard nge-join lebih dari lima tabel besar tiap kali dibuka.
• Tim non teknis minta akses ke tabel mentah dan bingung kolom mana yang bener.
• Ada tiga versi angka pelanggan aktif di tiga laporan berbeda.
• Beban database naik tiap pagi karena semua orang buka dashboard barengan.

Kalau masalahnya cuma satu query lambat, coba dulu composite index atau partisi tabel. Mart itu solusi struktural, bukan tambal cepat.

Gimana cara bikin data mart di SQL?

Cara paling ringkas pakai materialized view. Kamu tulis satu query agregasi dari tabel fakta dan dimensi, simpan hasilnya sebagai objek fisik, lalu jadwalkan refresh harian. Dashboard tinggal baca objek itu tanpa perlu ngitung ulang tiap kali dibuka.

CREATE MATERIALIZED VIEW mart_penjualan_harian AS
SELECT
    DATE(t.waktu_pesan)           AS tanggal,
    k.nama_kanal                  AS kanal,
    p.kategori                    AS kategori,
    COUNT(DISTINCT t.order_id)    AS jumlah_pesanan,
    COUNT(DISTINCT t.customer_id) AS jumlah_pembeli,
    SUM(t.nilai_bersih)           AS pendapatan
FROM fakta_transaksi t
JOIN dim_kanal  k ON k.kanal_id  = t.kanal_id
JOIN dim_produk p ON p.produk_id = t.produk_id
WHERE t.status_pesanan = 'selesai'
  AND t.waktu_pesan >= CURRENT_DATE - INTERVAL '24 months'
GROUP BY 1, 2, 3;

Tambahkan index unik supaya refresh bisa jalan tanpa ngunci tabel buat pembaca.

CREATE UNIQUE INDEX idx_mart_penjualan_harian
    ON mart_penjualan_harian (tanggal, kanal, kategori);

REFRESH MATERIALIZED VIEW CONCURRENTLY mart_penjualan_harian;

Klausa CONCURRENTLY cuma bisa jalan kalau index uniknya ada. Syarat lengkapnya ada di dokumentasi PostgreSQL.

Setelah mart jadi, query dashboard yang tadinya panjang jadi sependek ini.

SELECT
    tanggal,
    SUM(pendapatan)     AS pendapatan,
    SUM(jumlah_pesanan) AS pesanan
FROM mart_penjualan_harian
WHERE kanal = 'marketplace'
  AND tanggal >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY tanggal
ORDER BY tanggal;

Kalau kamu butuh beberapa index tambahan atau mau kontrol penuh atas struktur tabelnya, pakai tabel fisik biasa dan isi ulang lewat penjadwal ETL.

Contoh kasus: data mart marketing toko_berkah

Data warehouse toko_berkah di dataset latihan ngulikdata punya tabel fakta transaksi berisi 41 juta baris, ditambah 8 tabel dimensi.

Dashboard marketing di sana nampilin enam grafik. Tiap grafik manggil query yang nge-join tabel fakta sama tiga tabel dimensi, lalu ngagregasi 24 bulan data.

Waktu buka dashboard rata-rata 38 detik. Tim marketing akhirnya berhenti pakai dan balik minta ekspor manual ke tim data tiap Senin pagi.

Solusinya satu materialized view berisi agregasi harian per kanal per kategori. Hasilnya 2,3 juta baris, alias 5,6 persen dari ukuran tabel fakta.

Ukuran	Sebelum mart	Sesudah mart
Waktu buka dashboard	38 detik	1,7 detik
Baris yang dipindai per query	41 juta	2,3 juta
Tabel yang di-join	4	1
Permintaan ekspor manual per minggu	3	0

Yang menarik bukan angka 1,7 detik. Yang menarik kolom terakhir.

Tiga permintaan ekspor manual per minggu itu setara sekitar dua jam kerja analis. Setahun berarti sekitar 100 jam yang balik lagi ke pekerjaan analisis.

Struktur tabel fakta dan dimensi yang dipakai di sini ngikutin pola bintang. Aku bahas bentuknya di artikel star schema.

Kesalahan umum waktu bikin data mart

1. Nyalin seluruh isi warehouse ke mart. Kalau nggak ada yang dipotong, kamu cuma dapat salinan yang bikin biaya penyimpanan naik dua kali.
2. Bikin mart tanpa tanya pertanyaannya dulu. Kumpulin dulu 10 pertanyaan rutin timnya, baru rancang kolomnya.
3. Refresh kelewat sering. Refresh tiap 5 menit buat dashboard yang dibuka sekali sehari itu pemborosan.
4. Lupa index unik di materialized view. Tanpa itu, refresh ngunci tabel dan dashboard mati beberapa menit.
5. Tiap tim bikin definisi sendiri. Ini yang bikin rapat manajemen berisi tiga angka pendapatan yang beda.
6. Nggak ada dokumentasi kolom. Kolom nilai_bersih itu udah dipotong diskon atau belum? Tulis di deskripsi tabelnya.

Ringkasan dan langkah berikutnya

Data mart itu potongan warehouse yang dibentuk sesuai pertanyaan rutin satu tim. Manfaat utamanya dua: query yang jauh lebih cepat dan definisi angka yang seragam.

Bikinnya nggak harus rumit. Satu materialized view yang benar sering udah nyelesaiin keluhan paling berisik dari tim bisnis.

Kalau martmu udah jadi, lanjut rapikan tampilannya lewat dashboard yang fokus ke sedikit angka penting. Dan kalau query-mu masih lambat walau udah pakai mart, cek dulu antipattern SQL yang sering nyelinap di query agregasi.