Hadoop como um destino de dados de arquivo

O custo barato de armazenamento para Hadoop mais a capacidade de consultar dados do Hadoop com SQL faz Hadoop o principal destino para os dados de arquivamento. Este caso de uso tem um baixo impacto sobre sua organização, porque você pode começar a construir a sua habilidade Hadoop definido em dados que não está armazenado em sistemas de desempenho de missão crítica.

Além do mais, você não tem que trabalhar duro para obter os dados. (Uma vez que os dados arquivados normalmente são armazenados em sistemas que têm pouco uso, é mais fácil de obter pelo que os dados que está no “centro das atenções” em sistemas de desempenho de missão crítica, como armazéns de dados.) Se você já está usando o Hadoop como um pouso zona, você tem a base para o seu arquivo! Você simplesmente manter o que você deseja arquivar e excluir o que você não.

Se você pensar sobre zona de aterragem do Hadoop, o arquivo queryable, mostrado na figura, estende-se o valor de Hadoop e passa a integrar peças que provavelmente já existem em sua empresa. É um grande exemplo de encontrar economias de escala e de custo oportunidades de take-out usando Hadoop.

Aqui, o componente de arquivo liga a zona de aterragem e data warehouse. Os dados a serem arquivados origina em armazém e é então armazenado no cluster Hadoop, que também é o provisionamento da zona de aterragem. Em suma, você pode usar o mesmo cluster Hadoop para arquivar dados e agir como sua zona de aterragem.

A tecnologia-chave Hadoop você usaria para realizar o arquivamento é Sqoop, que pode mover os dados a serem arquivados a partir do armazém de dados para Hadoop. Você terá de considerar a forma que você deseja que os dados para levar em seu cluster Hadoop. Em geral, os arquivos compactados Hive são uma boa escolha.

Você pode, é claro, transformar os dados das estruturas para armazenagem em alguma outra forma (por exemplo, uma forma normalizada para reduzir a redundância), mas isso geralmente não é uma boa idéia. Manter os dados na mesma estrutura que o que está no armazém, será muito mais fácil de executar uma consulta de conjunto de dados completo em todo os dados arquivados em Hadoop e os dados ativo que está no armazém.

O conceito de consultar ambos os conjuntos de dados ativos e arquivados traz à tona uma outra consideração: a quantidade de dados que você deve arquivar? Há realmente duas escolhas comuns: arquivar tudo conforme os dados são adicionadas e alteradas no armazém de dados ou somente arquivar os dados que consideram ser frio.

Arquivar tudo tem o benefício de permitindo-lhe emitir facilmente consultas de uma interface única em todo o conjunto de dados - sem um arquivo completo, você precisa descobrir uma solução de consulta federada onde você teria de união os resultados a partir do arquivo e o armazém de dados activa.

Mas a desvantagem é que as atualizações regulares de dados quentes do seu data warehouse poderia causar dores de cabeça para o arquivo baseado em Hadoop. Isso ocorre porque quaisquer alterações aos dados em linhas e colunas individuais exigiria exclusão atacado e re-catalogação de conjuntos de dados existentes.

Agora que os dados de arquivo é armazenado em sua zona de aterragem baseados em Hadoop (supondo que você está usando uma opção como os arquivos compactados Hive mencionados anteriormente), você pode consultá-lo. Este é o lugar onde o SQL em soluções Hadoop pode se tornar interessante.

Um excelente exemplo do que é possível é para as ferramentas de análise (à direita na figura) para rodar diretamente relatórios ou análises sobre os dados arquivados armazenados no Hadoop. Esta não é substituir o data warehouse - afinal, o Hadoop não seria capaz de igualar as características de desempenho do armazém para centenas de apoio ou mais usuários simultâneos fazendo perguntas complexas.

O ponto aqui é que você pode usar ferramentas de relatório contra o Hadoop para experimentar e chegar a novas perguntas para responder em um armazém dedicado ou mart.

Ao iniciar seu primeiro projeto baseado em Hadoop para o arquivamento de dados do warehouse, não quebre os processos atuais até que você tenha testado-los plenamente na sua nova solução de Hadoop. Em outras palavras, se sua estratégia de armazenamento atual é para arquivar em fita, manter esse processo no lugar e dual-arquivar os dados em Hadoop e fita até que você tenha testado completamente o cenário (que normalmente incluiria a restauração dos dados do armazém, no caso de uma falha do armazém).

Embora você está mantendo (no curto prazo) dois repositórios de arquivo, você terá uma infra-estrutura robusta no lugar e testado antes de encerrar um processo tentou-e-verdadeiro. Este processo pode garantir que você permanecer empregado - com o seu empregador atual.

Este caso de uso é simples porque não há nenhuma mudança para o armazém existente. O objetivo de negócio ainda é o mesmo: mais baratos os custos de armazenamento e licenciamento de migração de dados raramente usados ​​para um arquivo. A diferença neste caso é que a tecnologia por trás do arquivo é Hadoop ao invés de armazenamento offline, como uma fita.

Além disso, vários fornecedores de arquivo já começaram a incorporar Hadoop em suas soluções (por exemplo, permitindo que os seus ficheiros de arquivo de propriedade para residir no HDFS), assim esperamos capacidades nesta área para expandir em breve.

Como você desenvolver habilidades Hadoop (como troca de dados entre Hadoop e bancos de dados relacionais e dados consultando no HDFS), você pode usá-los para resolver problemas maiores, como projetos de análise, que poderiam fornecer valor adicional para investimento Hadoop da sua organização.