OLAP baseado em LLM: a experiência da Tencent com Apache Doris

Seis meses atrás, escrevi sobre por que substituímos o ClickHouse pelo Apache Doris como um mecanismo OLAP para nosso sistema de gerenciamento de dados. Naquela época, estávamos lutando com a geração automática de instruções SQL. Com o passar dos dias, fizemos progressos grandes o suficiente para serem referências para vocês, então aqui estou eu novamente.

Adotamos Large Language Models (LLM) para capacitar nossos serviços OLAP baseados em Doris.

LLM + OLAP

Nosso incentivo foi salvar nossa equipe interna da íngreme curva de aprendizado da escrita SQL. Assim, usamos o LLM como intermediário. Ele transforma questões de linguagem natural em instruções SQL e envia os SQLs para o mecanismo OLAP para execução.

Como toda experiência relacionada à IA, encontramos alguns atritos:

1. O LLM não entende jargões de dados, como “campos”, “linhas”, “colunas” e “tabelas”. Em vez disso, eles podem traduzir perfeitamente termos comerciais como "renda corporativa" e "DAU", que são basicamente o assunto dos campos/linhas/colunas. Isso significa que só poderá funcionar bem se os analistas usarem a palavra exata para se referir à métrica de que precisam ao digitar suas perguntas.

   
   

2. O LLM que estamos usando é lento em inferência. Demora mais de 10 segundos para responder. Como cobra taxas por token, a relação custo-benefício torna-se um problema.

   
   

3. Embora o LLM seja treinado em uma grande coleção de conjuntos de dados públicos, ele está mal informado sobre conhecimentos de nicho. No nosso caso, o LLM não tem muita familiaridade com músicas indie, então mesmo que as músicas estejam incluídas em nosso banco de dados, o LLM não conseguirá identificá-las adequadamente.

   
   

4. Às vezes, nossas perguntas de entrada exigem informações jurídicas, políticas, financeiras e regulatórias adequadas e mais recentes, que são difíceis de serem incluídas em um conjunto de dados de treinamento ou base de conhecimento. Precisamos conectar o LLM a bases de informações mais amplas para realizar tarefas mais diversificadas.

   
   

Eliminamos esses problemas um por um.

1. Uma camada semântica

Para o problema nº 1, introduzimos uma camada semântica entre o LLM e o mecanismo OLAP. Esta camada traduz os termos comerciais nos campos de dados correspondentes. Ele pode identificar condições de filtragem de dados a partir de diversas formulações de linguagem natural, relacioná-las com as métricas envolvidas e, em seguida, gerar instruções SQL.

Além disso, a camada semântica pode otimizar a lógica computacional. Quando os analistas inserem uma pergunta que envolve uma consulta complicada, digamos, uma junção de múltiplas tabelas, a camada semântica pode dividir isso em múltiplas consultas de tabela única para reduzir a distorção semântica.

2. Regras de análise LLM

Para aumentar a relação custo-benefício no uso do LLM, avaliamos a complexidade computacional de todos os cenários, como cálculo métrico, recuperação detalhada de registros e segmentação de usuários. Em seguida, criamos regras e dedicamos a etapa de análise do LLM apenas a tarefas complicadas. Isso significa que para tarefas de computação simples, a análise será ignorada.

Por exemplo, quando um analista insere “diga-me os ganhos das principais plataformas musicais”, o LLM identifica que esta questão envolve apenas várias métricas ou dimensões, por isso não irá analisá-la mais, mas enviá-la diretamente para geração e execução SQL. Isso pode reduzir bastante o tempo de resposta da consulta e reduzir as despesas com API.

3. Mapeador de esquema e base de conhecimento externa

Para capacitar o LLM com conhecimento de nicho, adicionamos um Schema Mapper upstream do LLM. O Schema Mapper mapeia a questão de entrada para uma base de conhecimento externa e, em seguida, o LLM fará a análise.

Estamos constantemente testando e otimizando o Schema Mapper. Categorizamos e classificamos o conteúdo na base de conhecimento externa e realizamos vários níveis de mapeamento (mapeamento de texto completo e mapeamento difuso) para permitir uma melhor análise semântica.

4. Plug-ins

Usamos plugins para conectar o LLM a mais campos de informação e temos diferentes métodos de integração para diferentes tipos de plugins:

• Incorporação de arquivos locais : Isso é especialmente útil quando precisamos "ensinar" ao LLM as políticas regulatórias mais recentes, que geralmente são arquivos de texto. Em primeiro lugar, o sistema vetoriza o arquivo de texto local, executa pesquisas semânticas para encontrar termos correspondentes ou semelhantes no arquivo local, extrai o conteúdo relevante e os coloca na janela de análise LLM para gerar a saída.

  
  

• Plug-ins de terceiros : o mercado está cheio de plug-ins de terceiros projetados para todos os tipos de setores. Com eles, o LLM é capaz de tratar de temas variados. Cada plugin tem seus próprios prompts e funções de chamada. Assim que a pergunta de entrada chegar a um prompt, o plugin relevante será chamado.

Depois de concluirmos as quatro otimizações acima, a estrutura SuperSonic passa a existir.

A estrutura SuperSonic

Agora, deixe-me guiá-lo por esta estrutura :

• Um analista insere uma pergunta.

  
  

• O Schema Mapper mapeia a questão para uma base de conhecimento externa.

  
  

• Se houver campos correspondentes na base de conhecimento externa, a questão não será analisada pelo LLM. Em vez disso, uma fórmula de cálculo métrico acionará o mecanismo OLAP para iniciar a consulta. Caso não haja campo correspondente, a questão entrará no LLM.

  
  

• Com base nas regras pré-definidas, o LLM avalia o nível de complexidade da questão. Se for uma consulta simples, irá diretamente para o mecanismo OLAP; se for uma consulta complicada, ela será analisada semanticamente e convertida em uma instrução DSL.

  
  

• Na Camada Semântica, a instrução DSL será dividida com base no seu cenário de consulta. Por exemplo, se for uma consulta de junção de múltiplas tabelas, esta camada gerará múltiplas instruções SQL de consulta de tabela única.

• Caso a questão envolva conhecimento externo, o LLM chamará um plugin de terceiros.

Exemplo:

Para responder se uma determinada música pode ser tocada em programas de variedades, o sistema recupera o data warehouse OLAP para obter detalhes sobre a música e apresenta resultados do plug-in de terceiros Commercial Use Query.

Arquitetura OLAP

Quanto à parte OLAP desta estrutura, após várias rodadas de evolução arquitetônica, é assim que se parece o nosso pipeline OLAP atual.

Os dados brutos são classificados em tags e métricas, que são definidas de forma personalizada pelos analistas. As tags e métricas estão sob gerenciamento unificado para evitar definições inconsistentes. Em seguida, eles são combinados em vários conjuntos de tags e conjuntos de métricas para diversas consultas.

Extraímos para você duas conclusões principais de nossa experiência em otimização arquitetônica.

1. Simplifique os links

Antes de adotarmos o Apache Doris, tínhamos o ClickHouse para acelerar o cálculo de tags e métricas e o Elasticsearch para processar dados dimensionais. São dois mecanismos analíticos e exigem que adaptemos as instruções de consulta a ambos. Era de muita manutenção.

Assim, substituímos o ClickHouse pelo Apache Doris e utilizamos a funcionalidade do Elasticsearch Catalog para conectar os dados do Elasticsearch ao Doris. Dessa forma, fazemos do Doris nosso gateway de consulta unificado.

2. Divida as mesas planas

Nas primeiras versões de nossa arquitetura OLAP, costumávamos colocar os dados em tabelas simples, o que tornava as coisas complicadas. Por um lado, as tabelas planas absorveram toda a latência de gravação dos upstreams, e isso resultou em uma perda considerável na atualidade dos dados. Por outro lado, 50% dos dados em uma tabela plana eram dados dimensionais, que raramente eram atualizados. Com cada nova tabela plana, surgiram alguns dados dimensionais volumosos que consumiam muito espaço de armazenamento.

Portanto, dividimos as tabelas simples em tabelas de métricas e tabelas de dimensões. À medida que são atualizados em ritmos diferentes, nós os colocamos em modelos de dados diferentes.

• Tabelas de métricas : organizamos os dados de métricas no modelo Aggregate Key do Apache Doris, o que significa que os novos dados serão mesclados com os dados antigos por meio de SUM, MAX, MIN, etc.

  
  

• Tabelas de dimensões : essas tabelas estão no modelo Unique Key do Apache Doris, o que significa que o novo registro de dados substituirá o antigo. Isso pode aumentar bastante o desempenho em nossos cenários de consulta.

  
  

Você pode perguntar: isso causa problemas nas consultas, já que a maioria das consultas requer dados de ambos os tipos de tabelas? Não se preocupe, resolvemos isso com o recurso Rollup do Doris. Com base nas tabelas base, podemos selecionar as dimensões necessárias para criar visualizações Rollup, que serão executadas automaticamente GROUP BY . Isso nos alivia da necessidade de definir tags para cada visualização cumulativa e acelera bastante as consultas.

Outros truques

Em nossa experiência com o Apache Doris, também encontramos algumas outras funcionalidades úteis, então eu as listo aqui para você também:

1. Visão Materializada

Uma visualização materializada é um conjunto de dados pré-computado. É uma forma de acelerar consultas quando você precisa acessar frequentemente dados de determinadas dimensões. Nesses cenários, definimos tags e métricas derivadas com base nas originais. Por exemplo, criamos uma métrica derivada combinando Métrica 1, Métrica 2 e Métrica 3: sum(m1+m2+m3) . Então, podemos criar uma Visualização Materializada para ele. De acordo com o cronograma de lançamento do Doris, a versão 2.1 oferecerá suporte a visualizações materializadas de várias tabelas, e estamos ansiosos por isso.

2. Conector Flink-Doris

Isto é para garantia Exatamente Uma Vez na ingestão de dados. O Flink-Doris-Connector implementa um mecanismo de checkpoint e commit em dois estágios e permite a sincronização automática de dados de bancos de dados relacionais para Doris.

3. Compactação

Quando o número de tarefas de agregação ou o volume de dados se torna excessivo para o Flink, pode haver uma enorme latência na compactação de dados. Resolvemos isso com Compactação Vertical e Compactação de Segmentos. A Compactação Vertical suporta o carregamento de apenas parte das colunas, podendo reduzir o consumo de armazenamento ao compactar mesas planas. A compactação de segmentos pode evitar a geração de muitos segmentos durante a gravação de dados e permite a compactação durante a gravação simultânea.

Qual é o próximo

Com o objetivo de reduzir custos e aumentar a disponibilidade do serviço, planejamos testar a recém-lançada separação de armazenamento-computação e replicação entre clusters do Doris, e aceitamos quaisquer ideias e contribuições sobre a estrutura SuperSonic e o projeto Apache Doris.