Guía de este artículo:

OneConnect, como empresa afiliada de Ping An Group de China, se basa en la rica experiencia de Ping An Group en la industria financiera y en las capacidades de investigación científica independiente durante más de 30 años para proporcionar a los clientes productos integrados de "integración horizontal y cobertura total vertical". La competitividad única ayuda a los clientes a mejorar la eficiencia, mejorar el servicio, reducir costos, reducir riesgos y realizar la transformación digital. En el proceso de creación de una solución digital, ante puntos débiles como el calibre de índice inconsistente, los cálculos repetitivos y la baja eficiencia de entrega en el proceso tradicional de producción de informes, OneConnect decidió crear una plataforma de servicio de datos de índice integrada basada en Apache Doris para lograr construcción y administración de índices, reduciendo la carga de trabajo de desarrollo de ETL y otros objetivos comerciales. Este artículo presentará en detalle el proceso de evolución de la arquitectura de dos generaciones de OneConnect, compartirá la experiencia de construcción y la práctica de aplicación de la plataforma de servicios de datos, y le mostrará cómo lograr una respuesta de consulta de nivel de milisegundos basada en Apache Doris en varias tablas. Asociación y escenarios de alta concurrencia.

Autor｜ Hou Lan, ingeniero de minería de datos, OneConnect

OneConnect es un proveedor de tecnología como servicio para instituciones financieras y una empresa nacional de alta tecnología. Como empresa afiliada de China Ping An Group, OneConnect se basa en los 30 años de rica experiencia de Ping An Group en la industria financiera y en las capacidades de investigación científica independiente para proporcionar a los clientes productos integrados de "integración horizontal, cobertura total vertical", que incluyen banca digital, seguros y La plataforma Jiama, que proporciona infraestructura digital fintech, utiliza "tecnología + negocio" como su competitividad única para ayudar a los clientes a mejorar la eficiencia, mejorar los servicios, reducir costos, reducir riesgos y lograr la transformación digital.

punto de dolor de negocios

En el proceso de creación de soluciones digitales, utilizamos principalmente indicadores (como indicadores de rendimiento operativo bancario: AUM del cliente) para reflejar de forma intuitiva el estado comercial de la empresa y desarrollar informes a través de indicadores para ayudar al personal comercial a realizar análisis de datos, lo que impulsa las decisiones de gestión. y el empoderamiento de la digitalización funcionan. En nuestro método de generación de informes inicial, el personal de diferentes líneas de negocios usaba diferentes herramientas de análisis para definir indicadores de acuerdo con su alcance comercial. Este método tradicional traerá dos puntos críticos importantes cuando se trata de una cooperación entre negocios:

Los indicadores y estándares no son uniformes: los reportes generados por varias líneas de negocio se amontonan como una montaña, debido al uso de diferentes herramientas de análisis, las fuentes de datos de acoplamiento son diversas y complicadas, lo que genera el problema de indicadores contradictorios.
Cálculo de índice duplicado y baja eficiencia de entrega: después de que el lado comercial deba proponer el proceso de desarrollo, el personal de TI explorará la fuente de datos y la procesará, y luego hará un informe y se conectará en línea para su aceptación. A lo largo del proceso, TI necesita comunicarse con la empresa varias veces para sincronizar la información, lo que da como resultado que el desarrollo de informes ordinarios tarde dos semanas en completarse.

Para resolver estos dos problemas principales, nuestro grupo decidió desarrollar internamente una plataforma integrada de servicio de datos indexados, estableciendo un sistema indexado para cumplir con los objetivos estratégicos de los clientes y estandarizando el proceso de desarrollo y los métodos de uso con la ayuda de la plataforma de servicio. , realizamos la construcción y gestión centralizada de indicadores. Al mismo tiempo, el motor de consulta OLAP se utiliza para facilitar el desarrollo y la aplicación de indicadores, de modo que el personal comercial pueda encontrar rápidamente los datos necesarios, reducir la carga de trabajo del desarrollo de ETL, acortar el ciclo de desarrollo de informes y acelerar el tiempo para el indicador. liberación y visualización generación Kanban.

En el proceso de creación de la plataforma de servicios de datos, OneConnect ha experimentado dos generaciones de evolución de la arquitectura del almacén de datos. La arquitectura de primera generación consulta datos de índice basados en el cálculo previo de Apache Kylin y, después de usar la arquitectura, se descubre que su rendimiento de consulta es insuficiente. Para cumplir con nuestros requisitos comerciales, llevamos a cabo más investigación de selección de OLAP y finalmente introdujimos Apache Doris para la actualización de la arquitectura, con la ayuda de las capacidades de análisis de alto rendimiento de Apache Doris para guiar consultas de índice eficientes.

Este artículo presentará en detalle el proceso de evolución de la arquitectura de dos generaciones de OneConnect y compartirá cómo crear una plataforma de datos integrada basada en Apache Doris para la construcción, consulta y gobierno unificados de indicadores, y lograr una respuesta de consulta de nivel de milisegundos en Asociación multitabla y escenarios de alta concurrencia.

Primeros desafíos de la arquitectura

Arquitectura 1.0: Hadoop + Presto + Apache Kylin

En la etapa inicial del negocio desarrollamos reportes T+1 basados en Apache Kylin, la figura anterior muestra el proceso de construcción y consulta de indicadores. Durante el proceso de construcción del indicador, los desarrolladores realizarán el empalme de SQL de acuerdo con los indicadores y dimensiones seleccionados, y realizarán cálculos en cada dimensión llamando a Apache Kylin a través de la API para completar la construcción del modelo y la carga de datos. En el proceso de consulta de índice, se adopta la estrategia combinada de consulta rápida y consulta de inserción. Si el campo de consulta llega a Cubo, podemos consultar directamente en Apache Kylin; si no hay coincidencia, empujar hacia abajo a Presto y luego consultar.

A medida que el volumen de negocios continúa creciendo, más y más usuarios comerciales utilizan la plataforma.En el proceso de promoción de clientes y uso interno dentro del grupo, encontramos que la arquitectura era insuficiente en los siguientes aspectos y no podía satisfacer nuestras demandas comerciales:

Análisis flexible: el cálculo previo de Apache Kylin solo puede satisfacer las necesidades de algunos escenarios y no hay forma de satisfacer necesidades de análisis más flexibles.
Rendimiento de la consulta: cuando el campo de consulta no llega al cubo, se debe empujar hacia abajo a Presto. Sin embargo, no se puede garantizar el rendimiento de la consulta de Presto, especialmente en el escenario del valor del código de consulta, se encontrará el fenómeno del tiempo de espera de la consulta, lo que dificulta la liberación de indicadores.
Costos de uso y operación y mantenimiento: La arquitectura Apache Kylin requiere el uso de múltiples conjuntos de componentes en el proceso de consulta y desarrollo, lo que genera altos costos de mantenimiento.

Basándonos en la experiencia de usar la arquitectura de primera generación, necesitamos encontrar con urgencia un motor OLAP que no solo pueda admitir escenarios de consulta asociados de múltiples tablas de índice, sino que también reduzca los costos y aumente la eficiencia. Con tales atractivos en mente, comparamos los motores OLAP actualmente populares para la selección de sistemas e hicimos comparaciones desde cuatro aspectos: escenarios de asociación de múltiples tablas, protocolos de uso, costos de uso y escenarios y casos de aplicaciones financieras.

Comparación de selección OLAP

Primero descartamos TiDB, principalmente porque está más inclinado a cumplir con los requisitos de TP y su rendimiento es relativamente insuficiente cuando se trata de escenarios de análisis de gran volumen de datos. En segundo lugar, también excluimos a Clickhouse y Greenplum. Debido al bajo rendimiento de Greenplum independiente, no es adecuado para nuestros escenarios de consulta; aunque Clickhouse funciona bien en el rendimiento de consultas de una sola tabla, no es compatible con el protocolo MySQL y la combinación de varias tablas no puede funcionar bien. Por lo tanto, ninguno de los productos puede cumplir con nuestros requisitos para datos masivos Requisitos de consulta en escenarios de asociación de varias tablas.

Al final, basándonos en los comentarios y recomendaciones de otras subsidiarias dentro del grupo, descubrimos que Apache Doris era muy adecuado para nuestras necesidades, y elegimos inquebrantablemente Apache Doris para la actualización de la arquitectura. Las razones principales son las siguientes:

Desarrollo fácil y conveniente: Apache Doris no solo es compatible con el protocolo MySQL, sino que también admite la sintaxis de consulta SQL estándar, lo que hace que el desarrollo sea fácil y conveniente.
Rendimiento de consultas de asociación de varias tablas en escenarios complejos: Apache Doris admite la unión distribuida, la agregación de detalles, etc., y puede proporcionar varios mecanismos de optimización al realizar la unión de varias tablas para mejorar la eficiencia de las consultas. Al mismo tiempo, Apache Doris también admite vistas materializadas y funciones de indexación para completar los efectos de precomputación y lograr una respuesta rápida a las consultas al acceder a las vistas materializadas.
Operación y mantenimiento simples, fácil de expandir: la implementación general de Apache Doris tiene solo dos roles: FE y BE, lo que simplifica enormemente el enlace de la arquitectura, hace que la arquitectura ya no necesite depender de otros componentes y logra una operación y un funcionamiento de bajo costo. mantenimiento.

Actualización basada en la arquitectura Apache Doris

Arquitectura 2.0: Apache Doris

Con base en las ventajas de rendimiento de Apache Doris, actualizamos la arquitectura en términos de migración de datos y aplicaciones. Durante el proceso de migración de datos, Apache Doris reemplazó a Apache Kylin y Presto en la arquitectura de primera generación, unificó el almacenamiento, el procesamiento y el cálculo de los datos de indicadores, utilizó el modelo Duplicate Key para consultar datos detallados y utilizó Range para realizar particiones de tiempo y formular asociaciones de dimensiones La clave se utiliza como clave, lo que resuelve eficazmente los puntos débiles del rendimiento insuficiente y la concurrencia insuficiente de la consulta detallada de Presto en la arquitectura inicial. Al mismo tiempo, Apache Doris adopta el modelo MPP en el motor de consultas, que tiene capacidades informáticas de alta simultaneidad y baja latencia, permite la ejecución paralela entre nodos y dentro de los nodos, y admite la unión aleatoria distribuida de varias tablas grandes, lo que puede cumplir con nuestros requisitos. para escenarios complejos Requisitos para consultas asociadas multitabla.

En términos de aplicación, hemos reescrito el motor de consulta compatible con MySQL. Al usar la plataforma de indicador para consulta, ya no es necesario usar la interfaz de llamada de Apache Kylin en Arquitectura 1.0, haga clic en el indicador de repetición de la página, y una serie de tareas engorrosas Basado en Apache Doris, el personal puede usar directamente la sintaxis de MySQL para realizar consultas, lo que simplifica enormemente el proceso de publicación de indicadores.

Apache Kylin contra Apache Doris

Seleccionamos el escenario común de asociación de varias tablas de la plataforma de indicadores para comparar el rendimiento de Apache Kylin y Apache Doris, y descubrimos que Apache Doris se desempeñó mejor en el rendimiento de consultas y la eficiencia de desarrollo de indicadores. Como se muestra en la figura anterior, cuando Apache Doris asocia cientos de miles de conjuntos de datos, la respuesta a la consulta básicamente alcanza el nivel de milisegundos. Al mismo tiempo, ya no necesitamos esperar a que Apache Kylin complete la construcción del segmento para usar los indicadores. El lanzamiento del indicador tarda un promedio de 30 minutos en usarse de inmediato, lo que mejora significativamente la eficiencia del desarrollo del indicador.

La introducción de Apache Doris también ahorra en gran medida el espacio de almacenamiento de índices, lo que satisface la demanda de reducción de costos del grupo. Como resultado, otras líneas de negocio dentro del grupo (seguros de propiedad, seguros de vida) también han comenzado a utilizar Apache Doris. La actualización de la nueva arquitectura ha logrado una mejora de muy alta eficiencia en términos de hardware, mano de obra y tiempo, y se ha convertido en un fuerte respaldo para la construcción de una plataforma integrada de indicadores digitales.

Plataforma integrada de datos de indicadores

Una vez completada la actualización de la arquitectura, podemos construir un sistema de indicadores unificado, construir funciones de plataforma a través del contenido de indicadores, tecnología BI e IA, y construir conjuntamente una plataforma integrada de datos de indicadores.

Construir un sistema de indicadores

Con la ayuda del análisis de relaciones de atribución, OneConnect ayuda a las instituciones a crear indicadores de arriba a abajo, clasificar los KPI principales y desmantelar los indicadores capa por capa, asegurando la integridad y la implementabilidad del sistema de indicadores. Según la forma en que se generan los indicadores, los tipos de indicadores se subdividen.Tomando como ejemplo el escenario de marketing bancario, los indicadores de medición (AUM) del valor total de los activos de los clientes en la gestión de activos bancarios se pueden subdividir en los siguientes tres tipos:

Indicador atómico: el indicador más granular conectado a la plataforma de indicadores a través de la fuente de datos, generalmente un campo de tabla, como el saldo de AUM.
Indicadores derivados: para un mayor análisis de indicadores, la plataforma deriva automáticamente una serie de indicadores, como AUM año tras año, aumento neto mensual, etc.
Indicadores derivados: para cumplir con escenarios de análisis de indicadores complejos, basados en indicadores atómicos, se agregan o combinan condiciones de filtro con otros indicadores para el cálculo, lo que ayuda a los usuarios a configurar kanban por sí mismos y ahorra el proceso de obtención de datos. Por ejemplo, si un usuario desea generar el saldo de AUM por cliente para su análisis, la plataforma puede generar este indicador con la ayuda del indicador atómico de saldo de AUM y el número total de clientes.

Construir funciones de la plataforma de indicadores

La realización de la función de la plataforma de indicadores depende principalmente del soporte de la arquitectura del almacén de datos Apache Doris, y el proceso general del indicador en línea se completa en función del desarrollo y la cooperación comercial. Los desarrolladores primero realizan la gestión de metadatos y la entrada de índices en la plataforma, incluido el registro de la tabla inferior del informe de procesamiento, la configuración de la granularidad de los datos y la frecuencia de actualización de la tabla intermedia, y luego la correlación de las tablas y el ingreso del nombre del índice y la información del calibre del índice. Después de ingresar la información básica de los indicadores, el personal comercial es responsable de seleccionar las dimensiones requeridas para el análisis de indicadores y liberar los indicadores.

Con base en los dos pasos anteriores, podemos analizar más a fondo los datos del indicador en la plataforma. Como se muestra en el lado izquierdo de la figura anterior, la plataforma de indicadores proporciona varias vistas de análisis en columnas, y el personal comercial puede ver visualmente el tablero de clasificación de indicadores y analizar la clasificación de AUM de cada sucursal bancaria. Al mismo tiempo, hemos integrado algoritmos inteligentes de IA para detectar indicadores anormales con la ayuda de modelos de series de tiempo, y asistimos a la inspección de KPI a través de algoritmos de análisis de causa raíz, y analizamos las razones de los cambios en los indicadores. Para los indicadores bursátiles, la plataforma proporciona un sistema de puntuación de valor, que puede detectar indicadores fuera de línea oportunos con bajo valor, a fin de lograr el propósito de la gobernanza durante el uso.

Práctica de aplicación basada en el índice de Apache Doris

La construcción de una plataforma de datos integrada ha resuelto por completo los problemas de calibre de índice inconsistente y doble conteo de indicadores en el desarrollo de informes tradicionales de OneConnect. En términos de eficiencia de análisis, esperamos lograr el objetivo de un tiempo de respuesta de la interfaz de 600 milisegundos y una respuesta de consulta dentro de los 100 milisegundos en escenarios complejos de asociación de varias tablas. Por lo tanto, probamos y ajustamos Apache Doris y compartimos la práctica de aplicación de Apache Doris en este escenario desde tres aspectos: preparación de datos, implementación de clústeres y ajuste de modelos.

En el proceso preliminar de preparación de datos, teniendo en cuenta que nuestro conjunto de datos es muy similar al conjunto de datos SSB probado en el sitio web oficial, elegimos la configuración del entorno de desarrollo y prueba recomendada por el sitio web oficial y seleccionamos la versión Apache Doris 1.1 para la prueba. Debido a que generamos archivos CSV directamente a través de datos simulados de Python, usamos Stream Load para lotes de derivados. Los archivos CSV importados cada vez están dentro del tamaño de archivo 1-10G recomendado por Stream Load, y la relación final de compresión de datos alcanza 3:1, pero la velocidad de importación de un solo nodo supera los 40 MB/s.

Durante el proceso de implementación del clúster, para monitorear el rendimiento del indicador y el servidor (CPU, IO, disco y memoria), usamos Prometheus para importar la plantilla de monitoreo de Apache Doris para monitorear la implementación del clúster. Prometheus recibe los elementos de monitoreo de exposición de Apache Doris , y luego los visualiza con Grafana presentado.

Después de completar el trabajo preparatorio, puede iniciar la consulta asociada de tabla grande.Elegimos el SQL que consume mucho tiempo para consultar el gráfico de tendencia del indicador. Basándonos en el objetivo de consulta de nivel de milisegundos, implementamos dos soluciones de optimización. La primera solución es usar Colocation Join para agregar datos por adelantado al crear tablas. La segunda solución es recopilar SQL de alta frecuencia con la ayuda de Audit Loader, optimizar de forma inversa la construcción de tablas del almacén de datos y reescribir SQL, y usar el diseño de tabla ancha para reemplazar el modelo anterior de estrella/copo de nieve. A través de la prueba y evaluación de los dos esquemas, encontramos que el segundo esquema puede lograr beneficios más significativos en la respuesta a consultas y el ahorro de recursos del servicio.

Cientos de millones de consultas de asociación de tablas múltiples de datos, para lograr una respuesta de consulta de nivel de milisegundos

Hemos realizado estadísticas sobre el tiempo de ejecución de las consultas SQL, como se muestra en la figura anterior, al adoptar la solución 1 Colocation Join, el tiempo de respuesta de la consulta aumentó de 5 segundos a 1 segundo. Si bien se ha mejorado la eficiencia de las consultas, esperamos acortar aún más el tiempo de respuesta y lograr el objetivo esperado. Después de ajustar el modelo de datos usando la segunda opción, el tiempo de ejecución de SQL aumentó de los 5 segundos originales a 63 milisegundos, y el tiempo de respuesta de consulta mejoró significativamente, cumpliendo con nuestro objetivo de respuesta de consulta en milisegundos.

Al mismo tiempo, usamos Grafana para comprobar el rendimiento de las consultas de Apache Doris y descubrimos que el esquema de construcción de tablas anchas puede reducir el tiempo de consulta de más de diez segundos a menos de 100 milisegundos, y el servidor ya no tiembla.

Habilite la caché de SQL para ahorrar recursos del servidor

Después de adoptar el esquema de construcción de tablas amplias, para mejorar aún más el rendimiento de las consultas, también habilitamos la memoria caché de SQL para ayudar al escenario del informe T+1 a lograr un rendimiento de consultas eficiente:

Después de habilitar el almacenamiento en caché, básicamente todas las duraciones de consulta son de un solo dígito y, finalmente, logran el resultado de que un solo usuario accede a la página en 4 segundos;
Cuando se realizan 30 indicadores al mismo tiempo (más de 120 instrucciones SQL), la interfaz puede cumplir con el retorno dentro de los 600 ms;
En el escenario concurrente, el TPS óptimo llega a 300, y la CPU, la memoria, el disco y el IO alcanzan menos del 80 %;
Después de la evaluación, descubrimos que bajo la escala de clúster de prueba recomendada por el sitio web oficial, Apache Doris puede almacenar en caché decenas de miles de indicadores, lo que ahorra recursos en gran medida.

plan futuro

Actualmente, OneConnect ha implementado una plataforma de datos integrada basada en Apache Doris para la construcción, consulta y gobierno unificados de indicadores, brindando a los bancos servicios como análisis y visualización integral de indicadores y gestión inteligente del ciclo de vida de los indicadores. Bajo la construcción de dicha plataforma, la escena bancaria dentro del grupo ha logrado resultados muy notables. Hasta ahora, se han acumulado decenas de miles de indicadores activos y miles de dimensiones de análisis, y se han procesado y formado decenas de miles de Kanbans. , reduciendo la carga de trabajo del desarrollo de ETL en un 30%. En el futuro, la empresa seguirá explorando y optimizando en base a Apache Doris, y nos centraremos en los siguientes aspectos:

Análisis en tiempo real de la plataforma : basado en Apache Doris, el lago y el almacén están integrados y combinados con Flink CDC y Apache Iceberg para construir conjuntamente un análisis unificado en tiempo real.
Vista materializada de la plataforma: en espera de los aspectos más destacados de la nueva versión, explore la optimización de consultas en la asociación de varias tablas, como la creación de una vista materializada de varias tablas.
Migración de otros productos: Migrar otros productos del middle office a Apache Doris. En la actualidad, la plataforma de etiquetado basada en Elasticsearch tiene ciertos problemas de uso, y tenemos previsto migrar la plataforma a Apache Doris en el futuro.

Un agradecimiento especial al equipo técnico de SelectDB y a la comunidad de Apache Doris por su respuesta oportuna a cualquier problema encontrado durante el uso, lo que nos redujo muchos costos de prueba y error. ¡En el futuro, también participaremos activamente en las contribuciones y actividades de la comunidad, y progresaremos y creceremos junto con la comunidad!

La Práctica de Aplicación de Apache Doris en la Plataforma de Financial OneConnect Index