Cuando una empresa necesita construir un sistema de almacenamiento de datos independiente para admitir servicios de análisis y BI, tiene una arquitectura híbrida de "lago de datos + almacenamiento de datos". Pero la arquitectura híbrida trae mayores costos de construcción, costos de gestión y costos de desarrollo comercial. Con el desarrollo de la tecnología de big data, mediante la adición de transacciones distribuidas, gestión de metadatos, rendimiento extremo de SQL, SQL y capacidades de interfaz de API de datos a la capa del lago de datos, las empresas pueden admitir negocios de lagos de datos y almacenes de datos basados en una arquitectura unificada. Esto es la arquitectura integrada del almacén del lago. Este artículo continúa presentando Transwarp Inceptor y Apache Delta Lake.
— Transwarp Inceptor — Transwarp Inceptor es un motor de análisis relacional distribuido, que se desarrolló en 2013 y se utiliza principalmente en escenarios comerciales analíticos de ODS, lagos de datos y otros datos estructurados. Inceptor admite la mayoría de los estándares SQL ANSI 92, 99 y 2003, es compatible con los dialectos de bases de datos relacionales tradicionales, como Oracle, IBM DB2, Teradata, etc., y admite procedimientos almacenados. Desde 2014, algunos clientes de bancos nacionales han comenzado a intentar migrar algunos servicios de procesamiento de datos que originalmente tenían un rendimiento insuficiente en DB2 a Inceptor, y estas tareas de datos originalmente creadas en bases de datos relacionales tienen una gran cantidad de requisitos de actualización y eliminación simultáneos, y hay son múltiples enlaces de datos que procesan una tabla de resultados, por lo que existe un fuerte requisito para el rendimiento de transacciones simultáneas. Además, debido a que los usuarios no solo esperan completar la migración del negocio de procesamiento por lotes de datos de la base de datos relacional a la plataforma Hadoop, sino que también esperan una mejora de orden de magnitud en el rendimiento, Transwarp Technology comenzó a desarrollar un mecanismo de transacciones distribuidas basado en HDFS en 2014 para admite algunos Para el escenario comercial del almacén de datos, las tecnologías relacionadas se lanzaron oficialmente con la versión Inceptor 4.3 en 2016, y se puso en producción en cientos de usuarios de la industria financiera en los años siguientes, y la madurez técnica ha alcanzado la financiera requisitos de nivel.
La arquitectura general de Inceptor se muestra arriba. Debido a que ORC es un almacenamiento en columnas y tiene un rendimiento de análisis estadístico muy bueno, elegimos volver a desarrollar el sistema distribuido basado en el formato de archivo ORC. Dado que HDFS no admite el acceso aleatorio a los archivos y las operaciones de transacción en los archivos, utilizamos el mecanismo MVCC para la actualización y eliminación simultáneas de datos. Cada vez que se actualizan los datos, el archivo de datos no se reescribe directamente, pero los datos Una nueva versión correspondiente se agrega al archivo y todas las operaciones de datos dentro de una transacción se escriben en un archivo delta. Al leer datos, lea todos los datos del archivo en la memoria y combine los mismos datos en varios archivos en la memoria de acuerdo con el orden de la transacción y la visibilidad, que es el mecanismo Combinar al leer. Debe enfatizarse que el almacén de datos tiene que ver con el procesamiento por lotes de datos, y cada SQL del negocio de datos por lotes puede operar una gran cantidad de datos, y la demora requerida para una sola operación de SQL puede ser decenas de segundos o incluso más que minutos Sus requisitos de rendimiento para transacciones distribuidas son de decenas a cientos de TPS, en lugar de las decenas de miles o incluso más TPS requeridos por las bases de datos distribuidas para negocios transaccionales. Los conflictos de bloqueo son un cuello de botella importante para el rendimiento de simultaneidad en el procesamiento por lotes. Si varias tareas de ETL están procesando una tabla de datos al mismo tiempo, es posible que se produzcan conflictos de bloqueo en esta tabla, lo que provocará una espera de bloqueo entre las tareas de datos y ralentizará el ritmo de procesamiento final. Para resolver el problema de rendimiento, desarrollamos un administrador de bloqueo independiente para administrar la generación y el juicio de visibilidad de las transacciones distribuidas. Al mismo tiempo, la granularidad del bloqueo incluye tres granularidades de base de datos, tabla y partición, lo que reduce muchos bloqueos innecesarios. cuestión de conflictos.
Además, en el proceso de procesamiento del almacén de datos, muchas tablas no solo son la tabla de resultados de la tarea de procesamiento anterior, sino también la fuente de datos de otras tareas de datos, por lo que también habrá conflictos de lectura y escritura, lo que conducirá a la concurrencia. restricciones en algunos casos. Para resolver este problema, presentamos el mecanismo de instantánea y el nivel de aislamiento de la instantánea serializable.La operación de lectura de la tabla de datos puede leer directamente una instantánea, por lo que no es necesario generar conflictos de transacción con la operación de escritura. En nuestro diseño, las instantáneas no necesitan conservarse ni agregar una gran cantidad de almacenamiento físico, sino que son un concepto lógico liviano y globalmente consistente que puede determinar rápidamente si una determinada versión de los datos debe incluirse o excluidos durante el procesamiento de transacciones.
En términos de aislamiento de transacciones, Inceptor admite cinco niveles de aislamiento: lectura no confirmada, lectura confirmada, lecturas repetibles, serializable e instantánea serializable. En términos de tecnología de control de concurrencia, Inceptor proporciona dos tipos de niveles de aislamiento serializables: pesimista y optimista: nivel de aislamiento de serialización estricto basado en bloqueo de dos fases y nivel de aislamiento de serialización basado en instantáneas. Los usuarios pueden elegir el tipo de nivel de aislamiento apropiado según el escenario empresarial. El aislamiento estricto de serialización de bloqueo en dos etapas (aislamiento serializable basado en S2PL) es una tecnología de control de concurrencia pesimista. Su característica principal es adquirir bloqueos primero, luego procesar lectura y escritura, y no liberar todos los bloqueos hasta que se confirme la transacción. Su implementación es relativamente conveniente, y la principal dificultad es lidiar con el problema de interbloqueo (resuelto a través de la detección de anillos). La lectura y escritura de esta tecnología no puede ser concurrente, por lo que el rendimiento de concurrencia del procesamiento de transacciones es deficiente. El aislamiento de instantáneas serializable (Serializable Snapshot Isolation) puede mejorar el rendimiento de concurrencia del procesamiento de transacciones. Adopta el aislamiento de instantáneas serializable basado en el bloqueo optimista. La ventaja de esta tecnología es que no causará el bloqueo mutuo de las operaciones de lectura y escritura en las dos etapas. tecnología de bloqueo La situación hace que la lectura y la escritura no sean bloqueadas y mejora la concurrencia. Aunque el aislamiento de instantáneas no provocará lecturas sucias, lecturas no repetibles y lecturas fantasma, no puede garantizar la serialización. Al procesar transacciones simultáneas, aún pueden ocurrir excepciones debido a restricciones (Restricciones), que se denominan problema de orden parcial de escritura (escritura sesgada) . Para resolver el problema del orden parcial de escritura, Inceptor introduce la inspección de conflictos de instantáneas serializables y agrega la detección de bucles en la dependencia de lectura y escritura entre transacciones bajo el nivel de aislamiento de instantáneas para encontrar problemas de conflicto relacionados y cancelar transacciones anormales.
Como se mencionó anteriormente, Inceptor tiene una acumulación técnica relativamente completa en términos de simultaneidad de transacciones distribuidas, aislamiento de transacciones y rendimiento de SQL. Además, ha sido ampliamente adoptado por la industria financiera desde 2016. En el escenario del almacén de datos, la madurez de Inceptor es relativamente alta. . Dado que Inceptor no está diseñado para escenarios de aprendizaje automático, no proporciona una capa de API de datos utilizada directamente por el marco de aprendizaje automático. Además, Inceptor no ha diseñado una arquitectura separada para la escritura de datos en tiempo real, ni puede admitir de manera efectiva la arquitectura de integración de flujo por lotes.Sin embargo, Transwarp Technology ha resuelto el problema de la demanda de integración de flujo por lotes en la base de datos distribuida ArgoDB.
— Lago Delta Apache —
Debido a la gran cantidad de usuarios que ejecutan tareas de aprendizaje automático en Databricks Cloud, los principales objetivos de diseño de Databricks incluyen:
- Excelente rendimiento de SQL
El rendimiento del análisis de datos es el requisito principal del software de análisis y BI, por lo que es necesario adoptar formatos de archivo en columnas (como Parquet, etc.) y otros formatos adecuados para el análisis estadístico, así como motores de cálculo vectorial. cachés de acceso a datos y almacenamiento de datos jerárquicos (como tecnología de almacenamiento de separación de datos fríos y calientes) y otras tecnologías para mejorar el rendimiento del análisis estadístico SQL en el lago de datos y cumplir con los requisitos técnicos del almacén de datos - Proporcionar transacciones distribuidas y compatibilidad con esquemas
Los lagos de datos se almacenan principalmente en forma de archivos y sin esquema, lo que brinda flexibilidad para el análisis de datos, pero no puede realizar la capacidad de administración ACID de la base de datos. Delta Lake mejoró el almacenamiento de archivos, proporcionó un mecanismo de esquema de base de datos estricto y luego desarrolló un mecanismo de transacción de varias versiones basado en MVCC, que proporciona además la semántica ACID de la base de datos y admite operaciones SQL de actualización y eliminación altamente simultáneas. Además, Delta Lake se basa en un formato de datos abiertos (Parquet), que no solo puede operar HDFS directamente, sino que también permite que otros motores informáticos accedan a datos relacionados, lo que mejora la compatibilidad ecológica.
- API de datos para acoplamiento flexible de tareas de aprendizaje automático y análisis exploratorio
El aprendizaje automático y las tareas de capacitación de inteligencia artificial son los escenarios comerciales centrales de Databricks, por lo que Delta Lake presta gran atención para garantizar el soporte de este tipo de negocios en el diseño. No solo proporciona la API DataFrame, sino que también admite interfaces de lenguajes de programación como Python y R. y fortalece el soporte para Spark Integración de marcos de aprendizaje automático como MLlib, SparkR y Pandas.
Con base en las capacidades anteriores, combinadas con el poder de cómputo de Spark y la capacidad de almacenamiento de Delta Lake, se puede realizar una arquitectura de datos basada completamente en la tecnología de cómputo y almacenamiento de Databricks, que puede soportar el análisis estadístico de BI, el análisis en tiempo real y la máquina. Además, Delta Lake se basa en un formato de almacenamiento de datos abierto y también se puede conectar a otros motores informáticos como Presto para el análisis interactivo. En cuanto a los objetivos de diseño iniciales del proyecto, Hudi se centra en el rendimiento de actualización/eliminación de alta simultaneidad, Iceberg se centra en el rendimiento de las consultas en el caso de grandes cantidades de datos, y el núcleo del diseño de Delta Lake es brindar un mejor soporte en tiempo real. computación y computación fuera de línea. A través de una integración profunda con Spark Structured Streaming, la tabla delta no solo se puede usar como fuente de datos de Streaming, sino también directamente como la tabla de destino de Streaming, y también puede garantizar la semántica Exactamente una vez. La comunidad de Delta combinó la arquitectura de datos de múltiples saltos para diseñar un conjunto de diseños de arquitectura de referencia integrados de flujo por lotes, que pueden lograr un almacenamiento de datos similar a la arquitectura Kappa para responder a las necesidades de ambos escenarios de flujo por lotes.
Dado que el código abierto de Delta Lake de Databricks es relativamente limitado, algunas funciones deben depender del motor y el sistema de archivos de Databricks para ser mejores, por lo que la atención en la comunidad no es tan buena como la de Huid e Iceberg. Además, Delta Lake no proporciona claves primarias por diseño, por lo que la actualización/eliminación altamente simultánea no es tan buena como Hudi, ni proporciona una optimización de consultas a nivel de metadatos similar a Iceberg, por lo que el rendimiento de las consultas puede no ser tan bueno como Iceberg. pero Delta Lake enfatiza la combinación de Spark.La arquitectura de datos integrados de flujo por lotes formada y el soporte nativo a nivel de API para aplicaciones de aprendizaje automático tienen una buena universalidad en los escenarios comerciales aplicables.
- Resumen -
Desde la perspectiva de la dimensión temporal, Transwarp Inceptor es el primer producto que explora la capacidad de proporcionar almacenes de datos en lagos de datos y completó la producción a gran escala de productos en 2016, por lo que la madurez del producto es relativamente alta, especialmente en transacciones distribuidas. son ventajas obvias en la integridad de la realización.
Hudi está diseñado para ser adecuado para escenarios comerciales de actualización/eliminación de alta simultaneidad. Similar a Transwarp Inceptor, estas dos tecnologías también se basan en la capacidad de Hadoop para proporcionar actualización y eliminación. En términos relativos, el rendimiento de Hudi en transacciones distribuidas Los detalles de implementación aún necesitan más Tiempo y producción de pulido para mejorar.
El diseño del proyecto Iceberg es adecuado para los escenarios de análisis de datos masivos con un gran número de particiones pero pocas operaciones de transacción. Es más adecuado para empresas de Internet. Además, Iceberg ha hecho una muy buena abstracción en el diseño de software y tiene relativamente soporte completo para varios motores informáticos, la optimización de la partición, etc., es muy meticulosa, y sigue siendo muy atractivo para algunos escenarios con requisitos transaccionales bajos.
El código abierto de Databricks para Delta Lake es relativamente limitado, y algunas funciones deben depender del sistema de archivos y el motor de Databricks para ser mejores, por lo que la atención en la comunidad no es tan buena como la de Hudi e Iceberg. Delta Lake no tiene un diseño sobresaliente en términos de rendimiento, y la implementación de transacciones distribuidas es relativamente simple. La implementación de la concurrencia y el aislamiento de transacciones aún se encuentra en una etapa inicial. En la actualidad, el proyecto enfatiza más la arquitectura de datos de secuencias y lotes combinados. con Spark y soporte de nivel de API nativo para aplicaciones de aprendizaje automático.
A medida que cada proyecto completa gradualmente los objetivos de diseño iniciales, todos quieren expandir aún más los escenarios aplicables, y todos están ingresando a sus respectivos campos.El rápido desarrollo de cada proyecto también promueve la rápida iteración de la arquitectura integrada del almacén del lago.