Orígenes de datos admitidos en Azure Analysis Services
Los orígenes de datos y los conectores que se muestran en Obtener datos o en el Asistente para la importación de tablas de Visual Studio con los proyectos de Analysis Services corresponden tanto a Azure Analysis Services como a SQL Server Analysis Services. Sin embargo, no todos los orígenes de datos y los conectores que aparecen son compatibles con Azure Analysis Services. Los tipos de orígenes de datos con los que se puede establecer conexión 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 que admite Azure Analysis Services.
Orígenes de datos de Azure
| Origen de datos | En memoria | DirectQuery | Notas |
|---|---|---|---|
| Azure SQL Database | Sí | Sí | 2, 3 |
| Azure Synapse Analytics (SQL DW) | Sí | Sí | 2 |
| Azure Blob Storage | Sí | No | 1 |
| Azure Table Storage | Sí | No | 1 |
| Azure Cosmos DB | 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 |
Notas:
1: Tabular 1400 y modelos posteriores solamente.
2: Cuando se especifica como un origen de datos de proveedor en los modelos tabulares 1200 y posteriores, los modelos en memoria y de DirectQuery requieren Microsoft OLE DB Driver for SQL Server MSOLEDBSQL (recomendado) o Proveedor de datos .NET Framework para SQL Server.
3: Compatible con Instancia administrada de Azure SQL. Dado que SQL Managed Instance se ejecuta dentro de una 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á habilitado, se requiere una puerta de enlace de datos local.
4: Actualmente no se admite Azure Databricks con el conector de Spark.
5: el conector ADLS Gen2 no se admite actualmente; no obstante, se puede usar el conector de Azure Blob Storage con un origen de datos ADLS Gen2.
Otros orígenes de datos
Para conectarse a los orígenes de datos locales desde un servidor de Azure Analysis Services, se necesita una puerta de enlace local. Cuando se usa una puerta de enlace, se requieren proveedores de 64 bits.
| Origen de datos | En memoria | DirectQuery | Notas |
|---|---|---|---|
| Base de datos de Access | Sí | No | |
| Active Directory | Sí | No | 6 |
| Analysis Services | 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 | |
| Exchange | 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 OData | Sí | No | 6 |
| Consulta ODBC | Sí | No | |
| OLE DB | Sí | No | |
| Oracle | Sí | Sí | 9 |
| Base de datos de 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 |
| Almacenamiento de datos de SQL Server | Sí | Sí | 7, 8 |
| Base de datos de Sybase | Sí | No | |
| Teradata | Sí | Sí | 10 |
| Archivo TXT | Sí | No | |
| Tabla XML | Sí | No | 6 |
Notas:
6: Tabular 1400 y modelos posteriores solamente.
7: Cuando se especifica como un origen de datos de proveedor en los modelos tabulares 1200 y posteriores, especifique Microsoft OLE DB Driver for SQL Server MSOLEDBSQL (recomendado), SQL Server Native Client 11.0 o Proveedor de datos .NET Framework para SQL Server.
8: Si especifica MSOLEDBSQL como proveedor de datos, puede que sea 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 origen de datos de proveedor en los modelos tabulares 1400 o posteriores, especifique el proveedor de datos de Oracle para .NET. Si se especifica como un origen de datos estructurado, no olvide habilitar el proveedor administrado de Oracle.
10: Para los modelos tabulares 1200, o como origen de datos de proveedor en los modelos tabulares 1400 o posteriores, especifique el proveedor de datos de Teradata para .NET.
11: no se admiten archivos en SharePoint en el entorno local.
12: Azure Analysis Services no admite conexiones directas con el punto de conexión TDS de Dataverse de Dynamics 365. 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 tabular 1400 y superiores en Visual Studio, de forma predeterminada no especifica un proveedor de datos al conectarse a un origen de datos mediante Obtener datos. Los modelos tabulares 1400 y posteriores 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 está habilitado, puede usar el Asistente de importación de tablas para conectarse a ciertas fuentes de datos tradicionalmente admitidas en modelos tabulares 1200 e inferiores como fuentes de datos heredadas o de proveedores. Cuando se especifica como un origen de datos del proveedor, puede especificar un proveedor de datos determinado y otras propiedades de conexión avanzadas. Por ejemplo, puede conectarse a una instancia de Almacenamiento de datos de SQL Server o incluso a una instancia de Azure SQL Database como un origen de datos heredado. Después, puede seleccionar el proveedor de datos MSOLEDBSQL de OLE DB Driver for SQL Server. En este caso, la selección de un proveedor de datos de OLE DB puede proporcionar un rendimiento mejorado en el conector de Power Query.
Cuando se usa el Asistente para la 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. Puede cambiarlo si es necesario. El tipo de proveedor que elija puede depender del rendimiento, de si el modelo utiliza almacenamiento en memoria o DirectQuery y de la plataforma de Analysis Services en la que implementa su modelo.
Especificar orígenes de datos del proveedor en proyectos de modelos tabulares 1400 y posteriores
Para habilitar orígenes de datos del proveedor, en Visual Studio, haga clic en Herramientas>Opciones>Tabular de Analysis Services>Importación de datos y seleccione Habilitar orígenes de datos heredados.
Con los orígenes de datos heredados habilitados, en Explorador de modelos tabulares, haga clic con el botón derecho en Orígenes de datos>Importar desde origen de datos (heredado).
Al igual que con los proyectos de modelos tabulares 1200, use el Asistente para la 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 los demás valores de conexión en Establecer propiedades avanzadas.
Suplantación
En algunos casos, puede ser necesario especificar otra cuenta de suplantación. 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 se utiliza la autenticación de Windows, establezca la contraseña y el usuario de Windows. Para SQL Server, se admite la autenticación de Windows con una cuenta de suplantación específica solo 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
En el caso de los modelos tabulares con el nivel de compatibilidad 1400 y superior con el modo en memoria, Azure SQL Database, Azure Synapse, Dynamics 365 y la lista de SharePoint admiten las credenciales de OAuth. Para generar tokens válidos, establezca las credenciales mediante Power Query. Azure Analysis Services administra la actualización de tokens para los orígenes de datos de OAuth para evitar los tiempos de espera con las operaciones de actualización de ejecució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 tiene acceso a uno o varios orígenes de datos de consulta de mashup a través de una puerta de enlace o la propiedad ASPaaS\AlwaysUseGateway está establecida en true.
El modo de consulta directa no es compatible con las credenciales de OAuth.
Habilitación del proveedor administrado de Oracle
En algunos casos, las consultas DAX que se realizan 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.
Tal y como se indica 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 como un origen de datos de proveedor. En el caso de los modelos con un origen de datos de Oracle especificado como un origen de datos de proveedor, asegúrese de que el proveedor especificado es Oracle Data Provider for .NET (Oracle.DataAccess.Client).
Si el origen de datos de Oracle se especifica como un origen de datos estructurado, habilite la propiedad MDataEngine\UseManagedOracleProvider del servidor. Al configurar esta propiedad, se asegura de que el modelo se conecta al origen de datos de Oracle utilizando el proveedor administrado de Oracle Data Provider for .NET recomendado.
Para habilitar el proveedor administrado de Oracle:
En SQL Server Management Studio, conéctese al servidor.
Cree una consulta XMLA con el siguiente script. Sustituya ServerName por el nombre completo del servidor y 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>Reinicie el servidor.