Viviamo in un'epoca straordinaria in cui puoi collegare rapidamente e facilmente diversi strumenti open source già pronti, configurarli con la tua "coscienza disattivata" secondo i consigli di StackOverflow, senza approfondire le "lettere multiple" e avviare in operazioni commerciali. E quando hai bisogno di aggiornare/espandere o qualcuno riavvia accidentalmente un paio di macchine, ti rendi conto che è iniziata una sorta di brutto sogno ossessivo, tutto è diventato drammaticamente complicato al di là di ogni riconoscimento, non si può tornare indietro, il futuro è vago e più sicuro, invece di programmare, alleviamo api e produciamo formaggio.
Non per niente i colleghi più esperti, con la testa piena di bug e quindi già grigi, contemplando l'implementazione incredibilmente veloce di pacchetti di "contenitori" in "cubi" su dozzine di server in "linguaggi alla moda" con supporto integrato per I/O asincrono non bloccante, sorridi modestamente. E continuano silenziosamente a rileggere "man ps", ad approfondire il codice sorgente "nginx" finché i loro occhi non sanguinano e a scrivere, scrivere, scrivere test unitari. I colleghi sanno che la cosa più interessante arriverà quando “tutto questo” un giorno verrà messo in gioco la notte di Capodanno. E saranno aiutati solo da una profonda comprensione della natura di Unix, della tabella di stato TCP/IP memorizzata e degli algoritmi di ricerca di ordinamento di base. Per riportare in vita il sistema mentre suonano i rintocchi.
Oh sì, mi sono distratto un po', ma spero di essere riuscito a trasmettere lo stato di attesa.
Oggi voglio condividere la nostra esperienza nell'implementazione di uno stack conveniente ed economico per DataLake, che risolve la maggior parte dei compiti analitici in azienda per divisioni strutturali completamente diverse.
Qualche tempo fa siamo giunti alla conclusione che le aziende hanno sempre più bisogno dei frutti dell’analisi tecnica e di prodotto (per non parlare della ciliegina sulla torta sotto forma di machine learning) e che per comprendere tendenze e rischi dobbiamo raccogliere e analizzare sempre più parametri.
Analisi tecnica di base in Bitrix24
Diversi anni fa, contemporaneamente al lancio del servizio Bitrix24, abbiamo investito attivamente tempo e risorse nella creazione di una piattaforma analitica semplice e affidabile che aiutasse a individuare rapidamente i problemi nell'infrastruttura e a pianificare il passo successivo. Naturalmente, era consigliabile prendere strumenti già pronti che fossero il più semplici e comprensibili possibile. Di conseguenza, è stato scelto nagios per il monitoraggio e munin per l'analisi e la visualizzazione. Ora abbiamo migliaia di assegni in nagios, centinaia di carte in munin e i nostri colleghi li usano con successo ogni giorno. Le metriche sono chiare, i grafici sono chiari, il sistema funziona in modo affidabile da diversi anni e nuovi test e grafici vengono regolarmente aggiunti: quando mettiamo in funzione un nuovo servizio, aggiungiamo diversi test e grafici. Buona fortuna.
Il dito sul polso - Analisi tecnica avanzata
Il desiderio di ricevere informazioni sui problemi “il più rapidamente possibile” ci ha portato a esperimenti attivi con strumenti semplici e comprensibili: pinba e xhprof.
Pinba ci ha inviato statistiche in pacchetti UDP sulla velocità di funzionamento di parti di pagine Web in PHP e abbiamo potuto vedere online nell'archivio MySQL (Pinba è dotato del proprio motore MySQL per l'analisi rapida degli eventi) un breve elenco di problemi e rispondere a loro. E xhprof ci ha permesso automaticamente di raccogliere grafici dell'esecuzione delle pagine PHP più lente dai client e analizzare cosa potrebbe portare a questo: con calma, versando il tè o qualcosa di più forte.
Qualche tempo fa, il toolkit è stato reintegrato con un altro motore abbastanza semplice e comprensibile basato sull'algoritmo di indicizzazione inversa, perfettamente implementato nella leggendaria libreria Lucene: Elastic/Kibana. La semplice idea di registrare documenti multi-thread in un indice Lucene inverso basato sugli eventi nei registri e una rapida ricerca al loro interno utilizzando la divisione delle faccette si è rivelata davvero utile.
Nonostante l’aspetto piuttosto tecnico delle visualizzazioni in Kibana con concetti di basso livello come “secchio” “che scorre verso l’alto” e il linguaggio reinventato dell’algebra relazionale non ancora completamente dimenticata, lo strumento ha iniziato ad aiutarci bene nei seguenti compiti:
- Quanti errori PHP ha riscontrato il client Bitrix24 sul portale p1 nell'ultima ora e quali? Comprendi, perdona e correggi rapidamente.
- Quante videochiamate sono state effettuate sui portali in Germania nelle 24 ore precedenti, con quale qualità e ci sono state difficoltà con il canale/rete?
- Come funziona la funzionalità di sistema (la nostra estensione C per PHP), compilata dal sorgente nell'ultimo aggiornamento del servizio e distribuita ai client? Ci sono segfault?
- I dati dei clienti rientrano nella memoria PHP? Ci sono errori relativi al superamento della memoria allocata ai processi: "memoria esaurita"? Trova e neutralizza.
Ecco un esempio concreto. Nonostante test approfonditi e multi-livello, il cliente, con un case molto non standard e dati di input danneggiati, ha ricevuto un errore fastidioso e inaspettato, è suonata una sirena ed è iniziato il processo di risoluzione rapida del problema:
Inoltre, Kibana consente di organizzare notifiche per eventi specifici e in breve tempo lo strumento in azienda ha iniziato a essere utilizzato da decine di dipendenti di diversi dipartimenti, dal supporto tecnico e sviluppo al controllo qualità.
L'attività di qualsiasi reparto all'interno dell'azienda è diventata conveniente da monitorare e misurare: invece di analizzare manualmente i log sui server, è sufficiente impostare una volta l'analisi dei log e inviarli al cluster elastico per divertirsi, ad esempio, contemplando nella kibana dashboard il numero di gattini a due teste venduti stampati su stampante 3D nell'ultimo mese lunare.
Analisi aziendale di base
Tutti sanno che l'analisi aziendale nelle aziende spesso inizia con un uso estremamente attivo, sì, di Excel. Ma la cosa principale è che non finisce qui. Anche Google Analytics basato su cloud aggiunge benzina sul fuoco: inizi rapidamente ad abituarti alle cose buone.
Nella nostra azienda in via di sviluppo armonioso, qua e là cominciarono ad apparire "profeti" di un lavoro più intenso con dati più grandi. La necessità di report più approfonditi e sfaccettati ha cominciato ad apparire regolarmente e, grazie agli sforzi di ragazzi di diversi dipartimenti, qualche tempo fa è stata organizzata una soluzione semplice e pratica: una combinazione di ClickHouse e PowerBI.
Per molto tempo, questa soluzione flessibile ha aiutato molto, ma gradualmente è iniziata a capire che ClickHouse non è di gomma e non può essere deriso in quel modo.
Qui è importante capire bene che ClickHouse, come Druid, come Vertica, come Amazon RedShift (che è basato su postgres), sono motori analitici ottimizzati per analisi abbastanza convenienti (somme, aggregazioni, minimo-massimo per colonna e alcuni possibili join ), Perché organizzato per l'archiviazione efficiente di colonne di tabelle relazionali, a differenza di MySQL e di altri database (orientati alle righe) a noi noti.
In sostanza, ClickHouse è solo un "database" più capiente, con un inserimento punto per punto non molto conveniente (è così che è previsto, va tutto bene), ma analisi piacevoli e una serie di interessanti e potenti funzioni per lavorare con i dati. Sì, puoi persino creare un grappolo, ma capisci che martellare i chiodi con un microscopio non è del tutto corretto e abbiamo iniziato a cercare altre soluzioni.
Domanda di Python e analisti
La nostra azienda ha 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 vissuto più di un disastro assolutamente incredibile che non rientra nelle leggi della statistica (ad esempio, quando la maggior parte dei dischi in un raid-10 viene distrutta da un forte fulmine). In tali circostanze, per molto tempo non è stato chiaro cosa fosse un “analista pitone”. Python è come PHP, solo il nome è un po’ più lungo e ci sono un po’ meno tracce di sostanze che alterano la mente nel codice sorgente dell’interprete. Tuttavia, man mano che venivano creati sempre più report analitici, gli sviluppatori esperti iniziarono a comprendere sempre più l'importanza di una specializzazione ristretta in strumenti come Numpy, Pandas, matplotlib e Seaborn.
Il ruolo decisivo, molto probabilmente, è stato giocato dall'improvviso svenimento dei dipendenti a causa della combinazione delle parole "regressione logistica" e della dimostrazione di un reporting efficace su dati di grandi dimensioni utilizzando, sì, sì, pyspark.
Apache Spark, il suo paradigma funzionale su cui si adatta perfettamente l'algebra relazionale e le sue capacità hanno impressionato così tanto gli sviluppatori abituati a MySQL che la necessità di rafforzare i ranghi con analisti esperti è diventata chiara come il giorno.
Ulteriori tentativi di Apache Spark/Hadoop di decollare e ciò non è andato del tutto secondo il copione
Tuttavia, divenne presto chiaro che qualcosa non andava a livello sistemico in Spark, o che era semplicemente necessario lavarsi meglio le mani. Se lo stack Hadoop/MapReduce/Lucene è stato realizzato da programmatori abbastanza esperti, il che è ovvio se si osserva attentamente il codice sorgente in Java o le idee di Doug Cutting in Lucene, allora Spark, all'improvviso, è scritto nell'esotico linguaggio Scala, che è molto controverso dal punto di vista pratico e attualmente non si sta sviluppando. E il calo regolare dei calcoli sul cluster Spark dovuto a un lavoro illogico e poco trasparente con l'allocazione della memoria per le operazioni di riduzione (molte chiavi arrivano contemporaneamente) ha creato attorno a sé un alone di qualcosa che ha spazio per crescere. Inoltre, la situazione era aggravata da un gran numero di strane porte aperte, file temporanei che crescevano nei posti più incomprensibili e un'infinità di dipendenze jar - che facevano sì che gli amministratori di sistema provassero una sensazione ben nota fin dall'infanzia: odio feroce (o forse avevano bisogno di lavarsi le mani con il sapone).
Di conseguenza, siamo “sopravvissuti” a diversi progetti analitici interni che utilizzano attivamente Apache Spark (inclusi Spark Streaming, Spark SQL) e l’ecosistema Hadoop (e così via). Nonostante il fatto che col tempo abbiamo imparato a prepararlo e monitorarlo abbastanza bene, e che "esso" abbia praticamente smesso di bloccarsi all'improvviso a causa dei cambiamenti nella natura dei dati e dello squilibrio dell'hashing RDD uniforme, il desiderio di prendere qualcosa di già pronto , aggiornato e amministrato da qualche parte nel cloud è diventato sempre più forte. È stato in questo momento che abbiamo provato a utilizzare l'assemblaggio cloud già pronto di Amazon Web Services: e, successivamente, ha provato a risolvere i problemi utilizzandolo. EMR è Apache Spark preparato da Amazon con software aggiuntivo dall'ecosistema, proprio come le build Cloudera/Hortonworks.
L'archiviazione di file in gomma per l'analisi è un'esigenza urgente
L'esperienza di "cucinare" Hadoop/Spark bruciando varie parti del corpo non è stata vana. La necessità di creare un unico archivio di file, poco costoso e affidabile, che fosse resistente ai guasti hardware e in cui fosse possibile archiviare file in diversi formati da diversi sistemi e creare campioni efficienti ed efficienti in termini di tempo per i report da questi dati è diventata sempre più crescente chiaro.
Volevo anche che l'aggiornamento del software di questa piattaforma non si trasformasse in un incubo di Capodanno con la lettura di tracce Java di 20 pagine e l'analisi di registri dettagliati del cluster lunghi chilometri utilizzando Spark History Server e una lente di ingrandimento retroilluminata. Volevo avere uno strumento semplice e trasparente che non richiedesse un'analisi regolare dei dettagli nel caso in cui la richiesta MapReduce standard dello sviluppatore interrompesse l'esecuzione quando il lavoratore dei dati di riduzione perdeva memoria a causa di un algoritmo di partizionamento dei dati di origine non molto ben scelto.
Amazon S3 è un candidato per DataLake?
L'esperienza con Hadoop/MapReduce ci ha insegnato che abbiamo bisogno di un file system scalabile e affidabile e di lavoratori scalabili sopra di esso, che "si avvicinino" ai dati in modo da non trasportare i dati sulla rete. I lavoratori dovrebbero essere in grado di leggere i dati in diversi formati, ma preferibilmente non leggere informazioni non necessarie ed essere in grado di archiviare i dati in anticipo in formati convenienti per i lavoratori.
Ancora una volta, l'idea di base. Non c'è alcun desiderio di "versare" big data in un unico motore analitico a cluster, che prima o poi si soffocherà e dovrai frammentarlo in modo brutto. Voglio archiviare file, solo file, in un formato comprensibile ed eseguire query analitiche efficaci su di essi utilizzando strumenti diversi ma comprensibili. E ci saranno sempre più file in diversi formati. Ed è meglio frammentare non il motore, ma i dati di origine. Abbiamo bisogno di un DataLake estensibile e universale, abbiamo deciso...
E se archiviassi i file nel familiare e noto cloud storage scalabile Amazon S3, senza dover preparare i tuoi pezzi da Hadoop?
È chiaro che i dati personali sono “bassi”, ma che dire degli altri dati se li rendiamo disponibili e li “gestiamo in modo efficace”?
Ecosistema di analisi cluster-bigdata di Amazon Web Services: in parole molto semplici
A giudicare dalla nostra esperienza con AWS, Apache Hadoop/MapReduce lì viene utilizzato attivamente da molto tempo sotto varie salse, ad esempio nel servizio DataPipeline (invidio i miei colleghi, hanno imparato a prepararlo correttamente). Qui configuriamo i backup da diversi servizi dalle tabelle DynamoDB:
E funzionano regolarmente su cluster Hadoop/MapReduce integrati ormai da diversi anni. “Impostalo e dimenticalo”:
Puoi anche impegnarti efficacemente nel satanismo dei dati configurando i laptop Jupiter nel cloud per gli analisti e utilizzando il servizio AWS SageMaker per addestrare e distribuire modelli di intelligenza artificiale in battaglia. Ecco come appare per noi:
E sì, puoi prendere un laptop per te o per un analista nel cloud e collegarlo a un cluster Hadoop/Spark, fare i calcoli e poi fissare tutto:
Davvero conveniente per progetti analitici individuali e per alcuni abbiamo utilizzato con successo il servizio EMR per calcoli e analisi su larga scala. Che ne dici di una soluzione di sistema per DataLake, funzionerà? In questo momento eravamo sull'orlo della speranza e della disperazione e abbiamo continuato la ricerca.
AWS Glue: Apache Spark ben confezionato con steroidi
Si è scoperto che AWS ha la propria versione dello stack "Hive/Pig/Spark". Il ruolo di Hive, ad es. Il catalogo dei file e delle loro tipologie in DataLake viene effettuato dal servizio “Catalogo dati”, che non nasconde la sua compatibilità con il formato Apache Hive. Devi aggiungere informazioni a questo servizio su dove si trovano i tuoi file e in quale formato sono. I dati possono trovarsi non solo in s3, ma anche nel database, ma questo non è l'oggetto di questo post. Ecco come è organizzata la nostra directory dei dati DataLake:
I file sono registrati, fantastico. Se i file sono stati aggiornati, lanciamo i crawler manualmente o secondo una pianificazione, che aggiorneranno le informazioni su di essi dal lago e li salveranno. Quindi i dati del lago possono essere elaborati e i risultati caricati da qualche parte. Nel caso più semplice, carichiamo anche su s3. L'elaborazione dei dati può essere eseguita ovunque, ma si consiglia di configurare l'elaborazione su un cluster Apache Spark utilizzando funzionalità avanzate tramite l'API AWS Glue. In effetti, puoi prendere il buon vecchio e familiare codice Python utilizzando la libreria pyspark e configurarne l'esecuzione su N nodi di un cluster di una certa capacità con monitoraggio, senza scavare nelle viscere di Hadoop e trascinare contenitori docker-moker ed eliminare i conflitti di dipendenza .
Ancora una volta, un'idea semplice. Non è necessario configurare Apache Spark, basta scrivere il codice Python per pyspark, testarlo localmente sul desktop e quindi eseguirlo su un cluster di grandi dimensioni nel cloud, specificando dove si trovano i dati di origine e dove inserire il risultato. A volte questo è necessario e utile, ed ecco come lo configuriamo:
Pertanto, se devi calcolare qualcosa su un cluster Spark utilizzando i dati in s3, scriviamo il codice in python/pyspark, lo testiamo e buona fortuna al cloud.
E l'orchestrazione? Cosa succederebbe se l'attività cadesse e scomparisse? Sì, si propone di realizzare una bellissima pipeline in stile Apache Pig e le abbiamo anche provate, ma per ora abbiamo deciso di utilizzare la nostra orchestrazione profondamente personalizzata in PHP e JavaScript (capisco, c'è dissonanza cognitiva, ma funziona, per anni e senza errori).
Il formato dei file archiviati nel Lake è fondamentale per le prestazioni
È molto, molto importante comprendere altri due punti chiave. Affinché le query sui dati dei file nel Lake vengano eseguite il più rapidamente possibile e le prestazioni non diminuiscano quando vengono aggiunte nuove informazioni, è necessario:
- Memorizza le colonne dei file separatamente (in modo da non dover leggere tutte le righe per capire cosa c'è nelle colonne). Per questo abbiamo preso il formato del parquet con compressione
- È molto importante suddividere i file in cartelle come: lingua, anno, mese, giorno, settimana. I motori che comprendono questo tipo di sharding esamineranno solo le cartelle necessarie, senza vagliare tutti i dati di seguito.
In sostanza, in questo modo si dispongono i dati di origine nella forma più efficiente per i motori analitici appesi in alto, che anche nelle cartelle frammentate possono inserire e leggere selettivamente solo le colonne necessarie dai file. Non è necessario "riempire" i dati da nessuna parte (lo spazio di archiviazione semplicemente esploderà): inseriscili immediatamente e saggiamente nel file system nel formato corretto. Naturalmente dovrebbe essere chiaro che archiviare in DataLake un enorme file CSV, che deve prima essere letto riga per riga dal cluster per estrarre le colonne, non è molto consigliabile. Ripensa ai due punti precedenti se non è ancora chiaro il motivo per cui tutto ciò sta accadendo.
AWS Athena: il jack-in-the-box
E poi, mentre creavamo un lago, in qualche modo ci siamo imbattuti per caso in Amazon Athena. All'improvviso si è scoperto che organizzando attentamente i nostri enormi file di registro in frammenti di cartelle nel formato di colonna corretto (parquet), è possibile effettuare molto rapidamente selezioni estremamente informative da essi e creare report SENZA, senza un cluster Apache Spark/Glue.
Il motore Athena alimentato dai dati in s3 è basato sul leggendario - un rappresentante della famiglia di approcci MPP (elaborazione parallela di massa) all'elaborazione dei dati, portando i dati dove si trovano, da s3 e Hadoop a Cassandra e normali file di testo. Devi solo chiedere ad Athena di eseguire una query SQL e poi tutto “funziona in modo rapido e automatico”. È importante notare che Athena è “intelligente”, va solo nelle cartelle condivise necessarie e legge solo le colonne necessarie nella richiesta.
Interessante anche il prezzo per le richieste ad Athena. Paghiamo noi . Quelli. non per il numero di macchine nel cluster al minuto, ma... per i dati effettivamente scansionati su 100-500 macchine, solo i dati necessari per completare la richiesta.
E richiedendo solo le colonne necessarie da cartelle suddivise correttamente, si è scoperto che il servizio Athena ci costa decine di dollari al mese. Bene, fantastico, quasi gratuito, rispetto all'analisi sui cluster!
A proposito, ecco come partizioniamo i nostri dati in s3:
Di conseguenza, in breve tempo, reparti completamente diversi dell'azienda, dalla sicurezza delle informazioni all'analisi, hanno iniziato a presentare attivamente richieste ad Athena e rapidamente, in pochi secondi, a ricevere risposte utili dai "big" data per periodi abbastanza lunghi: mesi, sei mesi, ecc. P.
Ma siamo andati oltre e abbiamo iniziato a cercare risposte nel cloud : un analista scrive una query SQL in una console familiare, che su 100-500 macchine “per pochi centesimi” invia dati a s3 e restituisce una risposta solitamente in pochi secondi. Comodo. E veloce. Non riesco ancora a crederci.
Di conseguenza, avendo deciso di archiviare i dati in s3, in un efficiente formato a colonne e con una ragionevole suddivisione dei dati in cartelle... abbiamo ricevuto DataLake e un motore analitico veloce ed economico - gratuitamente. Ed è diventato molto popolare nella compagnia, perché... comprende SQL e funziona con ordini di grandezza più veloci rispetto all'avvio/arresto/configurazione dei cluster. “E se il risultato è lo stesso, perché pagare di più?”
Una richiesta ad Atena assomiglia a questa. Se lo desideri, ovviamente, puoi formarne abbastanza , ma ci limiteremo al semplice raggruppamento. Vediamo quali codici di risposta ha avuto il cliente qualche settimana fa nei log del server web e assicuriamoci che non ci siano errori:
risultati
Dopo aver attraversato, per non dire un percorso lungo, ma doloroso, valutando costantemente adeguatamente i rischi, il livello di complessità e i costi di supporto, abbiamo trovato una soluzione per DataLake e analisi che non smette mai di soddisfarci sia in termini di velocità che di costi di proprietà.
Si è scoperto che costruire un DataLake efficace, veloce ed economico per le esigenze di reparti completamente diversi dell'azienda è completamente alla portata anche di sviluppatori esperti che non hanno mai lavorato come architetti e non sanno come disegnare quadrati su quadrati con frecce e conoscere 50 termini dell'ecosistema Hadoop.
All'inizio del viaggio, la mia testa si spaccava a causa dei tanti zoo selvaggi di software aperto e chiuso e della comprensione dell'onere della responsabilità nei confronti dei discendenti. Inizia a costruire il tuo DataLake da semplici strumenti: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., raccogliendo feedback e comprendendo profondamente la fisica dei processi in atto. Tutto ciò che è complesso e oscuro: dallo a nemici e concorrenti.
Se non vuoi andare sul cloud e ti piace supportare, aggiornare e applicare patch a progetti open source, puoi creare uno schema simile al nostro localmente, su macchine da ufficio economiche con Hadoop e Presto in cima. L'importante è non fermarsi e andare avanti, contare, cercare soluzioni semplici e chiare e tutto funzionerà sicuramente! Buona fortuna a tutti e ci vediamo di nuovo!
Fonte: habr.com