Bagikan melalui

Pelajari cara memecahkan masalah kegagalan runtime U-SQL karena perubahan runtime

  • Artikel

Penting

Azure Data Lake Analytics pensiun pada 29 Februari 2024. Pelajari lebih lanjut dengan pengumuman ini.

Untuk analitik data, organisasi Anda dapat menggunakan Azure Synapse Analytics atau Microsoft Fabric.

Runtime U-SQL Azure Data Lake, termasuk pengompilasi, pengoptimal, dan pengelola pekerjaan, adalah proses yang dikodekan oleh U-SQL Anda.

Memilih versi runtime U-SQL Anda

Saat Anda mengirimkan pekerjaan U-SQL dari Visual Studio, ADL SDK, atau portal Azure Data Lake Analytics, pekerjaan Anda akan menggunakan runtime default yang tersedia saat ini. Versi baru runtime U-SQL dirilis secara teratur dan menyertakan pembaruan kecil dan perbaikan keamanan.

Anda juga dapat memilih versi runtime kustom; baik karena Anda ingin mencoba pembaruan baru, harus tetap menggunakan versi runtime yang lebih lama, atau diberikan perbaikan untuk masalah yang dilaporkan di mana Anda tidak dapat menunggu pembaruan baru biasa.

Perhatian

Memilih runtime selain default dapat merusak pekerjaan U-SQL Anda. Gunakan versi lain ini hanya untuk pengujian.

Dalam kasus yang jarang terjadi, Dukungan Microsoft dapat menyematkan versi runtime yang berbeda sebagai default untuk akun Anda. Pastikan Anda mengembalikan pin ini sesegera mungkin. Jika Anda tetap menyematkan ke versi tersebut, versi tersebut akan kedaluwarsa di kemudian hari.

Memantau versi runtine U-SQL pekerjaan Anda

Anda dapat melihat riwayat versi runtime mana yang sudah digunakan oleh pekerjaan lama Anda dalam riwayat pekerjaan akun Anda melalui browser pekerjaan Visual Studio atau riwayat pekerjaan portal Microsoft Azure.

  1. Di portal Microsoft Azure, buka akun Data Lake Analytics Anda.
  2. Pilih Tampilkan Semua Pekerjaan. Daftar semua pekerjaan aktif dan yang baru saja diselesaikan di akun akan ditampilkan.
  3. Secara opsional, pilih Filter untuk membantu Anda menemukan pekerjaan berdasarkan rentang waktu, Nama Pekerjaan, dan nilai Penulis .
  4. Anda dapat melihat runtime yang digunakan dalam pekerjaan yang diselesaikan.

Menampilkan versi runtime dari pekerjaan sebelumnya

Versi runtime yang tersedia berubah dari waktu ke waktu. Runtime default selalu disebut "default" dan kami menyimpan setidaknya runtime sebelumnya yang tersedia untuk beberapa waktu dan membuat runtime khusus tersedia karena berbagai alasan. Runtime bernama secara eksplisit umumnya mengikuti format berikut (huruf miring digunakan untuk bagian variabel dan [] menunjukkan bagian opsional):

release_YYYYMMDD_adl_buildno[_modifier]

Misalnya, release_20190318_adl_3394512_2 berarti versi kedua build 3394512 dari rilis runtime pada 18 Maret 2019 dan release_20190318_adl_3394512_private berarti build privat dari rilis yang sama. Catatan: Tanggal tersebut terkait dengan kapan check-in terakhir diambil untuk rilis tersebut dan belum tentu tanggal rilis resmi.

Memecahkan masalah versi runtime U-SQL

Ada dua kemungkinan masalah versi runtime yang dapat Anda temui:

  1. Skrip atau beberapa kode pengguna mengubah perilaku dari satu rilis ke rilis berikutnya. Perubahan mencolok seperti itu biasanya dikomunikasikan sebelumnya dengan publikasi catatan rilis. Jika Anda mengalami perubahan yang melanggar seperti itu, hubungi Dukungan Microsoft untuk melaporkan perilaku melanggar ini (jika belum didokumenkan) dan kirimkan pekerjaan Anda terhadap versi runtime yang lebih lama.

  2. Anda telah menggunakan runtime nondefault baik secara eksplisit atau implisit ketika telah disematkan ke akun Anda, dan runtime tersebut telah dihapus setelah beberapa waktu. Jika Anda menemukan runtime yang hilang, perbarui skrip Anda untuk dijalankan dengan runtime default saat ini. Jika Anda membutuhkan lebih banyak waktu, hubungi Dukungan Microsoft

Masalah yang diketahui

  1. Merujuk file Newtonsoft.Json versi 12.0.3 atau seterusnya di skrip USQL akan menyebabkan kegagalan kompilasi berikut:

    "Kami minta maaf; pekerjaan yang berjalan di akun Data Lake Analytics Anda kemungkinan akan berjalan lebih lambat atau gagal diselesaikan. Masalah tak terduga mencegah kami memulihkan fungsionalitas ini secara otomatis ke akun Azure Data Lake Analytics Anda. Teknisi Azure Data Lake telah dihubungi untuk menyelidiki."

    Ketika tumpukan panggilan akan berisi:
    System.IndexOutOfRangeException: Index was outside the bounds of the array.
    at Roslyn.Compilers.MetadataReader.PEFile.CustomAttributeTableReader.get_Item(UInt32 rowId)
    ...

    Solusi: Gunakan file Newtonsoft.Json v12.0.2 atau yang lebih rendah.

  2. Pelanggan mungkin melihat file dan folder sementara di penyimpanan mereka. Keduanya diproduksi sebagai bagian dari eksekusi pekerjaan normal, tetapi biasanya dihapus sebelum pelanggan melihatnya. Dalam keadaan tertentu, yang jarang dan acak, mereka mungkin tetap terlihat. Mereka akhirnya dihapus, dan tidak pernah dihitung sebagai bagian dari penyimpanan pengguna, atau menghasilkan segala bentuk biaya apa pun. Bergantung pada logika pekerjaan pelanggan, file dan folder sementara tersebut mungkin menyebabkan masalah. Misalnya, jika pekerjaan menghitung semua file dalam folder, lalu membandingkan daftar file, hal ini mungkin gagal karena adanya file sementara yang tidak terduga. Demikian pula, jika pekerjaan hilir menghitung semua file dari folder tertentu untuk diproses lebih lanjut, proses tersebut mungkin juga menghitung file sementara.

    Solusi: Perbaikan diidentifikasi dalam runtime tempat file sementara akan disimpan di folder temp tingkat akun daripada folder output saat ini. File sementara akan ditulis dalam folder sementara baru ini dan akan dihapus di akhir eksekusi pekerjaan.
    Karena perbaikan ini menangani data pelanggan, penting untuk memvalidasi perbaikan ini dengan baik dalam MSFT sebelum dirilis. Diperkirakan perbaikan ini tersedia sebagai runtime beta pada pertengahan tahun 2021 dan sebagai runtime default pada paruh kedua tahun 2021.

Lihat juga