E-MapReduce:Cenários

Cenário de data lake

Os clusters EMR DataLake atendem equipes que precisam centralizar armazenamento, governança e análise de data lakes corporativos construídos sobre o OSS-HDFS. Três capacidades principais atuam em conjunto para cobrir todo o ciclo de vida, desde a ingestão de dados brutos até as aplicações downstream.

O diagrama a seguir ilustra o fluxo de dados ponta a ponta do cenário EMR DataLake.

Etapa 1: Ingerir dados de múltiplas fontes

Dados de diferentes sistemas de source chegam ao OSS-HDFS em seu formato original.

• Bancos de dados relacionais (MySQL, Oracle): Use Sqoop ou DataX para extrair dados completos ou incrementais conforme agendamento regular e gravá-los no OSS-HDFS com base no esquema da tabela de negócios.

• Bancos de dados não relacionais (MongoDB, Redis): Utilize um script personalizado ou conector Spark para exportar dados JSON ou binários ao OSS-HDFS.

• Dados de log: Configure Logstash ou Flume para coletar logs incrementais (comportamento do usuário, sistema) e gravá-los no OSS-HDFS com latência de nível de minuto.

• Dados de arquivo: Carregue arquivos CSV, Parquet e outros em massa no OSS-HDFS usando JindoSDK com a API HDFS ou faça upload diretamente pelo console do OSS.

Etapa 2: Processar e analisar dados

Refine os dados brutos no OSS-HDFS para obter métricas de negócios consultáveis.

• Processamento em lote: Execute jobs Spark e Hive para limpar, associar e agregar logs brutos e dados de negócios. As saídas típicas incluem usuários ativos diários, taxas de retenção de usuários em 30 dias e contagens de novos pedidos por Stock Keeping Unit (SKU).

• Consultas interativas: Utilize Trino ou Presto com SQL padrão para consultar big data com tempos de resposta inferiores a um segundo e dar suporte a análises ad hoc das equipes de operações.

Etapa 3: Aplicar dados em sistemas downstream

Alimente diversas aplicações de negócios com os dados processados.

• Ciência de dados: Disponibilize os dados processados via serviços de API para sistemas downstream, como motores de controle de risco e sistemas de recomendação.

• Business intelligence: Conecte-se à API Java Database Connectivity (JDBC) de ferramentas como o Quick BI para criar relatórios interativos.

• Análise preditiva: Envie resultados de processamento e dados de recursos para uma plataforma de machine learning, treine modelos (como previsão de vendas de SKU) e armazene os resultados novamente no data lake.

• Visualização de dados: Use a API JDBC para conectar-se a ferramentas de visualização como o DataV e exibir dados complexos em painéis.

Cenário de análise de dados

Os clusters EMR Online Analytical Processing (OLAP) atendem equipes que executam análises de big data de alto desempenho. Eles se integram a motores OLAP (StarRocks, Doris e ClickHouse) que compartilham três características de desempenho: compressão eficiente de dados, armazenamento orientado a colunas e execução paralela de consultas. Tais atributos tornam os clusters OLAP adequados para criação de perfis de usuários, seleção de destinatários e cargas de trabalho de business intelligence.

O diagrama a seguir utiliza o motor de análise StarRocks para mostrar o fluxo de dados ponta a ponta no cenário EMR OLAP.

Etapa 1: Coletar dados

O StarRocks recebe dados de fontes em tempo real e offline.

• Tempo real: O Flume captura dados de log; o Message Queue for Apache Kafka armazena fluxos de dados em buffer com alto throughput e baixa latência para estabilizar a ingestão em tempo real.

• Offline: O Sqoop ou DataX extrai dados de bancos de dados relacionais (como MySQL e Oracle) conforme agendamento regular e os carrega no StarRocks.

Etapa 2: Organizar dados em camadas no StarRocks

O StarRocks organiza os dados em quatro camadas hierárquicas, padrão semelhante à arquitetura medalhão usada em data lakehouses modernos. Assim, cada camada se baseia na anterior e pode ser reutilizada independentemente.

• Camada DIM (camada de dimensão): Armazena dados dimensionais, como atributos de usuários e categorias de produtos, e suporta análises de múltiplas granularidades.

• Camada ODS (camada de armazenamento de dados operacionais): Mantém os dados brutos em seu estado original e permite análises retrospectivas.

• Camada DWD (camada de detalhes do data warehouse): Aplica limpeza de dados, padronização de formato e associações básicas para produzir conjuntos de dados detalhados.

• Camada DWS (camada de resumo do data warehouse): Pré-agrega métricas por assunto de negócios (comportamento do usuário, conversão de pedidos) para reduzir a latência das consultas.

Etapa 3: Aplicar dados

Impulsione três aplicações principais de negócios com os dados organizados em camadas.

• Criação de perfil de usuário: Combine tags de atributos da camada DIM com dados comportamentais da camada DWS para construir perfis de usuários voltados ao marketing de precisão.

• Seleção de destinatários: Filtre usuários por múltiplas condições, como alta atividade sem compras nos últimos 30 dias.

• Business intelligence: Conecte-se à API JDBC do Quick BI para gerar relatórios diários, semanais e painéis em tempo real.

Cenário de streaming de dados em tempo real

Os clusters EMR Dataflow atendem cargas de trabalho que exigem ingestão e análise contínua de dados com baixa latência, como controle de risco e painéis em tempo real. O cluster integra três componentes principais que cobrem armazenamento, processamento de fluxo e gerenciamento incremental de dados.

• OSS-HDFS: Camada de armazenamento escalável compatível com o protocolo HDFS. Suporta armazenamento persistente de petabytes de dados em tempo real, gravações com latência de milissegundos e tiering de dados quentes e frios de baixo custo.

• Flink: Executa ETL em fluxos de dados (análise de logs, associação de dimensões), agregação de janelas (medição de Gross Merchandise Volume (GMV) no nível de minuto) e processamento de eventos complexos (avaliação de regras de controle de risco).

• Paimon: Gerencia dados incrementais em tempo real e snapshots históricos em um data lake de streaming. Oferece suporte à sincronização de change data capture (CDC), transações ACID (atomicidade, consistência, isolamento e durabilidade) e consultas time-travel.

O diagrama a seguir mostra como Flink, Paimon e OSS-HDFS trabalham juntos para construir um data lakehouse de streaming que alimenta um painel em tempo real.

Etapa 1: Ingerir dados em tempo real de múltiplas fontes

Use conectores Flink para coletar simultaneamente alterações de banco de dados, logs e dados de rastreamento de eventos de vários sistemas upstream.

Etapa 2: Construir o data lakehouse de streaming

Processe e armazene dados em um lakehouse estruturado e consultável com Flink e Paimon.

• Flink: Como motor integrado de computação de dados em lote e fluxo, consome fluxos de dados em tempo real e executa limpeza, transformação (análise de logs, padronização de pontos de rastreamento de eventos) e associação de dimensões.

• Paimon: Armazena os resultados do processamento em um data lake de streaming por meio de dois mecanismos principais:

  • Changelog: Registra inserções, atualizações e exclusões de dados para garantir a integridade das transações ACID e a sincronização incremental em tempo real.

  • Modelagem hierárquica: Combina o Paimon com as camadas ODS, DWD e DWS para criar uma arquitetura de dados em camadas e permitir o acúmulo e a reutilização de dados incrementais.

• OSS-HDFS: Armazena persistentemente logs brutos, snapshots incrementais do Paimon e dados históricos arquivados.

Etapa 3: Entregar insights de negócios

Alimente ferramentas de relatórios em tempo real e tomada de decisão com os dados processados do lakehouse.

• Gere relatórios de negócios em tempo real, como monitoramento de GMV e análise de retenção de usuários, com o StarRocks.

• Conecte-se ao Quick BI para criar painéis que permitam tomada de decisão T+0.

Cenário de serviço de dados

Os clusters EMR DataServing atendem cargas de trabalho que exigem armazenamento e consulta de grandes conjuntos de dados com latência de milissegundos. O cluster integra OSS-HDFS, HBase e Phoenix para cobrir todo o caminho, desde o armazenamento de dados brutos até a execução de consultas complexas, dando suporte a casos de uso como análise de comportamento do usuário e marketing de precisão.

• HBase: Banco de dados distribuído e orientado a colunas que fornece leitura e gravação em tempo real com alto throughput para grandes conjuntos de dados. Inclui consultas pontuais com latência de milissegundos para status de pedidos e registros de comportamento do usuário. O HBase persiste HFiles no OSS-HDFS, desacopla armazenamento e computação e permite recriar o cluster rapidamente.

• Phoenix: Motor de consulta SQL para HBase. Mapeia dados NoSQL para tabelas relacionais padrão e suporta análises SQL complexas (associação de múltiplas tabelas e computação agregada) com tempos de resposta inferiores a um segundo para centenas de bilhões de registros. Índices secundários e pushdown de consulta aceleram a seleção baseada em tags e o agrupamento de usuários, o que reduz o esforço de desenvolvimento das equipes de negócios.

O diagrama a seguir mostra como os clusters EMR DataServing utilizam a arquitetura de armazenamento HBase + OSS-HDFS e o motor de consulta Phoenix para dar suporte à análise de comportamento do usuário.

Etapa 1: Processar dados

Dois caminhos de processamento (fluxo e lote) alimentam o cluster HBase com dados.

• Processamento de fluxo (Flink): Consome fluxos de dados de log em tempo real, aplica limpeza de dados (remoção de ruído, padronização de formato), agregação de janelas (contagens de unique visitor (UV) em tempo real) e alertas de eventos (detecção de tráfego anormal). Em seguida, grava os resultados no HBase via API HBase.

• Processamento em lote (Spark): Executa jobs em lote periódicos sobre dados de bancos de dados relacionais, realiza operações de ETL (cálculo de tags de usuário, deduplicação de dados) e grava a saída no HBase.

Etapa 2: Armazenar dados em escala

Gerencie diferentes padrões de acesso com duas camadas de armazenamento.

• OSS-HDFS: Armazena logs brutos e HFiles do HBase de forma persistente. O JindoCache reduz a latência de leitura e gravação do OSS-HDFS.

• Cluster HBase: Lida com gravações em tempo real (registros de comportamento do usuário) e consultas pontuais de alta frequência (status de pedidos).

Etapa 3: Consultar comportamento do usuário

Execute consultas Phoenix SQL no HBase para extrair insights comportamentais destinados ao marketing de precisão. Por exemplo, identifique usuários que compraram uma categoria de produto e clicaram em anúncios relacionados nos últimos sete dias.