Přesunout bota na ML (2021)

[honzajavorek]

Toto je veřejný plán přesunu bota na ML, který slouží mě a @miiila k organizaci práce.

📖 Situace

Scrapery vytváří tabulku employments, která kumuluje stará data ze záloh a měla by být ústředním centrálním mozkem pracovních nabídek. ML (čtení a zapisování) nebo API pro Czechitas (jen čtení) by mělo používat tuto tabulku, scrapery by měly ukládat do této tabulky, apod. V tabulce jsou kanonická historická i současná data, bez ohled na jejich následnou „užitečnost“. Zapisuje se tam, zda byla nabídka vybrána nebo vyhozena. Pokud v tabulce dochází ke změnám, do scraperu backups je potřeba dopsat adaptér, který „migruje“ staré tabulky, tedy vypořádá se se změnami a překlápí stará data do nových struktur.

To, které inzeráty se v daném buildu dostanou na webovky nebo do klubu, by měly řešit jiné tabulky, 1:1 navázané na tuto a vytvořené v každém buildu nově, ad hoc, podle aktuálních podmínek. Robot se podívá do mých Google Sheets, spojí si data s employments tabulkou a vytvoří do jiné splachovací tabulky 1:1 záznamy k inzerátům, které mají být zrovna vyvěšeny.

Ze záloh se do employments načítají data jak z minulých tabulek employments, tak jobs a jobs dropped. Nenačítá se do ní ale nic z aktuálního buildu, je to vždy jen z minulých buildů, z těch záloh. Zároveň jsem vytvořil zvlášť tyhle employments, aby mi dál fungovaly jobs postaru a nemusel jsem měnit vše najednou. Takže je v tom trochu binec. K tomu všemu ten backups scraper jede strašně dlouho a nesmírně to prodlužuje build. Bere teď všechny zálohy, které najde, snad všechny za poslední měsíc.

Prvním naším cílem tedy bude konsolidace, aby se vlastně dalo něco přidat a my se z toho úplně nezbláznili. Už teď je to tak komplikované, že je problém to udržet v hlavě. Až se to vyčistí, můžeme přidat ML, což pak už bude vlastně poměrně snadný úkol.

Jednak bude potřeba nějak sloučit employments a jobs a vyřešit, aby se employments nestahovaly věčnost. Potom máme 🌈 a můžeme přidat učení ML, apod. Pak můžeme ladit, tedy vyhodnocovat palečky z Discordu, nebo do Discordu házet i potenciálně juniorní nabídky (jednoduše, v titulku slovo junior), které ML vyhodnotilo jako že ne a vybraní lidé na nich budou hlasovat a tím hlídat i zahazování správných nabídek.

🚜 Nejkratší cesta k výsledku

• Zefektivnit backups scraper, který načítá data do employments.
  • [x] Analyzovat problém a navrhnout řešení
    Tipy 💡

    Tím, že se tabulka kumuluje, mělo by vlastně stačit načíst poslední zálohu, ne posledních 30. Jenže employments mají data o jeden build zpět (jobs a jobs dropped se načítají až zpětně) a taky se může build nějak pokazit. Co mě napadlo? Ve scraperu jít od nejnovějších záloh po nejstarší a hlídat, kolik nových inzerátů se uložilo do tabulky. Když už to jen mlátí prázdnou slámu a vytváří dokola duplicity, zastavit načítání dalších záloh. Problém je, že o tabulce scraper nic neví (SRP) ukládání se děje až v pipelines, konkrétně v save.py. Jak scraper během scrapování zjistí, co se děje v databázi a že už nemá pokračovat? Možná by mohl před stažením každé zálohy po vlastní ose mrknout na počet řádků v tabulce employments a srovnat s tím, kolik jich tam je po stažení a když se to už nemění, tak přestat? 😬 Ale je to teda dost náhodný coupling v asynchronním systému, kde data typicky tečou jen jedním směrem...
  • [x] Realizovat řešení a zkrátit tím běh employments na co nejmenší čas, se zachováním funkčnosti kumulování dat
• Udělat z employments plnohodnotnou stínovou infrastrukturu
  • [x] Mít employments tabulku, kam se ukládají věci z minulých backupů, tzn. všechny nabídky, které prošly výběrem, i které neprošly kvůli nedostatečné junioritě, zpětně do historie (nabídky, které neprošly kvůli něčemu jinému, nás nezajímají a neuchovávají se)
  • [x] Spouštět jobs první a nechat je naplnit databázi s jobs. Vytvořit employments scraper, který to bere z téhle db a vyhazuje jako employments. Za ním je pak nová pipeline. Až budeme překlápět, místo tohoto temporary scraperu se prostě zapojí původní scrapery do téhle pipeliny tak, aby vyhazovaly rovnou employments.
  • [x] Duplikovat pipelines do employments a postupně portovat věci na nový systém, zatímco starý jede a nešťourá se do něj.
  • [x] Employments pipeline bude jen vyhazovat formální nesmysly (required_fields_filter, short_description_filter, broken_encoding_filter, language_filter) a pak vše prostě uloží. Možná ještě dočistí (description_parser, language_parser, features_parser, gender_cleaner, emoji_cleaner, employment_types_cleaner). Další záležitosti se budou dít až zpětně na datech v databázi, ne ve Scrapy pipeline. Scrapy bude scrapovat a generovat data, ale nebude je nijak vyhodnocovat, kromě vyhazování zjevných nesmyslů, maximálně akorát začišťovat. Tím pádem mohou scrapery do databáze vložit cokoliv, ať už je to z backupů, z JG Google Sheets, JG MkDocs, nebo random z internetu. Snese to vše, vyhodnocení je později.
  • [x] Mít zvlášť skript na zhodnocování, zda je něco juniorní nebo ne, ať už podle regulárů nebo podle ML.
  • [x] Mít splachovací "listing" tabulku, která je 1:1 navázaná na employments a představuje věci, které se vypisujou na web/do discordu jako aktuální relevantní nabídky. To, jak se tvoří, je náhradou např. za validity_filter a hodně se orientuje podle toho, co bylo vyhodnoceno jako juniorní a jaké je datum.
  • [x] Pipeline na company logo odstranit, ukládat jen raw a udělat zvlášť scrapery na company/logo, které budou vytvářet novou splachovací tabulku, která je jen pro věci z "listing" tabulky. Totéž favicon pro JG nabídky.
  • [x] Pipeline na location odstranit, ukládat jen raw a udělat zvlášť scrapery na location, které budou vytvářet novou napojenou splachovací tabulku, která je jen pro věci z "listing" tabulky.
  • [ ] Monitoring scraperů jak je teď na jobs nějak vymyslet a zapojit pro employments scrapery.
• Sloučit employments a jobs
  • [x] Posílat apply eventy do Simple Analytics
  • [x] Jakmile nebude žádný aktuální aktivní inzerát, změnit způsob, jak se posílají e-maily inzerentům, využít Simple Analytics místo Google Analytics, metriky už napojit na employments?!
  • [x] Odebrat kompletně Google Analytics
  • [x] Překlopit maily, web a Discord na to, aby brali a zobrazovali data z employments a ne z jobs.
  • [x] Překlopit scrapery na employments.
  • [x] Smazat staré tabulky a veškerý původní binec. Přejmenovat vše z employments zpátky na jobs.
• Znovu nahodit ML, a to i s trénováním modelu
  • [ ] Zkontrolovat, co z ML přežilo Honzovo předělávání
  • [ ] Doplnit co chybí co se týče vyhodnocování, ukládat do kumulované tabulky jako skóre
  • [ ] Doplnit trénování modelu a přežívání/kešování/zálohování modelu mezi buildy
• Podívat se pořádně na zpětnou vazbu z Discordu
  • [ ] False positives: Vyhodnocovat jak nejlépe interpretovat palečky
  • [ ] False negatives: Napsat funkci, která dokáže vypsat z tabulky inzeráty vyhodnocené v ML jako špatné, ale které mají např. v title slovo junior
  • [ ] False negatives: Zřídit kontrolní místnost, kam budou tyhle nabídky padat, doladit zpětnou vazbu z místnosti skrze reakce

🚫 Koš s body, které jsme objevili, ale teď je dělat nebudeme

• [ ] Vytvořit administraci k employments, asi Datasette.
• [ ] (prozatimní bot, aby tady byl připravený seznam)

[honzajavorek]

Jen tak pro info, teď ty employments zaberou 27.3min. Stahování inzerátů v jobs je 23.7min, ale to je řekněme adekvátní. Takže loadování tabulky ze záloh je pomalejší než všechny scrapery na pracovní nabídky :D

[honzajavorek]

Tak teď to (s keší teda, což není úplně fér srovnání), zabralo 0.9 minut místo 27.3 minut. Odškrtávám si první bot.

[honzajavorek]

Zavírám, máme teď https://github.com/honzajavorek/junior.guru/issues/862