Pengungkapan penuh:Karena artikel ini ditulis oleh perusahaan yang berpusat pada ETL dengan setelan kuatnya dalam memanipulasi data besar di luar basis data, apa yang berikut ini tampaknya tidak objektif bagi banyak orang. Namun demikian, ini tetap dimaksudkan untuk menyajikan bahan pemikiran, dan membuka ruang untuk diskusi.
Sejak awal, arsitek gudang data (DWA) telah ditugaskan untuk membuat dan mengisi gudang data dengan sumber dan format data yang berbeda. Karena pertumbuhan dramatis dalam volume data, DWA yang sama ini ditantang untuk mengimplementasikan integrasi data dan operasi staging secara lebih efisien. Pertanyaan apakah transformasi data akan terjadi di dalam atau di luar database target telah menjadi pertanyaan penting karena kinerja, kenyamanan, dan konsekuensi finansial yang terlibat.
Dalam operasi ETL (extract, transform, load), data diekstraksi dari sumber yang berbeda, ditransformasikan secara terpisah, dan dimuat ke database DW dan kemungkinan target lainnya. Di ELT, ekstrak dimasukkan ke dalam database staging tunggal yang juga menangani transformasi.
ETL tetap lazim karena pasar berkembang dengan pemain yang sudah terbukti seperti Informatica, IBM, Oracle — dan IRI dengan Voracity, yang menggabungkan transformasi FACT (Fast Extract), CoSort atau Hadoop, dan pemuatan massal di GUI Eclipse yang sama — untuk mengekstrak dan mentransformasi data. Pendekatan ini mencegah membebani database yang dirancang untuk penyimpanan dan pengambilan (optimasi kueri) dengan overhead transformasi data skala besar.
Namun, dengan perkembangan teknologi database baru dan perangkat keras seperti Oracle Exadata yang dapat menangani transformasi 'dalam kotak', ELT dapat menjadi solusi praktis dalam keadaan tertentu. Dan ada manfaat khusus untuk mengisolasi lapisan staging (memuat) dan semantik (mengubah).
Keuntungan yang dikutip dari ELT adalah isolasi proses beban dari proses transformasi, karena menghilangkan ketergantungan yang melekat antara tahapan ini.
Kami mencatat bahwa pendekatan ETL IRI tetap mengisolasi mereka karena Voracity mementaskan data dalam sistem file (atau HDFS). Setiap potongan data yang terikat untuk database dapat diperoleh, dibersihkan, dan diubah secara eksternal sebelum pemuatan (diurutkan sebelumnya). Ini menghilangkan beban transformasi skala besar dari database (serta alat BI/analitik, dll.).
Volume data dan anggaran sering kali menentukan apakah DWA harus mengembangkan solusi ETL atau ELT. Dalam artikel blog ITToolbox-nya “Jadi Apa yang Lebih Baik, ETL atau ELT?”, Vincent McBurney mengajukan pro dan kontra untuk kedua pendekatan tersebut, yang telah saya ulangi di sini di bawah, dan kemudian mengikuti masing-masing dengan tanggapan khas yang IRI ETL pengguna yang berorientasi pada intinya (per peringatan subjektivitas awal saya):
Pro ETLKontra ETL
- ETL dapat menyeimbangkan beban kerja dan berbagi beban kerja dengan RDBMS – dan bahkan menghapus beban kerja tersebut dengan mengubah data melalui program SortCL atau Hadoop tanpa coding di Voracity
- ETL dapat melakukan operasi yang lebih kompleks dalam diagram aliran data tunggal melalui peta data – seperti dengan pemetaan Voracity dan diagram alur kerja yang juga abstrak singkat, terbuka skrip 4GL vs. SQL
- ETL dapat diskalakan dengan perangkat keras terpisah – pada kotak komoditas Anda dapat mencari dan memelihara sendiri dengan biaya yang jauh lebih rendah daripada peralatan vendor tunggal
- ETL dapat menangani partisi dan paralelisme terlepas dari model data, tata letak database, dan arsitektur model data sumber – melalui tugas CoSort SortCL Voracity tidak perlu dipartisi sama sekali ...
- ETL dapat memproses data in-stream, karena transfer dari sumber ke target – atau dalam batch jika itu masuk akal juga
- ETL tidak memerlukan lokasi bersama set data agar dapat berfungsi – memungkinkan Anda untuk memelihara platform sumber data yang ada tanpa kekhawatiran sinkronisasi data
- ETL menangkap sejumlah besar silsilah metadata hari ini- seberapa baik atau secara intuitif satu staging DB dapat melakukannya?
- ETL dapat berjalan pada perangkat keras SMP atau MPP – yang lagi-lagi dapat Anda kelola dan eksploitasi dengan lebih hemat biaya, dan tidak perlu khawatir tentang pertentangan kinerja dengan DB
- ETL memproses informasi baris demi baris dan tampaknya berfungsi dengan baik dengan integrasi data ke produk pihak ketiga – lebih baik lagi blok penuh, tabel, atau file dalam satu waktu, yang dijalankan Voracity dalam volume.
Pro ELT
- Investasi perangkat keras tambahan diperlukan untuk mesin ETL – kecuali jika Anda menjalankannya di server basis data
- Biaya tambahan untuk membangun sistem ETL atau melisensikan alat ETL – yang masih lebih murah dibandingkan dengan peralatan ELT, tetapi masih lebih murah adalah alat IRI seperti Voracity yang menggabungkan Fast Extract (FACT) dan CoSort untuk mempercepat ETL tanpa kerumitan seperti itu
- Kemungkinan penurunan performa pendekatan berbasis baris – benar, dan mengapa kemampuan Voracity untuk membuat profil, memperoleh, mengubah, dan menghasilkan data dalam potongan yang lebih besar lebih cepat
- Keterampilan khusus dan kurva pembelajaran yang diperlukan untuk menerapkan alat ETL – kecuali jika Anda menggunakan GUI ergonomis seperti Voracity yang menyediakan beberapa opsi desain pekerjaan dalam IDE Eclipse yang sama
- Fleksibilitas yang berkurang karena ketergantungan pada vendor alat ETL – Saya tidak yakin bagaimana hal itu dapat ditingkatkan dengan mengandalkan satu vendor ELT/alat; bukankah kemandirian vendor adalah kunci fleksibilitas dan penghematan biaya?
- Data perlu melewati satu lapisan lagi sebelum masuk ke data mart – kecuali mart hanyalah keluaran lain dari proses ETL, tipikal dari operasi Voracity multi-target.
Kontra ELT
- ELT memanfaatkan perangkat keras mesin RDBMS untuk skalabilitas – tetapi juga mengenakan pajak pada sumber daya DB yang dimaksudkan untuk pengoptimalan kueri. Transformasi CoSort dan Hadoop di Voracity memanfaatkan algoritme penskalaan linier dan konsolidasi tugas, bukan memori atau resource I/O DB
- ELT menyimpan semua data di RDBMS sepanjang waktu – boleh saja asalkan data sumber dan target berada dalam DB yang sama
- ELT diparalelkan sesuai dengan kumpulan data, dan I/O disk biasanya dioptimalkan pada tingkat mesin untuk throughput yang lebih cepat – ya, tetapi itu bahkan lebih benar untuk transformasi eksternal yang tidak bersaing dengan sumber daya server DB
- Penskalaan ELT selama perangkat keras dan mesin RDBMS dapat terus melakukan penskalaan – berapa biayanya jika dibandingkan dengan alternatif di atas?
- ELT dapat mencapai 3x hingga 4x tingkat throughput pada platform MPP RDBMS yang disetel dengan tepat – yang menempatkan alat pada tingkat kinerja Voracity relatif terhadap alat ETL, juga, tetapi dengan biaya 20 kali lipat.
- Transformasi ELT dilakukan di server RDBMS setelah database berada di platform target dan tidak lagi membebani jaringan – jadi malah membebani database (pengguna)?
- ELT memiliki spesifikasi transformasi sederhana melalui SQL – yang tidak sesederhana, fleksibel, atau kaya fitur seperti sintaks CoSort SortCL atau pemetaan bidang seret dan lepas di GUI Eclipse Voracity.
- Alat terbatas tersedia dengan dukungan penuh untuk ELT – dan dengan harga yang sangat tinggi untuk peralatan DB yang menggembar-gemborkan kinerja volume tinggi
- Hilangnya statistik pemantauan run-time mendetail dan garis keturunan data – terutama analisis dampak metadata pada perubahan pada file, tabel, atau sumber tidak terstruktur yang berbeda
- Hilangnya modularitas karena desain berbasis set untuk kinerja – dan hilangnya fungsionalitas/fleksibilitas yang mengalir darinya
- Transformasi akan memanfaatkan sumber daya Database, yang berpotensi memengaruhi kinerja pelaporan BI – belum lagi kinerja kueri dan operasi DB lainnya
Arsitektur hibrida seperti ETLT, TELT dan bahkan TETLT kemudian muncul dalam upaya untuk menopang kelemahan dalam kedua pendekatan tersebut. Tetapi ini tampaknya menambah tingkat kerumitan tambahan pada proses yang sudah begitu penuh. Sebenarnya tidak ada peluru perak, dan banyak proyek integrasi data gagal karena beban SLA, pembengkakan biaya, dan kompleksitas.
Karena alasan inilah IRI membuat Voracity untuk mengintegrasikan data melalui program CoSort SortCL dalam sistem file yang ada atau fabric Hadoop tanpa pengodean ulang. Voracity adalah satu-satunya platform berorientasi ETL (meskipun juga mendukung ELT) yang menawarkan kedua opsi untuk transformasi data eksternal. Selain kinerja harga yang unggul dalam pergerakan dan manipulasi data, Voracity mencakup:
- transformasi data lanjutan, kualitas data, MDM, dan pelaporan
- mengubah dimensi secara perlahan, mengubah pengambilan data, federasi data
- pemrofilan data, penyembunyian data, pembuatan data pengujian, dan manajemen metadata
- skrip 4GL sederhana yang dibuat dan dikelola oleh wizard, diagram, dan dialog Eclipse
- eksekusi yang mulus di Hadoop MR2, Spark, Spart Stream Storm, dan Tez
- dukungan untuk erwin Smart Connectors (konversi dari alat ETL lainnya)
- driver MongoDB asli dan koneksi ke NoSQL, Hadoop, cloud, dan sumber lama lainnya
- pelaporan tersemat, statistik, dan fungsi prediktif, keterkaitan KNIME dan Splunk, serta feed data alat analitik.
Lihat juga:
- http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
- http://www.iri.com/solutions/data-integration/etl
- http://www.iri.com/solutions/data-integration/elt
- http://www.iri.com/solutions/data-integration/implement
