ഇൻഡസ്ട്രിയൽ മെഷീൻ ലേണിംഗ്: 10 ഡിസൈൻ തത്വങ്ങൾ

ഇൻഡസ്ട്രിയൽ മെഷീൻ ലേണിംഗ്: 10 ഡിസൈൻ തത്വങ്ങൾ

ഇക്കാലത്ത്, പുതിയ സേവനങ്ങളും ആപ്ലിക്കേഷനുകളും മറ്റ് പ്രധാന പ്രോഗ്രാമുകളും എല്ലാ ദിവസവും സൃഷ്ടിക്കപ്പെടുന്നു, അത് അവിശ്വസനീയമായ കാര്യങ്ങൾ സൃഷ്ടിക്കുന്നത് സാധ്യമാക്കുന്നു: സ്‌പേസ് എക്‌സ് റോക്കറ്റ് നിയന്ത്രിക്കുന്നതിനുള്ള സോഫ്റ്റ്‌വെയർ മുതൽ സ്മാർട്ട്‌ഫോൺ വഴി അടുത്ത മുറിയിലെ കെറ്റിൽ വരെ.

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

ഈ ലേഖനത്തിൽ, 10-ഘടക ആപ്പ് രീതിശാസ്ത്രത്തെ അടിസ്ഥാനമാക്കി, ഒരു ആപ്ലിക്കേഷനിലേക്ക്/സേവനത്തിലേക്ക് എളുപ്പത്തിൽ സംയോജിപ്പിക്കാൻ കഴിയുന്ന തരത്തിൽ വ്യാവസായിക മെഷീൻ ലേണിംഗ് എങ്ങനെ പ്രോഗ്രാം ചെയ്യാം എന്നതിന്റെ 12 തത്ത്വങ്ങൾ ഞാൻ ഹ്രസ്വമായി വിവരിക്കും. Heroku ടീം നിർദ്ദേശിച്ചു. നിരവധി ഡെവലപ്പർമാരെയും ഡാറ്റാ സയൻസ് ആളുകളെയും സഹായിക്കുന്ന ഈ സാങ്കേതികതയെക്കുറിച്ചുള്ള അവബോധം വർദ്ധിപ്പിക്കുക എന്നതാണ് എന്റെ സംരംഭം.

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

തത്വം 1: ഒരു കോഡ് അടിസ്ഥാനം

ആദ്യ ഘട്ടങ്ങളിൽ ചില പ്രോഗ്രാമർമാർ, അത് കണ്ടുപിടിക്കാനുള്ള മടി കാരണം (അല്ലെങ്കിൽ അവരുടേതായ ചില കാരണങ്ങളാൽ), Git-നെ കുറിച്ച് മറക്കുന്നു. ഒന്നുകിൽ അവർ വാക്ക് പൂർണ്ണമായും മറക്കുന്നു, അതായത്, അവർ ഡ്രൈവിൽ ഫയലുകൾ പരസ്പരം എറിയുന്നു / ടെക്സ്റ്റ് എറിയുന്നു / പ്രാവുകൾ അയക്കുന്നു, അല്ലെങ്കിൽ അവർ അവരുടെ വർക്ക്ഫ്ലോയെക്കുറിച്ച് ചിന്തിക്കുന്നില്ല, കൂടാതെ ഓരോന്നും അവരവരുടെ ബ്രാഞ്ചിലേക്ക് സമർപ്പിക്കുന്നു, തുടർന്ന് മാസ്റ്റർ.

ഈ തത്വം പ്രസ്താവിക്കുന്നു: ഒരു കോഡ്ബേസും നിരവധി വിന്യാസങ്ങളും ഉണ്ട്.

Git ഉൽപ്പാദനത്തിലും ഗവേഷണത്തിലും വികസനത്തിലും (R&D) ഉപയോഗിക്കാവുന്നതാണ്, അതിൽ ഇത് പലപ്പോഴും ഉപയോഗിക്കാറില്ല.

ഉദാഹരണത്തിന്, R&D ഘട്ടത്തിൽ, നിങ്ങൾക്ക് വ്യത്യസ്ത ഡാറ്റാ പ്രോസസ്സിംഗ് രീതികളും മോഡലുകളും ഉപയോഗിച്ച് കമ്മിറ്റുകൾ ഉപേക്ഷിക്കാം, തുടർന്ന് ഏറ്റവും മികച്ചത് തിരഞ്ഞെടുത്ത് അതിനൊപ്പം എളുപ്പത്തിൽ പ്രവർത്തിക്കുന്നത് തുടരുക.

രണ്ടാമതായി, ഉൽപ്പാദനത്തിൽ ഇത് മാറ്റാനാകാത്ത കാര്യമാണ് - നിങ്ങളുടെ കോഡ് എങ്ങനെ മാറുന്നുവെന്ന് നിങ്ങൾ നിരന്തരം നോക്കുകയും ഏത് മോഡലാണ് മികച്ച ഫലങ്ങൾ നൽകിയതെന്നും അവസാനം ഏത് കോഡ് പ്രവർത്തിച്ചുവെന്നും അത് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നതിനോ തെറ്റായ ഫലങ്ങൾ സൃഷ്ടിക്കുന്നതിനോ കാരണമായത് എന്താണെന്ന് അറിയേണ്ടതുണ്ട്. . അതിനാണ് പ്രതിബദ്ധതകൾ!

നിങ്ങൾക്ക് നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ ഒരു പാക്കേജ് സൃഷ്ടിക്കാനും കഴിയും, ഉദാഹരണത്തിന്, ജെംഫ്യൂറിയിൽ സ്ഥാപിക്കുക, തുടർന്ന് മറ്റ് പ്രോജക്റ്റുകൾക്കായി അതിൽ നിന്ന് ഫംഗ്ഷനുകൾ ഇറക്കുമതി ചെയ്യുക, അതിനാൽ അവ 1000 തവണ മാറ്റിയെഴുതാതിരിക്കുക, എന്നാൽ പിന്നീട് അതിൽ കൂടുതൽ.

തത്വം 2: ഡിപൻഡൻസികൾ വ്യക്തമായി പ്രഖ്യാപിക്കുകയും ഒറ്റപ്പെടുത്തുകയും ചെയ്യുക

ഓരോ പ്രോജക്‌റ്റിലും വ്യത്യസ്‌ത ലൈബ്രറികൾ ഉണ്ട്, അവ എവിടെയെങ്കിലും പ്രയോഗിക്കുന്നതിനായി നിങ്ങൾ പുറത്തു നിന്ന് ഇറക്കുമതി ചെയ്യുന്നു. അത് പൈത്തൺ ലൈബ്രറികളോ വിവിധ ആവശ്യങ്ങൾക്കുള്ള മറ്റ് ഭാഷകളുടെ ലൈബ്രറികളോ സിസ്റ്റം ടൂളുകളോ ആകട്ടെ - നിങ്ങളുടെ ചുമതല:

• ഡിപൻഡൻസികൾ വ്യക്തമായി പ്രഖ്യാപിക്കുക, അതായത്, നിങ്ങളുടെ പ്രോജക്റ്റിൽ ഉപയോഗിക്കുന്ന എല്ലാ ലൈബ്രറികളും ടൂളുകളും അവയുടെ പതിപ്പുകളും ഉൾക്കൊള്ളുന്ന ഒരു ഫയൽ, അത് ഇൻസ്റ്റാൾ ചെയ്യണം (ഉദാഹരണത്തിന്, പൈത്തണിൽ ഇത് Pipfile അല്ലെങ്കിൽ ആവശ്യകതകൾ.txt ഉപയോഗിച്ച് ചെയ്യാം. A നന്നായി മനസ്സിലാക്കാൻ സഹായിക്കുന്ന ലിങ്ക്: realpython.com/pipenv-guide)
• വികസന സമയത്ത് നിങ്ങളുടെ പ്രോഗ്രാമിനായി പ്രത്യേകമായി ഡിപൻഡൻസികൾ വേർതിരിക്കുക. പതിപ്പുകൾ നിരന്തരം മാറ്റാനും വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാനും നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല, ഉദാഹരണത്തിന്, Tensorflow?

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

ഒരു നിർദ്ദിഷ്‌ട OS-ൽ ഇൻസ്റ്റാൾ ചെയ്‌തേക്കാവുന്ന സിസ്റ്റം ടൂളുകളെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ആശ്രയിക്കരുത്. ഡിപൻഡൻസി മാനിഫെസ്റ്റിലും ഈ ടൂളുകൾ പ്രഖ്യാപിക്കണം. ടൂളുകളുടെ പതിപ്പ് (അതുപോലെ തന്നെ അവയുടെ ലഭ്യതയും) ഒരു പ്രത്യേക OS-ന്റെ സിസ്റ്റം ടൂളുകളുമായി പൊരുത്തപ്പെടാത്ത സാഹചര്യങ്ങൾ ഒഴിവാക്കാൻ ഇത് ആവശ്യമാണ്.

അതിനാൽ, മിക്കവാറും എല്ലാ കമ്പ്യൂട്ടറുകളിലും ചുരുളൻ ഉപയോഗിക്കാമെങ്കിലും, നിങ്ങൾ അത് ഡിപൻഡൻസികളിൽ പ്രഖ്യാപിക്കണം, കാരണം മറ്റൊരു പ്ലാറ്റ്‌ഫോമിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുമ്പോൾ അത് അവിടെ ഉണ്ടാകണമെന്നില്ല അല്ലെങ്കിൽ പതിപ്പ് നിങ്ങൾക്ക് ആദ്യം ആവശ്യമുള്ളത് ആയിരിക്കില്ല.

ഉദാഹരണത്തിന്, നിങ്ങളുടെ ആവശ്യങ്ങൾ.txt ഇതുപോലെയാകാം:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

തത്വം 3: കോൺഫിഗറേഷനുകൾ

AWS-ൽ നിന്നുള്ള പാസ്‌വേഡുകളും മറ്റ് കീകളും ഉപയോഗിച്ച് പബ്ലിക് റിപ്പോസിറ്ററികളിലേക്ക് അബദ്ധവശാൽ GitHub-ലേക്ക് കോഡ് അപ്‌ലോഡ് ചെയ്യുന്ന വിവിധ ഡവലപ്പർമാരുടെ കഥകൾ പലരും കേട്ടിട്ടുണ്ട്, അടുത്ത ദിവസം $6000 അല്ലെങ്കിൽ $50000 കടവുമായി ഉണരുന്നു.

തീർച്ചയായും, ഈ കേസുകൾ അങ്ങേയറ്റം, എന്നാൽ വളരെ പ്രധാനമാണ്. കോഡിനുള്ളിൽ കോൺഫിഗറേഷന് ആവശ്യമായ നിങ്ങളുടെ ക്രെഡൻഷ്യലുകളോ മറ്റ് ഡാറ്റയോ നിങ്ങൾ സംഭരിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് ഒരു തെറ്റ് സംഭവിക്കുന്നു, എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കേണ്ട ആവശ്യമില്ലെന്ന് ഞാൻ കരുതുന്നു.

എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ കോൺഫിഗറേഷനുകൾ സംഭരിക്കുക എന്നതാണ് ഇതിനൊരു ബദൽ. പരിസ്ഥിതി വേരിയബിളുകളെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ.

എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ സാധാരണയായി സൂക്ഷിക്കുന്ന ഡാറ്റയുടെ ഉദാഹരണങ്ങൾ:

• ഡൊമെയ്ൻ നാമങ്ങൾ
• API URL-കൾ/URI-കൾ
• പൊതു, സ്വകാര്യ കീകൾ
• കോൺടാക്റ്റുകൾ (മെയിൽ, ഫോണുകൾ മുതലായവ)

ഈ രീതിയിൽ നിങ്ങളുടെ കോൺഫിഗറേഷൻ വേരിയബിളുകൾ മാറുകയാണെങ്കിൽ നിങ്ങൾ നിരന്തരം കോഡ് മാറ്റേണ്ടതില്ല. ഇത് നിങ്ങളുടെ സമയവും പരിശ്രമവും പണവും ലാഭിക്കാൻ സഹായിക്കും.

ഉദാഹരണത്തിന്, നിങ്ങൾ ടെസ്റ്റുകൾ നടത്താൻ Kaggle API ഉപയോഗിക്കുന്നുവെങ്കിൽ (ഉദാഹരണത്തിന്, മോഡൽ നന്നായി പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുന്നതിന് സോഫ്‌റ്റ്‌വെയർ ഡൗൺലോഡ് ചെയ്‌ത് അതിലൂടെ മോഡൽ പ്രവർത്തിപ്പിക്കുക), തുടർന്ന് Kaggle-ൽ നിന്നുള്ള KAGGLE_USERNAME, KAGGLE_KEY എന്നിവ പോലുള്ള സ്വകാര്യ കീകൾ ആയിരിക്കണം. പരിസ്ഥിതി വേരിയബിളുകളിൽ സംഭരിച്ചിരിക്കുന്നു.

തത്വം 4: മൂന്നാം കക്ഷി സേവനങ്ങൾ

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

ഒരു മൂന്നാം കക്ഷി സേവനം അപ്രാപ്‌തമാക്കുന്നതിനോ മറ്റൊന്ന് ബന്ധിപ്പിക്കുന്നതിനോ, മുകളിലുള്ള ഖണ്ഡികയിൽ ഞാൻ സംസാരിച്ച എൻവയോൺമെന്റ് വേരിയബിളുകളിലെ കോൺഫിഗറേഷനിലെ കീകൾ നിങ്ങൾ മാറ്റേണ്ടതുണ്ട്.

അതിനാൽ, ഉദാഹരണത്തിന്, ഓരോ തവണയും കോഡിനുള്ളിൽ ഡാറ്റാസെറ്റുകളുള്ള ഫയലുകളിലേക്കുള്ള പാത വ്യക്തമാക്കുന്നതിനുപകരം, പാത്ത്ലിബ് ലൈബ്രറി ഉപയോഗിക്കുകയും ഡാറ്റാസെറ്റുകളിലേക്കുള്ള പാത config.py-യിൽ പ്രഖ്യാപിക്കുകയും ചെയ്യുന്നതാണ് നല്ലത്, അതുവഴി നിങ്ങൾ ഏത് സേവനം ഉപയോഗിച്ചാലും (ഇതിനായി ഉദാഹരണത്തിന്, CircleCI), പുതിയ സേവനത്തിലെ പുതിയ ഫയൽ സിസ്റ്റത്തിന്റെ ഘടന കണക്കിലെടുത്ത് ഡാറ്റാസെറ്റുകളിലേക്കുള്ള പാത കണ്ടെത്താൻ പ്രോഗ്രാമിന് കഴിഞ്ഞു.

തത്വം 5. ബിൽഡ്, റിലീസ്, റൺടൈം

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

1. സ്റ്റേജ് സമ്മേളനങ്ങൾ. ആവശ്യമായ എല്ലാ കോഡും ഡാറ്റയും അടങ്ങുന്ന പാക്കേജ് എന്ന് വിളിക്കപ്പെടുന്ന ഒരു പാക്കേജായി വ്യക്തിഗത ഉറവിടങ്ങളുള്ള നിങ്ങളുടെ കേവല കോഡ് നിങ്ങൾ മാറ്റുന്നു. ഈ പാക്കേജിനെ അസംബ്ലി എന്ന് വിളിക്കുന്നു.
2. സ്റ്റേജ് റിലീസ് — ഇവിടെ ഞങ്ങൾ ഞങ്ങളുടെ കോൺഫിഗറേഷൻ അസംബ്ലിയുമായി ബന്ധിപ്പിക്കുന്നു, അതില്ലാതെ ഞങ്ങളുടെ പ്രോഗ്രാം റിലീസ് ചെയ്യാൻ കഴിയില്ല. ഇപ്പോൾ ഇത് പൂർണ്ണമായും റെഡി ടു ലോഞ്ച് റിലീസാണ്.
3. അടുത്തതായി സ്റ്റേജ് വരുന്നു നിവൃത്തി. ഞങ്ങളുടെ റിലീസിൽ നിന്ന് ആവശ്യമായ പ്രക്രിയകൾ പ്രവർത്തിപ്പിച്ച് ഇവിടെ ഞങ്ങൾ ആപ്ലിക്കേഷൻ റിലീസ് ചെയ്യുന്നു.

ഒരു മോഡലിന്റെ അല്ലെങ്കിൽ മുഴുവൻ പൈപ്പ്ലൈനിന്റെയും പുതിയ പതിപ്പുകൾ പുറത്തിറക്കുന്നതിനുള്ള അത്തരമൊരു സംവിധാനം, അഡ്മിനിസ്ട്രേറ്റർമാർക്കും ഡവലപ്പർമാർക്കും ഇടയിൽ റോളുകൾ വേർതിരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, പതിപ്പുകൾ ട്രാക്കുചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു, പ്രോഗ്രാമിന്റെ അനാവശ്യ സ്റ്റോപ്പുകൾ തടയുന്നു.

റിലീസ് ടാസ്‌ക്കിനായി, ഒരു .yml ഫയലിൽ സ്വയം പ്രവർത്തിപ്പിക്കുന്നതിന് നിങ്ങൾക്ക് പ്രോസസ്സുകൾ എഴുതാൻ കഴിയുന്ന നിരവധി സേവനങ്ങൾ സൃഷ്‌ടിച്ചിട്ടുണ്ട് (ഉദാഹരണത്തിന്, CircleCI-ൽ ഇത് പ്രോസസ്സിനെ പിന്തുണയ്ക്കുന്നതിനുള്ള config.yml ആണ്). പ്രോജക്റ്റുകൾക്കായി പാക്കേജുകൾ സൃഷ്ടിക്കുന്നതിൽ വീലി മികച്ചതാണ്.

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

തത്വം 6. നിങ്ങളുടെ മോഡൽ ഒന്നോ അതിലധികമോ പ്രക്രിയകളായി പ്രവർത്തിപ്പിക്കുക

മാത്രമല്ല, പ്രോസസ്സുകൾക്ക് പങ്കിട്ട ഡാറ്റ ഉണ്ടായിരിക്കരുത്. അതായത്, പ്രക്രിയകൾ വെവ്വേറെ നിലനിൽക്കണം, കൂടാതെ എല്ലാ തരത്തിലുമുള്ള ഡാറ്റയും വെവ്വേറെ നിലനിൽക്കണം, ഉദാഹരണത്തിന്, MySQL അല്ലെങ്കിൽ മറ്റുള്ളവ പോലുള്ള മൂന്നാം-കക്ഷി സേവനങ്ങളിൽ, നിങ്ങൾക്ക് ആവശ്യമുള്ളതിനെ ആശ്രയിച്ച്.

അതായത്, പ്രോസസ്സ് ഫയൽ സിസ്റ്റത്തിനുള്ളിൽ ഡാറ്റ സംഭരിക്കുന്നതിന് ഇത് തീർച്ചയായും വിലമതിക്കുന്നില്ല, അല്ലാത്തപക്ഷം ഇത് അടുത്ത റിലീസ് / കോൺഫിഗറേഷനുകളുടെ മാറ്റം അല്ലെങ്കിൽ പ്രോഗ്രാം പ്രവർത്തിക്കുന്ന സിസ്റ്റത്തിന്റെ കൈമാറ്റം ചെയ്യുമ്പോൾ ഈ ഡാറ്റ മായ്ക്കുന്നതിലേക്ക് നയിച്ചേക്കാം.

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

മോഡൽ നിരവധി പ്രോസസ്സുകളായി പ്രവർത്തിപ്പിക്കുന്നതിന്, നിങ്ങൾക്ക് ഒരു .yml ഫയൽ സൃഷ്ടിക്കാൻ കഴിയും, അതിൽ ആവശ്യമായ പ്രക്രിയകളും അവയുടെ ക്രമവും വ്യക്തമാക്കും.

തത്വം 7: പുനരുപയോഗം

നിങ്ങളുടെ മോഡൽ ആപ്ലിക്കേഷനിൽ പ്രവർത്തിക്കുന്ന പ്രക്രിയകൾ ആരംഭിക്കാനും നിർത്താനും എളുപ്പമായിരിക്കണം. അതിനാൽ, കോഡ് മാറ്റങ്ങൾ, കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ, വേഗത്തിലും അയവുള്ളതിലും വേഗത്തിൽ വിന്യസിക്കാനും, പ്രവർത്തന പതിപ്പിന്റെ സാധ്യമായ തകരാറുകൾ തടയാനും ഇത് നിങ്ങളെ അനുവദിക്കും.

അതായത്, മോഡൽ ഉപയോഗിച്ചുള്ള നിങ്ങളുടെ പ്രക്രിയ:

• സ്റ്റാർട്ടപ്പ് സമയം കുറയ്ക്കുക. എബൌട്ട്, സ്റ്റാർട്ടപ്പ് സമയം (സ്റ്റാർട്ടപ്പ് കമാൻഡ് ഇഷ്യൂ ചെയ്ത നിമിഷം മുതൽ പ്രോസസ്സ് പ്രവർത്തനത്തിൽ വരുന്ന നിമിഷം വരെ) കുറച്ച് സെക്കൻഡിൽ കൂടരുത്. മുകളിൽ വിവരിച്ച ലൈബ്രറി കാഷിംഗ്, സ്റ്റാർട്ടപ്പ് സമയം കുറയ്ക്കുന്നതിനുള്ള ഒരു സാങ്കേതികതയാണ്.
• ശരിയായി അവസാനിപ്പിക്കുക. അതായത്, സേവന പോർട്ടിൽ കേൾക്കുന്നത് യഥാർത്ഥത്തിൽ താൽക്കാലികമായി നിർത്തിവച്ചിരിക്കുന്നു, ഈ പോർട്ടിലേക്ക് സമർപ്പിച്ച പുതിയ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യില്ല. ഇവിടെ നിങ്ങൾ ഒന്നുകിൽ DevOps എഞ്ചിനീയർമാരുമായി നല്ല ആശയവിനിമയം സജ്ജീകരിക്കേണ്ടതുണ്ട്, അല്ലെങ്കിൽ അത് സ്വയം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസിലാക്കുക (വെയിലത്ത്, തീർച്ചയായും, രണ്ടാമത്തേത്, എന്നാൽ ആശയവിനിമയം എല്ലായ്പ്പോഴും നിലനിർത്തണം, ഏത് പ്രോജക്റ്റിലും!)

തത്വം 8: തുടർച്ചയായ വിന്യാസം/സംയോജനം

പല കമ്പനികളും ആപ്ലിക്കേഷൻ വികസനവും വിന്യാസ ടീമുകളും തമ്മിലുള്ള വേർതിരിവ് ഉപയോഗിക്കുന്നു (അവസാന ഉപയോക്താക്കൾക്ക് ആപ്ലിക്കേഷൻ ലഭ്യമാക്കുന്നു). ഇത് സോഫ്‌റ്റ്‌വെയർ വികസനം വളരെ മന്ദഗതിയിലാക്കാനും അത് മെച്ചപ്പെടുത്തുന്നതിലെ പുരോഗതിക്കും കാരണമാകും. വികസനവും സംയോജനവും ഏകദേശം പറഞ്ഞാൽ സംയോജിപ്പിച്ചിരിക്കുന്ന DevOps സംസ്കാരത്തെയും ഇത് നശിപ്പിക്കുന്നു.

അതിനാൽ, നിങ്ങളുടെ വികസന അന്തരീക്ഷം നിങ്ങളുടെ ഉൽപ്പാദന അന്തരീക്ഷവുമായി കഴിയുന്നത്ര അടുത്തായിരിക്കണമെന്ന് ഈ തത്വം പറയുന്നു.

ഇത് അനുവദിക്കും:

1. റിലീസ് സമയം പത്തിരട്ടിയായി കുറയ്ക്കുക
2. കോഡ് പൊരുത്തക്കേട് കാരണം പിശകുകളുടെ എണ്ണം കുറയ്ക്കുക.
3. ഡെവലപ്പർമാരും ആപ്ലിക്കേഷൻ വിന്യസിക്കുന്ന ആളുകളും ഇപ്പോൾ ഒരു ടീമായതിനാൽ ഇത് ജീവനക്കാരുടെ ജോലിഭാരവും കുറയ്ക്കുന്നു.

സർക്കിൾസിഐ, ട്രാവിസ് സിഐ, ജിറ്റ്ലാബ് സിഐ എന്നിവയും മറ്റുള്ളവയും ഇതിനൊപ്പം പ്രവർത്തിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ടൂളുകളാണ്.

നിങ്ങൾക്ക് മോഡലിലേക്ക് വേഗത്തിൽ കൂട്ടിച്ചേർക്കലുകൾ നടത്താനും അത് അപ്‌ഡേറ്റ് ചെയ്യാനും ഉടനടി സമാരംഭിക്കാനും കഴിയും, അതേസമയം പരാജയങ്ങളുടെ കാര്യത്തിൽ, പ്രവർത്തന പതിപ്പിലേക്ക് വളരെ വേഗത്തിൽ മടങ്ങുന്നത് എളുപ്പമായിരിക്കും, അതിനാൽ അന്തിമ ഉപയോക്താവ് ഇത് ശ്രദ്ധിക്കുന്നില്ല. നിങ്ങൾക്ക് നല്ല പരിശോധനകളുണ്ടെങ്കിൽ ഇത് പ്രത്യേകിച്ചും എളുപ്പത്തിലും വേഗത്തിലും ചെയ്യാവുന്നതാണ്.

വ്യത്യാസങ്ങൾ കുറയ്ക്കുക!!!

തത്വം 9. നിങ്ങളുടെ ലോഗുകൾ

ലോഗുകൾ (അല്ലെങ്കിൽ "ലോഗുകൾ") ഇവന്റുകൾ, സാധാരണയായി ടെക്സ്റ്റ് ഫോർമാറ്റിൽ റെക്കോർഡ് ചെയ്യപ്പെടുന്നു, അത് ആപ്ലിക്കേഷനിൽ (ഇവന്റ് സ്ട്രീം) സംഭവിക്കുന്നു. ഒരു ലളിതമായ ഉദാഹരണം: "2020-02-02 - സിസ്റ്റം ലെവൽ - പ്രോസസ്സിന്റെ പേര്." പ്രോഗ്രാം പ്രവർത്തിക്കുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഡവലപ്പർക്ക് അക്ഷരാർത്ഥത്തിൽ കാണാൻ കഴിയുന്ന തരത്തിലാണ് അവ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. അവൻ പ്രക്രിയകളുടെ പുരോഗതി കാണുകയും അത് ഡവലപ്പർ തന്നെ ഉദ്ദേശിച്ചതാണോ എന്ന് മനസ്സിലാക്കുകയും ചെയ്യുന്നു.

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

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

തത്വം 10. ടെസ്റ്റ്!

വ്യാവസായിക മെഷീൻ ലേണിംഗിന്, ഈ ഘട്ടം വളരെ പ്രധാനമാണ്, കാരണം മോഡൽ ശരിയായി പ്രവർത്തിക്കുന്നുവെന്നും നിങ്ങൾ ആഗ്രഹിച്ചത് നിർമ്മിക്കുന്നുവെന്നും നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.

പൈറ്റെസ്റ്റ് ഉപയോഗിച്ച് ടെസ്റ്റുകൾ സൃഷ്‌ടിക്കാനും നിങ്ങൾക്ക് ഒരു റിഗ്രഷൻ/ക്ലാസിഫിക്കേഷൻ ടാസ്‌ക് ഉണ്ടെങ്കിൽ ഒരു ചെറിയ ഡാറ്റാസെറ്റ് ഉപയോഗിച്ച് പരീക്ഷിക്കാനും കഴിയും.

ആഴത്തിലുള്ള പഠന മാതൃകകൾക്കായി ഒരേ വിത്ത് സജ്ജീകരിക്കാൻ മറക്കരുത്, അങ്ങനെ അവ നിരന്തരം വ്യത്യസ്ത ഫലങ്ങൾ ഉണ്ടാക്കില്ല.

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

താൽപ്പര്യമുണ്ടെങ്കിൽ ആർക്കും അഭിപ്രായങ്ങളിൽ ഇടാൻ കഴിയുന്ന രസകരമായ തത്വങ്ങൾ ഉപയോഗിക്കാൻ ഞാൻ ശ്രമിക്കും.

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