Как появляется архитектура 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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



19 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Неужели B2(Oracle) это широко известная в узких украинско-банковских кругах АБС Б2 (CS LTD Харьков)? Интересно почему заказчик выбрал ваше решение, а не воспользовался предлагаемым все тем же CS продукт CS::BI, в чем преимущестов вашего раешения для заказчика... Я сам работая на подобном проекте заметил что проект хранилища в основном «пушится» подразделением ИТ и в итоге потенциальные пользователи(риски, финдеп) все также продолжают использовать свои «местные» наработки... В этом и вижу главную проблему BI проектов у нас — заказчик не всегда получает то что действительно хочет потому что не участвует в проекте на равне с ИТ, а получает с точки зрения ИТ «конфету», которую со своей точки зрения даже надкусить не может.

Да, это Б2, как-никак больше 40% рынка АБС в Украине.
Мне в прошлом году на одном проекте довелось разбираться с CS::BI. Выскажу свое мнение по данному продукту, который имеет свои достоинства и недостатки. По сути представляет набор преднастроенных витрин для АБС Б2, читай — подход Кимбала. Предлагаемое CS решение по подключению данных из IS Card представляло собой простую заливку данных в теже структуры, что и Б2, при этом интеграция данных не производилась, что бы было всем понятно — если есть Ваня Иванов в Б2 и Иванов Иван в IS Card, то на витрине это будут два разных человека. Историзация решена на примитивном уровне — регулярные срезы данных, соотвественно анализ в исторической ретроспективе потребует обработки чувствительных объемов данных, что потянет за собой потребности в железе. Состав витрин, по понятным причинам, ограничен по составу показателей, которые рассчитываются по тем алгоритмам, которые CS посчитал правильными. Это влечет за собой необходимость существенной кастомизации продукта под потребности каждого отдельного банка, что, учитывая существенную загруженность ресурсов CS, процесс весьма небыстрый. Но продукт довольно дешев и в базовой версии внедряется довольно быстро.
У Вас, Алексей, на предыдущем месте работы, кстати, была эпопея с внедрением и кастомизацией обсуждаемого продукта, Вы, наверное, могли бы рассказать о своих впечатлениях?

Что касается идеологов проекта у заказчика — я писал об этом в предыдущей статье. Нет заинтересованных лиц от бизнеса — нет успешного хранилища.

Да, пришлось столкнуться с этим продуктом на самой ранней стадии его развития. Мое мнение основывается на том что было в самом начале, как сейчас — не знаю...
1. Много было чисто технических ошибок — какие то данные были рассчитаны не верно, многих вообще не было.
2. Продукт был пригоден для небольшого банка который использует только АБС Б2 — но зачем небольшому банку огромный массив исторических данных по сути в том же формате что и в транзакционной системе. В таком банке аналитические запросы не очень мешали работе системы.
3. По поводу кастомизации — заказчик осознанно пошел на схему «change request — пол года реализации — результат(не всегда ожидаемый)». Ни о каком итерационном подходе речь не шла.

Мое мнение таково — специалисты банка(может с помощью внешних консультантов) не должны отталкиваться от имеющихся транзакционных систем и подстравиаиться под их структуры данных, а должны больше общаться с потенциальными пользователями системы. АБС Б2 необходимо рассматривать только как один из источников наполнения хранилища, структура которго спроектирована для решения бизнес задач а не оптимизирована под структруы систем источников. Но в таком случае сам продукт CS::BI не нужен, достаточно механизма выгрузки staging данных задачами по завершения дня... Разве что как покупка самого продукта OBI EE плюс возможность сотрудничать с Сиес в планы выгрузки данных из АБС Б2.
Хранилище это уникальный продукт для каждого банка и не может быть кастомизирован «под всех и каждого».

На диаграмме с примером архитектуры-предпочтения видны два источника данных (B2 и вторая система), процессы интеграции и очистки данных, формирование пользовательских отчетов. Любопытно как чаще всего подбирается состав команды, и реализауются подобные BI проекты в Украине.

Какие роли предусматриваются со стороны заказчика, какие со стороны исполнителя. Есть ли отдельные роли Business Analyst, Functional Analyst, Data Analyst, разработчики БД (Oracle, DB2, MS SQL), разработчики прикладных систем (Cognos, SharePoint), QA. Как распределяется работа в командах. Применяется waterfall или Agile. Исполнитель большей частью работает у себя в офисе или работа onsite у заказчика.

Артем, у Вас вопросов на три статьи вперед :)

Еще забыл: Data Architect, Solutions Architect, Product Manager, Project Manager, QA, QA Manager, Development Manager, Engineering Director, Development Team Lead, DBA Team Lead, Scrum Master — вот это будет настоящий энтерпрайз, а пилить проект должны три программиста в офшоре.

Повеселил на картинке datawarehousing на mysql-e который извлекает данные из оракла

«Художник так видит» ©

На учетной системе не было ресурсов строить сложные запросы, поэтому ИТ-шники для аналитиков сделали выгрузки, почему выбрали MySQL — я, честно говоря, не спрашивал. Может на оракл денег не было на тот момент. На картинке кстати не показаны все потоки данных, на самом деле в B2 регулярно заливаются данные еще из нескольких систем, таких как iscard, управление контрагентами и т.д. которые в свою очередь крутятся на MS SQL.

нечасто могу такое сказать, но... познавательно :)

хотел уточнить — получается, что архитектура появляется в результате разгребания проблем в существующей системе, так?

были ли существующие системы, которые не получилось побороть эволюционно и пришлось делать всё заново? если да, то что там такого было?

Это вообще харатктерно для отечественного BI. Пока заказчик не набьет шишек в самостоятельном создании разного рода прикладных поделок, у него не возникает понимания, зачем платить немалые деньги консультантам, специализируюмщимся на обсуждаемой тематике. Соотвественно, и бекграунд проекта, как правило, представляет собой конгломерат учетных систем и существующих наработок по аналитической тематике.

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

Спасибо за статью (особенно радует, что на ДОУ все же пишут не только про зарплату и как все плохо в Украине ;)

Если не сложно пару вопросов:
1. С какими вариантами презентейшен лейера кроме шарепойнта вы сталкивались?

2. Проблема предметных прав пользователей и доступа к данным. Идет интеграция на уровне баз данных систем. Соответственно в некоторых случаях подсистема прав конкретной системы идет побоку. Кто отвечает за права доступа в этом случае?

Наш флагман — саповский BusinessObjects, как то так уж сложилось, что основную массу проектов делаем именно с этим продуктом, из прямых аналогов можно упомянуть Cognos BI, слегка экзотичный для наших краев Oracle BI. Не совсем прямые — QlickView, а также, в качестве конкурентов, Microstrategy. Можно, ради справедливости отметить, что базовым и наиболее распространенным BI-инструментом в нашей стране является Excel. С ним такое порой умудряются люди делать, я иногда поражаюсь.

По поводу прав доступа к данным: в теории можно городить близкую к идеалу с точки зрения безопасности, но очень громоздкую организационно-техническую схему с распределением прав на уровне БД, но на моей практике заказчик всегда удовлетворяется решением на верхнем уровне — указанные выше инструменты обладают достаточными возможностями для распределения прав вплоть до объектов данных. Это, видимо, обусловлено решаемыми аналитической системой задачами, в которых самое слабое звено — это не техника и софт, а люди, работающие с информацией и делающие выводы.

Где-то встречал: Если что-то не может быть автоматизировано с помощью Excel, значит это не может быть автоматизировано никогда :)

По поводу стоимости такого решения не спрашиваю, ибо наверное коммерческая тайна :) но если не секрет примерная оценка трудозатрат (услуг) в таком проекте ?

З.Ы. Не в обиду — был у вас на сайте — первый раз увидел сайт на русском в домене ко.юкей :)

Компания гордится своими английскими корнями. Нужно сказать, первое место работы, где я ощущаю, что это не просто пиар.

Ексель это наще все :))) Но, нужно из коротких штанишек всеже расти))

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

Мы вот недавно педалили проект- би портал — для одного большого западного банка, с ui на extjs и систему прав большую и гибкую сами сделали и хранили в бд в специальных табличках.

Очень интересно, не могли бы Вы подробнее рассказать о проекте, под какие задачи портал, какие возможности реализовали?

Ничего особенного:
Данные собирались из разных баз(оракл, sql server, db2 на мэйнфреймах) в staging бд на оракле, потом оттуда в основной dwh на оракле, в процессе запускаются джобы которые считают всякие полезные агрегации, заполняют всякие вспомогательные табличнки и факт и dimension талбицы из которых потом строятся OLAP кубы, потом против всего этого работает два типа интерфейсов:
— простые репорты, в основе которых лежит sql, a результаты показываются в ext js фронтенде в виде таблицы с паджинацией, и всякими рюшками типа экспорта в эксель и принтингом

— репорты/чарты с drill down, в основном работают против OLAP кубов в виде mdx(но некоторые как sql тоже были), которые позволяют дриллдаунится по типам транзакций, географии, продуктам разным и т.д. Тоже фронтенд на gwt ext js.

Підписатись на коментарі