Saturday, August 30, 2008

Change Data Capture (CDC)

Apa itu Change Data Capture ?


Salah satu kendala peningkatan kinerja di dalam implementasi data warehouse adalah strategi pengambilan  data transaksional yang mengalami perubahan dari titik pengambilan (snapshot) terakhir. Hal ini dikenal dengan nama proses pengambilan data yang berubah atau Changed Data Capture (CDC).

Beberapa Teknik Solusi


Untuk beberapa vendor BI pemecahan masalah ini mungkin kelihatan sederhana seperti penambahan kolom timestamp pada tabel yang akan di-capture maupun membuat tabel audit baru yang mencatat perubahan data di tabel yang dipantau.

Selanjutnya kolom ini akan dipopulasi berdasarkan perubahan yang terjadi melalui mekanisme trigger (insert, update dan delete).

Teknik lainnya adalah  mencoba untuk menggantungkan diri pada sistem aplikasi yang ada misalkan aplikasi ERP (Enterprise Resource Planning) yang memiliki  field seperti creation_date dan updated_date - yang masing-masing mewakili waktu dibentuknya row data dan waktu update terakhir.

Namun pendekatan solusi ini memiliki kelemahan, bagaimana kalau row tersebut dihapus ? Tentunya kita tidak bisa melakukan query terhadap row tersebut lagi dan row data yang berkaitan di data warehouse kita tentu sudah menjadi tidak valid lagi tanpa kita bandingkan dengan row data sumber.

Ada juga solusi yang "tidak mau ambil pusing"... yaitu mencoba membandingkan satu per satu row dari data warehouse dengan data asalnya. Solusi ini tentunya adalah proses yang sangat lama dan 'mahal'. Bukan saja ini solusi yang tidak tepat karena menurunkan kinerja tapi hampir mustahil dilakukan atas alasan praktis terutama jika data yang ditangani sudah sangat besar.

Walau pada awalnya bagi sebagian orang, masalah capture data ini kelihatan sepele tapi memang tidak sesederhana seperti yang dipikirkan.

Contohnya jika menyangkut policy maka pada kebanyakan kasus kita tidak boleh merubah struktur maupun membuat trigger apapun pada database client kita sehingga menjadikan solusi pengambilan data ini menjadi semakin sulit.

Jika ini yang terjadi, maka solusi terbaik yang biasanya dapat dilakukan adalah membuat aplikasi untuk membaca dan menganalisa transaction log dari database yang digunakan sehingga tidak mengganggu data sebenarnya. Transaction log biasanya adalah file yang digunakan sebagai jembatan untuk mencatat transaksi yang dilakukan sebelum dilakukan perubahan ke tabel sebenarnya.

Namun lagi-lagi solusi ini terkendala oleh tidak adanya log file ini pada beberapa sistem database terutama jika itu adalah legacy database system atau sistem database lama seperti XBase.

Masalah lain yang dihadapi dengan pendekatan ini adalah kebanyakan sistem database populer tidak menyertakan dokumentasi ataupun API untuk mengambil informasi dari transaction log-nya seperti contoh MS SQL Server 2000. Jika ini yang terjadi, maka kita terpaksa harus menduga-duga dengan melakukan reverse engineering yang tentunya sangat menghabiskan waktu.

Nah untungnya bagi para teman-teman sesama praktisi data warehousing, sebagian database populer ternyata mendukung fitur CDC ini seperti Oracle 9i ke atas. Berita baik juga untuk para pengguna produk Microsoft SQL Server, sejak versi 2008 fitur CDC sudah disertakan di dalam produk ini.

Produk Pihak Ketiga


Bagaimana untuk produk database server lainnya yang tidak mendukung langsung pembacaan perubahan data ?

Untuk Anda yang serius untuk mendapatkan solusi ini ada beberapa vendor/produk yang mengkhususkan diri di area ini, diantaranya :
  • Attunity , untuk produk seperti DB2, Oracle, Microsoft SQL Server, dan lainnya.
  • Apex SQL , untuk produk Microsoft SQL Server
  • Golden Gate, fiturnya hampir sama dengan Attunity
  • dan lain-lain, untuk list lengkapnya dapat dilihat di situs IT-Toolbox.

Penutup


Change Data Capture (CDC) atau masalah pengambilan data yang berubah dari suatu titik waktu tertentu adalah hal yang cukup krusial di dunia data warehousing. Dengan mengambil strategi populasi bertahap maka kita harus memastikan kalau data yang akan kita ambil pada tahap berikutnya memang berbeda dari data saat terakhir kita melakukan proses.

Dan dengan mengenali dukungan untuk CDC ini pada produk database yang digunakan oleh klien kita dan juga mengetahui adanya solusi pihak ketiga yang menyediakan dukungan ini maka akan menjamin kesuksesan lebih lanjut dari implementasi proyek yang kita lakukan.

Semoga berguna dan sampai jumpa di artikel BI berikutnya...

Feris

3 comments:

Anonymous said...

saya mahasiswi yng mengangkat cdc sbg topik tgs akhir..
kira2 ada tdk kondisi dari source database yng membuat performansi cdc menurun

Misal, ketika throughput tiba2 sangat besar..
emudian parameter apa yng bs digunakan untuk mengukur efektivitas peng-capturan data

Feris Thia said...

Hi Anonymous,

Mohon maaf saya baru baca comment ini.

Untuk trade-off kelengkapan vs performance saya sangat setuju kalau CDC akan meng-gradasi performance.

Tapi kalau memang mainnya di data warehouse sejauh ini beban mencatat perubahan di source akan sangat bisa diterima.

Hm... kalau bicara "efektivitas" dan bukan efisiensi maka saya akan mengambil kasus data warehouse (repopulate) dan CDC. Maka parameter yang akan saya gunakan adalah :
- Tingkat gangguan operasional pada saat peak time entri data dan laporan data. Misal jumlah dead lock, jumlah waktu, jumlah user yang terkena, dll.
- Jumlah waktu (otomatis overhead I/O) yang dibutuhkan untuk data warehouse NON CDC vs CDC

Demikian Anonymouse, semoga berguna ya.

Btw, kenapa tidak bergabung di milis Pentaho di pentaho-id@googlegroups.com untuk diskusi lebih lanjut ? Subscribe dengan pentaho-id+subscribe@googlegroups.com


Regards,

Feris

Yoyo said...

Hi Feris,

bagaimana kalo kita membandingkan dengan any_date+value_kolom_yang_sering_berubah ?

Norman