Quebrando Silos de Dados: Como o Apache Doris Simplifica a Integração de Dados do Cliente

O problema dos silos de dados é como uma artrite para os negócios online, porque quase todo mundo o contrai à medida que envelhecem. As empresas interagem com os clientes por meio de sites, aplicativos móveis, páginas H5 e dispositivos finais. Por uma razão ou outra, é complicado integrar os dados de todas estas fontes. Os dados permanecem onde estão e não podem ser inter-relacionados para análise posterior. É assim que os silos de dados se formam. Quanto maior for o crescimento do seu negócio, mais diversificadas serão as fontes de dados dos clientes e maior será a probabilidade de ficar preso em silos de dados.

É exatamente isso que acontece com a seguradora da qual vou falar neste post. Em 2023, já serviram mais de 500 milhões de clientes e assinaram 57 mil milhões de contratos de seguros. Quando começaram a construir uma plataforma de dados do cliente (CDP) para acomodar esse tamanho de dados, eles usaram vários componentes.

Silos de dados no CDP

Como a maioria das plataformas de dados, o CDP 1.0 tinha um pipeline de processamento em lote e um pipeline de streaming em tempo real. Os dados off-line foram carregados por meio de trabalhos do Spark para o Impala, onde foram marcados e divididos em grupos. Enquanto isso, o Spark também o enviou ao NebulaGraph para cálculo do OneID (elaborado posteriormente neste post). Por outro lado, os dados em tempo real foram etiquetados pelo Flink e depois armazenados no HBase, prontos para serem consultados.

Isso levou a uma camada de computação com muitos componentes no CDP: Impala, Spark, NebulaGraph e HBase.

Como resultado, tags offline, tags em tempo real e dados gráficos foram espalhados por vários componentes. Integrá-los para serviços de dados adicionais era caro devido ao armazenamento redundante e à transferência volumosa de dados. Além do mais, devido a discrepâncias no armazenamento, eles tiveram que expandir o tamanho do cluster CDH e do cluster NebulaGraph, aumentando os custos de recursos e manutenção.

CDP baseado em Apache Doris

Para o CDP 2.0, eles decidem introduzir uma solução unificada para limpar a bagunça. Na camada de computação do CDP 2.0, o Apache Doris realiza armazenamento e computação de dados em tempo real e offline.

Para ingerir dados offline , eles utilizam o método Stream Load . O teste de ingestão de 30 threads mostra que ele pode realizar mais de 300.000 upserts por segundo. Para carregar dados em tempo real , eles usam uma combinação de Flink-Doris-Connector e Stream Load. Além disso, em relatórios em tempo real, onde é necessário extrair dados de diversas fontes de dados externas, eles aproveitam o recurso Multicatálogo para consultas federadas .

Os fluxos de trabalho analíticos do cliente neste CDP são assim. Primeiro, eles classificam as informações do cliente; em seguida, eles anexam tags a cada cliente. Com base nas tags, eles dividem os clientes em grupos para análise e operação mais direcionadas.

A seguir, vou me aprofundar nessas cargas de trabalho e mostrar como o Apache Doris as acelera.

Um ID

Isso já aconteceu com você quando você tem diferentes sistemas de registro de usuários para seus produtos e serviços? Você pode coletar o e-mail do UserID A de uma página da web de um produto e, posteriormente, o número do seguro social do UserID B de outra. Então você descobre que o UserID A e o UserID B, na verdade, pertencem à mesma pessoa porque usam o mesmo número de telefone.

É por isso que o OneID surge como uma ideia. É reunir as informações de registro do usuário de todas as linhas de negócios em uma grande tabela no Apache Doris, classificá-las e garantir que um usuário tenha um OneID exclusivo.

É assim que eles descobrem quais informações de registro pertencem ao mesmo usuário, aproveitando as funções do Apache Doris.

Serviços de marcação

Este CDP acomoda informações de 500 milhões de clientes , que vêm de mais de 500 tabelas de origem e estão anexadas a mais de 2.000 tags no total.

Por oportunidade, as tags podem ser divididas em tags em tempo real e tags offline. As tags em tempo real são calculadas pelo Apache Flink e gravadas na tabela plana no Apache Doris, enquanto as tags offline são calculadas pelo Apache Doris, pois são derivadas da tabela de atributos do usuário, da tabela de negócios e da tabela de comportamento do usuário no Doris. Aqui estão as práticas recomendadas da empresa em marcação de dados:

1. Tags off-line:

Durante os picos de gravação de dados, uma atualização completa pode facilmente causar um erro de OOM, dada a enorme escala de dados. Para evitar isso, eles utilizam a função INSERT INTO SELECT do Apache Doris e habilitam atualização parcial da coluna . Isso reduzirá significativamente o consumo de memória e manterá a estabilidade do sistema durante o carregamento de dados.

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. Tags em tempo real:

Atualizações parciais de colunas também estão disponíveis para tags em tempo real, pois as tags em tempo real são atualizadas em ritmos diferentes. Tudo o que é necessário é definir partial_columns como true .

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. Consultas de pontos de alta simultaneidade:

Com o tamanho atual do seu negócio, a empresa está recebendo solicitações de consulta de tags em um nível de simultaneidade de mais de 5.000 QPS. Eles usam uma combinação de estratégias para garantir alto desempenho. Primeiramente, eles adotam uma Declaração Preparada para pré-compilação e pré-execução de SQL. Em segundo lugar, eles ajustam os parâmetros do Doris Backend e das tabelas para otimizar o armazenamento e a execução. Por último, eles habilitam o cache de linha como um complemento ao Apache Doris orientado a colunas.

• Ajuste os parâmetros do Doris Backend em be.conf :

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Ajuste os parâmetros da tabela na criação da tabela:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Cálculo de tags (junção):

Na prática, muitos serviços de marcação são implementados por junções de múltiplas tabelas no banco de dados. Isso geralmente envolve mais de dez tabelas. Para um desempenho computacional ideal, eles adotam a estratégia de grupo de colocation em Doris.

Agrupamento de clientes

O pipeline de agrupamento de clientes no CDP 2.0 é assim: Apache Doris recebe SQL do atendimento ao cliente, executa a computação e envia o conjunto de resultados para o armazenamento de objetos S3 por meio de SELECT INTO OUTFILE. A empresa dividiu seus clientes em 1 milhão de grupos. A tarefa de agrupamento de clientes que costumava levar 50 segundos no Impala para ser concluída agora só precisa de 10 segundos no Doris .

Além de agrupar os clientes para análises mais refinadas, às vezes eles fazem análises no sentido inverso. Ou seja, atingir um determinado cliente e saber a quais grupos ele pertence. Isso ajuda os analistas a compreender as características dos clientes e também como os diferentes grupos de clientes se sobrepõem.

No Apache Doris, isso é implementado pelas funções BITMAP: BITMAP_CONTAINS é uma maneira rápida de verificar se um cliente faz parte de um determinado grupo, e BITMAP_OR , BITMAP_INTERSECT e BITMAP_XOR são as opções para análise cruzada.

Conclusão

Do CDP 1.0 ao CDP 2.0, a seguradora adota o Apache Doris, um data warehouse unificado, para substituir Spark+Impala+HBase+NebulaGraph. Isso aumenta a eficiência do processamento de dados, quebrando os silos de dados e simplificando os pipelines de processamento de dados. No futuro CDP 3.0, eles desejam agrupar seus clientes combinando tags em tempo real e tags off-line para análises mais diversificadas e flexíveis. A comunidade Apache Doris e a equipe VeloDB continuarão a ser parceiros de suporte durante esta atualização.

Também publicado aqui .