Besprechen Sie mit Vincent Rainardi das Data Warehousing für die Finanzdienstleistungsbranche

By |2021-09-14T07:24:00+00:00März 31st, 2021|

Mit dem Start von Astera DW-Builder Gleich um die Ecke haben wir mit einigen der führenden Vordenker der Branche gesprochen, um zu erfahren, wie sich die Branche entwickelt, wie sie sich entwickelt und wo sie sieht, dass die Automatisierung von Data Warehouse in das Gesamtbild passt.

Für unser zweites Interview in dieser Reihe haben wir uns mit Vincent Rainardi zusammengesetzt, einem langjährigen Veteranen im Bereich Data Warehousing. Er hat an Projekten für Kunden wie Barclays, Lloyds Bank, Toyota und Avery Dennison gearbeitet. Vincent hat auch ausführlich über Data Warehousing und BI geschrieben und ein Buch verfasst Erstellen eines Data Warehouse: Mit Beispielen in SQL Server und eine beliebte Blog zu diesem Thema.

In dieser Diskussion haben wir uns eingehend mit Vincents vielfältigen Erfahrungen und Erkenntnissen im Bereich Data Warehousing befasst, wobei ein besonderer Schwerpunkt auf der Finanzdienstleistungsbranche lag, in der er im Laufe der Jahre umfangreiches Fachwissen aufgebaut hat.

Können Sie mir etwas über Ihr Engagement im Data Warehousing erzählen? Wann haben Sie zum ersten Mal an diesen Projekten gearbeitet und welche Rolle haben Sie im Laufe der Jahre im Entwicklungsprozess gespielt?

Ich begann 1996 im Data Warehousing zu arbeiten und baute ein Data Warehouse und BI für einen Autohersteller auf. Zu dieser Zeit hieß DW & BI DSS und EIS / MIS (Decision Support System und Executive / Management Information System). Ich habe DW / BI dann für einige Jahre verlassen, mich aber 2005 wieder in diesem Bereich engagiert, als ich Ralph Kimballs Buch über Data Warehousing las (Das Data Warehouse Toolkit) und wurde sehr leidenschaftlich. Danach schrieb ich viele Artikel zum Thema für verschiedene Websites und meinen Blog. 2007 veröffentlichte ich ein Buch, das viele meiner Erkenntnisse zum Data Warehousing enthielt.

Seit 2005 habe ich an mehreren Data Warehousing-Projekten gearbeitet und Data Warehouses für Banken, Vermögensverwalter, Versicherer, Hersteller, Gesundheitsdienstleister, Einzelhändler und E-Commerce-Unternehmen entwickelt. Während der Implementierung bin ich hauptsächlich als Data Warehouse-Architekt verantwortlich, dh beim Entwerfen der Datenflussarchitektur, der Datenmodelle und der physischen Plattformen, einschließlich SQL Server, Oracle, Teradata, Hadoop und Azure.

Ich war auch in verschiedenen anderen Funktionen tätig, unter anderem als Business Analyst (Geschäftsanforderungen, Funktionsspezifikationen), BI-Designer (Definieren von Dashboards und Visualisierungen) und BI-Entwickler (Arbeiten mit Plattformen wie QlikView, Spotfire, Tableau, SSRS, SSAS) , ProClarity, Business Objects, Strategy Companion), ETL-Entwickler (SSIS, Informatica, Teradata-Dienstprogramme, SQL), Tester und Projektmanager.

Sie haben bereits ein wenig über die Unterschiede zwischen Data Warehousing und BI gesprochen. Wie ergänzen sich diese beiden Konzepte Ihrer Meinung nach und wo unterscheiden sie sich im Prinzip?

In der Praxis werden sie synonym verwendet, aber tatsächlich sind sie unterschiedlich. BI ist das Frontend (Dashboards, Berichte, Visualisierungen) und das Data Warehouse das Backend (Datenbank, Speicher, ETL, Dateien). Sie ergänzen sich jedoch und werden in der Praxis zusammen verwendet. Heute muss das Backend kein Data Warehouse sein. Es kann ein Datensee sein. Und das Frontend muss nicht BI sein. es kann maschinelles Lernen sein.

Sie verfügen über umfangreiche Erfahrungen im Bereich Finanzdienstleistungen. Was sind Ihrer Meinung nach die häufigsten Anwendungsfälle, die Sie von Organisationen in Branchen wie Versicherungen oder Investmentbanking sehen?

Die Anwendungsfälle in der Versicherung beinhalten viele komplexe Analysen. Daher werden Unternehmen in der Regel versuchen, Fragen zu den Arten der höheren verdienten Bruttoprämie, den schriftlichen Prämien, der Risikodeckung, den Risikokosten, den Schadensanpassungen, den Schadenfristen, den Verkaufspipelines, der Kundenrentabilität, dem Underwriting, den versicherungsmathematischen Raten und den Rückversicherungsrisiken zu beantworten. und Cashflow.

Im Investment Banking werden diese Analysen Marktrisiken, Positionsrisiken, Handelsaktivitäten, regulatorische Berichterstattung, Marktforschung, Liquidität, Sicherheiten, Deal Pipelines, Kundenkonten, Geldwäschebekämpfung, Gegenparteien, Betrugserkennung, Portfoliomanagement und Kapitalstresstests abdecken .

Wir haben in den letzten zehn Jahren einen deutlichen Anstieg des Datenvolumens und der Datenvielfalt in Unternehmen festgestellt. Wie sehen Sie die Entwicklung des sogenannten traditionellen Data Warehouse, um diesen Anforderungen gerecht zu werden?

Daher hat sich das traditionelle Data Warehousing dahingehend weiterentwickelt, dass Data Lake- und Big Data-Technologien integriert werden. Unstrukturierte Daten werden in Data Lakes gespeichert, einschließlich Dokumenten, Bildern, Videos, IoT und Social Media-Feeds, während strukturierte Daten (Daten in Tabellenform) im Data Warehouse gespeichert werden. Data Lakes basieren normalerweise auf dem Hadoop-Dateisystem im Vergleich zum Data Warehouse, das im Allgemeinen auf relationalen Datenbanken basiert. Moderne Data Warehouses enthalten auch NoSQL, wie z. B. Grafik- und Dokumentendatenbanken, da einige Daten für diese Formattypen besser geeignet sind. Das deckt das Sortenbit ab.

In den ersten Jahren des Data Warehousing waren MPP-Datenbanken wie Teradata, Oracle Exadata und Microsoft PDW eine beliebte Methode, um große Datenmengen zu verarbeiten und gleichzeitig die Daten relational zu halten. Heutzutage werden Big-Data-Technologien jedoch viel häufiger eingesetzt.

Wie sehen Sie den Datensee? Hat es einen Platz im modernen BI-System? Ergänzt es das Data Warehouse oder ist es eine praktikable Alternative?

Ja tut es. Moderne Data Warehouses verwenden Data Lakes als Staging-Bereich, über den Benutzer und Frontend-ML-Technologien auf Rohdaten zugreifen können. Solange Sie keine Daten integrieren möchten, ist der Datensee eine praktikable Alternative. Diese Art von Anwendungsfall tritt häufig in Projekten auf, in denen Daten isoliert (von anderen Funktionen getrennt) und die Entwicklungszeit minimal ist. In diesem Fall sind Data Lakes sehr effektiv. Ein gutes Beispiel hierfür wäre ein auf maschinellem Lernen basierendes Betrugserkennungsprojekt in einer Bank oder ein Projekt, bei dem eine bestimmte Meldepflicht innerhalb von drei Monaten erfüllt werden muss. Wenn diese Silos später entfernt werden (dh wenn andere Unternehmensfunktionen auf das Vorhersageergebnis zugreifen müssen), kann die Modellausgabe für nachgeschaltete Benutzer im Data Warehouse gespeichert werden.

In den meisten Unternehmensszenarien müssen Sie jedoch Daten integrieren. Beispielsweise muss ein Versicherer oder Vermögensverwalter eine erstellen einheitliche Ansicht von Daten über Wertpapiere, Emittenten, Richtlinien und Kunden, um ein genaues Bild ihres Unternehmens zu entwickeln.

Sie haben in der Vergangenheit gesagt, dass das Verständnis des Geschäfts der kritischste Teil der Data Warehouse-Entwicklung sein könnte. Wie würden Sie sicherstellen, dass die Geschäftsanforderungen originalgetreu in die Datenarchitektur umgesetzt werden?

Ja, Geschäftsverständnis ist sehr wichtig. Sie können unmöglich ein gutes Datenmodell entwerfen, ohne das Geschäft gut zu verstehen. Stellen Sie sich vor, Sie wären beauftragt, ein ESG-Data-Warehouse (Umwelt, Soziales, Governance) zu entwerfen, hätten aber keine Ahnung, was ESG ist. Oder ein Underwriting Data Mart, aber Sie haben nie in der Versicherung gearbeitet. Sie können unmöglich wissen, wie die Fakten- und Dimensionstabellen aussehen sollten. Ein guter Datenarchitekt muss sich für das Wesentliche des Geschäfts interessieren. Angenommen, Sie entwerfen einen Performance Attribution Mart für einen Anlageverwalter. Es ist wichtig, dass Sie den Unterschied zwischen arithmetischen und geometrischen Rückgaben, Ertragskurven und Interaktionsfaktoren kennen. Leider sind einige Datenarchitekten nicht an diesen wesentlichen Geschäftsdetails interessiert. Sie interessieren sich mehr für die technischen Details.

Der beste Weg, um sicherzustellen, dass die Geschäftsanforderungen gut in das Datenmodell integriert sind, besteht darin, verschiedene Geschäftsszenarien auszuführen und zu testen, ob jedes Szenario durch Abfragen des Datenmodells mithilfe einer einfachen SQL-Abfrage erfüllt werden kann. Wenn Sie dafür eine komplexe Abfrage benötigen, ist das Datenmodell nicht gut gestaltet. Dies ist normalerweise der Untergang eines Datensees; Sie erfüllen keine komplizierten Geschäftsszenarien. Und das ist der Kern des Ganzen: diese Szenarien gut zu schreiben; Sie müssen ein gutes Verständnis für das Geschäft haben.

In einem früheren Blogbeitrag haben Sie darüber geschrieben, wie viele Finanzdienstleistungsunternehmen Excel noch zum Generieren von Berichten und Analysen verwenden. Sehen Sie, dass sich diese Praxis ändert, wenn ausgefeiltere Visualisierungswerkzeuge an der Tagesordnung sind, oder werden wir diesen Prozess auf absehbare Zeit fortsetzen?

Finanzdienstleistungsunternehmen werden Excel weiterhin für Analysen und Berichte verwenden. Dies liegt in der Natur des Menschen, da Mitarbeiter in diesem Bereich in der Regel über starke Excel-Kenntnisse verfügen. Diese Präferenz habe ich bei verschiedenen Banken und Investmentgesellschaften hautnah miterlebt. Selbst Unternehmen, die Plattformen wie Tableau, Qlik oder Power BI verwenden, forderten eine Funktion zum Exportieren nach Excel zur weiteren Analyse.

Obwohl die von Visualisierungstools erstellten Standardberichte und Dashboards wichtig sind (sie enthalten formalisierte Daten in einem leicht verdaulichen Format), müssen Benutzer in vielen Fällen ihre eigene Analyse durchführen. Dafür fragen sie nach den Rohdaten hinter diesen Dashboards in einem Tool, mit dem sie weitaus besser vertraut sind - Excel. Mit den vorliegenden Rohdaten können sie die Daten je nach Bedarf unterschiedlich gruppieren, bestimmte Filter anwenden usw.

Denken Sie daran, dies sind Finanzanalysten, zahlenbewusste und intelligente Mitarbeiter. Sie analysieren Daten und geben Zahlen ein. Das Konsumieren statischer Berichte wird niemals ihre gesamten Anforderungen erfüllen, weshalb es im Allgemeinen keine gute Idee ist, zu versuchen, alle möglichen Anforderungen im BI-Tool zu erfüllen.

In den letzten Jahren gab es große Anstrengungen, Data Warehouses auf Plattformen wie Google BigQuery oder Amazon Redshift in die Cloud zu verlagern. Wie sehen Sie die Vorteile der Cloud-Bereitstellung? Würden Sie in einigen Fällen immer noch empfehlen, bei lokalen Datenbanken zu bleiben?

Die Hauptvorteile sind das Outsourcing von Humanressourcen und die Flexibilität bei den Computerressourcen. Mit einem Cloud-Data-Warehouse müssen Sie nicht viele interne Mitarbeiter bezahlen, um die Prozesse für Server, Speicher, Netzwerk, Sicherheit, Sicherung und Notfallwiederherstellung zu warten. Wenn Sie einen neuen Datenbankserver benötigen, müssen Sie nicht drei Wochen warten, um Speicher zu kaufen, zu konfigurieren, zu installieren, anzuhängen usw. Stattdessen erhalten Sie bei Bedarf eine erhöhte Serverkapazität und zahlen stundenweise.

Dieses Wertversprechen ist nicht nur für kleine Unternehmen interessant, sondern auch für große Unternehmen, die sich oft fragen: "Auf welches Geschäft sollte ich mich konzentrieren?" Unabhängig davon, ob Sie ein Einzelhändler, ein Telekommunikations- oder ein Finanzunternehmen sind, lautet die Antwort sicherlich weder "das Servergeschäft" noch "das IT-Infrastrukturgeschäft". Sie lagern also aus. Mit der Cloud-Infrastruktur können Sie die Rechenleistung und den Arbeitsspeicher nach Bedarf erhöhen und verringern. Sie schalten Test- und Entwicklungsserver aus, wenn sie nachts nicht verwendet werden, und zahlen stundenweise.

Wenn es um leistungsstarke Data Warehouse-Server geht, sind die Kosten für die interne Einrichtung (vor Ort) unerschwinglich. Die erforderlichen Fähigkeiten der Mitarbeiter sind ebenfalls unerschwinglich, da viele verschiedene Fachkenntnisse erforderlich sind, von SAN bis Sicherheit, von Docker bis Yarn. Daher würde ich eine Cloud-basierte Bereitstellung anstelle eines lokalen Data Warehouse empfehlen. Dies ist das Argument für die Verwendung von Google BigQuery, Amazon Redshift und Azure Dedicated SQL Pool (früher SQL DW, PDW, APS).

Angenommen, es handelt sich nicht um ein Greenfield-Projekt, und Sie müssen ein vorhandenes Data Warehouse, das vor Ort ist, mit vielen daran angeschlossenen On-Prem-Systemen erweitern. In diesem Fall sind die Kosten für die Migration all dieser Systeme / Anwendungen in die Cloud enorm. Nehmen wir an, es würde zusätzliche 2 Millionen US-Dollar und drei Jahre kosten, um diese Art von Projekt abzuschließen. Es ist wirtschaftlich nicht sinnvoll, diese 2 Millionen US-Dollar für keine zusätzlichen Geschäftsfunktionen auszugeben. Halten Sie es vor Ort, führen Sie die Verbesserung vor Ort durch und bauen Sie in der Zwischenzeit Ihr neues System langsam in der Cloud auf. Derzeit fließen rund 25% der IT-Budgets in die Wartung bestehender Systeme und Infrastrukturen. Dies ist der Pool, aus dem Sie ziehen sollten, um eine langsame Migration in die Cloud zu ermöglichen.

Ich habe gesehen, wie Sie die große Debatte zwischen ETL und ELT angesprochen haben. Gibt es einen Ansatz, den Sie beim Laden von Daten in das Data Warehouse bevorzugen? Oder muss es von Fall zu Fall entschieden werden?

Es muss von Fall zu Fall entschieden werden. Das hängt von der Infrastruktur ab. Es kommt auf den Datensee an. Dies hängt vom Datenerfassungstool ab. Und das hängt von der Data Warehouse-Plattform ab. Letztendlich spielt es keine Rolle, ob Sie ETL, ELT oder ELTLT verwenden. Sie können die Datenaufnahme auf verschiedene Arten durchführen. Sie können es einmal, zweimal oder gar nicht inszenieren. Verwandle es einmal, zweimal oder gar nicht. Sie müssen nur den am besten geeigneten Ansatz für jede Pipeline und jede Situation auswählen.

Unabhängig davon, ob es sich um ETL oder ELT handelt, ist das „Muss“ bei der Datenaufnahme das automatisierte Testen. Nimrod Avissar erklärt es gut . Das ist der Ansatz, den ich bei ETL / ELT bevorzuge: automatisierter Testansatz.

Was den Data Warehouse-Entwicklungsprozess selbst angeht, sind Sie der Meinung, dass Agile oder Wasserfall besser in der Lage sind, den sich ständig ändernden BI-Anforderungen gerecht zu werden?

Es geht nicht um Agilität oder Wasserfall (Agilität natürlich, wer möchte einen großen Teil auf einmal begehen?). Der Data Warehouse-Entwicklungsprozess befasst sich mit Entwicklungsvorgängen. Diese technische Disziplin ist jetzt ausgereift. Sie benötigen eine Release-Pipeline, ein Sprint-Board, ein Backlog, eine Quellcodeverwaltung, eine Änderungskontrolle, eine Fehlerprotokollierung und ein Incident Management. Ein Data Warehouse-Entwicklungsteam muss über eine DevOps-Automatisierung verfügen, dh der Freigabeprozess sollte von der Quellcodeverwaltung aus automatisiert werden, Anforderungen in den Freigabezweig ziehen, in einem Test bereitstellen, automatisierte Tests ausführen und in der Produktion bereitstellen.

CI / CD war früher mit der Anwendungsentwicklung verbunden, nicht mit der Data Warehouse-Entwicklung. Aber jetzt ist es ein Muss. Wenn Sie ein Data Warehouse-Entwicklungsteam ohne dieses Team betreiben, entstehen Ihnen jeden Monat viele zusätzliche Kosten. Oder schlimmer noch, die Qualität der Data Warehouse-Erstellung zu beeinträchtigen.

In Ihrem Blog haben Sie einige wichtige Elemente beschrieben, die die Effektivität Ihres Data Warehouse bestimmen, darunter Datenverfügbarkeit, Datensicherheit, Datenqualität und natürlich die Abfrage- / Ladeleistung. Welcher ist Ihrer Meinung nach der wichtigste Faktor?

Das wichtigste Element, das die Effektivität eines Data Warehouse bestimmt, ist, ob es geschäftliche Probleme und Anwendungsfälle angeht oder nicht. Letztendlich können Sie mit Ihrem DW Kundenberichte, Management-Dashboards, behördliche Berichte oder allgemeine Geschäftsanalysen erstellen. Wenn Ihr Geschäftsproblem jedoch nicht behoben werden kann, ist es einfach nicht effektiv. In diesem Fall kann ein Fehler normalerweise an eines von drei Dingen gebunden werden:

  1. Fehlen bestimmter Daten, z. B. Daten zu einem wichtigen Produkt oder Kunden,
  2. Datenqualitätsprobleme, z. B. falsche Daten,
  3. Schwierigkeiten beim Abfragen von Daten, z. B. befinden sich die Daten im Lager, werden jedoch nicht in Berichten angezeigt.

Ich würde sagen, dass falsche Daten für das Unternehmen besonders schädlich sind, insbesondere wenn sie auf der Grundlage dieser Daten Maßnahmen ergriffen haben. Wenn Sie beispielsweise die Performance-Daten des Lagers verwendet haben, um ein Fact Sheet zu erstellen, und die Performance des Fonds falsch angegeben haben, ist dies sowohl ein Reputationsrisiko als auch ein großes finanzielles Risiko. Dies kann nicht nur zu einer erheblichen Strafe für die Finanzbehörden führen, sondern Ihre Kunden könnten aufgrund der von Ihnen angegebenen irreführenden Zahlen den Ausstieg anstreben, was zu massiven Abflüssen und einer insgesamt düsteren Geschäftszukunft führt.

Im Vergleich dazu ist eine einstündige Abfrage, die den ganzen Tag ausgeführt wurde, nichts, fast kein finanzieller Schaden. Das gleiche gilt für das Fehlen bestimmter Daten (Datenverfügbarkeit). Dies ist kein so großes Risiko im Vergleich zu falschen Daten, die veröffentlicht / an Behörden oder Kunden gesendet werden. Wenn andererseits die Daten Ihrer Kunden gestohlen werden, kann dies auch das Vertrauen des Kunden schädigen und zu einem Exodus des Kunden führen, wodurch Sie auf absehbare Zeit kein Geschäft mehr haben.

Ich würde sagen, dass Datenqualität und Datensicherheit die beiden Hauptprobleme sind, vor denen Sie sich schützen müssen.

Sie haben auch einige der kritischen Schritte beim Aufbau eines Data Warehouse erläutert, z. B. Datenmodellierung, Erstellen von Prozessen zum Laden und Bereitstellen von Daten und anschließende Architektur dieser Prozesse, um maximale Effizienz sicherzustellen. Welcher Teil ist Ihrer Meinung nach der schwierigste Teil der Data Warehouse-Entwicklung?

Der schwierigste Teil der Data Warehouse-Entwicklung ist nicht die Datenmodellierung, das Laden von Daten oder die Prozesseffizienz, sondern die Bestimmung dessen, was Architektur ist am besten geeignet.

Wenn Sie sich für den Bau eines Datensees entschieden haben, während Sie wirklich ein dimensionales Data Warehouse benötigen (aufgrund seiner integrierten Natur), sind Sie von Anfang an in die falsche Richtung gegangen. Wenn Sie sich für eine bestimmte Aufnahmetechnologie entschieden haben, die keiner Ihrer Mitarbeiter bedienen konnte, haben Sie eine erhebliche Investition getätigt, die Ihr Risiko erhöht und vermeidbare Verzögerungen bei der Implementierung verursacht hat. Wenn Sie sich für ein vorgefertigtes Data Warehouse entschieden haben, das Datenmodell jedoch nicht zu Ihnen passte, war es, als würden Sie einen Wolkenkratzer auf einem schwachen Fundament bauen.

 Was wir hinter den Kulissen nicht sehen, ist das, was das Lager normalerweise zum Erfolg macht, dh die Wahl der Architektur, die Entwicklungsvorgänge und das Datenqualität Schecks.

Wo passt hier die Data Warehouse-Automatisierung hin? Wie kann es helfen, den Aufwand und die Zeit für einige dieser Aufgaben zu reduzieren? Wo sehen Sie den großen Wert eines speziell entwickelten Tools?

Der Wert der Data Warehouse-Automatisierung ist das automatische Laden. Beispielsweise verwenden viele Vermögensverwaltungsunternehmen weit verbreitete Standard-Anlageverwaltungssysteme, um ihre Portfolios zu verwalten. Ein dimensionales Data Warehouse, das automatisch Daten von ihnen laden kann, hat viel Wert. Viele große Fertigungsunternehmen verwenden SAP als Kernbetriebssystem. Ein Data Warehouse, das automatisch Daten aus SAP laden kann, ist wertvoll, da Sie keine Pipelines zum Laden der Daten entwickeln müssen, was viel Zeit in Anspruch nimmt. In jedem Fall müssen Sie in der Lage sein, das Maßmodell nach Belieben zu ändern.

Das nächstbeste ist, zu versuchen, die Datenaufnahme zu automatisieren. Die Integration mehrerer Datenquellen in eine Dimension ist komplex (z. B. Kundendimension, Unternehmensdimension, Sicherheitsdimension), und die Automatisierung ist noch schwieriger. Es könnte sich um vertikale oder inkrementelle Dateien, CSV- oder Excel-Dateien handeln. Wir müssen in der Lage sein, diese Daten zu schwenken, zu aggregieren und zusammenzuführen.

Wir dürfen auch nicht davon ausgehen, dass die Datenquelle eine Datei ist, die zur Verarbeitung bereit ist. Möglicherweise muss es zuerst entschlüsselt, entpackt, umbenannt oder heruntergeladen werden. Der Kern der Integration von Daten aus mehreren Quellen besteht aus einem Prozess, der als „Datenabgleich“ bezeichnet wird, und es kann sich um einen Wasserfallabgleich nach mehreren Kriterien handeln. Der zweite Kernprozess wird als „Datenanreicherung“ bezeichnet. Wenn das Wertpapier beispielsweise kein S & P-Rating, kein Risikoland oder keinen GICS-Sektor hat, wird es von einer externen Quelle wie Bloomberg oder FactSet angereichert.

Der Kernwert eines Data Warehouse ist die integrierte Dimension, die aus vielen Quellen erstellt wird. Ein Data Warehouse-Automatisierungstool muss in der Lage sein, diese Dimension zu erstellen, nicht eine Länder- oder Währungsdimension, sondern eine Kunden- oder Sicherheitsdimension, die aus mehreren Quelltabellen besteht.

Welche Features und Funktionen sind Ihrer Meinung nach für ein effektives Data Warehouse-Automatisierungstool unbedingt erforderlich?

Die Funktionen, die für ein effektives Data Warehouse-Automatisierungstool unbedingt erforderlich sind, sind:

  1. Es muss mit ERP, CRM oder IMS (z. B. SAP, Salesforce oder ThinkFolio) auf dem neuesten Stand sein, wenn Versionen geändert werden
  2. Es muss in der Lage sein, mehrere Quellen zu integrieren, um komplexe Dimensionen zu erstellen, dh die Kundendimension
  3. Es muss in der Lage sein, Datendateien vorzuverarbeiten, z. B. Dateien zur Verarbeitung abzurufen oder herunterzuladen.
  4. Es muss ein automatisiertes Testen und Bereitstellen ermöglichen

Wo sehen Sie das Data Warehouse in der Zukunft? Welche bedeutenden Fortschritte (falls vorhanden) sehen Sie in diesem Bereich?

Einige Leute denken, dass sie zwei Jahre Data Warehouse-Entwicklung durch eine dreimonatige Data Lake-Entwicklung ersetzen können. Dies täuscht, weil die Kunden- oder Produktdaten, die in die letztere Architektur geladen werden, nicht integriert sind und daher nicht abfragbar sind. Und sie vergessen möglicherweise, Datenqualitätsprüfungen oder Betriebsbereitschaft (z. B. Überwachungstools) in das System einzubauen, was andernfalls 30% des gesamten Aufwands in Anspruch nehmen würde. Zugegeben, einige Projekte müssen nicht integriert werden. In diesem Fall kann ein Datensee verwendet werden. Sie müssen jedoch weiterhin Datenqualitätsprüfungen und Betriebsbereitschaft erstellen.

Was ich in Zukunft sehe, ist die Automatisierung von Tests und die Automatisierung von Datenqualitätsprüfungen. Es ist nicht allzu schwierig, ein Tool zu erstellen, das jede eingehende Datei überwacht, bestimmte Spalten überprüft und sie mit den Daten der letzten Tage vergleicht. Das andere, was erstellt werden könnte, ist ein BI-Tool, das CI / CD-freundlich ist, z. B. XML-basiert, sodass es automatisch von der Quellcodeverwaltung zur Produktion bereitgestellt werden kann, da es textbasiert ist.

Und schließlich gibt es bisher kein einziges Data Governance-Tool auf dem Markt, das Datenbanken, ETL- und BI-Tools scannen und automatisch erstellen kann Datenherkunft von den Quelldateien zum Bericht. Es ist möglicherweise nicht möglich, dieses Tool für jede einzelne Datenbank, ETL und BI-Tool zu erstellen, aber es ist möglich, die wichtigsten zu erstellen. Der Schlüssel zur Datenverwaltung ist die Automatisierung.

Astera DW Builder - Eine agile Antwort auf Ihre Data Warehouse-Entwicklungsherausforderungen

Astera DW Builder ist eine einheitliche Plattform, mit der Sie schnell mit Metadaten angereicherte Datenmodelle bereitstellen und nutzen können, die von den Anforderungen der Endbenutzer abhängen.

Das Produkt bietet eine Reihe von sofort einsatzbereiten Funktionen, mit denen Sie ein agiles Data Warehouse aufbauen können, das die Anforderungen Ihres Unternehmens wirklich erfüllt. Von der Implementierung von Geschäftsregeln und Namenskonventionen auf logischer Ebene bis zur Erstellung komplexer Datenpipelines, mit denen Daten automatisch von den von Ihnen ausgewählten Quellsystemen abgerufen, entsprechend Ihren Datenqualitätsanforderungen transformiert und in eine Cloud oder eine lokale Datenbank Ihrer Wahl geladen werden können All dies wird durch unsere No-Code-Lösung ermöglicht.

Jetzt geben wir Ihnen die Möglichkeit, sich in einer End-to-End-Einführungsveranstaltung, die verspricht, Ihre Denkweise über Data Warehousing zu verändern, einen exklusiven ersten Einblick in die Geschwindigkeit und Intuitivität von ADWB zu verschaffen. Beobachten Sie die exklusives Launch-Event hier.