Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini membahas praktik terbaik untuk keandalan yang diatur oleh prinsip arsitektur yang tercantum di bagian berikut.
1. Desain untuk kegagalan
Menggunakan format data yang mendukung transaksi ACID
Transaksi ACID adalah fitur penting untuk menjaga integritas dan konsistensi data. Memilih format data yang mendukung transaksi ACID membantu membangun alur yang lebih sederhana dan jauh lebih andal.
Delta Lake adalah kerangka kerja penyimpanan sumber terbuka yang menyediakan transaksi ACID serta penegakan skema, penanganan metadata yang dapat diskalakan, dan menyatukan pemrosesan data streaming dan batch. Delta Lake sepenuhnya kompatibel dengan API Apache Spark dan dirancang untuk integrasi yang ketat dengan streaming terstruktur, memungkinkan Anda untuk dengan mudah menggunakan satu salinan data untuk operasi batch dan streaming dan menyediakan pemrosesan bertahap dalam skala besar.
Menggunakan mesin data terdistribusi yang tangguh untuk semua beban kerja
Apache Spark, sebagai mesin komputasi lakehouse Azure Databricks, didasarkan pada pemrosesan data terdistribusi yang tangguh. Jika tugas Spark internal tidak mengembalikan hasil seperti yang diharapkan, Apache Spark secara otomatis menjadwalkan ulang tugas yang hilang dan terus menjalankan seluruh pekerjaan. Ini berguna untuk kegagalan yang terjadi di luar kode, seperti masalah jaringan sementara atau VM Spot yang dibatalkan. Ketahanan ini telah terintegrasi ke dalam mesin saat bekerja dengan SQL API dan Spark DataFrame API.
Di lakehouse Databricks, Photon, mesin vektorisasi asli yang sepenuhnya ditulis dalam C++, adalah mesin komputasi performa tinggi yang kompatibel dengan API Apache Spark.
Secara otomatis menyelamatkan data yang tidak valid atau tidak berkonformasi
Data yang tidak valid atau tidak berkonformasi dapat menyebabkan beban kerja yang mengandalkan format data yang ditetapkan mengalami crash. Untuk meningkatkan ketangguhan end-to-end seluruh proses, praktik terbaik adalah memfilter data yang tidak valid dan tidak sesuai saat penerimaan. Dukungan untuk data yang diselamatkan memastikan Anda tidak pernah kehilangan atau melewatkan data selama pengambilan data atau ETL. Kolom data yang diselamatkan berisi data apa pun yang tidak diurai, baik karena hilang dari skema yang diberikan, karena ada ketidakcocokan jenis, atau karena isi kolom dalam rekaman atau file tidak cocok dengan yang ada dalam skema.
Databricks Auto Loader:Auto Loader adalah alat yang ideal untuk streaming pemasukan file. Ini mendukung data yang diselamatkan untuk JSON dan CSV. Misalnya, untuk JSON, kolom data yang diselamatkan berisi data apa pun yang tidak diurai, mungkin karena hilang dari skema yang diberikan, karena ada jenis ketidakcocokan, atau karena casing kolom tidak cocok. Kolom data yang diselamatkan adalah bagian dari skema yang dikembalikan oleh Auto Loader sebagai
_rescued_data
secara default ketika skema sedang disimpulkan.Pipa: Opsi lain untuk membangun alur kerja untuk ketahanan adalah menggunakan Alur Deklaratif Lakeflow dengan batasan kualitas. Lihat Mengelola kualitas data dengan ekspektasi alur. Alur Deklaratif Lakeflow mendukung tiga mode secara default: mempertahankan, menghilangkan, dan gagal pada rekaman yang tidak valid. Untuk mengkarantina rekaman yang diidentifikasi tidak valid, aturan ekspektasi dapat ditentukan dengan cara tertentu sehingga rekaman yang tidak valid disimpan ("dikarantina") di tabel lain. Lihat Mengkarantina rekaman yang tidak valid.
Mengonfigurasi pekerjaan untuk pengulangan otomatis dan penghentian otomatis.
Sistem terdistribusi sangatlah kompleks, dan kegagalan pada satu titik berpotensi dapat mengalir ke seluruh sistem.
- Pekerjaan Lakeflow mendukung kebijakan pengulangan untuk tugas yang menentukan kapan dan berapa kali percobaan yang gagal diulang. Lihat Kebijakan penyetelan ulang.
- Anda dapat mengonfigurasi ambang durasi opsional untuk tugas, termasuk waktu penyelesaian tugas yang diharapkan dan waktu penyelesaian maksimum untuk tugas tersebut.
- Alur Deklaratif Lakeflow juga mengotomatiskan pemulihan kegagalan dengan menggunakan percobaan ulang secara bertahap untuk mempertahankan kecepatan dan keandalan. Lihat Mode pengembangan dan produksi.
Sebaliknya, sebuah tugas yang tertunda dapat mencegah seluruh pekerjaan untuk diselesaikan, yang dapat menyebabkan biaya tinggi. Lakeflow Jobs mendukung konfigurasi batas waktu untuk mematikan pekerjaan yang memakan waktu lebih lama dari yang diharapkan.
Gunakan infrastruktur penyajian model yang dapat diskalakan dan berkualitas produksi.
Untuk inferensi batch dan streaming, gunakan Lakeflow Jobs dan MLflow untuk menyebarkan model sebagai Apache Spark UDF untuk memanfaatkan penjadwalan job, pengulangan, penskalaan otomatis, dan lain-lain. Lihat Meluncurkan model untuk inferensi dan prediksi batch.
Penyajian model menyediakan infrastruktur yang dapat diskalakan dan tingkat produksi untuk penyajian model real time. Ini memproses model pembelajaran mesin Anda menggunakan MLflow dan mengeksposnya sebagai titik akhir REST API. Fungsionalitas ini menggunakan komputasi tanpa server, yang berarti bahwa titik akhir dan sumber daya komputasi terkait dikelola dan dijalankan di akun cloud Azure Databricks.
Gunakan layanan terkelola jika memungkinkan
Manfaatkan layanan terkelola (komputasi tanpa server) dari Databricks Data Intelligence Platform, seperti:
- SQL warehouse tanpa server
- penyajian model
- pekerjaan tanpa server
- komputasi tanpa server untuk notebook
- Pipeline Deklaratif Lakeflow
Layanan ini dioperasikan oleh Databricks dengan cara yang andal dan dapat diskalakan, membuat beban kerja lebih dapat diandalkan.
2. Mengelola kualitas data
Menggunakan arsitektur penyimpanan berlapis
Kurasi data dengan membuat arsitektur berlapis dan memastikan bahwa kualitas data meningkat saat data bergerak melalui lapisan. Pendekatan lapisan umum adalah:
- Lapisan mentah (perunggu): Data sumber diserap ke dalam lakehouse ke lapisan pertama dan harus dipertahankan di sana. Ketika semua data hilir dibuat dari lapisan mentah, dimungkinkan untuk membangun kembali lapisan berikutnya dari lapisan ini sesuai kebutuhan.
- Lapisan yang dikumpulkan (perak): Tujuan dari lapisan kedua adalah untuk menyimpan data yang dibersihkan, disempurnakan, difilter, dan diagregasi. Tujuan dari lapisan ini adalah untuk memberikan fondasi yang solid dan andal untuk analisis dan pelaporan di semua peran dan fungsi.
- Lapisan akhir (emas): Lapisan ketiga dibangun di sekitar kebutuhan bisnis atau proyek. Ini memberikan pandangan yang berbeda sebagai produk data untuk unit bisnis atau proyek lain, menyiapkan data sesuai kebutuhan keamanan (seperti data anonim) atau mengoptimalkan performa (seperti dengan pandangan yang sudah diaggregasi sebelumnya). Produk data dalam lapisan ini dianggap sebagai kebenaran untuk bisnis.
Lapisan akhir hanya boleh berisi data berkualitas tinggi dan sepenuhnya dipercaya dari perspektif bisnis.
Meningkatkan integritas data dengan mengurangi redundansi data
Menyalin atau menduplikasi data membuat redundansi data dan menyebabkan hilangnya integritas, hilangnya silsilah data, dan sering kali izin akses yang berbeda. Ini mengurangi kualitas data di gudang data danau.
Salinan data sementara atau sekali pakai tidak berbahaya dalam dirinya sendiri - terkadang perlu untuk meningkatkan kelincahan, eksperimen, dan inovasi. Namun, ketika salinan-salinan ini menjadi operasional dan secara teratur digunakan untuk membuat keputusan bisnis, mereka berubah menjadi silo data. Ketika silo data ini menjadi tidak sinkron, itu memiliki dampak negatif yang signifikan pada integritas dan kualitas data, mengajukan pertanyaan seperti "Himpunan data mana yang merupakan master?" atau "Apakah himpunan data terkini?"
Mengelola skema secara aktif
Perubahan skema yang tidak terkontrol dapat menyebabkan data yang tidak valid dan pekerjaan yang gagal yang menggunakan himpunan data ini. Azure Databricks memiliki beberapa metode untuk memvalidasi dan menerapkan skema:
- Delta Lake mendukung validasi skema dan penegakan skema dengan menangani variasi skema secara otomatis untuk mencegah penyisipan rekaman buruk selama penyerapan. Lihat Penegakan skema.
-
Auto Loader mendeteksi penambahan kolom baru saat memproses data Anda. Secara bawaan, penambahan kolom baru menyebabkan aliran Anda berhenti pada
UnknownFieldException
. Auto Loader mendukung beberapa mode untuk evolusi skema.
Menggunakan batasan dan ekspektasi data
Tabel Delta mendukung klausul manajemen batasan SQL standar yang memastikan bahwa kualitas dan integritas data yang ditambahkan ke tabel diperiksa secara otomatis. Ketika batasan dilanggar, Delta Lake melemparkan InvariantViolationException
kesalahan untuk memberikan sinyal bahwa data baru tidak dapat ditambahkan. Lihat Batasan di Azure Databricks.
Untuk lebih meningkatkan penanganan ini, Lakeflow Declarative Pipelines mendukung ekspektasi: Harapan menentukan batasan kualitas data pada konten himpunan data. Harapan terdiri dari deskripsi, invarian, dan tindakan yang harus diambil jika catatan melanggar invarian. Ekspektasi pada kueri menggunakan dekorator Python atau klausa batasan SQL. Lihat Mengelola kualitas data dengan ekspektasi alur.
Mengambil pendekatan yang berfokus pada data untuk pembelajaran mesin
Prinsip panduan yang tetap menjadi inti visi AI untuk Databricks Data Intelligence Platform adalah pendekatan yang berpusat pada data untuk pembelajaran mesin. Karena AI generatif menjadi lebih lazim, perspektif ini tetap sama pentingnya.
Komponen inti dari proyek ML apa pun hanya dapat dianggap sebagai alur data: Rekayasa fitur, pelatihan, penyebaran model, inferensi, dan alur pemantauan adalah semua alur data. Dengan demikian, mengoperasionalkan solusi ML memerlukan penggabungan data dari tabel prediksi, pemantauan, dan fitur dengan data relevan lainnya. Pada dasarnya, cara term mudah untuk mencapainya adalah dengan mengembangkan solusi yang didukung AI pada platform yang sama yang digunakan untuk mengelola data produksi. Lihat MLOps dan LLMOps yang berpusat pada data
3. Desain untuk penskalaan otomatis
Mengaktifkan penskalaan otomatis untuk beban kerja ETL
Autoscaling memungkinkan kluster untuk mengubah ukuran secara otomatis berdasarkan beban kerja. Autoscaling dapat menguntungkan banyak kasus penggunaan dan skenario dari perspektif biaya dan performa. Dokumentasi ini memberikan pertimbangan untuk menentukan apakah akan menggunakan penskalaan otomatis dan cara mendapatkan manfaat maksimal.
Untuk beban kerja streaming, Databricks merekomendasikan penggunaan Alur Deklaratif Lakeflow dengan penskalaan otomatis. Peningkatan penskalaan otomatis Databricks mengoptimalkan pemanfaatan kluster dengan mengalokasikan sumber daya kluster secara otomatis berdasarkan volume beban kerja, dengan dampak yang sangat minimal pada latensi pemrosesan data alur Anda.
Mengaktifkan penskalaan otomatis untuk gudang SQL
Parameter penskalaan gudang SQL menetapkan jumlah minimum dan jumlah maksimum kluster di mana kueri yang dikirim ke gudang didistribusikan. Defaultnya adalah satu kluster tanpa penskalakan otomatis.
Untuk menangani pengguna yang lebih bersamaan untuk gudang tertentu, tingkatkan jumlah kluster. Untuk mempelajari bagaimana Azure Databricks menambahkan dan menghapus kluster ke dan dari gudang, lihat ukuran, penskalaan, dan perilaku antrean gudang SQL.
4. Menguji prosedur pemulihan
Memulihkan dari kegagalan kueri Streaming Terstruktur
Streaming Terstruktur menyediakan toleransi kesalahan dan konsistensi data untuk kueri streaming. Dengan menggunakan Tugas Lakeflow, Anda dapat dengan mudah mengonfigurasi kueri Streaming Terstruktur untuk memulai ulang secara otomatis ketika terjadi kegagalan. Dengan mengaktifkan titik pemeriksaan untuk kueri streaming, Anda dapat memulai ulang kueri setelah kegagalan. Kueri yang dimulai ulang berlanjut dari titik di mana kueri yang gagal berhenti. Lihat Titik pemeriksaan Streaming Terstruktur dan Pertimbangan produksi untuk Streaming Terstruktur.
Memulihkan pekerjaan ETL menggunakan kemampuan data perjalanan waktu
Meskipun pengujian menyeluruh, pekerjaan mungkin gagal dalam produksi atau menghasilkan data yang tidak terduga, bahkan tidak valid. Terkadang ini dapat diperbaiki dengan pekerjaan tambahan setelah memahami sumber masalah dan memperbaiki alur yang menyebabkan masalah di tempat pertama. Namun, seringkali ini tidak mudah dan pekerjaan yang bersangkutan harus digulung balik. Dengan menggunakan Delta Time travel, pengguna dapat dengan mudah mengembalikan perubahan ke versi atau tanda waktu yang lebih lama, memperbaiki alur, dan memulai ulang alur tetap.
Cara mudah untuk melakukannya adalah RESTORE
perintah.
Memanfaatkan kerangka kerja otomatisasi pekerjaan dengan pemulihan bawaan
Pekerjaan Lakeflow dirancang untuk pemulihan. Ketika sebuah tugas dalam sebuah pekerjaan multi-tugas gagal (dan, dengan demikian, semua tugas dependen), pekerjaan menyediakan tampilan matriks dari eksekusi-eksekusi tersebut yang memungkinkan Anda menyelidiki masalah yang menyebabkan kegagalan, lihat Melihat eksekusi untuk satu pekerjaan. Baik itu masalah jaringan singkat atau masalah nyata dalam data, Anda dapat memperbaikinya dan memulai eksekusi perbaikan di Lakeflow Jobs. Ini hanya akan menjalankan tugas yang gagal dan tergantung dan menjaga hasil yang berhasil dari eksekusi sebelumnya, menghemat waktu dan uang, lihat Memecahkan masalah dan memperbaiki kegagalan pekerjaan.
Mengonfigurasi pola pemulihan bencana
Untuk platform analitik data cloud-native seperti Azure Databricks, pola pemulihan bencana yang jelas sangat penting. Sangat penting bahwa tim data Anda dapat menggunakan platform Azure Databricks bahkan jika terjadi pemadaman regional di seluruh layanan dari penyedia layanan cloud, baik yang disebabkan oleh bencana regional seperti badai, gempa bumi, atau beberapa sumber lainnya.
Azure Databricks sering menjadi bagian inti dari ekosistem data keseluruhan yang mencakup banyak layanan, termasuk layanan penyerapan data hulu (batch/streaming), penyimpanan cloud-native seperti Azure Data Lake Storage, alat dan layanan hilir seperti aplikasi inteligensi bisnis, dan alat orkestrasi. Beberapa kasus penggunaan Anda mungkin sangat sensitif terhadap pemadaman di seluruh layanan regional.
Pemulihan bencana melibatkan serangkaian kebijakan, alat, dan prosedur yang memungkinkan pemulihan atau kelanjutan infrastruktur dan sistem teknologi vital setelah bencana alam atau yang diinduksi manusia. Layanan cloud besar seperti Azure melayani banyak pelanggan dan memiliki perlindungan bawaan terhadap satu kegagalan. Misalnya, wilayah adalah sekelompok bangunan yang terhubung ke sumber daya yang berbeda untuk memastikan bahwa satu pemadaman listrik tidak akan menurunkan suatu wilayah. Namun, kegagalan wilayah cloud dapat terjadi, dan tingkat keparahan kegagalan dan dampaknya pada bisnis Anda dapat bervariasi.
5. Mengotomatiskan penyebaran dan beban kerja
Lihat Keunggulan Operasional - Mengotomatiskan penyebaran dan beban kerja.
6. Memantau sistem dan beban kerja
Lihat Keunggulan Operasional - Menyiapkan pemantauan, pemberitahuan, dan pengelogan.