Lenta tabella pivot Excel MDX?

Question

Sto avendo un momento estremamente difficile con Excel molto lento quando si interagisce con una tabella pivot. Aggiungendo/rimuovendo un campo, cambiando un filtro o un'affettatrice, tutti richiedono diversi minuti di congelamento di Excel prima di rispondere.

Sembra che l'MDX generato sia estremamente inefficiente. Posso apprezzare che devono generare l'MDX in modo dinamico e devono supportare molte funzionalità delle tabelle pivot, ma essere 100 volte più lento è ridicolo.

quando generano MDX per un campo su una riga o colonna, usano DrilldownLevel (... [Dimension Proprietà]. [County])

Non sono sicuro di quale sia lo scopo di approccio più complesso di Excel è, ma spero che ci siano alcune opzioni in cui posso deselezionare in modo che Excel non abbia bisogno di usare la funzione DrilldownLevel.

Invece, di solito ometto la funzione Drilldownlevel e faccio solo [Dimensione proprietà]. [Contea] . [Contea] per accedere all'attributo.

Una query per lo stesso set di risultati richiede 5 minuti con MDX di Excel e richiede meno di 5 secondi con il mio MDX.

Ho verificato che la lentezza non è un problema con il rendering/formattazione Excel dei risultati, poiché ho preso l'MDX utilizzato da Excel e l'ho eseguito direttamente in SSMS per verificare i tempi. Posso visualizzare il task manager sul server e osservare la CPU che si agita mentre elabora i risultati.

Nota, non sto incolpando il server dato che posso creare query MDX che funzionano molto velocemente e forniscono gli stessi risultati.

Come posso ottenere Excel per generare MDX più efficiente? Sto usando Excel 2010.

Ho sentito che powerpivot genera MDX più efficiente, tuttavia Powerpivot non è utilizzabile su SSAS, in quanto non utilizza il cubo SSAS. Quindi un breve accenno sul motivo per cui Powerpivot su SSAS non funziona. Se si importano dati da SSAS in powerpivot, sostanzialmente si sta eseguendo un crossjoin gigante per migrare i dati da SSAS in una tabella Powerpivot. Se hai provato questo, trovi che genera nomi di campi/etichette come "Proprietà DimensionCountyCountyCountyCounty" ... wow davvero? Quindi stai solo lavorando con i dati usando il motore OLAP di Powerpivot locale, e quindi dipende dal fatto che il computer client abbia un sistema operativo a 64 bit per funzionare con un set di dati di dimensioni ragionevoli. È come se stessimo tagliando SSAS, buttando tutto il tuo duro lavoro sulla creazione di un sofisticato database OLAP e su tutti i metadati, i calcoli, le aggregazioni, ecc. La metà del motivo dell'utilizzo di SSAS è che può riassumere i dati granulari prima che venga restituito al client, in modo che il client non abbia bisogno di un sistema operativo a 64 bit e non abbia bisogno di un'enorme quantità di risorse sul client. Ho provato davvero a rendere utilizzabile powerpivot contro SSAS, ma dopo aver provato diversi approcci e avanti e indietro con gli utenti, non era davvero così vicino all'essere utilizzabile. Non per battere Powerpivot, perché vedo che è utile in molti altri scenari, ma se il tuo cubo SSAS è una parte importante del tuo sistema (es. Calcoli, aggregazione di grandi quantità di record sul lato server, ecc.) Powerpivot sembra l'opzione sbagliata .

Ecco un esempio della mia interrogazione:

SELECT 
NON EMPTY CrossJoin(
{[Department Dimension].[Name].[Name]}, 
{[Finance Month].[Report Year].[Report Year]} 
) 
    ON COLUMNS , 
CrossJoin(
    {[Department Finance Line Type Dimension].[Display Order].[Display Order] }, 
    {[Department Finance Line Type Dimension].[Line Number].[Line Number]}, 
    {[Department Finance Line Type Dimension].[Display Name].[Display Name]} 
    ) 
    ON ROWS 
    FROM 
    (
    SELECT ({[Department Dimension].[County].&[Seminole],[Department Dimension].[County].&[Sarasota]}) ON COLUMNS FROM [HYP Data View] 
    ) 
    WHERE ([Department Finance Line Type Dimension].[Section Name].&[Part 1 - Balance Sheet], 
    [Measures].[Amount] 
    ) CELL PROPERTIES VALUE 

E sotto è quello che ha generato Excel. In realtà avevo già rimosso molti altri aspetti della query di Excel mentre tentavo di semplificarlo per determinare quale fosse il colpevole. Questo era l'aspetto della query quando era ancora lento, quindi il passo successivo è stato quando ho rimosso DrilldownLevel e sostituito. [All] con.[Nome attributo] ha iniziato a funzionare molto più velocemente.

molto molto lento query:

SELECT 
NON EMPTY CrossJoin(
{DrilldownLevel({[Department Dimension].[Name].[All]})}, 
{DrilldownLevel({[Finance Month].[Report Year].[All]})} 
) 
DIMENSION PROPERTIES PARENT_UNIQUE_NAME ON COLUMNS , 
CrossJoin(
    {DrilldownLevel({[Department Finance Line Type Dimension].[Display Order].[All] })}, 
    {DrilldownLevel({[Department Finance Line Type Dimension].[Line Number].[All]})}, 
    {DrilldownLevel({[Department Finance Line Type Dimension].[Display Name].[All]})} 
    ) 
    DIMENSION PROPERTIES PARENT_UNIQUE_NAME ON ROWS 
    FROM (
    SELECT ({[Department Dimension].[County].&[Seminole],[Department Dimension].[County].&[Sarasota]}) ON COLUMNS FROM [Afr Data View] 
    ) 
    WHERE ([Department Finance Line Type Dimension].[Section Name].&[Part 1 - Balance Sheet], 
    [Measures].[Amount] 
    ) CELL PROPERTIES VALUE 

Perché ha bisogno il DrilldownLevel (... [tutto])? C'è un'opzione da qualche parte che posso capovolgere per far sì che Excel non generi quella parte della query in modo che funzioni più velocemente?

Answer 1

Sfortunatamente nonostante abbia lavorato con Excel e Pivottables su SSAS MOLAP Cubes, non ho ancora trovato un meccanismo in puro Excel per modificare le query che genera.

Ho tuttavia utilizzato uno strumento di terze parti chiamato XLCubed che è abbastanza potente quando si lavora con query Excel e MDX da cubi OLAP SSAS, posso suggerire di provarlo per il proprio scopo? Puoi anche sostituire l'MDX che userà per una "Grid" con MDX totalmente personalizzato come sopra. Anche se trovo che non sia spesso necessario sostituirli con tabelle pivot "Grid" sembra generare MDX molto più efficiente in generale.

Possa gli dei SSAS essere con voi.