Memahami dan menggunakan strategi penalaan Apache Spark

Motivator untuk membaca artikel ini.

• Pengalaman sendiri hidup dalam saat-saat huru-hara dan saat analisis tenang.
• Apa yang saya cari untuk menyelidiki lebih mendalam.
• Perkara yang saya pelajari tentang cara percikan berfungsi untuk pengoptimuman.
• Apakah 'tambah' tentang Databricks untuk pengoptimuman.
• Amalan baik yang boleh mengelakkan keperluan untuk penalaan dan pemfaktoran semula.

pengenalan

Saya sentiasa mempunyai hubungan yang baik dengan pangkalan data hubungan dan kemudiannya dengan sistem teragih seperti Spark. Pada mulanya, saya mendalami DBMS, kedua-duanya untuk menyediakan pertanyaan kompleks, pentadbiran dan terutamanya cara menyusun skrip performatif untuk DBMS. Apabila saya mula bekerja lebih banyak dengan Spark dan kemudian dengan Databricks, pada mulanya saya tidak mempunyai masalah prestasi untuk senario yang perlu saya bina, tetapi kerana kawasan bigdata benar-benar menjadi bigdata saya mula mengalami masalah prestasi dalam rutin yang meningkat sebanyak 30% setiap minggu dan ini membuatkan saya mencari cara percikan berfungsi 'di bawah hud', terutamanya kerana saya sudah tahu cara DBMS berfungsi dan ini membantu saya memahami beberapa konsep yang akan saya bawa ke sini.

Penjelasan ringkas tentang komponen Apache Spark

Mari kita ringkaskan kerana saya mahu artikel ini memfokuskan pada senario analisis prestasi, teknik dan amalan terbaik.

SparkCore:

Komponen ini adalah asas Spark, ia bertanggungjawab untuk pengurusan memori, tugas, pemulihan kegagalan, pengurusan I/O, dengan kata lain, ia memanipulasi RDD. Oleh itu, dia adalah seorang lelaki yang mempunyai sebahagian besar kluster.

Pelaksana:

Komponen ini adalah pekerja sebenar ekosistem percikan (cluster), ia adalah orang yang menerima perintah menulis atau membaca (tugas), yang boleh berada pada cakera, memori atau kedua-duanya (saya akan menerangkan kemudian mengapa ini berlaku main). senario prestasi).

pekerja:

Pekerja secara literal adalah seperti mereka bagi mereka yang sudah biasa dengan pengkomputeran teragih, mereka adalah nod kluster, jadi itulah yang 'menghos' pelaksana yang saya nyatakan di atas, setiap pekerja boleh mengandungi satu atau lebih pelaksana. Ia bertanggungjawab untuk menguruskan sumber yang diperuntukkan kepada pelaksana, seolah-olah pelaksana adalah pembantu dan pekerja adalah pekerja gudang. Bagaimana jika dia adalah penjaga gudang yang dia laporkan?

Pengurus Kluster:

Ini adalah pengurus, dia menguruskan sumber (Memori dan CPU) untuk pekerja, dialah yang menentukan bilangan pelaksana untuk setiap aplikasi dan berapa banyak sumber yang akan diperuntukkan, dia menguruskan tugas yang dihantar oleh 'nya. bos' yang akan saya terangkan lebih jauh ke bawah, dan memandangkan ia adalah jawatan tanggungjawab yang lebih tinggi, ia juga memantau keadaan kluster untuk pulih daripada kegagalan, mengagihkan semula tugas jika perlu. (NOTA: terdapat beberapa jenis pengurus kluster: Benang, mesos, kubernetes dan yang paling mudah adalah kendiri).

SparkContext:

Nah, ini bos atau gateway, saya katakan gateway kerana mana-mana aplikasi Spark akan melaluinya, itulah yang membolehkan aplikasi berinteraksi dengan kluster, iaitu pekerja dan pelaksana, ia yang membenarkan dan mengurus tugas antara pekerja dan dengan cara ini ia menguruskan keseluruhan aplikasi dari segi konfigurasi, bilangan pelaksana dan sumber seperti memori. Adakah anda perlu tahu bagaimana tugasan dijalankan? bercakap dengan bos ini di sini.

Jadi, secara ilustrasi:

Sekarang mari bercakap tentang prestasi, penalaan, kelajuan, kelajuan dan semua yang anda dengar dari kedudukan yang berbeza.

Apabila saya bekerja dengan bahagian perbankan hubungan dan terdapat masalah prestasi, terutamanya dalam prosedur atau fungsi atau pertanyaan dalam aplikasi, saya menganalisis aspek berikut:

1. Bilakah skrip ini dijalankan dan bagaimanakah pelayannya pada masa ini?
2. Adakah sesiapa yang bersaing untuk mendapatkan sumber atau kunci meja?
3. Semuanya lancar, tiada siapa yang menyekat (menyekat) sumber pelayan bagus, hebat...
4. Sekarang izinkan saya melihat skripnya, adakah logiknya berprestasi? Dalam erti kata lain, sesiapa yang berfikir tentang membaca/menulis bersama atau memikirkannya baris demi baris (ketagihan pengaturcaraan), sedang merujuk terlalu banyak lajur yang mereka tidak perlukan, pertanyaan besar dengan subkueri, CTE, dsb.? Saya mengubah suai semua mata ini (pemfaktoran semula) dan menguji kedua-dua kelajuan tindak balas dan penggunaan sumber pelayan. Mengapa saya menerangkan semua ini, sedangkan kita akan bercakap tentang Apache Spark? Jadi.... ini juga terpakai kepada Spark dan dengan cara yang saya katakan lebih kompleks, tetapi kita akan sampai ke sana.
5. Saya rasa akhir sekali, jika skripnya bagus saya akan menganalisis 'jalan batu' iaitu anggaran pelan pelaksanaan dan pelan pelaksanaan sebenar. Daripada ini, saya dapat memahami apa yang DBMS lakukan dengan statistiknya (histogram) dan laluan mana yang diandaikan untuk diikuti dengan maklumatnya dan apakah realitinya, laluan mana yang diikuti. Dan kemudian anda boleh mengenal pasti mata seperti: penapis tambahan dalam pertanyaan, JOIN yang lebih berprestasi dan juga penciptaan indeks atau jadual sementara.

Nah, saya rasa itu sahaja, sekarang apakah persamaan mata ini dengan Apache Spark?

• Skrip tidak direka untuk manipulasi set teragih (saya kata Spark mempunyai 'tambah' kesukaran lol).
• Masa ketika rutin tertentu berjalan, jika Spark Job mudah berjalan dalam kelompok yang sama dengan Job berprestasi lain (atau bahkan tidak) yang memakan semua sumber. (Lihat sejenis kunci DBMS yang terkenal di sini).
• Dan akhirnya, ya, Apache Spark mempunyai rancangan pelaksanaan, lebih tepat lagi, ia mempunyai peringkat berikut:

1. Pelan logik.
2. Satah Fizikal.
3. Strategi pelaksanaan.
4. Kadangkala menunjukkan anggaran kos.

Untuk meringkaskan maksud setiap satu, walaupun namanya, anda sudah boleh mendapatkan idea:

Pelan Logik:
Mewakili pertanyaan asal sebagai satu siri operasi logik. Ia adalah bentuk abstrak pertanyaan, tanpa mengambil kira bagaimana ia sebenarnya akan dilaksanakan. Termasuk maklumat tentang operasi yang akan dilakukan, seperti penapisan, pemilihan, penyatuan, pengagregatan dan 'perkara kecil' yang salah juga lol.

Satah Fizikal:
Butiran bagaimana Spark sebenarnya akan melaksanakan pertanyaan. Ini termasuk susunan operasi dan algoritma yang akan digunakan (seperti algoritma DBMS). Ia mungkin termasuk butiran tentang cara data akan dibahagikan dan diedarkan di kalangan pelaksana.

Strategi Pelaksanaan:
Pesawat fizikal boleh menunjukkan strategi pelaksanaan berbeza yang boleh digunakan oleh Spark, seperti "Broadcast Join" atau "Shuffle Hash Join", bergantung pada operasi dan saiz data. Saya juga akan menerangkan algoritma utama pelan pelaksanaan, bertenang...

Anggaran Kos:
Walaupun tidak selalu dipaparkan, sesetengah pelan mungkin termasuk anggaran kos untuk bahagian pelan yang berlainan, membantu anda memahami bahagian pemprosesan yang mana mungkin paling mahal.

Cara untuk melihat pelan pelaksanaan Apache Spark

Kami mempunyai bentuk 'root' yang akan menjadi teks, menggunakan perintah explain() dan ia akan mempunyai output yang serupa dengan yang di bawah menunjukkan penapis mudah dan kerangka data:

== Rancangan Fizikal ==
*(2) Penapis (Nilai > 1)
- *(2) Projek [Nama#0, Nilai#1]
- *(1) Imbas Sedia AdaRDD[Nama#0, Nilai#1]

Dan secara objektif, kita boleh menganalisisnya melalui antara muka, melalui UI Spark, dalam Databricks kita boleh mengaksesnya, sama ada dalam pelaksanaan sel, dalam kerja atau dalam kelompok. Dalam Apache Spark ia adalah secara langsung IP pada port lalai 4040.

UI Spark dibahagikan kepada beberapa bahagian berguna:

• Pekerjaan: Menunjukkan senarai semua kerja yang dilaksanakan dalam aplikasi. Setiap kerja sepadan dengan tindakan dalam kod anda.

• Peringkat: Memaparkan peringkat yang membentuk setiap kerja. Peringkat ialah pembahagian kerja yang boleh dilakukan secara selari.

• Tugas: Memperincikan tugas individu dalam setiap peringkat, termasuk maklumat tentang masa dan status pelaksanaan tugas.

• Storan: Menyediakan maklumat tentang memori dan penggunaan storan RDD (Set Data Teragih Berdaya Tahan).

• Persekitaran: Menunjukkan sifat persekitaran masa jalan, termasuk konfigurasi Spark dan pembolehubah sistem.

• Pelaksana: Memaparkan maklumat tentang pelaksana yang dibuat untuk aplikasi, termasuk penggunaan memori, penggunaan cakera dan statistik prestasi.

Di sini saya berhierarki, okay? Ini ialah susunan perkara yang berfungsi.

Saya mahu imej diletakkan pada skrin!!

Algoritma Spark dan cara mengetahui siapa pesalah penalaan:

Pertama sekali, saya akan menerangkan algoritma utama yang ditunjukkan dalam antara muka UI Spark dan dalam pelan pelaksanaan, sama ada pelan logik atau fizikal:

NOTA: Mengingati bahawa set data adalah sama di sini dengan jadual Spark ;)

1. Mari mulakan dengan Imbasan yang paling terkenal:

• FileScan: Membaca data daripada fail input. Ia boleh dioptimumkan untuk format fail yang berbeza seperti parket, ORC, CSV, JSON dan sebagainya.

2. Sertai (Yang ini memberikan beberapa B.O):

• Broadcast Hash Join: Digunakan apabila salah satu set data cukup kecil untuk dihantar ke semua nod dalam kelompok, mengelakkan Shuffle (saya akan menerangkan lebih lanjut tentang perkara ini, tetapi ringkasnya ia adalah operasi shuffle data kepada penyertaan akhir).

• Shuffle Hash Join: Kedua-dua set data (jadual jika anda lebih suka) dikocok supaya kekunci yang sepadan berada dalam partition yang sama. Ia digunakan apabila set data adalah besar dan tidak boleh dihantar ke nod lain.

• Isih Gabung Sertai: Memerlukan kedua-dua set data diisih sebelum Menyertai. Ia adalah cekap untuk set data besar yang telah dipisahkan dan dipesan, iaitu, penyambungan sedang dilakukan oleh lajur pembahagian dan juga tertib (cth. df.write.partitionBy("coluna1").sortBy("coluna2").parket(" laluan /ke/save/partitioned")

3. Pengagregatan (jumlah, kiraan, kumpulan mengikut dll...):

• HashAggregate: menggunakan jadual cincang untuk mengagregat data. Ia cekap untuk set data besar yang sesuai dengan ingatan.

• Isih Agregat. Mengagregat data selepas mengisihnya. Ia digunakan apabila data tidak muat dalam ingatan.

4. Kocok (Berhati-hati dengan lelaki ini):

• Shuffle: Mengagihkan semula data antara partition untuk operasi yang memerlukan penyusunan semula, seperti cantuman dan pengagregatan. Ia adalah operasi yang mahal dari segi I/O dan rangkaian.

5. Pertukaran:

• Menukar pengedaran data antara partition. Ia boleh digunakan untuk mengimbangi beban kerja merentas nod kluster. (strategi untuk mengimbangi dan melarikan diri dari shuffle)

6. Projek:

• Memilih subset lajur daripada DataFrame atau RDD.

7. Penapis:

• Menggunakan syarat untuk menapis baris data.

8. Isih:

• Memesan data berdasarkan satu atau lebih lajur.

Semua algoritma di atas boleh diperhatikan seperti yang saya katakan sebelum ini melalui arahan explain().

Senario masalah Shuffle kehidupan sebenar:

1. Sertai dan Operasi GroupBy
Operasi seperti join() dan groupByKey() sering mencetuskan shuffle, yang mengagihkan semula data antara partition. Ini boleh mengakibatkan:
Penggunaan I/O cakera tinggi: Kocok menjana banyak fail perantaraan, yang boleh memenuhi cakera setempat pelaksana.
Beban rangkaian tinggi: Jumlah data yang dipindahkan antara pelaksana boleh menjadi banyak, bergantung pada bilangan sambungan yang diperlukan (bilangan pemeta didarab dengan bilangan pengurang)

• Pengenalan: Dalam Spark UI, pada tab Stage, semak nilai Saiz/Rekod Baca Kocok dan Kocok Tumpahan (Cakera). Kelantangan tinggi dalam metrik ini menunjukkan kemungkinan masalah.

1. Ketidakseimbangan Partition (Data Skew) Apabila data diedarkan secara tidak sekata merentas sekatan, sesetengah tugasan mungkin mengambil masa lebih lama daripada yang lain, mengakibatkan prestasi keseluruhan terjejas. Pengenalpastian adalah sama, pergi ke Spark UI, pergi ke kerja merujuk kepada bahagian yang mengambil masa (di sini datang satu titik amalan baik yang akan saya nyatakan di bawah) dan semak peringkat tersekat (ia sedang berjalan, tetapi tidak kemajuan) dan lihat metrik Kocok, secara amnya, kelantangan tinggi dalam ingatan dan mula mempunyai kelantangan pada cakera semasa anda menyegarkan ia menunjukkan bahawa ketidakseimbangan ini mencapai memori dan mula menulis ke cakera dan jelas cakera itu lebih perlahan, kemudian anda duduk dan menangis jika anda membiarkan senario ini.

Mitigasi

• Untuk mengurangkan isu berkaitan shuffle: Kurangkan operasi yang menyebabkan shuffle: Bila boleh, minimumkan Penggunaan groupByKey() dan lebih suka reduceByKey(). Laraskan bilangan Partition: Gunakan spark.sql.shuffle.partitions untuk melaraskan bilangan Pembahagian semasa operasi shuffle. Gunakan teknik seperti Broadcast Joins: Untuk menyertai set besar Data dengan set yang lebih kecil, dengan itu mengelakkan shuffle yang tidak perlu.

Kocok metrik dalam Spark UI:

Cara shuffle berfungsi dan sebab ia mahal:

Akhir sekali dan mungkin yang paling penting - Amalan baik:

1. Sebahagian besar bekerja dengan buku nota kerana populariti hebat Databricks, buku nota Jupyter dan Google Colab. Oleh itu, bahagikan setiap pertanyaan atau transformasi kepada sel yang berasingan, ini memudahkan untuk mengenal pasti bahagian mana yang menjadi masalah prestasi. Meninggalkan segala-galanya bersama-sama, terdapat beberapa pekerjaan dan sukar untuk mengetahui peringkat mana.

2. Gunakan Gabung dan bukannya Tulis Ganti, saya tahu ia lebih berkesan, tetapi ia lebih logik dan berprestasi, memandangkan Gabungan akan menggunakan kurang I/O daripada 'dump' tulis ganti seluruh jadual sekali lagi dalam datalake.

3. Gunakan cache() atau persist() untuk menyimpan data perantaraan dalam ingatan, terutamanya jika ia akan digunakan semula merentas berbilang operasi. Ini boleh mengurangkan masa pengiraan semula dan meningkatkan prestasi.

4. Sekiranya anda tidak tahu, Spark berjalan pada JVM jadi ia adalah Java asli, apabila anda mencipta UDF yang terkenal - Fungsi Definisi Pengguna dengan Python anda meninggalkan sejenis "kotak hitam" untuk Spark, menghalang pengoptimuman automatik. Apabila boleh, gunakan fungsi Spark SQL terbina dalam, dioptimumkan untuk prestasi.

Nah, saya rasa saya menulis semua yang ada dalam fikiran saya, saya suka menulis artikel kerana ia membantu saya mengingati beberapa senario. Saya berhasrat untuk merakam video yang menunjukkan semua ini, dalam amalan dengan beberapa data awam, saya mungkin akan mendapatkannya di Kaggle jadi ikuti saya di LinkedIn untuk mengikuti semua yang berkaitan dengan dunia data, kecerdasan buatan dan pembangunan perisian

--> https://www.linkedin.com/in/airton-lira-junior-6b81a661

Ikuti saya di LinkedIn, berikan saya rangsangan, saya suka maklum balas dan saya juga terbuka sepenuhnya untuk menambah baik perkongsian pengetahuan.

Jika anda sudah membaca sejauh ini, tahniah!!! Saya harap ia dapat mengatasi semua masalah prestasi. Dalam artikel seterusnya, saya akan membincangkan kelebihan Databricks, jadi ikuti saya di LinkedIn untuk mengetahui. Terima kasih!!

Atas ialah kandungan terperinci Memahami dan menggunakan strategi penalaan Apache Spark. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!