Pertimbangan EMR Studio - Amazon EMR

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pertimbangan EMR Studio

Pertimbangan

Pertimbangkan hal berikut ketika Anda bekerja dengan EMR Studio:

  • EMR Studio tersedia sebagai berikut: Wilayah AWS

    • AS Timur (Ohio) (us-east-2)

    • AS Timur (Virginia Utara) (us-east-1)

    • AS Barat (California Utara) (us-west-1)

    • AS Barat (Oregon) (us-west-2)

    • Africa (Cape Town) (af-south-1)

    • Asia Pacific (Hong Kong) (ap-east-1)

    • Asia Pasifik (Jakarta) (ap-southeast-3) *

    • Asia Pasifik (Melbourne) (ap-southeast-4) *

    • Asia Pasifik (Mumbai) (ap-south-1)

    • Asia Pasifik (Osaka) (ap-northeast-3) *

    • Asia Pasifik (Seoul) (ap-northeast-2)

    • Asia Pasifik (Singapura) (ap-southeast-1)

    • Asia Pacific (Sydney) (ap-southeast-2)

    • Asia Pacific (Tokyo) (ap-northeast-1)

    • Kanada (Pusat) (ca-central-1)

    • Eropa (Frankfurt) (eu-central-1)

    • Eropa (Irlandia) (eu-west-1)

    • Eropa (London) (eu-west-2)

    • Europe (Milan) (eu-south-1)

    • Eropa (Paris) (eu-west-3)

    • Eropa (Spanyol) (eu-south-2)

    • Eropa (Stockholm) (eu-north-1)

    • Eropa (Zurich) (eu-central-2) *

    • Israel (Tel Aviv) (il-central-1) *

    • Timur Tengah (UEA) (me-central-1) *

    • Amerika Selatan (Sao Paulo) (sa-east-1)

    • AWS GovCloud (AS-Timur) (gov-us-east-1)

    • AWS GovCloud (AS-Barat) (gov-us-west-1)

    * UI Spark langsung tidak didukung di Wilayah ini.

  • Agar pengguna dapat menyediakan kluster EMR baru yang berjalan di Amazon EC2 untuk Workspace, Anda dapat mengaitkan EMR Studio dengan sekumpulan templat klaster. Administrator dapat menentukan template cluster dengan Service Catalog dan dapat memilih apakah pengguna atau grup dapat mengakses template cluster, atau tidak ada template cluster, di dalam Studio.

  • Saat Anda menentukan izin akses ke file notebook yang disimpan di Amazon S3 atau membaca rahasia, gunakan AWS Secrets Manager peran layanan Amazon EMR. Kebijakan sesi tidak didukung dengan izin ini.

  • Anda dapat membuat beberapa EMR Studios untuk mengontrol akses ke cluster EMR di VPC yang berbeda.

  • Gunakan AWS CLI untuk mengatur Amazon EMR di kluster EKS. Anda kemudian dapat menggunakan antarmuka Studio untuk melampirkan cluster ke Workspaces dengan endpoint terkelola untuk menjalankan pekerjaan notebook.

  • Ada pertimbangan tambahan ketika Anda menggunakan propagasi identitas tepercaya dengan Amazon EMR yang juga berlaku untuk EMR Studio. Untuk informasi selengkapnya, lihat Pertimbangan dan batasan untuk Amazon EMR dengan integrasi Pusat Identitas.

  • EMR Studio tidak mendukung perintah ajaib Python berikut:

    • %alias

    • %alias_magic

    • %automagic

    • %macro

    • %%js

    • %%javascript

    • Memodifikasi proxy_user menggunakan %configure

    • Memodifikasi KERNEL_USERNAME menggunakan %env atau %set_env

  • Amazon EMR di kluster EKS tidak mendukung perintah SparkMagic untuk EMR Studio.

  • Untuk menulis pernyataan Scala multi-baris di sel notebook, pastikan bahwa semua kecuali baris terakhir berakhir dengan titik. Contoh berikut menggunakan sintaks yang benar untuk pernyataan Scala multi-baris.

    val df = spark.sql("SELECT * from table_name). filter("col1=='value'"). limit(50)
  • Untuk meningkatkan keamanan aplikasi off-console yang mungkin Anda gunakan dengan Amazon EMR, domain hosting aplikasi terdaftar di Daftar Akhiran Publik (PSL). Contoh domain hosting ini meliputi:emrstudio-prod.us-east-1.amazonaws.com,emrnotebooks-prod.us-east-1.amazonaws.com,emrappui-prod.us-east-1.amazonaws.com. Untuk keamanan lebih lanjut, jika Anda perlu mengatur cookie sensitif di nama domain default, kami sarankan Anda menggunakan cookie dengan __Host- awalan. Ini membantu mempertahankan domain Anda dari upaya pemalsuan permintaan lintas situs (CSRF). Untuk informasi selengkapnya, lihat Set-Cookiehalaman di Jaringan Pengembang Mozilla.

Masalah yang diketahui

  • Studio EMR yang menggunakan Pusat Identitas IAM dengan propagasi identitas tepercaya diaktifkan hanya dapat dikaitkan dengan kluster EMR yang juga menggunakan propagasi identitas tepercaya.

  • Pastikan Anda menonaktifkan alat manajemen proxy seperti FoxyProxy atau SwitchyOmega di browser sebelum membuat Studio. Proksi aktif dapat menyebabkan kesalahan saat Anda memilih Buat Studio, dan menghasilkan pesan galat Kegagalan Jaringan.

  • Kernel yang berjalan di Amazon EMR di kluster EKS dapat gagal dimulai karena masalah batas waktu. Jika Anda mengalami kesalahan atau masalah saat memulai kernel, tutup file notebook, matikan kernel, lalu buka kembali file notebook.

  • Operasi kernel Restart tidak berfungsi seperti yang diharapkan saat Anda menggunakan EMR Amazon di kluster EKS. Setelah Anda memilih Restart kernel, segarkan Workspace agar restart diterapkan.

  • Jika Workspace tidak dilampirkan ke klaster, pesan kesalahan akan muncul saat pengguna Studio membuka file notebook dan mencoba memilih kernel. Anda dapat mengabaikan pesan kesalahan ini dengan memilih Oke, tetapi Anda harus melampirkan Workspace ke klaster dan memilih kernel agar Anda dapat menjalankan kode notebook.

  • Saat Anda menggunakan Amazon EMR 6.2.0 dengan konfigurasi keamanan untuk mengatur keamanan klaster, antarmuka Workspace tampak kosong dan tidak berfungsi seperti yang diharapkan. Kami menyarankan Anda menggunakan versi Amazon EMR yang didukung berbeda jika Anda ingin mengonfigurasi enkripsi data atau otorisasi Amazon S3 untuk EMRFS untuk klaster. EMR Studio bekerja dengan Amazon EMR versi 5.32.0 (Amazon EMR 5.x series) dan 6.2.0 (Amazon EMR 6.x series) dan lebih tinggi.

  • Saat Anda Debug Amazon EMR berjalan di pekerjaan Amazon EC2, tautan ke Spark UI pada klaster mungkin tidak bekerja atau gagal untuk muncul. Untuk meregenerasi tautan, buat sel notebook baru dan jalankan perintah %%info.

  • Jupyter Enterprise Gateway tidak membersihkan kernel idle pada node utama cluster dalam versi rilis Amazon EMR berikut: 5.32.0, 5.33.0, 6.2.0, dan 6.3.0. Kernel idle mengkonsumsi sumber daya komputasi dan dapat menyebabkan cluster yang berjalan lama gagal. Anda dapat mengonfigurasi pembersihan kernel idle untuk Jupyter Enterprise Gateway menggunakan contoh skrip berikut. Anda dapat Connect ke node utama menggunakan SSH, atau mengirimkan skrip sebagai langkah. Untuk informasi selengkapnya, lihat Menjalankan perintah dan skrip di klaster EMR Amazon.

    #!/bin/bash sudo tee -a /emr/notebook-env/conf/jupyter_enterprise_gateway_config.py << EOF c.MappingKernelManager.cull_connected = True c.MappingKernelManager.cull_idle_timeout = 10800 c.MappingKernelManager.cull_interval = 300 EOF sudo systemctl daemon-reload sudo systemctl restart jupyter_enterprise_gateway
  • Saat Anda menggunakan kebijakan penghentian otomatis dengan Amazon EMR versi 5.32.0, 5.33.0, 6.2.0, atau 6.3.0, Amazon EMR menandai klaster sebagai idle dan dapat menghentikan klaster secara otomatis meskipun Anda memiliki kernel Python3 yang aktif. Ini karena menjalankan kernel Python3 tidak mengirimkan pekerjaan Spark di cluster. Untuk menggunakan penghentian otomatis dengan kernel Python3, sebaiknya gunakan Amazon EMR versi 6.4.0 atau yang lebih baru. Untuk informasi selengkapnya tentang penghentian otomatis, lihatMenggunakan kebijakan penghentian otomatis.

  • Saat Anda menggunakan %%display untuk menampilkan Spark DataFrame dalam tabel, tabel yang sangat lebar mungkin terpotong. Anda dapat mengklik kanan output dan memilih Buat Tampilan Baru untuk Output untuk mendapatkan tampilan output yang dapat digulir.

  • Memulai kernel berbasis Spark, seperti, Spark PySpark, atau SparkR, memulai sesi Spark, dan menjalankan sel di notebook mengantri pekerjaan Spark di sesi itu. Saat Anda mengganggu sel yang sedang berjalan, pekerjaan Spark terus berjalan. Untuk menghentikan pekerjaan Spark, Anda harus menggunakan UI Spark on-cluster. Untuk petunjuk tentang cara menyambung ke UI Spark, lihatDebug aplikasi dan pekerjaan dengan Studio EMR.

  • Menggunakan Amazon EMR Studio Workspaces sebagai pengguna root Akun AWS menyebabkan kesalahan. 403: Forbidden Ini karena konfigurasi Jupyter Enterprise Gateway di Amazon EMR tidak mengizinkan akses ke pengguna root. Kami menyarankan Anda untuk tidak menggunakan pengguna root untuk tugas sehari-hari Anda. Untuk opsi otentikasi lainnya, lihat AWS Identity and Access Management Amazon EMR.

Batasan fitur

Amazon EMR Studio tidak mendukung fitur Amazon EMR berikut:

  • Melampirkan dan menjalankan pekerjaan pada cluster EMR dengan konfigurasi keamanan yang menentukan otentikasi Kerberos

  • Cluster dengan beberapa node primer

  • Cluster yang menggunakan instans Amazon EC2 berdasarkan AWS Graviton2 untuk Amazon EMR 6.x rilis lebih rendah dari 6.9.0, dan rilis 5.x lebih rendah dari 5.36.1

Fitur berikut tidak didukung dari Studio yang menggunakan propagasi identitas tepercaya:

  • Membuat cluster EMR tanpa template.

  • Menggunakan aplikasi EMR Tanpa Server.

  • Meluncurkan Amazon EMR di kluster EKS.

  • Menggunakan peran runtime.

  • Mengaktifkan kolaborasi SQL Explorer atau Workspace.

Kuota layanan untuk EMR Studio

Tabel berikut menampilkan batas layanan untuk EMR Studio.

Item Kuota
EMR Studio Maksimal 100 per AWS akun
Subnet Maksimum 5 yang terkait dengan setiap EMR Studio
Grup Pusat Identitas IAM Maksimum 5 yang ditetapkan untuk setiap EMR Studio
Pengguna Pusat Identitas IAM Maksimum 100 yang ditetapkan untuk setiap EMR Studio

Praktik terbaik VPC dan subnet

Gunakan praktik terbaik berikut untuk menyiapkan Amazon Virtual Private Cloud (Amazon VPC) dengan subnet untuk EMR Studio:

  • Anda dapat menentukan maksimal lima subnet di VPC Anda untuk diasosiasikan dengan Studio. Kami menyarankan Anda menyediakan beberapa subnet di Availability Zone yang berbeda untuk mendukung ketersediaan Workspace dan memberi pengguna Studio akses ke cluster di berbagai Availability Zone. Untuk mempelajari lebih lanjut tentang bekerja dengan VPC, subnet, dan Availability Zone, lihat VPC dan subnet di Panduan Pengguna.Amazon Virtual Private Cloud

  • Subnet yang Anda tentukan harus dapat berkomunikasi satu sama lain.

  • Untuk memungkinkan pengguna menautkan Workspace ke repositori Git yang dihosting publik, Anda harus menentukan hanya subnet pribadi yang memiliki akses ke internet melalui Network Address Translation (NAT). Untuk informasi selengkapnya tentang menyiapkan subnet pribadi untuk Amazon EMR, lihat. Subnet privat

  • Saat Anda menggunakan Amazon EMR di EKS dengan EMR Studio, setidaknya harus ada satu subnet yang sama antara Studio Anda dan klaster Amazon EKS yang Anda gunakan untuk mendaftarkan cluster virtual. Jika tidak, endpoint terkelola Anda tidak akan muncul sebagai opsi di Studio Workspaces. Anda dapat membuat klaster Amazon EKS dan mengaitkannya dengan subnet milik Studio, atau membuat Studio dan menentukan subnet kluster EKS Anda.

  • Jika Anda berencana untuk menggunakan Amazon Amazon EMR di EKS dengan EMR Studio, pilih VPC yang sama dengan node pekerja klaster Amazon EKS Anda.

Persyaratan klaster untuk Amazon EMR Studio

Cluster EMR Amazon Berjalan di Amazon EC2

Semua klaster Amazon EMR yang berjalan di Amazon EC2 yang Anda buat untuk EMR Studio Workspace harus memenuhi persyaratan berikut. Cluster yang Anda buat menggunakan antarmuka EMR Studio secara otomatis memenuhi persyaratan ini.

  • Cluster harus menggunakan Amazon EMR versi 5.32.0 (Amazon EMR 5.x series) atau 6.2.0 (Amazon EMR 6.x series) atau yang lebih baru. Anda dapat membuat klaster menggunakan konsol Amazon EMR, atau SDK AWS Command Line Interface, lalu melampirkannya ke EMR Studio Workspace. Pengguna studio juga dapat menyediakan dan melampirkan cluster saat membuat atau bekerja di Amazon EMR Workspace. Untuk informasi selengkapnya, lihat Melampirkan komputasi ke Ruang Kerja EMR Studio.

  • Cluster harus berada dalam Amazon Virtual Private Cloud. Platform EC2-Classic tidak didukung.

  • Cluster harus menginstal Spark, Livy, dan Jupyter Enterprise Gateway. Jika Anda berencana untuk menggunakan cluster untuk SQL Explorer, Anda harus menginstal Presto dan Spark.

  • Untuk menggunakan SQL Explorer, cluster harus menggunakan Amazon EMR versi 5.34.0 atau yang lebih baru atau versi 6.4.0 atau yang lebih baru dan memiliki Presto diinstal. Jika Anda ingin menentukan Katalog Data AWS Glue sebagai metastore Hive untuk Presto, Anda harus mengkonfigurasinya di cluster. Untuk informasi selengkapnya, lihat Menggunakan Presto dengan Katalog Glue Data AWS.

  • Cluster harus berada dalam subnet pribadi dengan terjemahan alamat jaringan (NAT) untuk menggunakan repositori Git yang dihosting publik dengan EMR Studio.

Kami merekomendasikan konfigurasi klaster berikut saat Anda bekerja dengan EMR Studio.

  • Setel mode penerapan untuk sesi Spark ke mode cluster. Mode cluster menempatkan proses master aplikasi pada node inti dan bukan pada node utama cluster. Melakukannya mengurangi simpul utama dari tekanan memori potensial. Untuk informasi selengkapnya, lihat Gambaran Umum Mode Cluster di dokumentasi Apache Spark.

  • Ubah batas waktu Livy dari default satu jam menjadi enam jam seperti pada konfigurasi contoh berikut.

    { "classification":"livy-conf", "Properties":{ "livy.server.session.timeout":"6h", "livy.spark.deploy-mode":"cluster" } }
  • Buat armada instans yang beragam dengan hingga 30 instans, dan pilih beberapa jenis instans di armada Instans Spot Anda. Misalnya, Anda dapat menentukan jenis instance yang dioptimalkan memori berikut untuk beban kerja Spark: r5.2x, r5.4x, r5.8x, r5.12x, r5.16x, r4.2x, r4.4x, r4.8x, r4.12, dll. Untuk informasi selengkapnya, lihat Mengkonfigurasi armada instans.

  • Gunakan strategi alokasi yang dioptimalkan kapasitas untuk Instans Spot untuk membantu Amazon EMR membuat pilihan instans yang efektif berdasarkan wawasan kapasitas real-time dari Amazon EC2. Untuk informasi selengkapnya, lihat Strategi alokasi untuk armada instans.

  • Aktifkan penskalaan terkelola di klaster Anda. Tetapkan parameter node inti maksimum ke kapasitas persisten minimum yang Anda rencanakan untuk digunakan, dan konfigurasikan penskalaan pada armada tugas yang terdiversifikasi dengan baik yang berjalan di Instans Spot untuk menghemat biaya. Untuk informasi selengkapnya, lihat Menggunakan penskalaan terkelola di Amazon EMR.

Kami juga mendorong Anda untuk menjaga Amazon EMR Block Public Access diaktifkan, dan itu untuk membatasi lalu lintas SSH masuk ke sumber tepercaya. Akses masuk ke klaster memungkinkan pengguna menjalankan notebook pada klaster. Untuk informasi lebih lanjut, lihat Menggunakan Amazon EMR memblokir akses publik dan Mengendalikan lalu lintas jaringan dengan grup keamanan.

Amazon EMR di Kluster EKS

Selain klaster EMR yang berjalan di Amazon EC2, Anda dapat menyiapkan dan mengelola Amazon EMR pada klaster EKS untuk EMR Studio menggunakan AWS CLI. Siapkan Amazon EMR di kluster EKS menggunakan pedoman berikut:

  • Buat titik akhir HTTPS terkelola untuk EMR Amazon di kluster EKS. Pengguna melampirkan Workspace ke endpoint terkelola. Cluster Amazon Elastic Kubernetes Service (EKS) yang Anda gunakan untuk mendaftarkan klaster virtual harus memiliki subnet pribadi untuk mendukung endpoint terkelola.

  • Gunakan klaster Amazon EKS dengan setidaknya satu subnet pribadi dan terjemahan alamat jaringan (NAT) saat Anda ingin menggunakan repositori Git yang dihosting publik.

  • Hindari penggunaan AMI Linux Arm Amazon Amazon Amazon yang dioptimalkan Amazon EKS, yang tidak didukung untuk Amazon EMR pada titik akhir yang dikelola EKS.

  • Hindari menggunakan kluster Amazon EKS AWS Fargate-only, yang tidak didukung.