ApsaraDB for SelectDB:Çalışma zamanı filtresi

HashJoinNode
     |                    |
     | 1,000,000          | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 1,000,000          | 200
    T1 (fact)            T2 (dimension)

HashJoinNode
     |                    |
     | 6,000              | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 1,000,000          | 200
    T1 (fact)            T2 (dimension)

HashJoinNode
     |                    |
     | 6,000              | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 6,000              | 200
    T1 (fact)            T2 (dimension)

Temel kavramlar

Sol tablo — Join işleminin sol tarafında yer alan tablo; probe işlemi için kullanılır. Join yeniden sıralama, hangi tablonun hangi tarafta olacağını değiştirebilir.

Sağ tablo — Join işleminin sağ tarafında yer alan tablo; hash tablosunu oluşturmak için kullanılır. Join yeniden sıralama bu durumu da değiştirebilir.

Parça (Fragment) — Sorgu yürütme birimi. Frontend (FE) düğümü, bir SQL ifadesini parçalara böler ve bunları dağıtılmış kümedeki backend (BE) düğümlerine dağıtır.

Çalışma zamanı filtrelerinin yararlı olduğu durumlar

Çalışma zamanı filtreleri aşağıdaki durumlarda en etkili sonucu verir:

• Sol tablo, sağ tablodan önemli ölçüde daha büyükse. Filtre oluşturmanın bellek ve hesaplama maliyeti vardır; bu maliyet yalnızca büyük ölçeklerde telafi edilir.

• Join sonucu, sol tablodan çok daha küçükse; bu durum, filtrenin sol tablodaki satırların çoğunu atabileceği anlamına gelir.

Sağ tablo büyükse veya join sonucu sol tabloyla neredeyse aynı büyüklükteyse, çalışma zamanı filtreleri herhangi bir fayda sağlamadan ek yük getirebilir.

Filtre türleri

ApsaraDB for SelectDB beş tür çalışma zamanı filtresini destekler:

Parametreler

runtime_filter_mode

Sorgu yürütme parçaları arasında filtre yayılımının kapsamını kontrol eder.

• **LOCAL** — Filtre üreticisi (HashJoinNode) ve tüketici (OlapScanNode) aynı parçada olmalıdır. Broadcast joinler için uygundur. Daha düşük ek yük sunar.

• **GLOBAL** — Filtreler birleştirilir ve ağ üzerinden parça sınırları arasında aktarılır. Üretici ve tüketicinin farklı parçalarda bulunduğu shuffle joinler için gereklidir.

GLOBAL modu, LOCAL modunun işlediği tüm senaryoların yanı sıra shuffle joinleri de kapsar. Belirli bir shuffle join için filtreleri birleştirip iletmenin ek yükü, tarama tasarrufundan daha fazlaysa LOCAL moduna geçin. Çalışma zamanı filtrelerini tamamen devre dışı bırakmak için OFF olarak ayarlayın.

Parçalar arası filtre birleştirme teknik tasarımı için bkz. ISSUE 6116.

runtime_filter_type

Bir tür belirtin veya birden çok türü birleştirin:

-- By name (comma-separated, quoted)
SET runtime_filter_type = "BLOOM_FILTER,IN,MIN_MAX";

-- Equivalent numeric form (1=IN, 2=BLOOM_FILTER, 4=MIN_MAX)
SET runtime_filter_type = 7;

IN yüklemesi davranışı:

• Dağıtılmış yürütme için bir birleştirme stratejisi kullanır.

• Hem IN hem de diğer filtre türleri belirtildiğinde ve sağ tablo runtime_filter_max_in_num sınırı içinde kaldığında, sistem diğer filtreleri atar. IN yüklemesi kesin sonuç verdiği için ek filtreler fayda sağlamaz. Bu optimizasyon yalnızca üretici ve tüketici aynı parçada olduğunda uygulanır.

Bloom filtresi davranışı:

• Sıfırdan farklı bir yanlış pozitif oranına sahiptir; yani eşleşmeyen bazı satırları geçirebilir. Sonuçlar doğru kalır; yalnızca filtreleme verimliliği etkilenir.

• Depolama motoruna itilebilir ancak yalnızca sol tablodaki anahtar sütunlar için geçerlidir. Depolama katmanı itmesi olmadan performans genellikle düşer.

• Düşük seçiciliğe sahip sütunlarda veya küçük sol tablolarda bloom filtreleri kullanmaktan kaçının.

MinMax filtresi davranışı:

• Sağ ve sol tabloların değer aralıkları çakışmadığında en etkilidir (örn. sağ tablonun maksimum değeri sol tablonun minimum değerinden düşükse veya tam tersi).

• Sayısal sütunlarda (INT, BIGINT, DOUBLE), çakışan aralıklar etkinliği sıfıra indirir.

• Sayısal olmayan sütunlarda (VARCHAR) genellikle performansı düşürür.

IN_OR_BLOOM_FILTER davranışı:

• Sağ tablo satırları < 102.400 ise IN yüklemesini kullanır; bu eşiğin üzerinde bloom filtresine geçer.

• Eşiği runtime_filter_max_in_num parametresiyle ayarlayın.

Bitmap filtresi davranışı:

• Yalnızca IN alt sorgusu bir bitmap sütunu döndürdüğünde uygulanabilir.

• Vektörleştirilmiş motor gerektirir.

runtime_filter_wait_time_ms

OlapScanNode, taramaya başlamadan önce atanmış her bir çalışma zamanı filtresi için bu süreye kadar bekler. Üç filtre varsa, maksimum bekleme süresi bu değerin üç katıdır.

Bekleme penceresi içinde gelen filtreler depolama motoruna itilir. Tarama başladıktan sonra gelen filtreler, zaten taranmış veriler üzerinde ifade filtreleri olarak uygulanır; bu yöntem etkilidir ancak depolama katmanı itmesinden daha az verimlidir.

Ayarlama rehberi:

• Uzun süren joinler çalıştıran yoğun kümeler — Tarama başlamadan önce filtrelerin oluşturulup iletilmesi için yeterli zaman tanımak amacıyla bu değeri artırın.

• Çok sayıda küçük sorgu çalıştıran hafif yükteki kümeler — Saniyeler içinde tamamlanan sorgulara gereksiz gecikme eklememek için bu değeri azaltın.

Küme yoğunsa ve kümede birçok kaynak yoğun veya zaman alıcı sorgu yürütülüyorsa, karmaşık sorguların optimizasyon fırsatlarını kaçırmamasını önlemek için bekleme süresini uzatabilirsiniz. Küme yükü hafifse ve kümede yalnızca birkaç saniye süren birçok küçük sorgu yürütülüyorsa, her sorgu için 1 sn'lik gecikme artışını önlemek amacıyla bekleme süresini azaltabilirsiniz.

runtime_filters_max_num

Sorgu başına bloom filtresi sayısını sınırlar. IN yüklemeleri ve MinMax filtreleri sayıma dahil edilmez.

Sınır aşıldığında, sistem daha yüksek seçiciliğe sahip (yani daha fazla satır elmesi beklenen) bloom filtrelerini korur:

Selectivity = HashJoinNode cardinality / HashJoinNode left child cardinality

Bu parametreyi yalnızca büyük tablolar arasındaki yavaş join sorgularını ayarlarken değiştirin.

Bloom filtresi boyutu parametreleri

FE, sorgu planlama zamanında bloom filtresi uzunluğunu hesaplar. Bir sorgudaki tüm HashJoinNode bloom filtreleri, birleştirilebilmeleri için aynı uzunlukta olmalıdır.

• Sağ tablo kardinalitesi istatistiklerde mevcutsa, FE optimal boyutu tahmin eder ve en yakın 2'nin katına yukarı yuvarlar.

• Kardinalite mevcut değilse, FE varsayılan olarak runtime_bloom_filter_size değerini kullanır.

• runtime_bloom_filter_min_size ve runtime_bloom_filter_max_size parametreleri, tahminden bağımsız olarak nihai boyutu sınırlar.

Daha büyük bloom filtreleri, yüksek kardinaliteli sütunları daha doğru şekilde işler ancak daha fazla bellek tüketir. Yüksek kardinaliteli bir sütun (milyonlarca farklı değer) için filtreleme doğruluğu yetersizse, runtime_bloom_filter_size değerini artırın ve sonucu kıyaslayın.

Bloom filtresi boyutunu genel olarak değil, sorgu başına ayarlayın.

CREATE TABLE test (t1 INT) DISTRIBUTED BY HASH (t1) BUCKETS 2;
INSERT INTO test VALUES (1), (2), (3), (4);

CREATE TABLE test2 (t2 INT) DISTRIBUTED BY HASH (t2) BUCKETS 2;
INSERT INTO test2 VALUES (3), (4), (5);

EXPLAIN SELECT t1 FROM test JOIN test2 WHERE test.t1 = test2.t2;

+-------------------------------------------------------------------+
| Explain String                                                    |
+-------------------------------------------------------------------+
| PLAN FRAGMENT 0                                                   |
|  OUTPUT EXPRS:`t1`                                                |
|                                                                   |
|   4:EXCHANGE                                                      |
|                                                                   |
| PLAN FRAGMENT 1                                                   |
|  OUTPUT EXPRS:                                                    |
|   PARTITION: HASH_PARTITIONED: `default_cluster:ssb`.`test`.`t1`  |
|                                                                   |
|   2:HASH JOIN                                                     |
|   |  join op: INNER JOIN (BUCKET_SHUFFLE)                         |
|   |  equal join conjunct: `test`.`t1` = `test2`.`t2`              |
|   |  runtime filters: RF000[in] <- `test2`.`t2`                   |
|   |                                                               |
|   |----3:EXCHANGE                                                 |
|   |                                                               |
|   0:OlapScanNode                                                  |
|      TABLE: test                                                  |
|      runtime filters: RF000[in] -> `test`.`t1`                    |
|                                                                   |
| PLAN FRAGMENT 2                                                   |
|  OUTPUT EXPRS:                                                    |
|   PARTITION: HASH_PARTITIONED: `default_cluster:ssb`.`test2`.`t2` |
|                                                                   |
|   1:OlapScanNode                                                  |
|      TABLE: test2                                                 |
+-------------------------------------------------------------------+

SET enable_profile = true;

RuntimeFilter:in:
    HasPushDownToEngine: true    -- filter reached the storage engine
    AWaitTimeCost: 0ns           -- no wait; filter arrived before scan started
    EffectTimeCost: 2.76ms       -- time spent applying the filter

RowsVectorPredFiltered: 9,320,008   -- rows discarded by the filter
VectorPredEvalTime: 364.39ms        -- time spent on filter evaluation