View a markdown version of this page

Tantangan umum saat menskalakan beban kerja Trino - Amazon EMR
Mengoptimalkan tata letak data untuk kumpulan data besarTantangan umum saat Anda menanyakan kumpulan data besar

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

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 sesekali. Ini dapat dihasilkan dari bagaimana data disimpan, atau oleh 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.

Topik ini bersumber dari presentasi konferensi berikut: Mempercepat kinerja dalam skala besar: Praktik terbaik untuk Trino dengan Amazon S3.

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 memberi diri Anda awal yang lebih baik ketika 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 sehingga kueri tidak perlu memindai banyak 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 oleh Katalog Data AWS Glue atau posting Top 10 Tips Penyetelan Kinerja untuk Amazon Athena.

  • Bucketing — Bucketing mengelompokkan data terkait bersama-sama dalam file umum. Misalnya, jika Anda menanyakan data menurut wilayah geografis, seperti negara bagian, Anda dapat meningkatkan kinerja kueri dengan mengelompokkan semua data untuk status tertentu dalam file atau grup file yang sama. Agar ini berfungsi dengan baik, mendasarkan bucketing Anda pada atribut data dengan kardinalitas tinggi, seperti negara bagian atau provinsi, misalnya. Juga, Anda dapat mempertimbangkan pola kueri Anda. Contohnya bisa berarti mengelompokkan 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 awalan tunggal 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 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 pembacaan lebih sedikit daripada kasus di mana awalan hanya menyertakan tanggal.

    Mengurangi kesalahan HTTP 503 dibahas secara lebih rinci di bagian perlambatan HTTP yang berikut dalam 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 properti konfigurasi umum Hive.

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

  • Konfigurasikan percobaan ulang — Anda dapat meningkatkan batas percobaan ulang, yang dapat mengurangi kemungkinan kesalahan HTTP 503, dengan mengatur yang berikut:. s3.max-error-retries Ini berlaku saat Anda menggunakan TrinoFileSystem API dan versi Trino 449 atau yang lebih baru. Di sisi lain, jika Anda menggunakan Amazon EMR dengan Trino, Anda menggunakan EMRFS untuk mengakses Amazon S3. Dengan EMRFS, Anda dapat meningkatkan jumlah pensiun dengan mengubah parameter. fs.s3.maxRetries

  • Pilih kelas penyimpanan Amazon S3 — Memilih kelas penyimpanan yang sesuai untuk data pada titik yang berbeda dalam siklus hidupnya dapat membantu kinerja dan biaya, berdasarkan kebutuhan Anda untuk pengumpulan data tertentu. Untuk informasi selengkapnya, lihat Mem ahami dan mengelola kelas penyimpanan Amazon S3 di dokumentasi Amazon S3.

  • Bermigrasi ke Iceberg — Solusi lain untuk mengurangi masalah kinerja, khususnya mengenai menjalankan kueri pada file kecil, adalah 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 Katalog Data AWS Glue 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 besar, hal 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. Hal ini dapat menyebabkan query yang lebih lambat.

Untuk mengurangi dampak kinerja dari pemindaian kumpulan data besar, sebaiknya gunakan partisi dan bucketing:

  • Partisi mengelompokkan data terkait bersama-sama, berdasarkan atributnya. Menggunakan partisi secara efektif dapat sangat meningkatkan kinerja kueri.

  • Bucketing mengacu pada pengelompokan data dalam file atau bucket 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 negara bagian 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 pertukaran antara biaya dan kinerja. Penting untuk memilih kelas penyimpanan Amazon S3 yang sesuai yang sesuai 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 dapat menjadi pilihan yang baik, karena membantu mengurangi biaya. Jika Anda 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 membutuhkan penggunaan 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 pemadatan otomatis Iceberg, jika Anda menggunakan tabel Iceberg, yang menghasilkan ukuran file yang lebih optimal, untuk meningkatkan efisiensi kueri. Untuk informasi selengkapnya, lihat Katalog Data AWS Glue sekarang mendukung pemadatan otomatis tabel Apache Iceberg.

Kesalahan perlambatan HTTP

Hal ini terjadi ketika tingkat permintaan melebihi ambang batas pra-konfigurasi pada awalan Amazon S3. Kesalahan HTTP yang paling sering terjadi ketika status ini tercapai adalah sebagai berikut: Kes alahan 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 yang digunakan 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 di-query, lihat Properti konfigurasi penyetelan kinerja dalam dokumentasi konektor Hive.

Kesulitan menanyakan file kecil

Mengkueri 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 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 Katalog Data AWS Glue sekarang mendukung pemadatan otomatis tabel Apache Iceberg.

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 dari waktu ke waktu, terutama karena banyaknya volume data untuk dipindai ketika 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 bisa membutuhkan beberapa pekerjaan, karena mungkin berarti mengubah skema data sumber Anda. Tetapi hasil positifnya adalah mengurangi volume data dan menghasilkan kueri yang lebih cepat. Untuk informasi selengkapnya, lihat Mengelola siklus hidup objek.