Tuning kinerja di Athena - Amazon Athena
Kuota layananBatas sumber dayaTeknik pengoptimalan kueriTeknik pengoptimalan dataSumber daya tambahan

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

Tuning kinerja di Athena

Topik ini memberikan informasi umum dan saran khusus untuk meningkatkan kinerja kueri Athena Anda, dan cara mengatasi kesalahan yang terkait dengan batasan dan penggunaan sumber daya.

Kuota layanan

Athena memberlakukan kuota untuk metrik seperti waktu berjalan kueri, jumlah kueri bersamaan dalam akun, dan tingkat permintaan API. Untuk informasi lebih lanjut tentang kuota ini, lihatService Quotas. Melebihi kuota ini menyebabkan kueri gagal — baik saat dikirimkan, atau selama eksekusi kueri.

Banyak tips optimasi kinerja di halaman ini dapat membantu mengurangi waktu berjalan kueri. Optimalisasi membebaskan kapasitas sehingga Anda dapat menjalankan lebih banyak kueri dalam kuota konkurensi dan menjaga agar kueri tidak dibatalkan karena berjalan terlalu lama.

Kuota pada jumlah kueri bersamaan dan permintaan API adalah per dan. Akun AWS Wilayah AWS Kami merekomendasikan menjalankan satu beban kerja per Akun AWS (atau menggunakan reservasi kapasitas yang disediakan terpisah) agar beban kerja tidak bersaing untuk kuota yang sama.

Jika Anda menjalankan dua beban kerja di akun yang sama, salah satu beban kerja dapat menjalankan banyak kueri. Hal ini dapat menyebabkan beban kerja yang tersisa terhambat atau diblokir agar tidak menjalankan kueri. Untuk menghindari hal ini, Anda dapat memindahkan beban kerja ke akun terpisah untuk memberikan setiap beban kerja kuota konkurensi sendiri. Membuat reservasi kapasitas yang disediakan untuk salah satu atau kedua beban kerja mencapai tujuan yang sama.

Kuota di layanan lain

Ketika Athena menjalankan kueri, ia dapat memanggil layanan lain yang memberlakukan kuota. Selama eksekusi kueri, Athena dapat melakukan panggilan API ke, Amazon S3 AWS Glue Data Catalog, dan layanan AWS lain seperti IAM dan. AWS KMS Jika Anda menggunakan kueri federasi, Athena juga menelepon. AWS Lambda Semua layanan ini memiliki batas dan kuota sendiri yang dapat dilampaui. Ketika eksekusi kueri menemukan kesalahan dari layanan ini, gagal dan menyertakan kesalahan dari layanan sumber. Kesalahan yang dapat dipulihkan dicoba ulang, tetapi kueri masih bisa gagal jika masalah tidak teratasi dengan sendirinya tepat waktu. Pastikan untuk membaca pesan kesalahan secara menyeluruh untuk menentukan apakah pesan tersebut berasal dari Athena atau dari layanan lain. Beberapa kesalahan yang relevan tercakup dalam dokumen ini.

Untuk informasi selengkapnya tentang mengatasi kesalahan yang disebabkan oleh kuota layanan Amazon S3, lihat Hindari memiliki terlalu banyak file nanti di dokumen ini. Untuk informasi selengkapnya tentang pengoptimalan kinerja Amazon S3, lihat Pola desain praktik terbaik: mengoptimalkan kinerja Amazon S3 di Panduan Pengguna Amazon S3.

Batas sumber daya

Athena menjalankan kueri di mesin kueri terdistribusi. Saat Anda mengirimkan kueri, perencana kueri mesin Athena memperkirakan kapasitas komputasi yang diperlukan untuk menjalankan kueri dan menyiapkan sekelompok node komputasi yang sesuai. Beberapa query seperti query DDL berjalan hanya pada satu node. Kueri kompleks pada kumpulan data besar berjalan pada cluster yang jauh lebih besar. Node seragam, dengan konfigurasi memori, CPU, dan disk yang sama. Athena meningkatkan, bukan meningkatkan, untuk memproses pertanyaan yang lebih menuntut.

Terkadang permintaan kueri melebihi sumber daya yang tersedia untuk cluster yang menjalankan kueri. Ketika ini terjadi, kueri gagal dengan kesalahan Sumber daya yang habis Kueri pada faktor skala ini.

Sumber daya yang paling sering habis adalah memori, tetapi dalam kasus yang jarang terjadi juga bisa berupa ruang disk. Kesalahan memori biasanya terjadi ketika mesin melakukan fungsi gabungan atau jendela, tetapi mereka juga dapat terjadi dalam jumlah dan agregasi yang berbeda.

Bahkan jika kueri gagal dengan kesalahan 'kehabisan sumber daya' sekali, itu mungkin berhasil ketika Anda menjalankannya lagi. Eksekusi kueri tidak deterministik. Faktor-faktor seperti berapa lama waktu yang dibutuhkan untuk memuat data dan bagaimana dataset menengah didistribusikan melalui node dapat menghasilkan penggunaan sumber daya yang berbeda. Misalnya, bayangkan kueri yang menggabungkan dua tabel dan memiliki kemiringan berat dalam distribusi nilai untuk kondisi gabungan. Kueri semacam itu dapat berhasil sebagian besar waktu tetapi kadang-kadang gagal ketika nilai yang paling umum akhirnya diproses oleh node yang sama.

Untuk mencegah kueri Anda melebihi sumber daya yang tersedia, gunakan kiat penyetelan kinerja yang disebutkan dalam dokumen ini. Khususnya, untuk tips tentang cara mengoptimalkan kueri yang menghabiskan sumber daya yang tersedia, lihat Mengoptimalkan bergabungMengoptimalkan fungsi jendela, danMengoptimalkan kueri dengan menggunakan perkiraan.

Teknik pengoptimalan kueri

Gunakan teknik pengoptimalan kueri yang dijelaskan di bagian ini untuk membuat kueri berjalan lebih cepat atau sebagai solusi untuk kueri yang melebihi batas sumber daya di Athena.

Mengoptimalkan bergabung

Ada banyak strategi berbeda untuk mengeksekusi gabungan dalam mesin kueri terdistribusi. Dua yang paling umum adalah gabungan hash terdistribusi dan kueri dengan kondisi gabungan yang kompleks.

Gabung hash terdistribusi

Jenis gabungan yang paling umum menggunakan perbandingan kesetaraan sebagai kondisi gabungan. Athena menjalankan jenis join ini sebagai gabungan hash terdistribusi.

Dalam gabungan hash terdistribusi, mesin membangun tabel pencarian (tabel hash) dari salah satu sisi gabungan. Sisi ini disebut sisi build. Catatan sisi build didistribusikan di seluruh node. Setiap node membangun tabel pencarian untuk subsetnya. Sisi lain dari gabungan, yang disebut sisi probe, kemudian dialirkan melalui node. Catatan dari sisi probe didistribusikan di atas node dengan cara yang sama seperti sisi build. Ini memungkinkan setiap node untuk melakukan gabungan dengan mencari catatan yang cocok di tabel pencariannya sendiri.

Saat tabel pencarian yang dibuat dari sisi build join tidak sesuai dengan memori, kueri bisa gagal. Bahkan jika ukuran total sisi build kurang dari memori yang tersedia, kueri dapat gagal jika distribusi catatan memiliki kemiringan yang signifikan. Dalam kasus ekstrim, semua catatan dapat memiliki nilai yang sama untuk kondisi gabungan dan harus masuk ke dalam memori pada satu node. Bahkan kueri dengan sedikit kemiringan dapat gagal jika satu set nilai dikirim ke node yang sama dan nilainya bertambah hingga lebih dari memori yang tersedia. Node memang memiliki kemampuan untuk menumpahkan catatan ke disk, tetapi tumpahan memperlambat eksekusi kueri dan tidak cukup untuk mencegah kueri gagal.

Athena mencoba menyusun ulang gabungan untuk menggunakan relasi yang lebih besar sebagai sisi probe, dan relasi yang lebih kecil sebagai sisi build. Namun, karena Athena tidak mengelola data dalam tabel, ia memiliki informasi yang terbatas dan sering harus mengasumsikan bahwa tabel pertama lebih besar dan tabel kedua lebih kecil.

Saat menulis gabungan dengan kondisi gabungan berbasis ekualitas, asumsikan bahwa tabel di sebelah kiri JOIN kata kunci adalah sisi probe dan tabel di sebelah kanan adalah sisi build. Pastikan bahwa tabel yang tepat, sisi build, adalah tabel yang lebih kecil. Jika tidak memungkinkan untuk membuat sisi build dari join cukup kecil agar sesuai dengan memori, pertimbangkan untuk menjalankan beberapa kueri yang menggabungkan subset tabel build.

Jenis bergabung lainnya

Kueri dengan kondisi gabungan yang kompleks (misalnya, kueri yang menggunakanLIKE,>, atau operator lain), seringkali menuntut komputasi. Dalam kasus terburuk, setiap catatan dari satu sisi bergabung harus dibandingkan dengan setiap catatan di sisi lain dari bergabung. Karena waktu eksekusi tumbuh dengan kuadrat jumlah catatan, kueri tersebut berisiko melebihi waktu eksekusi maksimum.

Untuk mengetahui bagaimana Athena akan menjalankan kueri Anda sebelumnya, Anda dapat menggunakan pernyataan tersebut. EXPLAIN Untuk informasi selengkapnya, lihat Menggunakan JELASKAN dan JELASKAN ANALISIS di Athena dan Memahami Athena MENJELASKAN hasil pernyataan.

Mengoptimalkan fungsi jendela

Karena fungsi jendela adalah operasi intensif sumber daya, mereka dapat membuat kueri berjalan lambat atau bahkan gagal dengan pesan Sumber daya yang habis Kueri pada faktor skala ini. Fungsi jendela menyimpan semua catatan yang mereka operasikan dalam memori untuk menghitung hasilnya. Ketika jendela sangat besar, fungsi jendela bisa kehabisan memori.

Untuk memastikan kueri Anda berjalan dalam batas memori yang tersedia, kurangi ukuran jendela tempat fungsi jendela Anda beroperasi. Untuk melakukannya, Anda dapat menambahkan PARTITIONED BY klausa atau mempersempit cakupan klausa partisi yang ada.

Gunakan fungsi non-jendela sebagai gantinya

Terkadang kueri dengan fungsi jendela dapat ditulis ulang tanpa fungsi jendela. Misalnya, alih-alih menggunakan row_number untuk menemukan N catatan teratas, Anda dapat menggunakan ORDER BY danLIMIT. Alih-alih menggunakan row_number atau menghapus rank duplikat catatan, Anda dapat menggunakan fungsi agregat seperti max_by, min_by, dan arbitrer.

Misalnya, Anda memiliki kumpulan data dengan pembaruan dari sensor. Sensor secara berkala melaporkan status baterainya dan menyertakan beberapa metadata seperti lokasi. Jika Anda ingin mengetahui status baterai terakhir untuk setiap sensor dan lokasinya, Anda dapat menggunakan kueri ini:

SELECT sensor_id,
       arbitrary(location) AS location,
       max_by(battery_status, updated_at) AS battery_status
FROM sensor_readings
GROUP BY sensor_id

Karena metadata seperti lokasi sama untuk setiap catatan, Anda dapat menggunakan arbitrary fungsi untuk memilih nilai apa pun dari grup.

Untuk mendapatkan status baterai terakhir, Anda dapat menggunakan max_by fungsi ini. max_byFungsi memilih nilai untuk kolom dari catatan di mana nilai maksimum kolom lain ditemukan. Dalam hal ini, ia mengembalikan status baterai untuk catatan dengan waktu pembaruan terakhir dalam grup. Kueri ini berjalan lebih cepat dan menggunakan lebih sedikit memori daripada kueri setara dengan fungsi jendela.

Mengoptimalkan agregasi

Ketika Athena melakukan agregasi, Athena mendistribusikan catatan di seluruh node pekerja menggunakan kolom dalam klausa. GROUP BY Untuk membuat tugas mencocokkan catatan ke grup seefisien mungkin, node berusaha menyimpan catatan dalam memori tetapi menumpahkannya ke disk jika perlu.

Ini juga merupakan ide yang baik untuk menghindari memasukkan kolom berlebihan dalam GROUP BY klausa. Karena lebih sedikit kolom membutuhkan lebih sedikit memori, kueri yang menggambarkan grup menggunakan lebih sedikit kolom lebih efisien. Kolom numerik juga menggunakan lebih sedikit memori daripada string. Misalnya, saat Anda menggabungkan kumpulan data yang memiliki ID kategori numerik dan nama kategori, gunakan hanya kolom ID kategori dalam klausa. GROUP BY

Terkadang kueri menyertakan kolom dalam GROUP BY klausa untuk mengatasi fakta bahwa kolom harus menjadi bagian dari GROUP BY klausa atau ekspresi agregat. Jika aturan ini tidak diikuti, Anda dapat menerima pesan galat seperti berikut:

EXPRESSION_NOT_AGGREGATE: baris 1:8: 'kategori' harus berupa ekspresi agregat atau muncul di klausa GROUP BY

Untuk menghindari keharusan menambahkan kolom redundan ke GROUP BY klausa, Anda dapat menggunakan fungsi arbitrer, seperti pada contoh berikut.

SELECT country_id,
       arbitrary(country_name) AS country_name,
       COUNT(*) AS city_count
FROM world_cities
GROUP BY country_id

ARBITRARYFungsi mengembalikan nilai arbitrer dari grup. Fungsi ini berguna ketika Anda tahu semua catatan dalam grup memiliki nilai yang sama untuk kolom, tetapi nilainya tidak mengidentifikasi grup.

Mengoptimalkan kueri N teratas

ORDER BYKlausa mengembalikan hasil query dalam urutan diurutkan. Athena menggunakan pengurutan terdistribusi untuk menjalankan operasi pengurutan secara paralel pada beberapa node.

Jika Anda tidak benar-benar membutuhkan hasil Anda untuk diurutkan, hindari menambahkan ORDER BY klausa. Selain itu, hindari ORDER BY menambahkan kueri batin jika tidak benar-benar diperlukan. Dalam banyak kasus, perencana kueri dapat menghapus penyortiran yang berlebihan, tetapi ini tidak dijamin. Pengecualian untuk aturan ini adalah jika kueri dalam melakukan N operasi teratas, seperti menemukan nilai terbaru, atau N paling umum. N

Ketika Athena melihat ORDER BY bersamaLIMIT, ia memahami bahwa Anda menjalankan N kueri teratas dan menggunakan operasi khusus yang sesuai.

catatan

Meskipun Athena juga sering dapat mendeteksi fungsi jendela seperti row_number itu menggunakan topN, kami merekomendasikan versi yang lebih sederhana yang menggunakan ORDER BY dan. LIMIT Untuk informasi selengkapnya, lihat Mengoptimalkan fungsi jendela.

Sertakan hanya kolom yang diperlukan

Jika Anda tidak benar-benar membutuhkan kolom, jangan sertakan dalam kueri Anda. Semakin sedikit data yang harus diproses oleh kueri, semakin cepat ia akan berjalan. Ini mengurangi jumlah memori yang dibutuhkan dan jumlah data yang harus dikirim antar node. Jika Anda menggunakan format file kolumnar, mengurangi kolom angka juga mengurangi jumlah data yang dibaca dari Amazon S3.

Athena tidak memiliki batasan spesifik pada jumlah kolom dalam hasil, tetapi bagaimana kueri dijalankan membatasi kemungkinan ukuran gabungan kolom. Ukuran gabungan kolom mencakup nama dan jenisnya.

Misalnya, kesalahan berikut disebabkan oleh relasi yang melebihi batas ukuran untuk deskriptor relasi:

GENERIC_INTERNAL_ERROR: io.airlift.bytecode. CompilationException

Untuk mengatasi masalah ini, kurangi jumlah kolom dalam kueri, atau buat subkueri dan gunakan JOIN yang mengambil sejumlah kecil data. Jika Anda memiliki kueri yang dilakukan SELECT * di kueri terluar, Anda harus mengubah * ke daftar hanya kolom yang Anda butuhkan.

Mengoptimalkan kueri dengan menggunakan perkiraan

Athena memiliki dukungan untuk fungsi agregat aproksimasi untuk menghitung nilai yang berbeda, nilai yang paling sering, persentil (termasuk perkiraan median), dan membuat histogram. Gunakan fungsi-fungsi ini setiap kali nilai yang tepat tidak diperlukan.

Tidak seperti COUNT(DISTINCT col) operasi, approx_distinct menggunakan lebih sedikit memori dan berjalan lebih cepat. Demikian pula, menggunakan numeric_histogram alih-alih histogram menggunakan metode perkiraan dan karenanya lebih sedikit memori.

Mengoptimalkan LIKE

Anda dapat menggunakan LIKE untuk menemukan string yang cocok, tetapi dengan string panjang, ini adalah komputasi intensif. Fungsi regexp_like dalam banyak kasus merupakan alternatif yang lebih cepat, dan juga memberikan lebih banyak fleksibilitas.

Seringkali Anda dapat mengoptimalkan pencarian dengan menambatkan substring yang Anda cari. Misalnya, jika Anda mencari awalan, jauh lebih baik menggunakan 'substr %' daripada '% substr %'. Atau, jika Anda menggunakanregexp_like, '^ substr '.

Gunakan UNION ALL alih-alih UNION

UNION ALLdan UNION dua cara untuk menggabungkan hasil dari dua query menjadi satu hasil. UNION ALLmenggabungkan catatan dari kueri pertama dengan yang kedua, dan UNION melakukan hal yang sama, tetapi juga menghapus duplikat. UNIONperlu memproses semua catatan dan menemukan duplikat, yang merupakan memori dan komputasi intensif, tetapi UNION ALL merupakan operasi yang relatif cepat. Kecuali Anda perlu menghapus duplikat catatan, gunakan UNION ALL untuk kinerja terbaik.

Gunakan UNLOAD untuk set hasil besar

Ketika hasil kueri diharapkan besar (misalnya, puluhan ribu baris atau lebih), gunakan UNLOAD untuk mengekspor hasilnya. Dalam kebanyakan kasus, ini lebih cepat daripada menjalankan kueri biasa, dan menggunakan UNLOAD juga memberi Anda lebih banyak kontrol atas output.

Saat kueri selesai dijalankan, Athena menyimpan hasilnya sebagai satu file CSV yang tidak terkompresi di Amazon S3. Ini membutuhkan waktu lebih lama dariUNLOAD, bukan hanya karena hasilnya tidak terkompresi, tetapi juga karena operasi tidak dapat diparalelkan. Sebaliknya, UNLOAD menulis hasil langsung dari node pekerja dan memanfaatkan sepenuhnya paralelisme cluster komputasi. Selain itu, Anda dapat mengonfigurasi UNLOAD untuk menulis hasil dalam format terkompresi dan dalam format file lain seperti JSON dan Parket.

Untuk informasi selengkapnya, lihat MEMBONGKAR.

Gunakan CTAS atau Glue ETL untuk mewujudkan agregasi yang sering digunakan

'Mewujudkan' kueri adalah cara mempercepat kinerja kueri dengan menyimpan hasil kueri kompleks yang telah dihitung sebelumnya (misalnya, agregasi dan gabungan) untuk digunakan kembali dalam kueri berikutnya.

Jika banyak kueri Anda menyertakan gabungan dan agregasi yang sama, Anda dapat mewujudkan subquery umum sebagai tabel baru dan kemudian menjalankan kueri terhadap tabel tersebut. Anda dapat membuat tabel baru denganMembuat tabel dari hasil query (CTAS), atau alat ETL khusus seperti Glue ETL.

Misalnya, Anda memiliki dasbor dengan widget yang menunjukkan aspek berbeda dari kumpulan data pesanan. Setiap widget memiliki kueri sendiri, tetapi semua kueri berbagi gabungan dan filter yang sama. Tabel pesanan digabungkan dengan tabel item baris, dan ada filter untuk ditampilkan hanya tiga bulan terakhir. Jika Anda mengidentifikasi fitur umum dari kueri ini, Anda dapat membuat tabel baru yang dapat digunakan widget. Ini mengurangi duplikasi dan meningkatkan kinerja. Kerugiannya adalah Anda harus memperbarui tabel baru.

Gunakan kembali hasil kueri

Biasanya kueri yang sama berjalan beberapa kali dalam durasi singkat. Misalnya, ini dapat terjadi ketika beberapa orang membuka dasbor data yang sama. Saat menjalankan kueri, Anda dapat memberi tahu Athena untuk menggunakan kembali hasil yang dihitung sebelumnya. Anda menentukan usia maksimum hasil yang akan digunakan kembali. Jika kueri yang sama sebelumnya dijalankan dalam jangka waktu tersebut, Athena mengembalikan hasil tersebut alih-alih menjalankan kueri lagi. Untuk informasi selengkapnya, lihat di Menggunakan kembali hasil kueri sini di Panduan Pengguna Amazon Athena dan Kurangi biaya serta tingkatkan kinerja kueri dengan Penggunaan Kembali Hasil Kueri Amazon Athena di AWS Blog Big Data.

Teknik pengoptimalan data

Kinerja tidak hanya bergantung pada kueri, tetapi juga penting pada bagaimana dataset Anda diatur dan pada format file dan kompresi yang digunakannya.

Partisi data Anda

Partisi membagi tabel Anda menjadi beberapa bagian dan menyimpan data terkait bersama-sama berdasarkan properti seperti tanggal, negara, atau wilayah. Tombol partisi bertindak sebagai kolom virtual. Anda menentukan kunci partisi pada pembuatan tabel dan menggunakannya untuk memfilter kueri Anda. Saat Anda memfilter kolom kunci partisi, hanya data dari partisi yang cocok yang dibaca. Misalnya, jika kumpulan data Anda dipartisi berdasarkan tanggal dan kueri Anda memiliki filter yang hanya cocok minggu lalu, hanya data untuk minggu terakhir yang dibaca. Untuk informasi selengkapnya tentang partisi, lihat. Partisi data di Athena

Pilih kunci partisi yang akan mendukung kueri Anda

Karena partisi memiliki dampak signifikan pada kinerja kueri, pastikan untuk mempertimbangkan bagaimana Anda mempartisi dengan hati-hati ketika Anda mendesain dataset dan tabel Anda. Memiliki terlalu banyak kunci partisi dapat mengakibatkan dataset terfragmentasi dengan terlalu banyak file dan file yang terlalu kecil. Sebaliknya, memiliki terlalu sedikit kunci partisi, atau tidak ada partisi sama sekali, mengarah ke kueri yang memindai lebih banyak data daripada yang diperlukan.

Hindari mengoptimalkan kueri langka

Strategi yang baik adalah mengoptimalkan kueri yang paling umum dan menghindari pengoptimalan untuk kueri langka. Misalnya, jika kueri Anda melihat rentang waktu hari, jangan partisi berdasarkan jam, bahkan jika beberapa kueri memfilter ke tingkat itu. Jika data Anda memiliki kolom timestamp granular, kueri langka yang memfilter berdasarkan jam dapat menggunakan kolom stempel waktu. Bahkan jika kasus yang jarang memindai sedikit lebih banyak data daripada yang diperlukan, mengurangi kinerja keseluruhan demi kasus yang jarang terjadi biasanya bukan tradeoff yang baik.

Untuk mengurangi jumlah data yang harus dipindai oleh kueri, dan dengan demikian meningkatkan kinerja, gunakan format file kolumnar dan simpan catatan yang diurutkan. Alih-alih mempartisi berdasarkan jam, simpan catatan yang diurutkan berdasarkan stempel waktu. Untuk kueri pada jendela waktu yang lebih pendek, pengurutan berdasarkan stempel waktu hampir sama efisiennya dengan mempartisi berdasarkan jam. Selain itu, penyortiran berdasarkan stempel waktu biasanya tidak merusak kinerja kueri pada jendela waktu yang dihitung dalam beberapa hari. Untuk informasi selengkapnya, lihat Gunakan format file kolumnar.

Perhatikan bahwa kueri pada tabel dengan puluhan ribu partisi berkinerja lebih baik jika ada predikat pada semua kunci partisi. Ini adalah alasan lain untuk merancang skema partisi Anda untuk kueri yang paling umum. Untuk informasi selengkapnya, lihat Partisi kueri berdasarkan kesetaraan.

Gunakan proyeksi partisi

Proyeksi partisi adalah fitur Athena yang menyimpan informasi partisi tidak AWS Glue Data Catalog di, tetapi sebagai aturan dalam properti tabel di. AWS Glue Ketika Athena merencanakan kueri pada tabel yang dikonfigurasi dengan proyeksi partisi, Athena membaca aturan proyeksi partisi tabel. Athena menghitung partisi untuk dibaca dalam memori berdasarkan kueri dan aturan alih-alih mencari partisi di. AWS Glue Data Catalog

Selain menyederhanakan manajemen partisi, proyeksi partisi dapat meningkatkan kinerja untuk dataset yang memiliki sejumlah besar partisi. Ketika kueri menyertakan rentang alih-alih nilai spesifik untuk kunci partisi, mencari partisi yang cocok dalam katalog membutuhkan waktu lebih lama semakin banyak partisi yang ada. Dengan proyeksi partisi, filter dapat dihitung dalam memori tanpa masuk ke katalog, dan bisa jauh lebih cepat.

Dalam keadaan tertentu, proyeksi partisi dapat menghasilkan kinerja yang lebih buruk. Salah satu contoh terjadi ketika sebuah tabel “jarang.” Tabel sparse tidak memiliki data untuk setiap permutasi nilai kunci partisi yang dijelaskan oleh konfigurasi proyeksi partisi. Dengan tabel jarang, kumpulan partisi yang dihitung dari kueri dan konfigurasi proyeksi partisi semuanya terdaftar di Amazon S3 bahkan ketika mereka tidak memiliki data.

Bila Anda menggunakan proyeksi partisi, pastikan untuk menyertakan predikat pada semua kunci partisi. Persempit cakupan nilai yang mungkin untuk menghindari daftar Amazon S3 yang tidak perlu. Bayangkan kunci partisi yang memiliki kisaran satu juta nilai dan kueri yang tidak memiliki filter pada kunci partisi itu. Untuk menjalankan kueri, Athena harus melakukan setidaknya satu juta operasi daftar Amazon S3. Kueri tercepat ketika Anda menanyakan nilai tertentu, terlepas dari apakah Anda menggunakan proyeksi partisi atau menyimpan informasi partisi dalam katalog. Untuk informasi selengkapnya, lihat Partisi kueri berdasarkan kesetaraan.

Saat Anda mengonfigurasi tabel untuk proyeksi partisi, pastikan rentang yang Anda tentukan masuk akal. Jika kueri tidak menyertakan predikat pada kunci partisi, semua nilai dalam rentang untuk kunci tersebut digunakan. Jika kumpulan data Anda dibuat pada tanggal tertentu, gunakan tanggal tersebut sebagai titik awal untuk rentang tanggal apa pun. Gunakan NOW sebagai rentang akhir tanggal. Hindari rentang numerik yang memiliki sejumlah besar nilai, dan pertimbangkan untuk menggunakan tipe yang disuntikkan sebagai gantinya.

Untuk informasi selengkapnya tentang proyek partisi, lihat Proyeksi partisi dengan Amazon Athena.

Gunakan indeks partisi

Indeks partisi adalah fitur dalam AWS Glue Data Catalog yang meningkatkan kinerja pencarian partisi untuk tabel yang memiliki sejumlah besar partisi.

Daftar partisi dalam katalog seperti tabel dalam database relasional. Tabel memiliki kolom untuk kunci partisi dan kolom tambahan untuk lokasi partisi. Saat Anda menanyakan tabel yang dipartisi, lokasi partisi dicari dengan memindai tabel ini.

Sama seperti database relasional, Anda dapat meningkatkan kinerja kueri dengan menambahkan indeks. Anda dapat menambahkan beberapa indeks untuk mendukung pola kueri yang berbeda. Indeks AWS Glue Data Catalog partisi mendukung operator kesetaraan dan perbandingan seperti>,>=, dan < dikombinasikan dengan AND operator. Untuk informasi selengkapnya, lihat Bekerja dengan indeks partisi AWS Glue di Panduan AWS Glue Pengembang dan Meningkatkan kinerja kueri Amazon Athena AWS Glue Data Catalog menggunakan indeks partisi di AWS Blog Big Data.

Selalu gunakan STRING sebagai tipe untuk kunci partisi

Saat Anda menanyakan kunci partisi, ingatlah bahwa Athena memerlukan kunci partisi untuk menjadi tipe untuk menekan pemfilteran partisi ke STRING dalam. AWS Glue Jika jumlah partisi tidak sedikit, menggunakan jenis lain dapat menyebabkan kinerja yang lebih buruk. Jika nilai kunci partisi Anda seperti tanggal atau seperti angka, lemparkan ke jenis yang sesuai dalam kueri Anda.

Hapus partisi lama dan kosong

Jika Anda menghapus data dari partisi di Amazon S3 (misalnya, dengan menggunakan siklus hidup Amazon S3), Anda juga harus menghapus entri partisi dari. AWS Glue Data Catalog Selama perencanaan kueri, partisi apa pun yang cocok dengan kueri terdaftar di Amazon S3. Jika Anda memiliki banyak partisi kosong, overhead daftar partisi ini dapat merugikan.

Juga, jika Anda memiliki ribuan partisi, pertimbangkan untuk menghapus metadata partisi untuk data lama yang tidak lagi relevan. Misalnya, jika kueri tidak pernah melihat data yang lebih tua dari setahun, Anda dapat menghapus metadata partisi secara berkala untuk partisi yang lebih lama. Jika jumlah partisi bertambah menjadi puluhan ribu, menghapus partisi yang tidak terpakai dapat mempercepat kueri yang tidak menyertakan predikat pada semua kunci partisi. Untuk informasi tentang menyertakan predikat pada semua kunci partisi dalam kueri Anda, lihat. Partisi kueri berdasarkan kesetaraan

Partisi kueri berdasarkan kesetaraan

Kueri yang menyertakan predikat kesetaraan pada semua kunci partisi berjalan lebih cepat karena metadata partisi dapat dimuat secara langsung. Hindari kueri di mana satu atau lebih kunci partisi tidak memiliki predikat, atau predikat memilih rentang nilai. Untuk kueri seperti itu, daftar semua partisi harus disaring untuk menemukan nilai yang cocok. Untuk sebagian besar tabel, overhead minimal, tetapi untuk tabel dengan puluhan ribu atau lebih partisi, overhead bisa menjadi signifikan.

Jika tidak mungkin untuk menulis ulang kueri Anda untuk memfilter partisi berdasarkan kesetaraan, Anda dapat mencoba proyeksi partisi. Untuk informasi selengkapnya, lihat Gunakan proyeksi partisi.

Hindari menggunakan MSCK REPAIR TABLE untuk pemeliharaan partisi

Karena MSCK REPAIR TABLE bisa memakan waktu lama untuk dijalankan, hanya menambahkan partisi baru, dan tidak menghapus partisi lama, itu bukan cara yang efisien untuk mengelola partisi (lihat). Pertimbangan dan batasan

Partisi lebih baik dikelola secara manual menggunakan AWS Glue Data Catalog API,ALTER TABLE ADD PARTITION, atau AWS Glue crawler. Sebagai alternatif, Anda dapat menggunakan proyeksi partisi, yang menghilangkan kebutuhan untuk mengelola partisi sama sekali. Untuk informasi selengkapnya, lihat Proyeksi partisi dengan Amazon Athena.

Validasi bahwa kueri Anda kompatibel dengan skema partisi

Anda dapat memeriksa terlebih dahulu partisi mana yang akan dipindai kueri dengan menggunakan EXPLAINpernyataan tersebut. Awali kueri Anda dengan EXPLAIN kata kunci, lalu cari fragmen sumber (misalnya,Fragment 2 [SOURCE]) untuk setiap tabel di dekat bagian bawah output. EXPLAIN Cari tugas di mana sisi kanan didefinisikan sebagai kunci partisi. Baris di bawahnya menyertakan daftar semua nilai untuk kunci partisi yang akan dipindai saat kueri dijalankan.

Misalnya, Anda memiliki kueri di atas meja dengan kunci dt partisi dan awalan kueri denganEXPLAIN. Jika nilai dalam kueri adalah tanggal, dan filter memilih rentang tiga hari, EXPLAIN output mungkin terlihat seperti ini:

dt := dt:string:PARTITION_KEY
    :: [[2023-06-11], [2023-06-12], [2023-06-13]]

EXPLAINOutput menunjukkan bahwa perencana menemukan tiga nilai untuk kunci partisi ini yang cocok dengan kueri. Ini juga menunjukkan kepada Anda apa nilai-nilai itu. Untuk informasi selengkapnya tentang penggunaanEXPLAIN, lihat Menggunakan JELASKAN dan JELASKAN ANALISIS di Athena danMemahami Athena MENJELASKAN hasil pernyataan.

Gunakan format file kolumnar

Format file kolumnar seperti Parket dan ORC dirancang untuk beban kerja analitik terdistribusi. Mereka mengatur data berdasarkan kolom, bukan berdasarkan baris. Mengatur data dalam format kolumnar menawarkan keuntungan sebagai berikut:

  • Hanya kolom yang diperlukan untuk kueri yang dimuat

  • Jumlah keseluruhan data yang perlu dimuat berkurang

  • Nilai kolom disimpan bersama, sehingga data dapat dikompresi secara efisien

  • File dapat berisi metadata yang memungkinkan mesin melewati pemuatan data yang tidak dibutuhkan

Sebagai contoh bagaimana metadata file dapat digunakan, metadata file dapat berisi informasi tentang nilai minimum dan maksimum dalam halaman data. Jika nilai yang ditanyakan tidak berada dalam rentang yang dicatat dalam metadata, halaman dapat dilewati.

Salah satu cara untuk menggunakan metadata ini untuk meningkatkan kinerja adalah memastikan bahwa data dalam file diurutkan. Misalnya, Anda memiliki kueri yang mencari catatan di mana created_at entri berada dalam rentang waktu yang singkat. Jika data Anda diurutkan berdasarkan created_at kolom, Athena dapat menggunakan nilai minimum dan maksimum dalam metadata file untuk melewati bagian file data yang tidak diperlukan.

Saat menggunakan format file kolumnar, pastikan file Anda tidak terlalu kecil. Seperti disebutkan dalamHindari memiliki terlalu banyak file, kumpulan data dengan banyak file kecil menyebabkan masalah kinerja. Hal ini terutama berlaku dengan format file kolumnar. Untuk file kecil, overhead format file kolumnar melebihi manfaatnya.

Perhatikan bahwa Parket dan ORC diatur secara internal oleh kelompok baris (Parket) dan garis (ORC). Ukuran default untuk grup baris adalah 128 MB, dan untuk garis, 64 MB. Jika Anda memiliki banyak kolom, Anda dapat meningkatkan grup baris dan ukuran garis untuk kinerja yang lebih baik. Mengurangi grup baris atau ukuran garis menjadi kurang dari nilai defaultnya tidak disarankan.

Untuk mengonversi format data lain ke Parket atau ORC, Anda dapat menggunakan AWS Glue ETL atau Athena. Untuk informasi lebih lanjut tentang menggunakan Athena untuk ETL, lihat. Menggunakan CTAS dan INSERT INTO untuk ETL dan analisis data

Kompres data

Athena mendukung berbagai format kompresi. Menanyakan data terkompresi lebih cepat dan juga lebih murah karena Anda membayar jumlah byte yang dipindai sebelum dekompresi.

Format gzip memberikan rasio kompresi yang baik dan memiliki berbagai dukungan di seluruh alat dan layanan lainnya. Format zstd (Zstandard) adalah format kompresi yang lebih baru dengan keseimbangan yang baik antara kinerja dan rasio kompresi.

Saat mengompresi file teks seperti data JSON dan CSV, cobalah untuk mencapai keseimbangan antara jumlah file dan ukuran file. Sebagian besar format kompresi mengharuskan pembaca untuk membaca file dari awal. Ini berarti bahwa file teks terkompresi tidak dapat, secara umum, diproses secara paralel. File besar yang tidak terkompresi sering dibagi antara pekerja untuk mencapai paralelisme yang lebih tinggi selama pemrosesan kueri, tetapi ini tidak mungkin dilakukan dengan sebagian besar format kompresi.

Seperti yang dibahas dalamHindari memiliki terlalu banyak file, lebih baik tidak memiliki terlalu banyak file atau terlalu sedikit. Karena jumlah file adalah batas berapa banyak pekerja yang dapat memproses kueri, aturan ini terutama berlaku untuk file terkompresi.

Untuk informasi lebih lanjut tentang penggunaan kompresi di Athena, lihat. Dukungan kompresi Athena

Gunakan bucketing untuk pencarian pada tombol dengan kardinalitas tinggi

Bucketing adalah teknik untuk mendistribusikan catatan ke dalam file terpisah berdasarkan nilai salah satu kolom. Ini memastikan bahwa semua catatan dengan nilai yang sama akan berada dalam file yang sama. Bucketing berguna ketika Anda memiliki kunci dengan kardinalitas tinggi dan banyak kueri Anda mencari nilai spesifik dari kunci tersebut.

Misalnya, Anda menanyakan satu set catatan untuk pengguna tertentu. Jika data diselimuti oleh ID pengguna, Athena tahu sebelumnya file mana yang berisi catatan untuk ID tertentu dan file mana yang tidak. Hal ini memungkinkan Athena untuk membaca hanya file yang dapat berisi ID, sangat mengurangi jumlah data yang dibaca. Ini juga mengurangi waktu komputasi yang jika tidak akan diperlukan untuk mencari melalui data untuk ID tertentu.

Kerugian dari bucketing

Bucketing kurang berharga ketika kueri sering mencari beberapa nilai di kolom yang dikandung oleh data. Semakin banyak nilai yang ditanyakan, semakin tinggi kemungkinan bahwa semua atau sebagian besar file harus dibaca. Misalnya, jika Anda memiliki tiga bucket, dan kueri mencari tiga nilai yang berbeda, semua file mungkin harus dibaca. Bucketing berfungsi paling baik saat kueri mencari nilai tunggal.

Untuk informasi selengkapnya, lihat Partisi dan bucketing di Athena.

Hindari memiliki terlalu banyak file

Kumpulan data yang terdiri dari banyak file kecil menghasilkan kinerja kueri keseluruhan yang buruk. Ketika Athena merencanakan kueri, itu mencantumkan semua lokasi partisi, yang membutuhkan waktu. Menangani dan meminta setiap file juga memiliki overhead komputasi. Oleh karena itu, memuat satu file yang lebih besar dari Amazon S3 lebih cepat daripada memuat catatan yang sama dari banyak file yang lebih kecil.

Dalam kasus ekstrim, Anda mungkin mengalami batas layanan Amazon S3. Amazon S3 mendukung hingga 5.500 permintaan per detik untuk satu partisi indeks. Awalnya, bucket diperlakukan sebagai partisi indeks tunggal, tetapi ketika beban permintaan meningkat, itu dapat dibagi menjadi beberapa partisi indeks.

Amazon S3 melihat pola permintaan dan pemisahan berdasarkan awalan kunci. Jika dataset Anda terdiri dari ribuan file, permintaan yang berasal dari Athena dapat melebihi kuota permintaan. Bahkan dengan file yang lebih sedikit, kuota dapat dilampaui jika beberapa kueri bersamaan dibuat terhadap kumpulan data yang sama. Aplikasi lain yang mengakses file yang sama dapat berkontribusi pada jumlah total permintaan.

Ketika tingkat permintaan limit terlampaui, Amazon S3 mengembalikan kesalahan berikut. Kesalahan ini termasuk dalam informasi status untuk kueri di Athena.

SlowDown: Harap kurangi tingkat permintaan Anda

Untuk memecahkan masalah, mulailah dengan menentukan apakah kesalahan disebabkan oleh satu kueri atau oleh beberapa kueri yang membaca file yang sama. Jika yang terakhir, koordinasikan menjalankan kueri sehingga tidak berjalan pada saat yang sama. Untuk mencapai ini, tambahkan mekanisme antrian atau bahkan coba lagi di aplikasi Anda.

Jika menjalankan satu kueri memicu kesalahan, coba gabungkan file data atau modifikasi kueri untuk membaca lebih sedikit file. Waktu terbaik untuk menggabungkan file kecil adalah sebelum ditulis. Untuk melakukannya, pertimbangkan teknik-teknik berikut:

Hindari hierarki penyimpanan tambahan di luar partisi

Untuk menghindari overhead perencanaan kueri, simpan file dalam struktur datar di setiap lokasi partisi. Jangan gunakan hierarki direktori tambahan apa pun.

Ketika Athena merencanakan kueri, Athena mencantumkan semua file di semua partisi yang cocok dengan kueri. Meskipun Amazon S3 tidak memiliki direktori sendiri, konvensi ini adalah untuk menafsirkan garis miring ke / depan sebagai pemisah direktori. Ketika Athena mencantumkan lokasi partisi, secara rekursif mencantumkan direktori apa pun yang ditemukannya. Ketika file dalam partisi diatur ke dalam hierarki, beberapa putaran daftar terjadi.

Ketika semua file berada langsung di lokasi partisi, sebagian besar waktu hanya satu operasi daftar yang harus dilakukan. Namun, beberapa operasi daftar sekuensial diperlukan jika Anda memiliki lebih dari 1000 file dalam partisi karena Amazon S3 hanya mengembalikan 1000 objek per operasi daftar. Memiliki lebih dari 1000 file dalam partisi juga dapat membuat masalah kinerja lain yang lebih serius. Untuk informasi selengkapnya, lihat Hindari memiliki terlalu banyak file.

Gunakan SymlinkTextInputFormat hanya jika diperlukan

Menggunakan SymlinkTextInputFormatteknik ini bisa menjadi cara untuk mengatasi situasi ketika file untuk tabel tidak tertata rapi ke dalam partisi. Misalnya, symlink dapat berguna ketika semua file berada dalam awalan yang sama atau file dengan skema berbeda berada di lokasi yang sama.

Namun, menggunakan symlink menambahkan tingkat indirection ke eksekusi kueri. Tingkat indirection ini berdampak pada kinerja keseluruhan. File symlink harus dibaca, dan lokasi yang mereka tentukan harus terdaftar. Ini menambahkan beberapa perjalanan pulang pergi ke Amazon S3 yang tidak diperlukan oleh tabel Hive biasa. Kesimpulannya, Anda harus menggunakan SymlinkTextInputFormat hanya ketika opsi yang lebih baik seperti mengatur ulang file tidak tersedia.

Sumber daya tambahan

Untuk informasi tambahan tentang penyetelan kinerja di Athena, pertimbangkan sumber daya berikut: