Elasticsearch finalmente ganha suporte a JOIN no estilo SQL

• O comando LOOKUP JOIN do ES|QL foi introduzido no ES 8.18, permitindo correlacionar e enriquecer dados
• É mais fácil de configurar e gerenciar do que o recurso ENRICH existente, sendo útil para joins de dados, análise correlacionada de eventos de segurança e mesclagem de informações de ativos
• Foi introduzido o novo modo lookup index baseado em shard único, projetado especificamente para JOINs — com capacidade para armazenar até 2 bilhões de documentos
• O LOOKUP JOIN lida facilmente com joins muitos-para-muitos e também é adequado para definição dinâmica de campos e agregações
• Pelo Kibana ou pela API, é possível criar facilmente índices de lookup a partir de CSV, e há planos para adicionar INNER JOIN e subqueries no futuro

---

O ES|QL agora tem um JOIN de verdade: apresentação do recurso LOOKUP JOIN

Agora também é possível fazer JOIN no estilo SQL no Elasticsearch

• A partir do Elasticsearch 8.18, o ES|QL oferece suporte a LOOKUP JOIN
• Ele segue o formato de LEFT OUTER JOIN, e os dados do “lado direito” são gerenciados por meio do novo modo de índice lookup
• Exemplos:
  • mesclar nomes de ambiente (dev, QA, prod) com base no endereço IP
  • adicionar informações de funcionários, ativos e inteligência de ameaças a eventos de segurança
  • analisar ambientes por código de resposta em logs web

Diferenças em relação ao ENRICH existente

• Abordagem ENRICH

  • é necessário configurar previamente uma política baseada em índice
  • sempre que os dados mudam, é preciso executar novamente a política
  • em caso de múltiplas correspondências, o retorno vem como campo multivalorado, o que complica o pós-processamento
  • não é adequada para agregações e análises estatísticas
  • é indicada para dados estáticos (informações de referência que quase não mudam)

• Abordagem LOOKUP JOIN

  • pode ser usada imediatamente, sem política separada
  • como o índice pode ser alterado diretamente, as mudanças são refletidas na hora
  • em caso de múltiplas correspondências, os resultados são separados por linha, facilitando a análise
  • é otimizada para agrupamentos e agregações (ex.: soma de tráfego por usuário)
  • também é vantajosa para dados dinâmicos e atualizados com frequência

Exemplo de uso

FROM kibana_sample_data_logs   
| WHERE response.keyword != "200"   
| LOOKUP JOIN envs_lkp ON clientip   
| STATS COUNT(*) by response, environment  

• Faz JOIN com dados de ambiente por IP para analisar onde ocorrem erros HTTP

• Também é possível fazer JOIN com informações de propriedade das equipes para identificar em quais servidores gerenciados por cada time há problemas

  FROM kibana_sample_data_logs   
  | WHERE response.keyword != "200"   
  | LOOKUP JOIN teams_lkp ON host   
  | STATS num = COUNT(*) by host, response.keyword, team   
  | SORT num DESC  
  

Como criar um índice de lookup

• Pela interface do Kibana: Stack Management → Index Management → Create index

• Pela API REST:

  PUT mylookupindex  
  {  
    "settings": {  
      "index.mode": "lookup"  
    }  
  }  
  

• Ao enviar um CSV via File Upload do machine learning, também é possível definir o modo lookup ao criar o índice

Cuidados e dicas

• Como JOIN é uma operação pesada, para campos usados com frequência vale considerar ENRICH + ingest-time denormalization em vez de lookup
• O lookup index é composto por um único shard e tem limite máximo de 2 bilhões de documentos
• Também é possível consultá-lo diretamente como em uma query comum, com FROM <lookup_index>
• Também é possível inserir dados por Logstash ou Elastic Agent (mas não como data stream)

Próximos passos

• Há planos para oferecer suporte também a INNER JOIN, SUBQUERY e join com índices comuns
• Também está prevista uma interface no Kibana para criar e editar índices de lookup diretamente
  • Ex.: arrastar e soltar um CSV no Discover → criação automática do índice
  • Também será oferecido um recurso de gerenciamento de Lookup baseado em GUI (um mockup já foi divulgado)

Resumo e como começar

• O LOOKUP JOIN ainda é uma prévia técnica antes do lançamento oficial, mas é um recurso capaz de levar o ES|QL a um novo patamar
• É possível começar com Elasticsearch 8.18 ou 9.0 no Elastic Cloud