Die automatisierte, Kein Code Datenstapel
Erfahren Sie, wie Astera Data Stack kann die Datenverwaltung Ihres Unternehmens vereinfachen und rationalisieren.
Frage-und-Antwort-Runde mit Paul Kellett zu automatisierten Datenpipelines
Automatisierte Datenpipelines dienen als Rückgrat eines vollständig datengesteuerten Ökosystems. Sie ermöglichen es Unternehmen, Daten aus unterschiedlichen Quellen zu extrahieren, Transformationen anzuwenden und den Integrationsprozess effizient, zuverlässig und schnell durchzuführen. Immer mehr Unternehmen entscheiden sich für die Data Warehouse-Automatisierung, um die Datenanalyse zu verbessern und strategischer zu konkurrieren.
Wir haben vor kurzem gestartet Astera DW Builder, eine End-to-End-Data-Warehouse-Automatisierungsplattform, die eine iterative, codefreie Umgebung zum Entwerfen, Entwickeln und Bereitstellen von Datenpipelines mit beispielloser Geschwindigkeit bietet.
Um moderne Unternehmen über die selbstregulierende Datenpipeline aufzuklären, haben wir ein Live-Webinar mit dem Titel – Machen Sie Ihr Data Warehouse zukunftssicher mit selbstregulierenden Datenpipelines am November 2nd, wo wir eine großartige Gelegenheit hatten, mit Paul Kellett zu diskutieren. Er verfügt über mehr als 25 Jahre Erfahrung in der Arbeit an Business-Intelligence-Projekten auf Unternehmensebene für Unternehmen.
In unserer Q&A-Sitzung haben wir wertvolle Einblicke in den Aufbau hochwertiger, automatisierter Datenpipelines, moderne Data-Warehouse-Prozesse, Cloud-Data-Warehousing und mehr erhalten.
Afnan: Moderne Data Warehouses verarbeiten riesige Datenmengen. Würden Sie Best Practices empfehlen, die Benutzer verwenden sollten, um Datenpipelines zu erstellen, die diese großen Datenmengen effektiv an ihr Data Warehouse liefern können?
Paul: Ja, aber ich möchte auch hinzufügen, dass es nicht nur um die Datenmengen geht. Es ist die Vielfalt der Quellen, die Vielfalt der Formate der Quellen und die Tatsache, dass Sie, insbesondere in einer Unternehmensumgebung, häufig auf Dutzende von Systemen zugreifen – sie befinden sich in einem ständigen Wandel. Die Art der Daten, die Sie erhalten, ändert sich also im Allgemeinen.
Diese Systeme stehen nicht still – Unternehmen innovieren und verändern sich, daher sehen Sie sich hier mehrere Probleme an. Sie müssen es zuverlässig erhalten; Sie müssen [Daten] auf robuste Weise [mit] so [wenigen] Eingriffen wie möglich verarbeiten. In der Vergangenheit konnten die Leute eine ganze Reihe von Extrakten aus ihren Quellsystemen erstellen, sie führten Punkt-zu-Punkt-Lösungen durch, bei denen Sie mehrere verschiedene Mechanismen zum Empfangen der Daten haben könnten. Ich würde sagen, versuchen Sie, [einen] konstanten Standardmechanismus zu haben, [und] Sie werden eine einzige Art von Praxis haben.
Sie müssen dann Werkzeuge einsetzen, die für diese Dinge geeignet sind. Vermeiden Sie daher so viel wie möglich handgefertigte oder Punkt-zu-Punkt-Lösungen. Was wir bei vielen historischen Data Warehouses sehen, ist, dass es eine Reihe von maßgeschneiderten, handgefertigten Lösungen gibt, um die Daten von System 'A' und einer anderen von 'System B' zu erhalten. Sie enden im Wesentlichen mit Qualitäts- und Robustheitsproblemen, und sie enden auch mit Wartungsproblemen und neigen dazu, sich eher langsam an Veränderungen anzupassen.
Es ist also ein dreifacher Schlag, das zu tun. Sie möchten Dinge verwenden, die Ihnen die schwere Arbeit abnehmen. Sie möchten keine Standardsachen wie die Fehlerbehandlung wiederholen. Sie müssen einfach, leicht, robust, konsistent und standardisiert sein. Mein letzter Punkt zu dieser Frage wäre, wenn möglich zu versuchen, die Daten aus den Quellsystemen zu ziehen, anstatt sie Ihnen als Extrakt zur Verfügung zu stellen.
Afnan: Data Pipelines und ETL ist im Grunde ein Konzept, das seit den Anfängen der Technologie gleichbedeutend mit Data Warehousing ist. Wie haben sich Ihrer Meinung nach ELT und Data Pipelining im Zeitalter von Big Data entwickelt? Welche Art von Innovationen könnten Ihrer Meinung nach sowohl die Kosten als auch die Komplexität des traditionellen ETL senken?
Paul: Viele der Kosten sind in der Vergangenheit wahrscheinlich aus zwei Hauptbereichen entstanden: Einer davon waren viele handgefertigte Lösungen, die ziemlich teuer und ziemlich begrenzt sind. Außerdem – und ich komme hier nicht auf ELT-Tools an, aber – sie waren groß [und] teuer. Sie erfordern spezialisierte Ressourcen und eigene dedizierte Infrastruktur, Hardware, Server, Plattformen, und sie [erfordern] Ressourcen, [die] schwer zu bekommen sind.
Was wir jetzt sehen, ist also ein Schritt, diese Arten von Prozessen zu vereinfachen. Anstatt also herausfinden zu müssen, was Sie bekommen werden, erstellen sie automatisch eine Karte für Sie. Es ist viel mehr Klick und Punkt, als es in der Vergangenheit der Fall war. Wir sehen also, dass dies im Wesentlichen den Bedarf verringert und viel mehr Codierung ermöglicht und dies durchzieht.
Afnan: Eine wichtige Anforderung, die wir immer häufiger sehen, besteht darin, dass mehr Unternehmen jetzt ELT-Pipelines anstelle von herkömmlichen ETL-Pipelines bauen möchten. Also, was halten Sie von diesem Ansatz? Glauben Sie, dass es für jede Organisation funktionieren könnte? oder gibt es bestimmte Dinge, die Unternehmen beachten müssen, bevor sie sich für ELT anstelle von ETL entscheiden?
Paul: Erstens gibt es nie eine Lösung, die für alles funktioniert. Es gibt Fälle, in denen ETL durchaus geeignet ist; tatsächlich bevorzugt. Aber was wir sehen ist, dass der bevorzugte Ausgangspunkt heutzutage wahrscheinlich das ELT wäre. Die Datenbanksoftware und -architekturen haben sich erheblich verbessert. Eine der Anforderungen für historisches ELT war die Unfähigkeit der Datenbank, die großen Mengen an Transformationen zu verarbeiten, die in den Zeitskalen erforderlich sind. Sie können eine sehr große Anzahl von Anwendungsfällen durchführen.
Ich persönlich bewegte mich in Richtung ELT. Ich kann mich nicht erinnern, wann ich das letzte Mal ELT gemacht habe – es wäre mindestens zehn Jahre her. Ihr Hauptantrieb wäre die Wellness-Komponente. Sie haben Ihre Lösung einfacher gemacht. Sie haben eine Plattform weniger, auf der Sie schief gehen können, und müssen [sowie] eine Reihe von Testplattformen weniger durchlaufen. So haben Sie Ihre Komplexität fallen gelassen.
Sie haben auch Kosten, da Sie nicht über diese Plattformen verfügen, um dies zu tun. Die Dinge, die den Bedarf dafür getrieben haben, haben sich im Wesentlichen verringert. Wenn ich heute in einer Greenfields-Umgebung suchen würde, würde ich davon ausgehen, dass mein Ausgangspunkt ELT ist, und mich dann davon entfernen, wenn ich das Gefühl habe, dass es aufgrund besonderer Umstände erforderlich ist.
Afnan: Wie können Sie sicherstellen, dass Sie die richtigen Daten in Ihrem Data Warehouse haben? und dass beides so kombiniert, konsolidiert [und] transformiert wird, dass es Ihren Reporting- und Analyseanforderungen entspricht?
Paul: Erstens können Sie nicht wirklich korrekte Daten erhalten. Der Grund dafür ist, dass Sie auf die Daten angewiesen sind, die Ihnen die Quellsysteme liefern, und wie jeder, der in diesem Bereich gearbeitet hat, bezeugen wird, geben sie Ihnen oft falsche Daten oder inkonsistente Daten oder Daten haben Probleme, wenn sie auf andere Weise präsentiert werden — [ it] liefert die falsche Position.
Aber was Sie tun können, ist zu versuchen, das bestmögliche Bild der Daten auf die bestmögliche Weise zu vermitteln. Sie sollten sich nicht so einrichten, dass wir sagen, dass wir perfekte Daten liefern werden, weil dies nicht geschieht. Glücklicherweise ist [es] nicht so wichtig, weil Sie im Allgemeinen von Analytics sprechen und es darum geht, das Datenvolumen zu verstehen. Es ist also nicht unbedingt ein Problem, wenn Sie es richtig verwalten.
Wenn Sie die bestmöglichen Daten erhalten möchten, würde ich ein paar Taktiken empfehlen, eine davon wäre, zu viel zu sammeln. Wenn wir das Beispiel, sagen wir, Verkaufstransaktionen nehmen, werden Sie gebeten, Verkaufsberichte oder Verkaufsanalysen bereitzustellen, und jemand wird herausfinden, dass Sie die Felder A, B und C dieser beiden Tabellen und dann [Felder] von diesem und diesem benötigen und dies und Sie erhalten die Daten, die erforderlich sind, um das Problem zu lösen.
Mein Rat ist im Allgemeinen, wenn Sie Verkaufsinformationen benötigen, greifen Sie auf die gesamte Verkaufstransaktion [und] alle zugehörigen Daten zu. Nehmen Sie es auch so untransformiert wie möglich ein. Gehen Sie nicht das Risiko ein, dass bei einer Transformation oder einer Ableitung der Daten Ihre eigenen Übersetzungsfehler eingefügt werden. Bringen Sie das in Ihr Data Warehouse und tun Sie es dort.
Ich würde auch versuchen, einige Feedback-Schleifen einzubauen, damit ich Möglichkeiten für High-Level-Checks habe. Sagen Sie, dass ich die Daten habe, die ich erwarte, und das verwendet normalerweise vertrauenswürdige Berichte oder Daten aus den Quellsystemen und vergleicht sie dann mit etwas Ähnlichem in dem, was Sie beim Durcharbeiten ableiten.
Es ist wichtig zu verstehen, was gut genug für das Geschäft ist. Historisch gesehen müssen beispielsweise Buchhaltungstransaktionen perfekt und innerhalb von Cents sein, aber wenn Ihre Verkaufstransaktionen ein wenig höher sind, ist dies nicht das Ende der Welt. Also würde ich auch solche Sachen verwenden. Es [gibt] Standardtricks und -techniken wie die Standarddatenformatierung [und] das Entfernen von Leerzeichen wie ein Komma. Überlegen Sie sich, dass Sie dies tun werden, und tun Sie es [auf] Standard [Weise].
Afnan: Wenn Sie davon sprechen, all diese Daten aus verschiedenen Quellen zu sammeln. Sie haben es mit mehreren Datenpipelines zu tun, und alle diese Pipelines haben offensichtlich unterschiedliche Datenlatenzen und Abhängigkeiten. Was sind Ihrer Meinung nach die wesentlichen Elemente für die Orchestrierung dieser Pipelines?
Paul: Es gibt ziemlich standardmäßige getestete Modellierungstechniken in der Bemaßungsmodellierung, die da draußen verwendet werden. Kimball [ist] ein sehr guter Ausgangspunkt, um sich die Ratschläge und Designtechniken anzusehen, die sie gegeben haben. Diese sind sehr gut geeignet, um Ihr Data Warehouse so aufzubauen, dass Ihre Daten konsistent sind und in Zukunft ein gemeinsames Format aufweisen.
Sie werden mit Dingen wie fehlenden Informationen umgehen. Wenn Sie also kein XYZ von einer bestimmten Quelle haben, wenn Sie die Produktdefinition nicht kennen, wissen Sie, dass Sie über Standardtechniken verfügen, wie ich ein Domänenprodukt erstellen werde Zumindest mein Verkaufsbericht summiert das Produkt. Ich kenne die Produktinformationen vielleicht nicht, aber ich weiß, dass ich Informationen zu einem Produkt namens Fracht habe. Ich weiß nicht mehr über das Produkt, aber das ist alles, was ich weiß.
Die zweite Sache ist, dass Sie die Art und Weise steuern müssen, wie Sie Ihre Informationen über den Dateninhalt [Metadaten] verarbeiten, und nicht, wie die Daten verarbeitet oder abgerufen werden. Wenn Sie also am Montag die Transaktionen vom Sonntag erhalten, gehen Sie nicht davon aus, dass Sie die Transaktionen vom Sonntag erhalten. Treiben Sie alles von den Daten innerhalb der Daten ab. Versuchen Sie also immer, so viele Daten wie möglich aus den Daten herauszuholen, damit Sie wissen, was los ist, und dann können Sie die Dinge wieder miteinander vergleichen.
Dann werden Sie einige Inkonsistenzen zwischen den Systemen feststellen, insbesondere [wenn Sie] Dutzende von Systemen haben, die unweigerlich an Ihr Data Warehouse liefern, eines davon wird irgendwann ausfallen, eines davon wird verfügbar sein. [und] dies wird häufig passieren. Präsentieren Sie zu diesem Zweck, was in Ihrer Lösung fehlt, präsentieren Sie es nicht nur und machen Sie klar und deutlich, dass wir keine Bestandsdaten vom Montag für [sagen wir] Verteilzentrum 27 haben.
Umgang damit als Teil Ihrer Verarbeitung; das wären meine wichtigsten Kommentare. Verwenden Sie daher die Daten, um es zu steuern; Kimball ist König, und stellen Sie sicher, dass das Geschäft weiß, wenn Sie Dinge bekommen, die nicht erschienen sind.
Afnan: Cloud Data Warehousing hat viel Fahrt aufgenommen, besonders in diesem Jahr haben wir überall davon gehört. Was sind Ihrer Meinung nach einige Überlegungen, die Unternehmensdatenteams berücksichtigen müssen, wenn sie Datenpipelines speziell für ein Cloud-Data-Warehouse erstellen?
Paul: Okay, ich gehe also davon aus, dass es sich um einen gekauften Cloud-Service in Bezug auf das Hosten und Verwalten Ihrer Data Warehouse-Infrastruktur handelt. Aus technischer Sicht unterscheidet sich der Wechsel in die Cloud nicht so sehr.
[Die] wichtigsten technischen Unterschiede wären, dass Sie sich offensichtlich sozusagen im Internet befinden und möglicherweise große Datenmengen verschieben. Sie müssen sich also viele Gedanken darüber machen, wie Sie diese großen Daten übertragen werden Bände um. Sind Ihre Quellsysteme und Ihre Cloud-gehostete Infrastruktur – aus Netzwerksicht – nah genug beieinander, dass Sie diese Dinge verschieben können? Darüber hinaus sind sie zwischen Ihren verschiedenen Systemen robust genug, damit Sie auch in Bezug auf die Daten Zuverlässigkeit haben.
Das andere Element, das man sich dann nur anschauen sollte, sind häufig Data-Warehousing-Lösungen. Es gibt Elemente vom Typ Dashboard, und Elemente vom Typ Dashboard haben ziemlich oft eine schnelle Reaktionsfähigkeit. Sie müssen recht schnell auf Benutzer reagieren, wenn Sie hier klicken, und Sie erhalten das nächste Set.
Die Latenz spielt eine Rolle. Wenn Ihre Ping-Zeit zwischen Ihren Benutzern und Ihrer Cloud-Infrastruktur gering ist, kann dies dazu führen, dass Ihre Dashboards schlecht aussehen, obwohl sie es nicht sind. Die meisten Überlegungen beziehen sich entweder auf kommerzielle, regulatorische oder infrastrukturelle Aspekte. Wenn Sie in die Cloud wechseln, wählen Sie normalerweise einen Anbieter aus. Sie sind jetzt also nicht technologieabhängig. Sie sind von einem Anbieter abhängig, damit seine Systeme betriebsbereit sind.
Es geht eher darum, den Anbieter und seine Fähigkeiten zu messen als die Technologie. Einige der möglichen behördlichen Probleme sind, dass Sie – wenn ich hier schaue, wo ich ansässig bin – grundsätzlich nicht ohne besondere Erlaubnis Gesundheitsdaten als Beispiel aus dem Land mitnehmen dürfen, weil es sich um personenbezogene Daten handelt und es Regeln gibt, was Sie tun mit personenbezogenen Daten machen.
Ebenso haben Sie eine gewisse Datensicherheit, auf die Sie achten müssen, da Sie jetzt die Verantwortung für die Aufbewahrung Ihrer Daten an Dritte übertragen. Tatsächlich werden sie wahrscheinlich besser in der Datensicherheit sein als Sie, weil es ein Teil ihres Lebens ist, aber Sie müssen trotzdem sicherstellen, dass Sie dies überprüfen. Und tatsächlich würde ich sagen, dass dies wahrscheinlich einer der Bereiche ist, in denen Sie sich etwas leichter ausruhen können.
Eines der Dinge beim Wechsel in die Cloud ist, dass Sie viel mehr Möglichkeiten [in Bezug auf] Ihre Anpassungsfähigkeit erhalten. [Es gibt eine] Reihe von Fällen, in denen ich mit Kunden zusammen war und deren Data Warehouse im Wesentlichen eingerichtet wurde auf 10 Jahre alter Architektur, die langsam knarrt, [mit] den täglichen Lasten, die immer später am Morgen ankommen. [Also] Sie bekommen Ihre Berichte nicht vor Mittag, aber der Umzug war unglaublich schwierig.
Sie hatten alle möglichen Probleme im Zusammenhang mit der Rekrutierung und dem Besitz von Ressourcen, die in der Lage waren, diese Art von Arbeit zu erledigen, damit Sie einen Großteil dieses Problems an andere weitergeben können. Tun Sie dies jedoch nicht aus Kostengründen, da es im Allgemeinen ähnlich kostet; Auch wenn das Kostenmodell unterschiedlich sein kann, kaufen Sie mehr und werden besser. Dies wären also einige der Überlegungen für den Wechsel in die Cloud.
Afnan: Wie passt Automatisierung Ihrer Meinung nach in all das? [Mithilfe] von Automatisierung und Orchestrierung, wie können Sie den gesamten Prozess der Erstellung und Wartung Ihrer Datenpipelines Ihrer Meinung nach effizienter gestalten?
Paul: Erstens sollten Sie Punkt-zu-Punkt-Lösungen so weit wie möglich vermeiden. Sie möchten also etwas, das die Überwachung für Sie übernimmt. Häufig treten diese Belastungen mitten in der Nacht auf. Sie möchten standardmäßige automatisierte Typfähigkeiten wie die Möglichkeit, von einem bestimmten Zeitpunkt aus neu zu starten, Punkte zu überspringen, all diese Art von Jobsteuerung und Jobverwaltung.
Sie möchten etwas, das im Wesentlichen einfach zu bauen ist. Je einfacher es ist, sie [das System] zusammenzustellen, desto mehr Daten erhalten Sie. Je schneller Sie es erhalten und je [weniger] Fehler Sie haben, wenn Sie diese Daten eingeben, desto wahrscheinlicher ist es, dass Sie es so machen, wie es das Geschäft von Ihnen möchte.
Ich meine, nebenbei sage ich häufig, dass wir unser eigener schlimmster Feind sind. Wenn wir mit einer Business-Intelligence-Lösung erfolgreich sind, wissen wir das normalerweise, weil wir mit der Nachfrage komplett überlastet sind. Okay, Sie müssen in der Lage sein, diese Dinge auf die einfachste Weise zu tun, um dieser Nachfrage gerecht zu werden.
In der Vergangenheit lagen die Kosten für den Umzug [und] die Erstellung von Data Warehouses in der Größenordnung von sechzig Prozent, vielleicht sogar zwei Drittel, abhängig von Ihrem Zeitrahmen auf der ELT-Seite. Sie möchten also wirklich sicherstellen, dass Sie auf einfache Weise viele der wiederholbaren Aufgaben so weit wie möglich für Sie erledigen, da dies eine so große Menge an Kosten sein kann.
Astera DW Builder: Automatisierte Data Warehouse-Plattform
Astera DW Builder ist eine End-to-End-Data-Warehousing-Lösung, mit der Sie automatisierte Datenpipelines in einer codefreien Umgebung entwickeln können. Die einheitliche Plattform verfügt über eine metadatengesteuerte Architektur und rationalisiert Ihre Design- und Engineering-Prozesse, um genaue und relevante Einblicke zu liefern, die eine bessere Entscheidungsfindung ermöglichen.
Unternehmen können selbstregulierende Datenpipelines erstellen, indem sie die erweiterten ETL- und ELT-Funktionen wie die integrierte Workflow-Orchestrierung und Jobplanungskomponenten von . nutzen Astera DW-Builder. MIT DER INTELLIGENTEN SCHADENKALKULATION VON Astera DW Builder heute um herauszufinden, wie es Ihrem Unternehmen einen Mehrwert bieten kann.
