Introducción: El nuevo tipo de tabla Transaction Table2.0 (en adelante, Transaction Table 2.0) de MaxCompute estará disponible para pruebas el 27 de junio de 2023. Admite soluciones informáticas y de almacenamiento de datos casi en tiempo real basadas en Transaction Table 2.0.
Autor: Shi Yuyang , ingeniero senior de investigación y desarrollo de datos en Renjia
Introducción de negocios
Renrenjia es una empresa de Internet fundada y fundada conjuntamente por Alibaba Dingding y Renrenwo para ayudar a los clientes a ingresar a la digitalización de los recursos humanos y confiar en la innovación de productos y tecnología para impulsar estrategias. La empresa proporciona principalmente servicios SaaS de recursos humanos que incluyen gestión de personal, gestión salarial, gestión de seguridad social y servicios de valor agregado, acelerando el empoderamiento del campo de recursos humanos y realizando nuevas formas de trabajar en recursos humanos. Actualmente, ha atendido a clientes en múltiples industrias en comercio electrónico, servicios minoristas y otros campos.
Renrenjia es una típica empresa de nueva creación. Actualmente se encuentra en un entorno de mercado altamente competitivo. La empresa tiene múltiples productos y los datos de cada producto son independientes. Al mismo tiempo, para satisfacer las necesidades internas de datos de CRM e integrar mejor los datos, para Este es un gran desafío para el equipo del almacén de datos, que requiere estabilidad, precisión y respuesta oportuna. El equipo del almacén de datos no solo debe satisfacer las necesidades de datos internos, sino también optimizar los costos informáticos.
Puntos débiles empresariales
En el proceso de utilizar el servicio de computación de big data de Alibaba Cloud, MaxCompute, se descubrió que a medida que aumentan los datos de stock, el costo de la deduplicación de datos incremental es cada vez mayor. Un análisis específico encontró las siguientes cuatro razones.
Los datos incrementales son de pequeña magnitud
Aunque la empresa tiene varios productos, la cantidad de datos de nuevos usuarios y cambios históricos cada día es de una escala menor (MB) en comparación con la escala de todos los datos históricos (GB).
Cálculo secundario de datos históricos.
Para la deduplicación de datos incremental, utilizamos los datos históricos completos de ayer + los datos nuevos de hoy para realizar cálculos de deduplicación de ventana todos los días. Sin embargo, la cantidad de datos que deben actualizarse para los datos históricos completos es en realidad muy pequeña y los datos históricos deben actualizarse. Se retira cada vez para la deduplicación de ventana Cálculo, este es sin duda un costo de cálculo relativamente grande.
La ventana para eliminar duplicados es computacionalmente costosa
El uso de la función número_fila para abrir ventanas para deduplicar y obtener los datos más recientes de la clave primaria empresarial requiere combinar los datos históricos de ayer + los datos de hoy. La tabla de usuarios tiene un tamaño de cientos de millones. Sin embargo, para ahorrar costos de almacenamiento y modelado posterior operaciones para la deduplicación de datos, esta parte del costo es grande, de hecho, la mayoría de los datos históricos no se han actualizado y, esencialmente, no es necesario involucrarlos nuevamente en el procesamiento de cálculos. El costo estimado de una sola declaración SQL deduplicar tablas de usuarios una vez al día cuesta 4,63 yuanes (pague sobre la marcha).
El costo de retirar el monto total es alto.
Si los datos de la base de datos empresarial se extraen en su totalidad todos los días, la cantidad de datos será de cientos de millones, pero en realidad la cantidad de datos actualizados es pequeña, lo que ejercerá una gran presión sobre la base de datos del extremo empresarial y afectará gravemente la rendimiento de la base de datos del extremo comercial.
Mejora de la deduplicación de datos de Transaction Table2.0
El nuevo tipo de tabla Transaction Table2.0 (en adelante, Transaction Table 2.0) de MaxCompute estará disponible para pruebas el 27 de junio de 2023. MaxCompute admite soluciones informáticas y de almacenamiento de datos casi en tiempo real basadas en Transaction Table 2.0. El equipo de I+D de Human Resources Data Warehouse comenzó a comprender sus características y funciones de inmediato. El equipo de Human Resources Data Warehouse descubrió que su modelo de clave primaria característico se puede utilizar para deduplicar datos y reducir los costos de cálculo de ventanas. Los principales métodos de implementación son los siguientes.
- La información básica del usuario incremental diaria se abre y duplica;
- Dado que la clave principal de la tabla de claves principales no puede estar vacía, es necesario filtrar los datos cuya clave principal comercial esté vacía;
- Inserte directamente los datos incrementales diarios en ventana y los datos deduplicados en la tabla de clave principal, y el sistema realizará automáticamente cálculos de deduplicación basados en la clave principal del negocio.
Medidas prácticas específicas para mejorar
Comparación general
| Tiempo de ejecución de SQL de deduplicación (unidades) | Costo estimado de deduplicación SQL (unidad yuan) | |
|---|---|---|
| reloj ordinario | 151 | 4.63 |
| Tabla de transacciones 2.0 | 72 | 0,06 |
Comparación de costos y tiempo de cálculo.
1. Cree declaraciones de tabla e inserte declaraciones de actualización
declaración de actualización
2. Costo y cálculo
Costo estimado de la operación de deduplicación de la tabla de particiones:
El costo estimado no se puede utilizar como estándar de facturación real y es solo como referencia. Consulte la factura para conocer el costo real.
Costo estimado de ejecutar la deduplicación de la tabla de claves primarias:
El costo estimado no se puede utilizar como estándar de facturación real y es solo como referencia. Consulte la factura para conocer el costo real.
Tiempo y recursos de cálculo de tablas particionadas
Tiempo y recursos de cálculo de la tabla de clave primaria de la Tabla de transacciones 2.0
A través de la comparación anterior, el costo SQL de cálculo diario de la tabla de usuario disminuyó de 4,63 yuanes a 0,06 yuanes, el tiempo de cálculo se redujo a la mitad, reduce_num aumentó significativamente, el lado del mapa disminuyó y la cantidad de datos en el lado reducido aumentó significativamente. .
Fusionar archivos pequeños
Transaction Table 2.0 admite funciones de consulta de viaje en el tiempo y escritura incremental casi en tiempo real. En escenarios donde los datos se escriben con frecuencia, inevitablemente se introducirá una gran cantidad de archivos pequeños. Es necesario diseñar una estrategia de fusión razonable y eficiente para fusionar archivos pequeños. y deduplicar datos Resuelve la ineficiencia de la lectura y escritura de IO para una gran cantidad de archivos pequeños y alivia la presión sobre el sistema de almacenamiento, pero también debe evitar la amplificación de escritura grave y fallas de conflicto causadas por la compactación frecuente.
Actualmente existen dos métodos principales de combinación de datos:
- Agrupación: simplemente combine el DeltaFile de la confirmación en un archivo grande sin cambiar el contenido de los datos. El sistema se ejecutará periódicamente en función de factores como el tamaño de los archivos recién agregados y la cantidad de archivos, y no requiere operación manual por parte del usuario. Resuelve principalmente los problemas de eficiencia y estabilidad de lectura y escritura de E/S de archivos pequeños.
- Compactación: todos los archivos de datos se fusionarán de acuerdo con una determinada estrategia para generar un lote de nuevos BaseFiles. Las filas de datos con la misma PK solo almacenan el estado más reciente y no contienen ningún estado histórico ni información de columnas del sistema. Por lo tanto, BaseFile no no admite operaciones de viaje en el tiempo y se utiliza principalmente para mejorar la eficiencia de las consultas. Permite a los usuarios activar activamente de acuerdo con escenarios comerciales y también admite la activación automática periódica por parte del sistema mediante la configuración de atributos de la tabla.
En resumen, cuando los datos incrementales se enfrentan a la superficie de la clave principal, los archivos pequeños no se fusionarán inmediatamente, por lo que se generará una gran cantidad de archivos pequeños, que ocuparán una gran cantidad de espacio de almacenamiento y no son propicios para los datos. Velocidad de consulta. En vista de la situación anterior, podemos agregar archivos pequeños que fusionen manualmente la tabla de claves primarias después de insertarla, o podemos activar automáticamente el mecanismo de compactación de acuerdo con dimensiones como la frecuencia de tiempo, el número de confirmaciones, etc. configurando propiedades de la tabla o esperar a que el sistema fusione la agrupación en clústeres. Si los datos se actualizan solo una vez al día, se recomienda utilizar el mecanismo de agrupación en clústeres del sistema.
punto importante:
El número de archivo y el tamaño mostrados por desc extend table_name incluyen los datos de la papelera de reciclaje. Actualmente, no hay forma de mostrarlos con precisión. Puede borrar los datos de la papelera de reciclaje o usar Compactación para observar el número de archivos al final del registro.
Consulta de datos sobre viajes espaciales y temporales y reparación de datos históricos.
Para las tablas de tipo tabla de transacciones 2.0, MaxCompute admite la consulta de un determinado tiempo histórico o versión de la tabla de origen para consultas de instantáneas históricas (consulta TimeTravel) y también admite la especificación de un determinado intervalo de tiempo histórico o de versión de la tabla de origen para incrementos históricos. consulta (consulta incremental). Consulta), debe configurar acid.data.retain.hours para usar la consulta TimeTravel y la consulta incremental.
Consulta de viaje en el tiempo de datos
1. Consultar todos los datos históricos hasta un momento específico (como una constante de cadena en formato de fecha y hora) según TimeTravel (se requiere configuración)
select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';
Consultar datos históricos y número de versión.
show history for table mf_tt2 partition(dd='01',hh='01');
Consultar todos los datos históricos hasta la constante de versión especificada
select * from mf_tt2 version as of 2 where dd='01' and hh='01';
2. Basado en consultas incrementales, datos incrementales históricos en el intervalo de tiempo especificado (como una cadena constante en formato de fecha y hora). El valor constante debe configurarse de acuerdo con el tiempo de la operación específica.
select * from mf_tt2 timestamp between '2023-06-26 09:31:40' and '2023-06-26 09:32:00' where dd= '01' and hh='01';
Consultar los datos incrementales históricos del intervalo de versión especificado.
select * from mf_tt2 version between 2 and 3 where dd ='01' and hh = '01';
Reparación de datos
Según la consulta TimeTravel, la cantidad total de datos hasta el momento especificado se inserta directamente en una tabla temporal, los datos de la tabla de clave principal de la tabla de transacciones actual 2.0 se borran y los datos de la tabla temporal se insertan en la clave principal de la tabla de transacciones actual 2.0. mesa.
Cosas a tener en cuenta y planes futuros.
Eliminar datos dinámicamente
No hay forma de eliminar datos históricos (esta parte debe depender de flink-cdc). Actualmente, se puede lograr mediante una eliminación suave o mediante un período de acumulación de datos históricos, todos los datos históricos se pueden filtrar y volver a insertar. en la tabla de clave principal en su conjunto; una cosa para mencionar aquí es que flink-cdc+flink-sql admite la eliminación completa de datos en tiempo real, pero la tarea de flink-cdc de una sola tabla es relativamente pesada y varias tablas requieren diferentes server-ids. No se recomienda para sistemas empresariales que tienen una presión de base de datos severa en la fuente. Esperamos con ansias la sincronización posterior de toda la base de datos con cdas.
Mayor espacio de almacenamiento
El espacio de almacenamiento de datos del modelo de clave primaria de la tabla de transacciones 2.0 es ligeramente mayor que el de los datos después de la ventana en la tabla de partición. La razón principal es que los datos después de la ventana se distribuyen más uniformemente y la relación de compresión de datos es mayor. Sin embargo, en comparación con los datos diarios de SQL El costo informático único y el costo diario del espacio de almacenamiento están en un nivel de costo más bajo (insignificante).
flink-cdc
Al cooperar con flink-cdc, puede realizar directamente la sincronización de datos en tiempo casi real y mejorar la actualización de los datos.
Sincronización completa de la base de datos
Esperamos que el objetivo de sintaxis Flink cdas de computación en tiempo real de Alibaba Cloud se integre con el lado MaxCompute para lograr una sincronización completa de la biblioteca y cambios ddl.
vista materializada
Esto se puede hacer usando la combinación de vista materializada + flink-cdc