Belajar BI Analyst - ETL/ELT Dasar

#Pendahuluan

Setelah di episode 5 kalian merancang model star schema, muncul pertanyaan besar: siapa yang membangun tabel-tabel itu setiap hari? Data baru masuk terus-menerus — kalau kalian membangun fact_orders secara manual, pekerjaan itu tidak akan pernah selesai. Jawabannya adalah pipeline data, dan episode ini akan membekali kalian pemahaman dasar ETL/ELT serta praktiknya dengan dbt.

Mengapa BI Analyst perlu memahami pipeline? Karena dashboard kalian hanya sebagus pipeline yang mengisinya. Kalau pipeline berhenti tengah malam atau menyalin data kotor, dashboard pagi hari akan menyesatkan. Kalian tidak perlu jadi Data Engineer, tetapi wajib bisa membaca, memvalidasi, dan berkomunikasi dengan pipeline — itu bagian dari menjaga keandalan report.

#ETL vs ELT

Dua arsitektur pipeline yang wajib kalian bedakan:

• ETL (Extract → Transform → Load): data diekstrak dari source, diubah di server terpisah, baru dimuat ke target. Populer di era sebelum warehouse cloud; transformasi butuh server sendiri.
• ELT (Extract → Load → Transform): data mentah dimuat dulu ke warehouse, lalu diubah di dalam warehouse. Karena warehouse cloud modern (Snowflake, BigQuery) sangat cepat dan murah, transformasi justru paling efisien dilakukan di sini.

ELT adalah standar modern. Di sini pipeline biasanya dibagi dua peran:

1. Extract + Load: tool seperti Fivetran/Airbyte menyalin data mentah dari source ke warehouse (atau database staging).
2. Transform: dbt mengubah data mentah menjadi model (star schema) yang rapi dan teruji.

#Struktur Pipeline: Staging → Intermediate → Marts

Pipeline dbt yang baik mengikuti alur bertahap:

raw data (dari connector)
  → staging_orders   (bersihkan tipe data, rename kolom)
  → dim_customer, dim_product, fact_orders   (model inti)
  → marts: revenue_report, region_performance  (siap dipakai dashboard)

Tiga lapisan yang umum:

Lapisan ini menjawab pertanyaan klasik: "model ini dipakai dashboard atau masih bahan olahan?" — kalian selalu tahu kapan harus berhati-hati mengubah sebuah tabel.

#Praktik: Pipeline Sederhana dengan dbt

Sekarang bangun pipeline ELT sederhana dengan dbt (data build tool) — standar modern untuk transformasi data. Install dbt dan inisialisasi project:

pip install dbt-postgres
dbt init bi_pipeline
cd bi_pipeline
dbt debug

Buat file sumber data pertama — beri tahu dbt di mana orders mentah berada:

sources:
  - name: bi_lab
    tables:
      - name: orders
        columns:
          - name: order_id
            tests: [not_null]
          - name: sales
            tests: [not_null]

Lalu bangun model staging yang membersihkan data mentah:

SELECT
    order_id::text            AS order_id,
    order_date::date          AS order_date,
    customer_id::text         AS customer_id,
    product_id::text          AS product_id,
    sales::numeric            AS sales,
    quantity::int             AS quantity,
    profit::numeric           AS profit
FROM {{ source('bi_lab', 'orders') }}
WHERE order_id IS NOT NULL
  AND sales IS NOT NULL

{{ source(...) }} adalah Jinja template dbt yang otomatis merujuk ke sumber yang dideklarasikan di sources.yml. Perhatikan pembersihan di sini: cast tipe data eksplisit dan filter baris yang tidak valid — inilah data quality yang dimulai sejak hulu.

Terakhir, bangun model fact_orders bersih yang siap dipakai dashboard:

WITH orders AS (
    SELECT *
    FROM {{ ref('stg_orders') }}
)
SELECT
    order_id,
    order_date,
    customer_id,
    product_id,
    sales,
    quantity,
    profit
FROM orders

Jalankan pipeline dan verifikasi:

dbt run
dbt test
dbt build

dbt build menjalankan semua model plus tes — satu perintah untuk seluruh pipeline. Output akhirnya: tabel stg_orders dan fact_orders siap dipakai BI.

#Data Quality dalam Pipeline

Data quality tidak hanya urusan Data Engineer. Sebagai BI Analyst, kalian wajib:

• Memvalidasi volume: bandingkan jumlah baris hari ini vs kemarin — lonjakan/drop tiba-tiba = sinyal pipeline rusak.
• Memeriksa anomali nilai: misal profit yang anehnya nol di satu region, atau sales negatif.
• Menjaga definisi tetap konsisten: ketika pipeline berubah, pastikan metrik lama dan baru tetap bisa dibandingkan.
• Memakai tes otomatis: not_null, unique, accepted_values, hingga tes kustom di dbt.

#Kesalahan Umum Pipeline BI

• Dashboard membaca data mentah langsung: semua pembersihan diulang di dashboard, lambat dan rawan inkonsistensi.
• Tanpa tes data: pipeline diam-diam menghasilkan duplikat atau null, dan baru ketahuan saat stakeholder mengeluh.
• Tanpa lapisan staging: koreksi tipe data di sana-sini bikin model kacau dan tidak bisa dilacak.
• Satu pipeline untuk semua kebutuhan: kebutuhan report harian dan real-time berbeda — jangan dipaksakan dalam satu alur.

#Penutup

Inti yang harus dibawa pulang:

• ELT adalah standar modern: data mentah dimuat dulu, transformasi terjadi di warehouse (dbt).
• Pipeline terbagi: staging → intermediate → marts — makin ke kanan, makin siap dipakai dashboard.
• dbt mengubah transformasi menjadi kode yang bisa di-review, di-test, dan di-versioning.
• Data quality dimulai dari hulu: tes not_null/unique di dbt test jauh lebih murah daripada dashboard yang salah.
• Praktik: pipeline dbt sederhana (stg_orders → fact_orders) berhasil dijalankan dengan dbt build.

Di episode 7 selanjutnya kita akan masuk ke dunia visual: data visualization principles — memilih chart yang tepat, prinsip encoding visual, dan bagaimana menghindari visualisasi yang menyesatkan. Pipeline kalian sudah bersih, sekarang saatnya membuat angkanya berbicara!