តើ Data Science អាចមានបញ្ហាអ្វី? ការ​ប្រមូល​ទិន្នន័យ

សព្វថ្ងៃនេះមានវគ្គសិក្សាវិទ្យាសាស្ត្រទិន្នន័យចំនួន 100500 ហើយវាត្រូវបានគេស្គាល់ជាយូរមកហើយថាប្រាក់ច្រើនបំផុតនៅក្នុងវិទ្យាសាស្ត្រទិន្នន័យអាចរកបានតាមរយៈវគ្គសិក្សាវិទ្យាសាស្ត្រទិន្នន័យ (ហេតុអ្វីបានជាជីកនៅពេលដែលអ្នកអាចលក់ប៉ែលបាន?)។ គុណវិបត្តិចម្បងនៃវគ្គសិក្សាទាំងនេះគឺថាពួកគេមិនមានអ្វីដែលត្រូវធ្វើជាមួយការងារពិតប្រាកដទេ: គ្មាននរណាម្នាក់នឹងផ្តល់ឱ្យអ្នកនូវទិន្នន័យដែលបានដំណើរការស្អាតនៅក្នុងទម្រង់ដែលត្រូវការនោះទេ។ ហើយនៅពេលដែលអ្នកចាកចេញពីវគ្គសិក្សា ហើយចាប់ផ្តើមដោះស្រាយបញ្ហាពិតប្រាកដ ការ nuances ជាច្រើនបានលេចឡើង។

ដូច្នេះហើយ យើងកំពុងចាប់ផ្តើមកំណត់ចំណាំជាបន្តបន្ទាប់ “តើមានអ្វីខុសជាមួយវិទ្យាសាស្ត្រទិន្នន័យ” ដោយផ្អែកលើព្រឹត្តិការណ៍ពិតដែលបានកើតឡើងចំពោះខ្ញុំ សមមិត្ត និងសហការីរបស់ខ្ញុំ។ យើងនឹងវិភាគកិច្ចការវិទ្យាសាស្ត្រទិន្នន័យធម្មតាដោយប្រើឧទាហរណ៍ជាក់ស្តែង៖ តើវាកើតឡើងយ៉ាងដូចម្តេច។ តោះចាប់ផ្តើមថ្ងៃនេះជាមួយនឹងកិច្ចការប្រមូលទិន្នន័យ។

ហើយរឿងដំបូងដែលមនុស្សជំពប់ដួលនៅពេលពួកគេចាប់ផ្តើមធ្វើការជាមួយទិន្នន័យពិតប្រាកដគឺការប្រមូលទិន្នន័យនេះដែលពាក់ព័ន្ធបំផុតចំពោះយើង។ សារសំខាន់នៃអត្ថបទនេះ៖

យើងវាយតម្លៃជាលក្ខណៈប្រព័ន្ធ ពេលវេលា ធនធាន និងការខិតខំប្រឹងប្រែងដែលត្រូវការដើម្បីប្រមូល សម្អាត និងរៀបចំទិន្នន័យ។

ហើយសំខាន់បំផុត យើងនឹងពិភាក្សាពីអ្វីដែលត្រូវធ្វើ ដើម្បីទប់ស្កាត់បញ្ហានេះ។

យោងទៅតាមការប៉ាន់ប្រមាណផ្សេងៗ ការសម្អាត ការបំប្លែង ដំណើរការទិន្នន័យ វិស្វកម្មលក្ខណៈពិសេស ជាដើម ត្រូវចំណាយពេល 80-90% នៃពេលវេលា និងការវិភាគ 10-20% ខណៈដែលសម្ភារៈសិក្សាស្ទើរតែទាំងអស់ផ្តោតលើការវិភាគទាំងស្រុង។

សូមក្រឡេកមើលបញ្ហាវិភាគសាមញ្ញក្នុងកំណែបីជាឧទាហរណ៍ធម្មតា ហើយមើលថាតើ "ស្ថានការណ៍កាន់តែធ្ងន់ធ្ងរ" ជាអ្វី។

ហើយជាឧទាហរណ៍ម្តងទៀត យើងនឹងពិចារណាពីការប្រែប្រួលស្រដៀងគ្នានៃភារកិច្ចប្រមូលទិន្នន័យ និងការប្រៀបធៀបសហគមន៍សម្រាប់៖

1. អត្ថបទរង Reddit ពីរ
2. ផ្នែកពីរនៃ Habr
3. Odnoklassniki ពីរក្រុម

វិធីសាស្រ្តតាមលក្ខខណ្ឌក្នុងទ្រឹស្តី

បើកគេហទំព័រ ហើយអានឧទាហរណ៍ ប្រសិនបើវាច្បាស់ ទុកពីរបីម៉ោងសម្រាប់ការអាន ពីរបីម៉ោងសម្រាប់កូដដោយប្រើឧទាហរណ៍ និងការបំបាត់កំហុស។ បន្ថែមពីរបីម៉ោងសម្រាប់ការប្រមូល។ បោះក្នុងរយៈពេលពីរបីម៉ោងក្នុងទុនបម្រុង (គុណនឹងពីរហើយបន្ថែម N ម៉ោង) ។

ចំណុចសំខាន់៖ ការប៉ាន់ស្មានពេលវេលាគឺផ្អែកលើការសន្មត់ និងការទស្សន៍ទាយអំពីរយៈពេលដែលវានឹងត្រូវការ។

វាចាំបាច់ក្នុងការចាប់ផ្តើមការវិភាគពេលវេលាដោយការប៉ាន់ប្រមាណប៉ារ៉ាម៉ែត្រខាងក្រោមសម្រាប់បញ្ហាតាមលក្ខខណ្ឌដែលបានពិពណ៌នាខាងលើ:

• តើទិន្នន័យមានទំហំប៉ុនណា និងចំនួនប៉ុន្មានដែលត្រូវប្រមូលជារូបវ័ន្ត (*សូមមើលខាងក្រោម*)។
• តើពេលវេលាប្រមូលសម្រាប់កំណត់ត្រាមួយគឺជាអ្វី ហើយតើអ្នកត្រូវរង់ចាំរយៈពេលប៉ុន្មាន ទើបអ្នកអាចប្រមូលទីពីរបាន?
• ពិចារណាលើការសរសេរកូដដែលរក្សាទុកស្ថានភាព ហើយចាប់ផ្តើមការចាប់ផ្ដើមឡើងវិញនៅពេលដែល (មិនមែនប្រសិនបើ) អ្វីៗទាំងអស់បរាជ័យ។
• រកមើលថាតើយើងត្រូវការការអនុញ្ញាត និងកំណត់ពេលវេលាសម្រាប់ការទទួលបានការចូលប្រើតាមរយៈ API ដែរឬទេ។
• កំណត់ចំនួននៃកំហុសជាមុខងារនៃភាពស្មុគស្មាញនៃទិន្នន័យ - វាយតម្លៃសម្រាប់កិច្ចការជាក់លាក់មួយ៖ រចនាសម្ព័ន្ធ របៀបបំប្លែងចំនួនប៉ុន្មាន អ្វី និងរបៀបស្រង់ចេញ។
• ជួសជុលកំហុសបណ្តាញ និងបញ្ហាជាមួយនឹងឥរិយាបថគម្រោងមិនស្តង់ដារ។
• វាយតម្លៃថាតើមុខងារដែលត្រូវការមាននៅក្នុងឯកសារ ឬអត់ នោះតើត្រូវការប៉ុន្មាន និងប៉ុន្មានសម្រាប់ដំណោះស្រាយ។

អ្វីដែលសំខាន់បំផុតនោះគឺថាដើម្បីប៉ាន់ប្រមាណពេលវេលា - អ្នកពិតជាត្រូវចំណាយពេលវេលានិងការខិតខំប្រឹងប្រែងលើ "ការឈ្លបយកការណ៍ជាធរមាន" - មានតែពេលនោះផែនការរបស់អ្នកនឹងគ្រប់គ្រាន់។ ដូច្នេះមិនថាអ្នកត្រូវបានគេជំរុញឱ្យនិយាយថា "តើវាត្រូវចំណាយពេលប៉ុន្មានដើម្បីប្រមូលទិន្នន័យ" - ទិញខ្លួនអ្នកនូវពេលវេលាខ្លះសម្រាប់ការវិភាគបឋមហើយជជែកវែកញែកថាតើពេលវេលានឹងប្រែប្រួលអាស្រ័យលើប៉ារ៉ាម៉ែត្រពិតប្រាកដនៃបញ្ហា។

ហើយឥឡូវនេះយើងនឹងបង្ហាញឧទាហរណ៍ជាក់លាក់ដែលប៉ារ៉ាម៉ែត្របែបនេះនឹងផ្លាស់ប្តូរ។

ចំណុចសំខាន់៖ ការប៉ាន់ស្មានគឺផ្អែកលើការវិភាគលើកត្តាសំខាន់ៗដែលមានឥទ្ធិពលលើវិសាលភាព និងភាពស្មុគស្មាញនៃការងារ។

ការប៉ាន់ប្រមាណដោយផ្អែកលើការស្មានគឺជាវិធីសាស្រ្តដ៏ល្អមួយនៅពេលដែលធាតុមុខងារមានទំហំតូចល្មម ហើយមិនមានកត្តាជាច្រើនដែលអាចជះឥទ្ធិពលយ៉ាងខ្លាំងដល់ការរចនានៃបញ្ហានោះទេ។ ប៉ុន្តែនៅក្នុងករណីនៃបញ្ហាវិទ្យាសាស្រ្តទិន្នន័យមួយចំនួន កត្តាបែបនេះក្លាយជាច្រើនណាស់ ហើយវិធីសាស្រ្តបែបនេះមិនគ្រប់គ្រាន់។

ការប្រៀបធៀបសហគមន៍ Reddit

ចូរចាប់ផ្តើមជាមួយនឹងករណីសាមញ្ញបំផុត (ដូចដែលវាប្រែចេញនៅពេលក្រោយ) ។ ជាទូទៅ ដើម្បីឲ្យមានភាពស្មោះត្រង់ទាំងស្រុង យើងមានករណីស្ទើរតែដ៏ល្អមួយ សូមពិនិត្យមើលបញ្ជីផ្ទៀងផ្ទាត់ភាពស្មុគស្មាញរបស់យើង៖

• មាន API ស្អាត ច្បាស់លាស់ និងជាឯកសារ។
• វាសាមញ្ញបំផុត ហើយសំខាន់បំផុត សញ្ញាសម្ងាត់ត្រូវបានទទួលដោយស្វ័យប្រវត្តិ។
• មាន រុំពស់ថ្លាន់ - ជាមួយឧទាហរណ៍ជាច្រើន។
• សហគមន៍ដែលវិភាគ និងប្រមូលទិន្នន័យនៅលើ reddit (សូម្បីតែវីដេអូ YouTube ដែលពន្យល់ពីរបៀបប្រើ Python wrapper) ឧទាហរណ៍.
• វិធីសាស្រ្តដែលយើងត្រូវការទំនងជាមាននៅក្នុង 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 - យើងត្រូវបានគេបង្ខំឱ្យយកទិន្នន័យជាបាច់ (គេងរវាងសំណើ។ ល។ ) ។
• ពេលវេលាប្រមូល - សម្រាប់ការវិភាគ និងការប្រៀបធៀបពេញលេញ អ្នកនឹងត្រូវកំណត់ពេលវេលាដ៏សំខាន់សម្រាប់សត្វពីងពាងដើរកាត់ subreddit ប៉ុណ្ណោះ។
• បូតត្រូវតែដំណើរការលើម៉ាស៊ីនមេ អ្នកមិនអាចគ្រាន់តែដំណើរការវានៅលើកុំព្យូទ័រយួរដៃរបស់អ្នក ដាក់វានៅក្នុងកាបូបស្ពាយរបស់អ្នក និងធ្វើអាជីវកម្មរបស់អ្នកនោះទេ។ ដូច្នេះខ្ញុំបានដំណើរការអ្វីគ្រប់យ៉ាងនៅលើ VPS ។ ដោយប្រើលេខកូដផ្សព្វផ្សាយ habrahabr10 អ្នកអាចសន្សំបាន 10% ទៀតនៃការចំណាយ។
• ភាពមិនអាចចូលដំណើរការបានជាក់ស្តែងនៃទិន្នន័យមួយចំនួន (ពួកវាអាចមើលឃើញដោយអ្នកគ្រប់គ្រង ឬពិបាកក្នុងការប្រមូល) - នេះត្រូវតែយកមកពិចារណា ជាគោលការណ៍ មិនមែនទិន្នន័យទាំងអស់អាចប្រមូលបានក្នុងពេលវេលាគ្រប់គ្រាន់នោះទេ។
• កំហុសបណ្តាញ៖ ការភ្ជាប់បណ្តាញគឺជាការឈឺចាប់។
• នេះគឺជាទិន្នន័យពិតដែលកំពុងរស់នៅ - វាមិនដែលបរិសុទ្ធទេ។

ជាការពិតណាស់វាចាំបាច់ដើម្បីរួមបញ្ចូល nuances ទាំងនេះនៅក្នុងការអភិវឌ្ឍ។ ម៉ោង/ថ្ងៃជាក់លាក់អាស្រ័យលើបទពិសោធន៍អភិវឌ្ឍន៍ ឬបទពិសោធន៍ដែលធ្វើការលើកិច្ចការស្រដៀងគ្នានេះ ទោះជាយ៉ាងណាក៏ដោយ យើងឃើញថាការងារនេះមានលក្ខណៈវិស្វកម្មសុទ្ធសាធ ហើយមិនត្រូវការចលនារាងកាយបន្ថែមដើម្បីដោះស្រាយនោះទេ - អ្វីគ្រប់យ៉ាងអាចត្រូវបានវាយតម្លៃ កំណត់ពេល និងធ្វើបានយ៉ាងល្អ។

ការប្រៀបធៀបផ្នែក Habr

ចូរបន្តទៅករណីគួរឱ្យចាប់អារម្មណ៍ និងមិនមែនជារឿងតូចតាចបន្ថែមទៀតនៃការប្រៀបធៀបខ្សែស្រឡាយ និង/ឬផ្នែកនៃ Habr ។

ចូរយើងពិនិត្យមើលបញ្ជីត្រួតពិនិត្យភាពស្មុគស្មាញរបស់យើង - នៅទីនេះ ដើម្បីយល់ពីចំណុចនីមួយៗ អ្នកនឹងត្រូវជីកកកាយបន្តិចទៅក្នុងកិច្ចការដោយខ្លួនវា ហើយពិសោធន៍។

• ដំបូងអ្នកគិតថាមាន API ប៉ុន្តែមិនមានទេ។ បាទ/ចាស បាទ Habr មាន API ប៉ុន្តែវាគ្រាន់តែមិនអាចចូលប្រើបានសម្រាប់អ្នកប្រើប្រាស់ (ឬប្រហែលជាវាមិនដំណើរការទាល់តែសោះ)។
• បន្ទាប់មកអ្នកគ្រាន់តែចាប់ផ្តើមញែក html - "ការស្នើសុំនាំចូល" តើមានអ្វីអាចខុស?
• តើធ្វើដូចម្តេចដើម្បីញែក? វិធីសាស្រ្តសាមញ្ញបំផុត និងប្រើញឹកញាប់បំផុតគឺការធ្វើម្តងទៀតលើ IDs ចំណាំថាវាមិនមែនជាប្រសិទ្ធភាពបំផុតទេ ហើយនឹងត្រូវដោះស្រាយករណីផ្សេងៗគ្នា - នេះគឺជាឧទាហរណ៍នៃដង់ស៊ីតេនៃលេខសម្គាល់ពិតប្រាកដក្នុងចំណោមអ្នកដែលមានស្រាប់ទាំងអស់។

  
  យកពី នេះ អត្ថបទ

• ទិន្នន័យ​ដើម​ដែល​រុំ​ក្នុង HTML នៅ​លើ​គេហទំព័រ​គឺ​ជា​ការ​ឈឺ​ចាប់។ ឧទាហរណ៍ អ្នកចង់ប្រមូល និងរក្សាទុកការវាយតម្លៃនៃអត្ថបទ៖ អ្នកបានដកពិន្ទុចេញពី html ហើយសម្រេចចិត្តរក្សាទុកវាជាលេខសម្រាប់ដំណើរការបន្ថែម៖ 

  1) int (ពិន្ទុ) បោះចោលកំហុស៖ ចាប់តាំងពីនៅលើ Habre មានដកមួយ ដូចជាឧទាហរណ៍នៅក្នុងបន្ទាត់ “–5” - នេះគឺជាសញ្ញា en មិនមែនជាសញ្ញាដក (មិននឹកស្មានដល់មែនទេ?) ដូច្នេះនៅ ចំណុចមួយចំនួនដែលខ្ញុំត្រូវលើកអ្នកញែកទៅជាជីវិតជាមួយនឹងការជួសជុលដ៏អាក្រក់បែបនេះ។

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

  ប្រហែលជាមិនមានកាលបរិច្ឆេទ បូក និងដកទាំងអស់ទេ (ដូចដែលយើងឃើញខាងលើនៅក្នុងមុខងារ check_date វាបានកើតឡើង)។

  2) តួអក្សរពិសេសដែលមិនបានគេចខ្លួន - ពួកគេនឹងមកអ្នកត្រូវរៀបចំ។

  3) រចនាសម្ព័ន្ធផ្លាស់ប្តូរអាស្រ័យលើប្រភេទនៃប្រកាស។

  4) ប្រកាសចាស់អាចមានរចនាសម្ព័ន្ធចំលែក ** ។

• ជាការសំខាន់ ការដោះស្រាយកំហុស និងអ្វីដែលអាច ឬមិនកើតឡើង នឹងត្រូវដោះស្រាយ ហើយអ្នកមិនអាចទស្សន៍ទាយបានថា អ្វីនឹងខុស ហើយរចនាសម្ព័ន្ធផ្សេងទៀតអាចនឹងទៅជាយ៉ាងណា និងអ្វីដែលនឹងធ្លាក់ចេញពីកន្លែងណា - អ្នកគ្រាន់តែត្រូវព្យាយាម និងពិចារណា។ កំហុសដែលអ្នកញែកចោល។
• បន្ទាប់មកអ្នកដឹងថាអ្នកត្រូវញែកជាខ្សែអក្សរជាច្រើន បើមិនដូច្នេះទេការញែកក្នុងមួយនឹងចំណាយពេល 30+ ម៉ោង (នេះគឺជាពេលវេលាប្រតិបត្តិសុទ្ធសាធនៃ parser តែមួយខ្សែដែលកំពុងដំណើរការរួចហើយ ដែលដេកហើយមិនស្ថិតនៅក្រោមការហាមឃាត់ណាមួយឡើយ)។ IN នេះ អត្ថបទនេះនាំអោយមានគ្រោងការណ៍ស្រដៀងគ្នានេះ៖

បញ្ជីត្រួតពិនិត្យសរុបតាមភាពស្មុគស្មាញ៖

• ធ្វើការជាមួយបណ្តាញ និងការវិភាគ html ជាមួយនឹងការធ្វើឡើងវិញ និងការស្វែងរកតាមលេខសម្គាល់។
• ឯកសារនៃរចនាសម្ព័ន្ធខុសគ្នា។
• មានកន្លែងជាច្រើនដែលកូដអាចធ្លាក់ចុះយ៉ាងងាយស្រួល។
• ចាំបាច់ត្រូវសរសេរ || កូដ។
• បាត់ឯកសារចាំបាច់ គំរូកូដ និង/ឬសហគមន៍។

ពេលវេលាប៉ាន់ស្មានសម្រាប់កិច្ចការនេះនឹងខ្ពស់ជាងការប្រមូលទិន្នន័យពី Reddit 3-5 ដង។

ការប្រៀបធៀបក្រុម Odnoklassniki

ចូរបន្តទៅករណីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតតាមបច្ចេកទេសដែលបានពិពណ៌នា។ សម្រាប់ខ្ញុំ វាពិតជាគួរឱ្យចាប់អារម្មណ៍ណាស់ ពីព្រោះនៅក្រឡេកមើលដំបូង វាមើលទៅមិនសូវសំខាន់ ប៉ុន្តែវាមិនបានក្លាយទៅជាបែបនោះទាល់តែសោះ - ភ្លាមៗនៅពេលដែលអ្នកគោះឈើ។

ចូរចាប់ផ្តើមជាមួយនឹងបញ្ជីត្រួតពិនិត្យការលំបាករបស់យើង ហើយចំណាំថាពួកគេជាច្រើននឹងប្រែទៅជាពិបាកជាងអ្វីដែលពួកគេមើលដំបូង៖

• មាន API ប៉ុន្តែវាស្ទើរតែខ្វះមុខងារចាំបាច់ទាំងស្រុង។
• ចំពោះមុខងារមួយចំនួន អ្នកត្រូវស្នើសុំការចូលប្រើតាមសំបុត្រ ពោលគឺការផ្តល់សិទ្ធិចូលប្រើគឺមិនភ្លាមៗនោះទេ។
• វាត្រូវបានចងក្រងជាឯកសារយ៉ាងគួរឱ្យភ័យខ្លាច (ដើម្បីចាប់ផ្តើមជាមួយ ពាក្យរុស្ស៊ី និងអង់គ្លេសត្រូវបានលាយបញ្ចូលគ្នាគ្រប់ទីកន្លែង ហើយមិនជាប់លាប់ទាំងស្រុង - ពេលខ្លះអ្នកគ្រាន់តែត្រូវទាយអ្វីដែលពួកគេចង់បានពីអ្នកនៅកន្លែងណាមួយ) ហើយលើសពីនេះទៅទៀត ការរចនាមិនសមរម្យសម្រាប់ការទទួលបានទិន្នន័យ ឧទាហរណ៍ , មុខងារដែលយើងត្រូវការ.
• ទាមទារវគ្គនៅក្នុងឯកសារ ប៉ុន្តែពិតជាមិនប្រើវាទេ ហើយគ្មានវិធីដើម្បីយល់ពីភាពស្មុគ្រស្មាញទាំងអស់នៃរបៀប API ក្រៅពីការមើលជុំវិញ ហើយសង្ឃឹមថាអ្វីមួយនឹងដំណើរការនោះទេ។
• មិនមានឧទាហរណ៍ និងគ្មានសហគមន៍ទេ ចំណុចតែមួយគត់នៃការគាំទ្រក្នុងការប្រមូលព័ត៌មានគឺតូច រុំ នៅក្នុង Python (ដោយគ្មានឧទាហរណ៍ជាច្រើននៃការប្រើប្រាស់) ។
• សេលេញ៉ូមហាក់ដូចជាជម្រើសដែលអាចធ្វើការបានបំផុត ព្រោះទិន្នន័យចាំបាច់ជាច្រើនត្រូវបានចាក់សោ។
  1) នោះគឺការអនុញ្ញាតកើតឡើងតាមរយៈអ្នកប្រើប្រាស់ប្រឌិត (និងការចុះឈ្មោះដោយដៃ)។

  2) ទោះជាយ៉ាងណាក៏ដោយជាមួយនឹងសេលេញ៉ូមមិនមានការធានាសម្រាប់ការងារត្រឹមត្រូវនិងអាចធ្វើម្តងទៀតបានទេ (យ៉ាងហោចណាស់ក្នុងករណី ok.ru ប្រាកដ) ។

  3) គេហទំព័រ Ok.ru មានកំហុស JavaScript ហើយជួនកាលមានអាកប្បកិរិយាចម្លែកនិងមិនជាប់លាប់។

  4) អ្នកត្រូវធ្វើ pagination, ផ្ទុកធាតុ, ល ...

  5) កំហុស API ដែល wrapper ផ្តល់ឱ្យនឹងត្រូវដោះស្រាយដោយឆ្គង ឧទាហរណ៍ដូចនេះ (បំណែកនៃកូដពិសោធន៍)៖

  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) ទីបំផុត Selenium + API មើលទៅដូចជាជម្រើសសមហេតុផលបំផុត។

• វាចាំបាច់ក្នុងការរក្សាទុករដ្ឋ និងចាប់ផ្តើមប្រព័ន្ធឡើងវិញ ដោះស្រាយកំហុសជាច្រើន រួមទាំងអាកប្បកិរិយាមិនស៊ីសង្វាក់គ្នានៃគេហទំព័រ ហើយកំហុសទាំងនេះពិតជាពិបាកក្នុងការស្រមៃ (លុះត្រាតែអ្នកសរសេរកម្មវិធីញែកដោយវិជ្ជាជីវៈ ជាការពិត)។

ការប៉ាន់ស្មានពេលវេលាតាមលក្ខខណ្ឌសម្រាប់កិច្ចការនេះនឹងខ្ពស់ជាង 3-5 ដងសម្រាប់ការប្រមូលទិន្នន័យពី Habr ។ ទោះបីជាការពិតដែលថាក្នុងករណី Habr យើងប្រើវិធីសាស្រ្តផ្នែកខាងមុខជាមួយនឹងការញែក HTML ហើយក្នុងករណី OK យើងអាចធ្វើការជាមួយ API នៅកន្លែងសំខាន់ៗ។

ការរកឃើញ

មិនថាអ្នកត្រូវបានគេតម្រូវឱ្យប៉ាន់ប្រមាណពេលវេលាកំណត់ "នៅនឹងកន្លែង" (យើងកំពុងរៀបចំផែនការថ្ងៃនេះទេ!) នៃម៉ូឌុលដំណើរការបំពង់បង្ហូរទិន្នន័យដ៏អស្ចារ្យ ពេលវេលាប្រតិបត្តិគឺស្ទើរតែមិនអាចប៉ាន់ប្រមាណបានសូម្បីតែគុណភាពដោយមិនធ្វើការវិភាគលើប៉ារ៉ាម៉ែត្រកិច្ចការ។

នៅលើកំណត់ចំណាំផ្នែកទស្សនវិជ្ជាបន្តិច យុទ្ធសាស្ត្រប៉ាន់ស្មានយ៉ាងរហ័សដំណើរការល្អសម្រាប់កិច្ចការវិស្វកម្ម ប៉ុន្តែបញ្ហាដែលមានលក្ខណៈពិសោធន៍ច្រើន ហើយក្នុងន័យមួយ "ការច្នៃប្រឌិត" និងការរុករក ពោលគឺ ការព្យាករណ៍តិចមានការលំបាក ដូចជានៅក្នុងឧទាហរណ៍នៃប្រធានបទស្រដៀងគ្នា , ដែលយើងបានពិភាក្សានៅទីនេះ។

ជាការពិតណាស់ ការប្រមូលទិន្នន័យគ្រាន់តែជាឧទាហរណ៍ដ៏សំខាន់មួយប៉ុណ្ណោះ - ជាធម្មតាវាជាកិច្ចការដ៏សាមញ្ញ និងបច្ចេកទេសមិនគួរឱ្យជឿ ហើយអារក្សតែងតែមានព័ត៌មានលម្អិត។ ហើយវាច្បាស់ណាស់នៅលើកិច្ចការនេះដែលយើងអាចបង្ហាញជួរទាំងមូលនៃជម្រើសដែលអាចធ្វើបានសម្រាប់អ្វីដែលអាចខុស និងច្បាស់ថាតើការងារអាចចំណាយពេលប៉ុន្មាន។

ប្រសិនបើអ្នកក្រឡេកមើលលក្ខណៈនៃភារកិច្ចដោយគ្មានការពិសោធបន្ថែមនោះ Reddit និង OK មើលទៅស្រដៀងគ្នា៖ មាន API ដែលជាឧបករណ៍រុំពស់ថ្លាន់ ប៉ុន្តែនៅក្នុងខ្លឹមសារ ភាពខុសគ្នាគឺធំណាស់។ ការវិនិច្ឆ័យដោយប៉ារ៉ាម៉ែត្រទាំងនេះ pars របស់ Habr មើលទៅស្មុគស្មាញជាង OK - ប៉ុន្តែនៅក្នុងការអនុវត្តវាពិតជាផ្ទុយគ្នា ហើយនេះពិតជាអ្វីដែលអាចរកឃើញដោយធ្វើការពិសោធន៍សាមញ្ញដើម្បីវិភាគប៉ារ៉ាម៉ែត្រនៃបញ្ហា។

តាមបទពិសោធន៍របស់ខ្ញុំ វិធីសាស្រ្តដ៏មានប្រសិទ្ធភាពបំផុតគឺការប៉ាន់ស្មានពេលវេលាដែលអ្នកនឹងត្រូវការសម្រាប់ការវិភាគបឋមដោយខ្លួនឯង និងការពិសោធន៍ដំបូងសាមញ្ញ ការអានឯកសារ - ទាំងនេះនឹងអនុញ្ញាតឱ្យអ្នកផ្តល់នូវការប៉ាន់ស្មានត្រឹមត្រូវសម្រាប់ការងារទាំងមូល។ នៅក្នុងលក្ខខណ្ឌនៃវិធីសាស្រ្ត agile ដ៏ពេញនិយម ខ្ញុំស្នើឱ្យអ្នកបង្កើតសំបុត្រសម្រាប់ "ប៉ាន់ប្រមាណប៉ារ៉ាម៉ែត្រភារកិច្ច" ដោយឈរលើមូលដ្ឋានដែលខ្ញុំអាចផ្តល់ការវាយតម្លៃនូវអ្វីដែលអាចសម្រេចបាននៅក្នុង "sprint" និងផ្តល់នូវការប៉ាន់ប្រមាណត្រឹមត្រូវបន្ថែមទៀតសម្រាប់នីមួយៗ។ ភារកិច្ច។

ដូច្នេះ អាគុយម៉ង់ដែលមានប្រសិទ្ធភាពបំផុតហាក់ដូចជាមួយដែលនឹងបង្ហាញអ្នកឯកទេស "មិនបច្ចេកទេស" ថាតើពេលវេលា និងធនធាននឹងប្រែប្រួលអាស្រ័យលើប៉ារ៉ាម៉ែត្រដែលមិនទាន់ត្រូវបានវាយតម្លៃនៅឡើយ។

ប្រភព: www.habr.com