Aynı kümede birden çok Yapılandırılmış Akış sorgusu çalıştırma

Birçok müşteri aynı Azure Databricks kümesinde birden çok Yapılandırılmış Akış sorgusu çalıştırır. Bu desen desteklense de Databricks, ölçeklendirme sorunlarını ve performans sorunlarını önlemek için küme başına sorgu sayısını sınırlamanızı önerir. Sunucusuz işlemde Azure Databricks ölçeklendirmeyi otomatik olarak yönetir, bu nedenle bu önemli noktalar sizin için ele alınır. Sürücü ve yürütücü boyutlandırmasını denetlediğiniz klasik işlem kullanıyorsanız, bu sayfada dikkate alınması gereken önemli performans sorunları ve bunları ele almanın yolları açıklanmaktadır.

Aynı kümede birden çok sorgu ne zaman kullanılır?

Aynı kümede birden çok akış sorgusu çalıştırmak, özellikle her birinin ayrılmış işlem gerektirmeyen çok sayıda küçük akışınız olduğunda altyapı maliyetlerini azaltır. Temel ödünleşim, ortak arıza riskidir: küme arızalanırsa, üzerindeki her akış da arızalanır. Görev açısından kritik işlem hatlarında bu paylaşılan hata modu genellikle kabul edilemez.

Kritik ve kritik olmayan akışları birleştiren iş yükleri için Databricks aşağıdakileri önerir:

• Her akışa iş etkisine göre bir öncelik atayın.
• Görev açısından kritik akışları daha yüksek maliyetle bile ayrılmış kümelere yerleştirin.
• İşlem kaynaklarını paylaşmak ve maliyeti azaltmak için düşük öncelikli akışları aynı ortamda konumlandırın.

Sürücü boyutlandırma

Sürücü paylaşılan bir kaynaktır. Birden çok sorgu aynı CPU, bellek, DAG zamanlayıcı, görev zamanlayıcı ve sürücü tarafı UDF yürütmesini (örneğin, foreachBatch) paylaşır. Birçok eşzamanlı akış çalıştırırken, standart CPU ve bellek sağlamanın ötesindeki bu belirli performans sorunlarını izleyin:

• Otomatik Yükleyici ek yükü: Akışlarınız Otomatik Yükleyici kullanıyorsa, dosya bulma ve dizin listesi sürücü baskısını artırır.
• İşletim sistemi düzeyinde kaynak sınırları (açık dosyalar): Tek bir sürücüde aynı anda yüksek hacimli dosya tabanlı akışlar (veya Otomatik Yükleyici gibi FileStreamSource ) çalıştırmak kullanıcı düzeyinde açık dosya tanımlayıcı sınırlarını tüketebilir ve bu da rastgele akış hatalarına neden olabilir.
• Dinleyici veri yolu geri baskısı: Çok sayıda eşzamanlı akış sorgusu, tek Bir Spark oturumunun StreamingQueryListener veri yolu üzerinde geri baskıya neden olabilir. onQueryIdle dahil olmak üzere tüm olaylar bu tek veriyoluna gönderilir ve büyük bir olay birikmesi, eşzamansız onQueryProgress işleyicilerini ciddi şekilde geciktirebilir ve küme kararlılığını etkileyebilir.
• Pahalı sürücü işlemleri: Büyük sonuç kümelerinin somutlaştırılmasını ve bellek yetersizliği (OOM) hatalarına yol açmasını önlemek için, kesinlikle gerekli olmadıkça sürücüde collect() veya diğer pahalı DataFrame işlemlerini çağırmaktan kaçının.

Sürücü çekişmesi sorunlarını giderme

OOM veya çekişme sorunları nedeniyle sürücü kilitlenmeleri yaşıyorsanız:

1. Spark kullanıcı arabiriminde sürücü ölçümlerini izleyin. Yüksek CPU, bellek veya disk kullanımı görüyorsanız, küme işlem ayarlarında sürücü boyutlandırmasını ayarlayın.
2. Sorunlar devam ederse, kodunuzun sürücüde yoğun bellek kullanan işlemler veya UDF'ler çalıştırmadığını doğrulayın.
3. Sürücüyü dikey olarak daha fazla ölçeklendiremiyorsanız Databricks, bu paylaşılan düğüm ölçeklendirme darboğazlarını aşmak için işlerinizi birden çok kümeye bölmenizi şiddetle tavsiye eder.

Eksekütör boyutlandırma

Aynı kümede çalışan birden çok sorguyla, tüm sorgular yürütücülerdeki görev yuvalarını paylaşır. Bir sorgudaki aşamalar kullanılabilir yuvaları kaplayarak diğer sorgularda gecikmelere ve yetersizliklere yol açabilir. Spark, görev yuvaları ve kullanılabilir çekirdekler arasında 1:1 eşlemesi kullanır. Sorguların eşzamanlı olarak çalıştırılması gerekiyorsa yeterli sayıda çekirdeğin kullanılabilir olduğundan emin olun.

Genel olarak, yürütücüler sürücü düğümünden daha yoğun bellek kullanan işlemler gerçekleştirebilir. Uygulama yükünüzü işlemek için gerekirse yürütücü JVM ve yığın dışı bellek ayırma parametrelerini ayarlayın. Yürütücü düğümlerinin CPU, bellek ve disk alanı açısından uygun şekilde boyutlandırıldığından ve gerekirse dikey olarak ölçeklendirildiğinden emin olun. Dikey ölçeklendirme mümkün değilse kümeye ek çalışan düğümleri eklemeyi göz önünde bulundurun.

Zamanlayıcı havuzlarını kullanın

Aynı kaynak koddan birden çok akış sorgusu çalıştırırken sorgulara işlem kapasitesi atamak için zamanlayıcı havuzlarını yapılandırabilirsiniz.

Varsayılan olarak, bir not defterinde başlatılan tüm sorgular aynı adil zamanlama havuzunda çalıştırılır. Bir not defterindeki tüm akış sorgularından tetikleyiciler tarafından oluşturulan Apache Spark işleri "ilk giriş, ilk çıkış" (FIFO) sırasına göre birbiri ardına çalıştırılır. Bu, küme kaynaklarını verimli bir şekilde paylaşmadıkları için sorgularda gereksiz gecikmelere neden olabilir.

Zamanlayıcı havuzları, hangi Yapılandırılmış Akış sorgularının işlem kaynaklarını paylaştığını bildirmenize olanak sağlar.

Aşağıdaki örnekte, query1 ayrılmış bir havuza atanırken, query2 ve query3 bir zamanlayıcı havuzunu paylaşmaktadır.

:::note Sunucusuz uyumluluk

Databricks, Databricks sunucusuz bilgi işlem mimarisiyle uyumlu olmadığı için spark.sparkContext kullanımından vazgeçilmesini önerir. Bunun yerine doğrudan (SparkSession) kullanın spark . Zamanlayıcı havuzları klasik işlem kavramıdır; Databricks sunucusuz olarak ölçeklendirmeyi ve kaynak ayırmayı otomatik olarak yönetir.

:::

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

Adil zamanlayıcı havuzları hakkında daha fazla bilgi için Apache Spark fair scheduler belgelerine bakın.

Durum bilgisi olan sorguyla ilgili dikkat edilmesi gerekenler

Aynı kümede çalışan durum bilgisi içeren sorgular için aşağıdakileri göz önünde bulundurun:

• OOM sorunlarını ve GC duraklamalarını önlemek için Durum deposu sağlayıcısı olarak RocksDB kullanın. RocksDB, Databricks Runtime 17.3 ve üzeri sürümlerin varsayılan durum deposu sağlayıcısıdır. Bkz. Azure Databricks'te RocksDB durum depolarını yapılandırma.
• Uygulamanızın gereksinimlerine göre shuffle bölümlerini ayarlayın. Durum tutan aşamalar için Spark, görevleri shuffle bölüm sayısıyla orantılı olacak şekilde planlar.
• Düğüm başına RocksDB bellek kullanımını sınırlandırın; yığın dışı bellek kullanımından kaynaklanan OOM hatalarını önlemek için. Bu, Databricks Runtime 17.3 ve üzeri sürümlerde otomatik olarak işlenir, ancak önceki sürümlerde el ile yapılandırma gerektirir. Bkz . Cap RocksDB bellek kullanımı.
• Aynı yürütücü düğümünde çok fazla bölüm paketlemekten kaçının. Anlık görüntü yükleme ve temizleme işlemleri de dahil olmak üzere, durum deposu üzerindeki bakım işlemleri her düğüm bazında çalışır. Bir yürütücü düğümüne çok fazla bölüm atamak, daha az tam anlık görüntü sağlandığı için bakım yetersizliği ve daha uzun kurtarma sürelerine neden olabilir.