Discutiendo el almacenamiento de datos para la industria de servicios financieros con Vincent Rainardi

Con el lanzamiento de Astera Constructor DW A la vuelta de la esquina, hemos estado hablando con algunos de los líderes de opinión más importantes de la industria para conocer su opinión sobre la industria tal como está, cómo está evolucionando y dónde ven que la automatización del almacén de datos encaja en el panorama general.

Para nuestra segunda entrevista de esta serie, nos sentamos con Vincent Rainardi, un veterano en el ámbito del almacenamiento de datos. Ha trabajado en proyectos para clientes como Barclays, Lloyds Bank, Toyota y Avery Dennison. Vincent también ha escrito extensamente sobre almacenamiento de datos y BI, y es autor de un libro. Creación de un almacén de datos: con ejemplos en SQL Server y un popular blog en el tema.

En esta discusión, profundizamos en las variadas experiencias y conocimientos de Vincent sobre el almacenamiento de datos, con un enfoque específico en la industria de servicios financieros, donde ha acumulado una experiencia sustancial a lo largo de los años.

¿Podría contarme un poco sobre su participación en el almacenamiento de datos? ¿Cuándo comenzó a trabajar en estos proyectos y qué roles ha desempeñado en el proceso de desarrollo a lo largo de los años?

Comencé a trabajar en almacenamiento de datos en 1996, construyendo un almacén de datos y BI para un fabricante de automóviles. En ese momento, DW & BI se llamaba DSS y EIS / MIS (Sistema de apoyo a las decisiones y Sistema de información de gestión / ejecutivos). Luego dejé DW / BI por algunos años, pero volví a involucrarme en este espacio en 2005 cuando leí el libro de Ralph Kimball sobre almacenamiento de datos. (Data Warehouse Toolkit) y me apasionó mucho. Después de eso, escribí muchos artículos sobre el tema para varios sitios web y mi blog. En 2007, publiqué un libro que cubría muchas de mis ideas sobre el almacenamiento de datos.

Desde 2005 he trabajado en varios proyectos de almacenamiento de datos, desarrollando almacenes de datos para bancos, administradores de activos, aseguradoras, fabricantes, proveedores de atención médica, minoristas y empresas de comercio electrónico. Durante las implementaciones, mis responsabilidades principales son como arquitecto de almacenamiento de datos, es decir, diseñar la arquitectura de flujo de datos, los modelos de datos y las plataformas físicas, incluidas SQL Server, Oracle, Teradata, Hadoop, Azure.

También me desempeñé en una variedad de otros roles, incluso como analista de negocios (requisitos comerciales, especificaciones funcionales), diseñador de BI (definición de paneles y visualizaciones), desarrollador de BI (trabajando con plataformas como QlikView, Spotfire, Tableau, SSRS, SSAS). , ProClarity, Business Objects, Strategy Companion), desarrollador ETL (SSIS, Informatica, utilidades Teradata, SQL), tester y director de proyectos.

Ya ha hablado un poco antes sobre las diferencias entre el almacenamiento de datos y la BI: ¿cómo cree que estos dos conceptos se complementan y en qué se diferencian en principio?

En la práctica, se usan indistintamente, pero en realidad son diferentes. BI es el front-end (paneles, informes, visualizaciones) y el almacén de datos es el back-end (base de datos, almacenamiento, ETL, archivos). Sin embargo, se complementan entre sí y, en la práctica, se utilizan juntos. Hoy en día, el backend no tiene por qué ser un almacén de datos; puede ser un lago de datos. Y la interfaz no tiene por qué ser BI; puede ser aprendizaje automático.

Tiene una gran experiencia en servicios financieros. ¿Cuáles diría que son los casos de uso más comunes que ve en organizaciones en industrias como los seguros o la banca de inversión?

Los casos de uso en seguros implican muchos análisis complejos. Por lo tanto, las organizaciones buscarán responder consultas sobre los tipos de primas brutas de mayor nivel ganadas, primas emitidas, cobertura de riesgo, costo del riesgo, ajustes de reclamos, cronogramas de reclamos, canales de ventas, rentabilidad del cliente, suscripción, tasas actuariales, riesgos de reaseguro, y flujo de caja.

En banca de inversión, estos análisis cubrirán riesgos de mercado, exposición de posiciones, actividades comerciales, informes regulatorios, investigación de mercado, liquidez, garantías, canalizaciones de acuerdos, cuentas de clientes, lucha contra el lavado de dinero, contrapartes, detección de fraude, gestión de carteras y pruebas de tensión de capital .

Hemos visto un aumento significativo en el volumen y la variedad de datos que se mueven a través de las empresas durante la última década. ¿Cómo ve la evolución del denominado almacén de datos tradicional para manejar estos requisitos?

Por lo tanto, el almacenamiento de datos tradicional ha evolucionado para incorporar tecnologías de lago de datos y big data. Los datos no estructurados se almacenan en lagos de datos, incluidos documentos, imágenes, videos, IoT y feeds de redes sociales, mientras que los datos estructurados (datos almacenados en formato tabular) se almacenan en el almacén de datos. Los lagos de datos generalmente se construyen en el sistema de archivos Hadoop en comparación con el almacén de datos, que generalmente se basa en bases de datos relacionales. Los almacenes de datos modernos también incorporan NoSQL, como bases de datos de gráficos y documentos, ya que algunos datos son más adecuados para este tipo de formatos. Eso cubre la variedad.

En lo que respecta al volumen, en los primeros años del almacenamiento de datos, las bases de datos MPP como Teradata, Oracle Exadata y Microsoft PDW eran una forma popular de manejar grandes volúmenes de datos mientras se mantenían los datos relacionales. Pero hoy en día, las tecnologías de big data se utilizan mucho más.

¿Cuál es su opinión sobre el lago de datos? ¿Tiene un lugar en el sistema de BI moderno? ¿Complementa el almacén de datos o es una alternativa viable?

Si, lo hace. Los almacenes de datos modernos utilizan lagos de datos como un área de preparación que permite a los usuarios y las tecnologías frontend ML acceder a datos sin procesar. Siempre que no busque integrar datos, el lago de datos es una alternativa viable. Este tipo de caso de uso se ve a menudo en proyectos donde los datos están aislados (separados de otras funciones) y el tiempo de desarrollo es mínimo, en cuyo caso los lagos de datos son muy efectivos. Un buen ejemplo de esto sería un proyecto de detección de fraude basado en aprendizaje automático en un banco o un proyecto en el que se debe cumplir un requisito específico de informes regulatorios en un plazo de tres meses. Cuando estos silos se eliminan más adelante (es decir, cuando otras funciones empresariales necesitan acceder al resultado de la predicción), la salida del modelo se puede almacenar en el almacén de datos para los usuarios intermedios.

Sin embargo, en la mayoría de los escenarios empresariales, deberá integrar los datos. Por ejemplo, una aseguradora o un administrador de activos deberá crear una vista unificada a partir de datos sobre valores, emisores, políticas y clientes para desarrollar una imagen precisa de su empresa.

Ha dicho en el pasado que comprender el negocio podría ser la parte más crítica del desarrollo del almacén de datos. ¿Cómo se aseguraría de que los requisitos comerciales se traduzcan fielmente en la arquitectura de datos?

Sí, la comprensión empresarial es muy importante. No es posible diseñar un buen modelo de datos sin una buena comprensión del negocio. Imagínese si tuviera la tarea de diseñar un almacén de datos ESG (ambiental, social, de gobierno), pero no tuviera idea de qué era ESG. O un data mart de suscripción, pero nunca trabajó en seguros. No es posible que sepa cómo deberían verse las tablas de hechos y dimensiones. Un buen arquitecto de datos debe estar interesado en el meollo del asunto. Supongamos que está diseñando un mercado de atribución de rendimiento para un administrador de inversiones. Es esencial que conozca la diferencia entre rendimientos aritméticos y geométricos, curvas de rendimiento y factores de interacción. Lamentablemente, algunos arquitectos de datos no están interesados ​​en estos detalles comerciales esenciales. Están más interesados ​​en las partes técnicas.

La mejor manera de asegurarse de que los requisitos comerciales se incorporen bien en el modelo de datos es ejecutando varios escenarios comerciales, probando si todos los escenarios pueden satisfacerse consultando el modelo de datos mediante una simple consulta SQL. Si para eso necesitas una consulta compleja, el modelo de datos no está bien diseñado. Esto suele ser la caída de un lago de datos; no satisfacen escenarios comerciales complicados. Y este es el quid de todo: escribir bien esos escenarios; necesita tener un buen conocimiento del negocio.

En una publicación de blog anterior, escribió acerca de cuántas organizaciones de servicios financieros todavía usan Excel para generar informes y análisis. ¿Considera que esta práctica cambiará con herramientas de visualización más sofisticadas que se convertirán en algo común, o continuaremos viendo este proceso en el futuro previsible?

Las empresas de servicios financieros seguirán utilizando Excel para el análisis y también para la elaboración de informes. Esta es la naturaleza humana porque los empleados en este dominio tienden a tener sólidas habilidades en Excel. Experimenté esta preferencia de primera mano en varios bancos y compañías de inversión. Incluso las organizaciones que utilizan plataformas como Tableau, Qlik o Power BI solicitaron una función de "exportación a Excel" para un análisis más detallado.

Aunque los informes y cuadros de mando estándar producidos por las herramientas de visualización son importantes (contienen datos formalizados en un formato fácilmente digerible), los usuarios necesitan realizar su propio análisis en muchos casos. Para eso, solicitan los datos sin procesar detrás de esos paneles en una herramienta con la que están mucho más familiarizados: Excel. Con los datos brutos a mano, pueden agrupar los datos de manera diferente, aplicar ciertos filtros, etc., todo de acuerdo a sus necesidades.

Recuerde, estos son analistas financieros, conocedores de números, personas inteligentes; lo que hacen es analizar datos y procesar números. El consumo de informes estáticos nunca satisfará todas sus necesidades, por lo que generalmente no es una buena idea tratar de satisfacer todas las necesidades posibles en la herramienta de BI.

Ha habido un gran impulso para comenzar a mover los almacenes de datos a la nube en plataformas como Google BigQuery o Amazon Redshift en los últimos años. ¿Cuál es su opinión sobre las ventajas de la implementación en la nube? ¿Seguiría recomendando seguir con las bases de datos locales en algunos casos?

Las principales ventajas son la subcontratación de recursos humanos y la flexibilidad en los recursos informáticos. Con un almacén de datos en la nube, no necesita pagar a muchas personas internamente para mantener los servidores, el almacenamiento, la red, la seguridad, las copias de seguridad y los procesos de recuperación ante desastres. Si necesita un nuevo servidor de base de datos, no tendrá que esperar tres semanas para comprar, configurar, instalar, adjuntar almacenamiento, etc. En su lugar, obtiene una mayor capacidad del servidor a pedido y paga por hora.

Esta propuesta de valor no solo es interesante para las pequeñas empresas, sino también para las grandes corporaciones que a menudo se preguntan: "¿En qué negocio debería centrarme?". Ya sea que se trate de una empresa minorista, de telecomunicaciones o financiera, la respuesta ciertamente no es "el negocio de los servidores" ni "el negocio de la infraestructura de TI". Así que subcontratas. Con la infraestructura en la nube, puede aumentar y disminuir la potencia informática y la memoria cuando lo necesite. Apaga los servidores de prueba y desarrollo cuando no están en uso por la noche y paga por horas.

Cuando se trata de servidores de almacenamiento de datos potentes, el costo de configuración interno (local) es prohibitivo. Las habilidades requeridas por los empleados también son prohibitivas, ya que se requieren muchas habilidades especializadas diferentes, desde SAN hasta seguridad, desde Docker hasta Yarn. Por lo tanto, recomendaría una implementación basada en la nube en lugar de un almacén de datos local. Ese es el argumento para usar Google BigQuery, Amazon Redshift y Azure Dedicated SQL Pool (anteriormente SQL DW, PDW, APS).

Sin embargo, suponga que no es un proyecto nuevo y tiene que mejorar un almacén de datos existente que se encuentra en las instalaciones con muchos sistemas locales conectados a él. En ese caso, el costo de migrar todos esos sistemas / aplicaciones a la nube es enorme. Digamos por el bien del argumento que costaría $ 2 millones adicionales y tres años completar este tipo de proyecto. No tiene sentido comercial gastar esos 2 millones de dólares sin funciones comerciales adicionales. Manténgalo en las instalaciones, realice las mejoras en las instalaciones y, mientras tanto, cree lentamente su nuevo sistema en la nube. Actualmente, aproximadamente el 25% de los presupuestos de TI se destinan al mantenimiento de los sistemas y la infraestructura existentes. Este es el grupo del que debe extraer para impulsar una migración lenta a la nube.

Te he visto tocar el gran debate entre ETL y ELT antes. Cuando se trata de cargar datos en el almacén de datos, ¿hay algún enfoque que prefiera? ¿O debe decidirse caso por caso?

Debe decidirse caso por caso. Depende de la infraestructura. Depende del lago de datos. Depende de la herramienta de ingestión de datos. Y depende de la plataforma de almacenamiento de datos. En última instancia, no importa si está utilizando ETL, ELT o ELTLT; puede realizar la ingestión de datos de varias formas diferentes. Puede organizarlo una, dos o ninguna. Transfórmalo una vez, dos veces o ninguna. Solo necesita elegir el enfoque más apropiado para cada canalización y cada situación.

Ya sea ETL o ELT, lo "imprescindible" en la ingestión de datos son las pruebas automatizadas. Nimrod Avissar lo explica bien esta página. Ese es el enfoque que prefiero en ETL / ELT: enfoque de prueba automatizado.

En cuanto al proceso de desarrollo del almacén de datos en sí, ¿cree que la tecnología ágil o en cascada puede satisfacer mejor los requisitos de BI en constante cambio?

No se trata de ágil o en cascada (ágil, por supuesto, ¿quién quiere cometer una gran parte de una vez?). El proceso de desarrollo del almacén de datos se trata de operaciones de desarrollo. Esta disciplina de la ingeniería está madura ahora. Necesita tener un canal de lanzamiento, un tablero de sprint, acumulación, control de fuente, control de cambios, registro de errores y gestión de incidentes. Un equipo de desarrollo de almacén de datos debe tener automatización de DevOps, es decir, el proceso de lanzamiento debe automatizarse, desde el control de origen, la solicitud de extracción en la rama de lanzamiento, la implementación en una prueba, la ejecución de pruebas automatizadas y la implementación en producción.

CI / CD solía estar asociado con el desarrollo de aplicaciones, no con el desarrollo de almacenamiento de datos. Pero ahora es imprescindible. Si ejecuta un equipo de desarrollo de almacenamiento de datos sin él, incurrirá en muchos costos adicionales cada mes. O peor aún, sacrificar la calidad de construcción del almacén de datos.

En su blog, ha escrito sobre algunos elementos clave que determinan la efectividad de su almacén de datos, incluida la disponibilidad de los datos, la seguridad de los datos, la calidad de los datos y, por supuesto, el rendimiento de las consultas / cargas. ¿Cuál dirías que es el factor más importante?

El elemento más importante que determina la efectividad de un almacén de datos es si aborda o no problemas comerciales y casos de uso. Al final del día, podría utilizar su DW para crear informes de clientes, paneles de gestión, informes normativos o análisis comerciales generales. Aún así, si no resuelve su problema comercial, entonces simplemente no es efectivo. En este caso, la falla generalmente se puede vincular a una de estas tres cosas:

1. Falta de datos particulares, por ejemplo, datos sobre un producto o cliente importante,
2. Problemas de calidad de los datos, por ejemplo, datos incorrectos,
3. Dificultad para consultar datos, por ejemplo, los datos están en el almacén pero no aparecen en los informes.

Yo diría que los datos incorrectos son particularmente dañinos para la empresa, especialmente cuando han tomado medidas basadas en esos datos. Por ejemplo, si utilizó los datos de rendimiento del almacén para crear una hoja de datos y expresó incorrectamente el rendimiento del fondo, es tanto un riesgo para la reputación como un riesgo financiero enorme. Esto no solo puede resultar en una sanción sustancial por parte de las autoridades financieras, sino que sus clientes podrían dirigirse a la salida en función de las cifras engañosas que ha citado, lo que provocaría salidas masivas y un futuro comercial sombrío en general.

En comparación, si se ejecuta una consulta de una hora durante todo el día, eso no es nada, casi ningún daño financiero. Lo mismo ocurre con no tener datos particulares (disponibilidad de datos), no es un riesgo tan masivo en comparación con la publicación / envío de datos incorrectos a las autoridades o clientes. Por otro lado, si se roban los datos de sus clientes, eso también puede dañar la confianza del cliente, provocando un éxodo de clientes, lo que podría dejarlo sin negocio en el futuro previsible.

Yo diría que la calidad y la seguridad de los datos son los dos principales problemas de los que debe protegerse.

También ha analizado algunos de los pasos críticos en la construcción de un almacén de datos, es decir, el modelado de datos, la creación de procesos para la carga y entrega de datos y luego la arquitectura de estos procesos para garantizar la máxima eficiencia. ¿Cuál diría que es la parte más desafiante del desarrollo de un almacén de datos?

La parte más difícil del desarrollo del almacén de datos no es el modelado de datos, la carga de datos o la eficiencia del proceso, sino determinar qué arquitectura es el más adecuado.

Si eligió construir un lago de datos, mientras que lo que realmente necesita es un almacén de datos dimensional (debido a su naturaleza integrada), entonces estaba yendo en la dirección equivocada desde el principio. Si decidió utilizar una tecnología de ingesta particular que ninguno de sus empleados tenía la habilidad para operar, ha realizado una inversión significativa que ha aumentado su riesgo y ha creado retrasos evitables en la implementación. Si decidió comprar un almacén de datos prediseñado, pero el modelo de datos no le convenía, fue como construir un rascacielos sobre una base débil.

 Lo que no vemos detrás de escena es lo que generalmente hace que el almacén sea un éxito, es decir, la elección de la arquitectura, las operaciones de desarrollo y el calidad de los datos cheques.

¿Dónde cree que encaja la automatización del almacén de datos aquí? ¿Cómo puede ayudar a reducir el esfuerzo y el tiempo dedicado a algunas de estas tareas? ¿Dónde ve el gran valor en lo que respecta a una herramienta especialmente diseñada?

El valor de la automatización del almacén de datos es la carga automática. Por ejemplo, muchas empresas de gestión de activos utilizan sistemas de gestión de inversiones estándar para gestionar sus carteras. Un almacén de datos dimensional que pueda cargar datos automáticamente desde ellos tiene mucho valor. Muchas grandes empresas de fabricación utilizan SAP como su sistema operativo central. Un almacén de datos que pueda cargar datos automáticamente desde SAP es valioso porque no es necesario desarrollar las canalizaciones para cargar los datos, lo que lleva mucho tiempo. En todos los casos, debe poder alterar el modelo dimensional como mejor le parezca.

La siguiente mejor opción es intentar automatizar la ingestión de datos. La integración de múltiples fuentes de datos en una dimensión es compleja (por ejemplo, dimensión del cliente, dimensión de la empresa, dimensión de seguridad) y automatizarla es aún más difícil. Podríamos estar tratando con archivos verticales o archivos incrementales, archivos CSV o Excel. Necesitamos poder pivotar, agregar y fusionar esos datos.

Además, no debemos asumir que la fuente de datos es un archivo que está listo para ser procesado; es posible que primero deba descifrarlo, descomprimirlo, renombrarlo o descargarlo. El núcleo de la integración de datos de múltiples fuentes implica un proceso llamado "coincidencia de datos", y podría ser una coincidencia en cascada en varios criterios. El segundo proceso central se llama "enriquecimiento de datos", por ejemplo, si el valor no tiene una calificación de S&P, un país de riesgo o un sector GICS, lo enriquecemos de una fuente externa como Bloomberg o FactSet.

El valor central de un almacén de datos es la dimensión integrada que se crea a partir de muchas fuentes. Una herramienta de automatización de almacenamiento de datos debe poder construir esta dimensión, no una dimensión de país o moneda, sino una dimensión de cliente o seguridad compuesta por varias tablas de origen.

¿Qué características y funcionalidades cree que son absolutamente esenciales para una herramienta de automatización de almacenamiento de datos eficaz?

Las funcionalidades que son absolutamente esenciales para una herramienta de automatización de almacenamiento de datos eficaz son:

1. Debe mantenerse actualizado con ERP, CRM o IMS (por ejemplo, SAP, Salesforce o ThinkFolio) a medida que cambian de versión.
2. Debe tener la capacidad de integrar múltiples fuentes para crear dimensiones complejas, es decir, la dimensión del cliente.
3. Debe tener la capacidad de preprocesar archivos de datos, por ejemplo, para recuperar o descargar archivos para su procesamiento.
4. Debe permitir la implementación y las pruebas automatizadas

Finalmente, ¿hacia dónde cree que se dirigirá el almacén de datos en el futuro? ¿Qué avances significativos (si los hay) prevé en este espacio?

Algunas personas piensan que pueden reemplazar dos años de desarrollo de almacén de datos con un desarrollo de lago de datos de tres meses. Esto es engañoso porque los datos del cliente o del producto que se cargan en esta última arquitectura no están integrados, por lo que no se pueden consultar. Y es posible que se olviden de incorporar controles de calidad de los datos o preparación operativa (por ejemplo, herramientas de monitoreo) en el sistema, lo que de otro modo requeriría el 30% de todo el esfuerzo. Por supuesto, algunos proyectos no necesitan integración y, en este caso, se puede usar un lago de datos, pero aún necesita crear controles de calidad de datos y preparación operativa.

Lo que veo venir en el futuro es la automatización de las pruebas y la automatización de los controles de calidad de los datos. No es demasiado difícil construir una herramienta que observe cada archivo entrante y realice verificaciones en columnas específicas, comparándolo con los datos de los últimos días. La otra cosa que se podría construir es una herramienta de BI que sea compatible con CI / CD, por ejemplo, basada en XML, por lo que se puede implementar desde el control de fuente a la producción automáticamente porque está basada en texto.

Y finalmente, hasta ahora, no existe una única herramienta de gobernanza de datos en el mercado que pueda escanear bases de datos, ETL y herramientas de BI y crear automáticamente linaje de datos desde los archivos de origen hasta el informe. Puede que no sea posible construir esta herramienta para cada una de las herramientas de base de datos, ETL y BI que existen, pero es posible hacer las principales. La clave para la gobernanza de datos es la automatización.

Astera DW Builder: una respuesta ágil a los desafíos de desarrollo de su almacén de datos

Astera DW Builder es una plataforma unificada que le permite implementar y consumir rápidamente modelos de datos enriquecidos con metadatos impulsados ​​por los requisitos del usuario final.

El producto ofrece una gama de funcionalidades listas para usar que puede aprovechar para crear un almacén de datos ágil que realmente satisfaga las necesidades de su empresa. Desde la implementación de reglas comerciales y convenciones de nomenclatura en el nivel lógico hasta la creación de canales de datos complejos que pueden recuperar datos automáticamente de los sistemas de origen elegidos, transformarlos de acuerdo con los requisitos de calidad de sus datos y cargarlos en una base de datos local o en la nube de su elección. , todo es posible gracias a nuestra solución sin código.

Ahora, le brindamos la oportunidad de obtener un primer vistazo exclusivo a la velocidad y la intuición de ADWB por sí mismo en un evento de lanzamiento de un extremo a otro que promete cambiar su forma de pensar sobre el almacenamiento de datos. Mira el evento de lanzamiento exclusivo aquí.