ഓപ്പൺ സോഴ്സ് ഡാറ്റാഹബ്: ലിങ്ക്ഡ്ഇന്നിന്റെ മെറ്റാഡാറ്റ സെർച്ചും ഡിസ്കവറി പ്ലാറ്റ്ഫോമും

ഓപ്പൺ സോഴ്സ് ഡാറ്റാഹബ്: ലിങ്ക്ഡ്ഇന്നിന്റെ മെറ്റാഡാറ്റ സെർച്ചും ഡിസ്കവറി പ്ലാറ്റ്ഫോമും

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

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

ഹൗസ് ഇപ്പോൾ ഒരു ഡാറ്റാഹബ് ആണ്!

ലിങ്ക്ഡ്ഇന്നിന്റെ മെറ്റാഡാറ്റ ടീം മുമ്പ് അവതരിപ്പിച്ചു ഡാറ്റാഹബ് (WhereHows-ന്റെ പിൻഗാമി), LinkedIn-ന്റെ സെർച്ച്, മെറ്റാഡാറ്റ ഡിസ്കവറി പ്ലാറ്റ്ഫോം, അത് തുറക്കാനുള്ള പദ്ധതികൾ പങ്കിട്ടു. ഈ പ്രഖ്യാപനത്തിന് തൊട്ടുപിന്നാലെ, ഞങ്ങൾ DataHub-ന്റെ ഒരു ആൽഫ പതിപ്പ് പുറത്തിറക്കുകയും അത് കമ്മ്യൂണിറ്റിയുമായി പങ്കിടുകയും ചെയ്തു. അതിനുശേഷം, ഞങ്ങൾ തുടർച്ചയായി റിപ്പോസിറ്ററിയിലേക്ക് സംഭാവന ചെയ്യുകയും താൽപ്പര്യമുള്ള ഉപയോക്താക്കളുമായി ഏറ്റവും കൂടുതൽ അഭ്യർത്ഥിച്ച സവിശേഷതകൾ ചേർക്കുകയും പ്രശ്നങ്ങൾ പരിഹരിക്കുകയും ചെയ്യുന്നു. ഔദ്യോഗിക റിലീസ് പ്രഖ്യാപിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട് GitHub-ലെ DataHub.

ഓപ്പൺ സോഴ്സ് സമീപനങ്ങൾ

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

ആദ്യം ശ്രമിക്കുക: "ആദ്യം സോഴ്‌സ് തുറക്കുക"

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

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

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

രണ്ടാമത്തെ ശ്രമം: "ആദ്യം ആന്തരികം"

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

മൂന്നാം തവണ അത് പ്രവർത്തിച്ചു!

മുകളിൽ സൂചിപ്പിച്ച രണ്ട് പരാജയപ്പെട്ട ശ്രമങ്ങളുടെ ഫലമായി, WhereHows GitHub ശേഖരം വളരെക്കാലം കാലഹരണപ്പെട്ടു. ഉൽപ്പന്നത്തിന്റെ സവിശേഷതകളും ആർക്കിടെക്ചറും ടീം മെച്ചപ്പെടുത്തുന്നത് തുടർന്നു, അതിനാൽ ലിങ്ക്ഡ്ഇന്നിനായുള്ള WhereHows-ന്റെ ആന്തരിക പതിപ്പ് ഓപ്പൺ സോഴ്‌സ് പതിപ്പിനേക്കാൾ കൂടുതൽ വിപുലമായി. ഇതിന് ഒരു പുതിയ പേര് പോലും ഉണ്ടായിരുന്നു - DataHub. മുമ്പത്തെ പരാജയപ്പെട്ട ശ്രമങ്ങളെ അടിസ്ഥാനമാക്കി, സ്കെയിലബിൾ, ദീർഘകാല പരിഹാരം വികസിപ്പിക്കാൻ ടീം തീരുമാനിച്ചു.

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

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

ഓപ്പൺ സോഴ്സ് പബ്ലിഷിംഗ് ഓട്ടോമേഷൻ

മെറ്റാഡാറ്റ ടീമിന്റെ ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാഹബ്ബിലേക്കുള്ള ഏറ്റവും പുതിയ സമീപനം ആന്തരിക കോഡ്‌ബേസും ഓപ്പൺ സോഴ്‌സ് ശേഖരണവും യാന്ത്രികമായി സമന്വയിപ്പിക്കുന്ന ഒരു ടൂൾ വികസിപ്പിക്കുക എന്നതാണ്. ഈ ടൂൾകിറ്റിന്റെ ഉയർന്ന തലത്തിലുള്ള സവിശേഷതകൾ ഉൾപ്പെടുന്നു:

1. ലിങ്ക്ഡ്‌ഇൻ കോഡ് ഓപ്പൺ സോഴ്‌സിലേക്ക്/ഓപ്പൺ സോഴ്‌സിലേക്ക് സമന്വയിപ്പിക്കുക rsync.
2. ലൈസൻസ് ഹെഡർ ജനറേഷൻ, സമാനമായത് അപ്പാച്ചെ എലി.
3. ആന്തരിക കമ്മിറ്റ് ലോഗുകളിൽ നിന്ന് ഓപ്പൺ സോഴ്‌സ് കമ്മിറ്റ് ലോഗുകൾ സ്വയമേവ ജനറേറ്റുചെയ്യുക.
4. ഓപ്പൺ സോഴ്‌സ് ബിൽഡുകളെ തകർക്കുന്ന ആന്തരിക മാറ്റങ്ങൾ തടയുക ആശ്രിതത്വ പരിശോധന.

രസകരമായ പ്രശ്‌നങ്ങളുള്ള മുകളിൽ സൂചിപ്പിച്ച ഫംഗ്‌ഷനുകളിലേക്ക് ഇനിപ്പറയുന്ന ഉപവിഭാഗങ്ങൾ പരിശോധിക്കും.

സോഴ്സ് കോഡ് സിൻക്രൊണൈസേഷൻ

ഒരൊറ്റ GitHub ശേഖരണമായ DataHub-ന്റെ ഓപ്പൺ സോഴ്‌സ് പതിപ്പിൽ നിന്ന് വ്യത്യസ്തമായി, DataHub-ന്റെ LinkedIn പതിപ്പ് ഒന്നിലധികം ശേഖരണങ്ങളുടെ (ആന്തരികമായി വിളിക്കപ്പെടുന്ന) സംയോജനമാണ്. ഒന്നിലധികം ഉൽപ്പന്നങ്ങൾ). DataHub ഇന്റർഫേസ്, മെറ്റാഡാറ്റ മോഡൽ ലൈബ്രറി, മെറ്റാഡാറ്റ വെയർഹൗസ് ബാക്കെൻഡ് സേവനം, സ്ട്രീമിംഗ് ജോലികൾ എന്നിവ ലിങ്ക്ഡ്ഇനിലെ പ്രത്യേക ശേഖരണങ്ങളിൽ വസിക്കുന്നു. എന്നിരുന്നാലും, ഓപ്പൺ സോഴ്‌സ് ഉപയോക്താക്കൾക്ക് ഇത് എളുപ്പമാക്കുന്നതിന്, DataHub-ന്റെ ഓപ്പൺ സോഴ്‌സ് പതിപ്പിനായി ഞങ്ങൾക്ക് ഒരൊറ്റ ശേഖരം ഉണ്ട്.

ചിത്രം 1: റിപ്പോസിറ്ററികൾ തമ്മിലുള്ള സമന്വയം ലിങ്ക്ഡ് ഡാറ്റാഹബ് ഒപ്പം ഒരൊറ്റ സംഭരണിയും ഡാറ്റാഹബ് ഓപ്പൺ സോഴ്സ്

ഓട്ടോമേറ്റഡ് ബിൽഡ്, പുഷ്, പുൾ വർക്ക്ഫ്ലോകളെ പിന്തുണയ്ക്കുന്നതിന്, ഞങ്ങളുടെ പുതിയ ടൂൾ ഓരോ സോഴ്സ് ഫയലിനും അനുയോജ്യമായ ഒരു ഫയൽ-ലെവൽ മാപ്പിംഗ് സ്വയമേവ സൃഷ്ടിക്കുന്നു. എന്നിരുന്നാലും, ടൂൾകിറ്റിന് പ്രാരംഭ കോൺഫിഗറേഷൻ ആവശ്യമാണ് കൂടാതെ ഉപയോക്താക്കൾ താഴെ കാണിച്ചിരിക്കുന്നതുപോലെ ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂൾ മാപ്പിംഗ് നൽകണം.

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

മൊഡ്യൂൾ-ലെവൽ മാപ്പിംഗ് ഒരു ലളിതമായ JSON ആണ്, അതിന്റെ കീകൾ ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററിയിലെ ടാർഗെറ്റ് മൊഡ്യൂളുകളും മൂല്യങ്ങൾ ലിങ്ക്ഡ്ഇൻ ശേഖരണങ്ങളിലെ ഉറവിട മൊഡ്യൂളുകളുടെ പട്ടികയുമാണ്. ഒരു ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററിയിലെ ഏത് ടാർഗെറ്റ് മൊഡ്യൂളും എത്ര സോഴ്‌സ് മൊഡ്യൂളുകൾ വഴിയും നൽകാം. ഉറവിട മൊഡ്യൂളുകളിലെ റിപ്പോസിറ്ററികളുടെ ആന്തരിക നാമങ്ങൾ സൂചിപ്പിക്കാൻ, ഉപയോഗിക്കുക സ്ട്രിംഗ് ഇന്റർപോളേഷൻ ബാഷ് ശൈലിയിൽ. ഒരു മൊഡ്യൂൾ-ലെവൽ മാപ്പിംഗ് ഫയൽ ഉപയോഗിച്ച്, അനുബന്ധ ഡയറക്‌ടറികളിലെ എല്ലാ ഫയലുകളും സ്‌കാൻ ചെയ്‌ത് ടൂളുകൾ ഒരു ഫയൽ-ലെവൽ മാപ്പിംഗ് ഫയൽ സൃഷ്‌ടിക്കുന്നു.

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

ടൂളുകളാൽ ഫയൽ ലെവൽ മാപ്പിംഗ് സ്വയമേവ സൃഷ്ടിക്കപ്പെടുന്നു; എന്നിരുന്നാലും, ഇത് ഉപയോക്താവിന് സ്വമേധയാ അപ്ഡേറ്റ് ചെയ്യാനും കഴിയും. ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററിയിലെ ഒരു ഫയലിലേക്ക് ലിങ്ക്ഡ്ഇൻ സോഴ്‌സ് ഫയലിന്റെ 1:1 മാപ്പിംഗ് ആണിത്. ഫയൽ അസോസിയേഷനുകളുടെ ഈ സ്വയമേവ സൃഷ്ടിക്കുന്നതുമായി ബന്ധപ്പെട്ട നിരവധി നിയമങ്ങളുണ്ട്:

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

കമ്മിറ്റ് ലോഗുകൾ സൃഷ്ടിക്കുന്നു

ഓപ്പൺ സോഴ്‌സ് കമ്മിറ്റുകൾക്കായുള്ള കമ്മിറ്റ് ലോഗുകളും ഇന്റേണൽ റിപ്പോസിറ്ററികളുടെ കമ്മിറ്റ് ലോഗുകൾ ലയിപ്പിച്ച് സ്വയമേവ ജനറേറ്റുചെയ്യുന്നു. ഞങ്ങളുടെ ടൂൾ സൃഷ്‌ടിച്ച കമ്മിറ്റ് ലോഗിന്റെ ഘടന കാണിക്കുന്നതിനുള്ള ഒരു സാമ്പിൾ കമ്മിറ്റ് ലോഗ് ചുവടെയുണ്ട്. സോഴ്‌സ് റിപ്പോസിറ്ററികളുടെ ഏത് പതിപ്പുകളാണ് ആ കമ്മിറ്റിൽ പാക്കേജുചെയ്‌തിരിക്കുന്നതെന്ന് ഒരു കമ്മിറ്റ് വ്യക്തമായി സൂചിപ്പിക്കുകയും കമ്മിറ്റ് ലോഗിന്റെ ഒരു സംഗ്രഹം നൽകുകയും ചെയ്യുന്നു. ഇത് ഒന്ന് പരിശോധിക്കുക പ്രതിബദ്ധത ഞങ്ങളുടെ ടൂൾകിറ്റ് സൃഷ്ടിച്ച ഒരു കമ്മിറ്റ് ലോഗിന്റെ യഥാർത്ഥ ഉദാഹരണം ഉപയോഗിക്കുന്നു.

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

ആശ്രിതത്വ പരിശോധന

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

ഓപ്പൺ സോഴ്‌സ് ബിൽഡ് തകർക്കുകയും കമ്മിറ്റ് സമയത്ത് അത് കണ്ടെത്തുകയും ചെയ്യുന്ന ഏതെങ്കിലും ആന്തരിക പ്രതിബദ്ധത തടയാൻ സഹായിക്കുന്ന ഒരു ഉപയോഗപ്രദമായ സംവിധാനമാണിത്. ഇതില്ലാതെ, ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററി ബിൽഡ് പരാജയപ്പെടാൻ കാരണമായ ആന്തരിക പ്രതിബദ്ധത നിർണ്ണയിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, കാരണം ഞങ്ങൾ DataHub ഓപ്പൺ സോഴ്‌സ് ശേഖരണത്തിലേക്ക് ആന്തരിക മാറ്റങ്ങൾ ബാച്ച് ചെയ്യുന്നു.

ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാഹബും ഞങ്ങളുടെ പ്രൊഡക്ഷൻ പതിപ്പും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ

ഈ സമയം വരെ, DataHub ശേഖരണങ്ങളുടെ രണ്ട് പതിപ്പുകൾ സമന്വയിപ്പിക്കുന്നതിനുള്ള ഞങ്ങളുടെ പരിഹാരം ഞങ്ങൾ ചർച്ച ചെയ്തിട്ടുണ്ട്, എന്നാൽ ഞങ്ങൾക്ക് രണ്ട് വ്യത്യസ്ത വികസന സ്ട്രീമുകൾ ആവശ്യമായി വരുന്നതിന്റെ കാരണങ്ങൾ ഞങ്ങൾ ഇപ്പോഴും വിശദീകരിച്ചിട്ടില്ല. ഈ വിഭാഗത്തിൽ, DataHub-ന്റെ പൊതു പതിപ്പും LinkedIn സെർവറുകളിലെ പ്രൊഡക്ഷൻ പതിപ്പും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ ഞങ്ങൾ പട്ടികപ്പെടുത്തുകയും ഈ വ്യത്യാസങ്ങളുടെ കാരണങ്ങൾ വിശദീകരിക്കുകയും ചെയ്യും.

ഞങ്ങളുടെ പ്രൊഡക്ഷൻ പതിപ്പിന് ലിങ്ക്ഡ്ഇനിന്റെ ഓഫ്‌സ്പ്രിംഗ് (ലിങ്ക്ഡ്‌ഇന്നിന്റെ ഇന്റേണൽ ഡിപൻഡൻസി ഇൻജക്ഷൻ ഫ്രെയിംവർക്ക്) പോലെ ഇതുവരെ ഓപ്പൺ സോഴ്‌സ് അല്ലാത്ത കോഡുകളെ ആശ്രയിക്കുന്നു എന്ന വസ്തുതയിൽ നിന്നാണ് പൊരുത്തക്കേടിന്റെ ഒരു ഉറവിടം. ഡൈനാമിക് കോൺഫിഗറേഷൻ കൈകാര്യം ചെയ്യുന്നതിനുള്ള തിരഞ്ഞെടുക്കപ്പെട്ട രീതിയായതിനാൽ ആന്തരിക കോഡ്ബേസുകളിൽ സന്തതികൾ വ്യാപകമായി ഉപയോഗിക്കുന്നു. എന്നാൽ ഇത് ഓപ്പൺ സോഴ്‌സ് അല്ല; അതിനാൽ ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാഹബിന് ഓപ്പൺ സോഴ്‌സ് ബദലുകൾ കണ്ടെത്തേണ്ടതുണ്ട്.

വേറെയും കാരണങ്ങളുണ്ട്. LinkedIn-ന്റെ ആവശ്യങ്ങൾക്കായി ഞങ്ങൾ മെറ്റാഡാറ്റ മോഡലിലേക്ക് വിപുലീകരണങ്ങൾ സൃഷ്ടിക്കുമ്പോൾ, ഈ വിപുലീകരണങ്ങൾ സാധാരണയായി LinkedIn-ന് വളരെ പ്രത്യേകമാണ്, മറ്റ് പരിതസ്ഥിതികളിൽ നേരിട്ട് ബാധകമായേക്കില്ല. ഉദാഹരണത്തിന്, പങ്കാളി ഐഡികൾക്കും മറ്റ് തരത്തിലുള്ള പൊരുത്തപ്പെടുന്ന മെറ്റാഡാറ്റയ്‌ക്കുമായി ഞങ്ങൾക്ക് വളരെ നിർദ്ദിഷ്ട ലേബലുകൾ ഉണ്ട്. അതിനാൽ, DataHub-ന്റെ ഓപ്പൺ സോഴ്‌സ് മെറ്റാഡാറ്റ മോഡലിൽ നിന്ന് ഞങ്ങൾ ഈ വിപുലീകരണങ്ങളെ ഇപ്പോൾ ഒഴിവാക്കിയിരിക്കുന്നു. ഞങ്ങൾ കമ്മ്യൂണിറ്റിയുമായി ഇടപഴകുകയും അവരുടെ ആവശ്യങ്ങൾ മനസ്സിലാക്കുകയും ചെയ്യുമ്പോൾ, ആവശ്യമുള്ളിടത്ത് ഈ വിപുലീകരണങ്ങളുടെ പൊതുവായ ഓപ്പൺ സോഴ്‌സ് പതിപ്പുകളിൽ ഞങ്ങൾ പ്രവർത്തിക്കും.

ഉപയോഗിക്കാനുള്ള എളുപ്പവും ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റിക്ക് എളുപ്പത്തിൽ പൊരുത്തപ്പെടുത്തലും DataHub-ന്റെ രണ്ട് പതിപ്പുകൾ തമ്മിലുള്ള ചില വ്യത്യാസങ്ങൾക്ക് പ്രചോദനമായി. സ്ട്രീം പ്രോസസ്സിംഗ് ഇൻഫ്രാസ്ട്രക്ചറിലെ വ്യത്യാസങ്ങൾ ഇതിന് ഉത്തമ ഉദാഹരണമാണ്. ഞങ്ങളുടെ ആന്തരിക പതിപ്പ് നിയന്ത്രിത സ്ട്രീം പ്രോസസ്സിംഗ് ചട്ടക്കൂട് ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും, ഓപ്പൺ സോഴ്‌സ് പതിപ്പിനായി ഞങ്ങൾ ബിൽറ്റ്-ഇൻ (സ്റ്റാൻഡലോൺ) സ്ട്രീം പ്രോസസ്സിംഗ് ഉപയോഗിക്കാൻ തിരഞ്ഞെടുത്തു, കാരണം ഇത് മറ്റൊരു ഇൻഫ്രാസ്ട്രക്ചർ ഡിപൻഡൻസി സൃഷ്ടിക്കുന്നത് ഒഴിവാക്കുന്നു.

ഒന്നിലധികം ജിഎംഎസുകൾക്ക് പകരം ഒരു ഓപ്പൺ സോഴ്‌സ് ഇംപ്ലിമെന്റേഷനിൽ ഒരൊറ്റ ജിഎംഎസ് (ജനറലൈസ്ഡ് മെറ്റാഡാറ്റ സ്റ്റോർ) ഉള്ളതാണ് വ്യത്യാസത്തിന്റെ മറ്റൊരു ഉദാഹരണം. GMA (Generalized Metadata Architecture) എന്നത് DataHub-നുള്ള ബാക്ക്-എൻഡ് ആർക്കിടെക്ചറിന്റെ പേരാണ്, GMS എന്നത് GMA-യുടെ പശ്ചാത്തലത്തിലുള്ള മെറ്റാഡാറ്റ സ്റ്റോറാണ്. GMA എന്നത് വളരെ വഴക്കമുള്ള ഒരു ആർക്കിടെക്ചറാണ്, അത് ഓരോ ഡാറ്റാ നിർമ്മാണവും (ഉദാ. ഡാറ്റാസെറ്റുകൾ, ഉപയോക്താക്കൾ മുതലായവ) അതിന്റേതായ മെറ്റാഡാറ്റ സ്റ്റോറിലേക്ക് വിതരണം ചെയ്യാനോ അല്ലെങ്കിൽ ഡാറ്റ ഘടന മാപ്പിംഗ് അടങ്ങുന്ന രജിസ്ട്രി ഉള്ളിടത്തോളം ഒരു മെറ്റാഡാറ്റ സ്റ്റോറിൽ ഒന്നിലധികം ഡാറ്റ നിർമ്മാണങ്ങൾ സംഭരിക്കാനോ നിങ്ങളെ അനുവദിക്കുന്നു. GMS അപ്ഡേറ്റ് ചെയ്തു. ഉപയോഗ എളുപ്പത്തിനായി, ഓപ്പൺ സോഴ്‌സ് DataHub-ൽ എല്ലാ വ്യത്യസ്‌ത ഡാറ്റാ നിർമ്മാണങ്ങളും സംഭരിക്കുന്ന ഒരൊറ്റ GMS ഉദാഹരണം ഞങ്ങൾ തിരഞ്ഞെടുത്തു.

രണ്ട് നടപ്പിലാക്കലുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങളുടെ പൂർണ്ണമായ ലിസ്റ്റ് ചുവടെയുള്ള പട്ടികയിൽ നൽകിയിരിക്കുന്നു.

ഉൽപ്പന്ന സവിശേഷതകൾ
ലിങ്ക്ഡ്ഇൻ ഡാറ്റാഹബ്
ഓപ്പൺ സോഴ്സ് ഡാറ്റാഹബ്

പിന്തുണയ്ക്കുന്ന ഡാറ്റ നിർമ്മാണങ്ങൾ
1) ഡാറ്റാസെറ്റുകൾ 2) ഉപയോക്താക്കൾ 3) മെട്രിക്‌സ് 4) ML ഫീച്ചറുകൾ 5) ചാർട്ടുകൾ 6) ഡാഷ്‌ബോർഡുകൾ
1) ഡാറ്റാസെറ്റുകൾ 2) ഉപയോക്താക്കൾ

ഡാറ്റാസെറ്റുകൾക്കായുള്ള പിന്തുണയുള്ള മെറ്റാഡാറ്റ ഉറവിടങ്ങൾ
1) ആംബ്രി 2) കൗച്ച്ബേസ് 3) ദലിദുകൾ 4) എസ്പ്രെസോ 5) HDFS 6) കൂട് 7) കാഫ്ക 8) മോംഗോഡിബി 9) MySQL 10) ഒറാക്കിൾ 11) പിനോട്ട് 12) പ്രെസ്റ്റോ 12) ആകുക 13) ടെറാഡാറ്റ 13) വെക്റ്റർ 14) വെനിസ്
ഹൈവ് കാഫ്ക RDBMS

പബ്-സബ്
ലിങ്ക്ഡ്ഇൻ കാഫ്ക
സംഗമസ്ഥാനമായ കാഫ്ക

സ്ട്രീം പ്രോസസ്സിംഗ്
നിയന്ത്രിക്കുന്നു
ഉൾച്ചേർത്തത് (സ്വന്തമായി)

ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ & ഡൈനാമിക് കോൺഫിഗറേഷൻ
ലിങ്ക്ഡ്ഇൻ സന്തതി
സ്പ്രിംഗ്

ബിൽഡ് ടൂളിംഗ്
ലിഗ്രാഡിൽ (ലിങ്ക്ഡ്ഇന്നിന്റെ ആന്തരിക ഗ്രാഡിൽ റാപ്പർ)
ഗ്രാഡ്ലെവ്

സിഐ / സിഡി
CRT (ലിങ്ക്ഡ്ഇന്നിന്റെ ആന്തരിക CI/CD)
ട്രാവിസ്സിഐ ഒപ്പം ഡോക്കർ ഹബ്

മെറ്റാഡാറ്റ സ്റ്റോറുകൾ
ഒന്നിലധികം GMS വിതരണം ചെയ്‌തു: 1) ഡാറ്റാസെറ്റ് GMS 2) ഉപയോക്തൃ GMS 3) മെട്രിക് GMS 4) ഫീച്ചർ GMS 5) ചാർട്ട്/ഡാഷ്‌ബോർഡ് GMS
ഇതിനായുള്ള സിംഗിൾ GMS: 1) ഡാറ്റാസെറ്റുകൾ 2) ഉപയോക്താക്കൾ

ഡോക്കർ കണ്ടെയ്‌നറുകളിലെ മൈക്രോ സർവീസുകൾ

ഡോക്കർ ഉപയോഗിച്ച് ആപ്ലിക്കേഷൻ വിന്യാസവും വിതരണവും ലളിതമാക്കുന്നു കണ്ടെയ്നറൈസേഷൻ. DataHub-ലെ സേവനത്തിന്റെ എല്ലാ ഭാഗങ്ങളും ഓപ്പൺ സോഴ്‌സാണ്, കാഫ്ക പോലുള്ള അടിസ്ഥാന സൗകര്യ ഘടകങ്ങൾ ഉൾപ്പെടെ, ഇലാസ്റ്റിസെര്ച്ച്, നിയോ 4 ജെ и MySQL, അതിന്റേതായ ഡോക്കർ ഇമേജ് ഉണ്ട്. ഞങ്ങൾ ഉപയോഗിച്ച ഡോക്കർ കണ്ടെയ്‌നറുകൾ ക്രമീകരിക്കാൻ ഡോക്കർ രചിക്കുക.

ചിത്രം 2: വാസ്തുവിദ്യ ഡാറ്റാഹബ് *ഓപ്പൺ സോഴ്സ്**

മുകളിലെ ചിത്രത്തിൽ നിങ്ങൾക്ക് DataHub-ന്റെ ഉയർന്ന തലത്തിലുള്ള ആർക്കിടെക്ചർ കാണാൻ കഴിയും. ഇൻഫ്രാസ്ട്രക്ചർ ഘടകങ്ങൾ കൂടാതെ, ഇതിന് നാല് വ്യത്യസ്ത ഡോക്കർ കണ്ടെയ്‌നറുകളും ഉണ്ട്:

datahub-gms: മെറ്റാഡാറ്റ സംഭരണ ​​സേവനം

datahub-frontend: ആപ്ലിക്കേഷൻ കളി, DataHub ഇന്റർഫേസ് സേവനം നൽകുന്നു.

datahub-mce-consumer: ആപ്ലിക്കേഷൻ കാഫ്ക സ്ട്രീമുകൾ, ഇത് മെറ്റാഡാറ്റ മാറ്റ ഇവന്റ് (MCE) സ്ട്രീം ഉപയോഗിക്കുകയും മെറ്റാഡാറ്റ സ്റ്റോർ അപ്ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.

datahub-mae-consumer: ആപ്ലിക്കേഷൻ കാഫ്ക സ്ട്രീമുകൾ, ഇത് ഒരു മെറ്റാഡാറ്റ ഓഡിറ്റ് ഇവന്റ് സ്ട്രീം (MAE) ഉപയോഗിക്കുകയും ഒരു തിരയൽ സൂചികയും ഗ്രാഫ് ഡാറ്റാബേസും സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററി ഡോക്യുമെന്റേഷനും യഥാർത്ഥ DataHub ബ്ലോഗ് പോസ്റ്റ് വിവിധ സേവനങ്ങളുടെ പ്രവർത്തനങ്ങളെക്കുറിച്ചുള്ള കൂടുതൽ വിശദമായ വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു.

DataHub-ലെ CI/CD ഓപ്പൺ സോഴ്‌സ് ആണ്

ഓപ്പൺ സോഴ്‌സ് DataHub റിപ്പോസിറ്ററി ഉപയോഗിക്കുന്നു ട്രാവിസ്സിഐ തുടർച്ചയായ സംയോജനത്തിനും ഡോക്കർ ഹബ് തുടർച്ചയായ വിന്യാസത്തിനായി. രണ്ടും നല്ല GitHub സംയോജനവും സജ്ജീകരിക്കാൻ എളുപ്പവുമാണ്. കമ്മ്യൂണിറ്റി അല്ലെങ്കിൽ സ്വകാര്യ കമ്പനികൾ വികസിപ്പിച്ച മിക്ക ഓപ്പൺ സോഴ്‌സ് ഇൻഫ്രാസ്ട്രക്ചറുകൾക്കും (ഉദാ. സംഗമം), കമ്മ്യൂണിറ്റിയുടെ എളുപ്പത്തിലുള്ള ഉപയോഗത്തിനായി ഡോക്കർ ഇമേജുകൾ സൃഷ്ടിക്കുകയും ഡോക്കർ ഹബിലേക്ക് വിന്യസിക്കുകയും ചെയ്യുന്നു. ഡോക്കർ ഹബ്ബിൽ കാണുന്ന ഏതൊരു ഡോക്കർ ചിത്രവും ഒരു ലളിതമായ കമാൻഡ് ഉപയോഗിച്ച് എളുപ്പത്തിൽ ഉപയോഗിക്കാനാകും ഡോക്കർ പുൾ.

DataHub ഓപ്പൺ സോഴ്‌സ് ശേഖരണത്തോടുള്ള എല്ലാ പ്രതിബദ്ധതയിലും, എല്ലാ ഡോക്കർ ചിത്രങ്ങളും "ഏറ്റവും പുതിയ" ടാഗ് ഉപയോഗിച്ച് ഡോക്കർ ഹബ്ബിലേക്ക് സ്വയമേവ നിർമ്മിക്കപ്പെടുകയും വിന്യസിക്കുകയും ചെയ്യുന്നു. ഡോക്കർ ഹബ് ചിലത് ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ റെഗുലർ എക്സ്പ്രഷൻ ശാഖകൾക്ക് പേരിടുന്നു, ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററിയിലെ എല്ലാ ടാഗുകളും ഡോക്കർ ഹബിൽ അനുബന്ധ ടാഗ് പേരുകൾക്കൊപ്പം റിലീസ് ചെയ്യുന്നു.

DataHub ഉപയോഗിക്കുന്നു

DataHub സജ്ജീകരിക്കുന്നു വളരെ ലളിതവും മൂന്ന് ലളിതമായ ഘട്ടങ്ങളും ഉൾക്കൊള്ളുന്നു:

1. ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററി ക്ലോൺ ചെയ്‌ത് ദ്രുത ആരംഭത്തിനായി നൽകിയിരിക്കുന്ന ഡോക്കർ-കമ്പോസ് സ്‌ക്രിപ്റ്റ് ഉപയോഗിച്ച് ഡോക്കർ-കംപോസ് ഉപയോഗിച്ച് എല്ലാ ഡോക്കർ കണ്ടെയ്‌നറുകളും പ്രവർത്തിപ്പിക്കുക.
2. കമാൻഡ് ലൈൻ ടൂൾ ഉപയോഗിച്ച് റിപ്പോസിറ്ററിയിൽ നൽകിയിരിക്കുന്ന സാമ്പിൾ ഡാറ്റ ഡൗൺലോഡ് ചെയ്യുക.
3. നിങ്ങളുടെ ബ്രൗസറിൽ DataHub ബ്രൗസ് ചെയ്യുക.

സജീവമായി ട്രാക്ക് ചെയ്തു ഗിറ്റർ ചാറ്റ് ദ്രുത ചോദ്യങ്ങൾക്കായി ക്രമീകരിച്ചു. ഉപയോക്താക്കൾക്ക് GitHub ശേഖരണത്തിൽ നേരിട്ട് പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാനും കഴിയും. ഏറ്റവും പ്രധാനമായി, എല്ലാ ഫീഡ്‌ബാക്കും നിർദ്ദേശങ്ങളും ഞങ്ങൾ സ്വാഗതം ചെയ്യുകയും അഭിനന്ദിക്കുകയും ചെയ്യുന്നു!

ഭാവിയിലേക്കുള്ള പദ്ധതികൾ

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

ഒരു പൊതു ക്ലൗഡ് സേവനത്തിൽ DataHub വിന്യസിക്കുന്നതിന് ഒരു ടേൺകീ പരിഹാരം നൽകാനും ഞങ്ങൾ പദ്ധതിയിടുന്നു അസൂർ, AWS അഥവാ Google ക്ലൗഡ്. അസുറിലേക്കുള്ള ലിങ്ക്ഡ്ഇന്നിന്റെ സമീപകാല പ്രഖ്യാപനം കണക്കിലെടുക്കുമ്പോൾ, ഇത് മെറ്റാഡാറ്റ ടീമിന്റെ ആന്തരിക മുൻഗണനകളുമായി യോജിപ്പിക്കും.

അവസാനമായി എന്നാൽ ഏറ്റവും പ്രധാനപ്പെട്ടത്, DataHub ആൽഫകൾ റേറ്റുചെയ്യുകയും പ്രശ്‌നങ്ങൾ തിരിച്ചറിയാനും ഡോക്യുമെന്റേഷൻ മെച്ചപ്പെടുത്താനും ഞങ്ങളെ സഹായിക്കുകയും ചെയ്ത ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റിയിലെ DataHub-ന്റെ ആദ്യകാല സ്വീകരിച്ച എല്ലാവർക്കും നന്ദി.

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