Что такое хранилище данных и как оно устроено?
Ты умеешь писать запросы в PostgreSQL и крутишь Python-скрипты. Но как работают с данными в Netflix или Ozon? Там не обойтись без хранилищ данных - про них и поговорим.
Представь, что ты оформляешь заказ в интернет-магазине, система должна мгновенно уточнить наличие товара, провести оплату и оформить заказ. Такие операции выполняются в OLTP-системах, они предназначены для работы с данными "здесь и сейчас".
Но что происходит с этими данными дальше?
Данные о его оформлении могут понадобиться для отчетности, составления статистики или модернизации уже внедренных процессов и даже обучения ML-моделей. Выходит, историчные данные нужно где-то сохранять? Вот тут-то и требуется помощь разработчика хранилища данных и вся мощь OLAP-систем.
В последние годы это направление стало особенно востребованным. С ростом информационных систем возрастает необходимость в эффективной работе с данными - их архитектуре, хранении истории и аналитической обработке. По данным IDC за последние 5 лет объем данных в корпоративном секторе вырос в 5 раз, а на hh.ru спрос на специалистов по хранилищам данных (Data Engineer / DWH Developer) увеличился в 3 раза. Сегодня это одна из самых быстрорастущих и высокооплачиваемых специальностей в IT.
Но что стоит за этими цифрами, почему компании готовы платить таким специалистам большие деньги? Давай заглянем под капот DWH.
Что вообще такое DWH?
DWH = Data Warehouse (Хранилище данных) - это централизованная система, которая собирает данные из различных источников, приводит их к единой структуре и хранит их для последующей аналитики, отчетности и поддержки принятия решений.
Но кто всем этим занимается? Познакомимся с областью разработки DWH.
Зачем нужен разработчик DWH и чем он занимается?
Разработчик DWH анализирует источники данных, соединяя данные из разных источников в единое хранилище, прорабатывает модель хранения данных, обрабатывает, приводя к формату, удобному для анализа.
Чтобы понять спектр задач разработчика, разберем DWH по слоям.
Какие слои данных выделяют в DWH?
1) От Data Lake к Staging Layer: путь данных в хранилище
Данные из различных источников - API, транзакционных баз, JSON-файлов, 1С баз, log-файлов, выгрузок из CRM/ERP, Kafka потоков, бэкапов в чистом, необработанном виде могут сначала попадать в Data Lake(озеро данных), откуда в дальнейшем загружаются в DWH. Внутри озера данные распределяют по слоям: Raw (сырые, исходные данные), Processed (очищенные), Curated (подготовленные для конкретных задач). Данные в Data Lake могут пригодиться ML-инженерам или дата сайентистам для обучения моделей.
Data Lake - это необязательный элемент. Данные могут поступать в Staging-слой и напрямую из источников, минуя озеро. Все зависит от архитектуры и задач компании.
Staging-слой является "подготовительным"/"промежуточным" в хранилище данных, так как содержит данные после процесса сбора, без каких-либо действий над ними.
Staging-слой служит также слоем «страхования», если возникнут проблемы при трансформации данных. Например, если при загрузке в хранилище прервалось соединение с базой или сервером, если некорректный запрос испортил данные или если в источнике изменилась структура полей. Данные в нем хранятся от нескольких часов до нескольких дней.
Возвращаясь к нашей аналогии, в интернет-магазине заказы приходят из разных мест: с сайта (в формате JSON), из мобильного приложения (логи), из 1С (таблицы выгрузок). Все эти данные сначала попадают в единое пространство - озеро данных, в Staging-слое эти файлы просто копируются в таблицы один в один.
2) Операционный слой (ODS Layer): первичная консолидация данных
Operational Data Store — Операционный Слой Данных.
В ODS данные попадают из Staging-слоя с помощью простых SQL-запросов или Python-скриптов, где данные проходят первичную очистку.
В нем приведены типы, убран явный мусор, источники данных объединены. Этот слой может быть использован для оперативных отчетов.
В нашем магазине заказы из разных источников теперь лежат в одной таблице, даты приведены к единому формату, пустые суммы заменены на 0, а в статусах удалены лишние пробелы.
Для перехода к следующему слою данные необходимо трансформировать.
Процесс их организации и обработки выполняется в рамках двух ключевых подходов — ETL и ELT. Выбор подхода определяет, как именно мы будем работать с данными.
ETL
Классический подход к интеграции данных, используемый несколько десятилетий. Его суть заключается в трех этапах:
Extract → Transform → Load (Извлечь → Преобразовать → Загрузить)
Трансформация данных происходит перед загрузкой в DWH с помощью, например, Python-скрипта (используем Pandas, SQL-alchemy, PySpark для очистки данных, фильтрации, агрегации, сортировк��, объединения и других операций)
ELT
Более современный подход при работе с данными. С ростом мощностей хранилищ дешевле трансформировать данные прямо в БД, чем гонять их через промежуточные серверы.
Подход также состоит из трёх этапов:
Extract → Load → Transform (Извлечь → Загрузить → Преобразовать)Трансформация данных происходит уже внутри DWH, операции выполняются непосредственно на мощностях хранилища данных или озера данных, используя доступные вычислительные ресурсы. Ключевые инструменты: CTE (создание временного набора строк), оконные функции, создание и заполнение витрин данных (DDL + DML команды).
Для выполнения ETL/ELT процессов используются специальные инструменты — например, Apache Airflow, dbt или облачные сервисы вроде Azure Data Factory. Они позволяют забирать данные из источников, трансформировать их и загружать в хранилище.
После выполнения этих процессов данные образуют следующий слой.
3) Слой детализированных данных (Core Layer): Сердце хранилища
В Core-слое данные уже очищены, нормализованы и хранят всю историю изменений.
Из этого слоя в будущем будут формироваться витрины данных, поэтому важно сформировать правильную архитектуру хранения данных.
Модель хранения данных определяется выбором методологии моделирования.
Чтобы перейти к описанию методологий, рассмотрим основные модели (схемы) данных.
Перед началом описания моделей введем два определения.
Таблица фактов - её главная задача ответить на вопрос "сколько?". При идеальной реализации модели хранит только число��ые значения и id ключей, однако может содержать и строковые значения, если те, например, отражают номера заказов.
Таблица измерений - вспомогательные таблицы, расшифровывающие сухие данные из таблицы фактов.
В общих чертах, таблица фактов используется для числовых расчетов, а таблицы измерений для группировки и фильтрации.
• Звездочка
Это денормализованная модель данных - модель, при которой данные повторяются в разных таблицах измерений для избежания процесса нормализации.
Процесс нормализации - это метод для устранения избыточности. Обычно в нормализованных базах данных каждая из таблиц хранит конкретный раздел, при необходимости добавления информация не дублируется в рамках таблицы, а присоединяется с помощью JOIN-ов.
Нормализованный принцип построения баз данных обычно используется в OLTP-системах. OLTP-системы предназначены для работы с данными «здесь и сейчас». Для работы с ними используются СУБД, которые тебе наверняка уже знакомы - это MySQL, PostgreSQL, Microsoft SQL Server. В них каждая таблица это отдельная сущность, проходящая нормализацию до 3 НФ.
Наряду с OLTP-схемами выделяют также OLAP-схемы. Им и посвящена эта статья. Они используются для обработки и анализа того, что уже произошло, поэтому их также называют "аналитическими" схемами.
Подобные схемы обычно содержат историчные данные, поэтому архитектура формируется с акцентом на анализ и оптимизацию под чтение. Данные в этих схемах не обязаны быть нормализованы. Они заточены под агрегации, а не транзакции.
Всему этому соответствует рассматриваемая модель "Звездочка"
В центре у неё таблица фактов, а от таблицы фактов отходят таблицы измерений.
Такая модель данных удобна для BI-разработки, потому что каждая из таблицы измерений отражает полную информацию одного из разделов (содержит все атрибуты одной сущности), благодаря чему легко демонстрировать отчеты.
Из минусов можно выделить плохую согласованность данных. Например, если "Москва" в разных фактах записана по-разному ("Мск", “Moscow"), будут проблемы с группировкой.
• Снежинка
Отличие от схемы «Звездочка» заключается в том, что каждое из измерений может иметь свое измерение.
Те измерения теперь становятся нормализованными (каждая сущность теперь находится в своей таблице, как в OLTP-системах.
Это значительно повышает согласованность данных, но уменьшает скорость выполнения запросов из-за большего количества JOIN-ов.
• Галактика
Схема, при которой несколько таблиц фактов используют одни и те же таблицы измерений. Из плюсов гибкость добавления новых таблиц, из минусов сложность изменения структуры - изменения в одной таблице отражается на зависимых таблицах.
Наше корпоративное хранилище интернет-магазина сейчас содержит обработанные данные, теперь данные "понятные" и "удобные", здесь хранятся все заказы за все время с полной историей: когда заказ создан, когда оплачен, когда доставлен, все изменения статусов. Данные агрегированы, трансформированы, осталось только построить витрины данных, в этом и заключается задача следующего слоя данных. В зависимости от цели, необходимо выбрать схему организации наших данных. Например, если нам необходимо построить BI-дашборды по результатам продаж по кварталам-выберем "Звездочку" или если предстоит строить несколько витрин на общих данных - удобно использовать схему «Галактика», чтобы избежать дублирования измерений, например для расчета целевых метрик.
Как мы уже упомянули выше, выбор схемы данных напрямую связан с методологией построения хранилища.
При построении хранилища по Кимбаллу - Core-слой будет звездой; по Инмону - Core будет в третьей нормальной форме, ближе к снежинке; Data Vault более сложный и гибридный подход с разделением данные на три типа сущностей (hubs, links и satellites). А галактика - признак того, что хранилище выросло и в нем появилось несколько фактов, использующих общие измерения.
4) Слой витрины данных (Data Marts Layer): то, ради чего всё строилось
Подмножество общего DWH, отвечающее за определенную тематику. Данные в нем денормализованы для конкретных областей и отчетов (например, BI-аналитика с помощью Tableau).
5) Semantic/access Layer: приёмная для бизнеса
Смоделированный для бизнеса слой, единая точка доступа и контроля для безопасности и управления.
Возвращаясь к аналогии, бизнес не хочет погружаться в то, как собраны и организованы данные - ему нужен результат. Запросы покупателей переводятся на "язык хранилища" - в нем могут быть предрассчитанные агрегаты, бизнес-логика и настройки доступа. BI-инструменты подключаются именно сюда. Руководитель видит готовые дашборды в Tableau с отчетами и не думает, как устроены JOIN-ы и какую модель хранения данных лучше выбрать.
На первый взгляд архитектура хранилищ данных может показаться сложной областью работы с данными, но на самом деле она строится из довольно понятных принципов. Я надеюсь, что эта статья помогла вам сформировать общее представление о том, что такое хранилища данных и чем занимается их разработчик.
Разработчик DWH должен уметь не только писать код и строить архитектуру, но понимать бизнес-ценность данных. Для этого стоит помнить о фундаментальных понятиях в теории баз данных: о прозрачности, согласованности, отказоустойчивости и историчности, а также о репликации и фрагментации. Об этих механизмах, позволяющих строить масштабируемые и надежные системы хранилищ данных, я расскажу в следующей статье.
