Archiv für die Kategorie Data Warehouse

Mehr Business Intelligence und Datenmanagement in der Cloud

Erstellt am: Montag, 20. März 2017 von Sascha
Das Interesse an der Nutzung von Software für Business Intelligence (BI) und Datenmanagement (DM) in der Cloud wächst. Zu diesem Schluss kommt eine internationale Umfrage vom BARC und der Eckerson Group. Teilnehmer waren laut der Autoren 370 IT-Verantwortlichen aus Anwenderunternehmen, die Business Intelligence und Datenmanagement im Einsatz haben. Danach ist in den Jahren 2013 bis 2016 der Einsatz entsprechender Cloud-Lösungen von 29 Prozent auf 43 Prozent der offenbar in diesem Vergleichszeitraum befragten Unternehmen gestiegen. Dies wäre eine Steigerung von 50 Prozent über die letzten drei Jahre.
Als wichtigste Vorteile von BI- und DM-Lösungen aus der Cloud nennen die Befragten die Flexibilität, geringeren Kosten (Keine Installation, keine Hardwarekosten u.a.) und Skalierbarkeit (nach Bedarf), die solche Angebote mit sich bringen. Der von den Studienteilnehmern mit Abstand am häufigste genannte Anwendungsfall von Cloud-BI-Werkzeugen ist die Bereitstellung von Reports und Dashboards (76 Prozent) – typischerweise ein Einsatzfeld für gelegentliche Nutzer.

 

Ad-hoc Analysen, Reporting und Dashboards in der Cloud

Viele Tätigkeiten in der Cloud ausgeführt sind aber laut der Autoren deutlich komplexer und werden vor allem von erfahrenen Power Usern vorgenommen. Letztere sind auch die häufigsten Nutzer von Cloud-Lösungen, denen es im Vergleich zu den gelegentlichen und ggf. weniger versierten Nutzern leichter fällt, sich für die Software-as-a-Service (SaaS) BI-Lösung ein Konto einzurichten, Daten hochzuladen sowie Daten zu analysieren und visualisieren. Am häufigsten werden Tools für Ad-hoc-Analysen (57 Prozent), das Erstellen von Reports und Dashboards (55 Prozent), für Data Preparation (39 Prozent) sowie Advanced- und Predictive Analytics (23 Prozent) genutzt.
Der Aufbau Cloud-basierter Data-Warehouse-Lösungen, von Data Marts oder die Nutzung von Datenintegrationswerkzeugen erfolgt hingegen bis dato im Vergleich zu den BI-SaaS-Anwendungen noch seltener. Den Grund dafür wollen die Autoren darin sehen, dass für den Aufbau solcher DM-Umgebungen mehr Aufwand in die Bereitstellung von Infrastruktur- und Plattform Services zu leisten sei. Hinzu kämen Anforderungen in punkto Sicherheit, Datenschutz sowie interne Auseinandersetzungen, die einer Verlagerung in die Cloud erschweren. QUNIS hilft Unternehmen beim Aufbau von BI- und Big-Data-Lösungen in der Cloud, beispielsweise mit Microsoft Azure Cloud, und hat dabei gute Erfahrungen gemacht. So lassen sich die benötigten Komponenten schnell und kostengünstig installieren und die Bandbreite der verfügbaren Infrastrukturkomponenten bis hin zu Umgebungen für Machine Learing ist heute bereits sehr groß. Weitere Informationen finden Sie hier.

 

Business Intelligence in der Public Cloud

Fast die Hälfte der Unternehmen, die Cloud BI nutzen, verwenden die Public Cloud (46 Prozent) für BI und Datenmanagement, weniger als ein Drittel (30 Prozent) setzt auf die Hybrid Cloud und 24 Prozent nutzen die Private Cloud. Die Public Cloud werde laut Studie hauptsächlich von Organisationen vorangetrieben, die BI-Umgebungen erstellen möchten, die keine On-Premise-Daten erfordern, und von Organisationen, die die Cloud verwenden, um ältere Data Warehouses zu ersetzen, erklärten die Autoren. Mit der Cloud lagern Unternehmen ihre Hardware-Infrastruktur automatisch an einen Dritten aus. Aber viele Unternehmen gehen noch weiter. Fast zwei Drittel der Befragten setzen beim Hosting ihrer Cloud-BI-Lösung auf BI- oder DM-Anbieter. Ein Viertel lässt seine Cloud-BI-Umgebung extern betreiben und verwalten, 16 Prozent lassen ihre Cloud-BI-Anwendung sogar von den Anbietern entwickeln.
Die gesamte Studie kann bei Sponsoren wie Jedox kostenfrei nach der Registrierung heruntergeladen werden.

Partitionierung des MS SQL Servers für das Data Warehouse – Teil 2

Erstellt am: Freitag, 16. Dezember 2016 von Sascha

Nach einem ersten Überblick und Erläuterungen zum Partition Switching im ersten Teil des Blog-Beitrags, geht es nun darum, was benötigt wird, um eine Partitionierung vorzunehmen. Unter dem Gesichtspunkt, die von Natur aus komplexen DWH-Verarbeitungsroutinen nicht noch unnötig zu verkomplizieren, bietet sich hierfür ein praktikables, schlankes und modular gehaltenes Umsetzungskonzept an, das aus nachfolgend aufgeführten Komponenten besteht.

Administrativen Aufwand bei der Partitionierung kleinhalten

Von zentraler Bedeutung für den Betrieb ist, dass keine regelmäßigen administrativen Eingriffe nötig sind, etwa um neue Partitionen anzulegen, sondern, dass automatisch ausgeführte Routinen dieses übernehmen.  Basis für dieses Konzept ist, dass sämtliche partitionierte Tabellen dasselbe Partitionsschema und dieselbe Partitionsfunktion nutzen (oder falls doch nötig: möglichst wenig davon). Das Ganze sollte sogar soweit gehen, dass die OLAP Measure Groups auf die gleiche Weise partitioniert sind, wie die relationalen DWH-Tabellen.

Bausteine eines Partitionierungskonzepts

Folgende modulare Bausteine sollte Ihr Partitionierungskonzept etwa beinhalten:

  • eine Importsteuerungstabelle, die für sämtliche Faktendaten, die auf Basis eines Importdatums inkrementell importiert werden, Steuerungsmöglichkeiten für entsprechende Anwender erlaubt, wie einmaliger Import von Datum x, danach wieder y Tage rollierend oder dauerhaft ab Datum z usw.;
  • eine Handvoll Sichten, die Ihnen Infos zu Dimensionen / Measure Groups (beides basierend auf sog. Dynamic Management Views (DMV) auf Grundlage eines eingerichteten Verbindungsservers zu Analysis Services) und Partitionen / Partitionsgrenzen liefern – diese sind für den allgemeinen Überblick sinnvoll und finden in den nachfolgend aufgeführten Routinen Verwendung;
  • eine zentrale interne Routine (gespeicherte Prozedur), die auf Basis übergebener Parameter das Partition Switching für die relevanten Partitionen einer Faktentabelle vornimmt (in/out), sowie bei inkrementellen Importprozessen, die auf einem Importdatum basieren, die entsprechenden Fakten, die neu eingelesen werden, löscht (auf Basis der obigen Importsteuerungstabelle);
  • eine manuell aufzurufende Routine, die für neu erstellte Measure Groups basierend auf partitionierten Faktentabellen die Partitionierung – gültig nach aktuellem Stand – einrichtet (auf Basis von XMLA-Code via Verbindungsserver);
  • eine Routine für die nächtliche Datenverarbeitung, die sämtliche Dimensionen parallel verarbeitet (process update) und anschließend alle nicht partitionierten Measure Groups sowie alle relevanten Partitionen partitionierter Measure Groups parallel verarbeitet (auf Basis von XMLA-Code via Verbindungsserver sowie der Importsteuerungstabelle);
  • eine Routine, die auch mehrfach am Monatsanfang ablaufen kann und wiederholt nachsieht, ob es in der obersten (nach oben hin nicht begrenzten Partition) bereits Daten gibt. In diesem Fall werden alle nötigen Maßnahmen durchgeführt, die relationalen wie auch die multidimensionalen Partitionen anzulegen und zu verarbeiten.

Ein Tipp für die Praxis: Achten Sie penibel auf die Benennung der Dimensionen, Cubes und Measure Groups, denn DMVs liefern grundsätzlich den Namen dieser Objekte, während über XMLA die internen IDs dieser Objekte angesprochen werden müssen. Umbenennungen der IDs sind hier aufwändig.

Vorteile der multidimensionalen Partitionierung

Bleibt noch auszuführen, welche Vorteile die multidimensionale Partitionierung u.a. bietet: Sie erlaubt es, den Caching-Mechanismus zu optimieren. Während eine unpartitionierte Measure Groups mit der nächtlichen Verarbeitung aus dem Arbeitsspeicher entfernt wird, bleiben bei partitionierten Measure Groups die nicht-verarbeiteten Partitionen im Arbeitsspeicher vorhanden. Weiterhin beschränkt sich die Verarbeitung auf relevante Partitionen, während historische Partitionen nicht immer wieder neu verarbeitet werden müssen.

Weitere Informationen: Im Rahmen der QUNIS Beratung für Data Warehousing  geben wir unseren Kunden auch Tipps zur Performance-Optimierung ihres Microsoft SQL Servers. Dabei spielt die richtige Partitionierung eine wichtige Rolle.

Partitionierung des MS SQL Servers für das Data Warehouse – Teil 1

Erstellt am: Freitag, 9. Dezember 2016 von Sascha

Im Rahmen der QUNIS Beratung für Data Warehousing  geben wir unseren Kunden auch Tipps zur Performance-Optimierung ihres Microsoft SQL Servers. Dabei spielt die richtige Partitionierung eine wichtige Rolle. Grundsätzlich ist eine Partitionierung sowohl relational wie multidimensional möglich. Während Letzteres häufiger Einsatz findet, ist gerade die relationale Partitionierung bei zeitintensiven Data-Warehouse-Verarbeitungsroutinen ein effektvolles Mittel zur Laufzeitverbesserung. Die relationale Partitionierung findet auf Tabellen Anwendung und bedeutet faktisch, dass die Tabelle physisch in einzelne Fragmente aufgeteilt wird. Es handelt sich aber nach wie vor logisch und abfragetechnisch um eine (1!) Tabelle.

Die einzelnen Fragmente sind die Partitionen. Diese können auf unterschiedlichen Dateigruppen liegen, was durch das Partitionsschema definiert ist. Wichtiger für das Verständnis ist jedoch, dass jeder Datensatz eindeutig zu einer bestimmten Partition zugeordnet werden kann. Das ist über die Partitionsfunktion einzustellen. Dazu ist ein Feld der Tabelle festzulegen, dessen Inhalt dieses für jeden Datensatz bestimmt, beispielsweise ein Datum. So ließe sich in der Partitionsfunktion für Data-Warehouse-Fakten festlegen, dass historische Daten in Jahrespartitionen und aktuelle Daten in Monatspartitionen abgelegt werden.

Partition Swichting zur Performance-Steigerung
Um auf dieser Basis tatsächlich signifikante Performance-Verbesserungen in der Data-Warehouse-Verarbeitung erzielen zu können, ist ein weiterer Aspekt zu beachten. Die alleinige Partitionierung hat keinerlei Effekt, wenn SQL-Server die anzusprechenden Partitionen nicht auf Basis des entsprechenden SQL-Statements ableiten kann. Daher ist bei der Erstellung der SQL-Anweisungen besondere Acht geboten. Um diese Gefahr auszuschalten, sollte alternativ zum Mittel des Partition Switching gegriffen werden.  Hierbei werden einzelne Partitionen aus der Data-Warehouse-Tabelle in eine Arbeitstabelle für die Verarbeitung (löschen, einfügen, aktualisieren) herausgelöst (Switch out). Bedenken Sie hierbei, dass keinerlei Daten physisch bewegt werden, sondern dass die einzelnen Datenseiten in den Metadaten als zugehörig zur Arbeitstabelle statt zur Data-Warerhouse-Tabelle deklariert werden. Dadurch ist ein solches Partition Switching auch eine Angelegenheit eines Bruchteils einer Sekunde, egal wie viele Datensätze betroffen sind. Nach der Verarbeitung erfolgt das Partition Switching in umgekehrter Richtung (Switch in).

Wann lohnt sich Partition Switching?
Ab wann lohnt sich der Aufwand der Partitionierung verbunden mit Partitionsschema, Partitionsfunktion, zusätzlicher Arbeitstabelle und Partition Switching? Zunächst muss ein gewisses Datenvolumen vorhanden sein, ab dem es sich überhaupt lohnt, über den Einsatz nachzudenken. Die Angaben hierzu schwanken zwischen 20 und 60 Millionen Datensätze pro Tabelle. In der Praxis beschränkt sich das folglich auf Faktendaten.  Sollten Sie also eine oder mehrere Faktentabellen in dieser Größenordnung und gleichzeitig Laufzeitprobleme in der Verarbeitung haben, lohnt sich der Einsatz der Partitionierung, die allerdings ausschließlich in der Enterprise Edition (gilt für relationale Partitionierung) verfügbar ist.

Was ist also nötig für einen Einsatz der Partitionierung auf relationalen Fakten und OLAP-Measure Groups? Lesen Sie weiter im zweiten Teil des Beitrags!

 

Hohe Anforderungen an ein modernes Reporting

Erstellt am: Donnerstag, 13. Oktober 2016 von Sascha

Konsolidierung, Datenbeschaffung, Plausibilisierung und Abstimmung sowie die Berichtserstellung sind die typischen Phasen, die ein Reporting durchläuft. Die dazugehörigen Prozesse sollen heute so flexibel sein, dass sich neue Anforderungen schnell und ohne größeren Aufwand umsetzen lassen. Doch glaubt man der diesjährigen Lünendonk-Untersuchung „Der Markt für Business Intelligence und Business Analytics in Deutschland“ ist dies lediglich in 37 Prozent der insgesamt 70 befragten Unternehmen heute der Fall (2014: 54 Prozent). Stattdessen sind viele Standardaufgaben im Reporting nur ungenügend automatisiert und integriert. Durchschnittlich 67 Prozent der zur Verfügung stehenden Zeit entfallen auf diese Phasen.

Operational Business Intelligence
Da immer mehr Geschäftsprozesse und -modelle digital gesteuert und Marktzyklen kürzer werden, besteht also Handlungsbedarf. Strategische und operative Entscheidungen müssen sich künftig immer häufiger zeitnah auf der Basis analysierter Datenmengen treffen lassen können (operational BI). Und nicht nur die bisherigen Prozesse sind laut Lünendonk häufig noch (oder wieder) zu unflexibel, sondern auch die Qualität und Detailtiefe der Reports lasse zu wünschen übrig. So erklärte mit 44 Prozent (2014: 64 Prozent) weniger als die Hälfte der befragten Unternehmen, man würde qualitativ hochwertige Reports erstellen.

Andererseits seien laut Lünendonk vielerorts Anstrengungen im Gang, das Reporting in den kommenden Monaten zu optimieren. Etwa bezüglich der Automatisierung: 36 Prozent der Unternehmen müssen aktuell noch manuelle Eingriffe in den Reporting-Prozess vornehmen. Bereits in den zwei Jahren sollen es nur noch 29 Prozent sein.

Etwas weiter sind die befragten Unternehmen hinsichtlich der Standardisierung ihres Reportings. Aktuell können bereits 47 Prozent der Unternehmen auf vordefinierte Berichtsvorlagen zurückgreifen. Nur 24 Prozent der Befragten erklärte, Berichte würden immer noch erst auf Anfrage neu erstellt. In den kommenden zwei Jahren wollen 79 Prozent der Unternehmen standardmäßig auf vordefinierte Berichtvorlagen zurückzugreifen.

Reporting häufig als Insellösung
Eine zusätzliche Herausforderung im Reporting sind laut Lünendonk viele noch existierende Insellösungen. Knapp 60 Prozent der Befragten erklärten, dass ihr Berichtswesen dadurch aktuell keinen einheitlichen Blick auf das Unternehmen ermöglicht.  Beklagt wurde ferner von mehr als der Hälfte der Umfrageteilnehmer der Mangel an Experten mit speziellem technischen und Branchenwissen, und auch eine stärkere Verzahnung des Berichtswesens der Fachbereiche sei für jeden zweiten Befragten noch nicht erreicht. Letztere sei aber Voraussetzung für eine integrierte Unternehmenssteuerung, in der Kennzahlen und Datenauswertungen der einzelnen Fachbereiche im Sinne eines unternehmensweiten Ansatzes genutzt werden können.