top of page

Databricks - Deletion Vector - Photon - Preditictive IO - Comparando a performance

Fala dataholics, no post de hoje continuaremos no tema do último post, alguns comentários bem legais no último post perguntando se havia usado Deletion Vector ou Photon nos teste entre o Merge e o ReplaceWhere.


Se você ainda não leu o último post, dá uma conferida la:

Nesse post mostrei a diferença de performance entre os comandos Merge e ReplaceWhere, onde o ReplaceWhere quando bem aplicado é extremamente mais performático que o comando Merge, alguns comentários me incentivaram a escrever esse post, onde mostraremos o comando Merge agindo em diferentes engines e contextos.


Este artigo não é sobre Photon em si, mas, após esses testes, trarei muito mais coisas de Photon para o Blog.


O que veremos nesse post:

  • Deletion Vector

  • Photon

  • Predictive IO

  • Parâmetros dos testes

  • Comparação de performance Merge

  • Comparação de performance Delete

  • Resumo

  • Quanto custou essa comparação


 

Deletion Vector


Não há muito o que falar sobre Deletion Vector, pois, já escrevi esse post abaixo, apesar de ser antigo a sua base não mudou:

Basicamente o Deletion Vector vem para otimizar as operações de escrita no Storage, comandos como Delete, Update e MERGE que fazem muita gravação no Storage foram otimizados com essa engine.


De forma bem simplista, a proposta principal do Deletion Vector é reduzir a escrita no storage utilizando um mapa de vetores para marcar registros alterados num PARQUET.

Ou seja, se você alterar 1 registro dentro de 1 PARQUET gigante, ao invés da engine marcar ele como excluído e criar um novo PARQUET gigante, ela simplesmente cria um mapa de vetores com poucos KBs, reduzindo escrita e storage, no post acima tem muito mais detalhes e explicação técnica.

 

Photon


Photon é uma Engine de aceleração de queries da Databricks, focada para código SQL, ela é uma engine totalmente compatível com as Spark APIS e pode rodar seus códigos criados anteriormente sem necessidade de alteração, ou seja, todo código SQL que já funcionava com Spark SQL em um cluster All Purspose, funciona nativamente no Photon.


O Photon é a Engine nativa dos clusters SQL Warehouse, enquanto nos Clusters All Purpose ou Jobs, ela é opcional e mesmo quando habilitado o Photon nos clusters All Purpose, não é sempre que a engine será utilizada, para isso você deve usar código SQL, para garantir se usou o Photon ou não, basta olhar no plano de execução.


O Photon é uma engine completamente nova escrita em C++, ela tem várias features para aceleração de performance de queries, controle de cache mais eficiente, melhores tratamentos para agregações e JOINs, por isso ela é nativamente usada para o SQL Warehouse, onde é conectado as ferramentas de visualização como Power BI.



Caso se interesse segue o paper do Photon, recomendo a leitura:

É fascinante ver como o Photon se integrou ao DBR e interage fortemente com as Spark APIs, que trabalho fora da curva, a interoperabilidade das duas linguagens, nesse caso Java e C++ feita toda a via JNI (Java Native Interface) para alcançar uma performance surreal.


Como habilitar o Photon em clusters All Purspose e Job Cluster:


Agora em clusters SQL Warehouse, você não precisa habilitar, ela é a engine Default, o que você escolhe são os tipos de Warehouse:


Basicamente as principais diferenças entre os 3 modelos são essas:


Na nossa demo usaremos um Warehouse PRO para comparação de performance, com esse tipo, temos o Photon + Prediticve Optimization.


O Predictive IO é uma feature para otimização de acesso ao Storage, usando inteligência artificial para buscas e escritas mais eficientes no Storage, minimizando a quantidade de leituras ou fazendo leituras a frente para otimizar o cache de dados, é realmente sensacional.

 

Parâmetros dos testes


Para os testes de comparação usaremos o seguinte ambiente:

Cluster All Purpose: DBR: 14.3 LTS, 1x Standard_E8ds_v4

SQL Warehouse PRO: 2X-Small (Por detrás dos panos as máquinas utilizadas são Standard_E8ds_v4 )

Tabelas de dados: 1x tabela com 59 milhões de registros, particionada por ano, mês e dia.

Testes: Aplicaremos uma operação de MERGE em uma partição de 11 milhões de registros, testaremos com e Sem Deletion Vector.

Cluster All Purpose:

Observação: Vale ressaltar que quando você habilita o Photon nos clusters All Purpose ou Job Cluster o custo dos DBUs também aumentam, ou seja, não é de graça habilitar o Photon.

Para esse cluster abaixo o custo do DBU sai de 2.75 para 5.5 DBU/h.


SQL Warehouse:

Como o Photon é nativo, o custo já está embutido, por isso você notara que o usar um SQL Warehouse é um pouco mais caro que usar um Cluster All Purpose, a infraestrutura de ambos também são bem diferentes.


 

Comparação de performance no MERGE


Criamos duas tabelas:

pedidosSemDeletionVector - Sem Deletion Vector
pedidosComDeletionVector - Com Deletion Vector

Ambas tabelas com mesmo número de arquivos e tamanho.


No Storage: Ambas pastas exatamente iguais após a criação.


Iniciando os testes:

Para o teste criaremos uma view temporária que contém os registros que queremos aplicar o MERGE.


Sem Deletion Vector e sem Photon rodando em um cluster All Purpose.

Merge: 2.91 minutos (Arredondando 3 minutos)


Com Deletion Vector e sem Photon rodando em um cluster All Purpose.

Merge: 2.46 minutos (Arredondando 2 minutos)


Métricas:

Sem Deletion Vector


Com Deletion Vector


Se olhar nas métricas da execução, não temos diferença nenhuma e o tempo relativamente parecido.


No storage notaremos que o Deletion Vector está sendo usado na tabela habilitada.


Vamos para os testes com o Warehouse PRO.


Sem Deletion Vector e COM Photon rodando em um cluster SQL Warehouse PRO.

Merge: 1.58 minutos (Arredondando 2 minutos)

Obs: Sem Cache de dados, testando com o Cache o tempo reduziu para 59 segundos.


Com Deletion Vector e COM Photon rodando em um cluster SQL Warehouse PRO.

Merge: 58 segundos

Obs: Sem Cache de dados.


Conclusão usando MERGE com ou sem Deletion Vector: Performance muito equivalente.

Conclusão usando Com ou sem Photon: Diferença bem significante.


 

Comparação de performance no DELETE


Agora, compararemos o DELETION VECTOR em operações puras de DELETES, simularei algumas operações de 200x DELETEs sequenciais.


200x Deletes Sem Photon e sem Deletion Vector: 24 minutos


200x Deletes Sem Photon e COM Deletion Vector: 25 minutos


200x Deletes COM Photon e Sem Deletion Vector: 12 minutos


200x Deletes COM Photon e Com Deletion Vector: 10 minutos


Aqui podemos confirmar que o Deletion Vector está de fato atuando.


Olhando para o Storage também podemos afirmar que o Deletion Vector está em ação:


 

Resumo dos testes


Não era bem esse resultado que esperava, confesso que gostaria de ver uma diferença maior com o Deletion Vector, embora, em relação à performance de usar ou não usar o Deletion Vector, podemos notar que a diferença foi muito pequena em todos os cenários.


Onde o Deletion Vector se destacou foi no espaço consumido pelo Storage, após todas as operações de Delete finalizarem, notem que a pasta com Deletion Vector, apesar de ter mais arquivos, ela está menor em espaço consumido, isso pelo fato que muitos arquivos PARQUETs não precisaram ser reescritos e apenas um mapa de vetor foi criado com poucos KBs.


Apesar dos testes acima, recomendo a utilização do Deletion Vector, inclusive ele está vindo habilitado por Default para novas tabelas criadas com a versão do DBR 14.x ou criadas no SQL Warehouse usando o UC.


O grande ponto de hoje vai para o Photon, com ele podemos notar diferenças extremas de performance tanto no MERGE quanto em operações simples de DELETE.


Podemos notar que em todos os testes o Photon conseguiu reduzir todos eles na metade do tempo, o que pode justificar e muito a sua utilização.


Esses testes não são um benchmark oficial, apesar de qualquer um poder simular, não disponibilizarei todos os detalhes das simulações.


Testei várias outras situações, como Delete no Merge, operações com uma massa de dados maior ou com poucos registros, todas seguiram os mesmos padrões, onde, o Photon se mostrou muito mais performático e o Deletion Vector imperceptível em relação à performance (mas, eficiente no espaço consumido no storage).


Esses testes me custaram algo em torno de R$250 reais para manter os clusters ligados durante os testes, é não é barato brincar com essas coisas, mas com certeza levarei mais experiência para os ambientes que tenho Photon ou Deletion Vector.


Espero que tenha gostado, comenta aí se você quer ver novos testes de performance e como gostaria de comparar, adicionarei ao meu backlog de testes.


Fique bem e até a próxima.


Referências:




147 visualizações0 comentário

Posts recentes

Ver tudo

Yorumlar


Post: Blog2 Post
bottom of page