Rangiranje gledanosti kanala uz Python i PostgreSQL
Matej Prpić
Matej Prpić
Star i trom sustav više ne odgovara potrebama kompanije.

Video statistike. Sve kompanije koje nude TV usluge korisnicima moraju imati kvalitetne statistike gledanosti jer im one između ostalog mogu poslužiti kao baza prilikom kreiranja ponuda prema krajnjim korisnicima, također pomažu prilikom pripreme za pregovore s postojećim i novim mogućim dobavljačima sadržaja, te služe za praćenje trendova u industriji. Najvažniji podaci su koliko je korisnika gledalo pojedini kanal i koliko dugo su ga gledali, pa se prema tome generiraju statistike i rangiraju najgledaniji kanali i emisije na mjesečnoj, polugodišnjoj i godišnjoj bazi. Danas ti podaci moraju biti točni i brzo dostupni, za razliku od prije 10 godina kada se nije zahtijevala tolika točnost i podaci nisu morali biti odmah dostupni, a s godinama i povećanjem korisnika naš sustav je postao jako spor.

A osim brzine, s dolaskom novih poslovnih zahtjeva tražili su se dodatni podaci i naravno poboljšanje kvalitete podataka, a uz našu najbolju volju, te izmjene na starom sustavu su bile nemoguće ili su zahtijevale velike napore. Jednostavno takvu brzinu i kvalitetu nismo mogli postići na starom sustavu, pa je bilo ključno da nađemo bolji način, gdje će se izmjene moći raditi s lakoćom.

Analiza i dokumentiranje cijelog procesa.

Morali smo napraviti cjelovitu analizu sustava koji je bio napisan u PHP-u, razvučen na 100 strana i klasa. Proučavali smo kod da dobijemo bolji osjećaj kako proces točno funkcionira, koje podatke obrađujemo i kako ih se obogaćuje. S obzirom na gore navedeno, nije bilo lako čitati kod, a pogotovo ulaziti u neku dubinu, nakon nekoliko pokušaja promijenili smo pristup. Pregledali smo samo dijelove koda vezano za dohvat podataka i one dijelove koji idu na vanjske sustave. Krenuli smo od glavnog sustava s kojeg i povlačimo statistike. Sustav ima dosta metoda, pa je bilo potrebno eksperimentiranje s metodama i uspoređivanje podataka koje dobijemo, dok nismo naišli na zadovoljavajuću metodu i nju koristili kao ulaz.

Naravno uz analizu bilo je potrebno i dokumentirati kako to trenutno radi. To smo i napravili. S marketingom smo morali vidjeti koji su podaci nužni, tj. Koji bi im zaista bili korisni – a koji preferirani (nice to have), ali ne ključni. Format u kojem ćemo ih dostavljati je isto bio bitan.

Imali smo aktivnost (u našoj kompaniji je to nešto poput projekta) preko koje smo pratili tijek napretka. Stoga smo i sastanke rijetko imali, samo kada se ukaže potreba i naiđemo na nešto problematično ili nejasno. U početku smo ih imali s marketingom dok nismo uskladili što oni žele imati od podataka i ono što mi zbilja možemo dohvatiti. Kasnije i s odjelom koji se bavi pohranom i pripremom podataka(DWH odjel) da definiramo kako i kada će oni podatke povlačiti te da im pojasnimo strukture tablica i podataka. Sve smo uspjeli dogovoriti u kratkom roku. Tako da sada znamo kako sustav radi i što nam je potreban output, a što sad?

Crtanje nove arhitekture i odabir tehnologija.

Za početak smo znali da želimo koristiti python i od toga smo krenuli, a čitanjem članaka, dokumentacije i iskustava ljudi smo tražili koje tehnologije najbolje idu uz python, i koje bi se najviše uklopile u naše potrebe, a skalabilnost je bila ključna karakteristika prilikom odabira rješenja. Budući da je kolega Mladen imao iskustva sa sličnim rješenjima, znali smo otprilike što trebamo tražiti, tako da smo nakon mukotrpnog istraživanja dobili čistu i skalabilnu arhitekturu novog sustava uz moderne tehnologije poput Pythona, Redisa, Postgresqla. Redis npr. nismo koristili do sada u tom formatu. Morali smo sate provoditi na čitanje dokumentacije, a još više na isprobavanje kako funkcionira. Redis smo koristili kao queueing/messaging kako bi lakše organizirati cijeli tok podataka. Primjer imamo radnika A koji puni red A sa svim korisnicima i relevantnim podacima, radnik B uzima iz reda A i obrađuje te podatke dalje. Nakon eksperimentiranja i povezivanja, pokazalo se da se Python lako integrira sa redisom i postresql-om – kao što se i lako skalira.

Work, work, work

Arhitekturu i tehnologije imamo, podigli smo potrebne strojeve za test i produkciju, sve je spremno da nešto deployamo. Arhitektura je takva da postoje cjeline, pa na primjer postoji cjelina za dohvat elektroničkog programskog vodiča koji u bazu sprema događaje, i na osnovu toga se povezuje gledanost korisnika s emisijom koja je tada bila na kanalu. Napravili smo popis svih metoda koje ćemo trebati u pojedinim cjelinama, pa smo tako i raspoređivali zadatke. Izmjene koda smo pratili na gitu, a lokalno smo razvijali nakon što smo postavili okoline da imamo pristup potrebnim sustavima/podacima. Sve razvijeno smo odmah i testirali u hodu, provjeravali rade li metode ono što trebaju, podržavaju li i neke „divlje“ podatke, morali smo pokriti sve moguće slučajeve da nam se ne bi raspala aplikacija.

Radili provjere baratamo li dobro s dobivenim podacima, i najvažnije, jesu li konačni podaci u tablici valjani. To je bilo dosta zeznuto, jer da bi validirali podatke morali smo provjeravati nekoliko različitih sustava koji se međusobno nadopunjuju. Razvoj je potrajao nekoliko mjeseci, jer aktivnost nije bila prioritetna i nije bilo roka do kada mora biti gotova, pa smo obojica paralelno uz ovaj projekt imali još nekoliko te nismo mogli svo svoje vrijeme posvetiti samo tome.

Optimizacija.

Sve je završeno, kod smo stavili na testnu okolinu i tamo podesili sustav kao što bi i na produkciji, pokretali smo dohvat statistika nekoliko dana. Gledali smo logove javljaju li se greške i obrađuju li se podaci na željeni način, nije bilo grešaka, podaci u finalnoj tablici su točni i pregledni. S ponosom možemo reći da je prelazak na produkciju bio bezbolan. Detaljno smo popratili situaciju prvih tjedana i brzinski ispravljali greške koje su se događale prilikom obrade podataka, jer kao što svi vjerojatno znate nikad se ne mogu pokriti apsolutno svi scenariji. Događale su se neke rubne greške prilikom obrade podataka, ali s obzirom na odabir tehnologije i arhitekturu, te izmjene smo na brzinu ispravljali u hodu i odmah smo mogli vidjeti rezultate, bez degradacije u usluzi. Nakon ispravaka grešaka, poradili smo i na ubrzanju procesa, tako da smo se igrali s brojem workera, podizali broj procesora i ram-a na našem stroju dok nismo došli do točke gdje više nije bilo moguće ubrzati jer smo ovisili o drugim sustavima.

Na kraju smo smanjili trajanje obrade statistika za više od 2 puta, u budućnosti ako bude potrebe za još većom brzinom moći ćemo to lako napraviti, uz preduvjet da prvo ubrzamo ostale sustave o kojima ovisimo. Novi sustav nam je očito bio prijeko potreban, a ispostavilo se i da je odabir tehnologija pun pogodak, rezultat je skalabilan sustav s kojim je lako upravljati, a i izmjene u kodu se rade bez puno muke.