Está é a primeira parte de uma série sobre o uso do Scala para armazenamento e análise de dados em grande escala.
Ao longo dos últimos anos, o Scala vem sendo usado em vários projetos de larga escala na construção de plataformas de armazenamento e análise de dados.
A BBC usou Scala, e o framework HTTP Scalatra na construção do data store RDF interno, que é usado para buscar dados nos artigos do BBC News e Sport.
Durante o ano de 2014, houve um aumento de interesse no Apache Spark, um conjunto de ferramentas de análises de dados escrito em Scala. O Spark tem uma interface HTTP em Spray e o backend para processamento paralelo em Akka.
A McLaren Applied Technologies (MAT) também usou Scala, Scalatra e Akka como base para a plataforma de análise de dados.
Porque foi escolhido o Scala para estes projetos?
Para descobrir isso, falamos com Andrew Jayne, engenheiro de software sênior na MAT, sobre a experiência de construir um data store de alto desempenho customizado em Scala.
Estabelecida próxima a Londres, a McLaren Applied Technologies (MAT) deriva de décadas de experiência da matriz McLaren na Formula 1. A MAT se separou para aplicar o conhecimento adquirido na Formula 1 em outras indústrias.
Devido ao seu conhecimento na F1, a MAT tem habilidades muito fortes na análise e tomada de decisões rápidas com base nos dados, como os dados de tempo de séries que são transmitidos na Formula 1 durante a corrida. Entretanto, perceberam que essa análise em série frequentemente associada a instrumentação do sensor podem ser aplicadas a várias coisas além da corrida: eles têm aconselhado empresas do setor de manufatura, transporte, energia e saúde.
Para apoiar este trabalho de consultoria, os engenheiros da MAT construíram uma plataforma de dados em séries, que é executado sob o AWS da Amazon.
InfoQ.com: Pode fornecer uma visão geral sobre o que é o MAT series data store e como ele é usado?
Jayne: É um armazenamento chave-valor ordenado de alto volume, alta velocidade com consistência de leitura e gravação e um conjunto de funcionalidades designadas especialmente para dados em série históricos e em tempo real (indexado pela hora, distância, profundidade, etc). Isso permite realizar micro processamentos em lote e processamentos em lote de uma maneira controlada além de ser utilizado para persistir todas a entradas e saídas em série para e a partir de nosso data analytics via API REST. Um exemplo é o trabalho que estamos fazendo com o GSK para analisar e monitorar os pacientes com ALS - equipados com sensores - através de triagem clínica permitindo a detecção de melhorias e deterioração para ter feedback dentro da triagem.
InfoQ.com: Estão usando o MAT series data store na Formula 1 para os dados em série relacionados a tempo, ou isso é para uma proposta mais geral?
Jayne: Isso foi concebido como uma solução geral para armazenar e buscar dados em série com base em nossa experiência em esportes motorizados, esportes de elite, saúde e industrias do ramo energético. Encontramos problemas similares através dos projetos e precisávamos de uma solução de armazenamento que mantivesse os dados íntegros enquanto nos permitia resolvê-los. Por exemplo, o que fazer quando os dados vêm de um dispositivo com clock drift? Como asseguramos alta fidelidade se os dados são enviados em uma baixa resolução devido aos limites de banda? O que acontece quando o backlog dos dados se torna disponível depois de um período sem rede?
InfoQ.com: Que tipo de conjuntos de dados e cargas de trabalho está sendo usado para isso?
Jayne: É utilizado para dados numéricos n-dimensionais com uma chave estritamente crescente. Casos de uso atuais incluem dados de sensores em pacientes equipados, em operações de perfuração e data center, além dos resultados das análises dos dados.
InfoQ.com: Porquê Scala? Se já tinham um bom conhecimento em Java e foram adiante? O que atraiu vocês para a linguagem?
Jayne: A equipe é poliglota. Até 2012 estávamos usando Java, C# e MATLAB, Com o lançamento do Stack 2.0 da Typesafe adotamos o Scala como linguagem para o backend de nossos serviços e aplicações web.
O principal motivo da equipe foi a escalabilidade. Por exemplo, simplificando a concorrência através de atores (Actors), imutabilidade e programação funcional (FP). Houveram outros incentivos, como a habilidade de expressar programas matematicamente mais aptos, reconhecimento de padrões, e a redução de código. Entretanto, não existia a possibilidade de irmos para o Scala se tivéssemos que sacrificar a interoperabilidade do Java. A abordagem da programação funcional estava fresca, revigorando e nos mostrando mais oportunidades para inovar. É um bom ajuste para a cultura e mentalidade da equipe.
InfoQ.com: Por que não construir em Java?
Jayne: Já tínhamos um componente desenvolvido em Java em cima do Hadoop que poderíamos ter construído em cima, mas o resto dos nossos componentes de backend estavam em Scala. Usamos isso como uma oportunidade de pesquisa e desenvolvimento, e logo tivemos a boa ideia de quais bibliotecas e tecnologias poderíamos usar para suportar a arquitetura que desenhamos. Com a experiência adquirida percebemos que tínhamos construído podia ser facilmente simplificado com o programação funcional. Enquanto o Java é fácil de usar, a sua verbosidade pode ficar no caminho ao tentar deixar o código claro. Temos usado o Scala comercialmente por anos e também temos descobrido que existe um grande valor em conversar com pessoas construindo a linguagem e as bibliotecas principais.
InfoQ.com: O que outros os outros bancos de dados de séries não puderam lhe oferecer? Por que não usar KairosDb, Druid, InfluxDb, OpenTSDB, ou algum outro TSDB proprietário existente?
Jayne: A integridade e gerenciamento dos dados são essenciais para nosso negócio e precisávamos de algumas garantias ao redor dos dados que esperamos do nosso código. Não era suficiente somente termos os backups e logs dos registros. Como resultado, foi projetado um armazenamento de dados com controle de revisão baseado em commit e organização baseada em árvore influenciado pelo Git.
Nosso critério de aceitação apresentou alguns desafios adicionais, como por exemplo:
- Atomicidade - não deve ser possível consultar o sistema em um estado inconsistente;
- Consistência e regularidade - as buscas devem ser repetíveis e retornar dados corretos e consistentes;
- Escrita próxima a tempo real - suporta escrever milhões de medições por segundo (originados de sensores de frequência) e tornando os dados disponíveis para busca dentro de segundos após a captura;
- Desempenho de consulta - análise de dados de suporte sensíveis a latência, oferecendo consultas previsíveis e rápidas em todos os canais (bilhões de datapoints) incluindo:
- preparação dos dados (tal como: interpolação);
- subconjuntos (janelas, ranges, distância, limites);
- agregações (médias, miníma, máxima, etc);
- previsão (extrapolação, regressão, correlação).
- Agnóstico a linguagem - API REST como caching ETag;
- Formato de dados comuns - os dados devem ser compatíveis com ferramentas existentes que usem csv, json, etc;
- Complexidade de publicação - deve usar a infraestrutura cloud existente (AWS) e permitir que novos data stores possam ser criados com mínimo esforço.
A maioria destes tem sido endereçados à TSDBs existentes e alguns deles tem resolvido esses problemas de uma melhor maneira. Entretanto, existem outros tipos de consultas que precisamos que outros bancos de dados não suportam e não são fáceis de ajustar. A maioria dos TSDBs são construídos em cima de outros sistemas de bancos de dados (como o HBase), que é na realidade mais complexo do que precisamos. Ao usar um mecanismo proprietário mais simples que tira proveito da distribuição, podemos arranjar os dados de forma que fique otimizado para as consultas que executamos e mantém as despesas gerais de administração do sistema e os custos de funcionamento, no mínimo. Mais importante ainda, nenhum fornece a semântica de revisão de controle ao redor dos dados que esperamos no desenvolvimento e produção.
InfoQ.com: Falando sobre API REST. Estão usando o Scalatra para a interface HTTP REST. Porquê?
Jayne: O Scalatra é bem cuidado e segue uma estratégia sensível de lançamentos, algo que tivemos problemas antes como outros frameworks. Este framework tem uma DSL muito simples e nos permite apenas usar o mínimo necessário - manipulação de requisição e testes - e usar nossas bibliotecas para coisas como serialização. Sendo fácil de implementar em contêiner servlet é uma grande vitória e o desempenho é excelente.
InfoQ.com: Foi mencionado atores. Como a escolha no Akka funciona na prática? Ouvi sobre pessoas que o amam e outras que dizem que o código ficou imensamente mais simples e desde então o usam. Quais foram os desafios?
Jayne: O Akka é usado no armazenamento de dados para gerenciar requisições assincronamente uma vez que a maioria das requisições serão originadas em I/O. Atualmente não é baseado a eventos de I/O, mas podemos considerar Akka Streams para o benefício do agendador e excesso de manipulação.
Usamos o modelo de ator quando um problema pode ser decomposto dentro de conjuntos de subsistemas no qual seu próprio estado e escalabilidade estão em consideração. Concebido para ser distribuído por padrão significa que podemos tirar vantagem da transparência de localização para escalar tanto verticalmente quanto horizontalmente. Entretanto, a perda de interfaces comuns é um inconveniente desde que perdemos as verificações do compilador. Um compromisso são os protocolos formais, mantendo os atores simples e tornando-os explícitos em nosso design e testes. Escrever testes claros e concisos pode ser complicado, e depuração é um desafio em qualquer sistema concorrente.
InfoQ.com: O datastore pode ser clusterizado através de vários nós? Quão bem isso escala? E a escolha do Scala está relacionada a isso, ou poderia ter funcionado em qualquer linguagem?
Jayne: Atualmente é escalável em termos de volume e falhas - A API endpoints e dados estão co-localizados. O próximo passo para melhorar a escalabilidade seria remover esta restrição, assim podemos usar um balanceador de carga elástico na API REST e separar isso da camada de armazenamento.
A etapa do desenvolvimento foi muito rápida no Scala e alguns dos mais complexos processos são muito claros quando escrevendo em programação funcional. Favorecer a imutabilidade por padrão encoraja padrões de programação claros e torna a atomicidade e consistência dos sistemas muitos mais fáceis de impor. Entretanto, não existe nada que não pudesse ter sido escrito em Java - é mais como se esta fosse a ferramenta correta para a equipe.
Dave Hrycyszyn é chefe de tecnologia na Head London, uma agência de produtos e serviços digitais no Reino Unido. Coautor do livro Scalatra in Action, e membro da equipe trabalhando no micro framework Scalatra. Ele escreve sobre Scala, APIs, e tópicos relacionados a dados na constructiveproof.com.
