Советы по успешному внедрению LuckyTemplates

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

Оглавление

• Дизайн набора данных для реализации проекта LuckyTemplates
  • 4 шага к дизайну набора данных
  • Выберите бизнес-процесс.
    • Анти-шаблон, которого следует избегать при реализации LuckyTemplates
  • Заявить зерно.
  • Определите размеры.
  • Дайте определение фактам.
• Матрица шины данных для реализации проекта LuckyTemplates
• Профилирование данных для реализации LuckyTemplates
  • Службы интеграции SQL Server
  • Студия DAX
  • Рабочий стол LuckyTemplates
• Планирование набора данных для внедрения LuckyTemplates
  • Выбор режима набора данных
  • Некоторые вопросы, которые следует задать при выборе режимов набора данных
• Заключение

Дизайн набора данных для реализации проекта LuckyTemplates

Давайте поговорим о процессе проектирования набора данных и обсудим матрицу шины хранилища данных — инструмент, который существует уже некоторое время.

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

4 шага к дизайну набора данных

Процесс разработки набора данных состоит из четырех шагов: выберите бизнес-процесс , объявите структуру ваших таблиц фактов, определите измерения и затем определите факты .

Выберите бизнес-процесс.

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

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

Анти-шаблон, которого следует избегать при реализации LuckyTemplates

Распространенный анти-шаблон (который является реакцией на повторяющуюся проблему, которая, как правило, неэффективна и потенциально контрпродуктивна), которой следует избегать в проектах LuckyTemplates, — это разработка наборов данных для конкретных проектов или групп, а не для бизнес-процессов .

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

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

Хотя аналитические потребности пользователей или команд являются приоритетом проектов LuckyTemplates, также важно планировать устойчивые решения, которые в конечном итоге могут использоваться всеми группами.

Заявить зерно.

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

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

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

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

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

Определите размеры.

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

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

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

Дайте определение фактам.

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

Матрица шины данных для реализации проекта LuckyTemplates

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

Архитектура, которую вы видите здесь, взята из The Data Warehouse Toolkit , 3-е издание Ральфа Кимбалла. Это позволяет использовать масштабируемые модели данных, которые часто требуются нескольким бизнес-группам или функциям для доступа к одним и тем же бизнес-процессам и измерениям.

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

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

Профилирование данных для реализации LuckyTemplates

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

Технические метаданные, включая диаграммы баз данных и результаты профилирования данных, необходимы на этапе планирования проекта.

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

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

Службы интеграции SQL Server

Есть несколько способов сделать это. Одним из способов является использование задачи профилирования данных в пакете служб SQL Server Integration Services (SSIS).

Задача профилирования данных требует подключения ADO.NET и может записывать свои выходные данные в XML-файл или переменную SSIS.

В этом примере исходные данные ADO.NET — это хранилище данных AdventureWorks, база данных и сервер SQL, а назначение — XML-файл.

Таким образом, после выполнения задачи XML-файл можно прочитать с помощью средства просмотра профиля данных SQL Server. Вы можете увидеть результаты с точки зрения количества нулей и процентного содержания нулей.

Студия DAX

Другой способ профилирования данных — через DAX Studio. вам нужно фактически загрузить данные в набор данных LuckyTemplates, перейдя в DAX Studio, перейдите на вкладку «Дополнительно» и запустите VertiPaq Analyzer .

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

Рабочий стол LuckyTemplates

профилирование данных также доступно в power query в LuckyTemplates Desktop. если вы перейдете на вкладку «Вид» , вы сможете включить такие параметры, как качество столбца, его распределение и профиль столбца. По крайней мере, для первой тысячи строк или около того вы можете увидеть такую ​​информацию, как ошибки, нули, средние значения и стандартные отклонения.

Планирование набора данных для внедрения LuckyTemplates

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

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

Этап планирования набора данных определяет, как решаются выявленные проблемы преобразования данных для поддержки набора данных. Кроме того, команда проекта должна определить, следует ли разрабатывать набор данных режима импорта , набор данных прямого запроса или составной набор данных .

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

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

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

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

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

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

Выбор режима набора данных

Следующим, но тесно связанным с планированием набора данных шагом является выбор между режимом импорта по умолчанию, режимом DirectQuery/live или составным режимом.

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

Таким образом, если источник данных считается медленным или плохо оборудованным для обработки большого объема аналитических запросов, то набор данных в режиме импорта, скорее всего, будет предпочтительным вариантом.

Аналогичным образом, если необходима видимость источника данных в режиме, близком к реальному времени, то DirectQuery или режим реального времени — единственный вариант для достижения этой цели. режимы DirectQuery и Live очень похожи друг на друга. Оба метода не хранят данные в самом наборе данных, и оба запрашивают исходные системы напрямую для извлечения данных на основе действий пользователя. Теперь у нас есть наборы данных DirectQuery для LuckyTemplates и DirectQuery для служб Analysis Services.

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

Вот несколько вопросов, которые следует задать при принятии решения о том, какой режим использовать. есть ли единый источник для нашего набора данных? Если нет единого источника, вы не могли использовать источник DirectQuery/Live в прошлом.

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

Если доступен источник DirectQuery/Live, может ли источник поддерживать аналитические запросы? Если вы работаете с миллиардами или триллионами строк, возможно, набор данных в режиме импорта невозможен, и вам придется перейти в режим DirectQuery или композитный режим, чтобы убедиться, что набор данных можно использовать.

Если источник DirectQuery/Live способен поддерживать рабочую нагрузку, является ли подключение DirectQuery/Live более ценным, чем производительность и гибкость, обеспечиваемые моделью импорта?

Заключение

Этот пост завершает серию статей о планировании проектов LuckyTemplates. я думаю, что это основные шаги для каждого проекта LuckyTemplates, над которым вы работаете. Эти шаги важны при комплексной проверке, особенно в условиях корпоративной бизнес-аналитики.

Всего наилучшего,

Грег Деклер