Selecciona un componente para conocer su función o sigue el recorrido de un evento de pago.
Ejemplo ilustrativo, sin datos reales de pagos. Valkey enriquece el procesamiento y OpenMetadata documenta el linaje de todo el flujo.
01 Almacenamiento
02 Acceso a los datos
03 Ingesta
04 Procesamiento
05 Gobierno del dato
06 Plataforma
Flujo de datos
El ejemplo comienza con un evento de pago publicado en Kafka. El registro conserva el evento para que los procesos posteriores puedan consumirlo y volver a leerlo cuando sea necesario.
Flink consume el flujo y mantiene las variables de actividad utilizadas para evaluar el pago. El procesamiento combina el evento con información operativa, como las agregaciones temporales y el perfil del cliente.
El perfil del cliente y los contadores operativos se consultan en Valkey para enriquecer el procesamiento de Flink. Esta etapa representa una lectura de la capa en memoria, sin llevar cada consulta al warehouse.
El recorrido representa después la escritura del evento y sus resultados en tablas Iceberg. Un snapshot identifica el estado de los datos que podrán utilizar los procesos analíticos y las revisiones posteriores.
El almacenamiento de objetos conserva los ficheros Parquet, metadatos y snapshots sobre los que se apoyan las tablas Iceberg. Esta etapa muestra la base física del lakehouse compartida por los distintos motores.
En el tratamiento por lotes, Spark valida y transforma los datos del lakehouse en conjuntos preparados para análisis. Los resultados vuelven a Iceberg y alimentan las cargas posteriores del warehouse.
Cloudberry o Greenplum permiten consultar y agregar los datos preparados mediante SQL distribuido. En este ejemplo, esa información alimenta informes y análisis de negocio con un origen de datos identificable.
OpenMetadata relaciona las tablas y los informes con sus fuentes, transformaciones y responsables. El recorrido termina mostrando ese linaje, aunque el catálogo y los controles de calidad actúan de forma transversal sobre la plataforma.
Casos de uso de la plataforma
Informes de negocio trazables
Un flujo gobernado conecta las transacciones con tablas versionadas e informes cuyo origen puede seguirse hasta la fuente.
Capturar el evento
Kafka recibe eventos y cambios conservando la marca temporal de origen.
Kafka
Guardar los datos originales
Iceberg registra los eventos sin modificar y conserva snapshots consultables.
Iceberg
Validar y transformar
Spark aplica reglas de calidad y separa los registros que requieren revisión.
Spark
Cargar el warehouse
Cloudberry recibe los datos preparados con particiones y distribución adaptadas a las consultas.
Cloudberry
Calcular el informe
Los modelos SQL expresan las reglas del informe y sus referencias versionadas.
SQL
Registrar el linaje
OpenMetadata enlaza los campos del informe con sus tablas y ubicaciones de origen.
OpenMetadata
Archivar las evidencias
Se conservan el informe, los identificadores de snapshots y el registro de consultas.
Object storage
Fraude y prevención del blanqueo en tiempo real
El procesamiento de eventos combina perfiles, reglas y modelos para apoyar decisiones e investigaciones sobre una misma base de datos.
Recibir autorizaciones
Kafka ordena los eventos relacionados mediante particiones por tarjeta o cuenta.
Kafka
Añadir contexto de comportamiento
Flink incorpora agregados temporales y patrones al evento recibido.
Flink
Consultar el perfil
Valkey o GemFire aportan el perfil, los límites y la valoración de riesgo.
Valkey / GemFire
Ejecutar el modelo
Flink calcula el score y registra la versión y características utilizadas.
Flink
Devolver la decisión
La decisión vuelve al sistema de autorización y se publica como evento.
GemFire
Indexar la investigación
OpenSearch reúne alertas, scores y características para la investigación.
OpenSearch
Realimentar el entrenamiento
Los resultados confirmados se guardan en Iceberg para nuevos entrenamientos con Spark.
Iceberg
Visión 360 del cliente
La plataforma reúne datos de canales, CRM y sistemas de negocio y los sirve a analítica, aplicaciones y equipos de atención.
Ingerir datos de los canales
Kafka y CDC recogen cambios de las fuentes y los trasladan a Iceberg.
Kafka / CDC
Resolver la identidad
Spark relaciona registros con reglas de identificación y correspondencia.
Spark
Construir la tabla de cliente
Iceberg conserva atributos, productos y permisos con historial de snapshots.
Iceberg
Ofrecer analítica SQL
Cloudberry expone el modelo de cliente y transacciones a herramientas BI.
Cloudberry
Publicar perfiles en memoria
Valkey sirve el perfil actual a aplicaciones y equipos de atención.
Valkey
Buscar perfiles
Solr permite buscar nombres, cuentas y documentos sin identificador exacto.
Solr
Gobernar los datos personales
OpenMetadata registra clasificación, responsables y contexto del consentimiento.
OpenMetadata
Repatriación de un data warehouse cloud
La migración mueve datos, esquemas, pipelines y consumidores con ejecución paralela y comprobación de resultados antes del cambio.
Inventariar el origen
Se revisan esquemas, consultas, conexiones BI, cuentas de servicio y costes.
Assessment
Exportar a formatos abiertos
Los datos se exportan a Parquet y se registran como tablas Iceberg.
Iceberg
Reconstruir los esquemas
Cloudberry adapta DDL, particiones y distribución a los patrones de consulta.
Cloudberry
Trasladar pipelines y consultas
Airflow, Spark y dbt incorporan los procesos y validan diferencias de dialecto.
Airflow / dbt
Ejecutar en paralelo
Se comparan los resultados y se documentan las diferencias entre plataformas.
Validation
Migrar por dominios
Cada dominio cambia sus consumidores con aceptación y vuelta atrás definidas.
Cutover
Cerrar y documentar
La retirada del origen respeta las retenciones acordadas y conserva evidencias.
Evidence
Logs y auditoría en infraestructura propia
Logs de aplicaciones y plataforma se recogen, normalizan e indexan, con archivo y políticas de retención documentadas.
Recoger los logs
Kafka recibe logs de aplicaciones, bases de datos, red y plataforma.
Kafka
Normalizar y enriquecer
Flink aplica un esquema común y etiquetas de sistema, entorno y clasificación.
Flink
Indexar datos recientes
OpenSearch ofrece búsquedas, paneles y alertas para los equipos operativos.
OpenSearch
Archivar datos históricos
Los datos antiguos pasan a snapshots y tablas Iceberg sobre objetos.
Iceberg
Consultar la evidencia
La búsqueda permite reconstruir accesos y actuaciones dentro del periodo conservado.
OpenSearch
Comprobar retención e integridad
Bloqueo de objetos, checksums y catálogo documentan la protección del archivo.
Object storage
Base de datos para IA privada
Conjuntos de datos gobernados, características e índices documentales alimentan modelos y asistentes con trazabilidad de las fuentes utilizadas.
Preparar datos gobernados
Iceberg identifica mediante snapshots los conjuntos utilizados por cada modelo.
Iceberg
Calcular características
Spark comparte las definiciones entre Iceberg para entrenamiento y Valkey para inferencia.
Spark / Valkey
Procesar documentos
Spark prepara fragmentos y embeddings conservando documento y página de origen.
Spark
Indexar texto y vectores
OpenSearch combina búsqueda por palabras clave y similitud vectorial.
OpenSearch
Recuperar contexto autorizado
El RAG filtra los pasajes según los permisos del usuario antes de enviarlos al modelo.
RAG
Registrar preguntas y respuestas
Se conservan consultas, fuentes recuperadas y respuestas para su revisión.
OpenSearch
Patrones de despliegue
Starter: un centro y un clúster Kubernetes
Kafka, RabbitMQ y CDC alimentan objetos RustFS y tablas Iceberg; Spark procesa los datos y Cloudberry, Valkey y OpenSearch los sirven. OpenMetadata aporta catálogo y linaje sobre Kubernetes.
Ejemplo de arquitectura de la referencia. Las cifras son ilustrativas; el dimensionamiento y la disponibilidad se validan por proyecto.
Ingesta
Kafka3 brokers
RabbitMQQuórum de 3 nodos
Conectores CDCSistemas centrales, tarjetas y canales
Almacenamiento lakehouse
Almacenamiento de objetos RustFS4 nodos, codificación de borrado
Tablas IcebergACID, instantáneas
Procesamiento y acceso
Spark en KubernetesProcesos por lotes y calidad
Cloudberry1 coordinador, 4 segmentos
ValkeyAcceso en memoria
OpenSearchLogs y búsqueda
Consumo y plataforma
BI e informes de negocioHerramientas que consultan SQL
OpenMetadataCatálogo y linaje
Kubernetes en un centro12–16 nodos, ejemplo
Conexiones entre componentes
Conectores CDC → Kafka: Eventos de cambio
Kafka → Tablas Iceberg: Persistencia
RabbitMQ → Tablas Iceberg: Mensajes
Almacenamiento de objetos RustFS → Tablas Iceberg: Archivos
Tablas Iceberg → Spark en Kubernetes: Lectura / escritura
Spark en Kubernetes → Cloudberry: Carga armonizada
Cloudberry → BI e informes de negocio: SQL
Spark en Kubernetes → Valkey: Publicación de perfiles
Kafka → OpenSearch: Logs
OpenMetadata → Tablas Iceberg: Linaje
Kubernetes en un centro → Spark en Kubernetes: Ejecución
Enterprise: tres zonas en un centro de datos
Distribuye Kafka, almacenamiento y Kubernetes entre tres zonas. Spark y Flink cubren lotes y streaming; Cloudberry, Valkey o GemFire y Solr u OpenSearch ofrecen SQL, memoria y búsqueda, con gobierno en OpenMetadata.
Ejemplo de arquitectura de la referencia. Las cifras son ilustrativas; el dimensionamiento y la disponibilidad se validan por proyecto.
Ingesta
Kafka9 brokers, 3 zonas
RabbitMQColas con quórum
Ingesta CDC y de archivosSistemas centrales, tarjetas y tesorería
Almacenamiento lakehouse
RustFS / CephCodificación de borrado entre zonas
Tablas Iceberg600 TB–1,5 PB útiles, ejemplo
HDFSHistórico extenso, opcional
Procesamiento y acceso
Apache SparkProcesos por lotes y variables
Apache FlinkStreaming y puntuación
Cloudberry MPP8–16 segmentos con réplica
Valkey / GemFireMalla de datos en memoria
Búsqueda, gobierno y plataforma
Solr / OpenSearchBúsqueda, logs y vectores
Kubernetes en 3 zonasOpenMetadata, monitorización y copias
Apache Flink → Tablas Iceberg: Actualización en streaming
Apache Flink → Valkey / GemFire: Estado y decisiones
Apache Spark → Cloudberry MPP: Carga armonizada
Tablas Iceberg → Cloudberry MPP: Tablas externas
Cloudberry MPP → Solr / OpenSearch: Extractos
Kubernetes en 3 zonas → Cloudberry MPP: Operación
DR: dos centros con replicación activa
Replica eventos, objetos y servicios entre un centro principal y otro secundario mediante MirrorMaker 2, replicación de buckets y servicios de reserva. Incluye operación común, selección del centro activo y simulacros de recuperación; los objetivos se acuerdan por proyecto.
Ejemplo de arquitectura de la referencia. Las cifras son ilustrativas; el dimensionamiento y la disponibilidad se validan por proyecto.
Centro principal
Kafka y RabbitMQIngesta principal
Objetos + IcebergLakehouse principal
Warehouse, memoria y búsquedaAcceso principal
Replicación
MirrorMaker 2Topics y posiciones
Replicación de bucketsContinua y cifrada
Reserva y malla WANWarehouse y GemFire
Centro secundario
Kafka y RabbitMQIngesta secundaria
Objetos + IcebergLakehouse secundario
Warehouse, memoria y búsquedaInformes y recuperación
Operación
Operación unificadaMonitorización, copias y procedimientos
Dirección del tráficoSelección del centro activo
Simulacro periódico de conmutaciónEvidencias de recuperación
Conexiones entre componentes
Kafka y RabbitMQ → Objetos + Iceberg: Ingesta
Objetos + Iceberg → Warehouse, memoria y búsqueda: Acceso
Kafka y RabbitMQ → MirrorMaker 2: Réplica de eventos
Objetos + Iceberg → Replicación de buckets: Replicación
Warehouse, memoria y búsqueda → Reserva y malla WAN: Envío y replicación
MirrorMaker 2 → Kafka y RabbitMQ: Aplicación
Replicación de buckets → Objetos + Iceberg: Aplicación
Reserva y malla WAN → Warehouse, memoria y búsqueda: Aplicación
Operación unificada → Warehouse, memoria y búsqueda: Monitorización
Operación unificada → Warehouse, memoria y búsqueda: Monitorización
Dirección del tráfico → Warehouse, memoria y búsqueda: Activo
Simulacro periódico de conmutación → Warehouse, memoria y búsqueda: Validación
Una plataforma lakehouse integrada
Nuxia Data Intelligence reúne almacenamiento, ingestión, procesamiento, consulta y gobierno del dato. Los formatos abiertos permiten que distintos motores trabajen sobre los mismos conjuntos de datos. La arquitectura combina servicios existentes, con selección y validación de versiones por proyecto.
Arquitectura por capas
Base: Kubernetes sobre virtualización o servidores físicos, con identidad, red y observabilidad comunes.
Ingestión: Kafka para eventos, RabbitMQ para mensajes y conectores CDC para cambios de bases de datos.
Almacenamiento: objetos S3 con RustFS o Ceph, ficheros Parquet y tablas Iceberg; HDFS para históricos existentes.
Procesamiento: Spark para lotes y aprendizaje automático, Flink para flujos y Airflow para orquestación.
Consulta: Cloudberry o Greenplum para SQL analítico; Valkey y GemFire/Geode para memoria; Solr y OpenSearch para búsqueda.
Gobierno transversal: OpenMetadata conecta catálogo, clasificación, responsables, calidad y linaje entre las capas.
Del origen al consumo del dato
Los sistemas de negocio publican eventos y cambios. La ingestión conserva datos originales y posiciones para reproducir procesos. Spark o Flink validan y transforman; Iceberg registra snapshots; SQL, BI, aplicaciones e IA consumen la información. El catálogo enlaza las transformaciones con sus fuentes y propietarios.
Casos de uso
Reporting trazable: enlazar cada cifra con sus fuentes, reglas de calidad y snapshot de entrada.
Analítica de riesgo y negocio: trabajar sobre histórico completo con SQL y procesamiento distribuido.
Datos para IA: combinar búsqueda documental, características operativas y evaluación de modelos.
Cómo abordar la migración
Empezamos por un dominio de datos y un resultado medible. Inventariamos fuentes y procesos, montamos la base, incorporamos el primer flujo y contrastamos resultados con el sistema actual. Después ampliamos dominios y consumidores, ensayamos recuperación y transferimos la operación. El TCO incluye hardware, energía, licencias y operación; se compara con el coste actual.
Las versiones, licencias, compatibilidades, cobertura de soporte y objetivos de servicio se concretan tras revisar el entorno. El dimensionamiento y los resultados se validan con cargas y pruebas representativas.
Preguntas frecuentes
¿Podemos incorporar solo una parte del catálogo?
Sí. La evaluación determina qué conservar, qué integrar y qué cambiar. La arquitectura puede empezar por una base de datos, un flujo de eventos o un dominio lakehouse y ampliarse por etapas.
¿Puede ejecutarse en un entorno desconectado?
Se evalúa por componente y versión: dependencias, imágenes, licencias, actualizaciones y observabilidad. Cuando se requiere aislamiento, el diseño incluye repositorios internos y un proceso controlado de importación y verificación.
