Polars 2.0: ဘာလို့ joins တွေက row order ကို မထားတော့တာလဲ

ဤဗီဒီယိုတွင် ဖော်ပြထားသောအရာများ

• lazy query တွင် collect() ကို ခေါ်ဆိုခြင်းသည် streaming engine ကို မူရင်းအတိုင်း အသုံးပြုပြီး join, group_by နှင့် unpivot အတွက် row order ကို အာမခံချက်မရှိပါ။
• migration guide တွင် ဖော်ပြထားသည်မှာ order သည် 2.0 မတိုင်မီ order နှင့် မတူတော့ဘဲ အာမခံချက်မရှိကြောင်း၊ ၎င်းကို အားကိုးပါက ရှင်းလင်းသော sort ကို အကြံပြုထားသည်။
• ကျွန်ုပ်တို့၏ run တွင် မူရင်း inner join သည် input order False ကို ပြန်ပေးခဲ့ပြီး join တွင် maintain_order="left_right" သည် True ကို ပြန်ပေးခဲ့သည်။ စက်တစ်လုံး၊ run တစ်ကြိမ်၊ join shape တစ်ခု။
• Out-of-core spilling သည် မူရင်းအတိုင်း ဖွင့်ထားသည်- ၎င်းသည် RAM ၏ 80% ခန့်မှ စတင်ပြီး 64 GB မူရင်း disk budget ဖြင့် လုပ်ဆောင်သည်။ Out-of-core join နှင့် group_by တို့သည် roadmap ပေါ်တွင် ရှိသည်။
• collect_schema() သည် data မဖတ်မီ ပျောက်ဆုံးနေသော column ကို ဖမ်းယူနိုင်သော်လည်း တန်ဖိုးတစ်ခုတည်းတွင် မအောင်မြင်သော cast သည် collect() တွင်သာ မအောင်မြင်ပါ။
• TPC-H နှင့် TPC-DS နှိုင်းယှဉ်ချက်သည် derived data တွင် vendor ၏ ကိုယ်ပိုင် run ဖြစ်ပြီး ၎င်း၏ footnote တွင် ရလဒ်များသည် တရားဝင် benchmark များနှင့် နှိုင်းယှဉ်၍ မရကြောင်း ဖော်ပြထားသည်။

ဘာသာပြန်ထားသော စာသားမှတ်တမ်း

မူရင်း အင်္ဂလိပ်စကားပြောမှ ဘာသာပြန်ထားသည်။ ရရှိနိုင်သော အသံနှင့် စာတန်းထိုးများကို YouTube မှ ထိန်းချုပ်ထားသည်။

မူရင်းအစီအစဉ် ဘာကြောင့် ပြောင်းလဲသွားတာလဲ။

0:00 သင်က join တစ်ခုက သင့် rows တွေကို သင်ရေးတဲ့ အစီအစဉ်အတိုင်း ပြန်ပေးတယ်လို့ ထင်နေတာပါ။ Polars 2.0 က မူရင်းအတိုင်း အဲ့ဒါကို တမင်တကာ ကတိမပေးတော့ဘူး။ ဒီဗီဒီယိုမှာ- မူရင်းပြောင်းလဲမှုက ဘာလို့လဲ။ ဘာတွေရခဲ့လဲ။ ပြီးတော့ သင့် script တွေထဲက ဘယ်ဟာက အရင်ဆုံး ပျက်စီးမလဲ။ ဒါက The Daily Diff, under the hood ပါ။ Polars က open-source DataFrame library တစ်ခုပါ။ Python ကနေ ခေါ်ယူအသုံးပြုနိုင်တဲ့ table engine တစ်ခုပါ။

0:20 ၎င်းရဲ့ core ကို Rust နဲ့ ရေးသားထားပါတယ်။ ဒါက MIT license အောက်မှာ အခမဲ့ဖြစ်ပြီး pip install polars နဲ့ install လုပ်နိုင်ပါတယ်။ အသေးစိတ် တစ်ခုအရင်ပြောပါရစေ။ အဟောင်းအစီအစဉ်ကို ပြန်ရစေမယ့် switch က join ကိုယ်တိုင်ရဲ့ argument တစ်ခုပါ။ ဒီအကြောင်းကို နောက်ဆုံးမှာ ပြန်လာခဲ့ပါမယ်။ 2.0 ကတည်းက collect က streaming engine ကို မူရင်းအတိုင်း run ပါတယ်။ Streaming က query ကို အပြိုင် run တဲ့ chunks တွေအဖြစ် ခွဲလိုက်ပါတယ်။ ပြီးတော့ chunks တွေက ပြီးသွားရင် ပြီးသွားတာပါပဲ။

0:42 join, group by နဲ့ unpivot အတွက် ဒီ release က order ကို ကတိမပေးပါဘူး။ ဘယ်သူက အရင်ဆုံးထိခိုက်မလဲ။ output ကို သိမ်းထားတဲ့ file တစ်ခုနဲ့ row by row နှိုင်းယှဉ်သူတိုင်းပါ။ အဲ့ဒီ test က သင့် laptop မှာ အောင်မြင်နိုင်ပေမယ့် တခြားစက်မှာ ကျရှုံးနိုင်ပါတယ်။ နောက်တစ်ခုက migration guide ပါ။

migration guide က ဘာတွေ ကတိပေးထားလဲ။

0:57 အပေါ်မှာပြထားတဲ့ row order အတိအကျကို အာမခံချက်မရှိဘူးလို့ ဖော်ပြထားပါတယ်။ ဒါကြောင့် order ကို အားကိုးရင် ရှင်းလင်းစွာ sort လုပ်ပါ။ Out-of-core ကလည်း မူရင်းအတိုင်း ဖွင့်ထားပါတယ်။ ၎င်းသည် RAM ၏ ၈၀ ရာခိုင်နှုန်းခန့်တွင် disk သို့ spill စတင်လုပ်ဆောင်သည်။ ခြောက်ဆယ့်လေး gigabyte budget ဖြင့်ဖြစ်သည်။ Sort, window functions နှင့် expressions များစွာသည် ယခုအခါ spill လုပ်နိုင်ပြီဖြစ်သည်။ Joins နှင့် group-bys များသည် လာပါတော့မည်။

benchmark က တရားမျှတတဲ့ ပြိုင်ပွဲတစ်ခုလား။

1:17 Polars က TPC-H နှင့် TPC-DS benchmarks တွေမှာ DataFusion နဲ့ DuckDB ကို ကျော်ဖြတ်နိုင်တယ်လို့ ပြောပါတယ်။ ကိန်းဂဏန်းတွေက သူတို့ကိုယ်တိုင် run ထားတဲ့ derived data တွေကနေ ရတာဖြစ်ပြီး သူတို့ရဲ့ footnote မှာ တရားဝင်ရလဒ်တွေနဲ့ နှိုင်းယှဉ်လို့မရဘူးလို့ ဖော်ပြထားပါတယ်။ သူတို့ရဲ့ ကိုယ်ပိုင်နံပါတ်တွေအရ Polars က TPC-H မှာ ၁၆ cores ကနေ ၁၉၂ cores ကို သုံးဆရှစ်ဆ ပိုမြန်လာတယ်လို့ ဆိုပါတယ်။ သူတို့က စက်ကြီးရဲ့ ပိုလျှံနေတဲ့ threads တွေက small queries တွေကို နှေးကွေးစေတယ်လို့လည်း ပြောပါတယ်။

ကျွန်တော်တို့ run လုပ်တဲ့အခါ ဘာတွေမြင်ရလဲ။

1:41 Polars 2.0.0 တွင် တူညီသော join ကို နှစ်ကြိမ် run ခဲ့ပါသည်။ မူရင်း run သည် rows များကို ရောသမမွှေလိုက်သည်။ အလံဖြင့် input order သည် ကျန်ရှိနေပါသည်။ test ကို ပေးပို့သော joins များကို ရှာပါ။ ၎င်းနောက်တွင် sort မပါဝင်သော မည်သည့် join မဆို သင်ဘယ်တော့မှ မလုပ်ခဲ့သော row order ဆုံးဖြတ်ချက်တစ်ခုဖြစ်သည်။ Polars 2.0 သည် types များနှင့် ပတ်သက်၍ ပိုမိုတင်းကျပ်သည်။

ပိုတင်းကျပ်တာက ပိုစောတာကို ဆိုလိုလား။

1:58 schema check သည် data မဖတ်မီ ပျောက်ဆုံးနေသော column ကို ဖမ်းယူနိုင်သည်။ ၎င်းသည် row တစ်ခုတည်းတွင် မအောင်မြင်သော cast ကို မဖမ်းယူနိုင်ပါ၊ အဘယ်ကြောင့်ဆိုသော် ထို error သည် data ကို စောင့်နေရသောကြောင့်ဖြစ်သည်။ ယခု ကျွန်ုပ်ဖွင့်ခဲ့သော loop အကြောင်းပါ။

အဟောင်းအစီအစဉ်ကို ဘယ်လိုပြန်ရမလဲ။

2:08 switch သည် join ပေါ်တွင် တည်ရှိသည်။ join တွင် maintain order ကို သတ်မှတ်ပါ၊ သို့မဟုတ် ၎င်းနောက်တွင် sort တစ်ခုထည့်ပါ။ guide က sort ကို အကြံပြုထားသည်။ join flag သည် ကျွန်ုပ်တို့၏ run တွင် order ကို ထိန်းသိမ်းထားပြီး ဘယ်ဘက်ခြမ်း၏ order ကို left, right အဖြစ် ထိန်းသိမ်းထားသည်။ စီရင်ချက်, under the hood: NEEDS REVIEW။

စီရင်ချက်က ဘာလဲ။

2:22 upgrade မလုပ်မီ join တိုင်းကို ပြန်လည်စစ်ဆေးသင့်သည်။ ဒီအကြောင်းနဲ့ ပတ်သက်ပြီး မေးစရာရှိလား။ comments မှာ ရေးခဲ့ပါ။ ဒါကတော့ ဒီနေ့အတွက် diff ပါ။ ကျွန်တော် Axrisi က Niko ပါ။ တာဝန်ယူမှုဖြင့် ပေါင်းစည်းပါ။

ရင်းမြစ်များ

1. Release of Polars 2.0Polars (pola.rs)
2. Polars 2.0 upgrade guidePolars documentation
3. Polars homepagePolars (pola.rs)
4. polars-2.0-benchmark repositoryPolars on GitHub
5. Release of Polars 2.0 (Hacker News discussion)Hacker News