Živimo v čudovitem času, ko lahko hitro in enostavno povežete več že pripravljenih odprtokodnih orodij, jih nastavite z "izklopljeno zavestjo" po nasvetu stackoverflowa, ne da bi se poglabljali v "več črk", in zaženete jih v komercialno delovanje. In ko morate posodobiti/razširiti ali nekdo pomotoma znova zažene nekaj strojev - ugotovite, da so se v resnici začele nekakšne obsesivne slabe sanje, vse je nenadoma postalo bolj zapleteno do neprepoznavnosti, ni poti nazaj, prihodnost je nejasna in varneje, namesto da bi programirali, redili čebele in delali sir.
Ni zaman, da bolj izkušeni kolegi z glavami, posutimi s hrošči in zato že sivimi, razmišljajo o neverjetno hitrem namestitvi paketov "kontejnerjev" v "kocke" na desetine strežnikov v "modnih jezikih" z vgrajeno podporo za asinhroni neblokirni V/I, skromno se nasmehni. In tiho še naprej berejo »man ps«, se poglabljajo v izvorno kodo »nginx«, dokler jim ne zakrvavijo oči, in pišejo, pišejo, pišejo teste enot. Kolegi vedo, da bo najbolj zanimivo, ko bo »vse to« nekega dne postalo zastavljeno ponoči na silvestrovo. Pomagalo jim bo le globoko razumevanje narave unixa, shranjene tabele stanja TCP/IP in osnovnih algoritmov za razvrščanje in iskanje. Da oživimo sistem, ko zazvoni.
Aja, malo sem se zamotil, ampak upam, da mi je uspelo prenesti stanje pričakovanja.
Danes želim deliti naše izkušnje pri uvajanju priročnega in poceni sklada za DataLake, ki rešuje večino analitičnih nalog v podjetju za popolnoma različne strukturne oddelke.
Pred časom smo prišli do spoznanja, da podjetja vedno bolj potrebujejo sadove produktne in tehnične analitike (da ne omenjamo češnje na torti v obliki strojnega učenja), za razumevanje trendov in tveganj pa moramo zbirati in analizirati vedno več meritev.
Osnovna tehnična analitika v Bitrix24
Pred nekaj leti, hkrati z lansiranjem storitve Bitrix24, smo aktivno vlagali čas in sredstva v ustvarjanje preproste in zanesljive analitične platforme, ki bi pomagala hitro videti težave v infrastrukturi in načrtovati naslednji korak. Seveda je bilo priporočljivo vzeti že pripravljena orodja, ki so bila čim bolj preprosta in razumljiva. Zato je bil za spremljanje izbran nagios, za analitiko in vizualizacijo pa munin. Zdaj imamo na tisoče pregledov v nagios, na stotine grafikonov v munin in naši kolegi jih uspešno uporabljajo vsak dan. Metrike so jasne, grafi pregledni, sistem deluje zanesljivo že več let in redno se dodajajo novi testi in grafi: ko zaženemo novo storitev, dodamo več testov in grafov. Vso srečo.
S prstom na utripu - napredna tehnična analitika
Želja po prejemanju informacij o težavah "čim hitreje" nas je pripeljala do aktivnih poskusov s preprostimi in razumljivimi orodji - pinba in xhprof.
Pinba nam je v paketih UDP pošiljala statistiko o hitrosti dela delov spletnih strani v PHP, mi pa smo lahko na spletu v shrambi MySQL (Pinba ima lasten mehanizem MySQL za hitro analizo dogodkov) videli kratek seznam težav in se nanje odzvali. njim. In xhprof nam je samodejno omogočil zbiranje grafov izvajanja najpočasnejših PHP strani od strank in analizo, kaj bi lahko privedlo do tega - mirno, nalivanje čaja ali kaj močnejšega.
Pred časom je bil komplet orodij dopolnjen z drugim dokaj preprostim in razumljivim motorjem, ki temelji na algoritmu za obratno indeksiranje, ki je odlično implementiran v legendarni knjižnici Lucene - Elastic/Kibana. Preprosta zamisel o večnitnem zapisovanju dokumentov v inverzni indeks Lucene na podlagi dogodkov v dnevnikih in hitrem iskanju po njih z deljenjem faset se je izkazala za res uporabno.
Kljub precej tehničnemu videzu vizualizacij v Kibani z nizko nivojskimi koncepti, kot je »vedro«, ki »teče navzgor« in na novo izumljen jezik še ne povsem pozabljene relacijske algebre, nam je orodje začelo dobro pomagati pri naslednjih nalogah:
- Koliko PHP napak je imel odjemalec Bitrix24 na portalu p1 v zadnji uri in katere? Razumeti, odpustiti in hitro popraviti.
- Koliko video klicev je bilo opravljenih na portalih v Nemčiji v zadnjih 24 urah, s kakšno kakovostjo in ali so bile težave s kanalom/omrežjem?
- Kako dobro deluje sistemska funkcionalnost (naša razširitev C za PHP), prevedena iz vira v najnovejši posodobitvi storitve in uvedena strankam? Ali obstajajo segfaults?
- Ali se podatki o strankah prilegajo pomnilniku PHP? Ali obstajajo napake glede prekoračitve pomnilnika, dodeljenega procesom: »zmanjkalo pomnilnika«? Najdi in nevtraliziraj.
Tukaj je konkreten primer. Kljub temeljitemu in večnivojskemu testiranju je naročnik z zelo nestandardnim primerom in poškodovanimi vhodnimi podatki prejel nadležno in nepričakovano napako, oglasila se je sirena in začel se je postopek hitrega odpravljanja:
Poleg tega kibana omogoča organizacijo obvestil za določene dogodke, v kratkem času pa je orodje v podjetju začelo uporabljati na desetine zaposlenih iz različnih oddelkov – od tehnične podpore in razvoja do QA.
Dejavnost katerega koli oddelka v podjetju je postala priročna za sledenje in merjenje - namesto ročnega analiziranja dnevnikov na strežnikih morate samo enkrat nastaviti razčlenjevanje dnevnikov in jih poslati v elastično gručo, da lahko uživate na primer v razmišljanju v kibani nadzorna plošča število prodanih dvoglavih mačjih mladičev, natisnjenih na 3-D tiskalniku za zadnji lunarni mesec.
Osnovna poslovna analitika
Vsi vemo, da se poslovna analitika v podjetjih pogosto začne z izjemno aktivno uporabo, ja, Excela. A glavno je, da se tu ne konča. Google Analytics, ki temelji na oblaku, prav tako priliva olje na ogenj – hitro se začnete navaditi na dobre stvari.
V našem skladno razvijajočem se podjetju so se tu in tam začeli pojavljati »preroki« intenzivnejšega dela z večjimi podatki. Redno so se začele pojavljati potrebe po bolj poglobljenih in večplastnih poročilih in s prizadevanji fantov iz različnih oddelkov je bila pred časom organizirana preprosta in praktična rešitev - kombinacija ClickHouse in PowerBI.
Dolgo časa je ta prilagodljiva rešitev veliko pomagala, vendar je postopoma začelo prihajati razumevanje, da ClickHouse ni gumijast in se ga ne more tako norčevati.
Pri tem je pomembno dobro razumeti, da so ClickHouse, tako kot Druid, kot Vertica, kot Amazon RedShift (ki temelji na postgresu), analitični motorji, optimizirani za dokaj priročno analitiko (vsote, združevanja, najmanj-maksimum po stolpcih in nekaj možnih združevanj ), Ker organizirana za učinkovito shranjevanje stolpcev relacijskih tabel, za razliko od MySQL in drugih (vrstično usmerjenih) podatkovnih baz, ki jih poznamo.
V bistvu je ClickHouse le bolj obsežna "baza podatkov", z ne zelo priročnim vstavljanjem od točke do točke (tako je mišljeno, vse je v redu), vendar prijetno analitiko in nizom zanimivih zmogljivih funkcij za delo s podatki. Da, lahko celo ustvarite grozd - vendar razumete, da zabijanje žebljev z mikroskopom ni povsem pravilno in začeli smo iskati druge rešitve.
Povpraševanje po pythonu in analitikih
Naše podjetje ima veliko razvijalcev, ki pišejo kodo skoraj vsak dan 10–20 let v PHP, JavaScript, C#, C/C++, Javi, Go, Rust, Python, Bash. Obstaja tudi veliko izkušenih sistemskih skrbnikov, ki so doživeli več kot eno popolnoma neverjetno katastrofo, ki se ne ujema z zakoni statistike (na primer, ko je večina diskov v napadu 10 uničena zaradi močnega udara strele). V takih okoliščinah dolgo časa ni bilo jasno, kaj je "python analitik". Python je kot PHP, le da je ime nekoliko daljše in v izvorni kodi tolmača je malo manj sledi snovi, ki spreminjajo um. Ker pa je bilo ustvarjenih vedno več analitičnih poročil, so izkušeni razvijalci začeli vse bolj razumeti pomen ozke specializacije v orodjih, kot so numpy, pandas, matplotlib, seaborn.
Odločilno vlogo je najverjetneje odigrala nenadna omedlevica zaposlenih od kombinacije besed »logistična regresija« in demonstracija učinkovitega poročanja o velikih podatkih z uporabo, ja, ja, pyspark.
Apache Spark, njegova funkcionalna paradigma, ki se ji popolnoma prilega relacijska algebra, in njegove zmogljivosti so naredile takšen vtis na razvijalce, vajene MySQL, da je potreba po okrepitvi z izkušenimi analitiki postala jasna kot beli dan.
Nadaljnji poskusi vzleta Apache Spark/Hadoop in kaj ni šlo čisto po scenariju
Kmalu pa se je pokazalo, da s Sparkom sistemsko nekaj ni v redu ali pa si je preprosto treba bolje umiti roke. Če so sklad Hadoop/MapReduce/Lucene naredili precej izkušeni programerji, kar je očitno, če natančno pogledate izvorno kodo v Javi ali ideje Douga Cuttinga v Lucene, potem je Spark nenadoma napisan v eksotičnem jeziku Scala, ki je zelo sporen z vidika praktičnosti in se trenutno ne razvija. In redno padanje izračunov na gruči Spark zaradi nelogičnega in premalo preglednega dela z dodeljevanjem pomnilnika za operacije redukcije (veliko ključev pride naenkrat) je okoli njega ustvarilo halo nečesa, kar ima prostor za rast. Poleg tega je položaj poslabšalo veliko število nenavadnih odprtih vrat, začasne datoteke, ki rastejo na najbolj nerazumljivih mestih, in pekel odvisnosti od kozarcev - zaradi česar so sistemski skrbniki imeli občutek, ki je dobro znan iz otroštva: hudo sovraštvo (ali morda morali so si umiti roke z milom).
Posledično smo »preživeli« več notranjih analitičnih projektov, ki aktivno uporabljajo Apache Spark (vključno s Spark Streaming, Spark SQL) in ekosistem Hadoop (in tako naprej in tako naprej). Kljub dejstvu, da smo se sčasoma naučili "to" precej dobro pripraviti in spremljati in se je "to" praktično nehalo nenadoma zrušiti zaradi sprememb v naravi podatkov in neuravnoteženosti enotnega zgoščevanja RDD, želja, da vzamemo nekaj že pripravljenega , posodobljen in upravljan nekje v oblaku, je postajal vedno močnejši. V tem času smo poskušali uporabiti že pripravljeno zbirko oblakov Amazon Web Services - in nato skušal z njim rešiti težave. EMR je Apache Spark, ki ga je pripravil Amazon z dodatno programsko opremo iz ekosistema, podobno kot gradnje Cloudera/Hortonworks.
Gumijasto shranjevanje datotek za analitiko je nujno potrebno
Izkušnja "kuhanja" Hadoop/Spark z opeklinami različnih delov telesa ni bila zaman. Potreba po izdelavi enotnega, poceni in zanesljivega pomnilnika datotek, ki bi bil odporen na okvare strojne opreme in v katerem bi bilo mogoče shranjevati datoteke v različnih formatih iz različnih sistemov ter iz teh podatkov narediti učinkovite in časovno učinkovite vzorce za poročila jasno.
Želel sem tudi, da se posodabljanje programske opreme te platforme ne spremeni v novoletno nočno moro z branjem 20-stranskih sledi Java in analiziranjem kilometrskih podrobnih dnevnikov gruče s pomočjo Spark History Server in lupe z osvetlitvijo. Želel sem imeti preprosto in pregledno orodje, ki ne zahteva rednega potapljanja pod pokrovom, če se razvijalčeva standardna zahteva MapReduce neha izvajati, ko redukcijski podatkovni delavec pade iz pomnilnika zaradi ne preveč dobro izbranega algoritma za particioniranje izvornih podatkov.
Je Amazon S3 kandidat za DataLake?
Izkušnje s Hadoop/MapReduce so nas naučile, da potrebujemo razširljiv, zanesljiv datotečni sistem in razširljive delavce na vrhu, ki se »približajo« podatkom, da ne bi prenašali podatkov po omrežju. Delavci bi morali imeti možnost brati podatke v različnih formatih, vendar po možnosti ne brati nepotrebnih informacij in imeti možnost vnaprejšnjega shranjevanja podatkov v formatih, ki so primerni za delavce.
Še enkrat osnovna ideja. Ni želje, da bi velike podatke "zlivali" v en sam grozdni analitični motor, ki se bo prej ali slej zadušil in ga boste morali grdo razrezati. Datoteke, samo datoteke, želim shranjevati v razumljivi obliki in zanje izvajati učinkovite analitične poizvedbe z različnimi, a razumljivimi orodji. In vedno več bo datotek v različnih formatih. In bolje je, da ne razdelite motorja, ampak izvorne podatke. Odločili smo se, da potrebujemo razširljivo in univerzalno DataLake ...
Kaj pa, če shranjujete datoteke v znani in dobro znani razširljivi shrambi v oblaku Amazon S3, ne da bi morali pripravljati lastne odrezke iz Hadoopa?
Jasno je, da je osebnih podatkov "nizko", kaj pa drugi podatki, če jih vzamemo ven in jih "učinkovito upravljamo"?
Cluster-bigdata-analytics ekosistem Amazon Web Services – z zelo preprostimi besedami
Sodeč po naših izkušnjah z AWS, se Apache Hadoop/MapReduce tam že dolgo aktivno uporablja pod različnimi omakami, na primer v storitvi DataPipeline (zavidam svojim kolegom, naučili so se ga pravilno pripraviti). Tukaj nastavimo varnostne kopije iz različnih storitev iz tabel DynamoDB:
In že nekaj let redno delujejo na vdelanih gručah Hadoop/MapReduce kot po maslu. "Nastavi in pozabi":
Prav tako se lahko učinkovito vključite v satanizem podatkov tako, da nastavite prenosne računalnike Jupiter v oblaku za analitike in uporabite storitev AWS SageMaker za usposabljanje in uvajanje modelov AI v boj. Takole izgleda pri nas:
In ja, lahko izberete prenosni računalnik zase ali za analitika v oblaku in ga priključite na gručo Hadoop/Spark, naredite izračune in nato vse uredite:
Zelo priročno za posamezne analitične projekte in za nekatere smo uspešno uporabili storitev EMR za obsežne izračune in analitiko. Kaj pa sistemska rešitev za DataLake, bo delovala? V tem trenutku smo bili na meji upanja in obupa in nadaljevali iskanje.
AWS Glue - lično zapakiran Apache Spark na steroidih
Izkazalo se je, da ima AWS svojo različico sklada »Hive/Pig/Spark«. Vloga Hive, tj. Katalog datotek in njihovih tipov v DataLake izvaja storitev »Data catalog«, ki ne skriva svoje združljivosti s formatom Apache Hive. Tej storitvi morate dodati informacije o tem, kje se nahajajo vaše datoteke in v kakšnem formatu so. Podatki so lahko ne samo v s3, ampak tudi v bazi, vendar to ni tema te objave. Tukaj je organiziran naš imenik podatkov DataLake:
Datoteke so registrirane, super. Če so bile datoteke posodobljene, ročno ali po urniku zaženemo pajke, ki bodo posodobili informacije o njih iz jezera in jih shranili. Potem lahko podatke iz jezera obdelamo in rezultate nekam naložimo. V najenostavnejšem primeru naložimo tudi na s3. Obdelavo podatkov je mogoče izvesti kjer koli, vendar je predlagano, da konfigurirate obdelavo v gruči Apache Spark z uporabo naprednih zmogljivosti prek API-ja AWS Glue. Pravzaprav lahko vzamete dobro staro in znano kodo python s knjižnico pyspark in konfigurirate njeno izvajanje na N vozliščih gruče z določeno zmogljivostjo z nadzorom, ne da bi se poglobili v drobovje Hadoopa in vlekli vsebnike docker-moker ter odpravili konflikte odvisnosti .
Še enkrat preprosta ideja. Ni vam treba konfigurirati Apache Spark, samo napisati morate kodo python za pyspark, jo preizkusiti lokalno na namizju in jo nato zagnati v veliki gruči v oblaku, pri čemer določite, kje so izvorni podatki in kam želite dati rezultat. Včasih je to potrebno in uporabno, in tako ga nastavimo:
Torej, če morate nekaj izračunati v gruči Spark z uporabo podatkov v s3, napišemo kodo v python/pyspark, jo preizkusimo in veliko sreče v oblaku.
Kaj pa orkestracija? Kaj če bi naloga padla in izginila? Da, predlaga se izdelava čudovitega cevovoda v slogu Apache Pig in celo poskusili smo jih, vendar smo se za zdaj odločili, da uporabimo našo zelo prilagojeno orkestracijo v PHP in JavaScript (razumem, obstaja kognitivna disonanca, vendar deluje, za leta in brez napak).
Format datotek, shranjenih v jezeru, je ključ do učinkovitosti
Zelo, zelo pomembno je razumeti še dve ključni točki. Če želite, da se poizvedbe o podatkih datoteke v jezeru izvedejo čim hitreje in da se zmogljivost ne poslabša, ko dodate nove informacije, morate:
- Shranjujte stolpce datotek ločeno (tako da vam ni treba brati vseh vrstic, da bi razumeli, kaj je v stolpcih). Za to smo vzeli format parketa s stiskanjem
- Zelo pomembno je, da datoteke razdelite v mape, kot so: jezik, leto, mesec, dan, teden. Motorji, ki razumejo to vrsto drobljenja, bodo pogledali samo potrebne mape, ne da bi pregledali vse podatke po vrsti.
V bistvu na ta način razporedite izvorne podatke v najučinkovitejši obliki za analitične mehanizme, obešene na vrhu, ki lahko tudi v razdeljenih mapah selektivno vstopajo in berejo samo potrebne stolpce iz datotek. Podatkov vam ni treba nikjer "napolniti" (pomnilnik bo preprosto počil) - samo takoj ga pametno vstavite v datotečni sistem v pravilni obliki. Seveda bi moralo biti tukaj jasno, da shranjevanje ogromne datoteke csv v DataLake, ki jo mora gruča najprej prebrati vrstico za vrstico, da lahko ekstrahira stolpce, ni zelo priporočljivo. Ponovno razmislite o zgornjih dveh točkah, če še ni jasno, zakaj se vse to dogaja.
AWS Athena - jack-in-the-box
In potem smo med ustvarjanjem jezera nekako po naključju naleteli na amazonsko Atheno. Nenadoma se je izkazalo, da lahko s skrbnim urejanjem naših ogromnih dnevniških datotek v mape shards v pravilnem (parketnem) formatu stolpcev iz njih zelo hitro naredimo izjemno informativne izbore in sestavimo poročila BREZ, brez gruče Apache Spark/Glue.
Motor Athena, ki ga poganjajo podatki v s3, temelji na legendarnem - predstavnik MPP (massive parallel processing) družine pristopov k obdelavi podatkov, ki podatke vzame tam, kjer ležijo, od s3 in Hadoop do Cassandre in običajnih besedilnih datotek. Atheno morate samo prositi, da izvede poizvedbo SQL, in potem bo vse "delovalo hitro in samodejno." Pomembno je omeniti, da je Athena »pametna«, gre samo do potrebnih razdeljenih map in bere samo stolpce, ki so potrebni v zahtevi.
Zanimive so tudi cene za zahteve Atheni. Plačujemo za . Tisti. ne za število strojev v gruči na minuto, ampak... za podatke, ki so dejansko pregledani na 100-500 napravah, samo podatki, potrebni za dokončanje zahteve.
In z zahtevanjem samo potrebnih stolpcev iz pravilno razdeljenih map se je izkazalo, da nas storitev Athena stane na desetine dolarjev na mesec. No, super, skoraj zastonj, v primerjavi z analitiko na grozdih!
Mimogrede, tako delimo svoje podatke v s3:
Posledično so v kratkem času popolnoma različni oddelki v podjetju, od informacijske varnosti do analitike, začeli aktivno pošiljati zahteve Atheni in hitro, v nekaj sekundah, prejemati uporabne odgovore iz "velikih" podatkov v precej dolgih obdobjih: mesecih, pol leta itd. P.
Toda šli smo dlje in začeli iti v oblak po odgovore : analitik napiše SQL poizvedbo v poznano konzolo, ki na 100-500 strojih “za drobiž” pošlje podatke na s3 in vrne odgovor običajno v nekaj sekundah. Udobno. In hitro. Še vedno ne morem verjeti.
Posledično, ko smo se odločili za shranjevanje podatkov v s3, v učinkovitem stolpčnem formatu in z razumnim shardingom podatkov v mape ... smo prejeli DataLake in hiter in poceni analitični motor - brezplačno. In postal je zelo priljubljen v podjetju, ker ... razume SQL in deluje veliko hitreje kot z zagonom/ustavljanjem/nastavitvijo gruč. "In če je rezultat enak, zakaj plačati več?"
Prošnja Ateni izgleda nekako takole. Po želji seveda lahko oblikujete dovolj , vendar se bomo omejili na preprosto združevanje. Poglejmo, katere odzivne kode je imel odjemalec pred nekaj tedni v dnevnikih spletnega strežnika in se prepričajmo, da ni napak:
Ugotovitve
Po prehodni, da ne rečem dolgi, a boleči poti, ob nenehnem ustreznem ocenjevanju tveganj in stopnje zahtevnosti ter stroškov podpore, smo našli rešitev za DataLake in analitiko, ki nas ne preneha razveseljevati tako s hitrostjo kot s stroški lastništva.
Izkazalo se je, da je izgradnja učinkovitega, hitrega in poceni DataLake za potrebe popolnoma različnih oddelkov podjetja povsem v zmožnostih tudi izkušenih razvijalcev, ki nikoli niso delali kot arhitekti in ne znajo risati kvadratov na kvadratih z puščice in poznati 50 izrazov iz ekosistema Hadoop.
Na začetku poti se mi je razcepila glava od številnih divjih živalskih vrtov odprte in zaprte programske opreme ter razumevanja bremena odgovornosti do zanamcev. Samo začnite graditi svoj DataLake s preprostimi orodji: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 ..., zbirajte povratne informacije in poglobljeno razumejte fiziko procesov, ki se odvijajo. Vse zapleteno in mračno - dajte to sovražnikom in tekmecem.
Če ne želite iti v oblak in radi podpirate, posodabljate in popravljate odprtokodne projekte, lahko lokalno zgradite shemo, podobno naši, na poceni pisarniških strojih s Hadoopom in Presto na vrhu. Glavna stvar je, da se ne ustavite in greste naprej, računate, iščete preproste in jasne rešitve in vse se bo zagotovo izšlo! Srečno vsem in se spet vidimo!
Vir: www.habr.com