Cube Lab — semantic layer

Satu definisi metrik, dipakai semua dashboard & aplikasi. Data demo: 9.000 order e-commerce.

menghubungkan…

Pendapatan

—

order selesai

Order

—

baris item terjual

AOV

—

revenue ÷ order

Pelanggan unik

—

count distinct

Pendapatan harian

30 hari terakhir · query lewat REST API Cube

memuat…

join otomatis ke cube products

memuat…

measure + dimension dari dua cube berbeda (orders × customers)

memuat…

pangsa pendapatan per channel

memuat…

Pilih metrik → lihat query JSON yang dikirim dan SQL yang dihasilkan Cube. Tidak ada rumus yang ditulis ulang di dashboard.

Query (JSON) yang dikirim

—

SQL yang dihasilkan Cube

—

Model, bukan query. Kamu tulis sekali di model/cubes/orders.yml: measure revenue = qty × unit_price × (1 − discount), dimensi city, join ke customers/products. Semua konsumen memakai itu.
Query API, bukan SQL. Dashboard minta {"measures":["orders.revenue"]}; Cube yang menyusun SQL, join, filter, dan cache-nya.
Konsumen banyak. Dashboard (halaman ini), Metabase lewat SQL API, aplikasi lain lewat REST/GraphQL, dan AI agent lewat MCP — semuanya membaca definisi yang sama.

Layak kalau ada >1 konsumen metrik yang sama (BI + app + laporan klien) dan angka sering beda-beda antar dashboard.
Belum perlu kalau cuma satu Metabase untuk satu tim — Metabase sudah cukup, Cube jadi lapisan tambahan yang harus dirawat.
Untung teknis: pre-aggregation (rollup harian) bikin query berat jadi cepat tanpa ubah dashboard.
Ongkos: satu container + Postgres (di lab ini ±1,2 GB RAM), model YAML harus disiplin, dan konsep baru buat tim non-teknis.

Semantic layer jadi kontrak metrik per klien: satu repo model YAML, versi di git, review sebelum berubah.
Metabase tetap dipakai untuk eksplorasi tim; Cube dipakai kalau ada aplikasi/embed atau AI yang butuh angka yang sama.
Karena definisi terpusat, pertanyaan “kenapa angka di deck beda dengan dashboard?” selesai di satu file, bukan di lima query.