Copy and Paste

Anda bebas mengambil content blog ini, tapi mohon sebutkan alamat blog ini dalam tulisan Anda.

You are free to copy the content of my blog. However, please let your readers know my blog as your source.

Sabtu, 31 Maret 2018

Implementasi Data Vault Ketika Liburan

Jika pekerjaan membebani sedemikian rupa, sering kali hidup kita menjadi tidak imbang. Boleh jadi proyek pengembangan properti kita bikin pusing sejak membuat gambarnya. Setelah itu pendanaan bikin kita bolak balik depresi. Saat pekerjaan yang sesungguhnya bergulir, yaitu konstruksi, waktu tidur semakin dipepet. Pagi harinya kita butuh lebih banyak kopi dan doping.

Syukurlah tiga tahun terakhir saya beruntung punya kesempatan off dari pekerjaan. Perjalanan ibadah atau sekedar melancong menjadi mimpi lama yang terwujud. Sebenarnya perjalanan bisnis bisa juga punya efek rekreasi. Tapi kerja tetap kerja. Kita butuh waktu off untuk mengasah gergaji kita. Melihat keindahan dan kebesaran alam. Terlebih lagi Penciptanya. Melihat ragam budaya, sejarah, dan bahasa. Membina lagi hubungan agar lebih positif. Tentu saja dengan aktivitas fisik harian ribuan langkah dan “puluhan lantai” atau ratusan meter elevasi.

Lima belas tahunan yang lalu, saya terlibat dalam proyek pengembangan data warehouse. Sebelumnya saya sudah bereksperimen dengan proyek OLAP, sambil belajar dari buku Ralph Kimball, The Data Warehouse Toolkit. Pendekatan Kimball terkesan sederhana. Memang itu yang jadi sasaran beliau. User tidak butuh kompleksitas, kata beliau dalam suatu seminar di Jakarta sekitar tahun 1997. Model star schema adalah yang cocok untuk pengguna. Memang begitu...

Namun demikian, mengimplementasikan pendekatan star schema bisa jadi cerita lain, tergantung skala pengembangannya. Jika skalanya kecil, pendekatan ini paling baik. Pengalaman saya lima belas tahunan yang lalu menunjukkan proyek EDW dengan banyak subyek area - katakanlah puluhan tabel fakta dengan dimensi antara lima puluh sampai seratus atau bahkan lebih (jangan bahas dulu variasi kompleksitas dimensi dan tabel fakta - memakan waktu yang lama. Tiga tahun! Sakit kepala bertambah ketika kami sadar kebutuhan user sudah berubah selama tiga tahun itu. Proyek lanjutan untuk penyesuaian EDW yang sudah dibangun tidak dapat dikatakan sederhana. Conformed dimensions sulit dijaga. Akhirnya harus kompromi. Hasilnya adalah unconformed conformed dimensions

Liburan? Ah... situasi sulit dalam pengembangan dan enhancement EDW bikin liburan ga nyaman. Itupun kalau sempat. Kritik dan ketidakpuasan user terbayang-bayang terus. Apakah ini memang harus terjadi? Terjadi terus? Tentu saja tidak! Ada cara bekerja yang lebih cerdas, efektif, dan efisien. Pengguna bisa happy. Kita juga bisa. Coba deh bayangkan jalan-jalan ke tempat ini, sementara EDW berbasis Data Vault dari Dan Linstedt, yang sudah berkali-kali kita deploy tiga tahun terakhir dengan time to market yang mengesankan, berjalan lancar. Liburan makin menyenangkan karena proyek-proyek di tangan tetap terkendali dengan baik. Makasih ya, Laksmi.



Bagaimana? Mengesankan bukan? Gambar di atas saya ambil di Pamukkale, Turki, baru-baru ini. Sumber air panas menjadi sebab tempat ini menarik bagi bangsa Helenik untuk membangun Hierapolis. Air panasnya masih mengalir hingga kini, dan saya sempat merasakan hangatnya ketika merendamkan kaki di alirannya. Air panas ini juga mengaliri kontur yang berbukit-bukit membentuk travertine. Atau barangkali kisah penganut Nasrani bersembunyi di Goreme dari bangsa Romawi mampu menginspirasi kita dengan nilai kesabaran dan kecerdasan dalam membangun kota dan hunian yang aman dan reliable, seperti gambar-gambar berikut.



Kembali dari perjalanan yang luar biasa ini, saya masih terbayang dengan peradaban masa lalu yang sangat mencengangkan. Kemudian melewati jalan-jalan mulus antar dan di dalam kota-kota di Turki menambah keyakinan bagaimana penataan yang benar mampu membangkitkan kembali peradaban di masa sekarang menyongsong masa depan, setara dengan bangsa-bangsa maju lainnya.

Kota-kota yang bersih dan tertata rapi mengingatkan saya pada hubs di pemodelan DV. Jalan-jalan yang menghubungkan antar kota atau yang menghubungkan satu jalan dengan lainnya mengingatkan saya pada links. Baik kota maupun jalan memiliki properti detilnya masing-masing. Membuat jalan baru tidak harus membongkar jalan dan jembatan yang sudah dibangun sebelumnya dengan benar. Mengembangkan kota tidak berarti harus membongkar terlebih dahulu apa yang sudah dikembangkan sebelumnya dengan benar. Semua ini membuktikan manusia mempunyai kemampuan menata dengan baik, asalkan tahu cara-cara menata yang benar tersebut. Secara top down dan sekaligus bottom up, dengan mengkombinasikan kebaikan dari keduanya. Kalau ga percaya, tanya ke Yudha. Kami telah melewati perjalanan ini bersama. Implementasi EDW berbasis DV maksudnya, bukan ke Turki, tapi kayaknya dia tertarik jalan-jalan ke Turki.

Saya sih berpikir positif bahwa pembaca percaya dengan kehebatan Data Vault. Setidaknya mulai percaya. Itu langkah awal keberhasilan implementasi EDW saat liburan. Kuncinya? Buka pikiran dan belajar dari ahlinya, serta... jangan malas baca! Jangan hanya mengandalkan pendekatan star schema (star schema punya nilai tambahnya sendiri; don’t get me wrong!) yang terbukti tidak robust untuk membangun EDW - EDW sebagai saksi sejarah kehidupan. Saya pinjam istilah saksi sejarah ini dari Ahmal, yang selalu mampu menjawab tantangan pekerjaan. Tentu saja dengan sedikit penyesuaian mengikuti konteks tulisan

Selengkapnya.....

Jumat, 23 Februari 2018

Data Warehouse di Hadoop

Sejak teknologi Hadoop ngetren beberapa tahun lalu, banyak praktisi yang berpikir untuk menerapkan data warehousing dengan teknologi big data ini. Bahkan muncul juga istilah baru (yes, another buzzword) data lake sebagai pengganti atau pelengkap data warehouse. Di kantor kami, ada juga wawasan ke sana, tetapi masih belum betul-betul bergulir implementasinya.

Sebelum kita menjajaki lebih jauh kemungkinan penerapan data lake atau apapun istilahnya dengan menggunakan Hadoop, perlu kita ketahui alasan atau latar belakang munculnya gagasan ini. Ada beberapa alasan. Yang pertama, banyak perusahaan yang menerapkan data warehousing, setelah sukses pengembangan dan implementasinya di tahun-tahun pertama, menghadapi masalah skalabilitas. Pengalaman yang berulang kali terjadi, saya dengar, adalah keharusan untuk merombak atau mengembangkan ulang data warehouse setelah tiga sampai lima tahun. Tentunya konsekuensi biayanya bikin hati miris. Opsi penggunaan teknologi alternatif NoSQL seperti Hadoop untuk mengganti data warehouse yang lama menjadi menarik.

Kedua, teknologi Hadoop adalah teknologi open source yang dipersepsi lebih murah dibandingkan RDBMS seperti katakanlah Oracle dan MS SQL, meskipun pada akhirnya ada biaya yang tetap harus dikeluarkan jika perusahaan membutuhkan support yang dapat diandalkan, misalnya dengan men-subscribe Cloudera atau Hortonworks atau yang lain. Biaya ini tidak terhindarkan, tapi tetap persepsinya lebih murah. Yang bikin masalah adalah Hadoop tidak mengenal fitur update, padahal dalam beberapa hal data warehousing membutuhkan update. Untuk mengatasinya dibutuhkan pendekatan yang berbeda dari sebelumnya. Muncullah beberapa pendekatan baru, di antaranya data lake.

Ketiga, perusahaan membutuhkan segala jenis data, baik yang terstruktur, setengah terstruktur, maupun tidak terstruktur sama sekali. RDBMS tidak pas untuk mengolah data yang setengah terstruktur, apalagi yang tidak terstruktur sama sekali. Teknologi Hadoop dengan schemeless repository punya keunggulan signifikan dibandingkan RDBMS. Pada ujung yang paling ekstrem, katanya, kita bisa cemplungkan segala sesuatu ke dalam Hadoop tanpa harus peduli dengan skema atau struktur tabelnya. Skema baru dibutuhkan ketika membaca data, tidak pada saat menulis data ke Hadoop. Tentu saja kita mesti hati-hati dengan pandangan ekstrem yang too good to be true seperti itu.

Keempat, teknologi Hadoop memungkinkan proses yang sangat paralel dengan mendistribusikan beban pemrosesan ke distributed nodes yang secara mandiri masing-masing memiliki computing power dan storage sekaligus. Karena sifatnya terdistribusi ke simpul-simpul mandiri yang sendirinya memiliki computing power dan storage sekaligus, cluster Hadoop tidak butuh banyak data movement. Itu salah satu sebabnya Hadoop bisa sangat cepat. Di sini kita tidak akan mengelaborasi lebih dalam mengenai arsitektur Hadoop, mekanisme kerja, dan jeroannya. Cukuplah pembaca mencari sendiri di internet artikel-artikel yang hampir tidak terbatas mengenai hal teknis ini. Sebetulnya kemampuan pemrosesan secara paralel ini ada juga di RDBMS seperti Oracle, tapi jika kita menerapkan Hadoop, kita tidak membutuhkan server high end. Ini artinya lebih murah. Jika suatu saat diperlukan tambahan kapasitas, kita tinggal menambah sejumlah server mid range atau bahkan bisa juga low end ke cluster Hadoop yang telah kita miliki. Skalabilitas yang mengagumkan! 

Kembali pada gagasan membuat data warehouse di atas Hadoop, saya ingin menceritakan sedikit mengenai pemodelan dan metodologi Data Vault, saat ini sudah DV 2.0, yang diciptakan oleh Dan Linstedt. Meskipun tidak pernah ketemu langsung dengan beliau, saya berinteraksi intensif dengan teman-teman yang memiliki sertifikat dari Dan Linstedt, sebagiannya anggota atau mantan anggota tim saya, sebagiannya lagi tim Hasnur Ramadhan. Hasnur Ramadhan adalah satu dari sedikit orang Indonesia yang memiliki sertifikasi DV. Bahkan dia berkali-kali memperbaharui sertifikatnya. Tidak heran kalau dia dekat dengan Dan Linstedt.

Dari interaksi dengan orang-orang hebat tersebut dan belajar dari materi Data Vault yang dibawa oleh Ginanjar dan Laksmi waktu dulu mereka berguru ke Dan Linstedt di Colorado ataupun materi yang tersedia di internet, saya dapat memahami metodologi DV ini secara konseptual. Malah pada kondisi tidak tersedia bahan belajar yang cukup, somehow I am capable of connecting the dots. Pemikiran pribadi sering saya diskusikan dengan tim saya, di antaranya Yudha dan Ahmal, dua anak muda berbakat yang memampukan kami menerapkan Data Vault di kantor, tentu saja pada beberapa hal dibantu dan terinspirasi oleh Pak Hasnur dan timnya yang hebat - ketika mereka menjadi konsultan kami di 2015 di proyek Julia.

Baru-baru ini, akhir Januari, Pak Hasnur kasih khabar ke saya. “Lagi di Berlin, ngambil DV 2.0 Bootcamp,” katanya. Tentu saja khabarnya dilengkapi foto berdua Dan Linstedt, yang kelihatan lebih berisi badannya. Saya minta sampaikan salam ke Daniel. Sayang acara sudah selesai dan beliau tidak ketemu lagi dengan Dan Linstedt. Setelah itu, baru berapa hari lalu, Pak Hasnur pamer sertifikat DV 2.0 ke saya lewat pesan WA. Dia juga kasih oleh-oleh gambar arsitektur DV 2.0 terbaru. Dia kemudian menawarkan integrasi DV dengan Cloudera. Kontan aja sifat usil saya muncul. Lantaran tahun 2015 waktu ngobrol dengan Pak Hasnur, saya sudah bilang mau implementasi DV di Hadoop, dan kebetulan saat ini kami memang sedang mencobanya. Saya bilang Pak Hasnur kali ini harus belajar ke kami, tapi dasar dia dari dulu ga mau kalah sama saya. “Ga certified,” katanya! Saya tunjukkan percakapan WA itu ke Yudha dan Ahmal. Kami tertawa-tawa. Lalu salah satunya bilang (bercanda) bahwa itu ofensif. Saya nyantai aja.

Perlu diketahui bahwa DV 2.0 sudah beberapa tahun lalu dipublikasi oleh Dan Linstedt. DV 1.0 jauh lebih awal di tahun 2000-an, yang diciptakannya berdasarkan pengalaman bertahun-tahun sebelumnya menjadi konsultan pengembangan sistem-sistem besar dengan skala terabyte bahkan petabyte. Saya mengikutinya di dunia maya. Saya juga mengikuti Dan Linstedt bubar dengan beberapa rekannya di awal-awal mempromosikan Data Vault. Kemudian dia bermitra dengan orang baru. Pada saat-saat itu, lahirlah DV 2.0.

Terus terang saya mengikuti newsletter dari Dan Linstedt dan rekannya. Beberapa artikel di email dan beberapa video dari "Dan and Sanjay" (ya orang India) saya pelajari. Secukupnya sih, selama saya ada waktu di tengah pekerjaan yang menumpuk. Di tahun 2015 itu, saya sudah tahu dari kiriman email “Dan and Sanjay” bahwa DV 2.0 bisa diterapkan di atas Hadoop. Saya tidak perlu sertifikasi untuk mengatakan bahwa kami akan terapkan DV di atas Hadoop. Saya juga tidak perlu menunggu sertifikasi untuk menerapkan hash key di DV, menggantikan sequence key. Beda dengan Pak Hasnur. Beliau lebih butuh landasan akademik dan profesional. Hal ini bisa dipahami karena beliau adalah konsultan yang jualan di industri.

Mungkin pembaca ada yang ragu juga. Apa memang bisa menerapkan EDW berbasis Data Vault di atas Hadoop? Untuk pembaca yang seperti itu, ada baiknya ikut DV 2.0 Bootcamp atau kelas DV 2.0 lainnya. Jadwalnya sudah dipublikasi. Berdasarkan pengalaman tahun-tahun lalu, penyelenggaraannya tersebar di Amerika, Eropa, dan sedikit di Australia. Di Indonesia? Sayang sekali belum. Kalau Dan Linstedt mau buka kelas di Jakarta, pasti in syaa Allah saya hadir. Malah saya mau traktir dia, tentu saja kalau dia berkenan, dan saya mau pertemukan dia dengan tim saya yang warbiasah.

Pada titik ini, saya ingin menyarankan pembaca yang berencana membuat data warehouse di Hadoop atau membuat data lake, pakailah pemodelan dan metodologi DV 2.0. Data mudah ditata di dalam Data Vault. Menambahkan data baru - apakah hanya kolom baru, atau satu tabel transaksi, atau sekian banyak tabel baru - sangat mudah, tanpa mengganggu tabel-tabel yang sudah ada di DV. Sangat fleksibel! Proses ELT-nya sangat standard dan polanya mudah di-reuse. Kalau ada uang, DWA (Data Warehouse Automation) tools seperti BIReady dan WhereScape akan sangat membantu. Atau pembaca bisa bikin sendiri sistem DWA.

Apakah performance DV akan turun seiring dengan bertambahnya data dan tabel? Tidak, karena DV punya skalabilitas yang tinggi dan mendukung proses yang sangat paralel, terserah mau menggunakan Hadoop atau RDBMS yang mendukung MPP. DV juga sangat sangat sedikit melakukan proses lookup dalam tahapan ELT-nya. Ini tentu mendukung performance yang prima, dan yang tidak kalah penting tidak ada update di dalam proses ELT-nya. Fitur tidak ada update ini yang memungkinkan penerapan DV di Hadoop. Banyak lagi keunggulannya. Kami sudah membuktikannya di tempat kami. Faktanya, penerapan DV di seluruh dunia sangat sangat banyak dan terus tumbuh.

Jika pembaca masih belum percaya dan memilih metode lain atau berusaha membuat sendiri metodenya atau mengabaikan perlunya metodologi sembari mencemplungkan segala sesuatu ke dalam Hadoop, maka bersiaplah untuk membangun data lake tetapi pada akhirnya hanya menghasilkan data swamp! Atau mungkin ada juga yang berpikir persetan dengan Hadoop dan akan tetap menggunakan RDBMS kalau perlu berupa appliance, sembari tetap mengandalkan hanya star schema atau snowflake schema dari Ralph Kimball. Untuk yang memilih jalan ini, siap-siap saja dalam waktu tiga tahun untuk merombak data warehouse yang sudah dikembangkan, sambil menyalahkan infrastruktur!

Selengkapnya.....

Sabtu, 20 Januari 2018

Dan Linstedt, Data Vault, dan EDW di Kantor Kami

Saya kenal Dan Linstedt lewat dunia maya saja. Dalam pencarian pendekatan yang lebih efektif dalam mengembangkan sistem informasi, data warehouse khususnya, saya ga sengaja berkunjung ke situs tdan.com di mana Dan Linstedt menjadi salah satu penulisnya. Itu sekitar tahun 2008. 

Dia menulis mengenai Data Vault (sekarang sudah DV 2.0) yang diklaimnya mendapat pengakuan dari Bill Inmon, mbahnya data warehouse. Saya sudah kenal Bill Inmon terlebih dahulu yang bersama Claudia Imhoff memperkenalkan konsep data warehouse berupa Corporate Information Factory (CIF). Saya juga sudah kenal terlebih dahulu dengan Ralph Kimball yang pendekatannya kami gunakan dalam mengembangkan EDW di kantor dari 2002 sampai 2007. 

Dapat dikatakan pendekatan Kimball yg kami gunakan cukup berhasil. Kami ga perlu membuat model data top down ideal enterprise-wide untuk mengembangkan EDW. Jadinya bisa cepat menghasilkan. Murah tentu saja. Tapi dengan berjalannya waktu menjadi semakin sulit untuk menambahkan dan mengintegrasikan data baru ke EDW. Penyakitnya yang utama di antara beberapa hal lainnya adalah kesulitan memelihara tabel conform dimensions seiring dengan penambahan subyek area baru. Dan Linstedt menyebut penyakit ini dimensionitis


Sebenarnya sebelum ketemu konsep DV Dan Linstedt, saya menemukan DW 2.0 Bill Inmon terlebih dahulu. DW 2.0 dimaksudkan Inmon sebagai koreksi dari penyimpangan-penyimpangan istilah dalam perkembangan dunia data warehouse. Di 2008, saya minta Laksmi dan Ginanjar mempelajari keduanya: DW 2.0 dari Inmon dan DV (waktu itu sebut saja masih DV 1.0) dari Dan Linstedt.


Kebetulan sekitar tahun 2008 itu, saya tidak lagi in charge dalam pengembangan EDW di kantor. Saya waktu itu dipindah tugas ke QA dan PMO. Kami berusaha mendapatkan buy in terhadap DW 2.0 dan DV. Toh yang mengerjakan adalah kolega kami yang lain. Laksmi dan Ginanjar yang sudah mendapat sertifikasi DV modeling dari Linstedt langsung di Colorado, dengan saya sebagai promotornya, tentunya punya kewajiban moral agar investasi pengetahuan ini tidak sia-sia. 

Apa mau dikata, pembenahan EDW di kantor kami waktu itu tidak bergulir. Pengembangannya stagnan. Operasional EDW yang telah dibangun 2002-2007 terseok-seok. Sampai suatu hari, setelah serangkaian reorganisasi dan dinamika lainnya, tahun 2013 saya ditugaskan kembali menangani EDW di kantor kami. Beruntung divisi baru yang saya pimpin ini diperkuat oleh beberapa kolega lama yang pernah punya eksposur dalam pengembangan EDW sebelumnya, termasuk Laksmi dan Julia.

Saya juga merasa beruntung sekali dengan masuknya dua anak muda cerdas dan berbakat, yg ternyata dari satu sekolahan. Ahmal yang duluan masuk, 2013, kurang lebih berbarengan dengan masuknya saya ke divisi ‘lain sendiri’ itu. Disusul Yudha tahun 2014. Bersama Ahmal, saya berhasil melalui masa survival EDW paling sulit di 2013 dan 2014. Keberhasilan melalui masa paling sulit dengan kondisi morale paling rendah menjadi titik tolak bagi kami untuk menyongsong era baru. 

Selanjutnya, bersama Yudha dan Ahmal, kami berhasil menerapkan DV 2.0 hingga saat ini kami mampu mengembangkan EDW yg sangat modern dengan time to market yang luar biasa. Performance ETL/ELT? Itu juga luar biasa! Penambahan data 250 juta record bisa selesai beberapa jam saja, meskipun hanya dengan server database Oracle menengah. Rencananya mesin database akan kami ganti dengan yang high end, malah Yudha dan Ahmal sedang saya tugaskan untuk bersiap menerapkan DV 2.0 di atas Hadoop, sehingga EDW kami segera masuk ke skala “petabytes and beyond” dengan performance dan skalabilitas yang sangat memuaskan.

Sebenarnya kekuatan dari sisi teknis bukan segalanya, tetapi dalam pengembangan EDW yang ga pernah ada habisnya, kapasitas yang bagus dari sisi teknis merupakan key success factor. Kita dapat menghemat waktu menyelesaikan isu teknis dan dapat mengalokasikan lebih banyak waktu untuk ketemu user. User merasa puas dan yang paling penting “keep coming back” kepada kami. Tentu saja bukan tidak ada masalah sama sekali, tapi masalah dapat diselesaikan, dengan kolaborasi yang baik dan kadang dengan sedikit marah-marah, misalnya pas akhir 2017 kemarin (maaf ya gaes).

Rasa terima kasih tentunya harus juga saya tujukan ke kolega-kolega saya lainnya yang tidak bisa saya sebutkan satu per satu. Dari pihak eksternal, Pak Hasnur Ramadhan dengan tim yang luar biasa juga telah memberikan warna tersendiri dalam warisan kami di divisi yang sekarang ‘menceng dewe’ ini. Bagaimana kisah survival-revival kami mungkin perlu satu buku tersendiri - setidaknya satu artikel tersendiri - untuk menceritakannya. 

O God... I am very grateful for this wonderful experience. 

Selengkapnya.....

addthis

Live Traffic Feed