Lingkungan Pengembangan dan Produksi Terpisah di Snowflake

Dalam dunia pengembangan perangkat lunak, konsep lingkungan pengembangan dan produksi adalah hal mendasar. Lingkungan pengembangan adalah ruang di mana para pengembang bekerja pada fitur-fitur baru atau memperbaiki bug, menguji perubahan mereka tanpa memengaruhi sistem "produksi" atau lingkungan aktual yang berjalan. Pemisahan ini membantu memastikan stabilitas dan keamanan lingkungan produksi dengan mencegah kode yang tidak diuji atau berpotensi tidak stabil mencapainya.

Lingkungan terpisah juga sangat penting dalam pengelolaan data dan platform data warehouse seperti Snowflake. Memiliki lingkungan terpisah untuk pengembangan, pengujian, dan produksi memungkinkan tim untuk bereksperimen dengan data, menguji kode baru, dan menerapkan perubahan tanpa mengganggu database produksi yang berjalan. Di Snowflake, hal ini biasanya melibatkan pembuatan database atau akun yang berbeda untuk setiap lingkungan.

Satu Database untuk Setiap Lingkungan

Salah satu pendekatan untuk lingkungan terpisah di Snowflake adalah menggunakan satu akun Snowflake dan membuat satu database untuk setiap lingkungan. Dalam struktur ini, Anda akan membuat database seperti DEV_MY_DATABASE, TEST_MY_DATABASE, dan PROD_MY_DATABASE untuk lingkungan pengembangan, pengujian, dan produksi, secara berturut-turut.

Membuat database terpisah untuk setiap lingkungan memberikan batas yang jelas antara mereka, mengurangi risiko manipulasi data secara tidak sengaja di lingkungan yang salah. Selain itu, ini menawarkan konvensi penamaan yang intuitif, membantu tim dengan mudah mengidentifikasi dan beralih antara database.

Satu Skema untuk Setiap Lingkungan

Pendekatan alternatif adalah memiliki satu database dengan skema terpisah untuk setiap lingkungan. Dalam skenario ini, Anda mungkin memiliki MY_DATABASE dengan skema DEV_MY_SCHEMA, TEST_MY_SCHEMA, dan PROD_MY_SCHEMA.

Membuat skema terpisah untuk setiap lingkungan dalam satu database dapat membantu menjaga data terorganisir dan dapat diakses. Setiap skema berfungsi sebagai "namespace" terpisah dalam database, memungkinkan lingkungan yang berbeda untuk berdampingan tanpa saling mengganggu.

Namun, ada kekurangan signifikan dalam pendekatan ini. Ada risiko menjalankan kode pengembangan pada skema produksi secara tidak sengaja, yang dapat menyebabkan masalah data yang serius. Selain itu, mengamankan setiap skema bisa menjadi rumit dan rentan terhadap kesalahan. Oleh karena itu, metode ini umumnya tidak disarankan kecuali tim tersebut sangat disiplin dan berpengalaman dalam mengelola keamanan data pada tingkat skema.

Konvensi Penamaan Skema

Konvensi penamaan yang dipikirkan dengan baik membuat lebih mudah bagi para pengembang, analis data, dan anggota tim lainnya untuk memahami tujuan dari suatu skema hanya dengan sekilas.

Pertimbangkanlah awalan-awalan berikut untuk nama skema:

• LND
  Untuk menunjukkan skema "landing" yang digunakan untuk menyimpan data yang baru ditampung.
• RAW
  Untuk mengindikasikan area staging mentah di mana data pertama kali tiba sebelum proses atau transformasi apa pun.
• INT
  Untuk menandai area integrasi di mana data mentah digabungkan dan dibersihkan sebelum analisis.
• MRT
  Untuk menandakan data mart yang menyimpan data yang terkonfirmasi dan telah dibersihkan siap untuk pelaporan.

Awalan-awalan ini memberikan kejelasan tentang peran skema dalam siklus hidup data. Meskipun contoh-contoh ini hanya representasi umum dalam pengelolaan data warehousing, mereka dapat menjadi titik awal yang baik untuk merancang konvensi penamaan skema Anda sendiri.

Satu Akun untuk Setiap Lingkungan

Pendekatan Satu Akun untuk Setiap Lingkungan mungkin cocok untuk beberapa sistem yang sangat besar karena mempertahankan isolasi yang ketat. Namun, pendekatan ini memiliki kekurangan signifikan:

• Manajemen Data Duplikat
  Ketika setiap lingkungan benar-benar independen, masing-masing harus dikelola secara terpisah, yang meningkatkan beban kerja administrator database. Mengelola data duplikat di antara akun menjadi lebih sulit, yang berpotensi menyebabkan inkonsistensi dan redudansi.

• Penanganan Login Terpisah
  Setiap lingkungan akan memerlukan login dan kata sandi terpisah. Hal ini meningkatkan beban administratif dan berpotensi memperlambat operasi karena pengguna harus mengelola beberapa set kredensial.

• Tantangan dalam Penclonan Data
  Salah satu kekurangan serius dari memiliki akun terpisah untuk setiap lingkungan adalah ketidakmampuan untuk dengan cepat mencloning data di antara akun-akun tersebut. Ketidakmampuan ini membuat tugas pengelolaan data, terutama saat mentransfer data dari satu lingkungan ke lingkungan lain, menjadi lebih sulit.

• Isu Duplikasi Penyimpanan
  Karena tidak memungkinkan mencloning data di antara akun-akun, data harus disalin secara fisik dan dengan demikian terduplikasi di antara lingkungan. Duplikasi ini tidak hanya memakan ruang penyimpanan yang berharga tetapi juga dapat menyebabkan inkonsistensi data jika data tidak disinkronkan dengan benar di semua lingkungan.

Referensi

https://www.analytics.today/blog/snowflake-accounts-best-practice
https://www.propeldata.com/blog/how-to-set-up-development-and-production-environments-in-snowflake