Vídeo: Aula 1 - Big data e Hadoop - Módulo I 2025
Uma grande quantidade de estudos mostra que a maioria dos dados em um data warehouse corporativo raramente é consultado. Os fornecedores de banco de dados responderam a essas observações implementando seus próprios métodos para classificar os dados que são colocados onde.
Um método ordena o universo de dados em designações de hot, warm ou cold, onde hot dados (às vezes chamado dados ativos ) é usado com freqüência, dados quentes são utilizados de tempos em tempos; e dados frios raramente são usados. A solução proposta para muitos fornecedores é para armazenar os dados frios em discos mais lentos dentro dos compartimentos do data warehouse ou para criar estratégias de cache inteligentes para manter os dados quentes na memória, entre outros.
O problema com essa abordagem é que, embora seja usado um armazenamento mais lento, ainda é caro armazenar dados frios e raramente usados em um armazém. Os custos aqui decorrem de ambos licenciamento de hardware e software. Ao mesmo tempo, dados frios e latentes são frequentemente arquivados em fita.
Este modelo tradicional de dados de arquivamento quebra quando você deseja consultar todos os dados frios de forma econômica e relativamente eficiente - sem precisar solicitar fitas antigas, em outras palavras.
Se você olhar para o custo e as características operacionais do Hadoop, na verdade, parece que está configurado para se tornar a nova fita de backup. O Hadoop é barato em grande parte porque os sistemas Hadoop foram projetados para usar um grau mais baixo de hardware do que o que normalmente é implantado em sistemas de data warehouse. Outra economia significativa de custos é o licenciamento de software.
As licenças de distribuição Hadoop comerciais requerem uma fração do custo das licenças de software de warehouse de dados relacionais, que são notáveis por serem caras. Do ponto de vista operacional, o Hadoop é projetado para escalar facilmente apenas adicionando nós escravos adicionais a um cluster existente. E à medida que os nós escravos são adicionados e os conjuntos de dados crescem em volume, as estruturas de processamento de dados da Hadoop permitem que suas aplicações atendam perfeitamente ao aumento da carga de trabalho.
O Hadoop representa uma maneira simples, flexível e barata de empurrar o processamento em literalmente milhares de servidores.
Com a sua arquitetura escalável e barata, o Hadoop parece ser uma escolha perfeita para arquivar dados de armazém … exceto por uma pequena questão: a maioria do mundo da TI é executada no SQL e o SQL por conta própria não funciona bem com o Hadoop.
Com certeza, o movimento NSQL mais amigável para o Hadoop está vivo e bom, mas a maioria dos usuários avançados agora usam o SQL por meio de conjuntos de ferramentas comuns que oferecem consultas SQL sob o capô - produtos como Tableau, Microsoft Excel e IBM Cognos BI.
É verdade que o ecossistema Hadoop inclui a Hive, mas a Hive suporta apenas um subconjunto de SQL e, embora o desempenho esteja melhorando (juntamente com o suporte ao SQL), não é quase tão rápido como responder consultas menores que são os sistemas relacionais. Recentemente, tem havido grandes avanços em relação ao acesso SQL ao Hadoop, que abriu caminho para o Hadoop se tornar o novo destino para arquivos de data warehouse em linha.
Dependendo do fornecedor do Hadoop, as APIs SQL (ou SQL) estão se tornando disponíveis para que as ferramentas de análise e análise mais comuns disponíveis possam emitir problemas de SQL que sejam executados em dados armazenados em Hadoop. Por exemplo, a IBM tem sua API Big SQL, Cloudera tem Impala e a própria Hive, através da iniciativa Hortonworks Stinger, está se tornando cada vez mais compatível com SQL.
Embora existam vários pontos de vista (alguns visam aumentar a colmeia, alguns, estender o Hive e outros para fornecer uma alternativa), todas essas soluções tentam abordar dois problemas: o MapReduce é uma solução fraca para a execução de consultas menores, e o acesso SQL é - por enquanto - a chave para permitir que os trabalhadores de TI usem suas habilidades SQL existentes para obter o valor dos dados armazenados no Hadoop.
