Amazon EMR merilis 6.1.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

• Flink versi 1.11.0

• Ganglia versi 3.7.2

• Hadoop versi 3.2.1-amzn-1

• HBase versi 2.2.5

• HBase-operator-tools 1.0.0

• HCatalogversi 3.1.2-amzn-0

• Hive versi 3.1.2-amzn-1

• Hudi versi 0.5.2-incubating

• Hue versi 4.7.1

• JupyterHub versi 1.1.0

• Livy versi 0.7.0

• MXNetversi 1.6.0

• Oozie versi 5.2.0

• Phoenix versi 5.0.0

• Presto versi 0.232

• Presto SQL versi 338

• Spark versi 3.0.0-amzn-0

• TensorFlow versi 2.1.0

• Zeppelin versi 0.9.0-preview1

• Zookeeper versi 3.4.14

• Konektor dan driver: DynamoDB Connector 4.14.0

Fitur baru

• ARMJenis instans didukung mulai dari Amazon EMR versi 5.30.0 dan Amazon EMR versi 6.1.0.

• Jenis instans tujuan umum M6g didukung mulai dari Amazon EMR versi 6.1.0 dan 5.30.0. Untuk informasi selengkapnya, lihat Jenis Instans yang Didukung di Panduan EMR Manajemen Amazon.

• Fitur grup EC2 penempatan didukung dimulai dengan Amazon EMR versi 5.23.0 sebagai opsi untuk beberapa cluster node utama. Saat ini, hanya tipe node primer yang didukung oleh fitur grup penempatan, dan SPREAD strategi diterapkan pada node utama tersebut. SPREADStrategi ini menempatkan sekelompok kecil instance di perangkat keras dasar yang terpisah untuk mencegah hilangnya beberapa node primer jika terjadi kegagalan perangkat keras. Untuk informasi selengkapnya, lihat EMRIntegrasi dengan Grup EC2 Penempatan di Panduan EMR Manajemen Amazon.

• Penskalaan Terkelola — Dengan Amazon EMR versi 6.1.0, Anda dapat mengaktifkan penskalaan EMR terkelola Amazon untuk secara otomatis menambah atau mengurangi jumlah instans atau unit di klaster berdasarkan beban kerja. Amazon EMR terus mengevaluasi metrik klaster untuk membuat keputusan penskalaan yang mengoptimalkan kluster Anda untuk biaya dan kecepatan. Penskalaan Terkelola juga tersedia di Amazon EMR versi 5.30.0 dan yang lebih baru, kecuali 6.0.0. Untuk informasi selengkapnya, lihat Penskalaan Sumber Daya Cluster di Panduan EMR Manajemen Amazon.

• Presto SQL versi 338 didukung dengan EMR 6.1.0. Untuk informasi selengkapnya, lihat Presto.

  • Presto SQL didukung pada versi EMR 6.1.0 dan yang lebih baru saja, bukan pada EMR 6.0.0 atau 5.x. EMR

  • Nama aplikasi, Presto terus-menerus digunakan untuk menginstal PrestoDB pada klaster. Untuk menginstal Presto SQL pada cluster, gunakan nama aplikasi. PrestoSQL

  • Anda dapat menginstal baik PrestoDB atau SQL Presto, tetapi Anda tidak dapat menginstal keduanya pada satu cluster. Jika PrestODB dan SQL Presto ditentukan saat mencoba membuat cluster, kesalahan validasi terjadi dan permintaan pembuatan cluster gagal.

  • Presto SQL didukung pada cluster single-master dan muti-master. Pada cluster multi-master, metastore Hive eksternal diperlukan untuk menjalankan Presto atau PrestoDB. SQL Lihat Aplikasi yang didukung dalam EMR klaster dengan beberapa node primer.

• ECRdukungan autentikasi auto pada Apache Hadoop dan Apache Spark dengan Docker: Pengguna Spark dapat menggunakan gambar Docker dari Docker Hub dan Amazon Elastic Container Registry (Amazon) untuk menentukan dependensi lingkungan dan perpustakaan. ECR

  Konfigurasikan Docker dan Jalankan Aplikasi Spark dengan Docker Menggunakan Amazon 6.x. EMR

• EMRmendukung ACID transaksi Apache Hive: Amazon EMR 6.1.0 menambahkan dukungan untuk ACID transaksi Hive sehingga sesuai dengan properti database. ACID Dengan fitur ini, Anda dapat menjalankan INSERT, UPDATE, DELETE, dan MERGE mengoperasikannya di tabel terkelola Hive dengan data di Amazon Simple Storage Service (Amazon S3). Ini adalah fitur utama untuk kasus penggunaan seperti konsumsi streaming, penyajian ulang data, pembaruan massal menggunakanMERGE, dan dimensi yang berubah secara perlahan. Untuk informasi selengkapnya, termasuk contoh konfigurasi dan kasus penggunaan, lihat Amazon EMR mendukung transaksi Apache Hive ACID.

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.

• Apache Flink tidak didukung pada EMR 6.0.0, tetapi didukung pada 6.1.0 dengan Flink EMR 1.11.0. Ini adalah versi pertama Flink yang secara resmi mendukung Hadoop 3. Lihat Pengumuman Rilis Apache Flink 1.11.0.

• Ganglia telah dihapus dari bundel paket EMR 6.1.0 default.

Masalah yang diketahui

• 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

• Jika Anda mengatur konfigurasi pengumpulan sampah khusus dengan spark.driver.extraJavaOptions danspark.executor.extraJavaOptions, ini akan mengakibatkan kegagalan peluncuran driver/pelaksana dengan EMR 6.1 karena konfigurasi pengumpulan sampah yang bertentangan. Dengan EMR Release 6.1.0, Anda harus menentukan konfigurasi pengumpulan sampah Spark khusus untuk driver dan pelaksana dengan properti dan sebagai gantinya. spark.driver.defaultJavaOptions spark.executor.defaultJavaOptions Baca selengkapnya di Apache Spark Runtime Environment dan Mengkonfigurasi Spark Garbage Collection di Amazon 6.1.0. EMR

• Menggunakan Pig dengan Oozie (dan dalam Hue, karena Hue menggunakan tindakan Oozie untuk menjalankan skrip Pig), akan menghasilkan kesalahan di mana perpustakaan native-lzo tidak dapat dimuat. Pesan kesalahan ini adalah informasi dan tidak memblokir Pig sehingga tidak berjalan.

• Hudi Concurrency Support: Saat ini Hudi tidak mendukung tulis bersamaan ke tabel Hudi tunggal. Selain itu, Hudi membatalkan setiap perubahan yang dilakukan oleh penulis yang sedang berlangsung sebelum mengizinkan penulis baru untuk memulai. Tulis bersamaan dapat mengganggu mekanisme ini dan memperkenalkan kondisi ras, yang dapat menyebabkan korupsi data. Anda harus memastikan bahwa sebagai bagian dari alur kerja pengolahan data Anda, hanya ada satu penulis Hudi yang beroperasi terhadap tabel Hudi setiap saat. Hudi tidak mendukung beberapa pembaca bersamaan yang beroperasi terhadap tabel Hudi yang sama.

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

• Ada masalah di Amazon EMR 6.1.0 yang memengaruhi cluster yang menjalankan Presto. Setelah periode waktu yang lama (hari), klaster dapat memunculkan kesalahan seperti, “su: gagalexecute /bin/bash: Sumber daya sementara tidak tersedia” atau “permintaan shell gagal di saluran 0". Masalah ini disebabkan oleh EMR proses Amazon internal (InstanceController) yang menghasilkan terlalu banyak Proses Berat Ringan (LWP), yang akhirnya menyebabkan pengguna Hadoop melebihi batas nproc mereka. Hal ini mencegah pengguna dari membuka proses tambahan. Solusi untuk masalah ini adalah meningkatkan ke EMR 6.2.0.