ഡെൽറ്റ: ഡാറ്റ സിൻക്രൊണൈസേഷനും എൻറിച്ച്‌മെന്റ് പ്ലാറ്റ്‌ഫോമും

നിരക്കിൽ ഒരു പുതിയ ഒഴുക്കിന്റെ ലോഞ്ച് പ്രതീക്ഷിച്ച് "ഡാറ്റ എഞ്ചിനീയർ" രസകരമായ മെറ്റീരിയലിന്റെ വിവർത്തനം ഞങ്ങൾ തയ്യാറാക്കിയിട്ടുണ്ട്.

പൊതു അവലോകനം

ആപ്ലിക്കേഷനുകൾ ഒന്നിലധികം ഡാറ്റ സ്റ്റോറുകൾ ഉപയോഗിക്കുന്ന ഒരു ജനപ്രിയ പാറ്റേണിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും, അവിടെ ഓരോ സ്റ്റോറും സ്വന്തം ആവശ്യങ്ങൾക്കായി ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, ഡാറ്റയുടെ കാനോനിക്കൽ ഫോം (MySQL, മുതലായവ) സംഭരിക്കുന്നതിന്, വിപുലമായ തിരയൽ കഴിവുകൾ നൽകുക (ElasticSearch, മുതലായവ) .), കാഷിംഗ് (മെംകാഷ്ഡ്, മുതലായവ) കൂടാതെ മറ്റുള്ളവയും. സാധാരണഗതിയിൽ, ഒന്നിലധികം ഡാറ്റ സ്റ്റോറുകൾ ഉപയോഗിക്കുമ്പോൾ, അവയിലൊന്ന് പ്രാഥമിക സ്റ്റോറായും മറ്റുള്ളവ ഡെറിവേറ്റീവ് സ്റ്റോറായും പ്രവർത്തിക്കുന്നു. ഈ ഡാറ്റ സ്റ്റോറുകൾ എങ്ങനെ സമന്വയിപ്പിക്കാം എന്നതാണ് ഒരേയൊരു പ്രശ്നം.

ഒന്നിലധികം സ്റ്റോറുകൾ സമന്വയിപ്പിക്കുന്നതിനുള്ള പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിച്ച നിരവധി വ്യത്യസ്ത പാറ്റേണുകൾ ഞങ്ങൾ പരിശോധിച്ചു, ഇരട്ട എഴുത്തുകൾ, വിതരണം ചെയ്ത ഇടപാടുകൾ മുതലായവ. എന്നിരുന്നാലും, ഈ സമീപനങ്ങൾക്ക് യഥാർത്ഥ ജീവിത ഉപയോഗം, വിശ്വാസ്യത, പരിപാലനം എന്നിവയുടെ കാര്യത്തിൽ കാര്യമായ പരിമിതികളുണ്ട്. ഡാറ്റ സിൻക്രൊണൈസേഷനു പുറമേ, ചില ആപ്ലിക്കേഷനുകൾ ബാഹ്യ സേവനങ്ങളെ വിളിച്ച് ഡാറ്റ സമ്പുഷ്ടമാക്കേണ്ടതുണ്ട്.

ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനാണ് ഡെൽറ്റ വികസിപ്പിച്ചെടുത്തത്. ഡാറ്റാ സിൻക്രൊണൈസേഷനും സമ്പുഷ്ടീകരണത്തിനുമായി ഡെൽറ്റ ആത്യന്തികമായി സ്ഥിരമായ, ഇവന്റ്-ഡ്രൈവ് പ്ലാറ്റ്ഫോം നൽകുന്നു.

നിലവിലുള്ള പരിഹാരങ്ങൾ

ഇരട്ട എൻട്രി

രണ്ട് ഡാറ്റ സ്റ്റോറുകൾ സമന്വയിപ്പിക്കുന്നതിന്, നിങ്ങൾക്ക് ഡ്യുവൽ റൈറ്റ് ഉപയോഗിക്കാം, അത് ഒരു സ്റ്റോറിലേക്ക് എഴുതുകയും പിന്നീട് മറ്റൊന്നിലേക്ക് എഴുതുകയും ചെയ്യും. ആദ്യ റെക്കോർഡിംഗ് വീണ്ടും ശ്രമിക്കാവുന്നതാണ്, നിരവധി തവണ ശ്രമിച്ചതിന് ശേഷം ആദ്യത്തേത് പരാജയപ്പെട്ടാൽ രണ്ടാമത്തേത് നിർത്തലാക്കാവുന്നതാണ്. എന്നിരുന്നാലും, രണ്ടാമത്തെ സ്റ്റോറിലേക്ക് എഴുതുന്നത് പരാജയപ്പെടുകയാണെങ്കിൽ രണ്ട് ഡാറ്റ സ്റ്റോറുകളും സമന്വയത്തിന് പുറത്തായേക്കാം. ആദ്യത്തെ സ്റ്റോറേജിൽ നിന്ന് രണ്ടാമത്തേതിലേക്ക് ഇടയ്ക്കിടെ ഡാറ്റ വീണ്ടും കൈമാറ്റം ചെയ്യാൻ കഴിയുന്ന ഒരു വീണ്ടെടുക്കൽ നടപടിക്രമം സൃഷ്ടിക്കുന്നതിലൂടെ ഈ പ്രശ്നം സാധാരണയായി പരിഹരിക്കപ്പെടും, അല്ലെങ്കിൽ ഡാറ്റയിൽ വ്യത്യാസങ്ങൾ കണ്ടെത്തിയാൽ മാത്രം ചെയ്യുക.

പ്രശ്നങ്ങൾ:

ഒരു വീണ്ടെടുക്കൽ നടപടിക്രമം നടത്തുന്നത് വീണ്ടും ഉപയോഗിക്കാൻ കഴിയാത്ത ഒരു പ്രത്യേക ജോലിയാണ്. കൂടാതെ, വീണ്ടെടുക്കൽ നടപടിക്രമം നടക്കുന്നത് വരെ സ്റ്റോറേജ് ലൊക്കേഷനുകൾക്കിടയിലുള്ള ഡാറ്റ സമന്വയത്തിന് പുറത്താണ്. രണ്ടിൽ കൂടുതൽ ഡാറ്റ സ്റ്റോറുകൾ ഉപയോഗിച്ചാൽ പരിഹാരം കൂടുതൽ സങ്കീർണ്ണമാകും. അവസാനമായി, വീണ്ടെടുക്കൽ നടപടിക്രമം യഥാർത്ഥ ഡാറ്റ ഉറവിടത്തിലേക്ക് ലോഡ് ചേർക്കാൻ കഴിയും.

ലോഗ് ടേബിൾ മാറ്റുക

ഒരു കൂട്ടം പട്ടികകളിൽ മാറ്റങ്ങൾ സംഭവിക്കുമ്പോൾ (ഒരു റെക്കോർഡ് ചേർക്കൽ, അപ്‌ഡേറ്റ് ചെയ്യൽ, ഇല്ലാതാക്കൽ എന്നിവ പോലെ), മാറ്റ രേഖകൾ അതേ ഇടപാടിന്റെ ഭാഗമായി ലോഗ് ടേബിളിൽ ചേർക്കും. മറ്റൊരു ത്രെഡ് അല്ലെങ്കിൽ പ്രോസസ്സ് ലോഗ് ടേബിളിൽ നിന്ന് ഇവന്റുകൾ നിരന്തരം അഭ്യർത്ഥിക്കുകയും അവ ഒന്നോ അതിലധികമോ ഡാറ്റ സ്റ്റോറുകളിലേക്ക് എഴുതുകയും ചെയ്യുന്നു, ആവശ്യമെങ്കിൽ, എല്ലാ സ്റ്റോറുകളും റെക്കോർഡ് സ്ഥിരീകരിച്ചതിന് ശേഷം ലോഗ് ടേബിളിൽ നിന്ന് ഇവന്റുകൾ നീക്കം ചെയ്യുന്നു.

പ്രശ്നങ്ങൾ:

ഈ പാറ്റേൺ ഒരു ലൈബ്രറിയായി നടപ്പിലാക്കണം, അത് ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷന്റെ കോഡ് മാറ്റാതെ തന്നെ. ഒരു പോളിഗ്ലോട്ട് പരിതസ്ഥിതിയിൽ, അത്തരം ഒരു ലൈബ്രറി നടപ്പിലാക്കുന്നത് ആവശ്യമായ ഏത് ഭാഷയിലും നിലനിൽക്കണം, എന്നാൽ ഭാഷകളിലുടനീളം പ്രവർത്തനത്തിന്റെയും പെരുമാറ്റത്തിന്റെയും സ്ഥിരത ഉറപ്പാക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

MySQL പോലുള്ള ട്രാൻസാഷണൽ സ്കീമ മാറ്റങ്ങളെ [1][2] പിന്തുണയ്ക്കാത്ത സിസ്റ്റങ്ങളിൽ സ്കീമ മാറ്റങ്ങൾ നേടുന്നതിലാണ് മറ്റൊരു പ്രശ്നം. അതിനാൽ, ഒരു മാറ്റം വരുത്തുന്നതിനുള്ള പാറ്റേൺ (ഉദാഹരണത്തിന്, ഒരു സ്കീമ മാറ്റം) കൂടാതെ അത് മാറ്റ ലോഗ് ടേബിളിൽ ഇടപാട് റെക്കോർഡ് ചെയ്യുന്നത് എല്ലായ്പ്പോഴും പ്രവർത്തിക്കില്ല.

വിതരണം ചെയ്ത ഇടപാടുകൾ

ഒന്നിലധികം വൈവിധ്യമാർന്ന ഡാറ്റ സ്റ്റോറുകളിലുടനീളം ഒരു ഇടപാടിനെ വിഭജിക്കാൻ വിതരണ ഇടപാടുകൾ ഉപയോഗിക്കാനാകും, അതിലൂടെ പ്രവർത്തനം ഒന്നുകിൽ ഉപയോഗിച്ച എല്ലാ ഡാറ്റ സ്റ്റോറുകളോടും പ്രതിജ്ഞാബദ്ധമാണ്, അല്ലെങ്കിൽ അവയിലൊന്നിനും പ്രതിജ്ഞാബദ്ധമല്ല.

പ്രശ്നങ്ങൾ:

വൈവിധ്യമാർന്ന ഡാറ്റ സ്റ്റോറുകൾക്ക് വിതരണം ചെയ്ത ഇടപാടുകൾ വളരെ വലിയ പ്രശ്നമാണ്. അവരുടെ സ്വഭാവമനുസരിച്ച്, ഉൾപ്പെട്ടിരിക്കുന്ന സിസ്റ്റങ്ങളുടെ ഏറ്റവും താഴ്ന്ന പൊതു വിഭാഗത്തെ മാത്രമേ അവർക്ക് ആശ്രയിക്കാൻ കഴിയൂ. ഉദാഹരണത്തിന്, തയ്യാറെടുപ്പ് ഘട്ടത്തിൽ ആപ്ലിക്കേഷൻ പ്രക്രിയ പരാജയപ്പെടുകയാണെങ്കിൽ XA ഇടപാടുകൾ നിർവ്വഹണം തടയുന്നു. കൂടാതെ, XA ഡെഡ്‌ലോക്ക് കണ്ടെത്തൽ നൽകുന്നില്ല അല്ലെങ്കിൽ ശുഭാപ്തിവിശ്വാസമുള്ള കൺകറൻസി കൺട്രോൾ സ്കീമുകളെ പിന്തുണയ്ക്കുന്നില്ല. കൂടാതെ, ElasticSearch പോലുള്ള ചില സിസ്റ്റങ്ങൾ XA അല്ലെങ്കിൽ മറ്റേതെങ്കിലും വൈവിധ്യമാർന്ന ഇടപാട് മോഡലിനെ പിന്തുണയ്ക്കുന്നില്ല. അങ്ങനെ, വിവിധ ഡാറ്റാ സ്റ്റോറേജ് ടെക്നോളജികളിൽ റൈറ്റ് ആറ്റോമിസിറ്റി ഉറപ്പാക്കുന്നത് ആപ്ലിക്കേഷനുകൾക്ക് വളരെ വെല്ലുവിളി നിറഞ്ഞ ഒരു ജോലിയായി തുടരുന്നു [3].

ഡെൽറ്റ

നിലവിലുള്ള ഡാറ്റാ സിൻക്രൊണൈസേഷൻ സൊല്യൂഷനുകളുടെ പരിമിതികൾ പരിഹരിക്കുന്നതിനാണ് ഡെൽറ്റ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത്. ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാരിൽ നിന്ന് ഈ സങ്കീർണ്ണതകളെല്ലാം ഒഴിവാക്കുക എന്നതായിരുന്നു ഞങ്ങളുടെ ലക്ഷ്യം, അതുവഴി അവർക്ക് ബിസിനസ്സ് പ്രവർത്തനക്ഷമത നടപ്പിലാക്കുന്നതിൽ പൂർണ്ണമായി ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും. Netflix-ന്റെ ഡെൽറ്റയുടെ യഥാർത്ഥ ഉപയോഗ കേസായ "മൂവി തിരയൽ" ഞങ്ങൾ അടുത്തതായി വിവരിക്കും.

നെറ്റ്ഫ്ലിക്സ് ഒരു മൈക്രോസർവീസ് ആർക്കിടെക്ചർ വ്യാപകമായി ഉപയോഗിക്കുന്നു, ഓരോ മൈക്രോസർവീസും സാധാരണയായി ഒരു തരം ഡാറ്റ നൽകുന്നു. സിനിമയെക്കുറിച്ചുള്ള അടിസ്ഥാന വിവരങ്ങൾ മൂവി സർവീസ് എന്ന മൈക്രോസർവീസിൽ അടങ്ങിയിരിക്കുന്നു, കൂടാതെ നിർമ്മാതാക്കൾ, അഭിനേതാക്കൾ, വെണ്ടർമാർ എന്നിവയെക്കുറിച്ചുള്ള വിവരങ്ങൾ പോലെയുള്ള അനുബന്ധ ഡാറ്റ മറ്റ് നിരവധി മൈക്രോ സർവീസുകൾ (ഡീൽ സർവീസ്, ടാലന്റ് സർവീസ്, വെണ്ടർ സർവീസ്) നിയന്ത്രിക്കുന്നു.
നെറ്റ്ഫ്ലിക്സ് സ്റ്റുഡിയോയിലെ ബിസിനസ്സ് ഉപയോക്താക്കൾക്ക് പലപ്പോഴും വിവിധ മൂവി മാനദണ്ഡങ്ങളിൽ തിരയേണ്ടതുണ്ട്, അതിനാലാണ് സിനിമയുമായി ബന്ധപ്പെട്ട എല്ലാ ഡാറ്റയിലും തിരയുന്നത് അവർക്ക് വളരെ പ്രധാനമായത്.

ഡെൽറ്റയ്ക്ക് മുമ്പ്, മൂവി ഡാറ്റ ഇൻഡെക്‌സ് ചെയ്യുന്നതിന് മുമ്പ് മൂവി തിരയൽ ടീമിന് ഒന്നിലധികം മൈക്രോസർവീസുകളിൽ നിന്ന് ഡാറ്റ പിൻവലിക്കേണ്ടതുണ്ട്. കൂടാതെ, മാറ്റങ്ങളൊന്നും ഇല്ലെങ്കിലും, മറ്റ് മൈക്രോസർവീസുകളിൽ നിന്ന് മാറ്റങ്ങൾ അഭ്യർത്ഥിച്ച് തിരയൽ സൂചിക കാലാനുസൃതമായി അപ്‌ഡേറ്റ് ചെയ്യുന്ന ഒരു സിസ്റ്റം ടീമിന് വികസിപ്പിക്കേണ്ടതുണ്ട്. ഈ സംവിധാനം വളരെ വേഗം സങ്കീർണ്ണവും പരിപാലിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമായി മാറി.

ചിത്രം 1. ഡെൽറ്റയിലേക്കുള്ള പോളിംഗ് സംവിധാനം
ഡെൽറ്റ ഉപയോഗിച്ചതിന് ശേഷം, ഇനിപ്പറയുന്ന ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നതുപോലെ സിസ്റ്റം ഒരു ഇവന്റ് ഡ്രൈവൺ സിസ്റ്റത്തിലേക്ക് ലളിതമാക്കി. സിഡിസി (മാറ്റം-ഡാറ്റ-ക്യാപ്‌ചർ) ഇവന്റുകൾ ഡെൽറ്റ-കണക്ടർ ഉപയോഗിച്ച് കീസ്റ്റോൺ കാഫ്ക വിഷയങ്ങളിലേക്ക് അയയ്ക്കുന്നു. ഡെൽറ്റ സ്ട്രീം പ്രോസസ്സിംഗ് ഫ്രെയിംവർക്ക് (ഫ്ലിങ്കിനെ അടിസ്ഥാനമാക്കി) ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരു ഡെൽറ്റ ആപ്ലിക്കേഷൻ ഒരു വിഷയത്തിൽ നിന്ന് CDC ഇവന്റുകൾ സ്വീകരിക്കുന്നു, മറ്റ് മൈക്രോസർവീസുകളെ വിളിച്ച് അവയെ സമ്പന്നമാക്കുന്നു, ഒടുവിൽ ഇലാസ്റ്റിക് സെർച്ചിലെ ഒരു തിരയൽ സൂചികയിലേക്ക് സമ്പുഷ്ടമായ ഡാറ്റ കൈമാറുന്നു. മുഴുവൻ പ്രക്രിയയും ഏതാണ്ട് തത്സമയം നടക്കുന്നു, അതായത്, ഡാറ്റ വെയർഹൗസിൽ മാറ്റങ്ങൾ വരുത്തിയാലുടൻ, തിരയൽ സൂചികകൾ അപ്ഡേറ്റ് ചെയ്യപ്പെടും.

ചിത്രം 2. ഡെൽറ്റ ഉപയോഗിക്കുന്ന ഡാറ്റ പൈപ്പ്ലൈൻ
ഇനിപ്പറയുന്ന വിഭാഗങ്ങളിൽ, ഡെൽറ്റ-കണക്‌ടറിന്റെ പ്രവർത്തനത്തെ ഞങ്ങൾ വിവരിക്കും, അത് സംഭരണവുമായി ബന്ധിപ്പിക്കുകയും സിഡിസി ഇവന്റുകൾ ട്രാൻസ്‌പോർട്ട് ലെയറിലേക്ക് പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്നു, ഇത് സിഡിസി ഇവന്റുകൾ കാഫ്ക വിഷയങ്ങളിലേക്ക് നയിക്കുന്ന തത്സമയ ഡാറ്റാ ട്രാൻസ്മിഷൻ ഇൻഫ്രാസ്ട്രക്ചറാണ്. അവസാനം, ഞങ്ങൾ ഡെൽറ്റ സ്ട്രീം പ്രോസസ്സിംഗ് ചട്ടക്കൂടിനെക്കുറിച്ച് സംസാരിക്കും, ഡാറ്റ പ്രോസസ്സിംഗിനും സമ്പുഷ്ടീകരണ ലോജിക്കിനും ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാർക്ക് ഉപയോഗിക്കാൻ കഴിയും.

CDC (മാറ്റം-ഡാറ്റ-ക്യാപ്ചർ)

ഞങ്ങൾ Delta-Connector എന്ന പേരിൽ ഒരു CDC സേവനം വികസിപ്പിച്ചിട്ടുണ്ട്, അതിന് ഡാറ്റ സ്റ്റോറിൽ നിന്ന് തത്സമയം വരുത്തിയ മാറ്റങ്ങൾ ക്യാപ്‌ചർ ചെയ്യാനും അവ ഒരു സ്ട്രീമിലേക്ക് എഴുതാനും കഴിയും. ഇടപാട് ലോഗിൽ നിന്നും സ്റ്റോറേജ് ഡമ്പുകളിൽ നിന്നും തത്സമയ മാറ്റങ്ങൾ എടുക്കുന്നു. ഇടപാട് ലോഗുകൾ സാധാരണയായി മാറ്റങ്ങളുടെ മുഴുവൻ ചരിത്രവും സംഭരിക്കുന്നില്ല എന്നതിനാൽ ഡംപുകൾ ഉപയോഗിക്കുന്നു. മാറ്റങ്ങൾ സാധാരണയായി ഡെൽറ്റ ഇവന്റുകളായാണ് സീരിയലൈസ് ചെയ്യുന്നത്, അതിനാൽ മാറ്റം എവിടെ നിന്ന് വരുന്നു എന്നതിനെക്കുറിച്ച് സ്വീകർത്താവ് വിഷമിക്കേണ്ടതില്ല.

ഡെൽറ്റ-കണക്റ്റർ ഇനിപ്പറയുന്നതുപോലുള്ള നിരവധി അധിക സവിശേഷതകളെ പിന്തുണയ്ക്കുന്നു:

• കാഫ്ക കഴിഞ്ഞ ഇഷ്‌ടാനുസൃത ഔട്ട്‌പുട്ട് ഡാറ്റ എഴുതാനുള്ള കഴിവ്.
• എല്ലാ ടേബിളുകൾക്കും ഒരു നിർദ്ദിഷ്‌ട പട്ടികയ്‌ക്കും അല്ലെങ്കിൽ പ്രത്യേക പ്രാഥമിക കീകൾക്കുമായി എപ്പോൾ വേണമെങ്കിലും മാനുവൽ ഡംപുകൾ സജീവമാക്കാനുള്ള കഴിവ്.
• ഡമ്പുകൾ കഷണങ്ങളായി തിരിച്ചെടുക്കാൻ കഴിയും, അതിനാൽ പരാജയപ്പെടുമ്പോൾ വീണ്ടും ആരംഭിക്കേണ്ട ആവശ്യമില്ല.
• പട്ടികകളിൽ ലോക്കുകൾ സ്ഥാപിക്കേണ്ട ആവശ്യമില്ല, ഡാറ്റാബേസ് റൈറ്റ് ട്രാഫിക് ഞങ്ങളുടെ സേവനം ഒരിക്കലും തടയുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ ഇത് വളരെ പ്രധാനമാണ്.
• AWS ലഭ്യത സോണുകളിലെ അനാവശ്യ സംഭവങ്ങൾ കാരണം ഉയർന്ന ലഭ്യത.

AWS RDS, Aurora എന്നിവയിലെ വിന്യാസങ്ങൾ ഉൾപ്പെടെ ഞങ്ങൾ നിലവിൽ MySQL, Postgres എന്നിവയെ പിന്തുണയ്ക്കുന്നു. ഞങ്ങൾ കസാന്ദ്രയെയും (മൾട്ടി-മാസ്റ്റർ) പിന്തുണയ്ക്കുന്നു. Delta-Connector-നെ കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ നിങ്ങൾക്ക് ഇവിടെ കണ്ടെത്താം ബ്ലോഗ് പോസ്റ്റ്.

കാഫ്കയും ഗതാഗത പാളിയും

പ്ലാറ്റ്‌ഫോമിന്റെ സന്ദേശമയയ്‌ക്കൽ സേവനത്തിലാണ് ഡെൽറ്റയുടെ ഇവന്റ് ട്രാൻസ്‌പോർട്ട് ലെയർ നിർമ്മിച്ചിരിക്കുന്നത് കെയ്സ്തൊനെ.

ചരിത്രപരമായി, Netflix-ൽ പോസ്റ്റുചെയ്യുന്നത് ദീർഘായുസ്സിനേക്കാൾ പ്രവേശനക്ഷമതയ്ക്കായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു (ചുവടെ കാണുക). മുൻ ലേഖനം). വ്യത്യസ്‌ത സാഹചര്യങ്ങളിലെ ബ്രോക്കർ ഡാറ്റ പൊരുത്തക്കേടാണ് ട്രേഡ്-ഓഫ്. ഉദാഹരണത്തിന്, അശുദ്ധനായ നേതാവ് തിരഞ്ഞെടുപ്പ് ഡ്യൂപ്ലിക്കേറ്റ് അല്ലെങ്കിൽ നഷ്‌ടമായ ഇവന്റുകൾ ഉണ്ടാകാൻ സാധ്യതയുള്ള സ്വീകർത്താവിന് ഉത്തരവാദിയാണ്.

ഡെൽറ്റയ്‌ക്കൊപ്പം, സി‌ഡി‌സി ഇവന്റുകൾ ഡെറിവേഡ് സ്‌റ്റോറുകളിലേക്ക് ഡെലിവറി ചെയ്യുന്നത് ഉറപ്പാക്കുന്നതിന് ശക്തമായ ഡ്യൂറബിലിറ്റി ഗ്യാരണ്ടികൾ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഈ ആവശ്യത്തിനായി, ഞങ്ങൾ ഒരു ഫസ്റ്റ് ക്ലാസ് ഒബ്ജക്റ്റായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത കാഫ്ക ക്ലസ്റ്റർ നിർദ്ദേശിച്ചു. ചുവടെയുള്ള പട്ടികയിൽ നിങ്ങൾക്ക് ചില ബ്രോക്കർ ക്രമീകരണങ്ങൾ നോക്കാം:

കീസ്റ്റോൺ കാഫ്ക ക്ലസ്റ്ററുകളിൽ, അശുദ്ധനായ നേതാവ് തിരഞ്ഞെടുപ്പ് പ്രസാധകരുടെ പ്രവേശനക്ഷമത ഉറപ്പാക്കാൻ സാധാരണയായി ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. സമന്വയിപ്പിക്കാത്ത ഒരു പകർപ്പ് നേതാവായി തിരഞ്ഞെടുക്കപ്പെട്ടാൽ, ഇത് സന്ദേശം നഷ്‌ടമാകാനിടയുണ്ട്. പുതിയ ഉയർന്ന ലഭ്യതയുള്ള കാഫ്ക ക്ലസ്റ്ററിനായി, ഓപ്ഷൻ അശുദ്ധനായ നേതാവ് തിരഞ്ഞെടുപ്പ് സന്ദേശം നഷ്ടപ്പെടുന്നത് തടയാൻ ഓഫാക്കി.

ഞങ്ങളും വർദ്ധിച്ചു അനുകരണ ഘടകം 2 മുതൽ 3 വരെ ഒപ്പം ഏറ്റവും കുറഞ്ഞ ഇൻസിങ്ക് പകർപ്പുകൾ 1 മുതൽ 2 വരെ. ഈ ക്ലസ്റ്ററിലേക്ക് എഴുതുന്ന പ്രസാധകർക്ക് മറ്റെല്ലാവരിൽ നിന്നും അക്കുകൾ ആവശ്യമാണ്, 2-ൽ 3 പകർപ്പുകൾക്കും പ്രസാധകർ അയച്ച ഏറ്റവും പുതിയ സന്ദേശങ്ങൾ ഉണ്ടെന്ന് ഉറപ്പാക്കുന്നു.

ഒരു ബ്രോക്കർ ഇൻസ്‌റ്റൻസ് അവസാനിക്കുമ്പോൾ, പഴയതിന് പകരം പുതിയൊരു സംഭവം വരുന്നു. എന്നിരുന്നാലും, പുതിയ ബ്രോക്കർക്ക് സമന്വയിപ്പിക്കാത്ത പകർപ്പുകൾ കണ്ടെത്തേണ്ടതുണ്ട്, ഇതിന് നിരവധി മണിക്കൂറുകൾ എടുത്തേക്കാം. ഈ സാഹചര്യത്തിൽ വീണ്ടെടുക്കൽ സമയം കുറയ്ക്കുന്നതിന്, ലോക്കൽ ബ്രോക്കർ ഡിസ്കുകൾക്ക് പകരം ഞങ്ങൾ ബ്ലോക്ക് ഡാറ്റ സ്റ്റോറേജ് (ആമസോൺ ഇലാസ്റ്റിക് ബ്ലോക്ക് സ്റ്റോർ) ഉപയോഗിക്കാൻ തുടങ്ങി. ഒരു ടെർമിനേറ്റഡ് ബ്രോക്കർ ഇൻസ്‌റ്റൻസ് മാറ്റിസ്ഥാപിക്കുമ്പോൾ, അത് അവസാനിപ്പിച്ച സംഭവത്തിന് ഉണ്ടായിരുന്ന EBS വോളിയം അറ്റാച്ചുചെയ്യുകയും പുതിയ സന്ദേശങ്ങൾ ലഭിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ഈ പ്രക്രിയ ബാക്ക്‌ലോഗ് ക്ലിയറൻസ് സമയം മണിക്കൂറുകളിൽ നിന്ന് മിനിറ്റുകളായി കുറയ്ക്കുന്നു, കാരണം പുതിയ സംഭവത്തിന് ശൂന്യമായ അവസ്ഥയിൽ നിന്ന് ആവർത്തിക്കേണ്ടതില്ല. മൊത്തത്തിൽ, പ്രത്യേക സംഭരണവും ബ്രോക്കർ ജീവിതചക്രങ്ങളും ബ്രോക്കർ സ്വിച്ചിംഗിന്റെ ആഘാതം ഗണ്യമായി കുറയ്ക്കുന്നു.

ഡാറ്റ ഡെലിവറി ഗ്യാരണ്ടി കൂടുതൽ വർദ്ധിപ്പിക്കുന്നതിന്, ഞങ്ങൾ ഉപയോഗിച്ചു സന്ദേശ ട്രാക്കിംഗ് സിസ്റ്റം അങ്ങേയറ്റത്തെ സാഹചര്യങ്ങളിൽ എന്തെങ്കിലും സന്ദേശ നഷ്ടം കണ്ടെത്തുന്നതിന് (ഉദാഹരണത്തിന്, പാർട്ടീഷൻ ലീഡറിലെ ക്ലോക്ക് ഡീസിൻക്രൊണൈസേഷൻ).

സ്ട്രീം പ്രോസസ്സിംഗ് ഫ്രെയിംവർക്ക്

ഡെൽറ്റയുടെ പ്രോസസ്സിംഗ് ലെയർ നിർമ്മിച്ചിരിക്കുന്നത് Netflix SPaaS പ്ലാറ്റ്‌ഫോമിന് മുകളിലാണ്, ഇത് Netflix ഇക്കോസിസ്റ്റവുമായി Apache Flink സംയോജനം നൽകുന്നു. ഞങ്ങളുടെ ടൈറ്റസ് കണ്ടെയ്‌നർ മാനേജ്‌മെന്റ് പ്ലാറ്റ്‌ഫോമിന് മുകളിൽ ഫ്ലിങ്ക് ജോലികളുടെ വിന്യാസവും ഫ്ലിങ്ക് ക്ലസ്റ്ററുകളുടെ ഓർക്കസ്‌ട്രേഷനും നിയന്ത്രിക്കുന്ന ഒരു ഉപയോക്തൃ ഇന്റർഫേസ് പ്ലാറ്റ്‌ഫോം നൽകുന്നു. ഇന്റർഫേസ് ജോബ് കോൺഫിഗറേഷനുകൾ നിയന്ത്രിക്കുകയും ഫ്ലിങ്ക് ജോലികൾ വീണ്ടും കംപൈൽ ചെയ്യാതെ തന്നെ ചലനാത്മകമായി കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ വരുത്താൻ ഉപയോക്താക്കളെ അനുവദിക്കുകയും ചെയ്യുന്നു.

Flink, SPaaS എന്നിവയെ അടിസ്ഥാനമാക്കി ഡെൽറ്റ ഒരു സ്ട്രീം പ്രോസസ്സിംഗ് ചട്ടക്കൂട് നൽകുന്നു വ്യാഖ്യാനത്തെ അടിസ്ഥാനമാക്കിയുള്ളത് സാങ്കേതിക വിശദാംശങ്ങൾ സംഗ്രഹിക്കാൻ DSL (ഡൊമെയ്ൻ സ്പെസിഫിക് ലാംഗ്വേജ്). ഉദാഹരണത്തിന്, ബാഹ്യ സേവനങ്ങളെ വിളിച്ച് ഇവന്റുകൾ സമ്പന്നമാക്കുന്ന ഘട്ടം നിർവചിക്കുന്നതിന്, ഉപയോക്താക്കൾ ഇനിപ്പറയുന്ന DSL എഴുതേണ്ടതുണ്ട്, കൂടാതെ ഫ്രെയിംവർക്ക് അതിനെ അടിസ്ഥാനമാക്കി ഒരു മോഡൽ സൃഷ്ടിക്കും, അത് Flink നടപ്പിലാക്കും.

ചിത്രം 3. ഡെൽറ്റയിലെ DSL-ലെ സമ്പുഷ്ടീകരണത്തിന്റെ ഉദാഹരണം

പ്രോസസ്സിംഗ് ചട്ടക്കൂട് പഠന വക്രത കുറയ്ക്കുക മാത്രമല്ല, സാധാരണ പ്രവർത്തന പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഡ്യൂപ്ലിക്കേഷൻ, സ്കീമാറ്റൈസേഷൻ, ഫ്ലെക്സിബിലിറ്റി, റെസിലൻസി എന്നിവ പോലുള്ള പൊതുവായ സ്ട്രീം പ്രോസസ്സിംഗ് സവിശേഷതകളും നൽകുന്നു.

DSL & API മൊഡ്യൂൾ, റൺടൈം മൊഡ്യൂൾ എന്നിങ്ങനെ രണ്ട് പ്രധാന മൊഡ്യൂളുകൾ ഡെൽറ്റ സ്ട്രീം പ്രോസസ്സിംഗ് ഫ്രെയിംവർക്കിൽ അടങ്ങിയിരിക്കുന്നു. DSL & API മൊഡ്യൂൾ DSL, UDF (User-Defined-Function) API-കൾ നൽകുന്നു, അതുവഴി ഉപയോക്താക്കൾക്ക് അവരുടേതായ പ്രോസസ്സിംഗ് ലോജിക് (ഫിൽട്ടറിംഗ് അല്ലെങ്കിൽ പരിവർത്തനങ്ങൾ പോലുള്ളവ) എഴുതാൻ കഴിയും. റൺടൈം മൊഡ്യൂൾ ഒരു DSL പാഴ്‌സറിന്റെ ഒരു നിർവ്വഹണം നൽകുന്നു, അത് DAG മോഡലുകളിൽ പ്രോസസ്സിംഗ് ഘട്ടങ്ങളുടെ ആന്തരിക പ്രാതിനിധ്യം നിർമ്മിക്കുന്നു. യഥാർത്ഥ ഫ്ലിങ്ക് പ്രസ്താവനകൾ ആരംഭിക്കുന്നതിനും ആത്യന്തികമായി ഫ്ലിങ്ക് ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്നതിനും എക്സിക്യൂഷൻ ഘടകം DAG മോഡലുകളെ വ്യാഖ്യാനിക്കുന്നു. ചട്ടക്കൂടിന്റെ വാസ്തുവിദ്യ ഇനിപ്പറയുന്ന ചിത്രത്തിൽ ചിത്രീകരിച്ചിരിക്കുന്നു.

ചിത്രം 4. ഡെൽറ്റ സ്ട്രീം പ്രോസസ്സിംഗ് ഫ്രെയിംവർക്ക് ആർക്കിടെക്ചർ

ഈ സമീപനത്തിന് നിരവധി ഗുണങ്ങളുണ്ട്:

• ഫ്ലിങ്കിന്റെയോ SPaaS ഘടനയുടെയോ പ്രത്യേകതകൾ പരിശോധിക്കാതെ തന്നെ ഉപയോക്താക്കൾക്ക് അവരുടെ ബിസിനസ്സ് യുക്തിയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും.
• ഉപയോക്താക്കൾക്ക് സുതാര്യമായ രീതിയിൽ ഒപ്റ്റിമൈസേഷൻ ചെയ്യാൻ കഴിയും, കൂടാതെ യൂസർ കോഡിൽ (യുഡിഎഫ്) മാറ്റങ്ങളൊന്നും ആവശ്യമില്ലാതെ തന്നെ പിശകുകൾ പരിഹരിക്കാനാകും.
• ഡെൽറ്റ ആപ്ലിക്കേഷൻ അനുഭവം ഉപയോക്താക്കൾക്കായി ലളിതമാക്കിയിരിക്കുന്നു, കാരണം പ്ലാറ്റ്‌ഫോം ബോക്‌സിന് പുറത്ത് വഴക്കവും പ്രതിരോധശേഷിയും പ്രദാനം ചെയ്യുകയും അലേർട്ടുകൾക്കായി ഉപയോഗിക്കാവുന്ന വിവിധ വിശദമായ മെട്രിക്‌സ് ശേഖരിക്കുകയും ചെയ്യുന്നു.

ഉൽപാദന ഉപയോഗം

ഡെൽറ്റ ഒരു വർഷത്തിലേറെയായി നിർമ്മാണത്തിലാണ്, കൂടാതെ നിരവധി നെറ്റ്ഫ്ലിക്സ് സ്റ്റുഡിയോ ആപ്ലിക്കേഷനുകളിൽ ഒരു പ്രധാന പങ്ക് വഹിക്കുന്നു. സെർച്ച് ഇൻഡക്‌സിംഗ്, ഡാറ്റ സ്‌റ്റോറേജ്, ഇവന്റ്-ഡ്രൈവ് വർക്ക്ഫ്ലോകൾ എന്നിവ പോലുള്ള ഉപയോഗ കേസുകൾ നടപ്പിലാക്കാൻ ടീമുകളെ അവൾ സഹായിച്ചു. ഡെൽറ്റ പ്ലാറ്റ്‌ഫോമിന്റെ ഉയർന്ന തലത്തിലുള്ള വാസ്തുവിദ്യയുടെ ഒരു അവലോകനം ചുവടെയുണ്ട്.

ചിത്രം 5. ഡെൽറ്റയുടെ ഉയർന്ന തലത്തിലുള്ള വാസ്തുവിദ്യ.

അംഗീകാരങ്ങൾ

Netflix-ൽ ഡെൽറ്റയുടെ നിർമ്മാണത്തിലും വികസനത്തിലും ഏർപ്പെട്ടിരിക്കുന്ന ഇനിപ്പറയുന്ന ആളുകൾക്ക് ഞങ്ങൾ നന്ദി പറയുന്നു: അലൻ വാങ്, ചാൾസ് ഷാവോ, ജെയ്ബിൻ യൂൻ, ജോഷ് സ്നൈഡർ, കസ്തൂരി ചാറ്റർജി, മാർക്ക് ചോ, ഒലോഫ് ജോഹാൻസൺ, പിയൂഷ് ഗോയൽ, പ്രശാന്ത് രാംദാസ്, രഘുറാം ഒന്റി ശ്രീനിവാസൻ, സന്ദീപ് ഗുപ്ത, സ്റ്റീവൻ വു, തരംഗ ഗമേത്തിഗെ, യുൻ വാങ്, ഷെൻഷോങ് സൂ.

ഉറവിടങ്ങൾ

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. മാർട്ടിൻ ക്ലെപ്‌മാൻ, അലിസ്റ്റർ ആർ. ബെറെസ്‌ഫോർഡ്, ബോർജ് സ്വിംഗൻ: ഓൺലൈൻ ഇവന്റ് പ്രോസസ്സിംഗ്. കമ്മ്യൂൺ. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

ഒരു സൗജന്യ വെബിനാറിനായി സൈൻ അപ്പ് ചെയ്യുക: "ആമസോൺ റെഡ്ഷിഫ്റ്റ് സ്റ്റോറേജിനുള്ള ഡാറ്റ ബിൽഡ് ടൂൾ."

അവലംബം: www.habr.com