Dynamic filtering — query bajarilishi davomida bir inputdan olingan qiymatlar asosida boshqa inputning o‘qiladigan qismini kamaytirish optimizatsiyasidir. U ayniqsa katta fact jadvalni kichik dimension jadval bilan join qilganda foydali. Static optimizer oldindan aniq filter bilmasa, runtime build tomondagi kalitlardan dynamic predicate yaratib, probe tomonga uzatadi.
Join misoli
So‘rov sales fact jadvalini stores dimension bilan store_id orqali qo‘shib, faqat region='Toshkent' do‘konlarini oladi. Dimension filterdan keyin 50 ta store_id qoladi. Engine shu kalitlar to‘plami yoki Bloom filterni sales skaniga yuboradi. Fact source faqat mos partition, row group yoki recordlarni o‘qishga harakat qiladi.
Dynamic filter join natijasini o‘zgartirmasligi kerak. U faqat aniq mos kelmaydigan data ni xavfsiz tashlaydi. Bloom filter false positive berishi mumkin, shuning uchun ortiqcha record o‘tadi; false negative bo‘lmasligi kerak. Yakuniy join baribir correctnessni tekshiradi.
Pushdown darajalari
Filter query engine scan operatorida qo‘llanib, dekodlangan satrlarni kamaytirishi mumkin. Connector qo‘llasa, predicate storagega push qilinadi. Partition key qiymatlari ma’lum bo‘lsa directory yoki shard pruning bajariladi. Min–max statistikasi va Bloom filter row groupni chetlab o‘tadi. Eng katta foyda data disk yoki tarmoqdan kelishidan oldin to‘xtatilganda olinadi.
Remote database connector katta IN ro‘yxatini queryga aylantirishi mumkin. Ro‘yxat juda katta bo‘lsa query parsing, parameter limit va network xarajati ortadi. Temporary table, semi-join yoki compact Bloom representation muqobil bo‘lishi mumkin.
Kutish va parallelizm
Probe scan darhol boshlansa, dynamic filter hali tayyor bo‘lmay, ko‘p data o‘qib bo‘linadi. Scan filter uchun qisqa kutishi mumkin, ammo build tomoni sekin bo‘lsa cluster bekor turadi. Optimizer dimension hajmi, filter selektivligi va source startup xarajatiga qarab wait timeout belgilaydi.
Distributed join da build tasklarining barcha kalitlari coordinator yoki tree aggregationda birlashtiriladi. Juda ko‘p distinct key filter metadata sini kattalashtiradi. Threshold oshsa dynamic filtering o‘chirilishi yoki Bloom filterga o‘tilishi mumkin. Skewli worker progressni ushlab qolmasligi kerak.
Join turlari va xavfsizlik
Inner join va semi-joinda probe tomondagi mos bo‘lmagan satrlarni tashlash tabiiy. Outer joinning preserved tomonida recordni erta olib tashlash natijani buzadi, chunki u null bilan chiqishi kerak. Anti join va null semantikasi ham ehtiyotkorlik talab qiladi. Engine faqat algebraik jihatdan xavfsiz tomonga filter uzatadi.
Filter qiymati expression cast, kollatsiya va timezone bilan join semantikasiga aynan mos bo‘ladi. NULL odatiy tenglikda hech narsaga teng emas, null-safe join esa boshqa qoidaga ega. Type conversiondagi overflow yoki truncation false negative yaratmasligi kerak.
Kuzatuv
Query plan dynamic filter ID, producer va consumer ni ko‘rsatadi. Runtime metrikalar yaratilish vaqti, key soni, qabul qilgan splitlar, oldini olingan partition va o‘qilgan baytlarni beradi. Filter mavjud bo‘lib, o‘qish kamaymasa, source pushdownni qo‘llamasligi yoki kalit cardinality juda yuqori bo‘lishi mumkin. Foyda wall time bilan birga coordinator CPU va metadata xarajati orqali baholanadi.
Kesh va qayta foydalanish
Dynamic filter odatda ayni query execution uchun yaratiladi. Uni boshqa queryda qayta ishlatish source snapshot va dimension o‘zgarmaganini isbotlashni talab qiladi. Eski filter yangi qonuniy keyni false negative qilib tashlashi mumkin, shuning uchun oddiy result cache kabi qo‘llanmaydi. Prepared query plan filter strukturasini qayta ishlatishi, ammo qiymatlarni har executionda yangidan hosil qilishi mumkin.
Bog‘liq tushunchalar
Predicate pushdown, Join, Bloom filter, Partition pruning, Query optimizer, Semi-join, Runtime optimization