Caching Fragmen Hasil Percikan

Amazon EMR 6.6.0 dan yang lebih tinggi menyertakan fitur Caching Fragmen Hasil Spark opsional yang secara otomatis menyimpan fragmen hasil cache. Fragmen hasil ini adalah bagian dari hasil dari subpohon 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 menganalisis kueri SQL Spark Anda, dan menyimpan fragmen hasil yang memenuhi syarat di lokasi S3 yang Anda tentukan. Pada proses kueri berikutnya, fragmen hasil kueri yang dapat digunakan secara otomatis terdeteksi dan diambil dari S3. Result Fragment Caching berbeda dari Result Set Caching, di mana kueri berikutnya harus sama persis dengan kueri asli untuk mengembalikan hasil dari cache. Saat digunakan untuk kueri yang berulang kali menargetkan subset statis data Anda, hasil cache fragmen mempercepat 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 Result Fragment Caching, hasil untuk semua hari dalam setahun perlu dihitung ulang setiap hari. Kueri akan menjadi lebih lambat dari waktu ke waktu dan akan paling lambat pada akhir tahun, ketika semua 365 hari hasil perlu dihitung ulang.

Saat Anda mengaktifkan Result Fragment Caching, 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 tersebut menyimpan fragmen tersebut. Akibatnya, waktu kueri yang diaktifkan cache cepat dan tetap konstan untuk setiap kueri berikutnya.

Mengaktifkan Caching Fragmen Hasil Spark

Untuk mengaktifkan Spark Result Fragment Caching, lakukan langkah-langkah berikut:

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. Setel konfigurasi Amazon 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 menyetel fitur lebih lanjut.

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

Pertimbangan saat menggunakan Result Fragment Caching

Penghematan biaya saat 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 input: hasil) akan mendapat manfaat paling besar dari fitur ini. Semakin besar rasio reduksi antara input dan hasil, semakin besar manfaat biaya. Kueri dengan rasio reduksi yang lebih kecil, tetapi yang berisi langkah-langkah perhitungan yang mahal antara pemindaian tabel dan filter atau agregasi juga akan menguntungkan, selama biaya untuk menghasilkan hasilnya lebih besar daripada biaya untuk mengambilnya dari Amazon S3. Secara default, Result Fragment Caching hanya berlaku ketika mendeteksi bahwa rasio reduksi setidaknya 8:1.

Ketika kueri Anda berulang kali menggunakan kembali hasil cache, manfaat fitur ini paling besar. Kueri jendela bergulir dan inkremental 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 selama 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 tingkat hit cache yang rendah, karenanya tidak akan mendapat manfaat dari fitur ini.

• Kueri dengan rasio reduksi rendah yang tidak mengandung langkah komputasi yang mahal akan menghasilkan hasil cache yang kira-kira sama mahalnya untuk dibaca seperti pada awalnya diproses.

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

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

• Buffer fitur Result Fragment Caching hanya akan mencoba memindai cache 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 disetel, ukuran pemisahan file akan menjadi:

  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 ke 8:1 dinilai per partisi RDD. Beban kerja dengan rasio reduksi per-RDD baik yang lebih besar maupun kurang dari 8:1 mungkin melihat manfaat kinerja yang lebih kecil daripada beban kerja dengan rasio reduksi 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-cache.Jika 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 men-cache hasil partisi RDD dengan rasio reduksi yang lebih kecil dari 8:1 dan akan membatasi buffer tulisannya pada 16MB, kedua nilai ini dapat disetel melalui konfigurasi berikut:

  spark.sql.subResultCache.reductionRatioThreshold (default: 8.0)
  spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)

• Beberapa cluster yang menggunakan rilis Amazon EMR yang sama dapat berbagi lokasi cache yang sama. Untuk memastikan kebenaran hasil, Result Fragment Caching tidak akan menggunakan hasil cache yang ditulis oleh rilis EMR Amazon yang berbeda.

• Result Fragment Caching akan dinonaktifkan secara otomatis untuk kasus penggunaan Spark Streaming atau ketika RecordServer, Apache Ranger, atau digunakan. AWS Lake Formation

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