Una conferenza si svolgerà l'11 e il 12 luglio a San Pietroburgo , dedicata allo sviluppo di sistemi paralleli e distribuiti. Il trucco di Hydra è che unisce scienziati interessanti (che di solito si possono trovare solo nelle conferenze scientifiche straniere) e famosi ingegneri praticanti in un unico grande programma all'intersezione tra scienza e pratica.
Hydra è una delle nostre conferenze più importanti degli ultimi anni. È stato preceduto da una preparazione molto seria, dalla selezione dei relatori e dalle relazioni. La settimana scorsa a questo proposito con il direttore del gruppo JUG.ru, Alexey Fedorov ().
Noi circa tre importanti partecipanti, i fondatori della teoria dei sistemi distribuiti: Leslie Lamport, Maurice Herlihy e Michael Scott. È tempo di parlare più in dettaglio dell'intero programma!
motivazione
Se sei coinvolto nella programmazione, in un modo o nell'altro hai a che fare con il multithreading e l'elaborazione distribuita. Gli esperti nei settori rilevanti lavorano direttamente con loro, ma implicitamente la distribuzione ci guarda da ogni parte: in ogni computer multi-core o servizio distribuito c'è qualcosa che esegue calcoli in parallelo.
Ci sono molte conferenze che coprono vari aspetti della programmazione delle applicazioni. Dall’altro lato dello spettro, abbiamo scuole scientifiche specializzate che rivelano grandi quantità di teorie complesse in formato conferenza. Ad esempio, parallelamente all'Hydra a San Pietroburgo c'è . Alla conferenza Hydra, abbiamo cercato di riunire pratiche dure, scienza e tutto ciò che si trova alla loro intersezione.
Pensa a questo: viviamo in un’epoca straordinaria in cui puoi incontrare di persona i fondatori del campo della scienza e dell’ingegneria che studiamo. I fisici non incontreranno né Newton né Einstein: il treno è partito. Ma accanto a noi vivono ancora coloro che hanno creato le basi della teoria dei sistemi distribuiti, hanno inventato linguaggi di programmazione popolari e per la prima volta hanno incarnato tutto questo in prototipi funzionanti. Queste persone non hanno lasciato il lavoro a metà strada, ma stanno lavorando su questioni urgenti in università e aziende di fama mondiale e sono oggi le più grandi fonti di conoscenza ed esperienza.
D'altra parte, l'opportunità di incontrarli di solito rimane puramente teorica: pochi di noi possono monitorare costantemente gli eventi pubblici in qualche Università di Rochester, e poi correre negli Stati Uniti e tornare per una conferenza con Michael Scott. Visitare tutti i membri dell'Hydra costerebbe una piccola fortuna, senza contare l'abisso di tempo sprecato (anche se sembra una ricerca interessante).
D'altra parte, abbiamo molti ingegneri di alto livello che stanno lavorando su problemi urgenti nei sistemi distribuiti in questo momento, e hanno sicuramente molto da dire. Ma ecco il problema: loro stanno lavorandoe il loro tempo è prezioso. Sì, se sei un dipendente di Microsoft, Google o JetBrains, la probabilità di incontrare uno dei famosi relatori a un evento interno aumenta notevolmente, ma in generale no, questo non accade tutti i giorni.
In questo modo, la Conferenza Hydra realizza un compito importante che la maggior parte di noi non può svolgere da soli: riunisce in un luogo e in un momento persone le cui idee o interazioni con le quali possono cambiarti la vita. Ammetto che non tutti hanno bisogno di sistemi distribuiti o di alcune cose fondamentali complesse. Puoi programmare CRUD in PHP per il resto della tua vita e rimanere completamente felice. Ma chiunque ne abbia bisogno, questa è la tua occasione.
È passato parecchio tempo dal primo annuncio della conferenza Hydra su Habré. Durante questo periodo è stato svolto molto lavoro e ora disponiamo di un elenco di quasi tutti i rapporti. Nessun algoritmo lento a thread singolo, solo puro hardcore distribuito! Concludiamo con parole generali e vediamo cosa abbiamo tra le mani adesso.
Note chiave
Le keynote iniziano e concludono i giorni della conferenza. Di solito lo scopo di un keynote di apertura è definire lo spirito generale e la direzione della conferenza. Il keynote di chiusura traccia una linea e spiega come possiamo convivere con le conoscenze e le competenze acquisite durante la conferenza. L'inizio e la fine: ciò che viene ricordato meglio e, in generale, ha un significato maggiore.
Clic sulla scogliera
Cliff è una leggenda nel mondo Java. Alla fine degli anni '90, per la sua tesi di dottorato, ha scritto un articolo dal titolo , che qualche tempo dopo divenne la base per HotSpot JVM Server Compiler. Due anni dopo, stava già lavorando alla JVM presso Sun Microsystems e dimostrò al mondo intero che la JIT ha il diritto di esistere. Tutta questa storia su come Java sia uno dei runtime moderni più veloci con le ottimizzazioni più intelligenti e veloci proviene da Cliff Click. All'inizio si credeva che se qualcosa fosse accessibile a un compilatore statico, non dovessi nemmeno provare a farlo. Grazie al lavoro di Cliff e del suo team, tutti i nuovi linguaggi iniziarono a essere creati con l'idea della compilazione JIT per impostazione predefinita. Naturalmente, questo non era un lavoro individuale, ma Cliff ha giocato un ruolo molto importante in esso.
Nel keynote di apertura, Cliff parlerà del suo altro impegno: , una piattaforma in-memory per il machine learning distribuito e scalabile per applicazioni industriali. O più precisamente, sull'archiviazione distribuita delle coppie chiave-valore al suo interno. Si tratta di un sistema di archiviazione molto veloce con molte proprietà interessanti (l'elenco esatto è in ), che consentono l'utilizzo di soluzioni simili nella matematica dello streaming di big data.
Un altro rapporto che Cliff darà sarà: . Un'altra parte della sua biografia: dieci anni , dove ha aggiornato e migliorato molte cose nello stack hardware e tecnologico Azul: compilatori JIT, runtime, modello di thread, gestione degli errori, gestione dello stack, interruzioni hardware, caricamento delle classi e così via - beh, ottieni il idea.
La parte più interessante è iniziata quando hanno realizzato l'hardware per una grande azienda: un supercomputer per eseguire Java. Era una cosa piuttosto innovativa, su misura per Java, che ha requisiti speciali: leggere barriere di memoria per la garbage collection a bassa pausa, array con controllo dei limiti, chiamate virtuali... Una delle tecnologie più interessanti è la memoria transazionale hardware. L'intera L1 di uno qualsiasi degli 864 core potrebbe partecipare alla scrittura transazionale, il che è particolarmente importante per lavorare con i blocchi in Java (i blocchi sincronizzati possono funzionare in parallelo purché non vi sia un reale conflitto di memoria). Ma la bella idea è stata schiacciata dalla dura realtà - e in questo discorso Cliff ti spiegherà perché HTM e STM non sono molto adatti alle esigenze pratiche dell'elaborazione multi-thread.
Michael Scott-
- Professore di Informatica presso l'Università di Rochester, al quale il destino lo collegò , e nella sua casa, l'Università del Wisconsin-Madison, è stato preside per cinque anni. Ricerca e insegna agli studenti la programmazione parallela e distribuita e la progettazione del linguaggio.
Il mondo intero conosce Michael grazie al libro di testo , la cui ultima edizione è stata pubblicata relativamente di recente - nel 2015. Il suo lavoro ho ricevuto come uno dei più famosi nel campo del calcolo distribuito e presso la Biblioteca online dell'Università di Rochester. Potresti anche conoscerlo come l'autore dello stesso algoritmo di Michael-Scott .
Per quanto riguarda il mondo Java, questo è un caso particolare: insieme a Doug Lea ha sviluppato gli algoritmi non bloccanti e le code sincrone su cui lavorano le librerie Java. Questo è esattamente ciò di cui parlerà il keynote "Doppie strutture dati": l'introduzione di queste strutture in Java SE 6 ha migliorato le prestazioni di 10 volte java.util.concurrent.ThreadPoolExecutor. Se ti stai chiedendo in anticipo cosa siano queste “doppie strutture dati”, allora ci sono informazioni a riguardo .
Maurice Herlihy -
- vincitore di due premi Dijkstra. Il primo è per lavorare (Brown University), e il secondo, più recente - (Università tecnologica della Virginia). Il Premio Dijkstra riconosce il lavoro il cui significato e impatto sono visibili da almeno dieci anni e Maurice è chiaramente uno degli esperti più rinomati nel settore. Attualmente lavora come professore alla Brown University e ha un elenco di risultati lungo un paragrafo.
In questo keynote di chiusura, Maurice parlerà della teoria e della pratica dei sistemi distribuiti blockchain dal punto di vista dei classici del calcolo distribuito e di come semplifica molti problemi correlati. Questo è un rapporto esclusivamente sull'argomento della conferenza - non sull'hype minerario, ma piuttosto su come le nostre conoscenze possono essere utilizzate in modo sorprendentemente efficace e appropriato in relazione a una varietà di compiti.
Nel luglio 2017, Maurice è già venuto in Russia per frequentare la scuola SPTDC, ha partecipato al meetup JUG.ru e la registrazione può essere vista su YouTube:
Programma principale
Successivamente ci sarà una breve panoramica dei report inclusi nel programma. Alcune segnalazioni vengono qui descritte in dettaglio, altre più brevemente. Le descrizioni lunghe riguardavano principalmente rapporti in lingua inglese che richiedevano collegamenti a articoli scientifici, termini su Wikipedia e così via. L'elenco completo è disponibile . L'elenco presente sul sito sarà aggiornato ed integrato.
Leslie Lamport-
Leslie Lamport è autrice di lavori fondamentali sul calcolo distribuito. sta per "Lamport TeX". Fu lui il primo, nel 1979, a introdurre il concetto , e il suo articolo ha ricevuto il Premio Dijkstra.
Questa è la parte più insolita del programma in termini di formato, perché non è nemmeno un rapporto, ma una sessione di domande e risposte. Quando una parte significativa del pubblico ha già familiarità (o può acquisire familiarità) con tutti i tipi di lavori basati sulla “teoria di Lamport”, con i suoi articoli e rapporti, è più importante dedicare tutto il tempo disponibile alla comunicazione diretta.
L'idea è semplice: guardi due report su YouTube: и e prepara almeno una domanda e Leslie risponde.
Il primo di questi due video lo abbiamo già . Se non hai un'ora di tempo per guardare il video, puoi leggerlo velocemente tutto in formato testo.
Nota: ci sono molti altri video di Leslie Lamport su YouTube. Ad esempio, c'è un fantastico . Una versione offline dell'intero corso è disponibile all'indirizzo e lo ha caricato su YouTube per una visualizzazione più semplice sui dispositivi mobili.
Martin Kleppmann-
Martin Kleppmann è un ricercatore dell'Università di Cambridge che lavora sulla CRDT e sulla verifica formale degli algoritmi. Il libro di Martino , pubblicato nel 2017, ha avuto molto successo ed è entrato nelle liste dei bestseller nel campo dell'archiviazione ed elaborazione dei dati. Kevin Scott, CTO di Microsoft, : “Questo libro dovrebbe essere un must per gli ingegneri del software. Si tratta di una risorsa rara che combina teoria e pratica per aiutare gli sviluppatori a progettare e implementare infrastrutture e sistemi di dati in modo più intelligente”. Il creatore di Kafka e CTO di Confluent, Jay Kreps, ha detto qualcosa di simile.
Prima di dedicarsi alla ricerca accademica, Martin ha lavorato nell'industria e ha cofondato due start-up di successo:
- Rapportive, dedicato alla visualizzazione del profilo social dei contatti dalla propria email, che LinkedIn ha acquistato nel 2012;
- Go Test It, un servizio per testare automaticamente i siti Web in vari browser, acquistato da RedGate nel 2009.
In generale, Martin, anche se meno famoso dei nostri keynote, ha già saputo dare qualche contributo allo sviluppo del calcolo distribuito e all'industria.
In questo intervento, Martin parlerà di un argomento più vicino alla sua ricerca accademica. In Google Docs e simili divani di co-editing di documenti, "modifica collaborativa" si riferisce a un'attività di replica: ogni utente ha la propria replica del documento condiviso, che poi modifica, e tutte le modifiche vengono inviate attraverso la rete al resto del gruppo. partecipanti. Le modifiche ai documenti offline portano a una temporanea incoerenza del documento rispetto ad altri partecipanti e la risincronizzazione richiede la gestione dei conflitti. E' proprio per questo che esistono (CRDT), infatti, è una cosa abbastanza nuova, la cui essenza è stata formulata solo nel 2011. Questo discorso discute cosa è successo da allora nel mondo di CRDT, quali sono i progressi più recenti, l'approccio alla creazione di applicazioni local-first in generale e l'uso di una libreria open source in particolare.
La prossima settimana pubblicheremo una lunga intervista con Martin su Habré, sarà interessante.
Pedro Ramalhete -
Pedro lavora presso Cisco e sviluppa algoritmi paralleli da circa dieci anni, inclusi meccanismi di sincronizzazione, strutture dati senza blocchi e senza attesa e tutto ciò che puoi immaginare su questo argomento. I suoi attuali interessi di ricerca e ingegneria si concentrano su costruzioni universali, memoria transazionale software, memoria persistente e tecnologie simili che consentono applicazioni corrette, scalabili e tolleranti ai guasti. È anche autore di un blog ampiamente conosciuto in ambienti ristretti .
La maggior parte delle applicazioni multithread ora vengono eseguite su strutture dati parallele, dall'uso di code di messaggi tra attori a strutture dati indicizzate in archivi di valori-chiave. Funzionano con successo in Java JDK da molti anni e vengono lentamente aggiunti al C++.
Il modo più semplice per implementare una struttura dati parallela è un'implementazione sequenziale (a thread singolo) in cui i metodi sono protetti da mutex. È accessibile a qualsiasi giugno, ma presenta evidenti problemi di ridimensionamento e prestazioni. Allo stesso tempo, le strutture dati senza blocchi e senza attesa non solo sopportano meglio gli errori, ma hanno anche un profilo prestazionale migliore; tuttavia, il loro sviluppo richiede una profonda competenza e adattamento a un'applicazione specifica. Basta una riga di codice sbagliata per rompere tutto.
Come possiamo fare in modo che anche un non esperto possa progettare e implementare tali strutture di dati? È noto che qualsiasi algoritmo sequenziale può essere reso thread-safe utilizzando entrambi o memoria transazionale. Per prima cosa, possono abbassare la barriera all’ingresso nella soluzione di questo problema. Tuttavia, entrambe le soluzioni in genere portano a un’implementazione inefficace. Pedro parlerà di come sono riusciti a rendere questi progetti più efficienti e di come puoi utilizzarli per i tuoi algoritmi.
Heidi Howard-
Heidi Howard è, come Martin, una ricercatrice di sistemi distribuiti presso l'Università di Cambridge. Le sue specialità sono coerenza, tolleranza agli errori, performance e consenso distribuito. È conosciuta soprattutto per la sua generalizzazione dell'algoritmo di Paxos chiamato .
Ricordiamo che è una famiglia di protocolli per risolvere il problema del consenso in una rete di computer inaffidabili, basata sul lavoro di Leslie Lamport. Pertanto, alcuni dei nostri relatori stanno lavorando su problemi originariamente proposti dagli altri relatori - e questo è meraviglioso.
La capacità di trovare consenso tra più host (per l'indirizzamento, l'elezione del leader, il blocco o il coordinamento) è una questione fondamentale nei moderni sistemi distribuiti. Paxos è ora il modo principale per risolvere i problemi di consenso e sono in corso molte ricerche al riguardo per espandere e ottimizzare l’algoritmo per varie esigenze pratiche.
In questo discorso rivisiteremo le basi teoriche di Paxos, allentando i requisiti originali e generalizzando l'algoritmo. Vedremo che Paxos è essenzialmente solo un'opzione tra una vasta gamma di approcci consensuali, e che anche altri punti sullo spettro sono molto utili per costruire buoni sistemi distribuiti.
Alex Petrov—
Alex è uno specialista di database e sistemi di storage e, cosa più importante per noi, un committente . Attualmente sta lavorando a un libro, Database Internals, con O'Reilly.
Per sistemi con (nella terminologia russa - "coerenza massima"), dopo che un nodo si blocca o una divisione della rete, è necessario risolvere il seguente dilemma: continuare a eseguire le richieste, sacrificando la coerenza, oppure rifiutarsi di eseguirle e sacrificare la disponibilità. In un sistema di questo tipo, i quorum, la sovrapposizione di sottoinsiemi di nodi e la garanzia che almeno un nodo contenga il valore più recente, possono essere una buona soluzione edge. Puoi sopravvivere a guasti e perdita di connettività ad alcuni nodi continuando a rispondere con i valori più recenti.
Tuttavia, tutto ha il suo prezzo. Uno schema di replica del quorum implica maggiori costi di storage: i dati ridondanti devono essere archiviati su più nodi contemporaneamente per garantire che siano disponibili copie sufficienti quando si verifica un problema. Si scopre che non è necessario archiviare tutti i dati su tutte le repliche. È possibile ridurre il carico sullo storage se si archiviano i dati solo su una parte dei nodi e si utilizzano nodi speciali (replica transitoria) per gli scenari di gestione degli errori.
Nel corso del rapporto valuteremo , lo schema di replica utilizzato in и e l'implementazione di questo concetto in Apache Cassandra è stata chiamata .
Dmitrij Vjukov -
Dmitry è uno sviluppatore di Google che lavora su test dinamici per C/C++ e Go - Address/Memory/ThreadSanitizer e strumenti simili per il kernel Linux. Ha contribuito a Go uno scheduler goroutine scalabile, un poller di rete e un garbage collector parallelo. È un esperto di multithreading, autore di una dozzina di nuovi algoritmi non bloccanti ed è proprietario di Intel.
Ora parliamo un po' del rapporto stesso. Il linguaggio Go ha il supporto nativo per il multithreading sotto forma di goroutine (thread leggeri) e canali (code FIFO). Questi meccanismi rendono molto semplice e divertente per gli utenti scrivere moderne applicazioni multi-thread e sembra una magia. Come abbiamo capito, non c'è magia qui. In questo discorso, Dmitry approfondirà le complessità dello scheduler Go e mostrerà i segreti per implementare questa "magia". Innanzitutto, fornirà una panoramica dei componenti principali dello scheduler e ti spiegherà come funziona. Successivamente esamineremo più da vicino i singoli aspetti come la strategia di parcheggio/rimozione dal parcheggio e la gestione delle chiamate di sistema di blocco. Infine, Dmitry parlerà un po' dei possibili miglioramenti allo scheduler.
Dmitry Bugaichenko -
Dmitry ha lavorato in outsourcing per quasi 9 anni senza perdere i contatti con l'università e la comunità scientifica. L'analisi dei big data in Odnoklassniki è diventata per lui un'occasione unica per combinare formazione teorica e basi scientifiche con lo sviluppo di prodotti reali e richiesti.
L'analisi dei grafi distribuiti è stata e rimane un compito difficile: quando diventa necessario ottenere informazioni sulle connessioni di un vertice vicino, spesso i dati devono essere trasferiti tra macchine, il che comporta un aumento dei tempi di esecuzione e del carico sull'infrastruttura di rete. In questo intervento vedremo come ottenere velocità di elaborazione significative utilizzando strutture di dati probabilistiche o fatti come la simmetria del grafico dell'amicizia in un social network. Tutto questo è illustrato con esempi di codice in Apache Spark.
Denis Rystsov -
Denis - sviluppatore , esperto nel controllo di modelli di coerenza, algoritmi di consenso e transazioni distribuite. Attualmente lavora presso Microsoft e prima ancora ha lavorato su sistemi distribuiti presso Amazon e Yandex.
In questo discorso daremo uno sguardo ai protocolli di transazione distribuita che sono stati inventati negli ultimi anni, che possono essere implementati sul lato client su qualsiasi archivio dati che supporti l'aggiornamento condizionale (confronta e imposta). La conclusione è che la vita non finisce con un commit in due fasi, le transazioni possono essere aggiunte a qualsiasi database - a livello di applicazione, ma protocolli diversi (2PC, Percolator, RAMP) hanno compromessi diversi e non ci vengono forniti gratuito.
Aleksej Zinoviev -
Alessio () è relatore di lunga data e membro dei comitati di programma di altre conferenze. Formatore pratico presso EPAM Systems e amico di Hadoop/Spark e altri big data dal 2012.
In questo discorso, Alexey parlerà dei problemi legati all'adattamento degli algoritmi classici di machine learning per l'esecuzione in modalità distribuita in base alla sua esperienza di lavoro con Apache Spark ML, Apache Mahout, Apache Flink ML e all'esperienza nella creazione di Apache Ignite ML. Alexey parlerà anche dell'implementazione di algoritmi di ML distribuito in questi framework.
E infine, due rapporti di Yandex sul database Yandex.
Vladislav Kuznetsov -
Vladislav è uno sviluppatore presso Yandex nel gruppo della piattaforma distribuita. Yandex Database è un DBMS scalabile orizzontalmente, geo-distribuito e tollerante ai guasti in grado di resistere ai guasti di dischi, server, rack e data center senza perdere coerenza. Per garantire la tolleranza agli errori, viene utilizzato un algoritmo proprietario per ottenere il consenso distribuito, nonché una serie di soluzioni tecniche, discusse in dettaglio nel rapporto. Il rapporto potrebbe interessare sia gli sviluppatori di DBMS che gli sviluppatori di soluzioni applicative basate su DBMS.
Semyon Checherinda -
Semyon è uno sviluppatore del gruppo di piattaforme distribuite di Yandex, che lavora sulla possibilità di utilizzo multi-tenant dell'installazione YDB.
Il database Yandex è progettato per query OLTP ed è conforme ai requisiti ACID per un sistema transazionale. In questo rapporto, prenderemo in considerazione l'algoritmo di pianificazione delle transazioni che è alla base del sistema di transazioni YDB. Diamo un'occhiata a quali entità partecipano alle transazioni, chi assegna l'ordine globale alle transazioni, come vengono raggiunte l'atomicità delle transazioni, l'affidabilità e un rigoroso livello di isolamento. Utilizzando un problema comune come esempio, esaminiamo le implementazioni delle transazioni utilizzando commit a due fasi e transazioni deterministiche. Discutiamo le loro differenze.
Quali sono le prospettive?
Il programma della conferenza continua ad essere ricco di nuove relazioni. In particolare, ci aspettiamo un rapporto da Nikita Koval () da JetBrains e Oleg Anastasiev () della società Odnoklassniki. Nikita lavora su algoritmi per coroutine nel team Kotlin e Oleg sviluppa architettura e soluzioni per sistemi ad alto carico nella piattaforma Odnoklassniki. Inoltre, c'è ancora 1 posto condizionatamente vuoto, il comitato del programma sta lavorando con i candidati in questo momento.
La conferenza Hydra si svolgerà l'11 e il 12 luglio a San Pietroburgo. I biglietti sono disponibili . Ti preghiamo di prestare attenzione alla disponibilità dei biglietti online - se per qualche motivo non puoi arrivare a San Pietroburgo in questi giorni.
Ci vediamo all'Idra!
Fonte: habr.com