Режим DirectQuery (табличные службы SSAS)
Службы Analysis Services позволяют получать данные и создавать отчеты из табличной модели путем получения данных и агрегатов напрямую из системы реляционных баз данных, используя режим DirectQuery. В этом разделе объясняются отличия между стандартными табличными моделями, которые находятся только в памяти, и табличными моделями, которые могут отправлять запросы к реляционному источнику данных, а также способы создания и развертывания модели для использования в режиме DirectQuery.
Разделы данной темы:
Преимущества режима DirectQuery
По умолчанию табличные модели используют кэш в памяти для хранения данных и отправки запросов к данным. Поскольку табличные модели используют данные, находящиеся в памяти, даже сложные запросы могут выполняться очень быстро. Однако есть некоторые недостатки использования кэшированных данных.
Данные не обновляются при изменении исходных данных. Необходимо обработать модель для внедрения обновлений в данные.
При отключении компьютера, на котором располагается модель, кэш сохраняется на диск, поэтому после загрузки модели или открытия файла PowerPivot кэш нужно открыть заново. Операции сохранения и загрузки могут занимать много времени.
В противоположность этому режим DirectQuery использует данные, хранящиеся в базе данных SQL Server. Обычно при проектировании модели в кэш импортируются все данные или их небольшая часть. При развертывании модели пользователь должен указать, что источником данных для запросов к модели должен быть SQL Server, а не кэшированные данные. Все запросы DAX к данным претворяются службами Analysis Services в эквивалентные инструкции SQL для указанного реляционного источника данных.
У развертывания модели с использованием режима DirectQuery есть много преимуществ.
Для наборов данных, которые не помещаются в памяти на сервере служб Analysis Services, можно настроить модель.
Данные всегда будут обновленными, при этом нет необходимости хранить и поддерживать отдельную копию данных. Изменения данных базового источника могут быть сразу же отражены в запросах к модели данных.
DirectQuery может воспользоваться ускорением запросов на стороне поставщика, например за счет оптимизированных для памяти индексов столбцов xVelocity.
Безопасность, обеспечиваемая серверной базой данных, гарантирована на уровне строк. В противоположность этому при использовании кэшированных данных могут возникнуть трудности при обеспечении безопасности для кэша, сравнимой с безопасностью данных на сервере.
Если модель содержит сложные формулы, которым могут потребоваться несколько запросов, службы Analysis Services могут выполнять оптимизацию для того, чтобы план запроса к серверной базе данных был как можно более эффективным.
Создание моделей для использования в режиме DirectQuery
Табличные модели создаются с помощью конструктора моделей SQL Server Data Tools (SSDT). Конструктор моделей создает все модели в памяти. Это означает, что если во время моделирования объем данных оказывается слишком велик и они не помещаются в памяти, в кэш, используемый базой данных рабочей области, придется импортировать только подмножество данных.
Когда нужно переключиться в режим DirectQuery, достаточно изменить свойство, которое включает режим DirectQuery. Дополнительные сведения см. в разделе Включение режима конструктора DirectQuery (табличные службы SSAS).
Для этого конструктор моделей автоматически настраивает базу данных рабочей области для работы в гибридном режиме, который позволяет продолжить работу с кэшированными данными. Конструктор моделей также уведомит о функциях модели, несовместимых с режимом DirectQuery. В следующем списке перечислены основные требования, о которых следует помнить.
Источники данных. Модели DirectQuery могут использовать данные только одного источника данных SQL Server. Если для модели был включен режим DirectQuery, в конструкторе модели нельзя использовать другие типы данных, включая таблицы, добавленные путем копирования и вставки. Все остальные параметры импорта отключены. Включенные в запрос таблицы должны быть частью источника данных SQL Server. Дополнительные сведения можно узнать в разделе Data Sources for DirectQuery Models.
Поддержка вычисляемых столбцов. Вычисляемые столбцы для моделей DirectQuery не поддерживаются. Однако можно создавать меры и ключевые индикаторы производительности для работы с наборами данных. Дополнительные сведения см. в разделе, посвященном проверке .
Ограниченное использование DAX-функций. Некоторые DAX-функции не могут быть использованы в режиме DirectQuery, поэтому их необходимо заменить другими функциями или создать значения с использованием производных столбцов в источнике данных. Конструктор моделей во время разработки обеспечивает проверку ошибок, возникающих при создании формул, несовместимых с режимом DirectQuery. Дополнительные сведения см. в следующих разделах: Проверка.
Совместимость формул. В некоторых известных случаях одна и та же формула может возвращать разные результаты в кэшированной или гибридной модели по сравнению с моделью DirectQuery, которая использует только реляционное хранилище данных. Эти отличия являются следствием семантических отличий между подсистемой аналитики в памяти xVelocity (VertiPaq) и SQL Server. Дополнительные сведения об этих различиях см. в разделе: Совместимость формул.
Безопасность. В зависимости от способа развертывания модели используются различные методы обеспечения ее безопасности. Безопасность кэшированных данных для табличных моделей обеспечивается с помощью модели безопасности экземпляра служб Analysis Services. Безопасность моделей DirectQuery обеспечивается с помощью ролей, однако, помимо этого, можно использовать модель безопасности, определенную в реляционном хранилище данных. Модель может быть настроена таким образом, чтобы пользователи, открывающие отчет, созданный только на основе модели DirectQuery, видели только те данные, которые им разрешено видеть согласно разрешениям в SQL Server. Дополнительные сведения см. в разделе: Безопасность.
Клиентские ограничения. Когда модель используется в режиме DirectQuery, к ней можно обращаться только с помощью DAX-запросов. Многомерные выражения нельзя использовать для создания запросов. Это означает, что использовать клиент сводных таблиц и диаграмм Excel нельзя, поскольку в Excel используются многомерные выражения.
Однако вы можете создавать запросы к модели DirectQuery в SQL Server Management Studio если вы используете запрос таблицы DAX как часть инструкции ВЫПОЛНЕНИЯ XMLA. Дополнительные сведения см. в разделе [Справочник по синтаксису запросов DAX](/dax/dax-syntax-reference.
После разрешения всех вопросов проектирования и тестирования модели можно переходить к ее развертыванию. На данный момент пользователь может сам определить предпочтительный метод ответа на запросы к модели. Разрешить пользователям доступ к кэшу или всегда использовать только реляционный источник данных?
При развертывании модели в гибридном режимекэш по-прежнему доступен и может быть использован для запросов. Гибридный режим предоставляет множество вариантов.
Если доступны как кэш, так и реляционный источник данных, можно задать предпочтительный метод подключения, но в конечном счете именно клиент выбирает используемый источник с помощью свойства DirectQueryMode строки подключения.
Можно также настроить секции в кэше таким образом, чтобы первичная секция, используемая для режима DirectQuery, никогда не обрабатывалась и всегда ссылалась на реляционный источник. Есть много способов использования секций для оптимизации проектирования моделей и составления отчетов. Дополнительные сведения см. в разделе Секции и режим DirectQuery (табличные службы SSAS).
После развертывания модели можно изменить предпочтительный метод подключения. Например, можно использовать гибридную модель для тестирования и переключать модель в режим Только DirectQuery лишь после тщательного тестирования отчетов или запросов, использующих модель. Дополнительные сведения см. в разделе Установка или изменение предпочтительного метода подключения для DirectQuery.
Data Sources for DirectQuery Models
Сразу после включения в среде проектирования режима DirectQuery источники данных для базы данных рабочей области проверяются на предмет их происхождения от одного источника данных SQL Server. Данные из других источников, включая вставляемые из буфера обмена данные, в моделях DirectQuery запрещены.
Если планируется использовать модель в режиме DirectQuery, нужно, чтобы все данные для составления отчетов хранились в указанной базе данных SQL Server. Если данные, необходимые для моделирования, недоступны в указанном источнике, можно использовать службы Integration Services или другие средства хранения данных для импорта данных в базу данных SQL Server, которая служит источником данных DirectQuery.
Ограничения проверки и проектирования для режима DirectQuery
При создании модели для использования в режиме DirectQuery сначала необходимо загрузить в кэш некую часть данных. Если данные, которые вы в конечном итоге будете использовать, слишком велики для размещения в памяти, можно использовать параметр Предварительный просмотр & фильтр в мастере импорта таблиц, чтобы выбрать подмножество данных, или написать скрипт SQL для получения нужных данных.
Предупреждение
Поскольку режим DirectQuery не поддерживает использование вычисляемых столбцов, если есть столбцы, которые необходимо объединить или выполнить другие операции, это необходимо предусмотреть заранее и создать определение столбца при создании запроса импорта данных или скрипта.
Чтобы просмотреть и устранить ошибки проверки, откройте список ошибок в SQL Server Data Tools. Критические ошибки, препятствующие использованию режима DirectQuery, отображаются на вкладке Ошибки . Эти ошибки необходимо исправить перед переходом на режим DirectQuery. Ошибки проверки, которые трудно разрешить, обычно связаны с формулами, неподдерживаемыми в режиме DirectQuery. Обзор ошибок, связанных с формулами и вычисляемыми столбцами, см. в разделе Совместимость формул.
Ниже приводятся другие рекомендации, о которых следует помнить при создании модели для доступа в режиме DirectQuery.
В режиме Только DirectQuery результаты в отчете могут отличаться в зависимости от контекста безопасности пользователя, который просматривает результаты. Чтобы убедиться, чтобы пользователи получают необходимые результаты, следует протестировать модели с различными учетными данными.
Если настроить модель для работы в гибридном режиме, который позволяет использовать как кэш, так и данные из SQL Server, необходимо помнить о том, что клиенты, подключающиеся к разным источникам, могут видеть разные результаты в зависимости от режима, указанного в строке подключения. Если нужно, чтобы пользователи, просматривающие отчеты, видели только данные из SQL Server, необходимо очистить кэш или изменить модель на DirectQueryOnly.
Совместимость формул для моделей DirectQuery
Некоторые модели могут содержать формулы, которые не поддерживаются в режиме DirectQuery, поэтому для предотвращения ошибок проверки следует выполнить повторное проектирование модели. Существуют следующие ограничения для формул, поддерживаемых в режиме DirectQuery.
Вычисляемые столбцы не поддерживаются в табличных моделях со включенным режимом DirectQuery и в гибридных моделях. Если для модели требуются вычисляемые столбцы, попробуйте преобразовать их в производные столбцы путем использования Transact-SQL в определении импорта.
Модели DirectQuery не поддерживают использование DAX-формул в мерах, которые преобразуются в операции на основе наборов для реляционного хранилища данных. Поддерживаются все меры, создаваемые с помощью неявных мер.
Не все функции поддерживаются. Так как службы Analysis Services преобразуют все формулы DAX и определения мер в инструкции SQL при запросе модели DirectQuery, любая формула, содержащая элементы, которые не могут быть преобразованы в Transact-SQL, вызовет ошибки проверки в модели. Например, не поддерживаются функции логики операций со временем. Даже поддерживаемые функции, например статистические функции, могут вести себя по-другому. Полный список проблем совместимости см . в статье Совместимость формул в режиме DirectQuery.
Некоторые формулы в модели могут проходить проверку при переводе модели в режим DirectQuery, но при этом возвращать другие результаты при обращении к кэшу по сравнению с реляционным хранилищем данных. Это происходит, потому что вычисления для кэша используют семантику подсистемы аналитики в памяти xVelocity (VertiPaq), которая содержит многие функции, предназначенные для моделирования поведения Excel, в то время как запросы к данным, хранимым в реляционном хранилище данных, всегда используют семантику SQL Server. Список функций DAX, которые могут возвращать различные результаты при развертывании модели в режиме реального времени, см. в статье Совместимость формул в режиме DirectQuery.
Подключение к моделям DirectQuery
Клиенты, использующие для отчетов язык многомерных выражений, не могут подключаться к моделям, использующим режим DirectQuery. К примеру, если вы попытаетесь создать запрос многомерных выражений к модели DirectQuery, будет возвращена ошибка, сообщающая, что куб не найден или не обработан. Вы можете создавать запросы к моделям DirectQuery с помощью Power View, формул DAX или запросов XMLA. Дополнительные сведения о том, как выполнять нерегламентированные запросы к табличным моделям, см. в разделе Tabular Model Data Access.
Если используется гибридная модель, можно указать, будут ли пользователи подключаться к кэшу или использовать данные DirectQuery, установив свойство DirectQueryMode строки подключения.
Безопасность в режиме DirectQuery
В ходе создания модели необходимо указать разрешения, используемые для извлечения исходных данных. Часто это будут собственные учетные данные пользователя либо учетная запись, используемая для разработки. Однако при переключении модели в режим DirectQuery контекст безопасности становиться более сложным.
Необходимо определять, имеют ли пользователи необходимый уровень доступа к данным в реляционном хранилище данных.
Пользователи, которые просматривают одну и ту же модель или отчет, могут видеть разные данные в зависимости от контекста безопасности пользователя.
Если кэш модели сохранен, он защищен с помощью модели безопасности служб Analysis Services (ролей). Кэш может содержать данные, которые имеют право видеть разработчики моделей, но не пользователи. Конструкторы моделей и отчетов должны очищать кэш либо обеспечивать безопасность данных путем контроля доступа с помощью ролей.
Модель, отвечающая на запросы из кэша, не может олицетворять текущего пользователя при подключении к источнику данных. Если нужно олицетворять текущего пользователя при подключении к источнику данных, следует использовать режим DirectQuery.
Если для модели отчета требуется безопасность, у вас есть два варианта: можно использовать роли служб Analysis Services или задать разрешения на уровне строк для источника данных. Безопасность в реляционном источнике данных используется для управления доступом к таблицам, при этом безопасность уровня столбцов не поддерживается. Таким образом, если пользователи одного региона не имеют разрешения просматривать результаты продаж из других регионов, отчет, который включает меру на основе таблицы «Продажи», будет возвращать пустые ячейки или ошибку.
Свойство параметров олицетворения указывает учетные данные, используемые для подключения к модели с помощью DirectQuery, для модели DirectQuery или для гибридной модели, отвечающей на запросы с помощью DirectQuery. Свойство может принимать следующие значения.
Default
Использует учетные данные, заданные в мастере импорта для подключения к источнику данных. Это может быть определенный пользователь Windows или учетная запись службы.
ImpersonateCurrentUser
Использует для подключения к источнику данных учетные данные текущего пользователя.
Сведения о том, как задать эти свойства, см. в разделе Сценарии развертывания DirectQuery (табличные службы SSAS).
Свойства DirectQuery
В следующей таблице перечислены свойства, которые можно задать в SQL Server Data Tools и в SQL Server Management Studio, чтобы включить DirectQuery и управлять источником данных, используемым для запросов к модели.
| Имя свойства | Описание |
|---|---|
| Свойство DirectQueryMode | Это свойство позволяет использовать режим DirectQuery в конструкторе моделей. Чтобы изменить другие свойства DirectQuery, этому свойству следует задать значение On.Дополнительные сведения см. в разделе Включение режима конструктора DirectQuery (табличные службы SSAS). |
| Свойство QueryMode | Это свойство указывает метод отправки запросов по умолчанию для модели DirectQuery. Свойство задается в конструкторе моделей при развертывании модели, однако позже его можно изменить. Свойство может принимать следующие значения. DirectQuery — этот параметр указывает, что все запросы к модели должны использовать только реляционный источник данных. DirectQuery и в памяти . Указывает, что по умолчанию запросы должны получать ответ из реляционного источника, если иное не указано в строке подключения клиента. В памяти — этот параметр указывает, что на запросы следует отвечать только с помощью кэша. В памяти с DirectQuery . Этот параметр указывает, что по умолчанию запросы должны получать ответ из кэша, если иное не указано в строке подключения клиента. Дополнительные сведения см. в разделе Установка или изменение предпочтительного метода подключения для DirectQuery. |
| Свойство DirectQueryMode | После развертывания модели можно изменить предпочтительный источник данных запроса для модели DirectQuery, изменив это свойство в SQL Server Management Studio Как и в случае с предыдущим свойством, это свойство указывает источник данных по умолчанию для модели и может принимать следующие значения. InMemory. Запросы могут использовать только кэш. DirectQuerywithInMemory. По умолчанию запросы используют реляционный источник данных, если иное не указано в строке подключения клиента. InMemorywithDirectQuery. По умолчанию запросы используют кэш, если иное не указано в строке подключения клиента. (DirectQuery. Запросы используют только реляционный источник данных. Дополнительные сведения см. в разделе Установка или изменение предпочтительного метода подключения для DirectQuery. |
| Свойство «Параметры олицетворения» | Это свойство определяет учетные данные, используемые для подключения к источнику данных SQL Server во время отправки запроса. Это свойство можно задать в конструкторе моделей и изменить его позже после развертывания модели. Обратите внимание, что эти учетные данные используются только для ответа на запросы к реляционному хранилищу данных. Они отличаются от учетных данных, используемых для обработки кэша гибридной модели. Олицетворение не может использоваться, когда модель находится только в памяти. Параметр ImpersonateCurrentUser недействителен, если модель не использует режим DirectQuery. |
Помимо этого, если модель включает секции, следует выбрать одну секцию для использования в качестве источника для запросов в режиме DirectQuery. Дополнительные сведения см. в разделе Секции и режим DirectQuery (табличные службы SSAS).
Связанные темы и задачи
| Раздел | Описание |
|---|---|
| Секции и режим DirectQuery (табличные службы SSAS) | Описывает, как секции используются в моделях, настроенных для режима DirectQuery. |
| Совместимость формул в режиме DirectQuery | Описывает ограничения и требования совместимости для формул, которые используются в моделях, настроенных для режима DirectQuery. |
| Включить режим разработки DirectQuery (табличные службы SSAS) | Описывает, как можно изменить среду времени разработки так, чтобы она поддерживала использование режима DirectQuery. |
| Изменение секции DirectQuery (табличные службы SSAS) | Описывает, как изменить секцию DirectQuery. |
| Установка или изменение предпочтительного метода подключения для DirectQuery | Описывает, как задать или изменить метод соединения для моделей, настроенных для DirectQuery. |
| Сценарии развертывания DirectQuery (табличные службы SSAS) | Описывает сценарии развертывания DirectQuery. |
| Настройка доступа в памяти или доступа DirectQuery для базы данных табличной модели | Обзор конфигураций DirectQuery |
| Очистка кэша служб Analysis Services | Очистите кэш табличной модели |
См. также:
Секции (табличные службы SSAS)
Проекты табличной модели (табличные службы SSAS)
Анализ в Excel (табличные службы SSAS)