Hay muchas formas de analizar datos en tiempo real. En VTB, utilizamos la tecnología Change Data Capture (CDC) implementada en la herramienta Golden Gate Oracle: la velocidad es muy importante para nosotros, pero nos gustaría reducir la cantidad de datos transmitidos y la carga en la fuente. Y aunque el alcance principal de esta herramienta es la replicación de Oracle y MS SQL, a lo largo de los años de trabajo con CDC hemos acumulado varios casos interesantes, como la migración de datos entre plataformas o diferentes tipos de DBMS. Bajo el corte, compartiremos nuestra experiencia con Golden Gate.
¿Por qué necesitábamos CDC (Cambiar captura de datos)?
El uso diario de las tarjetas bancarias ha sido familiar desde hace mucho tiempo, y las personas, por regla general, no piensan que cada uso de un terminal de pago sea la transferencia rápida de cierta información al banco. Los volúmenes de datos están creciendo, y me gustaría procesarlos lo más rápido posible, incluso para enviar ofertas especiales en tiempo real, porque, como dicen, una buena cuchara para la cena. Y las herramientas ETL tradicionales (extraer, transformar, cargar - extraer, transformar, cargar) no son tan buenas para procesar datos sobre la marcha. Este es uno de los enlaces débiles: cuando los datos se toman de las tablas del sistema de origen, debe seleccionar solo nuevas filas o filas con cambios. Este enfoque carga adicionalmente el sistema fuente y aumenta la cantidad de datos transmitidos.
CDC captura los cambios de los registros de la base de datos en tiempo real. Por lo tanto, la fuente se carga mucho menos y la cantidad de datos transmitidos se reduce. Con esta tecnología, hemos reducido la necesidad de recursos informáticos para sistemas con un gran volumen de cambios transaccionales: después de todo, para la captura de datos incluso para los sistemas bancarios más cargados, son suficientes 1-2 núcleos de procesador en la fuente. Y si presentamos ETL, entonces tendríamos que comprar capacidades de procesador para leer los datos en paralelo.
Hemos estado utilizando la tecnología Oracle GoldenGate, la herramienta CDC de Oracle, durante varios años en VTB. Con su ayuda, llenamos el almacén de datos operativos y distribuimos las funciones de los sistemas de información en zonas "cálidas" y "calientes". El 90% de la aplicación OGG en el panorama de TI del banco está cargando datos de Oracle y MS SQL, pero, a excepción de la replicación, hace frente a otras tareas perfectamente. Veamos algunos ejemplos de nuestra práctica.
Caso 1. Informes en línea
Conocimos a GoldenGate en 2013. Luego, en nuestro complejo de procesamiento de tarjetas, las transacciones se procesaron simultáneamente y se prepararon los informes. La carga OLTP se mezcló con la carga DWH / DSS, y grandes muestras pesadas eliminaron la memoria caché de la memoria de la base de datos. Como resultado, las transacciones rápidas tuvieron que ir al disco duro, la velocidad de los servicios comerciales críticos estaba disminuyendo. Para descargar el núcleo de procesamiento, llevamos todos los procedimientos e informes que desarrollamos a una réplica "cálida" en Oracle Exadata.
Cómo replicar datos usando GoldenGate, lo describimos en detalle
aquí . En pocas palabras: para sistemas altamente cargados donde se mezclan diferentes tipos de cargas, los distribuimos a diferentes servidores OLTP y DWH / DSS, y para la sincronización entre ellos usamos GoldenGate. Este patrón de resaltar una réplica "cálida" fue útil en muchos otros casos. Por ejemplo, utilizamos el mismo enfoque en nuestro sistema antifraude: transferimos todos los informes a los sistemas integrados Oracle Exadata, les replicamos los datos mediante GoldenGate.
No hay sistemas sin fallas. Por ejemplo, si un desarrollador cambia los datos en el receptor, puede ocurrir un error de uso de datos y los procesos de GoldenGate se detendrán. Para excluir datos fuera de sincronización, usamos Oracle GoldenGate Veridata como árbitro independiente. Esta herramienta no solo verifica los datos entre las fuentes y los receptores: lo principal es que Veridata elimina las diferencias. Es importante que cuando nos ocupamos de la replicación, Veridata garantice una comparación precisa de los datos y la detección de registros perdidos. Obtenemos un informe completo con los resultados de la comparación, que se puede presentar a colegas incrédulos.
Caso 2. Informes y etapas consolidadas en almacenamiento en línea
Un caso separado está asociado con la construcción del almacenamiento operativo. La dificultad radica en el hecho de que, además de los informes operativos, estamos preparando datos para el almacenamiento corporativo (puesta en escena). Sucede que necesita generar informes operativos basados en datos que se recopilan de varios sistemas diferentes. Y es más conveniente hacerlo a nivel de almacenamiento en línea. Para obtener datos a alta velocidad y con una carga mínima de recursos, una vez más aplicamos GoldenGate.
A modo de comparación, expliquemos cómo encontramos el delta de cambios en algunos de nuestros sistemas anteriormente. Si el sistema en sí no permitía que el delta se resaltara o cambiara datos retroactivamente, entonces la tabla de la fuente de 10 TB se comparó con la tabla de 10 TB en el receptor del día anterior. Estos 10 TB tuvieron que capturarse primero en la fuente, y la carga cayó no solo en el sistema fuente, la CPU, la memoria, sino también en la red de datos, así como en el sistema involucrado en la comparación. ¡Y todo esto para encontrar el delta de nuevos datos en 0.01%!
GoldenGate no crea prácticamente ninguna carga en la fuente: los CDC simplemente leen las revistas y producen un delta terminado. Esto le permite ahorrar seriamente en infraestructura. No importa quién sea el receptor: un repositorio tradicional basado en Oracle, MSSQL, Teradata o simplemente productos Hadoop.
Tenga en cuenta que en este caso, las bases de datos Oracle se utilizaron como fuente y receptor. La solución ha demostrado ser efectiva, por lo que ahora estamos conectando todos los sistemas nuevos a un almacén de datos en línea común, y ahora no es solo Oracle. Otra ventaja de GoldenGate es que es adecuado para descargar datos de la mayoría de las bases de datos utilizadas en el panorama de TI del banco.
Caso 3. Ofertas personales a clientes en tiempo real.
Ya mencionamos análisis de transmisión, es decir, ofertas de oferta en tiempo real (RTO) a clientes en tiempo real. Los camaradas superiores dicen que el éxito en el negocio bancario depende directamente de qué tan bien conozca a su cliente y qué tan relevante pueda hacerle una oferta. En otras palabras, la probabilidad de que el cliente aproveche la oferta del banco es inversamente proporcional a la velocidad de la respuesta del banco a las necesidades del cliente.
Como funciona Por ejemplo, un historial de transacciones muestra que un cliente compra en una licorería todos los viernes. El geo-posicionamiento lo detecta en un centro comercial, donde hay una tienda de esta red, y a través de una aplicación móvil le enviamos una oferta personal de descuento a una tienda gourmet en el mismo centro comercial. Tal caso es el más interesante para el banco; le permite crear marcas compartidas y ofertas conjuntas. Los clientes pueden ser individuos y organizaciones.
Hay partes fuera de línea y en línea. En el primero, los clientes se segmentan previamente utilizando datos de todos los sistemas. Analistas y datos Los científicos estudian el comportamiento, los datos históricos y crean las llamadas trampas. Lo principal es detectar un evento significativo que pueda ser rastreado por una transacción de adquirente, una aplicación móvil u otras fuentes disponibles. Y este evento ya se procesa mediante análisis de transmisión, y la decisión se toma en el momento en función de las trampas preparadas.
El objetivo de GoldenCate de CDC es proporcionar un flujo de datos de eventos en tiempo real desde los sistemas fuente a la plataforma analítica. La licencia GoldenGate para Big Data también incluye Oracle Stream Analytics. Con su ayuda, los científicos de datos pueden procesar de forma independiente el flujo de datos en Spark Streaming, desarrollando la aplicación en un entorno visual.
Caso 4. Contraataque operacional a nuevos tipos de fraude.
Los sistemas antifraude son bastante cerrados, y con razón: cuanto menos personas se dediquen a los detalles, mayor será la seguridad. Hacen un gran trabajo al manejar casos estándar, pero a veces surgen situaciones que no se ajustan a los scripts estándar. Por lo tanto, es importante complementar estos modelos con escenarios no estándar. Estamos constantemente desarrollando nuevos modelos basados en la correlación de eventos de varios sistemas: transacciones con tarjeta y moneda, ubicación, operaciones de sistemas de pago, acciones en aplicaciones móviles, monitoreo de redes sociales. Para cambiar el modelo, debe seguir los procesos aceptados: solicitud comercial, configuración de tareas, pasar la aplicación a través de todas las etapas internas de implementación.
El año pasado, probamos la carga de datos utilizando Oracle GoldenGate para Big Data desde los sistemas tradicionales más activos, donde hubo muchas transacciones pequeñas, y desde nuestro sistema antifraude hasta el clúster principal en el dispositivo Big Data de Oracle. Tanto Hadoop como GoldenGate hicieron frente a la cantidad de datos transferidos, nos sorprendió un poco.
Terabytes por hora y otros hallazgos
En los últimos dos años, con GoldenGate, hemos duplicado el volumen de registros transferidos, hasta casi 1 TB por hora. Esto casi cierra nuestras necesidades en este momento. Desafortunadamente, hay física con la que nos encontramos. Pero para aumentar el rendimiento, se está trabajando activamente con el equipo de desarrollo de GoldenGate, por lo que esto está lejos del límite. Al mismo tiempo, estamos observando y probando soluciones CDC de otros proveedores, pero no encontramos ninguna razón para migrar desde Oracle GoldenGate. Por el momento, esta tecnología ha demostrado ser la más madura del mercado.