Experimento de muestra HA3 SQL: una nueva solución de muestra para consultas de computación híbrida

Autor: Lu Weiyi (Wushuang)

HA3 (nombre en código fuente abierto externo: Havenask) es un sistema de recuperación distribuido a gran escala desarrollado por el equipo de motor inteligente de Alibaba. Se utiliza ampliamente en el negocio de búsqueda interna de Alibaba. Es el producto de competitividad central que Alibaba ha acumulado en el sector electrónico. campo del comercio por más de diez años. Ha3 SQL es una nueva función de consulta SQL basada en el motor Ha3 original. El motor tiene una sintaxis de consulta incorporada en forma de SQL, lo que permite a los usuarios construir consultas del motor escribiendo declaraciones SQL.

I. Descripción general

En el escenario empresarial de búsqueda y promoción, la construcción de muestras es una parte importante del enlace de datos de características y, desde la perspectiva del flujo de trabajo, crear muestras suele ser el primer paso para que los estudiantes de algoritmos comiencen un nuevo experimento. En términos de selección de tecnología en este enlace, considerando la funcionalidad, la estabilidad y la ubicación de los datos ascendentes, la mayoría de los equipos finalmente eligen MaxCompute. MaxCompute es una plataforma de procesamiento de datos fuera de línea de primera clase, pero al comunicarnos con los estudiantes de algoritmos, con frecuencia escuchamos estos problemas de uso:

• El almacenamiento de muestras ocupa demasiado espacio de MaxCompute;

• La tarea de construcción de muestra consume muchos recursos informáticos y el clúster está agotado por las tareas de muestra durante todo el año;

• El ciclo de construcción de muestras para experimentos como agregar características y ajustar la distribución de la muestra es muy largo y el costo de tiempo es alto.

Analizamos las razones esenciales detrás de estos problemas y proporcionamos un nuevo conjunto de soluciones de muestra para los puntos clave aquí: Función de experimento de muestra HA3 SQL.

Al insertar una capa de consulta proporcionada por HA3 SQL en el proceso de "construcción de entrenamiento de muestras", los principales problemas enumerados anteriormente se resuelven con mucha precisión. En la actualidad, varios equipos de algoritmos tienen acceso a este conjunto de soluciones de muestra y obtuvieron de él una optimización integral de los enlaces de datos.

En este artículo, analizaremos y reflexionaremos sobre el problema de la construcción de muestra, presentaremos la arquitectura del esquema del experimento de muestra HA3 SQL y algunos detalles técnicos que vale la pena compartir con usted, y también brindaremos algunos informes de rendimiento y comparación de costos antes y después del acceso. Finalmente, algunas lecciones aprendidas y perspectivas de trabajo futuro en el proceso de desarrollo de esta función.

2. Introducción y análisis de problemas de escenarios de muestra

2.1 Estado actual de las muestras

Primero, permítanme presentarles brevemente cómo se ven normalmente las muestras y cómo se construyen en el escenario de promoción de búsqueda. Tomando como ejemplo la muestra de CTR más común (muestra de exposición-clic), haciendo referencia al ejemplo del documento WDL de Google, un registro de muestra típico se ve así:

id_pv	id_aplicación	id_usuario	hacer clic	título_aplicación	aplicación_cate	app_download_count	edad_usuario	sexo_usuario
xxx_xx	1234	4321	1	gorjeo	social	3000	20	0

pv_id es el uuid correspondiente a una determinada solicitud. El significado de este ejemplo es: el usuario hace clic en la aplicación devuelta por una determinada solicitud en el teléfono móvil. En el momento del clic, el nombre de la aplicación, el volumen de descarga y otros atributos son ciertos, la edad, el sexo y otros atributos del usuario son fulanos. Una muestra consta de cientos de millones de dichos registros, y el modelo de aprendizaje automático consumirá estos datos durante el entrenamiento para conocer la correlación entre el comportamiento de hacer clic y varias funciones.

El método de construcción común de este tipo de muestra es el siguiente: pv_id app_id user_id click Estos atributos provienen del registro de puntos enterrados del comportamiento del usuario, que registra algunas identificaciones clave cuando ocurre el comportamiento del usuario. El algoritmo que los estudiantes establecerán una serie de flujos ascendentes y descendentes Tareas para recopilar esta parte de los datos. Importarla a MaxCompute para convertirla en una tabla de particiones que represente el comportamiento del usuario y preparar varias tablas de atributos con campos como pv_id/app_id/user_id como clave principal, que generalmente se denominan tablas de dimensiones. La tabla se basa en el comportamiento del usuario. Para empezar, utilice los identificadores anteriores para unir estas tablas de atributos y, finalmente, realice algún procesamiento de formato de acuerdo con los requisitos de la plataforma de capacitación para generar la tabla de muestra final.

Expresados ​​en pseudocódigo SQL, los pasos clave son básicamente una pieza de lógica:

select pv_id, app_id, user_id, timestamp, click, download
from clean_behaviour_table
left outer join app_profile_table
on clean_behaviour_table.app_id = app_profile_table.app_id
left outer join user_profile_table
on clean_behaviour_table.user_id = user_profile_table.user_id

En la actualidad, el soporte de la mayoría de las plataformas de capacitación para muestras de MaxCompute se limita básicamente al recorrido y la lectura de una única tabla de MaxCompute, por lo que los estudiantes de algoritmos deben ejecutar el sql anterior en MaxCompute y escribir los resultados en otra tabla de resultados como muestra final.

Al mismo tiempo, las iteraciones experimentales del algoritmo de los estudiantes en términos de muestras se llevan a cabo principalmente en dos dimensiones: rangos y columnas:

1. Los experimentos iterativos a nivel de fila significan que se realizan cambios experimentales en el flujo de comportamiento que une las muestras, como cambiar la proporción de muestreo de ejemplos negativos y seleccionar muestras de diferentes escenarios;

2. El experimento iterativo a nivel de columna consiste principalmente en agregar varias características de diferentes dimensiones, como agregar una tabla de atributos de la aplicación o agregar algunos campos a la tabla original.

Y debido a las limitaciones de la plataforma de capacitación mencionada anteriormente, el algoritmo básicamente necesita agregar una tarea MaxCompute similar al pseudocódigo anterior para cada experimento y generar una tabla de muestra además.

Si este conjunto de procesos de producción corresponde al concepto de la industria pública, es principalmente el proceso de procesamiento de datos por lotes fuera de línea en el sistema de tienda de características. MaxCompute generalmente corresponde a sistemas como Hive / Spark, y aquellos que estén interesados ​​pueden consultarlo por sí mismos.

2.2 Análisis de las principales contradicciones

Del status quo descrito anteriormente, se pueden extraer dos atributos clave de tareas como las muestras:

1. Desde la perspectiva de la lógica de construcción, la tabla de muestra es un modelo en estrella muy típico. La tabla de flujo de comportamiento es la tabla de hechos y las otras tablas son tablas de dimensiones. Al mismo tiempo, debido a las limitaciones de la plataforma de capacitación, la muestra Se requiere completar la materialización de este modelo estelar.

2. Específicamente para la lógica de construcción del experimento de muestra, en realidad es el aumento o disminución de la tabla de hechos y la tabla de dimensiones.En comparación con la construcción completa de SQL, el cambio de cada experimento generalmente se limita a una o dos tablas.

A su vez, en el escenario del campo del comercio electrónico de Ali, la plena expansión del modelo estrella ha traído tres aspectos de impacto:

1. Una sola tarea de muestra es compleja y consume muchos recursos. Porque en muchos escenarios del grupo, el número de muestras en un día es cientos de millones o incluso miles de millones, y las dimensiones de cada tabla de dimensiones no son pequeñas. La tabla de productos es originalmente una dimensión de mil millones de niveles. una clase puede llegar a cientos de miles de millones. Una tarea de muestra generalmente une al menos siete u ocho tablas de este tipo. Para una plataforma informática fuera de línea como MaxCompute, el método más básico para este nivel de tarea es realizar ronda tras ronda de clasificación y combinación de combinaciones. Consume muchos recursos y, para escenarios con cierta escala, la implementación predeterminada ni siquiera puede ejecutarse en absoluto, y es necesario utilizar métodos como hash clutser y mapjoin distribuido para la optimización. Incluso introduce otra capa de servicios externos de tipo kv además de MaxCompute para acelerar esta unión. En los últimos años, la plataforma de algoritmo interno ha trabajado con principios similares.

2. Redundancia de almacenamiento: para algunas tablas de dimensiones, debido a que están unidas por la tabla grande de la tabla de comportamiento, una fila en la tabla de dimensiones puede repetirse cientos de miles de veces en la tabla de muestra final. Puede imaginar que productos populares como iPhones estar en Cuántas muestras de productos objetivo y secuencias de comportamiento existen, y cuántas funciones del lado del producto iPhone se almacenan de forma completamente redundante. Según las estadísticas, en la muestra de búsqueda principal, los atributos del producto de varias secuencias de comportamiento representaron 2/3 del espacio de datos. El resultado final de la implementación de materialización completa es que cualquier muestra con un ttl de 30 días en la escena principal puede ocupar directamente varios petabytes de espacio de almacenamiento MaxCompute.

3. Agregar y modificar datos requiere actualizar toda la tabla: debido a que MaxCompute en sí no tiene la función de modificar algunas columnas de la tabla de particiones existente, si necesita corregir datos o agregar algunas funciones, la única opción es ejecutarlo nuevamente. proceso, otros campos irrelevantes también se leerán y escribirán nuevamente en su totalidad. Y los requisitos experimentales del algoritmo significan que la enorme cantidad de cálculo y consumo de almacenamiento descritos anteriormente aumentará directamente en un orden de magnitud. ¿Cuántos experimentos desea hacer? ¿Cuántas tareas de muestra deben ejecutarse por completo, aunque estas tareas? Puede ser que solo haya una diferencia entre una unión más y una unión menos entre los dos. Después de comprender estos dos puntos, podrá comprender completamente por qué la tarea de muestra puede denominarse el asesino de recursos de MaxCompute.

2.3 Soluciones

Extraído de la escena, si usamos el concepto de dominio de base de datos para describir el problema de la muestra, entonces la esencia del problema de la muestra MaxCompute se puede resumir como: múltiples vistas de modelo complejas pero muy similares en forma de estrella se ven obligadas a materializar y ampliar las cuestiones de recursos informáticos y de almacenamiento.

Después de resumir este problema, nuestra idea de solución es muy clara: agregar una capa de consulta entre la capa de procesamiento de datos y la capa de entrenamiento, y retrasar parte de la lógica de cálculo a la capa de consulta durante el entrenamiento, de modo que las muestras experimentales puedan repetirse lógicamente. parte se convierte en una consulta repetida en la fase de consulta, y la capa informática solo procesa parte de la lógica adecuada para ser procesada por la plataforma informática y datos incrementales reales, que pueden acercarse al óptimo en términos de recursos y eficiencia.

Puede pensar en dos escenarios típicos de experimentos de fila y columna: ajustar la proporción de muestreo de muestras negativas y agregar tablas de características.

Ajustar muestras negativas se refiere a muestrear los ejemplos negativos en la muestra, porque puede haber demasiados ejemplos negativos en algunas escenas, lo que no es útil para entrenar el modelo. En el modelo anterior, este tipo de experimento solo se puede llevar a cabo generando múltiples tablas de hechos y luego construyendo múltiples tablas de muestra.

Si el sistema tiene la capacidad de consultar SQL, solo podemos mantener una tabla de hechos con ejemplos negativos completos, filtrar algunos ejemplos negativos directamente consultando declaraciones condicionales en SQL y luego unir varias tablas de dimensiones con los registros filtrados, de modo que Hacer experimentos con diferentes proporciones es solo una cuestión de ajustar un parámetro SQL. No es necesario generar muestras repetidamente y puede iniciar directamente múltiples tareas de capacitación con diferentes configuraciones.

La tabla de características recién agregada también debe generar una nueva tabla de muestra en el modo tradicional, lo que significa reescribir todos los datos de la tabla de muestra, y en el sistema con capacidad de consulta SQL, es el mismo que el método de procesamiento del modelo estrella en En la base de datos tradicional, solo necesitamos preparar los datos de esta nueva tabla de características, y podemos unirlos directamente al realizar la consulta, sin cambiar en absoluto la tabla de hechos y la tabla de dimensiones anteriores.



A todo este sistema lo llamamos Sistema de consulta de computación híbrida (Sistema de consulta de computación híbrida), que es diferente del sistema anterior que generaba muestras completamente a través de la capa informática.

3. Arquitectura del sistema

3.1 Selección de tecnología de capa de consulta

Después de determinar la idea, debemos seleccionar la tecnología. Desde la perspectiva del escenario de muestra, ¿qué tipo de capa de consulta necesitamos? Resumimos los puntos principales de la siguiente manera:

Admite SQL con todas las funciones: como se mencionó anteriormente, el proceso de construcción completo de la muestra en sí es adecuado para ser descrito mediante uno o más párrafos de lógica basada en SQL. La construcción de muestra por lotes MaxCompute tradicional en sí utiliza MaxCompute SQL específico para describir la construcción de muestra. logic., la capa de consulta también admite SQL con todas las funciones, lo que nos ayudará a transferir de manera flexible los cálculos adecuados a la capa de consulta y también hará que este proceso o lógica interna sea más fácil de entender para los usuarios (estudiantes de algoritmos).

Capacidad de indexación sólida: si desea transferir la unión a la etapa de consulta, la tabla de dimensiones debe indexarse ​​con anticipación y la capa de consulta debe tener capacidades de indexación sólidas y estables, y un proceso de construcción rápido y maduro.

Soporte para rendimiento ultra alto de lectura y escritura, retraso de milisegundos: durante el proceso de capacitación y lectura, la muestra escaneará la tabla de hechos completa y luego unirá tablas de múltiples dimensiones. Y a diferencia de las tareas de tipo olap seguidas de funciones de agregación, el entrenamiento requiere todos los datos de una fila completa y el rendimiento general en escenarios a gran escala puede incluso alcanzar el orden de decenas de GB/s. Al mismo tiempo, la cola de datos del final del entrenamiento en sí suele ser relativamente pequeña y, para no bloquear el entrenamiento, la latencia de una sola consulta también debe mantenerse en el nivel de milisegundos.

Separación de computación y almacenamiento nativos: no importa qué tablas físicas y la lógica combinada correspondiente se desmonten finalmente en el proceso de construcción lógica de la muestra, es imposible almacenar varias muestras y cada muestra durante varios días en la memoria del grupo de consultas o en el disco local Sí, requiere objetivamente que el sistema de consulta admita de forma nativa la separación de informática y almacenamiento. Al mismo tiempo, el requisito implícito es que la capa de consulta debe tener un mecanismo de caché rico y flexible para reducir la presión sobre la capa de almacenamiento y cumplir con los requisitos de rendimiento del final de la capacitación.

Soporte de datos en tiempo real:

• Por un lado, los problemas encontrados en el experimento de muestra de muestras odl (aprendizaje profundo en línea) son esencialmente los mismos que los de las muestras por lotes, pero las muestras odl no se almacenarán durante mucho tiempo y el problema de almacenamiento no se solucionará. Genial En segundo lugar, durante mucho tiempo, la dificultad de construir muestras Odl es obviamente mayor y muchos escenarios no pueden mantener muestras experimentales. Y si la propia capa de consulta admite fuentes de datos en tiempo real como fuente de tabla, de hecho, las muestras Odl también se pueden utilizar para varios experimentos de filas y columnas.

• Por otro lado, las tablas de dimensiones de características en realidad tienen fuertes requisitos en tiempo real. Muchas características están relacionadas con el momento en que ocurren los eventos. Anteriormente, este tipo de tabla de dimensiones no se podía crear en MaxCompute, por lo que se han utilizado simulaciones aproximadas o puntos enterrados. Esta parte de las características se puede generar de alguna manera, y si la capa de consulta en sí admite el almacenamiento y la lectura de datos de manera similar a las bases de datos de series de tiempo, esta parte de las características se puede generar sin conexión.

Después de analizar los requisitos de la capa de consulta y varias encuestas reales, finalmente decidimos utilizar ha3 sql como la capa de consulta de nuestro plan de experimento de muestra.

Los componentes subyacentes de ha3 sql se desarrollan a partir del motor ha3 (havenask, código abierto) que admite la búsqueda grupal. Su componente central indexlib puede respaldar las últimas cuatro preocupaciones enumeradas anteriormente y ha sido probado durante mucho tiempo. Sin embargo, ha3 sql reemplaza la expresión de consulta tradicional con un dialecto ha3 sql personalizado. La dificultad principal de la tarea en el escenario de muestra radica en la escala y la naturaleza de la unión continua de varias tablas. La expresión sql requerida para construir la lógica en sí no es complicado Actualmente, ha3 sql es totalmente capaz.

Al mismo tiempo, ha3 sql también es un proyecto dentro del sistema AIOS y tenemos control total sobre él, ya sea para solucionar problemas o ampliar funciones, podemos alcanzar el límite de la lógica o la voluntad.

3.2 Formulario de función del producto

La selección del tiempo de ejecución de la capa de consulta aún no está terminada. Todavía tenemos que responder una serie de preguntas sobre cómo convertir esta idea en una función de producto utilizable:

• ¿Cómo describir la lógica de construcción de la muestra? ¿Dónde describe el usuario esta lógica?

• ¿Cuándo y cómo importar la tabla MaxCompute de la que depende la compilación de muestra al sistema ha3?

• ¿Cómo interactúa la plataforma de capacitación con esta nueva capa de consulta?

Nuestra idea general para esta pieza es: usar un conjunto de DSL que sea similar al ejemplo anterior para construir un pseudocódigo que permita a los usuarios describir la lógica de muestra. A través de este DSL, podemos obtener la información de la tabla MaxCompute dependiente, por lo que en cuanto a crear tareas ETL periódicas para importar ha3, y también podemos generar el sql ha3 requerido para las muestras de consultas de entrenamiento finales de acuerdo con el DSL.

Para la parte DSL, nuestra selección de tecnología final es RTP Table Api (un conjunto de SDK de Python utilizado anteriormente para crear funciones en línea, el diseño de la interfaz se refiere principalmente a Table Api de Flink, y el nombre de Table Api se usará a continuación), ejemplos específicos y los detalles técnicos se detallarán en el siguiente capítulo. Desde la perspectiva del proceso funcional, la arquitectura del proceso de todo el sistema es la siguiente:



4. Detalles técnicos y trabajo de optimización.

4.1 módulo ADSL

Con respecto al diseño del DSL en sí, optamos por hacer algunas extensiones de Table Api como muestra para construir el DSL. La lógica de construcción de muestra descrita es aproximadamente la siguiente:

from turing_script.sdk.itable import ITable as Table
from turing_script.biz_plugin.default_modules.base_sample_module import BaseSampleModule

class SampleDemo(BaseSampleModule):
    def build(self, table_env) -> Table:
        ##获取基础样本表
        base_sample = table_env.get_table('odps_project.base_sample')

        #需要join的维表，指明pk_name和需要的字段
        video_rtp_feature = table_env.get_table("odps_project.video_rtp_feature", pk_name = "video_id") \
        .select("video_id, gmv_score, video_pageview")
        #需要join的维表可支持多张
        author_feature = table_env.get_table("odps_project.mainse_vs_author_feature", pk_name = "author_id")

        #三张表按条件join，字段类型需一致，如字段名相同，可用_right_前缀来区分
        sample_exp = base_sample.left_outer_join(video_rtp_feature, 'int64(video_id)=_right_video_id') \
        .left_outer_join(author_feature, 'video_authorid=author_id') \
        .filter("reserverd_rand_key > 0.5")
        return sample_exp

Se puede ver que el código de muestra anterior en sí también es un proceso que se puede asignar aproximadamente a SQL. De hecho, Table Api y ha3 SQL están relacionados con la misma raíz y muchos componentes se reutilizan en la capa inferior, como iquan. y calcita. La razón para elegir la transformación basada en la Tabla Api como DSL del experimento de muestra en sí se debe principalmente a las siguientes consideraciones:

1. La creación de muestras y la creación de entradas durante el servicio RTP en línea son en realidad dos caras de la misma función. A largo plazo, nuestro objetivo es unificar las expresiones de creación de funciones en línea y fuera de línea, por lo que tendemos a utilizar el mismo DSL que la etapa de servicio RTP para construir. .

2. Debido a que implica lógica como la programación y la importación, el DSL del experimento de muestra es en realidad una fusión de parte de la lógica de DDL y DML. Si usa ha3 sql para describir la necesidad de expandir parte de la sintaxis de SQL, la carga de trabajo Aumente significativamente, y algo de lógica y El mapeo del álgebra relacional no es directo, lo que afectará nuestra eficiencia de desarrollo en la etapa de exploración y también puede agregar alguna carga innecesaria a ha3 sql. En términos relativos, la interfaz estilo SDK es más fácil de expandir funciones distintas de SQL y hacer que las interfaces sean compatibles, lo que es más obvio en la naturaleza de la interfaz get_table presentada anteriormente.

Volviendo al DSL en sí, la interfaz principal se compone principalmente de dos partes:

• get_table es un reemplazo de las dos interfaces de scanregister_table en la Table Api original. Es diferente de la consulta en línea pura. En el escenario de muestra, debemos permitir que los usuarios proporcionen cierta información DDL, como índices y configuraciones. Elegimos pasar pk_name en esta interfaz Parámetros de clase para especificar;

• Las interfaces semánticas SQL de uso común, como la combinación de filtro selecto, el significado y la sintaxis de esta parte de la interfaz son completamente consistentes con la Table Api original y básicamente pueden cubrir las acciones SQL requeridas para crear muestras.

Debajo de la interfaz, implementamos las siguientes funciones:

• El análisis y derivación de la tabla dependiente genera la configuración de la tabla de índice ha3 correspondiente;

• Elimine automáticamente los campos redundantes y solicite los campos faltantes. Gracias al intercambio de componentes básicos como iquan y calcita, estas capacidades se disfrutan básicamente directamente desde la capa inferior;

• El sql ha3 utilizado para la consulta se genera automáticamente.

4.2 Diseño de tabla de índice

Otro lugar que debe diseñarse cuidadosamente es la configuración de la tabla de índice del sistema de consulta correspondiente a cada tabla MaxCompute. El sistema de índice subyacente indexlib de ha3 proporciona muchos tipos de índice y muchas configuraciones de parámetros detalladas; incluso se puede decir que es un Es demasiado detallado, por lo que los conceptos de esta capa no deben exponerse directamente a los usuarios. Necesitamos encontrar una configuración de tabla de índice adecuada de acuerdo con los requisitos del escenario de muestra y vincularla con algunos conceptos de la capa DSL que los usuarios puedan entender.

✪ 4.2.1 Tabla de hechos

Generalmente hay dos ejemplos típicos de tablas de hechos en escenarios de muestra: una es una tabla de flujo de comportamiento puro, que solo tiene algunos identificadores de clave externa y etiquetas de comportamiento, y tiene menos campos; la otra son otras muestras construidas. Las expectativas del usuario se basan en esto. La muestra básica también agrega algunas características para experimentar. Además de todos los campos del tipo anterior, este tipo de tabla también contiene una gran cantidad de características generadas. Hay muchos campos y la escala de la tabla es relativamente grande.

Al mismo tiempo, la forma en que se utiliza la tabla de hechos en el escenario de muestra es atravesar toda la tabla. En diferentes experimentos, es posible que solo se requiera una parte de los campos y no se unirán a otras tablas. Esta característica, combinada con el gran tamaño de datos del ejemplo anterior como tabla de hechos, determina que la tabla de hechos es adecuada para el almacenamiento en forma de tabla almacenada en columnas. Por un lado, puede reducir una gran cantidad de búsquedas leyendo por columna y, por otro lado, el formato de almacenamiento de columnas favorece la compresión, lo que puede reducir el tamaño de almacenamiento de la tabla de hechos de muestra. Entonces, al final elegimos configurar la tabla de hechos como una tabla en formato AliOrc, que también es compatible con indexlib.

✪ 4.2.2 Tabla de dimensiones

Los requisitos para la tabla de dimensiones son relativamente claros: la tabla de dimensiones en el escenario de muestra debe tener un índice, es decir, la clave principal, de lo contrario, el mismo registro unirá varios resultados. Las tablas de dimensiones tienen funciones unidas y requieren índices para proporcionar capacidades de recuperación rápida, por lo que son adecuadas para el almacenamiento en tablas de almacenamiento de filas con índices. Y porque en el escenario de muestra, las tablas de dimensiones son básicamente claves primarias de un solo campo o de dos campos. Entonces, elegimos la tabla de índice kv y kkv de indexlib como formato de almacenamiento de la tabla de dimensiones. Se proporcionan respectivamente las funciones de deduplicación y recuperación mediante clave primaria única y clave primaria doble.

4.3 Sistema de programación

El proceso diario de importación de muestras implica acciones en múltiples etapas: primero, después de que se genera la tabla fuente correspondiente en MaxCompute, se debe iniciar una tarea para realizar el trabajo ETL y luego esperar a que se completen los procesos posteriores, como la construcción de la tabla ha3 y el clúster. cambiando., y solo después de que se hayan importado todas las tablas de las que depende una muestra, podemos escribir el sql ha3 de la consulta completa en el metasistema. Cuando hay muchas tablas, este proceso de dependencia sigue siendo relativamente complicado y se necesita un sistema de programación para ayudar a completarlo.

Dado que la programación de tareas de MaxCompute en sí se basa en el sistema DataWorks, y los estudiantes de algoritmos están familiarizados con el flujo de trabajo y las operaciones de DataWorks, como la complementación de datos, decidimos implementar esta parte de la programación basada en DataWorks.

Dividimos tres tareas de programación detalladas: hundirse, esperar y confirmar .

El nodo receptor se basa en la programación del nodo de salida de la tabla fuente de MaxCompute para iniciar la tarea de exportación de datos, el nodo de espera se basa en la programación del nodo receptor y espera a que se complete la compilación y la conmutación. La razón por la cual el sumidero y la espera se dividen en dos nodos es que el nodo de espera En otros casos, puede volver a ejecutarlo por separado para evitar la importación repetida de datos; la confirmación se basa en los nodos de espera de todas las tablas en la tarea de muestra, y después de cambiar todas las tablas, vuelva a ejecutar la lógica DSL y reemplace el nombre de la tabla con la partición de salida específica del día El nombre de la tabla, la consulta de salida completa se escribe en el metasistema con sql.

Nos conectamos al sistema OpenApi de DataWorks y registramos directamente los nodos anteriores en los proyectos de cada equipo a través de la interfaz. Los usuarios solo necesitan usar el DSL anterior para describir el proceso de construcción de muestra, y estos nodos se crearán automáticamente.

Un ejemplo más complejo de programación de muestra es el siguiente:



4.4 Implementación y gestión de clústeres

Externamente, lo que exponemos a los usuarios es el concepto de base de datos similar a una base de datos. Todas las tablas en la misma base de datos son visibles. Si varias muestras dependen de la misma tabla, estas tablas no se crearán ni importarán repetidamente, sino que se compartirán. Esto también reserva espacio para el posible intercambio posterior de características, etiquetas y otros comportamientos entre equipos.

En la actualidad, hemos construido grupos públicos de salas de computadoras en diferentes regiones del país y decidimos qué grupo público usar de acuerdo con la sala de computadoras a la que pertenece el proyecto del equipo de algoritmos. En el enlace de importación, se garantiza que el clúster MaxCompute, el clúster Transit Swift (similar a Kafka), el clúster de compilación y el clúster Pangu estarán en la misma región para evitar el ancho de banda de transmisión de larga distancia interregional. , el grupo de capacitación está configurado de forma predeterminada y estará completamente en la misma sala de computadoras que el grupo DB y el grupo Pangu, lo que puede evitar por completo el ancho de banda entre salas de computadoras en la misma ciudad, lo que reduce los costos.

Esta parte es completamente transparente para los usuarios en su conjunto. Los usuarios solo necesitan seleccionar la base de datos apropiada de acuerdo con la ubicación de su sala de computadoras MaxCompute al principio.

Sin embargo, en nuestro trabajo actual de operación y mantenimiento de administración de clústeres, este modo también ha descubierto algunos problemas:

Aislamiento empresarial: debido a que el clúster se comparte, por un lado, existe el riesgo de influencia mutua entre los equipos empresariales. Por ejemplo, si un equipo importa demasiadas tablas un día, puede bloquear el cambio de mesa de otros equipos u ocupar recursos. . Por otro lado, esto ha causado muchos problemas en la facturación de nuestros servicios: es difícil saber cuántos recursos de un clúster utiliza cada empresa.

La escala de un solo clúster es demasiado grande: debido al uso mixto de los clústeres y la distribución desigual de las salas de computadoras MaxCompute en cada equipo, la escala de algunos clústeres en la tabla anterior ya es demasiado grande, lo que es un problema de que los recursos no pueden expandirse linealmente de acuerdo con las necesidades del negocio. El mayor problema es que nuestro sistema basado en ha3 y la plataforma de operación y mantenimiento generalmente se diseñaban antes en torno a clústeres en línea. No habrá cientos de tablas en un solo clúster como en el escenario de muestra, por lo que Se han encontrado con una serie de problemas durante el proceso de operación y mantenimiento. El tablero corto del barril de madera se ha encontrado con el problema de que el cambio se ralentiza seriamente o incluso el servicio no está disponible. Aunque se han utilizado varios medios para resolver el problema en el A corto plazo, el riesgo de una escala única de conglomerados es siempre la espada de Damocles.

Por lo tanto, nuestra próxima dirección de transformación en esta parte es desmantelar grupos pequeños y proporcionar un modelo de gestión de grupos basado en la granularidad de equipos y tareas, para evitar los problemas anteriores.

4.5 Atraque de la plataforma de entrenamiento

Al mismo tiempo, también hemos adaptado las muestras de SQL HA3 en la plataforma de capacitación del modelo. La consulta SQL de cada partición finalmente obtenida al final de la capacitación es aproximadamente la siguiente:

SELECT *
FROM (SELECT *
      FROM (SELECT *
      FROM mainse_video_ha3_sample_ds_20221123
      /*+ SCAN_ATTR(batchSize='1', partitionIds='0', localLimit='100')*/) AS t0
      WHERE pv = 1 AND content_type = 'video') AS t1
INNER JOIN (SELECT pv_id, item_id, label, cart
            FROM mainse_video_click_to_pay_backbone_v2_ds_20221123) AS t2 ON t1.pv_id = t2.pv_id AND t1.item_id = t2.item_id

Para una sesión de formación, muestras de diferentes particiones. Quizás nuestra declaración SQL sea diferente. Por ejemplo, a partir de un día determinado, un campo se transfiere de la tabla de dimensiones a la tabla de hechos, luego el SQL de esta partición cambiará, pero esto en realidad es transparente para el final del entrenamiento, y el final del entrenamiento solo necesita usar SQL. para consultar.Puede.

Para una muestra particionada, por un lado, considerando la presión de la memoria del servicio del motor, por otro lado, para barajar los datos, generalmente los dividimos en 256 columnas. Al realizar la consulta, especifique una determinada columna a través del parámetro de sugerencia SCAN_ATTR, y señalar un punto de partida y un límite, lo que equivale a dividir todos los datos en muchos fragmentos pequeños.

Específico para la implementación de la lectura de datos, lo realizamos mediante la concatenación de las siguientes operaciones:

GenStreamSqlOp: obtenga metainformación diaria de la API del centro de funciones de acuerdo con el nombre de la muestra y la lista de particiones, como el recuento de documentos, la plantilla de declaración SQL diaria, y luego divídala en muchas cadenas pequeñas. Cada cadena describe una información de fragmento, como part_id, fila_inicial, etc.;

WorkQueueOp: una cola global. Cuando todos los trabajadores están entrenando, toman los fragmentos de muestra para leer de esta cola única global, colocan los resultados de GenStreamSqlOp en la cola y guardan el punto de control cada vez. Registra alguna información de consumo de la cola en lograr una conmutación por error de entrenamiento normal;

SqlReadUpToOp: los fragmentos tomados de la cola se restauran a un sql completo de acuerdo con la información de la partición correspondiente, y luego los resultados se obtienen del ha3 remoto a través del cliente de transmisión en la operación. Dado que el entorno de capacitación fuera de línea es diferente del entorno de compilación en línea, encapsulamos los resultados en línea una vez y los devolvemos en forma de tensor para evitar problemas de compatibilidad y facilitar las actualizaciones posteriores del servicio back-end.

4.6 Optimización del rendimiento

✪ 4.6.1 ETL

La eficiencia de la importación de datos es un punto clave de nuestra atención, porque la idea básica de la función del experimento de muestra es reemplazar parte de la lógica de construcción de la muestra con consultas. Esta parte de la tarea MaxCompute se puede guardar y, en consecuencia, Se agregó recientemente el ETL de varias tablas de tareas, entonces la diferencia de velocidad entre las dos tareas es el primer detalle que los usuarios sienten al usar las funciones de la plataforma. Creemos que es necesario brindarles a los usuarios una comparación impresionante en este enlace.

Las tareas tradicionales de exportación de datos de MaxCompute se implementan básicamente a través de la función de túnel MaxCompute. Notamos dos problemas importantes durante el uso:

• La función de túnel requiere que MaxCompute transfiera el servicio de reenvío correspondiente y la cuota de control de flujo correspondiente. Al importar tablas relativamente grandes, la velocidad a menudo disminuye drásticamente debido al control de flujo;

• Falta de la función de exportar solo algunas columnas. En algunos casos, solo necesitamos exportar los datos de una pequeña cantidad de columnas en la tabla. El uso del túnel causará desperdicio.

Esto significa que en el proceso ETL, hay un cuello de botella en la lectura de datos del sistema de datos original desde el principio, por lo que no es necesario hablar de la velocidad de toda la tarea. Para resolver esta parte del problema, cambiamos la forma de pensar: utilizamos nuestro propio servicio Swift para realizar la transferencia de capas, escribimos los datos de la tabla de origen en una tarea MR rápida y la tarea de compilación posterior utiliza el tema Swift como punto de partida. fuente de datos. Una tarea de MR de este tipo es básicamente la lógica transversal más simple, consume muy poca CU y puede leer los campos obligatorios a pedido.

Después de resolver el problema a nivel de exportación, también hicimos una optimización especial para la muestra básica mencionada anteriormente como tabla de hechos. Este tipo de tabla se caracteriza por su gran escala, muchos campos y un índice simple. Al mismo tiempo, porque utilizar swift Como tránsito, la mezcla de datos se puede implementar con la ayuda de swift.Bajo esta premisa, el proceso de tres etapas de fusión-creador-procesador en la tarea de construcción de índice tradicional parece un poco derrochador, y el status quo de fuera de línea inestable Los recursos de la tarea y los inicios y paradas frecuentes también afectarán la velocidad de construcción de la mesa.

Por lo tanto, utilizamos el servicio de almacenamiento AIOS 2.0 con capacidad de lectura y escritura, y utilizamos un clúster de escritura orientado a servicios que utiliza recursos en línea para realizar la construcción de la tabla. Después de una serie de pruebas de ajuste de parámetros, puede completar de manera estable la importación de una tabla de muestra de 30T en una hora.

✪ 4.6.2  Ejecución de transmisión

Como se mencionó anteriormente en la sección de acoplamiento de la plataforma de capacitación, la consulta final ejecutada por el final del entrenamiento es un SQL dividido. Teniendo en cuenta la necesidad de agrupar los datos de entrenamiento, el tamaño de este segmento es generalmente de aproximadamente 1 w. Según la medición inicial, este tipo de consulta seguirá teniendo un rt grande incluso si el caché ya ha sido alcanzado, por lo que el final del entrenamiento debe iniciar varias consultas al mismo tiempo para que el rendimiento sea suficiente para satisfacer el consumo del modelo posterior. . Después de la investigación, se descubrió que la razón principal era que la capa de programación de ejecución de ha3 sql estaba relativamente cerca del modo de programación de tareas por lotes, por ejemplo, para el siguiente diagrama de ejecución:



Debido a que de hecho es un gráfico de dependencia en serie, el servidor solo puede ejecutarlo directamente sin ningún paralelismo, y el rt será muy impresionante. Para resolver este problema, los estudiantes de ha3 desarrollaron un nuevo motor de ejecución de transmisión. En el nuevo motor de ejecución, los núcleos ascendentes y descendentes estarán conectados por colas. Cada núcleo encuentra que hay un mini lote en su cola ascendente que es suficiente para su propio cálculo, que puede estimularse después de los datos, de modo que se paralelice un proceso en serie lógicamente puro.

✪ 4.6.3  Almacenamiento en caché

Como se mencionó en la selección de tecnología de la capa de consulta, debido al escenario de muestra, el tamaño total de la tabla definitivamente excederá el límite de memoria de un clúster, por lo que los datos completos solo se pueden colocar en un sistema DFS como el clúster Pangu, y se utiliza para HDD fuera de línea Pangu, las operaciones con múltiples acciones de búsqueda, como consultar índices, deben pasar por el mecanismo de caché para que la velocidad de consulta cumpla con las expectativas. En indexlib, existe un mecanismo de caché de bloques unificado en la capa IO, que nos ayuda a almacenar en caché tablas de hechos y tablas de dimensiones al mismo tiempo.

Además, en términos de uso, considerando algunas características comerciales comunes del escenario de muestra, realizamos algunos ajustes preestablecidos para el modo de distribución de datos para obtener una mejor tasa de aciertos de caché. Debido a que la tabla de hechos generalmente tiene claves primarias duales de pv_id y item_id, dividimos la tabla de hechos en 256 columnas de acuerdo con pv_id, para que la localidad de caché de la consulta de la tabla de hechos sea mejor. Al mismo tiempo, existe un tipo de super -tabla de dimensiones dimensionales que generalmente lleva pv_id Como una de las claves principales, también dividiremos este tipo de tabla en 256 columnas de acuerdo con pv_id, y luego el plan de ejecución se puede optimizar como una unión local en una sola columna. El estado óptimo de las tablas de dimensiones de otras dimensiones es dividirlas en columnas separadas según la naturaleza y escala de la clave principal e implementarlas por separado en una implementación.

Además, también notamos que el disco del clúster en línea es SSD y la velocidad de lectura del disco es 2-3 órdenes de magnitud más rápida que la del Pangu fuera de línea. Usar el disco como una capa de caché puede expandir enormemente el espacio de caché. Gracias nuevamente a la función de indexlib, podemos usar esta capa de funciones mediante una configuración simple. La configuración general actual del clúster es de 128G de almacenamiento en disco más 16G de memoria, basada en la eliminación de LRU.

5. Caso de costos del escenario

Comparta los métodos de uso específicos y los casos de comparación de costos antes y después de varios escenarios en los que se conectaron y reemplazaron muestras de MaxCompute.

5.1 Muestras generales de escenarios múltiples

Uno de los equipos de algoritmos a los que servimos administra los modelos de recomendación para múltiples escenarios. Las características utilizadas en cada escenario son las mismas. Nos hemos conectado a la función de punto completamente enterrado de nuestra plataforma de funciones antes, y todos los escenarios están enterrados uniformemente a través de un conjunto. de configuraciones de funciones. Después de eso, cada escena necesita usar las muestras de su propia escena para entrenar por separado durante el entrenamiento fuera de línea. Conceptualmente hablando, este método de uso es el experimento de nivel de fila mencionado anteriormente, pero antes el algoritmo solo podía seguir las muestras de puntos completamente enterrados que produjimos en MaxCompute, filtrar varias tablas de muestra de diferentes escenarios y entrenar la lectura por separado. Después de adoptar nuestra función de experimento de muestra, la estructura pasa a ser que solo necesita importar la muestra del punto completamente enterrado que contiene todas las escenas, y cada escena se filtra directamente de acuerdo con la ID de la escena durante el entrenamiento.



Después de acceder al equipo de algoritmos, se sometió a ajustes finos y AB estricto en línea. En comparación con el enlace anterior, el efecto fuera de línea es consistente y el modelo se puede cambiar a en línea dos horas antes todos los días. En todos los escenarios, el almacenamiento Pangu utilizado se reduce directamente del nivel de PB al nivel de TB (ambos tamaños de almacenamiento físico).

5.2 Recuperar muestras

El ejemplo de un escenario de retirada de negocios es un ejemplo muy típico de un ejemplo de construcción de modelo en estrella. Puede ver directamente el código de muestra:

from turing_script.sdk.itable import ITable as Table
from turing_script.biz_plugin.default_modules.base_sample_module import BaseSampleModule

class SampleDemo(BaseSampleModule):
    def build(self, table_env) -> Table:
        base_sample = table_env.get_table('odps_project.base_sample', shard_key="pvid", with_extra_rand_key = True)
        
        #需要join的维表，指明pk_name和需要的字段，可支持多张
        user_feature = table_env.get_table("odps_project.user_feature", pk_name = "id")
        content_pos_feature = table_env.get_table("odps_project.content_pos_feature", pk_name = "id")
        content_neg_feature = table_env.get_table("odps_project.content_neg_feature", pk_name = "id")

        # sequence feature
        sequence_feature = table_env.get_table("odps_project.sequence_feature", pk_name = "pvid")

        #三张表按条件join，字段类型需一致，如字段名相同，可用_right_前缀来区分
        sample_exp = base_sample.left_outer_join(user_feature, 'user_id=_right_id') \
                                .left_outer_join(content_pos_feature, 'content_id=_right_id') \
                                .left_outer_join(content_neg_feature, 'neg_content_id=_right_id') \
                                .left_outer_join(sequence_feature, 'pvid=_right_pvid') \
                                .select("is_clk as label, *") 
        return sample_exp

Este código es básicamente un reemplazo equivalente para la última tarea de generar una tabla de muestra en MaxCompute. Anteriormente, esta muestra se almacenaba en MaxCompute durante 8 días y podía ocupar almacenamiento de nivel PB. Después de migrar a la muestra HA3 SQL, solo el Los datos deben almacenarse por separado. Las tablas y tablas de dimensiones, las muestras almacenadas durante 14 días solo utilizaron decenas de TB de espacio de almacenamiento.

6. Lecciones aprendidas y perspectivas

La escena de muestra es un área a la que hemos estado prestando atención e invirtiendo durante mucho tiempo. Algunos intentos técnicos se remontan incluso a hace dos o tres años. Mirando hacia atrás en este viaje, hay muchos sentimientos en la tecnología y el producto. Diseño que vale la pena compartir contigo:

1. El control de la pila de tecnología de enlace completo afectará directamente el éxito o el fracaso de este complejo proyecto entre sistemas. De hecho, hemos tenido la idea de introducir una capa de consulta para resolver el problema de la construcción y el almacenamiento de muestras durante mucho tiempo. , pero nunca hemos podido encontrar un escenario adecuado: una implementación específica del requisito. Pero mirando hacia atrás ahora, ya sea que se mencione en este artículo sobre la transformación del motor de ejecución de transmisión ha3, el índice de escritura directa del clúster de escritura o la verificación de errores generada por varios planes de consulta que no se mencionaron, y la modificación detallada de la lógica de administración de memoria en tiempo de ejecución. , etc., si no tenemos forma de transformar directamente varios sistemas subyacentes, es difícil imaginar que finalmente podamos completar este proyecto.

2. Las ventajas de la velocidad de iteración de integración que aporta la base de código unificada son significativas y acumulativas. Este artículo menciona que hemos utilizado muchas funciones nuevas desarrolladas por el equipo del sistema subyacente, y los miembros del proyecto también han agregado muchas funciones o corregido errores en varios sistemas, y debido a que el código de todo nuestro equipo AIOS está básicamente en un repositorio mono unificado, nosotros No importa si desea utilizar las últimas funciones de otros sistemas o aprender y cambiar el sistema usted mismo, es un asunto de muy bajo costo, lo que mejorará enormemente nuestra eficiencia.

3. Es muy importante que el sistema se pueda depurar rápidamente. Al principio, estábamos muy preocupados de que el costo de los usuarios para aprender nuestro DSL de muestra fuera muy alto y nos hiciera dedicar mucho tiempo a responder esta parte. Pero después de conectarnos, descubrimos que debido a que hemos creado un entorno de desarrollo de ide web, los usuarios pueden compilar directamente el DSL en la página y ver el informe de error específico directamente. Este proceso de prueba es muy rápido, mucho más rápido que pedirnos que respondamos preguntas. Pruébelo, ya que nuestras necesidades de preguntas y respuestas son principalmente esquemas específicos y configuraciones sugeridas de algunas tablas.

La función de experimento de muestra es todavía un producto muy joven y continuaremos realizando mejoras en los siguientes aspectos:

1. La forma de implementación del clúster tiende a evolucionar según la granularidad del equipo y de las tareas, lo que proporciona un mejor aislamiento y flexibilidad del usuario y evita algunos riesgos en clústeres de escala ultragrande. Pero al mismo tiempo, todo el sistema de operación, mantenimiento y tiempo de ejecución también debe refactorizarse y optimizarse para escenarios de escala fuera de línea de manera oportuna para prepararse para los problemas de escala.

2. En términos de optimización del rendimiento de las consultas, el rendimiento de las consultas y el costo de los grupos de muestra se optimizan continuamente mediante la optimización de la caché de tabla dividida en varias zonas, la expansión y contracción automática y el ajuste automático de los parámetros de programación, de modo que la lectura de la muestra no se convierta en un cuello de botella para el entrenamiento. y los grupos de muestras se reducen con el mismo rendimiento LF.

3. Las funciones específicas del experimento de muestra deben enriquecerse continuamente, como admitir la importación de tablas MaxCompute de múltiples valores en cualquier nivel, comercializar funciones de datos complementarios, admitir udf y establecer un mecanismo de alarma comercial, etc., para cumplir con varios requisitos funcionales del negocio en términos de iteración de muestra.

4. En la actualidad, la lógica de la capa de cálculo se envía al usuario para su preprocesamiento. En el futuro, también se incluirá la generación de tareas de la capa de cálculo, que realizará funciones como el precálculo de uniones parciales y muestras. análisis de datos, para que todo el producto se pueda realizar realmente, hasta consultas de computación híbrida.