.compression-codec` Kami menyarankan Anda menggunakan codec kompresi ZSTD untuk meningkatkan kinerja keseluruhan pada tabel.
Secara default, Iceberg versi 1.3 dan sebelumnya menggunakan kompresi GZIP, yang memberikan read/write kinerja lebih lambat dibandingkan dengan ZSTD.
Catatan: Beberapa mesin mungkin menggunakan nilai default yang berbeda. Ini adalah kasus untuk [tabel Iceberg yang dibuat dengan Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html) atau Amazon EMR versi 7.x.
## Mengatur urutan sortir
Untuk meningkatkan kinerja baca pada tabel Iceberg, sebaiknya Anda mengurutkan tabel berdasarkan satu atau beberapa kolom yang sering digunakan dalam filter kueri. Penyortiran, dikombinasikan dengan statistik kolom Iceberg, dapat membuat pemangkasan file secara signifikan lebih efisien, yang menghasilkan operasi pembacaan yang lebih cepat. Penyortiran juga mengurangi jumlah permintaan Amazon S3 untuk kueri yang menggunakan kolom pengurutan dalam filter kueri.
Anda dapat mengatur urutan hierarkis di tingkat tabel dengan menjalankan pernyataan data definition language (DDL) dengan Spark. Untuk opsi yang tersedia, lihat dokumentasi [Iceberg](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by). Setelah Anda mengatur urutan pengurutan, penulis akan menerapkan penyortiran ini ke operasi penulisan data berikutnya di tabel Iceberg.
Misalnya, dalam tabel yang dipartisi berdasarkan date (`yyyy-mm-dd`) di mana sebagian besar kueri difilter`uuid`, Anda dapat menggunakan opsi DDL `Write Distributed By Partition Locally Ordered` untuk memastikan bahwa Spark menulis file dengan rentang yang tidak tumpang tindih.
Diagram berikut menggambarkan bagaimana efisiensi statistik kolom meningkat ketika tabel diurutkan. Dalam contoh, tabel yang diurutkan hanya perlu membuka satu file, dan manfaat maksimal dari partisi dan file Iceberg. Dalam tabel yang tidak disortir, apa pun `uuid` berpotensi ada di file data apa pun, sehingga kueri harus membuka semua file data.
![\[Mengatur urutan pengurutan dalam tabel Iceberg\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png)
Mengubah urutan pengurutan tidak memengaruhi file data yang ada. Anda dapat menggunakan pemadatan Iceberg untuk menerapkan urutan pengurutan pada itu.
Menggunakan tabel yang diurutkan Iceberg dapat mengurangi biaya untuk beban kerja Anda, seperti yang diilustrasikan dalam grafik berikut.
![\[Biaya perbandingan untuk tabel Iceberg dan Parket\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png)
Grafik ini merangkum hasil menjalankan benchmark TPC-H untuk tabel Hive (Parquet) dibandingkan dengan tabel yang diurutkan Iceberg. Namun, hasilnya mungkin berbeda untuk kumpulan data atau beban kerja lainnya.
![\[Hasil benchmark TPC-H untuk tabel Parket vs Iceberg\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png)
# Mengoptimalkan kinerja tulis
Bagian ini membahas properti tabel yang dapat Anda atur untuk mengoptimalkan kinerja tulis pada tabel Iceberg, terlepas dari mesin.
## Mengatur modus distribusi tabel
Iceberg menawarkan beberapa mode distribusi tulis yang menentukan bagaimana data tulis didistribusikan di seluruh tugas Spark. Untuk gambaran umum tentang mode yang tersedia, lihat [Menulis Mode Distribusi](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) dalam dokumentasi Gunung Es.
Untuk kasus penggunaan yang memprioritaskan kecepatan tulis, terutama dalam beban kerja streaming, atur ke. `write.distribution-mode` `none` Ini memastikan bahwa Iceberg tidak meminta pengocokan Spark tambahan dan data tersebut ditulis saat tersedia dalam tugas Spark. Mode ini sangat cocok untuk aplikasi Streaming Terstruktur Spark.
**catatan**
Mengatur mode distribusi tulis `none` cenderung menghasilkan banyak file kecil, yang menurunkan kinerja baca. Kami merekomendasikan pemadatan reguler untuk mengkonsolidasikan file-file kecil ini ke dalam file berukuran benar untuk kinerja kueri.
## Pilih strategi pembaruan yang tepat
Gunakan merge-on-read**** strategi untuk mengoptimalkan kinerja penulisan, ketika operasi baca yang lebih lambat pada data terbaru dapat diterima untuk kasus penggunaan Anda.
Saat Anda menggunakan merge-on-read, Iceberg menulis pembaruan dan menghapus ke penyimpanan sebagai file kecil yang terpisah. Saat tabel dibaca, pembaca harus menggabungkan perubahan ini dengan file dasar untuk mengembalikan tampilan data terbaru. Ini menghasilkan penalti kinerja untuk operasi baca, tetapi mempercepat penulisan pembaruan dan penghapusan. Biasanya, merge-on-read sangat ideal untuk streaming beban kerja dengan pembaruan atau pekerjaan dengan beberapa pembaruan yang tersebar di banyak partisi tabel.
Anda dapat mengatur merge-on-read konfigurasi (`write.update.mode`,`write.delete.mode`, dan`write.merge.mode`) di tingkat tabel atau secara independen di sisi aplikasi.
Menggunakan merge-on-read membutuhkan menjalankan pemadatan reguler untuk mencegah kinerja baca menurun dari waktu ke waktu. Pemadatan merekonsiliasi pembaruan dan penghapusan dengan file data yang ada untuk membuat kumpulan file data baru, sehingga menghilangkan penalti kinerja yang terjadi di sisi baca. [Secara default, pemadatan Iceberg tidak menggabungkan file hapus kecuali Anda mengubah default `delete-file-threshold` properti ke nilai yang lebih kecil (lihat dokumentasi Iceberg).](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files) Untuk mempelajari lebih lanjut tentang pemadatan, lihat bagian [Pemadatan gunung es](best-practices-compaction.md) nanti di panduan ini.
## Pilih format file yang tepat
Iceberg mendukung penulisan data dalam format Parket, ORC, dan Avro. Parket adalah format default. Parket dan ORC adalah format kolom yang menawarkan kinerja baca yang unggul tetapi umumnya lebih lambat untuk ditulis. Ini mewakili trade-off khas antara kinerja baca dan tulis.
Jika kecepatan tulis penting untuk kasus penggunaan Anda, seperti dalam beban kerja streaming, pertimbangkan untuk menulis dalam format Avro dengan menyetel `write-format` ke `Avro` opsi penulis. Karena Avro adalah format berbasis baris, Avro memberikan waktu tulis yang lebih cepat dengan mengorbankan kinerja baca yang lebih lambat.
Untuk meningkatkan kinerja baca, jalankan pemadatan reguler untuk menggabungkan dan mengubah file Avro kecil menjadi file Parket yang lebih besar. Hasil dari proses pemadatan diatur oleh pengaturan `write.format.default` tabel. Format default untuk Iceberg adalah Parquet, jadi jika Anda menulis di Avro dan kemudian menjalankan pemadatan, Iceberg akan mengubah file Avro menjadi file Parket. Inilah contohnya:
```
spark.sql(f"""
CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} (
Col_1 float,
<<<…other columns…>>
ts timestamp)
USING iceberg
PARTITIONED BY (days(ts))
OPTIONS (
'format-version'='2',
write.format.default'=parquet)
""")
query = df \
.writeStream \
.format("iceberg") \
.option("write-format", "avro") \
.outputMode("append") \
.trigger(processingTime='60 seconds') \
.option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \
.option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/")
.start()
```
# Mengoptimalkan penyimpanan
Memperbarui atau menghapus data dalam tabel Gunung Es meningkatkan jumlah salinan data Anda, seperti yang diilustrasikan dalam diagram berikut. Hal yang sama berlaku untuk menjalankan pemadatan: Ini meningkatkan jumlah salinan data di Amazon S3. Itu karena Iceberg memperlakukan file yang mendasari semua tabel sebagai tidak dapat diubah.
![\[Hasil pemutakhiran atau penghapusan data dalam tabel Iceberg\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png)
Ikuti praktik terbaik di bagian ini untuk mengelola biaya penyimpanan.
## Aktifkan S3 Intelligent-Tiering
Gunakan kelas penyimpanan [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html) untuk memindahkan data secara otomatis ke tingkat akses yang paling hemat biaya saat pola akses berubah. Opsi ini tidak memiliki overhead operasional atau berdampak pada kinerja.
Catatan: Jangan gunakan tingkatan opsional (seperti Akses Arsip dan Akses Arsip Dalam) di S3 Intelligent-Tiering with Iceberg tables. Untuk mengarsipkan data, lihat pedoman di bagian selanjutnya.
[Anda juga dapat menggunakan aturan [Siklus Hidup Amazon S3 untuk menetapkan aturan](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) sendiri untuk memindahkan objek ke kelas penyimpanan Amazon S3 lainnya, seperti IA Standar S3 atau IA Zona Satu S3 (lihat Transisi yang didukung dan batasan terkait dalam dokumentasi Amazon S3).](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc)
## Arsipkan atau hapus snapshot bersejarah
Untuk setiap transaksi yang dilakukan (sisipkan, perbarui, gabungkan, pemadatan) ke tabel Iceberg, versi baru atau snapshot tabel dibuat. Seiring waktu, jumlah versi dan jumlah file metadata di Amazon S3 terakumulasi.
Menyimpan snapshot tabel diperlukan untuk fitur seperti isolasi snapshot, rollback tabel, dan kueri perjalanan waktu. Namun, biaya penyimpanan tumbuh dengan jumlah versi yang Anda pertahankan.
Tabel berikut menjelaskan pola desain yang dapat Anda terapkan untuk mengelola biaya berdasarkan persyaratan retensi data Anda.
| **Pola desain** | **Solusi** | **Kasus penggunaan** |
| --- |--- |--- |
| **Hapus snapshot lama** | Gunakan [pernyataan VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) di Athena untuk menghapus snapshot lama. Operasi ini tidak dikenakan biaya komputasi apa pun. [Atau, Anda dapat menggunakan Spark di Amazon EMR AWS Glue atau untuk menghapus snapshot.Untuk informasi selengkapnya, lihat expire\$1snapshots dalam dokumentasi Iceberg.](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) | Pendekatan ini menghapus snapshot yang tidak lagi diperlukan untuk mengurangi biaya penyimpanan. Anda dapat mengonfigurasi berapa banyak snapshot yang harus disimpan atau untuk berapa lama, berdasarkan persyaratan retensi data Anda.Opsi ini melakukan penghapusan snapshot dengan keras. Anda tidak dapat memutar kembali atau melakukan perjalanan waktu ke snapshot yang kedaluwarsa. |
| **Tetapkan kebijakan retensi untuk snapshot tertentu** | Gunakan tag untuk menandai snapshot tertentu dan menentukan kebijakan penyimpanan di Iceberg. Untuk informasi selengkapnya, lihat [Tag Sejarah](https://iceberg.apache.org/docs/latest/branching/#historical-tags) dalam dokumentasi Gunung Es. Misalnya, Anda dapat menyimpan satu snapshot per bulan selama satu tahun dengan menggunakan pernyataan SQL berikut di Spark di Amazon EMR: ALTER TABLE glue_catalog.db.table
CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS
Gunakan Spark di Amazon EMR AWS Glue atau untuk menghapus sisa snapshot perantara yang tidak ditandai. | Pola ini berguna untuk kepatuhan dengan persyaratan bisnis atau hukum yang mengharuskan Anda untuk menunjukkan keadaan tabel pada titik tertentu di masa lalu. Dengan menempatkan kebijakan penyimpanan pada snapshot yang diberi tag tertentu, Anda dapat menghapus snapshot lain (tidak ditandai) yang dibuat. Dengan cara ini, Anda dapat memenuhi persyaratan retensi data tanpa mempertahankan setiap snapshot yang dibuat. |
| **Arsipkan foto lama** | Gunakan tag Amazon S3 untuk menandai objek dengan Spark. [(Tag Amazon S3 berbeda dari tag Iceberg; untuk informasi selengkapnya, lihat dokumentasi Iceberg.)](https://iceberg.apache.org/docs/latest/aws/#s3-tags) Contoh: spark.sql.catalog.my_catalog.s3.delete-enabled=false and \
spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive
Gunakan Spark di Amazon EMR AWS Glue atau [untuk](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) menghapus snapshot. Saat Anda menggunakan pengaturan dalam contoh, prosedur ini menandai objek dan melepaskannya dari metadata tabel Iceberg alih-alih menghapusnya dari Amazon S3. Gunakan aturan Siklus Hidup S3 untuk mentransisikan objek yang diberi tag `to_archive` ke salah satu kelas penyimpanan [S3 Glacier](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html). Untuk menanyakan data yang diarsipkan: [Kembalikan objek yang diarsipkan](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) (langkah ini tidak diperlukan jika objek dialihkan ke kelas penyimpanan Amazon Glacier Instant Retrieval). Gunakan [prosedur register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) di Iceberg untuk mendaftarkan snapshot sebagai tabel dalam katalog. Untuk petunjuk terperinci, lihat posting AWS blog [Meningkatkan efisiensi operasional tabel Apache Iceberg yang dibangun di danau data Amazon S3](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/). | Pola ini memungkinkan Anda menyimpan semua versi tabel dan snapshot dengan biaya lebih rendah.Anda tidak dapat melakukan perjalanan waktu atau memutar kembali ke snapshot yang diarsipkan tanpa terlebih dahulu memulihkan versi tersebut sebagai tabel baru. Ini biasanya dapat diterima untuk tujuan audit.Anda dapat menggabungkan pendekatan ini dengan pola desain sebelumnya, menyetel kebijakan retensi untuk snapshot tertentu. |
## Hapus file yatim piatu
Dalam situasi tertentu, aplikasi Iceberg dapat gagal sebelum Anda melakukan transaksi Anda. Ini meninggalkan file data di Amazon S3. Karena tidak ada komit, file-file ini tidak akan dikaitkan dengan tabel apa pun, jadi Anda mungkin harus membersihkannya secara asinkron.
Untuk menangani penghapusan ini, Anda dapat menggunakan [pernyataan VACUUM di Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html). Pernyataan ini menghapus snapshot dan juga menghapus file yatim piatu. Ini sangat hemat biaya, karena Athena tidak mengenakan biaya untuk biaya komputasi operasi ini. Selain itu, Anda tidak perlu menjadwalkan operasi tambahan apa pun saat menggunakan `VACUUM` pernyataan tersebut.
Atau, Anda dapat menggunakan Spark di Amazon EMR AWS Glue atau untuk menjalankan `remove_orphan_files` prosedur. Operasi ini memiliki biaya komputasi dan harus dijadwalkan secara independen. Untuk informasi lebih lanjut, lihat dokumentasi [Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files).
# Mempertahankan tabel dengan menggunakan pemadatan
Iceberg mencakup fitur yang memungkinkan Anda untuk melakukan [operasi pemeliharaan tabel](https://iceberg.apache.org/docs/latest/maintenance/) setelah menulis data ke tabel. Beberapa operasi pemeliharaan berfokus pada perampingan file metadata, sementara yang lain meningkatkan bagaimana data dikelompokkan dalam file sehingga mesin kueri dapat secara efisien menemukan informasi yang diperlukan untuk menanggapi permintaan pengguna. Bagian ini berfokus pada pengoptimalan terkait pemadatan.
## Pemadatan gunung es
Di Iceberg, Anda dapat menggunakan pemadatan untuk melakukan empat tugas:
+ Menggabungkan file kecil menjadi file yang lebih besar yang umumnya berukuran lebih dari 100 MB. Teknik ini dikenal sebagai *bin packing*.
+ Menggabungkan menghapus file dengan file data. Hapus file dihasilkan oleh pembaruan atau penghapusan yang menggunakan merge-on-read pendekatan.
+ (Re) menyortir data sesuai dengan pola kueri. Data dapat ditulis tanpa urutan apapun atau dengan urutan sortir yang cocok untuk menulis dan update.
+ Mengelompokkan data dengan menggunakan kurva pengisian ruang untuk mengoptimalkan pola kueri yang berbeda, terutama penyortiran urutan-z.
Pada AWS, Anda dapat menjalankan operasi pemadatan dan pemeliharaan tabel untuk Iceberg melalui Amazon Athena atau dengan menggunakan Spark di Amazon EMR atau. AWS Glue
Saat Anda menjalankan pemadatan dengan menggunakan prosedur [rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files), Anda dapat menyesuaikan beberapa kenop untuk mengontrol perilaku pemadatan. Diagram berikut menunjukkan perilaku default pengepakan bin. Memahami pemadatan kemasan bin adalah kunci untuk memahami penyortiran hierarkis dan implementasi penyortiran urutan-Z, karena mereka adalah ekstensi dari antarmuka pengemasan bin dan beroperasi dengan cara yang sama. Perbedaan utama adalah langkah tambahan yang diperlukan untuk menyortir atau mengelompokkan data.
![\[Perilaku pengepakan bin default di tabel Iceberg\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png)
Dalam contoh ini, tabel Iceberg terdiri dari empat partisi. Setiap partisi memiliki ukuran dan jumlah file yang berbeda. Jika Anda memulai aplikasi Spark untuk menjalankan pemadatan, aplikasi membuat total empat grup file untuk diproses. Grup file adalah abstraksi Gunung Es yang mewakili kumpulan file yang akan diproses oleh satu pekerjaan Spark. Artinya, aplikasi Spark yang menjalankan pemadatan akan menciptakan empat pekerjaan Spark untuk memproses data.
## Menyetel perilaku pemadatan
Properti kunci berikut mengontrol bagaimana file data dipilih untuk pemadatan:
+ [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) menetapkan batas data untuk satu grup file (Spark job) pada 100 GB secara default. Properti ini sangat penting untuk tabel tanpa partisi atau tabel dengan partisi yang menjangkau ratusan gigabyte. Dengan menetapkan batas ini, Anda dapat memecah operasi untuk merencanakan pekerjaan dan membuat kemajuan sekaligus mencegah kehabisan sumber daya di cluster.
Catatan: Setiap grup file diurutkan secara terpisah. Oleh karena itu, jika Anda ingin melakukan pengurutan tingkat partisi, Anda harus menyesuaikan batas ini agar sesuai dengan ukuran partisi.
+ [MIN\$1FILE\$1SIZE\$1BYTES atau MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) [default ke 75 persen dari ukuran file target yang ditetapkan pada tingkat](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO) tabel. Misalnya, jika tabel memiliki ukuran target 512 MB, file apa pun yang lebih kecil dari 384 MB disertakan dalam kumpulan file yang akan dipadatkan.
+ [MAX\$1FILE\$1SIZE\$1BYTES atau MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) [default 180 persen dari ukuran file target](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO). Seperti dua properti yang mengatur ukuran file minimum, properti ini digunakan untuk mengidentifikasi file kandidat untuk pekerjaan pemadatan.
+ [MIN\$1INPUT\$1FILES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) menentukan jumlah minimum file yang akan dipadatkan jika ukuran partisi tabel lebih kecil dari ukuran file target. Nilai properti ini digunakan untuk menentukan apakah layak untuk memadatkan file berdasarkan jumlah file (default ke 5).
+ [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) menentukan jumlah minimum operasi penghapusan untuk file sebelum disertakan dalam pemadatan. Kecuali Anda menentukan sebaliknya, pemadatan tidak menggabungkan file hapus dengan file data. Untuk mengaktifkan fungsi ini, Anda harus menetapkan nilai ambang dengan menggunakan properti ini. Ambang batas ini khusus untuk file data individual, jadi jika Anda mengaturnya ke 3, file data akan ditulis ulang hanya jika ada tiga atau lebih file hapus yang mereferensikannya.
Properti ini memberikan wawasan tentang pembentukan kelompok file dalam diagram sebelumnya.
Misalnya, partisi berlabel `month=01` mencakup dua grup file karena melebihi batasan ukuran maksimum 100 GB. Sebaliknya, `month=02` partisi berisi satu grup file karena di bawah 100 GB. `month=03`Partisi tidak memenuhi persyaratan file input minimum default dari lima file. Akibatnya, itu tidak akan dipadatkan. Terakhir, meskipun `month=04` partisi tidak berisi data yang cukup untuk membentuk satu file dengan ukuran yang diinginkan, file akan dipadatkan karena partisi mencakup lebih dari lima file kecil.
Anda dapat mengatur parameter ini untuk Spark yang berjalan di Amazon AWS Glue EMR atau. Untuk Amazon Athena, Anda dapat mengelola properti serupa dengan menggunakan [properti tabel](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties) yang dimulai dengan awalan`optimize_`).
## Menjalankan pemadatan dengan Spark di Amazon EMR atau AWS Glue
Bagian ini menjelaskan cara mengukur cluster Spark dengan benar untuk menjalankan utilitas pemadatan Iceberg. Contoh berikut menggunakan Amazon EMR Tanpa Server, tetapi Anda dapat menggunakan metodologi yang sama di Amazon EMR di EC2 atau EKS, atau di. AWS Glue
Anda dapat memanfaatkan korelasi antara grup file dan pekerjaan Spark untuk merencanakan sumber daya cluster. Untuk memproses grup file secara berurutan, dengan mempertimbangkan ukuran maksimum 100 GB per grup file, Anda dapat mengatur properti [Spark](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults) berikut:
+ `spark.dynamicAllocation.enabled` = `FALSE`
+ `spark.executor.memory` = `20 GB`
+ `spark.executor.instances` = `5`
Jika Anda ingin mempercepat pemadatan, Anda dapat menskalakan secara horizontal dengan meningkatkan jumlah grup file yang dipadatkan secara paralel. Anda juga dapat menskalakan EMR Amazon dengan menggunakan penskalaan manual atau dinamis.
+ **Penskalaan secara manual** (misalnya, dengan faktor 4)
+ `MAX_CONCURRENT_FILE_GROUP_REWRITES`= `4` (faktor kami)
+ `spark.executor.instances`= `5` (nilai yang digunakan dalam contoh) x `4` (faktor kami) = `20`
+ `spark.dynamicAllocation.enabled` = `FALSE`
+ **Penskalaan dinamis**
+ `spark.dynamicAllocation.enabled`= `TRUE ` (default, tidak ada tindakan yang diperlukan)
+ [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) = `N ` (sejajarkan nilai ini dengan`spark.dynamicAllocation.maxExecutors`, yang 100 secara default; berdasarkan konfigurasi pelaksana dalam contoh, Anda dapat mengatur ke 20) `N`
Ini adalah pedoman untuk membantu mengukur cluster. Namun, Anda juga harus memantau kinerja pekerjaan Spark Anda untuk menemukan pengaturan terbaik untuk beban kerja Anda.
## Menjalankan pemadatan dengan Amazon Athena
[Athena menawarkan implementasi utilitas pemadatan Iceberg sebagai fitur terkelola melalui pernyataan OPTIMIZE.](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html) Anda dapat menggunakan pernyataan ini untuk menjalankan pemadatan tanpa harus mengevaluasi infrastruktur.
Pernyataan ini mengelompokkan file kecil ke dalam file yang lebih besar dengan menggunakan algoritma pengemasan bin dan menggabungkan file hapus dengan file data yang ada. Untuk mengelompokkan data menggunakan pengurutan hierarkis atau pengurutan urutan z, gunakan Spark di Amazon EMR atau. AWS Glue
Anda dapat mengubah perilaku default `OPTIMIZE` pernyataan pada pembuatan tabel dengan meneruskan properti tabel dalam `CREATE TABLE` pernyataan, atau setelah pembuatan tabel dengan menggunakan `ALTER TABLE` pernyataan. Untuk nilai default, lihat dokumentasi [Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties).
## Rekomendasi untuk menjalankan pemadatan
| **Kasus penggunaan** | **Rekomendasi** |
| --- |--- |
| **Menjalankan pemadatan pengepakan bin berdasarkan jadwal** | Gunakan `OPTIMIZE` pernyataan di Athena jika Anda tidak tahu berapa banyak file kecil yang berisi tabel Anda. Model penetapan harga Athena didasarkan pada data yang dipindai, jadi jika tidak ada file yang akan dipadatkan, tidak ada biaya yang terkait dengan operasi ini. Untuk menghindari menemui batas waktu di tabel Athena, jalankan berdasarkan. `OPTIMIZE` per-table-partition Gunakan Amazon EMR atau AWS Glue dengan penskalaan dinamis saat Anda mengharapkan volume besar file kecil dipadatkan. |
| **Menjalankan pemadatan pengepakan bin berdasarkan peristiwa** | Gunakan Amazon EMR atau AWS Glue dengan penskalaan dinamis saat Anda mengharapkan volume besar file kecil dipadatkan. |
| **Menjalankan pemadatan untuk mengurutkan data** | Gunakan Amazon EMR atau AWS Glue, karena penyortiran adalah operasi yang mahal dan mungkin perlu menumpahkan data ke disk. |
| **Menjalankan pemadatan untuk mengelompokkan data menggunakan pengurutan urutan z** | Gunakan Amazon EMR atau AWS Glue, karena penyortiran urutan z adalah operasi yang sangat mahal dan mungkin perlu menumpahkan data ke disk. |
| **Menjalankan pemadatan pada partisi yang mungkin diperbarui oleh aplikasi lain karena data yang datang terlambat** | Gunakan Amazon EMR atau. AWS Glue Aktifkan properti Iceberg [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED). Saat Anda menggunakan opsi ini, Iceberg membagi output pemadatan menjadi beberapa komit. Jika ada tabrakan (yaitu, jika file data diperbarui saat pemadatan sedang berjalan), pengaturan ini mengurangi biaya percobaan ulang dengan membatasi ke komit yang menyertakan file yang terpengaruh. Jika tidak, Anda mungkin harus mengompres ulang semua file. |
| **Menjalankan pemadatan pada partisi dingin (partisi data yang tidak lagi menerima penulisan aktif)** | Gunakan Amazon EMR atau. AWS Glue Dalam `rewrite_data_files` prosedur, tentukan `where` predikat yang mengecualikan partisi yang ditulis secara aktif. Strategi ini mencegah konflik data antara penulis dan pekerjaan pemadatan, dan hanya menyisakan konflik metadata yang dapat diselesaikan oleh Iceberg secara otomatis. |
# Menggunakan beban kerja Iceberg di Amazon S3
Bagian ini membahas properti Iceberg yang dapat Anda gunakan untuk mengoptimalkan interaksi Iceberg dengan Amazon S3.
## Mencegah partisi panas (kesalahan HTTP 503)
Beberapa aplikasi data lake yang berjalan di Amazon S3 menangani jutaan atau miliaran objek dan memproses petabyte data. Hal ini dapat menyebabkan awalan yang menerima volume lalu lintas yang tinggi, yang biasanya terdeteksi melalui kesalahan HTTP 503 (layanan tidak tersedia). Untuk mencegah masalah ini, gunakan properti Iceberg berikut:
+ Setel `write.distribution-mode` ke `hash` atau `range` lebih agar Iceberg menulis file besar, yang menghasilkan lebih sedikit permintaan Amazon S3. Ini adalah konfigurasi yang disukai dan harus mengatasi sebagian besar kasus.
+ Jika Anda terus mengalami 503 kesalahan karena volume data yang sangat besar dalam beban kerja Anda, Anda dapat mengatur `write.object-storage.enabled` ke dalam Iceberg. `true` Ini menginstruksikan Iceberg untuk melakukan hash nama objek dan mendistribusikan beban di beberapa awalan Amazon S3 acak.
Untuk informasi selengkapnya tentang properti ini, lihat [Menulis properti](https://iceberg.apache.org/docs/latest/configuration/#write-properties) di dokumentasi Gunung Es.
## Gunakan operasi pemeliharaan Iceberg untuk merilis data yang tidak digunakan
Untuk mengelola tabel Iceberg, Anda dapat menggunakan API inti Iceberg, klien Iceberg (seperti Spark), atau layanan terkelola seperti Amazon Athena. [Untuk menghapus file lama atau yang tidak digunakan dari Amazon S3, kami sarankan Anda hanya menggunakan Iceberg APIs native [untuk menghapus snapshot, menghapus file metadata lama, dan menghapus](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots)[file yatim](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files) piatu.](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files)
Menggunakan Amazon S3 APIs melalui Boto3, Amazon S3 SDK, atau AWS Command Line Interface (AWS CLI), atau menggunakan metode non-Iceberg lainnya untuk menimpa atau menghapus file Amazon S3 untuk tabel Iceberg menyebabkan kerusakan tabel dan kegagalan kueri.
## Replikasi data di seluruh Wilayah AWS
Saat menyimpan tabel Iceberg di Amazon S3, Anda dapat menggunakan fitur bawaan di Amazon S3, seperti Replikasi [Lintas Wilayah (CRR) [dan Titik Akses Multi-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) (MRAP), untuk mereplikasi](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) data di beberapa. Wilayah AWS MRAP menyediakan titik akhir global untuk aplikasi untuk mengakses bucket S3 yang terletak di beberapa. Wilayah AWS Iceberg tidak mendukung jalur relatif, tetapi Anda dapat menggunakan MRAP untuk melakukan operasi Amazon S3 dengan memetakan bucket ke titik akses. MRAP juga terintegrasi secara mulus dengan proses Replikasi Lintas Wilayah Amazon S3, yang memperkenalkan jeda hingga 15 menit. Anda harus mereplikasi file data dan metadata.
**penting**
Saat ini, integrasi Iceberg dengan MRAP hanya berfungsi dengan Apache Spark. Jika Anda perlu gagal ke sekunder Wilayah AWS, Anda harus merencanakan untuk mengarahkan kueri pengguna ke lingkungan Spark SQL (seperti Amazon EMR) di Wilayah failover.
Fitur CRR dan MRAP membantu Anda membangun solusi replikasi lintas wilayah untuk tabel Iceberg, seperti yang diilustrasikan dalam diagram berikut.
![\[Replikasi lintas wilayah untuk tabel Gunung Es\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png)
Untuk menyiapkan arsitektur replikasi lintas wilayah ini:
1. Buat tabel dengan menggunakan lokasi MRAP. Ini memastikan bahwa file metadata Iceberg mengarah ke lokasi MRAP alih-alih lokasi bucket fisik.
1. Replikasi file Iceberg dengan menggunakan Amazon S3 MRAP. ****MRAP mendukung replikasi data dengan perjanjian tingkat layanan (SLA) selama 15 menit. Iceberg mencegah operasi baca dari memperkenalkan inkonsistensi selama replikasi.
1. Buat tabel tersedia AWS Glue Data Catalog di Wilayah sekunder. Anda dapat memilih dari dua opsi:
+ Siapkan pipeline untuk mereplikasi metadata tabel Iceberg dengan menggunakan replikasi. AWS Glue Data Catalog Utilitas ini tersedia di repositori [replikasi GitHub Glue Catalog dan Lake Formation Permissions.](https://github.com/aws-samples/lake-formation-pemissions-sync) Mekanisme berbasis peristiwa ini mereplikasi tabel di Wilayah target berdasarkan log peristiwa.
+ Daftarkan tabel di Wilayah sekunder saat Anda harus gagal. Untuk opsi ini, Anda dapat menggunakan utilitas sebelumnya atau [prosedur Iceberg register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) dan mengarahkannya ke file terbaru. `metadata.json`