Если посмотреть меню любой программы, используемой в бизнесе, будь то АБС, биллинговая система или автоматизированная бухгалтерия, можно без труда найти пункт «отчёты». Зачастую даже люди, имеющие к IT непосредственное отношение, недоумевают: зачем нужно что-то большее? Вот же они — отчёты, бери и пользуйся! Зачем нужны какие-то там «хранилища»? Ответ в статье Владимира Комарова «Современные принципы построения хранилищ данных» (опубликована в журнале «CONNECT! Мир связи»).

_______

Если посмотреть меню любой программы, используемой в бизнесе, будь то АБС, биллинговая система или автоматизированная бухгалтерия, можно без труда найти пункт «отчёты». Зачастую даже люди, имеющие к IT непосредственное отношение, недоумевают: зачем нужно что-то большее? Вот же они — отчёты, бери и пользуйся! Зачем нужны какие-то там «хранилища»? Давайте разбираться.

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

1. Информации становится слишком много, и традиционный способ её хранения уже не обеспечивает нужной скорости доступа. В качестве примера информации, объём которой нарастает лавинообразно, можно привести бухгалтерские проводки или информацию о мобильном трафике.
2. Как правило, разные процессы в организации обслуживаются разными программными продуктами. Например, в банке, помимо АБС, может быть отдельная система для обработки пластиковых карт. Или CRM-система. И никакой отчёт, создаваемый в рамках АБС, не даст ответа на вопрос, как использование банковских карт коррелирует со своевременностью выплат по кредиту или с активностью клиентской службы в отношении конкретного заёмщика.
3. Многие системы по тем или иным причинам не могут хранить данные всей компании в целом, поэтому приходится делать несколько инсталляций. Отчёт, формируемый в одной из них, не даст полной картины по всей организации.
4. Со временем в компании вырабатываются некие критерии эффективности, которые не хранятся в системе явно, а требуют ресурсоёмкого расчёта, зачастую с использованием внешних источников информации. Решить все эти проблемы и призвано хранилище.

Схема хранилища данных в самом общем виде представлена на рисунке. Данные забираются из источников, т.е. оперативных систем организации, перерабатываются, загружаются в БД хранилища, и затем на основе переработанных данных строятся отчёты.

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

Первая проблема, которая встаёт перед разработчиками хранилища, — как выделить из базы данных источника только нужные записи. Ряд оперативных систем уже имеет какие-либо метки изменения данных. Например, автоматически обновляемые поля update_date и/или creation_date, или журналы операций. Если таких меток нет, приходится идти на всевозможные ухищрения — от ежедневного копирования слепка таблицы с хэш-ключами каждой записи до применения низкоуровневых по отношению к приложению средств — например, Oracle CDC, фиксирующего физические ключи изменённых записей. Особая головная боль — это записи, удаляемые из таблицы. Тут приходится изучать логику приложения. Например, если окажется, что запись может быть удалена в течение определённого периода, то изменения будут забираться с источника с задержкой, равной этому периоду.

Вторая проблема — это организация интерфейса между системой-источником и хранилищем. Мы в своей практике применяем три подхода:

1. Непосредственный доступ к БД источника; преимущества — гарантированный доступ к последним обновлениям; недостатки — дополнительные риски на источнике, невозможность доступа во внеурочное время.

2. Доступ к копии БД источника; преимущества — большое окно доступности источника; недостатки — расходы (оборудование и администрирование) на поддержку копии.

3. Выгрузка файлов; преимущества — бесконечное окно доступности с возможностью хранить историю источника; недостатки — отложенный контроль качества данных.

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

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

На рынке представлено множество отраслевых моделей данных — для телекоммуникационных компаний, для банков, для розничной торговли... Поставщика модели можно выбрать как зарубежного — SAS, IBM, Sybase, — так и российского, например, R Style. В любом случае надо быть готовым к тому, что модель будет переработана под потребности конкретного заказчика, при этом от исходной модели останется не так много. Вот лишь несколько проблем, которые предстоит решить:

• Для отчётности требуются данные, изначально не предусмотренные моделью.
• С другой стороны, часть данных, которые предусмотрены, взять просто неоткуда.
• Все идентификаторы клиентов, документов и прочих объектов надо привести к единому формату.
• При этом должна остаться возможность по данным из хранилища найти объект в исходной системе.
• Взаимосвязи между объектами на источнике могут отличаться от связей, предусмотренных моделью.

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

Компонент, отвечающий за преобразования, называется ETL-машиной, от слов Extract, Transform, Load. На проектах, где требуется разовое перемещение данных, эту работу вполне можно выполнить SQL-скриптами. Однако при построении хранилища, когда предполагается вести загрузку каждую ночь, дешевизна разработки может обернуться дороговизной поддержки. Что входит в понятие поддержки? Во-первых, администратор достаточно низкой квалификации (а где найти высококвалифицированного специалиста на ночные дежурства?) должен увидеть проблему в тот момент, как она возникла. Во-вторых, те люди, которые строили хранилище, с большой вероятностью уйдут, а развитием и поддержкой будут заниматься другие. Следовательно, код ETL-процессов должен быть понятен. В-третьих, язык SQL хорош для манипуляций данными, но совершенно не пригоден для выстраивания сложных потоков управления. Всё это приводит к необходимости использовать какую-нибудь специализированную ETL-машину с развитым визуальным интерфейсом. Например, Informatica PowerCenter, IBM Transformation Extender, SAS Data Integration Studio, Oracle Warehouse Builder. Все эти продукты имеют схожие интерфейсы, но архитектурно различаются довольно сильно.
Третья стадия — построение отчётов. Здесь наблюдается наибольшее разнообразие вкусов, потребностей и подходов.

Первый подход — online-отчётность. В этом случае отчёт разрабатывается заранее и обновляется разными пользователями несколько раз за день. В большинстве случаев влияние пользователя на результаты отчёта сводится к заданию нескольких параметров. Для таких задач прекрасно подходит web-интерфейс, предоставляемый большинством программных продуктов. Однако возможно и использование так называемого «толстого клиента», позволяющего конструировать новые отчёты. В качестве примера средств, обеспечивающих online-отчётность, можно назвать Business Objects, Microstrategy, Crystal Reports, SAS BI, Cognos.
Второй подход — ad hoc запросы. Пользователь получает прямой доступ к базе данных хранилища и сам пишет запрос на языке SQL. Такой доступ нужен в тех случаях, когда нужно получить какой-то разовый отчёт, под который нецелесообразно заводить форму. Либо тогда, когда пользователь сам пока не может чётко сформулировать свои пожелания и хочет «посмотреть, что может получиться». Нередко пользовательские находки становятся стандартными отчётами.

Очевидно, что написание SQL-запросов к базе данных такого объёма требует высокой квалификации пользователя. Поэтому разработчику, помимо собственно разработки, приходится заниматься обучением. Курс обучения может включать в себя подробный рассказ о модели данных, практикум по языку SQL, разъяснение алгоритмов и методов, применяемых при выполнении аналитических запросов. Работа эта выходит далеко за рамки обычных обязанностей разработчика, но зато даёт порой потрясающие результаты.

Третий подход — интеллектуальный анализ данных, data mining. Есть множество компаний, разрабатывающих продукты для data mining, например, Angoss, Portrait software, SPSS, Unica. Внедрение методов интеллектуального анализа возможно на поздних стадиях развития хранилища, когда пользователь очень хорошо представляет себе, какая информация у него есть. Задача пользователя — выбрать вопрос, на который он хочет получить ответ, и предположить, от каких параметров этот ответ может зависеть. Получив задание, разработчик должен сформировать витрину данных, содержащую порой несколько сотен показателей, и обеспечить регулярное обновление этой витрины. На практике оказывается, что из сотни рассчитанных показателей реально влияют на ответ лишь пять-шесть, и тогда цикл повторяется — пользователь придумывает новые показатели, разработчик реализует новые витрины, data mining ищет взаимосвязи. Цикл разработки долгий, результаты не гарантированы, поэтому затраты на внедрение data mining велики и продолжительны. Естественно, заказчик пойдёт на них только тогда, когда уровень доверия к данным хранилища достаточно высок.

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

Пятый вариант доступа к данным — использование хранилища как ODS, operational data store. Представьте себе абонентскую службу, куда владелец телефона обращается за распечаткой своих разговоров. Или функцию drill down, реализованную, например, в SAS BI, когда, увидев строку «20 просроченных договоров», пользователь хочет получить список этих договоров на экране. Предоставление таких выборок и есть назначение ODS. В отличие от отчёта, такой запрос читает небольшое количество данных. Но зато таких запросов может быть много, а агрегаты и витрины для них не годятся.

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

Первая проблема — данных становится всё больше и больше, и отчётов с каждым днём строится тоже больше. В конце концов оказывается, что суммарное время загрузки данных и построения отчётов вплотную подбирается к 24 часам в сутки. И если вдруг оказывается, что активное чтение пересекается по времени с активной записью, база данных встаёт намертво.

Узнав об этой ситуации, наш директор сказал: «Возьмите два сервера. На одном будете грузить данные, а на другом — строить отчёты». Идея оказалась чрезвычайно продуктивной. ETL-машина может теперь работать круглые сутки. Основная же база данных останавливается для синхронизации совсем ненадолго.

Вторая проблема, которая проявляется с началом активной работы пользователей, — некорректность исходных данных. Поначалу именно от пользователей поступает сигнал о том, что отчёты неправдоподобны. И если оперативно не реагировать на эти сигналы, то легко потерять доверие к хранилищу. Но и исправлять ошибки не так просто — перезагрузка больших объёмов требует времени, а перенесение изменений в основную базу — сокращения окна доступности. Постепенно, когда команда разбора инцидентов накапливает статистику ошибок, начинает строиться система контроля входных данных, EWS (early warning system). В основе алгоритма работы этой системы лежит построение трендов. Скажем, если последнюю неделю с источника приходили файлы по 100000 записей, то файл, в котором 50000 записей, вызовет подозрения.

Третья проблема является логическим развитием первой и следствием решения второй: всё выше доверие к отчётам, всё больше пользователей получают доступ к данным, и вот исчерпывается пропускная способность самого быстрого и дорогого дискового массива. Именно она, а вовсе не вычислительная мощность и объём памяти являются узким местом.

Разумеется, первым делом применяются всевозможные технические ухищрения: оптимизация массива, применение сжатия в базе данных. Когда эти методы себя исчерпывают, остаётся два пути, по которому развивается хранилище: создание большего количества агрегатов и тиражирование данных на несколько серверов. С тиражированием возможны самые причудливые варианты: например, для online-отчётности достаточно агрегатов, для стратегического анализа нужны детальные данные, но не все, а только срез по определённым клиентам... Часть информации новые сервера могут получать непосредственно с ETL-машины, не затрагивая основную базу данных.

Если нарисовать все внесённые изменения, то из примитивной картинки с двумя стрелками получим вполне рабочую архитектурную схему хранилища данных.

После того, как достигнут приемлемый уровень производительности, неожиданно возникает проблема резервного копирования хранилища. Ведь поначалу все относились к хранилищу как к дорогой игрушке, а потом, получив какую-то отдачу, наращивали объём данных. А теперь вдруг оказывается, что перезагрузить данные из источников в случае сбоя — непозволительная роскошь, а традиционные схемы резервного копирования для таких объёмов не годятся.

Организация резервного копирования хранилища — отдельный большой проект. В первую очередь следует определить, какую часть данных можно держать в режиме «только для чтения». Доля такой информации может достигать 70%, но даже для оставшихся 30% могут быть применены самые разные методы: поддержка standby-сервера, зеркалирование дисковых массивов и даже поддержка копии БД хранилища при помощи синхронизации с ETL-машиной. У каждого из этих способов есть как преимущества, так и недостатки, и сравнивать их имеет смысл только в рамках конкретной системы резервного копирования, каждая из которых сродни произведению искусства.

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

Прочитав статью, вы, возможно, спросите: «А стоит ли пускаться в путь, на котором поджидает так много подводных камней?» Конечно, стоит. Почитайте другие статьи, где описаны преимущества, которые сулит бизнесу внедрение хранилища данных. Они не врут, и даже не преувеличивают. А вы, подготовившись к встрече с проблемами, только повышаете свои шансы на успех.