Aracılığıyla paylaş

Uyarlamalı sorgu yürütme

  • Makale

Uyarlamalı sorgu yürütme (AQE), sorgu yürütme sırasında gerçekleşen sorgu yeniden iyileştirmesidir.

Çalışma zamanını yeniden iyileştirmeye yönelik motivasyon, Azure Databricks'in karıştırma ve yayın değişiminin sonunda en güncel doğru istatistiklere sahip olmasıdır (AQE'de sorgu aşaması olarak adlandırılır). Sonuç olarak, Azure Databricks daha iyi bir fiziksel stratejiyi tercih edebilir, en uygun karıştırma sonrası bölüm boyutunu ve sayısını seçebilir veya eğme birleştirme işlemesi gibi ipuçları gerektiren iyileştirmeler yapabilir.

bu, istatistik koleksiyonu açık olmadığında veya istatistikler eski olduğunda çok yararlı olabilir. Karmaşık bir sorgunun ortasında veya veri dengesizliği oluştuktan sonra statik olarak türetilmiş istatistiklerin yanlış olduğu yerlerde de yararlıdır.

Özellikler

AQE varsayılan olarak etkindir. 4 ana özelliğe sahiptir:

  • Birleştirme birleştirmeyi dinamik olarak yayın karma birleştirmesine değiştirir.
  • Karışık değişimden sonra bölümleri dinamik olarak birleştirir (küçük bölümleri makul boyutta bölümler halinde birleştirin). Çok küçük görevler daha kötü G/Ç aktarım hızına sahiptir ve zamanlama ek yükü ve görev kurulumu ek yükünden daha fazla zarar görür. Küçük görevlerin birleştirilmesi, kaynak tasarrufu sağlar ve küme aktarım hızını artırır.
  • Dengesiz görevleri kabaca eşit boyutlu görevlere bölerek (ve gerekirse çoğaltarak) sıralama birleştirme birleştirmesindeki dengesizliği dinamik olarak işler ve karma birleştirmeyi karıştırır.
  • Boş ilişkileri dinamik olarak algılar ve yayılım.

Uygulama

AQE, aşağıdaki tüm sorgular için geçerlidir:

  • Akış dışı
  • En az bir değişim (genellikle birleştirme, toplama veya pencere olduğunda), bir alt sorgu veya her ikisini birden içerir.

AQE tarafından uygulanan sorguların tümü mutlaka yeniden iyileştirilmemiştir. Yeniden iyileştirme statik olarak derlenenden farklı bir sorgu planıyla gelebilir veya olmayabilir. Bir sorgunun planının AQE tarafından değiştirilip değiştirilmediğini belirlemek için aşağıdaki Sorgu planları bölümüne bakın.

Sorgu planları

Bu bölümde sorgu planlarını farklı şekillerde nasıl inceleyebileceğiniz açıklanır.

Bu bölümde:

Spark kullanıcı arabirimi

AdaptiveSparkPlan düğümü

AQE tarafından uygulanan sorgular genellikle her ana sorgunun veya alt sorgunun kök düğümü olarak bir veya daha fazla AdaptiveSparkPlan düğüm içerir. Sorgu çalışmadan önce veya çalıştırıldığında ilgili isFinalPlan düğümün AdaptiveSparkPlan bayrağı olarak gösterilir; sorgu yürütme tamamlandıktan sonra, bayrağı şu isFinalPlan şekilde falsedeğişir:true.

Gelişen plan

Yürütme ilerledikçe sorgu planı diyagramı gelişir ve yürütülmekte olan en güncel planı yansıtır. Önceden yürütülen düğümler (ölçümlerin kullanılabildiği) değişmez, ancak yeniden iyileştirmeler sonucunda zaman içinde değişemeyen düğümler değişebilir.

Aşağıda bir sorgu planı diyagramı örneği verilmiştir:

Query plan diagram

DataFrame.explain()

AdaptiveSparkPlan düğümü

AQE tarafından uygulanan sorgular genellikle her ana sorgunun veya alt sorgunun kök düğümü olarak bir veya daha fazla AdaptiveSparkPlan düğüm içerir. Sorgu çalışmadan önce veya çalıştırıldığında ilgili isFinalPlan düğümün AdaptiveSparkPlan bayrağı olarak falsegösterilir; sorgu yürütme tamamlandıktan isFinalPlan sonra bayrağı olarak truedeğişir.

Geçerli ve ilk plan

Her AdaptiveSparkPlan düğümün altında, yürütmenin tamamlanıp tamamlanmadığına bağlı olarak hem ilk plan (AQE iyileştirmelerini uygulamadan önceki plan) hem de geçerli veya son plan bulunur. Yürütme ilerledikçe geçerli plan gelişecektir.

Çalışma zamanı istatistikleri

Her karıştırma ve yayın aşaması veri istatistikleri içerir.

Aşama çalışmadan önce veya aşama çalışırken istatistikler derleme zamanı tahminleridir ve bayrağı isRuntime şöyledir false: Statistics(sizeInBytes=1024.0 KiB, rowCount=4, isRuntime=false);

Aşama yürütme tamamlandıktan sonra, istatistikler çalışma zamanında toplananlardır ve bayrağı isRuntime olur true, örneğin: Statistics(sizeInBytes=658.1 KiB, rowCount=2.81E+4, isRuntime=true)

Aşağıda bir DataFrame.explain örnek verilmiştir:

  • Yürütmeden önce

    Before execution

  • Yürütme sırasında

    During execution

  • Yürütmeden sonra

    After execution

SQL EXPLAIN

AdaptiveSparkPlan düğümü

AQE tarafından uygulanan sorgular genellikle her ana sorgunun veya alt sorgunun kök düğümü olarak bir veya daha fazla AdaptiveSparkPlan düğümü içerir.

Geçerli plan yok

SQL EXPLAIN Sorgu yürütülmediğinden geçerli plan her zaman ilk planla aynıdır ve AQE tarafından nelerin yürütüleceğini yansıtmaz.

Aşağıda bir SQL açıklama örneği verilmiştir:

SQL explain

Etkinliği

Bir veya daha fazla AQE iyileştirmesi geçerli olursa sorgu planı değişir. Bu AQE iyileştirmelerinin etkisi, geçerli ve son planlar ile ilk plan ile geçerli ve son planlardaki belirli plan düğümleri arasındaki farkla gösterilmiştir.

  • Sıralama birleştirme birleştirmesini dinamik olarak yayın karma birleştirmesine dönüştürme: geçerli/son plan ile ilk plan arasında farklı fiziksel birleştirme düğümleri

    Join strategy string

  • Bölümleri dinamik olarak bir arada kullanır: özelliği olan düğüm CustomShuffleReaderCoalesced

    Custom shuffle reader

    Custom shuffle reader string

  • Dengesizlik birleştirmesini dinamik olarak işleyin: alan true olarak olan isSkew düğümSortMergeJoin.

    Skew join plan

    Skew join string

  • Boş ilişkileri dinamik olarak algılayın ve yayın: planın bir bölümü (veya tamamı) localTableScan düğümüyle ve ilişki alanı boş olarak değiştirilir.

    Local table scan

    Local table scan string

Yapılandırma

Bu bölümde:

Uyarlamalı sorgu yürütmeyi etkinleştirme ve devre dışı bırakma

Özellik
spark.databricks.optimizer.adaptive.enabled

Tür: Boolean

Uyarlamalı sorgu yürütmeyi etkinleştirme veya devre dışı bırakma.

Varsayılan değer: true

Otomatik olarak iyileştirilmiş karıştırmayı etkinleştirme

Özellik
spark.sql.shuffle.partitions

Tür: Integer

Birleştirmeler veya toplamalar için verileri karıştırırken kullanılacak varsayılan bölüm sayısı. Değerin auto ayarlanması, bu sayıyı sorgu planına ve sorgu giriş veri boyutuna göre otomatik olarak belirleyen otomatik olarak iyileştirilmiş karıştırmayı etkinleştirir.

Not: Yapılandırılmış Akış için bu yapılandırma aynı denetim noktası konumundan sorgu yeniden başlatmaları arasında değiştirilemez.

Varsayılan değer: 200

Sıralama birleştirme birleştirmesini dinamik olarak yayın karma birleştirme olarak değiştirme

Özellik
spark.databricks.adaptive.autoBroadcastJoinThreshold

Tür: Byte String

Çalışma zamanında yayın katılımına geçmeyi tetikleme eşiği.

Varsayılan değer: 30MB

Bölümleri dinamik olarak birleştirme

Özellik
spark.sql.adaptive.coalescePartitions.enabled

Tür: Boolean

Bölüm birleştirmeyi etkinleştirme veya devre dışı bırakma.

Varsayılan değer: true
spark.sql.adaptive.advisoryPartitionSizeInBytes

Tür: Byte String

Birleştirmeden sonra hedef boyut. Birleştirilmiş bölüm boyutları bu hedef boyuta yakın ancak bundan büyük olmayacaktır.

Varsayılan değer: 64MB
spark.sql.adaptive.coalescePartitions.minPartitionSize

Tür: Byte String

Birleştirmeden sonra bölümlerin minimum boyutu. Birleştirilmiş bölüm boyutları bu boyuttan küçük olmayacaktır.

Varsayılan değer: 1MB
spark.sql.adaptive.coalescePartitions.minPartitionNum

Tür: Integer

Birleştirmeden sonra en az bölüm sayısı. Ayarın açıkça geçersiz kıldığından önerilmez
spark.sql.adaptive.coalescePartitions.minPartitionSize.

Varsayılan değer: 2x hayır. küme çekirdeklerinin sayısı

Dengesizlik birleştirmesini dinamik olarak işleme

Özellik
spark.sql.adaptive.skewJoin.enabled

Tür: Boolean

Eğme birleştirme işlemesini etkinleştirme veya devre dışı bırakma.

Varsayılan değer: true
spark.sql.adaptive.skewJoin.skewedPartitionFactor

Tür: Integer

Ortanca bölüm boyutuyla çarpıldığında bir bölümün çarpıp çarpılmadığını belirlemeye katkıda bulunan bir faktör.

Varsayılan değer: 5
spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes

Tür: Byte String

Bir bölümün dengesiz olup olmadığını belirlemeye katkıda bulunan bir eşik.

Varsayılan değer: 256MB

Hem hem de (partition size > skewedPartitionFactor * median partition size) (partition size > skewedPartitionThresholdInBytes) olduğunda bir bölüm dengesiz olarak kabul edilir true.

Boş ilişkileri dinamik olarak algılama ve yayma

Özellik
spark.databricks.adaptive.emptyRelationPropagation.enabled

Tür: Boolean

Dinamik boş ilişki yayma özelliğinin etkinleştirilip etkinleştirilmeyileceği veya devre dışı bırakılmayacağı.

Varsayılan değer: true

Sık sorulan sorular (SSS)

Bu bölümde:

AQE neden küçük bir birleştirme tablosu yayınlamadı?

Yayınlanması beklenen ilişkinin boyutu bu eşiğin altına düşerse ancak yine de yayınlanmadıysa:

  • Birleştirme türünü denetleyin. Yayın, belirli birleştirme türleri için desteklenmez, örneğin, bir LEFT OUTER JOIN öğesinin sol ilişkisi yayınlanamaz.
  • Ayrıca ilişki çok fazla boş bölüm içeriyor olabilir; bu durumda görevlerin çoğu sıralama birleştirme birleştirmesi ile hızlı bir şekilde tamamlanabilir veya eğme birleştirme işlemesi ile iyileştirilebilir. AQE, boş olmayan bölümlerin yüzdesi değerinden spark.sql.adaptive.nonEmptyPartitionRatioForBroadcastJoindüşükse, bu tür sıralama birleştirme birleşimlerini yayın karma birleştirmelerine değiştirmekten kaçınıyor.

AQE'nin etkin olduğu bir yayın birleştirme stratejisi ipucunu kullanmaya devam etmeli miyim?

Evet. Statik olarak planlanan bir yayın birleştirmesi genellikle AQE tarafından dinamik olarak planlanan bir birleşimden daha yüksek performans gösterir. AQE, birleştirmenin her iki tarafı için de karıştırma gerçekleştirildikten sonra (gerçek ilişki boyutları elde edilene kadar) yayın birleştirmeye geçmeyebilir. Bu nedenle, sorgunuzu iyi biliyorsanız yayın ipucu kullanmak yine de iyi bir seçim olabilir. AQE, sorgu ipuçlarını statik iyileştirmeyle aynı şekilde dikkate alır, ancak yine de ipuçlarından etkilenmeyen dinamik iyileştirmeler uygulayabilir.

Eğme birleştirme ipucu ile AQE eğme birleştirme iyileştirmesi arasındaki fark nedir? Hangisini kullanmalıyım?

AQE eğriltme birleşimi tamamen otomatik olduğundan ve genel olarak ipucuna karşılık gelenden daha iyi performans sergilediğinden, eğme birleştirme ipucunu kullanmak yerine AQE eğme birleştirme işlemesine güvenmeniz önerilir.

AQE birleşim sıralamamı neden otomatik olarak ayarlamadı?

Dinamik birleştirme yeniden sıralama, AQE'nin bir parçası değildir.

AQE neden veri dengesizliğimi algılamadı?

AQE'nin bir bölümü çarpık bölüm olarak algılaması için karşılanması gereken iki boyut koşulu vardır:

  • Bölüm boyutu, (varsayılan 256 MB) değerinden spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes büyük
  • Bölüm boyutu, tüm bölümlerin ortanca boyutundan çarpık bölüm faktöründen spark.sql.adaptive.skewJoin.skewedPartitionFactor daha büyüktür (varsayılan 5)

Buna ek olarak, eğme işleme desteği belirli birleştirme türleri için sınırlıdır, örneğin, içinde LEFT OUTER JOINyalnızca sol taraftaki eğme iyileştirilebilir.

Eski

Spark 1.6'dan bu yana "Uyarlamalı Yürütme" terimi mevcut, ancak Spark 3.0'daki yeni AQE temelde farklıdır. İşlevsellik açısından Spark 1.6 yalnızca "dinamik olarak bölümleri birleştirme" bölümünü yapar. Teknik mimari açısından yeni AQE, çalışma zamanı istatistiklerine göre sorguların dinamik planlama ve yeniden planlanması çerçevesini oluşturur. Bu çerçeve, bu makalede açıkladığımız iyileştirmeler gibi çeşitli iyileştirmeleri destekler ve daha fazla olası iyileştirme sağlamak için genişletilebilir.