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 uma programação 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 para o 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: Empregue o JindoSDK com a API HDFS para carregar arquivos CSV, Parquet e outros em massa no OSS-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 oferecer suporte à análise ad hoc das equipes de operações.

Etapa 3: Aplicar dados em sistemas downstream

Diversas aplicações de negócios consomem os dados processados.

• Ciência de dados: Disponibilize os dados processados por meio de serviços de api para sistemas downstream, como engines de controle de risco e recomendação.

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

• Análise preditiva: Envie resultados de processamento e dados de features 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: Estabeleça conexão via API JDBC com ferramentas como o DataV para 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 engines 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 a engine de análise StarRocks para mostrar o fluxo de dados ponta a ponta no cenário EMR OLAP.

Etapa 1: Coletar dados

Os dados chegam ao StarRocks provenientes 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 uma programação 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. Cada camada se baseia na anterior e pode ser reutilizada independentemente.

• Camada DIM (camada de dimensão): Armazena dados dimensionais, como atributos de usuário e categorias de mercadorias, e suporta análise 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 de retrocesso.

• Camada DWD (camada de detalhes do data warehouse): Aplica limpeza de dados, padronização de formato e associação básica 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 de consulta.

Etapa 3: Aplicar dados

Os dados organizados em camadas impulsionam três aplicações principais de negócios.

• 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 aqueles altamente ativos que não compraram nos últimos 30 dias.

• Business intelligence: Conecte-se via API JDBC ao 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ínuas 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: Realiza 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 ilustra como Flink, Paimon e OSS-HDFS trabalham juntos para construir uma data lakehouse de streaming que alimenta um painel em tempo real.

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

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

Etapa 2: Construir a data lakehouse de streaming

Flink e Paimon processam e armazenam dados em uma lakehouse estruturada e consultável.

• Flink: Como engine integrada de computação de dados em lote e fluxo, o Flink 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 com 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, permitindo acumulação e reutilização incremental de dados.

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

Etapa 3: Entregar insights de negócios

Os dados processados da lakehouse alimentam ferramentas de relatórios em tempo real e tomada de decisão.

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

• Conecte-se ao Quick BI para criar painéis que permitam a 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, com 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: Engine de consulta SQL para HBase. O Phoenix 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 em 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 a engine 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 (como cálculo de tags de usuário e deduplicação de dados) e grava a saída no HBase.

Etapa 2: Armazenar dados em escala

Duas camadas de armazenamento lidam com diferentes padrões de acesso.

• 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

As equipes de negócios executam consultas Phoenix SQL no HBase para extrair insights comportamentais para marketing de precisão. Um exemplo é encontrar usuários que compraram uma categoria de product e clicaram em anúncios relacionados nos últimos sete dias.