The post has been translated automatically. Original language: Russian
When an analyst opens a table in BI, everything looks simple: there are fields, the data converges, and the metrics count. It seems that the numbers just "lie somewhere" like in Excel, only centrally. But under this appearance of peace, there is a huge engineering job.
What we call ETL - Extract, Transform, Load - is the heart of any data warehouse.
What is ETL and why is it needed?
If you explain it in human language, ETL is the process of turning raw, chaotic data from different sources into a neat, understandable structure that can already be worked with analytically.
You can compare it to a coffee shop.
You have grain suppliers (sources), baristas (engineers), and a customer who just wants a cup of coffee (analyst).
The client cannot see how many stages of roasting, grinding and filtering the grains have gone through, but this is what determines the taste of the result.
Example: Let's take an online store. Data about orders comes from CRM, about customers from the user base, about payments from the financial system, and about refunds from support.
Each system lives in its own logic. There may be a customer with ID 123 in CRM, and the same person in payments, but with user_456. In one table, the dates are in the YYYY-MM-DD format, in the other it is DD.MM.YYYY. Somewhere the amount is in euros, somewhere in cents, somewhere else and with tax.
Now imagine: you need to calculate the average check for the day.
If you just "glue everything together", the result will be false.
And that's where ETL comes into play.
Extract - Extraction: At the first stage, data is extracted from all sources: CRM, ERP, API, logs.
The main goal is not to lose anything.
The raw data is saved to the staging layer, unchanged. It's like bringing grain to a warehouse: dirty, in bags, but real.
Sometimes, at this stage, you already need to decide how often to update the data, once a day, once an hour, or in real time. It's a matter of architecture: batch or streaming.
Transform - Transformation: This is where the magic begins. The data needs to be brought to a single structure, types, and meaning. Delete duplicates, fix errors, fill in gaps, bring currency, synchronize IDs between systems. All of this turns into a series of SQL queries, pipelines, and rules.
For example, to calculate revenue, you need to combine orders and payments, exclude cancelled ones, convert everything to euros, and round it to two digits. It is at this stage that the very business tables are born, which the analyst then works with.
And if you see a beautiful revenue_eur column in the showcase, remember: up to this point, the data may have gone through dozens of steps of cleaning, mapping and verification.
Load - Loading: After all transformations, the data is loaded into Data Marts. These are no longer technical, but analytical tables, each of which answers a specific business question.
For example:
, dm_orders are all orders with revenue and discounts,
, dm_customers are clients with signs of activity,
dm_marketing is the effectiveness of campaigns and sources.
This is the layer that connects to BI tools. What the analyst opens as a "data table" is actually the last page of a long engineering book.
What it looks like in DWH: A good data warehouse usually has three logical layers:
1. Staging raw data from sources, no changes.
2. Core cleaned up, consistent tables (still without business logic).
3. Data Marts storefronts for specific reports, models, and dashboards.
Movement between the layers is provided by pipelines, sequences of SQL scripts, Python jobs, or Airflow dashboards. They are performed automatically, for example, every night at 3:00, so that the business gets the latest figures in the morning.
Why this is important to understand is also analytics. Many analysts work “at the last mile” in BI, where everything is ready. But if you don't understand how this data got there, you can draw beautiful but false conclusions.
When you know how ETL works:
You are asking the right questions to the engineers;
Do you understand where data errors are possible;
You can suggest improvements to the logic, not just a report.
And then BI ceases to be a showcase, but becomes part of a living system.
Когда аналитик открывает таблицу в BI, всё выглядит просто: есть поля, данные сходятся, метрики считаются. Кажется, что цифры просто «где-то лежат» как в Excel, только централизованно. Но под этой видимостью покоя скрывается огромная инженерная работа.
То, что мы называем ETL - Extract, Transform, Load - это сердце любого хранилища данных.
Что такое ETL и зачем он нужен
Если объяснить на человеческом языке, ETL, это процесс превращения сырых, хаотичных данных из разных источников в аккуратную, понятную структуру, с которой уже можно работать аналитически.
Можно сравнить это с кофейней.
У тебя есть поставщики зерна (источники), бариста (инженеры), и клиент, который просто хочет чашку кофе (аналитик).
Клиенту не видно, через сколько стадий обжарки, помола и фильтрации прошли зёрна, но именно это и определяет вкус результата.
Пример : Возьмём интернет-магазин. Данные о заказах приходят из CRM, о клиентах из базы пользователей, о платежах из финансовой системы, а о возвратах из саппорта.
Каждая система живёт в своей логике. В CRM может быть клиент с ID 123, а в платежах тот же человек, но с user_456. В одной таблице даты в формате YYYY-MM-DD, в другой это DD.MM.YYYY. Где-то сумма в евро, где-то в центах, где-то ещё и с налогом.
Теперь представьте: нужно посчитать средний чек за день.
Если просто «склеить всё», результат будет ложным.
И вот здесь вступает в игру ETL.
Extract - Извлечение: На первом этапе данные вытягиваются из всех источников: CRM, ERP, API, логов.
Главная цель, не потерять ничего.
Сырые данные сохраняются в слой staging, без изменений. Это как привезти зерно на склад: грязное, в мешках, но настоящее.
Иногда на этом этапе уже нужно решить, как часто обновлять данные, раз в день, раз в час или в реальном времени. Это вопрос архитектуры: batch или streaming.
Transform - Преобразование: Вот здесь начинается магия. Данные нужно привести к единой структуре, типам и смыслу. Удалить дубли, исправить ошибки, заполнить пропуски, привести валюту, синхронизировать ID между системами. Всё это превращается в серию SQL-запросов, пайплайнов и правил.
Например, чтобы посчитать выручку, нужно объединить заказы и платежи, исключить отменённые, привести всё к евро и округлить до двух знаков. Именно на этом этапе рождаются те самые бизнес-таблицы, с которыми потом работает аналитик.
И если на витрине вы видите красивую колонку revenue_eur, помните: до этого момента данные, возможно, прошли через десятки шагов очистки, маппинга и проверки.
Load - Загрузка: После всех преобразований данные загружаются в витрины данных (Data Marts). Это уже не технические, а аналитические таблицы, каждая из которых отвечает на конкретный вопрос бизнеса.
Например:
📌 dm_orders это все заказы с выручкой и скидками,
📌 dm_customers это клиенты с признаками активности,
📌 dm_marketing это эффективность кампаний и источников.
Это слой, который подключается к BI-инструментам. То, что аналитик открывает как «таблицу с данными», на самом деле, последняя страница длинной инженерной книги.
Как это выглядит в DWH: В хорошем хранилище данных обычно есть три логических слоя:
1. Staging сырые данные из источников, без изменений.
2. Core очищенные, согласованные таблицы (ещё без бизнес-логики).
3. Data Marts витрины под конкретные отчёты, модели и дашборды.
Движение между слоями обеспечивается пайплайнами последовательностями SQL-скриптов, Python-джоб или Airflow-дашбордов. Они выполняются автоматически, например, каждую ночь в 3:00, чтобы утром бизнес получил актуальные цифры.
Почему это важно понимать, также аналитику. Многие аналитики работают “на последней миле” в BI, где уже всё готово. Но если не понимать, как эти данные туда попали, можно сделать красивые, но ложные выводы.
Когда вы знаете, как устроен ETL:
📌 вы задаёте правильные вопросы инженерам;
📌 понимаете, где возможны ошибки в данных;
📌 можете предложить улучшения логики, а не просто отчёт.
И тогда BI перестаёт быть витриной, а становится частью живой системы.
Share
