Metodologi keberhasilan implementasi Synapse: Evaluasi desain kumpulan SQL tanpa server

Catatan

Artikel ini merupakan bagian dari rangkaian artikel Keberhasilan implementasi Azure Synapse berdasarkan desain. Untuk melihat ringkasan rangkaian ini, lihat Keberhasilan implementasi Azure Synapse berdasarkan desain.

Anda harus mengevaluasi desain kumpulan SQL tanpa server untuk mengidentifikasi masalah dan memvalidasi bahwa desain tersebut memenuhi pedoman dan persyaratan. Dengan mengevaluasi desain sebelum pengembangan solusi dimulai, Anda dapat menghindari pemblokir dan perubahan desain yang tidak terduga. Dengan begitu, Anda melindungi garis waktu dan anggaran proyek.

Pemisahan penyimpanan dan komputasi arsitektur untuk data modern, platform analitik, dan layanan telah menjadi tren dan pola yang sering digunakan. Ini memberikan penghematan biaya dan lebih banyak fleksibilitas yang memungkinkan penskalaan penyimpanan dan komputasi sesuai permintaan independen Anda. Synapse SQL tanpa server memperluas pola ini dengan menambahkan kemampuan untuk mengkueri data lake Anda secara langsung. Tidak perlu khawatir tentang manajemen komputasi saat menggunakan jenis beban kerja layanan mandiri.

Analisis kesenjangan kecocokan

Saat berencana menerapkan kumpulan tanpa server SQL dalam Azure Synapse, Anda harus terlebih dahulu memastikan kumpulan tanpa server cocok untuk beban kerja Anda. Anda harus mempertimbangkan keunggulan operasional, efisiensi performa, keandalan, dan keamanan.

Keunggulan operasional

Untuk keunggulan operasional, evaluasi poin-poin berikut.

• Lingkungan pengembangan solusi: Dalam metodologi ini, ada evaluasi lingkungan pengembangan solusi. Identifikasi bagaimana lingkungan (pengembangan, pengujian, dan produksi) dirancang untuk mendukung pengembangan solusi. Umumnya, Anda akan menemukan lingkungan produksi dan non-produksi (untuk pengembangan dan pengujian). Anda harus menemukan ruang kerja Synapse di semua lingkungan. Dalam kebanyakan kasus, Anda akan diwajibkan untuk memisahkan pengguna produksi dan pengembangan/pengujian dan beban kerja Anda.
• Desain ruang kerja Synapse: Dalam metodologi ini, ada evaluasi Desain ruang kerja Synapse. Identifikasi bagaimana ruang kerja telah dirancang untuk solusi Anda. Kenali desain dan ketahui apakah solusi akan menggunakan satu ruang kerja atau apakah beberapa ruang kerja menjadi bagian dari solusi. Ketahui mengapa satu atau beberapa desain ruang kerja dipilih. Desain multi-ruang kerja sering dipilih untuk memberlakukan batas keamanan yang ketat.
• Penyebaran: SQL tanpa server tersedia sesuai permintaan dengan setiap ruang kerja Synapse, sehingga tidak memerlukan tindakan penyebaran khusus. Periksa kedekatan regional layanan dan akun Azure Data Lake Storage Gen2 (ADLS Gen2) yang tersambung dengannya.
• Pemantauan: Periksa apakah pemantauan bawaan sudah cukup dan apakah ada layanan eksternal yang perlu diberlakukan untuk menyimpan data log historis. Data log memungkinkan analisis perubahan performa dan memungkinkan Anda menentukan tindakan peringatan atau yang dipicu untuk keadaan tertentu.

Efisiensi kinerja

Tidak seperti mesin database tradisional, SQL tanpa server tidak bergantung pada lapisan penyimpanan yang dioptimalkan sendiri. Untuk alasan itu, performanya sangat tergantung pada bagaimana data diatur di ADLS Gen2. Untuk efisiensi performa, evaluasi poin-poin berikut.

• Penyerapan data: Tinjau bagaimana data disimpan di data lake. Ukuran file, jumlah file, dan struktur folder semuanya berdampak pada performa. Perlu diingat bahwa meskipun beberapa ukuran file mungkin berfungsi untuk SQL tanpa server, mereka mungkin memberlakukan masalah untuk pemrosesan atau konsumsi yang efisien oleh mesin atau aplikasi lain. Anda harus mengevaluasi desain penyimpanan data dan memvalidasinya terhadap semua konsumen data, termasuk SQL tanpa server dan alat data lainnya yang merupakan bagian dari solusi Anda.
• Penempatan data: Mengevaluasi apakah desain Anda memiliki pola umum yang terpadu dan ditentukan untuk penempatan data. Pastikan bahwa pencabangan direktori dapat mendukung persyaratan keamanan Anda. Ada beberapa pola umum yang dapat membantu Anda mengatur data rangkaian waktu Anda. Apa pun pilihan Anda, pastikan juga berfungsi dengan mesin dan beban kerja lain. Selain itu, validasi apakah dapat membantu mempartisi penemuan otomatis untuk aplikasi Spark dan tabel eksternal.
• Format data: Dalam kebanyakan kasus, SQL tanpa server akan menawarkan performa terbaik dan kompatibilitas fitur yang lebih baik dengan menggunakan format Parquet. Verifikasi persyaratan performa dan kompatibilitas Anda, karena sementara Parquet meningkatkan performa - berkat kompresi dan pengurangan IO yang lebih baik (dengan membaca hanya kolom yang diperlukan untuk analisis) - dibutuhkan lebih banyak sumber daya komputasi. Selain itu, karena beberapa sistem sumber tidak secara asli mendukung Parquet sebagai format ekspor, itu dapat menyebabkan lebih banyak langkah transformasi dalam alur dan/atau dependensi Anda dalam arsitektur Anda secara keseluruhan.
• Eksplorasi: Setiap industri berbeda. Namun, dalam banyak kasus, ada pola akses data umum yang ditemukan dalam kueri yang paling sering dijalankan. Pola biasanya melibatkan pemfilteran, dan agregasi berdasarkan tanggal, kategori, atau wilayah geografis. Identifikasi kriteria pemfilteran Anda yang paling umum, dan kateringkan dengan berapa banyak data yang dibaca/dibuang oleh kueri yang paling sering dijalankan. Validasi apakah informasi pada data lake diatur untuk mendukung persyaratan dan harapan eksplorasi Anda. Untuk kueri yang diidentifikasi dalam desain Anda dan dalam penilaian Anda, lihat apakah Anda dapat menghilangkan partisi yang tidak perlu dalam parameter jalur OPENROWSET Anda, atau - jika ada tabel eksternal - apakah membuat lebih banyak indeks dapat membantu.

Keandalan

Untuk keandalan, evaluasi poin-poin berikut.

• Ketersediaan: Validasi persyaratan ketersediaan apa pun yang diidentifikasi selama tahap penilaian. Meskipun tidak ada SLA tertentu untuk SQL tanpa server, ada batas waktu 30 menit untuk eksekusi kueri. Identifikasi kueri terlama dari penilaian Anda dan validasi terhadap desain SQL tanpa server Anda. Batas waktu 30 menit dapat memutus harapan untuk beban kerja Anda dan muncul sebagai masalah layanan.
• Konsistensi: SQL tanpa server dirancang terutama untuk beban kerja baca. Jadi, validasi apakah semua pemeriksaan konsistensi telah dilakukan selama proses provisi dan pembentukan data lake data. Ikuti kemampuan baru, seperti lapisan penyimpanan sumber terbuka Delta Lake, yang menyediakan dukungan untuk jaminan ACID (atomitas, konsistensi, isolasi, dan durabilitas) untuk transaksi. Kemampuan ini memungkinkan Anda menerapkan arsitektur lambda atau kappa yang efektif untuk mendukung kasus penggunaan streaming dan batch. Pastikan untuk mengevaluasi desain Anda untuk peluang untuk menerapkan kemampuan baru tetapi tidak dengan mengorbankan garis waktu atau biaya proyek Anda.
• Cadangan: Tinjau persyaratan pemulihan bencana apa pun yang diidentifikasi selama penilaian. Validasi terhadap desain tanpa server SQL Anda untuk pemulihan. SQL tanpa server itu sendiri tidak memiliki lapisan penyimpanannya sendiri dan itu akan memerlukan penanganan snapshot dan salinan cadangan data Anda. Penyimpanan data yang diakses oleh SQL tanpa server adalah eksternal (ADLS Gen2). Tinjau desain pemulihan dalam proyek Anda untuk himpunan data ini.

Keamanan

Organisasi data Anda penting untuk membangun fondasi keamanan yang fleksibel. Dalam kebanyakan kasus, proses dan pengguna yang berbeda akan memerlukan izin dan akses yang berbeda ke sub area tertentu dari data lake atau gudang data logis Anda.

Untuk keamanan, evaluasi poin-poin berikut.

• Penyimpanan data: Menggunakan informasi yang dikumpulkan selama tahap penilaian, identifikasi apakah area data lake Mentah, Tahap, dan Yang Dikumpulkan khas perlu ditempatkan pada akun penyimpanan yang sama alih-alih akun penyimpanan independen. Yang terakhir dapat mengakibatkan lebih banyak fleksibilitas dalam hal peran dan izin. Ini juga dapat menambahkan lebih banyak kapasitas operasi input/output per detik (IOPS) yang mungkin diperlukan jika arsitektur Anda harus mendukung beban kerja baca/tulis yang berat dan simultan (seperti skenario real-time atau IoT). Validasi apakah Anda perlu memisahkan lebih jauh dengan menyimpan area data master dan kotak pasir Anda di akun penyimpanan terpisah. Sebagian besar pengguna tidak perlu memperbarui atau menghapus data, sehingga mereka tidak memerlukan izin menulis ke data lake, kecuali untuk area kotak pasir dan privat.
• Dari informasi penilaian Anda, identifikasi apakah ada persyaratan yang bergantung pada fitur keamanan seperti Always Encrypted, Masking data dinamis, atau Keamanan tingkat baris. Validasi ketersediaan fitur-fitur ini dalam skenario tertentu, seperti saat digunakan dengan fungsi OPENROWSET. Antisipasi potensi solusi yang mungkin diperlukan.
• Dari informasi penilaian Anda, identifikasi apa yang akan menjadi metode autentikasi terbaik. Pertimbangkan perwakilan layanan Microsoft Entra, tanda tangan akses bersama (SAS), dan kapan dan bagaimana pass-through autentikasi dapat digunakan dan diintegrasikan dalam alat eksplorasi pilihan pelanggan. Evaluasi desain dan validasi bahwa metode autentikasi terbaik sebagai bagian dari desain.

Pertimbangan lain

Tinjau desain Anda dan periksa apakah Anda telah menerapkan praktik dan rekomendasi terbaik. Berikan perhatian khusus pada pengoptimalan filter dan kolase untuk memastikan bahwa pushdown predikat berfungsi dengan baik.

Langkah berikutnya

Pada artikel berikutnya dalam rangkaian Keberhasilan Azure Synapse berdasarkan desain, pelajari cara mengevaluasi desain kumpulan Spark untuk mengidentifikasi masalah dan memvalidasi bahwa desain tersebut telah memenuhi pedoman dan persyaratan.