O que é serviço de dados
O principal processo de desenvolvimento de big data é dividido em quatro etapas: integração de dados, desenvolvimento de dados, produção de dados e retorno de dados. A integração de dados abre o canal para que os dados do sistema de negócios entrem no ambiente de big data. Geralmente inclui três métodos: importação periódica de tabelas off-line, coleta e limpeza em tempo real de tabelas off-line importadas e gravação em tempo real das fontes de dados correspondentes. Atualmente, a plataforma interna do centro de sincronização da Didi oferece recursos de coleta de dados de várias fontes de dados, como MySQL, Oracle, MongoDB e Publiclog; desenvolvimento/produção de dados, os usuários podem criar armazéns de dados em tempo real e offline e modelagem de dados com base em várias tarefas métodos como SQL, Native e Shell; O backflow de dados melhora o desempenho de acesso importando dados offline para OLAP, RDBMS, etc., e os serviços downstream acessam diretamente a fonte de dados para análise e visualização de dados.
A fábrica interna de sonhos de dados da Didi é fornecer soluções completas de desenvolvimento e produção de dados. O foco principal é a eficiência, segurança e estabilidade do desenvolvimento de dados e links de produção.
Processo de desenvolvimento de dados
A fim de fornecer sistematicamente dados aos usuários, construímos uma plataforma de consumo de dados única, incluindo produtos gerais de consumo de dados, como Shuyi, robô inteligente de resposta a perguntas de dados e análise de transações, bem como produtos de conteúdo depositados horizontalmente Polaris e exibição em grupo salões. Uma plataforma de consumo completa precisa fornecer recursos de visualização e análise, consultando dados estruturados e padronizados. Da arquitetura técnica dos produtos de consumo de dados, existem certos requisitos para o desempenho da consulta, que serão retornados ao mecanismo de armazenamento de análise multidimensional apropriado de acordo com o método de consulta, os mais comuns são MySQL, ClickHouse, Druid e StarRocks. Portanto, o fechamento da consulta do mecanismo de armazenamento de análise multidimensional, a expansão dos recursos de computação, a implementação da otimização de desempenho e a garantia da estabilidade da consulta são todos recursos públicos e gerais para produtos de dados do consumidor.
Além disso, recursos de acesso a dados são necessários com urgência para outros produtos de dados personalizados, plataformas operacionais e produtos B-end/C-end. Essa também é a questão central da construção do data center e da unificação dos recursos de acesso a dados: recursos de serviço de dados.
Essa capacitação não foi realizada da noite para o dia, ela está dividida principalmente em três etapas.
Arquitetura Técnica de Produtos de Consumo de Dados
Fase um:
Crie a capacidade de refluxo de dados do centro de sincronização
Em 2019, a Didi iniciou a construção do sistema de dados 2.0. Como resultado principal da fábrica de sonhos de dados, seu objetivo da primeira fase é construir uma plataforma única de desenvolvimento e produção de dados. O nó principal é a conclusão do parar a construção do centro de sincronização como um marco. Através da construção de processos automatizados, o centro de sincronização encerrou o histórico de construção manual de tarefas de sincronização entre fontes de dados por meio do envio de ordens de serviço.Sua principal saída é a construção de recursos independentes de gerenciamento de dados que entram no link Hive. Além disso, construímos recentemente o backflow do Hive para os links MySQL, ClickHouse, Druid, Hbase e ES, para que o backflow de dados possa concluir a construção da plataforma.
A capacidade de serviço de dados com base no fluxo de dados permite a cobertura sistemática de cenários relevantes, como pontos de serviço, Polaris e Shuyi. O núcleo resolve o problema de desempenho do acesso direto da empresa ao ambiente de big data. Tomando Shuyi como exemplo, o desempenho da consulta de dados P90 cai de 5s para menos de 2s por meio do refluxo de dados para ClickHouse. Essa melhoria de desempenho faz com que a qualidade da experiência do usuário de Shuyi seja promovida. A arquitetura básica dos produtos de dados neste estágio, especialmente o lado da consulta, é semelhante à mostrada na figura abaixo, e dois módulos de retorno de dados e lógica de recuperação de dados são abstraídos.
O refluxo de dados realiza a exportação de dados para o mecanismo de armazenamento de análise multidimensional e acumula recursos de gerenciamento de tarefas e operação e manutenção. Esses produtos de dados abriram profundamente a fábrica de sonhos de dados e com base na poderosa operação de tarefas off-line e capacidades de manutenção dos dados fábrica de sonhos, a saída de dados é garantida. A lógica de acesso mantém a lógica de consulta específica.Exceto o Polaris, os outros dois produtos derivaram middleware baseado na abstração de consulta, como o QE (QueryEngine) da InSight e o centro de consultas da Shuyi. O retorno de dados e a lógica de acesso são os principais recursos dos produtos de dados e também são módulos com custos de construção extremamente altos. Portanto, neste estágio, semelhante a produtos como robôs de resposta a perguntas inteligentes de dados, portais de dados e tabelas complexas, os recursos de consulta e aceleração baseados em conjuntos de dados Shuyi são usados para verificar produtos rapidamente.
Fase dois:
Construa uma plataforma de cadeia digital e unifique o serviço de dados
A Fase 1 fornece recursos de armazenamento on-line de backflow de dados, melhora o desempenho de chamadas de sistema relacionadas e faz contribuições em fases para o desenvolvimento de produtos de dados. Com o desenvolvimento do negócio, o número de tabelas de dados aumentou, e o isolamento e precipitação da lógica de acesso a dados tornou-se proeminente em diferentes sistemas, e o custo de gerenciamento continuou a aumentar. Para melhorar o desempenho da recuperação de dados, além de acelerar para um mecanismo de armazenamento de análise multidimensional, também é necessário agregar dados altamente e construir uma camada de APP com menos dados. Existe uma forte correlação entre as tabelas da camada APP e os requisitos de negócios, portanto, mudanças nos requisitos geralmente levam a mudanças nas tabelas APP para serviços de suporte. Na Fase 1, as cenas lógicas de acesso a dados estão espalhadas em diferentes sistemas, e as mudanças na tabela APP serão uma carga de trabalho relativamente grande, incluindo troca de fonte de dados de diferentes kanbans e re-aceitação da qualidade kanban.O processo é muito complicado.
O refluxo de dados e a lógica de acesso são repetidos em diferentes produtos de dados, o que também aumenta a eficiência da construção do produto de dados. A fim de melhorar a eficiência, os produtos internos dependem basicamente de conjuntos de dados Shuyi para construção, como robôs de resposta a perguntas inteligentes de dados e tabelas complexas.
Mas esta não é a solução ideal, o problema se reflete principalmente em:
Com base no conjunto de dados Shuyi, a construção de medidas como aceleração, limitação de corrente e isolamento é muito complicada e complicada. Em particular, o método de aceleração do conjunto de dados de Shuyi é dividido em aceleração de tarefa SQL de primeiro nível e aceleração ClickHouse de segundo nível, e o formulário é solidificado.
As consultas de Shuyi são baseadas na construção MPP e é difícil suportar consultas e verificações simultâneas relativamente altas.
A capacidade de garantia de operação e manutenção é fraca, e as tarefas de aceleração são todas realizadas pela plataforma, e a percepção do usuário é fraca, e não pode ser operada e mantida.
O conjunto de dados de Shuyi é uma forte dependência de Shuyi e é difícil desinvestir e construir recursos orientados a serviços.Naquela época, não era a primeira prioridade de Shuyi.
Resumindo, a construção de uma plataforma unificada de serviço de dados traz grandes benefícios para os negócios. Desde o início de 2021, a plataforma de cadeia digital surgiu conforme os tempos exigem, com a ideia básica de realizar o gerenciamento unificado de links de aceleração e lógica de consulta e fornecer um gateway de consulta unificado e completo.
As capacidades básicas da cadeia digital estão em:
Fontes de dados diversificadas : suporta acesso a ES, MySQL, ClickHouse, Hbase, Druid e outras fontes de dados;
Acesso a dados em vários cenários : oferece suporte a consultas simultâneas de pares chave/valor chave-valor, oferece suporte a análises multidimensionais complexas e oferece suporte a recursos de download de dados;
Padrões de acesso unificado : gateway de acesso unificado, protocolo de acesso a dados unificado, operação e manutenção de dados unificados e recursos de gerenciamento de API unificados;
Controle de segurança de dados : Suporta auditoria de acesso a dados confidenciais, download de dados e recursos de controle de saída.
Após a construção da plataforma de cadeia digital, o tempo de construção da API de dados foi reduzido do nível do dia para o nível do minuto, e a capacidade de construção da API da tela branca foi realizada. Atualmente, o número de APIs da Cadeia Digital ultrapassou 4.000, e o número de APIs ativas semanais também ultrapassou 1.600, atendendo a mais de 200 aplicativos, abrangendo todas as linhas de negócios e atingindo as metas de construção estabelecidas.
Fase três:
Criar serviço de índice padrão de cadeia digital
Por meio da construção da plataforma na segunda etapa, os produtos de dados que serão obtidos são principalmente monitoramento, painéis, portais, sistemas operacionais e sistemas relacionados à segurança. Esses sistemas se concentram principalmente na eficiência da criação de APIs, nos recursos de gerenciamento da lógica de negócios da API e nos recursos de operação e manutenção das APIs. No entanto, em construções iniciais como Shuyi e Polaris, com produtos de circuito fechado com recursos relevantes, é difícil encontrar um avanço para acessar a cadeia digital ou é difícil ver os benefícios.
Atualmente, os indicadores em big data são fornecidos por meio de tabelas Hive e descrições de indicadores depositadas em ferramentas de gerenciamento de indicadores há muito tempo, ou seja, o data warehouse fornecerá ao lado comercial uma tabela Hive e uma lógica de valor descritiva. Quando o lado comercial usa a tabela Hive para criar Kanban e buscar dados temporariamente, ele precisa verificar repetidamente a lógica de busca de dados, que é relativamente ineficiente. Ao mesmo tempo, o mesmo indicador é frequentemente exibido em Polaris, Shuyi e outros produtos... O mais embaraçoso é que muitas vezes há inconsistências nos valores, o que significa que a consistência do consumo do indicador é proeminente.
A ferramenta de gerenciamento de indicadores é um sistema de gerenciamento de metadados de indicadores e dimensões construído de acordo com a metodologia de gerenciamento de indicadores. Para inserir indicadores e dimensões, a equipe de dados gasta muito dinheiro. As ferramentas de gerenciamento de índice fornecem apenas recursos de entrada e recuperação de índice, e a construção normativa de índice pode depender apenas do gerenciamento de cima para baixo e não pode ser efetivamente autogerida. Para consistência do indicador, você só pode garantir que o indicador venha de uma fonte, e o método de entrega não pode ser a tabela Hive, mas o próprio indicador. O indicador precisa fornecer recursos de consumo direto.
O dilema da construção orientada a serviços no segundo estágio, a ambigüidade do consumo dos indicadores Polaris e Shuyi e o dilema das próprias ferramentas de gerenciamento de indicadores, surgiu a construção orientada a serviços de indicadores padrão. A ideia básica é mostrada na figura. Uma delas é que a ferramenta de gerenciamento de índice fornece gerenciamento de modelo e associa o índice à tabela física. Além disso, a cadeia numérica fornece um gateway de consumo unificado, permitindo que produtos de dados como Shuyi e Polaris sejam abertos este canal de consumo.
Para a construção de indicadores padrão baseados em serviços, o gerenciamento de metadados precisa expandir as capacidades expressivas de indicadores e dimensões e usar modelos lógicos para associar indicadores, dimensões e campos específicos de tabelas físicas específicas. Para simplificar a lógica do consumo a jusante, o serviço de indicadores padrão precisa fornecer uma certa quantidade de recursos lógicos de recuperação automática. Normalmente, um índice é implementado em diferentes tabelas físicas, e a verificação de consistência dos índices entre diferentes tabelas físicas pode efetivamente evitar a ambigüidade do índice.
“
gerenciamento de metadados
Os metadados mais críticos para o serviço de indicadores padrão: indicadores, dimensões e modelos lógicos. O seguinte será introduzido sucessivamente.
índice
A metodologia de gestão de indicadores introduz principalmente os indicadores de cálculo e os indicadores compostos introduzidos para melhorar a capacidade semântica dos indicadores. Os indicadores derivados referem-se a indicadores que podem ser atendidos diretamente externamente após o desenvolvimento da tabela física (Hive/Starrocks/ClickHouse), ou seja, indicadores que devem ser materializados nos campos correspondentes da tabela física. Os indicadores calculados são calculados com base nos indicadores derivados registrados, não podendo ser materializados em indicadores correspondentes aos campos da tabela física.O método de cálculo atual suporta apenas as quatro operações aritméticas de adição, subtração, multiplicação e divisão. Por exemplo, taxa de cancelamento após atendimento = quantidade de pedidos cancelados após atendimento / quantidade de pedidos atendidos no mesmo dia. Os indicadores compostos referem-se aos indicadores gerados pelas dimensões compostas derivadas registradas, que podem não ser materializadas nos indicadores correspondentes aos campos da tabela física. Por exemplo, "net flower out GMV" é baseado no indicador "incluindo openapi e código de varredura pagamento GMV" e a dimensão composta "linha de negócios agregada do pedido", o valor da dimensão é gerado por "rede + saída + flor". Conforme mostrado na figura abaixo, os indicadores compostos e os indicadores calculados podem ser aninhados entre si. Atualmente, os indicadores compostos podem aparecer apenas uma vez na cadeia de aninhamento, no máximo.
latitude
Latitude, quatro tipos são atualmente construídos:
Dimensão da tabela de dimensões : uma tabela de dimensões independente, a tabela de dimensões terá uma chave primária exclusiva e outras informações de atributo. A dimensão da tabela de dimensões pode construir o modelo em estrela do data warehouse. Se houver chaves estrangeiras, você poderá criar um modelo de floco de neve que dependa de tabelas de dimensão de várias camadas. Por exemplo, a dimensão da tabela de dimensões da cidade whole_dw.dim_city.
Dimensão de enumeração : pares chave/valor chave-valor, pares chave-valor são gerenciados centralmente. Por exemplo: Dimensão de gênero, o par de valor-chave correspondente masculino (M)/feminino (F).
Dimensão degenerada : a lógica da dimensão não pode ser gerenciada centralmente e diferentes tabelas físicas têm diferentes implementações, mas representam a mesma dimensão. Por exemplo, na dimensão da linha de negócios do Polaris, a lógica de conversão da id da linha de negócios em diferentes setores para a id da linha de negócios do Polaris é diferente, o que precisa ser determinado na implementação específica.
Dimensão derivada : Ao contrário da dimensão degenerada, a lógica da dimensão pode ser gerenciada centralmente, que é um código de processamento.
modelo lógico
O modelo lógico tem diferentes interpretações em diferentes lugares.O modelo lógico na ferramenta de gestão de indicadores é o suporte para a ligação de indicadores, dimensões e tabelas físicas. O modelo lógico pode ser vinculado a três tipos de indicadores, indicadores derivados, indicadores calculados e indicadores compostos, e também pode ser vinculado a quatro dimensões: dimensão da tabela de dimensões, dimensão enumerada, dimensão derivada e dimensão degenerada. Os indicadores e dimensões vinculados ao modelo lógico podem ser vinculados diretamente aos campos da tabela física, ou podem ser vinculados aos campos calculados construídos com base nos campos da tabela física. Indicadores de cálculo e indicadores compostos também podem ser não materializados de acordo com a lógica de cálculo ou lógica composta. Um modelo lógico pode ser vinculado a vários indicadores e dimensões e, inversamente, um indicador ou dimensão pode ser vinculado a vários modelos lógicos. De um modo mais geral, várias implementações de um indicador são especificadas por meio de um modelo lógico.
Quando o modelo lógico especifica a tabela física, ele também especifica o mecanismo de armazenamento da tabela física, o layout de dados da tabela física e o nível do data warehouse. Atualmente, a cadeia de dados oferece suporte a três mecanismos de armazenamento: Hive, SR e ClickHouse; o layout de dados oferece suporte a tabelas APP gerais, tabelas Cube e tabelas GroupingSets; o nível do data warehouse oferece suporte a APP, DM, DWS e DWD.
“
Automação da lógica de recuperação de dados
Na servitização de indicadores padrão de construção de cadeia digital, a automação da lógica de recuperação de dados pode realizar o gerenciamento centralizado (Single Source of Truth) por um lado e melhorar a eficiência por outro lado. A automação da lógica de recuperação de dados se reflete principalmente no serviço de indicadores padrão:
Suporta acesso a dados por meio de indicadores e dimensões . O usuário só precisa fornecer os indicadores e dimensões necessários e obter os dados por meio da interface de acesso. Conforme mencionado acima no modelo lógico, o indicador e o modelo lógico têm uma relação um-para-muitos. A lógica de acesso automatizada selecionará o modelo lógico apropriado com base nos indicadores, dimensões, faixa de partição e método de acesso necessários com o melhor desempenho. É importante ressaltar que quando os indicadores derivados dos quais dependem os indicadores calculados só podem ser obtidos por meio de modelos diferentes, o processo de recuperação de dados pode ser concluído por meio de consultas federadas.
As tabelas que suportam vários layouts de dados atualmente suportam tabelas APP gerais, tabelas Cube e tabelas GroupingSets. Na busca, a lógica de busca de diferentes layouts de dados foi protegida e os usuários não precisam se preocupar com o layout de dados da tabela original.
Vários modelos de modelagem de data warehouse são suportados.Na saída padrão de modelagem de data warehouse, modelos singleton, estrela e floco de neve podem ser usados. Para modelos de floco de neve e estrela, a lógica de acesso automático pode realizar uma lógica de acesso complexa, como acúmulo de diferentes atributos de dimensão na dimensão da tabela de dimensão, associando automaticamente as tabelas de dimensão necessárias.
Ele suporta roll-up de granularidade diária, semanal, mensal e trimestral.Anteriormente , dados com granularidades de tempo diferentes só podiam ser obtidos desenvolvendo tabelas diferentes. Quando o desempenho da consulta é garantido, a capacidade de acúmulo de granularidade de tempo agora pode ser realizada.
“
checagem de Consistência
Além de obter eficiência na recuperação de dados por meio da automação da lógica de recuperação de dados, a consistência do índice também é o principal ponto de partida para o serviço de índice padrão de construção de cadeia digital. A consistência do índice, por um lado, ocorre por meio de uma interface de consumo unificada e, por outro lado, é baseada no status real do índice para realizar a verificação passiva e automática.
Verificação de indicadores passivos, o usuário configura os indicadores de verificação necessários na plataforma, conforme a figura abaixo, como "todo o grupo GMV no último dia", podendo ser implementado em vários modelos lógicos. Portanto, a lógica de verificação é realizar uma verificação periódica após a produção de vários modelos lógicos. Outra situação é que "o GMV do último dia de todo o grupo" pode ser obtido por "GMV do transporte on-line do último dia" + "GMV do último dia de duas rodas" + "GMV do frete do último dia". Portanto, conforme mostrado na figura abaixo, a lógica de verificação pode ser uma verificação periódica após o modelo lógico_1 à esquerda e o modelo lógico_1', modelo lógico_2' e modelo lógico_3' à direita serem produzidos.
A diferença entre a verificação automática do índice e a verificação passiva do índice é que o método de desmontagem do modelo é gerado automaticamente pelo sistema e o índice que pode ser verificado também é filtrado pelo sistema.
“
Processo de acesso e consulta
Atualmente, os serviços que acessam os indicadores padrão da cadeia digital incluem Polaris, Shuyi e InSight.Esses três produtos também são os principais produtos de dados da Didi. A servitização de indicadores padrão tem diferentes desafios na abertura desses três produtos, que serão detalhados nos artigos compartilhados por outros alunos. Aqui apresentamos apenas brevemente o processo básico de acesso e consulta de produtos de dados.
No processo normal, o BP de dados inserirá os indicadores e dimensões sequencialmente de acordo com a ferramenta de gerenciamento de indicadores, e os alunos de desenvolvimento de dados construirão data warehouses de acordo com diferentes métodos de arquitetura de dados e criarão modelos lógicos para associar e vincular indicadores e dimensões. Os metadados gerenciados serão sincronizados com a cadeia digital em tempo real.
Shuyi, Polaris e InSight criam relatórios e kanbans por meio de interfaces de metadados. Quando uma consulta de dados é iniciada, a solicitação será enviada para a cadeia de dados e, após a triagem e otimização do modelo, o SQL de execução final será gerado e os dados consultados serão retornados ao lado do produto de dados.
A estrutura geral do sistema de serviço de dados
A plataforma de cadeia digital visa criar uma plataforma de serviço de dados padronizada, eficiente, estável e segura. Os cenários de negócios de serviços atuais são divididos principalmente em serviço de dados local, serviço de dados off-line, serviço de recursos e serviço de índice padrão. A plataforma da cadeia digital é dividida em uma camada de gateway e uma camada de mecanismo. O gateway implementa uma entrada unificada e fornece recursos como autenticação, limitação de corrente, cache, roteamento e monitoramento. A camada do mecanismo divide os cenários de implementação em cenários de pares chave/valor de chave/valor, cenários de análise multidimensional e cenários de serviço de indicador padrão. O cenário do par chave/valor chave-valor é o serviço dos principais recursos de serviço, ou seja, cenários de negócios como escudos e recursos de mapa. Cenários de análise multidimensional atendem principalmente serviços de dados locais e serviços de dados offline, ou seja, Horus, Jiuxiao e outros cenários de negócios. Cenários de par chave/valor chave-valor e cenários de análise multidimensional são os principais recursos da Fase 2, e os cenários de serviço de indicadores padrão são os principais recursos da Fase 3.
Para atender às diversas e complexas demandas de consulta de dados, também construímos um middleware de consulta unificado: DiQuery. Baseando-se na poderosa capacidade de consulta do MPP, a DiQuery construiu uma capacidade de consulta unificada para atender a produtos de dados como Shulian e Shuyi. Além de oferecer suporte a recursos de consulta de tabela única, o DiQuery também oferece suporte a consultas federadas e recursos de consulta de função complexa de LOD. O DiQuery oferece suporte a funções estendidas, como proporção ano a ano e média de quatro semanas, e oferece suporte à capacidade de acumular com base nisso.
Resumo e Perspectivas
O desenvolvimento do sistema de serviço de dados da Didi passou pelo método de tarefa de retorno de dados original, a construção de uma plataforma de serviço de dados unificada e a construção do serviço de índice padrão, e está construindo um melhor sistema de serviço de dados passo a passo. A construção orientada a serviços de indicadores padrão é o destaque deste ano e se desenvolve rapidamente em plena cooperação de pesquisa e desenvolvimento de data warehouse, pesquisa e desenvolvimento de produtos e plataformas.
O sistema de serviço de dados atual dissocia a relação entre produção de dados e consumo de dados. Em seguida, é necessário promover a padronização da produção de dados, resolver ainda mais o problema da consistência dos indicadores, melhorar a eficiência da construção do data warehouse e melhorar a qualidade dos dados através da perspectiva dos indicadores, etc. A servitização de indicadores padrão será uma evolução importante da plataforma de dados que será promovida passo a passo, e a cortina foi baixada lentamente na indústria.