Im Laufe der Jahre wurden unzählige verschiedene Ansätze zum Verschieben und Zusammenführen von Daten entwickelt, die Geschäftsprozesse und Entscheidungsfindung unterstützen. Jeder davon verfügt über seine eigenen, nahezu einzigartigen Funktionen und Vorteile. Das Verständnis dieser Funktionen und ihrer Beziehung zum gewünschten Ergebnis Ihrer Datenstrategie ist für die Entwicklung eines optimalen Systems von entscheidender Bedeutung.
Beim Erstellen einer Strategie zur Optimierung, Zugänglichkeit und Integration aller Ihrer Daten müssen zahlreiche Variablen und Anforderungen berücksichtigt werden. Dazu gehören:
Bei der Stapelverarbeitung werden Daten in regelmäßigen Abständen oder in Stapeln übertragen. Zu diesen Mustern gehören Extract Transform Load (ETL), Extract Load Transform (ELT), Reverse ETL, Spiegelung oder Replikation sowie Writeback-Tools.
ETL ist der traditionelle Ansatz zum Verschieben von Daten. Daten werden aus einer Datenquelle extrahiert, basierend auf Geschäftsregeln transformiert und in eine Zieldatenbank geladen. Dieser Ansatz kann sehr sicher, aber auch unflexibel sein. Diese Starrheit erfordert, dass Datensätze sehr strukturiert und dokumentiert sind, was komplexe Transformationen erleichtert. Da die Datenbanken älterer Systeme in der Regel sehr strukturiert und starr sind, ist ETL für diese Systeme gut geeignet. Um diese Prozesse zu erstellen, müssen Entwickler über umfassende Kenntnisse der Datenstruktur und Programmiersprachen verfügen.
ELT ähnelt ETL, die Transformation erfolgt jedoch nach dem Laden in die Zieldatenbank. Dieser modernere Ansatz ermöglicht mehr Flexibilität, da die Rohdaten nach der Transformation in der Zieldatenbank verbleiben. Folglich können die Transformationen iterativ oder rückwirkend ausgeführt werden, ohne Daten aus der ursprünglichen Datenquelle abzurufen. Dadurch werden die zum Extrahieren eines neuen Datensatzes erforderlichen Ressourcen reduziert. ELT eignet sich besser für umfangreichere, weniger strukturierte Datensätze, bei denen Datenbereinigung und Transformationen näher am Endbenutzer ausgeführt werden können.
Reverse ETL ist ein weiterer Batch-Prozess, aber die Daten fließen in die entgegengesetzte Richtung einer ETL-Pipeline. Daten werden aus einer operativen Drittanbieteranwendung extrahiert und in eine zentrale Datenbank geladen. Dieser Ansatz ermöglicht es einem Unternehmen, eine Version eines Datensatzes in einem zentralen Lager zu konsolidieren und operativen Anwendungen die Verwendung derselben Daten zu ermöglichen, die möglicherweise auch andere Anwendungen oder Analysen verwenden. Reverse ETL unterstützt eine „einzige Quelle der Wahrheit“ für das Unternehmen.
Die Herausforderung besteht darin, dass Reverse ETL in Batches arbeitet. In dynamischen Organisationen, in denen sich Daten ständig ändern, können unterschiedliche Gruppen aufgrund unterschiedlicher Aktualisierungszeitpläne unterschiedliche Versionen derselben Daten verwenden. Reverse-ETL-Synchronisierungsstrategien können auch operative Systeme überfordern, da große Datenmengen aus mehreren Quellen in operative Systeme geladen werden. Dies kann zu Konflikten und Datenversionen derselben Daten führen.
Spiegelung und Replikation speichern Daten ohne jegliche Transformation in einer separaten Datenbank und werden häufig eingesetzt, um Datensätze für den Fall eines Datenverlusts zu sichern. Sie können auch bei der Optimierung der Datenverwaltung und beim Erstellen eines persistenten Datensatzes bei Datenbewegungen hilfreich sein. Durch Spiegelung werden nicht nur die Daten, sondern auch die gesamte Datenbankstruktur und das Verwaltungssystem repliziert.
Die Replikation unterscheidet sich geringfügig von der Spiegelung, da hier nicht das Datenbankverwaltungssystem, sondern nur die Daten kopiert werden. Der Zugriff auf Daten aus verschiedenen Systemen ist bei der Replikation viel einfacher, da sie nicht durch ein Datenbankverwaltungssystem definiert werden.
Spiegeln ist eine bessere Option für den Lastenausgleich. Die Quell- und die kopierten Datenbanken sind identisch, sodass auf die Daten von beiden Quellen aus problemlos zugegriffen werden kann. Notfallwiederherstellung und Optimierung der Ressourcennutzung sind gängige Anwendungsfälle für das Spiegeln. Es eignet sich auch zum Erfassen eines Snapshots von Daten während der Übertragung. Beispielsweise können regelmäßig verwendete virtualisierte Daten in einen persistenten Datenspeicher gespiegelt werden.
Die Integration und Verwaltung von Daten in Echtzeit bringt viele Komplexitäten mit sich, insbesondere beim Zusammenführen unterschiedlicher Datensätze. Da sich unterschiedliche Datensätze ständig ändern, bestehen immer Diskrepanzen zwischen den Quelldaten und den zusammengeführten Daten. Echtzeitdaten sind eher in operativen Systemen, Tracking-Sensoren oder Finanzdaten anwendbar.
CDC ist ein ereignisbasiertes Muster, bei dem Änderungen in einer Datenbank automatisch in einer anderen widergespiegelt werden, wenn definierte Ereignisse auftreten. Dieses Muster unterstützt bidirektionale Datenflüsse, sodass Quell- und Zieldatenbanken Daten austauschen können, um die Synchronisierung sicherzustellen. CDC ist eine viel effizientere Methode zum Verschieben von Daten als ETL, da nur die geänderten Daten in die Zieldatenbank übertragen werden, nicht der gesamte Datensatz.
CDC funktioniert gut mit Datenbanken oder Anwendungen, die nicht integriert werden können. CDC-Prozesse können Daten in einer separaten Datenbank bereitstellen und Änderungen können dann von den bereitgestellten Daten an die Zieldatenbanken weitergegeben werden. Diese Methode erfordert die Pflege einer separaten dynamischen Datenquelle, was zu übermäßiger Komplexität und einem höheren Fehlerpotenzial führt.
Beim Streaming von Daten werden diese ständig aufgenommen, verarbeitet und an ihr Ziel verschoben. Normalerweise handelt es sich dabei um Sensordaten oder Finanzdienstleistungsdaten. In vielen Fällen werden Streamingdaten auf dem Weg zu ihrer Zieldatenbank umgewandelt.
Obwohl Streaming-Daten schnell sind, gibt es auch ein paar Nachteile. Streaming-Daten bewegen sich ständig und nehmen verschiedene Wege durch das Internet, sodass nicht gewährleistet werden kann, dass die Daten in der richtigen Reihenfolge verarbeitet werden. Manche Daten können nach den aktuelleren Daten zur Verarbeitung eintreffen, was zu Verwirrung über die genauesten Daten führt. Um sicherzustellen, dass die Daten in der richtigen Reihenfolge verarbeitet werden, muss eine entsprechende Orchestrierung implementiert werden.
Streamingdaten stellen außerdem das Datenmodell der Datenquelle für nachgelagerte Benutzer bereit. Wenn nachgelagerte Anwendungen direkt mit dem Quelldatenmodell verbunden sind, verursachen Änderungen an diesem Modell Chaos in der nachgelagerten Anwendung.
Wenn Streamingdaten in einem Datenprodukt verpackt werden, können interne Quelldatenmodelle dem Datenmodell eines Datenprodukts zugeordnet werden. Diese Struktur erleichtert die gemeinsame Nutzung von Daten mit externen Gruppen.
Writeback-Funktionen von Front-End-BI-Tools sind eine weitere Methode, um Änderungen an einer Quelldatenbank vorzunehmen. Dieses neue Muster ermöglicht es Analysten, die mit BI-Tools arbeiten, Änderungen an der Quelldatenbank direkt aus dem BI-Tool vorzunehmen. Diese Änderungen werden sofort in der Datenquelle und der Arbeit der Analysten widergespiegelt. Dadurch kann der Analyst, der die Daten am besten versteht, die ursprüngliche Datenquelle anpassen oder korrigieren.
Durch die Writeback-Funktionen sind Datenanalysten zudem weniger auf Excel-Tabellen angewiesen, da sie nun die Möglichkeit haben, eine Datenbank genauso schnell zu aktualisieren wie mit Excel.
SaaS-Anwendungen tauschen Daten normalerweise über REST-APIs aus. Dabei handelt es sich um unkomplizierte Prozesse zum Abrufen von Daten aus einer Anwendungsdatenbank. APIs können Daten nicht allein transformieren. Wenn sie jedoch über eine iPaaS-Plattform ausgeführt werden, können automatisierte Transformationsprozesse an den Daten durchgeführt werden, bevor sie an die Zielanwendung gesendet werden.
REST-APIs eignen sich gut für den einfachen Datenaustausch zwischen einer oder zwei Anwendungen, dieser Ansatz ist jedoch nicht gut skalierbar. Wenn eine App ihre API ändert, können nachgelagerte Anwendungen beschädigt werden.
Bei der Datenvirtualisierung wird Code ausgeführt, der einen neuen virtualisierten Datensatz aus verbundenen Datenbanken erstellt. Dieser neue Datensatz wird bei jeder Ausführung des Codes erstellt, die Daten werden jedoch nur so lange wie nötig gespeichert. Dies ist das Muster, das die Avrio -Plattform verwendet, um Datensätze für die Analyse zu generieren. Die Verwendung dieser Technologie für die Datenintegration bietet mehrere Vorteile:
Erstens trennt die Datenvirtualisierung die zugrunde liegende Datenbank und Struktur von den Daten selbst. Dies macht die Datenvirtualisierung viel skalierbarer und flexibler.
Zweitens wird bei der Datenvirtualisierung keine dauerhafte Kopie der Datenbank erstellt. Da jedes Mal ein neuer Datensatz erstellt wird, wird der Code ausgeführt und die aktuellsten Daten werden aus der Quelldatenbank abgerufen. Dieser Ansatz vermeidet Konflikte zwischen mehreren Versionen derselben Daten. Auch die Speicherkosten können minimiert werden.
Drittens können ausgefeilte Konnektoren, föderierte Abfrage-Engines und Virtualisierung Daten aus mehreren Datenbanken gleichzeitig abfragen, transformieren und zusammenführen. Mit einem konsolidierten Metadatenspeicher und einem darüber liegenden einheitlichen Datenmodell können Datenanalysten mit diesem Ansatz Daten aus verschiedenen Datenspeichern abrufen, als wären sie eine einzige Datenbank.
Und schließlich ermöglicht die Datenvirtualisierung mehr Kontrolle über Ihre Daten. Da die Daten durch diese Virtualisierungsschicht laufen, können Datenqualitätsprüfungen durchgeführt und detaillierte Zugriffskontrollen implementiert werden.
Jeder Integrations- und Synchronisierungsansatz hat seine Vor- und Nachteile. Unabhängig von Ihrem Ansatz ist die Beachtung von Datenverwaltung, Sicherheit und Qualität für eine gesunde Datenarchitektur von größter Bedeutung. Die gemeinsame Verwendung geeigneter Ansätze in einer konsolidierten Plattform kann zu einer leistungsstarken und flexiblen Lösung führen.
Der Kern der Fähigkeiten von Avrio ist die Datenvirtualisierung, die zur Integration von Daten für die Analyse verwendet wird, um bei jeder Ausführung des Codes einen neuen Datensatz zu erstellen. Wenn persistente Daten erforderlich sind, es aber regelmäßig Änderungen gibt, verfügt Avrio auch über CDC-Funktionen, die nur Änderungen in der Quelldatenbank in die gespiegelte Umgebung spiegeln.
Avrio bietet auch Spiegelungsfunktionen, um persistente Datensätze aus virtualisierten Datensätzen zu erstellen. Wenn sich Daten nicht oft ändern, aber regelmäßig verwendet werden, kann die Spiegelung die Nutzung von Bandbreitenressourcen reduzieren.
Die Avrio-Plattform ermöglicht Drittanbietern den Zugriff auf Datenprodukte über eine API. Diese Front-End-Schicht von Avrio verfügt auch über Write-Back-Funktionen, um Änderungen, die in einem BI-Tool vorgenommen wurden, in die mit der Avrio-Plattform verbundene Back-End-Datenbank zu integrieren.
Die Kombination mehrerer Integrations- und Synchronisierungsmuster zur Erzielung eines Geschäftsergebnisses ist aus strategischer Sicht sinnvoll. Jede Situation ist anders und erfordert einzigartige Fähigkeiten. Die Avrio-Plattform kombiniert die richtigen Technologien und Muster, um Daten über mehrere Datensilos hinweg zugänglich zu machen, mit Self-Service-Datenprodukten, die über integrierte Governance und Sicherheit verfügen – konzipiert für das KI-Zeitalter, schnelle Analysen und bessere Entscheidungsfindung.
Avrio lässt sich außerdem gut mit Ihren vorhandenen Integrationstools und Ihrer Infrastruktur kombinieren. Wenn Sie Daten in einen Datensee streamen, kann Avrio ein Datenprodukt erstellen, um einen Snapshot der Streaming-Daten zur Analyse zu erfassen. Wenn Sie ETL-Pipelines erstellt haben, die gut etabliert sind und sich nicht stark ändern, kann Avrio diese Daten in ein Datenprodukt integrieren, das sie leichter zugänglich macht und Datensätze aus anderen Systemen integriert.