Amazon EMR rilis 5.33.1

• Versi aplikasi di Amazon EMR 7.x rilis

• Versi aplikasi di Amazon EMR 6.x rilis

• Versi aplikasi di Amazon EMR 5.x rilis

• Versi aplikasi di Amazon EMR 4.x rilis

Peningkatan

• Konektor Amazon Glue telah di-upgrade ke versi 1.15.0

• Ditingkatkan AWS SDK for Java ke versi 1.11.970

• EMRFS telah di-upgrade ke versi 2.46.0

• EMR Goodies telah di-upgrade ke versi 2.14.0

• EMR Record Server telah di-upgrade ke versi 1.9.0

• EMR S3 Dist CP telah di-upgrade ke versi 2.18.0

• EMR Secret Agent telah di-upgrade ke versi 1.8.0

• Flink telah di-upgrade ke versi 1.12.1

• Hadoop telah di-upgrade ke versi 2.10.1-amzn-1

• Hive telah di-upgrade ke versi 2.3.7-amzn-4

• Hudi telah di-upgrade ke versi 0.7.0

• Hue telah di-upgrade ke versi 4.9.0

• OpenCV telah di-upgrade ke versi 4.5.0

• Presto telah di-upgrade ke versi 0.245.1-amzn-0

• R telah di-upgrade ke versi 4.0.2

• Spark telah di-upgrade ke versi 2.4.7-amzn-1

• Diting TensorFlow katkan ke versi 2.4.1

• Zeppelin telah di-upgrade ke versi 0.9.0

Perubahan, penyempurnaan, dan masalah yang diselesaikan

• Ini adalah rilis untuk memperbaiki masalah dengan Amazon EMR Scaling ketika gagal up/scale menurunkan skala cluster dengan sukses atau menyebabkan kegagalan aplikasi.

• Memperbaiki masalah ketika permintaan penskalaan gagal untuk cluster besar yang banyak digunakan saat daemon on-cluster Amazon EMR menjalankan aktivitas pemeriksaan kesehatan, seperti mengumpulkan status node YARN dan status simpul HDFS. Ini terjadi karena daemon on-cluster tidak dapat mengkomunikasikan data status kesehatan node ke komponen Amazon EMR internal.

• Peningkatan daemon on-cluster EMR untuk melacak status node dengan benar ketika alamat IP digunakan kembali untuk meningkatkan keandalan selama operasi penskalaan.

• SPARK-29683. Memperbaiki masalah ketika kegagalan pekerjaan terjadi selama penurunan skala cluster karena Spark mengasumsikan semua node yang tersedia dicantumkan di daftar yang dibantah.

• YARN-9011. Memperbaiki masalah ketika kegagalan pekerjaan terjadi karena kondisi balapan dalam penonaktifan YARN saat cluster mencoba menaikkan atau menurunkan skala.

• Memperbaiki masalah dengan kegagalan langkah atau pekerjaan selama penskalaan cluster dengan memastikan bahwa status node selalu konsisten antara daemon on-cluster Amazon EMR dan. YARN/HDFS

• Memperbaiki masalah ketika operasi cluster seperti penurunan skala dan pengiriman langkah gagal untuk cluster Amazon EMR yang diaktifkan dengan otentikasi Kerberos. Ini karena daemon on-cluster Amazon EMR tidak memperbarui tiket Kerberos, yang diperlukan untuk berkomunikasi dengan aman dengan HDFS/YARN berjalan di node utama.

• Rilis Amazon EMR yang lebih baru memperbaiki masalah dengan batas “Max open files” yang lebih rendah pada AL2 yang lebih lama di Amazon EMR. Amazon EMR merilis 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 dan yang lebih baru sekarang menyertakan perbaikan permanen dengan pengaturan “Max open files” yang lebih tinggi.

• Mengkonfigurasi cluster untuk memperbaiki masalah kinerja Apache YARN Timeline Server versi 1 dan 1.5

  Apache YARN Timeline Server versi 1 dan 1.5 dapat menyebabkan masalah kinerja dengan cluster EMR besar yang sangat aktif, terutama denganyarn.resourcemanager.system-metrics-publisher.enabled=true, yang merupakan pengaturan default di Amazon EMR. YARN Timeline Server v2 sumber terbuka memecahkan masalah kinerja yang terkait dengan skalabilitas YARN Timeline Server.

  Solusi lain untuk masalah ini meliputi:

  • Mengkonfigurasi yarn.resourcemanager.system-metrics-publisher.enabled=false di yarn-site.xml.

  • Mengaktifkan perbaikan untuk masalah ini saat membuat cluster, seperti dijelaskan di bawah ini.

  Rilis Amazon EMR berikut berisi perbaikan untuk masalah kinerja YARN Timeline Server ini.

  EMR 5.30.2, 5.31.1, 5.32.1, 5.33.1, 5.34.x, 6.0.1, 6.1.1, 6.2.1, 6.3.1, 6.4.x

  Untuk mengaktifkan perbaikan pada salah satu rilis Amazon EMR yang ditentukan di atas, atur properti ini ke true dalam file JSON konfigurasi yang diteruskan menggunakan parameter aws emr create-cluster perintah:--configurations file://./configurations.json. Atau aktifkan perbaikan menggunakan UI konsol konfigurasi ulang.

  Contoh isi file configurations.json:

  [
  {
  "Classification": "yarn-site",
  "Properties": {
  "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
  "yarn.resourcemanager.system-metrics-publisher.enabled": "true"
  },
  "Configurations": []
  }
  ]

• Runtime Spark sekarang lebih cepat saat mengambil lokasi partisi dari Hive Metastore untuk kueri sisipan Spark.

• Versi komponen yang telah ditingkatkan. Untuk daftar versi komponen, lihat Tentang Rilis Amazon EMR dalam panduan ini.

• Menginstal AWS Java SDK Bundle pada setiap cluster baru. Ini adalah toples tunggal yang berisi semua SDK layanan dan dependensinya, bukan stoples komponen individual. Untuk informasi selengkapnya, lihat Ketergantungan Berbundel Java SDK.

• Memperbaiki masalah Penskalaan Terkelola di rilis Amazon EMR sebelumnya dan membuat perbaikan sehingga tingkat kegagalan aplikasi berkurang secara signifikan.

• HTTPS sekarang diaktifkan secara default untuk repositori Amazon Linux. Jika Anda menggunakan kebijakan Amazon S3 VPCE untuk membatasi akses ke bucket tertentu, Anda harus menambahkan bucket Amazon Linux ARN baru arn:aws:s3:::amazonlinux-2-repos-$region/* ke kebijakan Anda (ganti $region dengan wilayah tempat titik akhir berada). Untuk informasi lebih lanjut, lihat topik ini di forum AWS diskusi. Pengumuman: Amazon Linux 2 sekarang mendukung kemampuan untuk menggunakan HTTPS saat menghubungkan ke repositori paket.

Fitur baru

• Amazon EMR mendukung Amazon S3 Access Points, fitur Amazon S3 yang memungkinkan Anda mengelola akses untuk danau data bersama dengan mudah. Dengan menggunakan alias Titik Akses Amazon S3, Anda dapat menyederhanakan akses data dalam skala besar di Amazon EMR. Anda dapat menggunakan Amazon S3 Access Points dengan semua versi Amazon EMR tanpa biaya tambahan di semua AWS wilayah di mana Amazon EMR tersedia. Untuk mempelajari selengkapnya tentang Poin Akses Amazon S3 dan alias Titik Akses, lihat Menggunakan alias bergaya bucket untuk titik akses Anda di Panduan Pengguna Amazon S3.

• Amazon EMR-5.33 mendukung jenis instans Amazon EC2 baru: c5a, c5ad, c6gn, c6gd, m6gd, d3, d3en, m5zn, r5b, r6gd. Lihat Tipe Instans yang Di-Support.

Masalah yang diketahui

• Turunkan batas “Max open files” pada AL2 yang lebih lama [diperbaiki dalam rilis yang lebih baru]. Rilis Amazon EMR: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0, dan emr-6.2.0 didasarkan pada versi lama Amazon Linux 2 (AL2), yang memiliki pengaturan ulimit yang lebih rendah untuk “Max open files” saat cluster Amazon EMR dibuat dengan AMI default. Amazon EMR merilis 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 dan yang lebih baru menyertakan perbaikan permanen dengan pengaturan “Max open files” yang lebih tinggi. Rilis dengan batas file terbuka yang lebih rendah menyebabkan kesalahan “Terlalu banyak file terbuka” saat mengirimkan pekerjaan Spark. Dalam rilis yang terkena dampak, AMI default Amazon EMR memiliki pengaturan ulimit default 4096 untuk “Max open files,” yang lebih rendah dari batas file 65536 di AMI Amazon Linux 2 terbaru. Pengaturan ulimit yang lebih rendah untuk "Maksimal file terbuka" menyebabkan kegagalan tugas Spark ketika driver dan pelaksana mencoba untuk membuka lebih dari 4096 file. Untuk memperbaiki masalah, Amazon EMR memiliki skrip tindakan bootstrap (BA) yang menyesuaikan pengaturan ulimit saat pembuatan klaster.

  Jika Anda menggunakan versi Amazon EMR lama yang tidak memiliki perbaikan permanen untuk masalah ini, solusi berikut memungkinkan Anda untuk secara eksplisit mengatur ulimit instance-controller ke maksimum 65536 file.

  Mengatur secara eksplisit ulimit dari baris perintah

  1. Edit /etc/systemd/system/instance-controller.service untuk menambahkan parameter berikut ke bagian Layanan.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Mulai ulang InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Tetapkan ulimit menggunakan tindakan bootstrap (BA)

  Anda juga dapat menggunakan skrip tindakan bootstrap (BA) untuk mengkonfigurasi ulimit instans-pengendali menjadi 65536 file saat pembuatan klaster.

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• Untuk cluster subnet pribadi Amazon EMR 6.3.0 dan 6.2.0, Anda tidak dapat mengakses UI web Ganglia. Anda akan mendapatkan pesan kesalahan "akses ditolak (403)". UI web lainnya, seperti Spark, Hue, Zeppelin JupyterHub, Livy, dan Tez bekerja secara normal. Akses UI web Ganglia pada klaster subnet publik juga bekerja secara normal. Untuk mengatasi masalah ini, mulai ulang layanan httpd pada node utama dengansudo systemctl restart httpd. Masalah ini diperbaiki di Amazon EMR 6.4.0.

• penting

  Cluster EMR yang menjalankan Amazon Linux atau Amazon Linux 2 Amazon Machine Images (AMI) menggunakan perilaku Amazon Linux default, dan tidak secara otomatis mengunduh dan menginstal pembaruan kernel penting dan penting yang memerlukan reboot. Ini adalah perilaku yang sama dengan instans Amazon EC2 lainnya yang menjalankan AMI Amazon Linux default. Jika pembaruan perangkat lunak Amazon Linux baru yang memerlukan reboot (seperti pembaruan kernel, NVIDIA, dan CUDA) tersedia setelah rilis Amazon EMR tersedia, instans cluster EMR yang menjalankan AMI default tidak secara otomatis mengunduh dan menginstal pembaruan tersebut. Untuk mendapatkan pembaruan kernel, Anda dapat menyesuaikan Amazon EMR AMI menjadi gunakan Amazon Linux AMI terbaru.

• Dukungan konsol untuk membuat konfigurasi keamanan yang menentukan opsi integrasi AWS Ranger saat ini tidak didukung di Wil GovCloud ayah. Konfigurasi keamanan dapat dilakukan dengan menggunakan CLI. Lihat Membuat Konfigurasi Keamanan EMR di Panduan Pengelolaan Amazon EMR.

• Kebijakan terkelola dengan cakupan: Untuk menyelaraskan dengan praktik AWS terbaik, Amazon EMR telah memperkenalkan kebijakan ter EMR-scoped kelola default v2 sebagai pengganti kebijakan yang tidak akan digunakan lagi. Lihat Kebijakan Terkelola Amazon EMR.

• Saat menggunakan Spark dengan pemformatan lokasi partisi Hive untuk membaca data di Amazon S3, dan menjalankan Spark di Amazon EMR rilis 5.30.0 hingga 5.36.0, dan 6.2.0 hingga 6.9.0, Anda mungkin mengalami masalah yang mencegah cluster membaca data dengan benar. Hal ini dapat terjadi jika partisi Anda memiliki semua karakteristik berikut:

  • Dua atau lebih partisi dipindai dari tabel yang sama.

  • Setidaknya satu jalur direktori partisi adalah awalan dari setidaknya satu jalur direktori partisi lainnya, misalnya, s3://bucket/table/p=a adalah awalan daris3://bucket/table/p=a b.

  • Karakter pertama yang mengikuti awalan di direktori partisi lain memiliki UTF-8 nilai yang kurang dari / karakter (U+002F). Misalnya, karakter spasi (U+0020) yang terjadi antara a dan b dalam termasuk dalam kategori s3://bucket/table/p=a b ini. Perhatikan bahwa ada 14 karakter non-kontrol lainnya:!"#$%&‘()*+,-. Untuk informasi selengkapnya, lihat tabel UTF-8 pengkodean dan karakter Unicode.

  Sebagai solusi untuk masalah ini, atur spark.sql.sources.fastS3PartitionDiscovery.enabled konfigurasi ke false dalam klasifikasispark-defaults.