Gerenciando o desempenho da tarefa
Os fluxos de mascaramento, que copiam e mascaram dados, podem ser implementados usando-se a Spark. No entanto, o Spark tem várias características e limitações que afetam o desempenho do trabalho de fluxo de mascaramento e podem resultar em falhas de trabalho.
Gerenciando falhas de tarefas
Durante uma tarefa de fluxo de mascaramento, o Spark pode tentar ler tudo de uma origem de dados na memória. Por isso, as tarefas de fluxo de mascaramento podem enfrentar erros devido a condições de falta de memória. O maior volume de dados que pode se ajustar ao maior nó de processamento do Spark implementado é de aproximadamente 12 GBs. Para que um fluxo de mascaramento seja capaz de copiar e mascarar mais do que este volume de dados, o mecanismo do Spark deve ser capaz de particionar os dados em chunks menores. O Spark pode então processar cada chunk separadamente e em paralelo com outros chunks.
Existem algumas origens de dados, como arquivos do Parquet, em que o Spark pode particionar automaticamente os dados. No entanto, nenhuma dessas origens de dados são suportadas por fluxos de mascaramento agora.
Uma alternativa é especificar uma coluna de índice quando você está criando um fluxo de mascaramento para permitir que o Spark particione os dados. Para as origens de dados relacionais atualmente suportadas, a primeira etapa é localizar ou criar uma coluna de índice que divide os dados em porções aproximadamente iguais. A próxima etapa é fornecer um nome de coluna no índice de modo o Spark possa criar uma consulta que usará o índice. O fluxo de mascaramento descobrirá automaticamente e fornecerá outros dados que são necessários pelo Spark: os valores mínimo e máximo da coluna e o número de partições de dados a ser utilizado.
Melhores práticas
Para melhores resultados, os dados na coluna de particionamento devem ser distribuídos uniformemente. O objetivo de uma coluna de partição é permitir que o Spark divida os dados em peças consideráveis para processamento. Por exemplo, se os dados forem 10 TB divididos por 50 depósitos, cada chunk ainda será 0,2 TB. Quanto maior o número de depósitos, mais rápido o processamento.
Escolha uma coluna de partição, na qual os valores são distribuídos uniformemente sobre um grande intervalo. As colunas identificadoras são muitas vezes boas escolhas. Por exemplo, uma tabela Clientes possui uma coluna Customer_ID contendo 1,5 M IDs exclusivos. Uma coluna de estado não é um bom exemplo porque há apenas 50 valores exclusivos.