Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Gunakan protokol komit yang dioptimalkan EMRFS S3
Protokol komit yang dioptimalkan EMRFS S3 adalah [FileCommitProtocol](https://spark.apache.org/docs/2.2.0//api/java/org/apache/spark/internal/io/FileCommitProtocol.html)implementasi alternatif yang dioptimalkan untuk menulis file dengan partisi dinamis Spark menimpa ke Amazon S3 saat menggunakan EMRFS. Protokol meningkatkan kinerja aplikasi dengan menghindari operasi ganti nama di Amazon S3 selama fase komit pekerjaan menimpa partisi dinamis Spark.
Perhatikan bahwa [committer yang dioptimalkan EMRFS S3](emr-spark-s3-optimized-committer.html) juga meningkatkan kinerja dengan menghindari operasi penggantian nama. Namun, ini tidak berfungsi untuk kasus penimpaan partisi dinamis, sedangkan peningkatan protokol komit hanya menargetkan kasus penimpaan partisi dinamis.
Protokol komit tersedia dengan Amazon EMR rilis 5.30.0 dan yang lebih baru dan 6.2.0 dan yang lebih baru dan diaktifkan secara default. Amazon EMR menambahkan peningkatan paralelisme dimulai dengan rilis 5.31.0. Protokol ini digunakan untuk pekerjaan Spark yang menggunakan Spark, DataFrames, atau Datasets. Ada keadaan di mana protokol komit tidak digunakan. Untuk informasi selengkapnya, lihat [Persyaratan untuk protokol komit yang dioptimalkan EMRFS S3](emr-spark-committer-reqs.md).
**Topics**
+ [
# Persyaratan untuk protokol komit yang dioptimalkan EMRFS S3
](emr-spark-commit-protocol-reqs.md)
+ [
# Protokol komit yang dioptimalkan EMRFS S3 dan unggahan multipart
](emr-spark-commit-protocol-multipart.md)
+ [
# Pertimbangan penyetelan Job
](emr-spark-commit-protocol-tuning.md)
# Persyaratan untuk protokol komit yang dioptimalkan EMRFS S3
Protokol komit yang dioptimalkan EMRFS S3 digunakan ketika kondisi berikut terpenuhi:
+ Anda menjalankan pekerjaan Spark yang menggunakan Spark, DataFrames, atau Datasets untuk menimpa tabel yang dipartisi.
+ Anda menjalankan pekerjaan Spark yang mode timpa partisi. `dynamic`
+ Multipart upload diaktifkan di Amazon EMR. Ini adalah opsi default. Untuk informasi selengkapnya, lihat [Protokol komit yang dioptimalkan EMRFS S3 dan unggahan multipart](emr-spark-commit-protocol-multipart.md).
+ Cache sistem file untuk EMRFS diaktifkan. Ini adalah opsi default. Periksa apakah pengaturan `fs.s3.impl.disable.cache` diatur ke`false`.
+ Dukungan sumber data bawaan Spark digunakan. Dukungan sumber data bawaan digunakan dalam keadaan berikut:
+ Ketika pekerjaan menulis ke sumber data bawaan atau tabel.
+ Ketika pekerjaan menulis ke meja Parket Hive metastore. Ini terjadi ketika `spark.sql.hive.convertInsertingPartitionedTable` dan `spark.sql.hive.convertMetastoreParquet` keduanya disetel ke true. Ini adalah pengaturan default.
+ Ketika pekerjaan menulis ke tabel ORC metastore Hive. Ini terjadi ketika `spark.sql.hive.convertInsertingPartitionedTable` dan `spark.sql.hive.convertMetastoreOrc` keduanya diatur ke`true`. Ini adalah pengaturan default.
+ Spark job operations yang menulis ke lokasi partisi default — misalnya, `${table_location}/k1=v1/k2=v2/` — menggunakan protokol commit. Protokol tidak digunakan jika operasi pekerjaan menulis ke lokasi partisi kustom - misalnya, jika lokasi partisi kustom diatur menggunakan `ALTER TABLE SQL` perintah.
+ Nilai berikut untuk Spark mesti digunakan:
+ `spark.sql.sources.commitProtocolClass` harus diatur ke `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol`. Ini adalah pengaturan default untuk Amazon EMR rilis 5.30.0 dan lebih tinggi, dan 6.2.0 dan lebih tinggi.
+ Opsi `partitionOverwriteMode` tulis atau `spark.sql.sources.partitionOverwriteMode` harus diatur ke`dynamic`. Pengaturan default-nya adalah `static`.
**catatan**
Parameter `partitionOverwriteMode` menulis opsi diperkenalkan di Spark 2.4.0. Untuk Spark versi 2.3.2, disertakan dengan rilis Amazon EMR 5.19.0, mengatur `spark.sql.sources.partitionOverwriteMode` properti.
+ Jika pekerjaan Spark menimpa ke meja Parket Hive metastore,, `spark.sql.hive.convertMetastoreParquet``spark.sql.hive.convertInsertingPartitionedTable`, dan harus diatur ke. `spark.sql.hive.convertMetastore.partitionOverwriteMode` `true` Ada pengaturan default.
+ Jika pekerjaan Spark menimpa ke tabel ORC metastore Hive,, `spark.sql.hive.convertMetastoreOrc``spark.sql.hive.convertInsertingPartitionedTable`, dan harus disetel ke. `spark.sql.hive.convertMetastore.partitionOverwriteMode` `true` Ada pengaturan default.
**Example — Mode penimpaan partisi dinamis**
Dalam contoh Scala ini, optimasi dipicu. Pertama, Anda mengatur `partitionOverwriteMode` properti ke`dynamic`. Ini hanya menimpa partisi yang Anda tulis data. Kemudian, Anda menentukan kolom partisi dinamis dengan `partitionBy` dan mengatur mode tulis ke`overwrite`.
```
val dataset = spark.range(0, 10)
.withColumn("dt", expr("date_sub(current_date(), id)"))
dataset.write.mode("overwrite") // "overwrite" instead of "insert"
.option("partitionOverwriteMode", "dynamic") // "dynamic" instead of "static"
.partitionBy("dt") // partitioned data instead of unpartitioned data
.parquet("s3://amzn-s3-demo-bucket1/output") // "s3://" to use Amazon EMR file system, instead of "s3a://" or "hdfs://"
```
## Ketika protokol komit yang dioptimalkan EMRFS S3 tidak digunakan
Umumnya, protokol komit yang dioptimalkan EMRFS S3 bekerja sama dengan protokol komit Spark default open source,. `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol` Optimasi tidak akan terjadi dalam situasi berikut.
****
| Situasi | Mengapa protokol komit tidak digunakan |
| --- | --- |
| Saat Anda menulis ke HDFS | Protokol komit hanya mendukung penulisan ke Amazon S3 menggunakan EMRFS. |
| Saat Anda menggunakan sistem file S3A | Protokol komit hanya mendukung EMRFS. |
| Saat Anda menggunakan MapReduce atau API RDD Spark | Protokol commit hanya mendukung penggunaan DataFrame SparkSQL,, atau Dataset. APIs |
| Saat penimpaan partisi dinamis tidak dipicu | Protokol komit hanya mengoptimalkan kasus penimpaan partisi dinamis. Untuk kasus lain, lihat[Gunakan committer yang dioptimalkan EMRFS S3](emr-spark-s3-optimized-committer.md). |
Contoh Scala berikut menunjukkan beberapa situasi tambahan yang didelegasikan oleh protokol komit yang dioptimalkan EMRFS S3. `SQLHadoopMapReduceCommitProtocol`
**Example - Mode penimpaan partisi dinamis dengan lokasi partisi khusus**
Dalam contoh ini, program Scala menimpa dua partisi dalam mode penimpaan partisi dinamis. Satu partisi memiliki lokasi partisi kustom. Partisi lain menggunakan lokasi partisi default. Protokol komit yang dioptimalkan EMRFS S3 hanya meningkatkan partisi yang menggunakan lokasi partisi default.
```
val table = "dataset"
val inputView = "tempView"
val location = "s3://bucket/table"
spark.sql(s"""
CREATE TABLE $table (id bigint, dt date)
USING PARQUET PARTITIONED BY (dt)
LOCATION '$location'
""")
// Add a partition using a custom location
val customPartitionLocation = "s3://bucket/custom"
spark.sql(s"""
ALTER TABLE $table ADD PARTITION (dt='2019-01-28')
LOCATION '$customPartitionLocation'
""")
// Add another partition using default location
spark.sql(s"ALTER TABLE $table ADD PARTITION (dt='2019-01-29')")
def asDate(text: String) = lit(text).cast("date")
spark.range(0, 10)
.withColumn("dt",
when($"id" > 4, asDate("2019-01-28")).otherwise(asDate("2019-01-29")))
.createTempView(inputView)
// Set partition overwrite mode to 'dynamic'
spark.sql(s"SET spark.sql.sources.partitionOverwriteMode=dynamic")
spark.sql(s"INSERT OVERWRITE TABLE $table SELECT * FROM $inputView")
```
Kode Scala menciptakan objek Amazon S3 berikut:
```
custom/part-00001-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
custom_$folder$
table/_SUCCESS
table/dt=2019-01-29/part-00000-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
table/dt=2019-01-29_$folder$
table_$folder$
```
Menulis ke lokasi partisi khusus di versi Spark sebelumnya dapat mengakibatkan kehilangan data. Dalam contoh ini, partisi `dt='2019-01-28'` akan hilang. Untuk lebih jelasnya, lihat [SPARK-35106](https://issues.apache.org/jira/browse/SPARK-35106). Ini diperbaiki di Amazon EMR rilis 5.33.0 dan yang lebih baru, tidak termasuk 6.0.x dan 6.1.x.
Ketika menulis ke partisi di lokasi kustom, Spark menggunakan algoritma komit mirip dengan contoh sebelumnya, yang diuraikan di bawah ini. Seperti contoh sebelumnya, algoritme menghasilkan penggantian nama berurutan, yang dapat berdampak negatif pada kinerja.
Algoritma di Spark 2.4.0 mengikuti langkah-langkah berikut:
1. Ketika menulis output ke partisi di lokasi kustom, tugas menulis ke file di bawah direktori pementasan Spark ini, yang dibuat di bawah lokasi output akhir. Nama file termasuk UUID acak untuk melindungi terhadap tabrakan file. Upaya tugas melacak setiap file bersama dengan path output akhir yang diinginkan.
1. Ketika tugas selesai berhasil, menyediakan driver dengan file dan akhir yang diinginkan output jalan mereka.
1. Setelah semua tugas selesai, pekerjaan commit fase berurutan mengganti nama semua file yang ditulis untuk partisi di lokasi kustom ke jalur output akhir mereka.
1. Direktori pementasan dihapus sebelum pekerjaan komit fase selesai.
# Protokol komit yang dioptimalkan EMRFS S3 dan unggahan multipart
Untuk menggunakan pengoptimalan untuk penimpaan partisi dinamis dalam protokol komit yang dioptimalkan EMRFS S3, unggahan multibagian harus diaktifkan di Amazon EMR. Unggahan multipart diaktifkan secara default. Anda dapat mengaktifkannya kembali jika diperlukan. Untuk informasi lebih lanjut, lihat [Konfigurasi unggahan multipart untuk Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) di *Amazon EMR*.
Selama penimpaan partisi dinamis, protokol komit yang dioptimalkan EMRFS S3 menggunakan karakteristik seperti transaksi dari unggahan multibagian untuk memastikan file yang ditulis oleh upaya tugas hanya muncul di lokasi output pekerjaan pada komit pekerjaan. Dengan menggunakan unggahan multibagian dengan cara ini, protokol komit meningkatkan kinerja komit pekerjaan di atas default. `SQLHadoopMapReduceCommitProtocol` Saat menggunakan protokol komit yang dioptimalkan EMRFS S3, ada beberapa perbedaan utama dari perilaku pengunggahan multibagian tradisional yang perlu dipertimbangkan:
+ Unggahan multipart selalu dilakukan terlepas dari ukuran file. Ini berbeda dari perilaku default EMRFS, di mana `fs.s3n.multipart.uploads.split.size` properti mengontrol ukuran file di mana multipart upload dipicu.
+ Multipart upload yang tersisa dalam keadaan tidak lengkap untuk jangka waktu yang lebih lama sampai tugas melakukan atau aborts. Ini berbeda dari perilaku default EMRFS di mana upload multipart selesai ketika tugas selesai menulis file yang diberikan.
Karena perbedaan ini, jika Spark Executor JVM mogok atau terbunuh saat tugas sedang berjalan dan menulis data ke Amazon S3, atau Spark Driver JVM mogok atau terbunuh saat pekerjaan sedang berjalan, unggahan multipart yang tidak lengkap lebih mungkin tertinggal. Untuk alasan ini, saat Anda menggunakan protokol komit yang dioptimalkan EMRFS S3, pastikan untuk mengikuti praktik terbaik untuk mengelola unggahan multipart yang gagal. Untuk informasi lebih lanjut, lihat [Praktik terbaik](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) Untuk bekerja dengan bucket Amazon S3 dalam aplikasi *Amazon EMR*.
# Pertimbangan penyetelan Job
Pada pelaksana Spark, protokol komit yang dioptimalkan EMRFS S3 menghabiskan sejumlah kecil memori untuk setiap file yang ditulis oleh upaya tugas sampai tugas dilakukan atau dibatalkan. Dalam kebanyakan pekerjaan, jumlah memori yang dikonsumsi dapat diabaikan.
Pada driver Spark, protokol komit yang dioptimalkan EMRFS S3 memerlukan memori untuk menyimpan info metadata dari setiap file yang dikomit hingga pekerjaan dikomit atau dibatalkan. Di sebagian besar pekerjaan, pengaturan memori driver Spark default dapat diabaikan.
Untuk pekerjaan yang memiliki tugas yang berjalan lama yang menulis sejumlah besar file, memori yang dikonsumsi protokol komit mungkin terlihat dan memerlukan penyesuaian pada memori yang dialokasikan untuk Spark, terutama untuk pelaksana Spark. Anda dapat menyetel memori menggunakan `spark.driver.memory` properti untuk driver Spark, dan `spark.executor.memory` properti untuk pelaksana Spark. Sebagai pedoman, tugas tunggal menulis 100.000 file biasanya akan memerlukan tambahan 100MB memori. Untuk informasi lebih lanjut, lihat [Properti aplikasi](https://spark.apache.org/docs/latest/configuration.html#application-properties) dalam dokumentasi Apache Spark Configuration.