Ką rinkčiausi duomenų ūkyje

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.

Duomenų bazių testavimas

Prieš keletą dienų užtikau patikusį straipsnį apie automatizuotus duomenų bazių testus. Programiniam kodui jau senokai tapo įprastinė praktika rašyti testus, bet duomenų bazių struktūra testuojama ne visada. Tiesa, gerai sutvarkytoje duomenų bazėje įmanoma sudėti daug saugiklių: stulpeliams uždėti apribojimus, išorinius raktus ir panašiai, tačiau bendras požiūris į duomenų teisingumą bei validumą vis tiek reikalingas.

Autorius siūlo duomenis testuoti trijose vietose: pirminių šaltinių lygyje, tik juos sukėlus į duomenų bazę ir jau po verslo logikos transformacijų. Šis testų sąrašas atrodo visai nebloga pradžia:

  • Ar visi pirminiai raktai lentelėse unikalūs?
  • Ar [svarbiame stulpelyje] nėra null reikšmių?
  • Ar visi išoriniai raktai egzistuoja lentelėse kaip pirminiai raktai (be dublikatų, ir pan. – referencinis integralumas)?
  • Ar skaitinės duomenų reikšmės neiššoka iš tikėtino reikšmių rėžio?
  • Ar agreguoti duomenys atitinka detalesnių duomenų informaciją (ar čekio suma atitinka atskirų prekių sumai čekyje)?
  • Ar yra visi stulpeliai, kurie bus naudojami galutinėse lentelėse?
  • Ar įmanoma be klaidų paleisti dažniausiai pasitaikančias verslo užklausas?

Dar prie šio sąrašo pridėčiau patikrinimą, ar eilučių kiekis įvairiose duomenų bazės lentelėse yra toks, koks ir tikėtasi – labai dažnai dėl kokios nors lentelių jungimo klaidos duomenys susidublikuoja.

Rožės monitoringas su Raspberry

Noriu pasigirti: žmonos paskatintas pirmą kartą su Raspberry Pi nuveikiau kažką sudėtingesnio nei vien tik pajungiau prie jo kamerą. Jai paklausus, ar nebūtų įmanoma sukonstruoti kokio nors prietaiso, stebinčio rožės dirvos temperatūrą, suėmė savotiškas azartas, ir jau kitą dieną stovėjau prie visiškai neaiškių daiktų kupinos vitrinos elektronikos komponentų parduotuvėje. Kažkokie sensoriai, laidukai, mikroschemos, montažinės dėžutės, rezistoriai ir kiti ten parduodami dalykai – nieko nesuprantu, nieko nežinau. Ar čia man reikia to, ar kito, ar skiriasi kuo DHT-22 nuo DHT-11, kokių ir kiek man reikia rezistorių (o jų iš vis pasirodo reikia?), o jei neturite BCM3008 mikroschemos kur Youtube mačiau kad man reiks, tai ar tiks kas nors kitas? Sakot ADC1115? Jei reiktų apie Hėgelio filosofiją pasikalbėti čiuvašų kalba, manau, kad jausčiausi pasimetęs mažiau nei toje elektronikos parduotuvėje atsakinėdamas į konsultanto klausimus.

Sistemos bandymai

Visgi nukovęs glėbį keistų komponentų, pergalėjau save, praleidau kelis vakarus prie įvairiausių forumų bei straipsnių internete ir sukonstravau kažką veikiančio. Prie Raspberry prijungiau oro temperatūros ir drėgmės jutiklį (net kažkiek apygraibomis supratau, kodėl dar prie jo reikia pajungti rezistorių) ir dirvos drėgmės sensorių. Pastarasis duoda analoginį signalą, tad reikėjo prijungti ir analoginio-diskretinio signalo konvertavimo mikroschemą. Kol kas dar jos nelitavau, tad bet koks sujudinimas dažniausiai reiškia, jog vėl kažkas nusimušė. Buvo šiek tiek vargo.

Nustebau, kad visgi tie visokie su geležimi ir mikroschemomis susiję dalykai buvo ganėtinai nesudėtingi – programavimas tikriausiai sunkiau įveikiamas niekada su tuo nesusidūrusiems. O čia tik reikia teisingai sujungti laidukus, nieko sudėtingo. Ir dar gauni tam tikrą pasitenkinimą, kai matai, jog fiziškai tavo padarytas daiktas veikia.

Viso to pasekmė: rožės monitoringo svetainė, kurioje beveik realiu laiku galima matyti balkone esamą oro temperatūrą, santykinę drėgmę ir dirvos „prilaistymo“ procentą. Pastarasis kol skaičiuojamas gana komplikuotai, mat daviklis duoda įtampą, pagal kurią sukalibruoti drėgnumą reikia pačiam: 100 proc. buvo tik dirvą paliejus, o 0 proc atitiko sensoriaus įtampą jį ištraukus iš dirvos. Tikėtina, kad kažkur ties 50 proc drėgnumu jau galima bus siųsti įspėjimą, jog rožę reikia vėl laistyti. Matyt, reikės ir kitų korekcijų: dieną kylant temperatūrai, dirvos pralaidumas elektrai didėja, tad sensorius mano, jog dirva tampa drėgnesnė.

Sujungtos mikroschemos

Naudotos detalės: ADC1115 mikroschema, DHT–22 temperatūros sensorius, YH–69 dirvos sensorius, Raspberry Pi B series.