Pribadi

Data Warehouse pada Data Super Besar

Posted on: 25 September 2008

Biasanya jika sedang mendalami data warehouse, akan menemui dua tokoh dalam beberapa literatur. Ralph Kimball dan Bill Inmon. Keduanya cukup populer, dan cukup kontroversial karena kedua pendekatan mereka dalam membangun data warehouse sangat kontradiksi.

Penjelasan sederhana dari pendekatan Ralph Kimball adalah bahwa data warehouse berawal dari kumpulan data mart (bottom-up approach) yang berada dalam sebuah lingkungan enterprise (sebuah buzzword yang hampir semua orang memiliki pandangan yang berbeda, enterprise). Dalam desainnya, informasi dalam data warehouse selalu disajikan dalam bentuk dimensional. Fact, measure dan dimension adalah kata kunci dari pendekatan bapak yang satu ini.

Berbeda dengan Bill Inmon yang menegaskan bahwa data warehouse sebaiknya dibangun jika desain arsitektur data warehouse sudah dibuat (top-down approach). Karena data warehouse merupakan bagian dari business intelegent (apa lagi neh?) maka segala informasi berasal dari satu data warehouse. Data warehouse 3rd normal form atau 3NF adalah kata kunci beliau.

Antara pendekatan Ralph Kimball dan Bill Inmon, manakah yang harus digunakan?

Kebanyakan artikel pasti tidak akan menyalahkan kedua pendekatan ini. Karena keduanya memang bisa diterapkan. Namun jika semakin mendalami data warehouse, pendekatan Ralph Kimball akan terlihat masuk akal. Bukan karena pendekatan Bill Inmon salah, melainkan karena pendekatan Ralph Kimball sangat mudah untuk diimplementasikan. Kita tidak perlu memahami seluruh data enterprise untuk memulai sebuah data warehouse. Kata mereka, untuk memulai akan sangat mudah dengan Ralph Kimball, namun akan banyak mengalami kesulitan pada jangka panjang. Susah dikelola! Benarkah?

Selain dibutuhkan pemahaman yang menyeluruh terhadap data enterprise, pendekatan Bill Inmon sangat susah untuk dimulai. Namun dalam jangka waktu yang panjang, akan sangat mudah dalam mengelolanya (jika desainnya memang sudah benar!?). Karena pendekatan Bill Inmon susah dalam tahap desain awal, maka sangat wajar jika kebanyakan perusahaan konsultan yang bergerak dalam data warehouse menawarkan cetak biru (blueprint) desain data warehouse “best practice” dengan pendekatan 3NF. Agar para perusahaan tak perlu bersusah payah mendesain dari awal mengenai desain data warehouse di bidang usahanya. Mereka menyebutnya data model.

Jika harus memilih di antara kedua pendekatan tersebut, apa yang akan saya pilih?

Sebelum saya memilih, perlu saya jelaskan apa sebenarnya data warehouse pada kenyataannya. Saya bukan ingin menjelaskan pemodelan yang biasa ditemui di banyak literatur yang mengatakan 3NF atau dimension. Tapi saya akan mencoba mejelaskan data warehouse dari sudut pandang berbeda. Ukuran atau size. Saya coba ambil contoh model SalesFact dari artikel pak Toto mengenai Perancangan Data Warehouse.

Ukuran 1 dantum/tuple/record = ~40 bytes, rincian sebagai berikut:

  • kode_barang > varchar(5) = ~7 bytes.
  • kode_periode > varchar(8) = ~10 bytes.
  • kode_lokasi > varchar(5) = ~7 bytes.
  • total_penjualan > double = ~8 bytes.
  • total_penerimaan > double = ~8 bytes.

Karena menggunakan pendekatan dimension maka potensi jumlah record dalam sebulan sekitar 60.000 record, rincian sebagai berikut:

  • kode_barang.
    Jika seandainya menjual 100 jenis barang.
  • kode_periode.
    Asumsi bahwa varchar(8) akan berisi info “YYYYMMDD” (contoh: “20080925”), berarti summary per hari, yaitu 30 hari.
  • kode_lokasi
    Jumlah cabang yang dimiliki perusahaan ini, anggaplah ada sekitar 20 (biar gampang hitungnya huehuehuehue).

Maka dalam sebulan akan membutuhkan ruang data sebesar 2.400.000 bytes atau 2,4 Mb. Sangat kecil jika dibandingkan dengan ruang data yang dijual di pasar (sudah ada 1 tera byte loh!). Tunggu dulu, ini baru data sebulan. Apa gunanya kalau cuma data sebulan (ya ada seh gunanya, tapi). Setidaknya menyimpan hingga 6 -24 bulan. Supaya dapat terlihat trend data dan pola statistiknya. Jadi berapa ukurannya? 57.600.000 bytes atau 57 MB.

Masih terhitung kecil? Apakah kamu pernah memperhatikan bahwa data yang disimpan dalam database akan bertambah besar? Akan ada kebutuhan untuk indeks, spool dan temp (bergantung jenis database yang digunakan). 

Tapi, karena jumlah ukuran data yang terlibat masih kecil, maka keputusan memilih menggunakan pendekatan manapun akan sama saja. Susah untuk dikelola? Ah bercanda.

Namun bagaimana membangun data warehouse jika dihadapkan data super besar?

Dalam contoh di atas, kalau menurut opini saya, IMHO katanya, tidak perlulah menggunakan data warehouse pendekatan Inmon atau Kimball. Kenapa tidak simpan saja detail per transaksi? Bukankah akan jadi lebih akurat dan lagipula tidak membutuhkan ruang data yang besar.

Lain halnya jika dihadapkan dengan data super besar dan super kompleks. Barulah data warehouse sangat diperlukan (benarkah?). Namun, seperti apa sebenarnya data super besar dan super kompleks itu?

Salah satu contoh yang sempat terpikir adalah operator seluler dengan jumlah pelanggan yang diklaim sebanyak 58 juta orang (wah jika 1 record adalah 1 byte, maka 58 juta akan menjadi 58 Mb, hmmm). Seandainya perusahaan telekomunikasi ini ingin menyimpan info mengenai:

  • nomor pelanggan > varchar(18) = ~12 bytes.
  • waktu melakukan layanan > varchar(8) = ~ 10 bytes (jika pakai char(8) akan menjadi 4 bytes loh).
  • layanan telekomunikasi yang digunakan (SMS, voice, GPRS dll) > varchar(3) = ~5 bytes.
  • total penggunaan layanan > double = ~8 bytes.
  • lokasi penggunaan > varchar(5) = ~7 bytes.
  • total durasi/byte data yang digunakan > double = ~8 bytes.
  • total pendapatan > double = ~8 bytes.

Jadi 1 record berukuran sekitar 51 bytes. Hitungan belum selesai:

  • nomor pelanggan.
    Ada sekitar 58.000.000 pelanggan.
  • waktu melakukan layanan.
    Kurang lebih sama dengan contoh sebelumnya 30 hari.
  • layanan telekomunikasi yang digunakan (SMS, voice, GPRS dll).
    Hmmm, SMS, voice dan GPRS berarti cuma 3.
  • lokasi penggunaan.
    Kalau kata iklan bahwa sudah menjangkau lebih dari 1000 kecamatan di Indonesia. 

Akan ada sekitar 5.220.000.000.000 bytes (atau 5,22 Tb) data dalam sebulan. Jika disimpan dalam 24 bulan berarti menjadi 125,28 Tb. 

Dengan ukuran data sebesar itu, pemilihan dimension pada pendekatan Kimball harus benar-benar memilih tingkat granularitas yang mumpuni (bisa tidak?). Jika menggunakan Inmon maka harus mempersiapkan budget yang tidak sedikit untuk investasi perangkat keras. Karena 3NF boros ruang penyimpanan!

Ketika dihadapkan data yang super besar, kedua pendekatan ini harus benar-benar dipertimbangkan. Namun kebanyakan profesional IT akan memilih pendekatan 3NF-nya bapak Inmon (atau cuma profesional IT sales?). Karena sudah terbukti sebagai “best practice”. Cukup investasi di satu sisi saja: budget. 

Pada kenyataannya, hampir semua data warehouse memiliki kondisi seperti ini. Boros ruang penyimpanan! Dan dalam bisnis, keborosan merupakan  sesuatu yang harus dihindari, kecuali dalam tujuan riset akademis di kampus. Selebihnya kita harus dapat menjustifikasi bahwa ROI menggunakan data warehouse masuk dalam profitabilitas jangka pendek (karena jangka panjang sudah pasti). Maukah perusaahaan bertaruh dana dalam jumlah yang tidak sedikit dalam membangun data warehouse yang notabene tidak memiliki hubungan langsung dengan penjualan barang atau layanan?

Jadi, jika dihadapkan data super besar, pendekatan apa yang saya pilih?

Terus terang saya setuju dengan pendapat Bill Inmon bahwa data warehouse adalah bagian dari business intelegent. Namun saya sangat tidak setuju jika harus mendesain secara komprehensif arsitektur data warehouse sebelum implementasi. Lagipula, cetak biru “best practice” tawaran dari pihak konsultan pun tidak bisa langsung dipakai dan diterapkan. Kenyataannya, saya perlu memahami data enterprise terlebih dahulu agar bisa diterjemahkan pada cetak biru tersebut (termasuk mempelajari cetak birunya). Sangat tidak mudah.

Dengan pendekatan Kimball pun saya tidak bisa memastikan tingkat granularitas data yang dibutuhkan oleh perusahaan. Bisa jadi data warehouse yang saya bangun bersifat GIGO (Garbage In Garbage Out). Artinya saya menyimpan informasi yang tidak dibutuhkan oleh bisnis, karena saya merasa bahwa ada data sekiranya bisnis akan membutuhkan. Dan hal ini menyebabkab ruanya penyimpanan menjadi tempat penyimpanan data yang tidak diperlukan. Hal ini pun dapat terjadi pada pendekatan Inmon. 

Karena saya sependapat bahwa data warehouse adalah bagian dari business intelegence maka sudah seharusnya saya memilih dengan menggunakan sudut pandang bisnis. Ada sebuah pendekatan lagi yang menurut saya sangat cocok dilakukan dalam membangun data warehouse: “business-led approach”. kata kuncinya adalah pendekatan business-led dan Rob Mattison. Ada yang pernah dengar?

1 Response to "Data Warehouse pada Data Super Besar"

Sayang sekali saya baru membaca artikel ini setelah satu tahun lewat dari waktu penulisannya. Tulisannya menarik karena anda mencoba melihat dari sisi pandang praktis yaitu besar-kecil data dan manfaat investasi dari Data Warehouse.

Komentar saya: Anda keliru karena melihat keperluan Data Warehouse yang hanya sebagai media penyimpanan data. Yang anda perlu perhatikan adalah Data Warehouse dibangun dengan pendekatan Subject-Oriented.

Intinya Subject Oriented adalah Subject (area)-subject (area) apa yang akan digali dari Data Warehouse tersebut. Dari ukuran cakupan (satu/beberapa) Subject area-lah kita akan dapat mengukur berapa besar atau kecil Data Warehouse yang akan kita bangun lalu kita dapat memutuskan metode apakah yang kita akan gunakan: langsung data warehouse yang dirancang langsung utuh secara top-down (Inmon) atau dari rangkaian data mart (Kimball).

sementara itu dulu. Terima kasih.

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

Categories

Archives

My Bookmarks

%d blogger menyukai ini: