Escuché el término «data lake» hace un poco más de un un año, en una entrevista laboral que tuve (si mal no recuerdo) para el banco Scotiabank. Estoy acostumbrado a escuchar o leer de términos y terminajos tecnológicos a cada rato y considero que se me da con facilidad derivar la intención del significado inherente a éstos (como cuando supe del fog computing) dentro del contexto en el que lo escucho. Pero una cosa es darse una idea de la intención y otra verdaderamente saberla, por lo que siempre conviene no quedarse sólo con aquello que intuimos.

Un «lago de datos» es una ubicación central en la que se almacenan datos, independientemente de su fuente o formato (estructurado o no estructurado), y es diferente a lo que se concibe como un enterprise data warehouse (EDW). Un EDW recibe datos de una amplia variedad de aplicaciones empresariales que necesitan ser transformados (bajo las ya conocidas aciones ETL o ELT) para poder ser integrados en el propio esquema del EDW. El EDW es diseñado para recopilar sólo datos bajo control y calidad, formando un modelo de datos empresariales, así el EDW es capaz de responder a un número limitado de preguntas.

Los lagos de datos, por otro lado, reciben información en su forma nativa. Se realizan pocas o ninguna labores de procesamiento para adaptar lo que se recibe a la «estructura esquemática» de la empresa. Por lo tanto, la estructura de los datos recopilados es desconocida cuando se alimenta al lago de datos, y sólo se sabrá hasta el momento de leerla. Así, la mayor ventaja de los lagos de datos es su flexibilidad. Al permitir a los datos permanecer en su formato nativo y disponibles para diversos análisis (algunos de los cuáles serán definidos o creados en un futuro.

Referencias

1. Alice LaPlante & Ben Sharma, «Architecting Data Lakes«; O’Reilly Media, Inc., March 2016, ISBN 978-1-491-95257-3.