¿Qué es el servicio de datos?
El proceso principal del desarrollo de big data se divide en cuatro etapas: integración de datos, desarrollo de datos, producción de datos y retorno de datos. La integración de datos abre el canal para que los datos del sistema comercial ingresen al entorno de big data. Por lo general, incluye tres métodos: importación periódica de tablas fuera de línea, recopilación y limpieza en tiempo real de tablas fuera de línea importadas, y escritura en tiempo real de las fuentes de datos correspondientes. Actualmente, la plataforma del centro de sincronización interna de Didi ha proporcionado capacidades de recopilación de datos de múltiples fuentes de datos como MySQL, Oracle, MongoDB y Publiclog; desarrollo/producción de datos, los usuarios pueden crear almacenes de datos en tiempo real y fuera de línea, y modelado de datos basado en varias tareas métodos como SQL, Native y Shell; el flujo de retorno de datos mejora el rendimiento de acceso mediante la importación de datos sin conexión a OLAP, RDBMS, etc., y los servicios posteriores acceden directamente a la fuente de datos para el análisis y la visualización de datos.
La fábrica de sueños de datos internos de Didi es proporcionar soluciones integrales de desarrollo y producción de datos. El enfoque principal es la eficiencia, la seguridad y la estabilidad de los enlaces de desarrollo y producción de datos.
Proceso de desarrollo de datos
Con el fin de entregar datos de manera sistemática a los usuarios, hemos creado una plataforma de consumo de datos integral, que incluye productos de consumo de datos generales como Shuyi, robot inteligente de respuesta a preguntas de datos y análisis de transacciones, así como productos de contenido depositados horizontalmente Polaris y exhibición grupal. pasillos Una plataforma de consumo integral debe proporcionar capacidades de visualización y análisis mediante la consulta de datos estructurados y estandarizados. De la arquitectura técnica de los productos de consumo de datos, existen ciertos requisitos para el rendimiento de las consultas, que se devolverán al motor de almacenamiento de análisis multidimensional apropiado de acuerdo con el método de consulta, los más comunes son MySQL, ClickHouse, Druid y StarRocks. Por lo tanto, el cierre de consultas del motor de almacenamiento de análisis multidimensional, la expansión de las capacidades informáticas, la implementación de la optimización del rendimiento y la garantía de la estabilidad de las consultas son todas capacidades públicas y generales para los productos de datos de consumo.
Además, se necesitan con urgencia capacidades de acceso a datos para otros productos de datos personalizados, plataformas operativas y productos B-end/C-end. Este es también el tema central de la construcción del centro de datos y la unificación de las capacidades de acceso a datos: capacidades de servicio de datos.
Para este desarrollo de capacidades, no lo logramos de la noche a la mañana, se divide principalmente en tres etapas.
Arquitectura Técnica de Productos de Consumo de Datos
Fase uno:
Cree la capacidad de flujo de retorno de datos del centro de sincronización
En 2019, Didi inició la construcción del sistema de datos 2.0. Como resultado central de la fábrica de sueños de datos, su objetivo de la primera fase es construir una plataforma integral de desarrollo y producción de datos. El nodo clave es la finalización del proceso único. detener la construcción del centro de sincronización como un hito. A través de la construcción de procesos automatizados, el centro de sincronización ha terminado con la historia de la construcción manual de tareas de sincronización entre fuentes de datos mediante el envío de órdenes de trabajo. Su resultado principal es la construcción de capacidades de gestión independientes para los datos que ingresan al enlace de Hive. Además, hemos creado enlaces de retorno de Hive a MySQL, ClickHouse, Druid, Hbase y ES, de modo que el flujo de retorno de datos puede completar la construcción de la plataforma.
La capacidad de servicio de datos basada en el flujo de retorno de datos permite una cobertura sistemática de escenarios relevantes, como puntos de servicio, Polaris y Shuyi. El núcleo resuelve el problema de rendimiento del acceso empresarial directo al entorno de big data. Tomando a Shuyi como ejemplo, el rendimiento de consulta de datos P90 cae de 5 segundos a menos de 2 segundos a través del flujo de retorno de datos a ClickHouse. Esta mejora de rendimiento hace que la calidad de la experiencia del usuario de Shuyi promueva. La arquitectura básica de los productos de datos en esta etapa, especialmente el lado de la consulta, es similar a la que se muestra en la siguiente figura, y se abstraen dos módulos de devolución de datos y lógica de recuperación de datos.
El flujo de retorno de datos realiza la exportación de datos al motor de almacenamiento de análisis multidimensional y acumula capacidades de administración y operación y mantenimiento de tareas.Estos productos de datos han abierto profundamente la fábrica de sueños de datos y se basan en las poderosas capacidades de operación y mantenimiento de tareas fuera de línea de los datos. fábrica de sueños, la salida de datos está garantizada. La lógica de acceso mantiene la lógica de consulta específica. Excepto Polaris, los otros dos productos tienen un middleware derivado basado en la abstracción de consultas, como QE (QueryEngine) de InSight y el centro de consultas de Shuyi. El retorno de datos y la lógica de acceso son las capacidades centrales de los productos de datos, y también son módulos con costos de construcción extremadamente altos. Por lo tanto, en esta etapa, de manera similar a productos como robots de respuesta a preguntas inteligentes de datos, portales de datos y tablas complejas, las capacidades de consulta y aceleración basadas en conjuntos de datos de Shuyi se utilizan para verificar rápidamente los productos.
Fase dos:
Cree una plataforma de cadena digital y unifique el servicio de datos
La Fase 1 proporciona capacidades de almacenamiento en línea de flujo de retorno de datos, mejora el rendimiento de las llamadas al sistema relacionadas y realiza contribuciones graduales al desarrollo de productos de datos. Con el desarrollo del negocio, la cantidad de tablas de datos ha aumentado, y el aislamiento y la precipitación de la lógica de acceso a los datos se han vuelto prominentes en diferentes sistemas, y el costo de administración ha seguido aumentando. Para mejorar el rendimiento de la recuperación de datos, además de acelerar a un motor de almacenamiento de análisis multidimensional, también es necesario agregar datos en gran medida y crear una capa de aplicaciones con menos datos. Existe una fuerte correlación entre las tablas de capas de APP y los requisitos comerciales, por lo tanto, los cambios en los requisitos a menudo conducen a cambios en las tablas de APP para respaldar los servicios. En la Fase 1, las escenas lógicas de acceso a datos están dispersas en diferentes sistemas, y los cambios en la tabla de aplicaciones serán una carga de trabajo relativamente grande, incluido el cambio de fuente de datos de diferentes kanbans y la reaceptación de la calidad de kanban.El proceso es muy complicado.
El reflujo de datos y la lógica de acceso se repiten en diferentes productos de datos, lo que también aumenta la eficiencia de la construcción de productos de datos. Para mejorar la eficiencia, los productos internos básicamente se basan en los conjuntos de datos de Shuyi para la construcción, como los robots inteligentes de datos que responden a preguntas y las tablas complejas.
Pero esta no es la solución óptima, el problema se refleja principalmente en:
Según el conjunto de datos de Shuyi, la construcción de medidas como la aceleración, la limitación de corriente y el aislamiento son muy complicadas y complicadas. En particular, el método de aceleración del conjunto de datos de Shuyi se divide en la aceleración de tareas SQL de primer nivel y la aceleración ClickHouse de segundo nivel, y la forma se solidifica.
Las consultas de Shuyi se basan en la construcción de MPP y es difícil admitir consultas y verificaciones concurrentes relativamente altas.
La capacidad de garantía de operación y mantenimiento es débil, y la plataforma lleva a cabo todas las tareas de aceleración, y la percepción del usuario es débil, y no se puede operar ni mantener.
El conjunto de datos de Shuyi es una fuerte dependencia de Shuyi, y es difícil vender y desarrollar capacidades orientadas al servicio En ese momento, no era la primera prioridad para Shuyi.
En resumen, la creación de una plataforma de servicios de datos unificados tiene grandes beneficios comerciales. Desde principios de 2021, la plataforma de cadena digital ha surgido como lo requieren los tiempos. Su idea básica es realizar una gestión unificada de los enlaces de aceleración y la lógica de consulta, y proporcionar una puerta de enlace de consulta unificada y completa.
Las capacidades básicas de la cadena digital radican en:
Fuentes de datos diversificadas : admite acceso a ES, MySQL, ClickHouse, Hbase, Druid y otras fuentes de datos;
Acceso a datos multiescenario : admite consultas simultáneas altas de pares clave-valor clave/valor, admite análisis multidimensionales complejos y admite capacidades de descarga de datos;
Estándares de acceso unificado : puerta de enlace de acceso unificado, protocolo de acceso a datos unificado, operación y mantenimiento de datos unificados y capacidades de gestión de API unificadas;
Control de seguridad de datos : admite auditorías de acceso a datos confidenciales, descarga de datos y capacidades de control de salida.
Después de la construcción de la plataforma de la cadena digital, el tiempo de construcción de la API de datos se redujo del nivel de día al nivel de minutos, y se logró la capacidad de construcción de la API de pantalla blanca. En la actualidad, el número de APIs de Cadena Digital ha superado las 4.000, y el número de APIs activas semanales también ha superado las 1.600, atendiendo a más de 200 aplicaciones, cubriendo todas las líneas de negocio, y consiguiendo los objetivos de construcción establecidos.
Fase tres:
Cree un servicio de índice estándar de cadena digital
A través de la construcción de la plataforma en la segunda etapa, los productos de datos que se obtendrán son principalmente monitoreo, tableros, portales, sistemas operativos y sistemas relacionados con la seguridad. Estos sistemas se centran principalmente en la eficiencia de la creación de API, las capacidades de gestión de la lógica comercial de API y las capacidades de operación y mantenimiento de las API. Sin embargo, en construcciones tempranas como Shuyi y Polaris, con productos de ciclo cerrado con capacidades relevantes, es difícil encontrar un gran avance para acceder a la cadena digital, o es difícil ver los beneficios.
En la actualidad, los indicadores en big data se entregan a través de tablas de Hive y las descripciones de los indicadores se depositaron en herramientas de gestión de indicadores durante mucho tiempo, es decir, el almacén de datos proporcionará al lado comercial una tabla de Hive y una lógica de valor descriptiva. Cuando el lado comercial usa la tabla Hive para construir Kanban y obtener datos temporalmente, necesita verificar repetidamente la lógica de obtención de datos, que es relativamente ineficiente. Al mismo tiempo, el mismo indicador a menudo se muestra en Polaris, Shuyi y otros productos. Lo más vergonzoso es que a menudo hay inconsistencias en los valores, lo que significa que se destaca la consistencia del consumo del indicador.
La herramienta de gestión de indicadores es un sistema de gestión de metadatos de indicadores y dimensiones construido de acuerdo con la metodología de gestión de indicadores. Para ingresar indicadores y dimensiones, el equipo de datos gasta mucho dinero. Las herramientas de administración de índices solo brindan capacidades de entrada y recuperación de índices, y la construcción normativa de índices solo puede depender de la administración de arriba hacia abajo y no puede ser autogestionada de manera efectiva. Para mantener la coherencia del indicador, solo puede asegurarse de que el indicador provenga de una fuente, y el método de entrega no puede ser la tabla de Hive, sino el indicador en sí mismo. El indicador debe proporcionar capacidades de consumo directo.
El dilema de la construcción orientada al servicio en la segunda etapa, la ambigüedad del consumo de indicadores Polaris y Shuyi, y el dilema de las propias herramientas de gestión de indicadores, surgió la construcción orientada al servicio de indicadores estándar. La idea básica se muestra en la figura. Una es que la herramienta de gestión de índices proporciona gestión de modelos y asocia el índice con la tabla física. Además, la cadena de números proporciona una puerta de enlace de consumo unificado, lo que permite que productos de datos como Shuyi y Polaris se abran. este canal de consumo.
Para la construcción basada en servicios de indicadores estándar, la gestión de metadatos necesita expandir las capacidades expresivas de indicadores y dimensiones, y usar modelos lógicos para asociar indicadores, dimensiones y campos específicos de tablas físicas específicas. Para simplificar la lógica del consumo aguas abajo, el servicio de indicadores estándar debe proporcionar una cierta cantidad de capacidades lógicas de recuperación automática. Por lo general, un índice se implementa en diferentes tablas físicas y la verificación de la coherencia de los índices entre diferentes tablas físicas puede evitar de manera eficaz la ambigüedad del índice.
“
gestión de metadatos
Los metadatos más críticos al servicio de los indicadores estándar: indicadores, dimensiones y modelos lógicos. A continuación se presentarán a su vez.
índice
La metodología de gestión de indicadores introduce principalmente los indicadores de cálculo y los indicadores compuestos introducidos para mejorar la capacidad semántica de los indicadores. Los indicadores derivados se refieren a indicadores que se pueden servir directamente de forma externa después de que se desarrolle la tabla física (Hive/Starrocks/ClickHouse), es decir, indicadores que deben materializarse en los campos correspondientes de la tabla física. Los indicadores calculados se calculan sobre la base de indicadores derivados registrados y pueden no materializarse en indicadores correspondientes a los campos de la tabla física. El método de cálculo actual solo admite las cuatro operaciones aritméticas de suma, resta, multiplicación y división. Por ejemplo, tasa de cancelación después de responder = número de pedidos cancelados después de responder / número de pedidos respondidos el mismo día. Los indicadores compuestos se refieren a los indicadores generados por las dimensiones compuestas derivadas registradas, que pueden no materializarse en los indicadores correspondientes a los campos de la tabla física. Por ejemplo, "net flower out GMV" se basa en el indicador "incluyendo openapi y código de escaneo pago GMV", y la dimensión compuesta "pedido Línea de negocio agregada", el valor de la dimensión es generado por "red + salida + flor". Como se muestra en la figura a continuación, los indicadores compuestos y los indicadores calculados se pueden anidar entre sí Actualmente, los indicadores compuestos solo pueden aparecer una vez en la cadena de anidamiento como máximo.
latitud
Tipo de latitud, actualmente se construyen cuatro tipos:
Dimensión de la tabla de dimensiones : una tabla de dimensiones independiente, la tabla de dimensiones tendrá una clave principal única y otra información de atributos. La dimensión de la tabla de dimensiones puede construir el modelo estrella del almacén de datos. Si hay claves externas, puede crear un modelo de copo de nieve que dependa de tablas de dimensiones de varias capas. Por ejemplo, la dimensión de la tabla de dimensiones de la ciudad whole_dw.dim_city.
Dimensión de enumeración : pares clave-valor clave/valor, los pares clave-valor se administran de forma centralizada. Por ejemplo: Dimensión de género, el par clave-valor correspondiente masculino (M)/femenino (F).
Dimensión degenerada : la lógica de la dimensión no se puede administrar de forma centralizada y diferentes tablas físicas tienen implementaciones diferentes, pero representan la misma dimensión. Por ejemplo, en la dimensión de línea comercial de Polaris, la lógica de conversión de la identificación de línea comercial en diferentes sectores a la identificación de línea comercial de Polaris es diferente, lo que debe determinarse en la implementación específica.
Dimensión derivada : a diferencia de la dimensión degenerada, la lógica de la dimensión se puede administrar de forma centralizada, que es una pieza de código de procesamiento.
modelo lógico
El modelo lógico tiene diferentes interpretaciones en diferentes lugares.El modelo lógico en la herramienta de gestión de indicadores es el soporte para la vinculación de indicadores, dimensiones y tablas físicas. El modelo lógico se puede vincular a tres tipos de indicadores, indicadores derivados, indicadores calculados e indicadores compuestos, y también se puede vincular a cuatro dimensiones: dimensión de la tabla de dimensiones, dimensión enumerada, dimensión derivada y dimensión degenerada. Los indicadores y dimensiones vinculados al modelo lógico pueden vincularse directamente a los campos de la tabla física, o pueden vincularse a los campos calculados construidos en base a los campos de la tabla física. Los indicadores de cálculo y los indicadores compuestos también pueden no materializarse según la lógica de cálculo o la lógica compuesta. Un modelo lógico se puede vincular a múltiples indicadores y dimensiones y, a la inversa, un indicador o dimensión se puede vincular a múltiples modelos lógicos. En términos más generales, las implementaciones múltiples de un indicador se especifican a través de un modelo lógico.
Cuando el modelo lógico especifica la tabla física, también especifica el motor de almacenamiento de la tabla física, el diseño de datos de la tabla física y el nivel del almacén de datos. La cadena de datos actual admite tres motores de almacenamiento: Hive, SR y ClickHouse; el diseño de datos admite tablas generales de aplicaciones, tablas de cubos y tablas de GroupingSets; el nivel de almacenamiento de datos admite aplicaciones, DM, DWS y DWD.
“
Automatización de la lógica de recuperación de datos
En la servitización de indicadores estándar de construcción de cadena digital, la automatización de la lógica de recuperación de datos puede realizar una gestión centralizada (Fuente Única de la Verdad) por un lado, y mejorar la eficiencia por otro lado. La automatización de la lógica de recuperación de datos se refleja principalmente en el servicio de indicadores estándar:
Soporta el acceso a datos a través de indicadores y dimensiones , los usuarios solo necesitan proporcionar los indicadores y dimensiones requeridos, y obtener datos a través de la interfaz de acceso. Como se mencionó anteriormente en el modelo lógico, el indicador y el modelo lógico tienen una relación de uno a muchos. La lógica de acceso automatizada seleccionará el modelo lógico apropiado en función de los indicadores, las dimensiones, el rango de partición y el método de acceso requeridos con el mejor rendimiento. Es importante señalar que cuando los indicadores derivados de los que dependen los indicadores calculados solo pueden obtenerse a través de diferentes modelos, el proceso de recuperación de datos puede completarse a través de consultas federadas.
Las tablas que admiten varios diseños de datos actualmente admiten tablas de aplicaciones generales, tablas de cubos y tablas de GroupingSets. Al obtener, la lógica de obtención de diferentes diseños de datos se ha protegido y los usuarios no necesitan preocuparse por el diseño de datos de la tabla original.
Se admiten varios modelos de modelado de almacenamiento de datos. En el modelado de almacenamiento de datos, se pueden usar modelos de salida estándar, de estrella y de copo de nieve. Para los modelos de estrellas y copos de nieve, la lógica de acceso automático puede realizar una lógica de acceso compleja, como la acumulación de diferentes atributos de dimensión en la dimensión de la tabla de dimensiones al asociar automáticamente las tablas de dimensiones requeridas.
Es compatible con la acumulación de granularidad diaria, semanal, mensual y trimestral Anteriormente, los datos con diferentes granularidades de tiempo solo podían obtenerse mediante el desarrollo de tablas diferentes. Cuando se garantiza el rendimiento de la consulta, ahora se puede realizar la capacidad de acumulación de granularidad de tiempo.
“
verificación de consistencia
Además de lograr la eficiencia de la recuperación de datos a través de la automatización de la lógica de recuperación de datos, la consistencia del índice también es el punto de partida central para el servicio de índice estándar de construcción de cadenas digitales. La consistencia del índice, por un lado, es a través de una interfaz de consumo unificado, y por otro lado, se basa en el estado real del índice para realizar una verificación pasiva y automática.
Verificación pasiva de indicadores, el usuario configura en la plataforma los indicadores de verificación necesarios, tal y como se muestra en la siguiente figura, como "todo el grupo GMV en el último día", pudiendo implementarse en múltiples modelos lógicos. Por lo tanto, la lógica de verificación es realizar una verificación periódica después de que se produzcan varios modelos lógicos. Otra situación es que "el GMV del último día de todo el grupo" se puede realizar con "el GMV del último día de transporte de vehículos en línea" + "el GMV del último día de dos ruedas" + "el GMV del último día de mercancías". Por lo tanto, como se muestra en la figura a continuación, la lógica de verificación puede ser una verificación periódica después de que se produzcan el modelo lógico_1 a la izquierda y el modelo lógico_1', el modelo lógico_2' y el modelo lógico_3' a la derecha.
La diferencia entre la verificación de índice automática y la verificación de índice pasiva es que el sistema genera automáticamente el método de desmontaje del modelo, y el sistema también descarta el índice que se puede verificar.
“
Proceso de acceso y consulta
En la actualidad, los servicios que acceden a los indicadores estándar de la cadena digital incluyen Polaris, Shuyi e InSight.Estos tres productos también son los productos de datos centrales de Didi. La servitización de indicadores estándar tiene diferentes retos a la hora de abrir estos tres productos, que serán detallados en los artículos compartidos por otros estudiantes. Aquí solo presentamos brevemente el proceso básico de acceso y consulta de productos de datos.
En el proceso habitual, el BP de datos ingresará los indicadores y dimensiones secuencialmente de acuerdo con la herramienta de gestión de indicadores, y los estudiantes de desarrollo de datos construirán almacenes de datos de acuerdo con diferentes métodos de arquitectura de datos y crearán modelos lógicos para asociar y vincular indicadores y dimensiones. Los metadatos gestionados se sincronizarán con la cadena digital en tiempo real.
Shuyi, Polaris e InSight crean informes y kanbans a través de interfaces de metadatos. Cuando se inicia una consulta de datos, la solicitud se enviará a la cadena de datos y, después de la selección y optimización del modelo, se generará el SQL de ejecución final y los datos consultados se devolverán al lado del producto de datos.
La estructura general del sistema de servicio de datos.
La plataforma de la cadena digital tiene como objetivo crear una plataforma de servicio de datos estandarizada, eficiente, estable y segura de ventanilla única. Los escenarios comerciales de servicios actuales se dividen principalmente en servicio de datos locales, servicio de datos fuera de línea, servicio de características y servicio de índice estándar. La plataforma de la cadena digital se divide en una capa de puerta de enlace y una capa de motor. La puerta de enlace implementa una entrada unificada y brinda capacidades como autenticación, limitación de corriente, almacenamiento en caché, enrutamiento y monitoreo. La capa del motor divide los escenarios de implementación en escenarios de par clave-valor clave/valor, escenarios de análisis multidimensional y escenarios de servicio de indicador estándar. El escenario de par clave-valor clave/valor es el servicio de las características principales del servicio, es decir, escenarios comerciales como escudos de toros y características de mapas. Los escenarios de análisis multidimensional sirven principalmente al servicio de datos local y al servicio de datos fuera de línea, a saber, Horus, Jiuxiao y otros escenarios comerciales. El escenario de par clave-valor clave/valor y el escenario de análisis multidimensional son las capacidades centrales de la segunda etapa, y el escenario de servicio de indicador estándar es la capacidad central de la tercera etapa.
Con el fin de admitir demandas de consulta de datos diversas y complejas, también hemos creado un middleware de consulta unificado: DiQuery. Confiando en la poderosa capacidad de consulta de MPP, DiQuery ha creado una capacidad de consulta unificada para servir productos de datos como Shulian y Shuyi. Además de admitir capacidades de consulta de una sola tabla, DiQuery también admite consultas federadas y capacidades de consulta de funciones complejas LOD. DiQuery admite funciones ampliadas, como la relación interanual y el promedio de cuatro semanas, y admite la capacidad de acumulación en función de esto.
Resumen y Outlook
El desarrollo del sistema de servicio de datos de Didi ha pasado por el método de tarea de devolución de datos original, la construcción de una plataforma de servicio de datos unificado y la construcción de un servicio de índice estándar, y está construyendo un mejor sistema de servicio de datos paso a paso. La construcción orientada al servicio de indicadores estándar es lo más destacado de este año, y se desarrolla rápidamente en la plena cooperación de investigación y desarrollo de almacenamiento de datos, investigación y desarrollo de productos y plataformas.
El sistema de servicio de datos actual desvincula la relación entre la producción y el consumo de datos. Luego, es necesario promover la estandarización de la producción de datos, resolver aún más el problema de la consistencia de los indicadores, mejorar la eficiencia de la construcción del almacén de datos y mejorar la calidad de los datos a través de la perspectiva de los indicadores, etc. La servitización de indicadores estándar será una evolución importante de la plataforma de datos que se promoverá paso a paso, y el telón se ha levantado lentamente en la industria.