Domanda

Ogni giorno scrivo circa 150.000 righe di dati in un database.Queste righe rappresentano ad esempio gli articoli in uscita.Adesso ne ho bisogno mostra un grafico utilizzando SSRS che mostrano il numero medio di articoli al giorno nel tempo. Ho anche bisogno di avere informazioni sul numero effettivo di articoli di ieri.

L'idea è quella di avere una visione aggregata di tutte le nostre transazioni e avere qualcosa che possa indicare che qualcosa non va (che ad esempio inviamo il 20% di articoli in meno rispetto alla media).

La mia idea è di spostare i dati di ieri SSAS ogni notte e lì memorizza il valore aggregato del numero di transazioni e il numero effettivo di transazioni dai dati di ieri.Si spera che l'utilizzo di SSAS acceleri i rapporti.

Pensi che questa sia l'idea giusta?Dovrei saltare SSAS e avere report direttamente sui dati grezzi?So come utilizzare i servizi di reporting sui dati grezzi utilizzando query SQL standard, ma come cambierebbe la situazione durante l'esecuzione di query su SSAS?Non lo so SSAS - da dove comincio ..?

È stato utile?

Soluzione

La cosa bella con SSAS è che puoi ottenere quegli indicatori di cui parli abbastanza facilmente creando misure calcolate o utilizzando KPI.

Ho iniziato con Fornire business intelligence con Microsoft SQL Server 2005.Aveva una buona introduzione, ma sfortunatamente è troppo prolisso quando si tratta di dettagli.Ma se vuoi comprendere SSAS, OLAP e il reporting utilizzando questo framework è un buon inizio.

Mosha Pasumansky ha un blog su SSAS e MDX con grande collegamenti.

A parte questo, consiglierei i libri online di Microsoft.

Altri suggerimenti

Sei sicuro di non confondere SSAS (Analysis Services) e SSIS (servizi di integrazione)?

SSAS non è un ETL, è uno strumento OLAP.

SSIS è uno strumento ETL.

Sono d'accordo con tutto ciò che ha detto Rowan.Sono solo confuso dai termini.

SSAS è un ETL attrezzo.Fondamentalmente ottieni dati da qualche parte (i tuoi articoli in uscita), fai qualcosa su di essi (aggregati) e li metti da qualche altra parte (la tabella degli aggregati, il data warehouse, ecc.).Controlla il collegamento per i dettagli.

Probabilmente non manterrai tutte le righe nel DB a tempo indeterminato e se vuoi essere in grado di generare report su trend più lunghi devi in ​​ogni caso eseguire una sorta di aggregazione dei dati storici.Pertanto, ha senso fare in modo che i report utilizzino questo archivio dati storico come fonte.Puoi quindi utilizzarlo per eseguire tutti i tipi di report fantasiosi.

TL;DR:Definisci la tabella della cronologia aggregata tenendo presente le tue future esigenze di reporting.Utilizzare SSAS per popolare la tabella e aggiornarla dagli aggiornamenti giornalieri.Rapporto da quel tavolo.Ulteriori letture:Schemi stellari e data warehousing.

@Sergio e @Rowan

Si dove non parlando di caricamento e trasformazione dei dati nel database (come farebbe uno strumento SSIS).Questo è stato risolto utilizzando la nostra piattaforma di integrazione.

@Riri forse SSAS è eccessivo per la situazione che hai presentato.Se hai solo bisogno di popolare quotidianamente le tabelle di riepilogo, puoi farlo creando un normale JOB in SQL Server ed eseguendolo in un normale script T-SQL.

Utilizzo questo approccio da diversi anni in un processo quotidiano per calcolare gli indicatori aziendali da circa 9 GB di nuovi dati al giorno.Funziona, è veloce, è semplice e utilizza una tecnologia a cui sei già abituato.Se il tuo processo quotidiano diventa più complicato (è necessario leggere da file, utilizzare FTP, inviare e-mail) puoi passare a un pacchetto SSIS (o qualsiasi altro strumento ETL che ti piace), ma non posso consigliare di utilizzare SSAS a meno che tu non abbia bisogno di fornire OLAP funzionalità ai tuoi utenti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top