• Analizator de oferte cu ETP (JS-render, antibot) cu normalizare și încărcare în alerte PostgreSQL și Telegram

    5 ore în urmă
    • Buget dorit până la 380.7 USD
    • Se așteaptă un executant...
  • Situație inițială: departamentul de achiziții monitorizează zilnic noile licitații pe 6 platforme electronice de tranzacționare (ETP). În prezent, acest lucru se face manual într-un browser cu filtre, motiv pentru care unele achiziții relevante sunt ratate, iar datele de la diferite ETP-uri nu sunt aduse într-o singură formă.

    Mediu tehnic și limitări: server Linux (Ubuntu 22.04), acces prin SSH. Permis să utilizeze Python 3.11, Playwright sau Selenium, solicitări/httpx, PostgreSQL 14 (baza de date există deja). Docker este posibil, dar nu este necesar. Nu puteți utiliza servicii anti-captcha plătite și nu puteți stoca acreditările din conturile personale în text clar. Acces la ETP doar ca invitat, fără autorizație. Unele site-uri încarcă conținut cu JavaScript, au protecție anti-bot și limitează frecvența solicitărilor.

    Domeniul subiect: licitații/achiziții. Este necesar să colectați carduri de achiziție și loturi, să normalizați categoriile și sumele și să salvați un istoric al modificărilor.

    Ce ar trebui să se întâmple: un parser autonom care colectează date într-un program de la 6 ETP-uri specificate (voi furniza o listă de domenii și exemple de link-uri către rezultatele căutării), le aduce la o schemă comună și le adaugă la PostgreSQL și, de asemenea, trimite notificări către Telegram când apar noi achiziții relevante.

    Etape și cerințe cheie:
    1) Analiza surselor - pentru fiecare ETP, determinați metoda de încărcare (XHR/GraphQL/HTML/JS-render), punctele de intrare pentru emitere și carduri, un set de câmpuri, limite de viteză.
    2) Implementarea asamblatorului - module adaptoare separate pentru fiecare sursă cu o singură interfață. Trebuie acceptate reluări, backoff-uri, timeout-uri, limitarea concurenței, rotația User-Agent, lucrul printr-un proxy (voi furniza un proxy) și rezistența la eșecurile parțiale.
    3) Normalizarea datelor - un singur model în baza de date: achiziție, lot, client, regiune, date (publicare/sfârșit), NMC/monedă, stare, link, site, descriere text, CPV/OKPD2 (dacă există), precum și un câmp de relevanță calculat pentru cuvintele cheie și cuvintele de excludere (voi oferi o listă). Reduceți sumele la numere, datele la UTC, eliminați reclamele duplicate între ETP-uri folosind un set de euristici (NUM-ul clientului + suma + datele + asemănarea numelui).
    4) Stocare istorică - atunci când starea sau data de încheiere se schimbă, ar trebui să fie înregistrată o nouă intrare în tabelul istoric cu un marcaj de timp și câmpuri modificate.
    5) Notificări - Telegram bot trimite un mesaj despre noile achiziții relevante, nu mai mult de 1 notificare per achiziție, cu câmpuri scurte și un link. Comanda /health returnează, de asemenea, statistici ale ultimei rulări (cât a fost colectat de sursă, câte erori, timp).
    6) Operare - lansare prin cron sau cronometru systemd, logare la un fișier, mesaje de eroare clare pentru fiecare sursă.

    Ieșire specifică: un depozit cu cod sursă, configurație (env/ini/yaml), migrări de schemă SQL, instrucțiuni pentru rularea pe Ubuntu și un exemplu de configurare a filtrului de relevanță.

    Criterii de acceptare măsurabile:
    - În timpul unui test de rulare, în decurs de 24 de ore, analizatorul colectează cel puțin 95% din anunțurile din rezultatele căutării pentru fiecare sursă în primele 3 pagini (verificat prin calcul manual pe un eșantion de 30 de anunțuri per sursă).
    - Duplicatele din baza de date nu depășesc 2% din numărul total de înregistrări per rulare (verificați folosind o cheie unică și euristica de deduplicare).
    - Lansarea repetată pe aceleași filtre nu creează noi înregistrări de achiziție dacă nu există modificări în surse, iar istoricul este actualizat doar atunci când câmpurile sunt modificate efectiv.
    - Timpul complet de rulare pentru toate sursele nu depășește 45 de minute pe un server de 2 vCPU/4 GB RAM, cu o limită de până la 3 sarcini paralele.
    - Jurnalele conțin statistici separate în funcție de sursă și coduri de motiv de eroare (timeout, blocare, analizare, structura schimbată).

    În plus: voi furniza o listă de ETP-uri, exemple de URL-uri, cuvinte cheie și acces la baza de date de testare după ce am convenit asupra abordării și structurii datelor.
  • How would you rate this task?

    Sign in to leave your rating.

    Total ratings: 0

Oferta ta

Încă nu ai trimis o ofertă pentru această comandă.
Apasă „Trimite o ofertă” pentru a o trimite.

Aveți nevoie de o sarcină similară?

Dacă acest proiect este apropiat de ceea ce aveți nevoie, puteți consulta servicii gata în categorie sau publica propria sarcină cu bugetul, termenul și cerințele necesare.

Proiectul „Analizator de oferte cu ETP (JS-render, antibot) cu normalizare și încărcare în alerte PostgreSQL și Telegram” poate fi folosit ca referință pentru propriul brief: ce trebuie făcut, ce rezultat este necesar și ce buget să stabilești.