Viviamo in un'epoca straordinaria in cui è possibile collegare rapidamente e facilmente diversi strumenti open source pronti, configurarli con una 'mente spenta' seguendo i consigli di Stack Overflow, senza addentrarsi nei 'mille termini', e avviarli in produzione. E quando sarà necessario aggiornarsi/espandersi o qualcuno riavvierà per caso un paio di macchine, ci si accorgerà che ha iniziato un incubo ossessivo, la situazione è diventata troppo complessa per essere riconosciuta, non c'è via di ritorno, il futuro è nebuloso e, invece di programmare, è meglio dedicarsi all'apicoltura e alla produzione di formaggio.
Non è forse un caso che i colleghi più esperti, con capelli bianchi punteggiati da bug, osservando il dispiegamento incredibilmente rapido di pacchetti di 'container' in 'cubi' su decine di server con 'linguaggi trendy' dotati di supporto incorporato per input/output asincroni e non bloccanti, sorridano modestamente. E continuano silenziosamente a leggere 'man ps', immergendosi fino a sanguinare dagli occhi nei sorgenti di 'nginx' e a scrivere-scrivere-scrivere test unitari. I colleghi sanno che il meglio deve ancora venire, quando 'tutto questo' un giorno diventerà un incubo colossale sotto il Natale. E solo una profonda comprensione della natura unix, delle tabelle di stato TCP/IP e degli algoritmi di ricerca e ordinamento di base li aiuterà a riportare il sistema in vita al rintocco della mezzanotte.
Ah già, mi sono un po' distratto, ma spero di aver trasmesso lo stato di anticipazione.
Oggi voglio condividere la nostra esperienza nel dispiegare un stack conveniente e pratico per DataLake, in grado di risolvere la maggior parte delle esigenze analitiche dell'azienda per i più diversi reparti.
Tempo fa siamo arrivati alla consapevolezza che le aziende necessitano sempre di più dei frutti dell'analisi sia di prodotto che tecnica (senza contare le 'ciliegine sulla torta' come il machine learning) e per comprendere tendenze e rischi è necessario raccogliere e analizzare sempre più metriche.
Analisi tecnica di base in 'Bitrix24'
Qualche anno fa, insieme al lancio del servizio «Bitrix24», abbiamo investito attivamente tempo e risorse nella creazione di una piattaforma analitica semplice e affidabile, che ci aiutasse a vedere rapidamente i problemi nell'infrastruttura e a pianificare il passo successivo. Ovviamente, era preferibile utilizzare strumenti pronti e il più semplici e comprensibili possibile. Di conseguenza, abbiamo scelto nagios per il monitoraggio e munin per l'analitica e la visualizzazione. Ora abbiamo migliaia di controlli in nagios, centinaia di grafici in munin e i colleghi li utilizzano con successo ogni giorno. Le metriche sono chiare, i grafici sono comprensibili, il sistema funziona in modo affidabile da diversi anni e vengono regolarmente aggiunti nuovi test e grafici: quando introduciamo un nuovo servizio in produzione, aggiungiamo alcuni test e grafici. Buon lavoro.
La mano sul polso — analisi tecnica avanzata
Il desiderio di ricevere informazioni sui problemi «il più rapidamente possibile» ci ha portati a esperimenti attivi con strumenti semplici e comprensibili — pinba e xhprof.
Pinba ci inviava in pacchetti UDP statistiche sulla velocità di esecuzione delle parti delle pagine web in PHP, e si poteva vedere in tempo reale nel database MySQL (con pinba viene fornito un proprio motore MySQL per un'analisi rapida degli eventi) un breve elenco di problemi e reagire ad essi. E xhprof permetteva di raccogliere automaticamente i grafi di esecuzione delle pagine PHP più lente dai clienti e analizzare cosa potesse aver causato il rallentamento — tutto in tranquillità, sorseggiando un tè o qualcosa di più forte.
Un po' di tempo fa, gli strumenti sono stati ulteriormente arricchiti con un altro motore piuttosto semplice e comprensibile basato su un algoritmo di indicizzazione inversa, splendidamente realizzato nella leggendaria libreria Lucene — Elastic/Kibana. L'idea semplice di scrittura multithreading di documenti in un indice inverso Lucene basato su eventi nei log e la rapida ricerca attraverso di essi utilizzando la suddivisione in faccette si è rivelata, effettivamente, utile.
Nonostante l'aspetto piuttosto tecnico delle visualizzazioni in Kibana con concetti a basso livello come «bucket» e un linguaggio di algebra relazionale riadattato non dimenticato, lo strumento ci ha aiutato bene nelle seguenti attività:
- Quanti errori PHP ha avuto il cliente di Bitrix24 sul portale p1 nell'ultima ora e quali? Comprendere, perdonare e correggere rapidamente.
- Quanti videochiamate sono state effettuate sui portali in Germania nelle ultime 24 ore, con quale qualità e ci sono state difficoltà con il canale/rete?
- Quanto bene funziona il funzionamento del sistema (la nostra estensione in C per PHP), compilata dai sorgenti nell'ultimo aggiornamento del servizio e distribuita ai clienti? Ci sono stati segfault?
- I dati dei clienti vengono memorizzati nella memoria di PHP? Ci sono errori di superamento della memoria allocata per i processi: «out of memory»? Trova e disattiva.
Ecco un esempio concreto. Nonostante test accurati e multilivello, il cliente ha riscontrato un fastidioso e inaspettato errore in un caso molto anomalo con dati di input corrotti, è suonata la sirena e ha avuto inizio il processo di correzione rapida:
In aggiunta, Kibana consente di organizzare notifiche per eventi specificati e in breve tempo lo strumento è stato utilizzato da decine di dipendenti di diverse divisioni — dal supporto tecnico e sviluppo alla QA.
L'attività di qualsiasi divisione all'interno dell'azienda è diventata facile da monitorare e misurare — invece di un'analisi manuale dei registri sui server, è sufficiente impostare una volta il parsing dei log e il loro invio al cluster elastic per godere, ad esempio, della contemplazione nel dashboard di Kibana del numero di gattini a due teste stampati su una stampante 3D nel mese lunare passato.
Analisi aziendale di base
Tutti sanno che spesso l'analisi aziendale nelle aziende inizia con un uso estremamente attivo, sì, sì, di Excel. Ma, la cosa principale è che non finisca lì. Anche Google Analytics nel cloud contribuisce bene ad alimentare il fuoco — ci si abitua rapidamente al buono.
Nella nostra azienda in armoniosa crescita, hanno iniziato a comparire qua e là dei «profeti» di un lavoro più intenso con dati più ampi. Sono emerse regolarmente necessità di rapporti più approfonditi e multi-faccettati e grazie agli sforzi dei ragazzi di diverse divisioni è stata organizzata qualche tempo fa una soluzione semplice e pratica — l'accoppiamento di ClickHouse e PowerBI.
A lungo questa soluzione flessibile ha funzionato molto bene, ma gradualmente è emersa la consapevolezza che ClickHouse non è elastico e non si può abusare di esso.
È importante comprendere bene che ClickHouse, come Druid, Vertica e Amazon RedShift (basato su Postgres), sono motori analitici ottimizzati per un'analisi piuttosto conveniente (somme, aggregazioni, minimi e massimi per colonna e qualche join), in quanto organizzati per un'efficace memorizzazione delle colonne delle tabelle relazionali, a differenza del noto MySQL e di altri database (row-oriented).
In sostanza, ClickHouse è un «database» più capiente, con un'inserzione puntuale non molto comoda (è così deliberato, va bene), ma con un'analisi piacevole e una serie di potenti funzionalità interessanti per lavorare con i dati. Sì, è possibile creare anche un cluster, ma capite che usare un microscopio per piantare chiodi non è proprio corretto e abbiamo cominciato a cercare altre soluzioni.
Domanda di python e analisti
Nella nostra azienda ci sono molti sviluppatori che scrivono codice quasi ogni giorno da 10-20 anni in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ci sono anche molti amministratori di sistema esperti che hanno affrontato non una, ma diverse incredibili catastrofi che non rientrano nelle leggi della statistica (ad esempio, quando la maggior parte dei dischi di un raid-10 viene distrutta da un forte colpo di fulmine). In queste condizioni non è stato chiaro per molto tempo cosa fosse un «analista in python». Python è come PHP, solo che il nome è un po' più lungo e ci sono meno tracce di sostanze che alterano la mente nel codice sorgente dell'interprete. Tuttavia, con la creazione di sempre più nuovi report analitici, gli sviluppatori esperti hanno cominciato a rendersi conto dell'importanza della specializzazione in strumenti come numpy, pandas, matplotlib, seaborn.
Il ruolo decisivo è stato probabilmente giocato dagli svenimenti improvvisi dei dipendenti a causa della combinazione delle parole «regressione logistica» e dalla dimostrazione di costruzione efficace di report su dati voluminosi utilizzando, sì, pyspark.
Apache Spark, la sua paradigma funzionale, con cui l'algebra relazionale si sposa perfettamente e le sue capacità hanno impressionato così tanto gli sviluppatori abituati a MySQL, che la necessità di rinforzare le fila con analisti esperti è diventata chiara come il giorno.
I successivi tentativi di Apache Spark/Hadoop di decollare e ciò che non è andato proprio come previsto
Tuttavia, è presto diventato chiaro che con Spark c'era evidentemente qualcosa di sistemico che non andava, o forse era semplicemente necessario lavarsi meglio le mani. Sebbene il stack Hadoop/MapReduce/Lucene fosse stato realizzato da programmatori piuttosto esperti, come è evidente se si osservano con attenzione i sorgenti in Java o le idee di Doug Cutting in Lucene, Spark è stato improvvisamente scritto in un linguaggio esotico, molto controverso dal punto di vista pratico e ora non più in sviluppo, ovvero Scala. E il regolare fallimento dei calcoli nel cluster Spark a causa di una gestione poco logica e poco trasparente della memoria per le operazioni di riduzione (arrivano subito molte chiavi) ha creato attorno a lui un alone di qualcosa che ha del potenziale di crescita. Inoltre, la situazione è stata aggravata dalla presenza di un gran numero di porte aperte strane, file temporanei che crescevano nei luoghi più incomprensibili e un mare di dipendenze jar, che suscitava negli amministratori di sistema una sensazione ben nota sin dall'infanzia: un'ardente avversione (o forse era solo necessario lavarsi le mani con il sapone).
Di conseguenza, abbiamo "vissuto" diversi progetti analitici interni che utilizzavano attivamente Apache Spark (compresi Spark Streaming, Spark SQL) e l'ecosistema Hadoop (e altro, e altro). Sebbene nel tempo abbiamo imparato a "preparare" questo strumento in modo discreto e a monitorarlo, e che praticamente ha smesso di cadere improvvisamente a causa della modifica della natura dei dati e della sbilanciatura nella hash uniformemente distribuita degli RDD, il desiderio di adottare qualcosa di già pronto, aggiornato e amministrato, magari in cloud, cresceva sempre di più. Proprio in quel periodo, abbiamo provato a utilizzare una distribuzione cloud pronta di Amazon Web Services — e, successivamente, abbiamo cercato di risolvere i problemi su di essa. EMR è una versione di Apache Spark preparata da Amazon con software aggiuntivo dell'ecosistema, simile alle distribuzioni di Cloudera/Hortonworks.
Uno storage "elastic" per l'analisi — una necessità urgente
L'esperienza di "preparare" Hadoop/Spark con le scottature di varie parti del corpo non è stata vana. È diventata sempre più chiara la necessità di creare uno storage unico, economico e affidabile, che fosse resistente ai guasti hardware e in cui fosse possibile archiviare file in vari formati provenienti da diversi sistemi e effettuare selezioni su questi dati in modo efficace e in tempi ragionevoli per i report.
Si sperava anche che l'aggiornamento del software di questa piattaforma non si trasformasse in un incubo notturno di Capodanno con la lettura di stack trace Java di 20 pagine e l'analisi di chilometri di log dettagliati delle operazioni del cluster utilizzando Spark History Server e una lente di ingrandimento con illuminazione. Si desiderava avere uno strumento semplice e trasparente che non richiedesse immersioni regolari sotto il cofano, se un caricatore smettesse di eseguire una normale query MapReduce a causa di un fallimento nella memoria dei dati reduce a seguito di un algoritmo di partizionamento delle sorgenti non molto ben scelto.
Amazon S3 è un candidato per DataLake?
L'esperienza con Hadoop/MapReduce ha insegnato che serve un file system scalabile e affidabile e lavoratori scalabili che "vengono" più vicino ai dati, in modo da non dover trasferire i dati sulla rete. I worker devono essere in grado di leggere dati in diversi formati, ma idealmente non leggere informazioni superflue e consentire di memorizzare in anticipo i dati in formati convenienti per i worker.
Riassumendo - il concetto principale. Non c'è voglia di "caricare" grandi dati in un unico motore analitico clusterizzato, che comunque prima o poi affonderà e sarà necessario shardarlo in modo sgradevole. Si desidera conservare file, semplicemente file, in un formato comprensibile e eseguire su di essi richieste analitiche efficaci con strumenti diversi ma comprensibili. E i file in diversi formati saranno sempre di più. Ed è meglio shardare non il motore, ma i dati sorgenti. Abbiamo deciso che ci serve un DataLake scalabile e universale...
E se conservare i file in un archivio cloud scalabile noto a molti, Amazon S3, senza doversi occupare della preparazione di costolette da Hadoop?
Chiaro, i dati personali "non si possono", ma per altri dati se li portassi fuori e li "gireresti efficacemente"?
L'ecosistema di analisi big data clusterizzato di Amazon Web Services - in parole molto semplici
Secondo la nostra esperienza con AWS, Apache Hadoop/MapReduce è utilizzato da tempo e attivamente in diverse varianti, ad esempio nel servizio DataPipeline (invidio i colleghi, hanno davvero imparato a prepararlo correttamente). Qui abbiamo configurato backup da diversi servizi delle tabelle DynamoDB:
E vengono eseguiti regolarmente su cluster Hadoop/MapReduce come un orologio da diversi anni. "Configurato e dimenticato":
Inoltre, è possibile svolgere efficacemente il data satanismo, sollevando i notebook Jupiter nel cloud per gli analisti e utilizzarli per l'addestramento e il deploy dei modelli di IA tramite il servizio AWS SageMaker. Ecco come appare da noi:
Sì, è possibile sollevare un notebook nel cloud per se stessi o per un analista e collegarlo a un cluster Hadoop/Spark, fare i calcoli e poi "schiacciare tutto":
In effetti, è molto comodo per progetti analitici specifici e per alcuni di essi abbiamo utilizzato con successo il servizio EMR per calcoli e analisi su larga scala. E per una soluzione sistematica per DataLake, ce la faremo? In quel momento eravamo sul filo tra speranza e disperazione e continuavamo la ricerca.
AWS Glue è un Apache Spark «sottile» potenziato.
Si è scoperto che AWS ha una sua versione dello stack «Hive/Pig/Spark». Il ruolo di Hive, cioè il catalogo di file e dei loro tipi in DataLake, è svolto dal servizio «Data catalog», che non nasconde la sua compatibilità con il formato Apache Hive. In questo servizio è necessario aggiungere informazioni su dove si trovano i tuoi file e in quale formato sono. I dati possono trovarsi non solo in s3, ma anche in un database, ma non ne parleremo in questo post. Ecco come è organizzato il catalogo dati DataLake da noi:
I file sono registrati, ottimo. Se i file sono stati aggiornati, avviamo manualmente o in base a un programma i crawler, che aggiorneranno le informazioni su di essi dal lago e le salveranno. Poi, i dati dal lago possono essere elaborati e i risultati esportati in un certo luogo. Nel caso più semplice, anche noi esportiamo in s3. L'elaborazione dei dati può avvenire ovunque, ma si suggerisce di impostare il processo di elaborazione su un cluster Apache Spark utilizzando funzionalità avanzate tramite l'API AWS Glue. In sostanza, puoi prendere un vecchio e caro codice python con la libreria pyspark e configurarne l'esecuzione su N nodi di un cluster di una certa potenza con monitoraggio, senza dover frugare nelle interiora di Hadoop e spostare contenitori Docker e risolvere conflitti di dipendenze.
Ancora una volta, un'idea semplice. Non è necessario configurare Apache Spark, è sufficiente scrivere il codice python per pyspark, testarlo localmente sul desktop e poi eseguirlo su un grande cluster nel cloud, indicando dove si trovano i dati di origine e dove mettere il risultato. A volte è necessario e utile, ecco come lo impostiamo noi:
Pertanto, se è necessario eseguire qualche calcolo su un cluster Spark con dati in s3, scriviamo codice python/pyspark, testiamo e poi ci dirigiamo nel cloud.
E per quanto riguarda l'orchestrazione? E se il compito è scomparso? Sì, si propone di creare una pipeline elegante in stile Apache Pig e abbiamo anche provato a farlo, ma abbiamo deciso di continuare a utilizzare la nostra orchestrazione profondamente personalizzata in PHP e JavaScript (capisco che possa sembrare un dissonanza cognitiva, ma funziona, da anni e senza errori).
Il formato dei file memorizzati nel lago è la chiave per le prestazioni
È molto, molto importante comprendere due punti chiave. Affinché le richieste sui dati dei file nel lago vengano eseguite il più rapidamente possibile e le prestazioni non diminuiscano con l'aggiunta di nuove informazioni, è necessario:
- Conservare le colonne dei file separatamente (in modo da non dover leggere tutte le righe per capire cosa c'è nelle colonne). A tal fine, abbiamo adottato il formato parquet con compressione
- È molto importante shardare i file in cartelle secondo lo spirito: lingua, anno, mese, giorno, settimana. I motori che comprendono questo tipo di sharding considereranno solo le cartelle necessarie, senza dover setacciare tutti i dati.
In sostanza, in questo modo, esponete i dati originali nella forma più efficiente per i motori analitici superiori, che sanno anche accedere selettivamente alle cartelle shardate e leggere solo le colonne necessarie dai file. Non è necessario 'caricare' i dati ovunque (altrimenti, lo storage esploderebbe) — semplicemente posizionateli nella filesystem nel formato corretto. È ovvio che immagazzinare un enorme file csv in DataLake, che deve essere prima letto riga per riga da un cluster per estrarre le colonne, non è molto ragionevole. Riflettete ancora una volta sui due punti sopra menzionati, se non è chiaro perché tutto questo.
AWS Athena — un 'diavolo' uscito dalla scatola
E qui, creando il lago, ci siamo imbattuti, quasi per caso, in Amazon Athena. È emerso improvvisamente che, disponendo ordinatamente i nostri file di enormi log nei giusti formati colonnari (parquet) per shard e cartelle — si possono effettuare selezioni estremamente informative e costruire report MOLTO rapidamente, SENZA un cluster Apache Spark/Glue.
Il motore Athena, che opera sui dati in s3, è basato sul leggendario — rappresentante della famiglia MPP (massive parallel processing) approcci per l'elaborazione dei dati, che prende i dati dove si trovano, da s3 e Hadoop a Cassandra e normali file di testo. Basta chiedere ad Athena di eseguire una query SQL, e poi tutto «funziona velocemente e da solo». È importante notare che Athena è «intelligente», accede solo alle cartelle sharded necessarie e legge solo le colonne richieste nella query.
Le richieste ad Athena sono tariffate in modo interessante. Paghiamo per . Cioè, non per il numero di macchine nel cluster al minuto, ma... per i dati realmente scansionati su 100-500 macchine che sono necessari per eseguire la query.
E richiedendo solo le colonne necessarie dalle cartelle correttamente sharded, si è scoperto che il servizio Athena ci costa decine di dollari al mese. Insomma, fantastico, quasi gratuito, rispetto all'analisi nei cluster!
Ecco, peraltro, come shardiamo i nostri dati in s3:
Di conseguenza, in poco tempo, diverse divisioni dell'azienda, dalla sicurezza informatica all'analisi, hanno iniziato a fare richieste ad Athena e ricevere rapidamente, in pochi secondi, risposte utili dai «grandi» dati su periodi piuttosto ampi: mesi, semestri, ecc.
Ma siamo andati oltre e abbiamo iniziato a cercare risposte nel cloud : l'analista nella console abituale scrive una query SQL che in 100-500 macchine «a pochi soldi» setaccia i dati in s3 e restituisce risposte solitamente in pochi secondi. Comodo. E veloce. Ancora non ci credo.
Di conseguenza, avendo deciso di conservare i dati in s3, in un formato colonnare efficiente e con una ragionevole sharding dei dati in cartelle… abbiamo ottenuto un DataLake e un motore analitico rapido e economico — gratis. E questo è diventato molto popolare in azienda, poiché comprende SQL e funziona di gran lunga più velocemente rispetto ai lanci/arresti/impostazioni dei cluster. «E se il risultato è lo stesso, perché pagare di più?»
Una richiesta ad Athena appare più o meno così. Se desiderato, è possibile formulare una query SQL abbastanza , ma ci limiteremo a una semplice aggregazione. Vediamo quali codici di risposta aveva il cliente alcune settimane fa nei log del server web e verifichiamo che non ci siano errori:
Conclusioni
Dopo aver percorso un cammino che non si può definire lungo, ma sicuramente doloroso, valutando continuamente i rischi, il livello di complessità e il costo di mantenimento, abbiamo trovato la soluzione per DataLake e analisi che continua a sorprenderci sia per la velocità che per il costo di possesso.
Si è rivelato che costruire un DataLake efficace, veloce e poco costoso da mantenere per le esigenze di diversi reparti aziendali è assolutamente possibile anche per sviluppatori esperti che non hanno mai lavorato come architetti e non sanno disegnare quadrati su quadrati con frecce, conoscendo 50 termini dell'ecosistema Hadoop.
All'inizio del percorso, la testa scoppiava per la molteplicità di strani zoo di software aperto e chiuso e per il peso della responsabilità verso le generazioni future. Iniziate semplicemente a costruire il vostro DataLake partendo da strumenti semplici: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3…, raccogliendo feedback e comprendendo profondamente la fisica dei processi in atto. Tutto ciò che è complesso e confuso - lasciatelo ai nemici e ai concorrenti.
Se non desiderate utilizzare il cloud e amate mantenere, aggiornare e patchare progetti open source, è possibile costruire uno schema simile al nostro localmente, su semplici macchine da ufficio con Hadoop e Presto. L'importante è non fermarsi e andare avanti, contare, cercare soluzioni semplici e chiare e tutto funzionerà sicuramente! Buona fortuna a tutti e a presto!
Fonte: habr.com
