Drei Prinzipien der Data-Warehouse-Entwicklung

Gartner schätzt, dass fast 70 bis 80 Prozent der neu initiierten Business-Intelligence-Projekte scheitern. Dies hat unzählige Gründe, von der schlechten Tool-Wahl bis hin zu mangelnder Kommunikation zwischen IT- und Business-Stakeholdern. Nachdem ich branchenübergreifend BI-Projekte erfolgreich implementiert habe, hoffe ich, meine Erfahrungen in diesem Blogbeitrag zu teilen und die wichtigsten Gründe aufzuzeigen, warum Business-Intelligence-Projekte scheitern. In diesem Artikel werden Gegenmaßnahmen für Ausfälle vorgestellt, die auf drei Prinzipien basieren, die den Aufbau von Data Warehouses regeln sollten. Die Befolgung dieser Data-Warehouse-Konzepte sollte Ihnen als Data-Warehouse-Entwickler dabei helfen, die Entwicklungsreise zu meistern und dabei die üblichen Schlaglöcher oder sogar Sinkholes von BI-Implementierungen zu vermeiden.

Implementierung von Business Intelligence Data Warehouse

Während die Kriterien für ein erfolgreiches Business-Intelligence-Data-Warehouse von Projekt zu Projekt unterschiedlich sind, werden bestimmte Mindestanforderungen für alle Projekte erwartet und gefordert. Hier ist eine Liste der Hauptattribute, die normalerweise in einem erfolgreichen Business Intelligence Data Warehouse zu finden sind:

• Wert: Business-Intelligence-Projekte können sich über viele Monate oder sogar Jahre erstrecken. Es ist jedoch wichtig, die Vorteile eines Data Warehouse den Interessengruppen Ihres Unternehmens sehr früh im Projekt aufzuzeigen, um eine kontinuierliche Finanzierung und Interesse sicherzustellen. Idealerweise sollte den Stakeholdern innerhalb der ersten drei Wochen des Projekts ein sinnvoller Geschäftswert des neuen Systems aufgezeigt werden.
• Self-Service BI: Die Zeiten des Wartens auf die IT, um Datenanfragen zu erfüllen oder Datenanalysen durchzuführen, sind vorbei. Der Erfolg eines BI-Projekts wird heute daran gemessen, wie gut es die Geschäftsanwender in die Lage versetzt, selbst Wert aus dem System zu ziehen.
• Kosten: BI-Projekte haben im Allgemeinen relativ hohe Anfangskosten für die Implementierung. Um die hohen Anschaffungskosten auszugleichen und auszugleichen, ist es wichtig, Lager mit niedrigen Wartungskosten zu entwerfen. Wenn der Kunde ein vollwertiges Team von BI-Entwicklern benötigt, um Datenqualitätsprobleme sicherzustellen/zu diagnostizieren, routinemäßige Änderungen an den Datenmodellen vorzunehmen oder ETL-Fehler zu behandeln, wäre das Budget des Systems teuer und es besteht die Gefahr, dass es nach einiger Zeit abgeschaltet wird .
• Anpassungsfähigkeit: Die Fähigkeit, sich an sich ändernde Geschäftsanforderungen anzupassen, ist entscheidend. Es ist wichtig, die unzählige Anzahl von BI-Tools, die auf dem Markt verfügbar sind, und das Tempo, mit dem sie sich weiterentwickeln, um zusätzliche Funktionen und Features aufzunehmen, im Auge zu behalten. In Verbindung mit der Tatsache, dass sich Unternehmen ständig weiterentwickeln, werden sich die Anforderungen an das Lager ändern; Anpassbarkeit erfordert, dass Data Warehouses so gestaltet sind, dass sie auch in Zukunft den Einsatz alternativer BI-Werkzeuge wie unterschiedlicher Backends oder Visualisierungstools ermöglichen und an oft unvorhergesehene Änderungen der Anforderungen anpassbar sind.

Durch meine Erfahrung beim Aufbau erfolgreicher Lösungen und, was vielleicht noch wichtiger ist, durch die Beteiligung an gescheiterten Projekten bin ich zu dem Schluss gekommen, dass drei Schlüsselprinzipien von größter Bedeutung sind, um die Wahrscheinlichkeit einer erfolgreichen Implementierung von Business-Intelligence-Systemen zu erhöhen. Bevor wir sie jedoch im Detail behandeln, beginnen wir mit etwas Kontext.

Was ist ein Data Warehouse?

Bevor Sie sich mit verschiedenen Data Warehouse-Konzepten befassen, ist es wichtig zu verstehen, was ein Data Warehouse eigentlich ist.

Data Warehouses werden oft als Business-Intelligence-Systeme betrachtet, die entwickelt wurden, um die täglichen Berichtsanforderungen einer Geschäftseinheit zu erfüllen. Sie haben nicht die gleichen Anforderungen an die Echtzeitleistung (in Standardimplementierungen) wie OLTP-Datensysteme, und während OLTP-Systeme nur die Daten enthalten, die sich auf eine kleine Teilmenge des Unternehmens beziehen, versuchen Data Warehouses, alle Daten zu umfassen, die sich auf das Unternehmen beziehen Geschäft .

Data-Warehouse-Modelle bieten einem Unternehmen nur dann Vorteile, wenn das Warehouse als zentrale Drehscheibe für „alle Daten“ betrachtet wird und nicht nur als Werkzeug, mit dem Ihre Betriebsberichte erstellt werden. Alle operativen Systeme sollten eine bidirektionale Kommunikation mit dem Data Warehouse haben, um Daten einzuspeisen und Feedback zu erhalten, wie die betriebliche Effizienz verbessert werden kann. Jede geschäftliche Änderung, wie z. B. eine Preiserhöhung oder eine Verringerung des Angebots/Bestands, sollte zunächst in Ihrer Data-Warehouse-Umgebung als Prototyp erstellt und prognostiziert werden, damit Ihr Unternehmen das Ergebnis zuverlässig vorhersagen und quantifizieren kann. In diesem Zusammenhang würden sich alle Data-Science- und Data-Analytics-Funktionen um das Data Warehouse drehen.

Es gibt viele Komponenten eines Data Warehouse, und es ist nicht einfach eine Datenbank:

• Eine Datenbank ist ein Medium, über das Sie Ihre Daten speichern.
• Ein Data Warehouse geht darüber hinaus und enthält Tools und Komponenten, die erforderlich sind, um den Geschäftswert aus Ihren Daten zu ziehen, und kann Komponenten wie Integrationspipelines, Datenqualitäts-Frameworks, Visualisierungstools und sogar Plugins für maschinelles Lernen enthalten.

Hier ist eine anschaulichere Darstellung des Unterschieds zwischen einer Datenbank und einer Datenbank-Warehouse-Struktur. Datenbanken oder neue logische Daten-Metaspeicher wie Hive bilden den zentralen Stern des Sternensystems eines Data Warehouse, mit allen anderen Komponenten als seinen rotierenden Planeten. Im Gegensatz zu einem Star-System kann ein Data Warehouse jedoch eine oder mehrere Datenbanken haben, und diese Datenbanken sollten mit neuen Technologien austauschbar sein, wie wir später in diesem Artikel besprechen werden.

Erstes Data-Warehouse-Prinzip: Datenqualität steht an oberster Stelle

Data Warehouses sind nur in dem Maße nützlich und wertvoll, in dem die darin enthaltenen Daten von den Geschäftsbeteiligten als vertrauenswürdig eingestuft werden. Um dies zu gewährleisten, müssen Frameworks entwickelt werden, die Datenqualitätsprobleme automatisch erfassen und (wo möglich) korrigieren. Die Datenbereinigung sollte Teil des Datenintegrationsprozesses sein, wobei regelmäßige Datenaudits oder Datenprofilerstellung durchgeführt werden, um Datenprobleme zu identifizieren. Während diese proaktiven Maßnahmen implementiert werden, müssen Sie auch reaktive Maßnahmen in Betracht ziehen, wenn fehlerhafte Daten diese Tore passieren und vom Benutzer gemeldet werden.

Um das Vertrauen der Benutzer in das Data-Warehouse-System sicherzustellen, sollten alle fehlerhaften Daten, die von Geschäftsbenutzern hervorgehoben werden, vorrangig untersucht werden. Um diese Bemühungen zu unterstützen, sollten Datenherkunfts- und Datenkontroll-Frameworks in die Plattform integriert werden, um sicherzustellen, dass alle Datenprobleme schnell von den Support-Mitarbeitern identifiziert und behoben werden können. Die meisten Datenintegrationsplattformen integrieren ein gewisses Maß an Datenqualitätslösungen, wie z. B. DQS in MS SQL Server oder IDQ in Informatica.

Nutzen Sie diese integrierten Plattformen, wenn Sie ein kommerzielles Tool in Ihren Datenintegrationspipelines verwenden, aber stellen Sie zusätzlich oder anderweitig sicher, dass Sie die Mechanismen aufbauen, die Ihnen helfen würden, die Qualität Ihrer Daten aufrechtzuerhalten. Beispielsweise fehlt den meisten Datenintegrationstools eine gute Funktionalität zur Verfolgung der Datenherkunft. Um diese Einschränkung zu überwinden, kann ein benutzerdefiniertes Batch-Steuerungsframework erstellt werden, das eine Reihe von Steuertabellen verwendet, um jeden Datenfluss zu verfolgen, der innerhalb des Systems auftritt.

Es ist sehr schwierig, das Vertrauen Ihrer Geschäftsbeteiligten zurückzugewinnen, wenn sie innerhalb Ihrer Plattform auf schlechte Qualität stoßen, daher sollte die Vorabinvestition in Datenqualitäts-Frameworks die Kosten wert sein.

Zweites Data-Warehouse-Prinzip: Drehe das Dreieck um

Diese Abbildung veranschaulicht die Arbeitsteilung bei der Implementierung und Nutzung der meisten Data Warehouses.

Der größte Aufwand wird in den Aufbau und die Wartung des Lagers investiert, während der Mehrwert eines Lagers für Geschäftsanalysen einen viel geringeren Teil des Aufwands ausmacht. Auch deshalb scheitern Business-Intelligence-Projekte häufig. Manchmal dauert es im Projektzyklus zu lange, um dem Kunden einen sinnvollen Wert aufzuzeigen, und wenn das System endlich eingerichtet ist, erfordert es immer noch viel IT-Aufwand, um einen geschäftlichen Nutzen daraus zu ziehen. Wie wir in der Einleitung gesagt haben, kann das Entwerfen und Bereitstellen von Business-Intelligence-Systemen ein teurer und langwieriger Prozess sein. Daher werden Interessengruppen zu Recht erwarten, dass sie schnell den Mehrwert ihrer Business Intelligence- und Data Warehousing-Bemühungen ernten werden. Stellt sich kein Mehrwert ein oder kommen die Ergebnisse einfach zu spät, um einen echten Wert zu haben, hält sie nicht mehr viel davon ab, den Stecker zu ziehen.

Das zweite Prinzip der Data-Warehouse-Entwicklung besteht darin, das Dreieck umzudrehen, wie hier dargestellt.

Ihre Wahl der Business-Intelligence-Tools und die von Ihnen eingerichteten Frameworks müssen sicherstellen, dass ein größerer Teil der Bemühungen, die in das Warehouse fließen, darauf verwendet werden, den Geschäftswert zu extrahieren, als ihn aufzubauen und zu warten. Dies gewährleistet ein hohes Maß an Engagement Ihrer Geschäftsinteressenten, da sie sofort den Wert einer Investition in das Projekt erkennen. Noch wichtiger ist, dass Sie es dem Unternehmen ermöglichen, bei der Gewinnung von Werten autark zu sein, ohne eine so starke Abhängigkeit von der IT zu haben.

Sie können sich an dieses Prinzip halten, indem Sie beim Aufbau des Lagers inkrementelle Entwicklungsmethoden befolgen, um sicherzustellen, dass Sie die Produktionsfunktionalität so schnell wie möglich bereitstellen. Wenn Sie der Data-Mart-Strategie von Kimball oder den Data-Warehouse-Designmethoden von Linstedt Data Vault folgen, können Sie Systeme entwickeln, die inkrementell aufgebaut werden und gleichzeitig Änderungen reibungslos berücksichtigen. Verwenden Sie eine semantische Ebene in Ihrer Plattform, wie z. B. einen MS SSAS-Cube oder sogar ein Business Objects Universe, um eine leicht verständliche Geschäftsschnittstelle für Ihre Daten bereitzustellen. Im ersten Fall bieten Sie Benutzern auch einen einfachen Mechanismus zum Abfragen von Daten aus Excel – immer noch das beliebteste Datenanalysetool.

Die Einbindung von BI-Tools, die sich für Self-Service-BI einsetzen, wie Tableau oder PowerBI, wird nur dazu beitragen, das Benutzerengagement zu verbessern, da die Schnittstelle zum Abfragen von Daten jetzt drastisch vereinfacht ist, im Gegensatz zum Schreiben von SQL.

Das Speichern von Quelldaten in einem Data Lake vor dem Füllen einer Datenbank hilft dabei, die Quelldaten den Benutzern sehr früh im Onboarding-Prozess zur Verfügung zu stellen. Zumindest fortgeschrittene Benutzer wie Business Quants werden nun in der Lage sein, die Quelldaten (über die Rohdateien) zu verdauen, indem sie Tools wie Hive/Impala über den Dateien verbinden. Dies wird dazu beitragen, die Zeit, die das Unternehmen benötigt, um einen neuen Datenpunkt zu analysieren, von Wochen auf Tage oder sogar Stunden zu reduzieren.

Drittes Datenbank-Warehouse-Prinzip: Plug and Play

Daten stehen kurz davor, zum digitalen Äquivalent von Öl zu werden. In den letzten Jahren haben wir eine Explosion der Anzahl von Tools, die als Teil einer Data-Warehouse-Plattform verwendet werden können, und der Innovationsrate erlebt. An der Spitze stehen die unzähligen Visualisierungstools, die derzeit verfügbar sind, dicht gefolgt von erweiterten Optionen für Back-Ends. Angesichts dieses Umfelds und der Tendenz, dass sich die Geschäftsanforderungen ständig ändern, ist es wichtig zu bedenken, dass Sie im Laufe der Zeit Komponenten Ihres Technologie-Stacks austauschen oder sogar andere einführen oder entfernen müssten, je nach Geschäfts- und Technologieänderungen.

Basierend auf persönlicher Erfahrung wäre es ein Glück, wenn eine Plattform 12 Monate ohne irgendeine wesentliche Änderung überdauern könnte. Ein angemessener Aufwand ist in diesen Situationen unvermeidbar; Es sollte jedoch immer möglich sein, Technologien oder Design zu ändern, und Ihre Plattform sollte so konzipiert sein, dass sie diesem eventuellen Bedarf gerecht wird. Wenn die Migrationskosten eines Warenlagers zu hoch sind, könnte das Unternehmen einfach entscheiden, dass die Kosten nicht gerechtfertigt sind, und das, was Sie erstellt haben, aufgeben, anstatt zu versuchen, die vorhandene Lösung auf neue Tools zu migrieren.

Der Aufbau eines Systems, das allen vorstellbaren zukünftigen Anforderungen gerecht wird, ist unmöglich. Daher ist beim Erstellen von Data Warehouses ein gewisses Maß an Verständnis dafür erforderlich, dass alles, was Sie jetzt entwerfen und erstellen, mit der Zeit ersetzt werden kann. Zu diesem Zweck würde ich nach Möglichkeit die Verwendung generischer Tools und Designs empfehlen, anstatt Ihre Plattform eng an die Tools zu koppeln, auf denen sie ausgeführt wird. Natürlich muss dies nach sorgfältiger Planung und Überlegung erfolgen, da die Stärke vieler Tools, insbesondere Datenbanken, in ihrer Individualität und in enger Ergänzung liegt.

Beispielsweise wird die ETL-Leistung erheblich verbessert, wenn gespeicherte Prozeduren in einer Datenbank verwendet werden, um neue Geschäftsanalysedaten zu erstellen, anstatt die Daten außerhalb der Datenbank mit Python oder SSIS zu extrahieren und zu verarbeiten. In Bezug auf die Berichtsebene würden Visualisierungstools bestimmte Funktionalitäten bieten, die in anderen nicht ohne Weiteres verfügbar sind – Power BI unterstützt z. B. benutzerdefinierte MDX-Abfragen, Tableau jedoch nicht. Mir geht es nicht darum, die Desertion gespeicherter Prozeduren oder die Vermeidung von SSAS-Cubes oder Tableau in Ihren Systemen zu befürworten. Meine Absicht ist lediglich, darauf hinzuweisen, wie wichtig es ist, bei der Begründung von Entscheidungen, Ihre Plattform eng an ihre Tools zu koppeln, aufmerksam zu sein.

Ein weiteres potenzielles Loch befindet sich in der Integrationsschicht. Es ist sehr einfach, ein Tool wie SSIS für Ihre Datenintegration zu verwenden, da es Debugging-Funktionen bietet oder einfach mit der SQL Server-Plattform verwendet werden kann. Die Migration von Hunderten von SSIS-Paketen zu einem anderen Tool würde jedoch zu einem sehr kostspieligen Projekt. In Fällen, in denen Sie hauptsächlich „EL“ durchführen, verwenden Sie ein generisches Tool für Ihre Verarbeitung. Die Verwendung einer Programmiersprache wie Python oder Java zum Schreiben eines generischen Ladeprogramms zum Laden Ihrer Staging-Schicht trägt dazu bei, einzelne SSIS-Pakete zu reduzieren, die Sie sonst benötigt hätten. Dieser Ansatz trägt nicht nur zur Reduzierung der Wartungs- und zukünftigen Migrationskosten bei, sondern hilft auch, mehr Aspekte des Daten-Onboarding-Prozesses zu automatisieren, ohne dass neue individuelle Pakete geschrieben werden müssen (in Anlehnung an Prinzip 2).

In all diesen Fällen müssen Sie sich für einen praktischen Kompromiss zwischen den unmittelbaren Vorteilen und den zukünftigen Migrationskosten entscheiden, um sicherzustellen, dass das Lager nicht verschrottet wird, weil es Änderungen nicht bewältigen kann oder weil die Änderung zu viel Zeit in Anspruch genommen hätte. Anstrengung oder Investition.

Einpacken

Es gibt viele Gründe, warum ein bestimmtes Business-Intelligence-System ausfallen kann, und es gibt auch einige häufige Versehen, die letztendlich zu einem Ausfall führen können. Die sich ständig ändernde Technologielandschaft, das begrenzte Budget für Datensysteme aufgrund falsch verstandener sekundärer Priorität gegenüber Betriebssystemen und die schiere Komplexität und Schwierigkeit der Arbeit mit Daten bedeuten, dass beim Entwerfen und Planen nicht nur die unmittelbaren Ziele, sondern auch zukünftige Pläne sorgfältig berücksichtigt werden müssen Aufbau der Komponenten eines Data Warehouse.

Die in diesem Artikel skizzierten Data Warehousing-Grundlagen sollen Ihnen bei diesen wichtigen Überlegungen helfen. Die Berücksichtigung dieser Prinzipien garantiert natürlich keinen Erfolg, aber sie werden Ihnen sicherlich dabei helfen, Misserfolge zu vermeiden.