ഡാറ്റ സയൻസിൽ എന്ത് തെറ്റ് സംഭവിക്കാം? ഡാറ്റ ശേഖരണം

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

അതിനാൽ, എനിക്കും എന്റെ സഖാക്കൾക്കും സഹപ്രവർത്തകർക്കും സംഭവിച്ച യഥാർത്ഥ സംഭവങ്ങളെ അടിസ്ഥാനമാക്കി “ഡാറ്റ സയൻസിൽ എന്ത് തെറ്റ് സംഭവിക്കാം” എന്ന കുറിപ്പുകളുടെ ഒരു പരമ്പര ഞങ്ങൾ ആരംഭിക്കുന്നു. യഥാർത്ഥ ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് ഞങ്ങൾ സാധാരണ ഡാറ്റാ സയൻസ് ടാസ്‌ക്കുകൾ വിശകലനം ചെയ്യും: ഇത് യഥാർത്ഥത്തിൽ എങ്ങനെ സംഭവിക്കുന്നു. ഡാറ്റാ കളക്ഷൻ ടാസ്‌ക്കിൽ നിന്ന് നമുക്ക് ഇന്ന് തുടങ്ങാം.

യഥാർത്ഥ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ ആളുകൾ ആദ്യം ഇടറുന്നത് യഥാർത്ഥത്തിൽ ഞങ്ങൾക്ക് ഏറ്റവും പ്രസക്തമായ ഈ ഡാറ്റ ശേഖരിക്കുക എന്നതാണ്. ഈ ലേഖനത്തിന്റെ പ്രധാന സന്ദേശം:

ഡാറ്റ ശേഖരിക്കുന്നതിനും വൃത്തിയാക്കുന്നതിനും തയ്യാറാക്കുന്നതിനും ആവശ്യമായ സമയം, വിഭവങ്ങൾ, പരിശ്രമം എന്നിവ ഞങ്ങൾ വ്യവസ്ഥാപിതമായി കുറച്ചുകാണുന്നു.

ഏറ്റവും പ്രധാനമായി, ഇത് തടയാൻ എന്തുചെയ്യണമെന്ന് ഞങ്ങൾ ചർച്ച ചെയ്യും.

വിവിധ കണക്കുകൾ പ്രകാരം, ക്ലീനിംഗ്, പരിവർത്തനം, ഡാറ്റ പ്രോസസ്സിംഗ്, ഫീച്ചർ എഞ്ചിനീയറിംഗ് മുതലായവ 80-90% സമയവും വിശകലനം 10-20% എടുക്കുന്നു, അതേസമയം മിക്കവാറും എല്ലാ വിദ്യാഭ്യാസ സാമഗ്രികളും വിശകലനത്തിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.

മൂന്ന് പതിപ്പുകളിലെ ഒരു ലളിതമായ വിശകലന പ്രശ്നം ഒരു സാധാരണ ഉദാഹരണമായി നോക്കാം, കൂടാതെ "വഷളാക്കുന്ന സാഹചര്യങ്ങൾ" എന്താണെന്ന് നോക്കാം.

ഒരു ഉദാഹരണമായി, വീണ്ടും, ഡാറ്റ ശേഖരിക്കുന്നതിനും കമ്മ്യൂണിറ്റികളെ താരതമ്യം ചെയ്യുന്നതിനുമുള്ള ചുമതലയുടെ സമാന വ്യതിയാനങ്ങൾ ഞങ്ങൾ പരിഗണിക്കും:

1. രണ്ട് റെഡ്ഡിറ്റ് സബ്‌റെഡിറ്റുകൾ
2. ഹബറിന്റെ രണ്ട് വിഭാഗങ്ങൾ
3. Odnoklassniki യുടെ രണ്ട് ഗ്രൂപ്പുകൾ

സിദ്ധാന്തത്തിൽ സോപാധിക സമീപനം

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

പ്രധാന പോയിന്റ്: എത്ര സമയമെടുക്കും എന്നതിനെക്കുറിച്ചുള്ള അനുമാനങ്ങളുടെയും ഊഹങ്ങളുടെയും അടിസ്ഥാനത്തിലാണ് സമയം കണക്കാക്കുന്നത്.

മുകളിൽ വിവരിച്ച സോപാധിക പ്രശ്നത്തിന് ഇനിപ്പറയുന്ന പാരാമീറ്ററുകൾ കണക്കാക്കി സമയ വിശകലനം ആരംഭിക്കേണ്ടത് ആവശ്യമാണ്:

• ഡാറ്റയുടെ വലുപ്പം എന്താണ്, അതിൽ എത്രത്തോളം ഭൗതികമായി ശേഖരിക്കേണ്ടതുണ്ട് (*താഴെ കാണുക*).
• ഒരു റെക്കോർഡിന്റെ ശേഖരണ സമയം എത്രയാണ്, രണ്ടാമത്തേത് ശേഖരിക്കുന്നതിന് എത്ര സമയം കാത്തിരിക്കണം?
• സംസ്ഥാനത്തെ സംരക്ഷിക്കുകയും എല്ലാം പരാജയപ്പെടുമ്പോൾ (എങ്കിലല്ല) പുനരാരംഭിക്കുകയും ചെയ്യുന്ന കോഡ് എഴുതുന്നത് പരിഗണിക്കുക.
• ഞങ്ങൾക്ക് അംഗീകാരം ആവശ്യമുണ്ടോ എന്ന് കണ്ടെത്തുകയും API വഴി ആക്സസ് നേടുന്നതിനുള്ള സമയം സജ്ജമാക്കുകയും ചെയ്യുക.
• ഡാറ്റ സങ്കീർണ്ണതയുടെ ഒരു ഫംഗ്‌ഷനായി പിശകുകളുടെ എണ്ണം സജ്ജമാക്കുക - ഒരു നിർദ്ദിഷ്ട ടാസ്‌ക്കിനായി വിലയിരുത്തുക: ഘടന, എത്ര പരിവർത്തനങ്ങൾ, എന്ത്, എങ്ങനെ എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്യാം.
• നെറ്റ്‌വർക്ക് പിശകുകളും നിലവാരമില്ലാത്ത പ്രോജക്റ്റ് പെരുമാറ്റത്തിലെ പ്രശ്നങ്ങളും പരിഹരിക്കുക.
• ആവശ്യമായ ഫംഗ്‌ഷനുകൾ ഡോക്യുമെന്റേഷനിലുണ്ടോ എന്നും ഇല്ലെങ്കിൽ, ഒരു പരിഹാരത്തിന് എങ്ങനെ, എത്രമാത്രം ആവശ്യമുണ്ടെന്നും വിലയിരുത്തുക.

ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം, സമയം കണക്കാക്കാൻ - നിങ്ങൾ യഥാർത്ഥത്തിൽ സമയവും പ്രയത്നവും "ശക്തിയുള്ള നിരീക്ഷണത്തിനായി" ചെലവഴിക്കേണ്ടതുണ്ട് - അപ്പോൾ മാത്രമേ നിങ്ങളുടെ ആസൂത്രണം പര്യാപ്തമാകൂ. അതിനാൽ, “ഡാറ്റ ശേഖരിക്കാൻ എത്ര സമയമെടുക്കും” എന്ന് പറയാൻ നിങ്ങളെ എത്രമാത്രം പ്രേരിപ്പിച്ചാലും - ഒരു പ്രാഥമിക വിശകലനത്തിനായി സ്വയം കുറച്ച് സമയം വാങ്ങുകയും ടാസ്‌ക്കിന്റെ യഥാർത്ഥ പാരാമീറ്ററുകളെ ആശ്രയിച്ച് സമയം എത്രത്തോളം വ്യത്യാസപ്പെടുമെന്ന് വാദിക്കുകയും ചെയ്യുക.

അത്തരം പാരാമീറ്ററുകൾ മാറുന്ന നിർദ്ദിഷ്ട ഉദാഹരണങ്ങൾ ഇപ്പോൾ ഞങ്ങൾ പ്രദർശിപ്പിക്കും.

പ്രധാന പോയിന്റ്: ജോലിയുടെ വ്യാപ്തിയെയും സങ്കീർണ്ണതയെയും സ്വാധീനിക്കുന്ന പ്രധാന ഘടകങ്ങളുടെ വിശകലനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് എസ്റ്റിമേറ്റ്.

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

റെഡ്ഡിറ്റ് കമ്മ്യൂണിറ്റികളുടെ താരതമ്യം

നമുക്ക് ഏറ്റവും ലളിതമായ കേസിൽ നിന്ന് ആരംഭിക്കാം (അത് പിന്നീട് മാറുന്നതുപോലെ). പൊതുവേ, പൂർണ്ണമായും സത്യസന്ധമായി പറഞ്ഞാൽ, ഞങ്ങൾക്ക് ഏതാണ്ട് അനുയോജ്യമായ ഒരു കേസ് ഉണ്ട്, നമുക്ക് നമ്മുടെ സങ്കീർണ്ണത ചെക്ക്ലിസ്റ്റ് പരിശോധിക്കാം:

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

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

നിന്ന് എടുത്തത് ഇത് പൊതിയുന്നതിനുള്ള സൗകര്യപ്രദമായ യൂട്ടിലിറ്റികളുടെ ഒരു തിരഞ്ഞെടുപ്പ്.

ഇത് ഏറ്റവും മികച്ച കാര്യമാണെങ്കിലും, യഥാർത്ഥ ജീവിതത്തിൽ നിന്നുള്ള നിരവധി പ്രധാന ഘടകങ്ങൾ കണക്കിലെടുക്കുന്നത് ഇപ്പോഴും മൂല്യവത്താണ്:

• API പരിധികൾ - ബാച്ചുകളിൽ ഡാറ്റ എടുക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു (അഭ്യർത്ഥനകൾക്കിടയിലുള്ള ഉറക്കം മുതലായവ).
• ശേഖരണ സമയം - സമ്പൂർണ്ണ വിശകലനത്തിനും താരതമ്യത്തിനും വേണ്ടി, ചിലന്തിക്ക് സബ്‌റെഡിറ്റിലൂടെ നടക്കാൻ നിങ്ങൾ കാര്യമായ സമയം നീക്കിവയ്ക്കേണ്ടിവരും.
• ബോട്ട് ഒരു സെർവറിൽ പ്രവർത്തിക്കണം-നിങ്ങൾക്ക് ഇത് നിങ്ങളുടെ ലാപ്‌ടോപ്പിൽ പ്രവർത്തിപ്പിക്കാനും ബാക്ക്‌പാക്കിൽ ഇടാനും നിങ്ങളുടെ ബിസിനസ്സിലേക്ക് പോകാനും കഴിയില്ല. അതിനാൽ ഞാൻ എല്ലാം ഒരു വിപിഎസിൽ പ്രവർത്തിപ്പിച്ചു. പ്രമോഷണൽ കോഡ് habrahabr10 ഉപയോഗിച്ച് നിങ്ങൾക്ക് ചെലവിന്റെ 10% ലാഭിക്കാം.
• ചില ഡാറ്റയുടെ ഭൗതിക അപ്രാപ്യത (അത് അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് ദൃശ്യമാണ് അല്ലെങ്കിൽ ശേഖരിക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്) - ഇത് കണക്കിലെടുക്കണം; തത്വത്തിൽ, എല്ലാ ഡാറ്റയും മതിയായ സമയത്ത് ശേഖരിക്കാൻ കഴിയില്ല.
• നെറ്റ്‌വർക്ക് പിശകുകൾ: നെറ്റ്‌വർക്കിംഗ് ഒരു വേദനയാണ്.
• ഇത് ജീവിക്കുന്ന യഥാർത്ഥ ഡാറ്റയാണ് - ഇത് ഒരിക്കലും ശുദ്ധമല്ല.

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

ഹബ്ർ വിഭാഗങ്ങളുടെ താരതമ്യം

ഹബറിന്റെ ത്രെഡുകളും കൂടാതെ/അല്ലെങ്കിൽ വിഭാഗങ്ങളും താരതമ്യം ചെയ്യുന്ന കൂടുതൽ രസകരവും നിസ്സാരമല്ലാത്തതുമായ ഒരു കേസിലേക്ക് നമുക്ക് പോകാം.

നമുക്ക് ഞങ്ങളുടെ സങ്കീർണ്ണത ചെക്ക്‌ലിസ്റ്റ് പരിശോധിക്കാം - ഇവിടെ, ഓരോ പോയിന്റും മനസിലാക്കാൻ, നിങ്ങൾ ടാസ്‌ക്കിൽ തന്നെ അൽപ്പം കുഴിച്ച് പരീക്ഷണം നടത്തേണ്ടതുണ്ട്.

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

  
  നിന്ന് എടുത്തത് ഇത് ലേഖനങ്ങൾ.

• വെബിന്റെ മുകളിൽ HTML-ൽ പൊതിഞ്ഞ അസംസ്‌കൃത ഡാറ്റ വേദനാജനകമാണ്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഒരു ലേഖനത്തിന്റെ റേറ്റിംഗ് ശേഖരിക്കാനും സംരക്ഷിക്കാനും താൽപ്പര്യമുണ്ട്: നിങ്ങൾ html-ൽ നിന്ന് സ്കോർ കീറി, കൂടുതൽ പ്രോസസ്സിംഗിനായി ഒരു നമ്പറായി സംരക്ഷിക്കാൻ തീരുമാനിച്ചു: 

  1) int(സ്കോർ) ഒരു പിശക് എറിയുന്നു: ഹബ്രെയിൽ ഒരു മൈനസ് ഉള്ളതിനാൽ, ഉദാഹരണത്തിന്, “–5” എന്ന വരിയിൽ - ഇതൊരു എൻ ഡാഷ് ആണ്, മൈനസ് ചിഹ്നമല്ല (അപ്രതീക്ഷിതമായി, ശരിയല്ലേ?), അതിനാൽ ചില ഘട്ടങ്ങളിൽ, അത്തരമൊരു ഭയാനകമായ പരിഹാരത്തിലൂടെ എനിക്ക് പാഴ്‌സറിനെ ജീവിതത്തിലേക്ക് ഉയർത്തേണ്ടിവന്നു.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  തീയതി, പ്ലസുകൾ, മൈനസുകൾ എന്നിവ ഇല്ലായിരിക്കാം (നമുക്ക് ചെക്ക്_ഡേറ്റ് ഫംഗ്ഷനിൽ മുകളിൽ കാണുന്നത് പോലെ, ഇത് സംഭവിച്ചു).

  2) ഒഴിവാക്കപ്പെടാത്ത പ്രത്യേക പ്രതീകങ്ങൾ - അവർ വരും, നിങ്ങൾ തയ്യാറാകേണ്ടതുണ്ട്.

  3) പോസ്റ്റിന്റെ തരം അനുസരിച്ച് ഘടന മാറുന്നു.

  4) പഴയ പോസ്റ്റുകൾക്ക് **വിചിത്രമായ ഘടന** ഉണ്ടായിരിക്കാം.

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

സങ്കീർണ്ണത അനുസരിച്ച് മൊത്തം ചെക്ക്‌ലിസ്റ്റ്:

• നെറ്റ്‌വർക്കിനൊപ്പം പ്രവർത്തിക്കുകയും എച്ച്ടിഎംഎൽ പാഴ്‌സിംഗ് ഉപയോഗിച്ച് ആവർത്തനവും ഐഡി പ്രകാരം തിരയുകയും ചെയ്യുന്നു.
• വൈവിധ്യമാർന്ന ഘടനയുടെ രേഖകൾ.
• കോഡ് എളുപ്പത്തിൽ വീഴുന്ന നിരവധി സ്ഥലങ്ങളുണ്ട്.
• എഴുതേണ്ടത് ആവശ്യമാണ് || കോഡ്.
• ആവശ്യമായ ഡോക്യുമെന്റേഷനും കോഡ് ഉദാഹരണങ്ങളും കൂടാതെ/അല്ലെങ്കിൽ കമ്മ്യൂണിറ്റിയും കാണുന്നില്ല.

Reddit-ൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നതിനേക്കാൾ 3-5 മടങ്ങ് കൂടുതലായിരിക്കും ഈ ടാസ്‌ക്കിന്റെ ഏകദേശ സമയം.

Odnoklassniki ഗ്രൂപ്പുകളുടെ താരതമ്യം

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

ഞങ്ങളുടെ ബുദ്ധിമുട്ട് ചെക്ക്‌ലിസ്റ്റിൽ നിന്ന് ആരംഭിക്കാം, അവയിൽ പലതും ആദ്യം കാണുന്നതിനേക്കാൾ വളരെ ബുദ്ധിമുട്ടുള്ളതായി മാറുമെന്ന് ശ്രദ്ധിക്കുക:

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

  2) എന്നിരുന്നാലും, സെലിനിയം ഉപയോഗിച്ച് ശരിയായതും ആവർത്തിക്കാവുന്നതുമായ ജോലികൾക്ക് യാതൊരു ഗ്യാരണ്ടിയും ഇല്ല (കുറഞ്ഞത് ok.ru ന്റെ കാര്യത്തിൽ ഉറപ്പാണ്).

  3) Ok.ru വെബ്‌സൈറ്റിൽ JavaScript പിശകുകൾ അടങ്ങിയിരിക്കുന്നു, ചിലപ്പോൾ വിചിത്രമായും പൊരുത്തക്കേടോടെയും പെരുമാറുന്നു.

  4) നിങ്ങൾ പേജിനേഷൻ, ലോഡിംഗ് ഘടകങ്ങൾ മുതലായവ ചെയ്യേണ്ടതുണ്ട്...

  5) റാപ്പർ നൽകുന്ന API പിശകുകൾ വിചിത്രമായി കൈകാര്യം ചെയ്യേണ്ടിവരും, ഉദാഹരണത്തിന്, ഇതുപോലെ (പരീക്ഷണാത്മക കോഡിന്റെ ഒരു ഭാഗം):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  എന്റെ പ്രിയപ്പെട്ട തെറ്റ് ഇതായിരുന്നു:

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) ആത്യന്തികമായി, സെലിനിയം + API ഏറ്റവും യുക്തിസഹമായ ഓപ്ഷൻ പോലെ കാണപ്പെടുന്നു.

• സംസ്ഥാനം സംരക്ഷിക്കുകയും സിസ്റ്റം പുനരാരംഭിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്, സൈറ്റിന്റെ പൊരുത്തമില്ലാത്ത പെരുമാറ്റം ഉൾപ്പെടെ നിരവധി പിശകുകൾ കൈകാര്യം ചെയ്യുക - ഈ പിശകുകൾ സങ്കൽപ്പിക്കാൻ വളരെ പ്രയാസമാണ് (നിങ്ങൾ പ്രൊഫഷണലായി പാർസറുകൾ എഴുതുന്നില്ലെങ്കിൽ, തീർച്ചയായും).

ഈ ടാസ്‌ക്കിന്റെ സോപാധിക സമയ എസ്റ്റിമേറ്റ് ഹബറിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നതിനേക്കാൾ 3-5 മടങ്ങ് കൂടുതലായിരിക്കും. ഹബറിന്റെ കാര്യത്തിൽ ഞങ്ങൾ HTML പാഴ്‌സിംഗ് ഉപയോഗിച്ച് ഒരു മുൻനിര സമീപനം ഉപയോഗിക്കുന്നു, ശരിയുടെ കാര്യത്തിൽ ഞങ്ങൾക്ക് നിർണായക സ്ഥലങ്ങളിൽ API-യുമായി പ്രവർത്തിക്കാൻ കഴിയും.

കണ്ടെത്തലുകൾ

ഒരു വലിയ ഡാറ്റാ പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈൻ മൊഡ്യൂളിന്റെ "സ്പോട്ട്" (ഞങ്ങൾ ഇന്ന് ആസൂത്രണം ചെയ്യുന്നു!) ഡെഡ്‌ലൈനുകൾ എത്രത്തോളം കണക്കാക്കേണ്ടതുണ്ട്, ടാസ്‌ക് പാരാമീറ്ററുകൾ വിശകലനം ചെയ്യാതെ തന്നെ എക്‌സിക്യൂഷൻ സമയം ഗുണപരമായി കണക്കാക്കാൻ ഒരിക്കലും സാധ്യമല്ല.

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

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

അധിക പരീക്ഷണങ്ങളില്ലാതെ ടാസ്‌ക്കിന്റെ സവിശേഷതകളിലേക്ക് നിങ്ങൾ നോക്കുകയാണെങ്കിൽ, റെഡ്ഡിറ്റും ശരിയും സമാനമായി കാണപ്പെടുന്നു: ഒരു API, ഒരു പൈത്തൺ റാപ്പർ ഉണ്ട്, എന്നാൽ സാരാംശത്തിൽ, വ്യത്യാസം വളരെ വലുതാണ്. ഈ പാരാമീറ്ററുകൾ വിലയിരുത്തുമ്പോൾ, ഹബറിന്റെ പാർസ് ശരിയേക്കാൾ സങ്കീർണ്ണമാണെന്ന് തോന്നുന്നു - എന്നാൽ പ്രായോഗികമായി ഇത് തികച്ചും വിപരീതമാണ്, പ്രശ്നത്തിന്റെ പാരാമീറ്ററുകൾ വിശകലനം ചെയ്യുന്നതിനായി ലളിതമായ പരീക്ഷണങ്ങൾ നടത്തുന്നതിലൂടെ ഇത് കൃത്യമായി കണ്ടെത്താനാകും.

എന്റെ അനുഭവത്തിൽ, പ്രാഥമിക വിശകലനത്തിനും ലളിതമായ ആദ്യ പരീക്ഷണങ്ങൾക്കും ആവശ്യമായ സമയം ഏകദേശം കണക്കാക്കുക എന്നതാണ് ഏറ്റവും ഫലപ്രദമായ സമീപനം, ഡോക്യുമെന്റേഷൻ വായിക്കുക - ഇത് മുഴുവൻ ജോലിക്കും കൃത്യമായ എസ്റ്റിമേറ്റ് നൽകാൻ നിങ്ങളെ അനുവദിക്കും. ജനപ്രിയമായ ചടുലമായ രീതിശാസ്ത്രത്തിന്റെ അടിസ്ഥാനത്തിൽ, “ടാസ്‌ക് പാരാമീറ്ററുകൾ കണക്കാക്കുന്നതിന്” ഒരു ടിക്കറ്റ് സൃഷ്‌ടിക്കാൻ ഞാൻ നിങ്ങളോട് ആവശ്യപ്പെടുന്നു, അതിന്റെ അടിസ്ഥാനത്തിൽ “സ്പ്രിന്റ്” എന്നതിനുള്ളിൽ എന്താണ് ചെയ്യാൻ കഴിയുകയെന്ന് എനിക്ക് ഒരു വിലയിരുത്തൽ നൽകാനും ഓരോന്നിനും കൂടുതൽ കൃത്യമായ എസ്റ്റിമേറ്റ് നൽകാനും കഴിയും. ചുമതല.

അതിനാൽ, ഇതുവരെ വിലയിരുത്തപ്പെടാത്ത പാരാമീറ്ററുകളെ ആശ്രയിച്ച് എത്ര സമയവും വിഭവങ്ങളും വ്യത്യാസപ്പെടുമെന്ന് "സാങ്കേതികേതര" സ്പെഷ്യലിസ്റ്റിന് കാണിക്കുന്ന ഒന്നാണ് ഏറ്റവും ഫലപ്രദമായ വാദം.

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