0 1-arquitectura minimalista
En términos de diseño, Doris integra el modelo de almacenamiento de datos de Google Mesa, el formato de almacenamiento ORCFile de Apache, el motor de consultas de Apache Impala y el protocolo de interacción de MySQL. Es un producto de diseño líder con tecnología avanzada y arquitectura avanzada, como se muestra en la Figura 1.
▲Figura 1 Diagrama de descomposición técnica de Doris
En términos de arquitectura, Doris tiene solo dos tipos de procesos: uno es FE , que puede entenderse como el nodo de gestión de Doris, que es el principal responsable del acceso a las solicitudes de los usuarios, el análisis de los planes de consulta, el almacenamiento de metadatos y trabajo relacionado con la gestión de clústeres, el otro es BE es el principal responsable del almacenamiento de datos y la ejecución de los planes de consulta. Ambos tipos de procesos son escalables horizontalmente. Además, Doris no depende de ningún sistema de terceros (como HDFS, Zookeeper, etc.). Este diseño de arquitectura altamente integrado reduce en gran medida los costos de operación y mantenimiento.
Los nodos FE incluyen tres roles: líder, seguidor y observador. De forma predeterminada, un clúster solo puede tener un líder y puede haber varios seguidores y observadores. Entre ellos, el Líder y el Seguidor forman un grupo de selección de Paxos, si el Líder cae, los Seguidores restantes seleccionarán automáticamente un nuevo Líder para garantizar una alta disponibilidad de escritura. Observer sincroniza los datos de Leader, pero no participa en las elecciones. Si solo se implementa un FE, el FE es el líder por defecto.
El nodo FE incluye principalmente un módulo de gestión de almacenamiento (Store Manager), un módulo de gestión de estado (State Store), un módulo de coordinación (Coordinador), un módulo de metadatos (StoreMeta) y un módulo de caché de metadatos (StoreMeta Cache). El módulo de administración de almacenamiento es responsable de administrar toda la información de los metadatos, incluida la base de datos, la información de la tabla, la información de la tableta, la información de la copia de la tableta, etc. El módulo de administración de almacenamiento también es responsable de administrar la información de autoridad del usuario (es decir, la información de autenticación del usuario y la información de autorización) y las tareas de importación de datos. El módulo de gestión de estado es responsable de gestionar la información de estado de supervivencia de todos los procesos de BE, consultar información de carga y otra información no persistente, y proporcionar interfaces de publicación y suscripción. El módulo de coordinación es responsable de recibir solicitudes de los usuarios, luego analizar declaraciones, generar planes de ejecución y programar los planes de ejecución de acuerdo con el estado actual del clúster. El módulo de metadatos es responsable de leer y escribir metadatos, y solo el Líder FE tiene este permiso. El módulo de caché de metadatos es responsable de sincronizar los metadatos para el análisis de declaraciones y la generación del plan de ejecución, principalmente los permisos de los roles de seguidor y observador.
Los nodos BE se pueden expandir infinitamente y las funciones de todos los nodos BE son iguales. Cuando el clúster es lo suficientemente grande, algunos BE fuera de línea no afectarán al clúster para proporcionar servicios. El nodo BE se compone principalmente de un motor de almacenamiento (Store Engine) y un ejecutor de consultas (Query Executor). El motor de almacenamiento es responsable de administrar los datos de la tableta local del nodo, enviar o recibir datos para formar una copia y fusionar y actualizar periódicamente varias versiones de datos para reducir el uso del almacenamiento. El motor de almacenamiento también es responsable de recibir los requisitos de lectura de datos y los requisitos de importación de datos por lotes de los ejecutores de consultas. Cuando se ejecuta una consulta en un clúster MPP, se dividirá en un árbol de ejecución similar a un árbol. La ejecución de este árbol está coordinada por el Coordinador. Los nodos hoja del árbol también se denominan fragmentos del plan (PlanFragment), y cada PlanFragment se asigna a un nodo BE. El ejecutor de consultas a ejecutar, este es el rol del módulo ejecutor de consultas.
0 2 - Fácil de usar
Doris no solo es simple en estructura, sino también muy simple en desarrollo y uso. Para una base de datos OLAP, el rendimiento no es la totalidad de la base de datos, y la facilidad de uso es la clave para decidir si continuar usándola. Doris siempre ha tomado la facilidad de uso del usuario como punto de partida desde el principio del diseño del sistema.
Desde la perspectiva de todo el ciclo de análisis de datos, generalmente se puede resumir simplemente en cuatro aspectos, desde el modelado de datos→importación de datos→análisis de usuarios→uso continuo y mantenimiento y actualizaciones, la facilidad de uso de Doris está en todas partes.
En términos de modelado de datos, Doris admite tres modelos: agregado, único y duplicado, que pueden cumplir con varios escenarios de aplicación en el campo OLAP. Al mismo tiempo, la declaración de creación de tablas de Doris solo agrega algunas características de los sistemas distribuidos en comparación con MySQL, como claves de distribución y números de depósito. Los usuarios que tienen experiencia en el uso de bases de datos distribuidas son muy fáciles de entender y operar.
En términos de importación de datos, Doris ofrece una variedad de soluciones de importación de datos (como se muestra en la Figura 2), que se pueden seleccionar para diferentes fuentes de datos, al tiempo que brinda garantías de atomicidad durante el proceso . Ya sea que use Broker Load para la importación por lotes o use la declaración INSERT para la importación única, es una operación de transacción completa. La transacción de importación puede garantizar que los datos de un lote surtan efecto de forma atómica y que no se escriban datos parciales.
▲Figura 2 Compatibilidad con la importación de datos de Doris
Al mismo tiempo, cada trabajo de importación generará una etiqueta, que se utiliza para distinguir de forma única una tarea de importación en la base de datos. El usuario puede especificar la etiqueta y el sistema también generará automáticamente algunas funciones de importación. La etiqueta se utiliza para garantizar que el trabajo de importación correspondiente solo se pueda importar correctamente una vez. Cuando se vuelva a utilizar una etiqueta importada correctamente, se rechazará y se informará de la etiqueta de error ya utilizada. A través de este mecanismo, el lado del consumo de datos puede realizar la semántica At-Most-Once. Si se combina con la semántica Al menos una vez del sistema ascendente, se puede realizar la semántica Exactamente una vez de la importación de datos de extremo a extremo. El proceso de importación de datos se muestra en la Figura 3.
▲Figura 3 Proceso de importación de datos de Doris
En términos de desarrollo de SQL, Doris admite el lenguaje SQL estándar y es compatible con MySQL en dialecto. Ya sea que se trate de operaciones simples de agregación, clasificación y filtrado de una sola tabla, o asociaciones complejas de múltiples tablas, subconsultas, funciones de ventana, etc., Doris se puede completar fácilmente a través de SQL, lo que reduce en gran medida los costos de migración y uso del usuario. Las consultas ad hoc de alto rendimiento, como Adhoc y los escenarios ETL en la biblioteca, también son puntos fuertes de Doris. Doris también puede admitir sintaxis SQL compleja, incluidas funciones de sintaxis avanzada como Grouping Set, y también puede personalizar y expandir funciones a través de UDF o UDAF. Para terabytes de datos, Doris puede reemplazar parcialmente las funciones de los sistemas fuera de línea como Hive, lo que permite a los usuarios cumplir con todos los requisitos en una base de datos.
En términos de herramientas, Doris ha implementado compatibilidad con el protocolo MySQL en el módulo FE , lo que es conveniente para que los usuarios utilicen clientes MySQL estándar o bibliotecas de clases en varios idiomas para conectarse, y es compatible con varias herramientas muy bien. En términos de desarrollo de bases de datos [3] [4], podemos utilizar sin problemas las principales herramientas de desarrollo como DBeaver, DataGrip y Navicat; en términos de aplicaciones de programación [5] [6], Doris es totalmente compatible con las interfaces JDBC y ODBC de MySQL, y puede admitir C, Python, Java, Shell y otros lenguajes de desarrollo; en términos de aplicaciones de BI, Doris admite varios software de BI ágiles, como Fanruan BI, Guanyuan BI, Yonghong BI, Tableau; en términos de programación ETL, Doris admite Kettle, DolphinScheduler y otro software convencional.
En términos de confiabilidad del clúster, los metadatos de Doris usan el modo de almacenamiento en memoria + punto de control + archivo de registro espejo , y usan el protocolo BTBJE (similar a Raft) para lograr una alta disponibilidad y alta confiabilidad de los metadatos. Doris administra internamente copias múltiples y reparación automática de datos para garantizar una alta disponibilidad y confiabilidad de los datos. Cuando algunos servidores se caen, el clúster aún puede funcionar normalmente y los datos no se perderán. La implementación de Doris no tiene dependencias externas y solo necesita implementar módulos BE y FE para construir un clúster. Doris admite el cambio en línea del modo de tabla (agregar y restar columnas, crear un resumen), lo que no afectará el servicio actual y no bloqueará las operaciones de lectura y escritura, ya que dichas operaciones se realizan de forma asíncrona.
En términos de expansión y contracción de clústeres, con base en su propio marco de administración distribuida, Doris puede administrar automáticamente la distribución, reparación y balanceo de las copias de datos. Por ejemplo, si la copia está dañada, Doris la detectará y reparará automáticamente. Para la expansión y contracción del nodo, solo se necesita un comando SQL para completar, y Doris realizará automáticamente el equilibrio de fragmentación de datos.Todo el proceso no afecta los servicios del sistema en absoluto y no requiere ninguna operación adicional por parte del personal de operación y mantenimiento.
En cuanto a la actualización del clúster, el método de actualización de Doris es extremadamente simple, solo necesita reemplazar el programa binario y reiniciar el clúster de forma continua. En términos de diseño, Doris es totalmente compatible con versiones posteriores, por lo que también es posible verificar y probar nuevas versiones a través de actualizaciones en escala de grises. Algunas de las funciones de reintento de errores y enrutamiento de errores de Doris también reducen en gran medida el impacto de los errores que ocurren durante el proceso de actualización en el negocio.
0 3 - Rico en características
Doris proporciona un conjunto muy rico de funciones para ayudar a las empresas a adaptarse a diferentes escenarios de aplicaciones. A continuación se destacan algunas de las funciones características de Doris.
La primera es la función de poda de partición y cubeta . Doris admite dos niveles de división de datos: el primer nivel es Partición, que admite la división de Rango y Lista. La segunda capa es la agrupación de cubos, que divide los datos horizontalmente a través de Hash, y las tabletas de fragmentación de datos se dispersan uniformemente en el clúster. En la Figura 4 se muestra un ejemplo de la distribución de datos de Doris.
▲Figura 4 Ejemplo de distribución de datos de Doris
Mediante el uso de la función de eliminación de depósitos, Doris puede corregir consultas en una cantidad muy pequeña de fragmentos, lo que reduce significativamente el consumo de recursos del sistema con una sola consulta y mejora la capacidad general de consultas simultáneas del clúster. En escenarios de consulta de alta simultaneidad, un solo nodo Doris puede admitir solicitudes de consulta de miles de QPS.
La segunda es una función de caché razonable . Doris también es compatible con el almacenamiento en caché de consultas a nivel de SQL y de partición. Entre ellos, el caché de nivel SQL usa el valor Hash de la instrucción SQL como clave para almacenar en caché directamente los resultados SQL, lo cual es muy adecuado para escenarios donde la frecuencia de actualización no es alta pero la consulta es muy frecuente. La caché a nivel de partición almacenará en caché de manera inteligente los datos de resultados de diferentes particiones en el resultado de SQL, y las consultas posteriores pueden usar los datos de la partición almacenada en caché más los datos de consulta en tiempo real de la nueva partición para obtener el resultado final, reduciendo así el costo en tiempo real de los datos duplicados Requisitos de consulta para reducir el consumo de recursos del sistema.
Una vez más , Doris admite el tipo de datos de mapa de bits . Este tipo de datos utiliza mapas de bits para almacenar datos enteros y puede realizar algunas operaciones de recopilación a través de mapas de bits. El mapa de bits se puede aplicar a escenarios de deduplicación precisa de alta cardinalidad. El algoritmo tradicional de deduplicación en tiempo real necesita construir una tabla Hash en la memoria para deduplicar los datos.Cuando la cardinalidad es muy alta, ocupará una gran cantidad de memoria. Con Bitmap, el tipo numérico se puede convertir en 0 y 1 en el mapa de bits, lo que reduce en gran medida la sobrecarga de memoria, y para el cálculo de deduplicación, solo es necesario calcular el número 1 después de la intersección de varios mapas de bits, para lograr Realice cálculos rápidos de deduplicación exacta de alto radix con una sobrecarga de memoria limitada.
En el escenario de retrato de usuario, el mapa de bits se usa para almacenar ID de usuario, y los paquetes de multitud con diferentes combinaciones de etiquetas se pueden obtener rápidamente a través de operaciones de conjuntos de mapas de bits. Al mismo tiempo, Doris también tiene muchas funciones integradas relacionadas con Bitmap, que se utilizan para calcular el embudo, la retención, etc. Por ejemplo, a través de la función intersect_count(), la retención de usuarios se puede calcular fácilmente.
Y finalmente la vista materializada . La vista materializada es también una de las características principales de Doris . La vista materializada consiste en almacenar el conjunto de datos precalculados (de acuerdo con la declaración SELECT definida) en una tabla de vista que es transparente para el usuario y tiene datos reales. La vista materializada es principalmente para satisfacer las necesidades de los usuarios que no solo pueden analizar los datos detallados originales en cualquier dimensión, sino también analizar y consultar rápidamente la dimensión fija y analizar los datos detallados y agregados desde una perspectiva unificada.
En Doris, los usuarios pueden usar el modelo de datos detallados para almacenar datos detallados y luego seleccionar dimensiones e indicadores arbitrarios para crear vistas agregadas de los datos detallados, como SUM, MIN, MAX, COUNT, etc. Doris se asegurará de que los datos en el cronograma y la vista materializada sean completamente consistentes. Si los datos de la tabla física se importan o eliminan, la vista materializada se actualizará automáticamente para garantizar la coherencia de los datos entre la tabla original y la tabla de la vista materializada. Al mismo tiempo, la vista materializada es transparente para las consultas de los usuarios y Doris buscará automáticamente la vista materializada más adecuada para la consulta de acuerdo con el patrón en la declaración de consulta. A través de la función de vista materializada, los usuarios pueden unificar los modelos de detalle y agregación en una tabla y acelerar la respuesta de consulta de ciertos modos fijos.
Doris también admite actualizaciones de datos basadas en claves principales. A través del modelo de datos únicos, los usuarios pueden actualizar los datos en función de la clave principal. A nivel de implementación, Doris usa el método Merge-on-Read para proporcionar datos actualizados. Además, los usuarios también pueden usar el método de agregación REPLACE_IF_NOT_NULL para satisfacer las necesidades de actualizaciones de columnas parciales. Para el modelo de datos Unique, Doris también admite operaciones de actualización amigables.
Basado en el modelo Unique, Doris también utiliza funciones como Eliminación marcada y Columna de secuencia para realizar la operación de sincronización de los datos actualizados de la base de datos de transacciones ascendente, y no solo puede garantizar la atomicidad de las transacciones, sino también el orden de sincronización de datos.
0 4-Código abierto y abierto
Otra característica particularmente importante de Doris es que es completamente de código abierto y abierto . Como proyecto de la Fundación Apache, Apache Doris cumple con la Licencia Apache 2.0. Apache License 2.0, como el protocolo de código abierto más convencional, es reconocido por OSI como "las siguientes licencias aprobadas por OSI son populares, ampliamente utilizadas o tienen comunidades sólidas".
Para conocer el contenido específico de Apache License 2.0, puede consultarlo en el sitio web oficial de Apache. En resumen, la distribución es completamente gratuita, se permite modificar el código del proyecto y se permite volver a publicarlo como código abierto o software comercial. Una vez que la autorización es válida de forma permanente, se requiere un acuerdo con el código original y una declaración de patente. requerido en el código modificado o el código derivado del código fuente esperar. Este es un acuerdo extremadamente amigable para cualquier empresa comercial y usuario de código abierto.