Resumo: Este artigo é compartilhado por Mao Xiangyi, um engenheiro sênior de plataforma de dados da Good Future. Ele apresenta principalmente a prática de integração de fluxo em lote na indústria de educação. O conteúdo consiste em duas partes. A primeira parte é sobre algumas idéias sobre a plataforma em tempo real do futuro. A segunda parte compartilha principalmente os cenários de análise de dados exclusivos no setor de educação. O seguinte esboço:
Plano de fundo
bom futuro T-Streaming plataforma em tempo real
K12 Educação
perspectiva e planejamento de análise de cena típica
1. Introdução ao histórico
Boa introdução futura
A Good Future é uma empresa de tecnologia educacional fundada em 2003 com a marca Xueersi. Agora todos já ouviram que Xueersi Peiyou e Xueersi Online School são derivados dessa marca. Em 2010, a empresa foi listada na NASDAQ nos Estados Unidos. , Mudou seu nome para Good Future em 2013. Em 2016, o escopo de negócios da empresa abrangeu usuários entre um e 24 anos. Atualmente, as principais unidades de negócios da empresa incluem educação inteligente, plataformas abertas na área de educação, educação K12 e estudo no exterior.
Panorama de Taiwan em bons dados futuros
A imagem acima é uma visão panorâmica do bom futuro data center, que é dividido principalmente em três camadas:
- A primeira camada é a camada de habilitação de dados
- A segunda camada é a camada de dados global
- A terceira camada é a camada de desenvolvimento de dados
Primeiro, a camada de habilitação de dados. É principalmente a aplicação de inteligência de negócios e tomada de decisão inteligente, incluindo algumas ferramentas de dados, recursos de dados e sistemas de análise temática. As ferramentas de dados incluem principalmente ferramentas de análise de dados de pontos incorporados, ferramentas de teste AB e ferramentas de tela grande; a análise de capacidade de dados inclui principalmente serviços de retratos futuros e futuros Serviços de crescimento, serviços de futuro usuário e serviços de seleção de local para novos campi; o sistema de análise temática inclui principalmente a análise temática de operações de negócios, etc.
Em segundo lugar, a camada de dados global. Esperamos integrar e integrar profundamente os dados de todas as unidades de negócios de todo o grupo, abrir pools de usuários de diferentes linhas de negócios e produtos e revitalizar os dados de todo o grupo. O método específico é IDMapping, que desenterra os relacionamentos de mapeamento de id de dispositivo, pessoa natural e família, e associa dados de usuário em produtos diferentes. Desta forma, um grande pool de usuários pode ser formado, o que é conveniente para melhor capacitar os usuários.
Finalmente, a camada de desenvolvimento de dados. O desenvolvimento de dados carrega todos os projetos de desenvolvimento de dados de todo o grupo por meio de uma série de plataformas, incluindo principalmente integração de dados, desenvolvimento de dados, qualidade de dados, serviços de dados, governança de dados e outros serviços. A plataforma em tempo real que vamos compartilhar hoje está no desenvolvimento de dados.
2. Boa futura plataforma de T-Streaming em tempo real
Demandas antes da construção da plataforma em tempo real
No início da construção da plataforma em tempo real, resolvemos quatro demandas importantes.
- O primeiro apelo é ter um cluster unificado que pode melhorar a utilização de recursos, fornecendo vários inquilinos e isolamento de recursos, e resolver o problema de vários clusters em várias unidades de negócios.
- O segundo apelo é diminuir o limite de desenvolvimento de dados em tempo real por meio da plataforma, de modo a abranger mais desenvolvedores.
- O terceiro apelo é fornecer soluções para cenários comuns, melhorar a reutilização de projetos e evitar o desenvolvimento de ferramentas de análise para os mesmos cenários em cada unidade de negócios.
- O quarto apelo é realizar uma gestão completa do ciclo de vida da operação, incluindo metadados e relação de sangue. Quando uma operação é anormal, podemos analisar e localizar rapidamente o escopo de influência.
Visão geral da função da plataforma em tempo real
Nossa plataforma agora é uma plataforma única de análise de dados em tempo real, incluindo integração de dados, desenvolvimento de dados, segurança do trabalho, gerenciamento de recursos, segurança de dados e outras funções.
- Em termos de integração de dados, oferecemos suporte à integração de banco de dados, dados incorporados e dados de log do lado do servidor. Para melhorar a eficiência da integração de dados, fornecemos muitos modelos de jobs comuns. Os usuários precisam apenas configurar para obter a integração de dados rapidamente.
- Em termos de desenvolvimento de dados, oferecemos suporte a duas formas de desenvolvimento de trabalho, um é o desenvolvimento de trabalho Flink SQL e o outro é hospedagem de pacote Flink Jar. No desenvolvimento Flink SQL, incorporamos muitas funções UDF, por exemplo, podemos implementar tabelas de dimensão por meio de funções UDF Junte-se, também suporta UDF definido pelo usuário e implementa o recarregamento a quente de UDF. Além disso, também registraremos as informações de metadados do usuário durante o processo de desenvolvimento do trabalho para facilitar a construção do sistema de sangue.
- Em termos de segurança do trabalho, oferecemos suporte ao monitoramento do status do trabalho, alarmes anormais e início automático após a falha do trabalho. Quando o trabalho for iniciado automaticamente, selecionaremos automaticamente a versão do ponto de verificação disponível para iniciar. Ao mesmo tempo, também oferecemos suporte à alternância de trabalhos entre vários clusters.
- Em termos de gerenciamento de recursos, oferecemos suporte à multilocação de plataforma. Cada locatário usa namespace para isolamento, percebe o isolamento de diferentes unidades de negócios, diferentes usuários e diferentes versões de clientes Flink e percebe o isolamento de recursos de computação.
- Em termos de segurança de dados, oferecemos suporte a funções como gerenciamento de autoridade de função, gerenciamento de autoridade em nível de tabela e consulta de log de auditoria de operação.
As funções acima são as funções de nossa plataforma. Ao mesmo tempo em que capacitamos nossos negócios, também estamos em uma iteração rápida, esperando que a plataforma seja simples e fácil de usar, estável e confiável.
Integração de fluxo em lote de plataformas em tempo real
A seguir, falarei sobre algumas práticas na construção de plataformas, a primeira é a integração batch-stream.
Vamos primeiro esclarecer o que é integração de fluxo em lote?
A fusão de fluxo em lote pode ser dividida em dois conceitos. Um é a fusão de fluxo em lote proposta por Flink. O entendimento específico é que um Flink SQL pode atuar em dados de fluxo, bem como em dados de lote. Ao garantir a consistência do mecanismo de cálculo, os dados de resultado são reduzidos. A diferença, esta é uma integração de fluxo de lote em um nível técnico. Outro conceito que apresentamos internamente é a integração do fluxo em lote no nível arquitetônico. O método de operação específico é garantir o tempo real da camada ODS do data warehouse por meio de trabalhos Flink e, em seguida, fornecer agendamento em nível de hora e minuto, melhorando assim a análise de dados em tempo real.
Por que propomos a integração do fluxo de lote na arquitetura? Vemos principalmente duas tendências no desenvolvimento da indústria.
- A primeira tendência é o tempo real e a componentização da integração de dados. Por exemplo, o Flink integra o Hive e o Flink CDC continua a melhorar e aprimorar, de modo que quando fizermos a integração de dados, ela se tornará muito simples.
- A segunda tendência é que os mecanismos OLAP em tempo real estão se tornando cada vez mais maduros, como Kudu + impala, Hologres do Alibaba Cloud e soluções integradas Hucang.
Essas duas tendências tornam mais fácil para os usuários desenvolver dados em tempo real, e os usuários só precisam prestar atenção ao próprio SQL.
Conforme mostrado na figura acima, temos três tipos de data warehouses em tempo real, um é baseado no Hive, um é baseado no mecanismo OLAP em tempo real e o outro é baseado no Kafka. Entre eles, a linha azul é a realização concreta de nossa camada ODS em tempo real. Oferecemos uma ferramenta unificada que pode gravar dados em tempo real no Hive, no mecanismo OLAP em tempo real e, claro, no Kafka. Esta ferramenta é relativamente simples de usar.Se for a sincronização de dados MySQL, o usuário só precisa inserir o nome do banco de dados e o nome da tabela.
Com ferramentas em tempo real na camada ODS, podemos construir data warehouses em tempo real no Hive, mecanismo OLAP em tempo real e Kafka.
- Se for um armazém de dados em tempo real Hive , usaremos o Flink para gravar dados incrementais em tempo real na camada ODS e, em seguida, fornecer um script de mesclagem de tempo para mesclar os dados incrementais e os dados históricos, de modo a garantir que os dados na camada ODS sejam os mais recentes e melhores. completo. Com recursos de agendamento de fluxo de ar por hora, os usuários podem obter um data warehouse por hora.
- Se for um mecanismo OLAP em tempo real como Kudu / Hologres , primeiro importaremos os dados offline do Hive para o mecanismo OLAP em tempo real e, em seguida, usaremos o Flink para gravar dados incrementais em tempo real na camada ODS. O método de gravação é recomendado Com recursos como upsert, os usuários podem obter um data warehouse em tempo real puro. Com a capacidade de agendamento de nível de minuto do airflow, os usuários podem obter um data warehouse de nível de minuto.
- Construir um data warehouse em tempo real baseado em Kafka é uma arquitetura muito clássica e o custo de desenvolvimento é relativamente alto.Exceto para cenários de análise que devem ser atualizados em segundos, não recomendamos que os usuários o utilizem. Obviamente, em 2021, também implementaremos uma solução integrada de streaming em lote Flink para dar aos usuários mais opções e, ao mesmo tempo, tornar mais fácil todo o data warehouse em tempo real.
O que está acima é nosso pensamento e prática na integração de fluxo em lote. Por meio dessa integração de fluxo em lote em nível de arquitetura, costumava-se precisar desenvolver requisitos em tempo real por um mês, mas agora pode ser concluído quase em 2 dias . Isso reduz bastante o limite para o desenvolvimento de dados em tempo real e melhora a eficiência da análise de dados.
Camada ODS da plataforma em tempo real em tempo real
Deixe-me falar sobre como fazemos a camada ODS em tempo real.
Para tornar os dados da camada ODS em tempo real, precisamos resolver dois problemas: o primeiro é a inicialização de dados offline e o segundo é como gravar dados incrementais. A importação de dados off-line é melhor. Se a fonte de dados for MySQL, podemos usar tarefas DataX ou Spark para importar a quantidade total de dados MySQL para o Hive, e precisamos de duas etapas para gravar dados incrementais em tempo real. A primeira é A etapa é coletar o binlog do MySQL para o Kafka e a segunda etapa é importar os dados do Kafka para o Hive usando tarefas do Flink. Desta forma, para resolver o problema em tempo real da camada ODS, precisamos de um trabalho de inicialização offline, um trabalho de coleta de dados incremental e um trabalho de gravação de dados incremental, ou seja, três trabalhos são necessários.
Em nossa plataforma, encapsulamos e agendamos uniformemente os três trabalhos da camada ODS. Os usuários só precisam inserir um nome de banco de dados e um nome de tabela para concluir o trabalho em tempo real da camada ODS.
O acima é o processo de realização da camada ODS em tempo real em nossa fusão de fluxo em lote.
Processo de desenvolvimento do Flink SQL da plataforma em tempo real
Também temos outra prática, que é o encapsulamento de jobs do Flink SQL. Vamos dar uma olhada no processo geral de desenvolvimento do Flink SQL em nossa plataforma.
Da esquerda para a direita, os dados da fonte de dados serão coletados no Kafka por meio de ferramentas como Maxwell e canal.O formato dos dados originais coletados no Kafka não é uniforme, portanto, precisamos formatar os dados no Kafka de maneira uniforme. Por padrão, ele suporta a análise de formato de dados de ponto embutido, formato de dados de canal e dados de maxwell.Também permite que os usuários façam upload de pacotes Jar para análise de dados, e os dados padronizados obtidos da análise serão enviados novamente para Kafka.
Em seguida, usaremos as tarefas Flink SQL para consumir dados Kafka e desenvolver scripts SQL. O desenvolvimento de script SQL aqui é um pouco diferente do desenvolvimento de script Flink SQL nativo. Os usuários de desenvolvimento de script SQL nativo precisam gravar informações de origem e informações de coletor. Em nossa plataforma, os usuários só precisam gravar uma lógica SQL específica.
Depois que o usuário termina de escrever o SQL, ele envia as informações do trabalho SQL para nosso trabalho de execução Flink SQL empacotado e, finalmente, executa o trabalho enviado ao cluster Flink por meio de nosso motor SQL empacotado. Apresentaremos como o embalamos mais tarde.
Acima é o processo de desenvolvimento do Flink SQL em nossa plataforma. Além do desenvolvimento e envio do próprio trabalho do Flink, a plataforma também reterá várias informações de esquema de entrada e saída relacionadas ao trabalho. Por exemplo, as informações de esquema da tabela de banco de dados de negócios, as informações de esquema após o processamento unificado, as informações de esquema da tabela de saída de dados, por meio desses registros, podemos classificar rapidamente os meandros da operação e o escopo de influência quando solucionarmos problemas posteriormente.
Processo de desenvolvimento do Flink SQL da plataforma em tempo real
Para desenvolver trabalhos Flink SQL em nossa plataforma, apenas três etapas são necessárias:
- O primeiro passo é confirmar se o Tópico do Kafka foi registrado. Se não estiver registrado, o usuário precisa se registrar manualmente. Após concluir o registro, analisaremos os dados do Tópico e salvaremos as informações do campo.
- A segunda etapa é permitir que os usuários escrevam SQL.Como mencionado anteriormente, os usuários só precisam escrever uma lógica SQL específica, não as informações de Origem e Coletor.
- A terceira etapa é para o usuário especificar onde enviar os dados. Agora a plataforma pode suportar a especificação de vários dispositivos de armazenamento de coletor ao mesmo tempo, como gravar os dados calculados para Hive, Holo e outro armazenamento ao mesmo tempo.
Por meio da configuração das três etapas acima, o usuário pode enviar o trabalho.
A seguir, vamos falar sobre como fizemos. Dividi todo o processo de execução em 2 estágios e 10 etapas.
O primeiro estágio é o estágio de preparação do job e o segundo estágio é o estágio de execução SQL.
Etapa de preparação da operação
- Na primeira etapa, o usuário especifica as informações SQL e Sink nos dados da página.
- A segunda etapa é o processo de análise e verificação do SQL.Quando o usuário envia o SQL, vamos analisar o SQL para ver se a tabela de origem e o UDF usado no SQL estão registrados na plataforma.
- A terceira etapa é especular para construir uma tabela. Primeiro usaremos o SQL do usuário e, em seguida, obteremos o resultado de retorno do SQL, geraremos algumas instruções de construção de tabela com base nos dados do resultado e, finalmente, usaremos o programa para ir automaticamente para o armazenamento do coletor de destino para construir a tabela.
- A quarta etapa é montar o arquivo de script Flink SQL para obter um arquivo de script com três elementos: Source, SQL e Sink.
- A quinta etapa, envio de trabalho, enviará aqui o arquivo Flink SQL para nosso próprio mecanismo de execução.
Fase de execução SQL
- A primeira etapa é inicializar o StreamTableAPI e, em seguida, usar o método de conexão para registrar a Fonte Kafka. As informações da Fonte Kafka precisam especificar regras de análise de dados e informações de esquema de campo, e iremos gerá-las automaticamente com base em metadados.
- A segunda etapa é usar StreamTableAPI para registrar as tabelas de dimensão e funções UDF usadas em SQL. As funções UDF incluem funções UDF carregadas pelos usuários.
- A terceira etapa é usar a API StreamTable para executar instruções SQL. Se houver uma visualização, você também poderá executá-la.
- A quarta etapa é uma etapa mais crítica, converteremos StreamTabAPI em API DataStream.
- A quinta etapa é adicionar informações de link com base no DataStream.
O processo de execução acima é de dois estágios. No segundo estágio, a tarefa SQL do usuário será executada.
Trabalhos nativos da plataforma em tempo real e tarefas de modelo
O texto acima compartilhou como desenvolver e executar nosso trabalho Flink SQL. A seguir, vamos falar sobre o suporte de trabalho do tipo de pacote JAR de nossa plataforma.
Em nossa plataforma, oferecemos suporte aos usuários para fazer upload de trabalhos de pacote JAR por conta própria e, em seguida, gerenciá-los em nossa plataforma. Ao mesmo tempo, a fim de melhorar a capacidade de reutilização do código em cenários comuns, desenvolvemos muitos jobs de modelo, como o suporte ao binlog coletado por Maxwell para ser gravado diretamente em dispositivos de armazenamento como Hive, Kudu, Holo e logs de Alibaba Cloud SLS de suporte a serem gravados em vários Mecanismo OLAP.
Solução de implantação de nuvem híbrida de plataforma em tempo real
Fale sobre o plano de implantação de nuvem híbrida e a arquitetura de tecnologia da plataforma.
Nossa plataforma agora suporta o envio de trabalhos para a sala de informática da nuvem Alibaba e para a sala de informática construída por nós mesmos, e o trabalho pode ser alternado entre as duas salas de computador. Para ter essa função?
No início deste ano, com a eclosão da epidemia, a educação online na Internet inundou um grande volume de tráfego. Para fazer frente ao aumento do tráfego, adquirimos milhares de máquinas para implantação de emergência e online durante o Festival da Primavera. Mais tarde, após a epidemia estabilizar, estas A taxa de utilização da máquina é relativamente baixa. Para resolver esse problema, nossa plataforma oferece suporte a um esquema de implantação de nuvem híbrida. Durante os períodos de pico, os jobs podem ser migrados para o Alibaba Cloud e executados em seus próprios clusters, o que economiza recursos. Ele também garante uma expansão flexível.
Arquitetura de tecnologia de plataforma em tempo real
A seguir, fale sobre a arquitetura técnica da plataforma.
Somos um projeto que separa o front-end do back-end. O front-end usa vue + elmentui e o servidor usa springboot. Em diferentes salas de computadores, implantaremos uma instância de serviço de back-end. A tarefa é submetida a diferentes salas de computadores principalmente por meio de nginx + lua da camada de encaminhamento. O envio de tarefas, suspensão e operações off-line na plataforma são todos feitos por meio da camada de driver, que é principalmente scripts de shell. O último é o cliente. No cliente, isolamos a versão do Namespace / User / Flink.
3. Cenários de análise típicos da educação K12
Introdução à renovação de negócios
Vamos falar sobre um caso específico. O caso é um cenário de análise típico na indústria de educação K12, onde os usuários continuam a relatar negócios.
Deixe-me falar sobre a renovação primeiro. Renovação significa compra repetida. Os usuários compraram um curso de um ano. Esperamos que os usuários comprem um curso de dois anos. Para que os usuários adquiram os cursos, teremos um período concentrado de renovação, cada um com cerca de uma semana, quatro vezes ao ano.
Como o ciclo de renovação é relativamente concentrado e o tempo é relativamente curto, a demanda por dados de renovação em tempo real é particularmente urgente para professores que sempre fazem negócios de renovação.
Para isso, elaboramos uma solução geral de renovação para apoiar as ações de renovação de várias unidades de negócio. Existem vários desafios na renovação em tempo real.
- O primeiro desafio é calcular se o pedido de um usuário é uma renovação, ele precisa contar com todos os pedidos do histórico do usuário, ou seja, dados históricos são necessários para participar do cálculo.
- O segundo desafio é que uma mudança em um pedido afetará as mudanças em outros pedidos, o que é um efeito indireto. Por exemplo, o usuário tem 5 pedidos, e o pedido número 345 está no status de renovação. Se o usuário cancelar o pedido número 3, o status de renovação dos pedidos 4 e 5 precisa ser recalculado.
- O terceiro desafio é que a dimensão muda com frequência. Por exemplo, o status da filial da escola do usuário pela manhã é Pequim, o status da filial à tarde pode ser Xangai, o tutor da manhã é Zhang San e o tutor da tarde é Li Si. As dimensões que mudam frequentemente são resumidas em tempo real. Os dados trazem desafios.
Baseando-se em dados históricos, o efeito indireto das mudanças de ordem e frequentemente mudando as dimensões, esses desafios não são nada se você olhar para eles individualmente, e eles se tornarão mais interessantes se forem colocados juntos.
Solução de renovação em tempo real
Vamos falar sobre a arquitetura geral primeiro. Usamos o método de fusão de fluxo em lote para fazer isso. Ele é dividido em duas linhas, uma linha é o cálculo de dados de renovação em tempo real em nível de minuto e a outra é o cálculo de dados de renovação em tempo real de segundo nível. Os dados calculados são colocados em MYSQL e usados para telas grandes e outdoors de BI.
Primeiro, olhe para a linha azul. Vamos importar os dados off-line do Hive para o Kudu. Os dados off-line são todos tabelas de largura de pedido calculada. Em seguida, os trabalhos do Flink serão usados para transformar os pedidos recém-adicionados em uma mesa ampla e gravá-los no Kudu, para que ele tenha os dados mais recentes e completos. Com a programação de 4 minutos, fornecemos dados de renovação em tempo real em nível de minuto.
Olhando para a primeira linha laranja, há dois trabalhos do Flink nesta linha, um é o trabalho ETL e o outro é o trabalho de atualização.
O trabalho de ETL será responsável pelo splicing das dimensões estáticas e pelo cálculo do status de renovação.Para o splicing das dimensões estáticas, acessamos diretamente o MySQL e o cache no JVM. O cálculo do status de renovação precisa depender de dados históricos. O ETL Job carregará todos os dados do pedido na JVM. O método de implementação específico é que personalizamos um método personalizado de partição para dividir todos os dados históricos e cada downstream A tarefa armazena em cache os dados de um fragmento. Ao carregar dados na memória, aceleramos bastante o cálculo em tempo real do Flink.
Os dados calculados do ETL Job terão duas saídas. Uma é enviada para o Kudu para garantir que os dados no Kudu sejam os mais atualizados e completos. Os dois dados são Kafka. Há um tópico no Kafka que registra as alterações no pedido atual. Informações sobre quais pedidos ou dimensões foram alterados.
O programa por trás do Kafka é o Update Job, que é usado especificamente para processar os pedidos ou dimensões afetadas e modificar diretamente os dados estatísticos relevantes no MySQL.
Desta forma, realizamos o cálculo de renovação em tempo real por meio de 2 trabalhos Flink.
O resultado final é o processamento de alterações de dados de dimensão em tempo real. Os dados de alteração de dimensão serão enviados para Kafka e, em seguida, Flink será usado para processamento para ver quais estatísticas de dados são afetadas pela alteração de dimensão e, finalmente, enviar os pedidos afetados para Os tópicos afetados são recalculados por Update Job.
A solução acima é a solução geral para nossa renovação em tempo real. Se amigos do setor de educação ouvirem esse compartilhamento, eles poderão consultá-lo.
Garantia de estabilidade de relatório em tempo real
Vamos dar uma olhada nas garantias dessa solução universal depois que ela entrar no ar.
- A primeira garantia é remoto ativo-ativo. Implementamos um conjunto de procedimentos de renovação no Alibaba Cloud e na nossa sala de informática construída por nós. Se um deles estiver anormal, podemos alternar a interface de front-end. Se os programas em ambas as salas de computador estiverem desligados, iniciaremos o programa do zero e levará apenas 10 minutos.
- A segunda garantia é a tolerância a falhas no trabalho. Temos dois trabalhos Flink. Esses dois trabalhos param e começam a qualquer momento, sem afetar a precisão dos dados. Outro ponto é que armazenamos em cache todos os dados do pedido na JVM. Se a quantidade de dados aumentar, precisamos apenas alterar o paralelismo do programa ETL, sem nos preocupar com o estouro de memória da JVM.
- A terceira garantia é o monitoramento de trabalhos. Oferecemos suporte a avisos anormais e pull-ups automáticos após falhas de trabalhos, bem como avisos de atraso de dados do consumidor.
Por meio das medidas de salvaguarda acima, o procedimento de renovação em tempo real passou por vários ciclos de renovação e é relativamente estável, o que não causa preocupações.
4. Perspectiva e planejamento
O conteúdo acima detalha os negócios atuais e as soluções técnicas para o futuro. Em resumo, percebemos o isolamento de recursos de cada departamento de negócios por meio de multilocação, resolvemos a análise em tempo real por meio da solução de arquitetura de integração de fluxo em lote e resolvemos a fonte de dados em tempo real para OLAP por meio da camada ODS. Problemas de integração de dados, reduzindo o limite para desenvolvimento de dados em tempo real por meio do pacote Flink SQL, fornecendo soluções de cenário geral por meio de tarefas de modelo, resolvendo a expansão elástica de recursos por meio de soluções de implantação de nuvem híbrida e abrangendo a análise de dados do mesmo cenário por meio de soluções de renovação em tempo real.
Finalmente, dê uma olhada em nossa visão e plano. Em seguida, continuaremos a aprofundar a integração do fluxo em lote, fortalecer a implantação da nuvem híbrida e melhorar a oportunidade e a estabilidade da análise de dados. Suporta o tempo real da plataforma do algoritmo, o tempo real da aplicação de dados e melhora a oportunidade da tomada de decisão de dados.
Este artigo é o conteúdo original do Alibaba Cloud e não pode ser reproduzido sem permissão.