Orígenes de datos admitidos en Azure Analysis Services

Los orígenes de datos y los conectores que se muestran en el Asistente para obtener datos o importar tablas en Visual Studio con proyectos de Analysis Services se muestran para Azure Analysis Services y SQL Server Analysis Services. Sin embargo, no todos los orígenes de datos y conectores mostrados se admiten en Azure Analysis Services. Los tipos de orígenes de datos a los que puede conectarse dependen de muchos factores, como el nivel de compatibilidad del modelo, los conectores de datos disponibles, el tipo de autenticación y la compatibilidad con la puerta de enlace de datos local. En las tablas siguientes se describen los orígenes de datos admitidos para Azure Analysis Services.

Orígenes de datos de Azure

Origen de datos En memoria Consulta Directa Notas
Azure SQL Database Sí Sí 2, 3
Azure Synapse Analytics (SQL DW) Sí Sí 2
Base de datos SQL Fabric Sí Sí 2
Fabric punto de conexión de análisis de SQL Sí Sí 2
Azure Blob Storage (Servicio de almacenamiento de blobs de Azure) Sí No 1
Azure Table Storage Sí No 1
Azure Cosmos DB (la base de datos de Azure Cosmos) Sí No 1
Azure Data Lake Store Gen1 Sí No 1
Azure Data Lake Store Gen2 Sí No 1, 5
Azure HDInsight HDFS Sí No 1
Azure HDInsight Spark Sí No 1, 4

Nota:

1 - Solo modelos Tabular 1400 y superiores.
2 - Cuando se especifica como origen de datos de proveedor en modelos tabulares 1200 y superiores, tanto los modelos en memoria como los modelos DirectQuery requieren Microsoft OLE DB Driver for SQL Server MSOLEDBSQL (recomendado) o proveedor de datos de .NET Framework para SQL Server.
3 : Se admite Azure SQL Managed Instance. Dado que SQL Managed Instance se ejecuta dentro de la red virtual de Azure con una dirección IP privada, el punto de conexión público debe estar habilitado en la instancia. Si no está habilitada, se requiere una puerta de enlace de datos local .
4 : Actualmente no se admite Azure Databricks mediante el conector de Spark.
5 : actualmente no se admite el conector de ADLS Gen2; sin embargo, el conector de Azure Blob Storage se puede usar con un origen de datos de ADLS Gen2.

Otros orígenes de datos

La conexión a orígenes de datos locales desde un servidor de Azure Analysis Services requiere una puerta de enlace local. Cuando se usa una puerta de enlace, se requieren proveedores de 64 bits.

Origen de datos En memoria Consulta Directa Notas
Base de datos de Access Sí No
Active Directory Sí No 6
Servicios de Análisis Sí No
Sistema de la plataforma de análisis Sí No
Archivo CSV Sí No
Dynamics 365 Sí No 6, 12
Libro de Excel Sí No
Intercambio Sí No 6
Carpeta Sí No 6
IBM Informix Sí No
Documento JSON Sí No 6
Líneas de archivo binario Sí No 6
Base de datos de MySQL Sí No 13
Fuente de OData Sí No 6
Consulta ODBC Sí No
OLE DB Sí No
Oráculo Sí Sí 9
Base de datos PostgreSQL Sí No 6
Objetos de Salesforce Sí No 6
Informes de Salesforce Sí No 6
SAP HANA Sí No
SAP Business Warehouse Sí No 6
Lista de SharePoint Sí No 6, 11
SQL Server Sí Sí 7, 8
SQL Server Data Warehouse Sí Sí 7, 8
Base de datos de Sybase Sí No
Teradatos Sí Sí 10
archivo TXT Sí No
Tabla XML Sí No 6

Nota:

6 - Solo modelos Tabular 1400 y superiores. 7 : cuando se especifica como origen de datos de proveedor en modelos tabulares 1200 y superiores, especifique Microsoft OLE DB Driver for SQL Server MSOLEDBSQL (recomendado), SQL Server Native Client 11.0 o proveedor de datos de .NET Framework para SQL Server.
8 - Si se especifica MSOLEDBSQL como proveedor de datos, puede ser necesario descargar e instalar Microsoft OLE DB Driver for SQL Server en el mismo equipo que la puerta de enlace de datos local.
9 - Para los modelos tabulares 1200, o como un proveedor de origen de datos en modelos tabulares 1400+, especifique el Oracle Proveedor de datos para .NET. Si se especifica como origen de datos estructurado, asegúrese de habilitar el proveedor administrado de Oracle. 10 - Para los modelos Tabular 1200, o como fuente de datos de proveedor en modelos Tabular 1400 y superiores, especifica Teradata Proveedor de datos para .NET.
11 - No se admiten los archivos de SharePoint local.
12 : Azure Analysis Services no admite conexiones directas al punto de conexión de TDS de Dynamics 365 Dataverse. Al conectarse a este origen de datos desde Azure Analysis Services, debe usar una puerta de enlace de datos local y actualizar los tokens manualmente.
13 : Azure Analysis Services no admite conexiones directas a bases de datos MySQL. Al conectarse a este origen de datos desde Azure Analysis Services, debe usar una puerta de enlace de datos local y actualizar los tokens manualmente.

Descripción de los proveedores

Al crear proyectos de modelo tabulares 1400 y posteriores en Visual Studio, de forma predeterminada no se especifica un proveedor de datos al conectarse a un origen de datos mediante Obtener datos. Los modelos tabulares 1400 y superiores usan conectores de Power Query para administrar conexiones, consultas de datos y mashups entre el origen de datos y Analysis Services. A veces se hace referencia a ellos como conexiones de origen de datos estructuradas en los que la configuración de las propiedades de conexión se establece automáticamente. Sin embargo, puede habilitar orígenes de datos heredados para un proyecto de modelo en Visual Studio. Cuando se habilita, puede usar el Asistente para importación de tablas para conectarse a determinados orígenes de datos que tradicionalmente se admiten en modelos tabulares 1200 y inferiores como orígenes de datos heredados o de proveedor . Cuando se especifica como origen de datos de proveedor, puede especificar un proveedor de datos determinado y otras propiedades de conexión avanzadas. Por ejemplo, puede conectarse a una instancia de SQL Server Data Warehouse o incluso a una instancia de Azure SQL Database como origen de datos heredado. Después, puede seleccionar el proveedor de datos MSOLEDBSQL de OLE DB Driver for SQL Server. En este caso, seleccionar un proveedor de datos OLE DB puede proporcionar un rendimiento mejorado en el conector de Power Query.

Al usar el Asistente para importación de tablas en Visual Studio, las conexiones a cualquier origen de datos requieren un proveedor de datos. Se selecciona un proveedor de datos predeterminado. Si es necesario, puede cambiar el proveedor de datos. El tipo de proveedor que elija puede depender del rendimiento, tanto si el modelo usa almacenamiento en memoria como DirectQuery, y en qué plataforma de Analysis Services se implementa el modelo.

Especificar orígenes de datos del proveedor en proyectos de modelos tabulares 1400 y posteriores

Para habilitar los orígenes de datos del proveedor, en Visual Studio, haga clic en Herramientas>Opciones>Analysis Services Tabular>Importación de datos y seleccione Habilitar orígenes de datos heredados.

Captura de pantalla de Habilitar fuentes de datos heredadas.

Con los orígenes de datos heredados habilitados, en el Explorador de Modelos Tabulares, haga clic con el botón derecho en Orígenes de datos>Importar desde el origen de datos (heredado).

Captura de pantalla de orígenes de datos heredados en el Explorador de modelos tabulares.

Al igual que con los proyectos de modelo tabulares 1200, use el Asistente para importación de tablas para conectarse a un origen de datos. En la página de conexión, haga clic en Avanzado. Especifique el proveedor de datos y otras opciones de conexión en Establecer propiedades avanzadas.

Captura de pantalla de las propiedades avanzadas de orígenes de datos heredados.

Suplantación

En algunos casos, puede ser necesario especificar una cuenta de suplantación diferente. La cuenta de suplantación se puede especificar en Visual Studio o SQL Server Management Studio (SSMS).

Para orígenes de datos locales:

  • Si se utiliza la autenticación de SQL, la suplantación debe ser la Cuenta de servicio.
  • Si usa la autenticación de Windows, establezca Usuario y contraseña de Windows. Para SQL Server, la autenticación de Windows con una cuenta de suplantación específica solo se admite para los modelos de datos en memoria.

Para orígenes de datos en la nube:

  • Si se utiliza la autenticación de SQL, la suplantación debe ser la Cuenta de servicio.

Credenciales de OAuth

Para los modelos tabulares en el nivel de compatibilidad 1400 y superior mediante el modo en memoria, Azure SQL Database, Azure Synapse, Fabric SQL analytics endpoint, Fabric SQL database, Dynamics 365 y SharePoint List admiten credenciales de OAuth. Para generar tokens válidos, establezca las credenciales mediante Power Query. Azure Analysis Services gestiona la renovación de tokens para orígenes de datos de OAuth, con el objetivo de evitar los tiempos de espera en operaciones de actualización prolongadas.

Nota:

No se admite la actualización de tokens administrados para orígenes de datos a los que se accede a través de una puerta de enlace. Por ejemplo, se obtiene acceso a uno o varios orígenes de datos de consulta mashup a través de una puerta de enlace y/o la propiedad ASPaaS\AlwaysUseGateway está configurada en true.

El modo Direct Query no se admite con las credenciales de OAuth.

Habilitación del proveedor administrado de Oracle

En algunos casos, las consultas DAX en un origen de datos de Oracle pueden devolver resultados inesperados. Esto puede deberse al proveedor que se usa para la conexión del origen de datos.

Como se describe en la sección Descripción de los proveedores , los modelos tabulares se conectan a orígenes de datos como un origen de datos estructurado o un origen de datos de proveedor . En el caso de los modelos con un origen de datos de Oracle especificado como origen de datos de proveedor, asegúrese de que el proveedor especificado sea Proveedor de datos de Oracle para .NET (Oracle.DataAccess.Client).

Si el origen de datos de Oracle se especifica como origen de datos estructurado, habilite la propiedad de servidor MDataEngine\UseManagedOracleProvider . Establecer esta propiedad garantiza que el modelo se conecte al origen de datos de Oracle mediante el proveedor de datos de Oracle recomendado para el proveedor administrado de .NET.

Para habilitar el proveedor administrado de Oracle:

  1. En SQL Server Management Studio, conéctese al servidor.

  2. Cree una consulta XMLA con el siguiente script. Reemplace ServerName por el nombre completo del servidor y, a continuación, ejecute la consulta.

    <Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
        <Object />
        <ObjectDefinition>
            <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" 
    xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" 
    xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" 
    xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
                <ID>ServerName</ID>
                <Name>ServerName</Name>
                <ServerProperties>
                    <ServerProperty>
                        <Name>MDataEngine\UseManagedOracleProvider</Name>
                        <Value>1</Value>
                    </ServerProperty>
                </ServerProperties>
            </Server>
        </ObjectDefinition>
    </Alter>
    
  3. Reinicie el servidor.

Pasos siguientes