ការជ្រើស crawler កូដបើកចំហ៖ តួនាទី 4 និងលក្ខណៈវាយតម្លៃ 4

ការស្វែងរក crawler នៅលើ GitHub អាចបង្ហាញ repository រាប់រយ ឬរាប់ពាន់។ មនុស្សជាច្រើនជ្រើស project ដោយមើលចំនួន star ហើយចាប់ផ្តើមពី project ដែលពេញនិយមបំផុត។

ប៉ុន្តែភាពពេញនិយម និងភាពសមស្របសម្រាប់ករណីរបស់អ្នកគឺជារឿងផ្សេងគ្នា។ ទោះ project ពេញនិយមខ្លាំងក៏ដោយ ប្រសិនបើគោលបំណងរបស់វាមិនស្របនឹង scenario របស់អ្នក វានឹងធ្វើឱ្យការងារលំបាកជាងមុន។ ចំណុចចាប់ផ្តើមដែលសាមញ្ញជាងគេគឺបែងចែកតួនាទីជាមុន៖ ប្រព័ន្ធប្រមូលទិន្នន័យដែលត្រូវដំណើរការមានស្ថេរភាពយូរអង្វែង ជាទូទៅបង្កើតពី components ជាច្រើនដែលមានភារកិច្ចខុសគ្នា។ ពេលយល់ថាផ្នែកនីមួយៗធ្វើអ្វី ការប្រៀបធៀប implementation ជាក់លាក់ក៏ងាយឡើង។

Crawler framework ទូទៅ៖ សម្រាប់ទំព័រដែលមានរចនាសម្ព័ន្ធថេរ

Framework ប្រភេទនេះគ្រប់គ្រង request scheduling, concurrent fetching និង data pipeline។ វាទទួល URL ជាក្រុម ហើយបញ្ចេញលទ្ធផលដែលមានរចនាសម្ព័ន្ធ។ Ecosystem ដែលមានភាពចាស់ទុំ និង middleware អនុញ្ញាតឱ្យបន្ថែម logic ផ្ទាល់ខ្លួន ហើយសមស្របសម្រាប់ task ទំហំធំដែលត្រូវរត់យូរ។

វាមិនអាចដោះស្រាយដោយខ្លួនឯងនូវទំព័រដែល content បង្ហាញតែបន្ទាប់ពី JavaScript rendering ទេ។ ក្នុងករណីនេះ response ដំបូងគ្រាន់តែជាសំបកទទេ ដូច្នេះត្រូវភ្ជាប់ rendering engine បន្ថែម។ វាសមស្របសម្រាប់ target ដែលមានរចនាសម្ព័ន្ធថេរ ដូចជា list page, detail page និង open API។

Browser automation framework៖ សម្រាប់ rendering និង interaction

ទំព័រដែលត្រូវការការ render ពិតប្រាកដ ត្រូវការ session ដែលបាន login ឬត្រូវចុចប៉ុន្មានដងមុន content បង្ហាញ គួរឱ្យ browser automation ដោះស្រាយ។ Tools ប្រភេទនេះអាចដំណើរការលើ browser engine ច្រើន មាន waiting mechanism ល្អ និងអាចគ្រប់គ្រង request និង response របស់ទំព័រដោយផ្ទាល់។

តម្លៃដែលត្រូវបង់គឺការប្រើ resource ខ្ពស់ជាង HTTP request ធម្មតាច្រើន។ ដែនកំណត់ concurrency ពឹងផ្អែកជាចម្បងលើ memory និង CPU មូលដ្ឋាន។ Automation ក៏ទុកសញ្ញាដែលអាចរកឃើញបាន ដូច្នេះ site ដែលមាន detection តឹងរ៉ឹងអាចស្គាល់វា។

Scheduling និង queue components៖ ត្រូវការពេល task ច្រើនឡើង

បើ target មានតិច loop ធម្មតាអាចគ្រប់គ្រាន់។ ពេល task ឡើងដល់រាប់ពាន់ ហើយត្រូវគ្រប់គ្រង frequency និង retry ត្រូវមាន scheduling layer ដាច់ដោយឡែក៖ តើ task ចូល queue យ៉ាងដូចម្តេច, concurrency ប៉ុន្មាន, បន្ទាប់ពី failure ត្រូវរង់ចាំប៉ុន្មានមុន retry និង task ណាខ្លះគួរបោះបង់។ បើដាក់ logic ទាំងអស់នេះក្នុង crawler framework code នឹងស្មុគស្មាញយ៉ាងឆាប់រហ័ស។

កំហុសដែលជួបញឹកញាប់ពេលបង្កើត layer នេះដោយខ្លួនឯងគឺប្រើ in-process queue ប៉ុណ្ណោះ។ ពេល process restart task ទាំងអស់ដែលកំពុងរង់ចាំនឹងបាត់។ យ៉ាងហោចណាស់ queue ត្រូវ persistent ហើយអាចពិនិត្យ status បាន។

Parsing និង storage components៖ កំណត់ថាទិន្នន័យអាចប្រើភ្លាមៗឬអត់

អ្វីដែលទាញបានគឺ HTML ប៉ុន្តែអ្វីដែលត្រូវការពិតគឺ fields។ Parsing layer ត្រូវគ្រប់គ្រង extraction rules, validate fields, deduplicate និងសរសេរទិន្នន័យទៅ storage។ សម្រាប់ site ដែលប្តូររចនាសម្ព័ន្ធញឹកញាប់ អាចពិចារណា adaptive extraction ដែលរកទិន្នន័យតាមលក្ខណៈរបស់ទំព័រ ជំនួស hard-coded selector ដើម្បីកាត់បន្ថយការថែទាំ។

ផ្នែក storage ត្រូវយកចិត្តទុកដាក់លើ idempotency។ Task retry ជារឿងធម្មតា ដូច្នេះការសរសេរទិន្នន័យគួរដកស្ទួនដោយ unique identifier បើមិនដូច្នោះទេ duplicate records នឹងប៉ះពាល់ដល់ downstream analysis។

បញ្ហាដែលជួបញឹកញាប់បន្ទាប់ពីភ្ជាប់ components ចូលគ្នា

Component នីមួយៗមើលដោយឡែកមិនពិបាកទេ។ បញ្ហាភាគច្រើនកើតនៅចំណុចភ្ជាប់។

• Scheduling layer retry task ប៉ុន្តែ parsing layer មិន deduplicate ដូច្នេះបង្កើត row ស្ទួន
• Browser layer មិនមាន concurrency limit ធ្វើឱ្យ resource មូលដ្ឋានអស់ ហើយ batch ទាំងមូលបរាជ័យ
• Parsing rules ត្រូវ hard-code ក្នុង code ដូច្នេះពេល site ប្តូរ ត្រូវចេញ release ថ្មី
• Components ប្រើ task identifier មិនដូចគ្នា status មិនត្រូវគ្នា ហើយមិនអាច resume ពី checkpoint បាន

លក្ខណៈវាយតម្លៃ 4

បន្ទាប់ពីកំណត់ category ដែលត្រូវការ សូមប្រើ 4 ចំណុចនេះដើម្បីចម្រាញ់ project ជាក់លាក់។

សម្រាប់ maintenance activity សូមមើល commit frequency និងល្បឿនឆ្លើយតប issue ក្នុងប៉ុន្មានខែចុងក្រោយ មិនមែនចំនួន star សរុបទេ។ Project ដែលឈប់ថែទាំអាចឈប់ដំណើរការភ្លាមៗ បន្ទាប់ពី target site ប្តូរ។

Documentation និង examples កំណត់ការចំណាយពេលរៀន។ បើ docs មិនច្បាស់ ឬមានតែ example ងាយបំផុត ពេលវេលារៀនអាចលើសពីការរំពឹងទុក។

សម្រាប់ extensibility សូមពិនិត្យថាមាន integration points អ្វីខ្លះ៖ អាចប្តូរ proxy បានទេ អាចភ្ជាប់ rendering engine ផ្ទាល់ខ្លួនបានទេ ឬអាចប្តូរ storage បានទេ។ Project ដែលមាន extension points ច្បាស់អាចកែសម្រួលពេលក្រោយដោយមិនបាច់ប្តូរ source code។

ហានិភ័យផ្នែក license និង compliance ងាយត្រូវរំលង។ មុនប្រើប្រាស់ពាណិជ្ជកម្ម ត្រូវបញ្ជាក់ license type និងជៀសវាង license ដែលមិនសមនឹងគោលបំណងប្រើប្រាស់។ ត្រូវវាយតម្លៃ collection scope, request frequency និង terms របស់ target site ផងដែរ ដែលជាបញ្ហាដាច់ដោយឡែកពីគុណភាពបច្ចេកទេសរបស់ framework។

Environment layer ជាបញ្ហានៅកម្រិតផ្សេង

Framework ដោះស្រាយថាត្រូវ collect data យ៉ាងដូចម្តេច ប៉ុន្តែមិនដោះស្រាយ identity និង scale ទេ។ នៅពេល task ត្រូវ login ត្រូវបែងចែកតាម region ឬប្រើ account ច្រើនដំណើរការស្របគ្នា ការរត់ទាំងអស់ក្នុង browser environment តែមួយបង្កើតបញ្ហាពីរ៖ session ប៉ះពាល់គ្នា ព្រោះ cookies និង local storage overlap ហើយ target site អាចមើល task ដែលមិនពាក់ព័ន្ធគ្នាថាជាក្រុម access តែមួយ។

វិធីដែលមានភាពចាស់ទុំគឺធ្វើ browser environments ជា resource layer ដាច់ដោយឡែក។ Task ស្នើ environment ពី pool ហើយ release វាបន្ទាប់ពីប្រើ។ ក្នុង architecture បែបនេះ PurpleMark ស្ថិតនៅ layer នេះ ដោយផ្តល់ environment resources ដែលអាចបង្កើតជាក្រុម ភ្ជាប់ទៅ network egress ដាច់ដោយឡែក និងពិនិត្យ status បាន។

ព្រំដែន compliance

គោរព robots rules និង terms of service របស់ target site មិនប្រមូល personal information មិន bypass technical protection measures ហើយគ្រប់គ្រង request frequency មិនឱ្យប៉ះពាល់ដល់សេវាធម្មតា។ ការជ្រើស project ដោះស្រាយបញ្ហាប្រសិទ្ធភាព ប៉ុន្តែការវាយតម្លៃទាំងនេះកំណត់ថាគួរធ្វើ collection ឬអត់។