ProHoster > Blogs > Administrācija > Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Mēs dzÄ«vojam pārsteidzoŔā laikā, kad varat ātri un vienkārÅ”i savienot vairākus gatavus atvērtā pirmkoda rÄ«kus, iestatÄ«t tos ar ā€œizslēgtu apziņuā€ saskaņā ar stackoverflow ieteikumiem, neiedziļinoties ā€œvairākos burtosā€ un palaist. nodot tos komerciālai darbÄ«bai. Un, kad vajag atjaunināt/paplaÅ”ināt vai kāds nejauÅ”i pārstartē pāris maŔīnas - tu saproti, ka patiesÄ«bā ir sācies kaut kāds uzmācÄ«gi slikts sapnis, viss pēkŔņi ir kļuvis sarežģītāks lÄ«dz nepazÄ«Å”anai, nav atgrieÅ”anās, nākotne ir neskaidra un droŔāk, tā vietā, lai programmētu, audzētu bites un taisÄ«t sieru.

Ne velti pieredzējuŔāki kolēģi ar kļūdām nokaisÄ«tām un tāpēc jau pelēkām galvām apsver neticami ātru "konteineru" paku izvietoÅ”anu "kubiņos" desmitiem serveru "modes valodās" ar iebÅ«vētu atbalstu asinhrona nebloķējoÅ”a I/O, pieticÄ«gi smaidiet . Un viņi klusÄ«bā turpina pārlasÄ«t ā€œman psā€, iedziļināties ā€œnginxā€ pirmkodā, lÄ«dz viņiem asiņo acis, un rakstÄ«t, rakstÄ«t, rakstÄ«t vienÄ«bu testus. Kolēģi zina, ka pats interesantākais bÅ«s tad, kad ā€œtas vissā€ kādu dienu tiks likts uz spēles Vecgada vakarā. Un tiem palÄ«dzēs tikai dziļa izpratne par unix bÅ«tÄ«bu, iegaumētā TCP/IP stāvokļa tabulu un pamata ŔķiroÅ”anas-meklÄ“Å”anas algoritmiem. Lai sistēma atdzÄ«vinātu, kad skan zvani.

Ak jā, es mazliet apjucis, bet ceru, ka man izdevās nodot to gaidīŔanas stāvokli.
Å odien vēlos dalÄ«ties pieredzē par ērtas un lētas DataLake steka izvietoÅ”anu, kas uzņēmumā atrisina lielāko daļu analÄ«tisko uzdevumu pilnÄ«gi atŔķirÄ«gām struktÅ«rvienÄ«bām.

Pirms kāda laika mēs nonācām pie izpratnes, ka uzņēmumiem arvien vairāk ir vajadzÄ«gi gan produktu, gan tehniskās analÄ«zes augļi (nemaz nerunājot par glazÅ«ru uz kÅ«kas maŔīnmācÄ«bas veidā) un, lai izprastu tendences un riskus - mums ir jāapkopo un jāanalizē. arvien vairāk metrikas.

Pamata tehniskā analītika pakalpojumā Bitrix24

Pirms vairākiem gadiem, vienlaikus ar Bitrix24 pakalpojuma palaiÅ”anu, mēs aktÄ«vi ieguldÄ«jām laiku un resursus, lai izveidotu vienkārÅ”u un uzticamu analÄ«tisko platformu, kas palÄ«dzētu ātri saskatÄ«t infrastruktÅ«ras problēmas un plānot nākamo soli. Protams, bija ieteicams ņemt gatavus rÄ«kus, kas bÅ«tu pēc iespējas vienkārŔāki un saprotami. Rezultātā nagios tika izvēlēts uzraudzÄ«bai un munin analÄ«tikai un vizualizācijai. Tagad mums ir tÅ«kstoÅ”iem čeku nagios, simtiem diagrammu munin, un mÅ«su kolēģi tos veiksmÄ«gi izmanto katru dienu. Metrika ir skaidra, grafiki ir skaidri, sistēma jau vairākus gadus darbojas uzticami, un tai regulāri tiek pievienoti jauni testi un grafiki: nododot ekspluatācijā jaunu pakalpojumu, mēs pievienojam vairākus testus un grafikus. Veiksmi.

Pirksts uz pulsa ā€” uzlabota tehniskā analÄ«ze

Vēlme saņemt informāciju par problēmām ā€œpēc iespējas ātrākā€ noveda mÅ«s pie aktÄ«viem eksperimentiem ar vienkārÅ”iem un saprotamiem rÄ«kiem - pinba un xhprof.

Pinba nosÅ«tÄ«ja mums statistiku UDP paketēs par tÄ«mekļa lapu daļu darbÄ«bas ātrumu PHP, un mēs tieÅ”saistē varējām redzēt MySQL krātuvē (Pinba ir aprÄ«kots ar savu MySQL dzinēju ātrai notikumu analÄ«zei) Ä«su problēmu sarakstu un reaģēt uz viņiem. Un xhprof automātiski ļāva mums savākt grafikus par lēnāko PHP lapu izpildi no klientiem un analizēt, kas varētu novest pie tā - mierÄ«gi, lejot tēju vai ko stiprāku.

Pirms kāda laika rÄ«kkopa tika papildināta ar citu diezgan vienkārÅ”u un saprotamu dzinēju, kura pamatā ir reversās indeksācijas algoritms, lieliski ieviests leÄ£endārajā Lucene bibliotēkā - Elastic/Kibana. VienkārŔā ideja par dokumentu vairāku pavedienu ierakstÄ«Å”anu apgrieztā Lucene indeksā, pamatojoties uz notikumiem žurnālos, un ātru meklÄ“Å”anu tajos, izmantojot aspektu dalÄ«Å”anu, izrādÄ«jās patieŔām noderÄ«ga.

Neskatoties uz diezgan tehnisku vizualizāciju izskatu Kibanā ar zema lÄ«meņa jēdzieniem, piemēram, ā€œspainisā€ ā€œplÅ«st uz augÅ”uā€, un vēl pilnÄ«bā aizmirstās relāciju algebras no jauna izgudroto valodu, rÄ«ks sāka mums labi palÄ«dzēt Ŕādos uzdevumos:

  • Cik PHP kļūdu Bitrix24 klientam bija p1 portālā pēdējā stundā un kādas? Saprast, piedot un ātri izlabot.
  • Cik videozvani portālos Vācijā veikti iepriekŔējā diennaktÄ«, kādā kvalitātē un vai bija kādas grÅ«tÄ«bas ar kanālu/tÄ«klu?
  • Cik labi darbojas sistēmas funkcionalitāte (mÅ«su C paplaÅ”inājums PHP), kas apkopots no avota jaunākajā pakalpojuma atjauninājumā un ieviests klientiem? Vai ir segfaults?
  • Vai klientu dati iekļaujas PHP atmiņā? Vai ir kļūdas par procesiem atvēlētās atmiņas pārsniegÅ”anu: ā€œbeigusies atmiņaā€? Atrodi un neitralizē.

Å eit ir konkrēts piemērs. Neskatoties uz rÅ«pÄ«gu un daudzlÄ«meņu testÄ“Å”anu, klients ar ļoti nestandarta korpusu un bojātiem ievades datiem saņēma kaitinoÅ”u un negaidÄ«tu kļūdu, atskanēja sirēna un sākās tās ātras novērÅ”anas process:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Turklāt kibana ļauj organizēt paziņojumus par noteiktiem notikumiem, un Ä«sā laikā uzņēmuma rÄ«ku sāka izmantot desmitiem darbinieku no dažādām nodaļām - no tehniskā atbalsta un attÄ«stÄ«bas lÄ«dz kvalitātes nodroÅ”ināŔanai.

Jebkura uzņēmuma nodaļas darbÄ«ba ir kļuvusi ērti izsekojama un izmērāma - tā vietā, lai manuāli analizētu žurnālus serveros, jums vienkārÅ”i ir vienreiz jāiestata parsÄ“Å”anas žurnāli un jānosÅ«ta tie elastÄ«gajam klasterim, lai izbaudÄ«tu, piemēram, kontemplāciju kibanā. informācijas panelis pārdoto divgalvu kaķēnu skaits, kas izdrukāts ar 3-D printeri pēdējā Mēness mēnesÄ«.

Pamata biznesa analīze

Ikviens zina, ka biznesa analÄ«tika uzņēmumos bieži sākas ar ārkārtÄ«gi aktÄ«vu, jā, Excel izmantoÅ”anu. Bet galvenais ir tas, ka ar to viss nebeidzas. Uz mākoņiem balstÄ«ts Google Analytics arÄ« pievieno eļļu ugunij ā€” jÅ«s ātri sākat pierast pie labām lietām.

MÅ«su harmoniski augoÅ”ajā uzņēmumā Å”ur tur sāka parādÄ«ties intensÄ«vāka darba ā€œpravieÅ”iā€ ar lielākiem datiem. Regulāri sāka parādÄ«ties nepiecieÅ”amÄ«ba pēc padziļinātākiem un daudzpusÄ«gākiem ziņojumiem, un ar dažādu nodaļu puiÅ”u pÅ«lēm pirms kāda laika tika organizēts vienkārÅ”s un praktisks risinājums - ClickHouse un PowerBI kombinācija.

Diezgan ilgu laiku Å”is elastÄ«gais risinājums ļoti palÄ«dzēja, bet pamazām sāka nākt sapratne, ka ClickHouse nav gumija un ar to nevar tā ņirgāties.

Å eit ir svarÄ«gi labi saprast, ka ClickHouse, tāpat kā Druid, tāpat kā Vertica, tāpat kā Amazon RedShift (kas ir balstÄ«ts uz postgres), ir analÄ«tiskie dzinēji, kas optimizēti diezgan ērtai analÄ«tikai (summas, apkopojumi, minimums-maksimums pa kolonnām un daži iespējamie savienojumi ), jo organizēta efektÄ«vai relāciju tabulu kolonnu glabāŔanai, atŔķirÄ«bā no MySQL un citām mums zināmām (rindu orientētām) datu bāzēm.

BÅ«tÄ«bā ClickHouse ir tikai ietilpÄ«gāka "datu bāze", ar ne pārāk ērtu ievietoÅ”anu pa punktiem (tā tas ir paredzēts, viss ir kārtÄ«bā), bet patÄ«kamu analÄ«zi un interesantu jaudÄ«gu funkciju kopumu darbam ar datiem. Jā, jÅ«s pat varat izveidot klasteri, taču jÅ«s saprotat, ka naglu kalÅ”ana ar mikroskopu nav pilnÄ«gi pareiza, un mēs sākām meklēt citus risinājumus.

Pieprasījums pēc pitona un analītiķiem

MÅ«su uzņēmumā ir daudz izstrādātāju, kas gandrÄ«z katru dienu 10-20 gadus raksta kodu PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ir arÄ« daudzi pieredzējuÅ”i sistēmu administratori, kuri ir piedzÄ«vojuÅ”i vairāk nekā vienu absolÅ«ti neticamu katastrofu, kas neatbilst statistikas likumiem (piemēram, kad lielākā daļa disku RAID-10 tiek iznÄ«cināti spēcÄ«ga zibens spēriena rezultātā). Šādos apstākļos ilgu laiku nebija skaidrs, kas ir ā€œpitona analÄ«tiÄ·isā€. Python ir kā PHP, tikai nosaukums ir nedaudz garāks un tulka avota kodā ir nedaudz mazāk prātu mainoÅ”u vielu pēdu. Tomēr, veidojot arvien vairāk analÄ«tisko pārskatu, pieredzējuÅ”i izstrādātāji sāka arvien vairāk saprast, cik svarÄ«ga ir Å”aura specializācija tādos rÄ«kos kā numpy, pandas, matplotlib, seaborn.
IzŔķiroÅ”o lomu, visticamāk, nospēlēja darbinieku pēkŔņa ģībÅ”ana no vārdu kombinācijas ā€œloÄ£istiskā regresijaā€ un efektÄ«vas ziņoÅ”anas demonstrÄ“Å”ana par lieliem datiem, izmantojot, jā, jā, pyspark.

Apache Spark, tās funkcionālā paradigma, kurai relāciju algebra lieliski iederas, un tās iespējas atstāja tādu iespaidu uz izstrādātājiem, kuri bija pieraduÅ”i pie MySQL, ka nepiecieÅ”amÄ«ba nostiprināt rindas ar pieredzējuÅ”iem analÄ«tiÄ·iem kļuva skaidra kā diena.

Apache Spark/Hadoop turpmākie mēģinājumi pacelties gaisā un kas neizdevās gluži saskaņā ar skriptu

Taču drÄ«z vien kļuva skaidrs, ka ar Spark kaut kas sistēmiski nav Ä«sti kārtÄ«bā, vai arÄ« vienkārÅ”i labāk jānomazgā rokas. Ja Hadoop/MapReduce/Lucene steku veidojuÅ”i diezgan pieredzējuÅ”i programmētāji, kas ir acÄ«mredzami, ja rÅ«pÄ«gi aplÅ«ko Java pirmkodu vai Daga Katinga idejas Lucene valodā, tad Spark pēkŔņi ir uzrakstÄ«ts eksotiskā valodā Scala, kas ir ļoti strÄ«dÄ«gs no praktiskuma viedokļa un paÅ”laik neveidojas. Un regulārais aprēķinu kritums Spark klasterÄ« neloÄ£iskā un ne pārāk caurspÄ«dÄ«gā darba ar atmiņas pieŔķirÅ”anu samazināŔanas operācijām (daudzas atslēgas pienāk vienlaikus) dēļ ir radÄ«jis oreolu ap to kaut kam, kam ir kur augt. Turklāt situāciju pasliktināja liels skaits dÄ«vainu atvērtu pieslēgvietu, pagaidu faili, kas aug nesaprotamākajās vietās un elles burciņu atkarÄ«bas, kas sistēmu administratoros radÄ«ja vienu no bērnÄ«bas labi zināmu sajÅ«tu: nikns naids (vai varbÅ«t viņiem vajadzēja mazgāt rokas ar ziepēm).

Rezultātā esam ā€œizdzÄ«vojuÅ”iā€ vairākus iekŔējos analÄ«tiskos projektus, kas aktÄ«vi izmanto Apache Spark (tostarp Spark Streaming, Spark SQL) un Hadoop ekosistēmu (un tā tālāk, un tā tālāk). Neskatoties uz to, ka laika gaitā mēs iemācÄ«jāmies "to" sagatavot un uzraudzÄ«t diezgan labi, un "tas" praktiski pārstāja pēkŔņi avarēt datu rakstura izmaiņu un vienotas RDD jaukÅ”anas nelÄ«dzsvarotÄ«bas dēļ, vēlme paņemt kaut ko jau gatavu. , atjaunināts un administrēts kaut kur mākonÄ«, kļuva arvien spēcÄ«gāks. TieÅ”i Å”ajā laikā mēs mēģinājām izmantot gatavo Amazon Web Services mākoņa komplektu - EMR un pēc tam mēģināja atrisināt problēmas, izmantojot to. EMR ir Apache Spark, ko Amazon sagatavojis ar papildu programmatÅ«ru no ekosistēmas, lÄ«dzÄ«gi kā Cloudera/Hortonworks bÅ«vējumi.

Steidzami nepiecieŔama gumijas failu krātuve analīzei

Hadoop/Spark ā€œgatavoÅ”anasā€ pieredze ar dažādu Ä·ermeņa daļu apdegumiem nebija veltÄ«ga. Arvien aktuālāka kļuva nepiecieÅ”amÄ«ba izveidot vienotu, lētu un uzticamu failu krātuvi, kas bÅ«tu izturÄ«ga pret aparatÅ«ras kļūmēm un kurā bÅ«tu iespējams glabāt dažādu formātu failus no dažādām sistēmām un no Å”iem datiem izveidot efektÄ«vus un laika ziņā efektÄ«vus atskaites paraugus. skaidrs.

Vēlējos arÄ«, lai Ŕīs platformas programmatÅ«ras atjaunināŔana nepārvērstos par Jaungada murgu, nolasot 20 lappuÅ”u Java pēdas un analizējot kilometrus garus detalizētus klastera žurnālus, izmantojot Spark History Server un aizmugurgaismoto palielināmo stiklu. Es gribēju iegÅ«t vienkārÅ”u un pārskatāmu rÄ«ku, kas neprasa regulāru nirÅ”anu zem pārsega, ja izstrādātāja standarta MapReduce pieprasÄ«jums tika pārtraukts, kad datu samazināŔanas darbinieks izkrita no atmiņas ne pārāk labi izvēlēta avota datu sadalÄ«Å”anas algoritma dēļ.

Vai Amazon S3 ir DataLake kandidāts?

Pieredze ar Hadoop/MapReduce mums mācÄ«ja, ka mums ir vajadzÄ«ga mērogojama, uzticama failu sistēma un tai papildus mērogojami darbinieki, kas "tuvojas" datiem, lai tie netiktu pārvietoti tÄ«klā. Darbiniekiem jāspēj nolasÄ«t datus dažādos formātos, bet vēlams nelasÄ«t nevajadzÄ«gu informāciju un jāspēj datus iepriekÅ” uzglabāt darbiniekiem ērtos formātos.

Atkal pamatideja. Nav vēlmes ā€œielietā€ lielos datus vienā klastera analÄ«tiskajā dzinējā, kas agri vai vēlu noslāps un nāksies tos neglÄ«ti sadalÄ«t. Es vēlos saglabāt failus, tikai failus, saprotamā formātā un veikt tiem efektÄ«vus analÄ«tiskos vaicājumus, izmantojot dažādus, bet saprotamus rÄ«kus. Un bÅ«s arvien vairāk failu dažādos formātos. Un labāk ir izdalÄ«t nevis dzinēju, bet gan avota datus. Mums ir nepiecieÅ”ams paplaÅ”ināms un universāls DataLake, mēs nolēmām...

Ko darīt, ja glabājat failus pazīstamajā un labi zināmajā mērogojamajā mākoņkrātuvē Amazon S3, nesagatavojot savas karbonādes no Hadoop?

Ir skaidrs, ka personas datu apjoms ir ā€œzemsā€, bet kā ir ar citiem datiem, ja mēs tos izņemam un ā€œdarbojamies efektÄ«viā€?

Amazon Web Services klasteru-bigdata-analytics ekosistēma ā€” ļoti vienkārÅ”iem vārdiem

Spriežot pēc mūsu pieredzes ar AWS, Apache Hadoop/MapReduce tur jau sen aktīvi tiek lietots zem dažādām mērcēm, piemēram, DataPipeline servisā (apskaužu kolēģus, viņi iemācījās pareizi pagatavot). Šeit mēs iestatām dublējumus no dažādiem pakalpojumiem no DynamoDB tabulām:
Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Un tie jau vairākus gadus regulāri darbojas iegultos Hadoop/MapReduce klasteros, piemēram, pulksteņa mehānisms. ā€œIestatiet un aizmirstietā€:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Varat arī efektīvi iesaistīties datu sātanismā, mākonī iestatot Jupiter klēpjdatorus analītiķiem un izmantojot AWS SageMaker pakalpojumu, lai apmācītu un izvietotu AI modeļus cīņā. Lūk, kā tas mums izskatās:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Un jā, varat paņemt klēpjdatoru sev vai analītiķim mākonī un pievienot to Hadoop/Spark klasterim, veikt aprēķinus un pēc tam visu noteikt:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

PatieŔām ērts individuāliem analÄ«tiskajiem projektiem, un dažiem esam veiksmÄ«gi izmantojuÅ”i EMR pakalpojumu liela mēroga aprēķiniem un analÄ«tikai. Kā ar DataLake sistēmas risinājumu, vai tas darbosies? Å ajā brÄ«dÄ« mēs bijām uz cerÄ«bu un izmisuma robežas un turpinājām meklējumus.

AWS Glue - glīti iepakota Apache Spark uz steroīdiem

IzrādÄ«jās, ka AWS ir sava kaudzes ā€œHive/Pig/Sparkā€ versija. Stropa loma, t.i. Datņu un to tipu katalogu DataLake veic pakalpojums ā€œDatu katalogsā€, kas neslēpj savu saderÄ«bu ar Apache Hive formātu. Å im pakalpojumam ir jāpievieno informācija par to, kur atrodas jÅ«su faili un kādā formātā tie ir. Dati var bÅ«t ne tikai s3, bet arÄ« datu bāzē, taču tas nav Ŕī ieraksta priekÅ”mets. LÅ«k, kā ir sakārtots mÅ«su DataLake datu direktorijs:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Faili ir reÄ£istrēti, lieliski. Ja faili ir atjaunināti, mēs manuāli vai pēc grafika palaižam rāpuļprogrammas, kas atjaunos informāciju par tiem no ezera un saglabās. Tad datus no ezera var apstrādāt un rezultātus kaut kur augÅ”upielādēt. VienkārŔākajā gadÄ«jumā mēs arÄ« augÅ”upielādējam s3. Datu apstrādi var veikt jebkur, taču ir ieteicams konfigurēt apstrādi Apache Spark klasterÄ«, izmantojot papildu iespējas, izmantojot AWS Glue API. PatiesÄ«bā, izmantojot pyspark bibliotēku, varat izmantot veco labo un pazÄ«stamo Python kodu un konfigurēt tā izpildi N mezglos noteiktas ietilpÄ«bas klasterÄ« ar pārraudzÄ«bu, neiedziļinoties Hadoop iekÅ”ienē un nevelkot docker-moker konteinerus un novērÅ”ot atkarÄ«bas konfliktus. .

Atkal vienkārÅ”a ideja. Nav nepiecieÅ”ams konfigurēt Apache Spark, jums vienkārÅ”i ir jāraksta pyspark python kods, jāpārbauda tas lokāli uz darbvirsmas un pēc tam jāpalaiž lielā klasterÄ« mākonÄ«, norādot, kur atrodas avota dati un kur ievietot rezultātu. Dažreiz tas ir nepiecieÅ”ams un noderÄ«gs, un mēs to iestatām Ŕādi:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Tādējādi, ja jums kaut kas jāaprēķina Spark klasterī, izmantojot s3 datus, mēs ierakstām kodu python/pyspark, pārbaudām to un vēlam veiksmi mākonī.

Kā ar orÄ·estrÄ“Å”anu? Ko darÄ«t, ja uzdevums nokristu un pazustu? Jā, tiek piedāvāts izveidot skaistu cauruļvadu Apache Pig stilā, un mēs tos pat izmēģinājām, taču Å”obrÄ«d mēs nolēmām izmantot mÅ«su dziļi pielāgoto orÄ·estri PHP un JavaScript (es saprotu, ir kognitÄ«vā disonanse, bet tas darbojas, jo gados un bez kļūdām).

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Ezerā glabāto failu formāts ir veiktspējas atslēga

Ir ļoti, ļoti svarÄ«gi saprast vēl divus galvenos punktus. Lai vaicājumi par faila datiem ezerā tiktu izpildÄ«ti pēc iespējas ātrāk un veiktspēja nepasliktinātos, pievienojot jaunu informāciju, jums ir nepiecieÅ”ams:

  • Saglabājiet failu kolonnas atseviŔķi (lai jums nebÅ«tu jālasa visas rindiņas, lai saprastu, kas atrodas kolonnās). Å im nolÅ«kam mēs paņēmām parketa formātu ar kompresiju
  • Ir ļoti svarÄ«gi sadalÄ«t failus tādās mapēs kā valoda, gads, mēnesis, diena, nedēļa. Dzinēji, kas saprot Ŕāda veida sadalÄ«Å”anu, apskatÄ«s tikai nepiecieÅ”amās mapes, neizsijājot visus datus pēc kārtas.

BÅ«tÄ«bā Ŕādā veidā jÅ«s izkārtojat avota datus visefektÄ«vākajā formā analÄ«tiskajiem dzinējiem, kas ir piekārti augÅ”pusē, kas pat sadalÄ«tās mapēs var selektÄ«vi ievadÄ«t un nolasÄ«t tikai nepiecieÅ”amās kolonnas no failiem. Jums nekur nav ā€œjāaizpildaā€ dati (krātuve vienkārÅ”i pārsprāgs) - vienkārÅ”i nekavējoties saprātÄ«gi ievietojiet tos failu sistēmā pareizajā formātā. Protams, Å”eit ir jābÅ«t skaidram, ka nav Ä«paÅ”i ieteicams glabāt milzÄ«gu csv failu DataLake, kas vispirms ir jālasa klasterim rindu pa rindiņai, lai izvilktu kolonnas. Padomājiet par iepriekÅ”minētajiem diviem punktiem vēlreiz, ja vēl nav skaidrs, kāpēc tas viss notiek.

AWS Athena ā€” ligzda kastē

Un tad, veidojot ezeru, mēs kaut kā nejauÅ”i uzgājām Amazon Atēnu. PēkŔņi izrādÄ«jās, ka, rÅ«pÄ«gi sakārtojot mÅ«su milzÄ«gos žurnālfailus mapju skaidiņās pareizā (parketa) kolonnu formātā, no tiem var ļoti ātri veikt ārkārtÄ«gi informatÄ«vas atlases un veidot atskaites BEZ, bez Apache Spark/Glue klastera.

Athena dzinējs, ko darbina dati s3, ir balstÄ«ts uz leÄ£endāro Presto - MPP (masÄ«vas paralēlās apstrādes) pieeju Ä£imenes pārstāvis datu apstrādei, pārņemot datus, kur tie atrodas, no s3 un Hadoop lÄ«dz Cassandra un parastajiem teksta failiem. Jums vienkārÅ”i jālÅ«dz Athena izpildÄ«t SQL vaicājumu, un tad viss ā€œdarbojas ātri un automātiskiā€. Ir svarÄ«gi atzÄ«mēt, ka Athena ir ā€œgudraā€, tā iet tikai uz nepiecieÅ”amajām Ŕķeltajām mapēm un nolasa tikai pieprasÄ«jumam nepiecieÅ”amās kolonnas.

Interesanta ir arÄ« Athena pieprasÄ«jumu cenu noteikÅ”ana. Mēs maksājam par skenēto datu apjoms. Tie. nevis par aparātu skaitu klasterÄ« minÅ«tē, bet... par reāli noskenētajiem datiem uz 100-500 iekārtām, tikai tie dati, kas nepiecieÅ”ami pieprasÄ«juma pabeigÅ”anai.

Un, pieprasot tikai nepiecieÅ”amās kolonnas no pareizi sadrumstalotām mapēm, izrādÄ«jās, ka Athena pakalpojums mums izmaksā desmitiem dolāru mēnesÄ«. Lieliski, gandrÄ«z bez maksas, salÄ«dzinot ar klasteru analÄ«zi!

Starp citu, Å”eit ir norādÄ«ts, kā mēs sadalām savus datus s3:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Tā rezultātā Ä«sā laikā pilnÄ«gi dažādas uzņēmuma nodaļas, sākot no informācijas droŔības lÄ«dz analÄ«tikai, sāka aktÄ«vi veikt pieprasÄ«jumus Athena un ātri, dažu sekunžu laikā saņemt noderÄ«gas atbildes no ā€œlieliemā€ datiem diezgan ilgu laiku: mēneÅ”us, pusgads utt. P.

Bet mēs devāmies tālāk un sākām iet uz mākoni pēc atbildēm izmantojot ODBC draiveri: analÄ«tiÄ·is raksta SQL vaicājumu pazÄ«stamā konsolē, kas 100ā€“500 iekārtās ā€œpar santÄ«miemā€ nosÅ«ta datus uz s3 un atgriež atbildi parasti dažu sekunžu laikā. Ērti. Un ātri. Es joprojām nespēju tam noticēt.

Rezultātā, izlēmuÅ”i glabāt datus s3, efektÄ«vā kolonnu formātā un ar saprātÄ«gu datu sadalÄ«Å”anu mapēs... saņēmām DataLake un ātru un lētu analÄ«tisko dzinēju - bez maksas. Un kompānijā viņŔ kļuva ļoti populārs, jo... saprot SQL un darbojas daudz ātrāk nekā klasteru palaiÅ”ana/apturÄ“Å”ana/iestatÄ«Å”ana. "Un, ja rezultāts ir tāds pats, kāpēc maksāt vairāk?"

LÅ«gums Atēnai izskatās apmēram Ŕādi. Ja vēlas, protams, var veidot pietiekami daudz sarežģīts un vairāku lappuÅ”u SQL vaicājums, bet mēs aprobežosimies ar vienkārÅ”u grupÄ“Å”anu. ApskatÄ«sim, kādi atbildes kodi klientam bija pirms dažām nedēļām tÄ«mekļa servera žurnālos, un pārliecināsimies, ka nav kļūdu:

Kā mēs organizējām ļoti efektīvu un lētu DataLake un kāpēc tas tā ir

Atzinumi

Izejot, lai neteiktu garu, bet sāpÄ«gu ceļu, pastāvÄ«gi adekvāti novērtējot riskus un atbalsta sarežģītÄ«bas lÄ«meni un izmaksas, mēs atradām risinājumu DataLake un analytics, kas mÅ«s nebeidz priecēt gan ar ātrumu, gan ar Ä«paÅ”uma izmaksām.

IzrādÄ«jās, ka efektÄ«va, ātra un lēta DataLake izveide pilnÄ«gi atŔķirÄ«gu uzņēmuma nodaļu vajadzÄ«bām ir pilnÄ«bā pa spēkam pat pieredzējuÅ”iem izstrādātājiem, kuri nekad nav strādājuÅ”i par arhitektiem un neprot zÄ«mēt kvadrātus uz kvadrātiem ar bultiņas un zināt 50 terminus no Hadoop ekosistēmas.

Ceļojuma sākumā man Ŕķita galva no daudzajiem mežonÄ«gajiem atvērtās un slēgtās programmatÅ«ras zoodārziem un izpratnes par atbildÄ«bas nastu uz pēcnācējiem. VienkārÅ”i sāciet veidot savu DataLake, izmantojot vienkārÅ”us rÄ«kus: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., apkopojot atsauksmes un dziļi izprotot notiekoÅ”o procesu fiziku. Viss sarežģīts un neskaidrs - dodiet to ienaidniekiem un konkurentiem.

Ja nevēlaties izmantot mākoni un vēlaties atbalstÄ«t, atjaunināt un labot atvērtā pirmkoda projektus, varat izveidot shēmu, kas lÄ«dzÄ«ga mÅ«sējai, lokāli, lētās biroja iekārtās ar Hadoop un Presto augÅ”pusē. Galvenais neapstāties un virzÄ«ties uz priekÅ”u, rēķināties, meklēt vienkārÅ”us un skaidrus risinājumus, un viss noteikti izdosies! Veiksmi visiem un tiekamies atkal!

Avots: www.habr.com

Pievieno komentāru