Uma tradução do artigo foi preparada especificamente para os alunos do curso de Engenharia de Dados .
Leia a primeira parteNinguém precisa de Big Data
Quando você ouvir "Ninguém precisa de Big Data", observe o currículo do palestrante. Uma operadora de telecomunicações africana com níveis surpreendentes de crescimento não entrará em contato com o novo desenvolvedor de JavaScript e perguntará se ele pode ajudar a desenvolver sua plataforma de dados e otimizar os cálculos de cobrança. Você pode encontrar muitos aplicativos Web internos na sede da companhia aérea, mas quando se trata de analisar petabytes de telemetria de aeronaves para manutenção preventiva, pode não haver um desenvolvedor PHP único nesse projeto.
Os projetos acima geralmente não são anunciados de forma que os desenvolvedores da Web possam descobrir sobre eles. É por isso que alguém pode passar anos trabalhando em novos projetos que estão na parte inferior de sua curva S em termos de crescimento e acumulação de dados e, na maioria dos casos, nunca vê a necessidade de processamento de dados além do que pode caber na RAM em uma máquina.
Nos últimos 25 anos, o desenvolvimento da web tem sido um grande impulsionador do crescimento do número de programadores. A maioria das pessoas que se autodenomina programadores costuma criar aplicativos da web. Penso que muitos dos conjuntos de habilidades que eles possuem estão bem alinhados com os necessários para o design de dados, mas geralmente não possuem computação distribuída, estatística e narração de histórias.
Os sites geralmente não criam uma carga pesada para nenhum usuário, e muitas vezes o objetivo é manter a carga nos servidores que suportam um grande número de usuários abaixo do limite máximo de hardware. O mundo dos dados consiste em cargas de trabalho nas quais uma solicitação faz todo o possível para maximizar um grande número de máquinas, para concluir o trabalho o mais rápido possível, enquanto reduz os custos de infraestrutura.
As empresas de dados Petabyte costumam ter consultores e provedores de soluções em seu arsenal. Eu raramente via alguém sendo retirado do desenvolvimento da web por seu empregador e transferido para a área de desenvolvimento da plataforma de dados; quase sempre é o resultado de um longo auto-treinamento.
Este conjunto de dados pode estar na RAM
Ouvi pessoas dizerem que "um conjunto de dados pode caber na memória". A quantidade de RAM, mesmo na nuvem, aumentou significativamente recentemente. Há instâncias do EC2 com 2 TB de RAM. Normalmente, a RAM pode ser usada entre 12 e 25 GB / s, dependendo da arquitetura da sua instalação. Usar apenas a RAM não fornecerá a recuperação de uma falha se ocorrer uma falha de energia na máquina. Além disso, o custo por GB será enorme comparado ao uso de unidades.
Os discos também estão ficando mais rápidos. Recentemente
anunciado, um cartão SSD PCIe 4.0 NVMe de 4 x 2 TB capaz de ler e gravar a uma velocidade de 15 GB / s. O preço de uma unidade NVMe PCIe 4.0 será bastante competitivo com a RAM e fornecerá memória não volátil. Mal posso esperar para ver um cluster HDFS com uma boa rede usando essas unidades, porque ele demonstrará a aparência de um arquivo de dados na memória com armazenamento não volátil com as ferramentas avançadas do ecossistema Hadoop.
Sobrecarregado com excessos de engenharia
Eu não gostaria de gastar 6 ou 7 dígitos no desenvolvimento de uma plataforma de dados e de uma equipe para uma empresa que não poderia ser além do que cabe no laptop de um desenvolvedor.
Do ponto de vista do fluxo de trabalho, meus dias consistem principalmente em usar BASH, Python e SQL. Muitos recém-formados são qualificados acima.
Dados do Petquet O Parquet pode ser facilmente distribuído em um milhão de arquivos no S3. O planejamento relacionado ao exposto acima não é muito mais complicado do que considerar como armazenar 100.000 arquivos de micropacote no S3. Só porque uma solução é escalável, não significa que é redundante.
Basta usar o PostgreSQL?
Também ouvi argumentos de que sistemas orientados a linhas como MySQL e PostgreSQL podem atender às necessidades de cargas de trabalho analíticas, bem como às cargas de trabalho transacionais tradicionais. Ambas as sugestões podem ser feitas pela análise e, se você estiver visualizando menos de 20 GB de dados, provavelmente não será necessário dimensionar.
Eu tive que trabalhar com um sistema que carregava 10 bilhões de linhas diariamente no MySQL. No MySQL e PostgreSQL, não há nada que possa lidar com essa carga. O custo da infraestrutura para armazenar conjuntos de dados, mesmo por vários dias, no armazenamento orientado a linhas, ofuscou os custos com a equipe. A mudança para uma solução de armazenamento em coluna para esse cliente reduziu os custos de infraestrutura e acelerou os tempos de consulta em duas ordens de magnitude para cada um.
O PostgreSQL possui vários complementos para armazenar e distribuir consultas em várias máquinas. Os melhores exemplos que eu vi são ofertas comerciais. O
Zedstore anunciado pode, em um grau ou outro, dar suporte ao estabelecimento de armazenamento em coluna como uma função
interna padrão do PostgreSQL. Será interessante ver se a distribuição de solicitações individuais e a separação de armazenamento se tornarão funções padrão no futuro.
Se você precisar de um conjunto de dados transacional, é melhor manter essa carga de trabalho isolada usando um armazém de dados transacional. É por isso que espero que o MySQL, PostgreSQL, Oracle e MSSQL durem muito tempo.
Mas você gostaria de ver uma pausa de 4 horas no Uber porque um dos pedidos do Presto causou um comportamento inesperado? Deseja que sua empresa seja informada sobre a necessidade de cobrança mensal, por que você precisaria desligar o site por uma semana para que haja recursos suficientes para esta tarefa? Cargas de trabalho analíticas não devem ser associadas a cargas de trabalho transacionais. Você pode reduzir os riscos operacionais e escolher o equipamento mais adequado, executando-os em uma infraestrutura separada.
E como você trabalha em hardware separado, não precisa usar o mesmo software. Muitas das habilidades inerentes a um engenheiro competente do PostgreSQL são adequadas para o mundo dos dados orientados para a análise; Este é um pequeno passo em comparação com o salto para um desenvolvedor da Web que se muda para o espaço de big data.
Como é o futuro?
Continuarei analisando e expandindo minhas habilidades de dados no futuro próximo. Nos últimos 12 meses, tenho trabalhado usando Redshift, BigQuery e Presto em quantidades quase iguais. Tento distribuir minhas apostas, porque ainda não encontrei uma bola de cristal do preditor.
O que eu realmente espero é mais fragmentação e mais participantes entrando e saindo da indústria também. Existem razões para a existência da maioria dos bancos de dados, mas os casos de uso que eles podem servir podem ser limitados. Ao mesmo tempo, bons vendedores podem expandir a demanda do mercado por qualquer oferta. Ouvi dizer que as pessoas acreditam que a criação de um banco de dados de qualidade comercial requer cerca de US $ 10 milhões, e este é provavelmente o melhor local para capital de risco.
Existem muitas sugestões e implementações que deixam os clientes com um sabor desagradável. Também existe o choque de um preço na nuvem. Existem soluções boas, mas muito caras devido ao custo de contratação de especialistas. Os profissionais de vendas e marketing do setor estarão ocupados por algum tempo discutindo as compensações acima.
Cloudera e MapR podem estar em um momento difícil no momento, mas não ouvi nada parecido para me fazer acreditar que a AWS EMR, DataBricks e Qubole têm algo com o que competir. Até a Oracle está lançando uma oferta
orientada a
Spark . Seria bom se a indústria visse no Hadoop algo mais do que apenas uma oferta da Cloudera e reconhecesse que essas empresas, assim como o Facebook, Uber e Twitter, deram uma contribuição significativa ao mundo do Hadoop.
O Hortonworks, que se uniu à Cloudera este ano, é um provedor de plataforma para o Azure HDInsight, gerenciado pelo Microsoft Hadoop. Existem pessoas na empresa que podem fornecer uma plataforma decente para um provedor de serviços em nuvem de terceiros. Espero que as propostas nas quais eles estejam trabalhando se concentrem nesse tipo de suprimento.
Suspeito que os primeiros clientes da Cloudera fossem usuários do HBase, Oozie, Sqoop e Impala. Seria bom ver que eles não competem por um tempo de desenvolvimento tão longo e pelas versões futuras de suas plataformas que serão fornecidas com Airflow, Presto e a versão mais recente do Spark.
No final, se sua empresa planeja implantar uma plataforma de dados, não encontrará um substituto para uma equipe de gerenciamento exigente que possa pesquisar minuciosamente, planejar com cuidado e identificar rapidamente falhas.