Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Optimalkan kinerja 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. Secara garis besar, optimasi dapat dikelompokkan ke dalam kategori layanan, kueri, dan struktur data. Keputusan yang dibuat di tingkat layanan, tentang cara Anda menulis kueri, dan bagaimana Anda menyusun data dan tabel semuanya dapat memengaruhi kinerja. **Topics** + [Optimalkan penggunaan layanan](performance-tuning-service-level-considerations.md) + [Optimalkan kueri](performance-tuning-query-optimization-techniques.md) + [Optimalkan data](performance-tuning-data-optimization-techniques.md) + [Gunakan format penyimpanan kolumnar](columnar-storage.md) + [Gunakan partisi dan bucketing](ctas-partitioning-and-bucketing.md) + [Partisi data Anda](partitions.md) + [Gunakan proyeksi partisi dengan Amazon Athena](partition-projection.md) + [Cegah pelambatan Amazon S3](performance-tuning-s3-throttling.md) + [Sumber daya tambahan](performance-tuning-additional-resources.md) # Optimalkan penggunaan layanan Pertimbangan tingkat layanan mencakup jumlah beban kerja yang Anda jalankan per akun, kuota layanan tidak hanya untuk Athena, tetapi di seluruh layanan, dan pemikiran tentang cara mengurangi kesalahan 'kehabisan sumber daya'. **Topics** + [Mengoperasikan beberapa beban kerja dalam akun yang sama](#performance-tuning-service-quotas) + [Mengurangi kesalahan 'kehabisan sumber daya'](#performance-tuning-resource-limits) ## Mengoperasikan beberapa beban kerja dalam akun yang sama Athena menggunakan kuota untuk membatasi konkurensi kueri dan tingkat permintaan API di tingkat akun. Melebihi kuota ini dapat menyebabkan kueri gagal selama eksekusi atau pada waktu pengiriman. Untuk informasi lebih lanjut tentang kuota ini, lihat[Service Quotas](service-limits.md). Jika Anda mengoperasikan beberapa beban kerja dalam AWS akun yang sama, beban kerja Anda bersaing untuk mendapatkan kuota tingkat akun yang sama. Misalnya, jika satu beban kerja mengalami ledakan kueri yang tidak terduga, beban kerja lain yang berjalan di akun yang sama mungkin melihat waktu antrian yang meningkat, atau dalam kasus terburuk kegagalan pengiriman kueri karena pembatasan. Kami menyarankan Anda menggunakan CloudWatch untuk memantau penggunaan layanan Anda melalui grafik dan dasbor. Anda juga dapat mengonfigurasi CloudWatch alarm yang mengingatkan Anda saat penggunaan mendekati kuota layanan untuk kueri bersamaan, sehingga Anda dapat mengambil tindakan sebelum mencapai batas kuota. Untuk informasi selengkapnya, lihat [Pantau metrik penggunaan Athena dengan CloudWatch](monitoring-athena-usage-metrics.md). Untuk mengontrol konkurensi kueri dan mengisolasi beban kerja dalam akun Anda, gunakan reservasi kapasitas. Reservasi kapasitas menyediakan kapasitas pemrosesan kueri khusus dalam satu akun. Kapasitas diukur dalam Unit Pemrosesan Data (DPUs) dan dapat ditambahkan atau dihapus untuk menambah atau mengurangi konkurensi kueri, masing-masing. Reservasi kapasitas memungkinkan Anda untuk mengisolasi beban kerja dalam akun Anda dari satu sama lain dengan menetapkan kapasitas ke satu atau beberapa kelompok kerja. Untuk informasi selengkapnya, lihat [Kelola kapasitas pemrosesan kueri](capacity-management.md). Meskipun Anda harus mengisolasi beban kerja yang tidak terkait di AWS akun yang berbeda (seperti mengisolasi pengembangan dari lingkungan produksi), pendekatan ini tidak menyediakan cara yang dapat diskalakan untuk meningkatkan konkurensi kueri. Sebagai gantinya, gunakan reservasi kapasitas untuk mengelola dan menskalakan kebutuhan pemrosesan kueri Anda dalam satu akun. ### Pertimbangkan 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](federated-queries.md), 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 bagian tuning kinerja ini. Untuk informasi selengkapnya tentang mengatasi kesalahan yang disebabkan oleh kuota layanan Amazon S3, lihat [Hindari memiliki terlalu banyak file](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html).* ## Mengurangi kesalahan 'kehabisan 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 [Optimalkan bergabung](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins)[Kurangi ruang lingkup fungsi jendela, atau hapus](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions), dan[Optimalkan kueri dengan menggunakan perkiraan](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations). # Optimalkan 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. ## Optimalkan 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. ### Dalam gabungan hash terdistribusi, tempatkan tabel besar di sebelah kiri, tabel kecil di sebelah kanan 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. Ketika tabel pencarian yang dibuat dari sisi build gabungan 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. ### Gunakan EXPLOW untuk menganalisis kueri dengan gabungan kompleks Kueri dengan kondisi gabungan yang kompleks (misalnya, kueri yang menggunakan`LIKE`,`>`, 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 EXPLAIN dan EXPLAIN ANALYZE di Athena](athena-explain-statement.md) dan [Pahami Athena JELASKAN hasil pernyataan](athena-explain-statement-understanding.md). ## Kurangi ruang lingkup fungsi jendela, atau hapus 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 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` dan`LIMIT`. [https://trino.io/docs/current/functions/aggregate.html#min_by](https://trino.io/docs/current/functions/aggregate.html#min_by) 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` fungsinya. `max_by`Fungsi 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. ## Optimalkan 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 kesalahan seperti berikut: EXPRESSION\$1NOT\$1AGGREGATE: 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](https://trino.io/docs/current/functions/aggregate.html#arbitrary), seperti pada contoh berikut. ``` SELECT country_id, arbitrary(country_name) AS country_name, COUNT(*) AS city_count FROM world_cities GROUP BY country_id ``` `ARBITRARY`Fungsi 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. ## Optimalkan kueri N teratas `ORDER BY`Klausa 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` bersama`LIMIT`, 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 top`N`, kami merekomendasikan versi yang lebih sederhana yang menggunakan `ORDER BY` dan. `LIMIT` Untuk informasi selengkapnya, lihat [Kurangi ruang lingkup fungsi jendela, atau hapus](#performance-tuning-optimizing-window-functions). ## 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\$1INTERNAL\$1ERROR: io.airlift.bytecode. CompilationException Untuk mengatasi masalah ini, kurangi jumlah kolom dalam kueri, atau buat subkueri dan gunakan yang mengambil data dalam jumlah `JOIN` yang lebih kecil. Jika Anda memiliki kueri yang dilakukan `SELECT *` di kueri terluar, Anda harus mengubah `*` ke daftar hanya kolom yang Anda butuhkan. ## Optimalkan kueri dengan menggunakan perkiraan Athena memiliki dukungan untuk [fungsi agregat aproksimasi](https://trino.io/docs/current/functions/aggregate.html#appro) 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\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) menggunakan lebih sedikit memori dan berjalan lebih cepat. Demikian pula, menggunakan [numeric\$1histogram alih-alih [histogram](https://trino.io/docs/current/functions/aggregate.html#histogram)](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) menggunakan metode perkiraan dan karenanya lebih sedikit memori. ## Optimalkan LIKE Anda dapat menggunakan `LIKE` untuk menemukan string yang cocok, tetapi dengan string panjang, ini adalah komputasi intensif. Fungsi [regexp\$1like](https://trino.io/docs/current/functions/regexp.html#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 menggunakan`regexp_like`, '^ *substr* '. ## Gunakan UNION ALL alih-alih UNION `UNION ALL`dan `UNION` dua cara untuk menggabungkan hasil dari dua query menjadi satu hasil. `UNION ALL`menggabungkan catatan dari kueri pertama dengan yang kedua, dan `UNION` melakukan hal yang sama, tetapi juga menghapus duplikat. `UNION`perlu 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 dari`UNLOAD`, 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](unload.md). ## 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 dengan[Buat tabel dari hasil kueri (CTAS)](ctas.md), atau alat ETL khusus seperti [Glue ETL](https://aws.amazon.com/glue). 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 [Gunakan kembali hasil kueri di Athena](reusing-query-results.md) sini di *Panduan Pengguna Amazon Athena* dan [Kurangi biaya serta tingkatkan kinerja kueri dengan Penggunaan Kembali Hasil Kueri Amazon Athena](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/) di AWS Blog Big Data.* # Optimalkan 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 Anda](partitions.md) ## 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 stempel waktu 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](#performance-tuning-use-columnar-file-formats). 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](#performance-tuning-query-partitions-by-equality). ## 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 jarang 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](#performance-tuning-query-partitions-by-equality). 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](partition-projection-dynamic-id-partitioning.md#partition-projection-injection) sebagai gantinya. Untuk informasi selengkapnya tentang proyek partisi, lihat [Gunakan proyeksi partisi dengan Amazon Athena](partition-projection.md). ## 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](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Panduan AWS Glue Pengembang* dan [Meningkatkan kinerja kueri Amazon Athena AWS Glue Data Catalog menggunakan indeks partisi](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/) 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)), 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](#performance-tuning-query-partitions-by-equality) ## 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](#performance-tuning-use-partition-projection). ## 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](msck-repair-table.md#msck-repair-table-considerations) Partisi lebih baik dikelola secara manual menggunakan [AWS Glue Data Catalog APIs](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html),[ALTER TABLE ADD PARTITION](alter-table-add-partition.md), atau [AWS Glue crawler](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html). Sebagai alternatif, Anda dapat menggunakan proyeksi partisi, yang menghilangkan kebutuhan untuk mengelola partisi sama sekali. Untuk informasi selengkapnya, lihat [Gunakan proyeksi partisi dengan Amazon Athena](partition-projection.md). ## Validasi bahwa kueri Anda kompatibel dengan skema partisi Anda dapat memeriksa terlebih dahulu partisi mana yang akan dipindai kueri dengan menggunakan [`EXPLAIN`](athena-explain-statement.md)pernyataan 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 dengan`EXPLAIN`. 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]] ``` `EXPLAIN`Output 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 lebih lanjut tentang penggunaan`EXPLAIN`, lihat [Menggunakan EXPLAIN dan EXPLAIN ANALYZE di Athena](athena-explain-statement.md) dan[Pahami Athena JELASKAN hasil pernyataan](athena-explain-statement-understanding.md). ## 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 dalam[Hindari memiliki terlalu banyak file](#performance-tuning-avoid-having-too-many-files), 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 selengkapnya, lihat [Konversi ke format kolumnar](columnar-storage.md#convert-to-columnar). ## 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](https://www.gnu.org/software/gzip/) memberikan rasio kompresi yang baik dan memiliki berbagai dukungan di seluruh alat dan layanan lainnya. Format [zstd](https://facebook.github.io/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 dibahas dalam[Hindari memiliki terlalu banyak file](#performance-tuning-avoid-having-too-many-files), 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. [Gunakan kompresi di Athena](compression-formats.md) ## 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. ### Hindari bucketing saat kueri sering mencari beberapa nilai dalam kolom 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 [Gunakan partisi dan bucketing](ctas-partitioning-and-bucketing.md). ## 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: + Ubah proses yang menulis file untuk menulis file yang lebih besar. Misalnya, Anda dapat menyangga catatan untuk waktu yang lebih lama sebelum ditulis. + Letakkan file di lokasi di Amazon S3 dan gunakan alat seperti Glue ETL untuk menggabungkannya menjadi file yang lebih besar. Kemudian, pindahkan file yang lebih besar ke lokasi yang ditunjukkan tabel. Untuk informasi selengkapnya, lihat [Membaca file input dalam grup yang lebih besar](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) di *Panduan AWS Glue Pengembang* dan [Bagaimana cara mengonfigurasi pekerjaan AWS Glue ETL untuk menampilkan file yang lebih besar?](https://repost.aws/knowledge-center/glue-job-output-large-files) di Pusat *Pengetahuan AWS RE: Post*. + Kurangi jumlah tombol partisi. Ketika Anda memiliki terlalu banyak kunci partisi, setiap partisi mungkin hanya memiliki beberapa catatan, menghasilkan jumlah file kecil yang berlebihan. Untuk informasi tentang memutuskan partisi mana yang akan dibuat, lihat[Pilih kunci partisi yang akan mendukung kueri Anda](#performance-tuning-pick-partition-keys-that-will-support-your-queries). ## 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](#performance-tuning-avoid-having-too-many-files). ## Gunakan SymlinkTextInputFormat hanya jika diperlukan Menggunakan [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat)teknik 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. # Gunakan format penyimpanan kolumnar [Apache Parquet](https://parquet.apache.org) dan [ORC](https://orc.apache.org/) adalah format penyimpanan kolumnar yang dioptimalkan untuk pengambilan data dengan cepat dan digunakan dalam aplikasi analitis. AWS Format penyimpanan kolom memiliki karakteristik berikut yang membuatnya cocok untuk digunakan dengan Athena: + *Kompresi menurut kolom, dengan algoritma kompresi dipilih untuk tipe data kolom* untuk menghemat ruang penyimpanan di Amazon S3 dan mengurangi ruang disk dan I/O selama pemrosesan kueri. + *Predikat pushdown* di Parquet dan ORC memungkinkan kueri Athena untuk mengambil hanya blok yang dibutuhkan, meningkatkan performa kueri. Saat kueri Athena memperoleh nilai kolom tertentu dari data Anda, kueri Athena menggunakan statistik dari predikat blok data, seperti max/min nilai, untuk menentukan apakah akan membaca atau melewati blok. + *Memisahkan data* di Parquet dan ORC memungkinkan Athena membagi pembacaan data ke beberapa pembaca dan meningkatkan paralelisme selama pemrosesan kueri. Untuk mengonversi data mentah yang ada dari format penyimpanan lain ke Parket atau ORC, Anda dapat menjalankan kueri [CREATE TABLE AS SELECT (CTAS)](ctas.md) di Athena dan menentukan format penyimpanan data sebagai Parket atau ORC, atau menggunakan Crawler. AWS Glue ## Pilih antara Parket dan ORC Pilihan antara ORC (Optimized Row Columnar) dan Parquet tergantung pada kebutuhan penggunaan spesifik Anda. Apache Parquet menyediakan skema kompresi dan pengkodean data yang efisien dan sangat ideal untuk menjalankan kueri kompleks dan memproses data dalam jumlah besar. Parket dioptimalkan untuk digunakan dengan [Apache Arrow](https://arrow.apache.org/), yang dapat menguntungkan jika Anda menggunakan alat yang terkait dengan Arrow. ORC menyediakan cara yang efisien untuk menyimpan data Hive. File ORC seringkali lebih kecil dari file Parket, dan indeks ORC dapat membuat kueri lebih cepat. Selain itu, ORC mendukung tipe kompleks seperti struct, peta, dan daftar. Saat memilih antara Parket dan ORC, pertimbangkan hal berikut: **Kinerja kueri** — Karena Parket mendukung berbagai jenis kueri yang lebih luas, Parket mungkin menjadi pilihan yang lebih baik jika Anda berencana untuk melakukan kueri yang kompleks. **Tipe data yang kompleks** — Jika Anda menggunakan tipe data yang kompleks, ORC mungkin menjadi pilihan yang lebih baik karena mendukung berbagai tipe data kompleks yang lebih luas. **Ukuran file** — Jika ruang disk menjadi perhatian, ORC biasanya menghasilkan file yang lebih kecil, yang dapat mengurangi biaya penyimpanan. **Kompresi** - Parket dan ORC memberikan kompresi yang baik, tetapi format terbaik untuk Anda dapat bergantung pada kasus penggunaan spesifik Anda. **Evolusi** — Parket dan ORC mendukung evolusi skema, yang berarti Anda dapat menambah, menghapus, atau memodifikasi kolom dari waktu ke waktu. Baik Parket dan ORC adalah pilihan yang baik untuk aplikasi data besar, tetapi pertimbangkan persyaratan skenario Anda sebelum memilih. Anda mungkin ingin melakukan tolok ukur pada data dan kueri untuk melihat format mana yang berkinerja lebih baik untuk kasus penggunaan Anda. ## Konversi ke format kolumnar Opsi untuk dengan mudah mengonversi data sumber seperti JSON atau CSV ke dalam format kolom termasuk menggunakan kueri [CREATE TABLE AS](ctas.md) atau menjalankan pekerjaan di. AWS Glue + Anda dapat menggunakan kueri `CREATE TABLE AS` (CTAS) untuk mengonversi data menjadi Parket atau ORC dalam satu langkah. Sebagai contoh, lihat [Contoh: Menulis hasil kueri ke format yang berbeda](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format) pada [Contoh kueri CTAS](ctas-examples.md) halaman. + Untuk informasi tentang menggunakan Athena untuk ETL untuk mengubah data dari CSV ke Parket, lihat. [Gunakan CTAS dan INSERT INTO untuk ETL dan analisis data](ctas-insert-into-etl.md) + Untuk informasi tentang menjalankan AWS Glue pekerjaan untuk mengubah data CSV menjadi Parket, lihat bagian “Ubah data dari format CSV ke Parket” di posting blog AWS Big Data [Membangun fondasi danau data dengan dan Amazon AWS Glue](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/) S3. AWS Glue mendukung menggunakan teknik yang sama untuk mengonversi data CSV ke ORC, atau data JSON ke Parquet atau ORC. # Gunakan partisi dan bucketing Partisi dan bucketing adalah dua cara untuk mengurangi jumlah data Athena harus memindai ketika Anda menjalankan kueri. Partisi dan bucketing saling melengkapi dan dapat digunakan bersama. Mengurangi jumlah data yang dipindai mengarah pada peningkatan kinerja dan biaya yang lebih rendah. Untuk panduan umum tentang performa kueri Athena, lihat [10 kiat penyetelan performa terbaik untuk Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). **Topics** + [Apa itu partisi?](ctas-partitioning-and-bucketing-what-is-partitioning.md) + [Apa itu bucketing?](ctas-partitioning-and-bucketing-what-is-bucketing.md) + [Sumber daya tambahan](ctas-partitioning-and-bucketing-additional-resources.md) # Apa itu partisi? Partisi berarti mengatur data ke dalam direktori (atau “awalan”) di Amazon S3 berdasarkan properti data tertentu. Properti seperti itu disebut kunci partisi. Kunci partisi umum adalah tanggal atau satuan waktu lainnya seperti tahun atau bulan. Namun, dataset dapat dipartisi oleh lebih dari satu kunci. Misalnya, data tentang penjualan produk dapat dipartisi berdasarkan tanggal, kategori produk, dan pasar. ## Memutuskan cara partisi Kandidat yang baik untuk kunci partisi adalah properti yang selalu atau sering digunakan dalam kueri dan memiliki kardinalitas rendah. Ada trade-off antara memiliki terlalu banyak partisi dan memiliki terlalu sedikit. Dengan terlalu banyak partisi, peningkatan jumlah file menciptakan overhead. Ada juga beberapa overhead dari penyaringan partisi itu sendiri. Dengan terlalu sedikit partisi, kueri seringkali harus memindai lebih banyak data. ## Buat tabel yang dipartisi Saat kumpulan data dipartisi, Anda dapat membuat tabel yang dipartisi di Athena. Tabel yang dipartisi adalah tabel yang memiliki kunci partisi. Saat Anda menggunakan`CREATE TABLE`, Anda menambahkan partisi ke tabel. Saat Anda menggunakan`CREATE TABLE AS`, partisi yang dibuat di Amazon S3 secara otomatis ditambahkan ke tabel. Dalam sebuah `CREATE TABLE` pernyataan, Anda menentukan kunci partisi dalam `PARTITIONED BY (column_name data_type)` klausa. Dalam sebuah `CREATE TABLE AS` pernyataan, Anda menentukan kunci partisi dalam `WITH (partitioned_by = ARRAY['partition_key'])` klausa, atau `WITH (partitioning = ARRAY['partition_key'])` untuk tabel Iceberg. Untuk alasan kinerja, kunci partisi harus selalu bertipe`STRING`. Untuk informasi selengkapnya, lihat [Gunakan string sebagai tipe data untuk kunci partisi](data-types-timestamps.md#data-types-timestamps-partition-key-types). Untuk detail tambahan `CREATE TABLE` dan `CREATE TABLE AS` sintaks, lihat [CREATE TABLE](create-table.md) dan[Properti tabel CTAS](create-table-as.md#ctas-table-properties). ## Tabel yang dipartisi kueri Saat Anda menanyakan tabel yang dipartisi, Athena menggunakan predikat dalam kueri untuk memfilter daftar partisi. Kemudian menggunakan lokasi partisi yang cocok untuk memproses file yang ditemukan. Athena dapat secara efisien mengurangi jumlah data yang dipindai hanya dengan tidak membaca data di partisi yang tidak cocok dengan predikat kueri. ### Contoh Misalkan Anda memiliki tabel yang dipartisi oleh `sales_date` `product_category` dan dan ingin mengetahui total pendapatan selama seminggu dalam kategori tertentu. Anda menyertakan `sales_date` predikat pada `product_category` kolom dan untuk memastikan bahwa Athena hanya memindai jumlah minimum data, seperti pada contoh berikut. ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND product_category = 'Toys' ``` Misalkan Anda memiliki kumpulan data yang dipartisi berdasarkan tanggal tetapi juga memiliki stempel waktu berbutir halus. Dengan tabel Iceberg, Anda dapat mendeklarasikan kunci partisi untuk memiliki hubungan dengan kolom, tetapi dengan tabel Hive mesin kueri tidak memiliki pengetahuan tentang hubungan antara kolom dan kunci partisi. Untuk alasan ini, Anda harus menyertakan predikat pada kolom dan kunci partisi dalam kueri Anda untuk memastikan kueri tidak memindai lebih banyak data daripada yang diperlukan. Misalnya, `sales` tabel pada contoh sebelumnya juga memiliki `sold_at` kolom tipe `TIMESTAMP` data. Jika Anda menginginkan pendapatan hanya untuk rentang waktu tertentu, Anda akan menulis kueri seperti ini: ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date = '2023-02-28' AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' AND product_category = 'Toys' ``` Untuk informasi selengkapnya tentang perbedaan antara menanyakan tabel Hive dan Iceberg, lihat. [Cara menulis kueri untuk bidang stempel waktu yang juga dipartisi waktu](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned) # Apa itu bucketing? Bucketing adalah cara untuk mengatur catatan dataset ke dalam kategori yang disebut bucket. Arti bucket dan bucketing ini berbeda dari, dan jangan bingung dengan, ember Amazon S3. Dalam bucketing data, catatan yang memiliki nilai yang sama untuk properti masuk ke bucket yang sama. Catatan didistribusikan secara merata di antara ember sehingga setiap bucket memiliki jumlah data yang kira-kira sama. Dalam praktiknya, bucket adalah file, dan fungsi hash menentukan bucket yang masuk ke dalam rekaman. Dataset yang diselimuti akan memiliki satu atau lebih file per bucket per partisi. Bucket yang dimiliki file dikodekan dalam nama file. ## Manfaat Bucketing Bucketing berguna ketika kumpulan data diselimuti oleh properti tertentu dan Anda ingin mengambil catatan di mana properti tersebut memiliki nilai tertentu. Karena datanya diselimuti, Athena dapat menggunakan nilainya untuk menentukan file mana yang akan dilihat. Misalnya, dataset diselimuti oleh `customer_id` dan Anda ingin menemukan semua catatan untuk pelanggan tertentu. Athena menentukan ember yang berisi catatan itu dan hanya membaca file di ember itu. Kandidat yang baik untuk bucketing terjadi ketika Anda memiliki kolom yang memiliki kardinalitas tinggi (yaitu, memiliki banyak nilai berbeda), terdistribusi secara seragam, dan Anda sering meminta nilai tertentu. **catatan** Athena tidak mendukung penggunaan `INSERT INTO` untuk menambahkan catatan baru ke tabel berember. ## Tipe data yang didukung untuk pemfilteran pada kolom berember Anda dapat menambahkan filter pada kolom berember dengan tipe data tertentu. Athena mendukung penyaringan pada kolom berember dengan tipe data berikut: + BOOLEAN + BYTE + DATE + DOUBLE + FLOAT + INT + LONG + SHORT + STRING + VARCHAR ## Dukungan Hive dan Spark Mesin Athena versi 2 mendukung kumpulan data yang diselimuti menggunakan algoritma bucket Hive, dan mesin Athena versi 3 juga mendukung algoritma bucketing Apache Spark. Bucketing sarang adalah default. Jika kumpulan data Anda diselimuti menggunakan algoritma Spark, gunakan `TBLPROPERTIES` klausa untuk menyetel nilai properti. `bucketing_format` `spark` **catatan** Athena memiliki batas 100 partisi dalam kueri `CREATE TABLE AS SELECT` ([CTAS](ctas.md)). Demikian pula, Anda hanya dapat menambahkan maksimum 100 partisi ke tabel tujuan dengan [INSERT INTO](insert-into.md) pernyataan. Jika Anda melebihi batasan ini, Anda mungkin menerima pesan kesalahan HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Melebihi batas 100 penulis terbuka untuk partisi/ember. Untuk mengatasi batasan ini, Anda dapat menggunakan pernyataan CTAS dan serangkaian `INSERT INTO` pernyataan yang membuat atau menyisipkan hingga 100 partisi masing-masing. Untuk informasi selengkapnya, lihat [Gunakan CTAS dan INSERT INTO untuk bekerja di sekitar batas partisi 100](ctas-insert-into.md). ## Bucketing CREATE TABLE contoh Untuk membuat tabel untuk dataset bucketed yang ada, gunakan klausa yang diikuti oleh `CLUSTERED BY (column)` klausa. `INTO N BUCKETS` `INTO N BUCKETS`Klausa menentukan jumlah ember yang dimasukkan ke dalam data. Dalam `CREATE TABLE` contoh berikut, `sales` kumpulan data dimasukkan `customer_id` ke dalam 8 ember menggunakan algoritma Spark. `CREATE TABLE`Pernyataan menggunakan `TBLPROPERTIES` klausa `CLUSTERED BY` and untuk mengatur properti yang sesuai. ``` CREATE EXTERNAL TABLE sales (...) ... CLUSTERED BY (`customer_id`) INTO 8 BUCKETS ... TBLPROPERTIES ( 'bucketing_format' = 'spark' ) ``` ## Bucketing CREATE TABLE AS (CTAS) contoh Untuk menentukan ember dengan`CREATE TABLE AS`, gunakan `bucket_count` parameter `bucketed_by` dan, seperti pada contoh berikut. ``` CREATE TABLE sales WITH ( ... bucketed_by = ARRAY['customer_id'], bucket_count = 8 ) AS SELECT ... ``` ## Contoh kueri bucketing Contoh kueri berikut mencari nama-nama produk yang telah dibeli pelanggan tertentu selama seminggu. ``` SELECT DISTINCT product_name FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND customer_id = 'c123' ``` Jika tabel ini dipartisi oleh `sales_date` dan dikantongi oleh`customer_id`, Athena dapat menghitung ember tempat catatan pelanggan berada. Paling-paling, Athena membaca satu file per partisi. # Sumber daya tambahan + Untuk `CREATE TABLE AS` contoh yang membuat tabel berember dan dipartisi, lihat [Contoh: Membuat](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed) tabel berember dan dipartisi. + [Untuk informasi tentang penerapan bucketing pada AWS data lake, termasuk menggunakan pernyataan Athena CTAS, AWS Glue untuk Apache Spark, dan bucketing untuk tabel Apache Iceberg, lihat posting AWS Blog Big Data Optimalkan tata letak data dengan menggunakan Amazon Athena dan untuk mempercepat kueri hilir. AWS Glue](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/) # Partisi data Anda Dengan mempartisi data, Anda dapat membatasi jumlah data yang dipindai oleh setiap kueri, sehingga meningkatkan performa dan mengurangi biaya. Anda dapat mempartisi data Anda dengan kunci apa pun. Sebuah praktik umum adalah untuk partisi data berdasarkan waktu, sering mengarah ke skema partisi multi-level. Misalnya, pelanggan yang memiliki data datang setiap jam mungkin memutuskan untuk mempartisi menurut tahun, bulan, tanggal, dan jam. Pelanggan lain, yang memiliki data yang berasal dari berbagai sumber tetapi yang dimuat hanya sekali per hari, mungkin dipartisi oleh pengenal sumber data dan tanggal. Athena dapat menggunakan partisi gaya Apache Hive, yang jalur datanya berisi pasangan nilai kunci yang dihubungkan dengan tanda yang sama (misalnya, atau). `country=us/...` `year=2021/month=01/day=26/...` Dengan demikian, jalur mencakup nama kunci partisi dan nilai yang diwakili oleh setiap jalur. Untuk memuat partisi Hive baru ke dalam tabel yang dipartisi, Anda dapat menggunakan [MSCK REPAIR TABLE](msck-repair-table.md) perintah, yang hanya berfungsi dengan partisi gaya Hive. Athena juga dapat menggunakan skema partisi gaya non-sarang. Misalnya, CloudTrail log dan aliran pengiriman Firehose menggunakan komponen jalur terpisah untuk bagian tanggal seperti. `data/2021/01/26/us/6fc7845e.json` Untuk partisi gaya non-sarang seperti itu, Anda gunakan [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) untuk menambahkan partisi secara manual. ## Pertimbangan dan batasan Saat menggunakan partisi, ingatlah hal-hal berikut: + Jika Anda mengkueri tabel dipartisi dan menentukan partisi di `WHERE`, Athena memindai data hanya dari partisi itu. + Jika Anda mengeluarkan kueri terhadap bucket Amazon S3 dengan begitu banyak objek dan data yang tidak dipartisi, kueri tersebut dapat memengaruhi batas tingkat permintaan `GET` di Amazon S3 dan menyebabkan pengecualian Amazon S3. Untuk mencegah kesalahan, partisi data Anda. Selain itu, pertimbangkan untuk menyetel tingkat permintaan Amazon S3 Anda. Untuk informasi selengkapnya, lihat [Pola desain praktik terbaik: Mengoptimalkan kinerja Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html). + Lokasi partisi yang akan digunakan dengan Athena harus menggunakan protokol `s3` (misalnya, `s3://amzn-s3-demo-bucket/folder/`). Di Athena, lokasi yang menggunakan protokol lain (contohnya,`s3a://amzn-s3-demo-bucket/folder/`) akan mengakibatkan kegagalan permintaan ketika`MSCK REPAIR TABLE`query dijalankan pada tabel yang mengandung. + Pastikan bahwa jalur Amazon S3 dalam huruf kecil bukan camel case (misalnya, `userid` sebagai gantinya `userId`). Jika jalur S3 dalam kasus unta,`MSCK REPAIR TABLE`tidak menambahkan partisi ke AWS Glue Data Catalog. Untuk informasi selengkapnya, lihat [MSCK REPAIR TABLE](msck-repair-table.md). + Karena `MSCK REPAIR TABLE` memindai folder dan subfoldernya untuk menemukan skema partisi yang cocok, pastikan untuk menyimpan data untuk tabel terpisah dalam hierarki folder terpisah. Misalnya, Anda memiliki data untuk tabel 1 in `s3://amzn-s3-demo-bucket1` dan data untuk tabel 2 in`s3://amzn-s3-demo-bucket1/table-2-data`. Jika kedua tabel dipartisi oleh string, `MSCK REPAIR TABLE` akan menambahkan partisi untuk tabel 2 ke tabel 1. Untuk menghindari hal ini, gunakan struktur folder terpisah seperti `s3://amzn-s3-demo-bucket1` dan `s3://amzn-s3-demo-bucket2` sebagai gantinya. Perhatikan bahwa perilaku ini konsisten dengan Amazon EMR dan Apache Hive. + Jika Anda menggunakan AWS Glue Data Catalog with Athena, lihat [AWS Glue titik akhir dan kuota untuk kuota](https://docs.aws.amazon.com/general/latest/gr/glue.html) layanan pada partisi per akun dan per tabel. + Meskipun Athena mendukung AWS Glue tabel kueri yang memiliki 10 juta partisi, Athena tidak dapat membaca lebih dari 1 juta partisi dalam satu pemindaian. Dalam skenario seperti itu, pengindeksan partisi dapat bermanfaat. Untuk informasi selengkapnya, lihat artikel AWS Big Data Blog [Meningkatkan kinerja kueri Amazon Athena menggunakan indeks AWS Glue Data Catalog partisi](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/). + Untuk meminta peningkatan kuota partisi jika Anda menggunakan AWS Glue Data Catalog, kunjungi konsol [Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas) untuk. AWS Glue ## Membuat dan memuat tabel dengan data yang dipartisi Untuk membuat tabel yang menggunakan partisi, gunakan `PARTITIONED BY` klausa dalam pernyataan Anda[CREATE TABLE](create-table.md). `PARTITIONED BY`Klausa mendefinisikan kunci untuk mempartisi data, seperti pada contoh berikut. `LOCATION`Klausa menentukan lokasi root dari data yang dipartisi. ``` CREATE EXTERNAL TABLE users ( first string, last string, username string ) PARTITIONED BY (id string) STORED AS parquet LOCATION 's3://amzn-s3-demo-bucket' ``` Setelah Anda membuat tabel, Anda memuat data di partisi untuk kueri. Untuk partisi gaya Hive, Anda lari. [MSCK REPAIR TABLE](msck-repair-table.md) Untuk partisi gaya non-sarang, Anda gunakan [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) untuk menambahkan partisi secara manual. ## Siapkan gaya Hive dan data gaya non-Hive untuk kueri Bagian berikut menunjukkan bagaimana mempersiapkan gaya Hive dan data gaya non-Hive untuk query di Athena. ### Skenario 1: Data disimpan di Amazon S3 dalam format Hive Dalam skenario ini, partisi disimpan dalam folder terpisah di Amazon S3. Misalnya, berikut adalah daftar sebagian untuk contoh tayangan iklan yang dihasilkan oleh [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html)perintah, yang mencantumkan objek S3 di bawah awalan yang ditentukan: ``` aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/ PRE dt=2009-04-12-13-00/ PRE dt=2009-04-12-13-05/ PRE dt=2009-04-12-13-10/ PRE dt=2009-04-12-13-15/ PRE dt=2009-04-12-13-20/ PRE dt=2009-04-12-14-00/ PRE dt=2009-04-12-14-05/ PRE dt=2009-04-12-14-10/ PRE dt=2009-04-12-14-15/ PRE dt=2009-04-12-14-20/ PRE dt=2009-04-12-15-00/ PRE dt=2009-04-12-15-05/ ``` Di sini, log disimpan dengan nama kolom (dt) ditetapkan sama dengan tanggal, jam, dan kenaikan menit. Saat Anda memberikan DDL dengan lokasi folder induk, skema, dan nama kolom dipartisi, Athena dapat mengkueri data dalam subfolder tersebut. #### Buat tabel Untuk membuat tabel dari data ini, buat partisi bersama 'dt' seperti pada pernyataan Athena DDL berikut: ``` CREATE EXTERNAL TABLE impressions ( requestBeginTime string, adId string, impressionId string, referrer string, userAgent string, userCookie string, ip string, number string, processId string, browserCookie string, requestEndTime string, timers struct, threadId string, hostname string, sessionId string) PARTITIONED BY (dt string) ROW FORMAT serde 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ; ``` Tabel ini menggunakan Hive asli JSON serializer-deserializer untuk membaca data JSON yang disimpan di Amazon S3. Untuk informasi selengkapnya tentang format yang didukung, lihat [Pilih SerDe untuk data Anda](supported-serdes.md). #### Jalankan MSCK REPAIR TABLE Setelah Anda menjalankan `CREATE TABLE` kueri, jalankan `MSCK REPAIR TABLE` perintah di editor kueri Athena untuk memuat partisi, seperti pada contoh berikut. ``` MSCK REPAIR TABLE impressions ``` Setelah Anda menjalankan perintah ini, data siap untuk query. #### Kueri datanya Kueri data dari tabel tayangan menggunakan kolom partisi. Inilah contohnya: ``` SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100 ``` Kueri ini harus menunjukkan hasil yang mirip dengan berikut ini: ``` 2009-04-12-13-20 ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc 2009-04-12-13-20 17uchtodoS9kdeQP1x0XThKl5IuRsV 2009-04-12-13-20 JOUf1SCtRwviGw8sVcghqE5h0nkgtp 2009-04-12-13-20 NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH 2009-04-12-13-20 fFAItiBMsgqro9kRdIwbeX60SROaxr 2009-04-12-13-20 V4og4R9W6G3QjHHwF7gI1cSqig5D1G 2009-04-12-13-20 hPEPtBwk45msmwWTxPVVo1kVu4v11b 2009-04-12-13-20 v0SkfxegheD90gp31UCr6FplnKpx6i 2009-04-12-13-20 1iD9odVgOIi4QWkwHMcOhmwTkWDKfj 2009-04-12-13-20 b31tJiIA25CK8eDHQrHnbcknfSndUk ``` ### Skenario 2: Data tidak dipartisi dalam format Hive Dalam contoh berikut, `aws s3 ls` perintah menunjukkan log [ELB](elasticloadbalancer-classic-logs.md) yang disimpan di Amazon S3. Perhatikan bagaimana tata letak data tidak menggunakan `key=value` pasangan dan oleh karena itu tidak dalam format Hive. (`--recursive`Opsi untuk `aws s3 ls` perintah menentukan bahwa semua file atau objek di bawah direktori atau awalan yang ditentukan dicantumkan.) ``` aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive 2016-11-23 17:54:46 11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 0 elb/plaintext/2015/01/01_$folder$ 2016-11-23 17:54:47 9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 0 elb/plaintext/2015/01/02_$folder$ 2016-11-23 17:54:48 11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 0 elb/plaintext/2015/01/03_$folder$ 2016-11-23 17:54:50 8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/04_$folder$ 2016-11-23 17:54:51 7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/05_$folder$ 2016-11-23 17:54:51 11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 0 elb/plaintext/2015/01/06_$folder$ 2016-11-23 17:54:52 8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 0 elb/plaintext/2015/01/07_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015/01_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015_$folder$ ``` #### Jalankan ALTER TABLE ADD PARTITION Karena data tidak dalam format Hive, Anda tidak dapat menggunakan `MSCK REPAIR TABLE` perintah untuk menambahkan partisi ke tabel setelah Anda membuatnya. Sebagai gantinya, Anda dapat menggunakan [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) perintah untuk menambahkan setiap partisi secara manual. Misalnya, untuk memuat data di s3://athena-examples - *myregion* /elb/plaintext/2015/01/01/, Anda dapat menjalankan kueri berikut. Perhatikan bahwa kolom partisi terpisah untuk setiap folder Amazon S3 tidak diperlukan, dan bahwa nilai kunci partisi dapat berbeda dari kunci Amazon S3. ``` ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/' ``` Jika partisi sudah ada, Anda menerima kesalahan Partisi sudah ada. Untuk menghindari kesalahan ini, Anda dapat menggunakan klausa `IF NOT EXISTS`. Untuk informasi selengkapnya, lihat [ALTER TABLE ADD PARTITION](alter-table-add-partition.md). Untuk menghapus partisi, Anda dapat menggunakan[ALTER TABLE DROP PARTITION](alter-table-drop-partition.md). ## Pertimbangkan proyeksi partisi Untuk menghindari keharusan mengelola partisi sendiri, Anda dapat menggunakan proyeksi partisi. Proyeksi partisi adalah opsi untuk tabel yang sangat dipartisi yang strukturnya diketahui sebelumnya. Dalam proyeksi partisi, nilai partisi dan lokasi dihitung dari properti tabel yang Anda konfigurasikan daripada dibaca dari repositori metadata. Karena perhitungan dalam memori lebih cepat daripada pencarian jarak jauh, penggunaan proyeksi partisi dapat secara signifikan mengurangi runtime kueri. Untuk informasi selengkapnya, lihat [Gunakan proyeksi partisi dengan Amazon Athena](partition-projection.md). ## Sumber daya tambahan + Untuk informasi tentang opsi partisi untuk data Firehose, lihat. [Contoh Amazon Data Firehose](partition-projection-kinesis-firehose-example.md) + Anda dapat mengotomatiskan penambahan partisi dengan menggunakan [driver JDBC](connect-with-jdbc.md). + Anda dapat menggunakan CTAS dan INSERT INTO untuk partisi set data. Lihat informasi yang lebih lengkap di [Gunakan CTAS dan INSERT INTO untuk ETL dan analisis data](ctas-insert-into-etl.md). # Gunakan proyeksi partisi dengan Amazon Athena Anda dapat menggunakan proyeksi partisi di Athena untuk mempercepat pemrosesan kueri tabel yang sangat dipartisi dan mengotomatiskan manajemen partisi. Dalam proyeksi partisi, Athena menghitung nilai partisi dan lokasi menggunakan properti tabel yang Anda konfigurasikan langsung pada tabel Anda. AWS Glue Properti tabel memungkinkan Athena untuk 'memproyeksikan', atau menentukan, informasi partisi yang diperlukan alih-alih harus melakukan pencarian metadata yang lebih memakan waktu di. AWS Glue Data Catalog Karena operasi dalam memori sering lebih cepat daripada operasi jarak jauh, proyeksi partisi dapat mengurangi runtime kueri terhadap tabel yang sangat dipartisi. Tergantung pada karakteristik spesifik dari kueri dan data yang mendasari, partisi proyeksi dapat secara signifikan mengurangi permintaan runtime untuk mengkueri yang dibatasi pada partisi metadata pengambilan. ## Memahami pemangkasan partisi vs. proyeksi partisi Pemangkasan partisi mengumpulkan metadata dan “plum” untuk hanya partisi yang berlaku untuk permintaan Anda. Ini sering mempercepat kueri. Athena menggunakan pemangkasan partisi untuk semua tabel dengan kolom partisi, termasuk tabel yang dikonfigurasi untuk proyeksi partisi. Biasanya, saat memproses kueri, Athena menelepon sebelum melakukan pemangkasan AWS Glue Data Catalog partisi. `GetPartitions` Jika tabel memiliki sejumlah besar partisi, menggunakan`GetPartitions`dapat mempengaruhi performa negatif. Untuk menghindarinya, Anda bisa menggunakan proyeksi partisi. Proyeksi partisi memungkinkan Athena untuk menghindari panggilan`GetPartitions`karena konfigurasi proyeksi partisi memberikan Athena semua informasi yang diperlukan untuk membangun partisi itu sendiri. ## Cara menggunakan proyeksi partisi Untuk menggunakan proyeksi partisi, Anda menentukan rentang nilai partisi dan jenis proyeksi untuk setiap kolom partisi dalam properti tabel di AWS Glue Data Catalog atau di metastore [Hive eksternal](connect-to-data-source-hive.md) Anda. Properti kustom ini di atas tabel memungkinkan Athena untuk mengetahui pola partisi apa yang diharapkan saat menjalankan kueri di atas tabel. Selama eksekusi kueri, Athena menggunakan informasi ini untuk memproyeksikan nilai partisi alih-alih mengambilnya dari metastore Hive AWS Glue Data Catalog atau eksternal. Ini tidak hanya mengurangi waktu eksekusi kueri tetapi juga mengotomatiskan manajemen partisi karena menghilangkan kebutuhan untuk secara manual membuat partisi di Athena, AWS Glue, atau metastore Hive eksternal Anda. **penting** Mengaktifkan proyeksi partisi pada tabel menyebabkan Athena mengabaikan metadata partisi apa pun yang terdaftar ke tabel di metastore or Hive. AWS Glue Data Catalog ## Beberapa kasus penggunaan Skenario tempat proyeksi partisi berguna meliputi: + Kueri terhadap tabel yang sangat dipartisi tidak lengkap secepat yang Anda inginkan. + Anda secara teratur menambahkan partisi ke tabel sebagai partisi tanggal atau waktu baru dibuat dalam data Anda. Dengan proyeksi partisi, Anda mengonfigurasi rentang tanggal relatif yang dapat digunakan sebagai data baru tiba. + Anda memiliki data yang sangat dipartisi di Amazon S3. Data tidak praktis untuk dimodelkan di metastore Anda AWS Glue Data Catalog atau Hive, dan kueri Anda hanya membaca sebagian kecil saja. ### Struktur partisi yang dapat diproyeksikan Proyeksi partisi paling mudah dikonfigurasi saat partisi Anda mengikuti pola yang dapat diprediksi seperti, tetapi tidak terbatas pada, berikut: + **Bilangan bulat**— Setiap urutan kontinu bilangan bulat seperti`[1, 2, 3, 4, ..., 1000]`atau`[0500, 0550, 0600, ..., 2500]`. + **Tanggal**— Setiap urutan kontinu tanggal atau datetime seperti`[20200101, 20200102, ..., 20201231]`atau`[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`. + **Nilai yang disebutkan - Satu set terbatas dari nilai** yang disebutkan seperti kode bandara atau. Wilayah AWS + **Layanan AWS log** — Layanan AWS log biasanya memiliki struktur yang diketahui yang skema partisinya dapat Anda tentukan AWS Glue dan karena itu Athena dapat digunakan untuk proyeksi partisi. ### Cara menyesuaikan template jalur partisi Secara default, Athena membangun lokasi partisi menggunakan formulir`s3://amzn-s3-demo-bucket//partition-col-1=/partition-col-2=/`, tetapi jika data Anda diatur secara berbeda, Athena menawarkan mekanisme untuk menyesuaikan templat jalur ini. Untuk langkah, lihat [Cara menentukan lokasi penyimpanan S3 kustom](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations). ## Pertimbangan dan batasan Pertimbangan berikut berlaku untuk instans Mac: + Proyeksi partisi menghilangkan kebutuhan untuk menentukan partisi secara manual di AWS Glue atau metastore Hive eksternal. + Saat Anda mengaktifkan proyeksi partisi di atas meja, Athena mengabaikan metadata partisi apa pun di metastore Hive atau eksternal AWS Glue Data Catalog untuk tabel itu. + Jika partisi yang diproyeksikan tidak ada di Amazon S3, Athena masih akan memproyeksikan partisi. Athena tidak membuang kesalahan, tapi tidak ada data dikembalikan. Namun, jika terlalu banyak partisi Anda kosong, kinerja bisa lebih lambat dibandingkan dengan AWS Glue partisi tradisional. Jika lebih dari separuh partisi yang diproyeksikan kosong, sebaiknya gunakan partisi tradisional. + Kueri untuk nilai-nilai yang berada di luar batas rentang yang ditetapkan untuk proyeksi partisi tidak mengembalikan kesalahan. Sebaliknya, kueri berjalan, tetapi kembali nol baris. Misalnya, jika Anda memiliki data terkait waktu yang dimulai pada tahun 2020 dan didefinisikan sebagai`'projection.timestamp.range'='2020/01/01,NOW'`, kueri seperti`SELECT * FROM table-name WHERE timestamp = '2019/02/02'`akan selesai dengan sukses, tapi kembali nol baris. + Proyeksi partisi hanya dapat digunakan jika tabel dipertanyakan melalui Athena. Jika tabel yang sama dibaca melalui layanan lain seperti Amazon Redshift Spectrum, Athena for Spark, atau Amazon EMR, metadata partisi standar digunakan. + Karena proyeksi partisi adalah fitur DML-only, `SHOW PARTITIONS` tidak mencantumkan partisi yang diproyeksikan oleh Athena tetapi tidak terdaftar dalam katalog atau metastore Hive eksternal. AWS Glue + Athena tidak menggunakan properti tabel tampilan sebagai konfigurasi untuk proyeksi partisi. Untuk mengatasi keterbatasan ini, mengonfigurasi dan mengaktifkan partisi proyeksi dalam tabel properti untuk tabel yang tampilan referensi. ## Video Video berikut menunjukkan bagaimana menggunakan proyeksi partisi untuk meningkatkan performa kueri Anda di Athena. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk) **Topics** + [Memahami pemangkasan partisi vs. proyeksi partisi](#partition-projection-pruning-vs-projection) + [Cara menggunakan proyeksi partisi](#partition-projection-using) + [Beberapa kasus penggunaan](#partition-projection-use-cases) + [Pertimbangan dan batasan](#partition-projection-considerations-and-limitations) + [Video](#partition-projection-video) + [Mengatur proyeksi partisi](partition-projection-setting-up.md) + [Jenis yang didukung untuk proyeksi partisi](partition-projection-supported-types.md) + [Gunakan partisi ID dinamis](partition-projection-dynamic-id-partitioning.md) + [Contoh Amazon Data Firehose](partition-projection-kinesis-firehose-example.md) # Mengatur proyeksi partisi Menyiapkan proyeksi partisi di properti tabel adalah proses dua langkah: 1. Tentukan rentang data dan pola yang relevan untuk setiap kolom partisi, atau gunakan templat kustom. 1. Aktifkan proyeksi partisi untuk tabel. **catatan** Sebelum Anda menambahkan properti proyeksi partisi ke tabel yang ada, kolom partisi yang Anda siapkan properti proyeksi partisi harus sudah ada dalam skema tabel. Jika kolom partisi belum ada, Anda harus menambahkan kolom partisi ke tabel yang ada secara manual. AWS Glue tidak melakukan langkah ini untuk Anda secara otomatis. Bagian ini menunjukkan cara mengatur properti tabel untuk AWS Glue. Untuk mengaturnya, Anda dapat menggunakan AWS Glue konsol, [CREATE TABLE](create-table.md) kueri Athena, atau operasi. [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html) Prosedur berikut menunjukkan cara mengatur properti di AWS Glue konsol. **Untuk mengkonfigurasi dan mengaktifkan proyeksi partisi menggunakan konsol AWS Glue** 1. Masuk ke Konsol Manajemen AWS dan buka AWS Glue konsol di [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Pilih tab **Tabel**. Pada tab **Tabel**, Anda dapat mengedit tabel yang ada, atau memilih **Tambahkan tabel** untuk membuat yang baru. Untuk informasi tentang menambahkan tabel secara manual atau dengan crawler, lihat [Bekerja dengan tabel di AWS Glue konsol di](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) *Panduan AWS Glue Pengembang*. 1. Dalam daftar tabel, pilih tautan untuk tabel yang ingin Anda edit. ![\[Di AWS Glue konsol, pilih tabel untuk diedit.\]](http://docs.aws.amazon.com/id_id/athena/latest/ug/images/partition-projection-1.png) 1. Pilih **Tindakan**, **Edit tabel**. 1. Pada halaman **Edit tabel**, di bagian **properti Tabel**, untuk setiap kolom yang dipartisi, tambahkan pasangan kunci-nilai berikut: 1. Untuk **Kunci**, tambahkan`projection.columnName.type`. 1. Untuk **Nilai**, tambahkan salah satu tipe yang didukung: `enum`, `integer`, `date`, atau `injected`. Untuk informasi selengkapnya, lihat [Jenis yang didukung untuk proyeksi partisi](partition-projection-supported-types.md). 1. Mengikuti petunjuk di [Jenis yang didukung untuk proyeksi partisi](partition-projection-supported-types.md) , tambahkan pasangan kunci-nilai tambahan sesuai dengan kebutuhan konfigurasi Anda. Contoh konfigurasi tabel berikut mengkonfigurasi `year` kolom untuk proyeksi partisi, membatasi nilai-nilai yang dapat dikembalikan ke rentang dari 2010 hingga 2016. ![\[Mengonfigurasi proyeksi partisi untuk kolom partisi di poperti tabel konsol AWS Glue .\]](http://docs.aws.amazon.com/id_id/athena/latest/ug/images/partition-projection-3.png) 1. Tambahkan pasangan nilai kunci untuk mengaktifkan proyeksi partisi. Untuk **Kunci**, masukkan `projection.enabled`, dan untuk **Nilai**, masukkan `true`. **catatan** Anda dapat menonaktifkan proyeksi partisi pada tabel ini kapan saja dengan menetapkan `projection.enabled` ke `false`. 1. Setelah selesai, pilih **Simpan**. 1. Di Editor Kueri Athena, uji kueri kolom yang Anda konfigurasikan untuk tabel. Contoh kueri berikut menggunakan`SELECT DISTINCT`untuk mengembalikan nilai-nilai unik dari`year`kolom. Basis data berisi data dari 1987 hingga 2016, tetapi `projection.year.range` properti membatasi nilai yang dikembalikan ke tahun 2010 hingga 2016. ![\[Kueri kolom yang menggunakan proyeksi partisi.\]](http://docs.aws.amazon.com/id_id/athena/latest/ug/images/partition-projection-5.png) **catatan** Jika Anda mengatur`projection.enabled`ke`true`tetapi gagal untuk mengonfigurasi satu atau lebih partisi kolom, Anda menerima pesan kesalahan seperti berikut: `HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`. ## Cara menentukan lokasi penyimpanan S3 kustom Saat mengedit properti tabel AWS Glue, Anda juga dapat menentukan templat jalur Amazon S3 khusus untuk partisi yang diproyeksikan. Template kustom memungkinkan Athena untuk benar memetakan nilai partisi ke lokasi file Amazon S3 kustom yang tidak mengikuti`.../column=value/...`Pola. Menggunakan templat kustom adalah opsional. Namun, jika Anda menggunakan templat kustom, templat harus berisi placeholder untuk setiap kolom partisi. Lokasi template harus diakhiri dengan garis miring ke depan sehingga file data yang dipartisi hidup dalam “folder” per partisi. **Untuk menentukan templat lokasi partisi kustom** 1. Mengikuti langkah-langkah untuk [mengkonfigurasi dan mengaktifkan proyeksi partisi menggunakan AWS Glue konsol](#partition-projection-setting-up-procedure), tambahkan tambahan pasangan kunci-nilai yang menentukan template kustom sebagai berikut: 1. Untuk **Kunci**, masukkan `storage.location.template`. 1. Untuk**Nilai**, tentukan lokasi yang mencakup placeholder untuk setiap kolom partisi. Pastikan bahwa setiap placeholder (dan jalur S3 itu sendiri) diakhiri dengan satu garis miring ke depan. Nilai templat contoh berikut mengasumsikan tabel dengan kolom partisi`a`,`b`, dan`c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/ ``` ``` s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/ ``` Untuk tabel yang sama, nilai templat contoh berikut tidak valid karena mengandung tidak ada tempat untuk kolom`c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/ ``` 1. Pilih **Terapkan**. # Jenis yang didukung untuk proyeksi partisi Sebuah tabel dapat memiliki kombinasi`enum`,`integer`,`date,`atau`injected`jenis kolom partisi. ## Jenis enum Gunakan `enum` tipe untuk kolom partisi yang nilainya adalah anggota dari kumpulan yang disebutkan (misalnya, kode bandara atau). Wilayah AWS Tentukan properti partisi dalam tabel sebagai berikut: **** | Nama properti | Contoh nilai | Deskripsi | | --- | --- | --- | | projection.columnName.type | `enum` | Wajib. Jenis proyeksi yang digunakan untuk kolomcolumnName. Nilai harusenum(case sensitive) untuk memberi sinyal penggunaan tipe enum. Memimpin dan mengikuti ruang putih diperbolehkan. | | projection.columnName.values | `A,B,C,D,E,F,G,Unknown` | Wajib. Daftar dipisahkan koma dari nilai partisi yang disebutkan untuk kolom. columnName Setiap ruang putih dianggap sebagai bagian dari nilai enum. | **catatan** Sebagai praktik terbaik kami sarankan untuk membatasi penggunaan`enum`berdasarkan proyeksi partisi untuk beberapa lusin atau kurang. Meskipun tidak ada batasan spesifik untuk `enum` proyeksi, ukuran total metadata tabel Anda tidak dapat melebihi AWS Glue batas sekitar 1 MB saat gzip dikompresi. Perhatikan bahwa batas ini dibagi di bagian kunci dari tabel Anda seperti nama kolom, lokasi, format penyimpanan, dan lain-lain. Jika Anda menemukan diri Anda menggunakan lebih dari beberapa lusin unik IDs dalam `enum` proyeksi Anda, pertimbangkan pendekatan alternatif seperti memasukkan sejumlah kecil nilai unik di bidang pengganti. Dengan melakukan trading di luar kardinalitas, Anda dapat mengontrol jumlah nilai unik di`enum`Bidang. ## Jenis bilangan bulat Gunakan tipe integer untuk kolom partisi yang nilainya mungkin ditafsirkan sebagai bilangan bulat dalam kisaran yang ditentukan. Kolom bilangan bulat yang diproyeksikan saat ini terbatas pada kisaran Java yang ditandatangani panjang (-263ke 263-1 inklusif). **** | Nama properti | Contoh nilai | Deskripsi | | --- | --- | --- | | projection.columnName.type | `integer` | Wajib. Jenis proyeksi yang digunakan untuk kolomcolumnName. Nilai harus berupainteger(case sensitive) untuk sinyal penggunaan tipe integer. Memimpin dan mengikuti ruang putih diperbolehkan. | | projection.columnName.range | `0,10` `-1,8675309` `0001,9999` | Wajib. Daftar dipisahkan koma dua elemen yang memberikan nilai rentang minimum dan maksimum yang akan dikembalikan oleh kueri pada kolom. columnName Perhatikan bahwa nilai harus dipisahkan dengan koma, bukan tanda hubung. Nilai-nilai ini inklusif, bisa negatif, dan dapat memiliki nol terkemuka. Memimpin dan mengikuti ruang putih diperbolehkan. | | projection.columnName.interval | `1` `5` | Tidak wajib. Sebuah integer positif yang menentukan interval antara nilai-nilai partisi berturut-turut untuk kolom. columnName Contohnya,rangenilai “1,3" denganintervalNilai “1" menghasilkan nilai 1, 2, dan 3. SamarangeNilai denganintervalnilai “2" menghasilkan nilai-nilai 1 dan 3, melewatkan 2. Memimpin dan mengikuti ruang putih diperbolehkan. Default-nya adalah 1. | | projection.columnName.digits | `1` `5` | Tidak wajib. Sebuah integer positif yang menentukan jumlah digit untuk dimasukkan dalam representasi akhir nilai partisi untuk kolom. columnName Contohnya,rangenilai “1,3" yang memilikidigitsNilai “1" menghasilkan nilai 1, 2, dan 3. SamarangeNilai dengandigitsnilai “2" menghasilkan nilai-nilai 01, 02, dan 03. Memimpin dan mengikuti ruang putih diperbolehkan. Default adalah tidak ada jumlah statis digit dan tidak ada nol terkemuka. | ## Jenis tanggal Gunakan tipe tanggal untuk kolom partisi yang nilainya dapat diinterpretasikan sebagai tanggal (dengan waktu opsional) dalam rentang yang ditetapkan. **penting** Kolom tanggal yang Diproyeksikan dihasilkan dalam Waktu Universal Terkoordinasi (UTC) pada waktu eksekusi kueri. **** | Nama properti | Contoh nilai | Deskripsi | | --- | --- | --- | | projection.columnName.type | `date` | Wajib. Jenis proyeksi yang digunakan untuk kolomcolumnName. Nilai harus berupadate(case insensitive) untuk memberi sinyal penggunaan tipe tanggal. Memimpin dan mengikuti ruang putih diperbolehkan. | | projection.columnName.range | `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH` | Wajib. Daftar dua elemen yang dipisahkan koma yang memberikan `range` nilai minimum dan maksimum untuk kolom. *columnName* Nilai-nilai ini inklusif dan dapat menggunakan format yang kompatibel dengan Java`java.time.*`Jenis tanggal. Kedua nilai minimum dan maksimum harus menggunakan format yang sama. Format yang ditentukan dalam`.format`properti harus format yang digunakan untuk nilai-nilai ini. Kolom ini juga dapat berisi string tanggal relatif, diformat dalam pola ekspresi reguler ini: `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` Ruang putih diperbolehkan, tetapi dalam literal tanggal dianggap bagian dari string tanggal sendiri. | | projection.columnName.format | `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss` | Wajib. String format tanggal berdasarkan format tanggal Java [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html). Dapat didukungJava.time.\$1Jenis. | | projection.columnName.interval | `1` `5` | Sebuah integer positif yang menentukan interval antara nilai-nilai partisi berturut-turut untuk kolom. *columnName* Contohnya,`range`Nilai`2017-01,2018-12`dengan`interval`Nilai`1`dan sebuah`interval.unit`Nilai`MONTHS`menghasilkan nilai 2017-01, 2017-02, 2017-03, dan seterusnya. Sama`range`Nilai dengan`interval`Nilai`2`dan sebuah`interval.unit`Nilai`MONTHS`menghasilkan nilai 2017-01, 2017-03, 2017-05, dan seterusnya. Spasi di awal dan akhir kalimat tidak diperbolehkan. Saat tanggal yang diberikan berada pada presisi satu hari atau satu bulan,`interval` adalah opsional dan default untuk 1 hari atau 1 bulan, masing-masing. Sebaliknya, `interval` diperlukan. | | projection.columnName.interval.unit | `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS` | Kata satuan waktu yang mewakili bentuk serial dari a [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html). Kemungkinan nilai adalah `YEARS`, `MONTHS`, `WEEKS`, `DAYS`, `HOURS`, `MINUTES`, `SECONDS`, dan `MILLIS`. Nilai-nilai ini tidak peka huruf besar. Saat tanggal yang diberikan berada pada presisi satu hari atau satu bulan,`interval.unit` adalah opsional dan default untuk 1 hari atau 1 bulan, masing-masing. Sebaliknya, `interval.unit` diperlukan. | **Example — Partisi berdasarkan bulan** Berikut contoh tabel konfigurasi partisi data per bulan dari 2015 hingga saat ini. ``` 'projection.month.type'='date', 'projection.month.format'='yyyy-MM', 'projection.month.interval'='1', 'projection.month.interval.unit'='MONTHS', 'projection.month.range'='2015-01,NOW', ... ``` ## Jenis yang disuntikkan Gunakan jenis disuntikkan untuk partisi kolom dengan nilai-nilai yang mungkin tidak prosedural dihasilkan dalam beberapa kisaran logis tetapi yang disediakan dalam query`WHERE`klausul sebagai nilai tunggal. Penting untuk diingat hal-hal berikut: + Kueri pada kolom disuntikkan gagal jika ekspresi filter tidak disediakan untuk setiap kolom disuntikkan. + Kueri dengan beberapa nilai untuk ekspresi filter pada kolom yang disuntikkan hanya berhasil jika nilainya terpisah. + Hanya kolom`string`didukung. + Bila Anda menggunakan `WHERE IN` klausa dengan kolom partisi yang disuntikkan, ada batas 1.000 nilai yang dapat Anda tentukan dalam `IN` daftar. Untuk menanyakan kumpulan data dengan lebih dari 1.000 partisi untuk kolom yang disuntikkan, pisahkan kueri menjadi beberapa kueri yang lebih kecil, masing-masing dengan hingga 1.000 nilai dalam `WHERE IN` klausa, lalu agregat hasilnya. **** | Nama properti | Nilai | Deskripsi | | --- | --- | --- | | projection.columnName.type | `injected` | Wajib. Jenis proyeksi yang digunakan untuk kolomcolumnName. Hanyastringdidukung. Nilai yang ditentukan harusinjected(kasus tidak sensitif). Memimpin dan mengikuti ruang putih diperbolehkan. | Untuk informasi selengkapnya, lihat [Kapan menggunakan jenis `injected` proyeksi](partition-projection-dynamic-id-partitioning.md#partition-projection-injection). # Gunakan partisi ID dinamis Ketika data Anda dipartisi oleh properti dengan kardinalitas tinggi atau ketika nilai tidak dapat diketahui sebelumnya, Anda dapat menggunakan jenis proyeksi. `injected` Contoh properti tersebut adalah nama pengguna, dan IDs perangkat atau produk. Bila Anda menggunakan jenis `injected` proyeksi untuk mengkonfigurasi kunci partisi, Athena menggunakan nilai-nilai dari query itu sendiri untuk menghitung set partisi yang akan dibaca. Agar Athena dapat menjalankan kueri pada tabel yang memiliki kunci partisi yang dikonfigurasi dengan jenis `injected` proyeksi, berikut ini harus benar: + Kueri Anda harus menyertakan setidaknya satu nilai untuk kunci partisi. + Nilai harus literal atau ekspresi yang dapat dievaluasi tanpa membaca data apa pun. Jika salah satu kriteria ini tidak terpenuhi, kueri Anda gagal dengan kesalahan berikut: CONSTRAINT\$1VIOLATION: Untuk kolom partisi yang diproyeksikan yang disuntikkan*column\$1name*, klausa WHERE harus berisi hanya kondisi kesetaraan statis, dan setidaknya satu kondisi seperti itu harus ada. ## Kapan menggunakan jenis `injected` proyeksi Bayangkan Anda memiliki kumpulan data yang terdiri dari peristiwa dari perangkat IoT, yang dipartisi di perangkat '. IDs Kumpulan data ini memiliki karakteristik sebagai berikut: + Perangkat dihasilkan IDs secara acak. + Perangkat baru sering disediakan. + Saat ini ada ratusan ribu perangkat, dan di masa depan akan ada jutaan. Kumpulan data ini sulit dikelola menggunakan metastores tradisional. Sulit untuk menjaga partisi tetap sinkron antara penyimpanan data dan metastore, dan partisi penyaringan bisa lambat selama perencanaan kueri. Tetapi jika Anda mengonfigurasi tabel untuk menggunakan proyeksi partisi dan menggunakan jenis `injected` proyeksi, Anda memiliki dua keuntungan: Anda tidak perlu mengelola partisi di metastore, dan kueri Anda tidak harus mencari metadata partisi. `CREATE TABLE`Contoh berikut membuat tabel untuk set data peristiwa perangkat yang baru saja dijelaskan. Tabel menggunakan jenis proyeksi yang disuntikkan. ``` CREATE EXTERNAL TABLE device_events ( event_time TIMESTAMP, data STRING, battery_level INT ) PARTITIONED BY ( device_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.device_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}" ) ``` Contoh kueri berikut mencari jumlah peristiwa yang diterima dari tiga perangkat tertentu selama 12 jam. ``` SELECT device_id, COUNT(*) AS events FROM device_events WHERE device_id IN ( '4a770164-0392-4a41-8565-40ed8cec737e', 'f71d12cf-f01f-4877-875d-128c23cbde17', '763421d8-b005-47c3-ba32-cc747ab32f9a' ) AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00' GROUP BY device_id ``` Ketika Anda menjalankan query ini, Athena melihat tiga nilai untuk kunci `device_id` partisi dan menggunakannya untuk menghitung lokasi partisi. Athena menggunakan nilai `storage.location.template` properti untuk menghasilkan lokasi berikut: + `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e` + `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17` + `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a` Jika Anda meninggalkan `storage.location.template` properti dari konfigurasi proyeksi partisi, Athena menggunakan partisi gaya HIVE untuk memproyeksikan lokasi partisi berdasarkan nilai `LOCATION` dalam (misalnya,). `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e` # Contoh Amazon Data Firehose Saat Anda menggunakan Firehose untuk mengirimkan data ke Amazon S3, konfigurasi default akan menulis objek dengan kunci yang terlihat seperti contoh berikut: ``` s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension ``` Untuk membuat tabel Athena yang menemukan partisi secara otomatis pada waktu kueri, alih-alih harus menambahkannya ke AWS Glue Data Catalog saat data baru tiba, Anda dapat menggunakan proyeksi partisi. `CREATE TABLE`Contoh berikut menggunakan konfigurasi Firehose default. ``` CREATE EXTERNAL TABLE my_ingested_data ( ... ) ... PARTITIONED BY ( datehour STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.datehour.type" = "date", "projection.datehour.format" = "yyyy/MM/dd/HH", "projection.datehour.range" = "2021/01/01/00,NOW", "projection.datehour.interval" = "1", "projection.datehour.interval.unit" = "HOURS", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/" ) ``` `TBLPROPERTIES`Klausul dalam `CREATE TABLE` pernyataan tersebut memberi tahu Athena sebagai berikut: + Gunakan proyeksi partisi saat menanyakan tabel + Kunci partisi `datehour` adalah tipe `date` (yang mencakup waktu opsional) + Bagaimana tanggal diformat + Kisaran waktu tanggal. Perhatikan bahwa nilai harus dipisahkan dengan koma, bukan tanda hubung. + Di mana menemukan data di Amazon S3. Saat Anda menanyakan tabel, Athena menghitung nilai untuk `datehour` dan menggunakan templat lokasi penyimpanan untuk menghasilkan daftar lokasi partisi. **Topics** + [Cara menggunakan `date` tipenya](partition-projection-kinesis-firehose-example-using-the-date-type.md) + [Bagaimana memilih tombol partisi](partition-projection-kinesis-firehose-example-choosing-partition-keys.md) + [Cara menggunakan awalan khusus dan partisi dinamis](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md) # Cara menggunakan `date` tipenya Bila Anda menggunakan `date` tipe untuk kunci partisi yang diproyeksikan, Anda harus menentukan rentang. Karena Anda tidak memiliki data untuk tanggal sebelum aliran pengiriman Firehose dibuat, Anda dapat menggunakan tanggal pembuatan sebagai awal. Dan karena Anda tidak memiliki data untuk tanggal di masa depan, Anda dapat menggunakan token khusus `NOW` sebagai akhir. Dalam `CREATE TABLE` contoh, tanggal mulai ditentukan sebagai 1 Januari 2021 pada tengah malam UTC. **catatan** Konfigurasikan rentang yang cocok dengan data Anda sedekat mungkin sehingga Athena hanya mencari partisi yang ada. Ketika kueri dijalankan pada tabel sampel, Athena menggunakan kondisi pada tombol `datehour` partisi dalam kombinasi dengan rentang untuk menghasilkan nilai. Pertimbangkan kueri berikut: ``` SELECT * FROM my_ingested_data WHERE datehour >= '2020/12/15/00' AND datehour < '2021/02/03/15' ``` Kondisi pertama dalam `SELECT` kueri menggunakan tanggal yang sebelum dimulainya rentang tanggal yang ditentukan oleh `CREATE TABLE` pernyataan. Karena konfigurasi proyeksi partisi tidak menetapkan partisi untuk tanggal sebelum 1 Januari 2021, Athena mencari data hanya di lokasi berikut, dan mengabaikan tanggal sebelumnya dalam kueri. ``` s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/ ... s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/ ``` Demikian pula, jika kueri berjalan pada tanggal dan waktu sebelum 3 Februari 2021 pukul 15:00, partisi terakhir akan mencerminkan tanggal dan waktu saat ini, bukan tanggal dan waktu dalam kondisi kueri. Jika Anda ingin menanyakan data terbaru, Anda dapat memanfaatkan fakta bahwa Athena tidak menghasilkan tanggal masa depan dan hanya menentukan awal`datehour`, seperti pada contoh berikut. ``` SELECT * FROM my_ingested_data WHERE datehour >= '2021/11/09/00' ``` # Bagaimana memilih tombol partisi Anda dapat menentukan bagaimana proyeksi partisi memetakan lokasi partisi ke kunci partisi. Dalam `CREATE TABLE` contoh di bagian sebelumnya, tanggal dan jam digabungkan menjadi satu kunci partisi yang disebut datehour, tetapi skema lain dimungkinkan. Misalnya, Anda juga dapat mengonfigurasi tabel dengan kunci partisi terpisah untuk tahun, bulan, hari, dan jam. Namun, membagi tanggal menjadi tahun, bulan, dan hari berarti bahwa jenis proyeksi `date` partisi tidak dapat digunakan. Alternatifnya adalah memisahkan tanggal dari jam untuk tetap memanfaatkan jenis proyeksi `date` partisi, tetapi membuat kueri yang menentukan rentang jam lebih mudah dibaca. Dengan mengingat hal itu, `CREATE TABLE` contoh berikut memisahkan tanggal dari jam. Karena `date` adalah kata cadangan dalam SQL, contoh menggunakan `day` sebagai nama untuk kunci partisi yang mewakili tanggal. ``` CREATE EXTERNAL TABLE my_ingested_data2 ( ... ) ... PARTITIONED BY ( day STRING, hour INT ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy/MM/dd", "projection.day.range" = "2021/01/01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.hour.type" = "integer", "projection.hour.range" = "0,23", "projection.hour.digits" = "2", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/" ) ``` Dalam `CREATE TABLE` pernyataan contoh, jam adalah kunci partisi terpisah, dikonfigurasi sebagai bilangan bulat. Konfigurasi untuk kunci partisi jam menentukan rentang 0 hingga 23, dan jam harus diformat dengan dua digit saat Athena menghasilkan lokasi partisi. Kueri untuk `my_ingested_data2` tabel mungkin terlihat seperti ini: ``` SELECT * FROM my_ingested_data2 WHERE day = '2021/11/09' AND hour > 3 ``` ## Memahami kunci partisi dan tipe data proyeksi partisi Perhatikan bahwa `datehour` kunci dalam `CREATE TABLE` contoh pertama dikonfigurasi seperti `date` pada konfigurasi proyeksi partisi, tetapi jenis kunci partisi adalah`string`. Hal yang sama `day` berlaku untuk contoh kedua. Jenis dalam konfigurasi proyeksi partisi hanya memberi tahu Athena cara memformat nilai saat menghasilkan lokasi partisi. Jenis yang Anda tentukan tidak mengubah jenis kunci partisi — dalam kueri, `datehour` dan `day` bertipe`string`. Ketika kueri menyertakan kondisi seperti`day = '2021/11/09'`, Athena mem-parsing string di sisi kanan ekspresi menggunakan format tanggal yang ditentukan dalam konfigurasi proyeksi partisi. Setelah Athena memverifikasi bahwa tanggal berada dalam rentang yang dikonfigurasi, ia menggunakan format tanggal lagi untuk memasukkan tanggal sebagai string ke dalam template lokasi penyimpanan. Demikian pula, untuk kondisi kueri seperti`day > '2021/11/09'`, Athena mem-parsing sisi kanan dan menghasilkan daftar semua tanggal yang cocok dalam rentang yang dikonfigurasi. Kemudian menggunakan format tanggal untuk memasukkan setiap tanggal ke dalam template lokasi penyimpanan untuk membuat daftar lokasi partisi. Menulis kondisi yang sama dengan `day > '2021-11-09'` atau `day > DATE '2021-11-09'` tidak berfungsi. Dalam kasus pertama, format tanggal tidak cocok (perhatikan tanda hubung alih-alih garis miring ke depan), dan dalam kasus kedua, tipe data tidak cocok. # Cara menggunakan awalan khusus dan partisi dinamis [Firehose dapat dikonfigurasi dengan [awalan khusus dan partisi dinamis.](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html) Dengan menggunakan fitur-fitur ini, Anda dapat mengonfigurasi kunci Amazon S3 dan menyiapkan skema partisi yang mendukung kasus penggunaan Anda dengan lebih baik. Anda juga dapat menggunakan proyeksi partisi dengan skema partisi ini dan mengkonfigurasinya sesuai dengan itu. Misalnya, Anda dapat menggunakan fitur awalan khusus untuk mendapatkan kunci Amazon S3 yang memiliki tanggal berformat ISO, bukan skema default. `yyyy/MM/dd/HH` Anda juga dapat menggabungkan awalan kustom dengan partisi dinamis untuk mengekstrak properti seperti dari pesan `customer_id` Firehose, seperti pada contoh berikut. ``` prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/ ``` Dengan awalan Amazon S3 itu, aliran pengiriman Firehose akan menulis objek ke kunci seperti. `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension` Untuk properti seperti`customer_id`, di mana nilainya mungkin tidak diketahui sebelumnya, Anda dapat menggunakan jenis proyeksi partisi `injected` dan menggunakan `CREATE TABLE` pernyataan seperti berikut: ``` CREATE EXTERNAL TABLE my_ingested_data3 ( ... ) ... PARTITIONED BY ( day STRING, customer_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy-MM-dd", "projection.day.range" = "2021-01-01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.customer_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/" ) ``` Saat Anda menanyakan tabel yang memiliki jenis kunci partisi`injected`, kueri Anda harus menyertakan nilai untuk kunci partisi tersebut. Kueri untuk `my_ingested_data3` tabel mungkin terlihat seperti ini: ``` SELECT * FROM my_ingested_data3 WHERE day BETWEEN '2021-11-01' AND '2021-11-30' AND customer_id = 'customer-1234' ``` ## Gunakan tipe DATE untuk kunci partisi hari Karena nilai untuk kunci `day` partisi diformat ISO, Anda juga dapat menggunakan `DATE` tipe untuk kunci partisi hari alih-alih`STRING`, seperti pada contoh berikut: ``` PARTITIONED BY (day DATE, customer_id STRING) ``` Saat Anda melakukan kueri, strategi ini memungkinkan Anda untuk menggunakan fungsi tanggal pada kunci partisi tanpa parsing atau casting, seperti pada contoh berikut: ``` SELECT * FROM my_ingested_data3 WHERE day > CURRENT_DATE - INTERVAL '7' DAY AND customer_id = 'customer-1234' ``` **catatan** Menentukan kunci partisi dari `DATE` jenis mengasumsikan bahwa Anda telah menggunakan fitur [awalan khusus](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) untuk membuat kunci Amazon S3 yang memiliki tanggal berformat ISO. Jika Anda menggunakan format Firehose default`yyyy/MM/dd/HH`, Anda harus menentukan kunci partisi sebagai tipe `string` meskipun properti tabel yang sesuai adalah tipe`date`, seperti pada contoh berikut: ``` PARTITIONED BY ( `mydate` string) TBLPROPERTIES ( 'projection.enabled'='true', ... 'projection.mydate.type'='date', 'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}') ``` # Cegah pelambatan Amazon S3 Throttling adalah proses membatasi tingkat di mana Anda menggunakan layanan, aplikasi, atau sistem. Di AWS, Anda dapat menggunakan pelambatan untuk mencegah penggunaan layanan Amazon S3 yang berlebihan dan meningkatkan ketersediaan dan daya tanggap Amazon S3 untuk semua pengguna. Namun, karena pembatasan membatasi kecepatan transfer data ke atau dari Amazon S3, penting untuk mempertimbangkan untuk mencegah interaksi Anda terhambat. Seperti yang ditunjukkan dalam bagian [tuning kinerja, pengoptimalan](performance-tuning.md) dapat bergantung pada keputusan tingkat layanan Anda, bagaimana Anda menyusun tabel dan data, dan bagaimana Anda menulis kueri. **Topics** + [Kurangi pelambatan di tingkat layanan](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [Optimalkan tabel Anda](performance-tuning-s3-throttling-optimizing-your-tables.md) + [Optimalkan kueri Anda](performance-tuning-s3-throttling-optimizing-queries.md) # Kurangi pelambatan di tingkat layanan Untuk menghindari pelambatan Amazon S3 pada tingkat layanan, Anda dapat memantau penggunaan dan menyesuaikan [kuota layanan Anda, atau Anda menggunakan teknik tertentu seperti](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) partisi. Berikut ini adalah beberapa kondisi yang dapat menyebabkan throttling: + **Melebihi batas permintaan API akun Anda** - Amazon S3 memiliki batas permintaan API default yang didasarkan pada jenis dan penggunaan akun. Jika Anda melebihi jumlah maksimum permintaan per detik untuk satu awalan, permintaan Anda mungkin dibatasi untuk mencegah kelebihan layanan Amazon S3. + **Partisi data tidak memadai - Jika Anda tidak mempartisi** data dengan benar dan mentransfer sejumlah besar data, Amazon S3 dapat membatasi permintaan Anda. Untuk informasi selengkapnya tentang partisi, lihat [Gunakan partisi](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) bagian dalam dokumen ini. + **Sejumlah besar benda kecil** — Jika memungkinkan, hindari memiliki sejumlah besar file kecil. Amazon S3 memiliki batas [5500 permintaan GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) per detik per awalan yang dipartisi, dan kueri Athena Anda memiliki batas yang sama. Jika Anda memindai jutaan objek kecil dalam satu kueri, kueri Anda kemungkinan akan dibatasi oleh Amazon S3. Untuk menghindari pemindaian berlebih, Anda dapat menggunakan AWS Glue ETL untuk memadatkan file Anda secara berkala, atau Anda mempartisi tabel dan menambahkan filter kunci partisi. Untuk informasi selengkapnya, lihat sumber daya berikut ini. + [Bagaimana saya bisa mengonfigurasi pekerjaan AWS Glue ETL untuk mengeluarkan file yang lebih besar?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*Pusat AWS Pengetahuan*) + [Membaca file input dalam kelompok yang lebih besar](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Panduan AWS Glue Pengembang*) # Optimalkan tabel Anda Penataan data Anda penting jika Anda mengalami masalah pelambatan. Meskipun Amazon S3 dapat menangani data dalam jumlah besar, pembatasan terkadang terjadi karena cara data terstruktur. Bagian berikut menawarkan beberapa saran tentang cara menyusun data Anda di Amazon S3 untuk menghindari masalah pembatasan. ## Gunakan partisi Anda dapat menggunakan partisi untuk mengurangi pembatasan dengan membatasi jumlah data yang harus diakses pada waktu tertentu. Dengan mempartisi data pada kolom tertentu, Anda dapat mendistribusikan permintaan secara merata di beberapa objek dan mengurangi jumlah permintaan untuk satu objek. Mengurangi jumlah data yang harus dipindai meningkatkan kinerja kueri dan menurunkan biaya. Anda dapat menentukan partisi, yang bertindak sebagai kolom virtual, saat Anda membuat tabel. Untuk membuat tabel dengan partisi dalam `CREATE TABLE` pernyataan, Anda menggunakan `PARTITIONED BY (column_name data_type)` klausa untuk menentukan kunci untuk mempartisi data Anda. Untuk membatasi partisi yang dipindai oleh kueri, Anda dapat menentukannya sebagai predikat dalam `WHERE` klausa kueri. Dengan demikian, kolom yang sering digunakan sebagai filter adalah kandidat yang baik untuk partisi. Praktik umum adalah mempartisi data berdasarkan interval waktu, yang dapat menyebabkan skema partisi multi-level. Perhatikan bahwa partisi juga memiliki biaya. Ketika Anda meningkatkan jumlah partisi dalam tabel Anda, waktu yang diperlukan untuk mengambil dan memproses metadata partisi juga meningkat. Dengan demikian, partisi berlebihan dapat menghilangkan manfaat yang Anda peroleh dengan mempartisi dengan lebih bijaksana. Jika data Anda sangat miring ke satu nilai partisi, dan sebagian besar kueri menggunakan nilai itu, maka Anda mungkin dikenakan biaya tambahan. Untuk informasi lebih lanjut tentang partisi di Athena, lihat [Apa itu partisi?](ctas-partitioning-and-bucketing-what-is-partitioning.md) ## Bucket data Anda Cara lain untuk mempartisi data Anda adalah dengan memasukkan data dalam satu partisi. Dengan bucketing, Anda menentukan satu atau beberapa kolom yang berisi baris yang ingin Anda kelompokkan bersama. Kemudian, Anda menempatkan baris itu ke dalam beberapa ember. Dengan cara ini, Anda hanya menanyakan bucket yang harus dibaca, yang mengurangi jumlah baris data yang harus dipindai. Saat Anda memilih kolom yang akan digunakan untuk bucketing, pilih kolom yang memiliki kardinalitas tinggi (yaitu, yang memiliki banyak nilai berbeda), didistribusikan secara seragam, dan sering digunakan untuk memfilter data. Contoh kolom yang baik untuk digunakan untuk bucketing adalah kunci utama, seperti kolom ID. Untuk informasi lebih lanjut tentang bucketing di Athena, lihat [Apa itu bucketing?](ctas-partitioning-and-bucketing-what-is-bucketing.md) ## Gunakan indeks AWS Glue partisi Anda dapat menggunakan indeks AWS Glue partisi untuk mengatur data dalam tabel berdasarkan nilai satu atau lebih partisi. AWS Glue Indeks partisi dapat mengurangi jumlah transfer data, jumlah pemrosesan data, dan waktu untuk query untuk memproses. Indeks AWS Glue partisi adalah file metadata yang berisi informasi tentang partisi dalam tabel, termasuk kunci partisi dan nilainya. Indeks partisi disimpan dalam bucket Amazon S3 dan diperbarui secara otomatis oleh AWS Glue saat partisi baru ditambahkan ke tabel. Ketika indeks AWS Glue partisi hadir, query mencoba untuk mengambil subset dari partisi alih-alih memuat semua partisi dalam tabel. Query hanya berjalan pada subset data yang relevan dengan query. Saat Anda membuat tabel di AWS Glue, Anda dapat membuat indeks partisi pada kombinasi tombol partisi yang ditentukan di atas tabel. Setelah Anda membuat satu atau lebih indeks partisi di atas meja, Anda harus menambahkan properti ke tabel yang memungkinkan pemfilteran partisi. Kemudian, Anda dapat menanyakan tabel dari Athena. Untuk informasi tentang membuat indeks partisi AWS Glue, lihat [Bekerja dengan indeks partisi AWS Glue di Panduan AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Pengembang*. Untuk informasi tentang menambahkan properti tabel untuk mengaktifkan pemfilteran partisi, lihat[Optimalkan kueri dengan pengindeksan dan AWS Glue pemfilteran partisi](glue-best-practices-partition-index.md). ## Gunakan kompresi data dan pemisahan file Kompresi data dapat mempercepat kueri secara signifikan jika file berada pada ukuran optimal atau jika mereka dapat dibagi menjadi kelompok-kelompok logis. Umumnya, rasio kompresi yang lebih tinggi membutuhkan lebih banyak siklus CPU untuk mengompres dan mendekompresi data. Untuk Athena, kami menyarankan Anda menggunakan Apache Parquet atau Apache ORC, yang mengompres data secara default. Untuk informasi tentang kompresi data di Athena, lihat. [Gunakan kompresi di Athena](compression-formats.md) Memisahkan file meningkatkan paralelisme dengan memungkinkan Athena untuk mendistribusikan tugas membaca satu file di antara banyak pembaca. Jika satu file tidak dapat dibagi, hanya satu pembaca yang dapat membaca file sementara pembaca lain menganggur. Apache Parquet dan Apache ORC juga mendukung file splittable. ## Gunakan penyimpanan data kolumnar yang dioptimalkan Kinerja kueri Athena meningkat secara signifikan jika Anda mengonversi data Anda menjadi format kolumnar. Saat Anda menghasilkan file kolumnar, salah satu teknik pengoptimalan yang perlu dipertimbangkan adalah memesan data berdasarkan kunci partisi. Apache Parquet dan Apache ORC biasanya digunakan penyimpanan data kolumnar open source. Untuk informasi tentang mengonversi sumber data Amazon S3 yang ada ke salah satu format ini, lihat. [Konversi ke format kolumnar](columnar-storage.md#convert-to-columnar) ### Gunakan ukuran blok Parket yang lebih besar atau ukuran garis ORC Parket dan ORC memiliki parameter penyimpanan data yang dapat Anda atur untuk pengoptimalan. Di Parket, Anda dapat mengoptimalkan ukuran blok. Di ORC, Anda dapat mengoptimalkan ukuran garis. Semakin besar blok atau garis, semakin banyak baris yang dapat Anda simpan di masing-masing. Secara default, ukuran blok Parket adalah 128 MB, dan ukuran garis ORC adalah 64 MB. Jika garis ORC kurang dari 8 MB (nilai default`hive.orc.max_buffer_size`), Athena membaca seluruh garis ORC. Ini adalah tradeoff yang dilakukan Athena antara selektivitas kolom dan operasi input/output per detik untuk garis-garis yang lebih kecil. Jika Anda memiliki tabel dengan jumlah kolom yang sangat besar, ukuran blok atau garis kecil dapat menyebabkan lebih banyak data dipindai daripada yang diperlukan. Dalam kasus ini, ukuran blok yang lebih besar bisa lebih efisien. ### Gunakan ORC untuk tipe kompleks Saat ini, ketika Anda menanyakan kolom yang disimpan di Parket yang memiliki tipe data kompleks (misalnya,`array`,`map`, atau`struct`), Athena membaca seluruh baris data alih-alih membaca secara selektif hanya kolom yang ditentukan. Ini adalah masalah yang diketahui di Athena. Sebagai solusinya, pertimbangkan untuk menggunakan ORC. ### Pilih algoritma kompresi Parameter lain yang dapat Anda konfigurasikan adalah algoritma kompresi pada blok data. [Untuk informasi tentang algoritma kompresi yang didukung untuk Parket dan ORC di Athena, lihat Dukungan kompresi Athena.](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html) Untuk informasi lebih lanjut tentang optimalisasi format penyimpanan kolumnar di Athena, lihat bagian “Optimalkan pembuatan penyimpanan data kolumnar” di posting Blog AWS Big Data [10 Tips Penyetelan Kinerja Teratas](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) untuk Amazon Athena. ## Gunakan tabel Iceberg Apache Iceberg adalah format tabel terbuka untuk kumpulan data analitik yang sangat besar yang dirancang untuk penggunaan yang dioptimalkan di Amazon S3. Anda dapat menggunakan tabel Iceberg untuk membantu mengurangi pelambatan di Amazon S3. Tabel gunung es menawarkan keuntungan berikut: + Anda dapat mempartisi tabel Iceberg pada satu atau lebih kolom. Ini mengoptimalkan akses data dan mengurangi jumlah data yang harus dipindai oleh kueri. + Karena mode penyimpanan objek Iceberg mengoptimalkan tabel Iceberg agar berfungsi dengan Amazon S3, mode ini dapat memproses volume data yang besar dan beban kerja kueri yang berat. + Tabel gunung es dalam mode penyimpanan objek dapat diskalakan, toleran terhadap kesalahan, dan tahan lama, yang dapat membantu mengurangi pelambatan. + Dukungan transaksi ACID berarti bahwa beberapa pengguna dapat menambahkan dan menghapus objek Amazon S3 secara atom. [Untuk informasi lebih lanjut tentang Apache Iceberg, lihat Apache Iceberg.](https://iceberg.apache.org/) [Untuk informasi selengkapnya tentang menggunakan tabel Apache Iceberg di Athena, lihat Menggunakan tabel Gunung Es.](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html) # Optimalkan kueri Anda Gunakan saran di bagian ini untuk mengoptimalkan kueri SQL Anda di Athena. ## Gunakan LIMIT dengan klausa ORDER BY `ORDER BY`Klausa mengembalikan data dalam urutan yang diurutkan. Ini membutuhkan Athena untuk mengirim semua baris data ke node pekerja tunggal dan kemudian mengurutkan baris. Jenis kueri ini dapat berjalan untuk waktu yang lama atau bahkan gagal. Untuk efisiensi yang lebih besar dalam kueri Anda, lihat *N* nilai atas atau bawah, lalu gunakan juga `LIMIT` klausa. Ini secara signifikan mengurangi biaya pengurutan dengan mendorong penyortiran dan pembatasan ke node pekerja individu daripada ke satu pekerja. ## Optimalkan klausa JOIN Ketika Anda menggabungkan dua tabel, Athena mendistribusikan tabel di sebelah kanan ke node pekerja, dan kemudian mengalirkan tabel di sebelah kiri untuk melakukan gabungan. Untuk alasan ini, tentukan tabel yang lebih besar di sisi kiri gabungan dan tabel yang lebih kecil di sisi kanan gabungan. Dengan cara ini, Athena menggunakan lebih sedikit memori dan menjalankan kueri dengan latensi yang lebih rendah. Perhatikan juga poin-poin berikut: + Saat Anda menggunakan beberapa `JOIN` perintah, tentukan tabel dari yang terbesar hingga terkecil. + Hindari gabungan silang kecuali jika diperlukan oleh kueri. ## Optimalkan klausa GROUP BY `GROUP BY`Operator mendistribusikan baris berdasarkan `GROUP BY` kolom ke node pekerja. Kolom ini direferensikan dalam memori dan nilainya dibandingkan saat baris dicerna. Nilai-nilai dikumpulkan bersama ketika `GROUP BY` kolom cocok. Dengan mempertimbangkan cara kerja proses ini, disarankan untuk memesan kolom dari kardinalitas tertinggi ke yang terendah. ## Gunakan angka, bukan string Karena angka membutuhkan lebih sedikit memori dan lebih cepat diproses dibandingkan dengan string, gunakan angka alih-alih string jika memungkinkan. ## Batasi jumlah kolom Untuk mengurangi jumlah total memori yang diperlukan untuk menyimpan data Anda, batasi jumlah kolom yang ditentukan dalam `SELECT` pernyataan Anda. ## Gunakan ekspresi reguler alih-alih LIKE Kueri yang menyertakan klausa seperti `LIKE '%string%'` pada string besar bisa sangat intensif secara komputasi. Saat Anda memfilter beberapa nilai pada kolom string, gunakan fungsi [regexp\$1like ()](https://trino.io/docs/current/functions/regexp.html#regexp_like) dan ekspresi reguler sebagai gantinya. Ini sangat berguna ketika Anda membandingkan daftar panjang nilai. ## Gunakan klausa LIMIT Alih-alih memilih semua kolom saat Anda menjalankan kueri, gunakan `LIMIT` klausa untuk mengembalikan hanya kolom yang Anda butuhkan. Ini mengurangi ukuran kumpulan data yang diproses melalui pipeline eksekusi kueri. `LIMIT`klausa lebih membantu ketika Anda menanyakan tabel yang memiliki sejumlah besar kolom yang berbasis string. `LIMIT`klausa juga membantu ketika Anda melakukan beberapa gabungan atau agregasi pada kueri apa pun. # Sumber daya tambahan Untuk informasi tambahan tentang penyetelan kinerja di Athena, pertimbangkan sumber daya berikut: + AWS Posting blog Big Data: [10 kiat penyetelan kinerja teratas untuk Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). + AWS *Posting blog Big Data: [Jalankan kueri 3x lebih cepat dengan penghematan biaya hingga 70% pada mesin Amazon Athena terbaru](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/) di AWS Blog Big Data.* + AWS Posting blog Big Data: [Tingkatkan kueri federasi dengan pushdown predikat di](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/) Amazon Athena. + Panduan Pengguna Layanan Penyimpanan Sederhana Amazon: [Pola desain praktik terbaik: mengoptimalkan kinerja Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html). + Posting [Athena lainnya di blog data AWS besar](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/). + Ajukan pertanyaan di [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) menggunakan tag **Amazon Athena**. + Konsultasikan [topik Athena di pusat AWS pengetahuan](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena). + Kontak AWS Dukungan (di Konsol Manajemen AWS, klik **Support**, **Support Center**)