|
А ведь есть такие аспекты производительности, которые присущи этим системам по их природе. Даже если предположить, что волею провидения все параметры витрины данных или хранилища вдруг будут правильно угаданы с самого начала, то и тогда следует ожидать падения производительности. Ведь после того, как аналитики заканчивают свою работу и объем данных начинает свой естественный рост, требования к использованию и производительности могут измениться.
|
Время понимать
"Анализ типов данных, к которым обращаются пользователи, достаточно очевиден и обычно выполняется при проектировании, - объясняет Рик Рой, вице-президент M&I Data Servicese, фирмы, занимающейся интеграцией СППР в банковском и финансовом секторе. - Сложнее выяснять, как часто пользователи делают запросы и не получают удовлетворительного ответа. Когда так происходит, нужно выяснять причину".
Рой предлагает учить пользователей обращаться к разработчикам, если их запрос не получил ответа или потребовал нетерпимо много времени на отработку.
"Когда пользователь недопустимо долго ждет ответа, мы спрашиваем: 'А как часто вы собираетесь делать такие запросы?'" - говорит Терри Макдональд, ответственный за информационные ресурсы в Hoffman Enclosures. В этой фирме эксплуатируется витрина данных объемом 10 Гбайт на компьютере AS/400. Она организована посредством предназначенного для этого пакета Data Tracker фирмы Silvon Software. В настоящее время с помощью этой витрины анализируются продажи и маркетинг, однако, по словам Макдональда, планируется расширить витрину для обслуживания запросов по финансам и производству.
Пользователям объяснили, что время отклика даже для нерегламентированных запросов составляет от 30 секунд до 2 минут. Если ответа приходится ждать 15 минут, пользователь должен обратиться в службу ИТ.
Эксперты утверждают, что год накопления информации - это тот "магический срок", после которого требуется производить первую существенную перенастройку системы. "Обычно через 12 - 18 месяцев после начала работы с системой пользователь приходит и говорит: 'Давайте все переделаем'", - делится наблюдениями Джон Хьюгс, вице-президент фирмы Silvon Software. Этот период времени требуется руководителям информационных служб на сбор достаточной информации о характере работы пользователей с данными. Но это же время нужно пользователям, чтобы понять, чего они на самом деле хотят от системы, в отличие от того, что они запрашивали у разработчиков до ее запуска.
Сбросьте вес!
Есть одно средство, чаще всего способное незамедлительно ускорить работу системы: ограничить объем данных, которые приходится загружать, хранить или сортировать при обработке запросов. Действительно, эксперты сходятся в том, что ориентация на чересчур большой объем данных - ошибка номер один среди проектировщиков конкретных СППР, и витрин данных в том числе.
"Большинство людей стремится получать от витрины чересчур много, - говорит Джефф Уинго, проектировщик из фирмы Axiom, системного интегратора в области витрин данных. - Часто проектировщики заглядывают слишком далеко вперед. Они, например, могут поставить себе целью объединиться с бухгалтерской системой или с системой дистанционного маркетинга, и по этой причине пытаются включить соответствующие возможности в проектируемую витрину. И вместо завершенной и результативной системы они получают затянутые сроки и возросшую сложность".
Уинго и Рой отмечают, что так же, как и для витрин, для хранилищ нужно отбирать "самое сладкое", то есть данные, которые наиболее часто используются. Если это сделано, хранилище становится драгоценным источником "промытых" данных и может обеспечивать несколько витрин, построенных для конкретных приложений или отделов предприятия. Прямое обращение к хранилищу должно быть разрешено всего для нескольких людей, которым нужна картина всего предприятия невзирая на границы подразделений - например, для директора информационной службы.
"Хранилище обеспечивает данным общую основу, - говорит Эд Коннели, системный архитектор из фирмы Axiom. - Это должны быть 'нейтральные' исходные данные, не форматированые, к примеру, в соответствии с бухгалтерскими алгоритмами".
Загрузка и разгрузка
Когда для "придания стройности" распухшему хранилищу приходится разгружать ненужные данные, это - всего лишь половина решения проблемы. По словам пользователей, еще более важной является загрузка.
"Когда мы строили витрину данных, то каждый хотел поместить в нее все, - говорит Тодд Гринвуд, управляющий по маркетингу баз данных в Harvard Business School Publishing. - А сейчас мы понимаем, что 'всего' и не требовалось. Поэтому теперь нам надо переделывать процедуры извлечения данных, с тем, чтобы в витрину попадала только часть информации".
В этом некоммерческом подразделении Гарвардского университета используется система Analytix фирмы Customer Insight, работающая под Windows NT. Витрина используется для анализа данных о продажах и о маркетинге, ее объем - примерно 5 Гбайт, она одновременно обслуживает около десяти пользователей при общем количестве сотрудников 300. Основной режим работы этих десятерых - нерегламентированные запросы, относящиеся к деятельности этого издательства книг и компакт-дисков.
В дополнение к отсечению ненужных данных в процессе загрузки/разгрузки есть еще один путь сокращения объема хранимых данных: задание им разумной даты конца хранения.
"Наибольшую проблему я вижу в определении периода хранения информации в хранилище, - говорит Майк Бероник, старший руководитель проектов в области хранилищ данных в фирме M&I Data Services. - Если вы время от времени вынуждены добавлять новые отношения и новых пользователей, то система начинает терять производительность. Одни и те же данные вы будете получать все медленнее и медленнее".
Сложность схемы как сигнал опасности
По мнению экспертов, на то, что ваша база данных перегружена, указывает также ее слишком сложная схема. Если вы думаете о переходе к схеме "снежинка" с целью добавить к данным новые измерения, то у вас сильно растут шансы получить переусложненную систему, особенно если речь идет о витрине данных.
По замечанию Джагдиша Мирани, управляющего по маркетингу в области информационных хранилищ из фирмы Oracle, при проектировании хранилища схема "снежинка" в конечном счете может применяться, но - как последнее средство. Нормальное решение - это схема типа "звезда", так как она отражает базовые измерения для большинства важных для бизнеса запросов. Например, если у вас есть измерение "заказчик", то пользователи могут запрашивать по этому измерению такие подробности, как адрес или номер счета. Должны появиться потребности анализировать "адрес" дальше, чтобы начать применять схему "снежинка".
"Но модель данных не относится к тем вещам, которые следует изменять каждый день", - предупреждает Мирани.
Будь проще (если можешь)
Руководители проектов витрин и хранилищ не должны забывать и о менее сложных способах настройки систем. Первейшим среди них является организация сводной таблицы. Если данные удается собрать в такой таблице, скорость обработки запросов для типичных случаев может существенно возрасти. Однако, предупреждает Хьюгс, здесь могут возникать и обратные эффекты, поскольку общая производительность определяется балансом трех факторов: скоростью обработки запроса, потребным объемом дисковой памяти и интервалом времени для пакетной загрузки данных.
Чрезмерная оптимизация какого-нибудь одного фактора может привести к отрицательным изменениям остальных. К примеру, разработчик может преуспеть в уменьшении времени отклика путем организации сводных таблиц, однако при этом возрастет потребность системы в дисковом пространстве и увеличится время внесения обновлений в данные. Можно сэкономить дисковое пространство за счет уменьшения числа сводных таблиц, но тогда время выполнения запросов увеличится. Если плановая загрузка изменений производится по ночам, вам может не хватить времени на модификацию каких-то сводных таблиц, а ведь к утру система должна быть готова к работе.
Увеличению производительности также способствует ограничение круга людей, которым передаются инструменты формирования нерегламентированных запросов, и хорошее обучение этих людей. Такие предложения дает Дэвид Рокмор, отвечающий за управление информацией в фирме San Diego Gas&Electric (SDGE).
"Многие пользователи хотят просто увидеть отчет. Им не важно, как он получен, они просто хотят увидеть данные", - поясняет Рокмор. Поэтому в SDGE стараются использовать штатные формы отчетов - когда и где только возможно - и ограничить использование нерегламентированных запросов только кругом "продвинутых пользователей".
Когда какой-то запрос повторяется часто, всегда есть возможность оптимизировать его выполнение, заготовив соответствующий штатный отчет. Продвинутые же пользователи, обученные строить нерегламентированные запросы, могут после этого при необходимости задать уточняющий запрос и получить более подробную информацию.
Хранилища из "Lego-витрин"
При построении конкретной СППР, и особенно витрины данных, от нее часто требуют слишком многого. "Определитесь с тем, что должна обеспечивать эта витрина, и пусть она делает что-нибудь одно", - советует Бироник из V&I Data Services.
"Наилучшая в долгосрочном плане настройка производительности не нуждается даже в единственном 'кликаньи' мышкой, нужно просто разработать план объединения различных витрин данных", - говорит Том Хэммергрин, руководитель по решениям в области хранилищ фирмы Sybase и автор книги Data Warehousing: Building the Corporate Knowledge Base.
Простота такой интеграции достигается созданием одной общей модели для построения всех витрин. Для этого компания должна стандартизировать определения общих данных типа "клиент" или "продукт" и дать возможность "каждой группе расширять стандартные определения настолько, насколько это ей необходимо", поясняет Хэммергрин. Например, поля "клиента" с именем, адресом и номером телефона будут определены во всех системах идентично. Однако бухгалтерия может использовать еще и поле "кредитный рейтинг", а отделы продаж и маркетинга могут завести демографические характеристики клиента.
Использование принципа Lego - это хорошая стратегия в витринах данных, соглашается Марк Каминский, старший вице-президент по информационным технологиям в CompuSearch Micro Marketing Data Systems. С помощью системы Sybase IQ эта фирма строит у себя целую серию витрин данных для нужд основного бизнеса. "Мы видим, что проекты по созданию хранилищ очень часто проваливаются. Будет лучше, если к ним подходить как к набору витрин, - заключает Каминский. - Пользователи хотят выдавать запрос, а затем перезапрашивать снова и снова. Если они не смогут делать это за секунды, то ваша система теряет свою прелесть".
Управляйте ожиданиями
Естественно, что сама система - не единственная "часть уравнения", требующая оптимизации. Хороший совет руководителю проекта: "оптимизировать" нужно и пользователей. Нужно управлять их ожиданиями приемлемости или неприемлемости времени отклика в конкретных случаях и регулярно проводить с ними беседы для выявления претензий к производительности.
Кроме того, команда разработчиков должна стараться как можно больше узнать о прикладном аспекте системы.
"Вам нужно стремиться к тому, чтобы львиную долю своих ограниченных ресурсов тратить на наиболее важные вопросы бизнеса, - дает совет Гринвуд из Гарварда. - Я тесно контактирую с отделом маркетинга и его директором; я работаю и в области технологии, и в области бизнеса. Ведь в жизни они существуют вместе".
Когда ничего не помогает
И наконец, если все вышесказанное не помогает, наращивайте мощность аппаратных средств. Это не исправит недостатки плохого проектирования, но даст эффект в случае проблем с мощностью процессора или объемом памяти. Однако и на этом пути без тщательного контроля того, как конкретно работает система, вам не обойтись.
Джулия Борт - постоянный автор журнала InfoWorld, автор книги Building an Extranet (John Wiley&Sons).