O conferință va avea loc în perioada 11-12 iulie la Sankt Petersburg , dedicat dezvoltării de sisteme paralele și distribuite. Trucul Hydra este că reunește oameni de știință cool (care pot fi de obicei găsiți doar la conferințe științifice străine) și ingineri practicanți celebri într-un singur program mare, la intersecția științei și practicii.
Hydra este una dintre cele mai importante conferințe ale noastre din ultimii ani. A fost precedată de o pregătire foarte serioasă, selecție de vorbitori și rapoarte. Săptămâna trecută despre asta cu directorul JUG.ru Group, Alexey Fedorov ().
Noi aproximativ trei participanți importanți, fondatorii teoriei sistemelor distribuite - Leslie Lamport, Maurice Herlihy și Michael Scott. Este timpul să vorbim mai detaliat despre întregul program!
Motivație
Dacă sunteți implicat în programare, atunci într-un fel sau altul aveți de-a face cu multithreading și calculul distribuit. Experții din domeniile relevante lucrează cu ei direct, dar implicit, distribuția ne privește de pretutindeni: în orice computer multi-core sau serviciu distribuit există ceva care efectuează calcule în paralel.
Există multe conferințe care acoperă diverse aspecte ale programării aplicațiilor. De cealaltă parte a spectrului, avem școli științifice specializate care dezvăluie cantități mari de teorie complexă în format de prelegere. De exemplu, în paralel cu Hydra din Sankt Petersburg există . La conferința Hydra, am încercat să aducem împreună practica aspră, știința și tot ce se afla la intersecția lor.
Gândiți-vă la asta: trăim într-o perioadă uimitoare când îi puteți întâlni în persoană pe fondatorii domeniului științei și ingineriei pe care îl studiem. Fizicienii nu se vor întâlni nici cu Newton, nici cu Einstein - trenul a plecat. Dar lângă noi încă trăiesc cei care au creat bazele teoriei sistemelor distribuite, au inventat limbaje de programare populare și au întruchipat pentru prima dată toate acestea în prototipuri de lucru. Acești oameni nu și-au părăsit slujba la jumătate, ei lucrează chiar acum la probleme stringente în universități și companii de renume mondial și sunt cele mai mari surse de cunoștințe și experiență în prezent.
Pe de altă parte, oportunitatea de a-i întâlni de obicei rămâne pur teoretică: puțini dintre noi putem monitoriza constant evenimentele publice de la o anumită universitate din Rochester și apoi se grăbesc în SUA și înapoi pentru o prelegere cu Michael Scott. Vizitarea tuturor membrilor Hydra ar costa o mică avere, fără a număra abisul timpului pierdut (deși pare o căutare interesantă).
Pe de altă parte, avem mulți ingineri de top care lucrează la probleme stringente în sistemele distribuite chiar acum și cu siguranță au multe de spus. Dar aici este problema - ei sunt de lucru, iar timpul lor este valoros. Da, dacă sunteți angajat al Microsoft, Google sau JetBrains, probabilitatea de a întâlni unul dintre celebrii vorbitori la un eveniment intern crește brusc, dar, în general, nu, acest lucru nu se întâmplă în fiecare zi.
În acest fel, Hydra Conference îndeplinește o sarcină importantă pe care cei mai mulți dintre noi nu o putem face singuri - într-un loc și la un moment dat, reunește oameni ale căror idei sau interacțiuni cu care îți pot schimba viața. Recunosc că nu toată lumea are nevoie de sisteme distribuite sau de unele lucruri fundamentale complexe. Puteți programa CRUD-uri în PHP pentru tot restul vieții și să rămâneți complet fericit. Dar oricine are nevoie, aceasta este șansa ta.
A trecut destul de mult timp de la primul anunț al conferinței Hydra despre Habré. În acest timp, s-a lucrat mult - iar acum avem o listă cu aproape toate rapoartele. Fără algoritmi lenți cu un singur thread, doar hardcore distribuit pur! Să încheiem cu cuvinte generale și să vedem ce avem acum pe mâini.
Notele cheie
Notele principale încep și se încheie zilele conferinței. De obicei, scopul unei note de deschidere este de a stabili spiritul general și direcția conferinței. Discursul de închidere trasează o linie și explică cum putem trăi cu cunoștințele și abilitățile dobândite în timpul conferinței. Începutul și sfârșitul: ceea ce este amintit cel mai bine și, în general, are o semnificație sporită.
Cliff Click
Cliff este o legendă în lumea Java. La sfârșitul anilor 90, pentru teza de doctorat, a scris o lucrare intitulată , care ceva timp mai târziu a devenit baza pentru HotSpot JVM Server Compiler. Doi ani mai târziu, el lucra deja la Sun Microsystems pe JVM și a arătat lumii întregi că JIT are dreptul de a exista. Toată această poveste despre modul în care Java este unul dintre cele mai rapide runtime moderne cu cele mai inteligente și mai rapide optimizări a venit de la Cliff Click. La început, s-a crezut că, dacă ceva este accesibil unui compilator static, nici măcar nu trebuie să încerci să-l treci. Datorită muncii lui Cliff și a echipei, toate limbile noi au început să fie create cu ideea de compilare JIT în mod implicit. Desigur, aceasta nu a fost o slujbă de un singur om, dar Cliff a jucat un rol foarte important în ea.
În discursul de deschidere, Cliff va vorbi despre celălalt efort al lui - , o platformă în memorie pentru învățarea automată distribuită și scalabilă pentru aplicații industriale. Sau, mai precis, despre stocarea distribuită a perechilor cheie-valoare în interiorul acestuia. Aceasta este o stocare foarte rapidă, cu o mulțime de proprietăți interesante (lista exactă este în ), care permit utilizarea unor soluții similare în matematica fluxului de date mari.
Un alt raport pe care Cliff îl va da este... . O altă parte a biografiei sale - zece ani , unde a actualizat și îmbunătățit o mulțime de lucruri în stiva de hardware și tehnologie Azul: compilatoare JIT, runtime, model de fir, gestionarea erorilor, gestionarea stivei, întreruperi hardware, încărcarea clasei și așa mai departe - ei bine, obțineți idee.
Cea mai interesantă parte a început când au făcut hardware pentru o mare afacere - un supercomputer pentru a rula Java. A fost un lucru destul de inovator, adaptat special pentru Java, care are cerințe speciale - bariere de citire a memoriei pentru colectarea gunoiului cu pauză redusă, matrice cu verificarea limitelor, apeluri virtuale... Una dintre cele mai tari tehnologii este memoria tranzacțională hardware. Întregul L1 al oricăruia dintre cele 864 de nuclee ar putea participa la scrierea tranzacțională, ceea ce este deosebit de important pentru lucrul cu blocări în Java (blocurile sincronizate pot funcționa în paralel atâta timp cât nu există un conflict real de memorie). Dar ideea frumoasă a fost zdrobită de realitatea dură - și în această discuție Cliff vă va spune de ce HTM și STM nu sunt prea potrivite pentru nevoile practice ale calculului multi-threaded.
Michael Scott -
- Profesor de Informatică la Universitatea din Rochester, de care soarta l-a legat , iar la Universitatea sa natală din Wisconsin-Madison, a fost decan timp de cinci ani. El cercetează și îi predă pe studenți despre programarea paralelă și distribuită și despre proiectarea limbajului.
Lumea întreagă îl cunoaște pe Michael datorită manualului , a cărui ultimă ediție a fost publicată relativ recent - în 2015. Sarcina lui am primit ca una dintre cele mai cunoscute în domeniul calculului distribuit şi la Biblioteca online a Universității din Rochester. S-ar putea să-l cunoașteți și ca autor al algoritmului Michael-Scott de la .
În ceea ce privește lumea Java, acesta este un caz special: împreună cu Doug Lea, a dezvoltat algoritmii de neblocare și cozile sincrone pe care lucrează bibliotecile Java. Acesta este exact despre ce va fi vorba despre „Structuri de date duble” - introducerea acestor structuri în Java SE 6 a îmbunătățit performanța de 10 ori java.util.concurrent.ThreadPoolExecutor. Dacă vă întrebați în avans care sunt aceste „structuri de date duale”, atunci există informații despre acestea .
Maurice Herlihy -
- câștigător a două premii Dijkstra. Prima este pentru lucru (Universitatea Brown), iar al doilea, mai recent - (Universitatea Tehnică din Virginia). Premiul Dijkstra recunoaște lucrările a căror semnificație și impact au fost vizibile de cel puțin zece ani, iar Maurice este în mod clar unul dintre cei mai renumiți experți în domeniu. În prezent lucrează ca profesor la Universitatea Brown și are o listă lungă de realizări.
În acest discurs de încheiere, Maurice va vorbi despre teoria și practica sistemelor distribuite blockchain din punctul de vedere al clasicilor calculului distribuit și despre modul în care simplifică multe probleme conexe. Acesta este un raport exclusiv pe tema conferinței - deloc despre hype-ul minier, ci mai degrabă despre modul în care cunoștințele noastre pot fi utilizate uimitor de eficient și adecvat în legătură cu o varietate de sarcini.
În iulie 2017, Maurice a venit deja în Rusia pentru a urma școala SPTDC, a participat la întâlnirea JUG.ru, iar înregistrarea poate fi vizionată pe YouTube:
Programul principal
În continuare va fi o scurtă prezentare generală a rapoartelor incluse în program. Unele dintre rapoarte sunt descrise aici în detaliu, altele mai pe scurt. Descrierile lungi s-au referit în principal la rapoarte în limba engleză care necesitau link-uri către lucrări științifice, termeni de pe Wikipedia și așa mai departe. Lista completă este disponibilă . Lista de pe site va fi actualizată și completată.
Leslie Lampport -
Leslie Lamport este autoarea unor lucrări fundamentale în calculul distribuit. înseamnă „Lamport TeX”. El a fost primul, în 1979, care a introdus conceptul , și articolul lui a primit Premiul Dijkstra.
Aceasta este cea mai neobișnuită parte a programului în format, deoarece nu este nici măcar un raport, ci o sesiune de întrebări și răspunsuri. Când o parte semnificativă a publicului este deja familiarizată (sau poate deveni familiarizată) cu tot felul de lucrări bazate pe „teoria lui Lampport”, propriile articole și rapoarte, este mai important să aloci tot timpul disponibil comunicării directe.
Ideea este simplă - urmăriți două reportaje pe YouTube: и și pregătește cel puțin o întrebare, iar Leslie răspunde.
Primul dintre aceste două videoclipuri îl avem deja . Dacă nu aveți o oră de timp pentru a viziona videoclipul, îl puteți citi rapid pe tot sub formă de text.
Notă: Există multe alte videoclipuri Leslie Lampport pe YouTube. De exemplu, există o mare . O versiune offline a întregului curs este disponibilă la și l-a încărcat pe YouTube pentru o vizionare mai ușoară pe dispozitivele mobile.
Martin Kleppmann -
Martin Kleppmann este cercetător la Universitatea din Cambridge care lucrează la CRDT și la verificarea formală a algoritmilor. cartea lui Martin , publicată în 2017, s-a dovedit a fi de mare succes și a ajuns pe listele cu bestselleruri în domeniul stocării și prelucrării datelor. Kevin Scott, CTO la Microsoft, : „Această carte ar trebui să fie un must-have pentru inginerii de software. Aceasta este o resursă rară care combină teoria și practica pentru a ajuta dezvoltatorii mai inteligenți în proiectarea și implementarea infrastructurii și a sistemelor de date.” Creatorul Kafka și CTO al Confluent, Jay Kreps, a spus ceva similar.
Înainte de a trece în cercetarea academică, Martin a lucrat în industrie și a co-fondat două start-up-uri de succes:
- Rapportive, dedicat afișării profilului social al contactelor de pe email-ul tău, pe care LinkedIn l-a cumpărat în 2012;
- Go Test It, un serviciu de testare automată a site-urilor web în diverse browsere, pe care RedGate l-a cumpărat în 2009.
În general, Martin, deși mai puțin faimos decât discursurile noastre, a reușit deja să aducă o anumită contribuție la dezvoltarea computerului distribuit și la industrie.
În această discuție, Martin va vorbi despre un subiect mai apropiat de cercetarea sa academică. În Google Docs și în canapele de coeditare a documentelor similare, „editarea în colaborare” se referă la o sarcină de replicare: fiecare utilizator are propria sa copie a documentului partajat, pe care apoi o modifică, iar toate modificările sunt trimise prin rețea restului participanții. Modificările aduse documentelor offline duc la o inconsecvență temporară a documentului în raport cu alți participanți, iar resincronizarea necesită gestionarea conflictelor. Exact pentru asta există (CRDT), de fapt, este un lucru destul de nou, a cărui esență a fost formulată abia în 2011. Această discuție discută ce s-a întâmplat de atunci în lumea CRDT, care sunt cele mai recente progrese, abordarea creării de aplicații locale în general și utilizarea unei biblioteci open source în special.
Săptămâna viitoare vom publica un interviu lung cu Martin pe Habré, va fi interesant.
Pedro Ramalhete -
Pedro lucrează la Cisco și a dezvoltat algoritmi paraleli în ultimii zece ani, inclusiv mecanisme de sincronizare, structuri de date fără blocare și fără așteptare și tot ce vă puteți imagina pe acest subiect. Interesele sale actuale de cercetare și inginerie se concentrează pe construcții universale, memorie tranzacțională software, memorie persistentă și tehnologii similare care permit aplicații corecte, scalabile și tolerante la erori. El este, de asemenea, autorul unui blog larg cunoscut în cercurile înguste .
Cele mai multe aplicații cu mai multe fire rulează acum pe structuri de date paralele, de la utilizarea cozilor de mesaje între actori până la structurile de date indexate în depozitele cheie-valoare. Au lucrat cu succes în Java JDK de mulți ani și sunt adăugate încet la C++.
Cel mai simplu mod de a implementa o structură de date paralelă este o implementare secvenţială (cu un singur fir) în care metodele sunt protejate de mutexuri. Acesta este accesibil oricărui iunie, dar are probleme evidente cu scalarea și performanța. În același timp, structurile de date fără blocare și fără așteptare nu numai că fac față mai bine erorilor, dar au și un profil de performanță mai bun - cu toate acestea, dezvoltarea lor necesită expertiză profundă și adaptare la o aplicație specifică. O linie greșită de cod este suficientă pentru a sparge totul.
Cum putem face astfel încât chiar și un neexpert să poată proiecta și implementa astfel de structuri de date? Se știe că orice algoritm secvenţial poate fi protejat de fire folosind oricare , sau memorie tranzacțională. În primul rând, pot reduce bariera de intrare în rezolvarea acestei probleme. Cu toate acestea, ambele soluții duc de obicei la implementare ineficientă. Pedro va vorbi despre cum au reușit să facă aceste modele mai eficiente și despre cum le puteți folosi pentru algoritmii dvs.
Heidi Howard -
Heidi Howard este, ca și Martin, un cercetător de sisteme distribuite la Universitatea din Cambridge. Specialitățile ei sunt consistența, toleranța la greșeli, performanța și consensul distribuit. Ea este cel mai bine cunoscută pentru generalizarea algoritmului Paxos numit .
Amintiți-vă că este o familie de protocoale pentru rezolvarea problemei consensului într-o rețea de calculatoare nesigure, bazată pe munca lui Leslie Lamport. Astfel, unii dintre vorbitorii noștri lucrează la probleme care au fost propuse inițial de ceilalți vorbitori ai noștri - și acest lucru este minunat.
Capacitatea de a găsi un consens între mai multe gazde - pentru adresare, alegere de lider, blocare sau coordonare - este o problemă fundamentală în sistemele moderne distribuite. Paxos este acum principala modalitate de a rezolva problemele de consens și există o mulțime de cercetări în desfășurare în jurul lui pentru a extinde și optimiza algoritmul pentru diverse nevoi practice.
În această discuție, vom revizui baza teoretică a lui Paxos, relaxând cerințele originale și generalizând algoritmul. Vom vedea că Paxos este, în esență, doar o opțiune dintr-o gamă largă de abordări de consens și că alte puncte din spectru sunt, de asemenea, foarte utile pentru construirea unor sisteme bine distribuite.
Alex Petrov -
Alex este un specialist în baze de date și sisteme de stocare și, mai important pentru noi, un committer în . În prezent, lucrează la o carte, Database Internals, cu O'Reilly.
Pentru sistemele cu (în terminologia rusă - „coerență finală”), după ce un nod se prăbușește sau o divizare a rețelei, trebuie să rezolvați următoarea dilemă: fie continuați să executați cereri, sacrificând consistența, fie refuzați să le executați și sacrificați disponibilitatea. Într-un astfel de sistem, cvorumurile, subseturile suprapuse de noduri și asigurarea faptului că cel puțin un nod conține cea mai recentă valoare, poate fi o soluție bună. Puteți supraviețui eșecurilor și pierderii conectivității la unele noduri în timp ce răspundeți cu cele mai recente valori.
Totuși, totul are prețul lui. O schemă de replicare a cvorumului înseamnă costuri de stocare crescute: datele redundante trebuie să fie stocate pe mai multe noduri simultan pentru a se asigura că există suficiente copii disponibile atunci când apare o problemă. Se pare că nu trebuie să stocați toate datele pe toate replicile. Puteți reduce încărcarea stocării dacă stocați date numai pe o parte a nodurilor și utilizați noduri speciale (Replica tranzitorie) pentru scenariile de tratare a erorilor.
Pe parcursul raportului vom lua în considerare , schema de replicare utilizată în и , iar implementarea acestui concept în Apache Cassandra numit .
Dmitri Vyukov -
Dmitry este un dezvoltator la Google care lucrează la testarea dinamică pentru C/C++ și Go - Address/Memory/ThreadSanitizer și instrumente similare pentru nucleul Linux. A contribuit la Go un planificator scalabil de rutine, un sondaj de rețea și un colector de gunoi paralel. Este expert în multithreading, autorul a zeci de noi algoritmi non-blocante și este proprietarul Intel.
Acum puțin despre raportul în sine. Limbajul Go are suport nativ pentru multithreading sub formă de goroutine (file ușoare) și canale (cozi FIFO). Aceste mecanisme fac foarte ușor și plăcut pentru utilizatori să scrie aplicații moderne multi-threaded și arată ca o magie. După cum înțelegem, aici nu există magie. În această discuție, Dmitry va aprofunda în complexitatea programatorului Go și va arăta secretele implementării acestei „magie”. În primul rând, el va oferi o privire de ansamblu asupra componentelor principale ale planificatorului și vă va spune cum funcționează. În continuare, vom arunca o privire mai atentă asupra aspectelor individuale, cum ar fi strategia de parcare/deparcare și gestionarea apelurilor de sistem de blocare. În cele din urmă, Dmitry va vorbi puțin despre posibilele îmbunătățiri ale programatorului.
Dmitri Bugaichenko -
Dmitry a lucrat în outsourcing timp de aproape 9 ani fără a pierde contactul cu universitatea și comunitatea științifică. Analiza datelor mari în Odnoklassniki a devenit pentru el o șansă unică de a combina pregătirea teoretică și fundația științifică cu dezvoltarea de produse reale, la cerere.
Analiza graficelor distribuite a fost și rămâne o sarcină dificilă: atunci când devine necesară obținerea de informații despre conexiunile unui vârf învecinat, datele trebuie adesea transferate între mașini, ceea ce duce la creșterea timpului de execuție și a încărcăturii asupra infrastructurii de rețea. În această discuție, vom vedea cum puteți obține viteze semnificative de procesare folosind structuri de date probabilistice sau fapte precum simetria graficului de prietenie într-o rețea socială. Toate acestea sunt ilustrate cu exemple de cod în Apache Spark.
Denis Rystsov -
Denis - dezvoltator , un expert în verificarea modelelor de coerență, a algoritmilor de consens și a tranzacțiilor distribuite. În prezent, lucrează la Microsoft, iar înainte de asta a lucrat pe sisteme distribuite la Amazon și Yandex.
În această discuție, vom arunca o privire asupra protocoalelor de tranzacție distribuite care au fost inventate în ultimii ani, care pot fi implementate pe partea clientului pe deasupra oricărui magazin de date care acceptă actualizarea condiționată (comparați și setați). Concluzia este că viața nu se termină cu un commit în două faze, tranzacțiile pot fi adăugate peste orice baze de date - la nivel de aplicație, dar diferite protocoale (2PC, Percolator, RAMP) au compromisuri diferite și nu ne sunt date. gratuit.
Alexey Zinoviev -
Alexei () este un vorbitor de lungă durată și membru al comitetelor de program la alte conferințe. Trainer în practică la EPAM Systems și este prieten cu Hadoop/Spark și alte date mari din 2012.
În această discuție, Alexey va vorbi despre problemele adaptării algoritmilor clasici de învățare automată pentru execuția în modul distribuit, pe baza experienței sale de lucru cu Apache Spark ML, Apache Mahout, Apache Flink ML și experiența creării Apache Ignite ML. Alexey va vorbi și despre implementarea algoritmilor ML distribuiti în aceste cadre.
Și, în sfârșit, două rapoarte de la Yandex despre baza de date Yandex.
Vladislav Kuznetsov -
Vladislav este dezvoltator la Yandex în grupul de platforme distribuite. Yandex Database este un SGBD scalabil orizontal, geo-distribuit, tolerant la erori, care poate rezista la defecțiunile de discuri, servere, rafturi și centre de date fără a pierde consistența. Pentru a asigura toleranța la erori, se utilizează un algoritm proprietar pentru obținerea consensului distribuit, precum și o serie de soluții tehnice, care sunt discutate în detaliu în raport. Raportul poate fi de interes atât pentru dezvoltatorii DBMS, cât și pentru dezvoltatorii de soluții de aplicații bazate pe DBMS.
Semyon Checherinda -
Semyon este un dezvoltator în grupul de platforme distribuite de la Yandex, lucrând la posibilitatea utilizării multi-locatari a instalării YDB.
Baza de date Yandex este concepută pentru interogări OLTP și respectă cerințele ACID pentru un sistem tranzacțional. În acest raport, vom lua în considerare algoritmul de programare a tranzacțiilor care stă la baza sistemului de tranzacții YDB. Să ne uităm la ce entități participă la tranzacții, cine atribuie ordinea globală tranzacțiilor, cum sunt atinse atomicitatea tranzacției, fiabilitatea și un nivel strict de izolare. Folosind o problemă comună ca exemplu, să ne uităm la implementările tranzacțiilor folosind comiteri în două faze și tranzacții deterministe. Să discutăm despre diferențele dintre ele.
Ce urmeaza?
Programul conferinței continuă să fie plin de noi rapoarte. În special, așteptăm un raport de la Nikita Koval () de la JetBrains și Oleg Anastasyev () de la firma Odnoklassniki. Nikita lucrează la algoritmi pentru coroutine în echipa Kotlin, iar Oleg dezvoltă arhitectură și soluții pentru sisteme cu sarcină mare în platforma Odnoklassniki. În plus, există încă un loc liber condiționat, comitetul de program lucrează cu candidații pentru acesta chiar acum.
Conferința Hydra va avea loc în perioada 11-12 iulie la Sankt Petersburg. Biletele sunt disponibile . Vă rugăm să fiți atenți la disponibilitatea biletelor online - dacă din anumite motive nu puteți ajunge la Sankt Petersburg în aceste zile.
Ne vedem la Hydra!
Sursa: www.habr.com