Что такое DWH
Стойкая потребность в корпоративных хранилищах данных появилась еще в 90-х годах 20-го столетия. В этот период в бизнес-среде активно стали применяться информационные системы. Они применялись компаниями для контроля многих показателей эффективности работы, обеспечивая возможность мгновенно реагировать на их изменения. Каждое из приложений локально автоматизировало процесс производства или продажи товара, выполнение бухгалтерских расчетов, проведение банковских операций, позволяло составлять аналитику. Основные сложности на этом этапе состояли в разных рабочих схемах различных систем, что приводило к расхождению информации. Не было возможности получать консолидированные данные, позволяющие создать полноценную картину из отдельных прикладных систем.
Решить данную проблему призвано корпоративное хранилище данных – Data Warehouse, или DWH. Это предметно-ориентированная база данных, позволяющая автоматически готовить консолидированные отчеты и выполнять интеграцию бизнес-анализа. Благодаря ей пользователь получает возможность своевременно принимать правильные решения по управлению на основе целостной информационной картины. Так в чем отличие DWH от обычных баз данных? Почему она настолько привлекает внимание бизнес-аналитиков? Нужна ли она вашей компании? Постараемся найти ответы на эти вопросы.
Отличия DWH от других баз данных
Data Warehouse – это хранилище данных, которые нужны вашей компании для принятия решений. От обычных баз они отличаются:
- Типом данных, которые будут в нем храниться. Обычные системы, в частности СУБД предназначаются для сбережения информации от конкретных подсистем. Если это складская база, то и данные, находящиеся в ней, будут иметь непосредственное отношение к складу. Если отдела кадров – информация о персонале. В DWH будут находиться общие сведения от всех подразделений вашего предприятия или организации, начиная от персонала и вплоть до заключенных, выполненных сделках.
- Объемами хранимой информации. В простых базах данных находится только та информация, которая в определенный момент времени нужна для работы определенного сектора. В Data Warehouse записываются не столько актуальные состояния, как архивные, агрегированные. Можно получить информацию о полных продажах за определенный период времени или конкретный месяц на протяжении последних 5 лет и пр.
- Местом в рабочем процессе. Изначально все данные поступают в рабочие базы, а уже оттуда подтягиваются в корпоративное хранилище. И если в рабочую базу будут внесены корректировки или изменения, то они сразу же отобразятся и в DWH. Это в разы повышает эффективность труда и позволяет постоянно иметь под рукой актуальные данные.
То есть ответ запрос: DWH что это прост – это отдельная от оперативной системы база для хранения архивной информации от разных источников. Она работает совместно с процессами извлечения, загрузки или преобразования корпоративных данных (ETL). В результате получается единая система для хранения корпоративных сведений и работы с ними.
Основные аспекты формирования маппинга витрины для миграции
В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.
Перед разбором алгоритма маппирования разберем основные понятия.
Начнем с термина «витрина данных». Это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности: продажи, финансы или маркетинг. Источниками данных для витрины могут служить: центральное хранилище, внутренние операционные системы, а также внешние данные. Миграция используется для повышения скорости обращения с данными и построения бизнес-отчетов, повышения уровня безопасности информации в рамках импортозамещения на отечественное ПО и т.д.
Миграция витрин — перемещение витрин, например, в новую, более технологичную СУБД, включающее в себя изменение тракта сбора данных из систем-источников в представление витрины. Стоит отдельно выделить два омофона: репликацию и интеграцию данных — эти термины также относятся к теме перемещения данных.
Интеграция может быть непрерывным процессом, который включает потоковую передачу данных в реальном времени и обмен информацией между системами. А при репликации вы периодически переносите данные в целевое расположение, не удаляя и не отбрасывая их источник. Стоит отметить, что репликация данных может быть частью процесса интеграции данных. Например, миграция исторического среза витрины — что особенно актуально при введении в целевой базе данных нового источника, не имеющего истории.
Маппирование данных — это процесс сопоставления полей данных на источнике и связанных с ними полей данных в приемнике. То есть это установление соотношения между моделями данных, которые находятся в разных местах.
Маппинг — это описание соответствия между исходными и импортируемыми данными. В большинстве случаев это таблица, где правая часть отведена под источники витрины, а левая часть содержит поля витрины. Для каждого импортируемого поля создается отдельная строка маппинга.
Также в статье используются понятия «сущность» и «атрибут».
Атрибут — это поле (столбец) таблицы данных, сущность — таблица с атрибутами. Например, в сущности «Клиент» находятся атрибуты «ИНН», «Наименование организации», «Статус действия» и т.д.
Перейдем к практическим вопросам формирования маппинга витрин.
Маппинг можно сформировать «ручным» способом или с использованием специального ПО, пару слов о котором расскажу в конце статьи.
Проведение «ручного» маппирования витрины разделим на этапы:
Фиксация витрины и сбор информации о ней;
Анализ атрибутного состава;
Поиск первоисточников и систем-источник данных;
Анализ актуальных источников;
Проверка корректности заполнения и согласование маппинга.
Разберем каждый из них.
Первый этап. Фиксация витрины и сбор информации о ней
На основании опыта взаимодействия с бизнес-заказчиками на проекте рекомендую: прежде чем приступить к маппингу витрины, необходимо зафиксировать дату начала работ у заказчика и выявить их требования к реализации витрины.
Зачем это необходимо сделать? Частым случаем бывает, что бизнес-заказчик после включения витрины в план миграции проводит по ней доработки или вносит изменения. В результате, не уведомив бизнес-заказчика о начале работы над витриной, высока вероятность «отработать» не актуальный состав витрины. За чей счет будет происходить «переработка» — становится острым вопросом при организации работ на проекте.
Исходя из проектного опыта, предлагаю совмещать письмо к бизнес-заказчику о фиксации витрины с запросом первичной информации о ней. Вопросы в письме могут быть сформулированы следующим образом:
Планируются ли внесения изменений в атрибутный состав витрины или ее логику? Соответственно, можно ли начинать работы по витрине, строить ее маппинг?
Какой бизнес-смысл витрины, в чем ее «ценность» для бизнеса?
Где расположен актуальный S2T (source to target — преимущественно табличное описание соотнесенных между собой полей источника и витрины, если проще, это маппинг на изначальной БД), прототип и скрипт разработки (попросить ссылку)?
Какие должны быть глубина истории, историчность и регламент обновления для витрины в новом источнике? . Так, глубина истории может потребовать привлечения дополнительных источников, следовательно, расширения маппинга, или объемов для хранения, или оптимизации кода.
Какая система-источник для витрины?
Какие предъявляются требованиях к прототипу, к эталону (для сравнения) и какие необходимо провести тест-кейсы?
В каком формате необходимо предоставить итоговый маппинг по витрине (попросить шаблон) ?
Полученную информацию рекомендуется зафиксировать в удобном для вас виде, но доступном для использования другими членами команды (если возникнет потребность в ней во время вашего отсутствия). Например, сохранить письмо в папке на общекомандном файловом ресурсе или создать под витрину страницу в Confluence (при наличии возможности).
Второй этап. Анализ атрибутного состава S2T витрины
Особое внимание стоит уделить правилам, нормативам и требованиям, принятым у бизнес-заказчика. Важно уточнить у коллег по проекту/бизнес-заказчиков – какие существуют шаблоны, правила оформления результатов маппирования, основные и обязательные этапы работы на конкретном проекте, предусмотренные инструменты/ПО – все это позволит быстро и результативно, а, главное, корректно составить маппинг витрины.
Начнем с того, что в S2T витрине все расчетные атрибуты должны быть разложены на первичные атрибуты, а технические поля иметь однозначный алгоритм расчета.
В корректном S2T должны содержаться все использованные в скрипте витрины поля, в том числе те, которые используются при фильтрации и наложении ограничений. Это можно проверить с помощью скрипта на сборку витрины. Однако, это достаточно трудоемкий процесс, требующий согласования с заказчиком. Вполне возможно, что подобные работы уже проведены и дополнительный анализ будет излишним и дублирующимся шагом.
Перейдем к анализу бизнес-смысла атрибутов витрины. Для этого необходимо проверить – имеют ли поля однозначный смысл и полностью ли раскрыто их значение. Если есть сомнения в понимании атрибута – запрашиваем у бизнес-заказчика его смысл. Данное действие необходимо для последующего проведения корректного анализа и сопоставления полям витрины сущностей и атрибутов в новой БД.
Например, поле витрины с бизнес-описанием «Тип компании» имеет под собой минимум два значения. Атрибут может содержать информацию о том, является ли компания юридическим, физическим лицом (ИП) или информацию, касающуюся ее организационно-правовой формы (ООО, АО, ЗАО).
При наличии в бизнес-описании полей аббревиатуры также рекомендуется запросить их расшифровку. Понятное и общепринятое на первый взгляд сокращение может иметь у заказчика совершенно иной смысл. Например, КЭП: квалифицированная электронная подпись или коэффициент эффективности предприятия.
Третий этап. Поиск первоисточников и систем-источник данных
Этап зависит от требований заказчика и может быть пропущен. Причина в том, что он включает в себя поиск таблиц-источников и систем-источников, которые используются при формировании витрины в настоящее время, т.е. уже неактуальные. В любом случае, данный этап поможет ускорить маппирование четвертого этапа, если при анализе будет обнаружен маппинг данных старого источника на новый источник. С его помощью возможно не только значительно сэкономить время составления итогового маппинга витрины, но также избежать ошибок некорректного сопоставления полей.
Суть этапа – выявить трек (data lineage), используемый при построении витрины данных до систем-источников.
Этап поиска включает в себя анализ всего жизненного пути данных, например, используя:
ER-модели хранилища данных;
Confluence бизнес-заказчика (при наличии, или иной аналогичный инструмент);
Informatica (при наличии);
Если для построения витрины используются поля из другой витрины (далее – витрина-источник), но ее миграция не планируется или заказчиком был введен запрет формировать на новом источнике витрину на другой витрине (т.е. делать их взаимосвязанными), то также необходимо провести анализ полей из витрины-источника. Анализ витрины-источника будет аналогичный анализу по заказанной витрине.
Четвертый этап. Анализ актуальных источников
После выявления всех источников и первоисточников для витрины необходимо произвести корректировку плана миграции витрины. На этом этапе необходимо определить актуальные атрибуты для витрины в новой БД. Как правило, для БД существует описание реализованных/запланированных к реализации сущностей – формат представления этих данных может быть любой. Для упрощения понимания описание сущностей и атрибутов в новой БД (модель данных) представим в виде Excel-файла со следующим наполнением:
Наименование сущности и ее бизнес-описание;
Наименование атрибута и его бизнес-описание атрибута;
Наименование область сущности (группы сущностей, объединенных общим смыслом).
Это упрощенное в рамках статьи описание логики хранения данных. Возможно, на проекте описание модели данных будет содержать информацию и о формате данных, и о связях сущностей, ключах и т.д.
При анализе модели данных удобно идти как от общего к частному, так и от частного к общему.
В первом случае выбираем основное поле в витрине, например, «ИНН». Находим по бизнес-описанию атрибутов основную сущность с данным атрибутом. Далее последовательно соединяем необходимые по смыслу сущности и их атрибуты. Так как мы начинали сборку витрины от атрибута «ИНН», логично, что он находится в сущности «Клиенты», также для витрины нам нужна информация по кредитным договорам и выручке клиента. Эту информацию через поля-связки мы получим в сущностях, соответственно, «Договоры» и «Справочник аналитических показателей». Не забываем про указание в самом маппинге ключевых полей для связок.
Во втором случае необходимо определить основную узконаправленную область данных сущности, исходя из бизнес-описания полей витрины (в модели данных это «область сущности»). Например, «РКО» (расчетно-кассовое обслуживание) или «Операции», если витрина отражает информацию по заключенным договорам РКО или операциям клиентов по счетам, соответственно. После анализа узконаправленные сущностей и атрибутов переходим к общераспространенным – «Клиенты».
Что делать, если не нашли в новой БД требуемых для витрины атрибутов:
Выясняем у коллег (аналитиков, руководителей, бизнес-заказчика), установлен ли алгоритм действия в данном случае, если установлен – действуем согласно алгоритму. Алгоритм может быть изложен в нормативной документации: регламенты, методички.
Если порядок действий не регламентирован (рекомендуемый порядок):
а) Уведомляем своего руководителя об отсутствии данных в БД;
б) Пишем уточняющих запрос по данному атрибуту в команду проектирования модели БД (действительно ли БД отсутствую данные);
с) При получении ответа об отсутствии в БД необходимых данных – уведомляем бизнес-заказчика о проблеме, совместно прорабатываем пути решения.
Важно не молчать об отсутствии данных, так как это может сказаться на реализации проекта в целом.
Пятый и заключительный этап. Проверка корректности заполнения и согласование маппинга
Необходимо проверить наличие в маппинге всех запрошенных бизнесом в S2T атрибутов, а также наличие атрибутов-связок для актуальных источников. Еще раз уточнить соответствие бизнес-логики атрибутов и самой витрины, чтобы избежать противоречий между ними. В итоге маппинг витрины (формат запросили на первом этапе) может содержать следующую информацию:
о бизнес-смысле витрины, ее историчности, глубине истории и регламенте обновления, требованиях к прототипу. Также это ссылки на источники информации по витрине;
о сущностях, на которых строится витрина сейчас;
из каких систем-источников собирается информация для витрины;
об актуальных сущностях, на которых витрина строится после миграции.
Эти данные позволят провести миграцию витрины с сохранением ее логики и «полезности» для бизнес-заказчика. Необходимо уточнить регламент наименования атрибутов и сущностей у бизнес-заказчика.
Может потребоваться провести проверку на соответствие текущих наименований атрибутов витрины требованиям (например, в части суффиксов по типу «_date» или «_rk»). Также могут существовать правила относительно форматов данных атрибутов в новой БД. Например, даты необходимо отражать со указанием временм или даты.
Стоит также обратить внимание на корректность отражения ключевых полей в витрине.Так как маппинг витрины – это важный документ проекта (артефакт), на момент его готовности стоит перепроверить соответствие формата маппинга требованиям заказчика/привести к единообразию с предыдущими маппингами.
После завершения работ с маппингом, рекомендуем направить его на согласование и утверждение заказчику – особенно критично при переименовании полей, так как у заказчика могут быть особые обстоятельства, не допускающие переименования полей витрины.
После получения согласования от заказчика работы по витрине в части маппинга можно считать оконченными.
Предлагаю сейчас ознакомиться с программами, позволяющими оптимизировать процесс маппирования.
Один из таких продуктов – Informatica PowerCenter. Это платформа интеграции данных, работающая на визуализацию данных без написания программного кода. Для формирования маппинга возможно использовать такие особенности и функции Informatica, как:
Графическое представление потоков данных, анализ взаимосвязей и отслеживание данных;
Реализация логики обработки данных в визуальной среде. Автоматизация запуска процессов также выполняется в визуальной среде;
Наличие бизнес-глоссария (может и отсутствовать, но возможность его создания предусмотрена).
Что понравилось в Informatica, так это возможность через одну таблицу проанализировать – из каких таблиц-источников она собирается, а также в какие таблицы эти данные «уходят». Также удобно наличие бизнес-описания полей и таблиц (на практике такая информация не часто встречается).
Пример отображения информации в Informatica:
Стоит обратить внимание, что не каждая связь между таблицами может быть отражена в Informatica (заказчик мог ее и не занести).
Еще одним полезным инструментом является ER-диаграмма. Так как принцип работы программ по построению диаграмм одинаковый, поэтому расскажем их плюсы для маппирования, не привязываясь к конкретному ПО.
Начнем с того, что ER-диаграмма – это схема «сущность-связь», разновидность блок-схемы, где показано – как разные «сущности» (сотрудники, договоры и т.п.) связаны между собой внутри системы. Как и в Informatica, ER-диаграмма – это наглядное представление связи таблиц через ключи. Ключи — один из способов категоризации атрибутов, применяются с целью максимально эффективно связать между собой разные таблицы в базе данных.
Плюсы наглядного представления связи таблиц очевидны — легкое восприятие и понимание базы данных, так как все «как на ладони». Из минусов — в большинстве диаграмм не уточнен бизнес смысл полей, соответственно, что конкретно поле означает можно и не понять сразу.
Не забудьте уточнить — какие подобные инструменты использовались на вашем проекте — возможно, данные для миграции уже представлены в виде ER-диаграмм.
Есть еще два продукта от Microsoft, которые представят связи между таблицами данных в табличном виде — это Excel и Access. Первая программа наверняка вам известна, со второй уже могут быть вопросы.
У них примерно одинаковый принцип работы: при импорте связанных таблиц из реляционной базы данных ПО может создавать эти связи (через ключевые поля) в модели данных, формируемой в фоновом режиме.
Попробовав различные технологии при маппировании, приходим к выводу, что существующее и доступное ПО самостоятельно создать маппинг не может, но в качестве сокращения трудозатрат при проведении анализа может быть очень полезным.
Возможно, вы захотите поделиться личным опытом использования ПО на проекте: что для вас оказалось действительно полезным, а что — не стоило потраченного времени на изучение?
Что такое Data Warehouse (DWH) и зачем крупному бизнесу корпоративное хранилище данных
Данные — новая нефть. Чем больше их у компании, тем эффективнее она сможет привлекать новых клиентов, разрабатывать стратегии развития и укреплять свою позицию на рынке.
Для хранения данных используются специальные типы хранилищ — Data Warehouse. Разберемся, чем DWH отличается от других способов хранения данных, как используются такие решения и для каких компаний они актуальны.
DWH: чем отличается корпоративное хранилище от обычных БД
Бизнес стал активно интересоваться корпоративными хранилищами еще в конце прошлого века. Их внедряли для увеличения скорости реагирования на изменения, мониторинга показателей эффективности и автоматизации процессов. Разные приложения отвечали за разные процессы: одни использовались для финансовых операций, другие — для координации цепочек поставок, третьи помогали анализировать показатели продаж.
Однако такой подход привел к тому, что ключевые данные бизнеса хранились разрозненно. Компаниям требовалось решение, которое бы позволило анализировать информационную картину целиком, а не данные из разных систем по отдельности.
Для решения этой проблемы был создан особый инструмент — корпоративное хранилище данных, или Data Warehouse. Фактически DWH — это предметно-ориентированная база данных, которая консолидирует важную бизнес-информацию и позволяет в автоматическом режиме подготавливать консолидированные отчеты.
Data Warehouse — это единое корпоративное хранилище архивных данных из разных источников (систем, департаментов и прочее). Цель Data Warehouse — обеспечить пользователя (компанию и ее ключевых лиц) возможностью принимать верные решения в ключе управления бизнесом на основе целостной информационной картины.
DWH — это не просто база данных
Корпоративное хранилище данных отличается от обычных БД, используемых в бизнесе, по нескольким параметрам:
- Тип и источник данных
Обычные БД хранят данные от конкретных информационных систем компании. Например, в базе данных HR-отдела мы увидим информацию о сотрудниках, а вот данных о поставках там не будет. DWH строится по другому принципу: такое корпоративное хранилище консолидирует в себе информацию от всех департаментов компании — от статистики продаж до сведений о сотрудниках. - Объем данных
Обычные базы используются для хранения только актуальной информации — в ней не имеет смысла хранить данные за несколько лет работы предприятия. В Data Warehouse, наоборот, стекаются исторические данные и архивные сведения. Например, заглянув в DWH, можно получить информацию о всех сделках за последние несколько лет. - Роль в бизнес-процессах
Изначально данные хранятся в обычных БД и уже оттуда поступают в DWH. Иными словами, Data Warehouse всегда содержит последние версии данных.
Как бизнес использует DWH
DWH — не только склад важных данных компании, но еще и основа бизнес-аналитики (BI). Именно из корпоративного хранилища компания получает сведения, необходимые для принятия управленческих и стратегических решений.
Давайте на простом примере посмотрим, как это работает.
- У крупного интернет-ретейлера зафиксировано снижение продаж. Для решения проблемы привлекается бизнес-аналитик.
- Специалист, получив доступ к DWH, начинает изучать ключевые показатели: размер выручки, количество клиентов, издержки и прочее.
- После этапа изучения аналитик формирует отчет, в котором, на основе полученных из Data Warehouse данных, указаны причины возникновения проблемы. Результат отчета подкрепляется статистической информацией.
- Принимающие решения лица на основе сведений из аналитического отчета, принимают эффективные меры по увеличению уровня продаж, например, корректируют стратегии и политики продвижения продуктов компании.
Корпоративное хранилище позволяет не искать решение вслепую, а выявить источники проблемы. Обычные базы данных просто не позволяют этого сделать, потому что:
- не хранят исторических сведений;
- данные из разных БД хранятся разрозненно, не давая единой информационной картины;
- на поиск и сопоставление информации из обычных БД уйдет внушительное количество времени и других ресурсов.
Почему DWH — эффективный инструмент аналитики
Корпоративное хранилище играет роль большого склада данных. Давайте посмотрим, в погоне за какими возможностями компании организовывают DWH.
- Оперативный доступ к нужной информации
Чем крупнее компания — тем больше в ней отделов, каждый из которых генерирует свои потоки данных. И тем сложнее аналитику получить быстрый доступ к нужным сведениям. Только представьте: для анализа одной проблемы необходимо запрашивать доступы и разрешения к разным БД разных департаментов. Пока аналитик получит все необходимые ему сведения, пройдет очень много времени. DWH решает эту проблему, обеспечивая быстрое получение всей необходимой информации. - Продолжительная сохранность данных
Как правило, обычные БД не используются для хранения информации за десять последних лет работы компании. А вот для DWH такой срок — абсолютная норма. При этом все данные хранятся в оптимальном формате, включая агрегированные значения. - Исключение влияния бизнес-аналитики на другие процессы и системы
Если аналитическому отделу вдруг понадобятся большие массивы данных и специалисты пойдут выгружать их из DWH, нагрузка на хранилище не повлияет на работу других информационных систем и бизнес-приложений.
Структура DWH
Data Warehouse состоит из нескольких уровней:
- Область сбора первичных данных. Сюда стекается информация из разных отделов компании и БД.
- Ядро. Вся поступившая в DWH разрозненная информация приводится к нужным структурам и ключам. Именно этот ключевой компонент хранилища обеспечивает целостность и полноту данных.
- Витрины аналитики. Данные преобразовываются в массивы, которые удобно использовать для решения конкретных задач. Такие витрины могут быть первичными (помогают решать относительно простые задачи) и вторичными (для сложных аналитических отчетов и нетиповых задач).
- Сервисный слой. Отвечает за управление тремя предыдущими уровнями. Обеспечивает мониторинг данных и оперативное устранение ошибок.
DWH и Business Intelligence
Актуальные инструменты бизнес-аналитики (BI) вкупе с возможностями DWH позволяют принимать управленческие решения с гарантированным результатом. Благодаря эффективному анализу больших массивов данных менеджмент компании также может выдвигать гипотезы, построенные на реальных бизнес-показателях, и тестировать их.
Data Warehouse не только помогает решать конкретные прикладные задачи (например, увеличение прибыли, снижение издержек), но и выстраивать стратегию развития компании на основе data-driven подхода.