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

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

В части технической реализации оказывается, что для транзакционной системы важнейшей задачей является обеспечение надежного механизма добавления записей большим количеством конкурентных пользователей, в то время как для аналитической системы – возможность быстрой выборки больших объемов данных и их агрегации. Системы класса BI (Business Intelligence) обеспечивают интерфейс для пользователя аналитической отчетности. Они предоставляют инструменты для эффективной интерактивной работы с большими объемами данных, включают в себя средства для работы с OLAP-кубами.

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

Важно, чтобы пользователи доверяли данным из BI-системы, а при достижении этой цели мы неминуемо встретим задачи, связанные с обеспечения качества данных. Это пропущенные или неправильно заполненные аналитики, противоречивые данные, нарушения ссылочной целостности, несогласованные между системами справочники и многие другие «прелести». Часть выявленных проблем может решаться просто, с другими придется сложнее, главное – осознавать, что задачи обеспечения качества данных нужно будет решать, заранее готовиться к этому, планировать и осуществлять мониторинг в ходе внедрения и использования системы BI. Так, мы можем годами заносить информацию по клиентам в транзакционную систему, но, только приступив к внедрению BI, обнаружить, что попытки провести анализ по возрасту показывают, что у части клиентов дата рождения не заполнена, многие родились 1 января 1900 года, а
у некоторых дата рождения совпадает с датой первого обращения в нашу компанию. 

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

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

Первый такой вопрос связан с доступом к данным из систем-источников. Хорошо, если мы работаем с документированной системой, хранящей данные в современной СУБД. Еще лучше, если при этом у нас в компании есть специалисты, поддерживающие и развивающие эту систему. В таком случае у нас есть хорошие шансы без лишних проблем получить данные из этой системы, преобразовать их по нужным алгоритмам и поместить в область постоянного хранения нашего хранилища данных. Однако бывают ситуации, когда в компании используются системы с недокументированной структурой базы данных, для хранения данных используются файлы собственных форматов или базы данных, для которых не реализованы стандартные интерфейсы доступа. Тогда получение данных может превратиться в нетривиальную задачу с непредсказуемыми сроками и трудозатратами.

Помочь справиться с этой задачей могут специализированные инструмента извлечения, преобразования и загрузки данных (Extract-Transform-Load, ETL). Правильный ETL-инструмент должен обеспечивать доступ практически к любому источнику данных, работу на уровне логики приложений при подключении к типовым бизнес-приложениям, высокую производительность при преобразованиях данных и масштабируемость. Хорошие ETL-инструменты не требуют написания кода, позволяя визуально проектировать потоки данных, что повышает скорость разработки, а главное – кардинально упрощает поддержку и модификацию решения.

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

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

При подготовке к внедрению хранилища данных всегда решается вопрос о модели данных в хранилище. Есть решения, предполагающие необходимость хранения нормализованных данных и построения денормализованных витрин на их основе. Есть подход Ральфа Кимбалла, предлагающий создавать хранилище данных в виде совокупности таблиц фактов, соединяемых через таблицы согласованных измерений. Решение о выборе подхода является очень важным и должно приниматься индивидуально для каждого случая. В качестве общей рекомендации можно посоветовать рассматривать подход Кимбалла, когда необходимо получить быстрое и эффективное решение конкретных бизнес задач по анализу и отчетности, и подход с хранением нормализованных данных, когда нужно построить хранилище как элемент IT-инфраструктуры компании. При выборе подхода с хранением нормализованных данных имеет смысл серьезно задуматься об использовании промышленной отраслевой модели данных. Разработанные на основе опыта большого количества проектов модели таких компаний как IBM, Teradata, кардинально снижают риски возникновения проблем, связанных с неправильным проектированием модели
данных хранилища.

В нашей стране технологии, связанные с построением хранилищ данных, уже неплохо освоены. При этом степень «продвинутости» используемых технологий и архитектуры сильно связана с отраслью. Например, в большинстве крупных и средних банков для задач подготовки управленческой или регуляторной отчетности используются решения на основе технологий хранилищ данных. Большинство таких банков уже прошло этап стихийного и бессистемного роста разрозненных баз данных, каждая из которых содержит данные для решения одной локальной задачи. Как правило, при реализации таких решений широко использовалось кодирование, написание скриптов, не применялись специализированные ETL-средства. Столкнувшись со сложностями изменения таких решений при появлении новых требований от бизнеса, банки активно начали поиск промышленных технологий и решений. Например, сейчас все больше проектов по хранилищам данных в банках реализуется при использовании промышленных ETL-инструментов, позволяющих отказаться от написания кода, таких как системы от компаний IBM, Informatica.

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

Компании из сферы розничной торговли, исторически привыкшие выжимать максимум эффективности из вложений, в своей массе имеют менее развитые решения в области аналитических систем и хранилищ данных. Рынок внимательно присматривался к пионерам, внедрившим специализированные СУБД для хранилищ, промышленные ETL-инструменты, использующим промышленные модели данных, современные BI-инструменты. Сейчас заметно, как успешный опыт серьезных внедрений у конкурентов помогает ретейлерам принимать решение о запуске новых проектов по хранилищам данных и BI. Как правило, ретейлеры ставят перед собой очень конкретные задачи, направленные на измеримое повышение эффективности. Видя, как IT-инструменты помогают больше заработать или сократить расходы, они принимают взвешенные решения по выбору инструментов и запуску новых проектов.

Основными трендами в развитии аналитических систем и хранилищ данных можно считать желание персонификации клиента, постоянное увеличение объемов используемых данных и все более жесткие требования к оперативности поступления информации. Для того чтобы компания не теряла выгодных клиентов и приобретала новых, необходимо очень хорошо представлять потребности каждого конкретного клиента, основываясь на всей доступной о нем информации. Многие компании уже сейчас помимо традиционных источников информации: собственных транзакционных систем и данных из исследований рынка – стремятся использовать данные социальных сетей, чтобы еще больше персонифицировать предложение для конкретного клиента.

Это требует нового качества как процесса сбора, так и процесса очистки данных, приводит к все большему увеличению объемов собираемых, преобразуемых и хранимых данных. С другой стороны постоянно повышаются требования к оперативности получения результатов анализа. Все больше задач требуют доступа к данным в режиме online. В результате развиваются как программные инструменты, так и подходы к построению архитектуры аналитических систем. Системы, решавшие ранее только задачи ETL, получают возможности обращаться к данным приложений «на лету», используют возможности web-сервисов,
становятся системами не просто загрузки, а полноценной интеграции данных. По мере роста скорости обработки данных, роста пропускной способности каналов связи, мы можем обеспечивать все более высокую производительность аналитических систем, все больше приближаясь к режиму on-line.

  Чтобы отвечать на растущие требования бизнеса по сложности преобразований и скорости обработки данных, при планировании запуска проекта по хранилищу данных имеет смысл ориентироваться на продукты глобальных поставщиков. Менять СУБД или ETL-средство после нескольких лет эксплуатации будет сложно и затратно, поэтому выбирать эти платформы нужно рассчитывая на увеличение объемов данных и сложности преобразований. При выборе BI-инструмента правильно в первую очередь ориентироваться на потребности бизнес-пользователей, так как именно они будут постоянно использовать это средство в работе. Выбор продуктов из линейки одного производителя позволяет получить весомую экономию затрат на программное обеспечение, однако принимать решение о платформе можно только понимая то, насколько выбираемые средства эффективны для решения конкретных задач проекта в реально существующем в компании окружении IT. И, конечно, нельзя забывать, что даже выбор самого современного программного обеспечения не снижает требования к квалификации команды, которая будет осуществлять внедрение и развитие аналитической системы и хранилища данных.