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.

Duomenys nebūtinai sukuria daug verslo vertės

Šiandien užtikau gerą straipsnį apie tokį požiūrį, su kuriuo, deja, gana dažnai susiduriu kompanijose: reikia surinkti kuo daugiau duomenų, viską bet kaip sudėti į duomenų bazę ir iš to vis tiek gausis kas nors gero. Na, žinai, gi ten machine learning, dirbtinis intelektas, visa kita gi šiais laikais. Svarbu duomenų būtų.

Didesnėse kompanijose tai dažnai galima suprasti: pinigų projektams kaip ir yra, norisi užsidėti varnelę, kad „kažką darai su dirbtiniu intelektu“, net jei ir nieko nesigaus, tai bent jau bandysi. Nesvarbu, kad nelabai aišku, kokia reali to nauda verslui, ir kas bandoma pasiekti. Bet tai, pasirodo, dažnai pasitaiko ir tarp startuolių: vietoje to, kad pastangas skirti klientų paieškai ar geresniems procesams, per daug koncentruojamasi į duomenis, lyg jie būtų ta magiška burtų lazdelė, kuri visus staiga padarys milijonieriais.

Straipsnyje galima rasti gerų patarimų ir įžvalgų, kurių niekada reiktų nepamiršti, dirbant su duomenų projektais:

  • Kokie yra duomenų gavimo kaštai? Būtina bent jau apytiksliai paskaičiuoti, kiek kainuoja visi duomenų inžinieriai, visi vadovai, kuriems reikia ataskaitų ir planų, visi serveriai, infrastruktūra, visų vadovų laikas, kurį jie praleidžia kasdieną stebėdami analitines ataskaitas vietoje to, kad galbūt galvotų, kaip užkariauti naujas rinkas ir geriau padėti klientams.
  • Kokią naudą mes gauname iš duomenų? Kas atsitiktų, jei vienos ar kitos ataskaitos ar algoritmo nebūtų? Kiek verslo vertės susideda iš to, kad turime tikslesnę informaciją ir ją galime greičiau pasiekti? Taip neretai galima suprasti, kad visgi lengviau paskambinti klientui ir jo paklausti, kas jį mūsų svetainėje trikdo nei valandų valandas praleisti Google Analytics bandant išskaityti gudrias įžvalgas.
  • Per kiek duomenys pasensta? Dažnai net nepastebima, kad kelių metų duomenys jau niekam neįdomūs ir netgi nelabai naudingi: klientų poreikiai pasikeitė, elgsena kitokia, žiūrėk jau ir Facebook ne toks visiems įdomus, aplinka nujudėjo visai kitur. Kai supranti, kad tavo duomenys labai greitai sensta ir vien jų kiekis nesukuria tvaraus konkurencinio pranašumo (nes bet kas, investavęs metus ar kitus darbo gali irgi įgyti ne ką mažiau panašių duomenų), jų nuolatinis atnaujinimas ir kiekybės siekimas vien dėl kiekybės nušvinta kitomis spalvomis. Gal verčiau mažiau duomenų, bet labai gerai atrinktų? Ir gal užtenka logistinės regresijos ir visai nereikia neuroninio tinklo su dešimt tūkstančių faktorių?

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.

Neapdorotų duomenų nebūna

Yra toks gana gajus mitas, kad turint „žalius“ neapdorotus duomenis, galima nesunkiai padaryti objektyvias išvadas – juk neapdoroti duomenys turėtų kalbėti už save, jie neturėtų būti „sutepti“ šališkos žmogiškos nuomonės bei išankstinių nusistatymų. Kuo daugiau neapdorotų duomenų, tuo objektyvesnės išvados. Deja, visiškai neapdorotų duomenų nebūna. Jau pats faktas, kad kažkas juos rinko, reiškia, kad kažkas padarė sprendimą jais domėtis: o kodėl rinko būtent taip, o ne kitaip? Kodėl rinko tokius, o ne anokius? Kodėl skaičiavo žmones, o ne mašinas; kodėl išmetė iš skaičiavimų vaikus ar žmones vežimėliuose, kodėl nusprendė, jog tamsoje duomenys nepatikimi? Net jei duomenis renka automatiniai prietaisai (tarkim, kas kažkiek laiko skaičiuojama temperatūra), duomenys fiksuojami su aiškia paklaida, kuri nustatyta matavimo įrenginio specifikacijoje – pats įrenginys kažkiek matavimą apvalina, kažkiek veikia nepatikimai už tam tikrų temperatūros rėžių. Jei nežinosi šio konteksto, gali padaryti išvadą, kad temperatūra būna stabili (tiesiog nematai temperatūros pokyčių, mažesnių nei vienas laipsnis) ar ji niekada nenukrenta žemiau -20˚C.

Ypač sunku teisingai interpretuoti skaičius, kurie susiję su žmogumi. Nusikaltimų skaičius gali augti jau vien dėl to, kad pasikeitė suvokimas, kas yra nusikaltimas (tarkim, anksčiau gal buvo visuomenėje priimta, kad vaikus mušti ir tai nebuvo laikoma nusikaltimu). BVP ar infliacijos skaičiai gali kisti dėl metodologinių paklaidų. Pajamų duomenys, surinkti apklausos būdu, smarkiai skirsis nuo duomenų, gautų iš mokesčių inspekcijos.

Simply put, the context of data — why it was collected, how it was collected, and how it was transformed — is always relevant. There is, then, no such thing as context-free data, and thus data cannot manifest the kind of perfect objectivity that is sometimes imagined.

https://www.thenewatlantis.com/publications/why-data-is-never-raw

Šiuolaikinė „didelių duomenų“ mada bando įteigti, jog žali duomenys yra patys objektyviausi, nes jie neužteršti išankstinėmis nuostatomis. Kuo daugiau tokių duomenų, kuriuos galima sušerti taipogi labai objektyviam algoritmui, tuo teisingesnės išvados – ir tam net nereikia jokių ekspertų, mat jie tik įneš savo (nebūtinai teisingą) išankstinę nuomonę. Žmonėmis negalima pasitikėti dėl jų subjektyvumo: nuo to gali išgelbėti tik daugybė duomenų. Bet toks pasaulio vaizdas visgi yra utopinis: jei atvirai nedeklaruoji savo prielaidų, nereiškia, jog jų nedarai. Nematomos subjektyvios prielaidos duomenyse atsiranda jau jų rinkimo procese, ir to niekaip neišvengsi. Ką matuoji, tą ir optimizuosi. Duomenys už save nekalba, jie atkartoja duomenų rinkėjų nuomones.

Keletas patarimų apklausų sudarytojams

Artėjant tam pavasario metui, kai į elektroninį paštą bei Facebook’o srautą pradeda plaukti studentų prašymai užpildyti nuobodžias ir skausmingai ilgas bakalaurinių ar magistrinių darbų anketas, užtikau labai neprastą „Partially Derivativepodcast‘o seriją apie tai, kaip teisingai tas apklausas sudarinėti. Kadangi patarimai buvo vertingi ir man pačiam, dalinuosi trumpa jų santrauka:

  • Prieš sudarant apklausos anketą reikia gerai pagalvoti, kokius duomenis nori surinkti ir kaip tuos duomenis analizuosi. Visai ne pro šalį būtų iš anksto susidaryti sąrašą grafikų, kuriuos norėsi nupiešti ir nuspręsti, kokias regresijas skaičiuosi. Anketa žymiai sutrumpės, kai tikrai žinosi kokių tiksliai duomenų reikia, o ir klausimai bus žymiai tikslesni: gal iš tiesų reikia sužinoti, kaip klientai vertina restorano maisto kokybę, o ne tai, ar jiems tiesiog patiko jame apsilankyti. Kuo trumpesnė anketa – tuo geriau. Niekas nenori švaistyti laiko pusvalandį pildydamas anketą apie restoraną.
  • Tiksliai apibrėžk savo tiriamųjų populiaciją, nes nuo to priklausys ir tavo klausimai. Jei darai apklausą apie Pokemonus, tikriausiai gali naudoti ir ne tokią formalią kalbą, nes tavo respondentai bus jauni, bet jei klausinėji apie pensijų fondus, tai ir klausimai turėtų būti labiau solidūs.
  • Klausimai turi būti trumpi ir aiškūs. Juos respondentai turi suprasti be jokių papildomų paaiškinimų.
  • Klausimai turi būti objektyvūs. Neklausk „Ar tau labai patiko mūsų restorane?“ (Bet juk tai savaime suprantama, ar ne?)
  • Kad ir kokį užduosi klausimą visada gausi kažkokį atsakymą, bet ar pats klausimas buvo teisingai suformuluotas ir teisingai suprastas?
  • Geriausia prieš paleidžiant apklausą ją patestuoti su keliais žmonėmis. Reiktų jų paklausti, kaip jie suprato klausimus, ar jiems nekilo neaiškumų. Kiek užtruko laiko užpildyti anketą? Jei testuojama internete, galima pažiūrėti ties kuriuo klausimu žmonės daugiausiai užtrunka laiko – gal jis per sudėtingas ar tiesiog sunku apsispręsti?
  • Apklausa turėtų būtų kuo trumpesnė, bet jei apklausinėji žmones asmeniškai gyvame susitikime, ji gali trukti ir pusvalandį ar valandą. Apklausiant telefonu respondentai ima dairytis į laikrodį po 10-15 minučių, o internete jie dažniausiai pasiruošę paskirti tik keletą minučių. Tiesa, jei apklausos klausimai yra labai įdomūs, jos trukmė gali būti ir ilgesnė, bet geriausia galvoti, kad tavo apklausa nėra labai įdomi.
  • Reikėtų vengti atvirų klausimų, nes juos sunku analizuoti. Analizuojant juos kažkaip reikės sudėlioti į kategorijas, o tai nėra lengva automatizuoti.
  • Internete reikėtų vengti didelių klausimų blokų, kur prašoma nuo 1 iki 10 sužymėti savo vertinimus daugeliu kriterijų (pvz „Nuo 1 iki 10 įvertinkite: grožį, spalvą, kvapą, vaizdą, pojūtį, šaltį, etc“). Dažniausiai tokie klausimų blokai netelpa mobilaus telefono ekrane ir juos labai sunku teisingai sužymėti, ypač jei reikia slinkti ekraną.
  • Respondentai dažnai yra tinginiai ir linkę pasirinkti lengviausią variantą. Jei reikia rinktis iš kelių kategorijų („obuolys“, „kriaušė“ ar „bulvė“), jie dažnai pasirinks pirmą, todėl kartais vertakiekvienam respondentui atsakymus pateikti atsitiktine tvarka.
  • Jeigu vertinimo skalė susideda iš nelyginio skaičiaus kategorijų („įvertinkite nuo vieno iki penkių“), tingus respondentas žymiai lengviau pasirinks neutralią vidurinę reikšmę. Jei būtinai norima, kad respondentas pagalvotų geriau ir išreikštų savo (kad ir silpną) preferenciją, reikia prašyti rinktis iš lyginio skaičiaus kategorijų („nuo vieno iki keturių“ arba „nuo vieno iki dešimt“). Tiesa, skalė nuo vieno iki dešimt dažnai yra per smulki: lengviau apsispręsti, kai galima rinktis iš 4-5-6 kategorijų.
  • Ar leisti rinktis kategoriją „kita“ paliekant vietos įrašyti savo variantą? Dažniausiai taip, bet reikia palikti vietos tik vienam ar dviem žodžiams, kad nebūtų daug vietos plėstis (kiek vietos paliksi, tiek kas nors ir prirašys, o po to tai sukels problemų duomenis analizuojant ir kategorizuojant). Apklausos testavimo metu reikia stebėti, ar daug kas renkasi variantą “kita” ir pagal tai pakoreguoti atsakymų variantus. Galutinėje apklausoje reiktų tikėtis, kad šio varianto pasirinkimas nedominuos.
  • Analizuojant apklausos duomenis reikia atkreipti dėmesį į atsakymų pasiskirstymą. Jei visi repondentų atsakymai yra beveik vienodi, iš apklausos gausi nedaug informacijos. Jei visi tavo restoraną vertina penkiomis žvaigždutėmis, tikriausiai ne visai teisingai formuluoji klausimą.
  • Apklausos pradžioje nedėk demografinių klausimų (amžius, lytis, pajamos ir t.t.), nes respondentui tai nuobodu. Paklausk ką nors intriguojančio, kad respondentas susidomėtų ir norėtų iki galo užpildyti visą anketą. Žmonės nuo pat pirmųjų klausimų savo anketinių duomenų pildyti nenori – jie vis dar sprendžia ar verta paskirti savo penkias ar dešimt gyvenimo minučių tavo apklausai.

Dear Data,

Vieną Kalėdų senelio dovanotų knygų surijau per vieną vakarą. Dvi profesionalios duomenų dizainerės (net nesu tikras, kaip teisingai vadinti duomenų atvaizdavimu užsiimančiuosius) – viena Londone, o kita Niujorke –  ištisus metus kas savaitę viena kitai siųsdavo ranka pieštus atvirukus su duomenų schemomis, diagramomis ir grafikais. Kiekvieną savaitę jos pasirinkdavo vis naują temą – kiek kartų pasakei „ačiū“, kiek kartų per savaitę nusijuokei, kas kabo tavo spintoje, kas yra tavo geriausi draugai, kiek kartų nusikeikei ar kiek išgėrei alkoholio. Pasirodo, per septynias dienas tokių duomenų galima prikaupti devynias galybes, ypač jei žymėsiesi ne vien plikus faktus, bet ir su šiais faktais susijusias aplinkybes: ne visi pasakyti „ačiū“ yra vienodi, kai kurie būna ištarti kita kalba, kai kurie parašyti elektroniniame pašte, kai kurie buvo pasakyti tik iš mandagumo, o kai kurie ypač nuoširdūs, nes buvo sakyti su meile savo vyrui. Per daugiau nei penkiasdešimt savaičių šios dizainerės sugalvojo daug išradingų duomenų vaizdavimo būdų ir kone kiekviena atvirutė stebina detalių gausa – bet detalės neužgožia bendro duomenų piešiamo paveikslo, jos nenumaldomai traukia gilyn, ten kur abstraktūs agreguoti skaičiai nutrindami ribą tarp statistikos ir asmeninio intymumo pavirsta į atskirus išgyventus faktus. Kai dešimt kartų pasakytas žodis „ačiū“ tampa trimis „ačiū“ padavėjai už pateiktą sriubą, dviem „ačiū“ bendradarbiui už persiųstą emailą, padėka draugui už tai, kad jis šalia ir keturiais „ačiū“, kuriuos turėjai pasakyti, bet neišdrįsai, tai nebe plika statistika: tikrai jautiesi gerai pažįstantis autorę.

Peržvelgus šio projekto atvirutes pradedi suprasti, kad duomenimis savo gyvenime galima paversti beveik bet ką, tačiau vien pats duomenų rinkimas priverčia atkreipti dėmesį į tuos dalykus, kuriuos šiaip būtum praleidęs pro pirštus. Vien tai, kad skaičiuoji šypsenas, verčia tave daugiau šypsotis, vien tai, kad seki savo alkoholio suvartojimą, galbūt daro tavo blaivesniu, vien tai, kad surenki duomenis apie žmones, su kuriais bendravai per savaitę, primena tau, kad reiktų paskambinti seniai matytai tetai. Ką matuoji, tuo ir gyveni. Apie ką nuolat galvoji, su tuo ir susitapatini. Bet norint daugiau judėti neužtenka nuolat ant rankos nešioti Fitbit apyrankę – jei duomenys surenkami paprastai ir neskausmingai, į juos lengva numoti ranka ir užsimiršti. Kuo sunkiau duomenis teko rinkti ir analizuoti, tuo juos vertini rimčiau. Kartais nėra blogai duomenis sąmoningai užsirašinėti ranka: tai leidžia stabtelti ir pagalvoti apie kiekvieną konkretų stebėjimą.

Be to, kad ši knyga apie duomenis, ji dar priminė, jog reikėtų dažniau sakyti „ačiū“, tad dar kartą dėkoju Kalėdų seneliui už „Dear Data“.

Duomenų analizė Twitter

Geras straipsnis apie tai, ką reiškia būti duomenų analitiku tokioje didelėje kompanijoje kaip Twitter: ką jie veikia, su kokiomis problemomis susiduria ir kodėl norinčiam knistis dideliuose duomenyse reikia mokėti programuoti. Jei sukūrei modelį R kalba savo kompiuteryje tai dar nereiškia, jog jį bus galima panaudoti praktikoje – ties juo dar nemažai turės prisidėti programuotojai, kol jis galės būti perkeltas į produkcinę aplinką.

Šaltinis: Doing Data Science at Twitter — Medium