Jen la dua parto de serio de artikoloj pri analizaj sistemoj ().
Hodiaŭ ne plu estas dubo, ke zorgema datumtraktado kaj interpreto de rezultoj povas helpi preskaŭ ajnan tipon de komerco. Ĉi-rilate, analizaj sistemoj iĝas ĉiam pli ŝarĝitaj kun parametroj, kaj la nombro da ellasiloj kaj uzantaj eventoj en aplikoj kreskas.
Pro tio, kompanioj donas al siaj analizistoj pli kaj pli da krudaj informoj por analizi kaj transformi en sanajn decidojn. La graveco de analiza sistemo por kompanio ne devas esti subtaksita, kaj la sistemo mem devas esti fidinda kaj stabila.
Klientaj analizistoj
Klienta analizo estas servo, kiun kompanio konektas al sia retejo aŭ aplikaĵo per la oficiala SDK, integras en sian propran kodbazon kaj elektas evento-eksilon. Estas evidenta malavantaĝo al ĉi tiu aliro: ĉiuj datumoj kolektitaj eble ne estas traktataj ĝuste kiel vi ŝatus pro la limigoj de iu servo, kiun vi elektas. Ekzemple, en unu sistemo ne estos facile ruli MapReduce-taskojn, en alia vi ne povos ruli vian modelon. Alia malavantaĝo estos la regula (impona) fakturo por servoj.
Estas multaj klient-analizaj solvoj sur la merkato, sed baldaŭ analizistoj alfrontas la fakton, ke ne ekzistas unu universala servo taŭga por ĉiu tasko (dum la prezoj por ĉiuj ĉi tiuj servoj ĉiam altiĝas). En tia situacio, kompanioj ofte decidas krei sian propran analizan sistemon kun ĉiuj necesaj kutimaj agordoj kaj kapabloj.
Servilaj analizistoj
Servilflanka analizo estas servo kiu povas esti deplojita ene de firmao sur siaj propraj serviloj kaj (kutime) per siaj propraj klopodoj. En ĉi tiu modelo, ĉiuj uzantkazaĵoj estas stokitaj sur internaj serviloj, permesante al programistoj provi malsamajn konservajn datumbazojn kaj elekti la plej oportunan arkitekturon. Kaj eĉ se vi ankoraŭ volas uzi triajn klientajn analizojn por iuj taskoj, ĝi ankoraŭ eblos.
Servilflanka analizo povas esti deplojita laŭ du manieroj. Unue: elektu iujn malfermfontajn ilojn, disvolvu ilin sur viaj maŝinoj kaj disvolvu komercan logikon.
Puloj
Miksoj
Vi povas personecigi ion ajn, kion vi volas
Ĉi tio ofte estas tre malfacila kaj postulas apartajn programistojn
Due: prenu SaaS-servojn (Amazon, Google, Azure) anstataŭ deploji ĝin mem. Pri SaaS ni parolos pli detale en la tria parto.
Puloj
Miksoj
Ĝi povas esti pli malmultekosta ĉe mezaj volumoj, sed kun granda kresko ĝi ankoraŭ fariĝos tro multekosta
Ne eblos kontroli ĉiujn parametrojn
Administrado estas tute transdonita al la ŝultroj de la servoprovizanto
Oni ne ĉiam scias kio estas ene de la servo (ĝi eble ne estas bezonata)
Kiel kolekti servilajn analizojn
Se ni volas malproksimigi de uzado de kliento-analitiko kaj konstrui nian propran, unue ni devas pensi tra la arkitekturo de la nova sistemo. Malsupre mi diros al vi paŝon post paŝo, kion vi devas konsideri, kial ĉiu paŝo estas bezonata kaj kiajn ilojn vi povas uzi.
1. Ricevante datumojn
Same kiel en la kazo de klient-analitiko, unue, firmaaj analizistoj elektas la tipojn de eventoj, kiujn ili volas studi estonte, kaj kolektas ilin en liston. Tipe, tiuj okazaĵoj okazas en specifa ordo, nomita "okazaĵpadrono."
Poste, imagu, ke poŝtelefona aplikaĵo (retejo) havas regulajn uzantojn (aparatoj) kaj multajn servilojn. Por sekure translokigi eventojn de aparatoj al serviloj, necesas meza tavolo. Depende de la arkitekturo, povas ekzisti pluraj malsamaj eventovicoj.
Estas , kiu estas uzata kiel atendovico por kolektado de eventoj.
Laŭ en 2014, la kreinto de Apache Kafka decidis nomi la programaron laŭ Franz Kafka ĉar "ĝi estas sistemo optimumigita por skribo" kaj ĉar li amis la verkojn de Kafka. —
En nia ekzemplo, estas multaj datumproduktantoj kaj datumkonsumantoj (aparatoj kaj serviloj), kaj Kafka helpas ligi ilin unu al la alia. Konsumantoj estos priskribitaj pli detale en la sekvaj paŝoj, kie ili estos la ĉefaj temoj. Nun ni konsideros nur datumajn produktantojn (okazaĵojn).
Kafka enkapsuligas la konceptojn de vosto kaj sekcio; estas pli bone legi pli specife pri tio aliloke (ekzemple, en ). Sen eniri detalojn, ni imagu, ke poŝtelefona aplikaĵo estas lanĉita por du malsamaj OS-oj. Tiam ĉiu versio kreas sian propran okazaĵfluon. Produktantoj sendas eventojn al Kafka, ili estas registritaj en taŭga vico.
(bildo )
Samtempe, Kafka permesas vin legi en pecoj kaj prilabori fluon de eventoj en mini-lokoj. Kafka estas tre oportuna ilo, kiu bone skalas kun kreskantaj bezonoj (ekzemple per geolokigo de eventoj).
Kutime unu peceto sufiĉas, sed aferoj pli komplikiĝas dum grimpado (kiel ili ĉiam faras). Verŝajne neniu volos uzi nur unu fizikan peceton en produktado, ĉar la arkitekturo devas esti mistolerema. Krom Kafka, ekzistas alia konata solvo - RabbitMQ. Ni ne uzis ĝin en produktado kiel atendovico por evento-analitiko (se vi havas tian sperton, diru al ni pri ĝi en la komentoj!). Tamen ni uzis AWS Kinesis.
Antaŭ ol transiri al la sekva paŝo, ni devas mencii unu plian plian tavolon de la sistemo - kruda ŝtipo-stokado. Ĉi tio ne estas postulata tavolo, sed ĝi estos utila se io misfunkcias kaj la eventovicoj en Kafka estas rekomencigitaj. Stoki krudajn protokolojn ne postulas kompleksan kaj multekostan solvon; vi povas simple skribi ilin ie en la ĝusta ordo (eĉ sur malmola disko).
2. Prilaborado de eventofluoj
Post kiam ni preparis ĉiujn eventojn kaj metis ilin en la taŭgajn atendovicojn, ni transiras al la pretiga paŝo. Ĉi tie mi rakontos al vi pri la du plej oftaj pretigaj elektoj.
La unua opcio estas ebligi Spark Streaming en la Apache-sistemo. Ĉiuj Apache-produktoj vivas sur HDFS, sekura dosiersistemo kun dosierkopioj. Spark Streaming estas facile uzebla ilo, kiu bone traktas fluajn datumojn kaj skalas. Tamen, ĝi povas esti malfacile konservi.
Alia eblo estas konstrui vian propran evento-traktilon. Por fari tion, vi devas, ekzemple, skribi Python-aplikaĵon, konstrui ĝin en Docker kaj aboni la Kafka-vicon. Kiam ellasiloj alvenas al la docker-traktiloj, pretigo komenciĝos. Kun ĉi tiu metodo, vi devas teni aplikojn funkcii ĉiam.
Ni supozu, ke ni elektis unu el la supre priskribitaj elektoj kaj transiru al la prilaborado mem. Procesoroj devas komenci per kontrolado de la valideco de la datumoj, filtrado de rubo kaj "rompitaj" eventoj. Por validigo ni kutime uzas . Post ĉi tio, vi povas fari datumapadon: datumoj de malsamaj fontoj estas normaligitaj kaj normigitaj por esti aldonitaj al komuna tabelo.
3. Datumaro
La tria paŝo estas konservi normaligitajn eventojn. Laborante kun preta analiza sistemo, ni devos ofte aliri ilin, do gravas elekti oportunan datumbazon.
Se la datumoj bone konvenas al fiksa skemo, vi povas elekti aŭ iu alia kolumna datumbazo. Tiel la agregaĵoj funkcios tre rapide. La malavantaĝo estas, ke la skemo estas rigide fiksita kaj tial ne eblos aldoni arbitrajn objektojn sen modifo (ekzemple, kiam okazas ne-norma evento). Sed vi povas kalkuli vere tre rapide.
Por nestrukturitaj datumoj, vi povas preni NoSQL, ekzemple, . Ĝi funkcias per HDFS, reproduktiĝas bone, vi povas levi multajn okazojn kaj estas tolerema al misfunkciadoj.
Vi ankaŭ povas levi ion pli simplan, ekzemple, . Ĝi estas sufiĉe malrapida kaj por malgrandaj volumoj. Sed la pluso estas, ke ĝi estas tre simpla kaj tial taŭga por komenci.
4. Agregacioj
Singarde konservinte ĉiujn eventojn, ni volas kolekti ĉiujn gravajn informojn de la alveninta aro kaj ĝisdatigi la datumbazon. Tutmonde, ni volas akiri rilatajn instrumentpanelojn kaj metrikojn. Ekzemple, kolektu uzantprofilon de eventoj kaj iel mezuru konduton. Eventoj estas kunigitaj, kolektitaj kaj konservitaj denove (en uzanttabeloj). Samtempe, vi povas konstrui sistemon tiel ke vi ankaŭ povas konekti filtrilon al la agregator-kunordiganto: kolekti uzantojn nur de certa tipo de evento.
Post tio, se iu en la teamo bezonas nur altnivelan analizon, eksteraj analizaj sistemoj povas esti konektitaj. Vi povas preni Mixpanel denove. sed ĉar ĝi estas sufiĉe multekosta, ne ĉiuj uzantaj eventoj estas senditaj tien, sed nur tio, kio estas bezonata. Por fari tion, ni devas krei kunordiganton, kiu transdonos iujn krudajn eventojn aŭ ion, kion ni mem agregis pli frue al eksteraj sistemoj, API-oj aŭ reklamaj platformoj.
5. Frontend
Vi devas konekti la fasadon al la kreita sistemo. Bona ekzemplo estas servo , estas datumbaza GUI kiu helpas konstrui instrumentpanelojn. Kiel la interago funkcias:
- La uzanto faras SQL-demandon.
- Responde li ricevas signon.
- Ĝi kreas 'novan bildigon' por ĝi kaj ricevas belan grafikaĵon, kiun vi povas konservi por vi mem.
Bildigoj en la servo estas aŭtomate ĝisdatigitaj, vi povas personecigi kaj spuri vian monitoradon. Redash estas senpaga se memgastigita, sed kiel SaaS ĝi kostos $ 50 monate.
konkludo
Post plenumi ĉiujn ĉi-suprajn paŝojn, vi kreos vian servilan analizon. Bonvolu noti, ke ĉi tio ne estas tiel simpla kiel nur konekti klientan analizon, ĉar ĉio devas esti agordita mem. Tial, antaŭ ol krei vian propran sistemon, indas kompari la bezonon de serioza analiza sistemo kun la rimedoj, kiujn vi pretas asigni al ĝi.
Se vi faris la matematikon kaj trovis, ke la kostoj estas tro altaj, en la sekva parto mi parolos pri kiel fari pli malmultekostan version de servilflanka analizo.
Dankon pro legado! Mi ĝojos demandi demandojn en la komentoj.
fonto: www.habr.com