Guia para este artigo:

OneConnect, como uma empresa afiliada do Ping An Group da China, conta com a rica experiência do Ping An Group no setor financeiro e capacidades de pesquisa científica independente por mais de 30 anos para fornecer aos clientes produtos integrados de "integração horizontal e cobertura total vertical". A competitividade exclusiva ajuda os clientes a melhorar a eficiência, melhorar o serviço, reduzir custos, reduzir riscos e realizar a transformação digital. No processo de construção de uma solução digital, confrontada com pontos problemáticos como calibre de índice inconsistente, cálculos repetitivos e baixa eficiência de entrega no processo tradicional de produção de relatórios, a OneConnect decidiu construir uma plataforma integrada de serviço de dados de índice com base no Apache Doris para obter informações centralizadas construção e gerenciamento de índices, reduzindo a carga de trabalho de desenvolvimento de ETL e outras metas de negócios. Este artigo apresentará o processo de evolução da arquitetura de duas gerações do OneConnect em detalhes, compartilhará a experiência de construção e a prática de aplicação da plataforma de serviço de dados e mostrará como obter uma resposta de consulta em nível de milissegundos com base no Apache Doris em várias tabelas cenários de associação e alta simultaneidade.

Autor｜ Hou Lan, engenheiro de mineração de dados, OneConnect

OneConnect é um provedor de tecnologia como serviço para instituições financeiras e uma empresa nacional de alta tecnologia. Como uma empresa afiliada do Grupo Ping An da China, a OneConnect conta com os 30 anos de experiência do Grupo Ping An no setor financeiro e recursos de pesquisa científica independente para fornecer aos clientes produtos integrados de "integração horizontal, cobertura total vertical", incluindo banco digital, seguros e a plataforma Jiama, que fornece infraestrutura digital fintech, usa "tecnologia + negócios" como sua competitividade exclusiva para ajudar os clientes a melhorar a eficiência, melhorar os serviços, reduzir custos, reduzir riscos e realizar a transformação digital.

ponto de dor de negócios

No processo de construção de soluções digitais, usamos principalmente indicadores (como indicadores de desempenho operacional do banco: cliente AUM) para refletir intuitivamente o status do negócio da empresa e desenvolver relatórios por meio de indicadores para ajudar o pessoal de negócios a realizar análises de dados, orientando assim as decisões de gerenciamento e capacitar a operação de digitalização. Em nosso método inicial de geração de relatórios, diferentes funcionários de linhas de negócios usavam diferentes ferramentas de análise para definir indicadores de acordo com o escopo de negócios. Esse método tradicional trará dois grandes pontos problemáticos na cooperação entre empresas:

Os indicadores e padrões não são uniformes: os relatórios gerados por várias linhas de negócios são empilhados como uma montanha.Devido ao uso de diferentes ferramentas de análise, as fontes de dados de encaixe são diversas e complicadas, o que leva ao problema de indicadores conflitantes.
Cálculo de índice duplicado e baixa eficiência de entrega: Depois que o processo de desenvolvimento precisa ser proposto pelo lado do negócio, a equipe de TI irá explorar a fonte de dados e processá-la e, em seguida, fazer um relatório e ficar online para aceitação. Ao longo do processo, a TI precisa se comunicar com o negócio várias vezes para sincronizar as informações, resultando no desenvolvimento de relatórios comuns que levam duas semanas para serem concluídos.

Para resolver esses dois grandes problemas, nosso grupo decidiu desenvolver internamente uma plataforma integrada de serviço de dados de índice. Estabelecendo um sistema de índice para atender aos objetivos estratégicos dos clientes e padronizando o processo de desenvolvimento e os métodos de uso com a ajuda da plataforma de serviço , realizamos a construção e gestão centralizada de indicadores. Ao mesmo tempo, o mecanismo de consulta OLAP é usado para facilitar o desenvolvimento e a aplicação de indicadores, para que o pessoal de negócios possa encontrar rapidamente os dados necessários, reduzir a carga de trabalho do desenvolvimento de ETL, encurtar o ciclo de desenvolvimento de relatórios e acelerar o tempo para o indicador liberação e visualização Geração de Kanban.

No processo de construção da plataforma de serviço de dados, o OneConnect experimentou duas gerações de evolução da arquitetura de data warehouse. A arquitetura de primeira geração consulta os dados do índice com base na pré-computação do Apache Kylin e, após o uso da arquitetura, descobre-se que o desempenho da consulta é insuficiente. Para atender às nossas demandas de negócios, realizamos pesquisas de seleção de modelo OLAP e, finalmente, introduzimos o Apache Doris para atualização de arquitetura, com a ajuda dos recursos de análise de alto desempenho do Apache Doris para acompanhar a consulta de índice eficiente.

Este artigo apresentará em detalhes o processo de evolução da arquitetura de duas gerações do OneConnect e compartilhará como construir uma plataforma de dados integrada baseada no Apache Doris para construção, consulta e governança unificadas de indicadores e obter resposta de consulta em nível de milissegundos em associação multi-tabela e cenários de alta simultaneidade.

Primeiros desafios de arquitetura

Arquitetura 1.0: Hadoop + Presto + Apache Kylin

Na fase inicial do negócio, desenvolvemos relatórios T+1 baseados no Apache Kylin.A figura acima mostra o processo de construção e consulta de indicadores. Durante o processo de construção do indicador, os desenvolvedores executarão a junção SQL de acordo com os indicadores e dimensões selecionados e realizarão cálculos em cada dimensão chamando o Apache Kylin por meio da API para concluir a construção do modelo e o carregamento dos dados. No processo de consulta de índice, adota-se a estratégia combinada de consulta rápida e consulta push-down.Se o campo de consulta atingir Cube, podemos consultar diretamente no Apache Kylin; se não houver ocorrência, pressione o Presto e, em seguida, consulte.

À medida que o volume de negócios continua crescendo, mais e mais usuários comerciais usam a plataforma. No processo de promoção do cliente e uso interno dentro do grupo, descobrimos que a arquitetura era insuficiente nos seguintes aspectos e não atendia às nossas demandas de negócios:

Análise flexível: a pré-computação do Apache Kylin só pode atender às necessidades de alguns cenários e não há como atender às necessidades de análise mais flexíveis.
Desempenho da consulta: quando o campo de consulta não atinge o Cubo, ele precisa ser empurrado para o Presto. No entanto, o desempenho da consulta do Presto não pode ser garantido, principalmente no cenário de valor do código da consulta, o fenômeno de timeout da consulta será encontrado, o que dificulta a liberação dos indicadores.
Custos de uso e operação e manutenção: A arquitetura Apache Kylin requer o uso de múltiplos conjuntos de componentes no processo de consulta e desenvolvimento, resultando em altos custos de manutenção.

Com base na experiência de usar a arquitetura de primeira geração, precisamos urgentemente encontrar um mecanismo OLAP que possa não apenas oferecer suporte a cenários de consulta associados a várias tabelas de índice, mas também reduzir custos e aumentar a eficiência. Com esses apelos em mente, comparamos os mecanismos OLAP atualmente populares para seleção de sistema e fizemos comparações de quatro aspectos: cenários de associação de várias tabelas, protocolos de uso, custos de uso e cenários e casos de aplicativos financeiros.

Comparação de seleção OLAP

Primeiro descartamos o TiDB, principalmente porque ele é mais inclinado a atender aos requisitos de TP e seu desempenho é relativamente insuficiente ao lidar com cenários de análise de grande volume de dados. Em segundo lugar, também excluímos Clickhouse e Greenplum. Devido ao baixo desempenho do Greenplum autônomo, ele não é adequado para nossos cenários de consulta; embora o Clickhouse tenha um bom desempenho em consultas de tabela única, ele não oferece suporte ao protocolo MySQL e o Join multitabela não pode ter um bom desempenho. nenhum dos produtos pode atender aos nossos requisitos de dados massivos Requisitos de consulta em cenários de associação de várias tabelas.

No final, com base no feedback e nas recomendações de outras subsidiárias do grupo, descobrimos que o Apache Doris era muito adequado para nossas necessidades e escolhemos inabalavelmente o Apache Doris para atualização de arquitetura. Os principais motivos são os seguintes:

Desenvolvimento fácil e conveniente: Apache Doris não é apenas compatível com o protocolo MySQL, mas também suporta sintaxe de consulta SQL padrão, tornando o desenvolvimento fácil e conveniente.
Desempenho de consulta de associação de várias tabelas em cenários complexos: o Apache Doris suporta Join distribuído, agregação de detalhes, etc., e pode fornecer vários mecanismos de otimização ao executar Join de várias tabelas para melhorar a eficiência da consulta. Ao mesmo tempo, o Apache Doris também oferece suporte a exibições materializadas e funções de indexação para concluir os efeitos de pré-computação e obter uma resposta de consulta rápida ao acessar exibições materializadas.
Operação e manutenção simples, fácil de expandir: A implantação geral do Apache Doris tem apenas duas funções: FE e BE, o que simplifica muito o link da arquitetura, faz com que a arquitetura não precise mais depender de outros componentes e alcança operação e operação de baixo custo manutenção.

Atualização baseada na arquitetura Apache Doris

Arquitetura 2.0: Apache Doris

Com base nas vantagens de desempenho do Apache Doris, atualizamos a arquitetura em termos de migração de dados e aplicativos. Durante o processo de migração de dados, Apache Doris substituiu Apache Kylin e Presto na arquitetura de primeira geração, armazenamento unificado, processamento e cálculo de dados indicadores e usou o modelo Duplicate Key para consultar dados detalhados e usou Range para executar o particionamento de tempo e formular associações de dimensão A chave é usada como uma chave, que efetivamente resolve os pontos problemáticos de desempenho insuficiente e simultaneidade insuficiente da consulta detalhada do Presto na arquitetura inicial. Ao mesmo tempo, o Apache Doris adota o modelo MPP no mecanismo de consulta, que possui recursos de computação de alta simultaneidade e baixa latência, permite a execução paralela entre os nós e dentro dos nós e suporta o Shuffle Join distribuído de várias tabelas grandes, que podem atender aos nossos requisitos para cenários complexos Requisitos para consultas associadas a várias tabelas.

Em termos de aplicação, reescrevemos o mecanismo de consulta compatível com MySQL. Ao usar a plataforma do indicador para consulta, não é mais necessário usar a interface de chamada do Apache Kylin na Arquitetura 1.0, clique no indicador de reexecução na página, e uma série de tarefas complicadas.Com base no Apache Doris, o pessoal pode usar diretamente a sintaxe do MySQL para consultar, o que simplifica bastante o processo de publicação de indicadores.

Apache Kylin contra Apache Doris

Selecionamos o cenário comum de associação de várias tabelas da plataforma de indicadores para comparar o desempenho do Apache Kylin e do Apache Doris e descobrimos que o Apache Doris teve um desempenho melhor no desempenho da consulta e na eficiência do desenvolvimento do indicador. Conforme mostrado na figura acima, quando o Apache Doris associa centenas de milhares de conjuntos de dados, a resposta da consulta atinge basicamente o nível de milissegundos. Ao mesmo tempo, não precisamos mais esperar que o Apache Kylin conclua a construção do segmento para usar os indicadores. A liberação do indicador leva em média 30 minutos para ser usado imediatamente, o que melhora significativamente a eficiência do desenvolvimento do indicador.

A introdução do Apache Doris também economiza muito espaço de armazenamento de índices, o que atende à demanda do grupo por redução de custos. Como resultado, outras linhas de negócios dentro do grupo (seguros patrimoniais, seguros de vida) também começaram a usar o Apache Doris. A atualização da nova arquitetura alcançou uma melhoria de altíssima eficiência em termos de hardware, mão de obra e tempo, e tornou-se um forte suporte para a construção de uma plataforma integrada de indicadores digitais.

Plataforma de dados de indicadores integrados

Após a conclusão da atualização da arquitetura, podemos criar um sistema de indicadores unificado, criar funções de plataforma por meio de conteúdo de indicadores, tecnologia de BI e IA e construir em conjunto uma plataforma de dados de indicadores integrados.

Crie um sistema de indicadores

Com a ajuda da análise de relacionamento de atribuição, o OneConnect ajuda as instituições a criar indicadores de cima para baixo, classificar KPIs principais e desmontar indicadores camada por camada, garantindo a integridade e a implementabilidade do sistema de indicadores. De acordo com a forma como os indicadores são gerados, os tipos de indicadores são subdivididos. Tomando como exemplo o cenário de marketing bancário, os indicadores de medição (AUM) para o valor total dos ativos do cliente na gestão de ativos bancários podem ser subdivididos em três tipos a seguir:

Indicador atômico: o indicador mais granular conectado à plataforma do indicador por meio da fonte de dados, geralmente um campo de tabela, como saldo AUM.
Indicadores derivados: Para uma análise mais aprofundada dos indicadores, a plataforma deriva automaticamente uma série de indicadores, como AUM ano a ano, aumento líquido mês a mês, etc.
Indicadores derivados: Para atender a cenários complexos de análise de indicadores, baseados em indicadores atômicos, condições de filtro são adicionadas ou combinadas com outros indicadores para cálculo, ajudando o usuário a configurar o kanban sozinho e economizando o processo de busca de dados. Por exemplo, se um usuário deseja gerar o saldo AUM por cliente para análise, a plataforma pode gerar esse indicador com a ajuda do indicador atômico Saldo AUM e o número total de clientes.

Construir funções de plataforma de indicadores

A realização da função da plataforma do indicador depende principalmente do suporte da arquitetura de data warehouse Apache Doris, e o processo on-line geral do indicador é concluído com base no desenvolvimento e na cooperação comercial. Os desenvolvedores primeiro executam o gerenciamento de metadados e a entrada de índice na plataforma, incluindo o registro da tabela inferior do relatório de processamento, configurando a granularidade de dados e a frequência de atualização da tabela intermediária e, em seguida, correlacionando as tabelas e inserindo o nome do índice e as informações de calibre do índice. Depois de inserir as informações básicas dos indicadores, o pessoal do negócio é responsável por selecionar as dimensões necessárias para a análise dos indicadores e liberar os indicadores.

Com base nas duas etapas acima, podemos analisar melhor os dados do indicador na plataforma. Conforme mostrado no lado esquerdo da figura acima, a plataforma do indicador fornece várias visualizações de análise colunar, e o pessoal comercial pode visualizar visualmente o quadro de classificação do indicador e analisar a classificação AUM de cada agência bancária. Ao mesmo tempo, integramos algoritmos inteligentes de IA para detectar indicadores anormais com a ajuda de modelos de séries temporais e auxiliamos a inspeção de KPI por meio de algoritmos de análise de causa raiz e analisamos os motivos das alterações nos indicadores. Para indicadores de estoque, a plataforma fornece um sistema de pontuação de valor, que pode indicar indicadores off-line oportunos com baixo valor, de modo a atingir o objetivo de governança durante o uso.

Prática de aplicação baseada no índice Apache Doris

A construção de uma plataforma integrada de dados resolveu completamente os problemas de calibre inconsistente dos índices e contagem dupla de indicadores no desenvolvimento de relatórios tradicionais da OneConnect. Em termos de eficiência de análise, esperamos atingir a meta de um tempo de resposta de interface de 600 milissegundos e uma resposta de consulta em 100 milissegundos em cenários complexos de associação de várias tabelas. Portanto, testamos e ajustamos o Apache Doris e compartilhamos a prática de aplicação do Apache Doris neste cenário de três aspectos: preparação de dados, implantação de cluster e ajuste de modelo.

No processo preliminar de preparação dos dados, considerando que nosso conjunto de dados é muito semelhante ao conjunto de dados SSB testado no site oficial, escolhemos a configuração do ambiente de desenvolvimento e teste recomendada pelo site oficial e selecionamos a versão Apache Doris 1.1 para teste. Como geramos arquivos CSV diretamente por meio de dados Python Mock, usamos Stream Load para derivações em lote. Os arquivos CSV importados a cada vez estão dentro do tamanho de arquivo 1-10G recomendado pelo Stream Load, e a taxa de compactação de dados final atinge 3:1, mas a velocidade de importação de nó único excede 40 MB/s.

Durante o processo de implantação do cluster, para monitorar o desempenho do indicador e do servidor (CPU, IO, disco e memória), usamos o Prometheus para importar o modelo de monitoramento Apache Doris para monitorar a implantação do cluster. O Prometheus recebe os itens de monitoramento de exposição Apache Doris , e então os visualiza com o Grafana apresentado.

Após a conclusão do trabalho preparatório, você pode iniciar a consulta associada à tabela grande. Escolhemos o SQL demorado para consultar o gráfico de tendência do indicador. Com base na meta de consulta em nível de milissegundos, implementamos duas soluções de otimização. A primeira solução é usar o Colocation Join para agregar dados antecipadamente ao criar tabelas. A segunda solução é coletar SQL de alta frequência com a ajuda do Audit Loader, otimizar reversamente a construção da tabela do data warehouse e reescrever o SQL e usar o design de tabela ampla para substituir o modelo anterior de estrela/floco de neve. Por meio do teste e avaliação dos dois esquemas, descobrimos que o segundo esquema pode obter benefícios mais significativos na resposta a consultas e na economia de recursos de serviço.

Centenas de milhões de consultas de associação de várias tabelas de dados, para obter uma resposta de consulta em nível de milissegundos

Fizemos estatísticas sobre o tempo de execução das consultas SQL, como mostra a figura acima, ao adotar a solução 1 Colocation Join, o tempo de resposta da consulta aumentou de 5 segundos para 1 segundo. Embora a eficiência da consulta tenha melhorado, esperamos reduzir ainda mais o tempo de resposta e atingir o objetivo esperado. Depois de ajustar o modelo de dados usando a segunda opção, o tempo de execução do SQL aumentou dos 5 segundos originais para 63 milissegundos, e o tempo de resposta da consulta melhorou significativamente, atingindo nossa meta de resposta da consulta em milissegundos.

Ao mesmo tempo, usamos o Grafana para verificar o desempenho da consulta do Apache Doris e descobrimos que o esquema de construção de tabela ampla pode reduzir o tempo de consulta de mais de dez segundos para menos de 100 milissegundos, e o servidor não fica mais nervoso.

Habilite o cache SQL para economizar recursos do servidor

Depois de adotar o esquema de construção de tabela ampla, para melhorar ainda mais o desempenho da consulta, também habilitamos o cache SQL para ajudar o cenário de relatório T+1 a obter um desempenho de consulta eficiente:

Depois que o cache é ativado, basicamente todas as durações de consulta são de um dígito e, finalmente, alcançam o resultado de que um único usuário acessa a página em 4 segundos;
Quando 30 indicadores são executados ao mesmo tempo (mais de 120 instruções SQL), a interface pode atender o retorno em 600ms;
No cenário concorrente, o TPS ótimo chega a 300, e a CPU, memória, disco e IO atendem a menos de 80%;
Após a avaliação, descobrimos que, na escala de cluster de teste recomendada pelo site oficial, o Apache Doris pode armazenar em cache dezenas de milhares de indicadores, o que economiza bastante recursos.

plano futuro

Atualmente, a OneConnect implementou uma plataforma de dados integrada baseada no Apache Doris para construção, consulta e governança unificadas de indicadores, fornecendo aos bancos serviços como análise e exibição abrangente de indicadores e gerenciamento inteligente do ciclo de vida dos indicadores. Sob a construção de tal plataforma, o cenário bancário dentro do grupo alcançou resultados notáveis. Até agora, dezenas de milhares de indicadores ativos e milhares de dimensões de análise foram acumulados e dezenas de milhares de Kanbans foram processados e formados , reduzindo a carga de trabalho de desenvolvimento de ETL em 30%. . No futuro, a empresa continuará explorando e otimizando com base no Apache Doris, e focaremos nos seguintes aspectos:

Análise em tempo real da plataforma : Com base no Apache Doris, o lago e o armazém são integrados e combinados com Flink CDC e Apache Iceberg para construir em conjunto uma análise unificada em tempo real.
Visualização materializada da plataforma: aguardando os destaques da nova versão, explore a otimização de consulta em associação de várias tabelas, como a criação de uma visualização materializada de várias tabelas.
Migração de outros produtos: Migre outros produtos no middle office para o Apache Doris. No momento, a plataforma de rotulagem baseada em Elasticsearch tem alguns problemas de uso e planejamos migrar a plataforma para Apache Doris no futuro.

Agradecimentos especiais à equipe técnica do SelectDB e à comunidade Apache Doris por sua resposta oportuna a quaisquer problemas encontrados durante o uso, o que reduziu muitos custos de tentativa e erro para nós. No futuro, também participaremos ativamente das contribuições e atividades da comunidade, progrediremos e cresceremos junto com a comunidade!

A Prática de Aplicação do Apache Doris na Plataforma do Financial OneConnect Index