OLAP impulsado por LLM: la experiencia Tencent con Apache Doris

Hace seis meses, escribí sobre por qué reemplazamos ClickHouse con Apache Doris como motor OLAP para nuestro sistema de gestión de datos. En aquel entonces, estábamos luchando con la generación automática de declaraciones SQL. Conforme pasan los días, hemos logrado avances lo suficientemente grandes como para ser referentes para ustedes, así que aquí estoy nuevamente.

Hemos adoptado modelos de lenguaje grande (LLM) para potenciar nuestros servicios OLAP basados en Doris.

Máster en Derecho + OLAP

Nuestro incentivo fue salvar a nuestro personal interno de la pronunciada curva de aprendizaje de la escritura SQL. Por tanto, utilizamos LLM como intermedio. Transforma preguntas en lenguaje natural en declaraciones SQL y envía los SQL al motor OLAP para su ejecución.

Como toda experiencia relacionada con la IA, nos encontramos con algunas fricciones:

1. LLM no comprende jergas de datos, como "campos", "filas", "columnas" y "tablas". En cambio, pueden traducir perfectamente términos comerciales como "ingresos corporativos" y "DAU", que son básicamente de lo que tratan los campos/filas/columnas. Eso significa que puede funcionar bien sólo si los analistas usan exactamente la palabra correcta para referirse a la métrica que necesitan al escribir sus preguntas.

   
   

2. El LLM que estamos utilizando es lento en inferencia. Se necesitan más de 10 segundos para responder. Como cobra tarifas por token, la rentabilidad se convierte en un problema.

   
   

3. Aunque el LLM está capacitado en una gran colección de conjuntos de datos públicos, no está suficientemente informado sobre conocimientos especializados. En nuestro caso, el LLM no está muy familiarizado con las canciones independientes, por lo que incluso si las canciones están incluidas en nuestra base de datos, el LLM no podrá identificarlas correctamente.

   
   

4. A veces, nuestras preguntas de entrada requieren información legal, política, financiera y regulatoria adecuada y actualizada, que es difícil de incluir en un conjunto de datos de capacitación o una base de conocimientos. Necesitamos conectar el LLM a bases de información más amplias para poder realizar tareas más diversificadas.

   
   

Derribamos estos problemas uno por uno.

1. Una capa semántica

Para el problema número 1, introducimos una capa semántica entre el LLM y el motor OLAP. Esta capa traduce términos comerciales en los campos de datos correspondientes. Puede identificar condiciones de filtrado de datos a partir de diversas redacciones en lenguaje natural, relacionarlas con las métricas involucradas y luego generar declaraciones SQL.

Además de eso, la capa semántica puede optimizar la lógica de cálculo. Cuando los analistas ingresan una pregunta que involucra una consulta complicada, digamos, una unión de varias tablas, la capa semántica puede dividirla en múltiples consultas de una sola tabla para reducir la distorsión semántica.

2. Reglas de análisis de LLM

Para aumentar la rentabilidad en el uso de LLM, evaluamos la complejidad de cálculo de todos los escenarios, como el cálculo de métricas, la recuperación detallada de registros y la segmentación de usuarios. Luego, creamos reglas y dedicamos el paso de análisis del LLM solo a tareas complicadas. Eso significa que para las tareas de cálculo simples, se omitirá el análisis.

Por ejemplo, cuando un analista ingresa "dígame las ganancias de las principales plataformas musicales", el LLM identifica que esta pregunta solo implica varias métricas o dimensiones, por lo que no la analizará más, sino que la enviará directamente para la generación y ejecución de SQL. Esto puede acortar en gran medida el tiempo de respuesta a las consultas y reducir los gastos de API.

3. Schema Mapper y base de conocimientos externa

Para dotar al LLM de conocimientos especializados, agregamos un Schema Mapper ascendente al LLM. Schema Mapper asigna la pregunta de entrada a una base de conocimiento externa y luego el LLM realizará el análisis.

Estamos constantemente probando y optimizando Schema Mapper. Categorizamos y calificamos el contenido en la base de conocimientos externa y realizamos varios niveles de mapeo (mapeo de texto completo y mapeo difuso) para permitir un mejor análisis semántico.

4. Complementos

Usamos complementos para conectar el LLM a más campos de información y tenemos diferentes métodos de integración para diferentes tipos de complementos:

• Incrustar archivos locales : esto es especialmente útil cuando necesitamos "enseñar" al LLM las últimas políticas regulatorias, que a menudo son archivos de texto. En primer lugar, el sistema vectoriza el archivo de texto local, ejecuta búsquedas semánticas para encontrar términos coincidentes o similares en el archivo local, extrae los contenidos relevantes y los coloca en la ventana de análisis de LLM para generar resultados.

  
  

• Complementos de terceros : el mercado está lleno de complementos de terceros diseñados para todo tipo de sectores. Con ellos, el LLM puede abordar temas muy diversos. Cada complemento tiene sus propios mensajes y función de llamada. Una vez que la pregunta de entrada llegue a un mensaje, se llamará al complemento correspondiente.

Una vez que hayamos terminado con las cuatro optimizaciones anteriores, surge el marco SuperSonic.

El marco SuperSonic

Ahora déjame guiarte a través de este marco :

• Un analista introduce una pregunta.

  
  

• Schema Mapper asigna la pregunta a una base de conocimiento externa.

  
  

• Si hay campos coincidentes en la base de conocimientos externa, el LLM no analizará la pregunta. En cambio, una fórmula de cálculo métrico hará que el motor OLAP comience a realizar consultas. Si no hay ningún campo coincidente, la pregunta ingresará al LLM.

  
  

• Según las reglas predefinidas, el LLM califica el nivel de complejidad de la pregunta. Si es una consulta sencilla irá directamente al motor OLAP; si se trata de una consulta complicada, se analizará semánticamente y se convertirá en una declaración DSL.

  
  

• En la capa semántica, la declaración DSL se dividirá según su escenario de consulta. Por ejemplo, si se trata de una consulta de unión de varias tablas, esta capa generará varias declaraciones SQL de consulta de una sola tabla.

• Si la pregunta involucra conocimiento externo, el LLM llamará a un complemento de terceros.

Ejemplo:

Para responder si una determinada canción se puede interpretar en programas de variedades, el sistema recupera el almacén de datos OLAP para obtener detalles sobre la canción y lo presenta con los resultados del complemento de terceros Commercial Use Query.

Arquitectura OLAP

En cuanto a la parte OLAP de este marco, después de varias rondas de evolución arquitectónica, así es como se ve nuestra canalización OLAP actual.

Los datos sin procesar se clasifican en etiquetas y métricas, que los analistas definen de forma personalizada. Las etiquetas y métricas están bajo una gestión unificada para evitar definiciones inconsistentes. Luego, se combinan en varios conjuntos de etiquetas y conjuntos de métricas para diversas consultas.

Hemos extraído dos conclusiones principales de nuestra experiencia en optimización arquitectónica.

1. Agiliza los enlaces

Antes de adoptar Apache Doris, teníamos ClickHouse para acelerar el cálculo de etiquetas y métricas, y Elasticsearch para procesar datos dimensionales. Son dos motores analíticos y requieren que adaptemos las declaraciones de consulta a ambos. Requería mucho mantenimiento.

Por lo tanto, reemplazamos ClickHouse con Apache Doris y utilizamos la funcionalidad del catálogo de Elasticsearch para conectar los datos de Elasticsearch a Doris. De esta manera, hacemos de Doris nuestra puerta de enlace de consultas unificada.

2. Dividir las mesas planas

En las primeras versiones de nuestra arquitectura OLAP, solíamos colocar datos en tablas planas, lo que complicaba las cosas. Por un lado, las mesas planas absorbieron toda la latencia de escritura del flujo ascendente, y eso sumó una pérdida considerable en la puntualidad de los datos. Por otro lado, el 50 % de los datos de una tabla plana eran datos dimensionales, que rara vez se actualizaban. Con cada nueva mesa plana llegaban algunos datos dimensionales voluminosos que consumían mucho espacio de almacenamiento.

Por lo tanto, dividimos las tablas planas en tablas métricas y tablas de dimensiones. A medida que se actualizan a diferentes ritmos, los colocamos en diferentes modelos de datos.

• Tablas de métricas : organizamos los datos métricos en el modelo de clave agregada de Apache Doris, lo que significa que los datos nuevos se fusionarán con los datos antiguos mediante SUM, MAX, MIN, etc.

  
  

• Tablas de dimensiones : estas tablas están en el modelo de clave única de Apache Doris, lo que significa que el nuevo registro de datos reemplazará al anterior. Esto puede aumentar enormemente el rendimiento en nuestros escenarios de consulta.

  
  

Quizás se pregunte: ¿esto causa problemas en las consultas, ya que la mayoría de las consultas requieren datos de ambos tipos de tablas? No se preocupe, lo solucionamos con la función Rollup de Doris. Sobre la base de las tablas base, podemos seleccionar las dimensiones que necesitamos para crear vistas acumulativas, que ejecutarán automáticamente GROUP BY . Esto nos libera de la necesidad de definir etiquetas para cada vista acumulativa y acelera en gran medida las consultas.

Otros trucos

En nuestra experiencia con Apache Doris, también encontramos algunas otras funcionalidades útiles, así que también las enumero aquí:

1. Vista materializada

Una vista materializada es un conjunto de datos precalculado. Es una forma de acelerar las consultas cuando con frecuencia necesitas acceder a datos de determinadas dimensiones. En estos escenarios, definimos etiquetas y métricas derivadas basadas en las originales. Por ejemplo, creamos una métrica derivada combinando la Métrica 1, la Métrica 2 y la Métrica 3: sum(m1+m2+m3) . Luego, podemos crear una Vista Materializada para ello. De acuerdo con el cronograma de lanzamiento de Doris, la versión 2.1 admitirá vistas materializadas de múltiples tablas, y lo esperamos con ansias.

2. Conector Flink-Doris

Esto es para garantizar Exactamente una vez en la ingesta de datos. Flink-Doris-Connector implementa un mecanismo de punto de control y confirmación de dos etapas, y permite la sincronización automática de datos desde bases de datos relacionales a Doris.

3. Compactación

Cuando la cantidad de tareas de agregación o el volumen de datos se vuelven abrumadores para Flink, puede haber una enorme latencia en la compactación de datos. Eso lo solucionamos con Compactación Vertical y Compactación por Segmentos. La compactación vertical admite la carga de solo una parte de las columnas, por lo que puede reducir el consumo de almacenamiento al compactar mesas planas. La compactación de segmentos puede evitar generar demasiados segmentos durante la escritura de datos y permite la compactación mientras se escribe simultáneamente.

Que sigue

Con el objetivo de reducir costos y aumentar la disponibilidad del servicio, planeamos probar la recientemente lanzada separación de computación y almacenamiento y replicación entre clústeres de Doris, y aceptamos cualquier idea y aporte sobre el marco SuperSonic y el proyecto Apache Doris.