Sistema analitikoei buruzko artikulu sorta baten bigarren zatia da hau ().
Gaur egun, ez dago zalantzarik datuen tratamendu zehatzak eta emaitzen interpretazioak ia edozein negozio motari lagun diezaiokeela. Ildo horretan, sistema analitikoak gero eta parametroz kargatuago daude, aplikazioetan abiarazleen eta erabiltzaileen gertakarien kopurua hazten ari da.
Hori dela eta, enpresek gero eta informazio "gordina" gehiago ematen diete beren analistei, aztertu eta erabaki egokietan bihurtzeko. Ez da gutxietsi behar enpresa batentzako analisi-sistema batek duen garrantzia, eta sistemak berak fidagarria eta iraunkorra izan behar du.
Bezeroen analistak
Bezeroen analitika enpresa batek SDK ofizialaren bidez bere webgunerako edo aplikaziorako konektatzen duen zerbitzu bat da, bere kode-basean integratzen du eta gertaeren abiarazleak hautatzen ditu. Ikuspegi honek eragozpen nabaria du: bildutako datu guztiak ezin dira nahi bezala prozesatu guztiz, aukeratutako edozein zerbitzuk dituen mugak direla eta. Adibidez, sistema batean ez da erraza izango MapReduce zereginak exekutatu, beste batean ezin izango duzu zure eredua exekutatu. Beste desabantaila bat zerbitzuen ohiko faktura (ikusgarria) izango da.
Merkatuan bezeroen analisirako irtenbide asko daude, baina lehenago edo beranduago, analistek edozein zereginetarako egokia den zerbitzu unibertsala ez egotearen aurrean aurkitzen dira (zerbitzu horien guztien prezioak etengabe hazten ari diren bitartean). Egoera horretan, enpresek sarritan erabakitzen dute beren analitika sistema sortzea beharrezko ezarpen eta funtzio pertsonalizatu guztiekin.
Zerbitzariaren Analistak
Zerbitzariaren analisia enpresa baten zerbitzarietan eta (normalean) barnean zabal daitekeen zerbitzu bat da. Eredu honetan, erabiltzaileen gertaera guztiak barneko zerbitzarietan gordetzen dira, garatzaileek biltegiratzeko datu-base desberdinak probatzeko eta arkitektura erosoena aukeratzeko aukera emanez. Eta zeregin batzuetarako hirugarrenen bezeroen aldeko analisiak erabili nahi badituzu ere, posible izango da.
Zerbitzariaren aldeko analitika bi modutara zabaldu daiteke. Lehenik eta behin: aukeratu kode irekiko utilitate batzuk, zabaldu zure makinetan eta garatu negozio-logika.
Pros
Cons
Edozer pertsonaliza dezakezu
Askotan oso zaila da eta garatzaile bereiziak behar dira
Bigarrena: hartu SaaS zerbitzuak (Amazon, Google, Azure) zuk zeuk zabaldu beharrean. Hirugarren zatian SaaS-i buruz gehiago hitz egingo dugu.
Pros
Cons
Bolumen ertainetan merkeagoa izan daiteke, baina igoera handiarekin oraindik garestiegia izango da
Ezin da parametro guztiak kontrolatu
Administrazioa zerbitzu-hornitzailearen sorbaldetara mugitzen da guztiz
Ez da beti jakiten zer dagoen zerbitzuaren barruan (baliteke beharrezkoa ez izatea)
Nola bildu zerbitzariaren analisiak
Bezeroen analitika erabiltzeatik aldendu eta gurea eraiki nahi badugu, lehenik eta behin sistema berriaren arkitekturan pentsatu behar dugu. Jarraian, urratsez urrats esango dizut zer kontuan hartu behar duzun, zergatik behar den pauso bakoitza eta zer tresna erabil ditzakezun.
1. Datuak eskuratzea
Bezeroen analisiaren kasuan bezala, lehenik eta behin, enpresetako analistek gehiago aztertu nahi dituzten gertaera motak hautatzen dituzte eta zerrenda batean biltzen dituzte. Normalean, gertaera hauek ordena jakin batean gertatzen dira, "gertaera eskema" deitzen dena.
Gainera, pentsa dezagun mugikorrentzako aplikazio batek (webguneak) erabiltzaile arruntak (gailuak) eta zerbitzari asko dituela. Gertaerak gailuetatik zerbitzarietara modu seguruan transferitzeko, tarteko geruza bat behar da. Arkitekturaren arabera, hainbat gertaera-ilara sor daitezke.
- Is , ekitaldiak biltzeko ilara gisa erabiltzen dena.
Arabera 2014an, Apache Kafkaren sortzaileak softwareari Franz Kafkaren izena jartzea erabaki zuen, βidazketarako optimizatutako sistemaβ delako eta Kafkaren idatziak maite zituelako. β
Gure adibidean, datu-ekoizle eta haien kontsumitzaile asko daude (gailuak eta zerbitzariak), eta Kafkak elkarren artean konektatzen laguntzen du. Kontsumitzaileak zehatzago deskribatuko dira hurrengo urratsetan, non aktore nagusiak izango diren. Orain datu-ekoizleak (gertaerak) soilik hartuko ditugu kontuan.
Kafkak ilara eta partizio kontzeptuak biltzen ditu, zehatzago honi buruz hobe da beste nonbait irakurtzea (adibidez, ). Xehetasunetan sartu gabe, pentsa dezagun mugikorrentzako aplikazio bat martxan jartzen dela bi sistema eragile ezberdinetarako. Ondoren, bertsio bakoitzak bere gertaeren korronte bereizia sortzen du. Ekoizleek Kafkara bidaltzen dituzte ekitaldiak, ilara egoki batean grabatzen dira.
(irudia )
Aldi berean, Kafkak zatika irakurtzeko eta gertaeren fluxua mini-lotetan prozesatzeko aukera ematen du. Kafka oso tresna erosoa da, gero eta behar gehiagorekin (adibidez, gertaeren geolokalizazioaren bidez).
Normalean zati bat nahikoa da, baina komunikazioarekin gauzak konplikatu egiten dira eskalatzean (beti bezala). Seguruenik, inork ez du zati fisiko bakarra erabili nahi ekoizpenean, arkitekturak akatsekiko tolerantzia izan behar baitu. Kafka-z gain, beste irtenbide ezagun bat dago: RabbitMQ. Ekoizpenean ez dugu erabili gertaeren analisirako ilara gisa (halako esperientzia baduzu, kontatu iruzkinetan!). Hala ere, AWS Kinesis erabili zen.
Hurrengo urratsera pasatu aurretik, sistemaren geruza gehigarri bat aipatu behar da: erregistro gordinak biltegiratzea. Hau ez da derrigorrezko geruza, baina erabilgarria izango da zerbait gaizki joan eta Kafka-ko gertaeren ilarak zerora berrezartzen badira. Erregistro gordinak gordetzeak ez du irtenbide konplexu eta garestia behar, nonbait ordena egokian idatzi ditzakezu (baita disko gogorrean ere).
2. Gertaeren korronteak kudeatzea
Ekitaldi guztiak prestatu eta dagozkien ilaretan jarri ondoren, prozesatzeko urratsera pasatzen gara. Hemen bi prozesatzeko aukera ohikoenei buruz hitz egingo dut.
Lehenengo aukera Apache sistema batean Spark Streaming gaitzea da. Apache produktu guztiak HDFS-n bizi dira, fitxategi sistema erreplika seguru batean. Spark Streaming erreproduzitzeko datuak prozesatzen dituen eta ondo eskalatzen dituen tresna erabilerraza da. Hala ere, zaila izan daiteke mantentzea.
Beste aukera bat zure gertaeren kudeatzailea sortzea da. Horretarako, adibidez, Python aplikazio bat idatzi, docker-en eraiki eta Kafkaren ilaretara harpidetu behar duzu. Docker-eko kudeatzaileei abiarazleak heltzen zaizkienean, prozesatzea hasiko da. Metodo honekin, etengabe exekutatzen diren aplikazioak mantendu behar dituzu.
Demagun goian azaldutako aukeretako bat aukeratu dugula eta prozesatzeko berari ekin diogu. Prozesadoreek datuen baliozkotasuna egiaztatzen hasi beharko lukete, zaborra eta "hautsitako" gertaerak iragazten. Baliozkotzeko erabiltzen dugu normalean . Horren ostean, datuen mapaketa egin daiteke: iturri ezberdinetako datuak normalizatu eta estandarizatu egiten dira, taula komun batean gehitzeko.
3. Datu-basea
Hirugarren urratsa normalizatutako gertaerak gordetzea da. Prest egindako sistema analitiko batekin lan egiten dugunean, askotan sartu beharko dugu, beraz, garrantzitsua da datu-base eroso bat aukeratzea.
Datuak eskema finko batean ondo egokitzen badira, aukera dezakezu edo zutabeen beste datu-baseren bat. Beraz, agregazioek oso azkar funtzionatuko dute. Alde txarra da eskema zurrun finkatuta dagoela eta, beraz, ez duela funtzionatuko fintasunik gabeko objektu arbitrarioak gehitzeko (adibidez, gertaera ez-estandarra gertatzen denean). Baina oso azkar egin daiteke.
Egituratu gabeko datuetarako, NoSQL har dezakezu, adibidez, . HDFS-n exekutatzen da, ondo errepikatzen da, instantzia asko sor ditzakezu eta akatsak toleratzen ditu.
Zerbait sinpleagoa plantea dezakezu, adibidez, . Nahiko motela da bolumen txikietan ere. Baina abantaila da oso erraza dela eta, beraz, hasteko egokia dela.
4. Agregazioak
Gertaera guztiak arretaz gordeta, etorritako sortaren informazio garrantzitsu guztia bildu eta datu-basea eguneratu nahi dugu. Mundu mailan, aginte-panel eta metrika garrantzitsuak nahi ditugu. Adibidez, gertaeretatik erabiltzailearen profila biltzeko eta nolabait portaera neurtzeko. Gertaerak batu, bildu eta berriro gordetzen dira (dagoeneko erabiltzaileen tauletan). Aldi berean, posible da sistema bat eraikitzea, iragazki bat ere koordinazio-agregatzaileari konektatzeko moduan: gertaera mota jakin bateko erabiltzaileak soilik biltzeko.
Horren ostean, taldeko norbaitek goi-mailako analisiak soilik behar baditu, kanpoko analisi-sistemak konekta ditzakezu. Mixpanel berriro har dezakezu. baina nahiko garestia denez, erabiltzaileen gertaera guztiak ez dira bertara bidaltzen, behar dena baizik. Horretarako, koordinatzaile bat sortu behar dugu, gertakari gordinak edo guk geuk lehenago batu dugun zerbait kanpoko sistemetara, APIetara edo publizitate plataformetara transferituko dituena.
5. Frontend
Frontend-a sortutako sistemara konektatu behar duzu. Adibide on bat zerbitzua da. , panelak eraikitzen laguntzen duen datu-base GUI bat da. Interakzioak nola funtzionatzen duen:
- Erabiltzaileak SQL kontsulta bat egiten du.
- Horren harira, seinale bat jasotzen du.
- "Bistaratu berri" bat sortzen du eta dagoeneko gorde dezakezun grafiko eder bat lortzen du.
Zerbitzuko bistaratzeak automatikoki eguneratzen dira, zure jarraipena konfiguratu eta jarraipena egin dezakezu. Redash doakoa da, auto-ostatatutako kasuan, baina SaaS gisa hilean 50 $ balioko du.
Ondorioa
Aurreko urrats guztiak amaitu ondoren, zure zerbitzariaren aldeko analisiak sortuko dituzu. Kontuan izan hau ez dela bezeroen analisiak konektatzea bezain erraza, dena zure kabuz konfiguratu behar delako. Hori dela eta, zure sistema sortu aurretik, merezi du analisi-sistema serio baten beharra hari esleitzeko prest zauden baliabideekin alderatzea.
Matematika guztiak egin eta kostuak handiegiak direla ikusi baduzu, hurrengo zatian back-end analitiken bertsio merkeago bat nola egin hitz egingo dut.
Eskerrik asko irakurtzeagatik! Pozik egingo dut galderak iruzkinetan.
Iturria: www.habr.com