Conforme experiências em projetos atuais, tenho encontrado muitos
analistas que tem dificuldade em efetuar consultas nas bases de dados na estrutura do Big Data. A maioria das ingestões são feitas no Data Lake diariamente com apena
um “Delta” das informações, que seriam atualizações ocorridas dos registros durante o período
de um dia.
Nos projetos o Data Lake se tornar uma referência as fontes de origem, devido a documentação do dado ser compátivel ao sistema que originou a informação e a sua vizibilidade se torna maior devido ao conhecimento dos colaboradores dessa estrutura transacional, deste modo, o Data Lake acaba sendo fonte para diversas consultas no modo dimensional.
Nos projetos o Data Lake se tornar uma referência as fontes de origem, devido a documentação do dado ser compátivel ao sistema que originou a informação e a sua vizibilidade se torna maior devido ao conhecimento dos colaboradores dessa estrutura transacional, deste modo, o Data Lake acaba sendo fonte para diversas consultas no modo dimensional.
Esse processo ao consultar o Datalake onera drasticamente o
cluster, pois cada consulta aos dados brutos, a engine percorre toda a tabela ocorrendo o “full-scan”. Devemos lembrar que diferentemente de uma estrutura de um banco
de dados relacional, o Hive por ser um sumarizador de dados, ele não tem os
mesmos recursos de indexadores que um banco relacional, mas leva vantagem na
paralelização dos processos.
Para esclarecer melhor esse cenário, vamos supor que um cientista
de dados necessita montar um modelo no qual ele precisa consultar a cidade na
tabela de clientes.
No caso de uma consulta pelo Data Lake, o processo deverá
percorrer todas as partições e trazer o registro mais recente, no caso acima está
mencionado um exemplo de dados com 6 partições, se utilizarmos a persistência de
dados de 3 anos, são 1095 partições.
Caso em consultas no
Data Lake o join mais performático é feito da seguinte maneira:
Seguindo os conceitos "top down" definido por Bill Inmon, de amenizar esse processamento de
toda tabela, seria a construção de um Data Mart no qual a tabela seria
atualizada diariamente.
Fonte: https://www.computerweekly.com/tip/Inmon-or-Kimball-Which-approach-is-suitable-for-your-data-warehouse
acesso em 07/08/2019
Diariamente seria executado um script no qual consultaria a
nova partição criada no Data Lake e atualizaria seu Data Mart. Essa tabela geralmente
não é particionada e sua performance referente a consulta, será bem menos onerosa
ao cluster.
O modelo de query para executar o processo diário:
--INSERIR EM UMA TABELA A VISAO DO DIA ANTERIOR
INSERT INTO TABLE TABELA_UNIAO
SELECT ID, NOME, CIDADE, DATA_INGESTAO FROM DATAMART.CLIENTE;
--INSERIR O DIA DA NOVA PARTICAO DO DATALAKE
INSERT INTO TABLE TABELA_UNIAO
SELECT ID, NOME, CIDADE, DATA_INGESTAO
FROM DATAMART.CLIENTE
WHERE DATA_INGESTAO = "2019-01-06";
--CARREGAR O DATA MART COM OS DADOS MAIS RECENTES
INSERT OVERWRITE TABLE DATAMART.CLIENTE
SELECT
SUB_CLIENTE.ID,
SUB_CLIENTE.NOME,
SUB_CLIENTE.CIDADE,
SUB_CLIENTE.DATA_INGESTAO
FROM(
ID,
NOME,
CIDADE,
DATA_INGESTAO,
RANK() OVER (PARTITION BY ID ORDER BY DATA_INGESTAO DESC) RANKING
FROM DATALAKE.CLIENTE
) SUB_CLIENTE
WHERE SUB_CLIENTE.RANKING = 1;
Algumas orientações podem ser aplicadas:
- Em Big Data a replicação dos dados é permitida se caso for utilizado para o aumento de performance na consulta, mas deve ser avalidado com ponderação.
- Na instrução sql aplicada acima, utilizamos o RANK(), pois apresenta melhor performance na execução, mas caso possui uma duplicação de chaves (ID e DATA_INGESTAO), apresentará a quantidade de registros com o mesmo ranque (No caso acima multiplos registros com SUB_CLIENTE.RANKING = 1), para solucionar esse caso é possível utilizar a função ROW_NUMBER(). Fonte: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+WindowingAndAnalytics
- Outra forma segura de carregar o Data Mart e diminuir a indisponibilidade é utilizar o processo Exchange Partition. Fonte: https://cwiki.apache.org/confluence/display/Hive/Exchange+Partition
O assunto de estrutura de dados é algo importante e deve ser
discutida, pois em alguns casos o processo começa apresentar falhas após meses de
operação sistema, no qual, já está finalizado
o período de garantia oferecido pelo fornecedor.
Em caso de dúvidas ou sugestões, escreva nos comentários ou nos mande um email: slothbigdata@gmail.com.
