Insider-Einblicke zur modernen Data Warehouse-Entwicklung mit James Serra

Mit der Offizieller Start unserer End-to-End-Data-Warehousing-Lösung Astera DW Builder haben wir einen viel schnelleren und agileren Weg zum Entwerfen und Bereitstellen von Data Warehouses eingeführt. Aber das ist erst der Anfang. Wir planen im Laufe des nächsten Jahres einige wichtige Ergänzungen und Aktualisierungen des Produkts, die jedem Unternehmen, das die Probleme der herkömmlichen Data Warehouse-Entwicklung umgehen möchte, einen einzigartigen Mehrwert bieten werden.

Für unser drittes Interview in dieser Serie haben wir uns entschieden, uns mit jemandem zusammenzusetzen, der seine Karriere darauf aufgebaut hat, diese Herausforderungen zu erkennen, zu antizipieren und erfolgreich zu lösen, während er gleichzeitig Data Warehousing-Projekte für Microsoft und derzeit Ernst & Young leitet. Als einer der führenden Vordenker in diesem Bereich hat James Serra eine Reihe von Themen von BI und Datenarchitekturen bis hin zu Big Data und Analytics in seinem beliebten Blog und bei Vortragsveranstaltungen auf der ganzen Welt.

In diesem Interview haben wir mit James über einige der Erkenntnisse gesprochen, die er während seiner Zeit in der Branche gewonnen hat, die Entwicklung von Datenarchitekturen im Zeitalter von Big Data und wie die Zukunft des Data Warehouse aussehen könnte.

 

Können Sie mir etwas über Ihr Engagement im Bereich Data Warehousing erzählen? Wann haben Sie zum ersten Mal in diesem Bereich gearbeitet und welche Rollen haben Sie im Laufe der Jahre im Entwicklungsprozess gespielt? 

Ich habe vor vielen, vielen Jahren mit Datenbanken in den 80er Jahren angefangen. Der anfängliche Fokus lag auf Microsoft SQL Server, zuerst SQL Server 1.0, dann OS 2.0 im Jahr 1989, glaube ich. Das waren also eher transaktionale Datenbanken mit vielen Aktualisierungen, Einfügungen und Löschungen.

Vor vielleicht 20 Jahren habe ich mich zum ersten Mal mit Data Warehousing beschäftigt. Ich arbeitete als DBA in einem Unternehmen und sie wurden mit dem Aufbau eines Data Warehouse beauftragt. Damals wusste ich sehr wenig über die Technologie, aber das Data Warehouse wurde auf SQL Server gebaut, also habe ich mich in den Prozess eingebunden. Das war eine meiner ersten Erfahrungen beim Aufbau eines echten Data Warehouse, dh das Einlesen von Daten aus all diesen verschiedenen Quellen und das Erstellen von BI-Berichten darüber.

Seitdem hatte ich viele verschiedene Jobs – ich arbeitete als Berater an vielen verschiedenen Arten von Datenbanken immer im Microsoft-Bereich, angefangen bei SQL Server und dann kam Azure, dann gab es SQL Database, SQL Data Warehouse und jetzt Synapse, die ich in den letzten Jahren fast ausschließlich verwendet habe.

 

Offensichtlich verfügen Sie über umfangreiche Erfahrung im Aufbau von Datenarchitekturen sowohl bei Microsoft als auch jetzt bei EY. Was sind Ihrer Meinung nach die häufigsten Anwendungsfälle für Data Warehousing? Mit anderen Worten, warum wollen diese Unternehmen ein Data Warehouse aufbauen?

Unternehmen wollen vor allem bessere Geschäftsentscheidungen treffen. Dazu müssen sie alle möglichen Daten haben. Anstatt also zu versuchen, jede ihrer Betriebsdatenbanken einzeln aufzurufen und Berichte zu erstellen, können sie einen Mehrwert erzielen, wenn sie all diese Daten zusammenfassen.  

Angenommen, sie haben Kundeninformationen in einem CRM-System gespeichert, dann haben sie Kundensupportinformationen separat in einem anderen System gespeichert, noch eine weitere Plattform zum Verwalten von Vertriebsinformationen und ein ERP-System, das auch Kundeninformationen enthält. Sie haben diese Daten alle separat gespeichert und möchten sie natürlich sammeln und verwenden, um historische Trends zu identifizieren, damit sie beispielsweise Gründe finden können, warum Kunden in bestimmten Regionen des Landes nicht kaufen. Mit einem Data Warehouse können sie hineingehen, tiefer graben und herausfinden, was vor sich geht.

In jüngerer Zeit geht es nicht nur um historische Trends, sondern auch um den Blick in die Zukunft, hier kommen KI und maschinelles Lernen ins Spiel. Unternehmen wollen heute nicht nur sehen, wo sie waren, sondern auch wohin sie gehen , weshalb Predictive Analytics zu einer großen Sache wird. Wenn wir also diese Kundeninformationen von früher nehmen und sagen, dass wir sie verwenden möchten, prognostizieren Sie die Wahrscheinlichkeit, dass ein Kunde verlässt. Ein Modell für maschinelles Lernen kann basierend auf allen gesammelten Daten eine Wahrscheinlichkeit von 70 % schätzen, dass der Kunde das Unternehmen verlässt. Jetzt können Sie als Entscheider also proaktiv Maßnahmen ergreifen und etwas dagegen tun, wie zum Beispiel einen Coupon senden, um sich die Treue zu sichern.  

Im Grunde genommen ist es die Sammlung all dieser Daten, die es dem Endbenutzer/Analysten ermöglicht, Berichte zu erstellen und dann die Ausgaben zu zerlegen und zu würfeln, um bessere Geschäftsentscheidungen zu ermöglichen.

 

Wir haben also in den letzten zehn Jahren offensichtlich einen ziemlich signifikanten Anstieg des Volumens und der Vielfalt der Daten gesehen, die durch Unternehmen bewegt werden. Wie sehen Sie die Entwicklung des sogenannten traditionellen Data Warehouse, um diesen Anforderungen gerecht zu werden?

Als erstes würde ich Big Data also nicht nur als Größe der Daten definieren, sondern auch als Art und Geschwindigkeit der Daten. So viele Kunden, mit denen ich zusammengearbeitet habe, verarbeiten Terabytes an Daten, die sie zu konsumieren versuchen. Aber sie haben auch die Herausforderung, mit Daten in allen möglichen Formaten umzugehen, einschließlich Parkett, CSV, JSON sowie Daten, die sie möglicherweise in Echtzeit aus Social-Media-Feeds wie Twitter konsumieren möchten, sie möchten möglicherweise auch einige IoT-Daten abrufen pull da drin.

Jetzt stehen Sie also vor der Herausforderung aller drei Geschwindigkeitstypen und Datengrößen. Während in den letzten halben Dutzend Jahren Systeme auf den Markt kamen, die Big Data verarbeiten können, wie beispielsweise Azure Synapse in der Microsoft-Plattform, sind noch eine Reihe anderer Tools erforderlich, um ein modernes Data Warehouse aufzubauen. Diese Tools handhaben die Vielfalt, das Volumen und die Größe der Daten. Heutzutage können sie jede beliebige Kombination von Daten verarbeiten, sie abrufen, anpassen, bereinigen und beherrschen, bevor sie Berichte erstellen.

 

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?

Sie ergänzen sich definitiv. Als Data Lakes vor etwa zehn Jahren zum ersten Mal zum Einsatz kamen, befanden sie sich auf Hadoop und die Idee dahinter war, dass wir Big Data aufgrund ihrer Größe nicht effektiv erfassen konnten, halbstrukturierte oder nicht relationale Daten ebenfalls nicht. wirklich gut in eine relationale Datenbank passen. Also haben wir uns entschieden, es in den Data Lake zu legen und dort abzufragen. Das wurde zur Landezone für alle Arten von nicht-relationalen Daten, während relationale Daten noch in einer Datenbank gespeichert wurden.

Natürlich möchten die meisten Unternehmen die beiden Datentypen kombinieren, sodass die nicht relationalen/semistrukturierten Daten im Data Lake in die Datenbank verschoben werden müssen. Allerdings gab es schon früh Versuche, alles in den Data Lake zu legen, was zu einer Vielzahl von Problemen führte.

Der Ableger davon ist, dass wir erkannt haben, dass wir immer eine relationale Datenbank brauchen würden. Im Laufe der Zeit hat sich diese Denkweise weiterentwickelt, und wir verstehen jetzt, dass Sie neben der relationalen Datenbank einen Data Lake benötigen und dass jede ihre eigenen Stärken hat.

Wir können einen Data Lake so betrachten, dass er Daten unabhängig von Größe oder Typ verarbeiten kann, aber er hat einige Einschränkungen. Der Data Lake eignet sich nicht für extrem schnelle Abfragen, er eignet sich nicht für die Arten von Sicherheit, die Sie möglicherweise von Ihrer Datenarchitektur erwarten – wie Sicherheit auf niedriger Ebene oder Sicherheit auf Spaltenebene kann es für Ihren durchschnittlichen Endbenutzer auch schwieriger sein. Benutzer, um Daten abzufragen, die in einem Data Lake sitzen, weil sie schema-on-read sind, was bedeutet, dass es sich nur um einen glorifizierten Dateiordner handelt. Sie können jede Art von Daten dort ablegen und das kann es schwierig machen, sie herauszuziehen, wenn Sie dies nicht tun. nicht über die erforderlichen technischen Fähigkeiten verfügen. Hier kommt eine relationale Datenbank ins Spiel, da jemand in der IT die Arbeit übernimmt, die Daten zusammen mit den Metadaten zu speichern, sodass es für einen Endbenutzer viel einfacher wird, sie abzufragen. Wenn Sie also von einem Data Lake in eine relationale Datenbank und von 3NF in ein Star-Schema wechseln, können Endbenutzer jetzt problemlos Self-Service-BI durchführen, da sie einfach Felder aus der Datenbank ziehen und daraus Berichte oder Abfragen erstellen können.

Jetzt sind Tools wie Azure Synapse auf den Markt gekommen und machen es viel einfacher, Daten abzufragen, egal ob sie sich in einem Data Lake oder einer relationalen Datenbank mit normalem SQL befinden, und beide haben ihre Vor- und Nachteile. Letztendlich besteht die ganze Idee jedoch darin, Daten aus all diesen Quellen zu nehmen, sie zu verschieben und einige Arbeiten zur Vorbereitung zu erledigen, die zusätzliche Kosten verursachen können, aber am Ende erhalten Sie Daten, die so formatiert sind, dass sie viel einfacher für die meisten Endbenutzer. In der Zwischenzeit können Data Scientists und Power-User den Data Lake immer noch abfragen, aber für die meisten Benutzer möchten Sie eine relationale Datenbank zur Verfügung haben.  

 

Was wäre Ihrer Meinung nach der geschäftskritischste Aspekt der Data Warehouse-Entwicklung? Ist die Modellierung von Daten? Daten in das Data Warehouse laden? Stellen Sie sicher, dass das Data Warehouse für Ihre BI-Plattformen zugänglich ist?

All diese Aspekte sind äußerst wichtig, aber Data Governance ist wirklich der Hauptfaden beim Aufbau eines Data Warehouse. Das heißt, um sicherzustellen, dass die Daten korrekt und korrekt sind und eine einzige Quelle der Wahrheit für das Unternehmen darstellen. Denn das Schlimmste, was passieren kann, ist, dass Sie all diese Arbeit tun, um ein Data Warehouse zu erstellen und einen Bericht zu erstellen. Wenn ein Endbenutzer ihn zum ersten Mal sieht, sagt er, dass die Daten nicht korrekt oder falsch sind. Sie haben sofort ihr Vertrauen in das System verloren. Sie müssen also im Voraus sicherstellen, dass die Daten ordnungsgemäß verwaltet werden. Das bedeutet, dass es richtig bereinigt und gemastert wird und all die Dinge, die mit Data Governance einhergehen.

Fast genauso wichtig, wenn nicht sogar noch wichtiger, ist die Sicherheit. Heutzutage gibt es so viele persönlich identifizierbare Informationen, die in einem Data Warehouse landen könnten, und wenn Sie nicht die richtige Art von Sicherheit darin haben, könnten die Leute anfangen, Daten zu sehen, die sie nicht sollten. Das können persönliche Informationen, Verkaufszahlen oder andere Dinge sein, die Sie in große Schwierigkeiten bringen können, insbesondere wenn diese Daten außerhalb Ihres Unternehmens abgerufen werden. Jetzt sind Sie mit einem Verstoß auf der Titelseite des Wall Street Journal. Das ist die andere große Sache, die Sicherheit. Ich würde also sagen, dass diese beiden beim Aufbau eines Data Warehouse im Vordergrund stehen sollten.

In den letzten Jahren gab es große Anstrengungen, Data Warehouses auf Plattformen wie Azure Synapse, Google BigQuery oder Amazon Redshift in die Cloud zu verlagern. Was halten Sie von den Vorteilen der Cloud-Bereitstellung? Würden Sie in einigen Fällen dennoch empfehlen, bei lokalen Datenbanken zu bleiben?

Es fällt mir schwer, jemals eine Lösung zu sehen, die lokal sein sollte, es gibt nur noch sehr seltene Fälle, in denen dies eine praktikable Lösung ist. Es war zum Beispiel bei Microsoft, als ich vor 7 Jahren zum ersten Mal beigetreten bin, wo ich viele Gespräche über Cloud vs. On-Prem führte, aber in den letzten Jahren war es extrem selten, dass jemand über Letzteres sprechen möchte als mögliche Option.

Die seltenen Ausnahmen sind, wenn sich das Unternehmen an einem Ort befindet, der keinen Zugang zum Internet hat, wie beispielsweise in einer Mine oder einer Bohrinsel im Meer. Oder wenn es um Daten geht, die bei Abfragen und ähnlichem Millisekunden-Antwortzeiten benötigen, weil es in der Cloud zu einer gewissen Latenz kommen kann. Aber abgesehen davon hat, ist oder geht jeder aus zahlreichen Gründen in die Cloud, über die ich eine halbe Stunde reden könnte.

Es ist wichtig zu beachten, dass die Kosten bei diesem Schritt nicht immer im Vordergrund stehen, es sind andere Dinge wie die neuesten Funktionen eines Produkts oder der wahrscheinlich größte Vorteil, der die Möglichkeit bietet, schnell mit der Arbeit zu beginnen. Mit einem Cloud-Data Warehouse kann ich beispielsweise in Azure einsteigen und innerhalb von Minuten eine Datenbank fertig haben, während es bei On-Prem Tage, wenn nicht Wochen, wenn nicht sogar Monate dauern kann, um eine Datenbank auf einem Server zu bekommen. Ich kann mich also nicht erinnern, wann ich das letzte Mal einen Kunden getroffen habe, den ich auch vor Ort empfohlen habe. Sicher, es könnte ein paar Anwendungsfälle geben, wie ich oben erwähnt habe, aber diese sind dünn gesät.

 

Also, ich habe gesehen, wie Sie in den letzten Jahren einiges über Reverse ETL geschrieben haben. Wenn Sie das Konzept einfach zusammenfassen und ein wenig über die Vorteile sprechen könnten, die Ihrer Meinung nach dieser Ansatz bringt?

Ja, das ist ein ganz neues Konzept. Daher können einige Unternehmen Kundendaten in einem Dutzend verschiedener Quellsysteme haben, insbesondere wenn es sich um ein großes Unternehmen handelt. Angenommen, sie ziehen all diese Kundendaten, bereinigen sie und beherrschen sie (d. h. das Erstellen von Golden Records), da es mehrere Kopien des Kunden mit unterschiedlichen Schreibweisen geben könnte. Sie könnten auch Kundendaten aus einem System durch verschiedene Arten von Daten aus anderen Systemen ergänzen, z.

Nehmen wir also an, all diese Daten befinden sich jetzt im Data Warehouse und ich habe all diese Arbeit geleistet, um eine einheitliche Sicht auf den Kunden zu erstellen. Nun, das Problem ist, dass die Bereinigung auf Data Warehouse-Ebene durchgeführt wurde, aber die Quellsysteme, aus denen die Daten entnommen wurden, werden immer noch nicht bereinigt. Mit Reverse ETL kann ich nun die Data Warehouse-Daten zurück in das Quellsystem leiten und diese Kundendatensätze korrigieren. Aus diesem Grund sehe ich Reverse ETL immer beliebter, weil Sie all diese Arbeit im Data Warehouse erledigen, die Sie dann auf die Quellsysteme anwenden können, um sie zu korrigieren.

Der andere große Vorteil von Reverse ETL besteht darin, dass ich all diese Daten in ein Data Warehouse ziehe und BI-Berichte dazu erstelle und sage, dass es sich um ein Kundenansicht, nun, ich habe vielleicht viele Vertriebsmitarbeiter, die an diese anderen Betriebssysteme gewöhnt sind, dh ein CRM-System, in dem sie sich bereits Kundendaten ansehen und das sie bereits gerne verwenden. Jetzt bitten Sie sie, zu einem Data Warehouse zu gehen und ein anderes System, einen anderen Bericht zu verwenden, um sich dieselben Kunden anzusehen. Warum also nicht ETL umkehren und diese Daten aus dem Data Warehouse nehmen und in das Betriebssystem kopieren. Die Analysten können dann die Daten in dem System verwenden, mit dem sie sich am wohlsten fühlen. Sie müssen also nicht in das Data Warehouse gehen.

Dies ist ein weiterer Bereich, in dem Reverse ETL meiner Meinung nach sehr beliebt ist. Erledigen Sie die Arbeit in einem Data Warehouse, aber landen Sie die Daten dann in einem Betriebssystem, in dem sich die Endbenutzer am wohlsten fühlen.

 

Wenn Sie sich eine Data-Warehousing-Lösung für einen Kunden ansehen würden, welche der wichtigsten Funktionen würden Sie sich wünschen?

Ich habe im Laufe der Jahre eine Reihe von Data Warehouse-Automatisierungstools mit unterschiedlichem Erfolg verwendet. Einige von ihnen waren wirklich hilfreich, aber am effektivsten finde ich diejenigen, die nicht zu proprietär sind und eine Automatisierung bieten, die das Erstellen von Lösungen beschleunigt. Hier können sie sehr wertvoll sein.

Wenn Sie die Frage Build vs Buy abwägen, ob Sie Projekte komplett von Grund auf neu starten, empfehle ich immer, zuerst nach etwas zu suchen, das bereits gebaut wurde, und zu sehen, ob Ihnen das hilft. Dies könnte nun ein allgemeines Datenmodell oder ein Tool für die Data Warehouse-Automatisierung sein, das schnell das Data Warehouse für Sie erstellt. Wenn die Lösung dies mit gängiger Technologie kann, d. h. wenn dieses Automatisierungstool ein Data Warehouse für Sie erstellt, Sie das Data Warehouse trotzdem verwenden können, ohne gezwungen zu sein, das Drittanbieter-Tool zu verwenden, sind Sie auf dem richtigen Weg.

Die Data-Warehouse-Automatisierungslösung könnte beispielsweise mit einer bestimmten ETL-Software verbunden werden, um Pipelines zu erstellen, und nachdem sie diese Pipelines erstellt hat, können Sie sie selbst aktualisieren, ohne das DWA-Tool zu durchlaufen. Nehmen wir an, es verwendet ein Microsoft-Produkt für diese Aufgabe, das DWA-Tool kann möglicherweise nicht mit den Updates des ETL-Produkts Schritt halten. Nehmen wir also an, die Software erhält neue Funktionen, dann kann das Data Warehousing-Tool einige Zeit brauchen, um diese Funktionen zu nutzen, was natürlich schränkt die Funktionalität Ihrer Lösung ein. Es gibt auch die Frage der Fähigkeiten. Wenn Sie in Ihrem Unternehmen ein Data Warehouse-Automatisierungstool verwenden, müssen Sie möglicherweise Mitarbeiter einstellen, die bereits über die Erfahrung mit Drittanbietertools verfügen, um das Projekt voranzutreiben.

Insgesamt denke ich, dass DWA-Tools besonders hilfreich für Unternehmen sind, die neu im Data Warehousing sind und nicht über die besten Praktiken oder Standards verfügen und auch kein großes Team haben, um ihr eigenes Setup aufzubauen. Sie können schnell Ergebnisse erzielen und den Prozess abkürzen, indem sie ein vorgefertigtes Tool verwenden, um die Entwicklung zu beschleunigen.

 

Was halten Sie vom Konzept des agilen Data Warehouse? Im Grunde diese Idee, dass Data Warehousing ein Prozess und kein Endziel ist und dass Iteration so ziemlich das Herzstück jedes effektiven BI-Systems ist?

Als ich bei Microsoft war, sahen die Kunden es im Allgemeinen als eine Technologie, die Menschen und die Prozessseite waren etwas, mit dem sie sich selbst auseinandersetzen wollten. Natürlich ist es wichtig, dass alle diese Elemente vorhanden sind. Ob wir über die Schaffung eines Kompetenzzentrums für Data Governance oder über DataOps sprechen. Da sich das Erstellen einer Anwendung stark vom Erstellen eines Data Warehouse unterscheidet, unterscheide ich zwischen DevOps und DataOps.

In einem Data Warehouse haben Sie es mit so vielen Systemen zu tun. Du könntest sein ein Modell aktualisieren in einem Data Warehouse, zu einer ETL-Pipeline, zum Reporting. All diese Dinge müssen also koordiniert werden und hier kommt DataOps ins Spiel, und das ist enorm wichtig. Ich sehe viele Unternehmen, insbesondere EY, die dieses gigantische Data Warehouse aufgebaut haben und einem DataOps-Prozess folgen müssen, um sicherzustellen, dass das Produkt sowohl intern als auch außerhalb des Unternehmens verwendet wird , auch, dass es nicht kaputt geht, wenn ein neues Feature oder ein Bugfix eingebaut wird.

Daher sind Menschen und Prozesse manchmal der schwierigste Teil, während Technologie relativ einfach sein kann. Sie müssen also sicherstellen, dass alle diese Elemente vorhanden sind, um sicherzustellen, dass die fertige Lösung so fehlerfrei wie möglich ist und, wie ich bereits erwähnt habe, Genauigkeit der Daten bietet.

Abschließend: Wo sehen Sie das Data Warehouse in Zukunft? Welche großen Fortschritte (wenn überhaupt) sehen Sie in diesem Bereich?

Nun, um das zu berühren – ich denke, es wird einen viel größeren Fokus auf KI und insbesondere auf den Teil des maschinellen Lernens geben. Die Herausforderung beim Aufbau eines Data Warehouse besteht darin, Daten zu sammeln, zu bereinigen und dann irgendwo zu landen, egal ob es sich um einen Data Lake oder eine relationale Datenbank handelt. Für Kunden kann es Monate, wenn nicht sogar Jahre dauern, all diese Daten zu sammeln. Und das i-Tüpfelchen ist die Berichterstattung darüber, wenn Sie so etwas wie PowerBI verwenden, um Datensätze zu schneiden und zu würfeln. Momentan sind dort noch viele Kunden, die ihre Daten sammeln.

Die meiste Arbeit in diesem Bereich folgt einem hybriden Ansatz, da viele Unternehmen Datenquellen in der Cloud haben, aber viele Systeme noch vor Ort sind und sie alle in die Cloud ziehen müssen, was ihre eigenen Herausforderungen hat . Sobald Sie alle Daten gesammelt haben, können Sie daraus Berichte erstellen und ziemlich schnell einige Lösungen erhalten.

Der nächste Schritt besteht darin, maschinelles Lernen durchzuführen und Modelle zu erstellen, die mit den Daten in der Cloud trainiert werden können. Viele Kunden sind noch nicht da, sie sind noch in der Erfassungsphase und versuchen, Daten in das Data Warehouse zu bekommen. Der große Anstoß wird also sein, dass Kunden die Vorteile von ML-Modellen bei der Erstellung von Vorhersageanalysen für Dinge wie Kundenabwanderung oder für den Fall, dass ein Teil ausfallen wird, erkennen (IoT-Gerätedaten sind für diese Art der vorbeugenden Wartung sehr beliebt geworden). Aber auch hier ist es ein ziemlich großer Sprung, denn Sie brauchen Data Scientists und die notwendigen Produkte. Sicher, Lösungen mit automatisiertem maschinellem Lernen haben einen langen Weg zurückgelegt, um diesen Teil zu vereinfachen, aber Junk-in-Junk-out gilt immer noch. Sie brauchen immer noch jemanden, der die Konzepte der Data Science versteht.

Ich denke also, in den nächsten 2 Jahren werden Sie eine enorme Menge an Arbeit sehen, um diese Machine-Learning-Modelle zu erstellen, um noch mehr Wert aus den Daten zu ziehen als aus historischen Berichten.

Eine End-to-End-Lösung für die moderne Data Warehouse-Entwicklung

Astera DW Builder bietet eine einheitliche Plattform, die Benutzer nutzen können, um jeden Aspekt ihres Entwicklungsprozesses zu rationalisieren, von der anfänglichen Erfassung, Bereinigung der Daten bis hin zum Entwerfen von berichtsbereiten Datenmodellen, die Ihren Data Governance-Anforderungen entsprechen, und natürlich der Bereitstellung Ihrer Datawarehouse in der Cloud.

Mit ADWB müssen Sie sich nicht auf einen komplexen Technologie-Stack oder erfahrene technische Ressourcen verlassen, um Ihre Implementierung erfolgreich durchzuführen. Das Produkt bietet eine intuitive Drag-and-Drop-Oberfläche, unterstützt eine schnelle Iteration und funktioniert gleichermaßen gut mit einer Reihe von Quell- und Zielsystemen. Kontaktieren Sie unser Team um mit anzufangen Astera DW-Builder heute.