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

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.

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

Gunakan proyeksi partisi

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

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

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

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

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

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

Gunakan indeks partisi

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

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

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

Selalu gunakan STRING sebagai tipe untuk kunci partisi

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

Hapus partisi lama dan kosong

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

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

Partisi kueri berdasarkan kesetaraan

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

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

Hindari penggunaan MSCK REPAIR TABLE untuk pemeliharaan partisi

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

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

Validasi bahwa kueri Anda kompatibel dengan skema partisi

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

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

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

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

Gunakan format file kolumnar

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

• Hanya kolom yang diperlukan untuk kueri yang dimuat

• Jumlah keseluruhan data yang perlu dimuat berkurang

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

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

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

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

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

Perhatikan bahwa Parket dan secara internal ORC diatur oleh kelompok baris (Parket) dan garis-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 atauORC, Anda dapat menggunakan AWS Glue ETL atau Athena. Untuk informasi selengkapnya, lihat Konversi ke format kolumnar.

Kompres data

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

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

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

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

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

Gunakan bucketing untuk pencarian pada tombol dengan kardinalitas tinggi

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

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

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.

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 di Panduan AWS Glue Pengembang dan Bagaimana cara mengonfigurasi AWS Glue ETL pekerjaan untuk menampilkan file yang lebih besar? 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, lihatPilih kunci partisi yang akan mendukung kueri Anda.

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.

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

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

Gunakan SymlinkTextInputFormat hanya jika diperlukan

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

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