Ons leef in 'n wonderlike tyd wanneer jy vinnig en maklik verskeie klaargemaakte oopbron-nutsgoed kan koppel, dit kan opstel met jou "bewussyn afgeskakel" volgens die raad van stackoverflow, sonder om in die "veelvuldige letters" te delf, en begin hulle in kommersiële bedryf. En wanneer jy nodig het om op te dateer/uit te brei of iemand per ongeluk 'n paar masjiene herlaai - jy besef dat 'n soort obsessiewe slegte droom begin het, alles het dramaties ingewikkeld geword onherkenbaar, daar is geen omdraaikans nie, die toekoms is vaag en veiliger, in plaas van programmering, teel bye en doen kaas.
Dit is nie verniet dat meer ervare kollegas, met hul koppe besaai met goggas en dus reeds grys, die ongelooflike vinnige ontplooiing van pakke "houers" in "kubusse" op dosyne bedieners in "modieuse tale" met ingeboude ondersteuning vir asynchrone nie-blokkerende I/O, glimlag beskeie. En hulle gaan stilweg voort om "man ps" te herlees, delf in die "nginx"-bronkode totdat hul oë bloei, en skryf, skryf, skryf eenheidstoetse. Kollegas weet dat die interessantste ding sal kom wanneer "dit alles" eendag snags op Oujaarsaand in die spel raak. En hulle sal slegs gehelp word deur 'n diepgaande begrip van die aard van unix, die gememoriseerde TCP/IP-toestandstabel en basiese sorteer-soek-algoritmes. Om die stelsel weer lewendig te maak terwyl die klokke slaan.
O ja, ek het 'n bietjie afgelei, maar ek hoop ek het daarin geslaag om die toestand van afwagting oor te dra.
Vandag wil ek ons ervaring deel met die implementering van 'n gerieflike en goedkoop stapel vir DataLake, wat die meeste analitiese take in die maatskappy vir heeltemal verskillende strukturele afdelings oplos.
'n Tyd gelede het ons tot die insig gekom dat maatskappye toenemend die vrugte van beide produk- en tegniese ontledings nodig het (om nie eers te praat van die kersie op die koek in die vorm van masjienleer nie) en om tendense en risiko's te verstaan - ons moet versamel en ontleed meer en meer metrieke.
Basiese tegniese ontleding in Bitrix24
Etlike jare gelede, gelyktydig met die bekendstelling van die Bitrix24-diens, het ons aktief tyd en hulpbronne belê in die skep van 'n eenvoudige en betroubare analitiese platform wat sou help om vinnig probleme in die infrastruktuur te sien en die volgende stap te beplan. Dit was natuurlik raadsaam om gereedgemaakte gereedskap te neem wat so eenvoudig en verstaanbaar as moontlik was. As gevolg hiervan is nagios gekies vir monitering en munin vir ontleding en visualisering. Nou het ons duisende tjeks in nagios, honderde kaarte in Munin, en ons kollegas gebruik dit elke dag suksesvol. Die maatstawwe is duidelik, die grafieke is duidelik, die stelsel werk al etlike jare betroubaar en nuwe toetse en grafieke word gereeld daarby gevoeg: wanneer ons 'n nuwe diens in werking stel, voeg ons verskeie toetse en grafieke by. Sterkte.
Vinger aan die pols - Gevorderde Tegniese Analise
Die begeerte om inligting oor probleme "so vinnig as moontlik" te ontvang, het ons gelei tot aktiewe eksperimente met eenvoudige en verstaanbare gereedskap - pinba en xhprof.
Pinba het vir ons statistieke in UDP-pakkies gestuur oor die spoed van werking van dele van webbladsye in PHP, en ons kon aanlyn in die MySQL-berging (Pinba kom met sy eie MySQL-enjin vir vinnige gebeurtenisanalise) 'n kort lys probleme sien en reageer op hulle. En xhprof het ons outomaties toegelaat om grafieke van die uitvoering van die stadigste PHP-bladsye van kliënte te versamel en te ontleed wat hiertoe kan lei - rustig, tee skink of iets sterker.
'n Tyd gelede is die gereedskapstel aangevul met nog 'n redelik eenvoudige en verstaanbare enjin gebaseer op die omgekeerde indekseringsalgoritme, perfek geïmplementeer in die legendariese Lucene-biblioteek - Elastic/Kibana. Die eenvoudige idee van multi-draad-opname van dokumente in 'n omgekeerde Lucene-indeks gebaseer op gebeure in die logs en 'n vinnige soektog deur hulle met behulp van fasetverdeling, blyk baie nuttig te wees.
Ten spyte van die taamlik tegniese voorkoms van visualisasies in Kibana met lae-vlak konsepte soos “emmer” wat “opwaarts vloei” en die herontginde taal van die nog nie heeltemal vergete relasionele algebra, het die instrument ons goed begin help in die volgende take:
- Hoeveel PHP-foute het die Bitrix24-kliënt die afgelope uur op die p1-portaal gehad en watter? Verstaan, vergewe en maak vinnig reg.
- Hoeveel video-oproepe is in die vorige 24 uur op portale in Duitsland gemaak, met watter kwaliteit en was daar enige probleme met die kanaal/netwerk?
- Hoe goed werk die stelselfunksionaliteit (ons C-uitbreiding vir PHP), saamgestel vanaf bron in die jongste diensopdatering en na kliënte uitgerol? Is daar segfoute?
- Pas kliëntdata in PHP-geheue? Is daar enige foute oor die oorskryding van die geheue wat aan prosesse toegewys is: "buite geheue"? Vind en neutraliseer.
Hier is 'n konkrete voorbeeld. Ten spyte van deeglike en multi-vlak toetsing, het die kliënt, met 'n baie nie-standaard geval en beskadigde insetdata, 'n irriterende en onverwagte fout ontvang, 'n sirene het geklink en die proses om dit vinnig reg te maak het begin:
Boonop laat kibana jou toe om kennisgewings vir spesifieke geleenthede te organiseer, en binne 'n kort tydjie het die instrument in die maatskappy begin gebruik word deur dosyne werknemers van verskillende departemente - van tegniese ondersteuning en ontwikkeling tot QA.
Die aktiwiteit van enige departement binne die maatskappy het gerieflik geword om op te spoor en te meet - in plaas daarvan om logs op bedieners met die hand te ontleed, hoef jy net een keer ontledingslogboeke op te stel en dit na die elastiese groepie te stuur om dit byvoorbeeld in die kibana te geniet. dashboard die aantal verkoopte tweekoppige katjies wat op 3-D drukker gedruk is vir die laaste maanmaand.
Basiese Business Analytics
Almal weet dat besigheidsanalise in maatskappye dikwels begin met uiters aktiewe gebruik van, ja, Excel. Maar die belangrikste ding is dat dit nie daar eindig nie. Wolk-gebaseerde Google Analytics voeg ook brandstof by die vuur – jy begin vinnig gewoond raak aan die goeie goed.
In ons harmonieus ontwikkelende maatskappy het hier en daar “profete” van meer intensiewe werk met groter data begin verskyn. Die behoefte aan meer in-diepte en veelvlakkige verslae het gereeld begin verskyn, en deur die pogings van ouens van verskillende departemente is 'n tyd gelede 'n eenvoudige en praktiese oplossing georganiseer - 'n kombinasie van ClickHouse en PowerBI.
Vir 'n redelike lang tyd het hierdie buigsame oplossing baie gehelp, maar gaandeweg het die begrip begin kom dat ClickHouse nie rubber is nie en nie so gespot kan word nie.
Hier is dit belangrik om goed te verstaan dat ClickHouse, soos Druid, soos Vertica, soos Amazon RedShift (wat op postgres gebaseer is), analitiese enjins is wat geoptimaliseer is vir redelik gerieflike analise (somme, samevoegings, minimum-maksimum per kolom en 'n paar moontlike aansluitings). ), want georganiseer vir doeltreffende berging van kolomme van relasionele tabelle, anders as MySQL en ander (ry-georiënteerde) databasisse wat aan ons bekend is.
In wese is ClickHouse net 'n meer ruim "databasis", met nie baie gerieflike punt-vir-punt-invoeging nie (dis hoe dit bedoel is, alles is ok), maar aangename analise en 'n stel interessante kragtige funksies om met data te werk. Ja, jy kan selfs 'n tros skep - maar jy verstaan dat dit nie heeltemal korrek is om spykers met 'n mikroskoop te slaan nie en ons het na ander oplossings begin soek.
Vraag na luislang en ontleders
Ons maatskappy het baie ontwikkelaars wat vir 10-20 jaar byna elke dag kode skryf in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Daar is ook baie ervare stelseladministrateurs wat meer as een absoluut ongelooflike ramp beleef het wat nie by die wette van statistiek pas nie (byvoorbeeld wanneer die meerderheid skywe in 'n raid-10 vernietig word deur 'n sterk weerlig). In sulke omstandighede was dit lank nie duidelik wat 'n "luislangontleder" was nie. Python is soos PHP, net die naam is 'n bietjie langer en daar is 'n bietjie minder spore van verstandsveranderende stowwe in die tolk se bronkode. Soos meer en meer analitiese verslae egter geskep is, het ervare ontwikkelaars die belangrikheid van noue spesialisasie in gereedskap soos numpy, pandas, matplotlib, seaborn toenemend begin verstaan.
Die deurslaggewende rol is waarskynlik gespeel deur die skielike floute van werknemers deur die kombinasie van die woorde "logistiese regressie" en die demonstrasie van effektiewe verslagdoening oor groot data deur gebruik te maak van, ja, ja, pyspark.
Apache Spark, sy funksionele paradigma waarop relasionele algebra perfek pas, en sy vermoëns het so 'n indruk gemaak op ontwikkelaars wat gewoond is aan MySQL dat die behoefte om die geledere met ervare ontleders te versterk, duidelik geword het.
Verdere pogings van Apache Spark/Hadoop om op te styg en wat nie heeltemal volgens die draaiboek verloop het nie
Dit het egter gou duidelik geword dat iets sistemies nie heeltemal reg is met Spark nie, of dit was bloot nodig om jou hande beter te was. As die Hadoop/MapReduce/Lucene-stapel deur redelik ervare programmeerders gemaak is, wat duidelik is as jy mooi kyk na die bronkode in Java of Doug Cutting se idees in Lucene, dan is Spark skielik in die eksotiese taal Scala geskryf, wat is baie omstrede vanuit 'n praktiese oogpunt en ontwikkel tans nie. En die gereelde daling in berekeninge op die Spark-groepering as gevolg van onlogiese en nie baie deursigtige werk met geheuetoewysing vir verminderde bedrywighede (baie sleutels kom op een slag) het 'n stralekrans rondom dit geskep van iets wat ruimte het om te groei. Boonop is die situasie vererger deur 'n groot aantal vreemde oop hawens, tydelike lêers wat op die mees onverstaanbare plekke gegroei het en 'n helse jar-afhanklikhede - wat veroorsaak het dat stelseladministrateurs een gevoel gehad het wat van kleins af goed bekend was: hewige haat (of dalk hulle moes hul hande met seep was).
As gevolg hiervan het ons verskeie interne analitiese projekte "oorleef" wat Apache Spark aktief gebruik (insluitend Spark Streaming, Spark SQL) en die Hadoop-ekosisteem (ensovoorts, ensovoorts). Ten spyte van die feit dat ons met verloop van tyd geleer het om "dit" redelik goed voor te berei en te monitor, en "dit" het feitlik opgehou om skielik te val as gevolg van veranderinge in die aard van die data en die wanbalans van eenvormige RDD hashing, die begeerte om iets wat reeds gereed is, te neem , opgedateer en iewers in die wolk geadministreer, het sterker en sterker geword. Dit was in hierdie tyd dat ons probeer het om die klaargemaakte wolksamestelling van Amazon Web Services te gebruik - en het daarna probleme probeer oplos deur dit te gebruik. EMR is Apache Spark wat deur Amazon voorberei is met bykomende sagteware van die ekosisteem, baie soos Cloudera/Hortonworks-bou.
Rubberlêerberging vir ontleding is 'n dringende behoefte
Die ervaring om Hadoop/Spark met brandwonde aan verskeie dele van die liggaam te “kook” was nie verniet nie. Die behoefte om 'n enkele, goedkoop en betroubare lêerberging te skep wat bestand sou wees teen hardewarefoute en waarin dit moontlik sou wees om lêers in verskillende formate vanaf verskillende stelsels te stoor en doeltreffende en tyddoeltreffende monsters vir verslae uit hierdie data te maak, het toenemend geword duidelik.
Ek wou ook hê dat die opdatering van die sagteware van hierdie platform nie 'n Nuwejaarsnagmerrie word met die lees van 20-bladsye Java-spore en die ontleding van kilometers lange gedetailleerde logs van die groep met behulp van Spark History Server en 'n verligte vergrootglas nie. Ek wou 'n eenvoudige en deursigtige instrument hê wat nie gereelde duik onder die enjinkap vereis het as die ontwikkelaar se standaard MapReduce-versoek opgehou het om uit te voer toe die verminderde data-werker uit die geheue geraak het as gevolg van 'n nie baie goed gekose brondata-partisioneringsalgoritme nie.
Is Amazon S3 'n kandidaat vir DataLake?
Ervaring met Hadoop/MapReduce het ons geleer dat ons 'n skaalbare, betroubare lêerstelsel en skaalbare werkers nodig het, wat nader aan die data "kom" om nie die data oor die netwerk te stuur nie. Werkers moet data in verskillende formate kan lees, maar verkieslik nie onnodige inligting lees nie en data vooraf kan stoor in formate wat geskik is vir werkers.
Weereens, die basiese idee. Daar is geen begeerte om groot data in 'n enkele cluster analitiese enjin te "gooi" wat vroeër of later sal verstik en jy sal dit lelik moet versplinter nie. Ek wil lêers, net lêers, in 'n verstaanbare formaat stoor en doeltreffende analitiese navrae daaroor uitvoer deur verskillende maar verstaanbare gereedskap te gebruik. En daar sal meer en meer lêers in verskillende formate wees. En dit is beter om nie die enjin te verskeur nie, maar die brondata. Ons het 'n uitbreidbare en universele DataLake nodig, het ons besluit ...
Wat as jy lêers in die bekende en bekende skaalbare wolkberging Amazon S3 stoor, sonder om jou eie tjops van Hadoop voor te berei?
Dit is duidelik dat die persoonlike data "laag" is, maar wat van ander data as ons dit daar uithaal en dit "effektief bestuur"?
Cluster-bigdata-analytics-ekosisteem van Amazon Web Services - in baie eenvoudige woorde
Te oordeel aan ons ervaring met AWS, is Apache Hadoop/MapReduce al lank aktief daar gebruik onder verskeie souse, byvoorbeeld in die DataPipeline-diens (ek beny my kollegas, hulle het geleer hoe om dit reg voor te berei). Hier stel ons rugsteun van verskillende dienste vanaf DynamoDB-tabelle op:
En hulle loop al vir 'n paar jaar gereeld op ingebedde Hadoop/MapReduce-klusters soos klokwerk. "Stel dit en vergeet dit":
Jy kan ook effektief betrokke raak by data-satanisme deur Jupiter-skootrekenaars in die wolk vir ontleders op te stel en die AWS SageMaker-diens te gebruik om KI-modelle in die geveg op te lei en te ontplooi. Hier is hoe dit vir ons lyk:
En ja, jy kan vir jouself 'n skootrekenaar of 'n ontleder in die wolk optel en dit aan 'n Hadoop/Spark-kluster koppel, die berekeninge doen en dan alles vasspyker:
Werklik gerieflik vir individuele analitiese projekte en vir sommige het ons die EMR-diens suksesvol gebruik vir grootskaalse berekeninge en ontledings. Wat van 'n stelseloplossing vir DataLake, sal dit werk? Op hierdie oomblik was ons op die rand van hoop en wanhoop en het die soektog voortgesit.
AWS Glue - netjies verpakte Apache Spark op steroïede
Dit het geblyk dat AWS sy eie weergawe van die "Hive/Pig/Spark"-stapel het. Die rol van Hive, m.a.w. Die katalogus van lêers en hul tipes in DataLake word uitgevoer deur die "Data catalog" diens, wat nie die versoenbaarheid daarvan met die Apache Hive-formaat verberg nie. Jy moet inligting by hierdie diens voeg oor waar jou lêers geleë is en in watter formaat hulle is. Die data kan nie net in s3 wees nie, maar ook in die databasis, maar dit is nie die onderwerp van hierdie pos nie. Hier is hoe ons DataLake-datagids georganiseer is:
Die lêers is geregistreer, wonderlik. As die lêers opgedateer is, begin ons crawlers óf met die hand óf op 'n skedule, wat inligting oor hulle vanaf die meer sal opdateer en stoor. Dan kan die data van die meer verwerk word en die resultate iewers opgelaai word. In die eenvoudigste geval laai ons ook op na s3. Dataverwerking kan enige plek gedoen word, maar daar word voorgestel dat u die verwerking op 'n Apache Spark-groepering instel deur gevorderde vermoëns deur die AWS Glue API te gebruik. Trouens, jy kan die goeie ou en bekende luislang-kode gebruik deur die pyspark-biblioteek te gebruik en die uitvoering daarvan op N nodusse van 'n groepering van 'n sekere kapasiteit met monitering instel, sonder om in die ingewande van Hadoop te delf en dok-roker-houers te sleep en afhanklikheidskonflikte uit te skakel .
Weereens 'n eenvoudige idee. Dit is nie nodig om Apache Spark op te stel nie, jy hoef net python-kode vir pyspark te skryf, dit plaaslik op jou lessenaar te toets en dit dan op 'n groot groep in die wolk te laat loop, en spesifiseer waar die brondata is en waar om die resultaat te plaas. Soms is dit nodig en nuttig, en dit is hoe ons dit opstel:
Dus, as jy iets op 'n Spark-kluster moet bereken deur data in s3 te gebruik, skryf ons kode in python/pyspark, toets dit, en sterkte aan die wolk.
Wat van die orkestrasie? Wat as die taak val en verdwyn? Ja, daar word voorgestel om 'n pragtige pyplyn in die Apache Pig-styl te maak en ons het dit selfs probeer, maar vir nou het ons besluit om ons diep aangepaste orkestrasie in PHP en JavaScript te gebruik (ek verstaan, daar is kognitiewe dissonansie, maar dit werk, vir jaar en sonder foute).
Die formaat van lêers wat in die meer gestoor word, is die sleutel tot prestasie
Dit is baie, baie belangrik om nog twee sleutelpunte te verstaan. Om navrae oor lêerdata in die meer so vinnig moontlik te laat uitvoer en prestasie nie te verswak wanneer nuwe inligting bygevoeg word nie, moet jy:
- Stoor kolomme lêers afsonderlik (sodat jy nie al die reëls hoef te lees om te verstaan wat in die kolomme is nie). Hiervoor het ons die parketformaat met kompressie geneem
- Dit is baie belangrik om lêers in vouers te verdeel soos: taal, jaar, maand, dag, week. Enjins wat hierdie tipe versplintering verstaan, sal slegs na die nodige dopgehou kyk, sonder om al die data in 'n ry te sif.
In wese, op hierdie manier, lê jy die brondata in die mees doeltreffende vorm uit vir die analitiese enjins wat bo-op gehang is, wat selfs in geskeurde vouers selektief net die nodige kolomme van lêers kan ingaan en lees. Jy hoef nêrens die data “op te vul” nie (die berging sal eenvoudig bars) - plaas dit net dadelik wyslik in die lêerstelsel in die korrekte formaat. Natuurlik moet dit hier duidelik wees dat die stoor van 'n groot csv-lêer in DataLake, wat eers reël vir reël deur die groep gelees moet word om die kolomme te onttrek, nie baie raadsaam is nie. Dink weer aan bogenoemde twee punte as dit nog nie duidelik is hoekom dit alles gebeur nie.
AWS Athena - die domkrag-in-die-boks
En toe, terwyl ons 'n meer geskep het, het ons op een of ander manier per ongeluk op Amazon Athena afgekom. Skielik het dit geblyk dat deur ons groot loglêers noukeurig in vouerskerwe in die korrekte (parket)kolomformaat te rangskik, jy baie vinnig uiters insiggewende keuses daaruit kan maak en verslae SONDER kan bou, sonder 'n Apache Spark/Gom-kluster.
Die Athena-enjin aangedryf deur data in s3 is gebaseer op die legendariese - 'n verteenwoordiger van die MPP (massiewe parallelle verwerking) familie van benaderings tot dataverwerking, wat data neem waar dit lê, van s3 en Hadoop tot Cassandra en gewone tekslêers. Jy hoef net vir Athena te vra om 'n SQL-navraag uit te voer, en dan "werk alles vinnig en outomaties." Dit is belangrik om daarop te let dat Athena "slim" is, dit gaan net na die nodige geskeurde dopgehou en lees slegs die kolomme wat in die versoek benodig word.
Die pryse vir versoeke aan Athena is ook interessant. Ons betaal vir . Dié. nie vir die aantal masjiene in die groep per minuut nie, maar... vir die data wat werklik op 100-500 masjiene geskandeer is, slegs die data wat nodig is om die versoek te voltooi.
En deur slegs die nodige kolomme van korrek geskeurde dopgehou aan te vra, het dit geblyk dat die Athena-diens ons tientalle dollars per maand kos. Wel, wonderlik, amper gratis, in vergelyking met ontledings op groepe!
Terloops, hier is hoe ons ons data in s3 verdeel:
Gevolglik het heeltemal verskillende afdelings in die maatskappy, van inligtingsekuriteit tot analise, in 'n kort tydjie aktief versoeke aan Athena begin rig en vinnig, binne sekondes, nuttige antwoorde van "groot" data oor redelik lang tydperke ontvang: maande, 'n halfjaar, ens. P.
Maar ons het verder gegaan en na die wolk begin gaan vir antwoorde : 'n ontleder skryf 'n SQL-navraag in 'n bekende konsole, wat op 100-500 masjiene "vir pennies" data na s3 stuur en 'n antwoord gewoonlik binne 'n paar sekondes terugstuur. Gerieflik. En vinnig. Ek kan dit steeds nie glo nie.
As gevolg hiervan, nadat ons besluit het om data in s3 te stoor, in 'n doeltreffende kolomformaat en met redelike versplintering van data in vouers ... het ons DataLake en 'n vinnige en goedkoop analitiese enjin ontvang - gratis. En hy het baie gewild geword in die geselskap, want... verstaan SQL en werk ordes van grootte vinniger as deur groepe te begin/stop/op te stel. "En as die resultaat dieselfde is, hoekom meer betaal?"
’n Versoek aan Athena lyk so iets. As jy wil, kan jy natuurlik genoeg vorm , maar ons sal ons beperk tot eenvoudige groepering. Kom ons kyk watter reaksiekodes die kliënt 'n paar weke gelede in die webbedienerlogboeke gehad het en maak seker dat daar geen foute is nie:
Bevindinge
Nadat ons deur, om nie te sê 'n lang, maar pynlike pad, deurlopend die risiko's en vlak van kompleksiteit en koste van ondersteuning voldoende geassesseer het, het ons 'n oplossing vir DataLake en analise gevind wat nooit ophou om ons tevrede te stel met beide spoed en koste van eienaarskap nie.
Dit het geblyk dat die bou van 'n effektiewe, vinnige en goedkoop om te bedryf DataLake vir die behoeftes van heeltemal verskillende afdelings van die maatskappy heeltemal binne die vermoëns is van selfs ervare ontwikkelaars wat nog nooit as argitekte gewerk het nie en nie weet hoe om vierkante op vierkante te teken nie. pyle en ken 50 terme uit die Hadoop-ekosisteem.
Aan die begin van die reis was my kop besig om te skeur van die vele wilde dieretuine van oop en geslote sagteware en die begrip van die las van verantwoordelikheid vir afstammelinge. Begin net om jou DataLake te bou uit eenvoudige gereedskap: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., versamel terugvoer en verstaan die fisika van die prosesse wat plaasvind diep. Alles kompleks en troebel - gee dit aan vyande en mededingers.
As jy nie na die wolk wil gaan nie en graag oopbronprojekte wil ondersteun, opdateer en regmaak, kan jy 'n skema soortgelyk aan ons plaaslik bou, op goedkoop kantoormasjiene met Hadoop en Presto bo-op. Die belangrikste ding is om nie te stop en vorentoe te beweeg, te tel, te soek na eenvoudige en duidelike oplossings nie, en alles sal beslis uitwerk! Sterkte aan almal en sien julle weer!
Bron: will.com