Business DWH (DataWareHouse): аналитическое хранилище данных
Построение хранилища данных (например на базе аналитических СУБД - Arenadata, PostgrePro) — проект, требующий серьезной проработки и усилий со стороны бизнеса и поставщика информационных технологий. Наиболее эффективным подходом здесь будет совместный проект предприятия и компании, специализирующейся в этой области. Общемировая практика показывает, что хранилища данных создаются под конкретного заказчика. Серьезным преимуществом является наличие квалифицированного персонала, типовых Витрин Данных, а также отраслевой модели данных.
Хранилище может содержать:
- Учетную информацию о клиентах (персональные данные, адреса, телефоны)
- Информацию о банковских продуктах и услугах (кредиты, депозиты, пластиковые карточки, мобильный банк и т.д. )
- Данные об операциях (включая карточные) в минимальной детализации за последние 3 года
- Сведения о счетах, остатках на них и т.д.
Чтобы спроектировать хранилище данных (DWH, DataWareHouse),
нужно ответить на вопросы о требованиях к хранилищу в целом:
Нужно определиться с назначением этого хранилища:
- оно строится для BI системы;
- для сотрудников для формирования своих отчетов;
- общее решение для двух вариантов.
Во всех трех случаях, первым делом важно выявить целевых пользователей. Какие отчеты они используют в своей работе (важны запросы этих отчетов), что им не хватает.
Далее отталкиваться от этого и проектировать систему. Делать сразу для всех не получится: отчеты будут работать правильно и приемлемо (по времени), если хранилище заточено на работу с ними. В случае с BI, в некоторых системах мы можем переложить часть ETL (процесс Extract-Transform-Loading) на сторону BI, но это зависит от выбранной системы.
В случае, если это только для BI, то нужно учитывать выбранную систему. Как писали выше, некоторые BI системы имеют свой мощный ETL и при этом это технология in-memory, что в разы сокращает время преобразования данных (чеки, остатки – большой поток данных, даже с учетом инкрементальной загрузки). Речь не о полном переносе трансформации в BI, а о совмещении инструментов.
В случае, если это для отчетов пользователей – то нужно понимать, какие запросы будут чаще всего делаться к хранилищу и затачивать его на эти конкретные запросы (80% всех запросов должны отрабатываться оптимально, 20% - нет, но они должны быть редкими)
В случае, если для обоих вариантов – все рассчитывается на уровне хранилища. BI – это просто инструмент визуализации (но вопрос зачем двойная отчетность).
После того, как появится понимание цели хранилища и примерных аналитик, которые в нем будут, нужно понять в каком виде нужно хранить эти данные.
Например: количество чеков может быть аддитивным и неаддитивным; остатки – нужны движения или предрассчитанные остатки, какой период нужен, частота обновления и т.д.
После этого шага можно будет спроектировать модель, реализовать в рамках пилотного проекта один из его блоков. Реализация позволит правильно оценить размеры хранилища (на n-ый период времени с учетом прироста).
Построение хранилища данных:
- Разработка Устава Проекта;
-
Создание на корпоративном web-портале (или иной web-системе) узла Проекта и формирование структуры web-узла:
- библиотека бизнес-требований и методик;
- раздел Протоколов рабочих совещаний, текущих задач;
- подраздел обсуждений рабочих вопросов (возможно, в виде форума, трекинга);
- разделы документации по хранилищу данных, витринам, OLAP-кубам;
- система знаний (wiki);
- библиотека регламентов;
- раздел обучения, web-касты;
- и другие разделы".
- Сбор фрагментарных знаний о бизнес-процессах (БП) компании и метриках посредством проведения серий интервью с ключевыми бизнес-сотрудниками, экспертами. Формализация БП в виде укрупненных графических схем (например, BPMN-нотация);
- Получение доступов к учетным системам (желательно к копиям; доступ как на чтение данных на уровне СУБД, так и просмотру данных через графический интерфейс пользователя);
- Сбор и обсуждение методик, реализованных в существующих регламентных/управленческих отчетах;
- Формулирование требований/ обсуждение методологий для новых/желаемых регламентных/управленческих отчетов;
- Систематизация бизнес-требований (по результатам п.п 3, 5, 6) к составу атрибутов данных, которые должны быть отражены в хранилище данных;
- Построение/актуализация и описание логических моделей учетных систем - источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
- Описание/актуализация физических моделей (построение ER-диаграмм) учетных систем - источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
- Анализ и формализация бизнес-требований к составу атрибутов данных (по п.п. 7, 8, 9), которые должны быть отражены в хранилище данных;
- Подготовка технологической площадки для BI: сервер разработки, тестирования, производственного; установка серверного и прикладного программного обеспечения;
- Разработка (возможно реинжиниринг существующих) процедур по извлечению необходимых данных (п. 10) из учетных систем в буферные таблицы (stage area); наполнение буферных таблиц;
- Профилирование данных (по п.12), извлекаемых из учетных систем; систематизация статистики по метаданным и данным учетных систем;
- Разработка логической модели хранилища данных;
- Разработка структуры физической модели хранилища данных;
- Разработка концептуальной схемы, подходов ETL-процессов по загрузке данных из учетных систем в хранилище данных;
- Разработка карты мэппингов (поля source --> поля target);
- Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных справочников из учетных систем в таблицы измерений (dimensions) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
- Разработка процедур первичной/критической очистки/дедубликации данных справочников (совместно с п.18) [Проект НСИ (MDM) выполняется отдельным проектом/ подпроектом];
- Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных из учетных систем в таблицы фактов (fact table, factless table) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
-
Тестирование:
- контроль сходимости итогов по данным в учетной системе с итогами по данным таблиц хранилища;
- скорости исполнения полного ETL-цикла";
- Доработка п.п. 18, 19, 20 по выявленным ошибкам, замечаниям по результатам работ п. 21;
- Разработка структур витрин данных (агрегатных денормализованных таблиц/представлений). Выполняется поэтапно по предметным областям бизнеса;
- Разработка ETL/ELT-процедур по обновлению витрин данных, расчету производных показателей (обогащение витрин данными);
-
Тестирование:
- контроль сходимости итогов по данным витрин с итогами по данным учетных систем и итогами по данным таблиц хранилища;
- скорости исполнения цикла обновления витрин данных";
- Разработка документации по хранилищу данных;
- Разработка документации по витринам данных;
- Выработка и согласование требований к аналитическим OLAP кубам (перечень измерений, метрик, доп. действий, разграничение прав доступа);
- Разработка структур аналитических OLAP кубов, процедур обновления данных в кубах. Выполняется поэтапно по предметным областям бизнеса;
- Тестирование аналитических кубов;
- Подготовка, развёртывание инфраструктуры для публикации отчётов (репортинг, ad-hoc отчеты, OLAP) на web-портале (например, MS Sharepoint 2010 EE 64x + MS Reporting Services, возможно Gognos 10.х);
- Разработка документации по аналитическим кубам, публикация документации на web-портале в системе знаний;
- Разработка регламентных/управленческих отчётов (по п.п. 5, 6);
- Публикация и систематизация регламентных/управленческих отчётов на корпоративном web-портале;
- Обучение бизнес-пользователей интерактивному пользованию OLAP-кубами; выявление/формирование проактивных пользователей (power users);
- Бизнес-пользователи (по возможности) самостоятельно формируют отчеты (по результатам п. 35); приемка и публикация отчетов осуществляется по согласованию с IT-аналитическим подразделением (возможно на первых порах).
Еще по теме:
-
Серии советов популяризатора технологий хранилищ данных Ральфа Кимбалла
-
Гайд по созданию Big Data-проектов в облаке: технологический стек, этапы и подводные камни
Продукт Эксперт-BI
Продукт Эксперт-BI, запросить доступ к демо-стенду on-line
построением и поддержкой DWH на базе российских систем и инструментов: Построение DWH c нуля, Поддержка, развитие и оптимизация существующего хранилища, Перенос DWH на новую платформу (перевнедрение)
Хранилище данных (DataWarehouse, DWH) – это специально организованная единая база данных предприятия, с помощью которой осуществляется сбор и хранение корпоративной информации различного рода. В хранилище происходит структурирование корпоративной информации с поддержкой хронологии и обеспечивается быстрый доступ к необходимым данным
Виды хранилищ:
Хранилище в банке российские решения, DWH на российских платформах, хранилище данных в российских BI cbcntvf[, хранилище данных 1с на отечественных платформах, хранилище баз данных отечественные решения, база данных хранилище данных российский аналог, информационные хранилища данных российские платформы