Caching Fragmen Hasil Percikan - Amazon EMR

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

Caching Fragmen Hasil Percikan

Amazon EMR 6.6.0 dan yang lebih baru menyertakan fitur Caching Fragmen Hasil Spark opsional yang secara otomatis menyimpan fragmen hasil cache. Fragmen hasil ini adalah bagian dari hasil dari subtree kueri yang disimpan dalam bucket Amazon S3 yang Anda pilih. Fragmen hasil kueri yang disimpan digunakan kembali pada eksekusi kueri berikutnya, menghasilkan kueri yang lebih cepat.

Result Fragment Caching bekerja dengan menganalisis kueri Spark SQL Anda dan menyimpan fragmen hasil yang memenuhi syarat di lokasi S3 yang Anda tentukan. Pada query berikutnya berjalan, fragmen hasil query dapat digunakan secara otomatis terdeteksi dan diambil dari S3. Hasil Fragmen Caching berbeda dari Hasil Set Caching, di mana query berikutnya harus persis sama dengan query asli untuk mengembalikan hasil dari cache. Ketika digunakan untuk kueri yang berulang kali menargetkan subset statis data Anda, hasil fragmen caching kecepatan kinerja secara signifikan.

Pertimbangkan kueri berikut, yang menghitung pesanan hingga tahun 2022:

select l_returnflag, l_linestatus, count(*) as count_order from lineitem where l_shipdate <= current_date and year(l_shipdate) == '2022' group by l_returnflag, l_linestatus

Seiring berjalannya waktu, kueri ini perlu dijalankan setiap hari untuk melaporkan total penjualan untuk tahun tersebut. Tanpa Caching Fragmen Hasil, hasil untuk semua hari dalam setahun perlu dihitung ulang setiap hari. Kueri akan menjadi lebih lambat dari waktu ke waktu dan akan paling lambat di akhir tahun, ketika semua 365 hari hasil perlu dihitung ulang.

Saat Anda mengaktifkan Caching Fragmen Hasil, Anda menggunakan hasil untuk semua hari sebelumnya dalam setahun dari cache. Setiap hari, fitur harus menghitung ulang hanya satu hari hasil. Setelah fitur menghitung fragmen hasil, fitur cache fragmen. Akibatnya, waktu kueri berkemampuan cache cepat dan tetap konstan untuk setiap kueri berikutnya.

Mengaktifkan Caching Fragmen Hasil Spark

Untuk mengaktifkan Caching Fragmen Hasil Spark, lakukan langkah-langkah berikut ini:

  1. Buat bucket cache di Amazon S3 dan otorisasi akses baca/tulis untuk EMRFS. Untuk informasi selengkapnya, lihat Mengotorisasi akses ke data EMRFS di Amazon S3.

  2. Atur konfigurasi EMR Spark untuk mengaktifkan fitur.

    spark.subResultCache.enabled = true spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/
  3. Aktifkan manajemen siklus hidup S3 untuk bucket untuk membersihkan file cache secara otomatis.

  4. Secara opsional, konfigurasikan reductionRationThreshold dan maxBufferSize properti untuk lebih menyetel fitur.

    spark.sql.subResultCache.reductionRatioThreshold spark.sql.subResultCache.maxBufferSize

Pertimbangan saat menggunakan Caching Fragmen Hasil

Penghematan biaya ketika Anda menggunakan hasil yang sudah di-cache di Amazon S3 daripada menghitung ulang mereka tumbuh dengan berapa kali hasil cache yang sama dapat digunakan. Kueri dengan pemindaian tabel besar diikuti oleh filter atau agregasi hash yang mengurangi ukuran hasil dengan faktor minimal 8 (yaitu, rasio minimal 8:1 dalam ukuran masukan:hasil) akan mendapat manfaat paling banyak dari fitur ini. Semakin besar rasio reduksi antara input dan hasil, semakin besar manfaat biaya. Kueri dengan rasio pengurangan yang lebih kecil, tetapi berisi langkah-langkah perhitungan yang mahal antara pemindaian tabel dan filter atau agregasi juga akan menguntungkan, selama biaya untuk menghasilkan hasil lebih besar daripada biaya untuk mengambilnya dari Amazon S3. Secara default, Result Fragment Caching berlaku hanya ketika mendeteksi bahwa rasio reduksi akan setidaknya 8:1.

Ketika kueri Anda berulang kali menggunakan kembali hasil cache, manfaat dari fitur ini adalah yang terbesar. Kueri jendela bergulir dan tambahan adalah contoh yang baik. Misalnya, kueri jendela bergulir 30 hari yang telah berjalan selama 29 hari, hanya perlu menarik 1/30 data target dari sumber input aslinya dan akan menggunakan fragmen hasil cache untuk 29 hari sebelumnya. Kueri jendela tambahan akan lebih menguntungkan, karena awal jendela tetap tetap: pada setiap pemanggilan kueri, persentase pemrosesan yang lebih kecil akan memerlukan pembacaan dari sumber input.

Berikut ini adalah pertimbangan tambahan saat menggunakan Result Fragment Caching:

  • Kueri yang tidak menargetkan data yang sama dengan fragmen kueri yang sama akan memiliki hit rate cache yang rendah, karenanya tidak akan mendapat manfaat dari fitur ini.

  • Query dengan rasio reduksi rendah yang tidak mengandung langkah-langkah perhitungan mahal akan menghasilkan hasil cache yang kira-kira sama mahal untuk dibaca karena mereka awalnya memproses.

  • Query pertama akan selalu menunjukkan regresi kecil karena biaya penulisan ke cache.

  • Fitur Result Fragment Caching bekerja secara eksklusif dengan file Parket. Format file lain tidak didukung.

  • Buffer fitur Result Fragment Caching hanya akan mencoba melakukan cache scan dengan ukuran split file 128 MB atau lebih besar. Dengan konfigurasi Spark default, Result Fragment Caching akan dinonaktifkan jika ukuran pemindaian (ukuran total di semua file yang dipindai) dibagi dengan jumlah inti pelaksana kurang dari 128 MB. Ketika salah satu konfigurasi Spark yang tercantum di bawah ini ditetapkan, ukuran file split akan:

    min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))
    • spark.sql. leafNodeDefaultParalelisme (nilai default adalah spark.default.parallelism)

    • spark.sql.file. minPartitionNum (nilai default adalah spark.sql. leafNodeDefaultParalelisme)

    • spark.sql.file. openCostInByte

    • spark.sql.file. maxPartitionBytes

  • Fitur Result Fragment Caching cache pada granularitas partisi RDD. Rasio reduksi yang dijelaskan sebelumnya yang default menjadi 8:1 dinilai per partisi RDD. Beban kerja dengan rasio pengurangan per RDD yang lebih besar dan kurang dari 8:1 dapat melihat manfaat kinerja yang lebih kecil daripada beban kerja dengan rasio pengurangan per RDD yang secara konsisten kurang dari 8:1.

  • Fitur Result Fragment Caching menggunakan buffer tulis 16MB secara default untuk setiap partisi RDD yang di-cached.If lebih dari 16mb akan di-cache per partisi RDD, biaya untuk menentukan bahwa penulisan tidak mungkin dapat mengakibatkan regresi kinerja.

  • Sementara, secara default, Result Fragment Caching tidak akan mencoba untuk cache hasil partisi RDD dengan rasio reduksi lebih kecil dari 8:1 dan akan membatasi buffer tulisannya pada 16MB, kedua nilai ini dapat dirdu melalui konfigurasi berikut:

    spark.sql.subResultCache.reductionRatioThreshold (default: 8.0) spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)
  • Beberapa cluster menggunakan versi EMR yang sama dapat berbagi lokasi cache yang sama. Untuk memastikan kebenaran hasil, Result Fragment Caching tidak akan menggunakan hasil cache yang ditulis oleh versi EMR yang berbeda.

  • Hasil Fragmen Caching akan dinonaktifkan secara otomatis untuk kasus penggunaan Spark Streaming atau ketika RecordServer, Apache Ranger, atauAWS Lake Formation digunakan.

  • Baca/tulis cache fragmen hasil menggunakan bucket EMRFS dan Amazon S3. Enkripsi CSE/SSE S3/SSE KMS didukung.