Arquitetura de dados em Big Data

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.

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.