Как появляется архитектура BI-системы

I have proved by actual trial that a letter,
that takes an hour to write, takes only about 3 minutes to read!
Lewis Carroll

Основным назначением BI-систем является обеспечение возможности анализа больших объемов информации для решения бизнес-задач. Это определяет специфику архитектуры таких систем, которая направлена на эффективное получение, обработку и предоставление данных конечным пользователям. В укрупненном виде архитектуру можно представить следующим образом:

Успешность архитектуры проверяется на одном простом правиле: при штатной работе системы пользователи получают именно ту информацию, которая им нужна и именно тогда, когда она нужна. Когда такое правило не соблюдается, это, скорее всего, означает, что аналитик и архитектор допустили ошибку в момент проектирования системы.

Как показывает практика, архитектура, хотя бы в общих чертах, возникает уже на этапе предпродажной подготовки, после того как становятся понятны функциональные требования к будущей системе. Основой для создания архитектуры служат данные, которые требуются для решения возложенных на BI-систему задач и источники (чаще всего — разного рода учетные системы и файловые данные). При исследовании источников следует обратить особое внимание на специфику хранения данных, регламент работы источника и наличие компетенций по системе у заказчика. Думаю, важность первых двух моментов исходя из назначения создаваемой системы, интуитивно понятна. Однако я хотел бы обратить особое внимание на компетенции заказчика по эксплуатируемым системам. Недокументированные системы, про которые заказчик мало что может рассказать, всегда служат источником проблем и рисков на проекте, поскольку разбирательства с логикой хранения данных в таких системах могут длиться неопределенное время, а в ходе эксплуатации уже созданной аналитической системы будут постоянно возникать проблемы с извлечением данных.

Вообще говоря, в данный момент в мире нет единого взгляда на архитектуру основного элемента информационно-аналитических систем — Хранилища Данных, в основном дискутируют сторонники двух разных подходов, названых по имени их авторов — Билла Инмона и Ральфа Кимбалла. Если попытаться кратко описать их подходы, то Инмон является сторонником создания систем с интегрированными детальными данными, а Кимбалл предлагает сосредотачивать усилия на быстром создании специализированных витрин данных без интеграции всех данных в детальном слое. На практике это означает, что при использовании подхода Инмона процесс создания будет более длительным, но в итоге система будет более универсальна и стабильна. В случае создания хранилища по методике Кимбалла мы получим более быстрое решение, которое будет не так эффективно и устойчиво к изменениям в источниках.

Я не буду обсуждать в этой статье достоинства и недостатки обоих подходов. В моей практике чаще всего встречается ситуация, когда Заказчик обращается к нам после того, как самостоятельно создав «зоопарк» витрин данных, упирается в проблемы с производительностью и неконсистентностью данных полученных из разных витрин. Соответственно, основная масса решений, с которыми я работаю, формировалась на основе подхода Инмона и имела примерно такой вид:

На схеме видно, что данные попадают в хранилище через специальный слой — Operational Data Stage. Его назначение — минимизировать нагрузку на источники, поэтому данные на этом уровне представляют собой копии структур на момент извлечения из источников. Довольно редко, когда источник не успевает выдать срез данных в отведенное окно или же существенно перегружен собственными задачами (такое бывает с OLTP-системами в крупных телекомах) приходиться применять механизм отслеживания измененных данных, коротко — CDC. В одном из проектов нам даже пришлось разрабатывать собственный механизм для работы с одной из почтенных версий Oracle, которую не поддерживают существующие промышленные инструменты.

Полученные в ODS данные преобразуются к унифицированному виду на детальном уровне. При необходимости, на этапе преобразования данных происходит их «очистка» — например удаление дублирующихся записей. Основное назначение детального уровня — хранение интегрированных базовых данных из всех источников для последующего формирования витрин и агрегированных данных в нормализованном виде. По сути можно разделить все данные на два основных типа — факты (транзакционные данные) и справочники (такие как перечень клиентов, тарифов продуктов). Исходя из потребностей заказчика и возможностей системы, для фактов определяется горизонт хранения, чаще всего это год или два. Справочные данные, как правило, хранятся за всю имеющуюся историю.

Для того, что бы обеспечить высокую скорость доступа пользователей к необходимой им информации мы всегда применяем два дополнительных уровня — это уровень агрегированных данных, в котором хранятся предрассчитанные показатели в требуемых размерностях и специализированные витрины данных, такие как клиентская витрина, содержащая в себе клиентов с ключевыми атрибутами (географическое расположение, сегмент, уровень дохода). Следует отметить, что сейчас набирает популярность очень перспективная технология хранения и обработки необходимых пользователю данных, так называемая «in memory», которая, видимо, со временем поможет отказаться от предрассчитанных показателей, но пока это только первые шаги.

BI-инструменты, посредством которых пользователи работают с данными, в общую архитектуру включаются готовыми блоками, в зависимости от самого инструмента и особого творчества там не требуется. Единственный момент, который может осложнить жизнь — это интеграция с системами Identity management. К счастью промышленные BI-средства поддерживают интеграцию с наиболее популярными системами управления идентификацией пользователя.
Что касается выбора инструментов, на которых будет реализована вся система, то этот момент, всегда зависит только от двух обстоятельств: предпочтения заказчика по вендорам и вендорная политика исполнителя. Что я хочу этим сказать: если вы пришли к заказчику, у которого, к примеру, придворным поставщиком является IBM — то никакие технические параметры не заставят его купить СУБД Oracle. С другой стороны, если заказчик не имеет явно выраженных предпочтений, то исполнитель будет предлагать ему инструменты вендора, который предложит исполнителю наиболее выгодные условия сотрудничества, проще говоря — большую маржу на лицензиях. Вот пример архитектуры, продиктованной предпочтениями заказчика, которая была подана на презентации видения будущего проекта:

Учитывая, что в каждом классе инструментов, применяемых для создания информационно-аналитических систем, существует несколько фактических равных по своим возможностям предложений от ведущих вендоров, то обоснование выбора того или иного инструмента почти никогда не основывается на его преимуществах или недостатках.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU