Mengoptimalkan kinerja Runtime Integrasi Azure
Aliran data berjalan pada kluster Spark yang di-spin up pada saat run-time. Penggunaan konfigurasi untuk kluster ditentukan dalam runtime integrasi (IR) aktivitas. Ada tiga pertimbangan performa yang harus dibuat saat menentukan runtime integrasi Anda: jenis kluster, ukuran kluster, dan time to live.
Untuk informasi selengkapnya tentang cara membuat Integration Runtime, lihat Integration Runtime.
Cara paling mudah untuk memulai runtime integrasi aliran data adalah dengan memilih ukuran kecil, sedang, atau besar di pemilih ukuran komputasi. Lihat pemetaan ke konfigurasi kluster untuk ukuran tersebut di bawah ini.
Ukuran kluster
Aliran data mendistribusikan pemrosesan data melalui inti yang berbeda dalam kluster Spark untuk melakukan operasi secara paralel. Kluster Spark dengan lebih banyak inti meningkatkan jumlah inti di lingkungan komputasi. Lebih banyak inti meningkatkan daya pemrosesan aliran data. Meningkatkan ukuran kluster seringkali merupakan cara mudah untuk mengurangi waktu pemrosesan.
Ukuran kluster default adalah empat inti driver dan empat inti pekerja (kecil). Saat Anda memproses lebih banyak data, sebaiknya gunakan kluster yang lebih besar. Di bawah ini adalah opsi ukuran yang memungkinkan:
| Inti Pekerja | Inti Driver | Total Inti | Catatan |
|---|---|---|---|
| 4 | 4 | 8 | Bentuk dan |
| 8 | 8 | 16 | Medium |
| 16 | 16 | 32 | Bentuk dan |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
Aliran data diberi tarif berdasar pada vcore-jam yang berarti ukuran cluster dan waktu eksekusi diperhitungkan dalam hal ini. Saat Anda meningkatkan skala, biaya kluster per menit Anda akan meningkat, tetapi waktu keseluruhan Anda akan berkurang.
Tip
Ada batas pada seberapa besar pengaruh ukuran kluster pada kinerja aliran data. Bergantung pada ukuran data Anda, ada titik di mana peningkatan ukuran kluster akan berhenti meningkatkan performa. Misalnya, Jika Anda memiliki lebih banyak inti daripada partisi data, menambahkan inti tambahan tidak akan membantu. Praktik terbaik adalah memulai dari yang kecil dan meningkatkan skala untuk memenuhi kebutuhan performa Anda.
Partisi acak kustom
Aliran data membagi data menjadi partisi dan mengubahnya menggunakan proses yang berbeda. Jika ukuran data dalam partisi lebih dari proses yang dapat disimpan dalam memori, proses gagal dengan kesalahan OOM (kehabisan memori). Jika aliran data berisi sejumlah besar data yang memiliki gabungan/agregasi, Anda mungkin ingin mencoba mengubah partisi acak dengan cara bertahap. Anda dapat mengaturnya dari 50 hingga 2000, untuk menghindari kesalahan OOM. Menghitung properti Kustom dalam runtime aliran data, adalah cara untuk mengontrol persyaratan komputasi Anda. Nama properti adalah partisi Acak dan jenis bilangan bulat. Penyesuaian ini hanya boleh digunakan dalam skenario yang diketahui, jika tidak, penyesuaian ini dapat menyebabkan kegagalan aliran data yang tidak perlu.
Sambil meningkatkan partisi acak, pastikan data tersebar dengan baik. Angka kasar adalah memiliki sekitar 1,5 GB data per partisi. Jika data miring, meningkatkan "Partisi acak" tidak akan membantu. Misalnya, jika Anda memiliki data 500 GB, memiliki nilai antara 400 hingga 500 harus berfungsi. Batas default untuk partisi acak adalah 200 yang berfungsi dengan baik untuk sekitar 300 GB data.
- Dari portal ADF di bawah Kelola, pilih waktu proses integrasi kustom dan Anda masuk ke mode edit.
- Di bawah tab run time aliran data, buka bagian Properti Kustom Komputasi.
- Pilih Partisi Acak di bawah Nama properti, nilai input pilihan Anda, seperti 250, 500 dll.
Anda dapat melakukan hal yang sama dengan mengedit file JSON runtime dengan menambahkan array dengan nama properti dan nilai setelah properti yang ada seperti properti pembersihan .
Waktu untuk aktif
Secara default, setiap aktivitas aliran data melakukan spin up pada kluster Spark baru berdasarkan konfigurasi Azure Runtime integrasi. Waktu mulai aktif kluster Cold membutuhkan waktu beberapa menit sehingga pemrosesan data tidak dapat dimulai sampai waktu mulai aktif selesai. Jika alur Anda berisi beberapa aliran data berurutan, Anda dapat mengaktifkan nilai time to live (TTL). Menentukan nilai time to live membuat kluster tetap hidup untuk jangka waktu tertentu setelah eksekusinya selesai. Jika pekerjaan baru mulai menggunakan runtime integrasi selama waktu TTL, pekerjaan akan menggunakan kembali kluster yang ada dan waktu mulai akan sangat berkurang. Setelah pekerjaan kedua selesai, kluster akan kembali hidup selama waktu TTL.
Namun, jika sebagian besar aliran data Anda dijalankan secara paralel, Anda tidak disarankan untuk mengaktifkan TTL untuk runtime integrasi yang Anda gunakan untuk aktivitas tersebut. Hanya satu pekerjaan yang dapat berjalan pada satu kluster dalam satu waktu. Jika terdapat kluster yang tersedia dengan dua aliran data yang dimulai, hanya satu yang akan menggunakan kluster langsung. Pekerjaan kedua akan melakukan spin up pada kluster terisolasi sendiri.
Catatan
Waktu hingga aktif tidak tersedia saat menggunakan runtime integrasi penyelesaian otomatis (default).
Konten terkait
Lihat artikel Aliran Data lainnya yang terkait dengan performa: