Embora a flexibilidade das escolhas na organização quanto ao armazenamento de dados e compactação no Hadoop HDFS facilite o processamento dos dados, a compreensão das escolhas quanto a forma de armazenamento e o seu impacto na pesquisa, no desempenho e na usabilidade permite se pensar e melhores padrões de design quanto a arquitetura de armazenamento destes dados.
O HDFS é usado muito comumente para fins de armazenamento de dados, mas existem também outros sistemas comumente usados, como o HBase por exemplo, que apesar de armazenar os dados no HDFS possui uma forma própria de gerenciamento dos dados. Todos os formatos de armazenamento devem ser consideradas no desenho de uma arquitetura Hadoop. Há vários formatos de armazenamento e compactação adequados para diferentes casos de uso. Para armazenar dados brutos pode haver um certo formato de armazenamento e, após o processamento, pode se guardar os dados em outro formato de armazenamento diferente. Isso depende do padrão de acesso.
Existem vários formatos de armazenamento que são adequados para armazenar dados no HDFS, como arquivos de texto simples, formatos de arquivo avançados como Avro e Parquet, formatos específicos do Hadoop como sequence files. Esses formatos têm seus próprios prós e contras dependendo do caso de uso.
As soluções de Big Data devem ser capazes de processar uma grande quantidade de dados em tempo rápido. A compactação de dados acelera as operações de I / O e economiza espaço de armazenamento. Mas isso pode aumentar o tempo de processamento e a utilização da CPU devido à descompactação. Portanto, o equilíbrio é necessário – quanto maior a compactação – menor é o tamanho dos dados, mas em contrapartida é maior o processamento e a utilização da CPU.
Os arquivos compactados também devem ser divisíveis para suportar o processamento paralelo. Se um arquivo não é divisível, isso significa que não podemos inseri-lo em várias tarefas em paralelo e, portanto, perdemos a maior vantagem de estruturas de processamento paralelo do Hadoop, Spark etc.
Em qualquer sistema Hadoop os dados residem no HDFS, mas os pontos de decisão precisam ser considerados tais como se o acesso aleatório de dados é necessário e também se atualizações frequentes são necessárias. Os dados no HDFS são imutáveis, por isso, para atualizações frequentes precisamos de armazenamento semelhante ao do HBase que suporta atualizações.
Abaixo estão os princípios e considerações para organizar os dados na camada de armazenamento do Hadoop:
Exemplo de uma estrutura típica de pastas autoexplicativas que possui diferentes zonas de dados:
Como já discutimos na seção acima, os dados da camada de armazenamento do Hadoop são divididos em vários estágios. Para simplificar a discussão vamos classificar os dados armazenados em duas categorias simples:
Para dados brutos, os padrões de acesso seriam diferentes dos dados processados e, portanto, os formatos de arquivo seriam diferentes dos dados processados. Para fazer processamento sobre dados brutos geralmente usamos todos os campos de dados e, portanto, nosso sistema de armazenamento subjacente deve suportar esse tipo de uso de forma eficiente, mas só acessaremos apenas algumas colunas de dados processados em nossas consultas analíticas por isto nosso sistema de armazenamento subjacente deve ser capaz de lidar com esse caso de maneira mais eficiente em termos de I / O de disco etc.
Um caso de uso muito comum do ecossistema Hadoop é o de armazenar arquivos de log ou outros arquivos de texto simples com dados não estruturados para fins de armazenamento e análise. Esses arquivos de texto podem facilmente ocupar todo o espaço em disco, portanto, é necessário um mecanismo de compactação adequado dependendo do caso de uso. Por exemplo, algumas organizações usam o HDFS apenas para armazenar dados arquivados. Nesse caso, a utilização da melhor compactação é necessária, pois dificilmente haveria qualquer processamento nesses dados. Por outro lado, se os dados armazenados forem usados para fins de processamento, um formato de arquivo divisível om um nível de compactação aceitável é necessário.
Também devemos considerar o fato de que quando os dados são armazenados como arquivos de texto haverá sobrecarga adicional de conversões de tipo. Por exemplo, armazenar 10000 números inteiros como string ocuparia mais espaço e também exigiria conversão de tipo de string para Integer no momento da leitura. Essa sobrecarga aumenta consideravelmente quando temos o processamento de TBs de dados.
Existem formas mais sofisticadas de arquivos de texto com dados em alguns formulários padronizados, como arquivos CSV, TSV, XML ou JSON. No Hadoop, não há um formato de entrada construído para manipular arquivos XML ou JSON. Por não haver tags de início ou finalização em JSON há uma dificuldade em trabalhar com arquivos JSON pois é difícil dividir esses tipos de arquivos.
Para a maioria dos casos o armazenamento de arquivos binários, como imagens / vídeos, etc. no formato Container como sequence files é preferido, mas para arquivos binários muito grandes é preferível armazenar os arquivos como estão.
Existem muitos formatos de arquivo específicos para big data como estruturas de dados baseadas em arquivos como por exemplo sequence files, formatos de serialização como Avro, formatos colunares como Parquet ou ORC.
Esses arquivos contêm dados como pares binários de chave-valor. Existem mais 3 formatos que são:
Bloco compactado fornece melhor compactação do que apenas registro compactado. Um bloco se refere a um grupo de registros compactados juntos dentro de um bloco HDFS. Pode haver vários blocos de arquivos sequenciais dentro de um bloco HDFS.
Formatos colunares são geralmente usados onde você precisa consultar algumas colunas em vez de todos os campos em linha, porque o padrão de armazenamento orientado por coluna é adequado para o mesmo. Por outro lado, os formatos de linha são usados onde você precisa acessar todos os campos da linha. Então, geralmente, o Avro é usado para armazenar os dados brutos, porque durante o processamento, geralmente, todos os campos são necessários.
As principais vantagens do formato colunar são:
Conceito que é usado no momento da leitura de dados de qualquer armazenamento de dados. Ele é seguido pela maioria dos RDBMS e agora foi seguido por formatos de armazenamento de dados grandes como Parquet e ORC também.
Quando usamos alguns critérios de filtragem, o armazenamento de dados tenta filtrar os registros no momento da leitura do disco. Esse conceito é chamado de pushdown de predicado. A vantagem do pushdown de predicado é que menos I / O de discos acontecerão e, portanto, o desempenho sera melhor. Caso contrário, dados inteiros serão trazidos para a memória e em seguida, filtrados, o que resulta em um grande requisito de memória.
Quando os dados são lidos do armazenamento de dados, apenas as colunas necessárias serão lidas. Geralmente os formatos colunares como Parquets e ORC seguem esse conceito, o que resulta em melhor desempenho de I / O.
Hierarquicamente, um arquivo consiste em um ou mais grupo de linhas. Um grupo de linhas contém exatamente um bloco de coluna por coluna. Pedaços de colunas contêm uma ou mais páginas.
Embora o armazenamento de dados no Hadoop seja um esquema menos natural, ainda há muitos outros aspectos que precisam ser tratados. Isso inclui a estrutura de diretórios no HDFS, bem como a saída do processamento de dados.
É uma maneira comum de reduzir o I / O de disco durante a leitura do HDFS. Normalmente os dados no HDFS são muito grandes e a leitura de todo o conjunto de dados não é possível e também não é necessária em muitos casos. Uma boa solução é dividir os dados em partes / partições e ler o pedaço necessário. Considerações sobre particionamento:
Às vezes, se tentarmos particionar os dados em algum atributo para o qual a cardinalidade é alta o número de partições possíveis a ser criada pode exceder. Por exemplo, se tentarmos particionar os dados por um campo chamado tradeId, o número de partições criadas seria muito grande. Isso pode causar o problema “Excesso de arquivos pequenos”, resultando em problemas de memória no nameNode e também o processamento de tarefas criadas seria maior (igual ao número de arquivos) quando processado com o Apache Spark.
Em tais cenários, é recomendável criar partições / blocos hash. Uma vantagem adicional de bucketing é que ao unir dois conjuntos de dados como por exemplo dados de atributos de negociação (Deal number, Deal date etc.) com dados de atributos de risco de negociação (Risk measure type, risk amount) para fins de relatório é possível estabelecer esta relação com um campo tradeId por exemplo.
No Hadoop, é aconselhável armazenar os dados no formato Denormalized, de modo que haja menos requisitos para unir os dados. As junções são operações mais lentas no Hadoop, pois envolvem geralmente grande quantidade de dados.
Portanto, os dados devem ser pré-processados para desnormalização e pré-agregados, se forem necessárias agregações frequentes.
Tanto no Avro quanto no Parquet você pode ter dados estruturados planos, bem como dados de estrutura aninhada.
Hadoop in Practice, Second Edition
By: Alex Holmes
Publisher: Manning Publications
Pub. Date: September 29, 2014
Url: http://techbus.safaribooksonline.com/book/databases/hadoop/9781617292224
Data Lake Development with Big Data
By: Pradeep Pasupuleti; Beulah Salome Purra
Publisher: Packt Publishing
Pub. Date: November 26, 2015
Url: http://techbus.safaribooksonline.com/9781785888083
Hadoop Application Architectures
By: Mark Grover; Ted Malaska; Jonathan Seidman; Gwen Shapira
Publisher: O’Reilly Media, Inc.
Pub. Date: July 15, 2015
Url: http://techbus.safaribooksonline.com/book/databases/hadoop/9781491910313
You must be logged in to post a comment.