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 SQL kueri 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:

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: