Aracılığıyla paylaş

Yapılandırılmış Akış için üretimle ilgili dikkat edilmesi gerekenler

  • Makale

Bu makale, Azure Databricks'te işleri kullanarak Yapılandırılmış Akış iş yüklerini zamanlamaya yönelik öneriler içerir.

Databricks her zaman aşağıdakileri yapmanızı önerir:

  • display ve countgibi sonuçları döndürebilecek gereksiz kodu not defterlerinden kaldırın.
  • Tüm amaçlı işlem kullanarak Yapılandırılmış Akış iş yüklerini çalıştırmayın. Akışları her zaman iş hesaplama kullanarak iş olarak planlayın.
  • Continuous modunu kullanarak işleri zamanlayın.
  • Yapılandırılmış Akış işleri için işlem için otomatik ölçeklendirmeyi etkinleştirmeyin.

Bazı iş yükleri aşağıdakilerden yararlanıyor:

Azure Databricks, Yapılandırılmış Akış iş yükleri için üretim altyapısını yönetmenin karmaşıklıklarını azaltmak için DLT'yi kullanıma sunulmuştur. Databricks, yeni Yapılandırılmış Akış işlem hatları için DLT kullanılmasını önerir. Bkz. DLT nedir?.

Not

İşlem otomatik ölçeklendirmesi, Yapılandırılmış Akış iş yükleri için küme boyutunu azaltmayla ilgili sınırlamalara sahiptir. Databricks, akış iş yükleri için gelişmiş otomatik ölçeklendirme ile DLT kullanılmasını önerir. Bkz. Gelişmiş otomatik ölçeklendirmeile DLT işlem hatlarının küme kullanımını iyileştirme.

Akış iş yüklerini hata bekleyebileceğiniz şekilde tasarlama

Databricks her zaman akış işlerinin hata durumunda otomatik olarak yeniden başlatacak şekilde yapılandırılmasını önerir. Şema evrimi de dahil olmak üzere bazı işlevler, Yapılandırılmış Akış iş yüklerinin otomatik olarak yeniden denenecek şekilde yapılandırıldığını varsayar. Hata durumunda akış sorgularını yeniden başlatmak için bkz. Yapılandırılmış Akış işlerini yapılandırma.

Bazı işlemler foreachBatch gibi, tam olarak bir kez yerine en az bir kez garanti verir. Bu işlemler için işlem hattınızın idempotent olmasını sağlamalısınız. Bkz. Rastgele veri havuzlarına yazmak için foreachBatch'i kullanma.

Not

Bir sorgu yeniden başlatıldığında, önceki çalıştırma sırasında planlanan mikro toplu işlem gerçekleştirilir. İşiniz bellek yetersiz hatası nedeniyle başarısız olduysa veya büyük boyutlu bir mikro toplu işlem nedeniyle işi el ile iptal ettiyseniz, mikro toplu işlemi başarıyla işlemek için işlemin ölçeğini artırmanız gerekebilir.

Çalıştırmalar arasındaki yapılandırmaları değiştirirseniz, bu yapılandırmalar planlanan ilk yeni toplu işleme uygulanır. Bkz Yapılandırılmış Akış sorgusunda değişikliklerden sonra kurtarma.

bir iş ne zaman yeniden denenir?

Azure Databricks işinin bir parçası olarak birden çok görev zamanlayabilirsiniz. Sürekli tetikleyiciyi kullanarak bir işi yapılandırdığınızda, görevler arasında bağımlılık ayarlayamazsınız.

Aşağıdaki yaklaşımlardan birini kullanarak tek bir işte çok sayıda akışı zamanlamayı tercih edebilirsiniz:

  • Birden çok görev: Sürekli tetikleyiciyi kullanarak akış iş yüklerini çalıştıran birden çok görev içeren bir iş tanımlayın.
  • Birden çok sorgu: Tek bir görev için kaynak kodunda birden çok akış sorgusu tanımlayın.

Ayrıca bu stratejileri birleştirebilirsiniz. Aşağıdaki tablo bu yaklaşımları karşılaştırır.

Birden çok görev Birden çok sorgu
Hesaplama kaynakları nasıl paylaşılır? Databricks, her bir akış görevine uygun şekilde boyutlandırılmış işleri dağıtmanızı önerir. İsteğe bağlı olarak görevler arasında işlem gücü paylaşımı yapabilirsiniz. Tüm sorgular aynı hesaplamayı paylaşır. zamanlayıcı havuzlarına isteğe bağlı olarak sorgu atayabilirsiniz.
Yeniden denemeler nasıl yönetilir? İş yeniden denenmeden önce tüm görevlerin başarısız olması gerekir. Herhangi bir sorgu başarısız olursa görev yeniden denenir.

Hata durumunda akış sorgularını yeniden başlatmak için Yapılandırılmış Akış işlerini yapılandırma

Databricks, sürekli tetikleyiciyi kullanarak tüm akış iş yüklerinin yapılandırılmasını önerir. Bkz. Çalışmaları sürekli yürütme.

Sürekli tetikleyici varsayılan olarak aşağıdaki davranışı sağlar:

  • İşin birden fazla eşzamanlı çalışmasını engeller.
  • Önceki çalıştırma başarısız olduğunda yeni bir çalıştırma başlatır.
  • Yeniden denemeler için üstel geri çekilme stratejisi kullanır.

Databricks, iş akışlarını zamanlarken her zaman çok amaçlı işlem yerine iş hesaplama kaynaklarının kullanılmasını önerir. İş hatası ve yeniden deneme sırasında yeni işlem kaynakları dağıtılır.

Not

streamingQuery.awaitTermination() veya spark.streams.awaitAnyTermination() kullanmanıza gerek yok. Akış sorgusu etkin olduğunda işler otomatik olarak bir çalıştırmanın tamamlanmasını engeller.

Birden çok akış sorgusu için zamanlayıcı havuzlarını kullanma

Aynı kaynak kodundan birden çok akış sorgusu çalıştırırken sorgulara işlem kapasitesi atamak için zamanlama 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 örnek, query1'ı ayrılmış bir havuza atar, query2 ve query3 ise bir zamanlayıcı havuzunu paylaşır.

# 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")

Not

Yerel özellik yapılandırması, akış sorgunuzu başlattığınız aynı not defteri hücresinde olmalıdır.

Daha fazla ayrıntı için Apache fair scheduler belgelerine bakın.