Seleciona um componente para conhecer a sua função ou segue um evento de pagamento.
Exemplo ilustrativo, sem dados reais de pagamentos. Valkey enriquece o processamento e OpenMetadata documenta a linhagem de todo o fluxo.
01 Armazenamento
02 Acesso aos dados
03 Ingestão
04 Processamento
05 Governação de dados
06 Plataforma
Fluxo de dados
O exemplo começa com um evento de pagamento publicado em Kafka. O registo conserva o evento para que os processos seguintes o possam consumir e reler quando necessário.
Flink consome o fluxo e mantém as características de atividade utilizadas para avaliar o pagamento. O processamento combina o evento com informação operacional, como agregações temporais e o perfil do cliente.
O perfil do cliente e os contadores operacionais são consultados em Valkey para enriquecer o processamento Flink. Esta etapa representa uma leitura em memória, sem enviar cada consulta para o warehouse.
O percurso representa depois a escrita do evento e dos resultados em tabelas Iceberg. Um snapshot identifica o estado dos dados disponível para processos analíticos e revisões posteriores.
O armazenamento de objetos guarda os ficheiros Parquet, metadados e snapshots que suportam as tabelas Iceberg. Esta etapa mostra a base de armazenamento do lakehouse partilhada pelos diferentes motores.
No processamento em lote, Spark valida e transforma os dados do lakehouse em conjuntos preparados para análise. Os resultados regressam a Iceberg e alimentam as cargas seguintes do warehouse.
Cloudberry ou Greenplum permitem consultar e agregar os dados preparados com SQL distribuído. Neste exemplo, a informação alimenta relatórios e análises de negócio com uma origem identificável.
OpenMetadata relaciona tabelas e relatórios com as suas fontes, transformações e responsáveis. O percurso termina mostrando essa linhagem, embora o catálogo e os controlos de qualidade atuem transversalmente na plataforma.
Casos de utilização da plataforma
Relatórios de negócio rastreáveis
Um fluxo governado liga transações, tabelas versionadas e relatórios rastreáveis até às fontes.
Capturar o evento
Kafka recebe eventos e alterações preservando a marca temporal de origem.
Kafka
Guardar os dados originais
Iceberg regista eventos sem alteração e conserva snapshots consultáveis.
Iceberg
Validar e transformar
Spark aplica regras de qualidade e separa registos que exigem revisão.
Spark
Carregar o warehouse
Cloudberry recebe dados preparados com partições e distribuição adequadas às consultas.
Cloudberry
Calcular o relatório
Os modelos SQL expressam regras do relatório e referências versionadas.
SQL
Registar a linhagem
OpenMetadata liga os campos às tabelas e localizações de origem.
OpenMetadata
Arquivar evidências
Conservam-se o relatório, identificadores de snapshots e registo de consultas.
Object storage
Fraude e prevenção do branqueamento em tempo real
O processamento de eventos combina perfis, regras e modelos para apoiar decisões e investigações sobre a mesma base de dados.
Receber autorizações
Kafka ordena eventos relacionados por partições de cartão ou conta.
Kafka
Adicionar contexto comportamental
Flink enriquece o evento com agregados temporais e padrões.
Flink
Consultar o perfil
Valkey ou GemFire fornecem perfil, limites e avaliação de risco.
Valkey / GemFire
Executar o modelo
Flink calcula o score e regista a versão e características utilizadas.
Flink
Devolver a decisão
A decisão regressa ao sistema de autorização e é publicada como evento.
GemFire
Indexar a investigação
OpenSearch reúne alertas, scores e características para investigação.
OpenSearch
Realimentar o treino
Os resultados confirmados ficam em Iceberg para novos treinos com Spark.
Iceberg
Visão 360 do cliente
A plataforma reúne dados de canais, CRM e sistemas de negócio para análise, aplicações e equipas de atendimento.
Ingerir dados dos canais
Kafka e CDC recolhem alterações das fontes e colocam-nas em Iceberg.
Kafka / CDC
Resolver a identidade
Spark relaciona registos com regras de identificação e correspondência.
Spark
Construir a tabela de cliente
Iceberg conserva atributos, produtos e permissões com histórico de snapshots.
Iceberg
Oferecer análise SQL
Cloudberry disponibiliza modelos de cliente e transações às ferramentas BI.
Cloudberry
Publicar perfis em memória
Valkey serve perfis atuais às aplicações e equipas de atendimento.
Valkey
Pesquisar perfis
Solr pesquisa nomes, contas e documentos sem identificador exato.
Solr
Governar dados pessoais
OpenMetadata regista classificação, responsáveis e contexto do consentimento.
OpenMetadata
Repatriação de um data warehouse cloud
A migração move dados, esquemas, pipelines e consumidores com execução paralela e validação antes da mudança.
Inventariar a origem
Revêem-se esquemas, consultas, ligações BI, contas e custos.
Assessment
Exportar para formatos abertos
Os dados são exportados para Parquet e registados como tabelas Iceberg.
Iceberg
Reconstruir os esquemas
Cloudberry adapta DDL, partições e distribuição aos padrões de consulta.
Cloudberry
Transferir pipelines e consultas
Airflow, Spark e dbt incorporam processos e validam diferenças de dialeto.
Airflow / dbt
Executar em paralelo
Comparam-se resultados e documentam-se diferenças entre plataformas.
Validation
Migrar por domínios
Cada domínio muda consumidores com aceitação e reversão definidas.
Cutover
Fechar e documentar
A retirada da origem respeita retenções acordadas e conserva evidências.
Evidence
Logs e auditoria em infraestrutura própria
Os logs de aplicações e plataforma são recolhidos, normalizados e indexados, com arquivo e políticas de retenção documentadas.
Recolher logs
Kafka recebe logs de aplicações, bases, rede e plataforma.
Kafka
Normalizar e enriquecer
Flink aplica um esquema comum e etiquetas de sistema, ambiente e classificação.
Flink
Indexar dados recentes
OpenSearch oferece pesquisas, painéis e alertas às equipas operacionais.
OpenSearch
Arquivar dados históricos
Dados antigos passam a snapshots e tabelas Iceberg sobre objetos.
Iceberg
Consultar evidências
A pesquisa reconstitui acessos e atividades no período conservado.
OpenSearch
Verificar retenção e integridade
Bloqueio de objetos, checksums e catálogo documentam a proteção do arquivo.
Object storage
Base de dados para IA privada
Conjuntos de dados governados, características e índices documentais alimentam modelos e assistentes com rastreabilidade das fontes.
Preparar dados governados
Iceberg identifica por snapshots os conjuntos usados por cada modelo.
Iceberg
Calcular características
Spark partilha definições entre Iceberg para treino e Valkey para inferência.
Spark / Valkey
Processar documentos
Spark prepara fragmentos e embeddings preservando documento e página de origem.
Spark
Indexar texto e vetores
OpenSearch combina pesquisa por palavras-chave e semelhança vetorial.
OpenSearch
Recuperar contexto autorizado
O RAG filtra passagens pelas permissões do utilizador antes de as enviar ao modelo.
RAG
Registar perguntas e respostas
Conservam-se consultas, fontes recuperadas e respostas para revisão.
OpenSearch
Padrões de implementação
Starter: um centro e um cluster Kubernetes
Kafka, RabbitMQ e CDC alimentam objetos RustFS e tabelas Iceberg; Spark processa os dados e Cloudberry, Valkey e OpenSearch disponibilizam-nos. OpenMetadata acrescenta catálogo e linhagem em Kubernetes.
Exemplo de arquitetura da referência. Os números são ilustrativos; o dimensionamento e a disponibilidade são validados por projeto.
Ingestão
Kafka3 brokers
RabbitMQQuórum de 3 nós
Conectores CDCSistemas centrais, cartões e canais
Armazenamento lakehouse
Armazenamento de objetos RustFS4 nós, codificação de apagamento
Tabelas IcebergACID, snapshots
Processamento e acesso
Spark em KubernetesProcessamento em lote e qualidade
Cloudberry1 coordenador, 4 segmentos
ValkeyAcesso em memória
OpenSearchLogs e pesquisa
Consumo e plataforma
BI e relatórios de negócioFerramentas que consultam SQL
OpenMetadataCatálogo e linhagem
Kubernetes num centro12–16 nós, exemplo
Ligações entre componentes
Conectores CDC → Kafka: Eventos de alteração
Kafka → Tabelas Iceberg: Persistência
RabbitMQ → Tabelas Iceberg: Mensagens
Armazenamento de objetos RustFS → Tabelas Iceberg: Ficheiros
Tabelas Iceberg → Spark em Kubernetes: Leitura / escrita
Spark em Kubernetes → Cloudberry: Carregamento harmonizado
Cloudberry → BI e relatórios de negócio: SQL
Spark em Kubernetes → Valkey: Publicação de perfis
Kafka → OpenSearch: Logs
OpenMetadata → Tabelas Iceberg: Linhagem
Kubernetes num centro → Spark em Kubernetes: Execução
Enterprise: três zonas num centro de dados
Distribui Kafka, armazenamento e Kubernetes por três zonas. Spark e Flink cobrem lotes e streaming; Cloudberry, Valkey ou GemFire e Solr ou OpenSearch oferecem SQL, memória e pesquisa, com governação em OpenMetadata.
Exemplo de arquitetura da referência. Os números são ilustrativos; o dimensionamento e a disponibilidade são validados por projeto.
Ingestão
Kafka9 brokers, 3 zonas
RabbitMQFilas com quórum
Ingestão CDC e de ficheirosSistemas centrais, cartões e tesouraria
Armazenamento lakehouse
RustFS / CephCodificação de apagamento entre zonas
Tabelas Iceberg600 TB–1,5 PB úteis, exemplo
HDFSHistórico extenso, opcional
Processamento e acesso
Apache SparkProcessamento em lote e variáveis
Apache FlinkStreaming e pontuação
Cloudberry MPP8–16 segmentos replicados
Valkey / GemFireGrelha de dados em memória
Pesquisa, governação e plataforma
Solr / OpenSearchPesquisa, logs e vetores
Kubernetes em 3 zonasOpenMetadata, monitorização e cópias
Ligações entre componentes
Ingestão CDC e de ficheiros → Kafka: Eventos
Kafka → Apache Flink: Fluxos
Kafka → Tabelas Iceberg: Persistência
RabbitMQ → Apache Flink: Mensagens
RustFS / Ceph → Tabelas Iceberg: Ficheiros
HDFS → Apache Spark: Histórico
Tabelas Iceberg → Apache Spark: Leitura / escrita
Apache Flink → Tabelas Iceberg: Upsert em streaming
Apache Flink → Valkey / GemFire: Estado e decisões
Replica eventos, objetos e serviços entre centros principal e secundário através de MirrorMaker 2, replicação de buckets e serviços de reserva. Inclui operação comum, escolha do centro ativo e simulações de recuperação; os objetivos são acordados por projeto.
Exemplo de arquitetura da referência. Os números são ilustrativos; o dimensionamento e a disponibilidade são validados por projeto.
Centro principal
Kafka e RabbitMQIngestão principal
Objetos + IcebergLakehouse principal
Warehouse, memória e pesquisaAcesso principal
Replicação
MirrorMaker 2Tópicos e offsets
Replicação de bucketsContínua e cifrada
Reserva e grelha WANWarehouse e GemFire
Centro secundário
Kafka e RabbitMQIngestão secundária
Objetos + IcebergLakehouse secundário
Warehouse, memória e pesquisaRelatórios e recuperação
Operação
Operações unificadasMonitorização, cópias e procedimentos
Encaminhamento de tráfegoSeleção do centro ativo
Simulação periódica de comutaçãoEvidências de recuperação
Ligações entre componentes
Kafka e RabbitMQ → Objetos + Iceberg: Ingestão
Objetos + Iceberg → Warehouse, memória e pesquisa: Acesso
Kafka e RabbitMQ → MirrorMaker 2: Réplica de eventos
Objetos + Iceberg → Replicação de buckets: Replicação
Warehouse, memória e pesquisa → Reserva e grelha WAN: Envio e replicação
MirrorMaker 2 → Kafka e RabbitMQ: Aplicação
Replicação de buckets → Objetos + Iceberg: Aplicação
Reserva e grelha WAN → Warehouse, memória e pesquisa: Aplicação
Operações unificadas → Warehouse, memória e pesquisa: Monitorização
Operações unificadas → Warehouse, memória e pesquisa: Monitorização
Encaminhamento de tráfego → Warehouse, memória e pesquisa: Ativo
Simulação periódica de comutação → Warehouse, memória e pesquisa: Validação
Uma plataforma lakehouse integrada
Nuxia Data Intelligence reúne armazenamento, ingestão, processamento, consulta e governação. Os formatos abertos permitem partilhar dados entre motores. As versões dos serviços são selecionadas e validadas por projeto.
Arquitetura por camadas
Base: Kubernetes sobre virtualização ou servidores físicos, com identidade, rede e observabilidade comuns.
Ingestão: Kafka para eventos, RabbitMQ para mensagens e conectores CDC para alterações nas bases.
Armazenamento: objetos S3 com RustFS ou Ceph, ficheiros Parquet e tabelas Iceberg; HDFS para históricos existentes.
Processamento: Spark para lotes e aprendizagem automática, Flink para fluxos e Airflow para orquestração.
Consulta: Cloudberry ou Greenplum para SQL; Valkey e GemFire/Geode para memória; Solr e OpenSearch para pesquisa.
Governação transversal: OpenMetadata liga catálogo, classificação, responsáveis, qualidade e linhagem.
Da origem ao consumo dos dados
Os sistemas publicam eventos e alterações. A ingestão preserva dados e posições para reprodução. Spark ou Flink validam e transformam, Iceberg regista snapshots e SQL, BI, aplicações e IA consomem resultados. O catálogo liga fontes e responsáveis.
Casos de utilização
Relatórios rastreáveis: ligar cada valor às fontes, regras de qualidade e snapshots.
Análise de risco e negócio: histórico completo com SQL e processamento distribuído.
Dados para IA: combinar pesquisa documental, características operacionais e avaliação.
Como abordar a migração
Começamos por um domínio e um resultado mensurável. Inventariamos fontes, criamos a base e comparamos o primeiro fluxo com o sistema atual. Depois alargamos domínios, ensaiamos recuperação e transferimos a operação. O TCO inclui equipamento, energia, licenças e operação.
Versões, licenças, compatibilidades, cobertura e objetivos de serviço são definidos após a análise do ambiente. O dimensionamento e os resultados são validados com cargas e testes representativos.
Perguntas frequentes
Podemos adotar apenas parte do catálogo?
Sim. A avaliação determina o que manter, integrar e mudar. Pode começar por uma base, um fluxo ou um domínio lakehouse e alargar por etapas.
Pode funcionar num ambiente isolado?
Avalia-se por componente e versão: dependências, imagens, licenças, atualizações e observabilidade. O isolamento exige repositórios internos e importações verificadas.
