Ev beşa duyemîn e ji rêze gotarên li ser pergalên analîtîk ().
Îro êdî guman tune ku hilberandin û şirovekirina daneya bi baldarî ya encaman dikare hema hema her celeb karsaziyê bibe alîkar. Di vî warî de, pergalên analîtîk her ku diçe bi parameteran ve têne barkirin, û di serîlêdanan de hejmara teşqele û bûyerên bikarhêner zêde dibe.
Ji ber vê yekê, pargîdan bêtir û bêtir agahdariya xav didin analîstên xwe da ku analîz bikin û bibin biryarên saxlem. Pêdivî ye ku girîngiya pergalek analîtîk ji bo pargîdaniyek piçûk neyê hesibandin, û pêdivî ye ku pergal bixwe pêbawer û aram be.
analystên Client
Analîtîkên xerîdar karûbarek e ku pargîdaniyek bi navgîniya SDK-ya fermî ve bi malper an serîlêdana xwe ve girêdide, di bingeha koda xwe de entegre dike û pêlên bûyerê hildibijêre. Di vê nêzîkbûnê de kêmasiyek eşkere heye: dibe ku hemî daneyên ku hatine berhev kirin tam wekî ku hûn dixwazin neyên pêvajo kirin ji ber sînorên karûbarê ku hûn hilbijêrin. Mînakî, li ser pergalek ew ê ne hêsan be ku hûn karên MapReduce bimeşînin, li ser yeka din hûn ê nikaribin modela xwe bimeşînin. Dezavantajek din jî dê fatûreya birêkûpêk (bibandor) ya karûbaran be.
Li ser sûkê gelek çareseriyên analîtîk ên xerîdar hene, lê zû an dereng analîst bi vê rastiyê re rû bi rû ne ku ji bo her peywirê karûbarek gerdûnî tune (di heman demê de ku bihayên van hemî karûbaran her dem zêde dibin). Di rewşek weha de, pargîdan pir caran biryar didin ku pergala xweya analîtîk bi hemî mîheng û kapasîteyên xwerû yên pêwîst biafirînin.
analîstên server
Analîtîk-side-server karûbarek e ku dikare di hundurê pargîdaniyek de li ser serverên xwe û (bi gelemperî) bi hewildanên xwe were bicîh kirin. Di vê modelê de, hemî bûyerên bikarhêner li ser serverên hundurîn têne hilanîn, ku destûrê dide pêşdebiran ku databasên cihêreng ên hilanînê biceribînin û mîmariya herî hêsan hilbijêrin. Û her çend hûn hîn jî dixwazin ji bo hin karan analîtîkên xerîdar ên sêyemîn bikar bînin, ew ê dîsa jî gengaz be.
Analîtîkên server-side dikare bi du awayan were saz kirin. Pêşîn: Hin karûbarên çavkaniya vekirî hilbijêrin, wan li ser makîneyên xwe bicîh bikin û mantiqa karsaziyê pêşve bibin.
Плюсы
Минусы
Hûn dikarin her tiştê ku hûn dixwazin xweş bikin
Ev pir caran pir dijwar e û pêşdebirên cuda hewce dike
Ya duyemîn: li şûna ku hûn xwe bişopînin karûbarên SaaS (Amazon, Google, Azure) bigirin. Em ê di beşa sêyemîn de bi berfirehî li ser SaaS biaxivin.
Плюсы
Минусы
Dibe ku di cildên navîn de erzantir be, lê digel mezinbûna mezin ew ê dîsa jî pir biha bibe
Ew ê ne gengaz be ku hemî pîvanan kontrol bikin
Rêvebirî bi tevahî dikeve ser milên pêşkêşkerê karûbar
Her gav nayê zanîn ka di hundurê karûbarê de çi heye (dibe ku ne hewce be)
Meriv çawa analîzên serverê berhev dike
Ger em dixwazin ji karanîna analîzên xerîdar dûr bikevin û ya xwe ava bikin, berî her tiştî divê em bi mîmariya pergala nû bifikirin. Li jêr ez ê gav bi gav ji we re vebêjim ka hûn çi hewce dikin ku bifikirin, çima her gav hewce ye û hûn dikarin kîjan amûran bikar bînin.
1. Dane wergirtin
Mîna ku di mijara analîtîkên xerîdar de, berî her tiştî, vekolerên pargîdanî celebên bûyerên ku ew dixwazin di pêşerojê de bixwînin hilbijêrin û wan di navnîşek de kom bikin. Bi gelemperî, ev bûyer bi rêzek taybetî diqewimin, ku jê re "teşeya bûyerê" tê gotin.
Dûv re, bifikirin ku serîlêdanek mobîl (malper) bikarhênerên birêkûpêk (cîhaz) û gelek server hene. Ji bo veguheztina bi ewlehî bûyeran ji cîhazan berbi serveran, pêvekek navîn hewce ye. Bi mîmariyê ve girêdayî, dibe ku çend rêzikên bûyerê yên cihêreng hebin.
Ye , ku ji bo komkirina bûyeran wek dorê tê bikaranîn.
Li gorî di sala 2014 de, afirînerê Apache Kafka biryar da ku nermalavê navê Franz Kafka bike ji ber ku "ew pergalek ji bo nivîsandinê xweşbîn e" û ji ber ku wî ji karên Kafka hez dikir. -
Di mînaka me de, gelek hilberînerên daneyê û xerîdarên daneyê (cîhaz û pêşkêşker) hene, û Kafka alîkariya wan dike ku wan bi hevûdu ve girêdin. Xerîdar dê di gavên jêrîn de bi hûrgulî werin vegotin, ku ew ê mijarên sereke bin. Naha em ê tenê hilberînerên daneyê (bûyeran) bifikirin.
Kafka têgehên rêz û dabeşkirinê vedihewîne; çêtir e ku meriv bi taybetî li ser vê yekê li cîhek din bixwîne (mînak, di ). Bêyî ku em biçin nav hûrguliyan, em bifikirin ku serîlêdanek mobîl ji bo du OS-yên cihêreng tê destpêkirin. Dûv re her guhertoyek bûyera xweya cihêreng diafirîne. Hilberîner bûyeran ji Kafka re dişînin, ew di rêzek guncaw de têne tomar kirin.
(sûret )
Di heman demê de, Kafka destûrê dide te ku hûn bi hûrgulî bixwînin û rûkalek bûyeran di piçûkan de bişopînin. Kafka amûrek pir maqûl e ku bi hewcedariyên mezinbûyî (mînakî, ji hêla erdnîgariya bûyeran ve) baş tê pîvandin.
Bi gelemperî yek perçek bes e, lê dema ku pîvandinê (wek ku her gav dikin) tişt tevlihevtir dibin. Dibe ku tu kes naxwaze di hilberînê de tenê yek şiklê laşî bikar bîne, ji ber ku mîmarî divê xelet-tolerans be. Ji bilî Kafka, çareseriyek din a naskirî heye - RabbitMQ. Me ew di hilberînê de wekî rêzek ji bo analîtîkên bûyeran bikar neanî (heke we ezmûnek wusa heye, di şîroveyan de ji me re bêje!). Lêbelê, me AWS Kinesis bikar anî.
Berî ku em derbasî qonaxa paşîn bibin, pêdivî ye ku em behsa qatek din a pergalê bikin - hilanîna têketina xav. Ev ne qatek pêdivî ye, lê heke tiştek xelet biçe û rêzikên bûyerê li Kafka ji nû ve werin vegerandin dê kêrhatî be. Hilgirtina têketinên xav ne hewceyî çareseriyek tevlihev û biha ye; hûn dikarin wan bi tenê li cîhek bi rêza rast binivîsin (tewra li ser dîska hişk).
2. Çêkirina rûdanên bûyerê
Piştî ku me hemû bûyer amade kirin û di rêzên guncan de bi cih kirin, em derbasî qonaxa pêvajoyê dibin. Li vir ez ê li ser du vebijarkên pêvajoyê yên herî gelemperî ji we re vebêjim.
Vebijarka yekem ev e ku meriv Spark Streaming di pergala Apache de çalak bike. Hemî hilberên Apache li ser HDFS, pergalek pelê ewledar a bi kopiyên pelan dijîn. Spark Streaming amûrek hêsan-karanîna wê ye ku daneya guheztinê baş digire dest û pîvan dike. Lêbelê, dibe ku ew domdar dijwar be.
Vebijarkek din ev e ku hûn rêvebirê bûyerê xwe ava bikin. Ji bo kirina vê yekê, hûn hewce ne ku, mînakî, serîlêdanek Python binivîsin, wê di Docker de ava bikin û bibin aboneya rêza Kafka. Dema ku teşqele digihîjin destên dokerê, pêvajo dê dest pê bike. Bi vê rêbazê, hûn hewce ne ku serîlêdanan her dem bimeşînin.
Ka em bihesibînin ku me yek ji vebijarkên ku li jor hatine destnîşan kirin hilbijartiye û em derbasî pêvajoyê bixwe bibin. Pêdivî ye ku pêvajo bi kontrolkirina rastdariya daneyan, fîlterkirina zibil û bûyerên "şikestî" dest pê bikin. Ji bo pejirandinê em bi gelemperî bikar tînin . Piştî vê yekê, hûn dikarin nexşeya daneyê bikin: daneyên ji çavkaniyên cihêreng têne normalîzekirin û standardîzekirin da ku li tabloyek hevpar werin zêdekirin.
3. Database
Pêngava sêyemîn domandina bûyerên normalîzekirî ye. Dema ku bi pergalek analîtîk a amade re dixebitin, em neçar in ku pir caran bigihîjin wan, ji ber vê yekê girîng e ku databasek hêsan hilbijêrin.
Ger daneyan baş di nexşeyek rast de cih digirin, hûn dikarin hilbijêrin an databasek stûnek din. Bi vî rengî dê kombûn pir zû bixebitin. Nebaş ev e ku nexşe bi hişkî rast e û ji ber vê yekê ne gengaz e ku meriv tiştên keyfî bêyî guheztinê zêde bike (mînakî, gava bûyerek ne-standard diqewime). Lê hûn dikarin bi rastî pir zû bijmêrin.
Ji bo daneyên nesazkirî, hûn dikarin NoSQL bigirin, mînakî, . Ew li ser HDFS-ê dimeşîne, baş dubare dike, hûn dikarin gelek mînakan raber bikin, û xelet-tolerans e.
Her weha hûn dikarin tiştek sadetir raber bikin, mînakî, . Ew pir hêdî û ji bo cildên piçûk e. Lê plus ev e ku ew pir hêsan e û ji ber vê yekê ji bo destpêkirinê maqûl e.
4. Kombûn
Piştî ku em hemî bûyeran bi baldarî tomar kirin, em dixwazin hemî agahdariya girîng ji koma ku hatî berhev bikin û databasê nûve bikin. Di gerdûnî de, em dixwazin dashboard û pîvanên têkildar bistînin. Mînakî, profîla bikarhênerek ji bûyeran berhev bikin û bi rengekî tevgerê bipîvin. Bûyer têne berhev kirin, berhev kirin û dîsa têne tomar kirin (di tabloyên bikarhêneran de). Di heman demê de, hûn dikarin pergalek ava bikin da ku hûn jî parzûnek bi berhevkar-koordînatorê ve girêdin: bikarhêneran tenê ji celebek bûyerek berhev bikin.
Piştî vê yekê, heke kesek di tîmê de tenê hewceyê analîtîkên asta bilind be, pergalên analîtîk ên derveyî dikarin werin girêdan. Hûn dikarin dîsa Mixpanel bigirin. lê ji ber ku ew pir biha ye, ne hemî bûyerên bikarhêner li wir têne şandin, lê tenê ya ku hewce ye. Ji bo vê yekê, em hewce ne ku koordînatorek biafirînin ku dê hin bûyerên xav an tiştek ku me berê berê berhev kiriye veguhezîne pergalên derveyî, API an platformên reklamê.
5. Frontend
Pêdivî ye ku hûn pêşiyê bi pergala afirandinê ve girêdin. Nimûneyek baş xizmet e , GUI-ya databasê ye ku alîkariya avakirina dashboardan dike. Têkilî çawa dixebite:
- Bikarhêner pirsek SQL dike.
- Di bersivê de ew nîşanek distîne.
- Ew ji bo wê 'dîmendariyek nû' diafirîne û grafiyek xweşik a ku hûn dikarin ji bo xwe hilînin distîne.
Dîtinên di karûbarê de bixweber têne nûve kirin, hûn dikarin çavdêriya xwe xweş bikin û bişopînin. Redash heke bixwe-mêvandar be belaş e, lê wekî SaaS ew ê mehê 50 $ lêçû.
encamê
Piştî temamkirina hemî gavên li jor, hûn ê analîzên servera xwe biafirînin. Ji kerema xwe not bikin ku ev ne ew qas hêsan e ku tenê analîtîkên xerîdar ve girêbide, ji ber ku her tişt hewce ye ku bixwe were mîheng kirin. Ji ber vê yekê, berî ku hûn pergala xwe biafirînin, hêja ye ku hewcedariya pergalek analîtîk a ciddî bi çavkaniyên ku hûn amade ne ku jê re veqetînin berhev bikin.
Ger we matematîkê kiriye û dîtiye ku lêçûn pir zêde ne, di beşa paşîn de ez ê biaxivim ka meriv çawa guhertoyek erzantir a analîtîkên server-side çêdike.
Spas ji bo xwendinê! Ez ê kêfxweş bibim ku di şîroveyan de pirsan bipirsim.
Source: www.habr.com