Сайзинг многоуровневого КХД (ч.1 Что сайзим)
Приветствую, ищущий методики и подхода, Гость!
Мой многолетний опыт работы в части проектирования и реализации КХД с использованием продуктов иностранных Вендоров, всегда был сопряжен с использованием их обширной инфраструктуры и наработок обеспечивающих и помогающих выполнять вспомогательные задачи быстро и условно качественно. Одной из таких задач всегда являлось выполнение сайзинга разрабатываемого КХД. Вы можете задаться вопросом:»Почему «условно качественно»? — ответ тут прозаичен и банален: «Инструменты сайзинга не могут однозначно ответить на вопрос, какие характеристики заложить и как посчитать сайзинг КХД до того, как полностью сформировано ТЗ и не расставлены все точки над Ё… будущего хранилища, ну и конечно, никакой инструмент не в силах справиться с изменениями требований по ходу проекта, криворукостью разработчиков и применением не оптимальных решений. Как оказалось, после ухода поставщиков программного обеспечения с рынка и массового перехода на OpenSource решения, вместе с софтом «ушли» и прикладные решения для выполнения сайзинга КХД.
Методика, которая рассматривается ниже, основывается на следующих постулатах:
КХД представляет собой многоуровневую структуру с перетоками данных между слоями
Слой сырых исходных данных;
Слой качественных и гармонизированных данных;
Слой унифицированных данных;
Слой бизнес-трасформированных данных;
Слой отчетных витрин.
Логика движения данных внутри КХД.
На слой исходных данных загружаются и должны храниться исходные данные, поступающие в КХД неизменном виде, как их отдают системы — поставщики данных. Делается это для решения задачи обратного анализа суммовых показателей до первичных значений из которых они сформировались (задача крайне ресурсоемкая и, по своей сути, бесполезная).
Данные со слоя исходных данных должны проходить процесс очистки от мусора, приведения к единой НСИ и гармонизации в части признаков и показателей. На выходе остаются те же исходные данные, что на слое исходных данных, но уже в единообразном виде, т.е. все данные между собой на этом уровне сопоставимы. Отдельно выделю, что иногда эти два понятия «качественные» и «гармонизированные» данные разделяют на отдельные слои, но суть от этого не меняется: данные должны стать между собой сопоставимыми для их совместного анализа.
Слой унификации данных решает задачи преобразования гармонизированных и качественных данных к внутренним целевым сущностям, например трансформация Типового плана счетов к Корпоративному плану счетов; трансформирование РСБУ в МСФО, как пример, путем применения правил меппинга. Т.е. на слое унифицированных данных вырисовываются информационные сущности заточенные для решения конечных задач хранилища данных. Важно понимать, что один и тот же объект КХД в дальнейшем может быть многократно переиспользован для решения частных задач (все, как в ООП).
Слой Бизнес-трансформации данных призван решить задачу применения »сложных» Бизнес-алгоритмов, которые не могут быть представлены в виде набора правил меппинга и требует, например, использование сложных скриптов для реализации расчетных моделей или алгоритмов для формирования отчетности или промежуточных результатов и их использования в других расчетных моделях.
Слой Отчетных витрин — набор конечных объектов с материализованными для целей отчетности наборами данных. Слой является высокоагрегированным представлением обработанной и рассчитанной на предыдущих шагах информации. У опытного КХД-шника может возникнуть логичное замечание: зачем делать материализацию, если можно формировать отчеты на лету, считая необходимые данные в памяти сервера. Отвечу простым примером: если тайминг формирования отчетов вам не критичен и сервер располагает большим объемом ОЗУ, например 2Tb, то да, все можно считать в памяти, НО! Если вы строите критичные для Бизнеса дашборды и отчеты, время формирования которых должно составлять секунды, то ничто не работает быстрей, чем выборка из колоночной таблицы заранее рассчитанных значений.
Продолжение: «ч.2 Как сайзим» тут
