The post has been translated automatically. Original language: Russian
Every second conversation with a CTO or CIO of a large business starts about the same way: "We already have Oracle, Hadoop, ELK, three DWH and four data lakes — why do we need something else?" And every time I see the same mixture of fatigue and hope in the eyes of the interlocutor.
Recently, one CTO of a large bank told a story. They spent two years building a "data lake". We spent a serious budget, assembled a team of 12 engineers, and purchased hardware. The result? The data is pouring in, but no one knows what's in there. Analysts still go to Oracle. ML engineers upload CSV files with their hands. And the lake is quietly turning into a swamp.
Spoiler alert: Data Lakehouse didn't appear because marketers came up with a beautiful word. It appeared because data engineers were tired of fixing pipelines at 3 a.m., and businesses were tired of hearing "data will be available tomorrow."
Part 1: A Brief and sad history of data Storage
In the data industry, we reinvent the same idea every 10 years. Our pendulum is simply swinging between two extremes.: "let's put everything in order" and "let's put everything in a pile, we'll figure it out later."
1990s: Data Warehouse — an elite warehouse with a catalog
It was a beautiful idea: collect all the structured company data (finances, sales) in one place and put things in order. Databases like Teradata or Oracle were the Rolls-Royces of the data world— expensive and slow to maintain. Do you want to add a new data type? Make an application, and the DBA will design the scheme in 3 months. Data is coming in at the speed of business, and storage is changing at the speed of bureaucracy.
And most importantly, semi—structured data (JSON, logs, images) simply did not fit conceptually in the Data Warehouse. It's like trying to put a cat in an aquarium: technically possible, but everyone will be unhappy.
2010s: Data Lake — "throw everything away, we'll figure it out later"
Why pay for expensive storage? Let's put everything in one cheap pile (in HDFS or S3) — both structured data and raw logs. But "then" never came.
According to Gartner, up to 60% of Data Lake projects either failed or failed to deliver their stated value. Data lakes have turned into swamps (data swamps). The data was uploaded without a catalog, schematics, or quality control. Finding something specific there is like looking for the right box in a garage where everything is piled on top of each other.
A metaphor for customer meetings: > Data Warehouse is IKEA. It's expensive, but everything is catalogued, there are signs and price tags. Data Lake is a garage sale. It's cheap, you might get a treasure, but to find it, you need to sort through three tons of junk.
2020s: Data Lakehouse — the third attempt
The data industry, having scored bumps on both approaches, came to the question: what if you can take cheap storage from the lake and add order from the storage? Without shifting the data back and forth, but right on the spot? This is the Data Lakehouse.
Part 2: What's Really broken in Architecture
The problem with modern Enterprise is not that there is a lot of data. The problem is that they live in different worlds (Oracle, Vertica, Hadoop, Kafka, Elasticsearch...). Seven systems are seven teams, seven budgets, and seven copies of the same data. Hence the three main pains:
- Pain #1: Double-entry accounting of data. When data is copied between systems via ETL pipelines, the numbers begin to diverge. The pipeline fell at night, 47,000 lines were not added — as a result, CFO in Power BI has some revenue figures, marketing in the dashboard has others. For three days, engineers look for a mistake, and the business makes decisions blindly.
- Pain No. 2: ETL-AD. According to Anaconda research, data engineers spend about 40% of their working time preparing, cleaning, and moving data from one format to another. Pipelines are fragile creatures, they break down from any change in the source circuit, providing engineers with eternal alerts at 3 a.m.
- Pain #3: Yesterday's data. The chain source → Data Lake → ETL → DWH → BI-the dashboard adds a delay at each stage. By the time the data appears on the dashboard, it has been several hours or a day. It's fine for a quarterly report. To detect fraud in real time or referral systems — loss of money.
Another metaphor: Imagine that you have a refrigerator (warehouse) and a pantry (lake). Every time you cook dinner, you need to first move the food from the pantry to the refrigerator, put it on the shelves, and only then start cooking. By this point, half of the products are no longer fresh. Data Lakehouse is when the pantry itself becomes a refrigerator.
Part 3: Data Lakehouse — honestly
Lakehouse is not a specific software, it is an architectural approach. Its essence is in three layers:
- Cheap storage — data is stored in object storage (S3, MinIO, HDFS) and stored cheaply, as in Data Lake.
- Metadata and order — A layer is added on top of the files, which provides schema, ACID transactions, and versioning, as in DWH. But without copying the data.
- Separation of computing and storage — the query engine (compute) works separately from storage. You can connect any engine to the same data.
The real hero of this story is Open Table Formats
All the magic happened thanks to the open table formats: Apache Iceberg, Delta Lake and Apache Hudi. They added to the regular files in S3 what they absolutely lacked: ACID transactions (no "half-written file"), on-the-fly schema evolution, and Time travel (the ability to query the state of data at any point in the past).
Apache Iceberg has become the de facto industry standard. It is supported by almost all major cloud and analytics platforms.
Comparing the three approaches
Who needs it and when?
There is no need to dispose of the existing DWH tomorrow morning. The move to Lakehouse is an evolution. We usually recommend starting with a 5-10 TB data pilot for new business loads. It can be deployed in 2-4 weeks by a small team of 2-3 engineers.
As a result, the business gets rid of ETL hell, receives data for BI and machine learning in real time, and savings on IT infrastructure fully pay off investments in the first year.
If you want to dive deeper into the technical underside, learn about the non-obvious advantages of architecture and the pitfalls of implementation, read the full version of the article on our blog: "What is DATA LAKEHOUSE" on Datanomix.pro .
Каждый второй разговор с CTO или ИТ-директором крупного бизнеса начинается примерно одинаково: «У нас уже есть Oracle, Hadoop, ELK, три DWH и четыре data lake — зачем нам что-то ещё?» И каждый раз я вижу в глазах собеседника одну и ту же смесь усталости и надежды.
Недавно один CTO крупного банка рассказал историю. Они два года строили «озеро данных». Потратили серьёзный бюджет, собрали команду из 12 инженеров, закупили железо. Результат? Данные туда льются — но никто не знает, что там лежит. Аналитики по-прежнему ходят в Oracle. ML-инженеры выгружают CSV-ки руками. А озеро тихо превращается в болото.
Спойлер: Data Lakehouse появился не потому, что маркетологи придумали красивое слово. Он появился потому, что data-инженеры устали чинить пайплайны в 3 часа ночи, а бизнес устал слышать «данные будут завтра».
Часть 1: Краткая и печальная история хранения данных
В индустрии данных мы каждые 10 лет переизобретаем одну и ту же идею. Наш маятник просто качается между двумя крайностями: «давайте всё упорядочим» и «давайте всё свалим в кучу, разберёмся потом».
1990-е: Data Warehouse — элитный склад с каталогом
Идея была красивая: собрать все структурированные данные компании (финансы, продажи) в одно место и навести порядок. СУБД вроде Teradata или Oracle были Роллс-Ройсами мира данных — дорогими и медленными в обслуживании. Хотите добавить новый тип данных? Оформите заявку, через 3 месяца DBA спроектирует схему. Данные поступают со скоростью бизнеса, а хранилище меняется со скоростью бюрократии.
А главное — полуструктурированные данные (JSON, логи, картинки) в Data Warehouse просто не помещались концептуально. Это как пытаться засунуть кота в аквариум: технически возможно, но все будут несчастны.
2010-е: Data Lake — «кидай всё, разберёмся потом»
Зачем платить за дорогое хранилище? Давайте зальём всё в одну дешёвую кучу (в HDFS или S3) — и структурированные данные, и сырые логи. Но «потом» так и не наступило.
По данным Gartner, до 60% проектов Data Lake либо провалились, либо не дали заявленной ценности. Озера данных превратились в болота (data swamps). Данные заливались без каталога, схем и контроля качества. Найти там что-то конкретное — это как искать нужную коробку в гараже, где всё свалено друг на друга.
Метафора для встреч с клиентами: > Data Warehouse — это IKEA. Дорого, но всё расставлено по каталогу, есть указатели и ценники. Data Lake — это гараж-сейл. Дёшево, может попасться сокровище, но чтобы его найти — нужно перебрать три тонны хлама.
2020-е: Data Lakehouse — третья попытка
Индустрия данных, набив шишки на обоих подходах, пришла к вопросу: а что если можно взять дешёвое хранилище из озера и добавить порядок из хранилища? Не перекладывая данные туда-сюда, а прямо на месте? Это и есть Data Lakehouse.
Часть 2: Что на самом деле сломалось в архитектуре
Проблема современного Enterprise не в том, что данных много. Проблема в том, что они живут в разных мирах (Oracle, Vertica, Hadoop, Kafka, Elasticsearch...). Семь систем — это семь команд, семь бюджетов и семь копий одних и тех же данных. Отсюда три главные боли:
- Боль №1: Двойная бухгалтерия данных. Когда данные копируются между системами через ETL-пайплайны, цифры начинают расходиться. Пайплайн упал ночью, 47 000 строк не долили — в итоге у CFO в Power BI одни цифры выручки, у маркетинга в дашборде — другие. Три дня инженеры ищут ошибку, а бизнес принимает решения вслепую.
- Боль №2: ETL-ад. По исследованиям Anaconda, data-инженеры тратят около 40% рабочего времени на подготовку, очистку и перемещение данных из одного формата в другой. Пайплайны — хрупкие существа, они ломаются от любого изменения схемы источника, обеспечивая инженерам вечные алерты в 3 часа ночи.
- Боль №3: Вчерашние данные. Цепочка источник → Data Lake → ETL → DWH → BI-дашборд на каждом этапе добавляет задержку. К моменту появления в дашборде данным уже несколько часов или сутки. Для квартального отчета — нормально. Для обнаружения фрода в реальном времени или рекомендательных систем — потеря денег.
Еще одна метафора: Представьте, что у вас есть холодильник (warehouse) и кладовка (lake). Каждый раз, чтобы приготовить ужин, вам нужно сначала перенести продукты из кладовки в холодильник, разложить по полочкам, и только потом начать готовить. К этому моменту половина продуктов уже не свежая. Data Lakehouse — это когда кладовка сама становится холодильником.
Часть 3: Data Lakehouse — по-честному
Lakehouse — это не конкретный софт, это архитектурный подход. Его суть в трёх слоях:
- Дешёвое хранилище — данные лежат в объектном хранилище (S3, MinIO, HDFS) и хранятся дёшево, как в Data Lake.
- Метаданные и порядок — поверх файлов добавляется слой, который обеспечивает схему, ACID-транзакции и версионирование, как в DWH. Но без копирования данных.
- Разделение вычислений и хранения — движок запросов (compute) работает отдельно от хранилища (storage). Можно подключить любой движок к тем же данным.
Настоящий герой этой истории — Open Table Formats
Вся магия случилась благодаря открытым форматам таблиц: Apache Iceberg, Delta Lake и Apache Hudi. Они добавили к обычным файлам в S3 то, чего им категорически не хватало: ACID-транзакции (никаких «файл записался наполовину»), эволюцию схемы на лету и Time travel (возможность запросить состояние данных на любой момент в прошлом).
В индустрии стандартом де-факто стал именно Apache Iceberg — его поддерживают практически все крупнейшие облачные и аналитические платформы.
Сравнение трёх подходов
Кому и когда это нужно?
Выбрасывать существующий DWH завтра утром не нужно. Переход на Lakehouse — это эволюция. Обычно мы рекомендуем начинать с пилота на 5–10 ТБ данных под новые бизнес-нагрузки. Его можно развернуть за 2–4 недели силами небольшой команды из 2–3 инженеров.
В итоге бизнес избавляется от ETL-ада, получает данные для BI и машинного обучения в реальном времени, а экономия на ИТ-инфраструктуре полностью окупает инвестиции уже за первый год.
Если вы хотите глубже погрузиться в техническую изнанку, узнать про неочевидные преимущества архитектуры и подводные камни внедрения, читайте полную версию статьи в нашем блоге: «Что такое DATA LAKEHOUSE» на Datanomix.pro.
Share
