A Hydra Conference será realizada de 11 a 12 de julho em São Petersburgo, dedicada ao desenvolvimento de sistemas paralelos e distribuídos. A característica do Hydra é que ele combina cientistas legais (que geralmente só podem ser encontrados em conferências científicas estrangeiras) e engenheiros praticantes famosos, em um grande programa na interseção entre ciência e prática.
Hydra é uma de nossas conferências mais importantes nos últimos anos. Ela foi precedida por uma preparação muito séria, pela seleção de oradores e relatórios. Na semana passada , uma entrevista com o diretor do grupo JUG.ru, Alexei Fedorov ( 23derevo ), foi divulgada sobre isso.
Já conversamos sobre três participantes importantes, os fundadores da teoria dos sistemas distribuídos - Leslie Lamport, Maurice Herlichi e Michael Scott. É hora de falar mais sobre todo o programa!
Motivação
Se você está programando, de alguma forma está lidando com computação multithreading e distribuída. Especialistas nas áreas relevantes trabalham diretamente com eles, mas implicitamente a distribuição nos olha de qualquer lugar: em qualquer computador com vários núcleos ou serviço distribuído, há algo que executa cálculos em paralelo.
Existem muitas conferências que revelam vários aspectos da programação aplicada. Do outro lado do espectro, temos escolas científicas especiais, no formato de palestras, revelando enormes volumes de teoria complexa. Por exemplo, a escola SPTDC funciona paralelamente à Hydra em São Petersburgo. Na Hydra, tentamos reunir práticas duras, ciência e tudo em sua junção.
Pense nisso: vivemos um momento incrível em que você pode conhecer os fundadores do campo da ciência e engenharia em que estamos envolvidos. Os físicos não encontrarão Newton ou Einstein - o trem saiu. Mas ainda existem pessoas vivendo perto de nós que criaram os fundamentos da teoria dos sistemas distribuídos, criaram linguagens de programação populares e, pela primeira vez, incorporaram tudo isso em protótipos funcionais. Essas pessoas não abandonaram seu trabalho pela metade, agora estão envolvidas em tarefas urgentes em universidades e empresas mundialmente famosas e são as maiores fontes de conhecimento e experiência até o momento.
Por outro lado, a oportunidade de encontrá-los geralmente permanece puramente teórica: poucos de nós podem monitorar constantemente eventos públicos em qualquer Universidade de Rochester, depois correr para os EUA e voltar a uma palestra para Michael Scott. Visitar todos os participantes da Hydra em geral estaria em um estado pequeno, sem contar o abismo do tempo gasto (embora isso pareça uma missão interessante).
Por outro lado, temos muitos engenheiros de ponta que estão trabalhando em problemas urgentes de sistemas distribuídos no momento e eles definitivamente têm algo a dizer. Mas aqui está o problema - eles trabalham e seu tempo é caro. Sim, se você é funcionário da Microsoft, Google ou JetBrains, a probabilidade de encontrar um dos famosos oradores em um evento interno aumenta dramaticamente, mas em geral - não, não, todos os dias isso acontece.
Assim, a conferência Hydra cumpre uma tarefa importante que a maioria de nós não pode realizar - em um só lugar e ao mesmo tempo reúne pessoas cujas idéias ou comunicação com quem podem mudar sua vida. Admito que nem todos precisam de sistemas distribuídos, algumas coisas fundamentais complexas. Você pode programar CRUDs em PHP para o resto de sua vida e permanecer completamente feliz. Mas quem precisa é a sua chance.
Muito tempo se passou desde o primeiro anúncio da conferência Hydra em Habré. Durante esse período, muito trabalho foi feito - e agora temos uma lista de quase todos os relatórios. Nenhum algoritmo de thread único lento, apenas puro hardcore distribuído! Vamos terminar com palavras gerais e ver o que temos em mãos agora.
Keynotes
As palestras iniciam e terminam os dias da conferência. Normalmente, o significado da palestra de abertura é definir o espírito geral e a direção da conferência. A palestra de encerramento define uma linha e explica como conviver com os conhecimentos e habilidades adquiridos durante os dias da conferência. Começo e fim: aquilo que será lembrado melhor de todos e, em geral, é de crescente importância.
Cliff é uma lenda no mundo Java. No final dos anos 90, para a tese de doutorado, ele escreveu um trabalho intitulado Combinando análises, combinando otimizações , que depois de algum tempo se tornou a base do HotSpot JVM Server Compiler. Dois anos depois, ele já trabalhou na Sun Microsystems na JVM e mostrou ao mundo que o JIT tem o direito de existir. Toda a história de que o Java é um dos tempos de execução modernos mais rápidos com as otimizações mais rápidas e inteligentes veio da Cliff Click. No início, acreditava-se que, se algo estivesse disponível para o compilador estático, você não poderia nem tentar dar um jit. Graças ao trabalho de Cliff e da equipe, todos os novos idiomas começaram a ser criados com a idéia de compilação JIT padrão. Obviamente, este não era um trabalho para uma pessoa, mas Cliff desempenhou um papel muito importante nele.
Na palestra de abertura, Cliff falará sobre seu outro empreendimento - o H20 , uma plataforma em memória para aprendizado de máquina distribuído e escalável para aplicações industriais. Ou melhor, sobre o armazenamento distribuído de pares de valores-chave dentro dele. Este é um repositório muito rápido, com muitas propriedades interessantes (a lista exata está na descrição ), o que permite que você use soluções semelhantes na matemática do streaming de big data.
Outra palestra que Cliff dará é a experiência da Memória Transacional da Azul Hardware . Outra parte de sua biografia são dez anos de trabalho na Azul , onde ele atualizou e aprimorou muitas coisas no hardware e na pilha de tecnologia Azul: compiladores JIT, tempo de execução, modelo de encadeamento, manipulação de erros, trabalho de pilha, interrupções de hardware, carregamento de classe e assim por diante. assim - bem, você entendeu.
A parte mais interessante começou quando eles criaram hardware para grandes empresas - um supercomputador para executar Java. Foi algo inovador, aprimorado especificamente para Java, que possui requisitos especiais - barreiras de memória à leitura para coleta de lixo em locais baixos, matrizes com verificação de borda, chamadas virtuais ... Uma das tecnologias mais legais é a memória transacional de hardware. Todos os L1 de qualquer um dos 864 núcleos poderiam participar da gravação transacional, o que é especialmente importante para trabalhar com bloqueios em Java (os blocos sincronizados podem funcionar em paralelo, desde que não haja um conflito real de memória). Mas uma bela idéia colidiu com a dura realidade - e, neste relatório, Cliff explicará por que o HTM e o STM não são muito adequados para as necessidades práticas da computação multithread.
Michael Scott é professor de Ciência da Computação na Universidade de Rochester, com quem o destino o vincula há 34 anos , e na universidade de Wisconsin - Madison, ele foi reitor por cinco anos. Ele está envolvido em pesquisas no campo da programação paralela e distribuída e design de idiomas e ensina isso aos alunos.
O mundo inteiro conhece Michael graças ao livro “Programming Language Pragmatics” , cuja última edição foi lançada relativamente recentemente - em 2015. Seu trabalho “Algoritmos para sincronização escalável em multiprocessadores de memória compartilhada” ganhou o Prêmio Dijkstra como um dos mais famosos no campo da computação distribuída e está abertamente na biblioteca on-line da Universidade de Rochester. Você também pode conhecê-lo como o autor do mesmo algoritmo Michael-Scott em "Algoritmos de fila simultânea simples, rápida e prática, sem bloqueio e bloqueio" .
Quanto ao mundo Java, este é um caso especial: juntamente com Doug Lea, ele desenvolveu esses algoritmos sem bloqueio e filas síncronas que executam as bibliotecas Java. É exatamente isso que a palestra do Dual Data Structures será: a introdução dessas estruturas no Java SE 6 permitiu 10 vezes melhorar o desempenho do java.util.concurrent.ThreadPoolExecutor . Se você tem interesse antecipado sobre o que são essas "estruturas de dados duplos", existe um trabalho correspondente sobre isso.
Maurice Herlichi é o vencedor de dois prêmios Dijkstra. O primeiro é para sincronização sem espera (Brown University) e o segundo, mais recente, é a memória transacional: suporte arquitetônico para estruturas de dados sem bloqueio (Virginia Tech University). O Prêmio Dijkstra é concedido por obras cujo significado e influência são notáveis há pelo menos dez anos e, obviamente, Maurice é um dos especialistas mais famosos da área. Atualmente, ele trabalha como professor na Brown University e tem muitas realizações para um parágrafo inteiro.
Nesta palestra de encerramento, Maurice falará sobre a teoria e a prática dos sistemas distribuídos em blockchain em termos dos clássicos da computação distribuída e como isso simplifica muitos problemas relacionados. Este relatório é exclusivamente sobre o tema da conferência - não sobre exageros de mineração, mas sobre como nosso conhecimento pode ser incrivelmente eficaz e apropriado para aplicar a uma variedade de tarefas.
Em julho de 2017, Maurice chegou à Rússia na escola SPTDC, participou do comício JUG.ru e a gravação pode ser vista no YouTube:
Programa principal
A seguir, será feita uma breve revisão dos relatórios incluídos no programa. Alguns dos relatórios são descritos em detalhes aqui, e outros são mais curtos. Descrições longas foram obtidas principalmente em relatórios em inglês, exigindo links para artigos científicos, termos na Wikipedia e assim por diante. A lista completa pode ser vista no site da conferência . A lista no site será atualizada e complementada.
Leslie Lampport é o autor do trabalho fundamental em computação distribuída. LaTeX significa Lamport TeX. Esta é a primeira vez que ele introduziu o conceito de consistência consistente em 1979, e seu artigo "Como fazer um computador multiprocessador que execute corretamente programas multiprocessos" ganhou o prêmio Dijkstra.
Essa é a parte mais incomum do programa em termos de formato, porque nem sequer é um relatório, mas uma sessão de perguntas e respostas. Quando uma parte significativa da audiência já está familiarizada (ou pode se familiarizar) com todos os tipos de trabalhos baseados na “teoria de Lamport”, seus próprios artigos e relatórios, é importante gastar todo o tempo disponível em comunicação direta.
A idéia é simples - você assiste a dois relatórios no YouTube: “A programação deve ser mais do que codificação” e “Se você não está escrevendo um programa, não use uma linguagem de programação” e prepara pelo menos uma pergunta, e Leslie responde.
O primeiro desses dois vídeos já se transformou em habrosta . Se você não tiver uma hora para assistir ao vídeo, poderá ler rapidamente tudo isso em texto.
Nota: há muito mais vídeos de Leslie Lamport no YouTube. Por exemplo, há um excelente curso TLA + . A versão offline de todo o curso está na página inicial do autor e, no YouTube, ele fez o upload para facilitar a visualização em dispositivos móveis.
Martin Kleppmann é um pesquisador da Universidade de Cambridge, trabalhando no CRDT e na verificação formal de algoritmos. O livro de Martin Designing Data-Intensive Applications , publicado em 2017, provou ser muito bem-sucedido e foi incluído na lista de mais vendidos no campo de armazenamento e processamento de dados. Kevin Scott, CTO da Microsoft, disse uma vez : “Este livro deve ser obrigatório para os engenheiros de desenvolvimento. "Esse é um recurso raro que combina teoria e prática, ajudando os desenvolvedores a projetar e implementar sistemas de infra-estrutura e processamento de dados". Algo semelhante foi dito pelo criador de Kafka e pelo CEO Confluent, Jay Kreps.
Antes de se envolver em pesquisas acadêmicas, Martin trabalhou no setor e co-fundou duas startups de sucesso:
- Rapportive, dedicado a exibir o perfil social dos contatos do seu email, que o LinkedIn comprou em 2012;
- Go Test It, um serviço para verificar automaticamente sites em vários navegadores, que a RedGate comprou em 2009.
Em geral, Martin, embora menos conhecido do que nossos principais participantes, já foi capaz de dar alguma contribuição ao desenvolvimento da computação distribuída e à indústria.
Neste relatório, Martin falará sobre um tópico mais próximo de sua pesquisa acadêmica. No Google Docs e em um sofá semelhante para co-edição de documentos, "co-edição" significa a tarefa de replicação: cada usuário tem sua própria réplica do documento comum, que eles modificam e todas as alterações são enviadas aos outros participantes pela rede. Alterações em documentos offline resultam em inconsistência temporária do documento em relação a outros participantes, e a ressincronização requer tratamento de conflitos. Só para isso, existem tipos de dados replicados sem conflitos (CRDT), de fato - uma coisa bastante nova, cuja essência foi formulada apenas em 2011. Este relatório discute o que aconteceu desde então no mundo do CRDT, quais são as mais recentes conquistas, discute a abordagem para a criação de aplicativos locais primeiro em geral e o uso da biblioteca de código aberto Automerge em particular.
Na próxima semana, publicaremos em Habré uma grande entrevista com Martin, será interessante.
Pedro trabalha na Cisco e desenvolve algoritmos paralelos nos últimos dez anos, incluindo mecanismos de sincronização, estruturas de dados sem bloqueio e sem espera e tudo o que você pode imaginar sobre esse tópico. Seus interesses atuais de pesquisa e engenharia estão focados em Construções Universais, Memória Transacional de Software, Memória Persistente e tecnologias similares que permitem a implementação de aplicativos corretos, escalonáveis e tolerantes a falhas. Ele também é o autor do blog Concurrency Freaks , amplamente conhecido em círculos estreitos.
A maioria dos aplicativos multithread agora trabalha em estruturas de dados paralelas, começando com o uso de filas de mensagens entre atores e terminando com estruturas de dados indexadas em armazenamentos de valores-chave. No Java JDK, eles trabalham com sucesso há muitos anos e, em C ++, estão sendo adicionados lentamente.
A maneira mais simples de implementar uma estrutura de dados paralela é uma implementação seqüencial (thread único) na qual os métodos são protegidos por mutexes. Isso é acessível a qualquer junho, mas tem problemas óbvios com dimensionamento e desempenho. Ao mesmo tempo, as estruturas de dados sem bloqueio e sem espera não apenas lidam melhor com os erros, mas também têm um perfil de desempenho mais bem-sucedido - no entanto, seu desenvolvimento requer conhecimento profundo e adaptação a um aplicativo específico. Uma linha de código errada é suficiente para quebrar tudo.
Como tornar até mesmo um não especialista capaz de projetar e implementar essas estruturas de dados? Sabe-se que qualquer algoritmo seqüencial pode ser tornado seguro para threads usando um design universal ou memória transacional. Por um lado, eles podem diminuir o limite para a entrada nesta tarefa. No entanto, ambas as soluções tendem a levar a uma implementação ineficiente. Pedro falará sobre como eles conseguiram tornar esses projetos mais eficientes e como eles podem ser usados para seus algoritmos.
Heidi Howard é, como Martin, um pesquisador de sistemas distribuídos da Universidade de Cambridge. Sua especialização é consistência, tolerância a falhas, desempenho e consenso distribuído. Ela é mais conhecida por generalizar o algoritmo Paxos chamado Paxos Flexível .
Lembre-se de que Paxos é uma família de protocolos para resolver o problema de consenso em uma rede de computadores não confiáveis, baseados no trabalho de Leslie Lamport. Assim, alguns de nossos palestrantes estão trabalhando em tarefas originalmente propostas por outros palestrantes - e isso é maravilhoso.
A capacidade de encontrar consenso entre vários hosts - para endereçamento, seleção de líderes, bloqueio ou coordenação - é uma questão fundamental nos modernos sistemas distribuídos. O Paxos agora é a principal maneira de resolver os problemas de busca de consenso, e muita pesquisa está sendo realizada a fim de expandir e otimizar o algoritmo para várias necessidades práticas.
Neste relatório, revisaremos a base teórica de Paxos, enfraquecendo os requisitos iniciais e generalizando o algoritmo. Veremos que Paxos, de fato, é apenas uma opção entre uma enorme variedade de abordagens de consenso, e que outros pontos no espectro também são muito úteis para a construção de bons sistemas distribuídos.
Alex é especialista em bancos de dados e sistemas de armazenamento e, mais importante para nós, é um colaborador da Cassandra . Juntamente com O'Reilly, ele está atualmente trabalhando no livro Database Internals.
Para sistemas com eventual consistência (na terminologia russa - "consistência a longo prazo"), depois que um nó é descartado ou a rede é dividida, o seguinte dilema deve ser resolvido: continue a atender solicitações, sacrificando a consistência ou se recuse a atendê-las e sacrifique a disponibilidade. Nesse sistema, os quóruns que se sobrepõem a subconjuntos de nós e garantir que pelo menos um nó contenha o valor mais recente pode ser uma boa solução de limite. Você pode sobreviver a falhas e perda de conexão com alguns nós, continuando a responder com os valores mais recentes.
No entanto, tudo tem um preço. Um esquema de replicação de quorum significa um aumento no custo de armazenamento: você precisa armazenar dados redundantes em vários nós de uma só vez para garantir um número suficiente de cópias disponíveis no momento do problema. Acontece que você não pode armazenar todos os dados em todas as réplicas. Você pode reduzir a carga no armazenamento mantendo os dados em apenas parte dos nós e usar nós especiais (réplica transitória) para cenários de processamento de falhas.
No decorrer do relatório, examinaremos as réplicas de testemunhas , o esquema de replicação usado pela Spanner e a Megastore e a implementação desse conceito no Apache Cassandra sob os nomes Replicação transitória e quorum barato .
Dmitry é um desenvolvedor do Google que trabalha no teste dinâmico de C / C ++ e Go - Address / Memory / ThreadSanitizer e em ferramentas similares para o kernel do Linux. O Go possui um agendador de goroutine escalável, pesquisador de rede e coletor de lixo paralelo. Ele é especialista em multithreading, autor de uma dúzia de novos algoritmos não-bloqueadores e é o proprietário do Intel Black Belt .
Agora um pouco sobre o próprio relatório. O Go possui suporte nativo para multithreading na forma de goroutines (threads leves) e canais (filas FIFO). Graças a esses mecanismos, é muito fácil e agradável para os usuários escrever aplicativos multithread modernos, e parece mágico. Como entendemos, não há mágica aqui. Neste relatório, Dmitry se aprofundará nos meandros do trabalho do agendador Go e mostrará os segredos da implementação dessa “mágica”. Primeiro, ele dará uma visão geral dos principais componentes do agendador e informará como ele funciona. Além disso, examinaremos mais de perto alguns aspectos, como a estratégia de estacionamento / desembalagem e o processamento de chamadas do sistema de bloqueio. Por fim, Dmitry falará um pouco sobre possíveis melhorias no agendador.
Dmitry trabalhou na terceirização por quase 9 anos, sem perder o contato com a universidade e a comunidade científica. A análise de big data em Odnoklassniki foi uma oportunidade única para ele combinar treinamento teórico e fundamento científico com o desenvolvimento de produtos reais e procurados.
A análise de gráficos distribuídos foi e continua sendo uma tarefa difícil: quando se torna necessário obter informações sobre as conexões de um vértice vizinho, os dados geralmente precisam ser destilados entre as máquinas, o que leva a um aumento no tempo de execução e na carga da infraestrutura de rede. Neste relatório, veremos como você pode obter velocidade de processamento significativa usando estruturas de dados probabilísticas ou fatos como a simetria de um gráfico de amizade em uma rede social. Tudo isso é ilustrado pelos exemplos de código do Apache Spark.
Denis é desenvolvedor do Cosmos DB , especialista na verificação de modelos de consistência, em algoritmos de consenso e em transações distribuídas. Agora ele trabalha na Microsoft e, antes disso, estava envolvido em sistemas distribuídos na Amazon e Yandex.
Neste relatório, vamos nos familiarizar com os protocolos de transações distribuídas inventados nos últimos anos, que podem ser implementados no lado do cliente em cima de qualquer armazenamento de dados que suporte atualização condicional (comparar e definir). O ponto principal é que a vida não termina com uma confirmação de duas fases, as transações podem ser adicionadas no topo de qualquer banco de dados - no nível do aplicativo, mas diferentes protocolos (2PC, Percolator, RAMP) têm vantagens e desvantagens diferentes e não nos são dados gratuitamente.
Alexey ( zaleslaw ) é nosso orador de longa data e membro de comitês de programas em outras conferências. Formador na EPAM Systems, é amigo do Hadoop / Spark e de outros grandes eventos desde 2012.
Neste relatório, Alexey falará sobre os problemas de adaptação de algoritmos clássicos de aprendizado de máquina para execução distribuída com base em sua experiência de trabalho com o Apache Spark ML, Apache Mahout, Apache Flink ML e a experiência na criação do Apache Ignite ML. Alexey também falará sobre a implementação de algoritmos ML distribuídos nessas estruturas.
E finalmente - dois relatórios da Yandex sobre o Yandex Database.
Vladislav é desenvolvedor de Yandex em um grupo de plataformas distribuídas. O Yandex Database é um DBMS tolerante a falhas, distribuído geograficamente e escalonável horizontalmente, capaz de suportar a falha de discos, servidores, racks e data centers sem comprometer a consistência. Para garantir a tolerância a falhas, é usado um algoritmo de consenso distribuído proprietário, além de várias soluções técnicas discutidas em detalhes no relatório. O relatório pode ser de interesse para desenvolvedores de DBMS e desenvolvedores de soluções de aplicativos baseadas em DBMS.
Semyon - um desenvolvedor de um grupo de uma plataforma distribuída em Yandex, está trabalhando na possibilidade de uso de vários locatários da instalação do YDB.
O Yandex Database foi desenvolvido para solicitações OLTP e atende aos requisitos de ACID para um sistema de transações. No relatório, consideraremos o algoritmo de planejamento de transações subjacente ao sistema de transações YDB. Analisaremos quais entidades participam das transações, quem atribui às transações uma ordem global, como a atomicidade das transações, a confiabilidade e um nível de isolamento rigoroso são alcançados. Usando um exemplo de um problema comum, consideramos a implementação de transações usando uma confirmação de duas fases e transações determinísticas. Discutimos suas diferenças.
O que vem a seguir?
O programa da conferência continua sendo preenchido com novos relatórios. Em particular, esperamos um relatório de Nikita Koval ( ndkoval ) da JetBrains e Oleg Anastasiev ( m0nstermind ) de Odnoklassniki. Nikita está envolvida em algoritmos para corotinas na equipe Kotlin, e Oleg está desenvolvendo arquitetura e soluções para sistemas altamente carregados na plataforma Odnoklassniki. Além disso, há mais uma vaga condicionalmente vazia, com candidatos para os quais o comitê do programa está trabalhando no momento.
A Conferência Hydra será realizada de 11 a 12 de julho em São Petersburgo. Os ingressos podem ser adquiridos no site oficial . Chamamos a atenção para a disponibilidade de ingressos on-line - se, por algum motivo, você não conseguir viver ao vivo em São Petersburgo atualmente.
Encontre-me na Hydra!