Información privilegiada sobre el desarrollo de almacenes de datos modernos con James Serra

By |2021-09-28T06:23:22+00:0018 de junio de 2021.|

Con la lanzamiento oficial de nuestra solución de almacenamiento de datos de un extremo a otro Astera DW Builder, hemos introducido una ruta mucho más rápida y ágil para diseñar e implementar almacenes de datos. Pero eso es solo el comienzo, estamos planeando algunas adiciones y actualizaciones importantes al producto durante el próximo año que agregarán un valor único a cualquier organización que busque evitar los problemas que vienen con el desarrollo tradicional del almacén de datos.

Para nuestra tercera entrevista de esta serie, decidimos sentarnos con alguien que haya construido su carrera al poder identificar, anticipar y resolver con éxito estos desafíos mientras lidera proyectos de almacenamiento de datos para Microsoft y, actualmente, Ernst & Young. Como uno de los líderes de opinión más importantes en este espacio, James Serra ha abordado una variedad de temas desde BI y arquitecturas de datos hasta big data y análisis en su popular blog y en sesiones de oratoria en todo el mundo.

En esta entrevista, hablamos con James sobre algunos de los conocimientos que obtuvo durante su tiempo en la industria, la evolución de las arquitecturas de datos en la era del big data y cómo podría ser el futuro del almacén de datos.

 

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

Empecé hace muchos, muchos años con bases de datos en los años 80. El enfoque inicial estaba en Microsoft SQL Server, primero SQL Server 1.0 y luego OS 2.0 en 1989, creo que sí. Entonces, esas eran bases de datos más transaccionales con muchas actualizaciones, inserciones y eliminaciones.

Quizás hace 20 años fue cuando me involucré por primera vez en el almacenamiento de datos. Trabajaba como DBA en una empresa y se les asignó la tarea de crear un almacén de datos. En ese momento, sabía muy poco sobre la tecnología, pero el almacén de datos estaba construido en SQL Server, así que me involucré en el proceso. Esa fue una de mis primeras experiencias en la creación de un verdadero almacén de datos, es decir, extraer datos de todas estas fuentes diferentes y crear informes de BI además de eso.

Desde entonces, he tenido muchos trabajos diferentes: fui consultor que trabajaba en muchos tipos diferentes de bases de datos siempre en el ámbito de Microsoft, comenzando desde SQL Server y luego apareció Azure, luego estaba SQL Database, SQL Data Warehouse, y ahora Synapse, que es lo que he estado usando casi exclusivamente durante los últimos años.

 

Obviamente, tiene una gran experiencia en la creación de arquitecturas de datos tanto con Microsoft como ahora en EY. ¿Cuáles diría que son los casos de uso más comunes para el almacenamiento de datos? En otras palabras, ¿por qué estas empresas quieren construir un almacén de datos?

Sobre todo, las empresas quieren tomar mejores decisiones comerciales. Para hacer eso, necesitan tener todos los datos posibles. Entonces, en lugar de intentar ir a cada una de sus bases de datos operativas individualmente y crear informes, pueden obtener más valor si reúnen todos esos datos.  

Por ejemplo, digamos que tienen información del cliente almacenada en un sistema CRM, luego tienen información de soporte al cliente almacenada por separado en otro sistema, otra plataforma para administrar información de ventas y algún sistema ERP que también contiene información del cliente. Tienen todos estos datos almacenados por separado y, por supuesto, quieren recopilarlos y usarlos para identificar tendencias históricas para poder encontrar razones de cosas como por qué los clientes no están comprando en ciertas áreas del país. Con un almacén de datos, pueden entrar, profundizar y averiguar qué está pasando.

Más recientemente, no solo se trata de tendencias históricas, sino también de mirar hacia el futuro, aquí es donde entran la inteligencia artificial y el aprendizaje automático. Hoy en día, las empresas no solo quieren ver dónde han estado, sino también hacia dónde se dirigen. , razón por la cual la analítica predictiva se está convirtiendo en algo importante. Entonces, si tomamos esa información del cliente de antes y decimos que queremos usarla, predice las posibilidades de que un cliente se vaya. Un modelo de aprendizaje automático podría estimar un 70% de probabilidad de que el cliente se vaya en función de todos los datos recopilados. Así que ahora, como tomador de decisiones, puede tomar medidas proactivas y hacer algo para evitarlo, como enviarles un cupón para asegurar su lealtad.  

Básicamente, es realmente la recopilación de todos estos datos lo que permite al usuario final / analista generar informes y luego dividir y dividir los resultados para permitir esas mejores decisiones comerciales.

 

Por lo tanto, obviamente hemos visto un aumento bastante 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?

Entonces, en primer lugar, definiría big data no solo como el tamaño de los datos, sino también como el tipo y la velocidad de los datos. Muchos clientes con los que he trabajado manejan terabytes de datos que intentan consumir. Pero también tienen el desafío de manejar datos en todo tipo de formatos, incluidos Parquet, CSV, JSON, así como los datos que pueden querer consumir en tiempo real de los feeds de redes sociales como Twitter, también pueden querer extraer algunos datos de IoT. ahí.

Entonces, ahora tiene el desafío de todos los tipos y tamaños de datos de tres velocidades. Si bien en la última media docena de años han aparecido sistemas que pueden manejar big data como Azure Synapse en la plataforma de Microsoft, por ejemplo, todavía hay una serie de otras herramientas necesarias para construir un almacén de datos moderno. Estas herramientas manejan la variedad, el volumen y el tamaño de los datos. Hoy en día pueden manejar cualquier combinación de datos, extraerlos, ajustarlos, limpiarlos y dominarlos antes de generar informes.

 

¿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?

Definitivamente son complementarios. Cuando los lagos de datos se empezaron a utilizar hace unos diez años, estaban en Hadoop y la idea detrás de ellos era que no podíamos capturar big data de forma eficaz debido a su tamaño, los datos semiestructurados o no relacionales tampoco. realmente encaja bien en una base de datos relacional. Entonces, decidimos ponerlo en el lago de datos y consultarlo allí. Eso se convirtió en la zona de aterrizaje para todo tipo de datos no relacionales, mientras que los datos relacionales todavía se almacenaban dentro de una base de datos.

Por supuesto, la mayoría de las organizaciones desean combinar los dos tipos de datos, por lo que los datos no relacionales / semiestructurados en el lago de datos deberían moverse a la base de datos. Aunque, desde el principio, hubo intentos desde el principio de poner todo en el lago de datos, lo que generó una variedad de problemas.

Entonces, la consecuencia de eso es que nos dimos cuenta de que siempre necesitaríamos una base de datos relacional. Con el tiempo, este pensamiento evolucionó y ahora entendemos que necesita tener un lago de datos junto con la base de datos relacional y que cada uno tiene sus propias fortalezas.

Podemos considerar que un lago de datos puede manejar datos sin importar el tamaño o el tipo, pero tiene algunas limitaciones. El lago de datos no es bueno para consultas extremadamente rápidas, no es bueno para los tipos de seguridad que puede desear de su arquitectura de datos, como seguridad de bajo nivel o seguridad de nivel de columna, también puede ser más difícil para su final promedio. que el usuario consulte los datos que se encuentran en un lago de datos porque es un esquema al leer, lo que significa que es solo una carpeta de archivos glorificada, puede colocar cualquier tipo de datos allí y eso puede hacer que sea difícil intentar extraerlos si no lo hace. Tener las habilidades técnicas necesarias. Ahí es donde entra en juego una base de datos relacional porque alguien en TI hará el trabajo para colocar los datos junto con los metadatos, por lo que resulta mucho más fácil para un usuario final consultarlos. Por lo tanto, si pasa de un lago de datos a una base de datos relacional y de 3NF a un esquema en estrella, los usuarios finales ahora pueden realizar BI de autoservicio fácilmente porque solo pueden arrastrar campos de la base de datos y crear informes o consultas a partir de eso.

Ahora, han aparecido herramientas como Azure Synapse y han facilitado mucho la consulta de datos, ya sea en un lago de datos o en una base de datos relacional con SQL regular, y ambas tienen sus pros y sus contras. Sin embargo, en última instancia, la idea es tomar datos de todas estas fuentes, moverlos y trabajar un poco para prepararlos, lo que puede implicar costos adicionales, pero al final, obtendrá datos formateados de una manera que sea mucho más fácil para la mayoría de los usuarios finales. Mientras tanto, aún puede tener el lago de datos para que los científicos de datos y los usuarios avanzados lo consulten, pero para la mayoría de los usuarios, querrá tener una base de datos relacional disponible.  

 

¿Cuál sería el aspecto más crítico para la misión del desarrollo del almacén de datos? ¿El modelado de datos? ¿Cargando datos al almacén de datos? ¿Asegurarse de que el almacén de datos sea accesible para sus plataformas de BI?

Todos estos aspectos son extremadamente importantes, pero la gobernanza de datos es realmente el hilo principal en la construcción de un almacén de datos. Eso es para asegurarse de que los datos sean precisos, correctos y constituyan una fuente única de verdad para la organización. Porque lo peor que puede suceder es que usted haga todo este trabajo para construir un almacén de datos y generar un informe, entonces la primera vez que un usuario final lo ve, dice que los datos no son precisos o incorrectos. De inmediato, ha perdido su confianza en el sistema. Por lo tanto, debe asegurarse de antemano de que los datos se controlen correctamente. Eso significa tenerlo limpiado y dominado adecuadamente y todas esas cosas que van junto con la gobernanza de datos.

Casi tan importante, si no más, es la seguridad. Hoy en día, hay tanta información de identificación personal que podría aterrizar en un almacén de datos, y si no tiene el tipo de seguridad adecuado, la gente podría comenzar a ver datos que no deberían. Eso podría ser información personal, podrían ser cifras de ventas u otras cosas que pueden causarle muchos problemas, especialmente si esos datos se extraen de su empresa. Ahora estás en la portada del Wall Street Journal con una infracción. Entonces esa otra gran cosa es la seguridad. Por lo tanto, diría que esos dos deben ser lo más importante cuando construya un almacén de datos.

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

Me cuesta más ver una solución que debería ser local, solo hay casos muy raros de que ya sea una solución viable. Solía ​​ser, en Microsoft, por ejemplo, cuando me uní por primera vez hace 7 años, donde tenía muchas conversaciones sobre la nube frente a local, pero durante los últimos años ha sido extremadamente raro que alguien quiera hablar sobre esto último. como una posible opción.

Las raras excepciones son si la empresa se encuentra en un lugar que no tiene acceso a Internet como, por ejemplo, una mina o una plataforma en el mar. O si están tratando con datos que necesitan tiempos de respuesta de milisegundos cuando se trata de consultas y cosas así porque podría haber un poco de latencia en la nube. Pero fuera de eso, todo el mundo ha ido, está o va a ir a la Nube por numerosas razones de las que podría pasar media hora hablando.

Es importante tener en cuenta que el costo no siempre está a la vanguardia de este movimiento, son otras cosas como tener las últimas funciones de un producto, o probablemente el mayor beneficio que es la capacidad de comenzar a trabajar rápidamente. Con un almacén de datos en la nube, puedo ingresar a Azure, por ejemplo, y tener una base de datos lista en minutos, mientras que con una base de datos local puede llevar días, si no semanas, si no meses, obtener una base de datos en un servidor. Entonces, no puedo recordar la última vez que conocí a un cliente que también recomendé en las instalaciones. Claro, puede haber un par de casos de uso como mencioné anteriormente, pero estos son pocos y distantes entre sí.

 

Entonces, te he visto escribir un poco sobre ETL inverso en los últimos años. ¿Si pudiera resumir el concepto y hablar un poco sobre los beneficios que cree que aporta este enfoque?

Sí, este es un concepto muy nuevo. Por lo tanto, algunas empresas pueden tener datos de clientes en una docena de sistemas de origen diferentes, especialmente si se trata de una empresa grande. Digamos que extraen todos estos datos del cliente, los limpian y los dominan (es decir, crean registros dorados) porque podría haber varias copias del cliente con diferentes grafías. También podrían complementar los datos del cliente de un sistema con diferentes tipos de datos de otros sistemas, como tomar datos del cliente de un sistema CRM y agregar información de tickets de soporte de los clientes.

Así que supongamos que todos estos datos están ahora en el almacén de datos y he hecho todo este trabajo para crear una vista unificada del cliente. Bueno, ahora, el problema es que toda la limpieza se ha realizado a nivel de almacén de datos, pero los sistemas de origen de donde se tomaron los datos aún no se han limpiado. Con ETL inverso, la idea es que ahora puedo canalizar los datos del almacén de datos al sistema de origen y corregir esos registros de clientes. Esa es una de las razones por las que veo que el ETL inverso se está volviendo algo popular porque está haciendo todo este trabajo en el almacén de datos que luego puede aplicar a los sistemas de origen para corregirlos.

El otro gran beneficio de ETL inverso es que si extraigo todos estos datos en un almacén de datos y creo informes de BI sobre eso y digo que es un vista del clienteBueno, puedo tener muchos asociados de ventas que estén acostumbrados a estos otros sistemas operativos, es decir, un sistema CRM en el que ya ven los datos de los clientes y que ya les gusta usar. Ahora, les está pidiendo que vayan a un almacén de datos y usen un sistema diferente, un informe diferente, para ver a esos mismos clientes. Entonces, ¿por qué no revertir ETL y tomar esos datos del almacén de datos y copiarlos en el sistema operativo? Luego, los analistas pueden usar los datos en el sistema con el que se sientan más cómodos. Por lo tanto, no tienen que ingresar al almacén de datos.

Esta es otra área en la que veo que el ETL inverso es realmente popular. Haga el trabajo en un almacén de datos, pero luego coloque los datos en un sistema operativo donde los usuarios finales se sientan más cómodos.

 

Si estuviera buscando una solución de almacenamiento de datos para un cliente, ¿cuáles serían algunas de las características clave que le gustaría que tuviera?

He utilizado varias herramientas de automatización de almacenamiento de datos a lo largo de los años con distintos niveles de éxito. Algunos de ellos han sido realmente útiles, pero los que encuentro más efectivos son los que no son demasiado propietarios y pueden proporcionar una automatización que hace que la construcción de soluciones sea más rápida, ahí es donde pueden ser enormemente valiosos.

Cuando sopesas la pregunta de Build vs Buy de si comenzar proyectos completamente desde cero, siempre recomiendo buscar primero algo que ya se haya construido y ver si eso te ayuda. Ahora, ese podría ser un modelo de datos común o una herramienta para la automatización del almacén de datos que construirá rápidamente el almacén de datos para usted. Si la solución puede hacer eso usando tecnología que es común, es decir, si esa herramienta de automatización crea un almacén de datos para usted, ¿podría seguir usando el almacén de datos sin verse obligado a usar la herramienta de terceros, entonces está en el camino correcto?

Por ejemplo, la solución de automatización del almacén de datos podría interactuar con un software ETL en particular para crear canalizaciones y, una vez que haya creado esas canalizaciones, puede actualizarlas usted mismo sin pasar por la herramienta DWA. Ahora, digamos que está usando un producto de Microsoft para esa tarea, es posible que la herramienta DWA no se mantenga al día con las actualizaciones del producto ETL, así que digamos que el software obtiene nuevas características, entonces la herramienta de almacenamiento de datos puede tomar algún tiempo para aprovechar esas características que, por supuesto limita la funcionalidad de su solución. También está la cuestión de los conjuntos de habilidades, si está utilizando una herramienta de automatización de almacenamiento de datos en su empresa, es posible que deba contratar personas que ya tengan esa experiencia en herramientas de terceros para llevar adelante el proyecto.

En general, creo que las herramientas DWA son especialmente útiles para las empresas que son nuevas en el almacenamiento de datos y no cuentan con las mejores prácticas o estándares y tampoco tienen un gran equipo para construir su propia configuración. Pueden ir y obtener algunos resultados rápidos y una especie de atajo del proceso mediante el uso de una herramienta preparada para acelerar el desarrollo.

 

¿Qué opinas del concepto de almacén de datos ágil? Básicamente, ¿esta idea de que el almacenamiento de datos es un proceso, no un objetivo final, y que la iteración está prácticamente en el corazón de cualquier sistema de BI eficaz?

Cuando estaba en Microsoft, los clientes generalmente lo veían como una tecnología, el lado de las personas y los procesos era algo que buscaban tratar con ellos mismos. Por supuesto, es importante tener todos esos elementos en su lugar. Ya sea que hablemos de crear un centro de excelencia para la gobernanza de datos o de DataOps. Porque crear una aplicación es muy diferente a crear un almacén de datos, por lo que hago la distinción entre DevOps y DataOps.

En un almacén de datos, se trata de muchos sistemas. Podrías estar actualizar un modelo en un almacén de datos, a una canalización ETL, a informes. Entonces, todas esas cosas deben coordinarse y ahí es donde entra en juego DataOps y eso es muy importante. Veo muchas empresas, y EY es una de ellas en particular, que tienen este gigantesco almacén de datos construido y tienen que seguir un tipo de proceso DataOps para asegurarse de que el producto se utilice tanto internamente como fuera de la empresa. , también que no se rompe cada vez que se le pone una función nueva o se corrige un error.

Por lo tanto, las personas y los procesos a veces son la parte más difícil, mientras que la tecnología puede ser relativamente fácil. Por lo tanto, debe asegurarse de tener todos estos elementos en su lugar para asegurarse de que la solución terminada esté lo más libre de errores posible y proporcione, como mencioné antes, precisión en los datos.

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

Bueno, hablando de eso, creo que habrá un enfoque mucho mayor en la inteligencia artificial y la parte de aprendizaje automático de eso en particular. El desafío cuando está construyendo un almacén de datos es recopilar datos, limpiarlos y luego colocarlos en algún lugar, ya sea un lago de datos o una base de datos relacional. Para los clientes, podría llevar meses, si no años, recopilar todos esos datos. Y la guinda del pastel se convierte en los informes a partir de eso, donde se usa algo como PowerBI para cortar y cortar conjuntos de datos. Por el momento, ahí es donde todavía se encuentran muchos clientes, en el proceso de recopilar sus datos.

La mayor parte del trabajo en este espacio sigue un enfoque híbrido porque muchas empresas tienen fuentes de datos en la nube, pero muchos sistemas todavía están en las instalaciones y necesitan llevarlos todos a la nube, lo que tiene sus propios desafíos. . Una vez que recopile todos los datos, puede informar sobre ellos y obtener algunas soluciones con bastante rapidez.

El siguiente paso es realizar aprendizaje automático y crear modelos que se puedan entrenar con los datos en la nube. Muchos clientes aún no están allí, todavía están en la etapa de recopilación tratando de obtener datos en el almacén de datos. Entonces, el gran impulso será que los clientes vean los beneficios de los modelos ML al crear análisis predictivos para cosas como la rotación de clientes o cuando una pieza va a fallar (los datos del dispositivo IoT se han vuelto muy populares para este tipo de mantenimiento predictivo). Pero nuevamente, es un gran salto llegar allí, porque necesitará científicos de datos y los productos necesarios. Claro, las soluciones han recorrido un largo camino con el aprendizaje automático automatizado para facilitar esta parte, pero la entrada de basura aún se aplica, todavía necesita a alguien que entienda los conceptos de ciencia de datos allí.

Entonces, creo que en los próximos 2 años, verá una gran cantidad de trabajo realizado para construir esos modelos de aprendizaje automático para obtener aún más valor de los datos que de los informes históricos.

Una solución integral para el desarrollo de almacenes de datos modernos

Astera DW Builder ofrece una plataforma unificada que los usuarios pueden aprovechar para optimizar todos los aspectos de su proceso de desarrollo, desde la recopilación inicial, la limpieza de datos hasta el diseño de modelos de datos listos para generar informes que se adapten a sus requisitos de gobernanza de datos y, por supuesto, la implementación de su almacén de datos en la nube.

Con ADWB no tiene que depender de una pila de tecnología compleja o de recursos técnicos experimentados para que su implementación se lleve a cabo. El producto ofrece una interfaz intuitiva de arrastrar y soltar, admite una iteración rápida y funciona igualmente bien con una variedad de sistemas de origen y destino. Contacta con nuestro equipo para empezar Astera DW Builder hoy.