Rydyn ni'n byw mewn amser anhygoel pan allwch chi gysylltu sawl teclyn ffynhonnell agored parod yn gyflym ac yn hawdd, eu gosod gyda'ch “ymwybyddiaeth wedi'i ddiffodd” yn ôl cyngor stackoverflow, heb ymchwilio i'r “llythyrau lluosog”, a lansio iddynt gael eu gweithredu'n fasnachol. A phan mae angen diweddaru/ehangu neu mae rhywun yn ailgychwyn cwpl o beiriannau yn ddamweiniol - rydych chi'n sylweddoli bod rhyw fath o freuddwyd ddrwg obsesiynol wedi dechrau, mae popeth wedi dod yn gymhleth yn ddramatig y tu hwnt i adnabyddiaeth, nid oes troi yn ôl, mae'r dyfodol yn amwys ac yn fwy diogel, yn lle rhaglennu, bridio gwenyn a gwneud caws.
Nid am ddim y mae cydweithwyr mwy profiadol, gyda’u pennau’n frith o fygiau ac felly eisoes yn llwyd, yn ystyried y defnydd hynod gyflym o becynnau o “gynwysyddion” mewn “ciwbiau” ar ddwsinau o weinyddion mewn “ieithoedd ffasiynol” gyda chefnogaeth adeiledig i asynchronous non-blocking I/O, gwenu'n gymedrol . Ac maen nhw'n dawel yn parhau i ailddarllen “man ps”, yn ymchwilio i'r cod ffynhonnell “nginx” nes bod eu llygaid yn gwaedu, ac yn ysgrifennu, ysgrifennu, ysgrifennu profion uned. Mae cydweithwyr yn gwybod y daw’r peth mwyaf diddorol pan ddaw “hyn i gyd” un diwrnod yn sownd yn y nos ar Nos Galan. A dim ond dealltwriaeth ddofn o natur unix, y tabl cyflwr TCP/IP wedi'i gofio ac algorithmau chwilio didoli sylfaenol fydd yn eu helpu. I ddod â'r system yn ôl yn fyw wrth i'r clychau daro.
O ie, fe wnes i dynnu fy sylw ychydig, ond rwy'n gobeithio y llwyddais i gyfleu'r cyflwr o ragweld.
Heddiw, rwyf am rannu ein profiad o ddefnyddio pentwr cyfleus a rhad ar gyfer DataLake, sy'n datrys y mwyafrif o dasgau dadansoddol yn y cwmni ar gyfer adrannau strwythurol cwbl wahanol.
Beth amser yn ôl, daethom i'r ddealltwriaeth bod cwmnïau angen mwy a mwy o ffrwyth dadansoddeg cynnyrch a thechnegol (heb sôn am yr eisin ar y gacen ar ffurf dysgu peirianyddol) ac i ddeall tueddiadau a risgiau - mae angen i ni gasglu a dadansoddi mwy a mwy o fetrigau.
Dadansoddeg dechnegol sylfaenol yn Bitrix24
Sawl blwyddyn yn ôl, ar yr un pryd â lansiad gwasanaeth Bitrix24, gwnaethom fuddsoddi amser ac adnoddau'n weithredol i greu llwyfan dadansoddol syml a dibynadwy a fyddai'n helpu i weld problemau yn y seilwaith yn gyflym a chynllunio'r cam nesaf. Wrth gwrs, fe'ch cynghorir i gymryd offer parod a oedd mor syml a dealladwy â phosibl. O ganlyniad, dewiswyd nagios ar gyfer monitro a munin ar gyfer dadansoddeg a delweddu. Nawr mae gennym filoedd o wiriadau yn nagios, cannoedd o siartiau yn munin, ac mae ein cydweithwyr yn eu defnyddio'n llwyddiannus bob dydd. Mae'r metrigau yn glir, mae'r graffiau'n glir, mae'r system wedi bod yn gweithio'n ddibynadwy ers sawl blwyddyn ac mae profion a graffiau newydd yn cael eu hychwanegu ato'n rheolaidd: pan fyddwn yn rhoi gwasanaeth newydd ar waith, rydym yn ychwanegu nifer o brofion a graffiau. Pob lwc.
Bys ar y Pwls - Dadansoddeg Technegol Uwch
Arweiniodd yr awydd i dderbyn gwybodaeth am broblemau “cyn gynted â phosibl” ni at arbrofion gweithredol gydag offer syml a dealladwy - pinba a xhprof.
Anfonodd Pinba ystadegau atom mewn pecynnau CDU am gyflymder gweithredu rhannau o dudalennau gwe yn PHP, a gallem weld ar-lein yn y storfa MySQL (mae Pinba yn dod gyda'i injan MySQL ei hun ar gyfer dadansoddeg digwyddiadau cyflym) restr fer o broblemau ac ymateb i nhw. Ac roedd xhprof yn caniatáu i ni yn awtomatig gasglu graffiau o weithrediad y tudalennau PHP arafaf gan gleientiaid a dadansoddi'r hyn a allai arwain at hyn - yn bwyllog, arllwys te neu rywbeth cryfach.
Beth amser yn ôl, cafodd y pecyn cymorth ei ailgyflenwi ag injan weddol syml a dealladwy arall yn seiliedig ar yr algorithm mynegeio cefn, a weithredwyd yn berffaith yn llyfrgell chwedlonol Lucene - Elastic/Kibana. Trodd y syniad syml o gofnodi dogfennau mewn sawl edafedd i fynegai Lucene gwrthdro yn seiliedig ar ddigwyddiadau yn y logiau a chwiliad cyflym trwyddynt gan ddefnyddio rhaniad ffased yn ddefnyddiol iawn.
Er gwaethaf ymddangosiad eithaf technegol delweddu yn Kibana gyda chysyniadau lefel isel fel “bwced” “yn llifo i fyny” ac iaith wedi'i hailddyfeisio'r algebra perthynol nad yw wedi'i hanghofio'n llwyr eto, dechreuodd yr offeryn ein helpu'n dda yn y tasgau canlynol:
- Faint o wallau PHP oedd gan y cleient Bitrix24 ar y porth p1 yn yr awr ddiwethaf a pha rai? Deall, maddau a chywiro'n gyflym.
- Faint o alwadau fideo a wnaed ar byrth yn yr Almaen yn ystod y 24 awr flaenorol, gyda pha ansawdd ac a oedd unrhyw anawsterau gyda'r sianel / rhwydwaith?
- Pa mor dda y mae ymarferoldeb y system (ein estyniad C ar gyfer PHP), a luniwyd o'r ffynhonnell yn y diweddariad gwasanaeth diweddaraf a'i gyflwyno i gleientiaid, yn gweithio? A oes segfaults?
- A yw data cwsmeriaid yn ffitio i mewn i gof PHP? A oes unrhyw wallau ynghylch mynd dros y cof a neilltuwyd i brosesau: “allan o gof”? Darganfod a niwtraleiddio.
Dyma enghraifft bendant. Er gwaethaf profion trylwyr ac aml-lefel, derbyniodd y cleient, gydag achos ansafonol iawn a data mewnbwn wedi'i ddifrodi, gamgymeriad annifyr ac annisgwyl, roedd seiren yn swnio a dechreuodd y broses o'i drwsio'n gyflym:
Yn ogystal, mae kibana yn caniatáu ichi drefnu hysbysiadau ar gyfer digwyddiadau penodol, ac mewn amser byr dechreuodd dwsinau o weithwyr o wahanol adrannau ddefnyddio'r offeryn yn y cwmni - o gefnogaeth dechnegol a datblygiad i SA.
Mae gweithgaredd unrhyw adran o fewn y cwmni wedi dod yn gyfleus i'w olrhain a'i fesur - yn lle dadansoddi logiau â llaw ar weinyddion, does ond angen i chi sefydlu logiau dosrannu unwaith a'u hanfon at y clwstwr elastig i fwynhau, er enghraifft, ystyried yn y kibana. dangosfwrdd nifer y cathod bach dau ben a werthwyd a argraffwyd ar argraffydd 3-D ar gyfer y mis lleuad diwethaf.
Dadansoddeg Busnes Sylfaenol
Mae pawb yn gwybod bod dadansoddeg busnes mewn cwmnïau yn aml yn dechrau gyda defnydd hynod weithgar o, ie, Excel. Ond y prif beth yw nad yw'n gorffen yno. Mae Google Analytics yn y cwmwl hefyd yn ychwanegu tanwydd at y tân - rydych chi'n dechrau dod i arfer â'r pethau da yn gyflym.
Yn ein cwmni sy’n datblygu’n gytûn, yma ac acw dechreuodd “proffwydi” o waith dwysach gyda data mwy ymddangos. Dechreuodd yr angen am adroddiadau mwy manwl ac amlochrog ymddangos yn rheolaidd, a thrwy ymdrechion dynion o wahanol adrannau, beth amser yn ôl trefnwyd datrysiad syml ac ymarferol - cyfuniad o ClickHouse a PowerBI.
Am gyfnod eithaf hir, roedd yr ateb hyblyg hwn wedi helpu llawer, ond yn raddol dechreuodd y ddealltwriaeth ddod nad yw ClickHouse yn rwber ac na ellir ei watwar fel hynny.
Yma, mae'n bwysig deall yn iawn bod ClickHouse, fel Druid, fel Vertica, fel Amazon RedShift (sy'n seiliedig ar postgres), yn beiriannau dadansoddol sydd wedi'u optimeiddio ar gyfer dadansoddeg eithaf cyfleus (symiau, agregau, lleiafswm-uchafswm fesul colofn ac ychydig o ymuniadau posibl). ), achos wedi'i drefnu ar gyfer storio colofnau o dablau perthynol yn effeithlon, yn wahanol i MySQL a chronfeydd data eraill (rhes-oriented) sy'n hysbys i ni.
Yn ei hanfod, dim ond “cronfa ddata” fwy galluog yw ClickHouse, heb fewnosod pwynt-wrth-bwynt cyfleus iawn (dyna sut y bwriedir, mae popeth yn iawn), ond dadansoddeg ddymunol a set o swyddogaethau pwerus diddorol ar gyfer gweithio gyda data. Gallwch, gallwch chi hyd yn oed greu clwstwr - ond rydych chi'n deall nad yw morthwylio ewinedd â microsgop yn gwbl gywir a dechreuon ni chwilio am atebion eraill.
Galw am python a dadansoddwyr
Mae gan ein cwmni lawer o ddatblygwyr sy'n ysgrifennu cod bron bob dydd am 10-20 mlynedd yn PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. Mae yna hefyd lawer o weinyddwyr system profiadol sydd wedi profi mwy nag un trychineb hollol anhygoel nad yw'n cyd-fynd â chyfreithiau ystadegau (er enghraifft, pan fydd mwyafrif y disgiau mewn cyrch-10 yn cael eu dinistrio gan streic mellt cryf). Mewn amgylchiadau o'r fath, am amser hir nid oedd yn glir beth oedd "dadansoddwr python". Mae Python fel PHP, dim ond yr enw sydd ychydig yn hirach ac mae ychydig yn llai o olion o sylweddau sy'n newid meddwl yng nghod ffynhonnell y cyfieithydd. Fodd bynnag, wrth i fwy a mwy o adroddiadau dadansoddol gael eu creu, dechreuodd datblygwyr profiadol ddeall yn gynyddol bwysigrwydd arbenigo cul mewn offer fel numpy, pandas, matplotlib, seaborn.
Chwaraewyd y rôl bendant, yn fwyaf tebygol, gan lewygu sydyn gweithwyr o'r cyfuniad o'r geiriau “atchweliad logistaidd” ac arddangosiad o adrodd effeithiol ar ddata mawr gan ddefnyddio, ie, ie, pyspark.
Gwnaeth Apache Spark, ei batrwm swyddogaethol lle mae algebra perthynol yn cyd-fynd yn berffaith, a'i alluoedd wneud cymaint o argraff ar ddatblygwyr sy'n gyfarwydd â MySQL nes bod yr angen i gryfhau'r rhengoedd gyda dadansoddwyr profiadol wedi dod yn amlwg fel y dydd.
Ymdrechion pellach gan Apache Spark / Hadoop i dynnu a beth nad aeth yn hollol yn ôl y sgript
Fodd bynnag, daeth yn amlwg yn fuan nad oedd rhywbeth yn iawn yn systematig gyda Spark, neu yn syml roedd angen golchi'ch dwylo'n well. Os gwnaed y stac Hadoop/MapReduce/Lucene gan raglenwyr gweddol brofiadol, sy'n amlwg os edrychwch yn ofalus ar y cod ffynhonnell yn Java neu syniadau Doug Cutting yn Lucene, yna mae Spark, yn sydyn, wedi'i ysgrifennu yn yr iaith egsotig Scala, sef dadleuol iawn o safbwynt ymarferoldeb ac nid yw'n datblygu ar hyn o bryd. Ac mae'r gostyngiad rheolaidd mewn cyfrifiadau ar y clwstwr Spark oherwydd gwaith afresymegol a heb fod yn dryloyw iawn gyda dyraniad cof ar gyfer gweithrediadau lleihau (mae llawer o allweddi'n cyrraedd ar unwaith) wedi creu halo o'i gwmpas o rywbeth sydd â lle i dyfu. Yn ogystal, gwaethygwyd y sefyllfa gan nifer fawr o borthladdoedd agored rhyfedd, ffeiliau dros dro yn tyfu yn y mannau mwyaf annealladwy ac uffern o ddibyniaethau jar - a achosodd i weinyddwyr systemau gael un teimlad a oedd yn adnabyddus o blentyndod: casineb ffyrnig (neu efallai roedd angen iddynt olchi eu dwylo â sebon).
O ganlyniad, rydym wedi “goroesi” sawl prosiect dadansoddol mewnol sy'n defnyddio Apache Spark yn weithredol (gan gynnwys Spark Streaming, Spark SQL) ac ecosystem Hadoop (ac yn y blaen ac yn y blaen). Er gwaethaf y ffaith ein bod dros amser wedi dysgu sut i baratoi a monitro “it” yn eithaf da, a bod “it” bron wedi rhoi'r gorau i chwalu'n sydyn oherwydd newidiadau yn natur y data ac anghydbwysedd stwnsio RDD unffurf, yr awydd i gymryd rhywbeth sydd eisoes yn barod. , diweddaru a gweinyddu rhywle yn y cwmwl tyfodd cryfach ac yn gryfach. Ar yr adeg hon y gwnaethom geisio defnyddio'r gwasanaeth cwmwl parod o Amazon Web Services - ac, wedi hynny, ceisio datrys problemau wrth ei ddefnyddio. EMR yw Apache Spark a baratowyd gan Amazon gyda meddalwedd ychwanegol o'r ecosystem, yn debyg iawn i Cloudera/Hortonworks builds.
Mae storio ffeiliau rwber ar gyfer dadansoddeg yn angen brys
Nid oedd y profiad o “goginio” Hadoop/Spark gyda llosgiadau i wahanol rannau o'r corff yn ofer. Daeth yr angen i greu un storfa ffeiliau, rhad a dibynadwy a fyddai’n gwrthsefyll methiannau caledwedd a lle byddai’n bosibl storio ffeiliau mewn fformatau gwahanol o systemau gwahanol a gwneud samplau effeithlon ac amser-effeithiol ar gyfer adroddiadau o’r data hwn yn gynyddol. clir.
Roeddwn hefyd eisiau na fyddai diweddaru meddalwedd y platfform hwn yn troi'n hunllef Blwyddyn Newydd gyda darllen olion Java 20 tudalen a dadansoddi logiau manwl cilomedr o hyd o'r clwstwr gan ddefnyddio Spark History Server a chwyddwydr wedi'i oleuo'n ôl. Roeddwn i eisiau cael teclyn syml a thryloyw nad oedd angen plymio rheolaidd o dan y cwfl pe bai cais safonol MapReduce y datblygwr yn rhoi'r gorau i weithredu pan syrthiodd y gweithiwr lleihau data allan o gof oherwydd algorithm rhannu data ffynhonnell nad yw wedi'i ddewis yn dda iawn.
A yw Amazon S3 yn ymgeisydd ar gyfer DataLake?
Dysgodd profiad gyda Hadoop/MapReduce i ni fod angen system ffeiliau scalable, dibynadwy a gweithwyr graddadwy ar ei ben, “dod” yn agosach at y data er mwyn peidio â gyrru'r data dros y rhwydwaith. Dylai gweithwyr allu darllen data mewn fformatau gwahanol, ond o ddewis peidio â darllen gwybodaeth ddiangen a gallu storio data ymlaen llaw mewn fformatau sy'n gyfleus i weithwyr.
Unwaith eto, y syniad sylfaenol. Nid oes unrhyw awydd i “arllwys” data mawr i mewn i beiriant dadansoddol clwstwr sengl, a fydd yn tagu yn hwyr neu'n hwyrach a bydd yn rhaid i chi ei dorri'n hyll. Rwyf am storio ffeiliau, dim ond ffeiliau, mewn fformat dealladwy a pherfformio ymholiadau dadansoddol effeithiol arnynt gan ddefnyddio offer gwahanol ond dealladwy. A bydd mwy a mwy o ffeiliau mewn gwahanol fformatau. Ac mae'n well torri nid yr injan, ond y data ffynhonnell. Mae angen DataLake estynadwy a chyffredinol arnom, fe wnaethom benderfynu...
Beth os ydych chi'n storio ffeiliau yn y storfa cwmwl scalable cyfarwydd ac adnabyddus Amazon S3, heb orfod paratoi eich golwythion eich hun o Hadoop?
Mae’n amlwg bod y data personol yn “isel”, ond beth am ddata arall os byddwn yn ei gymryd allan ac yn ei “yrru’n effeithiol”?
ecosystem Cluster-bigdata-analytics o Amazon Web Services - mewn geiriau syml iawn
A barnu yn ôl ein profiad gydag AWS, mae Apache Hadoop / MapReduce wedi cael ei ddefnyddio'n weithredol yno ers amser maith o dan amrywiol sawsiau, er enghraifft yn y gwasanaeth DataPipeline (Rwy'n eiddigeddus wrth fy nghydweithwyr, dysgon nhw sut i'w baratoi'n gywir). Yma rydym yn sefydlu copïau wrth gefn o wahanol wasanaethau o dablau DynamoDB:
Ac maen nhw wedi bod yn rhedeg yn rheolaidd ar glystyrau Hadoop / MapReduce sydd wedi'u hymgorffori fel gwaith cloc ers sawl blwyddyn bellach. “Gosodwch ac anghofiwch ef”:
Gallwch hefyd gymryd rhan yn effeithiol mewn sataniaeth data trwy sefydlu gliniaduron Jupiter yn y cwmwl ar gyfer dadansoddwyr a defnyddio gwasanaeth AWS SageMaker i hyfforddi a defnyddio modelau AI i frwydr. Dyma sut mae'n edrych i ni:
Ac ie, gallwch chi godi gliniadur i chi'ch hun neu ddadansoddwr yn y cwmwl a'i gysylltu â chlwstwr Hadoop / Spark, gwneud y cyfrifiadau ac yna hoelio popeth i lawr:
Yn gyfleus iawn ar gyfer prosiectau dadansoddol unigol ac i rai rydym wedi defnyddio'r gwasanaeth EMR yn llwyddiannus ar gyfer cyfrifiadau a dadansoddeg ar raddfa fawr. Beth am ddatrysiad system ar gyfer DataLake, a fydd yn gweithio? Ar hyn o bryd roeddem ar fin gobaith ac anobaith a pharhau i chwilio.
Glud AWS - Apache Spark wedi'i becynnu'n daclus ar steroidau
Daeth i'r amlwg bod gan AWS ei fersiwn ei hun o'r pentwr “Hive/Pig/Spark”. Rôl Hive, h.y. Mae'r catalog o ffeiliau a'u mathau yn DataLake yn cael ei berfformio gan y gwasanaeth “data catalog”, nad yw'n cuddio ei gydnawsedd â fformat Apache Hive. Mae angen i chi ychwanegu gwybodaeth at y gwasanaeth hwn am leoliad eich ffeiliau ac ym mha fformat y maent. Gall y data fod nid yn unig yn a3, ond hefyd yn y gronfa ddata, ond nid dyna yw testun y swydd hon. Dyma sut mae ein cyfeiriadur data DataLake wedi'i drefnu:
Mae'r ffeiliau wedi'u cofrestru, gwych. Os yw'r ffeiliau wedi'u diweddaru, rydym yn lansio ymlusgwyr naill ai â llaw neu ar amserlen, a fydd yn diweddaru gwybodaeth amdanynt o'r llyn a'u cadw. Yna gellir prosesu'r data o'r llyn a llwytho'r canlyniadau i fyny yn rhywle. Yn yr achos symlaf, rydym hefyd yn uwchlwytho i s3. Gellir gwneud prosesu data yn unrhyw le, ond awgrymir eich bod yn ffurfweddu'r prosesu ar glwstwr Apache Spark gan ddefnyddio galluoedd uwch trwy API Glud AWS. Mewn gwirionedd, gallwch chi gymryd y cod python hen a chyfarwydd da gan ddefnyddio'r llyfrgell pyspark a ffurfweddu ei weithrediad ar nodau N o glwstwr o rywfaint o allu gyda monitro, heb gloddio i mewn i berfedd Hadoop a llusgo cynwysyddion tocwyr-moker a dileu gwrthdaro dibyniaeth. .
Unwaith eto, syniad syml. Nid oes angen ffurfweddu Apache Spark, does ond angen i chi ysgrifennu cod python ar gyfer pyspark, ei brofi'n lleol ar eich bwrdd gwaith ac yna ei redeg ar glwstwr mawr yn y cwmwl, gan nodi ble mae'r data ffynhonnell a ble i roi'r canlyniad. Weithiau mae hyn yn angenrheidiol ac yn ddefnyddiol, a dyma sut mae wedi'i ffurfweddu yma:
Felly, os oes angen i chi gyfrifo rhywbeth ar glwstwr Spark gan ddefnyddio data yn s3, rydyn ni'n ysgrifennu cod yn python / pyspark, yn ei brofi, a phob lwc i'r cwmwl.
Beth am yr offeryniaeth? Beth pe bai'r dasg yn disgyn ac yn diflannu? Ydy, cynigir gwneud piblinell hardd yn arddull Apache Pig ac fe wnaethom hyd yn oed roi cynnig arnynt, ond am y tro fe benderfynon ni ddefnyddio ein cerddorfa wedi'i haddasu'n ddwfn yn PHP a JavaScript (deallaf, mae anghysondeb gwybyddol, ond mae'n gweithio, ar gyfer blynyddoedd a heb wallau).
Fformat y ffeiliau sy'n cael eu storio yn y llyn yw'r allwedd i berfformiad
Mae'n bwysig iawn, iawn deall dau bwynt allweddol arall. Er mwyn i ymholiadau ar ddata ffeil yn y llyn gael eu gweithredu cyn gynted â phosibl ac i berfformiad beidio â diraddio pan ychwanegir gwybodaeth newydd, mae angen i chi:
- Storio colofnau ffeiliau ar wahân (fel nad oes rhaid i chi ddarllen yr holl linellau i ddeall beth sydd yn y colofnau). Ar gyfer hyn fe wnaethom gymryd y fformat parquet gyda chywasgu
- Mae'n bwysig iawn rhannu ffeiliau i ffolderi fel: iaith, blwyddyn, mis, diwrnod, wythnos. Bydd peiriannau sy'n deall y math hwn o ddarnio yn edrych ar y ffolderi angenrheidiol yn unig, heb hidlo'r holl ddata yn olynol.
Yn y bôn, yn y modd hwn, rydych chi'n gosod y data ffynhonnell yn y ffurf fwyaf effeithlon ar gyfer y peiriannau dadansoddol sy'n hongian ar eu pennau, y gall hyd yn oed mewn ffolderi wedi'u torri fynd i mewn yn ddetholus a darllen y colofnau angenrheidiol o ffeiliau yn unig. Nid oes angen “llenwi” y data yn unrhyw le (bydd y storfa'n byrstio'n syml) - rhowch ef yn ddoeth ar unwaith yn y system ffeiliau yn y fformat cywir. Wrth gwrs, dylai fod yn glir yma nad yw'n ddoeth iawn storio ffeil csv enfawr yn DataLake, y mae'n rhaid ei darllen fesul llinell yn gyntaf gan y clwstwr er mwyn echdynnu'r colofnau. Meddyliwch eto am y ddau bwynt uchod os nad yw'n glir eto pam mae hyn i gyd yn digwydd.
AWS Athena - y jac-yn-y-bocs
Ac yna, wrth greu llyn, rhywsut daethom ar draws Amazon Athena yn ddamweiniol. Yn sydyn daeth i'r amlwg, trwy drefnu ein ffeiliau log enfawr yn ddarnau ffolder yn y fformat colofn cywir (parquet) yn ofalus, y gallwch chi wneud dewisiadau hynod addysgiadol ohonynt yn gyflym iawn ac adeiladu adroddiadau HEBLAW, heb glwstwr Apache Spark / Glue.
Mae'r injan Athena sy'n cael ei bweru gan ddata yn s3 yn seiliedig ar y chwedlonol - cynrychiolydd o'r teulu MPP (prosesu cyfochrog enfawr) o ddulliau o brosesu data, gan gymryd data lle mae'n gorwedd, o s3 a Hadoop i Cassandra a ffeiliau testun cyffredin. Does ond angen i chi ofyn i Athena weithredu ymholiad SQL, ac yna mae popeth “yn gweithio'n gyflym ac yn awtomatig.” Mae'n bwysig nodi bod Athena yn “smart”, mae'n mynd i'r ffolderi wedi'u torri'n ôl angenrheidiol yn unig ac yn darllen dim ond y colofnau sydd eu hangen yn y cais.
Mae'r prisiau ar gyfer ceisiadau i Athena hefyd yn ddiddorol. Rydym yn talu am . Y rhai. nid ar gyfer nifer y peiriannau yn y clwstwr y funud, ond... ar gyfer y data a sganiwyd mewn gwirionedd ar 100-500 o beiriannau, dim ond y data angenrheidiol i gwblhau'r cais.
A thrwy ofyn am y colofnau angenrheidiol yn unig o ffolderi wedi'u torri'n gywir, daeth i'r amlwg bod gwasanaeth Athena yn costio degau o ddoleri y mis i ni. Wel, gwych, bron yn rhad ac am ddim, o gymharu â dadansoddeg ar glystyrau!
Gyda llaw, dyma sut rydym yn rhannu ein data yn a3:
O ganlyniad, mewn amser byr, dechreuodd adrannau hollol wahanol yn y cwmni, o ddiogelwch gwybodaeth i ddadansoddeg, fynd ati i wneud ceisiadau i Athena ac yn gyflym, mewn eiliadau, derbyn atebion defnyddiol o ddata “mawr” dros gyfnodau eithaf hir: misoedd, hanner blwyddyn, etc. P.
Ond aethon ni ymhellach a dechrau mynd i'r cwmwl am atebion : mae dadansoddwr yn ysgrifennu ymholiad SQL mewn consol cyfarwydd, sydd ar beiriannau 100-500 “am geiniogau” yn anfon data i s3 ac yn dychwelyd ateb fel arfer mewn ychydig eiliadau. Cyfforddus. Ac yn gyflym. Dwi dal methu credu'r peth.
O ganlyniad, ar ôl penderfynu storio data yn s3, mewn fformat colofnog effeithlon a thrwy rannu data'n rhesymol yn ffolderi... cawsom DataLake a pheiriant dadansoddol cyflym a rhad - am ddim. A daeth yn boblogaidd iawn yn y cwmni, oherwydd ... yn deall SQL ac yn gweithio gorchmynion maint yn gyflymach na thrwy gychwyn/stopio/sefydlu clystyrau. “Ac os yw’r canlyniad yr un peth, pam talu mwy?”
Mae cais i Athena yn edrych rhywbeth fel hyn. Os dymunir, wrth gwrs, gallwch chi ffurfio digon , ond byddwn yn cyfyngu ein hunain i grwpio syml. Gadewch i ni weld pa godau ymateb a gafodd y cleient ychydig wythnosau yn ôl yn y logiau gweinydd gwe a gwnewch yn siŵr nad oes unrhyw wallau:
Canfyddiadau
Ar ôl mynd drwodd, nid i ddweud llwybr hir, ond poenus, gan asesu'n ddigonol y risgiau a lefel cymhlethdod a chost cymorth yn gyson, daethom o hyd i ateb ar gyfer DataLake a dadansoddeg nad yw byth yn peidio â'n plesio gyda chyflymder a chost perchnogaeth.
Mae'n troi allan bod adeiladu effeithiol, cyflym a rhad i weithredu DataLake ar gyfer anghenion adrannau hollol wahanol o'r cwmni yn gwbl o fewn galluoedd hyd yn oed datblygwyr profiadol nad ydynt erioed wedi gweithio fel penseiri ac nid ydynt yn gwybod sut i dynnu sgwariau ar sgwariau gyda saethau a gwybod 50 term o ecosystem Hadoop.
Ar ddechrau’r daith, roedd fy mhen yn hollti oddi wrth y sw gwyllt niferus o feddalwedd agored a chaeedig a’r ddealltwriaeth o faich cyfrifoldeb i ddisgynyddion. Dechreuwch adeiladu eich DataLake o offer syml: nagios/munin -> elastig/kibana -> Hadoop/Spark/s3..., casglu adborth a deall ffiseg y prosesau sy'n digwydd yn ddwfn. Popeth cymhleth a muriog - ei roi i elynion a chystadleuwyr.
Os nad ydych am fynd i’r cwmwl ac yn hoffi cefnogi, diweddaru a chlytio prosiectau ffynhonnell agored, gallwch adeiladu cynllun tebyg i’n un ni yn lleol, ar beiriannau swyddfa rhad gyda Hadoop a Presto ar ei ben. Y prif beth yw peidio â stopio a symud ymlaen, cyfrif, chwilio am atebion syml a chlir, a bydd popeth yn bendant yn gweithio allan! Pob lwc i bawb a welai chi eto!
Ffynhonnell: hab.com