Pribadi

Posts Tagged ‘data warehouse

Jika tidak salah, semua berawal pada bulan Juni 2008 di mana ada kebutuhan untuk membuat data warehouse khusus untuk data mining. Saya bergabung ke dalam tim untuk projek impementasi solusi kebutuhan data warehouse tersebut. Sejalannya waktu, dari solusi khusus untuk data mining, projek ini pun bermetamorfosis menjadi migrasi data warehouse dari platform lama ke platform yang baru.

Pada dasarnya migrasi tersebut sangatlah mudah secara teknik, namun banyak hal dan kepentingan yang membuatnya menjadi serba kompleks. Dan kendala terbesar adalah banyak pihak berekspetasi tinggi bahwa dengan memigrasikan ke platform baru maka performansi menjadi lebih baik. Yeah, right! Analogi yang mungkin sedikit tepat untuk projek ini adalah migrasi Windows XP ke Windows Vista namun dengan downgrade hardware. Platform baru memang menjanjikan, tapi tolong dong dilihat secara keseluruhan.

Terus terang saya merasa kesal dengan tim terdahulu yang telah melakukan perhitungan kapasitas hardware yang sangat jauh dari kebutuhan untuk melakukan migrasi data warehouse ini.

Awalnya saya coba menawarkan data model baru yang sedikit lebih kompleks dibandingkan dengan data model di platform yang lama. Data model yang saya tawarkan setidaknya dapat menjawab semua report yang dilayani oleh platform lama. Perlu re-engineer sedikit agar yang biasanya disimpan secara detail diganti dengan pendekatan Ralph Kimball yang saya pahami. Alasan utama saya menawarkan data model baru adalah agar proses report dan analisis pada platform lama dapat tetap terakomodasi, dan data bisa muat ke platform baru yang kapasitas storage-nya cuma satu per sepuluh dari platform lama (80 TB).

Aaah, saya berhadapan dengan orang-orang berparadigma data-sedetail-mungkin dan model-yang-future-proof. Terus terang saya agak bingung mengapa mereka tetap memaksa untuk menyimpan sedetail mungkin dengan keadaan seperti itu? Singkat cerita akhirnya didapat juga data model baru versi 2.0, setelah melewati tawar-menawar yang sengit *halah*.

Data warehouse sudah jalan hampir 2 bulan di platform yang baru. Saya tetap merasa bahwa projek ini merupakan sebuah keberhasilan yang luar biasa (bagi saya pribadi). Namun, seperti yang saya bilang, orang lain mempunyai ekspetasi berbeda. Berbagai masalah muncul satu per satu. Dan satu per satu itu pun patch-patch baru diterapkan. Terus terang saya cukup kecewa dengan proses yang sekarang sedang saya jalani dalam men-support data warehouse pada platform baru ini. Ya sudahlah, sigh…

Oia, rencananya dalam waktu dekat apa yang telah dikerjakan dalam hampir setahun ini akan digantikan dengan pendekatan data model baru, 3rd normal form, produk dari platform tersebut. Dulu sempat seru dibahas, namun karena mentok di kapasitas hardware maka data model 3rd normal form ditunda dulu. Entah apa yang menjadi pertimbangan, saya tidak dilibatkan dalam projek ini. Ya sudah, jangan minta tolong teknikal lagi ke saya atau tanya minta penjelasan tentang projek yang hampir setahun ini, semua ada di dokumen.

Data warehouse dengan pendekatan 3rd normal form??

Mungkin saya adalah satu-satunya orang yang ada dalam tim tersebut yang tidak begitu percaya dengan pendekatan ini dapat diterapkan. Dan untuk pemikiran ini ternyata saya tidak sendirian, Matt Casters dari Pentaho juga memiliki pandangan serupa:

After all these years, after sooooo many Kimball modelling success stories, no slowly changing dimensions and stars are being built. There is always one hot-shot in every organisation that will claim they “need it to be 3rd normal form”. In all (100% and at least 10) of the emergency “build it now or we’re dead” cases that I have experience with, there was no real data warehouse in place.

Semoga pandangan saya salah.

Iklan

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?

Sudah cukup lama tidak menulis artikel mengenai IT atau Information Technology, mau saya coba mulai lagi dengan artikel ringan mengenai fenomena tingkah laku orang IT di kebanyakan perusahaan. Sindrom atau gejala Santa Klaus pada orang IT.

Sebuah fenomena yang terjadi antara hubungan entitas IT dan entitas  bisnis. Entitas IT telah menjadi pengurus atau pengelola sumber daya IT. Sedangkan entitas bisnis telah menjadi peminta-minta, meminta agar urusan atau pekerjaan mereka menjadi lebih mudah, nyaman dan menguntungkan. Karena entitas IT memiliki kontrol pada sumber daya IT maka dengan segala upaya agar semua permintaan dapat terpenuhi. Fenomena inilah yang disebut sebagai sindrom Santa Klaus.

Namun sayangnya entitas IT hanya bisa memberikan berdasarkan kebutuhan yang paling mudah dipenuhi. Dengan berkembangnya kompleksitas bisnis, permintaan entitas bisnis akan semakin kompleks dan beragam. Di sinilah momen di mana entitas IT sudah tidak mampu lagi menjadi Santa Klaus. Entitas bisnis sudah tidak lagi bisa tersenyum puas dan senang terhadap performa entitas IT. 

Fenomena ini terjadi karena entitas IT terhadap entitas bisnis berfokus pada nilai kepuasan entitas bisnis. Apakah ini salah? Tidak, namun terkadang bisa jadi salah.

Dalam studi kasus data warehouse, dengan fokus seperti di atas, entitas IT memiliki kecenderungan melakukan metodologi arsitektur “dump and run”. Banyak sekali perusahaan yang memanfaatkan teknologi data warehouse menggunakan pendekatan ini. Bahkan kebanyakan skripsi atau tugas besar kuliah S1 pun arsitektur ini sangat populer.

Fact and Dimensional in Point of Sales (Data Warehouse Toolkit, Ralph Kimball, Page 22)

Oke, kita punya desain Operasional Data Store dan spesifikasi log dari transaksi. Selanjutnya mendesain arsitektur data warehouse menggunakan info tersebut. Pendekatan ini sangat umum terjadi. 

Permasalahan akan muncul ketika dihadapkan sebuah log transaksi yang memiliki volume luar biasa (kira-kira 1 hari berjumlah lebih dari 10 GBytes). Arsitektur data ware house sudah dibuat, namun bagaimana menjustifikasi kebutuhan terhadap hardware maupun software yang mampu memberikan performa terbaik kepada entitas bisnis? Padahal data warehouse ini sendiri belum memberikan keuntungan yang nyata terhadap perusahaan (karena memang belum berjalan). Kalau pun sudah berjalan, apakah entitas bisnis akan menggunakan semua data tersebut. Tidak semua data yang disimpan merupakan informasi yang dapat memajukan perusahaan, lalu kenapa terus saja disimpan di sana? Bukankah dengan tidak menyimpannya maka IT dapat mengefesiensikan storage dari data warehouse.

Jadi seharusnya apa fokus dari entitas IT terhadap entitas bisnis? Dan metodologi apa yang tepat diimplementasikan untuk data warehouse yang memiliki volume data luar biasa?


Categories

Archives

My Bookmarks