Kodėl sugenda web scraping sprendimai ir kaip to išvengti

Daugelis įmonių bent kartą yra turėjusios tokią patirtį: kažkas parašė programą, kuri rinko duomenis iš svetainės, ji kelis mėnesius veikė, o vieną dieną tyliai nustojo. Niekas nepastebėjo, ataskaitos rodė senus skaičius, ir problema paaiškėjo tik tada, kai pagal juos buvo priimtas sprendimas. Žemiau – kodėl taip nutinka ir kaip to išvengti.

Dažniausios gedimų priežastys

1. Svetainė pakeitė išvaizdą ar struktūrą

Tai dažniausia priežastis. Pasikeitus puslapio kodui, programa neberanda kainos ar pavadinimo ir arba nieko nesurenka, arba paima ne tai, ką reikia.

2. Pasikeitė būdas, kaip įkeliamas turinys

Svetainė, kuri anksčiau pateikdavo duomenis tiesiai puslapyje, gali pradėti juos įkelti naršyklėje naudodama JavaScript. Tada paprastos užklausos nebeužtenka ir reikia kitokio požiūrio.

3. Apsauga nuo automatinių užklausų

Svetainės gali riboti per dažnas užklausas arba blokuoti įtartiną srautą. Todėl svarbu nekelti nereikalingos apkrovos ir laikytis protingų dažnių, o ne bandyti „apeiti“ apsaugą. Apie pagarbų elgesį rašome straipsnyje ar legalus web scraping.

4. Laikini tinklo ar serverio sutrikimai

Pasitaiko, kad šaltinis kelias minutes neatsako. Jei programa tuo atveju sustoja arba įrašo tuščius duomenis, rezultatas būna neteisingas.

5. Duomenų kokybės problemos

Netikėti simboliai, naujas kainų formatas, trūkstami laukai ar pasikartojantys įrašai gali sugadinti ataskaitas, nors programa techniškai veikia.

Kaip sukurti stabilesnį sprendimą

1. Pakartotiniai bandymai. Nepavykus užklausai, programa po trumpos pauzės bando dar kartą.
2. Aiškūs patikrinimai. Kiekvieną kartą tikrinama, ar surinktas įprastas įrašų skaičius ir ar laukai užpildyti.
3. Pranešimai. Jei patikra nepavyksta, atsakingas žmogus gauna žinutę, o ne sužino po savaitės.
4. Duomenų išsaugojimas klaidos atveju. Blogi duomenys neperrašo gerų, o paskutinė tinkama versija išlieka.
5. Struktūros atskyrimas nuo logikos. Svetainės specifika laikoma vienoje vietoje, kad ją būtų lengva pataisyti.
6. Žurnalas. Išsaugomi įrašai apie tai, kas ir kada buvo surinkta, kad problemą būtų galima ištirti.
7. Pirmenybė API. Jei šaltinis siūlo oficialų API, jis dažniausiai stabilesnis nei puslapių analizė.

Kaip atrodo stebėsena

Praktiškai tai gali būti paprasta suvestinė, kurioje matote:

• kada paskutinį kartą sėkmingai surinkti duomenys;
• kiek įrašų surinkta, palyginti su įprastu kiekiu;
• kiek klaidų įvyko;
• kurie šaltiniai šiuo metu problemiški.

Net tokia paprasta santrauka leidžia reaguoti per kelias valandas, o ne po kelių savaičių.

Priežiūra – natūrali sprendimo dalis

Svetainės keisis visada, todėl planuojant projektą verta numatyti ir priežiūrą: sprendimo stebėjimą, taisymus ir periodinį patikrinimą. Tai ne papildomas išlaidų punktas, o dalis to, kas leidžia gauti patikimus duomenis ilgą laiką. Pradinį požiūrį į duomenų rinkimą aprašėme straipsnyje web scraping verslui, o vieną dažniausių pavyzdžių – kainų stebėsenoje el. parduotuvėms.

Jei jūsų duomenų rinkimo sprendimas nepatikimas arba norite sukurti naują, susisiekite su mumis – peržiūrėsime situaciją ir pasiūlysime, kaip padaryti jį stabilų.