Contoh Kettle Loop

[Feris Thia]

Hi All,

Sesuai janji saya kepada Andreas untuk membuat contoh Kettle yang
lebih kompleks berikut adalah artikel wiki dengan contoh data transfer
loop yang saya buat menjadi 2 bagian :

http://pentaho.phi-integration.com/kettle/data-transfer-loop-handling-bagian-1
http://pentaho.phi-integration.com/kettle/data-transfer-loop-handling-bagian-2

Bagian 1 berisi penggunaan contoh dan bagian 2 penjelasan rinci dari
tiap fitur yang digunakan.

Pada saat penulisan email ini, bagian 2 lagi saya lengkapi. Bila ada
yang sudah mempelajari contoh ini dan bisa memberi kontribusi saya
tentunya sangat senang ;)

Btw, mohon masukan juga untuk artikel ini misalknya di bagian mana
yang kurang jelas, perlu tambahan gambar, dsbnya.

--
Thanks & Best Regards,

Feris Thia
Business Intelligence Consultant
PT. Putera Handal Indotama
Phone : +6221-30119353
Fax : +6221-5513483
Mobile : +628176-474-525
http://www.phi-integration.com
http://pentaho.phi-integration.com

[Andreas]

Bung Feris,

Mantap contohnya. Lumayan complicated juga, masih dalam tahap
mempelajari-nya dulu nih.
Thanks banget atas effortnya.

Regards,
Andreas

On Sep 15, 8:57 pm, "Feris Thia" <fe...@phi-integration.com> wrote:
> Hi All,
>
> Sesuai janji saya kepada Andreas untuk membuat contoh Kettle yang
> lebih kompleks berikut adalah artikel wiki dengan contoh data transfer
> loop yang saya buat menjadi 2 bagian :
>

> http://pentaho.phi-integration.com/kettle/data-transfer-loop-handling...http://pentaho.phi-integration.com/kettle/data-transfer-loop-handling...

[Feris Thia]

Sama2 Bung Andreas,

Kalau ada contoh workaround lain, boleh tuh diposting di wiki juga. Tentunya dengan menyertai profile Bung Andreas ya ;)

Thanks,

Feris

[Andreas]

BungFeris,

Contohnya sudah saya coba dan berhasil dijalankan. Dibandingkan dengan
transfer secara langsung ternyata perbedaan lama waktunya tidak
terlalu berbeda.
Jika saya transfer langsung antar 2 database membutuhkan waktu 33
seconds, sedangkan jika ditambahkan dengan proses loop membutuhkan
waktu 37,5 seconds.

Kayaknya ini bisa diterapkan nih kalau performanya seperti ini. Tapi
saya baru coba untuk database yang ada di local area saja sih. Belum
sempat untuk mencoba antar database yang cukup jauh.

Tapi saya ada pertanyaan nih Bung Feris, kalau dari contoh kan DBMS
asal yang digunakan adalah MySQL, lalu di query "SELECT BY OFFSET"
menggunakan fungsi limit yang hanya ada pada DBMS MySQL. Nah
pertanyaannya, bagaimana kalau DBMS asal yang digunakan bukan MySQL
dan tidak mempunyai fungsi limit ini, sebagai contoh SQL Server.

Regards,
Andreas

[Feris Thia]

Hi Bung Andreas,

Kalau di SQL Server memang tidak ada offset paging langsung seperti itu.

Tapi workaround yang biasanya saya lakukan, misalnya :

Di MySQL :

Select * from Customers limit 10, 100

Di SQL Server

select top 100 * from Customers
where CustomerID not in
(
    select top 10 CustomerID from Customers
);

Keynya harus sama, kalau perpaduan menggunakan concatenation.

Semoga membantu...

Regards,

Feris

2008/9/16 Andreas <andrea...@gmail.com>

--
Thanks & Best Regards,

Feris Thia
Business Intelligence Consultant
PT. Putera Handal Indotama
Phone : +6221-30119353
Fax : +6221-5513483

[Andreas]

Bung Feris,

Hmm... Kalau dilihat sepintas sih memang tampak sama. Tapi ini hanya
untuk case dimana table tersebut mempunyai primary key (tidak ada data
yang redundant)
,masalah akan timbul jika ternyata ada data yang redundant. Tapi
sejauh ini cukup clear kok Bung Feris. Kebetulan table yang akan saya
transfer punya PK semua.
Thx banget nih buat pencerahannya.

Untuk masalah limit di MySql kita angkat di thread yang baru saja deh,
jangan disini karena sudah OOT.

Regards,
Andreas

[StandAlone™]

kalau saya biasanya menggunakan fitur error handling apabila ada problem saat insert ke database.
nantinya ketika network sudah resolve, bisa diulang kembali menggunakan file hasil error handling itu.
menjaga agar data yang query merupakan snapshot yang sama.

jadi looping awal tersebut melakukan pengecekan apakah ada file error handling itu.
jika ada, jalankan file itu saja.
jika tidak ada, maka query ulang dari database.

karena biasanya server database akan berbeda dengan server kettlenya.
jadi lumayan buat save di cost network saat query ulang database.

resikonya, yah saat ingin mereplay harus menunggu proses utama selesai dulu.




๑۩۩๑oº*ºo.. -------------------------- ..oº*ºo๑۩۩๑
Maka nikmat Tuhan kamu yang manakah yang kamu dustakan?
~~~~~~~~~~~~~~~~~~~~~~
http://standalone.blogsome.com
http://pribadi.wordpress.com
~~~~~~~~~~~~~~~~~~~~~~

2008/9/16 Andreas <andrea...@gmail.com>

[Feris Thia]

Hi Bung Lhutfhy,

Iya... pendekatan yang bagus juga... kalau saya terjemahin kira-kira seperti ini :

Start => Check Point : Error Snapshot File Exist ? :
                  => Yes => Dump to Destination
                  => No => Continue to main loop ... => ... => Dump Error ? => Create Error Snapshot File

Share yang bagus Bung Lhutfhy :)

Thanks,

Feris

2008/9/16 StandAlone™ <lhu...@gmail.com>

[Andreas]

Dear all,

Hanya ingin menyampaikan hasil uji coba yang saya lakukan untuk design
di-atas.

Total record : 150.000 record
Database asal : Local (Jakarta)
Database tujuan : Hongkong

Dengan kondisi network sebagai berikut:

1 1 ms 1 ms 1 ms 10.49.1.1
2 3 ms 1 ms 2 ms 10.49.0.4
3 1 ms 1 ms 1 ms 10.49.3.10
4 1 ms 1 ms 1 ms 10.49.3.1
5 6 ms 15 ms 8 ms 10.63.250.137
6 114 ms 182 ms 143 ms 10.63.250.5
7 57 ms 86 ms 91 ms 10.63.250.6
8 56 ms 117 ms 56 ms
9 60 ms 78 ms 69 ms
10 174 ms 91 ms 262 ms
11 62 ms 65 ms 63 ms HK

Hasil-nya:

Direct transfer (tanpa loop) = 3 jam 30 menit
Dengan loop = 2 jam 40 menit

Regards,
Andreas

[Feris Thia]

Hi Andreas,

Wow... ada perubahan cukup signifikan ya ?

Berarti dugaan saya pada saat dumping ke Hong Kong ini yang bermasalah padahal cuma 150 ribu record. Hm, pihak network dan db admin bisa coba diajak consult tuh :)

Btw... thanks banget atas benchmarking dan menunjukkan bahwa dengan kontrol yang lebih baik dapat meningkatkan kinerja.

2008/9/18 Andreas <andrea...@aig.com>

Hasil-nya:

Direct transfer (tanpa loop) = 3 jam 30 menit
Dengan loop                     = 2 jam 40 menit

[Joshua Partogi]

Keren. Bedanya sampe satu jam. Kenapa bisa jauh sekali ya
perbedaannya? I'm stunned.

2008/9/18 Feris Thia <fe...@phi-integration.com>:

> Hi Andreas,
>
> Wow... ada perubahan cukup signifikan ya ?
>
> Berarti dugaan saya pada saat dumping ke Hong Kong ini yang bermasalah
> padahal cuma 150 ribu record. Hm, pihak network dan db admin bisa coba
> diajak consult tuh :)
>
> Btw... thanks banget atas benchmarking dan menunjukkan bahwa dengan kontrol
> yang lebih baik dapat meningkatkan kinerja.
>
> 2008/9/18 Andreas <andrea...@aig.com>
>>
>> Hasil-nya:
>>
>> Direct transfer (tanpa loop) = 3 jam 30 menit
>> Dengan loop = 2 jam 40 menit

--
Read my blog: http://joshuajava.wordpress.com/
Follow me on twitter: http://twitter.com/jpartogi

[Feris Thia]

Dugaan saya adalah perjalanan ke HK ini yang memang terjadi banyak kendala, jadi dengan looping kita memberi nafas ke dia sekaligus kita mengurangi I/O di sistem (dengan batching di inputnya).

Kalau disain sebelumnya input diambil terus-menerus dan output juga dibiarin berlangsung aja tanpa kontrol yang lebih sophisticated.

IMHO, handle I/O di data warehouse seperti "art" memang... pengetahuan tentang berbagai hal harus cukup banyak dan solusinya biasanya unik banget untuk tiap proyek :)

2008/9/18 Joshua Partogi <joshu...@gmail.com>

Keren. Bedanya sampe satu jam. Kenapa bisa jauh sekali ya
perbedaannya? I'm stunned.

[Andreas]

Wah bung Josh baru keliatan lagi nih.. hehe..

Setuju sih dengan pendapatnya Bung Feris, dengan adanya loo[ping
memberikan kesempatan sistem untuk membersihkan temporary file yang
dipakai. Jadi I/O sistem tidak terlalu terbebani.

Btw ada satu hal yang aneh juga nih.. Saya coba mencoba bereksperimen
dengan menggunakan kitchen. Ternyata dengan menggunakan kitchen, waktu
yang dibutuhkan agak bertambah. berikut hasil-nya:

via spoon : 2 jam 40 menit
via kitchen : 2 jam 45 menit

Hasil-nya agak aneh nih menurut saya. Kitchen itu kan berjalan jadi
under prompt tanpa GUI, seharusnya kan berjalan lebih cepat, tetapi
hasil-nya malah lebih lambat.
Memang sedikit sih perbedaan-nya,kalau perkiraan saya sih ini
dikarenakan masalah traffic yang jelek.

Regards,
Andreas

[Feris Thia]

Hi Bung Andreas,

Bung Joshua lagi siap2 neh... jadi mungkin tidak bisa ikut detailnya :p hehehe

Btw, untuk kitchen lognya diset minimal, error aja  atau tidak ada sama sekali :

kitchen -file=namafile [-version] [-log=namafilelog][-level=logging level]

level = error / minimal / nothing

Tapi ya... mungkin juga dengan traffic yang jelek jadi kurang / lebih gitu :)

2008/9/18 Andreas <andrea...@aig.com>

[Joshua Partogi]

2008/9/18 Andreas <andrea...@aig.com>:

Kalau beda dikit gitu bisa karena kondisi networknya sedang tidak
stabil. Dicoba pas after working hours, atau pas semua udah pada
pulang.

[Andreas]

Semua kasus di set log-nya Basic, biar gak terlalu memakan waktu.
Iya sih pengen nyoba juga diwaktu networknya gak sibuk. Nanti saya
kabarin lagi deh, kalau ada perkembangan lebih lanjut.

Regards,
Andreas

[StandAlone™]

kalau bisa dilakukan test secara repetitif sebanyak N kali.
sehingga didapat angka rata-rata yang lebih mewakili kondisi network yang turun naik.


bisa jadi percobaan pertama tanpa loop terjadi network yang lebih sibuk dibandingkan dengan percobaan dengan loop.

coba mas mysql outputnya pakai mysql-bulk-loader, mungkin bisa meningkatkan performansi.

๑۩۩๑oº*ºo.. -------------------------- ..oº*ºo๑۩۩๑
Maka nikmat Tuhan kamu yang manakah yang kamu dustakan?
~~~~~~~~~~~~~~~~~~~~~~
http://standalone.blogsome.com
http://pribadi.wordpress.com
~~~~~~~~~~~~~~~~~~~~~~

2008/9/18 Andreas <andrea...@aig.com>

[Andreas]

Dear StandAlone,

Maunya sih gitu. Tapi apa daya, kerjainnya juga sambil curi-curi waktu
kerja. Dah gitu sekali jalan aja butuh waktu 2 jam lebih. Kalau
melakukan test secara repetitif, bisa-bisa kerjaan yang laen jadi
terbengkalai. Kalau ketauan boss, bisa diomelin nih.. :)

Regards,
Andreas