Semoga dengan bantuan wordpress for android membuat gairah menulisku bangkit kembali.

So, salam jumpa kembali bro and sis blogger sesantero Internet.

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.

Fennec alpha 2

Langsung aja ke TKP di Fennec alpha 2.

Bencana alam di berbagai negara

Ternyata Indonesia tidak sendirian

Teknik 3D-nya patut dicoba neh, siapa tahu ada yang tertipu. Huehuehuehue

Cara Meningkatkan Produktivitas

Masuk akal juga yah?!

Sebuah kisah dari perjalanan Barack Obama 20 tahun lalu. Cerita yang sangat mengharukan. Kita memang tidak bisa memperkirakan apa yang telah kita lakukan dulu akan memberikan perubahan yang sangat besar saat ini.

Bukan karena hal tersebut berarti atau Not that it matters. Sebuah tindakan kebaikan acak yang dilakukan oleh Barack Obama. Dan kisah ini pun langsung menjadi sebuah berita utama harian dari Norwegia.

Bsharre and the Kadisha valley

Pantas saja para wakil rakyat itu ingin sekali melakukan studi banding ke Libanon, seperti dikutip Pribadi dari situs detikNews, Sabtu (4/10/2008).

Tempat wisata lainnya di Libanon -> Lebanon: Switzerland of middle east.

Saya tak akan pernah melakukan tautan balik ke situs Detik. Saya hanya akan menggunakan cara yang sama seperti yang mereka gunakan dalam mengutip berita. Memang mereka pikir mengutip artikel internet sama seperti media cetak!

Oia, saya memang mengutip pada hari Sabtu (4/10/2008), tetapi beritanya itu sendiri sudah ada sejak Jumat (22/08/2008).

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?

Kecanduan Itu Seperti...