Martin Kleppman é um pesquisador da Universidade de Cambridge que trabalha no CRDT e na verificação formal de algoritmos. Seu livro
Designing Data-Intensive Applications , publicado em 2017, tornou-se um best-seller em 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 pensar mais profundamente sobre o design e a implementação de infra-estrutura e sistemas de processamento de dados". Algo semelhante foi dito por Jay Kreps, criador do Apache Kafka e CEO Confluent.
Antes de iniciar a pesquisa acadêmica, Martin trabalhou no setor e co-fundou duas startups de sucesso: Rapportive (comprado pelo LinkedIn em 2012) e Go Test It (comprado pela RedGate).
Este habrapost é uma entrevista detalhada com Martin. Exemplos de tópicos de discussão:
- Transição de negócios para pesquisa acadêmica;
- Pré-requisitos para escrever projetando aplicativos com uso intensivo de dados;
- Bom senso contra hype artificial e ferramentas de publicidade;
- Desnecessidade do teorema da PAC e outros erros do setor;
- A utilidade da descentralização;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Novo CRDT. Verificação formal em Isabelle;
- Discussão sobre o fornecimento de eventos. Abordagem de baixo nível. Transações XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Usando tudo na vida real;
- O limite para entrar nos relatórios de Martin e na conferência Hydra.
A entrevista foi conduzida por
Vadim Tsesko (
@incubos ) - um desenvolvedor líder da equipe da empresa Odnoklassniki Platform. Os interesses científicos e de engenharia da Vadim estão relacionados a sistemas distribuídos e data warehouses, bem como à verificação de sistemas de software.
Do negócio à pesquisa acadêmica
Vadim : Eu gostaria de começar com uma pergunta que é muito importante para mim pessoalmente. Você fundou o Go Test It e o Rapportive e, durante muito tempo, se envolveu no desenvolvimento de grandes sistemas no LinkedIn, mas decidiu abandonar o desenvolvimento comercial e fazer pesquisas na universidade. Você poderia me dizer o que o levou a isso? Quais são os benefícios de trabalhar em uma universidade e o que você sacrificou?
Martin : Foi uma transição muito interessante. Pelo que entendi, você está interessado na minha decisão devido ao fato de poucas pessoas estarem saindo para a pesquisa acadêmica a partir do desenvolvimento comercial, e muito mais frequentemente há um movimento na direção oposta. Isso é compreensível, pois os ganhos nas universidades são significativamente menores do que nos negócios. Pessoalmente, sou atraído para a posição de pesquisador pelo fato de poder decidir quais tópicos trabalhar, e faço essa escolha com base no que me parece interessante e importante, mesmo que trabalhar em um tópico não prometa obter lucro nos próximos 6. meses. Tudo o que você trabalha em uma empresa deve ser vendido de uma forma ou de outra. No momento, estou trabalhando em tópicos importantes para o futuro da Internet e do software, mas nosso entendimento deles ainda não é profundo o suficiente para criar um produto acabado. Até o momento, nem sequer temos uma idéia geral de como essas tecnologias devem funcionar. Como esses estudos são fundamentais, decidi que é melhor conduzi-los na universidade, e não na empresa: a universidade tem mais liberdade, aí você pode fazer coisas que não trarão lucro por mais 10 anos. O horizonte de planejamento é muito mais amplo.
Livro que cria aplicativos intensivos em dados
Vadim : Voltaremos definitivamente ao tópico da pesquisa, mas, por enquanto, vamos falar sobre o seu livro,
Designing Data-Intensive Applications . Na minha opinião, este é um dos melhores guias de sistemas distribuídos modernos, quase uma enciclopédia: lista todas as conquistas mais significativas que existem hoje.
Martin : Obrigado, fico feliz que tenha sido útil.
Vadim : É improvável que nossos leitores ainda não estejam familiarizados com isso, mas, apenas no caso, vamos discutir as conquistas mais significativas no campo dos sistemas distribuídos sobre os quais você está escrevendo.
Martin : Na verdade, ao escrever este livro, não estabeleci uma meta para descrever determinadas tecnologias. Em vez disso, eu queria fazer um guia em todo o mundo dos sistemas usados para armazenar e processar dados. Agora, há um grande número de bancos de dados, processadores de fluxo, ferramentas de processamento em lote, todos os tipos de ferramentas de replicação e similares, por isso é muito difícil compor uma imagem geral dessa área. E se você precisar de um banco de dados para resolver um problema específico, é difícil escolher um dos muitos existentes. Muitos livros escritos sobre tais sistemas são simplesmente inúteis neste caso. Por exemplo, em um livro sobre o Apache Cassandra, pode ser escrito sobre o quão maravilhoso é o Cassandra, mas nada será dito sobre tarefas para as quais não é adequado. Portanto, em meu livro, tento identificar as perguntas básicas que você precisa se perguntar ao escrever sistemas grandes. As respostas a essas perguntas ajudarão a determinar quais tecnologias são mais adequadas para resolver o problema atual e quais não são muito boas. O principal é que não há tecnologia que possa fazer tudo. Estou tentando mostrar quais são as vantagens e desvantagens de diferentes tecnologias em diferentes contextos.
Vadim : De fato, muitas tecnologias têm características e funcionalidades comuns e fornecem o mesmo modelo de dados. Ao mesmo tempo, não se pode confiar na publicidade e, para entender a estrutura interna do sistema, é preciso ler não apenas relatórios e documentação técnicos, mas também códigos-fonte.
Bom senso versus propaganda artificial e publicidade de ferramentas
Martin : Além disso, você geralmente precisa ler nas entrelinhas, porque a documentação não diz para quais tarefas o banco de dados não é muito adequado. De fato, qualquer banco de dados tem suas próprias limitações, portanto, você deve sempre saber quais. Muitas vezes, você precisa ler os guias de implantação e reconstruir a operação interna do sistema.
Vadim : Sim, este é um ótimo exemplo. Você não acha que nesta área não existe vocabulário comum suficiente ou um único conjunto de critérios, usando os quais seria possível comparar soluções diferentes para uma tarefa? Agora, nomes diferentes são usados para as mesmas coisas, e muitos aspectos que devem ser claramente e claramente explicitados não são mencionados - por exemplo, garantias de transacionalidade.
Martin : Sim, é mesmo. Infelizmente, em nossa indústria, muitas vezes há excitação excessiva em relação a diferentes instrumentos. O que é compreensível, pois essas ferramentas são criadas por empresas interessadas em promover seus produtos. Portanto, essas empresas enviam pessoas para conferências e, em essência, falam sobre o que esses produtos são ótimos. Isso se disfarça de relatórios técnicos, mas, em essência, é um anúncio publicitário. Como indústria, não seria prejudicial sermos mais honestos sobre as vantagens e desvantagens de nossos produtos. Um dos requisitos para isso é a terminologia geral; sem ela, é impossível comparar as coisas. Além disso, são necessários métodos para analisar as vantagens e desvantagens de várias tecnologias.
Teoremas desnecessários de CAP e outros erros do setor
Vadim : Minha próxima pergunta é bastante sensível. Você poderia nos contar sobre algum erro comum em nosso setor que você encontrou durante sua carreira? Por exemplo, sobre alguma tecnologia superestimada ou uma solução amplamente usada da qual você deveria ter se livrado há muito tempo? Este pode não ser o melhor exemplo, mas me ocorre usar JSON sobre HTTP / 1.1 em vez de gRPC sobre HTTP / 2. Ou talvez você não compartilhe esse ponto de vista?
Martin : Na maioria das vezes, ao criar sistemas, para conseguir uma coisa, você precisa sacrificar outra coisa, e aqui eu prefiro não falar sobre erros. No caso de uma escolha entre JSON sobre HTTP / 1.1 e, digamos, Protocol Buffers sobre HTTP / 2, ambas as opções têm o direito de existir. Se você decidir usar os Buffers de Protocolo, precisará definir um esquema, e ele pode ser muito útil, pois ajuda a determinar com precisão o comportamento do sistema. Mas em algumas situações, esse esquema não causa nada além de aborrecimento, especialmente nos estágios iniciais de desenvolvimento, quando os formatos de dados são alterados com bastante frequência. Novamente, aqui, para alcançar um determinado objetivo, é preciso sacrificar algo, e em algumas situações isso é justificado, mas em outras não. Não existem tantas soluções que realmente possam ser chamadas de erradas. Mas, como estamos falando sobre isso, vamos falar sobre o teorema da PAC - na minha opinião, não há absolutamente nenhum benefício com isso. Quando é usado no design de sistemas, existe um mal-entendido sobre o significado do teorema da PAC ou são demonstradas declarações evidentes usando-o. Ele usa um modelo de consistência muito restrito - linearizabilidade e um modelo de acessibilidade muito restrito - cada réplica deve estar totalmente acessível, mesmo que não consiga estabelecer uma conexão com nenhuma outra réplica. Por um lado, essas definições são bastante corretas, mas, por outro lado, são muito estreitas: muitos aplicativos simplesmente não precisam dessa definição de consistência ou acessibilidade. E se o aplicativo usa uma definição diferente dessas palavras, o teorema da CAP é inútil para ele. Portanto, não vejo muito sentido em aplicá-lo. A propósito, desde que começamos a falar sobre erros em nosso setor, vamos admitir honestamente que a mineração de criptomoedas é um completo desperdício de eletricidade. Não entendo como você pode fazer isso seriamente.
Vadim : além disso, a maioria das tecnologias de armazenamento agora é personalizável para uma tarefa específica, ou seja, Você pode selecionar o modo de operação apropriado na presença de falhas.
Martin : Isso mesmo. Além disso, uma parte significativa das tecnologias não se enquadra na definição estrita de consistência e acessibilidade do teorema da CAP, ou seja, não são CP, nem AP nem CA, mas apenas P. Ninguém escreverá diretamente sobre esse software, mas, na realidade, ele pode Seja uma estratégia de desenvolvimento perfeitamente racional. Essa é uma das razões pelas quais acredito que o CAP ao analisar software é mais prejudicial do que bom: uma parte significativa das decisões de design não é apresentada de forma alguma e pode ser soluções bastante racionais, mas o CAP não permite que elas sejam descritas.
Os benefícios da descentralização
Vadim : Quais são os problemas mais agudos no desenvolvimento de aplicativos intensivos de dados agora? Quais tópicos são mais ativamente explorados? Tanto quanto eu sei, você é um defensor da computação descentralizada e do armazenamento de dados descentralizado.
Martin : Sim. Um dos pontos que provo em minha pesquisa é que, no momento, confiamos demais nos servidores e na centralização. Nos primeiros dias da Internet, quando evoluiu da ARPANET, ela foi projetada como uma rede altamente estável na qual os pacotes podem ser enviados por várias rotas, e eles ainda alcançam seu objetivo. No caso de uma explosão nuclear em qualquer cidade da América, a parte sobrevivente da rede continuaria operando, rotas alternativas seriam simplesmente usadas para contornar as seções com falha. Foi um esquema gerado pela Guerra Fria. Mas então decidimos colocar tudo na nuvem, então agora quase tudo passa por um dos centros da AWS em algum lugar da Virgínia, no leste dos Estados Unidos. Em algum momento, abandonamos o ideal de uso descentralizado de várias partes da rede e identificamos os serviços dos quais agora tudo depende. Considero importante retornar a uma abordagem descentralizada, na qual mais controle sobre os dados pertenceria não aos serviços, mas aos usuários finais.
Quando se trata de descentralização, muitas vezes eles significam coisas como criptomoedas, porque eles têm redes de agentes interagindo sobre os quais não existe uma autoridade centralizada como um banco. Mas não é sobre a descentralização da qual estou falando, porque, na minha opinião, as criptomoedas também são extremamente centralizadas: se você precisa concluir um acordo com o Bitcoin, isso deve ser feito através da rede Bitcoin, para que tudo seja centralizado nessa rede. A estrutura da rede é descentralizada no sentido de que não possui um único centro organizador, mas a rede como um todo é extremamente centralizada, pois cada transação deve ser feita através dessa rede e nada mais. Eu acredito que isso também é uma forma de centralização. No caso de criptomoedas, isso é inevitável, pois é necessário garantir a ausência de custos duplos, e isso é difícil de alcançar sem uma rede que forneça consenso sobre quais transações foram concluídas e similares. Mas existem muitos aplicativos que não exigem um sistema como um blockchain; eles podem trabalhar com um modelo de dados muito mais flexível. São esses sistemas descentralizados que mais me interessam.
Vadim : Desde que você mencionou o blockchain, você poderia nos falar sobre tecnologias promissoras ou não conhecidas no campo de sistemas descentralizados? Eu mesmo brinquei com o IPFS, mas você tem muito mais experiência nessa área.
Martin : Na verdade, eu não sigo ativamente essas tecnologias. Eu li um pouco sobre o IPFS, mas não o usei. Trabalhamos um pouco com o
Dat , que, como o
IPFS , é uma tecnologia de armazenamento descentralizada. A diferença é que a
criptomoeda do Filecoin está vinculada ao IPFS e é usada para pagar pelo armazenamento de dados, e nenhuma blockchain está vinculada ao Dat. O Dat apenas permite replicar dados em várias máquinas com base em P2P e, para o projeto em que estávamos trabalhando, o Dat é ótimo. Criamos software para os usuários colaborarem em um documento, dados ou banco de dados e cada alteração nesses dados é enviada a todos que possuem uma cópia dos dados. Nesse sistema, o Dat pode ser usado de acordo com o princípio P2P, para garantir a operação no nível da rede, ou seja, NAT Traversal e passagem por firewalls, o que é uma tarefa bastante difícil. Além disso, escrevemos um nível do CRDT, com a ajuda de várias pessoas para editar um documento ou um conjunto de dados e que possibilitou o compartilhamento rápido e conveniente de edições. Eu acho que um sistema semelhante poderia ser escrito em cima do IPFS, ignorando o Filecoin e usando apenas a replicação P2P.
Vadim : Mas esse sistema não teria se tornado menos responsivo, porque o WebRTC conecta diretamente os nós e o IPFS é mais uma tabela de hash distribuída.
Martin : O problema é que o WebRTC é um nível de pilha ligeiramente diferente. Destina-se principalmente a videochamadas - com alta probabilidade de uso no software pelo qual estamos nos comunicando agora. Além disso, o WebRTC fornece um canal através do qual você pode enviar dados binários arbitrários. Mas criar um sistema de replicação em cima dele pode ser difícil. Mas no Dat e no IPFS, você não precisa fazer nada para isso.
Você mencionou a capacidade de resposta, e esse é um fator realmente importante a ser lembrado. Suponha que queremos tornar o próximo Google Docs descentralizado. No Google Docs, a unidade de alteração é pressionada uma única tecla e cada novo caractere pode ser enviado em tempo real para outras pessoas que trabalham com o mesmo documento. Por um lado, isso garante uma colaboração rápida; por outro lado, significa que, ao escrever um documento grande, você precisa enviar centenas de milhares de alterações de um caractere, e muitas tecnologias existentes lidam mal com esse tipo de compactação de dados. Mesmo se assumirmos que para cada pressionamento de tecla é necessário enviar apenas cem bytes, para um documento de 100.000 caracteres, será necessário enviar 10 MB de dados, embora normalmente esse documento não tenha mais do que várias dezenas de kilobytes. Até que algum método engenhoso de compactação tenha sido inventado, essa sincronização de dados requer um enorme custo adicional de recursos. Muitos sistemas P2P ainda não têm uma maneira eficaz de criar instantâneos do estado que permitiriam que fossem usados em um sistema como o Google Docs. No momento, estou trabalhando neste problema, tentando criar um algoritmo para uma sincronização de documentos mais eficiente para vários usuários. Este deve ser um algoritmo que não armazene todas as teclas pressionadas, porque isso exige muitos recursos e deve fornecer um uso mais eficiente da rede.
Novo CRDT, verificação formal em Isabelle
Vadim : Você poderia nos contar mais sobre isso? Você conseguiu obter mais de 100x de compactação de dados? Você está falando sobre novas técnicas de compactação ou CRDTs especiais?
Martin : Sim. Até agora, só temos um protótipo, que ainda não foi totalmente implementado. Experimentos adicionais precisam ser feitos para descobrir como é eficaz na prática. Mas alguns de nossos métodos são promissores. No meu protótipo, consegui reduzir o tamanho de uma única edição de 100 para 1,7 bytes. Mas, repito, esta é apenas uma versão experimental até agora, esse indicador pode mudar um pouco. De uma forma ou de outra, existem grandes oportunidades de otimização nessa área.
Vadim : Então seu relatório na conferência Hydra será sobre isso?
Martin : Sim. Terei uma breve introdução sobre o CRDT, o software de colaboração e alguns problemas que surgem neste contexto. Depois, falarei sobre as pesquisas que estamos fazendo nesta área - elas lidam com muitos problemas diferentes. No lado da aplicação, temos uma implementação desses algoritmos em JavaScript, com base nela, criamos programas funcionais para entender melhor o comportamento dos algoritmos. Ao mesmo tempo, também estamos trabalhando em métodos formais para provar a correção desses algoritmos, porque alguns deles são bastante óbvios e queremos garantir que eles sempre atinjam um estado consistente. Muitos algoritmos desenvolvidos anteriormente não fornecem consistência em alguns casos limítrofes. Para evitar isso, recorremos a métodos formais de comprovação da correção.
Vadim : Você usa provas de teoremas como Coq ou Isabelle para este sistema?
Martin : Sim,
Isabelle .
Nota dos editores: Martin lerá uma palestra sobre Isabelle no The Strange Loop.
Vadim : Você está planejando publicar essa evidência?
Martin : Sim, o primeiro conjunto de evidências que
publicamos há um ano e meio, juntamente com a estrutura de verificação do CRDT. Testamos três CRDTs usando essa estrutura, a mais importante das quais foi RGA (
Replicated Growable Array ), CRDT para co-edição de texto. Este algoritmo não é muito complicado, mas bastante óbvio, na opinião de não estar imediatamente claro se está correto; portanto, era necessária uma prova formal. Também trabalhamos para provar a correção de vários CRDTs existentes, e a última coisa que fizemos nesta área foi criar nossos próprios CRDTs para novos modelos de dados.
Vadim : Quanto mais o volume de prova formal do que o tamanho do código do próprio algoritmo? Às vezes há dificuldades com isso.
Martin : Dificuldades bastante suficientes, temos que trabalhar muito com evidências. : 60 , , 800 . , 12 . , . , . , . . , .
: , ? ?
: , . , . : TCP, Git . , , . , . . , .
Event sourcing, , XA-
:
, . , event sourcing. , - . event sourcing ? - , .
: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .
event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.
, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .
: . , , , , .
: , , JSON (, PostgreSQL ) . , . . , .
: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .
: , , , — ?
: . , , , , , 404, .
: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .
: ,
Multiversion Concurrency Control .
: , . XA-, , , . , , . , , . XA . , , . .
: , - .
: , . , , , . , . - , . , . - , : , , , . . , .
: , . , . - , , , - .
: . . , , . , .
: , . event sourcing. , , , . , . , , , . , , , , , . ?
: , . , , . , , , , . . , . , , .
: , , , .
: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .
: . .
: .
: , , . , — , . .
Hydra 2019,
: , Hydra? , , , .
: , , , , « » « ». . . , , - ; , , , , .
: , , , ? . , , ?
: , . , . , . - . , - , - . , . : , . — , — . , , , .
: . ? , - , , ?
: . . , . , , , . - — . , , . : . , , Slack ,
. , , . , , , .
: .
: , .
: ,
!
Lembro que esta é uma entrevista pré-gravada. Ao escrever comentários, lembre-se de que Martin não os lerá. Só podemos transmitir algo mais interessante. Se você realmente quiser conversar com o autor, ele fará uma apresentação “Sincronizando dados entre dispositivos do usuário para colaboração distribuída” na conferência Hydra 2019, que será realizada de 11 a 12 de julho de 2019 em São Petersburgo. Os ingressos podem ser adquiridos no site oficial .