မြစ်ဝကျွန်းပေါ်- ဒေတာ ထပ်တူပြုခြင်း နှင့် ပြည့်စုံသော ပလပ်ဖောင်း

နှုန်းဖြင့် စီးဆင်းမှုအသစ်ကို စတင်ရန် မျှော်လင့်ပါသည်။ ဒေတာအင်ဂျင်နီယာ ကျွန်ုပ်တို့သည် စိတ်ဝင်စားစရာကောင်းသော အကြောင်းအရာများကို ဘာသာပြန်ရန် ပြင်ဆင်ထားပါသည်။

ယေဘုယျအမြင်

စတိုးဆိုင်တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်ရည်ရွယ်ချက်များအတွက် အသုံးပြုသည့် ဒေတာစတိုးဆိုင်အများအပြားကို အသုံးပြုသည့် အပလီကေးရှင်းများက အတော်အတန်ရေပန်းစားသော ပုံစံတစ်ခုကို ပြောပြပါမည်။ ဥပမာအားဖြင့်၊ ဒေတာပုံစံ (MySQL စသည်ဖြင့်)၊ အဆင့်မြင့်ရှာဖွေမှုစွမ်းရည်များ (ElasticSearch၊ etc.) .), caching (Memcached, etc.) နှင့် အခြားအရာများ။ ပုံမှန်အားဖြင့်၊ များစွာသောဒေတာစတိုးဆိုင်များကိုအသုံးပြုသည့်အခါ ၎င်းတို့ထဲမှတစ်ခုသည် ပင်မစတိုးဆိုင်အဖြစ်နှင့် အခြားတစ်ခုကို ဆင်းသက်လာစတိုးဆိုင်များအဖြစ် လုပ်ဆောင်သည်။ တစ်ခုတည်းသောပြဿနာမှာ ဤဒေတာစတိုးဆိုင်များကို မည်ကဲ့သို့ synchronize လုပ်မည်နည်း။

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

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

ရှိပြီးသားဖြေရှင်းနည်းများ

နှစ်ထပ်ဝင်ခြင်း။

ဒေတာစတိုးနှစ်ခုကို ထပ်တူကျစေရန်အတွက်၊ စတိုးတစ်ခုသို့ စာရေးပြီး နောက်ချက်ချင်း နောက်တစ်ခုသို့ စာရေးသည့် dual write ကို အသုံးပြုနိုင်သည်။ ပထမအကြိမ် အသံသွင်းခြင်းကို ပြန်စမ်းကြည့်နိုင်ပြီး အကြိမ်အရေအတွက် ကုန်ဆုံးပြီးနောက် ပထမအကြိမ် မအောင်မြင်ပါက ဒုတိယအား ဖျက်သိမ်းနိုင်သည်။ သို့သော်၊ ဒုတိယစတိုးသို့ စာရေး၍မရပါက ဒေတာစတိုးနှစ်ခုသည် တစ်ပြိုင်တည်းဖြစ်သွားနိုင်သည်။ ပထမသိုလှောင်မှုမှ ဒုတိယသို့ ဒေတာကို အခါအားလျော်စွာ ပြန်လည်လွှဲပြောင်းပေးနိုင်သည့် ပြန်လည်ရယူရေးလုပ်ငန်းစဉ်ကို ဖန်တီးခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းနိုင်သည် သို့မဟုတ် ဒေတာတွင် ကွဲပြားမှုများကို တွေ့ရှိမှသာ ပြုလုပ်နိုင်သည်။

ပြနာများ -

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

မှတ်တမ်းဇယားကိုပြောင်းပါ။

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

ပြနာများ -

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

MySQL ကဲ့သို့ ငွေပေးငွေယူ အစီအစဉ်ပြောင်းလဲမှုများ [1][2] ကို မပံ့ပိုးသော စနစ်များတွင် schema အပြောင်းအလဲများ ရယူခြင်းတွင် နောက်ထပ်ပြဿနာတစ်ခုဖြစ်သည်။ ထို့ကြောင့်၊ ပြောင်းလဲမှုတစ်ခုပြုလုပ်သည့်ပုံစံ (ဥပမာ၊ ဇယားကွက်ပြောင်းလဲမှု) နှင့် ၎င်းကိုပြောင်းလဲမှုမှတ်တမ်းဇယားတွင် အရောင်းအဝယ်ပြုလုပ်ခြင်းဖြင့် မှတ်တမ်းတင်ခြင်းသည် အမြဲတမ်းအလုပ်မဖြစ်ပါ။

ဖြန့်ဝေထားသော ငွေကြေးလွှဲပြောင်းမှုများ

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

ပြနာများ -

ဖြန့်ဝေထားသော ငွေပေးငွေယူများသည် ကွဲပြားသော ဒေတာစတိုးဆိုင်များအတွက် အလွန်ကြီးမားသော ပြဿနာတစ်ခုဖြစ်သည်။ ၎င်းတို့၏ သဘောသဘာဝအရ ၎င်းတို့သည် ပါဝင်သော စနစ်များ၏ အနိမ့်ဆုံး ဘုံပိုင်းခြေကိုသာ အားကိုးနိုင်သည်။ ဥပမာအားဖြင့်၊ ပြင်ဆင်မှုအဆင့်အတွင်း လျှောက်လွှာတင်ခြင်းလုပ်ငန်းစဉ် ပျက်ကွက်ပါက XA အရောင်းအ၀ယ်ပြုလုပ်ခြင်းကို ပိတ်ဆို့ထားသည်။ ထို့အပြင်၊ XA သည် မသေမချာသိရှိနိုင်မှု သို့မဟုတ် အကောင်းမြင်သဘောတူသော ငွေကြေးထိန်းချုပ်မှုအစီအစဉ်များကို ပံ့ပိုးမပေးပေ။ ထို့အပြင်၊ ElasticSearch ကဲ့သို့သော အချို့သောစနစ်များသည် XA သို့မဟုတ် အခြားသော ကွဲပြားသော ငွေပေးငွေယူပုံစံကို မပံ့ပိုးပါ။ ထို့ကြောင့်၊ အမျိုးမျိုးသော ဒေတာသိမ်းဆည်းမှုနည်းပညာများတွင် အက်တမ်ဖြစ်မှုကို သေချာစေခြင်းသည် အပလီကေးရှင်းများ [3] အတွက် အလွန်ခက်ခဲသော အလုပ်တစ်ခုအဖြစ် ရှိနေသေးသည်။

မြစ်ဝကျွန်းပေါ်

Delta သည် ရှိပြီးသား data synchronization solutions များ၏ ကန့်သတ်ချက်များကို ဖြေရှင်းရန်နှင့် on-the-fly data enrichment ကိုလည်း လုပ်ဆောင်နိုင်စေရန် ဒီဇိုင်းထုတ်ထားပါသည်။ ကျွန်ုပ်တို့၏ရည်ရွယ်ချက်မှာ လုပ်ငန်းလုပ်ဆောင်နိုင်စွမ်းကို အပြည့်အဝအာရုံစိုက်နိုင်စေရန် အက်ပလီကေးရှင်းဆော့ဖ်ဝဲရေးဆွဲသူများထံမှ ဤရှုပ်ထွေးမှုအားလုံးကို ရှင်းရှင်းလင်းလင်း ပုံဖော်ရန်ဖြစ်သည်။ ထို့နောက် Netflix ၏ Delta အတွက် အမှန်တကယ်အသုံးပြုမှုကိစ္စဖြစ်သည့် "Movie Search" ကို ဖော်ပြပါမည်။

Netflix သည် မိုက်ခရိုဆားဗစ်ဗိသုကာကို ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုကြပြီး microservice တစ်ခုစီသည် ပုံမှန်အားဖြင့် ဒေတာအမျိုးအစားတစ်ခုကို ဆောင်ရွက်ပေးပါသည်။ ရုပ်ရှင်နှင့်ပတ်သက်သည့် အခြေခံအချက်အလက်များကို Movie Service ဟုခေါ်သော အသေးစားဝန်ဆောင်မှုတစ်ခုတွင် ပါ၀င်ပြီး ထုတ်လုပ်သူများ၊ သရုပ်ဆောင်များ၊ ရောင်းချသူများနှင့် အခြားအသေးစားဝန်ဆောင်မှုများအကြောင်း အချက်အလက်များကဲ့သို့သော ဆက်စပ်ဒေတာများကို အခြားအသေးစားဝန်ဆောင်မှုများ (Deal Service၊ Talent Service နှင့် Vendor Service) မှ စီမံခန့်ခွဲပါသည်။
Netflix Studios မှ စီးပွားရေးအသုံးပြုသူများသည် အမျိုးမျိုးသော ရုပ်ရှင်စံနှုန်းများကို မကြာခဏရှာဖွေရန် လိုအပ်ပြီး ယင်းကြောင့် ရုပ်ရှင်နှင့်ပတ်သက်သည့် အချက်အလက်အားလုံးကို ရှာဖွေနိုင်စေရန်အတွက် ၎င်းတို့အတွက် အလွန်အရေးကြီးပါသည်။

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

ပုံ ၁။ မဲစာရင်းစနစ် မြစ်ဝကျွန်းပေါ်ဒေသ
Delta ကိုအသုံးပြုပြီးနောက်၊ စနစ်ကို အောက်ဖော်ပြပါပုံတွင်ပြထားသည့်အတိုင်း event driven system သို့ ရိုးရှင်းအောင်ပြုလုပ်ထားသည်။ CDC (Change-Data-Capture) ဖြစ်ရပ်များကို Delta-Connector သုံးပြီး Keystone Kafka ခေါင်းစဉ်များသို့ ပေးပို့သည်။ Delta Stream Processing Framework (Flink ကိုအခြေခံ၍) ကို အသုံးပြု၍ တည်ဆောက်ထားသော Delta အပလီကေးရှင်းသည် အကြောင်းအရာတစ်ခုမှ CDC ဖြစ်ရပ်များကို လက်ခံရရှိပြီး ၎င်းတို့ကို အခြားအသေးစားဝန်ဆောင်မှုများကိုခေါ်ဆိုခြင်းဖြင့် ကြွယ်ဝစေပြီး နောက်ဆုံးတွင် ကြွယ်ဝသောဒေတာကို Elasticsearch ရှိ ရှာဖွေမှုအညွှန်းသို့ ပေးပို့သည်။ လုပ်ငန်းစဉ်တစ်ခုလုံးသည် အချိန်နှင့်တပြေးညီနီးပါးဖြစ်ပျက်သည်၊ ဆိုလိုသည်မှာ၊ ဒေတာဂိုဒေါင်တွင် အပြောင်းအလဲများလုပ်ဆောင်သည်နှင့်တပြိုင်နက် ရှာဖွေမှုအညွှန်းများကို အပ်ဒိတ်လုပ်ပါသည်။

ပုံ ၂။ မြစ်ဝကျွန်းပေါ်ကို အသုံးပြု၍ ဒေတာပိုက်လိုင်း
အောက်ဖော်ပြပါ ကဏ္ဍများတွင်၊ သိုလှောင်ခန်းသို့ ချိတ်ဆက်ပြီး CDC ဖြစ်ရပ်များကို သယ်ယူပို့ဆောင်ရေးအလွှာသို့ ထုတ်ဝေသည့် Delta-Connector ၏ လုပ်ဆောင်ချက်ကို ဖော်ပြပါမည်။ CDC ဖြစ်ရပ်များကို Kafka ခေါင်းစဉ်များဆီသို့ အချိန်နှင့်တစ်ပြေးညီ ဒေတာထုတ်လွှင့်မှုအခြေခံအဆောက်အအုံဖြစ်သည့် သယ်ယူပို့ဆောင်ရေးအလွှာသို့ ထုတ်ဝေပါမည်။ အဆုံးတွင်၊ အပလီကေးရှင်း developer များသည် data processing နှင့် enrichment logic အတွက် အသုံးပြုနိုင်သည့် Delta stream processing framework အကြောင်း ဆွေးနွေးပါမည်။

CDC (ပြောင်းလဲမှု-ဒေတာ-ဖမ်းယူမှု)

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

Delta-Connector သည် အောက်ပါကဲ့သို့သော နောက်ထပ်အင်္ဂါရပ်များစွာကို ပံ့ပိုးပေးသည်-

• Kafka တွင် စိတ်ကြိုက် output data များကို ရေးသားနိုင်သည်။
• ဇယားများအားလုံး၊ သီးသန့်စားပွဲတစ်ခု သို့မဟုတ် ပင်မသော့များအတွက် အချိန်မရွေး လူကိုယ်တိုင်စွန့်ပစ်ခြင်းများကို အသက်သွင်းနိုင်ခြင်း။
• အမှိုက်များကို အတုံးလိုက်အတုံးလိုက် ထုတ်ယူနိုင်သည်၊ ထို့ကြောင့် မအောင်မြင်ပါက ပြန်စရန် မလိုအပ်ပါ။
• ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုမှဒေတာဘေ့စ်ရေးသားခြင်းအသွားအလာကိုဘယ်သောအခါမျှမပိတ်ဆို့ကြောင်းသေချာစေရန်အတွက်အလွန်အရေးကြီးသောစားပွဲများပေါ်တွင်သော့ခတ်ထားရန်မလိုအပ်ပါ။
• AWS Availability Zones တွင် ထပ်နေသော ဖြစ်ရပ်များကြောင့် ရရှိနိုင်မှု မြင့်မားသည်။

ကျွန်ုပ်တို့သည် AWS RDS နှင့် Aurora တွင် ဖြန့်ကျက်မှုများအပါအဝင် MySQL နှင့် Postgres ကို လောလောဆယ် ပံ့ပိုးပေးပါသည်။ ကျွန်ုပ်တို့သည် Cassandra (မာစတာပေါင်းများစွာ)ကိုလည်း ပံ့ပိုးပေးပါသည်။ Delta-Connector အကြောင်း အသေးစိတ်ကို ဤနေရာတွင် ရှာဖွေနိုင်ပါသည်။ ဘလော့ဂ်.

Kafka နှင့်သယ်ယူပို့ဆောင်ရေးအလွှာ

Delta ၏ဖြစ်ရပ်သယ်ယူပို့ဆောင်ရေးအလွှာကို ပလပ်ဖောင်း၏ စာတိုပေးပို့ခြင်းဝန်ဆောင်မှုတွင် တည်ဆောက်ထားသည်။ အဓိကကြောကျတုံး.

သမိုင်းကြောင်းအရ၊ Netflix တွင် ပို့စ်တင်ခြင်းသည် အသက်ရှည်ခြင်းထက် သုံးစွဲနိုင်မှုအတွက် အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ထားသည် (အောက်တွင်ကြည့်ပါ)။ ယခင်ဆောင်းပါး) အပေးအယူသည် အမျိုးမျိုးသော အနားသတ်အခြေအနေများတွင် ဖြစ်နိုင်ချေရှိသော ပွဲစားဒေတာများ ကွဲလွဲမှုဖြစ်သည်။ ဥပမာအားဖြင့်, မသန့်ရှင်းသော ခေါင်းဆောင် ရွေးကောက်ပွဲ မိတ္တူပွားခြင်း သို့မဟုတ် ဆုံးရှုံးသွားသော ဖြစ်ရပ်များ ရှိနိုင်ချေရှိသော လက်ခံသူအတွက် တာဝန်ရှိပါသည်။

Delta ဖြင့်၊ ကျွန်ုပ်တို့သည် CDC ပွဲများကို ဆင်းသက်လာစေရန် စတိုးဆိုင်များသို့ ပို့ဆောင်မှုသေချာစေရန် ပိုမိုခိုင်မာသောကြာရှည်ခံမှု အာမခံချက်များကို လိုချင်ပါသည်။ ဤရည်ရွယ်ချက်အတွက်၊ ကျွန်ုပ်တို့သည် ပထမတန်းစားအရာဝတ္ထုအဖြစ် အထူးဒီဇိုင်းထုတ်ထားသော Kafka အစုအဝေးတစ်ခုကို အဆိုပြုခဲ့သည်။ အောက်ပါဇယားရှိ ပွဲစားဆက်တင်အချို့ကို ကြည့်ရှုနိုင်သည်-

Keystone Kafka အစုအဝေးများတွင်၊ မသန့်ရှင်းသော ခေါင်းဆောင် ရွေးကောက်ပွဲ ထုတ်ဝေသူ ဝင်ရောက်နိုင်မှု ရှိစေရန်အတွက် အများအားဖြင့် ပါဝင်သည်။ ထပ်တူမကျသော ပုံစံတူကို ခေါင်းဆောင်အဖြစ် ရွေးချယ်ပါက ၎င်းသည် မက်ဆေ့ချ် ဆုံးရှုံးနိုင်သည်။ မြင့်မားသောရရှိနိုင်မှုအသစ် Kafka အစုအဝေးအတွက်၊ ရွေးချယ်ခွင့် မသန့်ရှင်းသော ခေါင်းဆောင် ရွေးကောက်ပွဲ မက်ဆေ့ဂျ်ဆုံးရှုံးမှုကို ကာကွယ်ရန် ပိတ်ထားသည်။

ကျွန်တော်တို့လည်း တိုးလာတယ်။ ပွားမှုအချက် 2 မှ 3 နှင့် အနည်းဆုံး insync ပုံစံတူများ 1 မှ 2။ ဤအစုအဝေးသို့ စာရေးသားထုတ်ဝေသူများသည် ပုံတူ ၃ ခုတွင် ၂ ခုတွင် ထုတ်ဝေသူမှ ပေးပို့သော လက်ရှိမက်ဆေ့ဂျ်များဖြစ်ကြောင်း သေချာစေရန် အခြားသူများထံမှ acks လိုအပ်ပါသည်။

ပွဲစားဥပမာတစ်ခု ရပ်ဆိုင်းသွားသောအခါ၊ စံနမူနာအသစ်သည် အဟောင်းကို အစားထိုးသည်။ သို့သော်၊ ပွဲစားအသစ်သည် နာရီပေါင်းများစွာ ကြာနိုင်ပြီး၊ ထပ်တူမကျသော ပုံစံတူများကို အမီလိုက်ရန် လိုအပ်ပါမည်။ ဤအခြေအနေအတွက် ပြန်လည်ရယူချိန်ကို လျှော့ချရန်၊ ကျွန်ုပ်တို့သည် ဒေသတွင်း ပွဲစားဒစ်များအစား ပိတ်ဆို့ဒေတာသိုလှောင်မှု (Amazon Elastic Block Store) ကို စတင်အသုံးပြုခဲ့သည်။ ရပ်ဆိုင်းထားသော ပွဲစားနစတန့်တစ်ခုကို အစားထိုးလိုက်သောအခါ၊ ၎င်းသည် ရပ်စဲထားသော စံနမူနာရှိ EBS ပမာဏကို ပူးတွဲပါရှိပြီး မက်ဆေ့ဂျ်အသစ်များကို စတင်လိုက်ပါသည်။ ဤလုပ်ငန်းစဉ်သည် အချည်းနှီးသောအခြေအနေမှ ပုံတူပွားရန် မလိုအပ်တော့ဘဲ နမူနာအသစ်ကို နာရီများမှ မိနစ်သို့ လျှော့ချပေးသည်။ ယေဘုယျအားဖြင့်၊ သီးခြားသိုလှောင်မှုနှင့် ပွဲစားဘဝစက်ဝန်းများသည် ပွဲစားကူးပြောင်းခြင်း၏အကျိုးသက်ရောက်မှုကို သိသိသာသာလျှော့ချပေးသည်။

ဒေတာပေးပို့မှုအာမခံချက်ကို ပိုမိုတိုးမြှင့်ရန် ကျွန်ုပ်တို့အသုံးပြုခဲ့သည်။ မက်ဆေ့ခ်ျခြေရာခံစနစ် ပြင်းထန်သောအခြေအနေများအောက်တွင် မက်ဆေ့ချ်များ ပျောက်ဆုံးမှုကို သိရှိရန် (ဥပမာ၊ အခန်းကန့်ခေါင်းဆောင်ရှိ နာရီ desynchronization)။

Stream Processing Framework

Delta ၏လုပ်ဆောင်ခြင်းအလွှာသည် Netflix ဂေဟစနစ်နှင့် Apache Flink ပေါင်းစပ်မှုကိုပံ့ပိုးပေးသည့် Netflix SPaaS ပလပ်ဖောင်း၏ထိပ်တွင်တည်ဆောက်ထားသည်။ ပလပ်ဖောင်းသည် ကျွန်ုပ်တို့၏ Titus ကွန်တိန်နာစီမံခန့်ခွဲမှုပလပ်ဖောင်း၏ထိပ်တွင် Flink အလုပ်အကိုင်များနှင့် Flink အစုအဝေးများကို စီမံကွပ်ကဲသည့် အသုံးပြုသူမျက်နှာပြင်ကို ပံ့ပိုးပေးပါသည်။ အင်တာဖေ့စ်သည် အလုပ်ဖွဲ့စည်းပုံများကို စီမံခန့်ခွဲပြီး အသုံးပြုသူများအား Flink အလုပ်အကိုင်များကို ပြန်လည်ပေါင်းစည်းရန် မလိုအပ်ဘဲ ဖွဲ့စည်းမှုပုံစံပြောင်းလဲမှုများကို ဒိုင်းနမစ်ကျကျ ပြုလုပ်နိုင်စေပါသည်။

Delta သည် Flink နှင့် SPaaS ကိုအခြေခံ၍ stream processing framework တစ်ခုကို ပံ့ပိုးပေးပါသည်။ မှတ်ချက်-အခြေခံ စိတ္တဇနည်းပညာဆိုင်ရာ အသေးစိတ်အချက်အလက်များအတွက် DSL (Domain Specific Language)။ ဥပမာအားဖြင့်၊ ပြင်ပဝန်ဆောင်မှုများကိုခေါ်ဆိုခြင်းဖြင့် ဖြစ်ရပ်များ ကြွယ်ဝလာမည့်အဆင့်ကို သတ်မှတ်ရန်၊ အသုံးပြုသူများသည် အောက်ပါ DSL ကို ရေးသားရန် လိုအပ်ပြီး Flink မှ လုပ်ဆောင်မည့် ၎င်းအပေါ် အခြေခံသည့် စံနမူနာတစ်ခု ဖန်တီးမည်ဖြစ်သည်။

ပုံ 3။ မြစ်ဝကျွန်းပေါ်ရှိ DSL တွင် ကြွယ်ဝမှု နမူနာ

အပြောင်းအလဲလုပ်ခြင်းမူဘောင်သည် သင်ယူမှုမျဉ်းကွေးကို လျှော့ချရုံသာမကဘဲ မကြာခဏ လည်ပတ်မှုဆိုင်ရာ ပြဿနာများကို ဖြေရှင်းရန် ရိုးရှင်းသော လည်ပတ်မှုဆိုင်ရာ လုပ်ငန်းစဉ်များဖြစ်သည့် ထပ်တူထပ်ခြင်း၊ ပုံဖော်ချက်ပြုလုပ်ခြင်းနှင့် ပြောင်းလွယ်ပြင်လွယ်နှင့် ခံနိုင်ရည်ရှိခြင်းတို့ကဲ့သို့သော ဘုံစီးကြောင်းလုပ်ဆောင်ခြင်းဆိုင်ရာ အင်္ဂါရပ်များကို ပံ့ပိုးပေးပါသည်။

Delta Stream Processing Framework တွင် အဓိက module နှစ်ခု၊ DSL & API module နှင့် Runtime module တို့ ပါဝင်သည်။ DSL & API module သည် DSL နှင့် UDF (User-Defined-Function) API များကို ပံ့ပိုးပေးသောကြောင့် အသုံးပြုသူများသည် ၎င်းတို့၏ ကိုယ်ပိုင်လုပ်ဆောင်ခြင်းဆိုင်ရာ ယုတ္တိဗေဒ (စစ်ထုတ်ခြင်း သို့မဟုတ် အသွင်ပြောင်းခြင်းကဲ့သို့သော) ကို ရေးသားနိုင်စေပါသည်။ Runtime module သည် DAG မော်ဒယ်များတွင် လုပ်ဆောင်ခြင်းအဆင့်များ၏ အတွင်းပိုင်းကိုယ်စားပြုမှုကို တည်ဆောက်ပေးသည့် DSL parser ကို အကောင်အထည်ဖော်ပေးပါသည်။ Execution အစိတ်အပိုင်းသည် အမှန်တကယ် Flink ထုတ်ပြန်ချက်များကို စတင်ရန်နှင့် နောက်ဆုံးတွင် Flink အပလီကေးရှင်းကို run ရန် DAG မော်ဒယ်များကို ဘာသာပြန်ပေးသည်။ ဘောင်၏ဗိသုကာလက်ရာကို အောက်ပါပုံတွင် သရုပ်ဖော်ထားသည်။

ပုံ 4. Delta Stream Processing Framework တည်ဆောက်မှု

ဤချဉ်းကပ်မှုတွင် အားသာချက်များစွာရှိသည်။

• အသုံးပြုသူများသည် Flink သို့မဟုတ် SPaaS ဖွဲ့စည်းပုံ၏ သီးခြားအသေးစိတ်အချက်အလက်များကို စူးစမ်းလေ့လာရန်မလိုဘဲ ၎င်းတို့၏ လုပ်ငန်းဆိုင်ရာ ယုတ္တိကို အာရုံစိုက်နိုင်သည်။
• ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းကို သုံးစွဲသူများအတွက် ပွင့်လင်းမြင်သာသည့်နည်းလမ်းဖြင့် လုပ်ဆောင်နိုင်ပြီး အသုံးပြုသူကုဒ် (UDF) တွင် မည်သည့်ပြောင်းလဲမှုမှ မလိုအပ်ဘဲ အမှားများကို ပြင်ဆင်နိုင်သည်။
• ပလက်ဖောင်းသည် ကွက်လပ်အတွင်း ပြောင်းလွယ်ပြင်လွယ်နှင့် ခံနိုင်ရည်ရှိမှုကို ပေးဆောင်ပြီး သတိပေးချက်များအတွက် အသုံးပြုနိုင်သည့် အသေးစိတ်မက်ထရစ်များကို စုဆောင်းထားသောကြောင့် Delta အက်ပ်အတွေ့အကြုံကို အသုံးပြုသူများအတွက် ရိုးရှင်းပါသည်။

ထုတ်လုပ်သုံးစွဲမှု

Delta သည် တစ်နှစ်ကျော်ကြာ ထုတ်လုပ်ခဲ့ပြီး Netflix Studio အပလီကေးရှင်းများစွာတွင် အဓိကအခန်းကဏ္ဍမှ ပါဝင်ခဲ့သည်။ သူမသည် ရှာဖွေမှုအညွှန်းကိန်းထုတ်ခြင်း၊ ဒေတာသိမ်းဆည်းခြင်းနှင့် ဖြစ်ရပ်မှလုပ်ဆောင်သော အလုပ်အသွားအလာများကဲ့သို့သော အသုံးပြုမှုကိစ္စများကို အကောင်အထည်ဖော်ရန် အဖွဲ့များကို ကူညီပေးခဲ့သည်။ အောက်တွင် Delta ပလပ်ဖောင်း၏ အဆင့်မြင့်ဗိသုကာလက်ရာ၏ ခြုံငုံသုံးသပ်ချက်ဖြစ်သည်။

ပုံ 5. မြစ်ဝကျွန်းပေါ်၏ အဆင့်မြင့်ဗိသုကာလက်ရာ။

ကျေးဇူးတင်လွှာ

Netflix တွင် Delta ၏ဖန်တီးမှုနှင့်ဖွံ့ဖြိုးတိုးတက်မှုတွင်ပါဝင်ခဲ့ကြသောအောက်ပါလူများကိုကျေးဇူးတင်ပါသည်- Allen Wang၊ Charles Zhao၊ Jaebin Yoon၊ Josh Snyder၊ Kasturi Chatterjee၊ Mark Cho၊ Olof Johansson၊ Piyush Goyal၊ Prashanth Ramdas၊ Raghuram Onti Srinivasan၊ Sandeep Gupta၊ Steven Wu၊ Tharanga Gamaethige၊ Yun Wang နှင့် Zhenzhong Xu။

သတင်းရင်းမြစ်

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann၊ Alastair R. Beresford၊ Boerge Svingen- အွန်လိုင်းဖြစ်ရပ်ကို လုပ်ဆောင်နေသည်။ ကွန်မြူနတီ ACM 62(5): 43–49 (2019)။ DOI- doi.org/10.1145/3312527

အခမဲ့ webinar တစ်ခုအတွက် စာရင်းသွင်းပါ။- "Amazon Redshift Storage အတွက် Data Build Tool"

source: www.habr.com