Belajar BI Analyst - Arsitektur BI & Ekosistem Data

#Pendahuluan

Setelah di episode 1 kita memahami posisi BI Analyst sebagai jembatan antara data dan keputusan, pada episode ini kita turun ke lapisan teknis: di mana data berada, bagaimana ia mengalir, dan di titik mana kalian bekerja. Memahami arsitektur ini penting karena setiap dashboard yang kalian bangun bergantung pada rantai yang panjang — kalau salah satu lapisan bermasalah, angka di dashboard ikut bermasalah.

Banyak BI Analyst pemula hanya fokus pada "layar dashboard" dan lupa bahwa di baliknya ada ekosistem data yang utuh. Saat stakeholder bertanya "kenapa angka ini beda?", kemampuan kalian menelusuri arsitektur inilah yang akan menyelamatkan kalian.

#Alur Data di Ekosistem BI

Arsitektur BI modern mengikuti alur berlapis:

Empat lapisan utama yang wajib kalian pahami:

#1. Source Data (Sumber Data)

Semua data bermula dari sini: database operasional (PostgreSQL, MySQL), CRM seperti Salesforce, ERP seperti SAP/Odoo, file CSV/Excel, API pihak ketiga, hingga log aplikasi. Setiap source punya karakteristik sendiri — ada yang real-time, ada yang hanya sinkron tiap malam.

#2. Data Warehouse / Lake (Tempat Penyimpanan)

Data dari berbagai source digabung, dibersihkan, dan disimpan di satu tempat terpusat. Warehouse menyimpan data terstruktur yang siap di-query (Snowflake, BigQuery, Redshift, PostgreSQL); lake menyimpan data mentah dalam format apa pun (S3, GCS) untuk fleksibilitas lebih besar. Istilah lakehouse menggabungkan keduanya: penyimpanan murah seperti lake, tetapi dengan kemampuan query seperti warehouse.

#3. Semantic Layer (Lapisan Semantik)

Lapisan ini menerjemahkan tabel teknis menjadi konsep bisnis: definisi "revenue", "active user", dan "churn" ditetapkan sekali dan dipakai semua dashboard. Ini menjamin metrik konsisten — topik yang akan kita bedah di episode 12.

#4. BI Tools (Alat Visualisasi)

Lapisan teratas yang menghadap pengguna: Power BI, Tableau, Looker, atau tool open-source seperti Metabase/Superset. Di sinilah kalian membangun dashboard, report, dan eksplorasi visual.

#Siapa Bertanggung Jawab atas Tiap Lapisan?

Pembagian kerja yang umum di perusahaan data:

Perhatikan: domain utama kalian adalah semantic layer sampai dashboard. Namun tanpa memahami lapisan di bawahnya, kalian tidak akan bisa mendiagnosis kenapa angka di dashboard salah.

#Batch vs Streaming

Sumber data masuk ke warehouse dengan dua mode utama:

• Batch processing: data dipindahkan secara berkala — harian, per jam — misalnya sinkronisasi transaksi kemarin sore setiap pukul 02.00. Mayoritas BI berjalan dalam mode ini.
• Streaming processing: data diproses hampir seketika saat terjadi — misalnya pembayaran kartu kredit atau event mobile. Dipakai untuk dashboard real-time yang akan kita bahas di episode 16.

Jangan berpikir streaming selalu lebih baik: batch lebih murah, lebih mudah divalidasi, dan cukup untuk 90% kasus BI. Streaming hanya layak ketika latensi beberapa menit sudah tidak bisa ditoleransi.

#Warehouse: OLTP vs OLAP

Database operasional dan warehouse dirancang untuk tujuan berbeda:

Kalau kalian menjalankan query BI langsung ke database operasional, bisa terjadi "tabrakan": query besar kalian memperlambat aplikasi produksi. Karena itulah arsitektur memisahkan keduanya — data disalin ke warehouse sebelum di-query untuk analisis.

#Praktik: Memetakan Arsitektur BI

Sekarang saatnya mempraktikkan konsep. Ambil kertas (atau file kosong) dan petakan arsitektur BI di organisasi kalian — atau buat peta untuk contoh fiktif:

1. Identifikasi source data: tulis semua sistem yang menghasilkan data (CRM, POS, aplikasi internal, spreadsheet).
2. Identifikasi warehouse/lake: di mana data tersebut disimpan dan siapa yang mengelolanya.
3. Identifikasi semantic layer: apakah ada definisi metrik terpusat, atau setiap tim membuat definisinya sendiri?
4. Identifikasi BI tools: tool apa saja yang dipakai, siapa penggunanya, dan untuk keputusan apa.
5. Tandai titik lemah: di lapisan mana metrik paling sering tidak konsisten?

Untuk latihan mandiri, buat peta sederhana dengan tiga lapisan di atas dan isi setiap lapisan dengan entitas nyata dari Superstore: source = CSV/PostgreSQL, warehouse = PostgreSQL bi_lab, semantic layer = definisi metrik sales/profit (akan kita bangun di episode 3), BI tool = pilihan kalian di episode 0.

Source: orders.csv, products.csv, customers.csv
  └── warehouse: PostgreSQL bi_lab (schema staging + marts)
        └── semantic layer: dim_customer, dim_product, fact_orders
              └── BI tools: Power BI / Tableau / Looker
                    └── dashboard: Sales Performance

#Kesalahan Umum dalam Arsitektur BI

• Query langsung ke OLTP: memperlambat aplikasi produksi dan membuat angka tidak konsisten dengan warehouse.
• Tanpa semantic layer: setiap tim menghitung "revenue" dengan definisi berbeda — resep konflik antar departemen.
• Data kotor masuk tanpa validasi: garbage in, garbage out; kalian akan menanggung akibatnya di episode dashboard.
• Menambahkan tool tanpa alasan: terlalu banyak BI tool justru menambah fragmentasi metrik, bukan mengurangi.

#Penutup

Inti yang harus dibawa pulang:

• Arsitektur BI mengalir: source → warehouse/lake → semantic layer → BI tools → keputusan.
• Domain utama BI Analyst: semantic layer dan dashboard; lapisan lain dipahami sebagai konteks.
• Pahami perbedaan batch vs streaming dan OLTP vs OLAP agar tahu kapan memakai mode apa.
• Dashboard produksi membaca dari warehouse, bukan langsung dari database operasional.
• Praktik: petakan arsitektur BI di organisasi kalian dan tandai titik lemahnya.

Di episode 3 selanjutnya kita akan membahas metrik & KPI bisnis — bagaimana memilih KPI yang tepat, membedakan leading vs lagging indicator, dan menyelaraskan metrik dengan tujuan bisnis. Ini adalah fondasi konseptual terpenting sebelum kalian menulis SQL atau membuat dashboard. Pastikan tetap semangat!