{"id":67409,"date":"2022-04-25T09:40:01","date_gmt":"2022-04-25T13:40:01","guid":{"rendered":"https:\/\/dataladder.com\/datenqualitaets-api-funktionen-architektur-und-vorteile\/"},"modified":"2022-05-19T10:38:29","modified_gmt":"2022-05-19T10:38:29","slug":"datenqualitaets-api-funktionen-architektur-und-vorteile","status":"publish","type":"post","link":"https:\/\/dataladder.com\/de\/datenqualitaets-api-funktionen-architektur-und-vorteile\/","title":{"rendered":"Datenqualit\u00e4ts-API: Funktionen, Architektur und Vorteile"},"content":{"rendered":"\n

Bei einer Umfrage unter 1900 Datenteams nannten mehr als 60 %<\/a> zu viele Datenquellen und inkonsistente Daten als gr\u00f6\u00dfte Herausforderung f\u00fcr die Datenqualit\u00e4t. Doch wenn es darum geht, die Datenqualit\u00e4t zu verbessern, befinden sich Datenverantwortliche oft in einer schwierigen Lage, da wichtige Entscheidungen getroffen werden m\u00fcssen. Eine der wichtigsten Entscheidungen, die es zu treffen gilt, lautet: An welchem Punkt des Datenlebenszyklus sollten wir die Datenqualit\u00e4t pr\u00fcfen und verbessern?<\/em><\/p>\n\n

Um diese Frage zu beantworten, m\u00fcssen einige Aspekte ber\u00fccksichtigt werden. Da viele Unternehmen regelm\u00e4\u00dfig riesige Datenmengen produzieren und diese durchg\u00e4ngig im gesamten Unternehmen verwenden, ist ein reaktiver Ansatz – bei dem die Daten nach der Speicherung bereinigt werden – m\u00f6glicherweise nicht die beste Wahl, da er die Zuverl\u00e4ssigkeit und Verf\u00fcgbarkeit der Daten beeintr\u00e4chtigt. Der Einsatz einer zentralen Datenqualit\u00e4ts-Firewall, bei der die Daten vor der Speicherung in der Datenbank gepr\u00fcft und behandelt werden, k\u00f6nnte in solchen F\u00e4llen die bessere Option sein.<\/p>\n\n

Wenn Sie mehr \u00fcber die Unterschiede zwischen den beiden Ans\u00e4tzen erfahren m\u00f6chten, lesen Sie unseren letzten Blog: Batch-Verarbeitung versus Echtzeit-Validierung der Datenqualit\u00e4t<\/a>.<\/p>\n\n

Bei den meisten reaktiven Ans\u00e4tzen verwenden die Datenverantwortlichen oder andere Mitglieder des Datenqualit\u00e4tsteams<\/a> eine Software-Schnittstelle, um die Datenqualit\u00e4t zu testen und zu verbessern. Bei einem proaktiven Ansatz wird diese Aufgabe jedoch in der Regel \u00fcber eine API abgewickelt. In diesem Blog werden wir uns mit verschiedenen Aspekten befassen, die bei der Bereitstellung einer Datenqualit\u00e4ts-Firewall mit solchen APIs zu ber\u00fccksichtigen sind. Fangen wir an.<\/p>\n\n

Was ist eine Datenqualit\u00e4ts-API?<\/h2>\n\n

Eine API (Application Programming Interface) ist eine Software-Schnittstelle, die es Anwendungen erm\u00f6glicht, miteinander zu kommunizieren. Eine API befindet sich zwischen zwei Softwareanwendungen und verarbeitet die \u00fcbertragenen Anfragen\/Antworten. Wenn Sie zwei Systeme integrieren oder verbinden wollen, tun Sie dies normalerweise mit Hilfe einer API.<\/p>\n\n

In \u00e4hnlicher Weise bedeutet eine Datenqualit\u00e4ts-API:<\/p>\n\n

Ein Software-Vermittler, der Anfragen\/Antworten f\u00fcr verschiedene Datenqualit\u00e4tsfunktionen bereitstellt.<\/strong><\/p>\n\n

Architektonische Umsetzung einer Datenqualit\u00e4ts-API<\/h2>\n\n

Eine Datenqualit\u00e4ts-API wird oft unter verschiedenen Bezeichnungen gef\u00fchrt. Zum Beispiel Datenqualit\u00e4ts-Firewall, Datenqualit\u00e4tsvalidierung in Echtzeit, zentrale Datenqualit\u00e4ts-Engine, usw. Solche Namen werden vergeben, da die API zwischen der Anwendung, die die Daten erfasst, und der Datenbank, die sie speichert, fungiert.<\/p>\n\n

Datenqualit\u00e4ts-APIs basieren (wie alle anderen APIs auch) auf einer ereignisgesteuerten Architektur. Sie werden ausgel\u00f6st, wenn ein Ereignis eintritt. Wenn also neue Daten durch eine verbundene Anwendung kommen oder vorhandene Daten aktualisiert werden, werden sie zun\u00e4chst durch die API geleitet (wo die Datenqualit\u00e4t \u00fcberpr\u00fcft wird) und dann an die Quelldatenbank weitergeleitet. Dadurch fungiert die API als Gateway zwischen einer Datenerfassungsanwendung und einer Datenspeicherquelle, wodurch sichergestellt wird, dass keine Datenqualit\u00e4tsfehler von der ersten Seite auf die zweite Seite \u00fcbertragen werden.<\/p>\n\n

Beispiel f\u00fcr die Validierung der Datenqualit\u00e4t in Echtzeit f\u00fcr Kundendaten<\/h3>\n\n

Wenn Sie eine zentrale Datenqualit\u00e4ts-Firewall einsetzen, werden die eingehenden Daten nahezu in Echtzeit auf ihre Qualit\u00e4t gepr\u00fcft. Wenn beispielsweise eine \u00c4nderung an einem Kundendatensatz vorgenommen oder ein neuer Kundendatensatz in einer angeschlossenen Anwendung erstellt wird, wird die Aktualisierung zun\u00e4chst an die zentrale Datenqualit\u00e4ts-Engine gesendet. Hier wird die \u00c4nderung anhand der konfigurierten Datenqualit\u00e4tsdefinition \u00fcberpr\u00fcft, z. B. um sicherzustellen, dass die erforderlichen Felder nicht leer sind, dass die Werte dem Standardformat und -muster entsprechen, dass ein neuer Kundendatensatz m\u00f6glicherweise nicht mit einem bestehenden Kundendatensatz \u00fcbereinstimmt usw.<\/p>\n\n

Wenn Datenqualit\u00e4tsfehler gefunden werden, wird eine Liste von Transformationsregeln ausgef\u00fchrt, um die Daten zu bereinigen. In manchen F\u00e4llen ben\u00f6tigen Sie einen Datenqualit\u00e4tsbeauftragten, der eingreift und Entscheidungen trifft, wenn Datenwerte mehrdeutig sind und von konfigurierten Algorithmen nicht gut verarbeitet werden k\u00f6nnen. So besteht beispielsweise eine 60-prozentige Wahrscheinlichkeit, dass es sich bei einem neuen Kundendatensatz um ein Duplikat handelt, und jemand muss das Problem manuell \u00fcberpr\u00fcfen und beheben. Anschlie\u00dfend wird der bereinigte, abgeglichene und \u00fcberpr\u00fcfte Datensatz an eine Zielquelle gesendet, bei der es sich um einen Stammdatensatz, ein Data Warehouse, ein Business Intelligence-System usw. handeln kann.<\/p>\n\n

Ein Beispiel f\u00fcr eine solche Architektur ist nachstehend schematisch dargestellt:<\/p>\n\n

<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n

Funktionen einer Datenqualit\u00e4ts-API<\/h2>\n\n

Eine gute Datenqualit\u00e4ts-API ist in der Lage, verschiedene Arten von Datenqualit\u00e4tsfunktionen<\/a> f\u00fcr eingehende Daten auszuf\u00fchren. Je nach den Prozessen, die in Ihrem Datenqualit\u00e4tsrahmenwerk<\/a> enthalten sind, k\u00f6nnen Sie die erforderlichen Funktionen \u00fcber die API abonnieren. Da es sich die meisten Unternehmen jedoch nicht leisten k\u00f6nnen, wiederkehrende oder neue Datenqualit\u00e4tsprobleme durch das System fallen zu lassen, abonnieren sie meist so viele Datenqualit\u00e4tsvalidierungs- und -behebungstechniken, wie die API bietet.<\/p>\n\n

Zu den h\u00e4ufigsten Funktionen, die von einer Datenqualit\u00e4ts-API angeboten werden, geh\u00f6ren:<\/p>\n\n

1. Verbindung zu Datenquellen<\/h3>\n\n

Dies ist die wichtigste und n\u00fctzlichste Funktion, die eine Datenqualit\u00e4ts-API bietet. Unternehmen verwenden mehrere datenerzeugende Anwendungen, z. B. Website-Tracking-Tools, Marketing-Automatisierungstools, CRMs usw. Aus diesem Grund muss eine Datenqualit\u00e4ts-API in der Lage sein, eine Verbindung zu diesen verschiedenen Anwendungen herzustellen und mit ihnen zu kommunizieren<\/a>, ebenso wie mit der Zieldatenbank, in der die eingehenden Daten normalerweise landen.<\/p>\n\n

2. Datenqualit\u00e4tspr\u00fcfungen durchf\u00fchren<\/h3>\n\n

Immer wenn in einer angeschlossenen Anwendung ein Ereignis eintritt (ein neuer Datensatz wird erstellt oder ein bestehender aktualisiert), kann die API die eingehenden Daten<\/a> auf Datenqualit\u00e4tsfehler pr\u00fcfen und ein Profil erstellen<\/a>. Dies geschieht durch die Ausf\u00fchrung statistischer Algorithmen, die die eingehenden Daten bewerten und \u00fcberpr\u00fcfen, ob sie der Definition der Datenqualit\u00e4t entsprechen. Diese Kontrollen umfassen die Sicherstellung, dass:<\/p>\n\n