Belajar Data Engineer - ETL vs ELT & Tools

#Pendahuluan

Di episode 5 kalian telah menulis script ekstraksi API dengan Python. Pertanyaan berikutnya yang pasti muncul: di mana transformasi dilakukan? Jawabannya menentukan seluruh arsitektur pipeline kalian — dan jawaban industri telah bergeser secara fundamental dalam satu dekade terakhir.

Episode ini membedah ETL vs ELT: mengapa urutan huruf itu bukan sekadar kosmetik, tool mana yang menangani bagian mana, dan bagaimana kalian menggabungkannya menjadi pipeline yang praktis. Ini adalah fondasi konseptual sebelum kita menyentuh tool spesifik di episode 7 (dbt) dan 8 (Airflow).

#ETL: Transformasi Sebelum Masuk Warehouse

ETL (Extract, Transform, Load) adalah pola klasik: data diekstrak dari sumber, ditransformasi dulu (dibersihkan, diagregasi, diubah format) di mesin terpisah, baru dimuat ke target.

Keunggulannya di era lama: warehouse mahal dan terbatas, jadi hanya data yang sudah "bersih" yang boleh masuk. Masalahnya: transformasi di mesin terpisah butuh kapasitas komputasi ekstra, dan jika data mentah dibutuhkan lagi, kalian harus kembali ke sumber.

#ELT: Load Dulu, Transformasi di Warehouse

ELT (Extract, Load, Transform) membalik urutan: data mentah dimuat apa adanya ke warehouse, lalu transformasi dilakukan di dalam warehouse dengan SQL (atau engine di atasnya seperti dbt).

Mengapa pola ini menang di era modern? Tiga alasan utama:

1. Warehouse cloud murah dan elastis (Snowflake/BigQuery memisahkan storage dari compute) — menyimpan dan memproses data mentah menjadi terjangkau.
2. Transformasi memakai SQL — bahasa yang sama untuk semua, mudah diuji dan di-versioning.
3. Data mentah tersimpan selamanya — kalian bisa re-transform kapan pun logika berubah, tanpa kembali ke sumber.

#Tool Modern di Ekosistem ELT

Pasar tool data 2026 terbagi rapi menjadi dua lapisan: ingestion (memindahkan data) dan transformation (mengubah data).

#Layer Ingestion

Ketiganya melakukan hal yang sama secara konseptual: menghubungkan sumber (database, SaaS seperti Stripe/Shopify, API) dan menyalin datanya ke warehouse secara terjadwal — dengan incremental sync dan penanganan schema drift otomatis.

#Layer Transformation

Untuk transformasi, dbt (data build tool) telah menjadi standar de facto. Ia memindahkan transformasi ke dalam warehouse dengan model SQL yang bisa di-versioning, di-test, dan di-dokumentasikan. Detail lengkapnya kita bedah di episode 7.

#Trade-off: Build vs Buy

Pertanyaan klasik setiap data engineer: membangun sendiri atau membeli? Tidak ada jawaban tunggal, tapi ada kerangka berpikirnya:

• Bangun sendiri (script Python + API) jika sumbernya sedikit dan sederhana, atau sangat khusus. Kontrol penuh, tapi maintenance di tangan kalian.
• Beli (Fivetran/Stitch) jika sumbernya banyak (dozens SaaS) dan tim kecil. Hemat waktu, tapi biaya bulanan dan fleksibilitas terbatas.
• Open-source (Airbyte) jika butuh kendali dan banyak connector, tapi punya kapasitas operasional.

#Praktik: Pipeline ELT Sederhana

Mari bangun pipeline ELT mini end-to-end dengan PostgreSQL sebagai warehouse. Konsepnya: ekstrak dari API, load mentah ke tabel raw_orders, transform dengan SQL.

Langkah 1 — Simpan data mentah apa adanya (extract + load):

import requests
import psycopg2
import json
 
RAW_API = "https://api.example.com/orders"
CONN = psycopg2.connect(
    host="localhost", port=5432, user="de",
    password="secret", dbname="de_lab",
)
 
def main() -> None:
    resp = requests.get(RAW_API, timeout=30)
    resp.raise_for_status()
    rows = resp.json()["data"]
 
    with CONN.cursor() as cur:
        cur.execute("CREATE TABLE IF NOT EXISTS raw_orders (payload JSONB, ingested_at TIMESTAMP DEFAULT now())")
        for row in rows:
            cur.execute("INSERT INTO raw_orders (payload) VALUES (%s)", (json.dumps(row),))
    CONN.commit()
    print(f"OK: {len(rows)} baris mentah masuk raw_orders")
 
if __name__ == "__main__":
    main()

Perhatikan: kita tidak membersihkan apa pun di tahap ini — data mentah masuk ke JSONB. Itulah esensi ELT.

Langkah 2 — Transformasi di warehouse dengan SQL:

CREATE TABLE IF NOT EXISTS orders_clean AS
SELECT
    (payload->>'order_id')::INT AS order_id,
    payload->>'customer_name' AS customer_name,
    (payload->>'amount')::NUMERIC AS amount,
    (payload->>'created_at')::TIMESTAMP AS created_at
FROM raw_orders
WHERE payload->>'amount' IS NOT NULL;
 
SELECT COUNT(*) AS total_orders, SUM(amount) AS total_revenue
FROM orders_clean;

Dua langkah ini sudah membentuk pipeline ELT lengkap. Di episode 8, Airflow akan menjadwalkan keduanya; di episode 7, dbt akan menggantikan SQL mentah di atas dengan model yang terstruktur.

#Kesalahan Umum (Common Pitfalls)

1. Melakukan transformasi berat di script Python padahal bisa di SQL. Transformasi di Python sulit di-audit dan di-versioning. Pindahkan ke SQL/dbt jika bisa.

2. Load hanya data yang sudah bersih. Kalian kehilangan data mentah — dan kemampuan re-transform. Simpan raw terlebih dahulu.

3. Terlalu cepat membeli tool. Satu sumber data dengan 10 baris tidak perlu Fivetran. Skala dulu, baru beli.

4. Mencampur lapisan. Kalian tidak perlu memindahkan logika transformasi ke connector ingestion — biarkan ingestion mengurus pemindahan, dbt/SQL mengurus transformasi.

#Penutup

Di episode 6 ini kalian telah memahami jantung arsitektur pipeline:

• ETL mentransformasi sebelum masuk warehouse — relevan untuk kebutuhan khusus & regulasi.
• ELT memuat mentah lalu transformasi di warehouse — pola dominan modern berkat SQL, elastisitas, dan re-transformability.
• Tool: Airbyte/Fivetran/Stitch untuk ingestion, dbt untuk transformation; build vs buy tergantung skala dan kapasitas.
• Praktik: pipeline ELT sederhana dari API → raw_orders → orders_clean sudah berdiri.

Di episode 7 selanjutnya kita mendalami salah satu tool paling berpengaruh di ekosistem data: dbt untuk transformasi — model SQL, test, source freshness, macros, dan version control, plus praktik membangun data mart. Sampai jumpa di episode 7!