Хранилища Данных: вчера и завтра

Казалось бы, только вчера я делал доклад на тему «Хранилища данных в банках» (на одной очень уважаемой ИТ-тусовке), после которого несколько ИТ-директоров окружили меня и начали задавать вопросы «Почем шкафы (с серверами, разумеется) продаете?».

На самом деле эта история произошла в начала 2000-х: с тех пор «шкафы» принято называть системами хранения данных (СХД), а представление о том, что такое «хранилище данных» (ХД) у большинства ИТ-специалистов практически совпадает с его определением в Википедии. «Очень большая предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации».

Если «копнуть» еще глубже в историю, то сама концепция хранилища данных (с окончанием «… о бизнесе») появился с подачи компании IBM в конце 80-х. В то время это была модель архитектуры для организации потока данных из оперативных (учетных) систем к лицам, принимающим решения. С тех пор хранилище данных как система получило массу имен: система поддержки принятия решений, система бизнес-анализа, корпоративная информационно-аналитическая система. Концептуальная архитектура же подобной системы остается неизменной по сей день, включая в себя так называемые слои.

Слой систем-источников данных: ними служат любого рода учетные системы, использующиеся в организации – ERP, CRM, MRP, автоматизированные банковские системы, биллинговые системы (в телекоммуникационных компаниях), разрозненные эксель-файлы в конце концов.

Слой доступа к данным: фактически, интерфейс хранилища данных к системам-источникам, отвечающий за извлечение, преобразование и загрузку данных в хранилище.

Слой хранения данных и метаданных: собственно, сердце хранилища – та самая «очень большая … база данных».
Слой доступа к информации: интерфейс  конечных пользователей системы (потребителей информации, полученной из данных) для работы с хранилищем данных.

Казалось бы, если все так просто и прозрачно – в какой из учетных систем нет модуля отчетности? – зачем было придумывать что-то новое? Ответ достаточно тривиален.

Начнем с того, что учетных систем в любой организации всегда несколько, и в каждой из них одни и те же данные учитываются по-разному: «М» и «Ж» для определения пола клиента в одной, и «0» и «1» для той же цели – в другой (кстати, в жизни, полов значительно больше – минимум три, есть еще «не определен»). Поэтому для ответа на простейший вопрос «каково соотношение мужчин и женщин в части приносимых организации доходов», например, уже требует как минимум одной «лишней» операции – приведения значений такого измерения анализа как «пол» к единому знаменателю. (А вопрос этот, между прочим, вполне распространен вопрос в банках, операторах связи – любом клиенто-ориентированном бизнесе.)

Ладно, возьмем все учетные системы от одного поставщика (фантастика, конечно, но допустим), которые настолько интегрированы друг с другом, что подобные казусы и разночтения исключены, и вопрос решен? Не так все просто: заранее редко можно «просчитать» какого рода информация потребуется тому или иному лицу, принимающему решения, а плодить отчеты сотнями на все случаи жизни – такого ни одному ИТ-директору не пожелаешь.

Хорошо, возьмем удобное средство бизнес-анализа (термин появился также в конце 80-х) и «прикрутим» его прямо к базам данных учетных систем: теперь каждый пользователь может «перетаскивая» показатели и измерения на панель формирования запроса для построения отчета (никакого знания SQL – ура!) сам себя обеспечить информацией. Вопрос закрыт? Нет, оказывается наиболее «одаренные» аналитики своими запросами запросто кладут на лопатки рано или поздно любую учетную систему. Вместо того, чтобы учитывать (для чего, собственно, такие системы и предназначены), она начинает часами пыхтеть, чтобы вернуть пользователю выборку типа «все операции всех клиентов по дням за последние три года» (опять же, вполне типовой запрос в любом банке).

Все, удваиваем аппаратные мощности, строим кластер, делаем реплику баз данных учетных систем, внедряем сложные инструменты балансировки нагрузки, устраиваем систему интеллектуального резервирования и/или кэширования данных (нужное подчеркнуть) и забываем про проблемы производительности.

Все счастливы?

Не тут то было. Оказывается злобным аналитикам нужна историчность – а сколько нам был должен клиент позавчера, а в каком регионе он находился месяц назад, а к какому сегменту относился в прошлом году? В учетных системах историчности нет априори. Но даже если решить и эту проблему (можно хранить ежедневные «срезы» данных – с ними практически невозможно работать, ну да ладно, да и проблему с корректировками задним числом это не снимает), остаются проблемы одинаковой трактовки информации (банально «клиент» - это кто: тот с кем у нас сейчас есть действующий договор или тот, с кем у нас были хоть какие то договорные отношения на протяжении последнего года?), проверки, очистки и стандартизации данных (адресной, например), восполнение недостающих данных (определение связанных лиц, например) – и этот перечень далеко не полный.

Хранилища данных избавлены от таких проблем, так как организация данных в них (кстати, физически перемещенных из учетных систем) базируется на нескольких принципах:

Дополним этот перечень еще и рядом требований к информации, которым удовлетворяет хранилище данных – правильность (за счет проверки и очистки данных), своевременность (за счет предрассчитанных показателей), доступность, релевантность, краткость и защищенность (за счет применения инструментов бизнес-анализа). И становится очевидным, что подобные системы появились для эффективной поддержки следующей важной цепочки: данные ->  информация -> знания -> решения.

Хотя, конечно, хранилища данных сами решений не принимают, как бы этого многим не хотелось.