Papel de optimización del sistema de procesamiento de flujo

AJoin: conexiones de transmisión ad-hoc a escala VLDB2019

Antecedentes: los sistemas de procesamiento de flujo existentes, como flink, se utilizan principalmente para procesar una sola consulta que se ha estado ejecutando en el flujo de datos, y estas consultas se optimizan y ejecutan por separado. El marco propuesto por Astream ¹ se dirige principalmente a consultas ad-hoc. En este escenario, la secuencia no solo usa consultas de ejecución prolongada para el procesamiento, sino que también usa miles de consultas temporales de ejecución corta para su procesamiento. Para respaldar esto de manera efectiva, los recursos y cálculos para la transmisión de consultas temporales deben compartirse en un entorno multiusuario. Astream utiliza algunos operadores compartidos para evitar cálculos redundantes. Basado en Astream, AJoin ² ha realizado algunas optimizaciones adicionales, como reducir el costo de los operadores compartidos, volver a optimizar los planes de consulta en tiempo de ejecución, escalar y escalar en tiempo de ejecución, etc.

Por ejemplo, el siguiente escenario:

V = {vID, length, geo, lang, time} La transmisión de video que se muestra en el muro de usuarios

W = {usrID, vID, duration, geo, time} el flujo de visualización de video del usuario

C = {usrID, comentario, longitud, foto, emojis, tiempo} Flujo de evaluación del usuario

R = {usrID, reacción, tiempo} flujo de comentarios del usuario

P1: El módulo de aprendizaje automático se utiliza para aprender a obtener las preferencias del usuario. Esta consulta obtendrá las películas en inglés que a los usuarios alemanes les gusta ver.

Q2: El equipo editorial se utiliza para descubrir la organización de operaciones de la red (Navy). Esta consulta se utiliza para detectar usuarios de los Estados Unidos. Estos usuarios comentaron dentro de los 10 segundos de haber visto la película y la longitud del comentario es superior a 5 .

P3: El grupo de garantía de calidad se utiliza para analizar los comentarios de los usuarios sobre los videos recomendados. Esta consulta se utiliza para analizar los videos que los usuarios europeos dan comentarios negativos, y hay al menos una expresión en los comentarios.

Este es uno de los gráficos experimentales. Puedes ver que cuando hay más consultas al mismo tiempo (enfócate en la parte púrpura), la ventaja de rendimiento de Ajoin es muy obvia.

Arreglos compartidos: uso compartido práctico entre consultas para flujos de datos de transmisión VLDB2020

Antecedentes: los sistemas actuales de paralelismo de datos, procesamiento incremental y mantenimiento de vistas en flujos de alta velocidad aíslan la ejecución de consultas independientes. En presencia de consultas de mantenimiento incrementales simultáneas, esto provocará redundancia y sobrecarga innecesarias: cada consulta debe mantener de forma independiente el mismo estado de índice en el mismo flujo de entrada, y las nuevas consultas deben construir este estado desde cero. Solo entonces puede comenzar a emitir su primer resultado. Este artículo ³ presenta la disposición para compartir: mantener una vista indexada del estado, lo que permite que las consultas simultáneas reutilicen el mismo estado de la memoria sin afectar el rendimiento y la escalabilidad en paralelo de los datos. Implementamos un arreglo para compartir en procesadores de flujo modernos y realizamos consultas interactivas incrementales para flujos de alto rendimiento, mostrando una mejora de orden de magnitud en el tiempo de respuesta de consultas y el consumo de recursos.

El trabajo anterior de AJoin pertenece a Multi-Query-Optimization (MQO), que compartirá el estado y el procesamiento de subexpresiones comunes, mientras que los arreglos compartidos son índices históricos compartidos, que permiten el intercambio post-mortem: las nuevas consultas se pueden agregar inmediatamente al Se programó la memoria de las consultas existentes y rápidamente comenzó a generar una salida correcta que reflejaba todos los eventos anteriores.

Procesamiento incremental: a diferencia de las consultas SQL generales, en las consultas SQL incrementales, cuando el contenido de una tabla cambia, esperamos que estas tablas expresen la modificación del contenido como una tabla delta que contiene filas aumentadas y filas disminuidas (tabla delta en forma de) , estas tablas incrementales serán enviadas al operador superior para su procesamiento El SQL en flink es todo SQL incremental.

La figura anterior es un gráfico de resultados experimentales, ejecutando la prueba TPC-H, el más a la izquierda es la distribución del retraso de la consulta, el medio es el retraso del procesamiento de actualización y el derecho es el uso de la memoria. Se puede ver que la investigación mejora efectivamente el rendimiento y reduce el uso de memoria. El gráfico del medio es el gráfico de distribución acumulativa complementario, lo que significa la distribución acumulativa de consultas que se retrasan durante más de un tiempo determinado.

También hay un trabajo relacionado ⁴ .

Análisis de procesamiento de flujo eficiente en hardware moderno VLDB2019

Antecedentes: los motores de procesamiento de flujo (SPE) modernos procesan grandes cantidades de datos bajo estrictas restricciones de latencia. Muchas SPE utilizan mensajes entregados en una arquitectura de nada compartido para realizar líneas de procesamiento y aplican estrategias de escalamiento horizontal basadas en particiones para procesar flujos de entrada de alta velocidad. Además, muchas de las últimas SPEs dependen de la máquina virtual Java para lograr la independencia de la plataforma y acelerar el desarrollo del sistema al abstraerse del hardware subyacente, pero no pueden hacer un uso completo de los recursos de hardware de alto rendimiento existentes. Este artículo ⁵ considera principalmente la transmisión de datos y la sobrecarga de sincronización que trae Scale out, y propone hacer un uso completo del hardware de alto rendimiento para hacer que Scale up sea otra opción para la expansión de la capacidad. Sabre ⁶ es un ejemplo, que utiliza recursos de GPU para la aceleración computacional. Este artículo analiza exhaustivamente qué optimizaciones puede hacer el sistema de procesamiento de flujo existente para adaptarse al desarrollo de hardware existente.

• Desarrollo de hardware existente:
  • CPU : cada zócalo de una CPU de varios zócalos tiene varios núcleos y su propio controlador de memoria, y la demora de acceso a la memoria entre los zócalos será mayor (NUMA)
  • Memoria: crecimiento de la capacidad (hasta terabytes de memoria)
  • Red: la velocidad de acceso aumenta más rápido, incluso más rápido que la memoria. Por lo tanto, la tecnología de acceso remoto a memoria RDMA
• Este artículo funciona:
  • Comparación del rendimiento de C ++ y Java: como el acceso RDMA (ingestión de datos), el acceso a la cola (intercambio de datos)
  • Se proponen dos estrategias de paralelización: Partición inicial (UP, ampliamente utilizada en arquitecturas de escalamiento horizontal existentes como flink) y dos estrategias de paralelización para Escalado, fusión local tardía (LM) y fusión global tardía (GM).
  • Implementar un mecanismo de ventana sin bloqueo: minimizar los conflictos entre los hilos de trabajo

Las anteriores son varias imágenes experimentales en el artículo. YSB, LRB y NYT corresponden a diferentes benchmarks, y UP, LM y GM corresponden a diferentes estrategias de paralelización. Se puede ver que el método basado en c ++ puede hacer un mejor uso de la memoria y está cerca de la memoria El ancho de banda basado en Java es muy inferior. Además, la estrategia de MG propuesta por el autor también funciona mejor en un caso independiente.

Este artículo ⁷ trata sobre la gestión de memoria global de RDMA.

La figura anterior es un gráfico experimental extendido, que es el resultado de una condición de red de 1 Gbs. Para los puntos de referencia intensivos en la red, como YSB, el rendimiento ya no mejorará cuando haya más de 4 nodos. Este artículo ⁸ muestra que cuando aumenta el ancho de banda de la red, la CPU volverá a ser el cuello de botella y apache spark y flink requieren cambios en el sistema.

Unión de flujos paralelos basada en índices en una cpu multinúcleo SIGMOD2020

Antecedentes: la tarea principal de este documento es indexar los datos de transmisión de ventanas deslizantes para mejorar el rendimiento de las conexiones de ventanas. La estructura de índice tradicional no puede cumplir con las características de los cambios dinámicos de transmisión de datos. Este artículo ⁹ propone un índice con una estructura de árbol de fusión de memoria particionada, y también propone algunos mecanismos de control de concurrencia para él, de modo que el índice admita actualizaciones frecuentes bajo multiproceso. Sobre esta base, este documento también diseña un algoritmo para implementar una conexión de flujo paralelo basada en índices, a fin de utilizar la potencia de cálculo de los procesadores de múltiples núcleos. La siguiente figura es la comparación entre PIM-Tree e IM-Tree y B + Tree propuestos en el artículo. El eje vertical es el rendimiento y el eje horizontal es el tamaño de la ventana. A la derecha está la mejora del rendimiento de la combinación mediante subprocesos múltiples.

Aprender a optimizar las consultas conjuntas con aprendizaje por refuerzo profundo

La optimización de la secuencia de conexión tradicional solo debe basarse en programación dinámica o métodos heurísticos (Zig-Zag, QuickPick-1000, etc.). Cuando el modelo de costes no es lineal (por ejemplo, limitaciones de memoria, materialización de multiplexación, etc.), las soluciones obtenidas por estos métodos suelen ser subóptimas. Este artículo ¹⁰ expresa el problema del orden de conexión como un proceso de decisión de Markov (MDP), y luego construye un optimizador usando una red Q profunda (DQN) para ordenar las conexiones de manera efectiva. Este documento evalúa el método propuesto basado en el Join Order Benchmark (especialmente utilizado para la optimización de conexiones de pruebas de estrés). El costo del plan de ejecución del optimizador profundo basado en el aprendizaje por refuerzo se mejora 2 veces en comparación con todas las soluciones óptimas del modelo de costo actual, y se mejora hasta 3 veces en comparación con los mejores métodos heurísticos actuales.

El experimento en la figura anterior compara el desempeño de DQ (el método propuesto en este artículo) bajo los tres modelos de costos en comparación con algunos otros métodos. Entre ellos, la solución obtenida por solución violenta se utiliza como línea de base, y los demás son relativos al desempeño de esta línea de base. Hay tres modelos de costos, el primero es que todos los datos están en la memoria, el segundo es considerar el límite de memoria y la memoria se sobrescribe en el disco, y el tercero es reutilizar la tabla hash establecida por la operación upstream. . Se puede ver que a medida que el modelo de costos se vuelve adicional, el desempeño relativo de DQ también es mejor.

La figura anterior muestra el cambio de retardo del optimizador en sí a medida que aumenta el número de relaciones de unión y el eje vertical es log. Se puede ver que cuando aumenta el número de relaciones conjuntas, las ventajas de DQ se vuelven más obvias. Si usa aceleración de GPU o TPU, mostrará una mayor ventaja.

Chi: un plano de control escalable y programable para sistemas de procesamiento de flujo distribuidos

La carga de trabajo del sistema de procesamiento de flujo y el entorno de nube compartida son muy variables e impredecibles. Junto con un gran espacio de parámetros y diferentes SLO, es difícil que el sistema de procesamiento de flujo se ajuste estáticamente. Este artículo ¹¹ propone un panel de control escalable y programable para un sistema de procesamiento de flujo distribuido que admite monitoreo continuo, retroalimentación y reconfiguración dinámica. Chi utiliza el mensaje del plano de control integrado en el canal del plano de datos para darse cuenta de la baja latencia y el plano de control flexible del sistema de procesamiento de flujo. Chi introdujo un nuevo modelo de programación reactiva y un mecanismo de diseño para ejecutar estrategias de control de forma asincrónica, evitando así la sincronización global.

La figura de arriba es un experimento de expansión dinámica, en t = 40s, la velocidad de adquisición de datos se duplica y luego las estrategias de cada sistema se utilizan para la expansión. En Flink, llamará a SavePoint y luego reiniciará el flujo de datos. Flink se detendrá debido al mecanismo de punto de guardado y el rendimiento caerá a cero en el lugar de la derecha, y se recuperará después de unos segundos. El aumento máximo de Chi es relativamente pequeño y vuelve a un estado estable a un ritmo más rápido, que es aproximadamente 6 veces el de flink.

El sistema realizará un punto de control cada 10 segundos, y se ha realizado un punto de control en 35 segundos, y luego se suspende una máquina virtual en 40 segundos, y luego se utilizan los tres mecanismos de recuperación del sistema. Dado que flink necesita el punto de control anterior para volver a implementar el flujo de datos, el rendimiento cayó a 0 nuevamente, mientras que el rendimiento de Chi no disminuyó y el retraso volvió a un estado estable más rápido, que fue aproximadamente 3 veces más rápido que flink.

Agregación de ventana deslizante óptima y general fuera de orden

La agregación de ventana deslizante es muy común en aplicaciones de sistemas de procesamiento de flujo. Algunos operadores, como suma y media, no tienen requisitos en el orden de llegada de los datos. Cada uno puede agregarse, por lo que la complejidad del tiempo es O (1). Pero para algunos operadores, como max, min, etc., la secuencia de llegada por convección requiere orden. Sin embargo, muchas veces, como la fluctuación de la red, el procesamiento por lotes, la recuperación de fallas, etc., causarán algunos retrasos, por lo que los datos no llegan en orden. En este momento, hay dos estrategias principales. Una es esperar a que lleguen los datos, ordenarlos y luego agregarlos; la otra es agregar todos los datos en una estructura de datos para facilitar la consulta en cualquier momento. El método es para usar un árbol rojo-negro mejorado para hacerlo, la complejidad es O (Logn), donde n es el tamaño de la ventana. Este artículo ¹² propone un algoritmo agregador de árbol B finger, que puede alcanzar una complejidad O (1) en una situación ordenada, y un ligero desorden puede alcanzar una complejidad cercana a O (1). En casos extremos, es solo O (logn ) Complejidad.

Como puede verse en la figura, el rendimiento de agregación de flink en escenarios fuera de orden es relativamente bajo.

otro

mvcc

1. Böttcher, Jan y col. "Recolección de basura escalable para sistemas MVCC en memoria". Actas de la Dotación VLDB 13.2 (2019): 128-141.
2. Sun, Yihan y col. "Sobre la compatibilidad con el aislamiento de instantáneas eficiente para cargas de trabajo híbridas con índices de varias versiones". Actas de la Fundación VLDB 13.2 (2019): 211-225.

topk

1. Zois, Vasileios, Vassilis J. Tsotras y Walid A. Najjar. "Selección eficiente de la memoria principal top-K para arquitecturas multinúcleo". Actas de la Dotación VLDB 13.2 (2019): 114-127.

Compilación SparkSQL

Schiavio, Filippo, Daniele Bonetta y Walter Binder. "Optimizaciones especulativas dinámicas para la compilación de SQL en Apache Spark". Actas del VLDB Endowment 13.5 (2020): 754-767.

AI4DB

1. Sun, Ji y Guoliang Li. "Un estimador de costos basado en el aprendizaje de un extremo a otro". Actas de la Dotación VLDB 13.3 (2019): 307-319.
2. Li, G. y col. (2019). "Qtune: un sistema de ajuste de bases de datos con reconocimiento de consultas con aprendizaje de refuerzo profundo". Actas de la Fundación VLDB 12 (12): 2118-2130.
3. Tan, J. y col. (2019). "Ibtune: ajuste de búfer individualizado para bases de datos en la nube a gran escala". Actas de la Fundación VLDB 12 (10): 1221-1234.
4. Van Aken, D. y col. (2017). Ajuste automático del sistema de administración de bases de datos a través del aprendizaje automático a gran escala. Actas de la Conferencia Internacional ACM 2017 sobre Gestión de Datos.
5. Zhu, Y. y col. (2017). Bestconfig: aprovechando el potencial de rendimiento de los sistemas mediante el ajuste automático de la configuración. Actas del Simposio de 2017 sobre Computación en la Nube.
6. Zhang, J. y col. (2019). Un sistema de ajuste de base de datos en la nube automático de extremo a extremo que utiliza aprendizaje de refuerzo profundo. Actas de la Conferencia Internacional sobre Gestión de Datos de 2019 - SIGMOD '19: 415-432.

referencias

---

1. Karimov, J. y col. (2019). Astream: procesamiento de flujo compartido ad-hoc. Actas de la Conferencia Internacional sobre Gestión de Datos de 2019. ↩︎

2. Karimov, J. y col. (2019). "AJoin: la transmisión ad-hoc se une a escala". Actas de la Fundación VLDB 13 (4): 435-448. ↩︎

3. McSherry, F. y col. (2020). "Arreglos compartidos: uso compartido práctico entre consultas para flujos de datos de transmisión". Actas de la Fundación VLDB 13 (10): 1793-1806. ↩︎

4. Rehrmann, Robin y col. "Oltpshare: el caso para compartir en cargas de trabajo OLTP". Actas del VLDB Endowment 11.12 (2018): 1769-1780. ↩︎

5. Zeuch, S. y col. (2019). "Analizando el procesamiento de flujo eficiente en hardware moderno". Actas de la Fundación VLDB 12 (5): 516-530. ↩︎

6. A. Koliousis, M. Weidlich, R. Castro Fernandez, AL Wolf, P. Costa y P. Pietzuch. Sabre: procesamiento de flujo híbrido basado en ventanas para arquitecturas heterogéneas. En SIGMOD, páginas 555–569. ACM, 2016. ↩︎

7. Cai, Qingchao y col. "Gestión de memoria distribuida eficiente con RDMA y almacenamiento en caché". Actas del VLDB Endowment 11.11 (2018): 1604-1617. ↩︎

8. A. Trivedi, P. Stuedi, J. Pfefferle, R. Stoica, B. Metzler, I. Koltsidas y N. Ioannou. Sobre la [ir] relevancia del rendimiento de la red para el procesamiento de datos. En el Taller de USENIX sobre temas candentes en Cloud Computing (HotCloud 16). USENIX ↩︎

9. Shahvarani, A. y H.-A. Jacobsen (2020). Combinación de secuencias paralelas basadas en índices en una CPU multinúcleo. Actas de la Conferencia Internacional ACM SIGMOD 2020 sobre Gestión de Datos. ↩︎

10. Krishnan, Sanjay y col. "Aprender a optimizar las consultas conjuntas con aprendizaje por refuerzo profundo". preimpresión de arXiv arXiv: 1808.03196 (2018). ↩︎

11. Mai, Luo y col. "Chi: un plano de control escalable y programable para sistemas de procesamiento de flujo distribuidos". Actas de la Fundación VLDB 11.10 (2018): 1303-1316. ↩︎

12. Tangwongsan, Kanat, Martin Hirzel y Scott Schneider. "Agregación de ventana deslizante óptima y general fuera de orden". Actas de la Dotación VLDB 12.10 (2019): 1167-1180.
    l, y Scott Schneider. "Agregación de ventana deslizante fuera de orden óptima y general". Actas de la Dotación VLDB 12.10 (2019): 1167-1180. ↩︎