Хранилище данных без Е
Сегодня в любой компании, относящийся к большому и среднему бизнесу, наличие хранилища данных является де-факто корпоративным стандартом. Неважно, в какой индустрии работает компания, без анализа имеющихся данных о клиентах, поставщиках, финансах, невозможно удерживать конкурентное преимущество. С развитием автоматизации и оптимизации на каждом уровне производства товара или услуги, в организации используется все больше и больше ИТ систем, создающих данные — производственные, бухгалтерские, системы планирования, управления персоналом, и другие.
Как же выстроить процесс создания хранилища данных наиболее эффективно с точки зрения глобальной оптимизации ресурсов предприятия, новых и текущих потребностей бизнеса, и почему ведение метаданных — это важно.
Задачи по использованию накопленных данных наиболее часто используются для следующих классов задач:
- регуляторная отчетность
- финансовый учет
- планирование и контроль
- бюджетирование
- анализ клиентской базы
- риск-менеджмент
Часто для самых насущных целей достаточно использования одного источника — например, если мы говорим о предоставлении регулятору некоторой детализации из определенной системы, или выслать клиенту всю историю его заказов, используя CRM. Даже при смене информационных систем обычно нет сложностей при получении отчетности.
Способы и виды хранилищ данных
Однако, когда размер организации становится достаточно большим, или же требуется повысить конкурентное преимущество, то уже недостаточно только создать продукт и вывести его на рынок. Современные тенденции — во всестороннем изучении потребителя для повышения его лояльности. Необходимо анализировать бизнес с разных углов и научиться более точно оценивать затраты. Типовые задачи из разряда must have следующие:
- как аллоцировать расходы по бизнес-добывающим подразделениям
- Как прогнозировать спрос в зависимости от внутренних или внешних факторов
- Как управлять риском в финансовых и страховых организациях
- Как повысить средний чек клиента (таргетинг)
В каждом из вышеприведенных примеров требуется использование более одного источника данных. Кроме того, важно, чтобы методы сопоставления данных между источниками были едины. Иначе неизбежно возникнет ситуация, когда в организации, скажем, директор по стратегии и директор по продажам будут приносить генеральному директору одну и ту же информацию, но с разными цифрами. А потом месяц выясняют, кто же был «правее», используя чуть ли не половину имеющегося в их распоряжении персонала.
Самым примитивным способом организации хранилища данных является так называемое «озеро данных» (или data lake), когда мы просто берем и сваливаем в кучу данные из разных источников. В этом случае мы имеем единую техническую платформу для работы с данными и изолируем сложные аналитические запросы от первичных задач информационных систем. Такое хранилище данных может быть вполне себе и нереляционным. Однако в этом случае можно забыть о сложном анализе, и оперировать лишь простыми запросами. Кроме того, люди, работающие с данными, должны быть хорошо осведомлены не только о бизнес-области, но и о моделях данных исходных систем.
Далее по уровню организации хранилища данных следует хранилище, по т.н. классификации Кимбелла (Kimpball). Измерения из разных систем унифицируются, и таким образом, получается что-то вроде сети с двумя типами таблиц — фактов и измерений. Это первичное обогащение справочников, когда мы, используя какой-то общий натуральный ключ в одних и тех же таблицах разных источников, например, ИНН в справочнике организаций, получаем единый справочник.
Следующим по сложности и надежности является хранилище данных с единой моделью данных, отражающей наиболее важные объекты, описывающие деятельность организации. Надежность заключается в том, что данные, будучи представлены в форме, близкой к третьей нормальной, при правильно составленной модели, являются универсальным средством описания жизнедеятельности всего бизнеса, и таким образом, модель данных может быть легко приспособлена не только для аналитической и регуляторной отчетности, но и для работы некоторых систем предприятия.
Е — Единое
Говоря о тезисе данной статьи, я перечислю основные проблемы, с которыми сталкиваются лица, ответственные за построение хранилищ данных:
"Конь в вакууме". Хранилище построено, но им никто не пользуется.
"Черный ящик". Хранилище построено, но что в нем есть и как оно работает непонятно. Из-за этого возникают постоянные ошибки, а если еще и уволилась часть команды разработчиков, то как результат, скатываемся в пункт a.
"Калькулятор". Хранилище построено, но оно удовлетворяет только примитивные запросы, бизнес меняется гораздо быстрее, чем реализация требований, новые запросы бизнеса в ней не учтены. К тому же некоторые данные могут быть устаревшими или обновляться достаточно редко.
"Хрустальная ваза". Для хранилища необходимо много ручного контроля, проверок и неавтоматизированных управляющих воздействий, если один из участников поддержки не на работе, есть большой риск получить невалидные данные или не получить их вообще.
Разберем все четыре случая более подробно
«Конь в вакууме». Если вы получили этот результат, то это произошло по одной из двух причин:
- Менее вероятно. Вами не были собраны требования от бизнес-подразделений (или, что — то же самое, они были плохо проработаны). Такая, казалось бы, абсурдная ситуация возникает, если идея создания хранилища идет не от бизнеса, а от ИТ подразделения, у которого просто есть «лишний» бюджет, а хранилище — задумывалось потому, что оно есть у всех. Заказчиков вроде как потом найдем (еще лучше вариант «сами прибегут с протянутыми руками») — если все туда уложим. Лица, ответственные за выделение бюджета, считают это чем-то необходимым, в книжках читали, слыхали, ну вроде это как модернизация, и согласно кивают.
- Более вероятно. Определены заказчики хранилища данных, допустим, это департамент по продажам, и тут приходит светлая идея: «а давайте сделаем еще небольшое усилие дельта, загоним в него финансы, кадры и еще чуть-чуть и хранилищем будет пользоваться все предприятие». Хранилище построено, но им пользуется только департамент продаж, хотя там все красиво, и молочные береги — бери не хочу, но нет, времени на кисельные берега у коллег нет, им нужно скорее в шахту, с утра до ночи долбить кусочек данных. Ведь это кусочек, добытый потом и кровью (читай: потраченным рабочим временем).
В обоих случаях отсутствует элемент взятия ответственности на топ-менеджера и спускании ее вниз по иерархии. Это как с корпоративной культурой. Если у ген. директора предприятия 2 зама, то заставить пользоваться хранилищем на уровне предприятия может только сам ген. дир, или же хранилище строится для части предприятия — той, которую курирует руководитель наивысшей должности, осознающий необходимость внедрения ЕХД.
Для исключения таких ситуаций необходимо следующее:
- Определить формально спонсора проекта хранилища данных — кто будет отвечать за результат и финансово, и духовно
- Утвердить скоуп проекта, возможно, этапность, обозначить приблизительные сроки
- Согласовать со всеми подразделениями — желательно, с построением бизнес-процессов as is и to be
Только после этого можно приступать к реализации проекта — сбору требований, проектирования архитектуры и т.д.
"Черный ящик". Итак, вы утверждаете, что построили хранилище, что все требования учтены, однако, никто не понимает, как им пользоваться, к тому же если ушел один из ключевых разработчиков, понять, что и как было сделано, становится практически нереально.
В этом случае, очевидно, не был поставлен процесс документирования разработки. Принцип «сначала документирование», потом разработка должен быть возведен если не в Абсолют, то в достаточно жесткий контроль. И не только со стороны команды, ответственной за разработку хранилища данных. В идеале необходимо, чтобы к процессу непрерывной и актуальной документации были подключены дополнительно разработчики отчетности (аналитической, регуляторной), владельцы внутренних информационных систем компании, и, конечно, сами потребители.
Кроме того, процесс документации должен удовлетворять следующим принципам:
- Актуальность — текущее состояние программного кода полностью определено составом документации
- Версионность — возможность анализировать документацию прошлых релизов и планировать модификации на будущие релизы
- Разделяемость — над документом могут работать одновременно несколько человек
- Применимость. Тут говорится о том, что для каждого вида документации хранилища важно подобрать такую структуру, которая будет лучше всего восприниматься целевыми пользователями: так, структуру таблиц лучше описывать в табличной форме, бизнес-процессы в виде нотаций, взаимодействие между информационными системами в виде диаграммы, бизнес-словарь в виде вики-системы, и т.д.
Сейчас появляются программные продукты, которые серьезно позволяют упростить жизнь, т.е. связать проектирование и разработку, но пока цельного решения для хранилищ данных еще нет, это:
- ER-диаграммы
- BPMN-продукты
- ETL-решения
Без актуальной документации сложность разработки новых требований будет увеличиваться, а при грамотной — сокращаться.
"Калькулятор". Если считать, что мы не получили «коня в вакууме», тогда эта ситуация о том, когда требования вроде бы выполнены, но выполнены они формально. Вы хотели посчитать остатки по дням — пожалуйста. Хотите получить их в разрезе по регионам контрагентов — такого в требованиях не было, вам нужно сделать выгрузку в excel, далее берете из системы X выгрузку по контрагентам с выбором поля Y, и затем ВПР-ите.
Сложившаяся ситуация свидетельствует об отсутствии опыта у команды, без архитектурного взгляда на последующее развитие хранилища, без, даже примитивной, модели данных. Обычно такие хранилища становятся временными, или о них быстро забывают. По-хорошему, хранилище должно обладать силой снежного кома, катящегося с горы. Сначала, когда ком еще небольшой, а впереди рыхлый снег, вам самим с трудом нужно будет его собирать и толкать. В какой-то момент времени слава о вашем продукте будет распространяться, и пользователи будут смотреть в хранилище все чаще.
Итак, чтобы хранилище не оказалось калькулятором, необходимо обеспечить:
- квалифицированные кадры — архитекторы, аналитики, разработчики EtL и SQL
- Устав проекта, в котором будут обозначены цели хранилища не только на ближайший бюджетный период, но и на последующие годы
- Количественные и качественные критерии хранилища данных. Если не хватает своих кадров, рекомендуется привлечь консультантов
- Четко представлять себе, что поможет оптимизировать хранилище данных в дальнейшем — расходы на персонал, ПО, увеличить скорость разработки отчетов и т.д.
"Хрустальная ваза". Хранилище построено, оно вроде бы справляется со своими задачами, но для его поддержки нужна масса усилий: ведение каких-то ручных справочников, постоянная перезагрузка некоторых источников, сбои в загрузке, дублирующиеся данные, и т.д.
Такая ситуация может происходить по следующим причинам:
- О ней уже было сказано выше — недостаток квалифицированных кадров;
- Безархитекутрная концепция — когда разные части хранилища делаются разными людьми или командами без общей утвержденной концепциии, в результате имеем множественные способы извлечения, трансформации и загрузки данных;
- Очень частая ситуация — «аутсорсим разработку», поддержка своя, при этом приемка работ сделана плохо
- На каком-то этапе развития хранилища «бюджет кончился». И далее хранилище дорабатывает (поддерживает) не та команда, которая создавала, а те, кому нужны данные
Для предотвращения данных ситуаций, рекомендуются следующие действия:
- Сказанное в пунктах выше — квалифицированные кадры, устав проекта, долгосрочный план и бюджет, заинтересованное лицо из топ-менеджера.
- Не аутсорс руководит процессом, а внутренний сотрудник (главный аналитик или архитектор) руководит аутсорсом.
- Любые сбойные ситуации должны выноситься на собрания на рассмотрения архитектору хранилища. Если архитекторов несколько, то на архитектурный комитет.
- Желательно ввести метрику качества хранилища данных, можно использовать эту метрику для привязки к KPI команды.
Как видно, во всех перечисленных случаях, несмотря на то, что создание хранилища данных — это проектная деятельность, сами процессы по созданию должны быть регламентированы для создания качественного результата.
Переход от хранилища данных к единому
Как уже было сказано выше, успех проекта по созданию хранилища данных, определяется достаточно многими входными данными (бюджет, спонсор, команда, цели, заказчики). Однако мы практически не касались бизнес-процессов, которые направлены на развитие и поддержание самого ХД. Ниже я попробую сформулировать основные бизнес-процессы, которые и призваны сделать процессы работы с данными на предприятии действительно едиными:
- Процессы поддержания технической и пользовательской документации в актуальном состоянии
- Процессы ведения в актуальном состоянии бизнес-словаря (глоссария) данных
- Процессы контроля качества данных
- Процессы сбора и управления требованиями к ХД и системе отчетности
- Процессы управления инфраструктурой хранения и обработки данных
- Процессы оптимизации хранения и сбора данных
В современной парадигме данная совокупность бизнес-процессов составляет основу концепции Data Governance.
Очень часто при попытке внедрить эти процессы силами команды по созданию ХД и отчетности будет предпринято активное сопротивление, или же игнорирование процессов. Оно и понятно, ведь в локальном смысле это удлинение разработки.
Поэтому полезным будет предпринять следующие действия:
- Введение горизонтальной структуры ответственности (каждый участник может отвечать за небольшую область)
- Изображение в графическом виде всех возможных workflow для всех сотрудников (формализация процесса)
- Внедрение в систему KPI процент и качество выполнения ответственности
Несмотря на то, что в локальном смысле процесс перехода кажется значительно «обюрократизированным» и тяжеловесным, в глобальном смысле это дает существенные плюсы и экономию времени. Так как основные потери времени — при изобретении с нуля уже существующих решений ввиду невозможности или отсутствия желания разобраться в существующем механизме.
Немного о целевом архитектурном решении
Несмотря на то, что архитектура ЕХД тянет на отдельную большую статью, или даже книгу, обозначу также основные технические требования к зрелому хранилищу данных:
- Парадигма data lake не заменяет корпоративных хранилищ данных, а сосуществует с ним вместе
- ЕХД должно иметь различные интерфейсы предоставления данных: средства bi, возможность выполнения ad-hoc sql запросов, стандартное предоставление данных в форматах json, xml и т.д.
- Должна быть реализована ролевая модель доступа к данным
- Скорость отклика при обращении к данным: 90% типовых запросов — менее 1 секунды, 99% запросов — менее 10 секунд. Должен быть достаточно хороший запас по ресурсам
- Наличие единого и связного центрального слоя ХД (предпочтительно — Inmon методология)
Как итог, хранилище данных нарекается единым не по наличию источников, а по наличию потребителей данных. А это гораздо сложнее, чем написать универсальный ETL и подогнать петабайты памяти.
