Die automatisierte, Kein Code Datenstapel
Erfahren Sie, wie Astera Data Stack kann die Datenverwaltung Ihres Unternehmens vereinfachen und rationalisieren.
Fragen und Antworten mit Barry Devlin zu automatisierten Datenpipelines
Automatisierte Datenpipelines sind ein entscheidender Teil des Data Warehousing-Puzzles. Sie ermöglichen es modernen Unternehmen, genaue und qualitativ hochwertige Daten zu pflegen, die ihre BI- und Analyseinitiativen vorantreiben. Wir haben vor kurzem gestartet Astera DW Builder, ein robuster Data Warehouse Builder, der den Aufbau, die Orchestrierung und das Management von Datenpipelines radikal beschleunigt, um schnellere, datengesteuerte Entscheidungen zu ermöglichen.
Astera Die selbstregulierenden Datenpipelines von DW Builder ermöglichen es Ihnen, Ihr Data Warehouse nahtlos mit unternehmensübergreifenden Daten zu füllen. Mit den automatisierten ETL- und ELT-Funktionalitäten des Produkts können Sie die Datenreise von der Quelle bis hin zu Erkenntnissen mit minimalem manuellen Aufwand abdecken.
Wir hatten vor kurzem die Gelegenheit, mit Barry Devlin zu sprechen, einer führenden Autorität in allen Bereichen des Data Warehousing, von Best Practices für Business Intelligence bis hin zu Big Data und darüber hinaus. Hier sind einige der Erkenntnisse, die Barry zu wichtigen Überlegungen für das Datenpipelining in der modernen EVW gegeben hat.
Moderne Data Warehouses verarbeiten riesige Datenmengen. Gibt es Best Practices, die Sie empfehlen, wenn es um den Aufbau von Datenpipelines geht, die diese großen Datenmengen aktiv bereitstellen können?
Nun, bevor ich über Best Practices spreche, möchte ich vorab eine Best Practice ansprechen, die darin besteht, einige der Ausdrücke zu definieren und auszuarbeiten, die wir hier verwenden werden. [Das liegt daran], dass es auf dem Markt derzeit sehr viele verschiedene Bedeutungen von Schlüsselwörtern und Phrasen gibt.
Erstens, Datenpipelines, viele Leute verwenden diesen Begriff, um einen vollständigen integrierten Weg von den Quelldaten bis hin zu den von den Geschäftsleuten verwendeten Tools zu bezeichnen. Ich sehe, dass Ihre Verwendung des Begriffs weniger auf den Weg von der vollen Suppe zu den Nüssen ausgerichtet ist, sondern eher auf die Möglichkeit einer kürzeren Pipeline zwischen beispielsweise verschiedenen Komponenten wie einer SAP-Instanz und einem Website-Clickstream zu einem Enterprise-Data-Warehouse. Ich glaube, dass dies ein besserer Ansatz ist und der wahrscheinlicher ist, dass er erfolgreich ist.
Zweitens stellt sich die Frage, was wir meinen, wenn wir von Data Warehouse sprechen. Denn es gibt viele gegensätzliche Ansätze. Wenn ich also Data Warehouse sage, meine ich in den meisten Fällen eine zweischichtige Struktur, die aus einem Enterprise Data Warehouse, einem EDW und einer lockeren dritten Normalform – oder heute wahrscheinlicher, Data Vault-Modell – besteht, die mehrere Data Marts speist. viele davon können dimensionaler Natur sein. Und das schließt andere Strukturen nicht aus, von denen die meisten eine Vereinfachung dieses zweischichtigen Ansatzes sind.
Schließlich werde ich den Begriff „Daten- oder Informationsaufbereitung“ verwenden, um alle Arten der Verarbeitung wie ETL, ELT, Streaming, Data Warehouse-Automatisierung und sogar Datenvirtualisierung abzudecken, da all diese letzteren Begriffe spezifische Instanzen der Aufbereitung von Daten und Informationen oder der technische Ansätze dazu.
Lassen Sie mich, nachdem ich dies im Voraus gesagt habe, über die Best Practices sprechen, nach denen Sie mich gefragt haben, und ich werde mich auf drei beschränken, aber es gibt noch viel mehr.
Als erstes würde ich sagen, einfach zu bedienende, umfassende Tools und Automatisierung – und das ist ziemlich offensichtlich. Die Datenvorbereitung [Vorbereitung] ist der teuerste Teil eines Data Warehouse. Das Einrichten von Programmierteams, um mehrere inkonsistente und nicht wartbare maßgeschneiderte Lösungen zu erstellen, gehört oder sollte der Vergangenheit angehören. Das ist Punkt eins.
Die zweite Best Practice lautet: Richten Sie die Designphase richtig ein, indem Sie das Unternehmen eng und kontinuierlich in den Prozess einbeziehen. Das bedeutet iterativ, agile Entwicklungsansätze [d. h.] weniger auf die Bereitstellung von Business-Apps, sondern mehr auf die Bereitstellung nützlicher Teile des Data-Warehouse-Informationsumfangs.
Und drittens würde ich Wartungs- und Änderungsmanagement sagen. Dies sind wichtige Funktionen, die oft vernachlässigt werden. Konzentrieren Sie sich also darauf, sicherzustellen, dass Upgrades und Wartung frühzeitig berücksichtigt werden, und richten Sie einen Prozess ein, der eng mit dem ursprünglichen Design und Build verknüpft ist.
Um auf meinen ersten Punkt zurückzukommen, spielen Werkzeuge und Automatisierung dabei eine zentrale Rolle. Es gibt also drei Best Practices, die meiner Meinung nach in diesem Bereich sehr wichtig sind.
ETL ist seit den Anfängen der Technologie ein Synonym für Data Warehousing. Wie hat sich dieser Prozess im Zeitalter der sogenannten Big Data entwickelt, die wir heute haben? Welche Art von Innovationen sehen Sie, die die Kosten und die Komplexität des traditionellen ETL senken können?
Ich glaube, wir müssen immer aus der Geschichte lernen. Die Datenaufbereitung hat sich meiner Ansicht nach phasenweise entwickelt und beginnt mit häufigen Rückschritten. So wurden beispielsweise in letzter Zeit erste Data Lakes und Cloud-basierte Data Warehouses sehr oft über Skripte und ähnliche programmatische Lösungen in Hadoop befüllt. Das war eine große Enttäuschung für mich.
Es ist gut zu sehen, dass jetzt eine Neuausrichtung auf automatisierte Werkzeuge stattfindet. Der langfristige Trend geht von handgefertigten und maßgeschneiderten Lösungen zum Einsatz von ETL – und neuerdings auch von ELT-Tools. Dies wurde durch eine Verschiebung von der Batch-Bereitstellung von Daten zu einer Vielzahl von inkrementellen Bereitstellungsansätzen ergänzt, da das Datenvolumen steigt und das Geschäft immer mehr zeitnahe Informationen benötigt.
In den alten Tagen war ETL alles von Betriebssystemen, die oft altmodisch im Design mit vielen obskuren Codes waren. Das Verständnis der Komplexität sowie der tiefgreifenden Geschäftsregeln, die veraltet waren, aber immer noch im System vorhanden waren, war eine Schlüsselanforderung für einen ETL-Programmierer.
Und dann war da die absolute Forderung, die Auswirkungen auf die Betriebssysteme zu begrenzen, sowohl in Bezug auf Design als auch auf Leistung. ETL-Ingenieure mussten tiefgreifende Experten in den mysteriösen Strukturen und Inhalten dieser alten Quellsysteme sein.
Die gute Nachricht ist jetzt, dass die Betriebssysteme oft besser gestaltet, moderner und manchmal cloudbasiert sind. Sie müssen sich also weniger mit arkanen Systemen befassen und konzentrieren sich mehr auf innovative Design- und Zielsysteme. Natürlich senkt [es] die Kosten und die Komplexität der Datenaufbereitung.
Externe Datenquellen wie das Internet der Dinge (IoT) führen jedoch zu neuen Anforderungen sowohl in Bezug auf die Aktualität der Daten als auch auf die Art der beteiligten Analysen. Auf technischer Seite müssen wir also auch Streaming- versus Batch-Load- oder Replikationsansätze berücksichtigen.
Weniger archaische Quellen ermöglichen auch einen Wechsel von maßgeschneiderten, handcodierten Transformationen hin zu einem eher modell- oder metadatengesteuerten Ansatz der Informationsaufbereitung, die wirklich das Herzstück der Data Warehouse-Automatisierung ist.
Sie haben ein paar Mal erwähnt, dass ELT ein neuerer Ansatz ist, der sich durchgesetzt hat. Wie sehen Sie das in Bezug auf ETL? Handelt es sich dabei um komplementäre Ansätze oder geht es hier um eine Versus-Sache?
Ich denke, es gibt viele Fragen dazu, aber zuerst möchte ich nur etwas sagen, dass ETL meiner Meinung nach in den frühen Tagen eine wirklich unglückliche Terminologiewahl war. Extrahieren, transformieren und laden – weil es sich auf die Abfolge von Aktionen konzentriert und nicht auf den Gesamtprozess, weshalb ich lieber den Begriff Daten- oder Informationsaufbereitung verwende.
Die Reihenfolge oder der Ort der Schritte ist mir weniger wichtig, als wie wir sie tatsächlich ausführen. Hoffentlich auf eine metadatengesteuerte Weise. Es ist also auch erwähnenswert, dass die Transformation der komplexeste und wichtigste Schritt des Prozesses ist, und das Verständnis, wo sie stattfindet, erweist sich als ein wichtiger Aspekt beim Design.
Also, das sagte und zurück zu deiner Frage. ELT – extrahieren, laden und transformieren – bedeutet einfach, dass die Transformation in der Zielumgebung unter Verwendung der Rechenleistung [der] Ansätze wie einer dort gefundenen relationalen Datenbank erfolgt. Ist das gut? Ja. Meist.
Das Transformieren auf dem Quellsystem, das vielleicht als transform, extrahieren und laden [TEL] bezeichnet werden sollte, wird immer bis zu einem gewissen Grad durchgeführt, wurde aber in der Vergangenheit auf das absolute Minimum beschränkt, um die Auswirkungen des Quellsystems zu reduzieren. Die Transformation auf ein Zwischensystem – ETL – war dann eine naheliegende Wahl, um die Auswirkungen auf Quell- und Zielsysteme zu minimieren.
Zielsysteme, insbesondere in der Cloud, haben jedoch wenig oder keine Leistungseinschränkungen und das relationale Ziel-DBMS verfügt über gute Transformationsfähigkeiten, sodass ELT sehr sinnvoll ist, und ja, ich denke, sie ergänzen sich und insbesondere scheint ein Ansatz, der ETL und ELT kombiniert, zu sein für mich die flexibelste und leistungsstärkste, insbesondere wenn es eine gewisse Intelligenz und Automatisierung bei der Auswahl gibt, wann und unter welchen Umständen die Funktion vom ETL-Server übertragen wird [dh] dort, wo sie zuerst definiert und zum Zielsystem ausgeführt wird. Also unbedingt! Keine Frage der Wahl zwischen den beiden. Ich denke, sie können beide nebeneinander existieren, und ich denke, das ist ein wirklich guter Ansatz.
Wie stellen Sie sicher, dass korrekte Daten in Ihr Data Warehouse eingebracht, kombiniert und optimal für die Anforderungen von Reporting und Analytics transformiert werden? Welche Tipps würden Sie Organisationen geben, die die Qualität der Daten in ihrem Enterprise Data Warehouse sicherstellen möchten?
Oh, das sind tolle Fragen. Ich meine, Qualität ist zentral für alle Formen der Entscheidungsfindung auf der Grundlage von Daten oder ich würde sagen, richtigere Informationen. Daher ist für mich immer eine gründliche und qualitativ hochwertige Daten- oder Informationsmodellierung das Erste. Ich weiß, dass manche Leute die Hände heben und sagen: „Oh, zu langsam [und] zu teuer. Lassen Sie uns ein Schema beim Lesen erstellen.“ Aber ehrlich gesagt, ich glaube, es gibt keinen anderen Weg, um hochkonsistente Daten in Ihrem Warehouse zu erhalten, als im Voraus zu modellieren.
Das ist also wirklich wichtig, und ich denke, diese Modellierung kann und muss in Etappen erfolgen – ein agiler schrittweiser Ansatz. Das ist ein riesiges Thema und wahrscheinlich für einen anderen Tag. Ich weiß, dass sich viele Unternehmen für einen volldimensionalen Data-Warehouse-Ansatz entschieden haben, der für mittelständische Unternehmen ideal sein kann.
Aber für größere Unternehmen ist ein konsistenter Speicher von abgeglichenen Kerndaten und EDW im Allgemeinen vorzuziehen, um Daten und Informationen in optimaler Qualität zu erstellen und zu pflegen. Und schließlich – neben der Modellierung ist der Einsatz eines guten und flexiblen Modellierungsteams wahrscheinlich der zweitwichtigste Aspekt bei der Implementierung einer erstklassigen Datenaufbereitungsumgebung.
Insbesondere in mittelgroßen Unternehmen würde ich vorschlagen, dass ein Ansatz zur Data Warehouse-Automatisierung sowohl in Bezug auf Qualität als auch Kosten wahrscheinlich am besten ist, da dies in der Regel den Modellierungsschritt im Prozess der Weiterentwicklung umfasst.
[Sagen Sie] diese Architektur, die Sie haben, ist gebaut. Sie haben mehrere Datenpipelines, die aus einer Vielzahl von Quellsystemen stammen. Sie haben natürlich Betriebssysteme erwähnt, vielleicht IoT-Streams, [also] es gibt viele Möglichkeiten, wenn Sie über das moderne Unternehmen sprechen. Hier arbeiten unterschiedliche Datenlatenzen und in vielen Fällen Abhängigkeiten. All dies zu orchestrieren ist natürlich eine schwierige Aufgabe. Was würden Sie sagen, sind die wesentlichen Elemente, um diesen Teil der Gleichung richtig zu machen?
Nun, zunächst möchte ich sagen, dass wir, wie Sie bereits erwähnt haben, immer mit mehreren Datenpipelines aus verschiedenen Quellsystemen mit unterschiedlichen Datenlatenzen und Abhängigkeiten zu tun hatten – sicherlich in großen Unternehmen, mit denen ich zu tun hatte.
Ich denke, der wichtigere Aspekt heute, und Sie haben es erwähnt, ist, dass wir riesige Mengen an Rohdaten aufnehmen und analysieren möchten, und das sind oft schmutzige Daten – und es ist unbekannt, wie schmutzig sie sind – aus dem Web und dem Internet von Dinge. Und solche Daten haben ganz andere Eigenschaften als Betriebssystemdaten, die ich als prozessvermittelte Daten oder kurz PMD bezeichne, die bis, sagen wir, vor 10 Jahren die Hauptdatenquellen waren.
Angesichts dieses Unterschieds in der Datenqualität würde ich sagen, dass der Versuch, all diese neuen Daten in dasselbe Data Warehouse wie Ihr PMD zu übertragen, ein Fehler ist. Sie benötigen mehrere Säulen der Datenverarbeitung. Das alles habe ich in meinem Buch erklärt „Geschäftsintelligenz“, also wenn Sie dort tiefer eintauchen möchten, tun Sie dies bitte. Einige dieser Säulen werden traditionelle Data Warehouses sein, andere eher wie Data Lakes, aber alle werden natürlich mit Datenpipelines gespeist, wie ich zuvor im Interview definiert habe.
Der Schlüssel zu all dem, was gut funktioniert, ist natürlich sicherzustellen, dass die Daten in diesen Säulen gut miteinander verbunden, miteinander verbunden und abgestimmt sind, im Gegensatz zu dem, was wir in herkömmlichen Datensilos gesehen haben, und was Sie Orchestrierung über die Datenpipelines hinweg nennen, ist ein Schlüsselkomponente, um dies zu ermöglichen.
Dies bringt uns nun zurück zur Modellierung, aber auch zu Metadaten, denn ein wesentliches Element bei der Orchestrierung all dieser Pipelines sind Metadaten. Jetzt nenne ich es lieber kontextbezogene Informationen oder CSI, weil dieses Wort 'Meta' heutzutage ein wenig missbraucht wird, sogar Facebook hat es übernommen.
Diese Art von kontextbezogenen Informationen ist also in der Data Fabric Architecture von Gartner enthalten und erwähnt, und ist wirklich diese Idee, aktiv und aktiv gewartet und intern konsistent und auf sich ändernde Geschäftsabläufe ausgerichtet zu bleiben Intelligenz] dazu.
Es ist also wirklich wichtig, diese Vorstellung von aktiven Metadaten zu erhalten. Ich bin der Meinung, dass wir heute noch ziemlich weit davon entfernt sind, aber wir müssen uns wirklich darauf konzentrieren, weil ich denke, dass es entweder dieses ganze System wirklich zum Laufen bringen oder auseinanderfallen wird.
Sprechen wir also über das eigentliche Data Warehouse und wo es aufgebaut ist. Offensichtlich scheint die Cloud heutzutage der Ort zu sein, an dem jeder seine BI-Systeme verwendet. Welche Überlegungen sollten Unternehmensdatenteams beim Aufbau einer Datenpipeline für diese Plattformen berücksichtigen?
Ja, ich meine, alle reden von Cloud. In architektonischer Hinsicht ist die Cloud meiner Ansicht nach einfach ein weiterer Speicherpool, wenn auch riesig und stark verteilt, und wenn Ihre Datenvorbereitungstools Cloud-Quellen und -Ziele unterstützen, können Sie loslegen, oder? Nun, ich würde sagen, nicht ganz.
Es ist die verteilte Natur der Cloud, die Sie zuerst und immer im Hinterkopf behalten müssen. Die Datenverwaltung war viel einfacher, sage ich immer, wenn sich alle Ihre Daten in einem einzigen Mainframe befanden. Aber Kopien von Daten sind der Fluch der Data Governance, und je mehr Orte und je weiter diese Kopien voneinander entfernt sind, desto schwieriger wird die Herausforderung. Die Cloud ermöglicht und – in gewissem Maße – fördert die Datenduplizierung, einige davon [ist] weitgehend unsichtbar.
Daher ist mein erster Rat in Bezug auf die Cloud, Ihre Data-Governance- und Management-Teams zu verstärken, weil sie wirklich gebraucht werden. Die zweite Überlegung ist die sogenannte Datengravitation. Woher stammen die Daten?
Wenn es lokal kommt, fallen Kosten an, um es in die Cloud zu heben. [Und] wenn es aus der Cloud kommt, ist es im Allgemeinen effektiver, es dort zu behalten.
Natürlich verfügen die meisten Unternehmen heute über Daten aus beiden Quellen, sodass es keine einzige richtige Antwort darauf gibt, wo Ihre Daten gespeichert und verarbeitet werden sollen. Aber offensichtlich ist der Druck groß, es in die Cloud zu bringen, oft aus finanziellen Gründen. Aber hier ist der Raub – die Hauptsache hier ist, die relativen Kosten der Speicherverarbeitung und des Datentransports im Auge zu behalten, und ich denke, letzteres kann Sie einholen, insbesondere wenn es um Datenaufbereitung und Datenpipelines geht .
Kommen wir also zur letzten Frage, und ich denke, es ist diejenige, die wir auf unterschiedliche Weise und in einigen früheren Antworten umgangen und erwähnt haben, aber um nur eine ungefähre Angabe zu machen, wo die Automatisierung Ihrer Meinung nach in all das passt? Wie kann es den Prozess des Aufbaus und der Pflege von Datenpipelines effizienter machen?
Ja, ich glaube du hast recht. Alles deutet jetzt in Richtung Automatisierung. Wie ich bereits sagte, bin ich ein großer Befürworter der Automatisierung in der Daten- und Informationsaufbereitung. Trotzdem bin ich in anderen Bereichen sehr misstrauisch gegenüber Automatisierung, insbesondere dort, wo lebensbeeinflussende Entscheidungen getroffen werden, und ich denke, wir müssen dort mit der Automatisierung vorsichtig sein.
Aber zurück zur Datenvorbereitung, ich denke, alles, was die Kosten für das reduziert, was effektiv nur Sanitär ist, ist sehr willkommen. Und die Automatisierung sollte nach Möglichkeit in jeder Phase des Prozesses angewendet werden – von der ersten Spezifikation und dem Design über den täglichen Betrieb bis hin zur laufenden Wartung und dem Änderungsmanagement.
Das ist ein sehr weites und sehr breites Spektrum dessen, was wir tun und automatisieren müssen. Ich werfe einfach keinen Vorbehalt ein, wissen Sie, basierend auf meiner langjährigen Erfahrung, und das ist, dass die Automatisierung Sie tendenziell zu vordefinierten Transformationsfunktionen drängt, und sie sind großartig! Die Fähigkeit, benutzerdefinierte Transformationen zu erstellen, die für Ihre eigene Umgebung einzigartig sind, ist jedoch oft der Schlüssel zum Erfolg von Datenvorbereitungstools im eigenen Haus.
Dieser Bedarf liegt möglicherweise nur bei fünf Prozent oder weniger als bei den [vordefinierten] Transformationen, aber ihre Bedeutung wird oft leicht unterschätzt, da sie aus geschäftlicher Sicht oft die wichtigsten Transformationen sind.
Aus meiner Sicht müssen Data Warehouse-Automatisierungstools es ermöglichen, diese sehr spezifischen Transformationsroutinen zu entwickeln und in den Workflow einzubetten. Die Automatisierung bietet jedoch die Möglichkeit, die sich wiederholenden und gemeinsamen Teile des Datenaufbereitungsprozesses zu reduzieren oder zu eliminieren. Und Data Warehouse-Automatisierungstools ergänzen auch die menschlichen Aspekte des Prozesses.
Ich denke hier an Anforderungsdefinition, Konsensbildung, Änderungsmanagement und so weiter. In diesem Sinne ist DWA ein bisschen wie künstliche Intelligenz, da sie sowohl Aspekte der Automatisierung als auch der Erweiterung enthält. Ich denke, das ist ein besonders wichtiger Aspekt dessen, worüber wir nachdenken müssen.
Abschließend möchte ich sagen, dass ich immer das Gefühl hatte, dass Data Warehouse-Automatisierung wie ETL eine unglückliche Namenswahl für diese Klasse von Tools war, da diese Tools mehr als nur Automatisierung leisten, wie ich gerade sagte, und sie können und müssen weitreichend angewendet werden eine breitere Palette von Datenspeicher- und -verwaltungssystemen als nur Data Warehouses.
Alle Teile des Namens haben ihre Schwächen. Also, wie soll der Name lauten? Ich weiß es nicht wirklich, es sei denn, Sie möchten versuchen, es das Schweizer Taschenmesser der Datenverwaltung zu nennen, und ich denke, das ist wahrscheinlich ein guter Ort, um aufzuhören.
Astera DW Builder: Automatisieren Sie Ihre Datenpipelines
Astera DW Builder ist eine einheitliche Data Warehousing-Lösung, mit der Sie eine metadatengesteuerte Datenpipeline-Architektur erstellen können. Die End-to-End-Plattform bietet eine Zero-Code-Umgebung, um Ihr Data Warehouse auf einer logischen Ebene zu entwickeln und Ihre Design- und Engineering-Prozesse zu automatisieren, um umfassende Einblicke zu erhalten, die Ihre Business Intelligence-Anforderungen erfüllen.
Die agile, automatisierte Lösung verfügt über erstklassige ETL- und ELT-Funktionen, einschließlich integrierter Komponenten zur Workflow-Orchestrierung und Jobplanung, um selbstregulierende Datenpipelines aufzubauen. Nehmen Astera DW Builder für eine Probefahrt um zu erfahren, wie es dazu beitragen kann, genaue und zuverlässige Daten für Ihre BI- und Berichtsarchitektur bereitzustellen.
