Amazon EMR merilis 6.2.0

• 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

Aplikasi-aplikasi yang didukung

• AWS SDK for Java versi 1.11.828

• emr-record-server versi 1.7.0

• Flink versi 1.11.2

• Ganglia versi 3.7.2

• Hadoop versi 3.2.1-amzn-1

• HBaseversi 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalogversi 3.1.2-amzn-0

• Hive versi 3.1.2-amzn-3

• Hudi versi 0.6.0-amzn-1

• Hue versi 4.8.0

• JupyterHub versi 1.1.0

• Livy versi 0.7.0

• MXNetversi 1.7.0

• Oozie versi 5.2.0

• Phoenix versi 5.0.0

• Pig versi 0.17.0

• Presto versi 0.238.3-amzn-1

• Presto SQL versi 343

• Spark versi 3.0.1-amzn-0

• spark-rapids versi 0.2.0

• TensorFlow versi 2.3.1

• Zeppelin versi 0.9.0-preview1

• Zookeeper versi 3.4.14

• Konektor dan driver: DynamoDB Connector 4.16.0

Fitur baru

• HBase: Menghapus ganti nama dalam fase komit dan menambahkan HFile pelacakan persisten. Lihat HFilePelacakan Persisten di Panduan EMR Rilis Amazon.

• HBase: Backported Buat konfigurasi yang memaksa untuk menyimpan blok pada pemadatan.

• PrestoDB: Perbaikan Pemangkasan Partisi Dinamis. Join Reorder berbasis aturan bekerja pada data non-partisi.

• Kebijakan terkelola tercakup: Untuk menyelaraskan dengan praktik AWS terbaik, Amazon EMR telah memperkenalkan kebijakan EMR terkelola default dengan cakupan v2 sebagai pengganti kebijakan yang tidak digunakan lagi. Lihat Kebijakan yang EMR Dikelola Amazon.

• Status dukungan Instance Metadata Service (IMDS) V2: Untuk Amazon EMR 6.2 atau versi lebih baru, EMR komponen Amazon digunakan IMDSv2 untuk semua panggilan. IMDS Untuk IMDS panggilan dalam kode aplikasi Anda, Anda dapat menggunakan keduanya IMDSv1 danIMDSv2, atau mengkonfigurasi IMDS untuk digunakan hanya IMDSv2 untuk keamanan tambahan. Jika Anda menonaktifkan IMDSv1 rilis Amazon EMR 6.x sebelumnya, ini menyebabkan kegagalan startup cluster.

Perubahan, penyempurnaan, dan masalah yang diselesaikan

• Ini adalah rilis untuk memperbaiki masalah dengan Amazon EMR Scaling ketika gagal meningkatkan/menurunkan klaster dengan sukses atau menyebabkan kegagalan aplikasi.

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

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

• SPARK-29683. Memperbaiki masalah di mana kegagalan pekerjaan terjadi selama penskalaan klaster karena Spark mengasumsikan semua node yang tersedia tidak terdaftar.

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

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

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

• EMRRilis Amazon yang lebih baru memperbaiki masalah dengan batas “Max open files” yang lebih rendah pada yang lebih lama AL2 di AmazonEMR. 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.

• Spark: Perbaikan performa dalam waktu aktif Spark.

Masalah yang diketahui

• Amazon EMR 6.2 memiliki izin yang salah disetel pada direktori the /etc/cron.d/libinstance-controller-java file in EMR 6.2.0. Permissions on the file are 645 (-rw-r--r-x), when they should be 644 (-rw-r--r--). As a result, Amazon EMR version 6.2 does not log instance-state logs, and the /emr/instance -logs kosong. Masalah ini diperbaiki di Amazon EMR 6.3.0 dan yang lebih baru.

  Untuk mengatasi masalah ini, jalankan skrip berikut sebagai tindakan bootstrap saat peluncuran cluster.

  #!/bin/bash
  sudo chmod 644 /etc/cron.d/libinstance-controller-java
              

• Untuk Amazon EMR 6.2.0 dan 6.3.0 kluster subnet pribadi, Anda tidak dapat mengakses UI web Ganglia. Anda akan mendapatkan pesan kesalahan "akses ditolak (403)". Web lainUIs, 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 telah diperbaiki di Amazon EMR 6.4.0.

• Ada masalah di Amazon EMR 6.2.0 di mana httpd terus gagal, menyebabkan Ganglia tidak tersedia. Anda mendapatkan pesan kesalahan "tidak dapat menyambung ke server". Untuk memperbaiki cluster yang sudah berjalan dengan masalah ini, SSH ke node utama cluster dan tambahkan baris Listen 80 ke file yang httpd.conf terletak di/etc/httpd/conf/httpd.conf. Masalah ini telah diperbaiki di Amazon EMR 6.3.0.

• HTTPDgagal pada cluster EMR 6.2.0 saat Anda menggunakan konfigurasi keamanan. Hal ini membuat antarmuka pengguna aplikasi web Ganglia tidak tersedia. Untuk mengakses antarmuka pengguna aplikasi web Ganglia, tambahkan Listen 80 ke /etc/httpd/conf/httpd.conf file pada node utama cluster Anda. Untuk informasi tentang menghubungkan ke klaster Anda, lihat Connect to the Primary Node Using SSH.

  EMRNotebook juga gagal membuat koneksi dengan cluster EMR 6.2.0 saat Anda menggunakan konfigurasi keamanan. Notebook tersebut akan gagal untuk membuat daftar kernel dan mengirimkan tugas Spark. Kami menyarankan Anda menggunakan EMR Notebook dengan versi Amazon lain EMR sebagai gantinya.

• Turunkan batas “Maks open files” pada yang lebih lama AL2 [diperbaiki dalam rilis yang lebih baru]. EMRRilis Amazon: 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 Linux ofAmazon 2 ()AL2, yang memiliki pengaturan ulimit yang lebih rendah untuk “File terbuka maksimum” ketika cluster Amazon dibuat dengan default. EMR AMI 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 kemudian 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, EMR default Amazon AMI memiliki pengaturan ulimit default 4096 untuk “File terbuka maksimum,” yang lebih rendah dari batas file 65536 di Linux 2. latestAmazon AMI 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 ini, Amazon EMR memiliki skrip bootstrap action (BA) yang menyesuaikan pengaturan ulimit pada pembuatan cluster.

  Jika Anda menggunakan EMR versi Amazon lama yang tidak memiliki perbaikan permanen untuk masalah ini, solusi berikut memungkinkan Anda untuk secara eksplisit menyetel ulimit pengontrol instans 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

• penting

  Amazon EMR 6.1.0 dan 6.2.0 menyertakan masalah kinerja yang secara kritis dapat memengaruhi semua operasi penyisipan, peningkatan, dan penghapusan Hudi. Jika Anda berencana untuk menggunakan Hudi dengan Amazon EMR 6.1.0 atau 6.2.0, Anda harus menghubungi AWS dukungan untuk mendapatkan Hudi yang ditambal. RPM

• penting

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

• Artefak Amazon EMR 6.2.0 Maven tidak dipublikasikan. Mereka akan diterbitkan dengan rilis Amazon di masa depanEMR.

• HFilePelacakan persisten menggunakan tabel sistem HBase storefile tidak mendukung fitur replikasi HBase wilayah. Untuk informasi selengkapnya tentang replikasi HBase wilayah, lihat Bacaan Tersedia Tinggi Konsisten Waktu.

• Perbedaan versi bucketing Amazon EMR EMR 6.x dan 5.x Hive

  EMR5.x menggunakan OOS Apache Hive 2, sedangkan di EMR 6.x menggunakan OOS Apache Hive 3. Hive2 sumber terbuka menggunakan Bucketing versi 1, sementara Hive3 sumber terbuka menggunakan Bucketing versi 2. Perbedaan versi bucketing antara Hive 2 (EMR5.x) dan Hive 3 (EMR6.x) berarti fungsi hashing bucketing Hive secara berbeda. Lihat contoh di bawah ini.

  Tabel berikut adalah contoh yang dibuat di EMR 6.x dan EMR 5.x, masing-masing.

  -- Using following LOCATION in EMR 6.x
  CREATE TABLE test_bucketing (id INT, desc STRING)
  PARTITIONED BY (day STRING)
  CLUSTERED BY(id) INTO 128 BUCKETS
  LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';
  
  -- Using following LOCATION in EMR 5.x 
  LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';

  Memasukkan data yang sama di EMR 6.x dan EMR 5.x.

  INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
  INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');

  Memeriksa lokasi S3, menunjukkan nama file bucketing berbeda, karena fungsi hashing berbeda antara EMR 6.x (Hive 3) dan 5.x (Hive 2). EMR

  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
  2020-10-21 20:35:16         13 000025_0
  2020-10-21 20:35:22         14 000121_0
  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
  2020-10-21 20:32:07         13 000066_0
  2020-10-21 20:32:51         14 000072_0
  

  Anda juga dapat melihat perbedaan versi dengan menjalankan perintah berikut di Hive CLI di EMR 6.x. Perhatikan bahwa ia menghasilkan pem-bucket-an versi 2.

  hive> DESCRIBE FORMATTED test_bucketing;
  ...
  Table Parameters:
      bucketing_version       2
  ...

• Masalah yang diketahui dalam cluster dengan beberapa node primer dan otentikasi Kerberos

  Jika Anda menjalankan cluster dengan beberapa node utama dan otentikasi Kerberos di EMR Amazon rilis 5.20.0 dan yang lebih baru, Anda mungkin mengalami masalah dengan operasi klaster seperti penurunan skala atau pengiriman langkah, setelah klaster berjalan selama beberapa waktu. Periode waktunya tergantung pada masa validitas tiket Kerberos yang Anda tetapkan. Masalah menurunkan skala akan berdampak pada permintaan menurunkan skala otomatis dan permintaan menurunkan skala eksplisit yang Anda kirimkan. Operasi klaster tambahan juga dapat terkena dampak.

  Pemecahan masalah:

  • SSHsebagai hadoop pengguna ke simpul utama utama EMR cluster dengan beberapa node primer.

  • Jalankan perintah berikut untuk memperbarui tiket Kerberos untuk pengguna hadoop.

    kinit -kt <keytab_file> <principal>

    Biasanya, fail keytab terletak di /etc/hadoop.keytab dan file utama-nya dalam bentuk hadoop/<hostname>@<REALM>.

  catatan

  Pemecahan masalah ini akan efektif untuk jangka waktu selama tiket Kerberos berlaku. Durasi ini adalah 10 jam secara default, tetapi dapat dikonfigurasi dengan pengaturan Kerberos Anda. Anda harus menjalankan kembali perintah di atas setelah tiket Kerberos berakhir.

• Saat Anda menggunakan format lokasi partisi Spark dengan Hive untuk membaca data di Amazon S3, dan Anda menjalankan Spark di Amazon EMR merilis 5.30.0 hingga 5.36.0, dan 6.2.0 hingga 6.9.0, Anda mungkin mengalami masalah yang mencegah klaster membaca data dengan benar. 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 dari. s3://bucket/table/p=a b

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

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