YARN တွင် Spark ကို ပြင်ဆင်ခြင်း

ဟာဘ၊ မင်္ဂလာပါ။ မနေ့က Apache Spark အတွက် ရည်ရွယ်ထားသော တွေ့ဆုံမှုRambler&Co မှ ယောက်ျားလေးများထံမှ၊ ဤကိရိယာကို ပြင်ဆင်သတ်မှတ်ခြင်းနှင့် ပတ်သက်သည့် ပါဝင်သူများထံမှ မေးခွန်းများစွာရှိခဲ့သည်။ သူ့ခြေရာအတိုင်းလိုက်ဖို့ ဆုံးဖြတ်ပြီး အတွေ့အကြုံတွေကို မျှဝေခဲ့ပါတယ်။ ခေါင်းစဉ်သည် မလွယ်ကူပါ - ထို့ကြောင့် ကျွန်ုပ်တို့သည် သင့်အတွေ့အကြုံကို မှတ်ချက်များတွင် မျှဝေရန် သင့်အား ဖိတ်ခေါ်ပါသည်၊ ကျွန်ုပ်တို့လည်း နားလည်ပြီး မှားယွင်းသော တစ်ခုခုကို အသုံးပြုနိုင်ပါသည်။

Spark ကိုအသုံးပြုပုံအကြောင်း အနည်းငယ်မိတ်ဆက်ပေးပါရစေ။ ကျွန်တော်တို့မှာ သုံးလအစီအစဉ်ရှိတယ်။ “ဒေတာပညာရှင်ကြီး”နှင့် ဒုတိယ သင်ခန်းစာ တစ်လျှောက်လုံး ကျွန်ုပ်တို့၏ ပါဝင်သူများသည် ဤတူရိယာကို လုပ်ဆောင်ပါသည်။ ထို့ကြောင့်၊ စီစဉ်သူများအနေဖြင့် ကျွန်ုပ်တို့၏တာဝန်မှာ ထိုသို့သောကိစ္စရပ်အတွင်း အသုံးပြုရန်အတွက် အစုအဖွဲ့ကို ပြင်ဆင်ရန်ဖြစ်သည်။

ကျွန်ုပ်တို့၏အသုံးပြုမှု၏ထူးခြားချက်မှာ Spark ကိုတစ်ပြိုင်နက်တည်းလုပ်ဆောင်နေသောလူအရေအတွက်သည်တစ်ဖွဲ့လုံးနှင့်တူညီနိုင်သည်။ ဥပမာအားဖြင့်၊ ဆွေးနွေးပွဲတစ်ခုမှာ လူတိုင်းက တစ်ချိန်တည်းမှာ တစ်ခုခုကြိုးစားပြီး ငါတို့ရဲ့ဆရာနောက်မှာ ထပ်ပြောတဲ့အခါ။ ဒါကအများကြီးမဟုတ်ပါဘူး - တစ်ခါတစ်ရံလူ 40 အထိ။ ကမ္ဘာပေါ်တွင် ထိုသို့သောအသုံးပြုမှုကိစ္စနှင့် ရင်ဆိုင်နေရသော ကုမ္ပဏီများစွာ မရှိပါ။

ထို့နောက်၊ ကျွန်ုပ်တို့သည် အချို့သော config parameters များကို မည်သို့ရွေးချယ်ခဲ့သည်ကို ပြောပြပါမည်။

အစကနေ စလိုက်ရအောင်။ Spark တွင် အစုအဝေးတစ်ခုပေါ်တွင် လုပ်ဆောင်ရန် ရွေးချယ်စရာ 3 ခု ရှိသည်- သီးသန့်၊ Mesos ကိုအသုံးပြုခြင်းနှင့် YARN ကိုအသုံးပြုခြင်း။ ကျွန်ုပ်တို့အတွက် အဓိပ္ပါယ်ရှိသောကြောင့် တတိယရွေးချယ်မှုကို ရွေးချယ်ရန် ဆုံးဖြတ်ခဲ့သည်။ ကျွန်ုပ်တို့တွင် hadoop အစုအဝေးတစ်ခု ရှိနှင့်ပြီးဖြစ်သည်။ ကျွန်ုပ်တို့၏ပါဝင်သူများသည် ၎င်း၏ဗိသုကာပညာကို ကောင်းစွာသိပြီးဖြစ်သည်။ YARN သုံးကြည့်ရအောင်။

spark.master=yarn

ပိုစိတ်ဝင်စားဖို့ကောင်းတယ်။ ဤ အသုံးချမှု ရွေးချယ်စရာ 3 ခု တစ်ခုစီတွင် အသုံးချမှု ရွေးချယ်စရာ 2 ခု ရှိသည်- client နှင့် cluster ။ အခြေခံ စာရွက်စာတမ်း အင်တာနက်ပေါ်ရှိ လင့်ခ်အမျိုးမျိုးနှင့်၊ client သည် အပြန်အလှန်အကျိုးပြုသောအလုပ်အတွက် သင့်လျော်သည်ဟု ကျွန်ုပ်တို့ကောက်ချက်ချနိုင်သည် - ဥပမာအားဖြင့်၊ jupyter notebook နှင့် cluster သည် ထုတ်လုပ်မှုဖြေရှင်းချက်များအတွက် ပိုသင့်လျော်ပါသည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် အပြန်အလှန်အကျိုးပြုသောအလုပ်ကို စိတ်ဝင်စားခဲ့သည်၊ ထို့ကြောင့်၊

spark.deploy-mode=client

ယေဘုယျအားဖြင့်၊ ယခုမှစပြီး Spark သည် YARN တွင် တစ်နည်းနည်းဖြင့် လုပ်ဆောင်နိုင်သော်လည်း ၎င်းသည် ကျွန်ုပ်တို့အတွက် မလုံလောက်ပါ။ ကျွန်ုပ်တို့တွင် ဒေတာကြီးကြီးမားမားနှင့်ပတ်သက်သည့် ပရိုဂရမ်တစ်ခုရှိသောကြောင့် တစ်ခါတစ်ရံတွင် ပါဝင်သူများသည် အရင်းအမြစ်များကို ပိုင်းဖြတ်ခြင်း၏ဘောင်အတွင်း၌ ရရှိသောအရာများကို လုံလောက်စွာမရရှိကြပါ။ ပြီးတော့ စိတ်ဝင်စားစရာကောင်းတဲ့အချက် - တက်ကြွတဲ့အရင်းအမြစ်ခွဲဝေမှု။ အတိုချုပ်ပြောရလျှင် အချက်မှာ ဤအရာဖြစ်သည်- အကယ်၍ သင့်တွင် ခက်ခဲသောအလုပ်တစ်ခုရှိပြီး အစုအဖွဲ့သည် အခမဲ့ဖြစ်သည် (ဥပမာ၊ နံနက်ပိုင်း)၊ ထို့နောက် ဤရွေးချယ်မှုကို Spark ကိုအသုံးပြုခြင်းဖြင့် သင့်အား နောက်ထပ်အရင်းအမြစ်များကို ပေးနိုင်ပါသည်။ လိုအပ်ချက်များကို ကောက်ကျစ်သော ပုံသေနည်းအရ တွက်ချက်သည်။ အသေးစိတ်အချက်အလက်များကိုကျွန်ုပ်တို့မလေ့လာပါ - ၎င်းသည်ကောင်းစွာအလုပ်လုပ်သည်။

spark.dynamicAllocation.enabled=true

ကျွန်ုပ်တို့သည် ဤသတ်မှတ်ချက်ကို သတ်မှတ်ပြီး စတင်ချိန်တွင် Spark ပျက်သွားပြီး မစတင်ပါ။ မှန်တယ် ဆိုတော့ ကျွန်တော် ဖတ်ခဲ့ရတယ်။ စာရွက်စာတမ်း ပိုဂရုတစိုက်။ အရာအားလုံး အဆင်ပြေစေရန်အတွက် အပိုဘောင်တစ်ခုကိုလည်း ဖွင့်ထားရန် လိုအပ်သည်ဟု ၎င်းကဆိုသည်။

spark.shuffle.service.enabled=true

ဘာကြောင့် လိုအပ်တာလဲ။ ကျွန်ုပ်တို့၏အလုပ်သည် အရင်းအမြစ်များစွာမလိုအပ်တော့သည့်အခါ Spark သည် ၎င်းတို့ကို ဘုံရေကန်သို့ ပြန်ပေးသင့်သည်။ MapReduce လုပ်စရာအားလုံးနီးပါးတွင် အချိန်ကုန်ဆုံးအဆင့်မှာ မြူးကြွသည့်အဆင့်ဖြစ်သည်။ ဤအဆင့်သတ်မှတ်ချက်သည် သင့်အား ဤအဆင့်တွင် ထုတ်ပေးသည့်ဒေတာကို သိမ်းဆည်းနိုင်ပြီး စီမံအုပ်ချုပ်သူများကို လျော်ညီစွာ ထုတ်ပြန်နိုင်စေမည်ဖြစ်သည်။ ပြီးတော့ executor က အလုပ်သမားအပေါ် အရာအားလုံးကို တွက်ချက်ပေးတဲ့ လုပ်ငန်းစဉ်ပါ။ ၎င်းတွင် အချို့သော ပရိုဆက်ဆာ Core အရေအတွက်နှင့် မှတ်ဉာဏ်ပမာဏအချို့ ရှိသည်။

ဤသတ်မှတ်ချက်ကို ထည့်သွင်းပြီးဖြစ်သည်။ အရာအားလုံးက အလုပ်ဖြစ်ပုံရသည်။ ပါဝင်သူများသည် ၎င်းတို့ကို လိုအပ်သောအခါတွင် အရင်းအမြစ်များ ပိုမိုပေးအပ်ခဲ့ကြောင်း သိသာထင်ရှားလာသည်။ သို့သော် အခြားပြဿနာတစ်ခု ပေါ်လာသည်- တစ်ချိန်ချိန်တွင် အခြားပါဝင်သူများ နိုးလာပြီး Spark ကို အသုံးပြုလိုသော်လည်း ထိုနေရာတွင် အရာအားလုံး အလုပ်ရှုပ်နေပြီး ၎င်းတို့သည် မပျော်မရွှင် ဖြစ်နေကြသည်။ သူတို့နားလည်နိုင်တယ်။ စာရွက်စာတမ်းတွေကို စတင်ကြည့်ရှုခဲ့ကြတယ်။ လုပ်ငန်းစဉ်ကို လွှမ်းမိုးရန် အသုံးပြုနိုင်သည့် အခြားသော ကန့်သတ်ချက်များ များစွာရှိနေကြောင်း တွေ့ရှိရပါသည်။ ဥပမာအားဖြင့်၊ executor သည် standby mode တွင်ရှိနေပါက၊ အရင်းအမြစ်များကိုမည်သည့်အချိန်မှထုတ်ယူနိုင်မည်နည်း။

spark.dynamicAllocation.executorIdleTimeout=120s

ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ သင်၏တရားစီရင်ရေးမှူးများသည် နှစ်မိနစ်ကြာအောင် ဘာမှမလုပ်ပါက၊ ၎င်းတို့ကို ဘုံရေကန်သို့ ပြန်ပို့ပေးပါ။ ဒါပေမယ့် ဒီသတ်မှတ်ချက်က အမြဲတမ်း မလုံလောက်ပါဘူး။ ထိုလူသည် အချိန်အတော်ကြာအောင် ဘာမှမလုပ်ဘဲ၊ အရင်းအမြစ်များ မလွတ်မြောက်ကြောင်း ထင်ရှားပါသည်။ ကက်ရှ်ဒေတာပါရှိသော executors ကိုရွေးချယ်ရန် မည်သည့်အချိန်ပြီးနောက်တွင် အထူးကန့်သတ်ဘောင်တစ်ခုလည်း ရှိနေကြောင်း တွေ့ရှိရပါသည်။ မူရင်းအားဖြင့်၊ ဤကန့်သတ်ချက်သည် အဆုံးမရှိဖြစ်သည်။ အဲဒါကို ကျွန်တော်တို့ ပြင်တယ်။

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

ဆိုလိုသည်မှာ၊ သင်၏တရားစီရင်ရေးမှူးများသည် ၅ မိနစ်ကြာမျှ ဘာမှမလုပ်ပါက၊ ၎င်းတို့ကို ဘုံရေကန်သို့ ပေးလိုက်ပါ။ ဤမုဒ်တွင်၊ အသုံးပြုသူအများအပြားအတွက် အရင်းအမြစ်များကို ထုတ်လွှတ်ခြင်းနှင့် ထုတ်ပေးခြင်း၏ အမြန်နှုန်းသည် သင့်တင့်လျောက်ပတ်သည်။ မကျေမနပ်ဖြစ်မှု ပမာဏ လျော့သွားပါပြီ။ သို့သော် ကျွန်ုပ်တို့သည် ထပ်ဆင့်သွားရန် ဆုံးဖြတ်ပြီး လျှောက်လွှာတစ်ခုလျှင် အများဆုံး စီမံအုပ်ချုပ်သူ အရေအတွက်ကို ကန့်သတ်ရန် ဆုံးဖြတ်ခဲ့သည် - အခြေခံအားဖြင့် ပရိုဂရမ်ပါဝင်သူ တစ်ဦးစီအတွက် ဖြစ်သည်။

spark.dynamicAllocation.maxExecutors=19

အခု၊ တစ်ဖက်မှာ မကျေနပ်တဲ့သူတွေရှိတယ် - "အစုအဝေးက ဘာမှမလုပ်ဘဲ၊ ငါ့မှာ အမှုစီရင်သူ ၁၉ ယောက်ပဲရှိတယ်" ဒါပေမယ့် မင်းဘာလုပ်နိုင်မလဲ။ မှန်ကန်တဲ့ ချိန်ခွင်လျှာမျိုးလိုတယ်။ လူတိုင်းကို ပျော်ရွှင်အောင် မလုပ်နိုင်ပါဘူး။

ကျွန်ုပ်တို့၏ဖြစ်ရပ်နှင့်ပတ်သက်သော နောက်ထပ်အသေးစိတ်အကြောင်းအရာတစ်ခု။ တစ်နည်းတစ်ဖုံအားဖြင့် လူများစွာသည် လက်တွေ့သင်ခန်းစာအတွက် နောက်ကျခဲ့ကြပြီး အကြောင်းတစ်ခုခုကြောင့် Spark သည် ၎င်းတို့အတွက် မစတင်ခဲ့ပေ။ အခမဲ့အရင်းအမြစ်များ ပမာဏကို ကျွန်ုပ်တို့ကြည့်ရှုခဲ့သည်- ထိုနေရာတွင် ရှိနေပုံရသည်။ မီးပွားစတင်သင့်သည်။ ကံကောင်းထောက်မစွာ၊ ထိုအချိန်တွင် စာရွက်စာတမ်းများကို တစ်နေရာရာသို့ subcortex တွင်ထည့်သွင်းထားပြီးဖြစ်ပြီး စတင်သည့်အခါ Spark သည် စတင်မည့် port ကိုရှာဖွေနေကြောင်း ကျွန်ုပ်တို့သတိရမိသည်။ အကွာအဝေးရှိ ပထမ port သည် အလုပ်များနေပါက၊ ၎င်းသည် အစဉ်လိုက်အတိုင်း နောက်တစ်ခုသို့ ရွှေ့သည်။ အလကားရရင် ဖမ်းတယ်။ ပြီးတော့ ဒီအတွက် အများဆုံး ကြိုးစားမှု အရေအတွက်ကို ညွှန်ပြတဲ့ ကန့်သတ်ချက်တစ်ခု ရှိပါတယ်။ မူရင်းမှာ 16 ဖြစ်သည်။ နံပါတ်သည် အတန်းရှိ ကျွန်ုပ်တို့၏အဖွဲ့ရှိ လူအရေအတွက်ထက် နည်းပါသည်။ ထို့ကြောင့်၊ 16 ကြိမ်ကြိုးစားပြီးနောက် Spark သည်လက်လျှော့ပြီး ကျွန်ုပ်မစတင်နိုင်တော့ကြောင်းပြောခဲ့သည်။ ကျွန်ုပ်တို့သည် ဤကန့်သတ်ချက်ကို ပြုပြင်ပြီးဖြစ်သည်။

spark.port.maxRetries=50

ထို့နောက် ကျွန်ုပ်တို့၏ကိစ္စရပ်နှင့် အလွန်သက်ဆိုင်ခြင်းမရှိသော အချို့သောဆက်တင်များအကြောင်း ပြောပြပါမည်။

Spark ကိုပိုမိုမြန်ဆန်စွာစတင်ရန်၊ SPARK_HOME ပင်မလမ်းညွှန်တွင်ရှိသော jars ဖိုင်တွဲကိုသိမ်းဆည်းပြီး HDFS တွင်ထည့်ရန်အကြံပြုထားသည်။ အဲဒီအခါမှာ အလုပ်သမားတွေက ဒီ jarnik တွေတင်တာ အချိန်ဖြုန်းမှာမဟုတ်ဘူး။

spark.yarn.archive=hdfs:///tmp/spark-archive.zip

ပိုမိုမြန်ဆန်သောလုပ်ဆောင်ချက်အတွက် kryo ကို နံပါတ်စဉ်အလိုက်အသုံးပြုရန်လည်း အကြံပြုထားသည်။ ၎င်းသည် မူရင်းပုံစံထက် ပိုကောင်းအောင်ပြုလုပ်ထားသည်။

spark.serializer=org.apache.spark.serializer.KryoSerializer

ထို့အပြင် ၎င်းသည် မှတ်ဉာဏ်မှ မကြာခဏ ပျက်စီးသွားသည့် Spark တွင် ကြာရှည်စွာ ပြဿနာတစ်ခုလည်း ရှိပါသည်။ အလုပ်သမားများသည် အရာအားလုံးကို တွက်ချက်ပြီး ရလဒ်ကို ယာဉ်မောင်းထံ ပေးပို့သောအခါတွင် ဤအရာသည် မကြာခဏ ဖြစ်ပွားတတ်ပါသည်။ ကျွန်ုပ်တို့သည် ဤကန့်သတ်ချက်ကို ပိုကြီးအောင် ပြုလုပ်ထားသည်။ ပုံမှန်အားဖြင့်၊ ၎င်းသည် 1GB ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် ၎င်းကို ၃ ခုပြုလုပ်ထားသည်။

spark.driver.maxResultSize=3072

နောက်ဆုံးအနေနဲ့ အချိုပွဲအဖြစ်။ HortonWorks ဖြန့်ဖြူးမှုတွင် Spark ကို ဗားရှင်း 2.1 သို့ အပ်ဒိတ်လုပ်နည်း - HDP 2.5.3.0။ HDP ၏ဤဗားရှင်းတွင် ကြိုတင်ထည့်သွင်းထားသောဗားရှင်း 2.0 ပါရှိသည်၊ သို့သော် Spark သည် အလွန်တက်ကြွစွာလုပ်ဆောင်နေပြီဖြစ်ကြောင်း ကျွန်ုပ်တို့ကိုယ်တိုင်ဆုံးဖြတ်ပြီးသည်နှင့် ဗားရှင်းအသစ်တစ်ခုစီသည် ချို့ယွင်းချက်အချို့ကို ပြင်ဆင်ပြီး python API အတွက် အပါအဝင် နောက်ထပ်အင်္ဂါရပ်များကို ပံ့ပိုးပေးသောကြောင့် ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်၊ အဘယ်အရာလိုအပ်သနည်း။ ပြီးသွားသည်က update တစ်ခုဖြစ်သည်။

Hadoop 2.7 အတွက်တရားဝင်ဝဘ်ဆိုဒ်မှဗားရှင်းကိုဒေါင်းလုဒ်လုပ်ခဲ့သည်။ ဇစ်ဖွင့်ပြီး HDP ဖိုဒါတွင် ထည့်ပါ။ ကျွန်ုပ်တို့သည် လိုအပ်သလို symlinks များကို ထည့်သွင်းထားပါသည်။ ကျွန်ုပ်တို့ စတင်လိုက်သည် - မစတင်ပါ။ အလွန်ထူးဆန်းတဲ့ အမှားတစ်ခုရေးတယ်။

java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

Googling လုပ်ပြီးနောက် Spark သည် Hadoop မမွေးဖွားမီအထိ မစောင့်ရန် ဆုံးဖြတ်ခဲ့ပြီး ဂျာစီဗားရှင်းအသစ်ကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ JIRA တွင် ဤအကြောင်းအရာနှင့်ပတ်သက်၍ ၎င်းတို့ကိုယ်တိုင် အချင်းချင်း ငြင်းခုံကြသည်။ ဖြေရှင်းနည်းကတော့ ဒေါင်းလုဒ်လုပ်ပါ။ ဂျာစီဗားရှင်း 1.17.1. ၎င်းကို SPARK_HOME ရှိ jars ဖိုင်တွဲတွင် ထည့်ပါ၊ ၎င်းကို ဇစ်ထပ်ကာ HDFS သို့ အပ်လုဒ်လုပ်ပါ။

ကျွန်ုပ်တို့သည် ဤအမှားကို ကြုံတွေ့ခဲ့ရသော်လည်း၊ ပိုမိုကောင်းမွန်ပြီး ရိုးရှင်းသော အသစ်တစ်ခု ပေါ်လာပါသည်။

org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master

တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည်ဗားရှင်း 2.0 ကို run ရန်ကြိုးစားသည် - အားလုံးအဆင်ပြေသည်။ ဘာဖြစ်နေတာလဲ ခန့်မှန်းကြည့်ပါ။ ကျွန်ုပ်တို့သည် ဤအပလီကေးရှင်း၏ မှတ်တမ်းများကို ကြည့်ရှုပြီး ဤကဲ့သို့ အရာတစ်ခုကို တွေ့လိုက်ရသည်-

/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar

ယေဘုယျအားဖြင့်၊ အကြောင်းတစ်ခုခုကြောင့် hdp.version သည် မပြေလည်ခဲ့ပါ။ Googling လုပ်ပြီးနောက် ကျွန်ုပ်တို့သည် အဖြေတစ်ခုကို တွေ့ရှိခဲ့သည်။ သင်သည် Ambari ရှိ YARN ဆက်တင်များသို့သွားပြီး စိတ်ကြိုက် yarn-site သို့ ကန့်သတ်ချက်တစ်ခုကို ပေါင်းထည့်ရန် လိုအပ်သည်-

hdp.version=2.5.3.0-37

ဒီမှော်ပညာက ကူညီပေးခဲ့ပြီး Spark က ထွက်သွားတယ်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ Jupyter လက်ပ်တော့များစွာကို စမ်းသပ်ခဲ့သည်။ အားလုံးက အလုပ်လုပ်ပါတယ်။ စနေနေ့ (မနက်ဖြန်) တွင် ပထမဆုံး Spark သင်ခန်းစာအတွက် ကျွန်ုပ်တို့ အသင့်ဖြစ်နေပါပြီ။

DUP. စာသင်ချိန်အတွင်း နောက်ထပ်ပြဿနာတစ်ခု ပေါ်လာသည်။ တစ်ချိန်ချိန်တွင်၊ YARN သည် Spark အတွက် ကွန်တိန်နာများ ပေးဆောင်ခြင်းကို ရပ်လိုက်သည်။ YARN တွင် default အားဖြင့် 0.2 ဖြစ်သည့် parameter ကို ပြင်ရန်လိုအပ်ပါသည်။

yarn.scheduler.capacity.maximum-am-resource-percent=0.8

ဆိုလိုသည်မှာ ရင်းမြစ်များ၏ 20% မျှသာ အရင်းအမြစ်များ ဖြန့်ဖြူးရာတွင် ပါဝင်ခဲ့သည်။ ကန့်သတ်ချက်များကို ပြောင်းလဲပြီးနောက်၊ ကျွန်ုပ်တို့သည် YARN ကို ပြန်လည်စတင်ခဲ့သည်။ ပြဿနာကို ဖြေရှင်းပြီး ကျန်ပါဝင်သူများကလည်း မီးပွားအကြောင်းအရာကို လုပ်ဆောင်နိုင်ခဲ့သည်။

source: www.habr.com