Uma tradução do artigo foi preparada especificamente para os alunos do curso de Engenharia de Dados .
Depois que Cloudera e MapR anunciaram semanas atrás que seus negócios estavam em um momento difícil, vi um fluxo de postagens de mídia social com o tema "Hadoop is Dead". Essas postagens não são novas, mas em um setor em que especialistas técnicos raramente produzem material de alta qualidade para redes sociais, essas exclamações estão ficando cada vez mais altas. Eu gostaria de considerar alguns dos argumentos sobre o estado do Hadoop.
Competição com livre
Cloudera tem sugestões que ajudam o Hadoop a ser uma solução mais completa. Essas ferramentas apareceram antes que os devops se generalizassem, e a implantação automatizada era rara.
Suas ferramentas oferecem ótimas promoções para mais de 2.600 clientes, mas a maioria do software que eles oferecem é de código aberto e gratuito. Cloudera finalmente compete com o software livre. Além disso, muitos desenvolvedores de ecossistema do Hadoop já trabalharam uma vez ou outra na Cloudera, ou seja, no final, eles de alguma forma subsidiaram as ofertas gratuitas com as quais competem.
Como eles competem de graça, o Cloudera nunca servirá 100% da base de usuários do Hadoop. Eu não ousaria usá-los como um indicador da saúde do Hadoop por esse mesmo motivo.
Outras empresas que oferecem soluções turnkey Spark e Presto estão tentando se distanciar da marca Hadoop. Suas ofertas podem incluir centenas de arquivos .jar de vários projetos do Hadoop, mas, no entanto, essas empresas desejam fazer todo o possível para evitar a concorrência com ofertas gratuitas, enquanto reduzem seus custos de desenvolvimento usando software de código aberto. As vendas não são tão fáceis quando seu cliente pode baixar legalmente 80% da sua oferta sem pagar por isso.
Concorrência com a AWS
Em 2012, trabalhei na implementação do Hadoop com outros 25 contratados. Alguns dos meus colegas vieram do Google, outros continuaram trabalhando para a Cloudera. Um orçamento significativo foi envolvido, a equipe produziu muitas horas pagas, mas uma parte muito pequena do ecossistema do Hadoop estava pronta.
Dentro de alguns anos, o AWS EMR apareceu e começou a absorver sua participação de mercado. O EMR permite executar clusters do Hadoop com uma ampla variedade de softwares instalados em apenas alguns cliques. Ele pode trabalhar em cópias pontuais, o que reduz os custos de equipamentos em aproximadamente 80% e pode armazenar dados no S3, que era e permanece barato e confiável em 99,9999999999%.
De repente, a necessidade de 25 contratantes no projeto desapareceu. Em alguns projetos, apenas eu, um trabalhador em período integral e vários outros em meio período, preparando a infraestrutura, além de outras responsabilidades, poderíamos estar envolvidos. Ainda é necessário consultores de projeto que usam o AWS EMR, mas o potencial geral de cobrança para esse tipo de trabalho é muito menor do que alguns anos atrás.
Que parcela do potencial negócio da Cloudera foi perdida em favor da EMR? A Cloudera fez um bom trabalho ao configurar e gerenciar clusters bare metal, mas hoje a maior parte do mundo dos dados está na nuvem. Vale a pena considerar o quão atraente o Hadoop é para os seus negócios, mesmo que a AWS tenha uma oferta gerenciada com cópias pontuais.
O que é o Hadoop?
Se você me perguntasse a definição de Hadoop, eu diria que é uma grande coleção de software de código aberto que se integra até certo ponto e possui várias bibliotecas comuns. Eu vejo o Hadoop como um banco de dados particionado, quase como uma distribuição do sistema operacional para dados.
Nem todos os projetos de software patrocinados pelo Hadoop são projetos Apache. O Presto é uma dessas exceções. Outros, como ClickHouse, com suporte futuro para HDFS e Parquet, não serão percebidos por muitos como um projeto Hadoop, embora em breve marquem o gráfico de compatibilidade.
Até 2012, não havia arquivos ORC ou Parquet. Esses formatos contribuíram para a implementação de análises rápidas no Hadoop. Antes desses formatos, as cargas de trabalho eram principalmente orientadas para linhas. Se você precisar converter terabytes de dados e fazê-lo em paralelo, o Hadoop fará o trabalho perfeitamente. O MapReduce era uma estrutura frequentemente usada para esse fim.
O que o armazenamento em coluna foi oferecido é uma análise de terabytes de dados em questão de segundos. O que acabou sendo uma proposta mais valiosa para um número maior de empresas. Os cientistas de dados podem precisar de apenas uma pequena quantidade de dados para ter uma idéia, mas primeiro precisam analisar petabytes de dados potencialmente para escolher os corretos. A análise de colunas é crucial para eles em sua fluência no processamento de dados necessários para entender o que precisa ser selecionado.
O MapReduce possui dois operadores funcionais de processamento de dados, mapeiam e reduzem e tratam dados como cadeias. O Spark o segue imediatamente e possui operadores mais funcionais, como filtro e união, e percebe os dados estruturados em um gráfico acíclico direcionado (Direct Acyclic Graph - DAG). Esses elementos permitiram ao Spark executar cargas de trabalho mais complexas, como aprendizado de máquina e análise gráfica. O Spark ainda pode usar o YARN como um planejador de capacidade, como as tarefas no MapReduce. Mas a equipe do Spark também começou a criar seu próprio agendador e, posteriormente, adicionou suporte ao Kubernetes.
Em algum momento, a comunidade Spark tentou se distanciar do ecossistema Hadoop. Eles não queriam ser vistos como um complemento sobre o software Legacy ou como um tipo de "complemento" para o Hadoop. Dado o nível de integração que o Spark tem com o restante do ecossistema do Hadoop e as centenas de bibliotecas de outros projetos do Hadoop usados pelo Spark, discordo da opinião de que o Spark é um produto independente.
O MapReduce pode não ser a primeira escolha para a maioria das cargas de trabalho atualmente, mas ainda é o ambiente base ao usar o hadoop distcp - um pacote de software que pode transferir dados entre o AWS S3 e o HDFS
mais rapidamente do que qualquer outra oferta. testado.
Todas as ferramentas do Hadoop são bem-sucedidas?
Não, existem alguns projetos que já ofuscaram os novos itens.
Por exemplo, muitas cargas de trabalho que foram automatizadas anteriormente com o Oozie agora são automatizadas com o Airflow. Robert Kanter, o principal desenvolvedor do Oozie, forneceu uma parte significativa da base de código que existe hoje. Infelizmente, Robert não participou mais do projeto desde que deixou Cloudera em 2018. Enquanto isso, o Airflow tem mais de 800 participantes, cujo número quase dobrou no ano passado. Quase todos os clientes com quem trabalhei desde 2015 usavam o Airflow em pelo menos um departamento de suas organizações.
O Hadoop fornece os vários blocos de construção e elementos que compõem a plataforma de dados. Muitas vezes, vários projetos competem pelo fornecimento da mesma funcionalidade. No final, alguns desses projetos desaparecem enquanto outros assumem a liderança.
Em 2010, houve vários projetos que foram posicionados como a primeira escolha para várias cargas de trabalho, nos quais havia apenas alguns participantes ou, em alguns casos, várias implantações significativas. O fato de esses projetos irem e virem foi usado como evidência de que todo o ecossistema do Hadoop está morrendo, mas não tirei essas conclusões disso.
Vejo essa fraca associação de projetos como uma maneira de desenvolver muitos recursos poderosos que podem ser usados sem taxas significativas de licença de usuário final. Esse é o princípio de sobrevivência do mais apto e prova que, para cada problema, mais de uma abordagem foi considerada.
ATUALIZAÇÃO: Inicialmente afirmei que Oozie tinha 17 membros com base no que é relatado no GitHub. De fato, o Oozie teve confirmações diretas e correções enviadas por 152 desenvolvedores, e não apenas 17 que aparecem no cálculo do GitHub. Robert Kanter entrou em contato comigo após a publicação inicial deste post com evidências desses 135 autores adicionais, e agradeço a ele por esse esclarecimento.
O tráfego de pesquisa não está funcionando
Um dos argumentos a favor da "morte" do Hadoop é que o tráfego de pesquisa do Google em várias tecnologias Hadoop não funciona. Cloudera e vários outros consultores fizeram um bom trabalho de captação de recursos nos últimos anos e fizeram esforços significativos para avançar suas propostas. Isso, por sua vez, despertou grande interesse e, em algum momento, uma onda de pessoas estudando essas tecnologias apareceu na comunidade técnica. Essa comunidade é diversa e, em algum momento, a maioria das pessoas, como sempre, mudou para outras coisas.
Em toda a história do Hadoop, não havia uma variedade tão rica de funcionalidades como a oferecida hoje, e nunca foi tão estável e testada em batalha antes.
Os projetos do Hadoop consistem em milhões de linhas de código escritas por milhares de autores. Toda semana, centenas de desenvolvedores trabalham em vários projetos. A maioria das ofertas comerciais de bancos de dados tem sorte se pelo menos alguns engenheiros fizerem melhorias significativas em seus bancos de dados de código toda semana.
Por que o Hadoop é especial?
Primeiro, existem clusters HDFS com capacidade superior a 600 PB. A natureza dos metadados do HDFS na RAM significa que você pode processar facilmente operações de 60k por segundo.
O AWS S3 quebrou muito do que pode ser encontrado nos sistemas de arquivos POSIX para obter escalabilidade. Alterações rápidas de arquivo, como as necessárias para converter arquivos CSV em arquivos Parquet, não são possíveis no S3 e exigem algo como HDFS se você deseja distribuir a carga de trabalho. Se o software de conversão foi modificado para criar a carga de trabalho mencionada apenas no S3, as trocas com a localidade dos dados provavelmente serão significativas.
Em segundo lugar, o projeto Hadoop Ozone visa criar um sistema compatível com a API S3 que pode armazenar trilhões de objetos em um cluster sem a necessidade de usar seu próprio serviço de nuvem. O projeto visa ter suporte interno ao Spark e ao Hive, o que oferece uma boa integração com o restante do ecossistema do Hadoop. Uma vez lançado, este software será uma das primeiras ofertas de código aberto que podem armazenar tantos arquivos em um cluster.
Terceiro, mesmo que você não trabalhe com petabytes de dados, as APIs disponíveis no ecossistema Hadoop fornecem uma interface consistente para o processamento de gigabytes de dados. O Spark é a solução definitiva para aprendizado de máquina distribuído. Assim que você se sentir confortável com a API, não importa se sua carga de trabalho é medida em GB ou PB, o código que você cria não precisa ser reescrito, você só precisa de mais máquinas para executá-la. Primeiro eu ensinaria a alguém como escrever código SQL e PySpark e depois ensinaria a distribuir comandos AWK em várias máquinas.
Quarto, muitos dos recursos do ecossistema Hadoop são líderes para fornecedores comerciais. Cada movimento malsucedido de marketing de um banco de dados proprietário leva o departamento de vendas a descobrir quantos recursos, trade-offs e gargalos estão faltando em sua oferta. Toda falha no POC faz com que a equipe de vendas descubra a confiabilidade dos testes internos de software.
Isso conclui a primeira parte da tradução. A continuação pode ser
lida aqui . E agora estamos aguardando seus comentários e convidamos todos a um seminário on-line gratuito sobre o tópico:
"Princípios da construção de sistemas de análise de streaming" .