Cara Membangun Platform Data Lakehouse yang Dapat Diskalakan dan Hemat Biaya

Selama dekade terakhir, kami telah beralih dari data warehouse yang kaku ke data lake yang fleksibel dan, baru-baru ini, ke arsitektur lakehouse yang menjanjikan kombinasi terbaik dari keduanya.

Namun, perpindahan dari satu generasi platform data ke generasi berikutnya terbukti lebih sulit dari yang diperkirakan. Mereka yang sudah menjalani perjalanan ini menemukan tantangan dan mengulangi kesalahan dengan membawa pola desain lama ke sistem baru.

Setelah membantu banyak organisasi merancang dan menskalakan platform data modern, saya telah melihat bahwa kesuksesan tidak bergantung pada tools, tetapi pada disiplin. Artikel ini adalah panduan praktis, cara bertransisi secara efektif, apa yang harus dihindari, dan bagaimana menerjemahkan pilihan teknis menjadi nilai bisnis yang terukur.

Mengapa Sejarah Murni Big Data Tidak Lagi Berguna

Jika kita melihat ke belakang, gerakan big data dimulai dengan mimpi penyimpanan tak terbatas dan eksperimen tanpa akhir. Sekitar pertengahan 2010-an, perusahaan mulai mengumpulkan setiap kemungkinan log, klik, dan transaksi, yakin bahwa volume saja akan membawa wawasan. Dalam praktiknya, keyakinan ini hanya menciptakan lebih banyak kompleksitas. Data lake muncul sebagai penerus yang modis dari warehouse, namun sebagian besar dari mereka segera menjadi data swamp, tempat di mana informasi masuk dengan mudah tetapi jarang kembali dalam bentuk yang dapat digunakan.

Pada tahun 2022, industri telah matang, dan pertanyaan mulai berubah. Tim tidak lagi bertanya berapa banyak data yang dapat mereka simpan, tetapi bagaimana mereka dapat mempercayai dan menggunakan apa yang sudah mereka miliki. Tantangan sebenarnya saat ini bukan kapasitas tetapi governance, bukan ingestion tetapi interpretasi.

Pelajaran kunci di sini sederhana. Mengumpulkan lebih banyak data tidak membuat perusahaan menjadi data driven. Yang benar-benar penting adalah memahami data, mempertahankan governance yang tepat, dan menggunakannya secara efisien.

Saya merekomendasikan untuk mendefinisikan kepemilikan untuk setiap dataset, menetapkan kebijakan retensi dan kualitas yang jelas, dan memfokuskan upaya engineering pada data yang secara langsung mendukung keputusan bisnis. Tanpa fondasi ini, bahkan lakehouse yang paling canggih akhirnya berubah menjadi swamp modern.

Lakehouse sebagai Titik Balik

Munculnya lakehouse mencerminkan pergeseran ini. Alih-alih memilih antara performa dan fleksibilitas, model lakehouse menggabungkan keduanya. Pada intinya, ia menggunakan penyimpanan cloud yang murah dalam format seperti Delta atau Iceberg, diperkaya dengan metadata dan jaminan transaksional. Hasilnya adalah sistem yang biayanya semurah lake dan berperilaku seperti warehouse saat di-query.

Ini penting bagi pemimpin bisnis karena menghilangkan trade-off konstan antara penyimpanan murah untuk data historis dan sistem mahal untuk analitik live. Saya selalu menyarankan memposisikan lakehouse Anda bukan sebagai pengganti untuk segala hal lainnya, tetapi sebagai fondasi bersama yang memungkinkan analitik tradisional dan machine learning dalam satu lingkungan.

Dalam lakehouse, lingkungan yang sama dapat mendukung dashboard untuk CFO, model machine learning yang memprediksi perilaku pelanggan, dan query ad hoc dari analis produk. Data tidak lagi diduplikasi di seluruh sistem, yang membuat governance lebih sederhana dan memungkinkan optimisasi biaya terjadi secara alami.

Tantangan Struktural dan Governance dalam Adopsi Data Lakehouse

Ketika perusahaan beralih dari data warehouse klasik atau data lake ke arsitektur lakehouse yang lebih fleksibel, transisi tersebut jarang berjalan mulus. Banyak tim menyalin struktur yang ada dari warehouse lama ke lingkungan baru tanpa memikirkan kembali tujuannya. Hasilnya adalah munculnya data silo, dengan kata lain, fragmentasi. Satu versi data ada di warehouse, yang lain di lake, dan yang ketiga di suatu tempat di antara keduanya. Hindari ini dengan mendesain ulang skema untuk lakehouse dari awal. Model data berdasarkan pola akses dan kebutuhan konsumen daripada logika warehouse lama.

Masalah berulang lainnya adalah normalisasi. Apa yang saya maksud dengan itu? Warehouse dibangun pada struktur yang ketat dan sangat dinormalisasi dengan puluhan tabel yang saling terhubung. Ketika ini disalin langsung ke lake, setiap query memerlukan hutan join. Performa runtuh, engineer menyalahkan infrastruktur, dan proyek kehilangan kredibilitas. Sebaliknya, denormalisasi di mana ini membantu performa dan tempatkan entitas terkait lebih dekat bersama untuk meminimalkan shuffle. Perlakukan desain performa sebagai bagian dari pemodelan data, bukan optimisasi kemudian.

Governance dan kontrol sangat penting. Dalam data lake, sering kali ada sedikit pengawasan karena tim bekerja langsung dengan file. Dalam warehouse, aturan ketat berlaku seperti keamanan tingkat baris, akses berbasis peran, dan audit trail yang terperinci. Lakehouse harus mencapai keseimbangan dengan memastikan keterbukaan tanpa kehilangan akuntabilitas. Anda harus mengimplementasikan akses berbasis peran dan pelacakan lineage sejak awal. Governance bekerja paling baik ketika tumbuh bersama platform dan menjadi fondasi kepercayaan.

Performa juga bergantung pada desain yang cerdas. Warehouse tradisional mengandalkan indexing otomatis, tetapi dalam lakehouse efisiensi berasal dari partitioning atau liquid clustering, caching, dan memilih format file yang tepat untuk analitik. Saya merekomendasikan memperlakukan strategi partitioning dan layout file sebagai warga kelas satu dalam arsitektur Anda.

Optimisasi biaya adalah janji kunci lain dari lakehouse, tetapi tidak datang secara otomatis. Meskipun penyimpanan cloud murah dan analitik dapat diskalakan naik atau turun sesuai kebutuhan, keuntungan ini sering kali diimbangi oleh desain data yang buruk dan pertumbuhan yang tidak terkontrol. Anda harus secara aktif mengelola siklus hidup dataset dan menghapus salinan yang tidak digunakan. Jika proses ini diabaikan, biaya cloud akan meningkat secara diam-diam dari waktu ke waktu.

Optimisasi Biaya sebagai Aturan Nomor Satu

Saya ingin fokus lebih detail pada optimisasi biaya, karena ini adalah salah satu keunggulan utama dari arsitektur lakehouse.

Salah satu cara utama arsitektur lakehouse mengurangi biaya adalah dengan meminimalkan shuffle, yaitu pergerakan data antar sistem atau node pemrosesan. Untuk mencapai ini, selalu desain data Anda sehingga entitas terkait disimpan bersama.

Dengan menyimpan semua data di satu tempat dan menyimpan entitas terkait berdekatan, lakehouse menghilangkan kebutuhan untuk join berlebihan dan transfer data. Ketika kita melakukan analitik, misalnya saat membangun model machine learning untuk analisis pelanggan, kita dapat menggunakan data historis dan transaksional real tanpa menyalin atau memindahkannya antar sistem.

Prinsip kunci lainnya yang memungkinkan optimisasi biaya adalah pemisahan storage dan compute. Penyimpanan data dan pemrosesan data menskalakan secara independen berdasarkan permintaan aktual. Kita hanya membayar untuk resource yang kita gunakan daripada memelihara sistem berkapasitas tetap yang besar. Penyimpanan tetap murah dan dapat diskalakan, dan daya komputasi dapat ditingkatkan atau dikurangi saat dibutuhkan. Fleksibilitas ini mengarah pada biaya infrastruktur yang lebih rendah dan operasi data yang lebih efisien. Selalu mulai dari yang kecil dan biarkan autoscaling melakukan tugasnya. Pantau penggunaan dan pahami pola workload Anda sebelum berkomitmen pada kapasitas yang dipesan.

Cluster auto-scaling lebih lanjut membantu mengontrol biaya. Workload machine learning membutuhkan resource komputasi di cloud, mesin virtual dengan memori dan daya pemrosesan mirip dengan komputer biasa. Di masa lalu, perusahaan membeli atau menyewa server fisik di muka dan menjalankan proses pada kapasitas tetap tersebut. Di cloud, kita membayar untuk komputasi berdasarkan penggunaan aktual, per unit waktu dan per jumlah resource. Saya sangat merekomendasikan untuk memulai dengan ukuran cluster minimal, mengamati perilaku scaling, dan menetapkan batas atas untuk mencegah biaya yang tidak terkendali.

Memilih Pendekatan Arsitektur yang Tepat

Mari kita bicara tentang arsitektur lakehouse. Dalam banyak hal, desainnya bergantung pada bagaimana kita menyusun model data. Pendekatan yang paling umum dan efektif adalah arsitektur berlapis, atau medallion, di mana setiap lapisan melayani tujuan tertentu dan mendukung berbagai jenis pengguna dan workload.

— Lapisan pertama, sering disebut raw atau bronze, adalah salinan langsung dari data sumber. Ini terutama melayani kebutuhan teknis dan hanya disimpan untuk periode singkat untuk memungkinkan pemrosesan ulang cepat saat dibutuhkan. Ini harus diperlakukan sebagai penyimpanan sementara.

— Lapisan kedua, atau lapisan normalisasi, berisi data yang dibersihkan dan terstruktur, kadang-kadang digabungkan dengan tabel lain seperti pengguna dan pesanan. Di sinilah model machine learning sering dilatih. Praktik terbaik adalah mengotomatiskan validasi data dan penegakan skema pada tahap ini. Mempertahankan konsistensi lebih berharga daripada memproses volume data yang besar.

— Lapisan terakhir, yang dikenal sebagai lapisan gold, adalah tempat data teragregasi berada. Dashboard dan tool BI seperti Tableau atau Power BI biasanya terhubung ke lapisan ini untuk mengakses metrik dan visualisasi yang siap. Namun, tidak semuanya dapat dipra-kalkulasi.

Setiap lapisan memiliki tujuan, dan bersama-sama mereka memungkinkan machine learning dan business intelligence untuk berkembang.

Anda harus menyelaraskan strategi pelapisan Anda dengan pola konsumsi. Data scientist biasanya bekerja dengan lapisan silver, dan eksekutif mengharapkan jawaban dari lapisan gold. Fleksibilitas adalah kekuatan sejati dari lakehouse, kemampuan untuk melayani berbagai audiens tanpa membangun dan memelihara berbagai sistem terpisah.

Wawasan dari Lapangan

Jika saya mendesain dari awal, saya akan melakukan beberapa hal secara berbeda dari bagaimana industri mendekati data di masa lalu.

Di bawah ini adalah pelajaran yang telah saya pelajari dari implementasi nyata dan apa yang sekarang saya rekomendasikan.

1. Mulai dari kecil, kirim cepat

Memigrasikan semuanya sekaligus tidak selalu optimal. Perusahaan sering mencoba untuk lift dan shift terabyte data ke sistem baru, hanya untuk menemukan bahwa tidak ada yang menggunakannya. Jalur yang lebih baik adalah memulai dengan satu use case yang memberikan nilai bisnis yang jelas, seperti mesin rekomendasi, penetapan harga dinamis, atau model retensi pelanggan. Kesuksesan di area itu memberikan kredibilitas dan blueprint untuk scaling.

1. Terjemahkan persyaratan bisnis lebih awal

Saya akan menerjemahkan persyaratan bisnis ke persyaratan teknis sedini mungkin. Jika laporan perlu memfilter berdasarkan wilayah, persyaratan itu menyiratkan partitioning berdasarkan wilayah di tingkat penyimpanan. Jika analis mengharapkan pembaruan near real time, itu mendorong keputusan tentang indexing atau caching. Tanpa terjemahan ini, teknologi menjauh dari tujuan bisnis dan kepercayaan terkikis.

1. Sesuaikan teknologi dengan kemampuan organisasi

Saya akan selalu mencocokkan teknologi dengan kemampuan organisasi. Perusahaan dengan budaya engineering yang kuat mungkin lebih memilih komponen open source dan kontrol maksimum. Bisnis dengan resource teknis yang terbatas mungkin lebih baik dilayani oleh layanan terkelola yang mengekspos antarmuka SQL kepada analis. Tidak ada solusi universal, yang penting adalah menyelaraskan ambisi dengan kapasitas.

Akhirnya, saya akan menantang asumsi bahwa lakehouse hanyalah lake yang lebih baik. Kenyataannya, ini adalah paradigma yang berbeda. Ini mewarisi beberapa fitur dari lake dan warehouse, tetapi bukan pengganti untuk setiap use case. Workload transaksional frekuensi tinggi, misalnya, mungkin masih memerlukan sistem khusus. Mengenali batasan ini mencegah kekecewaan dan memastikan bahwa lakehouse digunakan di mana ia benar-benar unggul.