Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik untuk Trino di Amazon EMR
Arsitektur Trino dirancang untuk kueri SQL yang cepat dan terdistribusi pada kumpulan data besar di beberapa sumber data, mengikuti model koordinator-pekerja, di mana setiap komponen memiliki peran khusus dalam eksekusi kueri. Ada beberapa area atau kategori yang dapat Anda fokuskan untuk mengonfigurasi cluster EMR Amazon Anda yang menjalankan Trino untuk kinerja terbaiknya. Sumber daya yang dimaksud meliputi:
+ Menyesuaikan pengaturan konfigurasi cluster untuk optimasi memori.
+ Mengoptimalkan pengaturan untuk partisi data dan distribusi data.
+ Menggunakan pemfilteran dinamis untuk mengurangi jumlah hasil kueri.
Beberapa pengaturan ini disetel secara otomatis saat Anda menggunakan Trino dengan Amazon EMR. Lainnya dapat diatur secara manual melalui konsol atau melalui perintah CLI. Topik di bagian ini membantu Anda mengonfigurasi data dan klaster Anda secara optimal.
**Topics**
+ [Bidang fokus utama untuk peningkatan kinerja](emr-trino-performance-areas.md)
+ [Kumpulkan dan Manfaatkan statistik tabel](emr-trino-performance-areas-collect-stats.md)
+ [Tantangan umum saat menskalakan beban kerja Trino](emr-trino-common-issues.md)
# Bidang fokus utama untuk peningkatan kinerja
Trino memaksimalkan paralelisme kueri dan optimasi memori. Arsitektur ini memberikan fleksibilitas dengan memungkinkannya untuk menanyakan banyak sumber data yang bervariasi sambil melakukan penskalaan secara efisien. Bidang utama peningkatan kinerja di Trino termasuk yang tercantum di bawah ini.
## Optimalisasi memori
Manajemen memori di Trino sangat penting untuk mencapai kinerja dan stabilitas tinggi, terutama ketika Anda menjalankan kueri yang besar dan kompleks. Trino menggunakan model memori terdistribusi. Dalam model ini, memori dialokasikan di seluruh node pekerja untuk memproses tugas, agregasi, gabungan, dan operasi lainnya. Daftar berikut memperkenalkan kumpulan pengaturan ini:
+ **query.max-memory** - Menetapkan memori maksimum yang tersedia untuk satu kueri di seluruh cluster. Ini adalah batas yang sulit; jika kueri melebihi memori ini, itu akan gagal.
+ **pertanyaan. max-memory-per-node** — Mendefinisikan memori maksimum yang dapat dikonsumsi kueri pada setiap node pekerja. Menyetel ini memastikan tidak ada kueri tunggal yang memonopoli sumber daya pada pekerja mana pun.
+ **JVM Heap Size** - Dikonfigurasi pada level JVM, ini menetapkan ukuran heap maksimum untuk proses server Trino pada setiap node. **Nilai ini umumnya harus lebih besar dari konfigurasi terkait memori (ini adalah jumlah kueri. max-memory-per-node**dan **memori. heap-headroom-per-node**) di Trino untuk menghindari sistem kehabisan memori di tingkat JVM.
+ **memori. heap-headroom-per-node** — Menentukan jumlah buffer memori untuk meninggalkan dari ukuran tumpukan JVM untuk operasi non-query. Ini sangat penting untuk memastikan biaya overhead yang cukup untuk operasi internal dan pengumpulan sampah.
## Penyaringan Dinamis
Pemfilteran dinamis di Trino adalah teknik pengoptimalan yang meningkatkan kinerja kueri dengan mengurangi jumlah data yang diproses, terutama selama bergabung. Ini secara dinamis menerapkan kondisi filter untuk membatasi data yang dipindai oleh satu sisi gabungan, berdasarkan data yang terlihat di sisi lain, yang sangat berguna dalam kueri di mana satu sisi gabungan sangat selektif (artinya berisi sebagian kecil data). Ini diaktifkan secara default di Amazon EMR. Berikut ini adalah contoh query:
```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```
Tanpa penyaringan dinamis, Trino memindai seluruh tabel pesanan dalam gabungan, meskipun hanya sebagian kecil pelanggan (yang berasal dari Prancis) yang relevan. Pendekatan ini membaca semua baris dalam tabel **pesanan**, menghasilkan biaya tinggi I/O dan pemrosesan. Dengan pemfilteran dinamis, Trino awalnya memindai tabel **pelanggan** yang lebih kecil, mengambil nilai customer\$1id hanya untuk pelanggan dari Prancis, dan kemudian menerapkan subset ini sebagai filter pada pesanan. Ini berarti hanya baris yang relevan dari **pesanan** — yang memiliki customer\$1id yang cocok dengan subset yang difilter — yang dipindai, secara signifikan mengurangi catatan yang diproses.
## Tumpahan ke Disk
Di Trino, tumpahan disk memungkinkan hasil kueri menengah diturunkan ke disk, memungkinkan kueri intensif memori untuk diselesaikan, bahkan jika melebihi batas memori yang ditetapkan oleh atau. `query_max_memory` `query_max_memory_per_node` Secara default, Trino memberlakukan batasan ini untuk memastikan alokasi memori yang adil dan untuk mencegah kebuntuan cluster. Namun, ketika kueri besar melampaui batas ini, itu berisiko penghentian. Penumpahan disk mengatasi ini dengan menggunakan`revocable memory`, memungkinkan kueri untuk meminjam memori tambahan yang dapat dicabut jika sumber daya diperlukan di tempat lain. Ketika memori dicabut, data perantara tumpah ke disk, memungkinkan kueri untuk melanjutkan pemrosesan tanpa melebihi batas memori. Harap dicatat bahwa kueri yang dipaksa untuk tumpah ke disk mungkin memiliki waktu eksekusi yang lebih lama, sehingga dinonaktifkan secara default. Untuk mengaktifkan tumpahan di Amazon EMR, gunakan konfigurasi berikut:
+ `spill-enabled=true`— Memungkinkan tumpahan disk ketika penggunaan memori melebihi ambang batas yang tersedia.
+ `spill-paths`— Mendefinisikan direktori tempat data tumpah disimpan, `spill-paths=/mnt/spill`
# Kumpulkan dan Manfaatkan statistik tabel
Mengumpulkan statistik tabel memungkinkan pengoptimal berbasis biaya Trino untuk membuat keputusan berdasarkan informasi tentang pesanan gabungan, pushdown filter, dan pemangkasan partisi, menghasilkan kinerja yang lebih baik.
Anda dapat menggunakan `ANALYZE` perintah untuk mengumpulkan statistik untuk tabel Hive atau Iceberg:
```
ANALYZE sales;
```
Mengumpulkan statistik pada tabel lebar dapat membebani sumber daya. Kami merekomendasikan untuk menentukan subset kolom yang digunakan dalam gabungan, dalam filter, atau dalam operasi pengelompokan.
Ini adalah perintah lain yang bermanfaat. Ini menampilkan statistik saat ini untuk tabel untuk memverifikasi apakah statistik mutakhir.
```
show stats for table_name;
```
# Tantangan umum saat menskalakan beban kerja Trino
Manfaat utama menggunakan Amazon S3 dengan Trino adalah kemampuan S3 untuk menskalakan volume data yang besar dan efektivitas biaya S3. Tetapi ketika Anda menanyakan volume data yang besar, kumpulan masalah kinerja terkait dapat terjadi pada kesempatan tertentu. Ini dapat dihasilkan dari bagaimana data disimpan, atau dengan pengaturan konfigurasi yang membatasi kinerja yang baik, atau dari alasan lain. Ketika masalah ini terjadi, ada langkah-langkah efektif yang dapat Anda ambil untuk menghindari atau menguranginya.
Bagian ini dimulai dengan daftar pengoptimalan umum yang dapat Anda terapkan untuk meningkatkan kinerja kueri pada volume data yang besar. Setelah itu, masalah umum dirinci dan mitigasi disediakan untuk masing-masing masalah.
Topik ini bersumber dari presentasi konferensi berikut: [Mempercepat kinerja dalam skala: Praktik terbaik untuk Trino dengan Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ).
## Mengoptimalkan tata letak data untuk kumpulan data besar
Kemacetan kinerja tidak jarang terjadi saat Anda menanyakan kumpulan data besar. Tetapi ada praktik terbaik yang dapat Anda terapkan untuk memulai dengan baik saat Anda menggunakan Trino untuk menanyakan data di Amazon S3. Sumber daya yang dimaksud meliputi:
+ **Partisi** — Partisi berarti mengatur data dalam hierarki dan menyimpan data terkait bersama-sama, berdasarkan atribut terkait. Partisi membuatnya jadi kueri tidak perlu memindai sebanyak mungkin data yang tidak relevan dan menghasilkan kinerja kueri yang lebih baik. Anda dapat menggunakan berbagai strategi partisi, seperti mengatur data sumber dengan awalan, khususnya berdasarkan wilayah rentang tanggal, atau atribut lainnya. Untuk informasi lebih rinci tentang mempartisi data di Amazon S3 untuk meningkatkan kinerja, lihat [posting blog Mulai mengelola partisi untuk tabel Amazon S3 yang didukung AWS oleh Katalog Data Glue [atau posting](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) Top 10 Performance](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) Tuning Tips untuk. Amazon Athena
+ **Bucketing — Bucketing** adalah pengelompokan data terkait bersama-sama dalam file umum. Misalnya, jika Anda menanyakan data menurut wilayah geografis, seperti status, Anda dapat meningkatkan kinerja kueri dengan mengelompokkan semua data untuk status tertentu dalam file atau grup file yang sama. Agar ini bekerja paling baik, dasarkan bucketing Anda pada atribut data dengan kardinalitas tinggi, seperti negara bagian atau provinsi, misalnya. Selain itu, Anda dapat mempertimbangkan pola kueri Anda. Contohnya bisa berarti pengelompokan data untuk California dan Oregon bersama-sama, jika kueri Anda biasanya membaca data dari negara bagian tersebut bersama-sama.
+ **Mengelola awalan S3** - Anda dapat menggunakan awalan Amazon S3 untuk menerapkan strategi partisi. Jika Anda hanya menggunakan satu awalan untuk bucket Amazon S3, seperti tanggal tertentu, misalnya, ini dapat menyebabkan jumlah permintaan yang tinggi dan dapat mengakibatkan kesalahan HTTP 503. Sebaiknya gunakan awalan untuk menambahkan kondisi tambahan dan mengatur data sumber Anda dengan lebih efektif. Untuk informasi selengkapnya, lihat [Mengatur objek menggunakan awalan](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) dalam dokumentasi Amazon S3. Contoh singkat berikut menunjukkan awalan yang menghasilkan throughput permintaan yang lebih baik:. `s3://bucket/country=US/dt=2024-06-13` Dalam sampel ini, negara dan tanggal disertakan dalam awalan, yang menghasilkan lebih sedikit pembacaan daripada kasus di mana awalan hanya mencakup tanggal.
Mengurangi kesalahan HTTP 503 dibahas secara lebih rinci di bagian *pelambatan HTTP* yang mengikuti topik ini.
+ **Mengoptimalkan ukuran data** — Anda dapat menjalankan perintah OPTIMIZE untuk mengatur konfigurasi yang kondusif untuk kueri yang berkinerja lebih baik. Untuk menjalankannya terhadap tabel eksternal Hive, ikuti langkah-langkah ini:
+ Gunakan `OPTIMIZE` dengan parameter berikut:`hive.non-managed-table-writes-enabled=true`. Untuk informasi selengkapnya tentang properti ini, lihat [Hive properti konfigurasi umum](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties).
+ Tetapkan parameter sesi berikut: `SET SESSION` `catalog.non_transactional_optimize_enabled=true`
+ Jalankan `OPTIMIZE` perintah:`ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. Dalam hal ini, `file_size_threshold` adalah 100MB secara default. Menaikkan ambang batas ini, seperti yang ditunjukkan dalam sampel, akan menyebabkan file di bawah 128MB digabungkan.
+ **Konfigurasi percobaan ulang** - Anda dapat meningkatkan batas coba lagi, yang dapat mengurangi kemungkinan kesalahan HTTP 503, dengan menetapkan yang berikut:. `s3.max-error-retries` Ini berlaku ketika Anda menggunakan TrinoFileSystem API dan versi Trino 449 atau yang lebih baru. Di sisi lain, dalam kasus di mana Anda menggunakan Amazon EMR dengan Trino, Anda menggunakan EMRFS untuk mengakses Amazon S3. Dengan EMRFS, Anda dapat meningkatkan jumlah pensiunan dengan mengubah parameter. `fs.s3.maxRetries`
+ **Pilih kelas penyimpanan Amazon S3 — Memilih kelas** penyimpanan yang sesuai untuk data pada titik berbeda dalam siklus hidupnya dapat membantu kinerja dan biaya, berdasarkan kebutuhan Anda untuk pengumpulan data tertentu. Untuk informasi selengkapnya, lihat [Memahami dan mengelola kelas penyimpanan Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) dalam dokumentasi Amazon S3.
+ **Migrasi ke Iceberg** — Solusi lain untuk mengurangi masalah kinerja, khususnya terkait menjalankan kueri pada file kecil, adalah dengan bermigrasi ke tabel Iceberg. Iceberg memiliki fitur yang menangani file kecil dengan baik.
+ **Gunakan pemadatan data otomatis** — Jika Anda menggunakan tabel Iceberg, pemadatan data otomatis dengan AWS Glue Data Catalog dapat mengoptimalkan ukuran data dan menghasilkan kinerja kueri yang lebih baik.
## Tantangan umum saat Anda menanyakan kumpulan data besar
Bagian ini mencantumkan kumpulan masalah umum yang dapat terjadi saat Anda mengumpulkan kumpulan data besar di Amazon S3 dan menanyakannya dengan Trino. Setiap bagian menunjukkan cara untuk menyelesaikan masalah atau mengurangi dampaknya pada kueri. Setiap masalah yang dijelaskan di bagian berikut telah direproduksi dan diuji, menggunakan konektor Hive.
### Pemindaian data besar
Ketika kueri Anda harus memindai kumpulan data yang besar, itu dapat menyebabkan masalah seperti kinerja kueri yang lambat dan biaya penyimpanan yang lebih tinggi. Volume data yang besar dapat dihasilkan dari pertumbuhan atau perencanaan data yang cepat yang tidak menghasilkan pemindahan data lama dalam kerangka waktu yang sesuai. Ini dapat menyebabkan kueri lebih lambat.
Untuk mengurangi hit kinerja dari pemindaian kumpulan data besar, kami menyarankan Anda menggunakan partisi dan bucketing:
+ Mempartisi kelompok terkait data bersama-sama, berdasarkan atributnya. Menggunakan partisi secara efektif dapat sangat meningkatkan kinerja kueri.
+ Bucketing mengacu pada pengelompokan data dalam file atau ember sesuai dengan kolom data tertentu yang terkait. Bucketing biasanya berarti secara fisik menyimpan file data sumber terkait bersama-sama.
Untuk mengilustrasikan bagaimana mitigasi dapat bekerja untuk pemindaian data besar, asumsikan Anda menyimpan dan menanyakan data yang memiliki catatan dengan atribut status, yang dapat ditetapkan ke California atau Alaska, dan atribut status ini adalah salah satu kondisi kueri Anda. Anda dapat meningkatkan kinerja kueri dengan menyimpan data untuk setiap status dalam bucket S3 terpisah, atau mempartisi data berdasarkan status, menggunakan awalan S3. Partisi dan bucketing ini juga dapat menyebabkan peningkatan kinerja jika Anda mendasarkannya pada kolom tambahan, seperti atribut tanggal, misalnya.
**catatan**
Jika kolom memiliki kardinalitas tinggi, dan Anda ingin menggunakannya untuk mengelompokkan data, sebaiknya gunakan bucketing dalam kasus ini. Di sisi lain, umumnya, kunci partisi harus memiliki kardinalitas yang lebih rendah.
**Menggunakan berbagai jenis penyimpanan S3**
Umumnya, Anda memilih jenis penyimpanan berdasarkan kinerja, akses data, ketahanan, dan persyaratan biaya untuk beban kerja Anda. Mungkin ada trade off antara biaya dan kinerja. Penting untuk memilih kelas penyimpanan Amazon S3 yang sesuai yang cocok dengan pola akses data Anda. Ada dua pola akses utama:
+ Data yang diakses dengan cara yang diketahui atau dapat diprediksi. Umumnya, jika Anda memiliki data yang jarang diakses, S3 Standard IA bisa menjadi pilihan yang baik, karena membantu mengurangi biaya. Jika Anda telah sering mengakses data, S3 Standard adalah yang terbaik untuk akses dengan Amazon EMR dan Trino.
+ Data yang diakses dengan cara yang tidak diketahui atau tidak dapat diprediksi. Ini dapat meminta untuk menggunakan kelas penyimpanan Amazon S3 lainnya, Ada pertukaran antara kelas penyimpanan S3. Ini termasuk latensi, biaya penyimpanan, dan ketersediaan. Anda dapat memilih jenis penyimpanan S3 yang sesuai, berdasarkan beban kerja dan pola akses Anda. Untuk deskripsi manfaat setiap kelas, lihat Kelas Penyimpanan [Amazon S3]().
**Menggunakan pemadatan**
Anda juga dapat menggunakan Iceberg pemadatan otomatis, jika Anda menggunakan tabel Iceberg, yang menghasilkan ukuran file yang lebih optimal, untuk meningkatkan efisiensi kueri. Untuk informasi selengkapnya, lihat [AWS Glue Data Catalog sekarang mendukung pemadatan otomatis tabel Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Kesalahan pelambatan HTTP
Ini terjadi ketika tingkat permintaan melebihi ambang batas yang telah dikonfigurasi sebelumnya pada awalan Amazon S3. Kesalahan HTTP yang paling sering terjadi ketika status ini tercapai adalah sebagai berikut: **Kesalahan 503: Harap kurangi tingkat permintaan Anda**. Sumber untuk masalah ini dapat di-root di hadapan sejumlah besar file kecil, karena jumlah *split* yang harus dibuat untuk membaca data. Ada beberapa cara untuk mengurangi masalah ini:
+ Tingkatkan batas coba lagi untuk permintaan Amazon S3 di Trino. Ini diatur untuk EMRFS menggunakan `fs.s3.maxretries` di Trino 449.
+ Optimalkan ukuran file, yang juga dapat menghasilkan tingkat permintaan yang lebih rendah.
Untuk informasi selengkapnya tentang cara Trino menentukan jumlah pemisahan dalam kumpulan data yang akan dikueri, lihat [Properti konfigurasi penyetelan kinerja](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties) dalam dokumentasi konektor Hive.
### Kesulitan menanyakan file kecil
Menanyakan banyak file kecil dapat mengakibatkan I/O overhead yang berat, karena tingginya jumlah permintaan GET dan LIST, dan selanjutnya memengaruhi kinerja kueri secara negatif. Mengoptimalkan ukuran file dapat meningkatkan kinerja kueri. Ada beberapa cara untuk melakukan ini:
+ Konsolidasikan data menjadi lebih sedikit file yang lebih besar. (Umumnya, kami sarankan untuk menjaga ukuran file sekitar 128 MB.) Anda dapat melakukan ini dengan alat saat Anda menyerap data, seperti dalam pipeline ETL, atau Anda dapat mengkonsolidasikan data secara manual. Jika solusi ini tidak tersedia untuk Anda, opsi yang tersisa mungkin lebih cocok untuk Anda.
+ Jalankan perintah `OPTIMIZE`.
+ Atur parameter `SESSION`.
Perhatikan bahwa Iceberg memiliki fitur yang tersedia untuk menggabungkan file kecil menjadi file yang lebih besar yang merupakan pemadatan otomatis. Ia bekerja dengan file yang dikelola dengan Katalog Data AWS Glue. Untuk informasi selengkapnya, lihat [AWS Glue Data Catalog sekarang mendukung pemadatan otomatis tabel Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Kueri yang menyertakan data yang tidak diperlukan
Adalah umum bagi data untuk tumbuh, yang membuatnya penting untuk melacak pola akses data Anda dan memindahkan data dengan tepat seiring bertambahnya usia atau menjadi tidak relevan. Ini karena seiring bertambahnya data, kinerja kueri dapat menurun seiring waktu, terutama karena banyaknya volume data untuk dipindai saat kueri berjalan. Amazon S3 dan layanan lainnya menawarkan panduan untuk migrasi siklus hidup data, yang menunjukkan strategi untuk memindahkan data ke lokasi penyimpanan yang berbeda saat cuaca menjadi dingin. Ada juga manfaat biaya penyimpanan untuk melakukan ini.
Selain migrasi data, Anda dapat menggunakan strategi lain seperti menghapus data sumber yang tidak relevan dengan kueri yang Anda jalankan. Ini dapat membutuhkan beberapa pekerjaan, karena ini mungkin berarti mengubah skema sumber-data Anda. Tetapi hasil positifnya adalah mengurangi volume data dan menghasilkan kueri yang lebih cepat. Untuk informasi selengkapnya, lihat [Mengelola siklus hidup objek.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)