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

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

Databricks her zaman aşağıdakileri yapılandırmanı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.
  • Modu kullanarak Continuousişleri zamanlayın. Azure Databricks İşleri zamanlama özelliğini, Yapılandırılmış Akış trigger interval'ından ayıran budur.
  • 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 Lakeflow Spark Bildirimli İşlem Hatları'nı kullanıma sunulmuştur. Databricks, yeni Yapılandırılmış Akış işlem hatları için Lakeflow Spark Bildirimli İşlem Hatlarının kullanılmasını önerir. Bkz. Lakeflow Spark Bildirimli İşlem Hatları

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ştirilmiş otomatik ölçeklendirme ile Lakeflow Spark Bildirimli İşlem Hatlarının kullanılmasını önerir. Bkz. Otomatik Ölçeklendirme ile Lakeflow Spark Bildirimli İşlem Hatlarının küme kullanımını iyileştirme.

:::note Sunucusuz işlem

Sunucusuz işlemde yalnızca Trigger.AvailableNow() ve Trigger.Once() desteklenir. Databricks Trigger.AvailableNow() öneriyor.

Sunucusuz işlemde sürekli akış için, sürekli modda Tetiklenen ile sürekli işlem hattı modu karşılaştırmasını kullanın.

Bkz . Akış sınırlamaları.

:::

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ı özellikler, Yapılandırılmış Akış iş yüklerinin otomatik olarak yeniden denenecek şekilde yapılandırılmasını gerektirir. 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 olduğundan emin olun. Bkz. Rastgele veri havuzlarına yazmak için foreachBatch 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 işlemini.

bir iş ne zaman yeniden denenir?

bir Azure Databricks işinin 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.

Strateji 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. İsteğe bağlı olarak zamanlayıcı havuzlarına 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 İşleri sürekli çalıştırma.

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

  • İşin birden fazla eşzamanlı çalışmasını önler.
  • Ö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

Databricks, streamingQuery.awaitTermination() veya spark.streams.awaitAnyTermination() kullanmamanızı önerir. Bkz . Ne zaman kullanılır awaitTermination()?

Ne zaman kullanılır? awaitTermination()

streamingQuery.awaitTermination() ve spark.streams.awaitAnyTermination() mevcut iş parçacığını, akış sorgusu sonlandığında kadar bloklar. Bu işlevlerin kullanılıp kullanılmaymayacağı, yürütme ortamınıza bağlıdır.

Databricks İşleri için streamingQuery.awaitTermination() ve spark.streams.awaitAnyTermination() kullanmayın. İşler hizmeti bir akış sorgusu etkin olduğunda bir çalıştırmanın tamamlanmasını otomatik olarak engellediğinden bu işlevler gerekli değildir. Her iki işlev de not defteri hücrelerinin tamamlanmasını engeller ve Görevler servisinin canlı veri sorgusunu izlemesine mani olur, bu da kapsam ölçümlerini ve iş bildirimlerini kesintiye uğratır.

Aşağıdaki durumlarda kullanın awaitTermination() :

Kullanım örneği Davranış
Tüm amaçlı hesaplamada etkileşimli not defterleri awaitTermination() hücreyi çalışır durumda tutar, sorgu durumunu gözlemlemenizi sağlar ve not defteri çıkışında hataların ortaya çıkarılmasını sağlar.
Yerel ve geliştirme ortamları Spark programını yerel olarak çalıştırırken, ana iş parçacığı tamamlandığında işlemden çıkılır. Akış sorgusu bitene veya başarısız olana kadar programı canlı tutmak için çağırın awaitTermination() .
Hatanın sürücüye iletilmesi awaitTermination() olmadan, iş bağlamı olmayan bir akış sorgusu hatası, çağıran iş parçacığına aktarılamayabilir. Sorgu sessizce başarısız olabilir ve hataların algılanıp tanılanabilmesini zorlaştırır. awaitTermination() çağrısı, sürücü üzerinde sorgu istisnasını yeniden fırlatır.

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

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.

# 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.

Apache Fair Scheduler havuzları hakkında daha fazla bilgi için Apache Fair Scheduler belgesine bakın.

  • Last updated on