En la aplicación tradicional de datos empresariales, las empresas utilizan varios sistemas y los datos se encuentran dispersos en varios dispositivos de almacenamiento. Los requisitos de análisis de datos a menudo son de bases de datos cruzadas, y el análisis de los datos que ingresan al lago o al almacén puede causar problemas de seguridad o afectar el rendimiento. del sistema empresarial. Las empresas necesitan un método de integración de datos que sea flexible, rápido y con bajos costos de operación y mantenimiento, por lo que existe una arquitectura de federación de datos. Este artículo presenta la arquitectura de la federación de datos.
— Descripción general de la federación de datos —
En la aplicación de datos empresariales tradicional, a menudo surge este dilema: la empresa utiliza múltiples sistemas, los datos están dispersos en varios almacenes de datos y los requisitos de análisis de datos a menudo son de bases de datos cruzadas.Hay dos formas de resolver dichos requisitos. Una es hacer la integración de datos (ETL) primero para integrar los datos en lagos de datos o almacenes de datos antes del análisis.Esto generalmente es adecuado para escenarios comerciales donde los requisitos son relativamente ciertos y el sistema de stock se puede migrar a una nueva plataforma de datos. Para otras empresas, debido a las características por etapas de la construcción de su plataforma, puede haber situaciones en las que la demanda cambie rápidamente, o el sistema de stock no se pueda migrar directamente debido a varias razones, y la solución basada en ETL en el lago para re- El análisis puede tener una respuesta comercial lenta. Debido a las desventajas de la baja flexibilidad y el proceso complejo, las empresas necesitan un método de integración de datos más flexible y rápido, que es la arquitectura de federación de datos.
La federación de datos resuelve el problema de las "islas de datos" y evita los problemas del largo proceso ETL tradicional y los altos costos de desarrollo, operación y mantenimiento. Se puede aplicar a la recopilación de datos que requiere flexibilidad y rendimiento en tiempo real, o donde hay datos heterogéneos. Escenas de procesamiento de origen.
- Base de datos operativa virtual (ODS)
A través del almacenamiento virtual de datos operativos (ODS), construya una vista de integración de datos operativos, los cambios de datos se reflejarán rápidamente en ODS, y las fuentes de datos federadas se pueden aumentar o disminuir de manera flexible de acuerdo con los requisitos de análisis específicos, por lo que puede cumplir con algunos requisitos ligeros Cuantitativos, análisis de datos a corto plazo o aplicaciones de panel flexibles en tiempo real.
- Crear un área de preparación de datos
Al usar la federación de datos para crear un área de preparación de datos, se pueden combinar instantáneas para una gran cantidad de datos que ingresan al almacén de datos desde el sistema de producción, lo que reduce en gran medida la interferencia de la replicación de datos en el sistema de producción. El almacenamiento en tiempo real de cambios de datos en el área de transferencia de datos puede registrar información completa de cambios de datos.
- Expansión del almacén de datos
Hay problemas después de que la empresa implementa el almacén de datos: por un lado, es poco probable que toda la empresa use un único almacén de datos; por otro lado, la empresa todavía tiene una gran cantidad de datos que no se han almacenado en ningún almacén de datos, y necesita construir una perspectiva unificada. La federación de datos y la informática federada pueden proporcionar una perspectiva unificada de todos los almacenes de datos empresariales y datos dispersos sin convertir formatos ni mover datos, lo que reduce el costo del movimiento y la conversión de datos.
- Migración de plataforma heterogénea
El uso de computación federada en el proceso de migración de plataformas heterogéneas puede hacer que el proceso de migración sea más fluido sin considerar problemas como la migración de datos y la incompatibilidad de sintaxis de plataformas heterogéneas. Cambie la configuración de la fuente de datos sin afectar las nuevas aplicaciones.
- Análisis de datos heterogéneos
Las empresas pueden utilizar las capacidades de la federación de datos para lograr análisis de datos estructurados cruzados, no estructurados o semiestructurados. Aunque la federación de datos y la computación federada tienen un gran valor para optimizar la adquisición de datos, la migración de plataformas, etc., no son omnipotentes: por un lado, debido a que se puede implementar rápidamente una vista integrada de los datos, muchas empresas ignoran el gobierno de datos, lo que resulta en la proceso de federación Por otro lado, dado que la federación de datos no prediseña la arquitectura de datos para el negocio, es mejor proporcionar lagos de datos, almacenes de datos, etc. para el rendimiento de los requisitos de datos de formato fijo que se utilizan con frecuencia. Por lo tanto, métodos como el gobierno de datos y ETL no pueden abandonarse por completo, sino que deben combinarse y aplicarse juntos para resolver problemas más amplios de gestión de datos dentro de la empresa. La federación de datos resuelve más los requisitos de datos que aún evolucionan con frecuencia o los requisitos de desarrollo de datos empresariales en evolución, como los escenarios de desarrollo Adhoc.
— Breve análisis de la arquitectura de la federación de datos —
Desde la perspectiva de la arquitectura técnica, la tecnología de federación de datos proporciona una vista de datos unificada al agregar un motor informático federado a varias fuentes de datos existentes y ayuda a los desarrolladores a consultar y analizar datos heterogéneos de manera uniforme a través de motores informáticos federados. los desarrolladores pueden acceder y analizar datos homogéneos o heterogéneos en un sistema sin tener en cuenta cuestiones como la ubicación física de los datos, la estructura de los datos, la interfaz de operación y la capacidad de almacenamiento. La arquitectura de federación de datos puede aportar varias ventajas arquitectónicas clave para la gestión de datos empresariales, entre las que se incluyen principalmente:
- Integración de datos virtualizados : en comparación con ETL tradicional, la federación de datos solo realiza una integración virtual, que puede integrar una gran cantidad de datos más rápido y a un costo menor , mejorar la velocidad de integración de datos y explorar rápidamente algunos servicios de datos innovadores;
- Para algunos sistemas de acciones complejos, puede proporcionar capacidades de análisis de datos de bases de datos cruzadas mientras mantiene el sistema sin cambios tanto como sea posible , para proteger la inversión existente de la empresa;
- Es conveniente para los desarrolladores encontrar y usar los datos de manera flexible : los usuarios no necesitan percibir la ubicación y la estructura de las fuentes de datos, no es necesario cambiar el sistema de fuentes de datos y se mejora la flexibilidad del procesamiento de datos;
- Se puede lograr la gestión y el control de seguridad de datos unificados : debido a que se integra a través de vistas virtuales en lugar de copiar, y el control de seguridad unificado se realiza en la plataforma de federación de datos, puede lograr un control de seguridad de exportación de datos unificado y reducir el riesgo de fuga de datos causada por copiar datos, especialmente adecuado para analizar algunos sistemas comerciales que no son adecuados para importar datos al lago de datos, a fin de garantizar la seguridad de los datos estáticos y dinámicos;
- Elimine el movimiento de datos innecesario : para algunos datos que se usan con poca frecuencia, si se usa la arquitectura de federación de datos, esta parte de los datos no necesita integrarse en el lago de datos todos los días. En su lugar, el análisis de datos se realiza cuando hay una demanda de análisis real. , que reduce el movimiento de datos innecesario;
- Aprovisionamiento ágil de servicios de datos y función de portal : con la función de federación de datos, las empresas pueden desarrollar aún más un portal de servicios de datos basado en ella, proporcionando herramientas de desarrollo y herramientas de servicio para permitir a los usuarios utilizar los datos de manera más flexible.
El diagrama de la arquitectura técnica de la federación de datos se muestra arriba. El punto clave es implementar un motor de consulta SQL unificado, que puede federar múltiples fuentes de datos autónomas homogéneas o heterogéneas. Los usuarios pueden consultar datos libremente en cualquier lugar del sistema federado sin tener que preocuparse por el almacenamiento. ubicación de los datos, el tipo de lenguaje SQL o la capacidad de almacenamiento del sistema fuente de datos real. Como se muestra en la figura anterior, la arquitectura debe realizar la unificación de cuatro aspectos para realizar las capacidades básicas anteriores, incluida la gestión unificada de metadatos, la interfaz unificada de procesamiento de consultas, las herramientas unificadas de desarrollo y operación y mantenimiento, y la gestión unificada de la seguridad.
- Gestión unificada de metadatos
El módulo de gestión de metadatos debe crear una visión general abstracta de cada fuente de datos homogénea y heterogénea, y proporcionar una gestión unificada de la conexión de la fuente de datos y la gestión de la información de metadatos. La capa de desarrollo empresarial posterior solo necesita utilizar este módulo de gestión de metadatos centralizado para obtener datos de diferentes Bases de datos Información de metadatos sin tener que gestionar diferentes detalles de conexión para cada una de las diferentes bases de datos.
- Módulo de conexión de fuente de datos
A través de la plataforma de federación de datos, los desarrolladores pueden construir conexiones virtuales a través de instancias de bases de datos para lograr acceso entre bases de datos en la base de datos actual, generalmente usando extensiones de SQL similares a DBLink. Esta capa es responsable de administrar el acceso a las fuentes de datos. Admite tanto la conexión de fuentes de datos tradicionales como la conexión de plataformas de big data. Está mejor diseñada para admitir acceso a datos estructurados y no estructurados. El ejemplo de sintaxis de DBLink es el siguiente: Los desarrolladores subsiguientes pueden usar directamente el nombre de la tabla en dblink para acceder a tablas de datos en diferentes fuentes de datos e incluso acceder a varias tablas en un SQL.
| CREAR ENLACE DE BASE DE DATOS <nombre_enlace> CONECTAR A <nombre_usuario_jdbc> IDENTIFICADO POR '<contraseña_jdbc>' UTILIZANDO '<URL_jdbc>' con '<controlador_jdbc>'; CREAR TABLA EXTERNA <nombre_tabla> (col_cadena ficticia) ALMACENADA COMO DBLINK CON DBLINK <nombre_enlace> PROPIEDADES ('dblink.table.name'=<ref_table_name>); |
- Módulo de gestión de metainformación
Dado que los metadatos de cada base de datos cambian continuamente con la operación del negocio, el módulo de federación de datos también necesita obtener cambios de datos de manera oportuna, como la adición o eliminación de campos de tabla o cambios de tipo, etc. Por lo tanto, la gestión de metadatos El módulo es responsable de proporcionar esta función, que debe obtenerse de Cada fuente de datos obtiene metadatos y los administra de forma centralizada, y obtiene y mantiene los metadatos más recientes a través de consultas de fuentes de datos, lo que garantiza la coherencia de los metadatos entre plataformas Desempeña un papel de apoyo clave en el ciclo de vida
- Interfaz de procesamiento de consultas unificada
Este módulo proporciona un portal de servicios para los analistas de datos, que incluye principalmente el procesamiento de datos multiplataforma con declaraciones SQL estándar unificadas y algunas funciones de administración del portal de datos que las empresas pueden proporcionar en función de él, como la revisión de SQL, la aplicación de datos, etc. Dado que implica el procesamiento unificado de múltiples bases de datos, este módulo tiene requisitos técnicos relativamente altos Además de ser compatible con los tipos de datos de múltiples bases de datos y las diferencias en los dialectos de SQL, el rendimiento de SQL es otro elemento técnico muy crítico.
- Capa de motor SQL de consultas federadas
Como capa de análisis de sintaxis unificada, analiza las instrucciones SQL. Su núcleo es la unidad de compilador, optimizador y gestión de transacciones de SQL, que garantiza brindar a los desarrolladores una mejor experiencia de base de datos, sin necesidad de un desarrollo comercial basado en diferentes plataformas subyacentes y API diferenciadas, y será generado por el optimizador. El mejor plan de ejecución. finalmente se empuja a la capa del motor de cómputo. Para los desarrolladores, la capa del motor SQL debe ser compatible con las interfaces JDBC/ODBC/REST estándar.
- Capa de motor informático de consultas federadas
Algunas operaciones de SQL necesitarán operar datos en múltiples bases de datos y realizar análisis de correlación. Por lo tanto, la capa del motor informático debe poder cargar datos de diferentes bases de datos en el motor y realizar varias operaciones de datos. Esto requiere que el motor informático se base en computación distribuida Al mismo tiempo, es necesario resolver de manera efectiva las diferencias en los tipos de datos de cada base de datos. Por ejemplo, en diferentes bases de datos, varchar y otros tipos se procesarán de manera diferente si hay espacios en los lados izquierdo y derecho de la cadena, y el comportamiento de la función de recorte también será ligeramente diferente.Además, las definiciones de tipo de Decimal /Numeric en algunas bases de datos también son diferentes, y las diferencias en este tipo de sistemas serán diferentes. Aporta una complejidad de procesamiento muy grande y también es una capacidad central del motor informático. Otra característica importante está relacionada con la optimización del rendimiento.Dado que se involucran múltiples bases de datos remotas, a diferencia de las bases de datos tradicionales, el motor de computación federado necesita admitir dos optimizaciones típicas de SQL: el almacenamiento en caché de resultados de datos y la transferencia informática a bases de datos remotas.
- Capa de caché de resultados de datos
El motor informático federado cuenta automáticamente la frecuencia de consulta de los conjuntos de resultados. Para conjuntos de resultados calientes y conjuntos de datos de caché intermedios, elige almacenar en caché o sincronizar los conjuntos de resultados de la base de datos subyacente con la plataforma informática federada y selecciona la mejor ruta de consulta durante el proceso de consulta. para optimizar el rendimiento de las consultas.
Tomemos la consulta SQL anterior como ejemplo. Todos sabemos que la base de datos MySQL no es buena para el análisis estadístico de datos, y la operación de agregación para la tabla de elementos de línea con 10 millones de registros tarda unos 200 segundos. Sin embargo, si se usa el motor de computación federado, el motor de computación encuentra que la tabla ha sido analizada estadísticamente varias veces en función de múltiples registros del historial de consultas, y conserva los datos de MySQL en st_lineitem. Al consultar tpch1.lineitem de MySQL más adelante, utiliza st_lineitem. Dado que el motor informático distribuido es bueno en el análisis estadístico, las consultas posteriores pasan por el motor informático federado, y el rendimiento también mejora en un orden de magnitud, y el consumo de recursos de la base de datos MySQL original también se reduce considerablemente.
- Empuje de datos a la base de datos remota
En otros escenarios de análisis estadístico ad-hoc, si todos los datos de la base de datos de origen se cargan en el motor informático federado, puede haber una gran cantidad de E/S de datos y de E/S de red, lo que provoca un rendimiento lento. Si parte del plan de ejecución de este tipo de consulta SQL se puede ejecutar directamente en la base de datos remota, el motor de cálculo puede elegir empujar hacia abajo al operador en la base de datos subyacente al formular el plan de ejecución, y cada base de datos remota completará el cálculo básico. y, por último, ejecute el resultado Summarize en la capa informática federada para un cálculo unificado a fin de optimizar el rendimiento de las consultas.
Tomemos un ejemplo simple: si es necesario encontrar el número de empleados cuyo número de empleado es menor que un valor dado de las bases de datos MySQL y Oracle, si no hay optimización de agregación y pushdown, luego de que el desarrollador envíe el SQL estadístico, el El motor informático federado necesita recuperar En Oracle y Oracle, la cantidad total de decenas de millones de datos se carga en el motor informático para el cálculo. Este proceso de carga puede tardar cientos de segundos (principalmente limitado por la cantidad de subprocesos simultáneos que la base de datos se abre al motor informático federado). Sin embargo, si el motor de cómputo admite el cómputo push-down a la base de datos remota, se involucra muy poca migración de datos y el rendimiento mejora de cientos a decenas de segundos.
- Gestión de seguridad unificada
Dado que la federación de datos abrirá cada base de datos a los usuarios comerciales, se expondrán más riesgos de datos cuando los datos estén abiertos. Por lo tanto, necesitamos funciones de protección de seguridad de datos más detalladas para proteger la autenticación, auditoría y autorización de datos y proporcionar cifrado de datos. , desensibilización y clasificación de confidencialidad y otras funciones para garantizar la seguridad de los datos durante el almacenamiento, la transmisión y el procesamiento.
- Gestión de autoridad unificada
La capa de seguridad de la federación de datos debe proporcionar un módulo de usuario unificado para la administración de permisos relacionados y el uso autorizado de múltiples bases de datos. Brindamos control de permisos de fuentes de datos federados con la misma experiencia que el control de permisos a nivel de tabla de base de datos a través del mapeo de metainformación (creación externa) , y proporciona funciones de control de autoridad de nivel de columna y fila de nivel de usuario de granularidad fina. De esta manera, se puede aproximar que las restricciones de consulta en la tabla original -> vista se proporcionan durante la compilación para garantizar que los datos confidenciales no se filtren durante el proceso de cálculo.
- Auditoría dinámica de SQL
La auditoría SQL significa que cuando el SQL comercial se envía a la plataforma, la plataforma puede bloquear u optimizar consultas confidenciales (como consultas equivalentes de campos confidenciales) de acuerdo con las dimensiones del usuario o el comportamiento que envió el negocio, y de acuerdo con el integrado. o reglas de auditoría personalizadas Trato con sugerencias. Para facilitar la comprensión, enumeramos algunas reglas típicas de revisión de DML y las descripciones de las reglas correspondientes, como se muestra en la siguiente tabla:
| Descripción de la regla de auditoría | Expresión lógica de las reglas de auditoría |
| Las declaraciones DML que contienen Eliminar y Actualizar deben tener una condición Dónde | (sql.type = 'ELIMINAR' o sql.type = 'ACTUALIZAR') y !sql.hasWhere |
| Tabla ES de consulta de tabla única y tabla Hyperbase, si no hay declaración condicional ni agregación, debe solicitar a SQL que agregue una declaración de límite | sql.type = 'select' y sql.joinNum = 0 y (sql.from.tableType = 'es' o sql.from.tableType = 'hyperbase') y sql.where = null y !sql.hasUdaf |
| Demasiadas veces de UNION ALL en la instrucción SQL | (sql.type = 'select' y sql.unionallNum > 100) o (sql.type = 'insert' y sql.select.unionallNum > 100) |
| Hay demasiados JOIN en la instrucción SQL | (sql.type = 'select' y sql.joinNum > 100) o (sql.type = 'insert' y sql.select.joinNum > 100) |
| No elimine objetos de datos | sql.type = 'dropdatabase' o sql.type = 'droptable' |
| prohibir insertar sobrescribir | sql.type = 'insertar' y sql.isOverwrite |
| Verifique la declaración de creación de tablas, multiplique el número de particiones por el número de cubos y el número no puede exceder el límite; si el número excede el límite, le pedirá que ajuste y optimice | sql.type = 'createtable' y sql.partNum * sql.bucketNum > 3 |
| Al crear una tabla, el nombre de la tabla no debe usar otros formatos de datos excepto letras, números y guiones bajos. | sql.type = 'createtable' y !(sql.tableName ~ '^[a-zA-Z0-9_]+$') |
Con la apertura de los negocios, las grandes empresas tienen una demanda relativamente grande de auditoría de SQL. Muchas empresas tienen sus propias plataformas de auditoría y apertura de SQL, y la comunidad de código abierto también tiene algunas soluciones específicas. La arquitectura general puede hacer referencia a la arquitectura de la figura a continuación, con la definición más regular en el lenguaje DSL y el analizador correspondiente para completar las operaciones de auditoría de SQL relevantes (como sugerencias de optimización o bloqueo, etc.).
- Desensibilización dinámica de datos confidenciales
A diferencia de los permisos de nivel de fila y columna de las tablas de la base de datos, la desensibilización dinámica de los datos confidenciales debe garantizar la seguridad del contenido de los datos, que es más una protección de seguridad de datos de nivel empresarial junto con el control de permisos. Cabe señalar que, para garantizar la exactitud de los resultados, se utilizan cálculos de datos reales en la fase de cálculo de consultas y solo se realiza una desensibilización dinámica durante la salida para garantizar que no se filtren datos confidenciales. Para garantizar la eficacia de la desensibilización de datos, el motor de federación de datos debe mantener una tabla global y un gráfico de linaje de campos, de modo que la función de transmisión de reglas confidenciales globales pueda mejorarse en función del linaje de datos, de modo que se puedan crear tablas de datos más confidenciales. identificados, y estas tablas proporcionan identificación y desensibilización automática configurable de datos confidenciales.
- Gestión unificada de operaciones y mantenimiento
Además del soporte de la infraestructura, la implementación de la computación federada también requiere el soporte de herramientas de desarrollo de datos de nivel superior y coopera con la federación de datos para realizar el proceso completo desde la adquisición de datos, el procesamiento y la realización de valor. también se debe respaldar la seguridad de los datos en todas las fuentes de datos. Las herramientas de gestión de desarrollo y operación y mantenimiento generalmente incluyen plataformas de herramientas de desarrollo, gestión y operación y mantenimiento de datos, lo que permite a las empresas utilizar la computación federada de manera más eficiente para construir una capa de servicio de datos internos y una capa de valor comercial de datos.
— Presto与Trino —
Presto (o PrestoDB) es un motor de consulta SQL distribuido de código abierto diseñado desde cero para consultas analíticas rápidas contra datos de cualquier tamaño. Admite fuentes de datos no relacionales como Hadoop Distributed File System (HDFS), Amazon S3, Cassandra, MongoDB y HBase, y fuentes de datos relacionales como MySQL, PostgreSQL, Amazon Redshift, Microsoft SQL Server y Teradata. Presto puede consultar datos donde están almacenados sin mover los datos a un sistema de análisis separado. La ejecución de consultas se ejecuta en paralelo en una arquitectura puramente basada en memoria, y la mayoría de los resultados se devuelven en segundos. Presto fue originalmente un proyecto para ejecutar consultas analíticas interactivas en el almacén de datos de Facebook, y el almacenamiento de datos subyacente se basa en clústeres de HDFS. Antes de crear Presto, Facebook usaba Apache Hive, que se creó y lanzó en 2008. Sin embargo, debido al aumento de la carga comercial y la necesidad de análisis interactivo, Hive no puede cumplir con el alto rendimiento requerido para las consultas interactivas. En 2012, el grupo de infraestructura de datos de Facebook creó Presto, un sistema de consulta interactivo que puede ejecutarse rápidamente a escala de petabytes. Hoy, Presto se ha convertido en una opción popular para consultas interactivas sobre Hadoop, con numerosas contribuciones de Facebook y otras organizaciones. La versión de Facebook de Presto se trata más de resolver las necesidades internas de las empresas, también conocida como Presto DB. Más tarde, varias personas de Presto decidieron crear una rama de Presto más general, denominada Presto SQL, y el número de versión se divide por xxx, como la versión 345. Esta versión de código abierto también es una versión más común. Hace algún tiempo, para distinguirlo mejor de Presto de Facebook, Presto SQL cambió su nombre a Trino, que es la historia del proyecto Trino.
Tanto Presto como Trino son solo motores de computación distribuidos sin la capacidad de almacenar datos.Además, la comunidad ha realizado muchas adaptaciones de conectores de bases de datos, por lo que son motores más adecuados para consultas de federación de datos en soluciones de código abierto. En Trino, el núcleo de la separación de almacenamiento y computación es la arquitectura basada en conectores. El conector proporciona a Trino una interfaz para acceder a fuentes de datos arbitrarias. Como se muestra en la Figura 2, cada conector proporciona una abstracción basada en tablas del origen de datos subyacente. Siempre que los datos se puedan representar en tablas, columnas y filas con los tipos de datos disponibles para Trino, se puede crear un conector y el motor de consultas puede usar los datos para el procesamiento de consultas. Los conectores admitidos actualmente incluyen: Hive, Iceberg, MySQL, PostgreSQL, Oracle, SQL Server, ClickHouse, MongoDB, etc.
Como se presentó en el capítulo anterior, un motor de computación unificado es el núcleo clave del sistema de federación de datos. Cómo proporcionar consultas Adhoc flexibles y tener un buen rendimiento también es un objetivo de diseño importante de Presto. En términos de arquitectura física, Presto se divide principalmente en Coordinador y Trabajador. El Coordinador es principalmente responsable de compilar tareas de SQL y enviar tareas de cálculo a Trabajadores, mientras que el Trabajador es principalmente responsable de extraer datos del almacenamiento de datos remoto y realizar los cálculos de datos correspondientes. Dado que Presto está desarrollado en base al lenguaje Java, la eficiencia de ejecución de la JVM no es tan buena como la del lenguaje subyacente. Para solucionar el problema de rendimiento causado por esto, Presto también utiliza la tecnología de generación de código (Code generation) para generar Código de bytes ejecutado directamente por el motor subyacente para mejorar el rendimiento del análisis.
Presto utiliza el cálculo de datos basado en la memoria en lugar del disco en la informática, es decir, los datos en el proceso de cálculo de datos se almacenan principalmente en la memoria caché. Debido al inevitable problema de expansión de la memoria en el proceso de cálculo, puede provocar que el proceso Worker se bloquee, por lo que la gestión de la memoria es una tecnología muy importante en Presto. Presto divide toda la memoria en tres grupos de memoria, a saber, Grupo del sistema, Grupo reservado y Grupo general. El grupo del sistema está reservado para uso del sistema. Por ejemplo, cuando se transfieren datos entre máquinas, los búferes se mantendrán en la memoria. Esta parte de la memoria se monta con el nombre de sistema. De forma predeterminada, el 40 % del espacio de memoria está reservado para el sistema. usar. El grupo reservado y el grupo general se utilizan para asignar memoria de tiempo de ejecución de consultas. La mayoría de las consultas utilizan el grupo general. El espacio del Pool reservado es equivalente al espacio máximo utilizado por una consulta que se ejecuta en una máquina, y el valor predeterminado es el 10 % del espacio. Otra capacidad de soporte central para el análisis federado de planes de ejecución distribuida. Presto adopta el modelo de computación de canalización en el modelo de cálculo. Un plan de ejecución se compilará en varias etapas. Cada etapa es una colección de tareas de computación que no requieren la mezcla de datos. Las tareas de cada etapa se paralelizan y se dividen en múltiples tareas y luego se ejecutan en paralelo. Las etapas que no dependen entre sí también se pueden ejecutar en paralelo, por lo que la capacidad de ejecución simultánea del motor de computación distribuida se puede utilizar por completo para mejorar el rendimiento.
En términos generales, a nivel de gestión unificada de metadatos e interfaz de consulta, tanto Presto como Trino tienen una arquitectura muy buena y una estructura de código clara, y son más adecuados para proyectos de desarrollo secundarios basados en ellos. Sin embargo, debido a que la comunidad de código abierto no presta suficiente atención a las necesidades de administración a nivel empresarial, ambas comunidades aún carecen de buenos módulos funcionales para respaldar el control unificado de seguridad de datos y las herramientas de administración de operación y mantenimiento. Por lo tanto, si se va a implementar un sistema completo de análisis de federación de datos, se requiere un desarrollo secundario o la introducción de software comercial para complementar y mejorar las funciones necesarias. — Resumen — Este artículo presenta la arquitectura y los casos de la federación de datos.La federación de datos resuelve el problema de las "islas de datos" y evita el problema de los altos costos de desarrollo y operación y mantenimiento causados por los largos procesos ETL tradicionales. Se puede aplicar en escenarios donde existen requisitos de flexibilidad y tiempo real para la recopilación de datos, o hay escenarios de procesamiento de fuentes de datos heterogéneas.