Тайлер Чессман ( tylerc@microsoft.com )– специалист по технологиям в компании Microsoft, помогает клиентам в тестировании и внедрении SQL Server

Как показано на рисунке, к компонентам, необходимым для решения задач бизнес-аналитики на уровне предприятия и самостоятельного бизнес-анализа, относятся службы PerformancePoint Services, службы Excel, службы отчетов SQL Server SSRS (SQL Server Reporting Services), инструмент Power View и модуль PowerPivot for SharePoint. В приведенной таблице содержится их краткое описание. Каждый из этих компонентов я рассмотрю более подробно.

 

Выделение цветом компонентов, обслуживающих бизнес-аналитику на уровне предприятия и?самостоятельный бизнес-анализ
Рисунок. Выделение цветом компонентов, обслуживающих бизнес-аналитику на уровне предприятия и?самостоятельный бизнес-анализ

 

Компоненты для решения задач бизнес-аналитики на уровне предприятия и?самостоятельного анализа

Службы PerformancePoint и Excel

Многие организации моделируют бизнес-процессы (такие, как сбыт и прогнозирование продаж) с использованием служб SQL Server Analysis Services (SSAS), так, чтобы конечные пользователи могли с легкостью исследовать данные с помощью инструментов, подобных Microsoft Excel PivotTables. В традиционном многоразмерном режиме SSAS не зависит от SharePoint. То же можно сказать и о новом табличном режиме, реализованном в версии SSAS 2012. Располагая службой SSAS и внешним интерфейсом Excel, организация может реализовывать эффективные BI-решения. Однако по всей вероятности многие организации захотят строить внешний интерфейс для службы SSAS средствами SharePoint. Эти дополнительные интерфейсы можно создать с помощью двух технологий, непосредственно встроенных в SharePoint 2010 Enterprise; речь идет о службах PerformancePoint Services и Excel Services.

PerformancePoint Services.

Используемые в бизнес-аналитике панели мониторинга и оценочные листы стали весьма популярными, поэтому все крупные поставщики средств для BI оснастили свои продукты панелями мониторинга и оценочными листами. Оценочный лист обычно состоит из нескольких ключевых показателей производительности Key Performance Indicators (KPI), которые часто группируются по различным объектным областям. Типичная панель мониторинга представляет собой набор из одного или нескольких оценочных листов и обеспечивает возможность работы с деталями, а также с отчетами, которые часто связаны друг с другом посредством заранее заданных соединений или общих фильтров.

Поставку панелей мониторинга и оценочных листов корпорация Microsoft первоначально осуществляла через диспетчер Microsoft Office Business Scorecard Manager (BSM) 2005. В 2006 году Microsoft приобрела продукт ProClarity, который на тот момент был наиболее популярным партнерским внешним интерфейсом для SSAS. BSM и ProClarity были интегрированы в автономный продукт, получивший название PerformancePoint Server 2007. В PPS 2007 были реализованы три важные функции: мониторинг (панели мониторинга и оценочные листы), аналитика (интерактивные сетки и диаграммы) и планирование (прогнозирование и бюджетирование). И хотя сервер PPS 2007 относился к разряду автономных, панели мониторинга, оценочные листы, сетки и диаграммы, которыми он был оснащен, почти всегда развертывались в среде SharePoint 2007.

В версии SharePoint 2010 продукт SharePoint 2010 Enterprise PPS реализован как встроенная служба PerformancePoint Services. В оценочный лист PerformancePoint Services могут входить ключевые показатели производительности, которые обрабатывают значения, полученные из разных источников, однако аналитические сетки и диаграммы PerformancePoint Services функционируют только поверх куба SSAS или рабочей книги PowerPivot, резвернутой в библиотеке SharePoint. Отметим, что функции планирования в версии PPS 2007 уже не реализуются.

Excel Services. Excel Services — это служба, встроенная в редакцию Enterprise продукта SharePoint 2010, а также в версию SharePoint 2007. Она позволяет публиковать в библиотеке документов SharePoint, а затем и отображать в браузере целую рабочую книгу Excel или отдельный компонент такой книги (диаграмму или, скажем, поименованный диапазон ячеек). К примеру, на экране 1 правая сторона панели мониторинга представляет собой поименованный диапазон из рабочей тетради Excel. Когда пользователь щелкает на одном из KPI в левой части экрана (или выбирает другое значение в фильтре Fiscal Year), рабочая книга Excel обновляется, и на экране появляются сведения соответствующего индикатора KPI. Отметим, что служба Excel Services может отображать любую рабочую книгу — вне зависимости от того, подключена ли она к кубу SSAS. Но самая замечательная возможность службы Excel Services состоит в том, что она, по сути превращая Excel в авторское средство для формирования отчетов, сокращает тем самым время, затрачиваемое на обучение конечных пользователей; теперь они могут быстрее приступать к созданию аналитических материалов и предоставлять их в распоряжение других сотрудников.

 

Отображение в панели мониторинга поименованного диапазона ячеек из рабочей книги Excel
Экран 1. Отображение в панели мониторинга поименованного диапазона ячеек из рабочей книги Excel

Оценочные листы и ключевые показатели производительности используются не только в контексте служб Excel Services и PerformancePoint Services. Средствами для взаимодействия с этими компонентами наделен целый ряд продуктов Microsoft.

SSRS и Power View

Чтобы лучше разобраться в вопросах интеграции службы отчетов SQL Server и SharePoint, полезно совершить небольшой экскурс в историю SSRS. Когда в 2004 году эта служба была впервые реализована в виде дополнительного компонента SQL Server 2000, в ней был предусмотрен всего лишь один режим развертывания (сейчас он именуется собственным режимом — native mode), а об интеграции с SharePoint не было и речи. Единственным средством для отображения отчетов внутри SharePoint был универсальный компонент Page Viewer Web Part. Этот компонент, входящий во все версии SharePoint, представляет собой фрейм HTML для отображения веб-содержимого заданного URL-адреса.

В 2005 году Microsoft ввела в состав пакета SQL Server 2000 Reporting Services SP2 веб-компоненты Report Explorer и Report Viewer SharePoint 2.0 Web Parts. Отметим, что эти веб-компоненты до сих пор поставляются в текущих версиях и представляют собой вполне приемлемое решение для клиентов, использующих системы с собственным режимом SSRS. Компонент Report Explorer Web Part предназначен для отображения списка папок и отчетов из заданной папки SSRS в системе с собственным режимом. Кроме того, он передает имя выделенного отчета компоненту Report Viewer Web Part.

В версии SQL Server 2005 SP2 был реализован режим интеграции SSRS, обеспечивающий более тесный уровень интеграции с SharePoint. Режим интеграции с SharePoint обеспечивал ряд потенциальных преимуществ, включая следующие.

* Возможность хранить отчеты в библиотеке документов SharePoint. Такие библиотеки предоставляют возможности, которых не имеет собственный режим SSRS — например, возможность работы с несколькими версиями документов, возврат/извлечение и дополнительные столбцы для классификации отчетов.

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

* Новое расширение библиотек документов для подписок на отчеты. Подписки на отчеты дают возможность доставлять отчеты непосредственно в библиотеки документов, что удобно в случаях, когда сведения о предоставленных отчетах необходимо сосредоточить в одном месте. Отметим, что режим интеграции с SharePoint, реализованный в службе SSRS 2005, предполагает осуществление только пользовательской подписки, но не подписки, управляемой данными. Версия SSRS 2008 дает возможность осуществлять управляемую данными подписку.

Вариант режима интеграции с SharePoint, реализованный в пакете SQL Server 2005 SP2, имел ряд недостатков. Некоторые возможности собственного режима SSRS (такие, как My Reports и Linked Reports) не были предусмотрены. К тому же свои претензии могли предъявить и администраторы: в процессе настройки и обслуживания SSRS все еще приходилось рассматривать как особую службу. К примеру, при масштабном развертывании SSRS нельзя было воспользоваться автоматическим масштабированием архитектуры, применяемой во встроенных службах SharePoint.

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

В конце 2010 года консультативная группа SQL Server CAT (Customer Advisory Team) осуществила тщательное тестирование версий SSRS 2008 и SSRS 2008 R2. В технической заметке «Reporting Services Performance in SharePoint Integrated Mode in SQL Server 2008 R2» (http://sqlcat.com/sqlcat/b/technicalnotes/archive/2010/11/03/reporting-services-performance-in-sharepoint-integrated-mode-in-sql-server-2008-r2.aspx) консультанты отмечали «наличие связанных с использованием режима интеграции с SharePoint ощутимых дополнительных непроизводительных затрат, снижающих быстродействие выполнения отчета (от 250 миллисекунд до 500 миллисекунд дополнительных затрат при просмотре первой страницы любого отчета)». Некоторые потребители отметили еще большие непроизводительные затраты при использовании режима интеграции с SharePoint по сравнению с собственным режимом.

А теперь переместимся в 2012 год. В версии SSRS 2012 архитектура режима интеграции с SharePoint претерпела изменения, и была создана совместно используемая служба SharePoint 2010. Эту службу можно рассматривать как реально работающий компонент SharePoint — такой же, как Search и User Profile. В плане производительности это означает, что непроизводительные затраты на дополнительный сеанс связи ушли в прошлое, так же, как и снижение быстродействия. Производительность SSRS 2012 в режиме интеграции примерно на 30-60 % выше, чем у версии SSRS 2008 R2 и сопоставима с производительностью при использовании собственного режима. Применение новой архитектуры совместно используемой службы дает и другие преимущества:

— настройку SSRS в режиме интеграции с SharePoint можно осуществлять с помощью консоли центра администрирования SharePoint (SharePoint Central Administration console);

— служба SSRS может использовать реализованные в SharePoint функции масштабирования и балансировки нагрузки;

— SSRS обеспечивает проверку полномочий на основе утверждений;

— SSRS обеспечивает реализованные в SharePoint средства резервного копирования и восстановления, а также процедуру сквозной регистрации SharePoint средствами единой службы ведения журналов Unified Logging Service (ULS).

Кроме того, специалисты Microsoft решили реализовать в SSRS 2012 ряд новых возможностей, которые доступны только в режиме интеграции в SharePoint. Одна из таких возможностей — предупреждения о данных (data alerts). Как показано на экране 2, конечные пользователи могут создавать график и набор правил, в соответствии с которыми система будет извещать их в случае изменения данных в отчете. Другую возможность представляет новая технология визуализации данных и исследований Power View.

 

Создание предупреждения о данных
Экран 2. Создание предупреждения о данных

Предупреждения о данных и средства Power View доступны только в редакциях Business Intelligence и Enterprise продукта SQL Server 2012. Более подробную информацию об этих возможностях можно найти в статье «What's New (Reporting Services)» (http://msdn.microsoft.com/en-us/library/ms170438%28v=SQL.110%29.aspx) в SQL Server 2012 Books Online (BOL).

PowerPivot for SharePoint

После длительного периода приобретений и слияний мы, наконец, стали свидетелями возрождения на рынке средств BI специализированных поставщиков. Нередко эти продукты позволяют бизнес-пользователям решать задачи по сбору, хранению, моделированию, анализу и совместному использованию информации без применения традиционных ИТ-инструментов и процессов. Я знаком с несколькими профессионалами в сфере ИТ, обнаружившими такие решения в своих организациях лишь после того, как они были приобретены одним из бизнес-подразделений. По этой причине я рекомендую вам внимательно ознакомиться с возможностями, которые SQL Server, SharePoint и Office открывают перед пользователями для самостоятельной бизнес-аналитики. Вы получаете шанс стать героем в глазах своих пользователей, поскольку применяете продукты, которые им не нужно покупать и с которыми они уже знакомы. Я говорю, например, о поставляемых Microsoft продуктах PowerPivot для Office и SharePoint; представители корпорации называют их средствами «управляемой самостоятельной» бизнес-аналитики. Надстройка PowerPivot for Excel 2010 дает пользователям возможность собирать, хранить, моделировать и анализировать данные из нескольких источников. Без каких-либо видимых проявлений пользователи фактически создают куб OLAP, который выполняется в памяти внутри процесса Excel (этот куб сохраняется как часть рабочей книги Excel).

Надстройка PowerPivot for SharePoint 2010, впервые реализованная в пакете SQL Server 2008 R2, представляет собой экземпляр SSAS, интегрированный в SharePoint. PowerPivot for SharePoint устанавливается и настраивается как часть совместно используемой службы SharePoint. Когда пользователь публикует рабочую книгу Excel, содержащую модель PowerPivot, компонент PowerPivot for SharePoint (во взаимодействии с Excel Services) обеспечивает для других сотрудников возможность просматривать эту рабочую книгу и взаимодействовать с ней через браузер. Кроме того, PowerPivot for SharePoint обеспечивает подключение к рабочей книге других технологий (таких, как SSRS и Power View). Имейте в виду, что модуль PowerPivot for SharePoint реализован только в редакциях Business Intelligence и Enterprise пакета SQL Server 2012, а также в редакции Enterprise пакета SQL Server 2008 R2.

Я упомянул лишь малую часть функций, реализованных в модулях PowerPivot for Excel 2010 и PowerPivot for SharePoint 2010.

Система BI Shared Service

Итак, перед вами открывается масса возможностей в сфере BI, поэтому вполне вероятно, что вы подумываете о создании фермы SharePoint для решения задач бизнес-аналитики. Но даже если у вас уже есть ферма SharePoint, я рекомендую создать отдельную ферму, специально посвященную BI, которая именуется системой BI Shared Service. Эта рекомендация может показаться нелогичной. В конце концов, если SharePoint наделен функциями бизнес-аналитики (а SQL Server интегрируется в SharePoint), почему бы не активировать эти функции непосредственно внутри существующих ферм? Разве, устраивая отдельную ферму, мы не теряем все те преимущества, которые приносит интеграция?

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

* Несовпадение версий. Существующие фермы SharePoint выполняются на платформе SharePoint 2007 или вдохновляются планами администраторов перейти от версии SharePoint 2007 к версии SharePoint 2010 «когда-нибудь в будущем году».

* Конфликт рабочих нагрузок. Администраторы SharePoint обычно с опаской относятся к перспективе подвергнуть ферму дополнительной нагрузке, особенно если речь идет о нагрузке, которой они не понимают.

* Интеграция с системами, не относящимися к продуктам SharePoint. Администраторов SharePoint беспокоит то обстоятельство, что многие службы BI реализованы не как функции SharePoint, а как службы SQL Server.

Создание отдельной фермы BI позволит уменьшить эти опасения и поможет развертывать или обновлять функции BI вне зависимости от других рабочих нагрузок SharePoint. Администраторы SQL Server и SharePoint могут в процессе совместной работы познакомиться с этими новыми службами BI, не ставя под угрозу быстродействие и доступность существующих возможностей и служб SharePoint. Прекрасное решение для создания небольшой системы BI Shared Service, использующей всего один сервер — продукт HP Business Decision Appliance.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF