Problema de Big Data
Os volumes de Big Data estão crescendo exponencialmente. Esse fenômeno vem acontecendo há anos, mas seu ritmo acelerou drasticamente desde 2012. Confira este blog intitulado Big Data Just Beginning to Explode from CSC para um ponto de vista semelhante sobre o surgimento de big data e os desafios relacionados a ele.
A IRI está ciente dessa tendência desde a fundação da empresa no final da década de 1970. Seu principal pacote CoSort foi projetado para lidar com volumes de dados crescentes por meio de eficiências em algoritmos e design de software, técnicas de exploração de hardware “portáteis” e consolidação de tarefas (por exemplo, sort-join-aggregate-encrypt-report). A questão que este artigo coloca é de abordagem, dada a “ascensão das máquinas”.
Limitação do hardware em resolvê-loCertamente o desempenho do computador tem acelerado em quase todos os aspectos por décadas. E para muitos, jogar hardware no problema do big data é apenas uma segunda natureza. No entanto, o problema pode ser maior do que isso. Considere a Lei de Moore, na qual o poder da CPU apenas dobra a cada 18 meses, na melhor das hipóteses, e a obsolescência inerente, problemas de manutenção e custos puros de uma estratégia centrada em hardware.
Algo novo a ser considerado também é a expectativa de que esse paradigma de desempenho para big data possa estar chegando ao fim. Segundo Gery Menegaz, sua premissa é que o fim da Lei de Moore está próximo. A revista Time publicou uma história semelhante em maio de 2012, intitulada O colapso da lei de Moore: O físico diz que já está acontecendo. De acordo com o artigo da Time,
Dado isso, Kaku diz que quando a Lei de Moore finalmente entrar em colapso até o final da próxima década, "simplesmente ajustaremos [ela] um pouco com computadores semelhantes a chips em três dimensões". Além disso, ele diz que "talvez tenhamos que ir para computadores moleculares e talvez no final do século 21 computadores quânticos".
Para a maioria dos usuários, no entanto, seu hardware é comprado para lidar e, até certo ponto, escalar, para atender aos desafios de processamento de big data que eles enfrentam ou prevêem. Mas quanto menos eficiente for o desempenho do software em execução, mais recursos de hardware terão que ser gastos para superar a ineficiência. Um exemplo em nosso mundo pode ser comprar um IBM p595 para executar /bin/sort quando uma máquina com um terço desse tamanho e custo executando CoSort produziria o mesmo resultado.
Enquanto isso, dispositivos DB e ELT, como Exadata e Netezza, construídos em torno de hardware, já exigem investimentos de 6 a 7 dígitos. E, embora possam ser dimensionados para suportar cargas maiores, geralmente há um limite para o quanto eles podem dimensionar (certamente não exponencialmente), quanto dinheiro pode ser gasto na tentativa de continuar dimensionando e o quanto as pessoas estão dispostas a confiar em um único fornecedor para cada aspecto de missão crítica de suas cargas de trabalho. E é uma boa ideia impor a sobrecarga da transformação de big data em bancos de dados que foram projetados para otimização de armazenamento e recuperação (consulta)?
Mesmo que todas essas perguntas tivessem respostas fáceis, como os problemas computacionais (mesmo que apenas dimensionando linearmente o crescimento de big data) que exigem um consumo de recursos exponencialmente maior (como classificação) são resolvidos? De alguma forma, a resposta não parece estar apenas esperando por uma computação quântica acessível…
O papel do software
Como os arquitetos do Hadoop e do data warehouse sabem, a classificação - e as operações de junção, agregação e carregamento em ETL que dependem da classificação - estão no centro do desafio de processamento de big data e um consumidor exponencial de recursos de computação. À medida que o big data dobra, os requisitos de recursos para classificá-lo podem triplicar. Portanto, os algoritmos, técnicas de exploração de hardware e esquemas de processamento envolvidos com software de classificação multiplataforma e multinúcleo são as chaves para gerenciar esse problema de maneira escalável, acessível e eficiente.
Contribuição do CoSort
O desempenho do CoSort escala linearmente em volume, mais ao longo das linhas da Lei de Amdahl. Enquanto o CoSort pode transformar centenas de gigabytes de big data em minutos com algumas dúzias de núcleos, outras ferramentas podem levar mais que o dobro do tempo, não escalar tão bem e/ou consumir mais memória e E/S no processo. Talvez mais importante, o CoSort integra a classificação diretamente em aplicativos relacionados e faz todo o trabalho pesado fora da camada de banco de dados e BI, onde os dados de teste seriam menos eficientes.
A arquitetura de co-rotina do CoSort move os registros entre o classificador e programas como o SortCL (utilitário de transformação, filtragem, pesquisa, relatório, migração e proteção de dados do CoSort) interativamente, por meio da memória. Assim, assim que o próximo registro classificado estiver disponível, ele poderá se mover para o aplicativo, carregar etc. Ele parece que o aplicativo está lendo um arquivo de entrada, mas, na verdade, o back-end da fonte ainda não foi produzido. E não, você não vai ficar à frente do classificador.
No final de 2015, o CoSort também se tornou o motor dentro da moderna plataforma de gerenciamento e manipulação de big data da IRI, Voracity. O Voracity aproveita os mecanismos CoSort ou Hadoop perfeitamente.
Conclusão
Recursos de computação física sozinhos não podem ser considerados para escalar o problema de processamento de big data. O ambiente de software CoSort é aquele em que a transformação de big data necessária e as tarefas relacionadas são executadas não como processos independentes, mas em paralelo durante a mesma passagem de E/S.
Portanto, se você precisar de uma classificação rápida para algum propósito que não seja apenas o tempo de classificação, pense no que acontece a jusante da classificação e nas melhores maneiras de vincular esses processos. E depois de determinar o melhor paradigma de tempo de execução, você pode combinar hardware de alto desempenho com esse software para otimizar o desempenho? Você pode preparar dados DW com CoSort no lado do servidor de banco de dados do Exadata, por exemplo? Ou faria mais sentido manter seu IBM p595 e adicionar o CoSort para triplicar o rendimento? Ou se você pretende usar o Hadoop, considere usar o mesmo 4GL simples de CoSort ou mapeamentos ETL intuitivos de Voracity para conduzir trabalhos MapReduce 2, Spark, Storm ou Tez.
Deixe seu orçamento e sua imaginação serem seus guias para lidar com o crescimento de dados.
