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.