Kecepatan perkembangan AI dan banjirnya data di era AI, bisa membuat ETL tidak relevan untuk sebagian industri, apa alasannya, simak artikel berikut:

Definisi dan perbedaan secara singkat

Berdasarkan definisi IBM [1], Extract Transform Load (ETL) adalah, sebuah proses  transformasi (penggabungan, pembersihan data, dsb) dari berbagai sumber menjadi sekumpulan data untuk disimpan di sebuah sistem penyimpanan (gudang data, data lake, dll).

Berbeda urutan dengan ETL, ELT (Extract Load Transform) adalah sebuah integrasi data terkini yang banyak dipraktekan di industri, menekankan penyimpanan dari berbagai sumber menjadi sebuah kumpulan data. Hanya jika ada keperluan, transformasi dilakukan, selebihnya data mentah akan tetap tersimpan dalam gudang data, data lake, dsb. Transformasi sesuai kebutuhan ini (dalam ELT) merampingkan alur kerja pemrosesan data [2].

Load First, Transform Later

ELT menggunakan konsep “Load First, Transform Later”, salah satu argument utamanya adalah data bisa diakses secara cepat, ketika sebuah departemen memerlukan sebuah insight secepat mungkin, menggunakan dashboard Ad Hoc, dashboard tanpa pengembangan formal, bisa menjadi sebuah solusi. Contohnya pada data keuangan, saham, e-commerce, dsb. Inilah titik pergeseran paradigma dalam dunia data warehouse modern, sebagian praktisi merasa ETL menjadi bottleneck, karena proses transformasi tidaklah singkat, dan perlunya sebuah gebrakan: “ETL konvensional perlu berevolusi menjadi lebih agile.”

Contoh Kasus ETL vs ELT

Studi Kasus ETL

Aspek Keterangan
Skenario Bank yang membuat laporan keuangan setiap periode. Data yang disimpan harus akurat dan memenuhi regulasi oleh regulator keuangan.
Proses ETL
Extract Dalam industry perbankan, data seringkali terisolasi dan terpencar dari berbagai sumber. Sehingga perlu untuk mengekstrak dari berbagai database, dan system CRM.
Transform Melakukan standarisasi dan validasi, memastikan data valid saat diberikan kepada regulator.
Load Data yang sudah melalui proses transformasi di-load untuk tim analitik membuat laporan kepada regulator keuangan.
Analisis Harus menggunakan ETL karena perlu melakukan transformasi, menghapus data sensitive, validasi data.

 

Misalkan kesalahan pada kolom Riwayat tunggakan, bahkan hanya 0 menjadi 1 maka bank secara salah mengkategorikan orang tersebut pernah menunggak.

Missing value pada kolom Data Demografi (Usia/Pekerjaan) di database CRM, akan menyebabkan segmentasi gagal, dampaknya akan memuncak menjadi gagalnya strategi pemasaran, penawaran kredit yang tidak sesuai.

https://medium.com/@venimeka1906/before-elt-and-reverse-etl-my-journey-using-etl-in-a-banking-project-ceaaead8f9ec

Studi Kasus ELT

Aspek Keterangan
Skenario Bank mencatat log dari pengguna melalui aplikasi mobile dan website. Data hanya ditransformasi ketika ada kebutuhan untuk menganalisis Fraud Detection.
Proses ELT
Extract Ekstraksi dari berbagai sumber data yang besar dan beragam, termasuk logs dan data interaksi pelanggan melalui aplikasi mobile dan website.
Load Data mentah (raw data) dimuat langsung ke dalam data warehouse berbasis cloud (BigQuery/Snowflake).
Transform Transformasi dilakukan sesuai permintaan (on-demand) di dalam data warehouse menggunakan kekuatan pemrosesan cloud.
Analisis ELT tanpa enkripsi sama sekali data storage yang ditargetkan

 

Data log dan aktivitas tidaklah terlalu sensitif,

https://medium.com/@venimeka1906/before-elt-and-reverse-etl-my-journey-using-etl-in-a-banking-project-ceaaead8f9ec

 

ETL Bottleneck

Menurut Website Airbyte, transformasi yang tidak efisien: memerlukan banyak data cleansing, agregasi dalam jumlah besar menjadi hambatan. Kewajiban transformasi menghalangi kecepatan gerak perusahaan (agility) [4]. Extract dan Load bisa mengalami perubahan yang minor, perubahan Extract E adalah teknis (berhubungan perubahan versi API), dan Load L akan berubah jika mengubah seluruh sistem penyimanan, jangka waktunya tahunan. Lain hal dengan proses bisnis, yang dapat berubah kapanpun, begitu juga dengan transformasi dapat mengalami perubahan yang signifikan, karena eratnya kaitannya transformasi dengan proses bisnis.

Ilustrasinya seperti ini, pipeline ETL sudah diotomatisasi, ketika ada perubahan skema (pada tahap transformasi) hal ini membuat data yang baru menjadi tidak bisa masuk karena skemanya berubah, sehingga membuat tahap load pun tidak berjalan karena tidak ada data yang masuk. Pada pipeline ELT yang sudah diotomatisasi, skema dari database diubah. Hal ini tidak begitu merusak dari pipeline ELT, karena transformasi/ perubahan skema ini terjadi menjadi tahapan terakhir daripada ELT. Yang terganggu hanya lah End-user nya seperti Data scientist, Data Analys, BI. Tapi data tetap masuk ke data lake atau penyimpanan sejenisnya.

Keunggulan ELT

ELT memiliki keunggulan diantaranya adalah: skalabilitas, fleksibilitas, kelincahan performa [5]. Skalabilitas ini banyak didukung oleh platform cloud. Platform cloud memungkinkan kita meningkatkan kemampuan sistem tanpa menghambat performa ELT pipeline. Hal ini juga berlaku untuk ETL, tetapi karena kecepatan data yang masuk lebih lama (skalabilitas tertahan oleh proses transformasi), manfaatnya tidak terlalu terasa bagi mengimplementasikan ETL.

Integritas data yang longgar memungkinkan data yang kotor, kolom yang kurang sesuai tetap disimpan dalam sistem. Integritas data yang longgar ini memungkinkan ETL lebih fleksible. Walaupun akan meningkatkan risiko data swamp, pipeline ELT tetap berevolusi, para praktisi memitigasi risiko ini dengan menerapkan data lakehouse. Data lakehouse mengakomodasi integritas data (data warehouse) di sisi lain juga memungkinkan menyimpan data secara mentah, dengan data government yang baik (menerapkan Medalion Architecture) [6].

Seperti ilustrasi yang sudah dijelaskan sebelumnya, tidak terdampaknya tahap E dan L memungkinkan alur pemrosesan data menjadi lincah (agile). Data engineer dapat menguji otomatisasi transformasi T dengan konsekuensi terhentinya data pipeline yang minim. Selain itu berkurangnya ketergantungan terhadap data engineer, end user (DS,DA,BI) dapat secara mandiri mengakses data yang mentah setelah diberi akses melalui User Access Control oleh data engineer atau database admin. User Access Control ini memungkingkan pertanggung jawaban/ akuntabilitas dari  pihak yang mengaksesnya.

Kegagalan implementasi ELT: Bencana Data Lake menjadi Data Swamp

Saat data dimasukan tanpa kontrol, ini menjadi masalah. Data menjadi sangat besar dan sulit bernavigasi dalam data lake. Diiringi dengan tidak adanya kepemilikan yang jelas, kurangnya kepatuhan terhadap aturan dan dokumentasi, menjadikan permasalahan ini sebagai kegagalan implementasi ELT berakar dari tata kelola yang buruk (bad data governance). [7]

Data swamp membuat banyak waktu yang terbuang hanya untuk mencari data: dalam mencari data terbaru, atau data dengan transformasi khusus (data ad hoc) yang dibutuhkan dikemudian hari, dan kesulitan kesulitan lain untuk bernavigasi dalam data swamp.

Pendapat Praktisi Data Engineer: ETL vs ELT

Seorang praktisi Data Engineer, Wael Dagash, berpendapat bahwa bidang finansial dan kesehatan masih memerlukan alur kerja yang konvensional, ETL. Alasannya yaitu data yang mentah masih bersifat tidak terstandar dan tidak akurat. Akurasi data dan data terstandar dapat dicapai setelah data mentahnya telah melalui proses transformasi terlebih dahulu (data cleaning, data validation). [8]

Kesimpulan

ELT merupakan evolusi dari pipeline ETL, penyempurnaan ELT terus dilakukan oleh para praktisi. Mengingat prinsip agility yang dianut oleh perusahaan semakin banyak, seleksi industri penerapan pipeline ELT masih tetap diperlukan. Seperti yang sudah kita bahas sebelumnya, hal yang menjadi hambatan adalah data swamp. Jika data governance tidak diterapkan dengan baik, potensi ELT untuk mengefisiensikan sebuah alur pemrosesan data akan sia-sia. Pemilihan ETL ataupun ELT harus didasarkan atas risiko bisnis yang dapat ditoleransi oleh perusahaan tersebut.

Penulis:

Tsui Tin Lun (mahasiswa CS-Math)

References:

[1] https://www.ibm.com/think/topics/etl

[2] https://www.snowflake.com/en/fundamentals/understanding-extract-load-transform-elt/

[3] https://medium.com/@venimeka1906/before-elt-and-reverse-etl-my-journey-using-etl-in-a-banking-project-ceaaead8f9ec

[4] https://airbyte.com/data-engineering-resources/etl-pipeline-bottlenecks-causes-fixes

[5] https://www.tencentcloud.com/techpedia/101317

[6] https://www.dataforgelabs.com/data-transformation-tools/medallion-architecture

[7] https://www.linkedin.com/posts/kayyasit-sookma-96b893141_datagovernance-datalake-architecture-activity-7386046048525479936-t-xL/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAB0cZO0BdAfYB30W82UIADe0s2oU76oYjeI

[8] https://www.linkedin.com/posts/wael-dagash-48692b120_waeldagash-activity-7303430872563683328-15pT/