• Статья

Глобальный подход к BI: принципы организации хранилищ данных
для корпоративных BI-приложений

Чарльз Фихтер (Charles Fichter) (cfichter@microsoft.com) - старший архитектор решений в группе Global ISV (Independent Software Vendor) корпорации Microsoft в области Developer Evangelism. Ветеран разработки ПО и проектирования баз данных с 20-летним опытом, специализируется на бизнес-анализе, Microsoft SQL Server, Microsoft BizTalk Server и общих вопросах проектирования .NET-приложений и баз данных промежуточного уровня и уровня данных. Последние четыре с половиной года помогал Global ISV в выработке стратегий проектирования приложений. Ниже приведен список некоторых других публикаций Чарльза.

В статье рассказывается о принципах проектированиях архитектур глобальных хранилищ данных (data-warehouse, DW), являющихся венцом любого спешного решения в области бизнес-анализа (businessintelligence, BI). Статья основана на опыте партнеров Microsoft Global ISV (independent software vendor) в проектировании корпоративных BI-приложений с использованием технологий Microsoft и содержит ссылки на внешние источники и общедоступный контент, в котором более глубоко рассматриваются затронутые в ней темы. Предполагается, что читатель знаком с базовыми понятиями хранилищ данных, такими как многомерное хранение данных, таблицы фактов, поля которых называют мерами, таблицы измерений, поля которых называют атрибутами, и тем, как формируются схемы «звезда» или «снежинка». Доступно много ресурсов с обзорами на эту тему; при необходимости можно найти краткий обзор по ссылке http://www.simple-talk.com/sql/learnsql-server/sql-server-datawarehouse-cribsheet. Кроме того, в статье рассматриваются стратегии реализации успешных DW-проектов и тонкости разработки систем, обеспечивающих оптимальную производительность.

Введение

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

Изолированные корпоративные данные и доступ к ним

Корпоративные архитекторы, которым требуется обеспечить агрегирование данных приложений в моделях многомерной онлайновой аналитической обработки (Multidimensional Online Analytical Processing, MOLAP), часто сталкиваются с множеством внутренних препятствий, мешающих доступу к исходным данным. Это препятствия в меньшей степени технического характера и в большей степени связанные с бизнесом, законодательством, аудитом и безопасностью; также препятствиями могут быть слишком жесткие ограничения расходов, особенности реализации проекта и даже политические требования, поскольку бизнес-данные являются «прослойкой» между руководством и подразделениями. Иногда препятствиями становятся технологические ограничения, такие как несовместимости, применение закрытых решений, работа с унаследованными форматами файлов, нереляционными или неструктурированными данными. Но благодаря преимуществам средств, предлагаемых поставщиками (особенно усовершенствованиям Microsoft SQL Server 2008, прежде всего возможностям Microsoft SQL Server Integration Services [SSIS]), и технологий SOA (например, применению WS* и других открытых стандартов соединений), эти проблемы становятся значительно менее острыми.

Однако реализация многих BI-проектов затягивалась и/или терпела крах из-за того, что группе не удалось точно выяснить, какие данные необходимы и как обеспечить беспроблемный доступ к ним и сделать их полезными. Полезность является ключевым понятием. Как взять десятки полей (с именами наподобие «xtssalescongproc») и объединить их в центральной таблице фактов с удобочитаемыми именами полей, которая в будущем позволит конечным пользователям применить технологии самообслуживания в BI?

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

  1. Уже на раннем этапе получите широкие административные полномочия
    Успех вашего проекта зависит от того, насколько глубокий и широкий доступ к данным обеспечивают ваши полномочия. Запросить доступ - это всего 1% ваших усилий. Возможно, потребуется, чтобы подразделения потратили время и средства (часто потенциально может пострадать и обслуживание клиентов) на то, чтобы предоставить вам результаты анализа, доступ и/или результаты агрегирования данных. Кроме того, действительно ли сотрудники вашего отдела понимают, что представляют собой их данные? Сколько раз вы просили их проанализировать и оценить хотя бы то, какие данные и ресурсы они должны вам предоставить? Нельзя недооценивать важность полномочий и потенциальную стоимость ресурсов других хранилищ ценных данных и времени людей, которые ими управляют.
  2. Действительно ли все знают свои данные?
    Этот вопрос может показаться странным; но мы потратили много сил на решение этой проблемы и никогда не перестанем удивляться тому, насколько мало корпоративные пользователи знают собственные данные. Многие амбициозные BI-проекты приостанавливали сразу после того, как выяснялось, что группе, работающей над проектом, прежде всего придется полностью проанализировать все корпоративные хранилища данных, на что часто требуются месяцы. Даже простой просмотр таблиц может поставить в тупик архитектора, незнакомого с источником данных, поскольку имена полей не всегда описывают данные, которые содержат поля. Часто приложения и хранилища просто обслуживаются и не совершенствуются годами, а назначение и архитектура хранилища - знание о далеком прошлом, передаваемое по наследству. Можно ли эффективно проанализировать базу данных, содержащую более 500 таблиц, и понять каждое отношение в ней, не зная детали каждого приложения, использующего ту базу? Наверное, можно, имея продвинутые инструментальные средства и уйму времени. Но дьявол кроется в деталях, и мощь измерений и атрибутов, которые вы создадите в дальнейшем, зависит от знания источника необработанных данных, на основе которых формируются агрегаты.
  3. Изучайте и консолидируйте местные приоритетные требования
    Наиболее активно запрашиваемые BI-отчеты часто являются местными/региональными по своей природе (специфичными для страны/территории, где ведется торговля), поэтому встает вопрос: действительно ли необходимо немедленное создание гигантского хранилища агрегированных данных? Может, эффективнее создать распределенное хранилище данных и BI-стратегию, основанную на местных/региональных требованиях в сочетании с корпоративными? Этот вопрос более глубоко рассматривается в следующем разделе; может оказаться, что децентрализованный подход обеспечивает значительное сокращение расходов, снижение нагрузки на сеть и выигрыш в производительности.

Поэтапный подход к организации хранилища данных

Многие BI- и DW-проекты начинались с амбициозных стремлений спроектировать и разработать лучшее в мире агрегированное многомерное хранилище данных с поддержкой репликации подмножеств многомерного хранилища в различные регионы (т. е. витрин данных). Однако всегда ли необходим или хотя бы целесообразен такой подход? Почти в каждом DW- или BI-проекте недооценивают затраты времени и ресурсов на проектирование механизмов агрегирования и очистки данных, формирования наборов данных и/или репликации в независимые MOLAP-хранилища для соблюдения глобальных корпоративных требований.

Уровень развития и опыт в реализации BI-решений может сильно различаться от предприятия к предприятию. Разбивайте задачи на менее крупные и требующие меньше времени подпроекты - это позволит вашим группам получить навыки и опыт, необходимые, чтобы понимать, как достичь более крупных и долгосрочных целей. Запомните правило 80/20: обычно на реализацию 80% требуемых функций затрачивается 20% усилий. Попробуйте применить поэтапный подход (рис. 1).


Рис. 1. Предлагаемые этапы реализации глобального BI/DW

Этап 1
Если требования на построение BI-отчетов поступают достаточно редко, оставьте как можно больше исходных данных на своем месте и создайте многомерные представления, используя стратегию распределенного кеширования, чтобы быстро реализовать подмножество бизнес-решений. Будет ли эффективным просто применить продвинутые инструментальные средства для запроса данных из хранилищ, используемых существующими приложениями, даже если они основаны на конкурирующих платформах? Это важная точка принятия решения, которая встретится уже на ранних стадиях. Такой подход позволяет ответить на BI-вопросы наподобие «скажите, что происходит в моем бизнесе сейчас». Эта стратегия наиболее эффективна при использовании несовместимых технологий или при четком отделении хранилищ данных друг от друга в соответствии со структурой подразделений. Она гораздо эффективнее (с точки зрения затрат человеко-часов вашей группой) и позволяет быстрее предоставить решения бизнес-подразделениям.

Хотя в результате пользователям, возможно, придется дольше ждать, применение таких средств, как SSIS, поможет создать пакеты для получения агрегатов и очистки больших количеств данных (даже из хранилищ данных, не использующих технологии Microsoft), формировать отношения между измерениями в кеше в памяти и передавать выходные данные запрашивающим приложениям через Microsoft SQL Server Analysis Services (SSAS). Раньше такой подход был целесообразен только для относительно небольших объемов данных, однако благодаря оптимизациям, внесенным поставщиками СУБД, он стал пригоден для практического применения.

Этап 2
По возможности всегда разрабатывайте и храните многомерные хранилища данных локально. Имея большие объемы агрегированных данных, компании могут начать более интенсивно анализировать их, чтобы ответить на вопросы BI наподобие «Покажите, как менялась производительность с течением времени». Чтобы начать решать такие проблемы, вы обязательно должны критически проанализировать, действительно ли необходима репликация агрегированных данных в централизованное хранилище. Может быть, эффективнее заполнить локальные MOLAP-хранилища данными, используемыми в бизнес-анализе на региональном уровне? Когда вы будете выбирать между региональными и корпоративными требованиями, вы, вероятно, увидите, что требования к построению более глубоких и подробных отчетов - локальные/региональные по своей природе. BI-запросы уровня предприятия обычно связаны с более масштабным анализом, ориентированным на выявление тенденций, для поддержки которого достаточно агрегирования итоговых данных из небольших многомерных хранилищ. Менее дорогие бюджетные MOLAP-хранилища можно эффективно обслуживать, используя локальные ресурсы; их применение значительно упрощает проектирование центрального хранилища и уменьшает потенциально большую загруженность сети и требования к репликации данных.

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

Стратегия интеграции данных

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

Для создания корпоративной архитектуры бизнес-анализа (business-intelligence, BI) необходимо идентифицировать ключевые предметные области предприятия,
например:

Клиент
Товар
Сотрудник
Запасы

Когда все эти области идентифицированы, необходимо определить, какие атрибуты следует собирать для построения корпоративного представления. Поля, которые вы определите, станут основой корпоративной BI-платформы. Например, если CRM-система (customer relationship management) позволяет получить данные о том, что у клиента трое детей, нужно ли переносить эту информацию такого рода в корпоративную BI-систему, чтобы каждый сотрудник мог использовать ее для принятия лучших бизнес-решений? Знание о том, какие атрибуты необходимо хранить, чтобы принести пользу всему коллективу организации, позволит вам приступить к интеграции данных.

Используя Microsoft SQL Server и Microsoft Biz Talk Server, можно разработать корпоративную стратегию BI и интеграции данных, которая позволит интегрировать и хранить данные критически важных предметных областей. Структура базы данных должна быть аб страктной - для этого следует применить шаблон интеграции корпоративных данных, называемый канонической моделью данных. Эта модель требует, чтобы все входные данные соответствовали пользовательскому шаблону. Например, в корпоративной BI-системе следующие поля могут быть обязательными для запол нения:

Имя, фамилия
Адрес
Город, область, почтовый индекс
Телефон
Адрес электронной почты

В приложениях-источниках скорее всего хранится и другая информация, например номер телефона, пол и возраст.

BizTalk Server позволяет принимать сообщения из различных приложений и записывать информацию в соответствующие таблицы баз данных.

Собираемые данные можно сохранять в OLAP-кубах (online analytical processing), а затем предоставлять бизнес-пользователям для принятия решений. Процесс загрузки и добавления результатов расчетов в куб позволяет каждому бизнес-специалисту воспользоваться выполненной работой и найти данным полезное применение. Пользователи, обращающиеся к кубу, получают на свои запросы ответы, основанные на одной и той же информации, а когда запрашиваются новые результаты расчетов, каждый сотрудник организации выигрывает от добавления информации в базы данных.

Идентификация, интеграция и создание централизованных OLAP-хранилищ позволяет организациям использовать данные как ценный ресурс, доступный
в масштабах всей компании.

Дерек Э. Уилсон (Derek E. Wilson) - архитектор и менеджер по бизнес-анализу в Нэшвилле, штат Теннеси. Посетите его веб-сайт www.derekewilson.com.

Этап 3
Создайте и заполните традиционное независимое централизованное DW вашей мечты, чтобы выполнить все самые амбициозные BI-требования вашей компании. Такой подход позволит достичь более сложных целей BI, например ответить на вечный вопрос «просеивания» данных - «спрогнозируйте будущие результаты». На этот вопрос можно дать ответ, только проанализировав тенденции на основании огромного количества исторических данных, собранных со всей компании.

Можно выявлять исторические тенденции и анализировать данные, используя региональные хранилища (читать, использовать или агрегировать данные из репозитариев, созданных в соответствии с требованиями этапа 2 или даже этапа 1). Но для получения отчетов по необработанным данным и реализации информационных панелей с поддержкой углубленного анализа на основании очень большого количества исторических корпоративных данных наиболее эффективным выбором будет скорее всего реализация централизованного DW. Однако во многих успешных BI-проектах, пожалуй, можно обнаружить сочетание подходов этапа 2 и этапа 3.

Проектирование эффективных, производительных и удобных в обслуживании многомерных хранилищ

В результате эволюции хранилищ данных то, что когда-то было статической стратегией репликации крупных хранилищ данных только для чтения, выполняемой для построения отчетов, превратилось в гораздо более динамичную среду, где пользователи имеют широкие возможности, в том числе могут создавать собственные запросы, формировать отчеты по принципу самообслуживания - с помощью таких средств, как PowerPivot (прежнее кодовое название «Gemini») и расширения Office Excel 2010, которое будет доступно в первой половине 2010 г. и позволит пользователям обращаться к большим объемам многомерных данных (более 100 миллионов записей) и строить сводные отчеты, используя кеширование, - и даже выполнять обратную запись прямо в многомерные хранилища.

Возможности инструментов, доступных на этапе разработки, оказывают существенное влияние на качество моделей, помогая преодолеть сложности отношений с помощью визуальных средств и выявить потенциальные узкие места, неправильную структуру запросов и неэффективную семантику анализа. При работе с дизайнером SSAS в Business Intelligence Design Studio (BIDS) архитектор получает всеобъемлющий набор инструментов проектирования и оптимизации многомерных хранилищ и формирования запросов к этим хранилищам (рис. 2).


Рис. 2. Дизайнер SSAS — моделирование многомерных данных в BIDS

Ниже перечислены некоторые ключевые принципы DW, которые необходимо помнить при проектировании многомерных моделей, чтобы в дальнейшем добиться максимальной производительности (более полную информацию по этому вопросу и тонкостям проектирования в SSAS можно найти по ссылкам https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspx и http://www.ssasinfo.com/analysis-services-papers/1216-sql-server-2008-white-paper-analysisservices-performance-guide).

  1. Подавляющее большинство MOLAP-данных будет добавляться в таблицы фактов
    Ограничьте количество мер в таблице фактов, поскольку обработка запросов наиболее эффективна, когда таблицы имеют небольшое количество полей. Увеличьте глубину атрибутов во вспомогательных таблицах измерений. Преимущества подхода, в котором таблицы измерений по возможности разбиваются на более детализированные таблицы субизмерений (шаблон «снежинка») - предмет горячих обсуждений, хотя такой подход обычно обеспечивает большую гибкость, когда рассматриваются модели горизонтального масштабирования и применение индексов и таких технологий повышения производительности, как разбиение таблиц на части (partitioning).
  2. Реализуйте суррогатные ключи для поддержания ключевых отношений между таблицами фактов и измерений вместо введения ограничений внешнего ключа, которые часто объявляют как составные ключи, содержащие несколько полей. Суррогатный ключ - целое IDENTITY-поле, которое служит искусственным первичным ключом таблицы измерений. Такой подход уменьшает требования к хранению и издержки на хранение/обработку при поддержании индексов.
  3. Хотя OLTP-хранилища, как правило, имеют высокую степень нормализации, в случае многомерных хранилищ это гораздо менее важно. Денормализованные данные имеют определенные преимущества в случае чрезвычайно больших хранилищ, позволяя уменьшить количество соединений (joins) при выполнении запросов. Кроме того, в таких СУБД, как SQL Server 2008, применяется фильтрация битовых карт с высокой степенью оптимизации (так называемый «фильтр Блума»), исключающая множество избыточных и не относящихся к делу данных из обработки запросов с соединениями типа «звезда».
  4. Прототипы, прототипы, прототипы
    Ваша физическая архитектура может поначалу отлично работать, справляясь с построением статических отчетов. Однако по мере того, как пользователи привыкают к тому, что им доступны новые данные, и становятся опытнее, вы должны будете обеспечить поддержку значительного количества произвольных запросов. Произвольные запросы могут создавать быстро растущие наборы данных - объем данных определяется структурой модели хронологических данных, реализованной в ваших измерениях. Большинство серверов баз данных поддерживает разбиение на части при тестировании/моделировании. При проектировании поддержки произвольных запросов уделите максимум времени изучению ее влияния на вашу среду (в том числе на индексирование и обслуживание). Развернув BI-продукты, позволяющие осуществлять самообслуживание (скажем, PowerPivot), вместо поддержки выполнения произвольных запросов напрямую, вы значительно уменьшите объем запрашиваемых у сервера данных, передавая крупные порции многомерных данных прямо на клиент, где пользователь без усилий сможет манипулировать ими, осуществляя их углубленный анализ.
  5. Реализуйте кластерные индексы для суррогатных ключей наиболее часто используемых таблиц фактов и некластерные индексы для каждого из оставшихся суррогатных ключей. Как говорилось выше в п. 4, добавление поддержки произвольных запросов может существенно повлиять на стратегию индексирования, однако то, что такая стратегия в целом эффективна при применении шаблонов общего пользования - доказанный факт.
  6. Применяйте параллельную обработу таблиц, разбитых на части
    Поскольку таблицы фактов растут со временем, большинство архитекторов DW реализует стратегии разбиения на части, распределяя таблицу фактов между несколькими физическими устройствами хранения. Чаще всего для разбиения используют поле, содержащее даты, но можно задать диапазоны, основанные на шаблонах использования (такая возможность поддерживается SQL Server 2008). В SQL Server 2008 реализована новая функция - PTP (partitionedtable parallelism). Она обеспечивает высокую степень оптимизации запросов к разбитым на части таблицам за счет параллельного выполнения этих запросов на всех доступных многоядерных процессорах. Более подробную информацию о PTP и других усовершенствованиях DW в SQL Server 2008 см. по ссылке https://technet.microsoft.com/en-us/library/cc278097.aspx.
  7. Реализуйте стратегию сжатия
    Современем хранилища данных становятся огромными. Издержки сжатия часто компенсируются сокращением избыточных данных и, следовательно, уменьшением времени выполнения запросов, а также, поскольку размер хранилища уменьшается, большим удобством обслуживания. Однако наиболее распространена стратегия, основанная на сжатии данных, используемых реже всего. Сжатие можно обеспечивать многими способами, в том числе на уровне разделов (par ti tions), страниц, записей и т. д. Как и в п. 4, для получения наиболее эффективного шаблона потребуется построение многочисленных прототипов модели.

Консолидация, агрегирование и заполнение хранилищ

К счастью, после того как вы определили, к каким данным обращаться и спроектировали топологию своего хранилища данных, агрегирование и заполнение становятся более простой задачей благодаря усовершенствованиям инструментальных средств. Работая с такими средствами, как SSIS в BIDS (входит в SQL Server Enterprise Edition), архитектор может создать «пакет», который может получать и очищать данные, манипулировать ими и публиковать их. В SSIS имеются коннекторы для данных, позволяющие архитектору разрабатывать пакеты, обращающиеся ко всем основным платформам баз данных (в том числе Oracle, IBM, Teradata и др.). Кроме того, в SSIS реализован исчерпывающий набор функций манипулирования данными, к которым обеспечивается удобный доступ в окне инструментария: с ними можно работать в визуальной модели потока данных, используя операцию «drag-and-drop» (рис. 3).


Рис. 3. Представление потока данных SSIS в BIDS

SSIS позволяет создавать очень сложные пакеты. В частности, поддерживаются прохождение набора результатов, сравнение данных из нескольких источников, вложенные операции, позволяющие выполнять определенную последовательность действий или применять правила корректировки/повтора, когда не удается получить данные (например, если удаленный сервер в Центральной Америке остановлен на обслуживание), сложные преобразования данных.

Хотя SSIS можно сравнить с традиционными ETL-средствами (extract, transform, load), SSIS предлагает гораздо более широкий набор функций, позволяющих дополнить динамическую MOLAP-среду хранилищем данных, реализованным на основе SQL Server 2008 и Analysis Services (например, в DW можно внедрить сложные SSIS-пакеты, которые будут вызываться хранимыми процедурами динамически и выполнять операции, определяемые данными, получаемыми от механизма Analysis Service). Многие независимые поставщики ПО, сотрудничающие с Microsoft, даже разработали сложные стратегии выполнения SSIS-пакетов, которые вызываются операциями Windows Workf low Foundation (WF). Благодаря этому появляются дополнительные возможности управления агрегированием данных, когда есть сильная зависимость от состояния или когда операция выполняется в течение длительного времени. Более подробный обзор SSIS см. по ссылке https://download.microsoft.com/download/a/c/d/acd8e043-d69b-4f09-bc9e-4168b65aaa71/ssis2008Intro.doc.

Данные с высокой степенью распределения, сбор региональной информации, витрины данных для мобильных пользователей,произвольные запросы и синхронизация данных

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

Ключ к успеху -- использовать эффективную репликацию моментальных снимков заранее определенных агрегированных поднаборов данных, доступных только для чтения. Это означает, что требуется тщательный анализ требований каждого независимого регионального подразделения и использование продвинутых функций серверов баз данных, такие как сжатие больших объемов данных и объявление полей с атрибутом SPARSE. SPARSE (разреженный) - новый атрибут поля, доступный в SQL Server 2008. Он означает, что значения null вообще не занимают места при хранении. Поскольку хранилища данных обычно содержат огромное количество полей со значениями null (ведь не бывает так, что каждый день в каждом магазине каждого региона покупают каждую пару обуви), сжатие и хранение значений null, при котором не расходуется физическое пространство, становятся обязательными. Во многих традиционных продуктах для хранения данных эти возможности не реализованы, тогда как SQL Server 2008 дает многочисленные преимущества в про изводительности при репликации больших объемов многомерных данных.

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

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

Но как быть с продвинутыми пользователями, работающими на мобильных устройствах и занимающимися бизнесанализом в автономном режиме? С помощью платформы Microsoft можно предоставить мощные возможности BI даже в отсоединенном режиме, используя на клиенте SQL Server CE или Express
Edition. Microsoft сотрудничает с десятками глобальных независимых поставщиков ПО, которые создали пакеты приложений, работающие с большими многомерными кубами данных на клиенте, в отсоединенном режиме. Можно разработать стратегии репликации данных в базу данных на стороне клиента,
выполняемой, когда пользователь мобильного устройства подсоединен к сети, или создать приложения, в которых используется Synchronization Services for ADO.NET, и управлять репликацией данных в соответствии с требованиями, специфичными для рабочего процесса приложений. Дополнительную информацию см. по ссылке https://msdn.microsoft.com/en-us/sync/default.aspx.

Заключение

Чтобы приступить к реализации BI-решений на вашем предприятии, прежде всего потребуются большие затраты на тщательное изучение корпоративных данных, которые вам доступны. Как показала практика, когда требуется запрашивать крайне большие объемы данных, которые скорее всего содержат хронологическую справочную информацию (изменение данных с течением времени), наиболее эффективной стратегией является применение моделей многомерного хранения данных, таких как проектировочные шаблоны хранилищ данных (MOLAP и др.). Подробное описание того, как реализовывать DW- и BI-решения на основе SQL Server 2008, см. по ссылке https://www.microsoft.com/sqlserver/2008/en/us/white-papers.aspx. Кроме того, можно ознакомиться с передовым опытом практической реализации горизонтального масштабирования, посетив сайт http://sqlcat.com/.

Ресурсы по данной тематике