Бұл жазба автоматты түрде аударылған. Бастапқы тіл: Орысша
Талдаушы кестені 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.
Трансформация: сиқыр осы жерден басталады. Деректер біртұтас құрылымға, түрлерге және мағынаға әкелуі керек. Көшірмелерді жою, қателерді түзету, бос орындарды толтыру, валютаны әкелу, жүйелер арасында идентификаторды синхрондау. Мұның бәрі SQL сұрауларына, құбырларға және ережелерге айналады.
Мысалы, кірісті есептеу үшін тапсырыстар мен төлемдерді біріктіріп, жойылғандарды алып тастап, бәрін Еуроға әкеліп, екі белгіге дейін дөңгелектеу керек. Дәл осы кезеңде талдаушы жұмыс істейтін бизнес-кестелер туады.
Егер сіз дисплейде әдемі revenue_eur бағанын көрсеңіз, есіңізде болсын: осы уақытқа дейін деректер ондаған тазалау, картаға түсіру және тексеру қадамдарынан өткен болуы мүмкін.
Жүктеу: барлық түрлендірулерден кейін деректер деректер терезелеріне (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 витрина болуды тоқтатады және тірі жүйенің бөлігі болады.
Когда аналитик открывает таблицу в 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 перестаёт быть витриной, а становится частью живой системы.
Бөлісу
