Praktik terbaik pengembang di Databricks

Halaman ini menyediakan praktik terbaik untuk siklus hidup rekayasa dan pengembangan data Anda termasuk kontrol versi, manajemen lingkungan, alat pengembang, dan penyebaran terkelola.

Kontrol sumber

Kontrol versi semua file

Otomatisasi deklaratif dibangun berdasarkan gagasan bahwa jika ada sesuatu yang tidak dalam kontrol versi, itu tidak ada. Oleh karena itu, Databricks merekomendasikan agar Anda mengontrol versi hampir setiap file, termasuk:

  • Semua buku catatan dan file sumber (.py, .sql)
  • File konfigurasi bundel (databricks.yml dan penimpaan YAML khusus lingkungan)

Namun, jangan melakukan commit:

  • Buat artefak, seperti .jar atau .whl file. Sebagai gantinya, unggah biner yang dikompilasi ke volume Unity Catalog selama CI. Lihat mengunggah JAR.
  • Token atau kredensial. Gunakan manajemen rahasia tingkat ruang kerja yang didukung oleh manajer rahasia cloud (seperti AWS Secrets Manager atau Azure Key Vault) dan sinkronkan nilai ke dalam cakupan rahasia Databricks. Lihat Manajemen Rahasia.
  • Contoh data lokal dan file yang mengandung PII. Gunakan .gitignore untuk mengecualikannya.

Repositori tunggal

Databricks merekomendasikan agar Anda menggunakan satu repositori untuk semua kode Anda (kode sumber dan file konfigurasi), karena membuat kolaborasi, dan berbagi kode dan praktik terbaik untuk manusia dan AI lebih mudah. Jika Anda memiliki beberapa bundel untuk siklus hidup penyebaran terpisah, simpan dalam satu repositori.

Satu pengecualian untuk rekomendasi repositori tunggal adalah dalam industri yang diatur di mana beberapa repositori diperlukan untuk tujuan kerahasiaan.

Strategi percabangan berbasis batang

Untuk meminimalkan konflik penggabungan dan memastikan cabang utama selalu dalam keadaan yang dapat disebarkan, gunakan strategi percabangan berbasis batang.

Alur kerja sederhana adalah:

  1. Kembangkan secara lokal atau di ruang kerja dan sebarkan ke ruang kerja pengembangan Databricks untuk menguji perubahan.
  2. Buat cabang fitur berumur pendek untuk pembaruan kontrol versi dan sinkronkan perubahan lokal atau ruang kerja Anda secara teratur.
  3. Setelah pengujian selesai, gabungkan cabang fitur ke cabang utama.
  4. CI/CD secara otomatis mendistribusikan cabang utama ke ruang kerja staging dan pengujian otomatis dimulai.
  5. Ketika pengujian penahapan dan pemeriksaan lulus, CI/CD menyebarkan cabang utama ke ruang kerja produksi.

Langkah-langkah ini diuraikan dalam diagram berikut:

Strategi pencabangan CI/CD Bundel Otomatisasi Deklaratif

Konfigurasi ruang kerja

Mengisolasi lingkungan ruang kerja

Mengisolasi lingkungan ruang kerja untuk meminimalkan dampak penyebaran yang gagal. Contohnya:

  • Tim kecil (hingga 5 teknisi data): Mulailah dengan dua ruang kerja (pengembangan dan produksi) dalam satu akun cloud.
  • Tim yang berkembang (5+ insinyur data): Pindah ke tiga ruang kerja (pengembangan, penahapan, dan produksi). Lingkungan staging harus secara fungsional merepresentasikan produksi — dengan konfigurasi bundel, skema, dan integrasi penting yang sama — meskipun diskalakan lebih kecil.
  • Industri yang diatur (perbankan, layanan kesehatan, pertahanan): Mengisolasi ruang kerja dan akun cloud secara fisik untuk mencegah kebocoran data. Mengelola isolasi melalui batas IAM dan Unity Catalog dalam satu akun dimungkinkan tetapi memberikan postur keamanan yang kurang kuat.

Untuk ruang kerja produksi, gunakan komputasi tanpa server dengan kebijakan jaringan jika memungkinkan. Jika tidak, konfigurasikan akun cloud agar menggunakan subnet privat atau VNet dengan egres yang dikontrol secara ketat dan kontrol keamanan jaringan.

Untuk informasi selengkapnya, lihat Kebijakan jaringan berbasis konteks.

Mengisolasi penyimpanan data

  • Gunakan satu metastore Unity Catalog dan buat katalog terpisah untuk dev, staging (jika berlaku), dan production, sesuai dengan tata letak workspace Anda.
  • Gunakan skema pribadi bagi masing-masing pengembang untuk katalog pengembangan dan staging (non-produksi).
  • Ikat katalog produksi dalam ISOLATED mode ke ruang kerja produksi saja. Mengatur mode isolasi katalog untuk ISOLATED memastikan bahwa data produksi tidak dapat dijangkau dari lingkungan pengembangan atau penahapan, bahkan jika identitas salah dikonfigurasi.
  • Gunakan metastore, akun, atau wilayah terpisah hanya untuk organisasi dengan persyaratan peraturan, kedaulatan data, atau multi-wilayah yang tidak dapat dipenuhi oleh isolasi tingkat katalog.

Perlakukan metadata tabel dan kolom sebagai kode

Perlakukan komentar tabel dan kolom sebagai bagian dari kode Anda. Simpan item tersebut dalam file .sql bersama definisi Bundel Otomatisasi Deklaratif Anda, dan terapkan melalui tugas metadata agar definisi yang akurat dan ditujukan untuk bisnis selalu tersedia. Tulis komentar yang menjelaskan apa yang diwakili baris, unit, dan nilai valid dalam bahasa biasa daripada mengulangi nama kolom.

Konfigurasikan skema pribadi

Selama pengembangan, konfigurasikan bundel untuk menggunakan skema pribadi per pengguna, misalnya dev_${user_name}. Hal ini mencegah pengembang menimpa tabel satu sama lain di ruang kerja bersama.

Menggunakan komputasi tanpa server

Gunakan komputasi tanpa server untuk menyederhanakan manajemen kluster dan mengoptimalkan biaya. Lihat Menyambung ke komputasi tanpa server.

Rekomendasi CI/CD

Bundel Otomatisasi Deklaratif untuk CI/CD

Bundel Otomatisasi Deklaratif (sebelumnya dikenal sebagai Bundel Aset Databricks) menawarkan pendekatan terpadu yang kuat untuk mengelola kode, alur kerja, dan infrastruktur dalam ekosistem Databricks dan direkomendasikan untuk alur CI/CD Anda.

Untuk detail tambahan tentang menggunakan bundel untuk alur kerja CI/CD, lihat alur kerja CI/CD di Databricks.

Untuk informasi selengkapnya tentang Bundel Otomatisasi Deklaratif, lihat Apa itu Bundel Otomatisasi Deklaratif?.

Gunakan Terraform hanya untuk sumber daya eksternal

Gunakan Terraform untuk menentukan sumber daya berikut:

  • Sumber daya tingkat cloud dan eksternal
  • Tindakan admin yang tidak boleh dilakukan pengguna yang tidak istimewa, seperti provisi ruang kerja atau konfigurasi jaringan cloud

Gunakan Bundel Otomatisasi Deklaratif untuk semua sumber daya Databricks lainnya.

Manajemen bundel

Membuat bundel kecil

Databricks merekomendasikan pengembangan bundel kecil yang berfokus pada satu bundel besar.

  • Tempatkan semua yang dimiliki oleh satu tim ke dalam satu bundel.
  • Uji dan sebarkan melalui alur CI/CD yang sama yang memiliki siklus hidup dan irama rilis yang sama.
  • Setiap bundel harus mencakup semua lingkungan untuk proyek tertentu (dev, penahapan, produksi) daripada menggunakan bundel terpisah per lingkungan.

Buat bundel terpisah untuk:

  • Produk atau domain yang berbeda, misalnya "Analitik penagihan" dan "Deteksi penipuan"
  • Batas kepemilikan atau izin yang berbeda
  • Beban kerja dengan siklus hidup yang jelas berbeda
  • Kasus di mana Anda memerlukan promosi atau pembatalan independen

Gunakan sync.paths untuk menyinkronkan folder bersama

Saat mengelola beberapa bundel dalam satu repositori, gunakan sync.paths untuk menyinkronkan folder bersama dari luar akar bundel. Ini memungkinkan proyek yang berbeda untuk berbagi folder pustaka umum, seperti ../common, sambil mempertahankan identitas penyebaran terpisah.

Memodelkan dependensi antar-bundel di CI/CD

Ketika Bundel B bergantung pada aset yang dipublikasikan oleh Bundel A, modelkan ketergantungan tersebut di lapisan CI/CD atau orkestrasi Anda alih-alih menggabungkan keduanya ke dalam satu bundel.

  • Jadikan alur kerja penyebaran dan penerbitan Bundel A sebagai prasyarat eksplisit untuk Bundel B. Kawat alur Anda sehingga Bundel B dimulai hanya setelah penyebaran Bundel A berhasil dan semua pemeriksaan validasi yang diperlukan lulus.
  • Teruskan pengidentifikasi atau lokasi aset yang telah dipublikasikan sebagai input pipeline, dan segera hentikan proses jika aset hulu tidak ada. Ini memastikan Bundel B tidak pernah disebarkan terhadap status yang diterbitkan sebagian.

Untuk informasi selengkapnya tentang berbagi bundel, lihat Berbagi bundel dan file bundel.

Template paket kustom

Gunakan templat kustom Declarative Automation Bundles sebagai titik awal bawaan untuk proyek baru agar setiap proyek mewarisi standar pengaman yang sama—izin, penandaan, kebijakan kluster, integrasi CI/CD, dan konfigurasi dasar instance—tanpa perlu setiap tim menyiapkannya dari nol.

Templat harus mengodekan konvensi bersama dan berumur panjang seperti tata kelola, default performa, tata letak lingkungan, dan batas kuota. Hindari logika bisnis khusus aplikasi, rahasia, atau konfigurasi satu kali dalam templat.

Parameterisasi hanya input yang diharapkan bervariasi menurut tim, proyek, atau lingkungan:

  • Project atau nama aplikasi
  • Pengaturan ruang kerja target
  • Nama katalog atau skema
  • Pengenal prinsipal layanan
  • Pengaturan jadwal dan pemberitahuan

Pertahankan batasan platform dan setelan default bersama tetap di dalam templat alih-alih menjadikannya parameter.

Untuk informasi tentang templat bundel kustom dan cara membuatnya, lihat Templat proyek Bundel Otomatisasi Deklaratif.

Merencanakan pembatalan dan perbaikan

Jaga agar bundel tetap cukup kecil sehingga Anda dapat melakukan rollback secara terarah pada satu bundel, alih-alih mengoordinasikan rollback di banyak workload yang tidak terkait.

Selama insiden:

  1. Kembalikan atau gulung balik bundel yang terpengaruh ke versi baik terakhir yang diketahui.
  2. Gunakan hotfix hanya untuk perbaikan yang mendesak dan cakupannya terbatas, yang tidak dapat menunggu alur promosi normal.
  3. Gabungkan perbaikan apa pun kembali ke cabang utama segera setelah validasi sehingga batang pohon tetap menjadi sumber kebenaran tunggal.

Pengembangan umum

Gunakan service principal atau OIDC

Gunakan prinsipal layanan untuk semua otomatisasi nonpengembangan guna melepaskan keterkaitan alur kerja otomatis dari akun pengguna perorangan dan memastikan tugas tetap berjalan ketika pengguna internal keluar dari organisasi. Lihat Service principals.

  • Gunakan prinsipal layanan yang terpisah untuk penerapan dan proses runtime. Perwakilan layanan penyebaran khusus untuk penyebaran bundel harus memiliki akses data minimal. Setiap pekerjaan produksi atau pipeline harus memiliki service principal run-as tersendiri yang cakupannya dibatasi hanya pada data dan sumber daya yang diperlukan oleh beban kerja tersebut. Pemisahan ini memastikan penyebaran tetap aman saat Anda memutar atau mengencangkan izin akses data, dan menghindari perubahan infrastruktur konektor pada akses data produksi.
  • Industri teregulasi: Gunakan Federasi Identitas Beban Kerja (OIDC) untuk CI/CD. Ini menghilangkan rahasia berumur panjang di GitHub Actions atau Azure DevOps. Lihat Mengaktifkan federasi identitas beban kerja di CI/CD.

Menggunakan alat pengembang Databricks

Kembangkan di antarmuka pengguna ruang kerja Databricks menggunakan Folder Git, atau di IDE lokal. Jika Anda menggunakan Visual Studio Code atau fork yang kompatibel, instal ekstensi Databricks resmi untuk:

  • Keterampilan agen khusus Databricks
  • Unity Catalog dan akses sistem berkas
  • Kemampuan pengembangan jarak jauh untuk menjalankan beban kerja pada komputasi Databricks

Untuk informasi selengkapnya, lihat Ekstensi Databricks untuk Visual Studio Code.

Meminimalkan logika bisnis di notebook

Jangan perlakukan notebook sebagai kontainer utama untuk logika bisnis. Gunakan hanya untuk eksplorasi dan visualisasi.

  • Python: Masukkan logika inti ke dalam modul yang dapat .py diimpor di src/ atau src/py/, dan panggil fungsi tersebut dari notebook.
  • SQL: Simpan kueri di file .sql di src/ atau src/sql/, dan rujuk file tersebut dari pekerjaan dan alur daripada menuliskan SQL langsung di notebook.

Gunakan notebook hanya sebagai lapisan orkestrasi dan visualisasi tipis yang memanggil kode yang mendasar. Pendekatan ini membuat pengujian dan penggunaan kembali lebih mudah.

Saat memigrasikan proyek notebook-heavy, lakukan secara bertahap. Ekstrak satu modul yang dapat digunakan kembali atau file SQL sekaligus, dan gunakan Bundel Otomatisasi Deklaratif untuk membawa aset yang dimigrasikan di bawah alur kerja penyebaran dan pengujian yang sama dengan proyek lainnya.

Meneruskan konteks secara dinamis

Hindari variabel statis untuk dependensi tugas. Gunakan referensi nilai dinamis seperti {{tasks.<task_key>.values.<value_key>}} untuk meneruskan konteks runtime antar tugas dalam pekerjaan multi-tahap.

Pengujian dan pengamatan

Menerapkan lapisan pengujian

Gunakan tiga lapisan pengujian yang cocok dengan cara bundel Anda bergerak menuju produksi:

  1. Pengujian unit: Simpan logika bisnis dalam modul src/ yang dapat diimpor dan uji dengan pytest atau kerangka kerja yang setara. Jalankan ini untuk setiap pull request agar kegagalan mencegah penggabungan.
  2. Validasi bundel: Jalankan bundle validate secara lokal. Di CI, sebaiknya gunakan bundle deploy untuk workspace nonproduksi guna mendeteksi masalah YAML dan pemetaan sumber daya sebelum penerapan ke produksi.
  3. Pengujian integrasi di staging: Setelah menerapkan ke staging, jalankan job end-to-end dengan pemeriksaan penyelesaian dan asersi kualitas data yang penting, seperti jumlah baris atau kesesuaian skema.

Perlakukan "semua tes lulus pada cabang utama dan dalam pementasan" sebagai gerbang untuk mempromosikan artefak ke produksi.

Untuk alur Lakeflow, gunakan fitur pengembangan dan validasi bawaan daripada eksekusi notebook ad-hoc. Menguji logika alur terhadap himpunan data perwakilan kecil yang menyertakan rekaman dengan kesalahan, dan menggunakan mode pengembangan untuk memvalidasi perubahan sebelum memperbarui tabel produksi.

Perlakukan pencatatan log sebagai bagian dari penerapan

Untuk beban kerja yang diterapkan menggunakan bundle Otomasi Deklaratif, perlakukan metrik dan pencatatan log sebagai bagian dari kontrak penerapan, bukan sebagai sesuatu yang didefinisikan secara terpisah oleh tiap proyek.

  • Keluarkan log terstruktur secara konsisten di seluruh pekerjaan, alur, dan tugas. Sertakan nama bundel, lingkungan target, nama beban kerja, pengidentifikasi eksekusi, dan pengidentifikasi bisnis apa pun yang diperlukan untuk melacak kegagalan.
  • Pantau sekumpulan metrik operasional standar untuk setiap beban kerja produksi: status proses, durasi, jumlah percobaan ulang, serta indikator throughput atau kebaruan data jika relevan.
  • Kodekan konvensi ini di pustaka bersama, definisi beban kerja yang dapat digunakan kembali, atau templat bundel sehingga tim tidak perlu membuat ulang pola pengamatan untuk setiap proyek.
  • Last updated on