TL;DR
ETL (Extract, Transform, Load) mengubah bentuk data di server terpisah sebelum dimasukkan ke data warehouse. ELT (Extract, Load, Transform) memasukkan data mentah dulu ke warehouse, lalu transform-nya dijalankan pakai SQL di dalam warehouse itu sendiri. ELT makin populer karena warehouse cloud kayak BigQuery dan Snowflake sekarang cukup cepat dan murah buat ngolah data mentah langsung di tempat.
ETL dan ELT beda di satu hal: kapan data-nya dibentuk ulang. ETL bentuk dulu di luar, baru masukin ke data warehouse. ELT masukin data mentah dulu, bentuknya nyusul di dalam warehouse pakai SQL.
Kedengerannya sepele. Tapi urutan ini nentuin berapa server yang kamu bayar, seberapa cepat data sampai ke dashboard, dan seberapa gampang kamu benerin logika yang salah.
Aku bakal jelasin dua-duanya pakai contoh toko_berkah (dataset penjualan UMKM yang biasa dipakai buat latihan di ngulikdata) plus kapan sebaiknya kamu pilih yang mana.
ETL adalah pola pemindahan data dengan tiga langkah: Extract (tarik data dari sumber), Transform (bersihin dan ubah bentuknya di server terpisah), lalu Load (masukin hasil bersihnya ke data warehouse). Warehouse cuma nerima data yang udah rapi dan siap dipakai.
Pola ini lahir waktu penyimpanan mahal dan warehouse lemot. Ngolah data mentah di dalam warehouse dulu itu boros banget, jadi orang ngolahnya di luar.
Alurnya kayak gini di toko_berkah:
total_harga.Yang masuk warehouse cuma hasil akhirnya. Data mentah? Nggak ikut.
ELT adalah pola yang sama tapi urutannya ditukar: Extract, Load, lalu Transform. Data mentah dimasukkan apa adanya ke warehouse, dan semua pembersihan dijalankan di dalam warehouse pakai query SQL.
Jadi warehouse-nya nyimpen dua lapis. Lapis mentah (raw), dan lapis hasil transform yang dipakai dashboard.
Contoh transform-nya di ELT ditulis sebagai SQL biasa:
-- Lapis mentah: raw.penjualan (apa adanya dari kasir)
-- Lapis siap pakai: mart.penjualan_bersih
CREATE OR REPLACE TABLE mart.penjualan_bersih AS
SELECT
p.id_transaksi,
CAST(p.tanggal AS DATE) AS tanggal,
p.id_produk,
k.nama_produk,
k.kategori,
p.jumlah,
p.harga_satuan,
p.jumlah * p.harga_satuan AS total_harga
FROM raw.penjualan AS p
JOIN raw.produk AS k
ON p.id_produk = k.id_produk
WHERE p.status <> 'batal'
AND p.jumlah > 0;Nggak ada tool khusus. Cuma SQL yang jalan di dalam warehouse. Kalau kamu belum kuat di JOIN dan CAST, dua fungsi itu yang paling sering muncul di query transform.
Alasan utamanya: warehouse cloud sekarang jauh lebih cepat dan lebih murah dari 10 tahun lalu.
BigQuery bisa nge-scan puluhan giga dalam hitungan detik, dan kamu cuma bayar sesuai data yang diproses. Ngolah data mentah di dalam warehouse udah gak nyeremin lagi.
Tiga hal yang bikin ELT menang di praktik:
1. Data mentah kesimpen. Salah nulis logika transform? Tinggal perbaiki query, jalanin ulang. Nggak perlu narik ulang data dari sumber. Di ETL, kalau data mentahnya udah kebuang, kamu harus extract lagi dari awal.
2. Satu bahasa buat semua orang. Transform di ELT ditulis pakai SQL. Analis yang udah bisa SQL langsung bisa baca dan benerin logikanya sendiri, gak perlu nunggu data engineer.
3. Satu server lebih sedikit. Server transform di ETL itu mesin yang harus kamu urus, patch, dan bayar terus, walaupun cuma jalan 20 menit sehari.
Tapi ELT bukan jawaban buat semua kasus. Aku bahas batasnya di bawah.
| Aspek | ETL | ELT |
|---|---|---|
| Tempat transform | Server terpisah | Di dalam warehouse |
| Bahasa transform | Python, Java, tool ETL | SQL |
| Data mentah disimpan? | Nggak (biasanya) | Iya |
| Biaya penyimpanan | Lebih rendah | Lebih tinggi (nyimpen mentah + hasil) |
| Biaya compute | Server transform tetap nyala | Bayar per query warehouse |
| Benerin logika salah | Extract ulang dari sumber | Jalanin ulang query |
| Data sensitif | Bisa disaring sebelum masuk | Masuk dulu, harus di-mask duluan |
| Cocok buat | Aturan privasi ketat, sumber on-premise | Warehouse cloud, tim yang kuat SQL |
toko_berkah punya 3 cabang, 84.000 baris transaksi setahun. Datanya nyebar di tiga tempat: aplikasi kasir, Google Sheets buat stok, dan file CSV ekspor dari marketplace.
Versi ETL-nya: satu script Python jalan tiap malam jam 23.00 di server kecil. Script itu narik ketiga sumber, gabungin, bersihin, terus masukin satu tabel final ke warehouse.
Masalahnya muncul pas ada permintaan baru dari owner: "Bisa lihat penjualan per jam gak?"
Ternyata kolom jam udah kebuang di tahap transform. Data yang tersimpan cuma agregat harian. Buat jawab pertanyaan itu, tim harus narik ulang 12 bulan data dari kasir, dan API kasirnya cuma nyimpen 90 hari terakhir. Data 9 bulan sebelumnya hilang.
Setelah pindah ke ELT, semua kolom mentah masuk ke raw.penjualan, termasuk timestamp lengkapnya. Pertanyaan baru dari owner tinggal dijawab pakai query, bukan pakai proyek migrasi.
-- Pertanyaan owner: jam berapa paling ramai?
SELECT
EXTRACT(HOUR FROM waktu_transaksi) AS jam,
COUNT(*) AS jumlah_transaksi,
SUM(total_harga) AS omzet
FROM mart.penjualan_bersih
WHERE tanggal >= DATE '2026-01-01'
GROUP BY jam
ORDER BY omzet DESC;Hasilnya bikin owner kaget. Jam 19.00-21.00 nyumbang 34 persen omzet harian, padahal jadwal shift karyawan penuh justru ditaruh di jam 10.00-14.00. Jadwal shift-nya digeser bulan berikutnya.
Angka lain dari migrasi ini: biaya bulanan turun dari Rp 1.250.000 (server transform + warehouse) jadi Rp 740.000 (warehouse doang). Waktu pipeline dari 41 menit jadi 12 menit, karena warehouse ngolah paralel sementara script Python-nya jalan satu-satu.
Tiga situasi ini bikin ETL tetap pilihan yang benar:
Data sensitif yang gak boleh nyentuh warehouse. Kalau aturan internal atau regulasi ngelarang NIK atau data kesehatan disimpan mentah di cloud, transform (termasuk masking) harus jalan sebelum load.
Sumber datanya raksasa tapi yang dipakai dikit. Log server 500 GB per hari, tapi kamu cuma butuh ringkasan 200 MB? Ngolah di luar lebih hemat daripada nyimpen 500 GB mentah tiap hari.
Warehouse-nya on-premise dan lemot. Kalau database kamu server fisik di kantor yang udah ngos-ngosan, jangan tambahin beban transform ke situ.
Numpuk semua data mentah tanpa dokumentasi. Setahun kemudian gak ada yang tau tabel raw_v2_final_fix itu apa. Kasih nama yang jelas dan tulis satu paragraf keterangan per tabel.
Jalanin transform tiap 15 menit padahal data sumber update harian. Ini penyebab nomor satu tagihan warehouse membengkak. Samain jadwal transform sama jadwal update sumbernya.
Nulis satu query transform sepanjang 400 baris. Pecah jadi beberapa tabel bertahap: raw, staging, mart. Tiap tahap gampang dicek sendiri kalau ada angka yang aneh.
Lupa mask data sensitif. Kalau data pelanggan ikut masuk mentah, hash nomor HP-nya di tahap load. Ini satu baris kerjaan yang bisa nyelametin kamu dari masalah besar.
Anggap ELT bikin data otomatis bersih. Nggak. ELT cuma mindahin tempat bersih-bersihnya. Kalau kolom tanggal di sumber isinya campur "12/06/2026" sama "2026-06-12", kamu tetep harus benerin.
Nggak perlu langsung beli Fivetran atau Snowflake. Setup paling murah yang udah bener-bener ELT:
Postgres gratis. Cron gratis. Yang kamu butuhin cuma SQL yang cukup buat nulis GROUP BY dan JOIN dengan pede.
Urutan hurufnya beda karena urutan kerjanya beda. Di ETL, data dibersihin dulu di server perantara, baru dimasukkan ke warehouse. Di ELT, data mentah masuk warehouse duluan, transform-nya nyusul pakai SQL di dalam warehouse. Konsekuensinya beda: ETL cuma nyimpen data yang udah rapi, ELT nyimpen versi mentahnya juga jadi kamu bisa ngulang transform kapan aja.
Tergantung. ELT hemat karena kamu gak perlu bayar server transform terpisah. Tapi biaya compute warehouse bisa naik kalau query transform-nya boros. Di toko_berkah, pindah ke ELT nurunin total biaya sekitar 40 persen, sebagian besar dari server transform yang dimatiin. Yang bikin balik mahal biasanya query yang jalan tiap jam padahal datanya cuma update harian.
Data mentah masuk warehouse dulu, jadi data sensitif kayak NIK atau nomor HP ikut kesimpan. Kalau aturan internal kamu ngelarang itu, mask atau hash dulu sebelum load. Pola yang umum: masking di tahap extract, sisanya transform di warehouse. Jadi masih ELT, cuma ada satu langkah pengaman di depan.
Perlu tau konsepnya, gak perlu pakai tool-nya sekarang. Pas kamu copy data dari beberapa file, bersihin, terus tempel ke satu sheet gabungan, itu ETL manual. Ngerti polanya bikin kamu lebih gampang paham pas nanti tim data ngomongin pipeline. Dan kalau data kamu udah lewat 1 juta baris, ini sinyal buat mulai pindah ke database.
Buat extract dan load biasanya pakai Fivetran, Airbyte, atau script Python sendiri. Buat transform-nya, dbt paling sering dipakai karena semua logikanya ditulis pakai SQL biasa dan bisa di-version control pakai Git. Warehouse-nya BigQuery, Snowflake, atau Redshift. Kalau data kamu masih di bawah 50 GB, Postgres biasa pun udah cukup.
Ringkasannya:
Yang bikin kamu berguna di dua-duanya sama: SQL. Semua logika transform di ELT itu SELECT, JOIN, dan GROUP BY. Kalau mau latihan sampai lancar, coba NgulikSQL, bisa langsung praktek di browser tanpa install apa-apa.
Lanjut baca: Data Warehouse vs Data Lake buat tau di mana data mentah kamu sebaiknya diparkir.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Cara pakai pandas rolling buat hitung moving average dan haluskan data time series yang naik-turun. Lengkap dengan contoh penjualan harian UMKM.
Data transaksi harian sering terlalu ramai buat dilihat. Pandas resample ngeringkasnya jadi total per minggu atau per bulan cuma dengan satu baris, asal indeksnya tanggal.
Kolom tanggal yang kebaca sebagai teks bikin sortir dan hitung selisih hari jadi kacau. Ini cara pd.to_datetime ubah teks jadi tanggal asli, plus tangani format berantakan.