Amazon EMR rilis 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 untuk 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

• HBase versi 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalog versi 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

• MXNet versi 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

• PrestoSQL 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 HFile Pelacakan Persisten di Panduan Rilis EMR 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 cakupan: Untuk menyelaraskan dengan praktik AWS terbaik, Amazon EMR telah memperkenalkan kebijakan terkelola default cakupan EMR v2 sebagai pengganti kebijakan yang tidak digunakan lagi. Lihat Kebijakan Terkelola Amazon EMR.

• Status dukungan Instance Metadata Service (IMDS) V2: Untuk Amazon EMR 6.2 atau yang lebih baru, komponen EMR Amazon digunakan untuk semua panggilan IMDS. IMDSv2 Untuk panggilan IMDS dalam kode aplikasi Anda, Anda dapat menggunakan keduanya IMDSv1 dan IMDSv2, atau mengkonfigurasi IMDS untuk digunakan hanya IMDSv2 untuk keamanan tambahan. Jika Anda menonaktifkan IMDSv1 di 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 skala cluster dengan sukses atau menyebabkan kegagalan aplikasi.

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

• 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.

• BENANG 9011. Memperbaiki masalah di mana 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 klaster dengan memastikan bahwa status node selalu konsisten antara daemon on-cluster EMR Amazon dan YARN/HDFS.

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

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

• 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 lain UIs, 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.

• Ada masalah pada Amazon EMR 6.2.0 di mana httpd terus-menerus gagal, sehingga 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 pada Amazon EMR 6.3.0.

• HTTPD gagal pada klaster EMR 6.2.0 ketika 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 cluster Anda, lihat Connect to the Primary Node Using SSH.

  EMR Notebooks juga gagal untuk membuat sambungan dengan klaster EMR 6.2.0 bila Anda menggunakan konfigurasi keamanan. Notebook tersebut akan gagal untuk membuat daftar kernel dan mengirimkan tugas Spark. Kami merekomendasikan agar Anda menggunakan EMR Notebooks dengan Amazon EMR versi lainnya sebagai gantinya.

• Turunkan batas “Maks open files” pada yang lebih lama AL2 [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 dari Amazon Linux 2 (), yang memiliki pengaturan ulimit yang lebih rendah untuk “File terbuka maksimum” ketika kluster Amazon EMR dibuat dengan AMI default. AL2 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 “File terbuka maksimum,” yang lebih rendah dari batas file 65536 di AMI Amazon Linux 2 terbaruAmazon. 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 EMR Amazon yang lebih lama yang tidak memiliki perbaikan permanen untuk masalah ini, solusi berikut memungkinkan Anda untuk secara eksplisit mengatur 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 mempunyai masalah performa yang secara kritis dapat mempengaruhi semua operasi insert, upsert, dan delete Hudi. Jika Anda berencana untuk menggunakan Hudi dengan Amazon EMR 6.1.0 atau 6.2.0, Anda harus AWS menghubungi dukungan untuk mendapatkan RPM Hudi yang ditambal.

• penting

  Cluster EMR 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 AMI Amazon Linux default. Jika pembaruan perangkat lunak Amazon Linux baru yang memerlukan reboot (seperti pembaruan kernel, NVIDIA, dan CUDA) tersedia setelah rilis EMR Amazon tersedia, instance 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.

• Artefak Amazon EMR 6.2.0 Maven tidak dipublikasikan. Ia akan diterbitkan dengan rilis Amazon EMR yang akan datang.

• HFile Pelacakan 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 bucket Amazon EMR 6.x dan EMR 5.x Hive

  EMR 5.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 bucket antara Hive 2 (EMR 5.x) dan Hive 3 (EMR 6.x) berarti pem-bucket-an Hive melakukan hashing fungsi yang berbeda. Lihat contoh di bawah ini.

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

  -- 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 pem-bucket-an yang berbeda, karena fungsi hashing yang berbeda antara EMR 6.x (Hive 3) dan EMR 5.x (Hive 2).

  [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 Amazon EMR 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:

  • SSH sebagai hadoop pengguna ke node utama utama dari cluster EMR 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 rilis 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 tabel pengkodean UTF-8 dan karakter Unicode.

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