Saya ingin mentransformasi data pada 2 table dengan menggunakan Kettle. Saya ingin membuat sebuah design yang simple saja, jangan yang terlalu rumit, tapi design yang saya buat ini harus powerfull. Maksud dari powerfull ini adalah aman, recoverable, bisa mengatasi berbagai masalah yang mungkin terjadi.
Pemikiran seperti ini sangat lazim muncul jika anda masih baru atau sudah mempelajari Data Transformation Design, tidak hanya pada Kettle tapi juga tool yang lainnya. Saya sendiri pun sampai saat ini masih terus mencari sebuah design yang seperti itu. Mana yang paling cocok diterapkan pada sistem yang ada saat ini.
Contoh design yang paling sederhana adalah seperti berikut:
Simple Design
Design seperti di atas sangat mudah sekali dimengerti, tetapi jika kita ingin menggunakan design seperti ini untuk scheduled job, sangatlah tidak dianjurkan. Kenapa tidak dianjurkan? Karena pada design seperti di atas mau tidak mau, kita akan men-truncate table tujuan terlebih dahulu sebelum transformasi dilakukan, jika tidak makan akan terjadi error duplikasi data. Hal inilah yang akan menimbulkan beragam masalah, terutama koneksi jaringan anda bermasalah:
- Jika data yang dikirim besar, apakah proses transformasi akan sukses?
- Jika proses transformasi gagal, maka data di table tujuan sudah terlanjur di-truncate. Bagaimana cara me-restore data tersebut?
Hal-hal classic seperti ini lah yang ditakuti akan terjadi. Lalu bagaimana cara mengatasi masalah ini? Akan saya coba berikan solusinya pada tulisan ini, tapi sebelumnya kita coba lihat contoh design kettle yang jauh lebih kompleks.
Contoh design yang kompleks:
Bisa dilihat di:
Data Transfer Loop Handling (Bagian 1)
Data Transfer Loop Handling (Bagian 2)
Complex Design
Kalau kita lihat dari design seperti di atas, mungkin yang akan keluar pertama kali dipikiran anda: “Itu apa yah? Kok kayaknya rumit sekali.”
Setidaknya itulah yang keluar dipikiran saya :p
Tapi jika anda mencoba untuk mempelajari-nya tidak sesulit pada kesan pertama kok. Hehe..
Tenang saja, saya solusi yang saya berikan jauh lebih sederhana daripada design di atas. Tapi pilihan tetap ada di tangan anda. 😉
Mari langsung saja ke inti permasalahannya, solusi yang akan saya berikan sebenarnya tidak terlalu jauh dari design yang paling sederhana yang kita bahas pertama kali. Jika kita perhatikan dan analisa lebih jauh design awal, sebenarnya masalah yang paling besar atau saat yang paling rentan adalah pada saat kita akan sudah men-truncate table tujuan sampai data selesai ditransfer. Kita bisa mempersingkat waktu antara men-truncate table sampai data selesai ditransfer dengan cara mempergunakan bantuan 1 buah table lagi yang akan digunakan sebagai temporary table.
Jadi kria-kira scenario-nya dalah sebagai berikut:
- Kita men-create sebuah Temporary Table
- Kettle mentransfer data dari Table Input ke Table Temporary
- Table Output di drop
- Lalu Table Temporary di rename menjadi Table Output
Dengan begitu resiko data yang hilang/gagal di transfer akan menjadi sangat kecil. Tentu saja karena masih ada resiko tranformasi data gagal. Maka pada tahap no.1 kita akan tambahkan sql script untuk melakukan penge-cekan apakah Table Temporary masih exist atau tidak, jika ya akan di drop.
Kira-kira Design-nya seperti ini:
Solution Design
Mengenai bagaimana cara untuk mengcreate table, mendrop table, mengecek apakah table x exist atau tidak, tidak saya bahas pada artikel ini. Karena setiap Database mempunyai native sql yang berbeda-beda.
Semoga tulisan ini bermanfaat bagi anda.
Andreas Tjong 