00:00:08 Data lakes y su importancia.
00:00:39 Data lakes definidos y su propósito en el negocio.
00:02:13 Evolución de los data lakes desde los data warehouses.
00:04:15 Cambio en la mentalidad y la filosofía en torno a los data lakes.
00:07:43 Garantizar la precisión de los datos en los data lakes.
00:10:06 Cómo la tecnología ha mejorado el data warehousing desde hace 20 años.
00:12:14 Los beneficios de los sistemas a demanda en los data lakes.
00:13:31 Limitaciones del business intelligence y su enfoque anticuado.
00:15:22 Comparando el business intelligence con los data lakes y su capacidad para informar la toma de decisiones.
00:16:49 Complejidad de la implementación: Acceder a fuentes de datos y el impacto en las empresas multinacionales.
00:18:32 Adopción de Data Lakes: Beneficios para empresas impulsadas por la tecnología y su uso en la optimización transversal.
00:20:08 El futuro de los Data Lakes: Mayor accesibilidad e implementación, próximos pasos con APIs.
00:22:45 Comentarios finales y conclusión.
Resumen
En esta entrevista, Kieran Chandler y Joannes Vermorel, fundador de Lokad, discuten data lakes y su rol en la optimización de supply chain. Los data lakes son repositorios centralizados de datos sin procesar que permiten a aplicaciones impulsadas por machine learning tomar decisiones inteligentes. Vermorel destaca las limitaciones de las herramientas tradicionales de business intelligence, enfatizando que los data lakes ofrecen un análisis de datos más eficiente y automatizado, es decir, data analysis. Él cree que las empresas impulsadas por la tecnología ya han adoptado los data lakes y han avanzado hacia la implementación de interfaces de programación de aplicaciones (APIs) para sus subsistemas, permitiendo una automatización end-to-end. Vermorel predice que las grandes empresas adoptarán cada vez más los data lakes y APIs en los próximos cinco años para un mejor decision-making.
Resumen Ampliado
En esta entrevista, Kieran Chandler conversa sobre data lakes con Joannes Vermorel, el fundador de Lokad, una empresa de software especializada en optimización de supply chain. Comienzan definiendo los data lakes y sus orígenes. Los data lakes son un tipo de base de datos diseñada para consolidar todos los datos transaccionales fundamentales de una empresa, como ventas, compras y niveles de stock. Estas bases de datos están destinadas al uso por parte de aplicaciones, en lugar de humanos, permitiendo que apps específicas del dominio y basadas en datos tomen decisiones inteligentes para marketing, supply chain, recursos humanos y más.
Los data lakes tienen una historia que se remonta al data warehousing y a los data marts, tendencias de hace más de 20 años. Vermorel explica que la principal diferencia entre los data lakes y los data warehouses radica en la tecnología y la filosofía que hay detrás de ellos. Los data lakes son más eficientes para almacenar y servir grandes cantidades de datos, mientras que la computación en la nube los ha hecho más accesibles y asequibles.
Hace veinte años, una empresa necesitaba comprar un dispositivo costoso, como uno de Oracle, para albergar su data warehouse. Ahora, con las plataformas de computación en la nube, las empresas pueden disponer de data lakes de pago por uso, escalables y a precios muy competitivos. Esta flexibilidad permite a los negocios ajustar fácilmente su enfoque de almacenamiento de datos si es necesario.
La filosofía detrás de los data lakes también ha evolucionado en comparación con los data warehouses. El enfoque anterior ejercía mucha presión sobre los departamentos de IT para organizar y gestionar adecuadamente los datos. Los data warehouses estaban diseñados con data marts para diferentes divisiones, como marketing, supply chain y finanzas. Esto generaba desafíos en la gestión y el acceso a los datos a través de diferentes departamentos.
Los data lakes tienen como objetivo consolidar los datos de forma más centralizada y accesible, facilitando que las aplicaciones los procesen y tomen decisiones inteligentes. Este cambio de mentalidad ha permitido una mayor eficiencia y flexibilidad en la gestión y el uso de los datos.
Hace veinte años, el data warehousing era un método popular para gestionar y organizar los datos. Este enfoque implicaba un alto nivel de esfuerzo técnico para conectar varias tablas de datos y requería un modelo unificado de los datos de la empresa. Sin embargo, este método a menudo hacía que las divisiones de IT se viesen abrumadas por la gran cantidad de trabajo, lo que resultaba en muchos proyectos fallidos.
Hoy en día, los data lakes han surgido como un enfoque más ágil y eficiente para la gestión de datos. Los data lakes actúan como un repositorio para datos sin procesar extraídos de diversos sistemas, como CRM, ERP, y plataformas web. En lugar de intentar organizar o combinar los datos, simplemente se vierten en el data lake, que puede manejar grandes cantidades de datos sin problemas.
Uno de los desafíos al usar data lakes es asegurar que los datos sean precisos y estén actualizados. Las divisiones de IT son responsables de garantizar que el data lake contenga una representación exacta de los sistemas originales, pero no necesitan comprender las implicaciones comerciales de los datos. La responsabilidad de entender los datos dentro del CRM, por ejemplo, recae en las divisiones que lo utilizan, como ventas o marketing. Este enfoque permite una interpretación más específica del problema en relación con los datos, ya que diferentes divisiones pueden tener distintas necesidades y perspectivas sobre ellos.
El panorama tecnológico ha cambiado significativamente desde los días de los data warehouses, haciendo de los data lakes una opción más viable. Por un lado, la calidad de las herramientas para mover datos a través de internet ha mejorado, facilitando la consolidación de datos de sistemas distribuidos, como supply chains. Además, la infraestructura de internet ha mejorado, permitiendo incluso a los negocios más pequeños mover grandes cantidades de datos sin dificultad.
Además, las plataformas de computación en la nube han hecho que los data lakes sean más accesibles y rentables. Estas plataformas permiten iteraciones rápidas y uso a demanda, lo que posibilita que las empresas experimenten con data lakes sin un riesgo financiero significativo.
Aunque las herramientas de business intelligence han sido útiles para que las empresas obtengan insights de sus datos, están fundamentalmente destinadas al consumo humano. Esto implica que las empresas deben pagar a empleados para analizar los datos en lugar de automatizar el proceso. Los data lakes, en contraste, permiten un análisis de datos más eficiente y automatizado, lo que los convierte en una opción atractiva para las empresas multinacionales que buscan mejorar su gestión de datos.
Vermorel explica las limitaciones de las herramientas tradicionales de business intelligence (BI), las ventajas de los data lakes y el futuro de la gestión de datos en la optimización de supply chain.
Vermorel describe el BI como una tecnología anticuada que proporciona únicamente un análisis de datos básico de manera casi en tiempo real. Esta tecnología fue revolucionaria hace 30 años, permitiendo a las empresas acceder y agregar sus datos, pero no ofrece insights o decisiones accionables. En contraste, los data lakes son parte de un panorama más amplio, sirviendo como un repositorio de almacenamiento para datos sin procesar de diversas fuentes. Las aplicaciones impulsadas por machine learning pueden procesar estos datos de manera eficiente para generar decisiones accionables que impacten en la empresa y creen valor tangible.
La implementación de un data lake depende de la complejidad de acceder a las fuentes de datos de una empresa. Para las grandes empresas multinacionales, esto puede ser un proceso difícil, ya que cada país podría tener su propio sistema. Sin embargo, no hay alternativas si una empresa quiere obtener insights y tomar decisiones basadas en datos. Vermorel cree que las pequeñas empresas impulsadas por la tecnología ya han adoptado los data lakes, e incluso han ido más allá al implementar interfaces de programación de aplicaciones (APIs) en sus subsistemas. Esto permite una optimización transversal y una toma de decisiones inteligente.
Vermorel prevé que las grandes empresas adopten cada vez más los data lakes en los próximos cinco años, a medida que se vuelvan más accesibles y asequibles. Las empresas que no implementen data lakes corren el riesgo de ser superadas por aquellas que ya lo han hecho. Sin embargo, los data lakes no son el paso final en la gestión de datos. Vermorel sugiere que las APIs son el futuro, ya que permiten a las empresas no solo leer y analizar los datos, sino también actuar en consecuencia. Las APIs pueden posibilitar una automatización end-to-end, generando decisiones automáticamente e implementándolas dentro del sistema.
Joannes Vermorel enfatiza la importancia de superar las herramientas tradicionales de BI y adoptar data lakes para una toma de decisiones basada en datos más eficiente en la optimización de supply chain. Él prevé un futuro en el que las grandes empresas implementen data lakes y APIs para automatizar sus procesos y tomar decisiones más inteligentes.
Transcripción Completa
Kieran Chandler: Hoy en Lokad TV, vamos a discutir un poco más sobre el concepto de data lakes y entender por qué esas empresas deberían interesarse más en ellos. Entonces, Joannes, como siempre, quizás deberíamos comenzar definiendo un poco más qué son los data lakes y de dónde provienen.
Joannes Vermorel: Un data lake es, típicamente, un tipo de base de datos con algunas particularidades, que está destinado a consolidar prácticamente todos los datos fundamentales de tu empresa, especialmente todos los datos transaccionales como lo que has vendido, lo que has comprado, tus niveles de stock, y demás. La intención y el uso final del data lake es que está destinado a ser para apps, no para humanos. La idea es que implementas un data lake para que puedas tener apps específicas del dominio que sean muy orientadas a los datos y puedan utilizar una gran cantidad de datos del data lake para generar decisiones inteligentes para marketing, supply chains, recursos humanos, o lo que sea. Fundamentalmente, es un lugar donde puedes consolidar todos los datos para servirlos en lote a aplicaciones inteligentes. En cuanto a la segunda parte de tu pregunta, los data lakes tienen una larga historia, que se remonta a la idea de data warehousing y data marts.
Kieran Chandler: Los data warehouses fueron una tendencia que vimos probablemente hace más de 20 años. Entonces, ¿qué ha cambiado entre entonces y ahora, y cuáles son las diferencias clave?
Joannes Vermorel: Es interesante. La palabra de moda hoy en día es “data lake” y “data scientist”, mientras que hace veinte años, se hablaba de “data warehouse” y “data mining”, que básicamente son la misma evolución de las mismas ideas, solo que revisitadas veinte años después. Lo que ha cambiado es bastante. Primero, la tecnología de los data lakes ha cambiado, por lo que son mucho más eficientes para almacenar y servir grandes cantidades de datos. Luego, surgió la computación en la nube, lo que significa que hoy en día puedes tener data lakes completamente a demanda con un modelo de pago por uso por terabyte. Esto es bastante diferente en comparación con hace 20 años, cuando tenías que comprar un dispositivo muy costoso, como de Oracle, para almacenar todos tus datos. Hoy en día, con las plataformas de computación en la nube, puedes tener terabytes de pago por uso y precios extremadamente agresivos.
Kieran Chandler: Esa es la parte técnica de las cosas. ¿Y qué hay de la filosofía? ¿Qué ha cambiado en la mentalidad y en cómo usamos los data lakes en comparación con los data warehouses?
Joannes Vermorel: Sin duda, ha habido una gran evolución. El problema con los data warehouses, tal como se concebían hace 20 años, es que ponían mucha presión en el departamento de IT para organizar adecuadamente los datos. Incluso llegabas a tener un data warehouse que se suponía debía organizar los data marts, con un data mart destinado para cada tipo de división, como marketing, supply chain, finanzas, y así sucesivamente. Los data marts eran como subconjuntos o subsistemas dentro de tu data warehouse. El problema de este enfoque, que era algo similar en espíritu a los data lakes que tenemos hoy en día, es que requería mucha organización y gestión por parte del área de IT.
Kieran Chandler: Lo que se hacía en business intelligence era que existía un alto nivel, un alto grado de expectativas sobre el hecho de que ya habría datos preparados, organizados, ya sabes, en donde habías vinculado, ya sabes, clientes a ventas a devoluciones. Es decir, se pegaban las cosas entre sí. Todo lo que iba junto, en realidad, requiere mucho esfuerzo. Técnicamente, se trataba, ya sabes, de unir tablas, de conectar todas esas tablas con uniones adecuadas. Así, hace 20 años, la filosofía era hacer mucho, y era bastante similar a lo que se hacía en BI y similar a lo que se hacía de forma natural en sistemas relacionales. El problema de este enfoque era que la cantidad de trabajo requerida era completamente enorme, por lo que normalmente terminabas con divisiones de IT completamente abrumadas por la gran cantidad de requisitos que les recaían debido a estos proyectos de data warehousing. Como resultado, con frecuencia fallaban, simplemente porque IT no lograba entregar. ¿Pero qué pasa hoy? Quiero decir, seguramente las cosas se complicarán un poco ahora que tienes estos data lakes.
Joannes Vermorel: Los data lakes, en términos de filosofía, son mucho más simples porque la idea es que el data lake es solo un receptor para una extracción limpia, un volcado limpio de todos los datos que se encuentran en otros sistemas. Es decir, no intentas hacer ninguna recombinación elegante tanto de los datos que provienen del CRM, como los datos que provienen del ERP, y los datos que provienen de tu plataforma web. Simplemente vas a extraer esas fuentes de datos y volcarlas en el data lake. Y el data lake se comporta bien gracias a la tecnología, lo que significa que puedes volcar una gran cantidad de datos y este soportará la carga sin quejarse. Si estás en la nube, se te cobrará por ello.
Kieran Chandler: ¿Cómo sabes que los datos que realmente estás usando son buenos? Quiero decir, ¿cómo haces el seguimiento de qué datos están actualizados? Es decir, si simplemente los viertes todos en este data lake, ¿cómo haces el seguimiento?
Joannes Vermorel: La responsabilidad de TI con un data lake es asegurarse de que el data lake contenga un reflejo exacto de lo que hay en los sistemas originales. Pero eso no requiere ningún entendimiento de lo que sucede a nivel empresarial. Simplemente tienes un CRM que tiene 200 tablas, tablas relacionales, y simplemente las reflejas en el data lake, y eso es todo. No es necesario comprender lo que esté sucediendo en el CRM.
Kieran Chandler: Entonces, ¿quién necesita entender lo que ocurre dentro del CRM?
Joannes Vermorel: Resulta que son las propias divisiones quienes quieren explotar los datos, y el problema es que la interpretación de los datos es muy específica al problema. Por ejemplo, la forma en que se analizan los datos de ventas es diferente si se quiere resolver un problema de marketing o un problema de supply chain. Por eso, y esa fue también una de las principales razones por las que, hace veinte años, muchas de aquellas iniciativas de data warehousing fracasaron. Es porque la visión era producir un modelo unificado de la empresa, pero luego se descubrió que resultaba muy frustrante para cada división, pues marketing decía, “Oh, no encaja exactamente en la visión que tengo de mi dominio,” supply chain decía lo mismo, y Finanzas dirían igual. En contraste, la idea es que ahora son más bien las propias divisiones, como supply chain, marketing, finanzas, recursos humanos.
Kieran Chandler: Significa que hoy no van a fallar. Quiero decir, de nuevo, hay un montón de cosas que cambian. Un desafío particular, especialmente en supply chain, es que, por diseño, tratamos con sistemas distribuidos. ¿Qué quiero decir con distribuidos? Me refiero a que no todo está en un solo lugar, ya que, por definición, si tienes múltiples almacenes, no están en el mismo sitio. Tus proveedores no están en el mismo lugar que tus almacenes, y tus clientes tampoco. Así que, por definición, estamos tratando con sistemas dispersos, y quieres consolidar todos esos datos en un solo lugar, que es tu data lake, lo cual técnicamente debe hacerse a través de la red.
Joannes Vermorel: Obviamente, hace veinte años, internet ya había sido inventado. Existía, pero la calidad de las herramientas para mover datos a través de internet era completamente diferente en comparación con lo que tenemos hoy. Y además, la calidad de la red en sí también era completamente distinta. Hoy en día, si quieres mover, digamos, para una empresa no tan grande, una compañía de 1,000 empleados, es decir, considerable pero no una mega-corporación. Hace veinte años, si querías mover un gigabyte de datos por día a través de internet, era complicado.
Quiero decir, necesitabas tener acceso a fibra, por ejemplo, en París. Hace veinte años, solo había un lugar en París donde se podía acceder a la fibra, que era la zona cercana a la bolsa. Había, como, un kilómetro cuadrado donde era fácil obtener acceso a la fibra. En cualquier otro lugar, tenías que instalar tu propia fibra si la querías. Así que, las mega-corporaciones podían hacerlo, pero incluso una empresa considerable, ya sabes, con 1,000 empleados, no podía. Esto ha cambiado. Ahora, es muy sencillo. Las herramientas son mejores, y puedes mover literalmente gigabytes sin demasiadas complicaciones.
Y el hecho de que tengas sistemas bajo demanda, esos data lakes no solo son muy baratos, gracias a las economías de escala de esas plataformas de computación en la nube, sino que el hecho de que sean bajo demanda significa que puedes probar y errar. Si simplemente intentas configurar un data lake y resulta ser un completo fracaso, puedes simplemente decir “borrar” y volver a intentarlo, y solo pagas por lo que usas. Así que, puedes iterar rápidamente. No es como hace veinte años cuando tenías que comprometerte a comprar un aparato muy caro, y si fallabas, eso era un gran problema.
Kieran Chandler: Y apuesto a que esas áreas de finanzas probablemente siguen teniendo el internet más rápido. ¿Qué le dirías a una gran empresa multinacional que ya tiene un buen control sobre sus datos, que ya comprende las cosas utilizando herramientas de business intelligence? Es decir, ¿por qué deberían estar interesados en un data lake?
Joannes Vermorel: El problema con el business intelligence es que, fundamentalmente, está destinado a los humanos. Es bueno, pero significa que cada minuto que las personas dedican a mirar esos números es un minuto en el que, en realidad, le estás pagando a un empleado para que mire números en lugar de hacer otra cosa. Puedes producir fácilmente millones de números, lo que requerirá miles de horas de trabajo para procesarlos, lo cual es extremadamente costoso.
Así, el problema es que el business intelligence, tal como lo veo, es un tipo de tecnología bastante anticuada. Era una forma de obtener un análisis básico de tus datos de manera relativamente en tiempo real. Era muy interesante porque, si retrocedemos 30 años, que fue la época en que se fundó Business Objects, eran la compañía que… Y, de lo contrario, simplemente no sabías que no se podían realizar consultas sincronizadas que te dieran esta información: cuántas unidades se venden por día, por producto, etc. Eso no era posible con el business intelligence. De repente, fue posible tener este cubo, incluso se pueden tener hiper-cubos, y aún mejor, se puede tener de una manera muy, muy buena. Pero al final, solo estás viendo una agregación súper básica de tus datos, y esa agregación no es una decisión. No te dice si deberías subir o bajar tu precio, no te dice si deberías producir más o menos, no te dice si, de un lote de producción de 1000 unidades, deberías poner 100 unidades en un avión para una entrega más rápida. Fundamentalmente, se trata simplemente de obtener insights cuantitativos. La gran diferencia entre, ya sabes, BI y data lake es que el data lake viene con la idea de que es, fundamentalmente, una pieza de un engranaje en un panorama más amplio donde, sentado frente al data lake, típicamente tendrás una aplicación impulsada por machine learning que procesará los datos servidos de manera súper eficiente por el data lake para generar decisiones automáticamente. Y esas decisiones son algo que tiene un impacto físico en tu empresa y que creará valor tangible de alguna manera.
Kieran Chandler: Bien, si estamos de acuerdo en que quizá las herramientas de business intelligence tienen sus limitaciones, y si se trata de implementar un data lake, ¿qué tan fácil es realmente hacerlo? ¿Es solo cuestión de cargar todos esos datos en la nube y ya está listo?
Joannes Vermorel: La complejidad de implementar un data lake es estrictamente proporcional a la complejidad de acceder a tus fuentes de datos, es decir, simplemente acceder a ellas, sin hacer nada inteligente con esos datos. Eso significa que, para grandes multinacionales, bueno, eso implica que si cada país en tu empresa tiene su propio sistema, pues, ¿adivina qué? Tendrás tantos tipos de data lakes que instalar para poder traer los datos de cada país al data lake. Pero, es lamentable porque no tienes otra alternativa, ya que la única opción es tener una integración directa con los países, lo cual es aún más costoso, porque si tienes dos divisiones, digamos, marketing y supply chain, que quieren acceder a los datos de ventas, pagarás por esa integración dos veces. Así que la idea con un data lake es que, lo haces una vez, y luego ya está en el data lake, lo que lo hace muy adecuado para que el resto de la empresa acceda a los datos. Por lo tanto, la complejidad depende completamente de lo que tengas. Pero, de nuevo, si volvemos a tu cita inicial, si no tienes datos, simplemente eres un hombre con una opinión. No tienes otra alternativa para recuperar esos datos en ningún lado si quieres hacer algún tipo de medición.
Kieran Chandler: Reunamos las cosas ahora. Si hay tantos aspectos positivos de los data lakes y parece bastante simple, siendo solo un gran receptáculo de datos al final del día, ¿por qué es algo que la industria no está adoptando de manera generalizada en este momento?
Joannes Vermorel: Resulta que las empresas tecnológicas muy pequeñas adoptaron los data lakes hace bastante tiempo, e incluso fueron más allá con, podría decir, la API-ficación de su empresa, lo que significa que vas a poner una API (Application Programming Interface) en cada subsistema, que es como el siguiente paso que ocurre después del data lake. Así que, diría que el smart ecommerce, por ejemplo, ya ha consolidado sus datos, y eso.
Kieran Chandler: Hay que echar un vistazo a ambos hoy en día, lo que proviene del sitio web, lo que pagas por marketing de mercancía en motores de búsqueda, ya sabes, Google AdWords y algo por el estilo, y pedidos cruzados. Son capaces de tomar decisiones inteligentes en términos de acción de marketing directo y demás. En cuanto a las empresas puramente tecnológicas como Microsoft o Google, también han estado haciendo cosas similares, ya sabes, durante literalmente décadas. Quiero decir, Google solo ha existido por dos décadas, pero otras empresas, como todas las empresas tecnológicas, han estado haciendo eso desde hace bastante tiempo. Entonces, si lo han estado haciendo durante décadas, ¿qué hay del futuro? ¿Vamos a sumergirnos en un océano de datos alguna vez?
Joannes Vermorel: Sí, quiero decir, lo que puedo ver a continuación es que las empresas que están muy orientadas al supply chain, ahora que los data lakes se han vuelto muy accesibles y baratos, implementarán estos data lakes. Vemos entre nuestros clientes que muchos clientes que no tenían un data lake hace un año, ahora tienen un data lake. Diría que ha habido un punto de inflexión en los últimos dos años en lo que respecta a los data lakes. Así que, sospecho que la mayoría de las grandes empresas, en los próximos, probablemente, cinco años, realmente habrán implementado sus propios data lakes, porque de otro modo, simplemente quedarían completamente superadas por todas las grandes empresas que ya lo habrán hecho por ellas.
Pero también existen límites, en particular, un data lake es simplemente una copia de solo lectura de todos los datos que se encuentran en otros subsistemas. Por eso decía que el siguiente paso es que todos los subsistemas expongan APIs, application programming interfaces, porque eso es lo que hizo Amazon. Estas APIs te permiten hacer aún más, de repente ya no eres solo de solo lectura, sino que también puedes actuar. La idea es que puedes consolidar todos los datos, leerlos, procesarlos, tomar todas esas decisiones, y luego, ¿qué hacemos con esas decisiones que se han computado? La respuesta es que puedes enviar el spreadsheet de Excel a la división apropiada para que implementen tus decisiones, como por ejemplo, compras. Pero si hay una API, puedes llamar directamente a esta API para inyectar la orden de compra para este producto, de esta cantidad, de este proveedor, especificando este transporte y demás. Así que, en realidad, si tienes APIs, puedes tener automatizaciones de extremo a extremo donde no solo generas la decisión automáticamente, sino que luego implementas estas decisiones físicamente de manera automática porque se reinyecta en uno de los sistemas.
Kieran Chandler: Bien, tendremos que dejarlo aquí, pero gracias por tu tiempo hoy. Así que eso es todo por esta semana. Muchas gracias por sintonizarnos, y volveremos la próxima vez. Adiós por ahora.
