Vivim en un moment increïble en què podeu connectar de manera ràpida i senzilla diverses eines de codi obert preparades, configurar-les amb la vostra "consciència apagada" segons els consells de stackoverflow, sense aprofundir en les "múltiples lletres" i llançar-les. posar-los en funcionament comercial. I quan necessiteu actualitzar/ampliar o algú reinicia accidentalment un parell de màquines, us adoneu que ha començat una mena de mal somni obsessiu, tot s'ha complicat dramàticament més enllà del reconeixement, no hi ha marxa enrere, el futur és vague i més segur, en comptes de programar, criar abelles i fer formatge.
No és en va que els companys més experimentats, amb el cap escampat d'errors i, per tant, ja grisos, contemplen el desplegament increïblement ràpid de paquets de "contenidors" en "cubs" a desenes de servidors en "idiomes de moda" amb suport integrat per a E/S asíncrona sense bloqueig, somriu modestament. I en silenci continuen rellegint "man ps", aprofundint en el codi font "nginx" fins que els sagnin els ulls i escriuen, escriuen, escriuen proves unitàries. Els companys saben que el més interessant arribarà quan "tot això" un dia es posi a la nit de la nit de Cap d'Any. I només els ajudarà una comprensió profunda de la naturalesa d'unix, la taula d'estat TCP/IP memoritzada i els algorismes bàsics de cerca de classificació. Per tornar el sistema a la vida mentre sonen les campanes.
Ah, sí, em vaig distreure una mica, però espero haver aconseguit transmetre l'estat d'expectació.
Avui vull compartir la nostra experiència en el desplegament d'una pila còmoda i econòmica per a DataLake, que resol la majoria de tasques analítiques de l'empresa per a divisions estructurals completament diferents.
Fa un temps, vam entendre que les empreses necessiten cada cop més els fruits de l'anàlisi de producte i tècnica (per no parlar de la cirereta del pastís en forma d'aprenentatge automàtic) i per entendre les tendències i els riscos: hem de recollir i analitzar cada cop més mètriques.
Analítica tècnica bàsica en Bitrix24
Fa uns quants anys, simultàniament amb el llançament del servei Bitrix24, vam invertir activament temps i recursos en la creació d'una plataforma analítica senzilla i fiable que ajudés a veure ràpidament els problemes de la infraestructura i planificar el següent pas. Per descomptat, era aconsellable portar eines ja fetes que fossin el més senzilles i entenedores possibles. Com a resultat, es va triar nagios per al seguiment i munin per a l'anàlisi i la visualització. Ara tenim milers de controls a nagios, centenars de gràfics a munin, i els nostres companys els utilitzen amb èxit cada dia. Les mètriques són clares, els gràfics són clars, el sistema funciona de manera fiable des de fa uns quants anys i s'hi afegeixen regularment noves proves i gràfics: quan posem en funcionament un nou servei, hi afegim diverses proves i gràfics. Bona sort.
Finger on the Pulse - Analítica tècnica avançada
El desig de rebre informació sobre problemes "tan aviat com sigui possible" ens va portar a experiments actius amb eines senzilles i entenedores: pinba i xhprof.
Pinba ens va enviar estadístiques en paquets UDP sobre la velocitat de funcionament de parts de pàgines web en PHP, i vam poder veure en línia a l'emmagatzematge MySQL (Pinba ve amb el seu propi motor MySQL per a l'anàlisi ràpida d'esdeveniments) una breu llista de problemes i respondre a ells. I xhprof ens va permetre automàticament recopilar gràfics de l'execució de les pàgines PHP més lentes dels clients i analitzar què podria conduir a això: amb calma, abocant te o alguna cosa més fort.
Fa un temps, el conjunt d'eines es va reposar amb un altre motor bastant senzill i entenedor basat en l'algorisme d'indexació inversa, perfectament implementat a la llegendària biblioteca Lucene: Elastic/Kibana. La idea senzilla d'enregistrar documents multifils en un índex Lucene invers basat en els esdeveniments dels registres i una cerca ràpida a través d'ells mitjançant la divisió de facetes va resultar molt útil.
Malgrat l'aspecte més aviat tècnic de les visualitzacions a Kibana amb conceptes de baix nivell com "cubeta" "fluint cap amunt" i el llenguatge reinventat de l'àlgebra relacional encara no oblidada del tot, l'eina va començar a ajudar-nos bé en les tasques següents:
- Quants errors PHP ha tingut el client Bitrix24 al portal p1 durant l'última hora i quins? Entendre, perdonar i corregir ràpidament.
- Quantes videotrucades s'han fet als portals d'Alemanya durant les 24 hores anteriors, amb quina qualitat i hi ha hagut dificultats amb el canal/la xarxa?
- Què tan bé funciona la funcionalitat del sistema (la nostra extensió C per a PHP), compilada des de la font a l'última actualització del servei i desplegada als clients? Hi ha errors de seg?
- Les dades del client encaixen a la memòria PHP? Hi ha errors sobre la superació de la memòria assignada als processos: "fora memòria"? Trobar i neutralitzar.
Aquí teniu un exemple concret. Malgrat les proves exhaustives i multinivell, el client, amb un cas molt no estàndard i dades d'entrada danyades, va rebre un error molest i inesperat, va sonar una sirena i va començar el procés de solucionar-ho ràpidament:
A més, kibana us permet organitzar notificacions per a esdeveniments específics i, en poc temps, desenes d'empleats de diferents departaments van començar a utilitzar l'eina de l'empresa, des de suport tècnic i desenvolupament fins a control de qualitat.
L'activitat de qualsevol departament de l'empresa s'ha tornat convenient de fer un seguiment i mesurar: en comptes d'analitzar manualment els registres als servidors, només cal que configureu l'anàlisi dels registres una vegada i els envieu al clúster elàstic per gaudir, per exemple, contemplant a la kibana. Dashboard el nombre de gatets de dos caps venuts impresos en una impressora 3D durant l'últim mes lunar.
Analítica empresarial bàsica
Tothom sap que l'anàlisi de negocis a les empreses sovint comença amb un ús extremadament actiu, sí, d'Excel. Però el més important és que no s'acaba aquí. Google Analytics basat en núvol també afegeix combustible al foc: comenceu a acostumar-vos ràpidament a les coses bones.
A la nostra empresa en desenvolupament harmònic, van començar a aparèixer aquí i allà "profetes" de treball més intens amb dades més grans. La necessitat d'informes més profunds i multifacètics va començar a aparèixer regularment i, gràcies a l'esforç de nois de diferents departaments, fa un temps es va organitzar una solució senzilla i pràctica: una combinació de ClickHouse i PowerBI.
Durant força temps, aquesta solució flexible va ajudar molt, però a poc a poc es va començar a entendre que ClickHouse no és de goma i no es pot burlar així.
Aquí és important entendre bé que ClickHouse, com Druid, com Vertica, com Amazon RedShift (que es basa en postgres), són motors analítics optimitzats per a analítiques força convenients (sumes, agregacions, mínim-màxim per columna i algunes possibles unions). ), perquè organitzat per a l'emmagatzematge eficient de columnes de taules relacionals, a diferència de MySQL i altres bases de dades (orientades a files) conegudes per nosaltres.
En essència, ClickHouse és només una "base de dades" més àmplia, amb una inserció punt per punt poc convenient (així és com es pretén, tot està bé), però una anàlisi agradable i un conjunt de funcions interessants i potents per treballar amb dades. Sí, fins i tot podeu crear un clúster, però enteneu que picar claus amb un microscopi no és del tot correcte i vam començar a buscar altres solucions.
Demanda de Python i analistes
La nostra empresa compta amb molts desenvolupadors que escriuen codi gairebé cada dia durant 10-20 anys en PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. També hi ha molts administradors de sistemes experimentats que han experimentat més d'un desastre absolutament increïble que no s'ajusta a les lleis de les estadístiques (per exemple, quan la majoria dels discos d'un raid-10 són destruïts per un fort llamp). En aquestes circumstàncies, durant molt de temps no estava clar què era un "analista Python". Python és com PHP, només el nom és una mica més llarg i hi ha una mica menys de rastres de substàncies que alteren la ment al codi font de l'intèrpret. Tanmateix, a mesura que es van crear cada cop més informes analítics, els desenvolupadors experimentats van començar a entendre cada cop més la importància d'una especialització estreta en eines com numpy, pandas, matplotlib, seaborn.
El paper decisiu, molt probablement, el va jugar el desmai sobtat dels empleats per la combinació de les paraules "regressió logística" i la demostració d'informes efectius sobre dades grans mitjançant, sí, sí, pyspark.
Apache Spark, el seu paradigma funcional en el qual l'àlgebra relacional s'adapta perfectament, i les seves capacitats van causar tanta impressió als desenvolupadors acostumats a MySQL que la necessitat d'enfortir els rangs amb analistes experimentats es va fer evident com el dia.
Més intents d'Apache Spark/Hadoop per enlairar i el que no va anar del tot segons el guió
Tanmateix, aviat es va fer evident que alguna cosa sistemàticament no anava bé amb Spark, o simplement era necessari rentar-se millor les mans. Si la pila Hadoop/MapReduce/Lucene va ser feta per programadors bastant experimentats, la qual cosa és obvi si observeu de prop el codi font a Java o les idees de Doug Cutting a Lucene, aleshores Spark, de sobte, està escrit en el llenguatge exòtic Scala, que és molt controvertit des del punt de vista pràctic i actualment no es desenvolupa. I la caiguda regular dels càlculs al clúster Spark a causa d'un treball il·lògic i poc transparent amb l'assignació de memòria per a operacions de reducció (moltes claus arriben alhora) ha creat un halo al voltant d'alguna cosa que té espai per créixer. A més, la situació es va veure agreujada per un gran nombre de ports oberts estranys, fitxers temporals que creixien als llocs més incomprensibles i un infern de dependències jar - que va fer que els administradors del sistema tinguessin una sensació que era ben coneguda des de la infància: un odi ferotge (o potser necessitaven rentar-se les mans amb sabó).
Com a resultat, hem "sobreviscut" a diversos projectes analítics interns que utilitzen activament Apache Spark (incloent-hi Spark Streaming, Spark SQL) i l'ecosistema Hadoop (i així successivament). Tot i que amb el pas del temps vam aprendre a preparar-lo i controlar-lo bastant bé, i pràcticament va deixar de fallar de sobte a causa dels canvis en la naturalesa de les dades i el desequilibri del hashing RDD uniforme, el desig de prendre alguna cosa ja a punt. , actualitzat i administrat en algun lloc del núvol es va fer cada cop més fort. Va ser en aquest moment quan vam intentar utilitzar el conjunt de núvols preparat d'Amazon Web Services: i, posteriorment, va intentar resoldre problemes utilitzant-lo. EMR és Apache Spark preparat per Amazon amb programari addicional de l'ecosistema, igual que les compilacions de Cloudera/Hortonworks.
L'emmagatzematge d'arxius de goma per a l'anàlisi és una necessitat urgent
L'experiència de "cuinar" Hadoop/Spark amb cremades a diverses parts del cos no va ser en va. La necessitat de crear un únic emmagatzematge de fitxers, econòmic i fiable, que fos resistent a les fallades del maquinari i en el qual fos possible emmagatzemar fitxers en diferents formats de diferents sistemes i fer mostres eficients i eficients en temps per als informes d'aquestes dades es va fer cada cop més gran. clar.
També volia que l'actualització del programari d'aquesta plataforma no es convertís en un malson d'Any Nou amb la lectura de traces Java de 20 pàgines i l'anàlisi de registres detallats de quilòmetres de llargada del clúster mitjançant Spark History Server i una lupa retroil·luminada. Volia tenir una eina senzilla i transparent que no requereixi cap busseig regular sota el capó si la sol·licitud estàndard de MapReduce del desenvolupador es va deixar d'executar quan el treballador de dades de reducció es va quedar sense memòria a causa d'un algorisme de partició de dades d'origen no molt ben triat.
Amazon S3 és un candidat per a DataLake?
L'experiència amb Hadoop/MapReduce ens va ensenyar que necessitem un sistema de fitxers escalable i fiable i treballadors escalables a sobre, "apropant-nos" a les dades per no conduir les dades a la xarxa. Els treballadors haurien de poder llegir dades en diferents formats, però preferiblement no llegir informació innecessària i poder emmagatzemar dades amb antelació en formats convenients per als treballadors.
Un cop més, la idea bàsica. No hi ha cap voluntat d'"abocar" grans dades en un únic motor analític de clúster, que tard o d'hora s'asfixirà i l'haureu de trencar lleig. Vull emmagatzemar fitxers, només fitxers, en un format entenedor i realitzar consultes analítiques efectives amb eines diferents però comprensibles. I cada cop hi haurà més fitxers en diferents formats. I és millor fragmentar no el motor, sinó les dades font. Necessitem un DataLake extensible i universal, vam decidir...
Què passa si emmagatzemeu fitxers al conegut i conegut emmagatzematge escalable en núvol Amazon S3, sense haver de preparar les vostres pròpies costelles d'Hadoop?
Està clar que les dades personals són "basses", però què passa amb les altres dades si les traiem i les "impulsem amb eficàcia"?
Ecosistema d'anàlisi de clúster-bigdata d'Amazon Web Services, en paraules molt senzilles
A jutjar per la nostra experiència amb AWS, Apache Hadoop/MapReduce s'hi fa servir activament durant molt de temps sota diverses salses, per exemple al servei DataPipeline (envejo els meus companys, van aprendre a preparar-lo correctament). Aquí configurem còpies de seguretat de diferents serveis de taules DynamoDB:
I fa uns quants anys que s'executen regularment en clústers Hadoop/MapReduce integrats com un rellotge. "Configureu-lo i oblideu-lo":
També podeu participar eficaçment en el satanisme de dades configurant ordinadors portàtils Júpiter al núvol per als analistes i utilitzant el servei AWS SageMaker per entrenar i desplegar models d'IA a la batalla. Aquí teniu el que sembla per a nosaltres:
I sí, podeu agafar un ordinador portàtil per a vosaltres mateixos o per a un analista al núvol i connectar-lo a un clúster Hadoop/Spark, fer els càlculs i després aclarir-ho tot:
Realment convenient per a projectes analítics individuals i per a alguns hem utilitzat amb èxit el servei EMR per a càlculs i anàlisis a gran escala. Què passa amb una solució de sistema per a DataLake, funcionarà? En aquest moment estàvem a punt de l'esperança i la desesperació i vam continuar la recerca.
AWS Glue: Apache Spark ben empaquetat amb esteroides
Va resultar que AWS té la seva pròpia versió de la pila "Hive/Pig/Spark". El paper de Hive, és a dir. El catàleg de fitxers i els seus tipus a DataLake el realitza el servei "Catàleg de dades", que no amaga la seva compatibilitat amb el format Apache Hive. Heu d'afegir informació a aquest servei sobre on es troben els vostres fitxers i en quin format són. Les dades poden estar no només a s3, sinó també a la base de dades, però aquest no és el tema d'aquesta publicació. Així és com s'organitza el nostre directori de dades de DataLake:
Els fitxers estan registrats, genial. Si els fitxers s'han actualitzat, iniciem rastrejadors manualment o segons una programació, que actualitzaran la informació sobre ells des del llac i els desaran. Aleshores, les dades del llac es poden processar i els resultats es poden penjar en algun lloc. En el cas més senzill, també pengem a s3. El processament de dades es pot fer a qualsevol lloc, però es recomana que configureu el processament en un clúster d'Apache Spark mitjançant capacitats avançades mitjançant l'API d'AWS Glue. De fet, podeu agafar el codi python vell i conegut utilitzant la biblioteca pyspark i configurar la seva execució en N nodes d'un clúster d'una certa capacitat amb monitorització, sense cavar en les entranyes d'Hadoop i arrossegar contenidors docker-moker i eliminar els conflictes de dependència. .
Un cop més, una idea senzilla. No cal configurar Apache Spark, només cal escriure codi python per a pyspark, provar-lo localment a l'escriptori i executar-lo en un gran clúster al núvol, especificant on es troben les dades font i on posar el resultat. De vegades això és necessari i útil, i així és com ho configurem:
Per tant, si necessiteu calcular alguna cosa en un clúster Spark utilitzant dades a s3, escrivim codi a python/pyspark, ho provem i molta sort al núvol.
Què passa amb l'orquestració? I si la tasca caigués i desaparegués? Sí, es proposa fer un pipeline bonic a l'estil Apache Pig i fins i tot els vam provar, però de moment vam decidir utilitzar la nostra orquestració profundament personalitzada en PHP i JavaScript (entenc, hi ha dissonància cognitiva, però funciona, per anys i sense errors).
El format dels fitxers emmagatzemats al llac és la clau del rendiment
És molt, molt important entendre dos punts clau més. Per tal que les consultes sobre dades dels fitxers del llac s'executin tan ràpidament com sigui possible i el rendiment no es degradi quan s'afegeix informació nova, cal que:
- Emmagatzemeu columnes de fitxers per separat (de manera que no hàgiu de llegir totes les línies per entendre què hi ha a les columnes). Per a això vam agafar el format de parquet amb compressió
- És molt important dividir els fitxers en carpetes com: idioma, any, mes, dia, setmana. Els motors que entenguin aquest tipus de fragmentació només miraran les carpetes necessàries, sense tamisar totes les dades seguides.
Essencialment, d'aquesta manera, distribuïu les dades d'origen de la forma més eficient per als motors analítics penjats a la part superior, que fins i tot en carpetes fragmentades poden introduir i llegir de manera selectiva només les columnes necessàries dels fitxers. No cal que "ompliu" les dades enlloc (l'emmagatzematge simplement esclatarà); només cal que poseu-les immediatament al sistema de fitxers en el format correcte. Per descomptat, aquí hauria de quedar clar que emmagatzemar un fitxer csv enorme a DataLake, que primer ha de ser llegit línia per línia pel clúster per extreure les columnes, no és gaire aconsellable. Torna a pensar en els dos punts anteriors si encara no està clar per què passa tot això.
AWS Athena: el connector a la caixa
I aleshores, mentre creàvem un llac, d'alguna manera ens vam trobar accidentalment amb Amazon Athena. De sobte, va resultar que organitzant amb cura els nostres grans fitxers de registre en fragments de carpetes en el format de columna correcte (parquet), podeu fer-ne seleccions molt informatives i crear informes SENSE, sense un clúster Apache Spark/Glue.
El motor Athena alimentat per dades a s3 es basa en el llegendari - un representant de la família d'enfocaments MPP (processament paral·lel massiu) del processament de dades, prenent les dades on es troben, des de s3 i Hadoop fins a Cassandra i fitxers de text ordinaris. Només heu de demanar a l'Athena que executi una consulta SQL i, a continuació, tot "funciona ràpidament i automàticament". És important tenir en compte que Athena és "intel·ligent", només va a les carpetes fragmentades necessàries i només llegeix les columnes necessàries a la sol·licitud.
El preu de les sol·licituds a Athena també és interessant. Paguem . Aquells. no pel nombre de màquines del clúster per minut, sinó... per a les dades realment escanejades en 100-500 màquines, només les dades necessàries per completar la sol·licitud.
I en sol·licitar només les columnes necessàries de carpetes fragmentades correctament, va resultar que el servei Athena ens costa desenes de dòlars al mes. Bé, genial, gairebé gratuït, en comparació amb l'anàlisi dels clústers!
Per cert, així és com repartim les nostres dades a s3:
Com a resultat, en poc temps, departaments completament diferents de l'empresa, des de la seguretat de la informació fins a l'anàlisi, van començar a fer sol·licituds activament a Athena i ràpidament, en segons, a rebre respostes útils de dades "grans" durant períodes força llargs: mesos, mig any, etc. P.
Però vam anar més enllà i vam començar a anar al núvol per buscar respostes : un analista escriu una consulta SQL en una consola familiar, que en 100-500 màquines "per cèntims" envia dades a s3 i retorna una resposta normalment en pocs segons. Còmode. I ràpid. Encara no m'ho puc creure.
Com a resultat, després d'haver decidit emmagatzemar dades en s3, en un format de columna eficaç i amb una fragmentació raonable de dades en carpetes... vam rebre DataLake i un motor analític ràpid i barat, de forma gratuïta. I es va fer molt popular a l'empresa, perquè... entén SQL i funciona ordres de magnitud més ràpidament que mitjançant l'inici/aturada/configuració de clústers. "I si el resultat és el mateix, per què pagar més?"
Una sol·licitud a Athena sembla una cosa així. Si voleu, és clar, podeu formar-ne prou , però ens limitarem a una simple agrupació. Vegem quins codis de resposta tenia el client fa unes setmanes als registres del servidor web i assegureu-vos que no hi hagi errors:
Troballes
Després d'haver recorregut, per no dir un camí llarg, però dolorós, avaluant constantment de manera adequada els riscos i el nivell de complexitat i el cost del suport, hem trobat una solució per a DataLake i analítiques que no deixa de agradar-nos tant amb la velocitat com pel cost de propietat.
Va resultar que construir un DataLake eficaç, ràpid i barat d'operar per a les necessitats de departaments completament diferents de l'empresa està totalment dins de les capacitats de desenvolupadors experimentats que mai han treballat com a arquitectes i no saben com dibuixar quadrats en quadrats amb fletxes i coneix 50 termes de l'ecosistema Hadoop.
Al principi del viatge, el meu cap es separava dels molts zoològics salvatges de programari obert i tancat i la comprensió de la càrrega de responsabilitat dels descendents. Només heu de començar a construir el vostre DataLake a partir d'eines senzilles: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., recopilant comentaris i comprenent profundament la física dels processos que tenen lloc. Tot complex i tèrbol: doneu-ho als enemics i competidors.
Si no voleu anar al núvol i us agrada donar suport, actualitzar i aplicar pedaços a projectes de codi obert, podeu crear un esquema similar al nostre localment, en màquines d'oficina econòmiques amb Hadoop i Presto a la part superior. El més important és no aturar-se i avançar, comptar, buscar solucions senzilles i clares, i definitivament tot sortirà! Molta sort a tothom i ens veiem de nou!
Font: www.habr.com