Os días 11 e 12 de xullo terá lugar unha conferencia en San Petersburgo , dedicada ao desenvolvemento de sistemas paralelos e distribuídos. O truco de Hydra é que une científicos xeniais (que normalmente só se poden atopar en conferencias científicas estranxeiras) e enxeñeiros en exercicio famosos nun gran programa na intersección da ciencia e a práctica.
Hydra é unha das nosas conferencias máis importantes dos últimos anos. Estivo precedido dunha moi seria preparación, selección de relatores e relatorios. A semana pasada sobre isto co director do Grupo JUG.ru, Alexey Fedorov ().
Nós preto de tres participantes importantes, os fundadores da teoría dos sistemas distribuídos - Leslie Lamport, Maurice Herlihy e Michael Scott. Chegou o momento de falar máis polo miúdo de todo o programa!
Motivación
Se estás involucrado na programación, dun xeito ou doutro estás lidando con multithreading e computación distribuída. Os expertos dos campos relevantes traballan con eles directamente, pero, de forma implícita, a distribución está a mirarnos desde todas partes: en calquera ordenador multinúcleo ou servizo distribuído hai algo que realiza cálculos en paralelo.
Hai moitas conferencias que abarcan diversos aspectos da programación de aplicacións. Do outro lado do espectro, temos escolas científicas especializadas que revelan grandes cantidades de teoría complexa en formato de conferencia. Por exemplo, en paralelo con Hydra en San Petersburgo hai . Na conferencia Hydra, tentamos reunir a práctica dura, a ciencia e todo o que se atopa na súa intersección.
Pensa nisto: vivimos nunha época incrible na que podes coñecer en persoa aos fundadores do campo da ciencia e da enxeñaría que estudamos. Os físicos non se atoparán nin con Newton nin con Einstein: o tren saíu. Pero ao noso lado aínda viven os que crearon os fundamentos da teoría dos sistemas distribuídos, inventaron linguaxes de programación populares e plasmaron todo isto por primeira vez en prototipos de traballo. Estas persoas non deixaron o seu traballo á metade, agora mesmo están traballando en cuestións urxentes en universidades e empresas de renome mundial, e son as maiores fontes de coñecemento e experiencia na actualidade.
Por outra banda, a oportunidade de coñecelos adoita ser puramente teórica: poucos de nós podemos supervisar constantemente eventos públicos nalgunha Universidade de Rochester, e logo correr cara a EE. UU. e volver para unha charla con Michael Scott. Visitar a todos os membros de Hydra custaría unha pequena fortuna, sen contar o abismo do tempo perdido (aínda que pareza unha misión interesante).
Por outra banda, temos moitos enxeñeiros destacados que están traballando en problemas urxentes en sistemas distribuídos agora mesmo, e definitivamente teñen moito que contar. Pero aquí está o problema: eles работают, e o seu tempo é valioso. Si, se es un empregado de Microsoft, Google ou JetBrains, a probabilidade de atoparse cun dos oradores famosos nun evento interno aumenta drasticamente, pero en xeral, non, isto non ocorre todos os días.
Deste xeito, a Conferencia Hydra realiza unha tarefa importante que a maioría de nós non podemos facer pola nosa conta: nun lugar e á vez, reúne a persoas cuxas ideas ou interaccións poden cambiar a túa vida. Admito que non todos necesitan sistemas distribuídos ou algunhas cousas fundamentais complexas. Podes programar CRUD en PHP durante o resto da túa vida e permanecer completamente feliz. Pero quen o necesite, esta é a túa oportunidade.
Pasou bastante tempo dende o primeiro anuncio da conferencia Hydra sobre Habré. Durante este tempo, traballouse moito, e agora temos unha lista de case todos os informes. Non hai algoritmos lentos dun só fío, só puro hardcore distribuído. Rematemos con palabras xerais e vexamos o que temos agora entre mans.
Keynotes
As conferencias inician e rematan os días da conferencia. Normalmente, o obxectivo dunha conferencia de apertura é establecer o espírito xeral e a dirección da conferencia. A charla de clausura traza unha liña e explica como podemos convivir cos coñecementos e habilidades adquiridos durante o congreso. O principio e o final: o que mellor se lembra, e en xeral, ten maior importancia.
Cliff Click
Cliff é unha lenda no mundo de Java. A finais dos 90, para a súa tese de doutoramento, escribiu un traballo titulado , que tempo despois converteuse na base para HotSpot JVM Server Compiler. Dous anos despois, xa estaba traballando en Sun Microsystems na JVM e mostrou a todo o mundo que JIT ten dereito a existir. Toda esta historia sobre como Java é un dos tempos de execución modernos máis rápidos coas optimizacións máis intelixentes e rápidas veu de Cliff Click. Ao principio, críase que se algo era accesible para un compilador estático, nin sequera tes que tentar facelo. Grazas ao traballo de Cliff e do equipo, comezaron a crearse todos os novos idiomas coa idea de compilar JIT por defecto. Por suposto, este non era un traballo dun só home, pero Cliff xogou un papel moi importante nel.
Na conferencia de apertura, Cliff falará sobre o seu outro esforzo: , unha plataforma en memoria para a aprendizaxe automática distribuída e escalable para aplicacións industriais. Ou, máis precisamente, sobre o almacenamento distribuído de pares clave-valor no seu interior. Este é un almacenamento moi rápido con moitas propiedades interesantes (a lista exacta está en ), que permiten o uso de solucións similares nas matemáticas de big data streaming.
Outro informe que dará Cliff é... . Outra parte da súa biografía - dez anos , onde actualizou e mellorou moitas cousas na pila de hardware e tecnoloxía Azul: compiladores JIT, tempo de execución, modelo de fíos, tratamento de erros, manexo de pilas, interrupcións de hardware, carga de clases, etc. idea.
A parte máis interesante comezou cando fabricaron hardware para unha gran empresa: unha supercomputadora para executar Java. Foi algo bastante innovador, feito especialmente para Java, que ten requisitos especiais: barreiras de memoria de lectura para a recollida de lixo en pouca pausa, matrices con comprobación de límites, chamadas virtuais... Unha das tecnoloxías máis xeniais é a memoria transaccional de hardware. Toda a L1 de calquera dos 864 núcleos podería participar na escritura transaccional, o que é especialmente importante para traballar con bloqueos en Java (os bloques sincronizados poden funcionar en paralelo sempre que non haxa un conflito de memoria real). Pero a fermosa idea foi esmagada pola dura realidade, e nesta charla Cliff dirá por que HTM e STM non son moi adecuados para as necesidades prácticas da informática multiproceso.
Michael Scott -
- Profesor de Informática na Universidade de Rochester, con quen o destino o conectou , e na súa universidade natal de Wisconsin-Madison, foi decano durante cinco anos. Investiga e ensina aos estudantes sobre programación paralela e distribuída e deseño de linguaxes.
O mundo enteiro coñece a Michael grazas ao libro de texto , cuxa última edición foi publicada relativamente recentemente - en 2015. O seu traballo recibido como unha das máis famosas no campo da computación distribuída e na Biblioteca en liña da Universidade de Rochester. Tamén podes coñecelo como o autor do propio algoritmo de Michael-Scott .
En canto ao mundo Java, este é un caso especial: xunto con Doug Lea desenvolveu os algoritmos non bloqueadores e as colas sincrónicas nas que traballan as bibliotecas Java. Isto é exactamente o que tratará a charla "Estruturas de datos duales": a introdución destas estruturas en Java SE 6 mellorou o rendemento en 10 veces java.util.concurrent.ThreadPoolExecutor. Se estás a preguntar de antemán cales son estas "estruturas de datos duales", entón hai información sobre iso .
Maurice Herlihy -
- gañador de dous premios Dijkstra. O primeiro é para traballar (Brown University), e a segunda, máis recente - (Universidade Tecnolóxica de Virginia). O Premio Dijkstra recoñece traballos cuxo significado e impacto son visibles durante polo menos dez anos, e Maurice é claramente un dos expertos máis recoñecidos na materia. Actualmente traballa como profesor na Universidade de Brown e ten unha longa lista de logros.
Nesta charla de peche, Maurice falará da teoría e práctica dos sistemas distribuídos blockchain desde o punto de vista dos clásicos da computación distribuída e de como simplifica moitos problemas relacionados. Este é un informe exclusivamente sobre o tema da conferencia, non sobre o bombo da minería, senón sobre como o noso coñecemento se pode utilizar de forma sorprendente e eficaz en relación a unha variedade de tarefas.
En xullo de 2017, Maurice xa veu a Rusia para asistir á escola SPTDC, participou na reunión JUG.ru e a gravación pódese ver en YouTube:
Programa principal
A continuación farase un pequeno resumo dos informes incluídos no programa. Algúns dos informes descríbense aquí en detalle, outros máis brevemente. As descricións longas dirixíanse principalmente a informes en inglés que requirían ligazóns a artigos científicos, termos na Wikipedia, etc. A lista completa está dispoñible . A lista na páxina web será actualizada e completada.
Leslie Lampport -
Leslie Lamport é a autora de obras fundamentais en computación distribuída. significa "Lamport TeX". Foi el quen primeiro, por 1979, introduciu o concepto , e o seu artigo recibiu o Premio Dijkstra.
Esta é a parte máis inusual do programa en canto ao formato, porque nin sequera se trata dun informe, senón dunha sesión de preguntas e respostas. Cando unha parte importante do público xa está familiarizado (ou pode familiarizarse) con todo tipo de obras baseadas na “teoría de Lampport”, os seus propios artigos e informes, é máis importante dedicar todo o tempo dispoñible á comunicación directa.
A idea é sinxela: miras dous informes en YouTube: и e prepara polo menos unha pregunta, e Leslie responde.
O primeiro destes dous vídeos xa o temos . Se non tes unha hora de tempo para ver o vídeo, podes lelo todo rapidamente en forma de texto.
Nota: Hai moitos máis vídeos de Leslie Lampport en YouTube. Por exemplo, hai un gran . Unha versión sen conexión de todo este curso está dispoñible en , e cargouno a YouTube para facilitar a visualización en dispositivos móbiles.
Martin Kleppmann -
Martin Kleppmann é un investigador da Universidade de Cambridge que traballa en CRDT e verificación formal de algoritmos. Libro de Martín , publicado en 2017, demostrou ser moi exitoso e entrou nas listas de bestsellers no campo do almacenamento e procesamento de datos. Kevin Scott, CTO de Microsoft, : "Este libro debería ser imprescindible para os enxeñeiros de software. Este é un recurso raro que combina teoría e práctica para axudar aos desenvolvedores máis intelixentes a deseñar e implementar infraestruturas e sistemas de datos". O creador de Kafka e CTO de Confluent, Jay Kreps, dixo algo semellante.
Antes de pasar á investigación académica, Martin traballou na industria e co-fundou dúas empresas emergentes de éxito:
- Relativo, dedicado a mostrar o perfil social dos contactos do teu correo electrónico, que LinkedIn comprou en 2012;
- Go Test It, un servizo para probar automaticamente sitios web en varios navegadores, que RedGate comprou en 2009.
En xeral, Martin, aínda que menos famoso que as nosas ponencias, xa puido facer algunha contribución ao desenvolvemento da computación distribuída e á industria.
Nesta charla, Martín falará dun tema máis próximo á súa investigación académica. En Google Docs e sofás de coedición de documentos similares, a "edición colaborativa" refírese a unha tarefa de replicación: cada usuario ten a súa propia réplica do documento compartido, que logo modifica, e todos os cambios son enviados pola rede ao resto dos usuarios. participantes. Os cambios nos documentos fóra de liña provocan unha inconsistencia temporal do documento en relación con outros participantes, e a resincronización require o tratamento dos conflitos. Para iso existen exactamente (CRDT), de feito, é unha cousa bastante nova, cuxa esencia foi formulada só en 2011. Nesta charla fálase do que aconteceu dende entón no mundo da CRDT, cales son os avances máis recentes, o enfoque para crear aplicacións de primeira liña local en xeral e o uso dunha biblioteca de código aberto. en particular.
A vindeira semana publicaremos unha longa entrevista a Martín en Habré, será interesante.
Pedro Ramalhete -
Pedro traballa en Cisco e leva desenvolvendo algoritmos paralelos durante os últimos dez anos, incluíndo mecanismos de sincronización, estruturas de datos sen bloqueo e sen espera e todo o que poidas imaxinar sobre este tema. Os seus intereses actuais de investigación e enxeñería céntranse nas construcións universais, a memoria transaccional de software, a memoria persistente e tecnoloxías similares que permiten aplicacións correctas, escalables e tolerantes a fallos. Tamén é autor dun blog moi coñecido nos círculos estreitos .
A maioría das aplicacións multiproceso agora execútanse en estruturas de datos paralelas, desde o uso de colas de mensaxes entre actores ata estruturas de datos indexadas en almacéns de valores clave. Levan moitos anos traballando con éxito no JDK de Java, e pouco a pouco vanse engadindo a C++.
A forma máis sinxela de implementar unha estrutura de datos paralela é unha implementación secuencial (dun fío único) na que os métodos están protexidos por mutexes. Isto é accesible para calquera xuño, pero ten problemas evidentes coa escala e o rendemento. Ao mesmo tempo, as estruturas de datos sen bloqueo e sen espera non só se enfrontan mellor aos erros, senón que tamén teñen un mellor perfil de rendemento; non obstante, o seu desenvolvemento require unha profunda experiencia e adaptación a unha aplicación específica. Unha liña incorrecta de código é suficiente para romper todo.
Como podemos facer que mesmo un non experto poida deseñar e implementar tales estruturas de datos? Sábese que calquera algoritmo secuencial pode ser seguro para fíos usando calquera dos dous , ou memoria transaccional. Por unha banda, poden reducir a barreira de entrada para resolver este problema. Non obstante, ambas as solucións adoitan levar a unha implementación ineficaz. Pedro falará sobre como conseguiron que estes deseños sexan máis eficientes e como podes utilizalos para os teus algoritmos.
Heidi Howard -
Heidi Howard é, como Martin, unha investigadora de sistemas distribuídos na Universidade de Cambridge. As súas especialidades son a consistencia, a tolerancia ás fallas, o rendemento e o consenso distribuído. É máis coñecida pola súa xeneralización do algoritmo de Paxos chamado .
Lembre que é unha familia de protocolos para resolver o problema do consenso nunha rede de ordenadores pouco fiables, baseada no traballo de Leslie Lamport. Así, algúns dos nosos oradores están a traballar en problemas que foron propostos orixinalmente polos nosos outros falantes, e isto é marabilloso.
A capacidade de atopar consenso entre varios anfitrións (para o enderezo, a elección do líder, o bloqueo ou a coordinación) é unha cuestión fundamental nos sistemas distribuídos modernos. Paxos é agora a principal forma de resolver os problemas de consenso, e hai moitas investigacións ao seu redor para ampliar e optimizar o algoritmo para diversas necesidades prácticas.
Nesta charla, repasaremos as bases teóricas de Paxos, relaxando os requisitos orixinais e xeneralizando o algoritmo. Veremos que Paxos é esencialmente só unha opción entre unha gran variedade de enfoques de consenso, e que outros puntos do espectro tamén son moi útiles para construír bos sistemas distribuídos.
Alex Petrov -
Alex é un especialista en bases de datos e sistemas de almacenamento e, o que é máis importante para nós, é un comisario . Actualmente está a traballar nun libro, Database Internals, con O'Reilly.
Para sistemas con (na terminoloxía rusa - "coherencia definitiva"), despois de que un nodo falle ou unha división da rede, cómpre resolver o seguinte dilema: ou seguir executando solicitudes, sacrificando a coherencia ou rexeitar executalas e sacrificar a dispoñibilidade. Neste sistema, os quórums, os subconxuntos de nodos superpostos e asegurarse de que polo menos un nodo conteña o valor máis recente, pode ser unha boa solución de borde. Pode sobrevivir a fallos e perdas de conectividade con algúns nodos mentres segue respondendo cos valores máis recentes.
Con todo, todo ten o seu prezo. Un esquema de replicación de quórum significa un aumento dos custos de almacenamento: os datos redundantes deben almacenarse en varios nodos á vez para garantir que hai suficientes copias dispoñibles cando se produce un problema. Resulta que non tes que almacenar todos os datos en todas as réplicas. Pode reducir a carga do almacenamento se almacena datos só nunha parte dos nodos e utiliza nós especiais (Réplica transitoria) para os escenarios de tratamento de fallos.
Durante o transcurso do informe teremos en conta , o esquema de replicación utilizado en и , e a implementación deste concepto en Apache Cassandra chamado .
Dmitry Vyukov -
Dmitry é un programador de Google que traballa en probas dinámicas para C/C++ e Go - Address/Memory/ThreadSanitizer e ferramentas similares para o núcleo de Linux. Contribuíu a Go un programador de goroutine escalable, un sondeador de rede e un colector de lixo paralelo. É un experto en multithreading, o autor dunha ducia de novos algoritmos sen bloqueo e é o propietario de Intel.
Agora un pouco sobre o informe en si. O idioma Go ten soporte nativo para multithreading en forma de goroutines (fíos lixeiros) e canles (colas FIFO). Estes mecanismos fan que os usuarios poidan escribir aplicacións modernas multiproceso, e parece máxico. Como entendemos, aquí non hai maxia. Nesta charla, Dmitry afondará nas complejidades do programador Go e mostrará os segredos para implementar esta "maxia". En primeiro lugar, dará unha visión xeral dos principais compoñentes do planificador e dirá como funciona. A continuación, analizaremos con máis detalle aspectos individuais como a estratexia de aparcamento/desestacionamento e o manexo das chamadas do sistema de bloqueo. Finalmente, Dmitry falará un pouco sobre as posibles melloras do planificador.
Dmitry Bugaichenko -
Dmitry traballou na subcontratación durante case 9 anos sen perder o contacto coa universidade e a comunidade científica. A análise de big data en Odnoklassniki converteuse para el nunha oportunidade única de combinar a formación teórica e a base científica co desenvolvemento de produtos reais e demandados.
A análise de gráficos distribuídos foi e segue sendo unha tarefa difícil: cando se fai necesario obter información sobre as conexións dun vértice veciño, os datos moitas veces teñen que ser transferidos entre máquinas, o que leva a un aumento do tempo de execución e da carga na infraestrutura da rede. Nesta charla, veremos como podes conseguir velocidades de procesamento significativas utilizando estruturas de datos probabilísticos ou feitos como a simetría do gráfico de amizade nunha rede social. Todo isto ilustrarase con exemplos de código en Apache Spark.
Denis Rystsov -
Denis - desenvolvedor , un experto en comprobar modelos de coherencia, algoritmos de consenso e transaccións distribuídas. Actualmente traballa en Microsoft, e antes traballou en sistemas distribuídos en Amazon e Yandex.
Nesta charla, daremos unha ollada aos protocolos de transaccións distribuídas que se inventaron nos últimos anos, que se poden implementar no lado do cliente enriba de calquera almacén de datos que admita actualizacións condicionais (comparar e establecer). A conclusión é que a vida non remata cun compromiso en dúas fases, as transaccións pódense engadir enriba de calquera base de datos, a nivel de aplicación, pero os diferentes protocolos (2PC, Percolator, RAMP) teñen diferentes compensacións e non se nos dan. gratis.
Alexey Zinoviev -
Alexei () é un orador de longa data e membro dos comités de programas noutras conferencias. Adestrador en prácticas en EPAM Systems e é amigo de Hadoop/Spark e outros big data desde 2012.
Nesta charla, Alexey falará sobre os problemas de adaptación dos algoritmos clásicos de aprendizaxe automática para a súa execución en modo distribuído baseándose na súa experiencia traballando con Apache Spark ML, Apache Mahout, Apache Flink ML e a experiencia de crear Apache Ignite ML. Alexey tamén falará sobre a implementación de algoritmos de ML distribuídos nestes marcos.
E, finalmente, dous informes de Yandex sobre Yandex Database.
Vladislav Kuznetsov -
Vladislav é un programador de Yandex no grupo de plataformas distribuídas. Yandex Database é un DBMS escalable horizontalmente, xeodistribuído e tolerante a fallos que pode soportar a falla de discos, servidores, racks e centros de datos sen perder consistencia. Para garantir a tolerancia a fallos, utilízase un algoritmo propietario para lograr un consenso distribuído, así como unha serie de solucións técnicas, que se comentan en detalle no informe. O informe pode ser de interese tanto para os desenvolvedores de DBMS como para os desenvolvedores de solucións de aplicacións baseadas en DBMS.
Semyon Checherinda -
Semyon é un desenvolvedor do grupo de plataformas distribuídas de Yandex, que traballa na posibilidade de utilizar a instalación de YDB en varios inquilinos.
Yandex Database está deseñada para consultas OLTP e cumpre cos requisitos ACID para un sistema transaccional. Neste informe, consideraremos o algoritmo de programación de transaccións que subxace ao sistema de transaccións YDB. Vexamos que entidades participan nas transaccións, quen asigna orde global ás transaccións, como se consegue a atomicidade das transaccións, a fiabilidade e un estrito nivel de illamento. Usando un problema común como exemplo, vexamos as implementacións de transaccións usando commits en dúas fases e transaccións deterministas. Comentemos as súas diferenzas.
Cal é o próximo?
O programa do congreso segue cheo de novos relatorios. En particular, esperamos un informe de Nikita Koval () de JetBrains e Oleg Anastasyev () da empresa Odnoklassniki. Nikita traballa en algoritmos para corrutinas no equipo de Kotlin, e Oleg desenvolve arquitectura e solucións para sistemas de alta carga na plataforma Odnoklassniki. Ademais, hai 1 praza máis baleira condicionalmente, o comité do programa está traballando cos candidatos para iso agora mesmo.
A conferencia Hydra terá lugar do 11 ao 12 de xullo en San Petersburgo. As entradas están dispoñibles . Por favor, preste atención á dispoñibilidade de entradas en liña, se por algún motivo non pode chegar a San Petersburgo estes días.
Vémonos en Hydra!
Fonte: www.habr.com