¿Puede HTAP de base de datos distribuida unificar OLTP y OLAP?

OLAP y OLTP están conectados a través de ETL. Para mejorar el rendimiento de OLAP, se requiere una gran cantidad de cómputo previo en el proceso ETL, que incluye:

• Ajuste de estructura de datos
• procesamiento de lógica de negocios

Beneficios: puede controlar el retraso de acceso de OLAP y mejorar la experiencia del usuario. Sin embargo, para evitar que el sistema OLTP se vea afectado por la extracción de datos, el proceso ETL debe iniciarse durante el período de negociación bajo al final del día. Por lo tanto, el retraso de datos de OLAP y OLTP suele ser de al menos un día, y esta expresión de puntualidad es T+1:

• Día T, es decir, la fecha en que el sistema OLTP genera datos
• Día T+1, que es la fecha en que los datos están disponibles en OLAP
• El intervalo entre los dos es de 1 día.

El principal problema de este sistema es la puntualidad de los datos del sistema OLAP, T+1 es demasiado lento. Sí, después de ingresar a la era de los grandes datos, las decisiones comerciales prestan más atención al soporte de datos y el análisis de datos continúa penetrando en las operaciones de primera línea, todo lo cual requiere que los sistemas OLAP reflejen los cambios comerciales más rápidamente.

1 idea de solución

Lo que HTAP necesita resolver es el problema de la puntualidad de OLAP, pero no es la única opción, la solución a este problema es la siguiente:

1. Reemplace el proceso ETL por lotes original con cálculo de datos casi en tiempo real y reconstruya el sistema OLAP
2. Debilite o incluso elimine OLAP por completo y amplíelo directamente en el sistema OLTP, es decir, HTAP

1.1 Reconstruir el sistema OLAP

Énfasis en la puntualidad del procesamiento de datos, la principal dirección de desarrollo de la tecnología de big data en los últimos años. La arquitectura Kappa es la representante del nuevo sistema, propuesta por primera vez por Jay Kreps de LinkedIn en un artículo de 2014 :

El método original de transferencia de archivos por lotes se reemplaza completamente por Kafka, y el sistema de computación de flujo completa el procesamiento rápido de datos, y los datos finalmente llegan a Serving DB para proporcionar servicios de consulta. Servir DB generalmente se refiere a varios tipos de almacenamiento, como HBase, Redis o MySQL.

La arquitectura Kappa no se ha realizado por completo porque, en la práctica, la computación de flujo no puede reemplazar la computación por lotes, y la base de datos de servicio no puede cumplir con varios tipos de requisitos de análisis y consulta.

La arquitectura Kappa debe mejorarse aún más:

1. La mejora de la capacidad informática de transmisión requiere el uso de Kafka y Flink
2. La mejora de la potencia informática en tiempo real de Serving DB, con la esperanza de avances en las bases de datos OLAP, al igual que ClickHouse

El nuevo sistema OLAP intenta mejorar las capacidades informáticas en tiempo real, eliminar el ETL por lotes y reducir los retrasos en los datos. Este nuevo sistema es una oportunidad para la transmisión informática y una oportunidad para la autosalvación de la base de datos OLAP.

1.2 Crear un nuevo sistema HTAP (Hybrid Transaction/Analytical Processing)

El procesamiento de análisis de transacciones híbridas apareció por primera vez en un informe de Gartner en 2014 , el mismo año que la arquitectura Kappa. Gartner usa HTAP para describir un nuevo tipo de base de datos, rompiendo la brecha entre OLTP y OLAP, y admitiendo escenarios de bases de datos transaccionales y escenarios de bases de datos analíticas en un sistema de base de datos. La idea es maravillosa, HTAP puede ahorrar tediosas operaciones ETL, evitar el retraso causado por el procesamiento por lotes y analizar los datos más recientes más rápido.

Esta idea mostró rápidamente su lado agresivo, dado que la fuente de datos está en el sistema OLTP, el concepto HTAP rápidamente se convirtió en un estandarte para las bases de datos OLTP, especialmente las bases de datos distribuidas estilo NewSQL, para ingresar al campo OLAP.

Después de que NewSQL inicialmente resuelve los problemas de alta concurrencia y fuerte consistencia en los escenarios OLTP, ¿puede también tener en cuenta el escenario OLAP?

Es difícil decir, desde la perspectiva de la práctica técnica, que las tecnologías relacionadas para reconstruir la ruta OLAP parecen estar desarrollándose más rápido, los fabricantes participantes son más extensos y el entorno de producción real mejora constantemente.

Sin embargo, HTAP está progresando lentamente y existen pocas prácticas industriales a nivel de producción, pero muchos fabricantes aún lo consideran como la dirección de la evolución del producto:

• El HTAP oficial del fabricante incluye al menos TiDB y TBase
• OceanBase también anunció la introducción de funciones de escena OLAP en la versión reciente

Con base en consideraciones de estrategia comercial, más bases de datos distribuidas levantarán la bandera de HTAP en el futuro.

2 diseño de almacenamiento HTAP

Las diferencias entre las arquitecturas OLTP y OLAP son:

• calcular

  La diferencia entre los motores de cómputo es que el objetivo es programar recursos de cómputo de múltiples nodos para lograr el máximo procesamiento paralelo. Debido a que OLAP busca un alto rendimiento para datos masivos, mientras que OLTP se enfoca en baja latencia para pequeñas cantidades de datos, sus motores de cómputo tienen diferentes énfasis

• almacenamiento

  Los datos se organizan de diferentes maneras en el disco, y la forma de organización determina directamente la eficiencia del acceso a los datos. Los formatos de almacenamiento de OLTP y OLAP son almacenamiento de filas y almacenamiento de columnas respectivamente, y sus diferencias se explicarán en detalle más adelante.

El concepto de diseño de flujo de una base de datos distribuida es separar la computación y el almacenamiento, y la computación es más fácil de lograr sin estado, por lo que no es difícil construir múltiples motores de computación en un sistema HTAP, pero es fundamental implementar el concepto de HTAP en un sistema ejecutable El mayor desafío es el almacenamiento. Frente a este desafío, las soluciones de la industria incluyen:

1. El almacenamiento de fusión PAX (Partition Attributes Across) utilizado por Spanner intenta ser compatible con dos tipos de escenarios al mismo tiempo
2. El diseño en la versión TiDB4.0, sobre la base del almacenamiento en fila original, agrega almacenamiento en columna y, mediante un diseño innovador, se garantiza la consistencia de los dos

2.1 Llave inglesa: almacenamiento en uno

El artículo de Spanner de 2017 "Spanner: Becoming a SQL System" presentó su nueva generación de almacenamiento Ressi, que utiliza un método similar a PAX. Este PAX no es una innovación de Spanner, ya que se propuso en el documento VLDB2002 " Diseños de página de datos para bases de datos relacionales en jerarquías de memoria profunda ". Desde la perspectiva de la compatibilidad con la memoria caché de la CPU, este documento analiza diferentes métodos de almacenamiento, que incluyen formatos de almacenamiento NSM, DSM y PAX.

NSM (tienda de filas)

NSM (N-ary Storage Model) es el almacenamiento basado en filas, el método de almacenamiento predeterminado de las bases de datos OLTP, siempre acompañando el desarrollo de las bases de datos relacionales. Las bases de datos OLTP de uso común, como MySQL (InnoDB), PostgreSQL, Oracle y SQL Server, utilizan almacenamiento de filas.

Almacene un registro de datos juntos, que está más cerca del modelo relacional. La eficiencia de escritura es alta y se puede obtener rápidamente un registro de datos completo durante la lectura.Esta función se denomina Localidad espacial intra-registro.

Sin embargo, el almacenamiento de filas no es compatible con las consultas de análisis OLAP. Los datos del sistema OLAP a menudo se fusionan desde múltiples sistemas OLTP, y una sola tabla puede tener cientos de campos:

• Sin embargo, un usuario generalmente solo accede a una pequeña cantidad de campos en una consulta, como leer datos en unidades de filas, la mayoría de los campos son inútiles para consultar y una gran cantidad de operaciones de E/S no son válidas.
• Se lee una gran cantidad de datos no válidos, lo que hace que la memoria caché de la CPU falle, lo que reduce aún más el rendimiento del sistema.

La figura muestra el procesamiento de la memoria caché de la CPU. Podemos ver que una gran cantidad de datos no válidos se llenan en la memoria caché, desplazando los datos que tenían la oportunidad de ser reutilizados.

DSM (almacenamiento de columnas)

DSM (Modelo de almacenamiento de descomposición), apareció más tarde que el almacenamiento en fila. El sistema representativo típico es C-Store, un proyecto de código abierto dirigido por Michael Stonebraker, y luego comercializó el producto Vertica.

El almacenamiento centralizado de todas las columnas no solo es más adecuado para las características de acceso OLAP, sino que también es más compatible con CACHE. Esta característica se denomina Localidad espacial entre registros. El almacenamiento en columnas puede mejorar en gran medida el rendimiento de las consultas, y ck, que es famoso por su rapidez, es el almacenamiento en columnas.

El problema con el almacenamiento en columnas es que la sobrecarga de escritura es mayor, porque según el modelo relacional, la unidad organizativa lógica de datos sigue siendo una fila. Después de cambiar al almacenamiento en columnas, la misma cantidad de datos se escribirá en más páginas de datos ( página), y la página de datos corresponde directamente al sector físico, y la sobrecarga de E/S del disco aumenta naturalmente.

El segundo problema con el almacenamiento en columnas es que es difícil asociar diferentes columnas de manera eficiente. Después de todo, en la mayoría de los escenarios de aplicación, no solo se utilizan datos de una sola columna o de una sola tabla, sino que una vez que los datos se dispersan, el costo de la asociación es mayor.

PAZ

PAX agrega el concepto de minipágina, que es una unidad secundaria debajo de la página de datos original, por lo que la distribución básica de una fila de registros de datos en la página de datos no se destruirá y los datos de la misma columna se almacenarán juntos en una manera centralizada. En esencia, PAX aún está más cerca del almacenamiento de filas, pero también intenta equilibrar la localidad dentro de los registros y la localidad entre registros, lo que mejora el rendimiento de OLAP.

En teoría, PAX proporciona un método de almacenamiento con mejor compatibilidad, pero lo que hace que la gente tenga menos confianza es que se propuso ya en 2002, pero rara vez se implementó antes de Spanner.

Un diseño similar a esta idea es el DataBlock de HyPer (SIGMOD 2016), que construye una estructura de datos única para los escenarios OLTP y OLAP.

TiFlash: separación de almacenamiento

Si el almacenamiento subyacente es un dato, la coherencia de datos entre OLTP y OLAP se puede garantizar de forma natural, que es la mayor ventaja de PAX. Sin embargo, debido a los diferentes modos de acceso, la interacción del rendimiento parece ser inevitable, por lo que Solo podemos hacer nuestro mejor esfuerzo para elegir un punto de equilibrio. TiDB muestra una forma de pensar diferente, entre PAX y los sistemas OLAP tradicionales, es decir, OLTP y OLAP adoptan diferentes métodos de almacenamiento, que están físicamente separados, y luego usan estrategias de replicación innovadoras para garantizar que los datos de los dos sean consistentes. sexo.

TiDB propuso el objetivo de HTAP en una versión anterior y agregó TiSpark como un motor informático OLAP, pero aún comparte el almacenamiento de datos OLTP TiKV, por lo que la competencia de recursos entre las dos tareas sigue siendo inevitable. Hasta la reciente versión 4.0, TiDB lanzó oficialmente TiFlash como un almacenamiento dedicado para OLAP.

Nuestro enfoque está en el mecanismo de sincronización entre TiFlash y TiKV. De hecho, este mecanismo de sincronización todavía se basa en el protocolo Raft. TiDB agrega un rol de Aprendiz al protocolo original de Líder y Seguidor de Raft. Este Learner y el rol del mismo nombre en el protocolo Paxos tienen responsabilidades similares, es decir, son responsables de aprender el estado acordado, pero no participan en la votación. Es decir, Raft Group no incluye al Learner al contar la mayoría de nodos durante el proceso de escritura, la ventaja de esto es que el Learner no ralentizará la operación de escritura, pero el problema es que la actualización de datos del El alumno inevitablemente se quedará atrás del líder.

¿No es esto solo una replicación asíncrona? Si cambias tu chaleco, ¿cuál es la innovación? Esto no puede garantizar la coherencia de datos entre AP y TP, ¿verdad?

El protocolo Raft puede lograr la consistencia de los datos porque solo el nodo maestro está restringido para proporcionar servicios. De lo contrario, sin mencionar los servicios externos directos del alumno o el seguidor, no puede satisfacer la consistencia de los datos. Entonces, aquí hay otro diseño.

Cada vez que el alumno recibe una solicitud, primero debe confirmar si los datos locales son lo suficientemente nuevos y luego ejecutar la operación de consulta. ¿Cómo confirmar que es lo suficientemente nuevo? El alumno enviará una solicitud al líder con la marca de tiempo de la transacción de lectura para obtener el último índice de compromiso del líder, que es el número de secuencia del registro comprometido. Luego, espere a que el registro local continúe Aplicar hasta que el número de registro local sea igual al índice de confirmación y los datos sean lo suficientemente nuevos. Sin embargo, la solicitud esperará hasta que se agote el tiempo de espera antes de que la copia de la región local complete la sincronización.

El requisito previo para el funcionamiento eficaz de este mecanismo de sincronización es que TiFlash no se puede atrasar demasiado, de lo contrario, cada solicitud generará operaciones de sincronización de datos y una gran cantidad de solicitudes expirarán, lo que imposibilitará su uso en la práctica. Sin embargo, TiFlash es un almacenamiento en columna y el rendimiento de escritura del almacenamiento en columna generalmente no es bueno. ¿Cómo puede TiFlash mantener una velocidad de escritura cercana a la de TiKV? El motor de almacenamiento de TiFlash, Delta Tree, hace referencia al diseño de B+ Tree y LSM-Tree, y se divide en dos capas: Delta Layer y Stable Layer.La Delta Layer garantiza un alto rendimiento de escritura. Debido a que el conocimiento previo del motor de almacenamiento no se le ha presentado hasta ahora, el Árbol Delta no se ampliará aquí.

TiFlash es un sistema OLAP y su objetivo principal es garantizar el rendimiento de lectura, por lo que, por importante que sea la escritura, debe dejar paso a la optimización de la lectura. Como sistema distribuido, existe un último recurso disponible, que consiste en reducir la presión de la escritura de un solo punto a través de la expansión de la capacidad.

Resumir

1. OLTP se conecta con OLAP a través de ETL, por lo que la puntualidad de los datos OLAP suele ser T+1, lo que no puede reflejar los cambios comerciales de manera oportuna. Hay dos formas de resolver este problema: reconstruir el sistema OLAP, reemplazar el procesamiento de datos por lotes con computación de flujo y acortar el retraso de datos de OLAP. El representante típico es la arquitectura Kappa; HTAP propuesta por Gartner
2. Los puntos de diseño de HTAP son el motor informático y el motor de almacenamiento, entre los cuales el motor de almacenamiento es la base. También hay dos soluciones diferentes para el motor de almacenamiento, una está representada por PAX, que utiliza un almacenamiento físico para integrar las características de fila y columna, Spanner adopta este método. El otro es TiFlash de TiDB, que configura el almacenamiento de filas y columnas para OLTP y OLAP respectivamente, y asegura la consistencia de los datos a través de un innovador mecanismo de sincronización.
3. El mecanismo de sincronización de TiDB aún se basa en el protocolo Raft, y la replicación asíncrona se logra agregando el rol de Aprendiz. La replicación asincrónica inevitablemente genera demoras en los datos. Antes de responder a la solicitud, el alumno satisface la consistencia de los datos sincronizando registros incrementales con el líder, pero esto generará una sobrecarga de comunicación adicional.
4. Como almacenamiento de columna, TiFlash primero debe garantizar el rendimiento de lectura, pero debido a que se debe garantizar la consistencia de los datos, también requiere un alto rendimiento de escritura. TiFlash equilibra el rendimiento de lectura y escritura a través del diseño de Delta Tree. No hemos ampliado este tema y continuaremos discutiéndolo en la lección 22.

En términos generales, HTAP es una idea para resolver OLAP tradicional, pero los promotores son solo unos pocos proveedores de bases de datos OLTP. Mirando el otro lado, el nuevo sistema OLAP basado en la computación de flujo, estas tecnologías en sí mismas son parte de la ecología de la tecnología de big data, hay más participantes y constantemente se implementan nuevos logros. En cuanto a la consistencia de datos en la que HTAP tiene una ventaja absoluta, de hecho, es posible que no haya suficientes requisitos rígidos en los escenarios comerciales. Por lo tanto, partiendo del efecto práctico, soy más optimista sobre este último, que es el nuevo sistema OLAP.

Por supuesto, HTAP también tiene una ventaja relativa, es decir, la solución de cubo familiar evita que los usuarios integren múltiples productos técnicos y se reduce la complejidad técnica general. Finalmente, la solución proporcionada por TiDB es muy innovadora, pero aún está por verse si puede cubrir una escena OLAP lo suficientemente grande.

Preguntas más frecuentes

Presente TiFlash, el componente OLAP de TiDB. Mantiene la consistencia de los datos. Cada vez que TiFlash recibe una solicitud, solicitará el último incremento de registro de TiKV Leader y luego continuará procesando la solicitud después de reproducir localmente el registro. Aunque este modo puede garantizar que los datos estén lo suficientemente actualizados, tiene una comunicación de red más en comparación con el servicio independiente de TiFlash, que tiene un mayor impacto en la demora. Mi pregunta es, ¿crees que este modelo se puede optimizar? ¿Bajo qué circunstancias no necesita comunicarse con el Líder?

referencia

• Anastassia Ailamaki et al .: Diseños de página de datos para bases de datos relacionales en jerarquías de memoria profunda
• Harald Lang et al: Bloques de datos: OLTP híbrido y OLAP en almacenamiento comprimido usando vectorización y compilación
• Jay Kreps: cuestionando la arquitectura Lambda
• Nigel Rayner et al.: Transacción híbrida/procesamiento analítico fomentará oportunidades para una innovación comercial espectacular

Se puede iniciar un subproceso que sondea los incrementos de registro en segundo plano, y la sincronización de datos reales se activa cuando la diferencia es mayor que una cierta cantidad. O agregue una versión en el paquete de latidos para comparar y active la sincronización activa cuando la diferencia sea grande. De esta manera, no hay necesidad de esperar hasta que llegue la solicitud para disparar, ahorrando este retraso de espera. Sin embargo, dado que es un nodo que no es miembro de Raft, habrá ciertas diferencias de datos sobre cómo hacerlo. Debería ser suficiente para la mayoría de los escenarios de análisis OLAP.

Sin exposición a OLAP.

¿Es posible no solicitar el incremento de registro "más reciente" cada vez, sino solicitar datos a pedido: guarde una marca de tiempo nueva y antigua de los datos localmente, si es anterior a la marca de tiempo de la solicitud de lectura, no hay necesidad de solicitarlo;

O establezca un factor de calidad, puede asignar los datos solicitados, usar un algoritmo similar al promedio móvil, calcular dinámicamente el índice objetivo y dejar de solicitar datos una vez que se cumplan los requisitos de calidad.

Cuando la marca de tiempo solicitada por el cliente puede estar seguro de que es menor que la marca de tiempo del servidor. La dificultad debería ser cómo asegurar la sincronización de tiempo entre el cliente y el servidor.