Category: Python

Ką rinkčiausi duomenų ūkyje

Darbas, Programavimas, Python, , , ,

Kuo didesnis klientas, tuo mažiau laisvės technologijų pasirinkimui – dažniausiai dirbi tais įrankiais, kurie jau naudojami organizacijos viduje. Naujų programavimo kalbų, operacinių sistemų ar duomenų bazių klientams nesinori, nes kažkam organizacijos viduje tas naujas technologijas reikės prižiūrėti. Jei visas tavo lėktuvų parkas sudarytas iš Airbusų, įsigyti vieną Boeingą „pažaidimui“ nelabai protinga. Tačiau kartais sveika pagalvoti, kokias technologijas rinktumeisi, jeigu viską darytum nuo nulio.

Duomenų bazė

Anksčiau buvau pratęs dirbti su MySQL – greita, paprasta, lengva administruoti. Šiuo metu rinkčiausi Postgres, nes nebegaliu gyventi be Common Table Expressions, o MySQL jų palaikymas dar tik labai šviežias. SQL kodas, rašomas su WITH ... AS ( ... ) yra žymiai lengviau skaitomas, o tai labai svarbu, jeigu tenka rašyti sudėtingas ne vieno šimto eilučių SQL užklausas. Be to, Postgres turi begales papildomų funkcijų ir galimybių – kuo reikia sudėtingesnės verslo logikos, tuo mažiau pradeda tikti MySQL.

Savaime suprantama, galima naudotis ir MS SQL Server ar Oracle, tačiau lemiamas argumentas visgi yra kaina.

Programavimo kalba

Pradėjęs nuo Perl, jaunystėje daug ko daręs su PHP, po to perėjęs prie Ruby, kažkiek krapštęs R, nesusigyvenęs su Scala, šiuo metu viskam rinkčiausi Python. Daug reikiamų bibliotekų duomenims maigyti, nuo paprasto ETL iki dirbtinio intelekto ir beveik bet kokio machine learning (na, galbūt dar vis kokiais specifiniais statistiniais algoritmais čia jį lenkia R, bet universalumu R tikrai nusileidžia). Be to, python kuo toliau, tuo labiau populiarėja – tai ne eksperimentinė nišinė kalba, kurią gerai supranta tik sauja žmonių: tai svarbu, norint užtikrinti, jog kažkada kas nors iš tavęs galės sklandžiai perimti projektą.

Operacinė sistema

Labai dažnai dirbant Microsoft ekosistemoje tenka dirbti su Windows serveriais – nieko labai blogo, bet žymiai labiau esu pratęs prie Linux (ir daugiausiai Debian / Ubuntu). Konsolėje jaučiuosi kaip namie, juodas ekranas man jaukus ir savas, todėl rinkčiausi būtent jį. Bet kartu labai suprantu, kad administruoti naują operacinę sistemą to niekad nedariusiam yra labai sudėtinga, tad jei visi kompanijoje naudoja Windows, naujų žvėrių zoosode matyt nereikėtų.

Darbų dirigentas

Manau, kad įvairiems ETL darbams planuoti ir diriguoti naudočiau Apache Airflow. Rašyta python, turinti daug galimybių, aprėpianti beveik visus įmanomus poreikius, po truputį tampanti industrijos standartu (bent jau atviro ir nemokamo kodo ekosistemoje). Taip, reikia rašyti kodą, bet tai, mano nuomone, privalumas. Daug programuotojų gal ir nustebs, bet labai dažnai drag&drop įrankiai didelėse organizacijose labai vertinami, nes jie suteikia (dažniausiai nepasiteisinančią) viltį, jog duomenų ūkį lengvai galės administruoti koks nors net SQL nemokantis stažuotojas iš finansų analizės poskyrio. Paprastiems dalykams gražūs pele stumdomi daiktai gal ir veikia, bet kai viskas susivelia į vieną didelį neišnarpliojamą kamuolį… (taip, piktai žiūriu į tave, Alteryx).

Kiti būtini dalykai

git. Būtina naudoti git. Bet kokia forma (github, gitlab, bitbucket, savo pačių daryta, bet kokia…), bet būtina naudoti kodo versijavimą. Niekaip nesuprantu, kodėl didelėse organizacijose kodo versijavimas toks retas. Vis dar kodas taisomas tiesiai serveryje, vis dar dažnai kokioje nors direktorijoje kaupiasi programos pavadinimu load_foo_v12.192_final_do_not_use.sql. Tikriausiai kultūriškai tai ateina iš Excelio ir įvairiausių „vartotojui draugiškų“ drag&drop įrankių – lengvai jų į versijavimo sistemą nesudėsi.

Testai. Jeigu versijavimo sistemas tai dar pas klientus galima kur nors rasti, testus duomenų bazėms bei ETL programoms labai mažai kas rašo. Kuo mažiau kompanijoje inžinierių, tuo mažesnė tikimybė, jog kodas bus tikrinamas testų pagalba.

Lietuvos miestų gatvės pagal pasaulio šalis

Analizė, Lietuva, Programavimas, Python, , ,

Neseniai užtikau įdomią JAV bei kitų pasaulio didmiesčių gatvių orientacijos analizę, darytą vienu mano mėgstamiausių python modulių osmnx. Kadangi kodas viešas, tai buvo nesunku tą patį padaryti ir Lietuvos miestams.

Kaunas ir Vilnius – gana chaotiški, o kitur vyrauja aiški kvartalinė sistema

Kuo senesnis miestas, tuo didesnis senamiestis, o šie dažniausiai būna chaotiški. Naujesniuose miestuose daugiau vyrauja aiški kvadratinė kvartalinė sistema. Buvo įdomu tai, kad dažniausiai ji ne tiksliai šiaurės-pietų bei rytų-vakarų krypties, o apie 20 laipsnių pasukta pagal laikrodžio rodyklę (Alytus, Gargždai, Kretinga, Kėdainiai, Marijampolė, Mažeikiai, Neringa, Palanga, Telšiai – ypač Žemaitijoje). Tobulai pagal pasaulio šalis orientuoti Elektrėnai (kuo tikriausiai nereiktų stebėtis) ir Utena, Visaginas ir Šiauliai išsidėstę įstrižai žemėlapio šalims.

Lietuvos miestų gatvės

Lietuva, Pastebėjimai, Python, , , ,

Miestų žemėlapiai mane traukia kaip blizgučiai šarkas: nuo pat mažų dienų mėgau ištisas valandas juos tyrinėti vedžiodamas pirštais autobusų maršrutus, šnabždėdamas sau gatvių pavadinimus ir įsivaizduodamas miesto gyvenimą pagrindinėse sankryžose. Tad Rūtai užrodžius naują Pitono modulį OSMnx, kuris leidžia iš openstreetmaps duomenų nupiešti labai estetišką Allan Jacob knygos „Great Streets“ stiliaus žemėlapį negalėjau susilaikyti jo neišbandęs. To rezultatas: visų Lietuvos miestų centrinės kvadratinės mylios žemėlapiai.

Tokiuose žemėlapiuose dažniausiai į akį krenta kvartalų simetrija ir tvarka, o Lietuvoje to beveik neįmanoma rasti. Lietuvoje nedaug miestų, kuriame stipriai būtų padirbėjusi miesto planuotojo liniuotė: neskaitant įvairausių sodų ir garažų bendrijų itin tvarkingą smulkų gatvių tinklelį galima rasti Klaipėdos senamiestyje, ir tik Palanga, Šalčininkai ar Tauragė išlaiko daugiau mažiau kvadratinių kvartalų tinklą. Stebėtis nereikėtų: miesteliai kūrėsi gana seniai ir ne tuščiose vietose, dar prieš bandant natūralų procesą suvaldyti miesto architektams.

Tauragė išplanavimu panaši į Amerikos miestus

Itin įdomus naujai projektuotų miestų gatvių tinklas: Elektrėnai atrodo lyg įsprausti į vienos gatvės žiedą. Tokį patį dirbtinio suspaudimo įspūdį daro ir Ventos žemėlapis – vienoje kelio pusėje senoji individualių namų Venta, o kitoje – daugiaaukščių rajonas.

Senoji Venta vienoje kelio pusėje labai skiriasi nuo naujosios Ventos kitoje

Vienas svarbiausių faktorių, nulemiančių gatvių tinklą yra vandens telkiniai ir upės: jos skiria miesto dalis, arba atvirkščiai – įspraudžia į rėmus (pvz. Trakai). Nors kartais tokią funkciją atlieka geležinkelis – Varėna lyg nurėžta bėgių linijos.

Įsprausti tarp ežerų Trakai

Visgi man gražiausias Lietuvos miestų gatvių tinklas yra Zarasuose. Reikės kada apsilankyti.

Zarasų gatvių planas

Čia yra dar bent šimtas kitų žemėlapių. Tereikia pasirinkti miestą.

Zylių stebykla

Programavimas, Python, , , ,

Man patinka vis ką nors naujo išmokti, o mokytis geriausia ką nors darant. Taip visai netyčia užgimė Rube Goldbergiško stiliaus zylių stebėjimo projektas, kuris savyje sujungė norą išsibandyti python kalbos bibliotekas konvoliuciniams neuroniniams tinklams su idėja viską padaryti Amazon AWS debesies infrastruktūroje be jokių dedikuotų serverių vien tik su Lambda funkcijomis. Suprantu, kad tiems, kas su tokiais dalykais nesusiduria tai skamba lygiai tiek pat įdomiai kiek man skambėtų nauja variklio vožtuvo modifikacija paskutiniame BMW modelyje (tikiuosi nesuklydau, kad vožtuvai kažkaip susiję su varikliais, non?), bet trumpai tariant, projektas tapo sudėtingas dėl to, kad norėjosi prie lesyklos atskridusias zyles registruoti automatiškai, o tam vien judesio daviklio neužtenka: kartais dėl didelio vėjo juda pati lesykla, kartais užfiksuojama pravažiuojanti mašina, o kartais vaizdas pasikeičia, nes atidarius balkoną aprasoja stiklas. Taigi, reikėjo sistemą „išmokyti“ nuspręsti, ar kadre šiuo metu yra zylė. Tiesa, pati sudėtingiausia dalis pasirodė esanti zylių atpažinimo funkcijų perkėlimas į debesį: nes juk kam daryti viską įprastai, jeigu galima kuo sudėtingiau. Bet rezultatas mane džiugina: gal ne tiek dėl to, kiek kasdieną priskaičiuoju zylių, o dėl įgytų žinių ir patirties. Apie Amazono debesį ir kaip apeiti jo ribotumus sužinojau tikrai daug.

Keletas detalių tiems, kam jos įdomios: balkone, prie zylių lesyklos, stovi Orange Pi kompiuteris su web kamera, kurioje sukasi motion, o jis veikia kaip judesio daviklis. Atsiradus judesiui, daromos jpg nuotraukos ir siunčiamos į Amazon S3 kibirą, o čia yra trigerinama lambda funkcija, kuri išima iš paveiksliuko jo foną (faktiškai yra paskaičiuojamas skirtumas tarp apdorojamo paveiksliuko ir foninio paveiksliuko, kuriame tikrai nėra zylės). Taip paruoštas ir sumažintas paveikliukas per Amazono SNS servisą atiduodamas kitai lambda funkcijai, kuri perleidžia paruoštą paveiksliuką per ištreniruotą neuroninį tinklą ir išspjauna atsakymą, kiek, jo nuomone, paveiksliuke yra zylių. Šie atsakymai kaupiami SQS eilėje iki tol, kol motion mano, kad judesys baigėsi ir į S3 kibirą įkelia viso judesio vaizdą. Tai trigerina trečią lambda funkciją, kuri paskaičiuoja vidutinį zylių skaičių SQS eilėje, ir, jei jis gana didelis, statinėje svetainėje apie tai padaro naują įrašą. Eilė išvaloma ir viskas prasidės iš naujo tada kai tik bus užfiksuojamas naujas judesys.

Zylių stebėjimo sistema per Amazon debesį

Antro rinkimų turo prognozė pasitelkiant neuroninius tinklus

Analizė, Lietuva, Pastebėjimai, Python, , , ,

Pirmiausia turiu įspėti: nemanau, kad reikėtų į gautus rezultatus žiūrėti labai rimtai. Neuroninio tinklo mokymui naudojau tik 2012-ų metų Seimo rinkimų apygardų duomenis, tad imtis labai nedidelė, o tai turėtų lemti ir gana nemažą paklaidą prognozėse. Galbūt tikslesnių rezultatų būtų galima tikėtis naudojant apylinkių, o ne apygardų duomenis.

Prognozuoti šių metų rezultatus iš 2012-ų metų duomenų nelengva ir dėl stipriai pasikeitusio partijų populiarumo: žalieji valstiečiai prieš ketverius metus nebuvo labai patrauklūs rinkėjams, o ir Skvernelio atsiradimas labai šią partiją pakeitė. Įdomu tai, kad Darbo partijos bei tvarkiečių kritimas iš aukštumų gana gerai atsispindi neuroninio tinklo rezultatuose: jiems prognozuojama laimėti mažiau apygardų nei jie šiuo metu pirmauja.  Kad ir kaip ten būtų, gavau tokį rezultatą:

Prognozė Dabar pirmauja
LVZS 24 21
TSLKD 24 22
LSDP 9 10
LRLS 5 4
LLRA 3 3
TT 2 4
KITI 1 2
DP 1 3
NEP 2 2

Neuroninis tinklas „išmoko“, jog stiprus lenkų pirmavimas apygardoje dažniausiai lemia ir pergalę antrame ture. Algirdui Paleckiui pergalė neprognozuojama, nes istoriniai pernai metų duomenys rodo, jog „Frontui“ ne itin sekėsi – bet jo puikus pasirodymas pirmame ture tikriausiai buvo netikėtas ir daugeliui politikos analitikų. Keisčiausia prognozė, kuria sunku patikėti yra 52-oje Visagino-Zarasų apygardoje, kurioje antrame ture kausis Darbo partija su tvarkiečiais (pergalė prognozuojama Darbo partijai, nors stipriai pirmauja tvarkietis Dumbrava). Keistoka, bet gal ir logiška 40-osios Telšių apygardos prognozė, kur stipriai pirmaujantis darbietis turi mažai šansų atsilaikyti prieš valstietį Martinkų. Kaip jau minėjau, Darbo partijai šis modelis daug šansų nepalieka. Visas apygardų sąrašas su prognozuojamais nugalėtojais ir tikimybėmis, kad nugalės pirmaujantis:

Turint nedaug istorinių duomenų tikriausiai labiau pasitikėčiau politikos ekspertų prognozėmis konkrečioje apygardoje arba modeliuočiau tikimybes kiek kurios partijos rėmėjų ateis į antrą turą bei palaikys ne savo partijos kandidatą: būtent tokį modelį ruošia WebRobots komanda, kuri leido man pasinaudoti jų surinktais iš VRK duomenimis. Idėja patreniruoti neuroninį tinklą ir kilo susidūrus su problema ar nebūtų galima kaip nors statistiškai išskaičiuoti tikimybių, kiek, tarkim, socialdemokratų palaikytų konservatorių kandidatą jei jis būtų likęs prieš darbietį. Taip pat galima pažiūrėti į Vaidoto Zemlio prognozes.

Post Mortem

Rezutatai buvo stipriai kitokie, nei buvo tikimasi: daugiausiai prašauta (tikriausiai dėl to, kad 2012-aisias valstiečiai pasirodė ne itin įspūdingai) su LVŽS ir TSLKD. Tam tikros tendencijos buvo teisingos – Darbo partija, Tvarka ir Teisingumas bei Socialdemokratai iš tiesų gavo mažiau mandatų nei buvo pirmaujama po pirmo turo, tuo tarpu liberalai sugebėjo laimėti daugiau apygardų nei pirmavo po pirmo turo, tačiau šių pokyčių mastas buvo žymiai (žymiai žymiai) didesnis. Iš viso, neuroniniai tinklai sugebėjo atspėti 48 apygardas (67% tikslumas). Palyginimui – rankomis dėliotas Webrobots komandos modelis pasiekė 80% tikslumą. Tiesa, atmetus kai kuriuos nelogiškus neuroninio tinklo siūlymus, kurie plika akimi atrodė keisti ir pataisius prognozę Dainavos apygardoje dėl Vinkaus skandalo (ko iš 2012-ųjų duomenų niekaip nebuvo galima žinoti), buvo galima pasiekti maždaug 75% procentų tikslumą. Ne kažką, bet šis tas.

Skaičiuojant modelio patikimumą, dažnai žiūrimas plotas po Receiver Operating Characteristic (ROC) kreive (kuo gerenis modelis, tuo jis turėtų artėti link vieneto). Štai modelių palyginimai:

Area under ROC curve
Neuroninis tinklas (tikimybės) 0.597143
Webrobots modelis 0.708095
Neuroninis tinklas (binarinis) 0.549048
Laimės pirmaujantis 1 ture 0.500000
Laimės pirmaujantis daugiamandatėje 0.487619

O čia pačios ROC kreivės:

Skirtingų modelių ROC kreivės

 

Skaitykite toliau