Resumen: Este artículo está compilado a partir de Zhou Yueyue, arquitecto de OceanBase, compartiendo la sesión del almacén del lago en tiempo real de Flink Forward Asia 2022. El contenido de este artículo se divide principalmente en cuatro partes:
Interpretación de tecnologías clave de la base de datos distribuida OceanBase
Acoplamiento ecológico y escenarios típicos de aplicación
Práctica de OceanBase X Flink en la industria del juego
perspectiva del futuro
Haga clic para ver el PPT de video y discurso original
1. Interpretación de las tecnologías clave de la base de datos distribuida OceanBase
Como una base de datos distribuida nacional de desarrollo propio después de 12 años, desde la aprobación del proyecto del producto hasta el lanzamiento del negocio central de transacciones, OceanBase se ha movido firmemente hacia una arquitectura distribuida de la era 1.0, y el producto ha comenzado a implementarse en Alipay y respaldar el negocio central. .
Con la mejora adicional de las capacidades del producto, la era OceanBase 2.0 evolucionó de un sistema de almacenamiento KV a una base de datos distribuida nativa con transacciones distribuidas y una sólida consistencia de múltiples copias, y comenzó a servir a clientes corporativos externos, incluidos Internet, finanzas, valores y otros. industrias
En la era 3.0, con la mejora de las capacidades HTAP, los motores híbridos y las soluciones de implementación híbrida atraen a más clientes empresariales en el extranjero para su uso. Con el lanzamiento de la versión 4.0, OceanBase propone una arquitectura integrada distribuida independiente para ayudar a las empresas a miniaturizar y proporcionar servicios de nube pública.
La arquitectura integrada de OceanBase se puede resumir con tres palabras clave: protocolo Paxos, arquitectura de nada compartido y alta disponibilidad a nivel de partición.
De forma predeterminada, los datos se almacenan en copias múltiples, el concepto de copias múltiples. Se garantiza una fuerte consistencia de datos entre réplicas a través del protocolo Paxos. A través del protocolo multicopia + Paxos se garantiza la alta disponibilidad del sistema de base de datos.
Cada nodo OBServer en el sistema tiene capacidades de computación y almacenamiento. No hay cuello de botella de un solo punto en todo el sistema, y se pueden leer y escribir múltiples puntos. Cuando el clúster se expande y se reduce, los datos se migran utilizando particiones como unidad básica para lograr automáticamente el equilibrio de carga.
Como sistema que lleva el alma de una empresa, la alta disponibilidad de la base de datos es crucial para la empresa. La típica solución de implementación de tres copias de OceanBase basada en el protocolo Paxos garantiza que los datos no se perderán y los servicios no se interrumpirán cuando falla una sola máquina, una sala de computadoras o una ciudad.
La reducción de costos y el aumento de la eficiencia es un tema eterno para las empresas, por lo que la forma de reducir los costos de hardware a través de medios técnicos es una preocupación de todas las empresas. Cuando se escriben datos en OceanBase, primero se escriben en la memoria, y cuando se cumplen las condiciones o se activa el umbral establecido, los datos se actualizarán en el disco.
Por lo tanto, la cantidad total de datos en OceanBase consiste en datos de referencia de disco y datos incrementales de memoria, por lo que OceanBase a veces se denomina base de datos de cuasi-memoria. En términos de compresión de datos, la estructura de datos de árbol LSM utilizada por OceanBase tiene un algoritmo de compresión correspondiente en cada capa.Este tipo de compresión se denomina compresión general.
Sobre la base de la compresión general, OceanBase desarrolló un conjunto de métodos de compresión (codificación) para la codificación mixta de filas y columnas de la base de datos, que comprimirá aún más los datos. El espacio de almacenamiento se reduce aún más sobre la base de la compresión general. En las mismas condiciones, en comparación con Oracle, el costo de almacenamiento de OceanBase es solo alrededor de 1/3 del anterior.
En las soluciones de bases de datos tradicionales, como la base de datos MySQl más utilizada, las empresas múltiples generalmente se dividen en múltiples bases de datos. Aislar físicamente. Evite excepciones comerciales individuales que afecten a todo el sistema comercial. Con el rápido crecimiento de los negocios, el personal de operación y mantenimiento necesita operar, mantener y administrar múltiples conjuntos de entornos, y el costo es alto.
En OceanBase, en el caso de contar con recursos suficientes, solo es necesario crear nuevos inquilinos para acceder a nuevos servicios, y lograr el aislamiento de recursos y la independencia de datos entre servicios. El esquema de aislamiento de recursos entre inquilinos garantiza que un entorno pueda transportar múltiples conjuntos de servicios y la carga de trabajo del personal de operación y mantenimiento se reduce considerablemente.
HTAP es un tema que se ha mencionado constantemente en los últimos años, entonces, ¿HTAP es una proposición falsa? De hecho, HTAP no aparece de la nada, la realidad es que los usuarios tienen necesidades comerciales reales y escenarios reales.
En la solución anterior, los datos generados por el negocio de TP se sincronizaban con algunos productos analíticos a través de herramientas para realizar tareas como el análisis de datos y la ejecución de lotes. Esto implica el empalme de múltiples sistemas, así como la transferencia y el almacenamiento de múltiples copias de datos.
Actualmente, el HTAP en el que todos están de acuerdo es también el HTAP que piensa el OB: es decir, mientras hace un buen trabajo en TP, teniendo en cuenta y mejorando la capacidad de análisis. En este concepto, hay dos puntos centrales, a saber, una pieza de datos y un conjunto de sistemas. Los datos se pueden procesar en un sistema y no hay necesidad de sincronizar y transferir nuevamente.
Además de un conjunto de motores SQL para satisfacer las necesidades de TP y AP, OceanBase también puede implementar de manera flexible varias estrategias de separación de lectura y escritura a través de múltiples tipos de copia y consistencia débil de acuerdo con los requisitos de separación de lectura y escritura del usuario, asegurando que el negocio original no será cambiado El costo es 0, que puede satisfacer las necesidades de los usuarios.
Como una base de datos distribuida, la escalabilidad es la capacidad más importante Bajo la arquitectura integrada de OceanBase, los nodos del clúster son iguales, cada nodo tiene capacidades informáticas y de almacenamiento, y se puede expandir y reducir en línea al mismo tiempo. Cada nodo puede leer y escribir. En teoría, el rendimiento del clúster aumenta linealmente con la expansión de los nodos.
No hace mucho, OceanBase lanzó la versión 4.0, que presenta una arquitectura integrada distribuida independiente. La arquitectura distribuida se usa más en escenarios comerciales con gran volumen y escala de datos, y en estos escenarios, las ventajas distribuidas se pueden utilizar mejor.
Para los usuarios empresariales cuyo volumen de datos comerciales no es lo suficientemente grande, o cuyo volumen de datos actual no es grande, la solución distribuida requiere demasiados recursos, por lo que no es adecuada para escenarios de volumen de negocios pequeños y medianos. Al mismo tiempo, una arquitectura autónoma o liviana es más adecuada para este tipo de negocios. La solución de arquitectura integrada independiente, mientras usa una máquina independiente, puede cambiar la máquina independiente a una arquitectura distribuida a medida que la escala de datos crece en el futuro, satisfaciendo completamente las necesidades del desarrollo empresarial.
2. Atraque ecológico y escenarios típicos de aplicación
Como producto representativo en el campo del análisis en tiempo real, Flink es utilizado por muchos usuarios de la comunidad de OceanBasse y se utiliza en escenarios comerciales de almacenamiento de datos en tiempo real. De acuerdo con las necesidades de los usuarios de la comunidad, hemos acoplado y adaptado Flink y sus herramientas ecológicas circundantes, como ChunJun.
Los usuarios usan Flink y las herramientas ecológicas correspondientes para permitir que los datos fluyan libremente en diferentes sistemas. Por ejemplo, los datos de OceanBase o MySQL de origen aguas arriba se sincronizan con OceanBase, Kafka y otros destinos aguas abajo.
En la comunidad de OceanBase, muchos usuarios utilizan OceanBase+Flink para resolver problemas prácticos que se encuentran en la producción. Los escenarios típicos de aplicación incluyen:
Escenario 1, escritura y limpieza de datos en tiempo real, que también es el escenario más utilizado. Cuando los datos se escriben en flujo descendente, no solo es necesario garantizar el rendimiento en tiempo real de la escritura, sino que también puede haber problemas como la limpieza y conversión del formato de datos. Por lo tanto, Flink puede realizar la escritura en tiempo real. de datos a bases de datos posteriores como OceanBase, etc., y al mismo tiempo se pueden realizar acciones como la limpieza de datos durante el proceso de escritura.
Escenario 2: ampliar el flujo de datos. La combinación de varias tablas y la asociación con la tabla de dimensiones y la tabla de hechos son los escenarios más comunes. En la figura anterior, la fuente de datos comerciales generará continuamente un flujo de datos y realizará operaciones de unión con las tablas de dimensiones en OceanBase para ampliar el flujo de datos y generar una tabla grande y ancha. Finalmente, los datos se escriben en un conjunto de resultados y se almacenan en un sistema de base de datos, como OceanBase.
Escenario 3: Creación de una vista materializada. Cuando los datos comerciales se escriben continuamente en OceanBase, los datos de la tabla cambian constantemente. En este momento, al realizar algunas operaciones de consulta, como la consulta de agregación, una sola pieza de datos recién agregados activará el cálculo de la consulta. Cuando la escala de datos involucrada en la consulta es grande y los datos se actualizan con frecuencia, el rendimiento de la consulta será insatisfactorio.
Después de usar Flink, el flujo de datos se convierte en una tabla dinámica y se agrega continuamente. Almacene el conjunto de resultados generado aguas abajo, como OceanBase, etc. Los usuarios solo necesitan consultar el conjunto de resultados para obtener los datos requeridos, sin realizar operaciones de agregación cada vez, y la mejora del rendimiento es muy obvia.
Escenario 4: procesamiento secundario de datos. Con la popularidad de las soluciones distribuidas, las empresas utilizan la escalabilidad de las bases de datos distribuidas para almacenar datos sin procesar en escenarios de big data en bases de datos, como varios datos de indicadores.
Cuando es necesario reprocesar los indicadores de los datos originales, con la ayuda de la capacidad de sincronización en tiempo real de Flink, los datos del indicador se reprocesan durante el proceso de sincronización y los datos procesados se vuelven a escribir en OceanBase para uso comercial. Al mismo tiempo, los datos procesados se pueden procesar nuevamente como fuente, lo que es muy flexible de usar.
3. Práctica de OceanBase X Flink en la industria de los videojuegos
A medida que las empresas prestan cada vez más atención al valor de los datos, la frescura de los datos es crucial y las empresas deben poder observar los cambios en los datos en tiempo real. Por ejemplo, en la entrega de entrega urgente, las empresas deben comprender el estado operativo de la entrega urgente en todo el proceso, desde el pedido del usuario hasta la recepción del usuario en tiempo real, descubrir oportunamente los posibles problemas en cada enlace y resolverlos rápidamente, así como para mejorar la eficiencia operativa y la experiencia del usuario.
Durante el horario de mayor tráfico, los responsables de la toma de decisiones corporativas siempre deben prestar atención a la situación de las posiciones publicitarias populares, ajustar la ubicación de la publicidad de manera oportuna y maximizar el valor de las posiciones publicitarias.
En el campo de los grandes almacenes de datos en tiempo real, los almacenes de datos proporcionan estrategias basadas en datos para el proceso de toma de decisiones de las empresas.La arquitectura Lambda es una solución de almacén de datos anterior que utiliza dos arquitecturas, procesamiento de flujo y procesamiento por lotes, para datos Procesando. La arquitectura del almacén de datos de una empresa de juegos se muestra en la figura: el procesamiento fuera de línea se transfiere a Hive y Click House completa el análisis en tiempo real.
Hive es una herramienta de almacenamiento de datos basada en Hadoop que puede realizar la organización de datos, consultas especiales y procesamiento de análisis en conjuntos de datos almacenados en HDFS. Spark es un sistema de computación en clúster de código abierto basado en el análisis y la computación en memoria. El propósito es hacer que el análisis de datos sea más rápido. Hive+Spark se complementan entre sí. Y Spark+Click House está escrito en Click House a través de microlotes Spark, para reproducir la capacidad de análisis de Click House.
Hay tres escenarios típicos en la industria de los videojuegos:
-
Escenario 1: consulta el ID de usuario a través del número de ID. Cuando un usuario se registra, el sistema necesita usar la información del número de identificación para ir a cada plataforma y verificar si ya hay información de registro o varias identificaciones. Si ya hay información de registro, se solicita al usuario que inicie sesión.
-
Escenario 2: Comprobar el canal de publicidad a través del ID de usuario. Después de que el usuario se registra, el proveedor del canal de terceros debe recibir una devolución de llamada para saber si la atribución es correcta, por ejemplo, si el usuario registrado en este canal ha sido pirateado.
-
Escenario 3: Ver efectos publicitarios en tiempo real. Cuando el ancla del juego promociona el juego, necesita ver los datos de los clics, descargas, instalaciones, registros, creación de personajes, canales y otra información indicadora del juego en tiempo real. Correspondiente al nivel de negocio, involucra las operaciones asociadas de 7 mesas.
En los escenarios 1 y 2, se tarda 66 segundos en analizar con Click House; en el escenario 3, se tarda más de 20 minutos en completar la consulta en la solución Hive.
Combinando las características de las pruebas y la arquitectura empresarial, los desafíos actuales incluyen principalmente los siguientes cuatro aspectos:
- El rendimiento en tiempo real no es suficiente. Con la arquitectura Hive, los datos tardan 30 minutos en importarse y verse, mientras que ClickHouse también tarda un minuto.
- Consistencia insuficiente. Creo que cualquiera que haya usado la arquitectura Lambda sabe que los datos de ClickHouse y Hive a menudo "luchan", y los datos calculados por los dos son inconsistentes. Es necesario deduplicar el cálculo, pero incluso después de un procesamiento repetido, todavía hay inconsistencias en los datos. Como resultado, los datos de ClickHouse solo se pueden usar para la visualización de datos en tiempo real, y los datos de Hive se usarán para el uso final de los datos.
- La mantenibilidad es compleja. En el uso comercial, se deben desarrollar dos conjuntos de códigos para interactuar con las arquitecturas Hive y ClickHouse.
- El rendimiento de las consultas no es ideal. Entre los tres escenarios presentados anteriormente, se tarda segundos o incluso minutos en ClickHouse para los escenarios 1 y 2, y más de diez minutos para el escenario 3.
Después de introducir la solución OceanBase+Flink, los datos se escriben en OB en tiempo real a través de Flink y, al mismo tiempo, se realiza una limpieza de datos para estandarizar el formato de datos. En el Escenario 1 y el Escenario 2, los resultados se pueden devolver en milisegundos. En la escena 3, el efecto publicitario se puede ver en 1,5 segundos y la mejora del rendimiento es muy evidente.
Los beneficios de la nueva solución también son muy evidentes: en comparación con la arquitectura anterior, el rendimiento varía de minutos a segundos o incluso milisegundos, con menos componentes y una arquitectura más ligera. Un conjunto de soluciones puede cumplir con los requisitos en tiempo real de algunas empresas, con bajos costos de mantenimiento y bajos costos de transformación empresarial.
4. Perspectivas de futuro
En la implementación real de las soluciones OceanBase y Flink, encontramos que se pueden realizar algunas optimizaciones en Flink, principalmente en los siguientes tres aspectos:
- En términos de rendimiento. Actualmente, Flink es una instantánea de datos de lectura de un solo subproceso. En el futuro, las instantáneas se dividirán en múltiples segmentos de datos y se leerán simultáneamente para mejorar el rendimiento.
- En términos de consistencia. En el diseño original, para garantizar que los datos no se pierdan, primero se inician las lecturas incrementales y luego se inician las lecturas instantáneas. Al realizar operaciones ETL, puede haber problemas de redundancia de datos. En el nuevo diseño, la lectura instantánea + de datos incrementales se puede optimizar para lograr una lectura consistente.
- En cuanto a la compatibilidad. Actualmente, Flink es compatible con la versión 5.1 del conector OceanBase. Como OceanBase es compatible con mysql 8.0, Flink también deberá adaptarse al conector 8.0 en el futuro.
Dado que OceanBase+Flink se usa ampliamente en el entorno de producción, continuaremos adaptando y mejorando la solución con Flink y las herramientas ecológicas circundantes en el futuro para brindar un mejor servicio a los usuarios empresariales.