The post has been translated automatically. Original language: Russian
It is important to understand that Lakehouse architecture is applicable in completely different domains and business sectors. I will give examples from fundamentally different fields.
Our first acquaintance with this architectural concept took place in 2022, during the implementation of an ML project for an insurance company. There was so much data and systems, and the data processing SLAs were so harsh, that we quickly realized that we needed to place significant emphasis on efficient data management. As a result, we conducted a huge number of experiments with different data formats and tested many compute-engines until we finally reached the required performance.
The second interesting case is automation of distribution reporting processing in a pharmaceutical company. The data was received by mail, via SFTP and API in a variety of formats, and processing took place through several levels within the DBMS: from raw data to cleaned data and then to data marts. Completing such a (hitherto classical) path took a lot of time and resources. We decided to use a modern approach and implement the Lakehouse architecture. After that, the data path became significantly shorter and faster, and the total cost of ownership decreased. The end users of this data, BI, were able to generate reports based on up—to—date data with minimal delay. There is also no need for constant physical copying of data between DBMS layers.
The third example is the Customer 360 project for marketing in a medical company. The goal is to provide personalized services to patients in a timely manner to enhance their lifetime value. Before implementation Lakehouse teams of analysts and data scientists spent a lot of time preparing data from the Firebird-based medical information system (MIS), which was inherited and had significant integration limitations. We created a single managed layer for them, integrated it with MIS, with a data catalog, gave this layer versioning and the ability to publish ready-made datasets for analytics and machine learning. Thus, we were able to dramatically speed up iterations in this ML project and bring the model to production in a significantly shorter time. Another example is a company from the ecosystem of a large bank. In this case, the customer himself came with a request to implement Lakehouse. The goal was to create a virtual workplace for analysts, data engineers, and data scientists. An important condition was the use of corporate file storage and providing users with the opportunity to subscribe to datasets and request access to them on their own. As a result, we implemented a full-fledged Lakehouse platform that seamlessly integrated into the existing infrastructure and provided security, manageability and, most importantly, convenient access to data. Now new work scenarios are being enabled without recycling the storage, and the access process has become transparent and predictable.
Важно понимать, что архитектура Lakehouse применима в абсолютно разных доменах и отраслях бизнеса. Приведу примеры из принципиально разных областей.
Наше первое знакомство с этой архитектурной концепцией состоялось в 2022 году, во время реализации ML-проекта для страховой компании. Данных и систем было настолько много, а SLA обработки данных были настолько суровыми, что мы быстро поняли: нам нужно делать существенный акцент на эффективном обращении с данными. В итоге мы провели огромное количество экспериментов с разными форматами данных и протестировали множество compute-engines, пока наконец не вышли на необходимый перформанс.
Второй интересный кейс — автоматизация обработки дистрибьюторской отчетности в фармацевтической компании. Данные поступали по почте, через SFTP и API в самых разных форматах, а обработка шла через несколько уровней внутри СУБД: от сырых данных к очищенным и затем к витринам данных. Прохождение такого (до сих пор классического) пути занимало много времени и ресурсов. Мы решили использовать современный подход и внедрить архитектуру Lakehouse. После этого путь данных стал значительно короче и быстрее, а совокупная стоимость владения снизилась. Конечные потребители этих данных — BI — смогли формировать отчеты на актуальных данных с минимальной задержкой. Также отпала необходимость постоянного физического копирования данных между слоями СУБД.
Третий пример — проект Customer 360 для маркетинга в медицинской компании. Цель — своевременное предложение пациентам персонализированных услуг для повышения их lifetime value. До внедрения Lakehouse команды аналитиков и датасайентистов тратили массу времени на подготовку данных из медицинской информационной системы (МИС) на базе Firebird, которая унаследована и имела значительное ограничение по интеграции. Мы создали для них единый управляемый слой, интегрировали его с МИС, с каталогом данных, дали этому слою версионирование и возможность публикации готовых наборов данных для аналитики и машинного обучения. Тем самым мы смогли кардинально ускорить итерации в этом ML-проекте и вывести модель в продуктив в существенно меньшие сроки. Еще один пример — компания из экосистемы крупного банка. В этом кейсе сам заказчик пришел с запросом на внедрение Lakehouse. Задача заключалась в создании виртуального рабочего места для аналитиков, дата-инженеров и датасайентистов. Важным условием были использование корпоративного файлового хранилища и предоставление пользователям возможности подписываться на наборы данных и самостоятельно запрашивать доступы к ним. В итоге мы внедрили полноценную Lakehouse-платформу, органично встроившуюся в существующую инфраструктуру и обеспечившую безопасность, управляемость и, главное, удобный доступ к данным. Сейчас новые сценарии работы подключаются без переработки хранилища, а процесс получения доступа стал прозрачным и предсказуемым.
Share
