Pribadi

Bsharre and the Kadisha valley

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).

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?

addiction

Kecanduan Itu Seperti...

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?

Kesan pertama dari Google Chrome, produk Google terbaru yang konon katanya merupakan tipe web browser dengan arsitektur berbeda dengan kebanyakan web browser pada umumnya, yang saya rasakan:

  • Cepat!!
  • Cepat!!
  • Ringan!
  • Halaman terkesan luas.
  • Tampilan simple dan elegan.

Terus terang, saya langsung jatuh cinta pada pandangan pertama. Sepertinya saya akan segera pindah dari Firefox 🙂 Tapi ada satu hal yang membuat saya tidak suka adalah konfigurasi proxy yang menyatu dengan konfigurasi Internet Explorer. Hal ini dikarenakan IE pada notebook kantor saya selalu direset menggunakan proxy default (yang lambat). Padahal saya ingin Chrome menggunakan konfigurasi proxy seperti pada Firefox sehingga saya bisa menggunakan proxy pilihan saya.

Oia, berikut teknologi serta konspirasi terkait dengan Chrome ini:

Membajak yang saya maksud adalah seperti membajakan lagu, perangkat lunak atau film. Dan jargon “Membajak sama saja dengan mencuri” sangat popular dalam kampanye membrantas pembajakan.

Namun, pada kenyataannya membajak tidak sama dengan mencuri. Bisa dilihat pada ilustrasi berikut:

Pembajak tidak sama dengan pencuri

Pembajak tidak sama dengan pencuri

via Ngoprek Web dan PIRACY is not THEFT!

David Beckham juga Manusia

David Beckham juga Manusia

Tidak perlu mengambek begitu dong, Beckham kan juga manusia 🙂

Categories

Archives

My Bookmarks