Em di demek ecêb de dijîn ku hûn dikarin zû û bi hêsanî gelek amûrên çavkaniya vekirî yên amade ve girêdin, wan li gorî şîreta stackoverflow bi "hişmendiya xwe vegirtî" saz bikin, bêyî ku li "pir tîpan" bigerin, û dest pê bikin. wan bikeve operasyona bazirganî. Û gava ku hûn hewce ne ku nûve bikin/berfireh bikin an kesek bi xeletî çend makîneyan ji nû ve saz bike - hûn pê dihesin ku xewnek xirab a berbiçav dest pê kiriye, her tişt ji nedîtî ve pir tevlihev bûye, veger tune, pêşeroj nezelal û ewletir e, li şûna bernamekirinê, hingiv çêdikin û penîr dikin.
Ne ji bo tiştekî ye ku hevkarên bi tecrube, bi serê xwe bi xeletiyan ve zeliqandî û ji ber vê yekê jixwe gewr e, li ser bicihkirina pir bilez a pakêtên "konteyneran" di "kube" de li ser bi dehan serverên bi "zimanên modê" yên bi piştgirîya navxweyî ya ji bo I/O ne-astengker a asînkron, bi nermî bişirîn. Û ew bi bêdengî xwendina "man ps" ji nû ve didomînin, li koda çavkaniyê "nginx" vedigerin heta ku çavên wan xwîn bibin, û ceribandinên yekîneyê dinivîsin, dinivîsin, dinivîsin. Heval dizanin ku tişta herî balkêş dê were dema ku "ev hemî" rojek şevek şeva sersalê biqewime. Û ew ê tenê ji hêla têgihîştina kûr a xwezaya unix, tabloya dewleta TCP/IP-ya jibîrkirî û algorîtmayên bingehîn-lêgerînê ve bibin alîkar. Ji bo vegerandina sîstemê ji nû ve bi lêdana dengan.
Oh erê, ez hinekî bala min kişand, lê ez hêvî dikim ku min karîbû ku rewşa bendewariyê ragihînim.
Iro ez dixwazim ezmûna xwe di danîna stûnek hêsan û erzan de ji bo DataLake parve bikim, ku piraniya karên analîtîk ên di pargîdaniyê de ji bo beşên binesaziyê bi tevahî cûda çareser dike.
Demek berê, em gihîştin vê têgihiştinê ku pargîdanî her ku diçe pêdivî bi fêkiyên hilber û analîzên teknîkî (nebêjin ku di forma fêrbûna makîneyê de li ser kekê) û ji bo fêmkirina meyl û xetereyan - pêdivî ye ku em berhev bikin û analîz bikin. bêtir û bêtir metrics.
Di Bitrix24 de analîzên teknîkî yên bingehîn
Çend sal berê, hevdemî bi destpêkirina karûbarê Bitrix24 re, me dem û çavkaniyan bi awayekî çalak veberandin da ku platformek analîtîk a hêsan û pêbawer biafirîne ku dê alîkariya zûtirîn pirsgirêkan di binesaziyê de bibîne û gava paşîn plansaz bike. Bê guman, şîret bû ku meriv amûrên hazir ên ku bi qasî ku pêkan hêsan û têgihîştî ne bigirin. Wekî encamek, nagios ji bo çavdêriyê û munin ji bo analîtîk û dîtbariyê hate hilbijartin. Naha bi hezaran kontrolên me li nagios, bi sedan nexşeyên li munin hene, û hevkarên me her roj wan bi serfirazî bikar tînin. Metrîk zelal in, grafîk zelal in, pergal ev çend sal in bi pêbawer dixebite û ceribandin û grafikên nû bi rêkûpêk li wê têne zêdekirin: gava ku em karûbarek nû dixebitînin, em çend ceribandin û grafîkan lê zêde dikin. Bextxweş bî.
Tilî li ser Pulse - Analîtîka Teknîkî ya Pêşkeftî
Daxwaza wergirtina agahdariya di derbarê pirsgirêkan de "bi zûtirîn dem" me rê da ceribandinên çalak ên bi amûrên hêsan û têgihîştî - pinba û xhprof.
Pinba ji me re statîstîkên di pakêtên UDP de di derbarê leza xebitandina beşên rûpelên malperê di PHP de şand, û me dikaribû di hilanîna MySQL de serhêl bibînin (Pinba bi motora xwe ya MySQL re ji bo analîtîka bilez a bûyeran tê) navnîşek kurt a pirsgirêkan û bersivê bidin. wê. Û xhprof bixweber destûr da me ku em grafikên pêkanîna rûpelên PHP-ê yên herî hêdî ji xerîdaran berhev bikin û analîz bikin ka çi dikare bibe sedema vê yekê - bi aramî, rijandina çayê an tiştek bihêztir.
Demek berê, amûrek bi motorek din a pir hêsan û têgihîştî ya ku li ser bingeha algorîtmaya nîşankirina berevajî ye, ku bi rengek bêkêmasî di pirtûkxaneya efsanewî ya Lucene - Elastic/Kibana de hatî bicîh kirin, hate dagirtin. Fikra hêsan a tomarkirina pir-mijalek belgeyan di navnîşek Lucene ya berevajî de ku li ser bingeha bûyerên di qeydan de ye û lêgerînek bilez a di nav wan de bi karanîna dabeşkirina rûçikê re bi rastî bikêr bû.
Tevî ku xuyangiya teknîkî ya dîtbarî ya li Kibana bi têgînên nizm ên mîna "kepek" "ber bi jor ve diherike" û zimanê ji nû ve afirandî ya cebraya pêwendiyê ya ku hîna bi tevahî nehatiye jibîrkirin, amûrê dest pê kir ku di karên jêrîn de baş alîkariya me bike:
- Di saeta paşîn de çend xeletiyên PHP-ê xerîdar Bitrix24 li ser portalê p1 hebûn û kîjan? Fêm bikin, bibaxşînin û zû rast bikin.
- Li Almanyayê di 24 saetên berê de çend telefonên vîdeoyî li ser portalan hatin kirin, bi kîjan kalîteyê û di kanal/torê de çi zehmetî hebûn?
- Karbidestiya pergalê (berfirehkirina meya C ya ji bo PHP), ku di nûvekirina karûbarê herî dawî de ji çavkaniyê hatî berhev kirin û ji xerîdaran re hatî derxistin, çiqas baş dixebite? Segfaults hene?
- Ma daneyên xerîdar di bîra PHP de cih digirin? Ma di derheqê zêdekirina bîranîna ku ji pêvajoyan re hatî veqetandin de xeletî hene: "ji bîrê ne"? Bibînin û bêbandor bikin.
Li vir mînakek berbiçav heye. Tevî ceribandinek bêkêmasî û pir-asta, xerîdar, bi dozek pir ne-standard û daneya têketinê ya zirardar, xeletiyek acizker û neçaverêkirî wergirt, sîrenek deng da û pêvajoyek zû rastkirina wê dest pê kir:
Wekî din, kibana dihêle hûn ji bo bûyerên diyarkirî agahdariyan organîze bikin, û di demek kin de amûra di pargîdaniyê de ji hêla bi dehan karmendên ji beşên cihêreng ve dest pê kir - ji piştgirî û pêşkeftina teknîkî heya QA-yê.
Çalakiya her beşê di hundurê pargîdaniyê de ji bo şopandin û pîvandinê hêsan bûye - li şûna ku hûn bi destan têketinên li ser serveran analîz bikin, hûn tenê hewce ne ku carekê têketinên parskirinê saz bikin û wan bişînin koma elastîk da ku kêfê jê werbigirin, mînakî, di kibanê de fikirîn. dashboard hejmara kitikên du-serî yên ku di meha heyvê ya paşîn de li ser çapera 3-D hatine çap kirin.
Analyzên Karsaziya Bingehîn
Her kes dizane ku analîtîkên karsaziyê di pargîdaniyan de bi gelemperî bi karanîna pir çalak a, erê, Excel dest pê dike. Lê ya sereke ev e ku ew bi dawî nabe. Google Analytics-a-based Cloud di heman demê de sotemeniyê li agir zêde dike - hûn zû dest pê dikin ku bi tiştên baş re werin bikar anîn.
Di pargîdaniya meya ku bi ahengek pêşkeftî de, li vir û wir "pêxemberên" xebata zexmtir bi daneyên mezin dest pê kir. Pêdiviya raporên kûrtir û piralî dest pê kir ku bi rêkûpêk xuya bibe, û bi hewildanên xortên ji beşên cihêreng, demek berê çareseriyek hêsan û pratîkî hate organîze kirin - tevliheviyek ClickHouse û PowerBI.
Demek dirêj, vê çareseriya maqûl gelek alîkarî kir, lê hêdî hêdî têgihîştin ku ClickHouse ne gomî ye û nekare bi vî rengî tinazan bike.
Li vir girîng e ku meriv baş fam bike ku ClickHouse, mîna Druid, mîna Vertica, mîna Amazon RedShift (ya ku li ser bingeha postgres-ê ye), motorên analîtîk in ku ji bo analîtîkên pir rehet hatine xweşbîn kirin (hevok, berhevok, herî kêm-herî zêde li gorî stûnê û çend tevlêbûna gengaz. ), ji ber ku ji bo hilanîna bikêrhatî ya stûnên tabloyên pêwendiyê, berevajî MySQL û databasên din ên (rêz-oriented) yên ku ji me re têne zanîn têne organîze kirin.
Di eslê xwe de, ClickHouse tenê "danûstendek" jêhatîtir e, bi danasîna xal-bi-xal ne pir rehet e (bi vî rengî tê armanc kirin, her tişt baş e), lê analîtîkên xweş û komek fonksiyonên hêzdar ên balkêş ji bo xebata bi daneyan re. Erê, hûn dikarin komik jî biafirînin - lê hûn fêm dikin ku lêdana bi mîkroskopê neynûkên bi tevahî ne rast e û me dest bi lêgerîna çareseriyên din kir.
Daxwaza python û analîstan
Pargîdaniya me gelek pêşdebiran hene ku hema hema her roj 10-20 salan kodê di PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash de dinivîsin. Di heman demê de gelek rêveberên pergalê yên xwedî ezmûn jî hene ku ji yekê zêdetir karesatek bêkêmasî ya ku di qanûnên statîstîkê de cîh nagire (mînakî, dema ku piraniya dîskên di raid-10-ê de bi lêdanek birûskê ya bihêz ve têne hilweşandin) hene. Di rewşên weha de, ji bo demek dirêj ne diyar bû ku "analîstê python" çi ye. Python mîna PHP-ê ye, tenê nav hinekî dirêjtir e û di koda çavkaniya wergêrê de piçek kêmtir şopên madeyên hiş-guhêrbar hene. Lêbelê, her ku bêtir û bêtir raporên analîtîk hatin afirandin, pêşdebirên pispor dest pê kirin ku her ku diçe girîngiya pisporiya teng di amûrên mîna numpy, panda, matplotlib, seaborn de fam bikin.
Rola diyarker, bi îhtimaleke mezin, ji nişka ve bêhişbûna karmendan ji berhevkirina peyvên "regresîyona lojîstîkî" û xwenîşandana raporkirina bi bandor li ser daneyên mezin bi karanîna, erê, erê, pyspark ve lîst.
Apache Spark, paradîgmaya wê ya fonksîyonî ya ku cebraya peywendîdar bi bêkêmasî li hev dike, û kapasîteyên wê bandorek wusa li pêşdebirên ku bi MySQL-ê re fêr bûne çêkir ku hewcedariya bihêzkirina rêzan bi analîstên bi ezmûn re wekî roj eşkere bû.
Hewldanên din ên Apache Spark / Hadoop ku rabin û ya ku li gorî senaryoyê neçû
Lêbelê, zû eşkere bû ku tiştek bi pergalê bi Spark re ne rast bû, an jî hewce bû ku destên xwe çêtir bişon. Ger stoka Hadoop/MapReduce/Lucene ji hêla bernamenûsên bi tecrube ve hatî çêkirin, ev eşkere ye ku heke hûn ji nêz ve li koda çavkaniyê ya Java an jî ramanên Doug Cutting li Lucene binerin, wê hingê Spark, ji nişkê ve, bi zimanê biyanî Scala, ku ev e, tê nivîsandin. ji hêla pratîkî ve pir nakokî ye û niha pêş nakeve. Û daketina birêkûpêk a hesabên li ser koma Spark ji ber xebata ne mentiqî û ne pir zelal bi veqetandina bîranînê re ji bo kêmkirina operasyonan (gelek bişkok bi yekcarî digihîjin) li dora wê haloyek tiştek çêkiriye ku cîhê mezinbûnê heye. Digel vê yekê, rewş ji hêla hejmarek mezin ji portên vekirî yên xerîb, pelên demkî yên ku li cîhên herî nayên têgihîştin mezin dibin û dojehek girêdayiyên jar girantir bû - ku ev yek bû sedem ku rêvebirên pergalê bibin xwedî yek hestek ku ji zarokatiyê ve baş tê zanîn: nefreta dijwar (an belkî hewce bû ku destên xwe bi sabûnê bişon).
Wekî encamek, me ji gelek projeyên analîtîk ên hundurîn "bijî" ku bi çalak Apache Spark (di nav de Spark Streaming, Spark SQL) û ekosîstema Hadoop (û hwd û hwd) bikar tînin. Digel vê yekê ku bi demê re em fêr bûn ku em "ew" pir baş amade bikin û çavdêrî bikin, û "ew" bi pratîkî ji nişkê ve ji ber guheztinên xwezaya daneyan û nehevsengiya hevsengiya RDD-ya yekgirtî rawestiya, xwesteka ku em tiştek jixwe amade bikin. , nûvekirin û rêvebirinê li cîhek ewr bi hêztir û bihêztir bû. Di vê demê de bû ku me hewl da ku meclîsa ewr a amadekirî ya Karûbarên Webê yên Amazon bikar bînin - û, paşê, hewl da ku pirsgirêkan bi karanîna wê çareser bike. EMR Apache Spark e ku ji hêla Amazon ve bi nermalava pêvek ji ekosîstemê ve hatî amadekirin, mîna avahîyên Cloudera / Hortonworks.
Ji bo analîtîk hilanîna pelê gomî hewcedariyek lezgîn e
Tecrûbeya "çêkirina" Hadoop/Sparkê bi şewatên cihêreng ên laş ne vala bû. Pêdiviya afirandina hilanîna pelan a yekane, erzan û pêbawer ku li hember têkçûnên hardware berxwedêr be û tê de gengaz e ku pelan bi formên cûda ji pergalên cihêreng hilîne û ji bo raporên ji van daneyan nimûneyên bikêr û bikêr û demdirêj were çêkirin, her ku diçe zêde dibe. zelal.
Di heman demê de min dixwest ku nûvekirina nermalava vê platformê bi xwendina şopên Java-ya 20-rûpelî û analîzkirina têketinên kîlometrî yên berfireh ên komê bi karanîna Pêşkêşkara Dîroka Spark û şûşeyek mezinker a paşverû venegere kabûsek Sersalê. Min dixwest ku ez amûrek sade û zelal a ku hewcedariya dakêşana birêkûpêk di binê kapê de nebe hebe ger ku daxwaznameya standard ya pêşdebiran MapReduce cîbicîkirina rawestîne dema ku xebatkarê daneya kêmkirinê ji bîrê ket ji ber algorîtmayek dabeşkirina daneya çavkaniyê ne pir baş bijartî.
Ma Amazon S3 berendamek DataLake ye?
Tecrûbeya bi Hadoop/MapReduce re ji me re hîn kir ku ji me re pêdivî bi pergalek pelê ya berbelavkirî, pêbawer û xebatkarên pêbawer ên li ser wê heye, ku "werin" nêzîkê daneyê bibin da ku daneyan li ser torê nehêlin. Karker divê bikaribin daneyan bi formên cihêreng bixwînin, lê çêtir e ku agahdariya nepêwist nexwînin û karibin daneyan di pêşwext de di formên ku ji bo karkeran re guncan e hilînin.
Careke din, ramana bingehîn. Ti xwestek tune ku hûn daneyên mezin "rijînin" di motorek analîtîk a komê de, ku zû an dereng dê bifetisîne û hûn neçar in ku wê xirav bişikînin. Ez dixwazim pelan, tenê pelan, di formek têgihîştî de hilînim û bi karanîna amûrên cihêreng lê têgihîştî pirsên analîtîk ên bi bandor li ser wan bikim. Û dê bêtir û bêtir pelên di formatên cuda de hene. Û çêtir e ku meriv ne motorê, lê daneyên çavkaniyê bişewitîne. Em hewceyê DataLake-ya berfireh û gerdûnî ne, me biryar da ...
Ger hûn pelan di hilanîna cloudê ya berbiçav û naskirî ya Amazon S3 de hilînin, bêyî ku hûn çîpên xwe ji Hadoop amade bikin?
Eşkere ye ku daneyên kesane "kêm" e, lê heke em wan derxin derve û "wê bi bandor bimeşînin" çi dibe bila bibe?
Cluster-bigdata-analîtîk ekosîstema Karûbarên Webê yên Amazon - bi gotinên pir hêsan
Li gorî ezmûna me ya bi AWS-ê re dadbar kirin, Apache Hadoop / MapReduce ji bo demek dirêj ve li wir di bin sosên cihêreng de bi rengek çalak tê bikar anîn, mînakî di karûbarê DataPipeline de (ez ji hevkarên xwe re çavnebar dikim, ew fêr bûn ku meriv wê çawa rast amade dike). Li vir em ji tabloyên DynamoDB ji karûbarên cihêreng paşvekêşan saz dikin:
Û ew ev çend sal in ku bi rêkûpêk li ser komên Hadoop/MapReduce yên bicîbûyî yên mîna demjimêran dixebitin. "Wê saz bike û ji bîr bike":
Her weha hûn dikarin bi şeytanîzma daneyê bi bandorkerî bi sazkirina laptopên Jupiter di ewr de ji bo analîstan û karanîna karûbarê AWS SageMaker bikar bînin da ku modelên AI-ê di şer de perwerde bikin û bicîh bikin. Li vir ew ji bo me çawa xuya dike:
Erê, hûn dikarin ji bo xwe an analîstek di ewrê de laptopek hildin û wê bi komek Hadoop/Spark ve girêbidin, hesaban bikin û dûv re her tiştî bişkînin:
Bi rastî ji bo projeyên analîtîk ên kesane rehet e û ji bo hinan me bi serfirazî karûbarê EMR ji bo hesab û analîtîkên mezin bikar aniye. Der barê çareseriyek pergalê ya DataLake de, ew ê bixebite? Di vê kêliyê de em li ber hêvî û bêhêvîtiyê bûn û lêgerîna me berdewam kir.
AWS Glue - Apache Spark bi xweşikî li ser steroîdên pakkirî
Derket holê ku AWS guhertoya xwe ya stoka "Hive / Pig / Spark" heye. Rola Hîvê, yanî. Kataloga pelan û celebên wan di DataLake de ji hêla karûbarê "Kataloga Daneyê" ve tête kirin, ku lihevhatina xwe bi formata Apache Hive venaşêre. Pêdivî ye ku hûn agahdarî li ser vê karûbarê zêde bikin ka pelên we li ku derê ne û di kîjan formatê de ne. Daneyên ne tenê di s3 de, lê di heman demê de di databasê de jî hene, lê ew ne mijara vê postê ye. Li vir pelrêça daneya meya DataLake çawa hatî organîze kirin:
Pelên qeydkirî ne, mezin. Ger pel hatine nûve kirin, em crawlers an bi destan an jî li gorî bernameyek dest pê dikin, ku dê agahdariya li ser wan ji golê nûve bike û wan xilas bike. Dûv re daneyên ji golê têne hilberandin û encam li cîhek têne barkirin. Di rewşa herî hêsan de, em li s3 jî bar dikin. Pêvajoya daneyê dikare li her deverê were kirin, lê tê pêşniyar kirin ku hûn pêvajoyê li ser komek Apache Spark bi karanîna kapasîteyên pêşkeftî bi navgîniya API-ya AWS Glue mîheng bikin. Di rastiyê de, hûn dikarin bi karanîna pirtûkxaneya pyspark koda python a baş a kevn û nas bistînin û bi çavdêrîkirinê ve pêkanîna wê li ser N girêkên komek hin kapasîteyên bi çavdêrîkirinê mîheng bikin, bêyî ku bikevin nav zikê Hadoop û kaşkirina konteynerên docker-moker û ji holê rakirina nakokiyên girêdayîbûnê. .
Careke din, ramanek hêsan. Ne hewce ye ku hûn Apache Spark mîheng bikin, hûn tenê hewce ne ku koda python ji bo pyspark binivîsin, wê li ser sermaseya xweya herêmî biceribînin û dûv re wê li ser komikek mezin a di ewr de bimeşînin, diyar bikin ka daneya çavkaniyê li ku ye û li ku derê ye ku encam bide. Carinan ev pêdivî û bikêr e, û li vir em çawa saz dikin:
Ji ber vê yekê, heke hûn hewce ne ku tiştek li ser komek Spark bi karanîna daneyên s3-ê bihesibînin, em kodê di python/pyspark de dinivîsin, ceribandinê dikin, û ji ewr re serkeftin.
Li ser orkestrasyonê çi ye? Ger peywir ket û wenda bû? Erê, tê pêşniyar kirin ku di şêwaza Apache Pig de boriyek xweşik were çêkirin û me tewra wan jî ceriband, lê naha me biryar da ku em orkestrasyona xweya kûr a xwerû di PHP û JavaScript-ê de bikar bînin (ez fam dikim, nehevsengiya cognitive heye, lê ew dixebite, ji bo salan û bê xeletî).
Formata pelên ku di golê de hatine hilanîn mifteya performansê ye
Pir, pir girîng e ku meriv du xalên din ên sereke fam bike. Ji bo ku lêpirsînên li ser daneyên pelê yên li golê bi lez û bez bêne darve kirin û dema ku agahdariya nû lê zêde dibe performans xirab nebe, hûn hewce ne:
- Stûnên pelan ji hev cuda hilînin (da ku hûn ne hewce ne ku hûn hemî rêzan bixwînin da ku hûn fêm bikin ka di stûnan de çi ye). Ji bo vê me formata parketê ya bi kompresyonê girt
- Pir girîng e ku pelan di peldankên wekî: ziman, sal, meh, roj, hefte de bihejînin. Motorên ku bi vî rengî parvekirinê fam dikin dê tenê li peldankên pêwîst binihêrin, bêyî ku hemî daneyan di rêzê de bişopînin.
Di bingeh de, bi vî rengî, hûn daneyên çavkaniyê di forma herî bikêr de ji bo motorên analîtîk ên ku li jor hatine daliqandin, datînin, ku tewra di peldankên şikestî de jî dikarin bi bijartî têkevin û tenê stûnên pêwîst ji pelan bixwînin. Hûn ne hewce ne ku daneyan li her deverê "dagirtin" bikin (hilanîn dê bi tenê biteqe) - tenê tavilê bi aqilmendî wê bi forma rast di pergala pelan de bihêlin. Bê guman, divê li vir zelal be ku hilanîna pelek csv ya mezin li DataLake, ku divê pêşî rêz bi rêz ji hêla komê ve were xwendin da ku stûnan derxîne, ne pir şîret e. Li ser her du xalên jorîn dîsa bifikire heke hîn ne diyar e çima ev hemî diqewimin.
AWS Athena - jack-in-the-box
Û dûv re, dema ku golek diafirand, em bi rengek bêhemdî rastî Amazon Athena hatin. Ji nişkê ve derket holê ku bi bi baldarî vesazkirina pelên meyên mezin ên têketinê di peldanka peldankê de di forma stûnê ya rast (parket) de, hûn dikarin pir zû ji wan vebijarkên pir agahdar bikin û BÊR, bêyî komek Apache Spark / Glue raporan ava bikin.
Motora Athena ku ji hêla daneyên s3 ve hatî hêzdar kirin li ser bingeha efsanewî ye - Nûnerek ji malbata MPP (pêvajoya paralel a girseyî) nêzîkatiyên ji bo hilanîna daneyê, girtina daneyan li ku derê ye, ji s3 û Hadoop heya Cassandra û pelên nivîsê yên asayî. Hûn tenê hewce ne ku ji Athena bipirsin ku pirsek SQL bicîh bike, û dûv re her tişt "zû û bixweber dixebite." Girîng e ku bala xwe bidinê ku Athena "aqilmend" e, ew tenê diçe peldankên şikestî yên pêwîst û tenê stûnên ku di daxwaznameyê de hewce ne dixwîne.
Bihayê daxwazên ji Athena re jî balkêş e. Em pere didin . Ewan. ne ji bo hejmara makîneyên di komê de di hûrdemê de, lê… ji bo daneyên ku bi rastî li ser 100-500 makîneyan hatine skankirin, tenê daneyên ku ji bo temamkirina daxwazê hewce ne.
Û bi daxwaza tenê sitûnên pêwîst ji peldankên bi rêkûpêk hatine şelandin, derket holê ku karûbarê Athena mehê bi dehan dolar mesrefa me dike. Welê, mezin, hema belaş, li gorî analîtîkên li ser koman!
Bi awayê, li vir em çawa daneyên xwe di s3 de parve dikin:
Wekî encamek, di demek kin de, beşên bi tevahî cihêreng ên pargîdaniyê, ji ewlehiya agahdariyê bigire heya analîtîk, bi aktîvî dest bi daxwazan ji Athena kirin û zû, di nav çirkeyan de, bersivên kêrhatî ji daneyên "mezin" di serdemên pir dirêj de werdigirin: mehan, nîv sal, hwd. P.
Lê em hê wêdetir çûn û ji bo bersivan dest bi çûna ber ewr kirin : analîstek di konsolek naskirî de pirsek SQL dinivîse, ku li ser 100-500 makîneyan "ji bo peran" daneyan ji s3 re dişîne û bi gelemperî di çend saniyan de bersivek vedigerîne. Rehet. Û bi lez. Ez hîn jî bawer nakim.
Wekî encamek, me biryar da ku daneyan di s3 de, bi rengek stûnek bikêrhatî û bi parvekirina maqûl a daneyan di peldankan de hilînin... me DataLake û motorek analîtîk a bilez û erzan - belaş wergirt. Û ew di şirketê de pir populer bû, ji ber ku ... SQL fam dike û fermanên mezinahiyê ji destpêkirina / rawestandin / sazkirina koman zûtir dixebite. "Û heke encam yek e, çima bêtir bidin?"
Daxwazek ji Athena re tiştek wusa xuya dike. Ger bixwaze, bê guman, hûn dikarin têra xwe ava bikin , lê em ê xwe bi komkirina hêsan sînordar bikin. Ka em bibînin ka xerîdar çend hefte berê di têketinên servera malperê de kîjan kodên bersivdanê hebûn û pê ewle bin ku xeletî tune:
vebiguherin
Piştî ku em rêyek dûr û dirêj, lê bi êş derbas bûn, bi domdarî xetere û asta tevlihevî û lêçûna piştgirîyê bi guncan dinirxînin, me çareseriyek ji bo DataLake û analîtîk dît ku çu carî dev jê bernade ku hem bi lez û hem jî bi lêçûna xwedaniyê dilxweş bike.
Derket holê ku avakirina DataLake ya bi bandor, bilez û erzan a xebitandina ji bo hewcedariyên beşên bi tevahî cihêreng ên pargîdaniyê bi tevahî di hundurê kapasîteyên pêşdebirên bi ezmûn de ye ku tu carî wekî mîmar kar nekiriye û nizanin ka meriv çawa li çargoşeyan bi tîrên û 50 şertên ji ekosîstema Hadoop dizanin.
Di destpêka rêwîtiyê de, serê min ji gelek zozanên çolê yên nermalava vekirî û girtî û têgihîştina barê berpirsiyariya ji dûndanan re veqetiya. Tenê dest bi avakirina DataLake-ya xwe ji amûrên hêsan bikin: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., berhevkirina bertekan û bi kûr ve têgihîştina fizîkî ya pêvajoyên ku diqewimin. Her tişt tevlihev û tarî - wê bidin dijmin û hevrikan.
Heke hûn nexwazin ku hûn biçin ewr û hez bikin ku piştgirî, nûvekirin û projeyên çavkaniya vekirî bişopînin, hûn dikarin nexşeyek mîna ya meya herêmî, li ser makîneyên nivîsgehê yên erzan ên li ser Hadoop û Presto ava bikin. Ya sereke ne ev e ku meriv raweste û pêşde neçe, jimartin, li çareseriyên sade û zelal bigerin, û her tişt bê guman dê bi ser bikeve! Serkeftin ji her kesî re û dîsa we bibînin!
Source: www.habr.com