Kapitel 4. Überwachung und Erkennung von Anomalien für deine Datenpipelines

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Mit Ryan Kearns

Stell dir vor, du hast gerade ein neues Auto gekauft. Nach der routinemäßigen Überprüfung vor dem Kauf funktionieren alle Systeme wie im Handbuch beschrieben, der Öl- und der Bremsflüssigkeitsbehälter sind fast bis zum Rand gefüllt und die Teile sind so gut wie neu - denn das sind sie ja auch.

Nachdem du die Schlüssel bei deinem Händler abgeholt hast, machst du dich auf den Weg. "Es geht nichts über den Geruch eines neuen Autos", denkst du, als du auf die Autobahn auffährst. Alles ist gut und schön, bis du einen lauten Knall hörst. Igitt. Und dein Auto fängt an zu wackeln. Du fährst auf den Seitenstreifen, schaltest den Warnblinker ein und springst aus dem Auto. Nach einer kurzen Untersuchung hast du den vermeintlichen Verursacher des lauten Geräuschs ausgemacht - einen platten Reifen. Egal, wie viele Tests oder Überprüfungen dein Autohaus durchgeführt hat, um den Zustand deines Autos zu überprüfen, es gibt keine Möglichkeit, unbekannte Faktoren (z. B. Nägel oder Schmutz auf der Straße) zu berücksichtigen, die dein Fahrzeug beeinträchtigen könnten.

Ähnlich verhält es sich bei den Daten: Alle Tests und Datenqualitätsprüfungen können dich nicht vollständig vor Datenausfällen schützen, die in allen Phasen der Pipeline auftreten und eine Vielzahl von Gründen haben können, die oft nichts mit den Daten selbst zu tun haben.

Wenn es darum geht, zu verstehen, wann es zu Datenpannen kommt, ist es am besten, sich auf die Überwachung zu stützen, insbesondere auf Verfahren zur Erkennung von Anomalien, die erkennen, wenn deine erwarteten Schwellenwerte für Volumen, Frische, Verteilung und andere Werte nicht den Erwartungen entsprechen.

Die Erkennung von Anomalien bezieht sich auf die Identifizierung von Ereignissen oder Beobachtungen, die von der Norm abweichen - z. B. betrügerisches Kreditkartenverhalten oder eine technische Panne, wie ein Website-Absturz. Vorausgesetzt natürlich, dass deine Website normal funktioniert.

Es gibt eine Reihe von Techniken, Algorithmen und Frameworks, die von Branchenriesen wie Meta, Google, Uber und anderen verwendet (und entwickelt) werden. Für eine technische Vertiefung empfehlen wir Preetam Jinka und Baron Schwartz' Bericht Anomaly Detection for Monitoring (O'Reilly).

Bis vor kurzem galt die Erkennung von Anomalien für viele Datenteams als "nice-to-have" und nicht als "need-to-have". Jetzt, da die Datensysteme immer komplexer werden und die Unternehmen ihren Mitarbeitern die Möglichkeit geben, Daten in allen Bereichen zu nutzen, ist es unerlässlich, dass die Teams sowohl proaktive als auch reaktive Ansätze zur Verbesserung der Datenqualität verfolgen.

Autos unterscheiden sich zwar deutlich von Datenpipelines, aber auch Autos und andere mechanische Systeme haben ihre eigenen Überwachungs- und Anomalieerkennungsfunktionen. Die meisten modernen Fahrzeuge warnen dich, wenn der Ölstand, die Bremsflüssigkeit, das Benzin, der Reifendruck und andere wichtige Werte zu niedrig sind und fordern dich auf, Maßnahmen zu ergreifen. Die Überwachung von Daten und die Erkennung von Anomalien funktionieren auf die gleiche Weise.

In diesem Kapitel zeigen wir dir, wie du deine eigenen Datenqualitätsmonitore für eine Data Warehouse-Umgebung erstellst, um die Säulen der Datenbeobachtung zu überwachen und Alarm zu schlagen: Frische, Volumen, Verteilung und Schema. Dabei werden wir wichtige Konzepte und Begriffe einführen, die du brauchst, um dein Wissen über wichtige Techniken zur Erkennung von Anomalien zu erweitern.

Bekannte Unbekannte und Unbekannte Unbekannte kennen

Es gibt zwei Arten von Datenqualitätsproblemen: solche, die du vorhersagen kannst (bekannte Unbekannte) und solche, die du nicht vorhersagen kannst (unbekannte Unbekannte). Bekannte Unbekannte sind Probleme, die du leicht vorhersagen kannst, z. B. ungültige Werte, bestimmte Aktualitätsprobleme oder Schemaänderungen, die durch ein System ausgelöst werden, das regelmäßig aktualisiert wird. Diese Probleme treten vielleicht nicht auf, aber mit einer gesunden Portion an Tests kannst du sie oft vorhersehen, bevor sie zu Problemen in der Datenbank führen. In Abbildung 4-1 zeigen wir beliebte Beispiele für beides.

Unbekannte Unbekannte beziehen sich auf Datenausfälle, die selbst die umfassendsten Tests nicht berücksichtigen können, Probleme, die in der gesamten Datenpipeline auftreten, nicht nur in den Abschnitten, die von bestimmten Tests abgedeckt werden. Unbekannte Unbekannte können sein:

  • Eine Verteilungsanomalie in einem kritischen Feld, die dazu führt, dass dein Tableau Dashboard nicht funktioniert

  • Eine von einem anderen Team vorgenommene Änderung des JSON-Schemas, die aus 6 Spalten 600 macht

  • Eine unbeabsichtigte Änderung an der ETL (oder Reverse-ETL, wenn du magst), die dazu führt, dass Tests nicht laufen und schlechte Daten übersehen werden

  • Unvollständige oder veraltete Daten, die erst einige Wochen später bemerkt werden und sich auf wichtige Marketingkennzahlen auswirken

  • Eine Codeänderung, die dazu führt, dass eine API keine Daten mehr sammelt, die ein wichtiges neues Produkt speisen

  • Datenabweichungen im Laufe der Zeit, die schwer zu erkennen sind, vor allem, wenn deine Tests nur die Daten betrachten, die zum Zeitpunkt deiner ETL-Aufträge geschrieben werden, die normalerweise keine Daten berücksichtigen, die sich bereits in einer bestimmten Tabelle befinden

Abbildung 4-1. Beispiele für bekannte Unbekannte und unbekannte Unbekannte

Während du mit Prüfungen und Schutzschaltern viele deiner bekannten Unbekannten in den Griff bekommst, können die Überwachung und die Erkennung von Anomalien deine Basis abdecken, wenn es um unbekannte Unbekannte geht.

Häufig nutzen Datenteams das Monitoring und die Anomalieerkennung, um Datenverhalten zu identifizieren und zu melden, das von dem abweicht, was in der Vergangenheit von einer bestimmten Datenpipeline erwartet wurde. Wenn du weißt, wie "gute" Daten aussehen, ist es einfacher, "schlechte" Daten proaktiv zu erkennen.

Nachdem wir nun die Unterschiede zwischen diesen beiden Arten von Datenproblemen erläutert haben, wollen wir uns ansehen, wie die Erkennung von Anomalien bei unbekannten Unbekannten in der Praxis aussieht.

Aufbau eines Algorithmus zur Erkennung von Anomalien

Um zu verdeutlichen, wie Anomalieerkennung funktioniert, gehen wir durch ein reales Tutorial, um einen Anomalie-Detektor für einen sehr anomalen Datensatz zu erstellen.

Denk daran, dass es eine Vielzahl von Technologien und Ansätzen gibt, die du für die Erstellung von Datenqualitätsmonitoren verwenden kannst, und dass die Entscheidungen, die du triffst, von deinem technischen Hintergrund abhängen. In diesem Beispiel setzen wir die folgenden Sprachen und Tools ein:

  • SQLite und SQL

  • Jupyter Notebooks

  • Python

Unser Beispieldaten-Ökosystem verwendet fingierte astronomische Daten über bewohnbare Exoplaneten. Für diese Übung haben wir den Datensatz mit Python generiert und Anomalien aus realen Vorfällen modelliert, die wir in Produktionsumgebungen erlebt haben. Dieser Datensatz kann kostenlos verwendet werden. Der Ordnerutils im Repository enthält den Code, mit dem die Daten erzeugt wurden, falls du mehr darüber erfahren möchtest, wie er zusammengestellt wurde.

Wir verwenden SQLite 3.32.3, mit dem die Datenbank entweder über die Eingabeaufforderung oder über SQL-Dateien mit minimaler Einrichtung zugänglich sein sollte. Die Konzepte lassen sich auf jede beliebige Abfragesprache übertragen, und diese Implementierungen können mit minimalen Änderungen auf MySQL, Snowflake und andere Datenbankumgebungen übertragen werden.

Im Folgenden geben wir tabellarische Informationen über unseren EXOPLANETS Datensatz, einschließlich fünf spezifischer Datenbankeinträge:

$ sqlite3 EXOPLANETS.db
sqlite> PRAGMA TABLE_INFO(EXOPLANETS);
_id            | TEXT | 0 | | 0  1
distance       | REAL | 0 | | 0  2
g              | REAL | 0 | | 0  3
orbital_period | REAL | 0 | | 0  4
avg_temp       | REAL | 0 | | 0  5
date_added     | TEXT | 0 | | 0  6

Ein Datenbankeintrag in EXOPLANETS enthält die folgenden Informationen:

1

_id: eine UUID, die dem Planeten entspricht

2

distanceEntfernung von der Erde, in Lichtjahren

3

g: Oberflächengravitation als Vielfaches von g, der Gravitationskraftkonstante

4

orbital_periodLänge eines einzelnen Orbitalzyklus in Tagen

5

avg_tempDurchschnittliche Oberflächentemperatur in Grad Kelvin

6

date_addedDatum, an dem unser System den Planeten entdeckt und automatisch in unsere Datenbanken aufgenommen hat

Beachte, dass einer oder mehrere der Werte distance, g, orbital_period und avg_temp für einen bestimmten Planeten NULL sein können, weil Daten fehlen oder fehlerhaft sind.

Wenn wir sqlite> SELECT * FROM EXOPLANETS LIMIT 5; abfragen, können wir fünf Zeilen aus unserer Datenbank ziehen. In Beispiel 4-1 teilen wir fünf Datenbankeinträge in unserem EXOPLANETS Datensatz, um das Format und die Verteilung der Daten zu verdeutlichen.

Beispiel 4-1. Fünf Zeilen aus dem Datensatz EXOPLANETS 
_id,distance,g,orbital_period,avg_temp,date_added
c168b188-ef0c-4d6a-8cb2-f473d4154bdb,34.6273036348341,,476.480044083599, ...
e7b56e84-41f4-4e62-b078-01b076cea369,110.196919810563,2.52507362359066, ...
a27030a0-e4b4-4bd7-8d24-5435ed86b395,26.6957950454452,10.2764970016067, ...
54f9cf85-eae9-4f29-b665-855357a14375,54.8883521129783,,173.788967912197, ...
4d06ec88-f5c8-4d03-91ef-7493a12cd89e,153.264217159834,0.922874568459221, ...

Beachte, dass diese Übung rückwirkend ist - wir betrachten historische Daten. In einer Produktionsdatenumgebung erfolgt die Erkennung von Anomalien in Echtzeit und in jeder Phase des Lebenszyklus der Daten, sodass eine etwas andere Implementierung erforderlich ist als hier.

Für diese Übung werden wir Algorithmen zur Datenbeobachtung für Frische und Verteilung entwickeln, aber in zukünftigen Artikeln werden wir uns mit dem Rest unserer fünf Säulen befassen - und mehr.

Überwachung auf Frische

Die erste Säule der Datenbeobachtung, auf die wir achten, ist die Aktualität, die uns einen starken Hinweis darauf geben kann, wann kritische Daten zuletzt aktualisiert wurden. Wenn ein Bericht, der regelmäßig stündlich aktualisiert wird, plötzlich sehr veraltet aussieht, sollte diese Art von Anomalie ein deutliches Zeichen dafür sein, dass etwas ungenau oder anderweitig falsch ist.

Beachte zunächst die Spalte DATE_ADDED. SQL speichert keine Metadaten darüber, wann einzelne Datensätze hinzugefügt wurden. Um die Aktualität in dieser rückwirkenden Einstellung zu visualisieren, müssen wir diese Informationen also selbst verfolgen. Die Gruppierung nach der Spalte DATE_ADDED gibt uns Aufschluss darüber, wie EXOPLANETS täglich aktualisiert wird. Wie in Beispiel 4-2 dargestellt, können wir die Anzahl der neuen IDs abfragen, die pro Tag hinzugefügt werden.

Beispiel 4-2. Eine Abfrage über die Anzahl der neuen Exoplaneten, die pro Tag zu unserem Datensatz hinzugefügt werden
SELECT
  DATE_ADDED,
  COUNT(*) AS ROWS_ADDED
FROM
  EXOPLANETS
GROUP BY
  DATE_ADDED;

Du kannst dies selbst mit $ sqlite3 EXOPLANETS.db < queries/freshness/rows-added.sql im Repository ausführen. Wir bekommen die Daten aus Beispiel 4-3 zurück.

Beispiel 4-3. Daten aus Beispiel 4-2
date_added     ROWS_ADDED
2020-01-01     84
2020-01-02     92
2020-01-03     101
2020-01-04     102
2020-01-05     100
... ...
2020-07-14     104
2020-07-15     110
2020-07-16     103
2020-07-17     89
2020-07-18     104

Ausgehend von dieser grafischen Darstellung unseres Datensatzes sieht es so aus, als ob EXOPLANETS jeden Tag etwa 100 neue Einträge erhält, obwohl es Lücken gibt, in denen mehrere Tage lang keine Daten eingehen.

Erinnere dich daran, dass wir mit Freshness die Frage stellen wollen: "Sind meine Daten aktuell?" - daher ist das Wissen über die Lücken bei Tabellenaktualisierungen wichtig, um die Zuverlässigkeit unserer Daten zu verstehen. Die folgende Abfrage, Beispiel 4-4, operationalisiert Freshness (wie in Abbildung 4-2 dargestellt), indem sie eine Metrik für DAYS_SINCE_LAST_UPDATE einführt. (Hinweis: Da in diesem Tutorial SQLite3 verwendet wird, unterscheidet sich die SQL-Syntax zur Berechnung der Zeitunterschiede in MySQL, Snowflake und anderen Umgebungen).

Beispiel 4-4. Abfrage, die die Anzahl der Tage seit der Aktualisierung des Datensatzes abfragt
WITH UPDATES AS(
  SELECT
    DATE_ADDED,
    COUNT(*) AS ROWS_ADDED
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
)
  
SELECT
  DATE_ADDED,
  JULIANDAY(DATE_ADDED) - JULIANDAY(LAG(DATE_ADDED) OVER(
    ORDER BY DATE_ADDED
  )) AS DAYS_SINCE_LAST_UPDATE
FROM
  UPDATES;
Abbildung 4-2. Rendering von Freshness-Mustern innerhalb unseres Datensatzes mit einem Jupyter Notebook

Die resultierende Tabelle, Beispiel 4-5, besagt: "Am Datum X waren die neuesten Daten in EXOPLANETS Y Tage alt." Dies ist eine Information, die nicht explizit in der Spalte DATE_ADDED in der Tabelle zu finden ist - aber die Anwendung der Datenbeobachtung gibt uns die Möglichkeit, sie aufzudecken. Dies wird in Abbildung 4-3 veranschaulicht, wo Freshness-Anomalien durch die hohen Y-Werte dargestellt werden. Dies sind Verzögerungen bei der Aktualisierung der Tabelle, die wir mit einem einfachen Detektor abfragen können.

Beispiel 4-5. Freshness-Tabelle der Exoplanetendaten aus der Abfrage in Beispiel 4-4
DATE_ADDED     DAYS_SINCE_LAST_UPDATE
2020–01–01     
2020–01–02     1
2020–01–03     1
2020–01–04     1
2020–01–05     1
...            ...
2020–07–14     1
2020–07–15     1
2020–07–16     1
2020–07–17     1
2020–07–18     1
Abbildung 4-3. Visualisierung von Frischeanomalien, die durch hohe Y-Werte dargestellt werden

Jetzt haben wir die Daten, die wir brauchen, um Frische-Anomalien zu erkennen. Jetzt müssen wir nur noch einen Schwellenwert für Y festlegen - wie viele Tage sind zu alt? Ein Parameter macht aus einer Abfrage ( Beispiel 4-6) einen Detektor, denn er entscheidet, was als anomal gilt (sprich: was eine Warnung wert ist) und was nicht.

Beispiel 4-6. Geänderte Abfrage zur Warnung vor Daten, die die erwartete Aktualität von Exoplanetendaten überschreiten
WITH UPDATES AS(
  SELECT
    DATE_ADDED,
    COUNT(*) AS ROWS_ADDED
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
),
  
NUM_DAYS_UPDATES AS (
  SELECT
    DATE_ADDED,
    JULIANDAY(DATE_ADDED) - JULIANDAY(LAG(DATE_ADDED)
      OVER(
        ORDER BY DATE_ADDED
      )
    ) AS DAYS_SINCE_LAST_UPDATE
  FROM
    UPDATES
)
  
SELECT
  *
FROM
  NUM_DAYS_UPDATES
WHERE
  DAYS_SINCE_LAST_UPDATE > 1;

Die an uns zurückgegebenen Daten, Beispiel 4-7, stellen Daten dar, an denen Frischevorfälle aufgetreten sind.

Beispiel 4-7. Daten, die von der Abfrage aus Beispiel 4-6 zurückgegeben werden
DATE_ADDED     DAYS_SINCE_LAST_UPDATE
2020–02–08     8
2020–03–30     4
2020–05–14     8
2020–06–07     3
2020–06–17     5
2020–06–30     3

Am 14.05.2020 waren die neuesten Daten in der Tabelle 8 Tage alt! Ein solcher Ausfall könnte eine Störung in unserer Datenpipeline darstellen und wäre gut zu wissen, wenn wir diese Daten für etwas sehr Wichtiges verwenden (und wenn wir sie in einer Produktionsumgebung verwenden, ist das wahrscheinlich der Fall). Wie in Abbildung 4-4 dargestellt, können wir Freshness-Anomalien erkennen, indem wir Schwellenwerte festlegen, die eine akzeptable Zeitspanne seit der letzten Aktualisierung darstellen.

Abbildung 4-4. Visualisierung von Frischeanomalien mithilfe von Schwellenwerten

Beachte vor allem die letzte Zeile der Abfrage: DAYS_SINCE_LAST_UPDATE > 1;.

Hier ist 1 ein Modellparameter - es gibt nichts "Richtiges" an dieser Zahl, aber eine Änderung wirkt sich darauf aus, welche Daten wir als Vorfälle betrachten. Je kleiner die Zahl ist, desto mehr echte Anomalien werden wir erkennen (hohe Rückrufquote), aber es ist wahrscheinlich, dass einige dieser "Anomalien" keine echten Ausfälle darstellen. Je größer die Zahl, desto größer ist die Wahrscheinlichkeit, dass alle Anomalien, die wir erfassen, echte Anomalien sind (hohe Genauigkeit), aber es ist möglich, dass wir einige übersehen.

Für dieses Beispiel könnten wir 1 in 7 ändern und so nur die beiden schlimmsten Ausfälle (am 08.02.2020 und 14.05.2020) abfangen. Die Wahl hängt vom jeweiligen Anwendungsfall und den Zielen ab. Es ist ein wichtiges Gleichgewicht, das bei der Anwendung der Datenbeobachtung in Produktionsumgebungen im großen Maßstab immer wieder auftaucht .

In Abbildung 4-5 verwenden wir denselben Freshness-Detektor, wobei die SQLite-Abfrage DAYS_SINCE_LAST_UPDATE > 3; als Schwellenwert dient. Zwei der kleineren Ausfälle bleiben nun unentdeckt.

Abbildung 4-5. Eingrenzung der Suche nach Anomalien (DAYS_SINCE_LAST_UPDATE > 3)

Jetzt sehen wir uns denselben Freshness-Detektor an, aber DAYS_SINCE_LAST_UPDATE > 7; dient jetzt als Schwellenwert. Bis auf die beiden größten Ausfälle bleiben alle unentdeckt(Abbildung 4-6).

Genau wie Planeten liegen auch optimale Modellparameter in einer "Goldlöckchen-Zone" oder einem "Sweet Spot" zwischen Werten, die als zu niedrig und zu hoch gelten.

Abbildung 4-6. Weitere Eingrenzung der Suche nach Anomalien (DAYS_SINCE_LAST_UPDATE > 7 )

Verteilung verstehen

Als Nächstes wollen wir den Zustand der Verteilung unserer Daten auf Feldebene beurteilen. Die Verteilung gibt Aufschluss über alle erwarteten Werte unserer Daten und darüber, wie häufig jeder Wert vorkommt. Eine der einfachsten Fragen ist: "Wie oft sind meine Daten NULL?" In vielen Fällen ist ein gewisses Maß an unvollständigen Daten akzeptabel - aber wenn aus 10 % NULL-Rate 90 % werden, wollen wir das wissen.

In der Statistik gehen wir gerne davon aus, dass Beobachtungsmengen aus Basisverteilungen gezogen werden, die mathematischen Regeln gehorchen. Wir nennen erstere "Stichprobenverteilungen" und letztere "wahre Verteilungen". In der Statistik gibt es eine Beobachtung über natürliche Prozesse, das so genannte zentrale Grenzwertsatz, der besagt, dass sich die Verteilungen von unabhängig voneinander erzeugten Stichproben einer bestimmten Verteilung annähern, wenn die Anzahl der Stichproben größer wird.

Die Anwendung der Gauß-Verteilung kann eine erste Eingabeaufforderung für die Erkennung von Anomalien sein, die recht naiv, aber überraschend effektiv ist: die Berechnung der Standardbewertung für jede Beobachtung. Das heißt, du ziehst μ ab und teilst dann durch σ. Dieser Wert (auch z-Score genannt) gibt einen quantifizierbaren Maßstab dafür, wie "weit draußen" (auf der Glockenkurve) jede Beobachtung liegt. Anomalieerkennung: gelöst! Ziehe einfach eine Linie von der Mitte der Glockenkurve aus und bezeichne alles, was außerhalb dieser Linie liegt, als "anomal". Vom statistischen Standpunkt aus gesehen, wirst du damit richtig liegen. Leider ist die statistische Theorie kein überzeugender Ansatz für die Erkennung von Anomalien im sehr konkreten Bereich der Datenqualität, und zwar aus zwei Gründen.

Erstens: Das zentrale Grenzwertsatztheorem besagt eine Schlüsseleigenschaft des Datenerzeugungsprozesses, die viele Menschen übersehen: Unabhängige, zufällige Beobachtungen ergeben im Grenzfall Normalverteilungen. Das ist eine gute Annahme, wenn man die Lautstärke des Windes im Gras oder die Schrittlänge des durchschnittlichen New Yorkers misst. Nicht so gut ist sie für Business Intelligence-Daten, bei denen die Beobachtungen in der Regel stark korreliert und mit anderen Variablen vermischt sind. Zum Beispiel sind die "täglichen Kunden" bei Chick-Fil-A, das sonntags schließt, nicht normalverteilt, da 1/7 aller Beobachtungen 0 sind. Diese Beobachtungen werden nicht zufällig generiert, sondern vom Wochentag beeinflusst.

Zweitens gibt es eine Unterscheidung zwischen "anomalen" und "interessanten" Beobachtungen, die mit rein statistischem Denken nicht ganz erfasst werden kann. Um das zu verdeutlichen, betrachte den z-Score, der ein paar Absätze zuvor besprochen wurde. Wir haben (im Scherz) gesagt, dass die Erkennung von Anomalien mit einem einfachen z-Score gelöst werden kann; leider ist das selten der Fall.

Wenn wir "Anomalie" als alles definieren, was, sagen wir, drei Standardabweichungen vom Mittelwert der Verteilung abweicht, können wir sicher sein, dass wir das für alle Daten "richtig" finden. Aber es geht uns nicht nur darum, einfach nur anomale Messwerte zu identifizieren. Zum einen enthalten unsere Zeitreihen wichtige kontextbezogene Informationen (Welcher Wochentag war es? Wiederholt sich das Muster?). Noch wichtiger ist jedoch, dass nicht alle anomalen Beobachtungen interessant sind - sie helfen uns nicht, Datenausfälle zu erkennen und zu korrigieren. In Beispiel 4-8 werden Daten mit einer anomalen Verteilung abgefragt.

Beispiel 4-8. Abfrage zum Abrufen von Daten über anomale Verteilungen
SELECT
  DATE_ADDED,
  CAST(
    SUM(
      CASE
        WHEN DISTANCE IS NULL THEN 1
        ELSE 0
      END
    ) AS FLOAT) / COUNT(*) AS DISTANCE_NULL_RATE,
  CAST(
    SUM(
      CASE
        WHEN G IS NULL THEN 1
        ELSE 0
      END
    ) AS FLOAT) / COUNT(*) AS G_NULL_RATE,
  CAST(
    SUM(
      CASE
        WHEN ORBITAL_PERIOD IS NULL THEN 1
        ELSE 0
      END
    ) AS FLOAT) / COUNT(*) AS ORBITAL_PERIOD_NULL_RATE,
  CAST(
    SUM(
      CASE
        WHEN AVG_TEMP IS NULL THEN 1
        ELSE 0
      END
    ) AS FLOAT) / COUNT(*) AS AVG_TEMP_NULL_RATE
FROM
  EXOPLANETS
GROUP BY
  DATE_ADDED;

Diese Abfrage liefert eine Menge Daten, wie in Beispiel 4-9 dargestellt.

Beispiel 4-9. Daten aus Beispiel 4-8 abfragen
date_added     DISTANCE_NULL_RATE    G_NULL_RATE          ORBITAL_PERIOD_NULL_RATE
2020-01-01     0.0833333333333333    0.178571428571429    0.214285714285714
2020-01-02     0.0                   0.152173913043478    0.326086956521739
2020-01-03     0.0594059405940594    0.188118811881188    0.237623762376238
2020-01-04     0.0490196078431373    0.117647058823529    0.264705882352941
...            ...                   ...                  ...
2020-07-13     0.0892857142857143    0.160714285714286    0.285714285714286
2020-07-14     0.0673076923076923    0.125                0.269230769230769
2020-07-15     0.0636363636363636    0.118181818181818    0.245454545454545
2020-07-16     0.058252427184466     0.145631067961165    0.262135922330097
2020-07-17     0.101123595505618     0.0898876404494382   0.247191011235955
2020-07-18     0.0673076923076923    0.201923076923077    0.317307692307692

Die allgemeine Formel CAST(SUM(CASE WHEN SOME_METRIC IS NULL THEN 1 ELSE 0 END) AS FLOAT) / COUNT(*) sagt uns, wenn sie nach der Spalte DATE_ADDED gruppiert wird, die Rate der NULL-Werte für SOME_METRIC in den täglichen Stapeln neuer Daten in EXOPLANETS. Es ist schwer, einen Eindruck zu bekommen, wenn man sich die rohe Ausgabe ansieht, aber eine visuelle Darstellung(Abbildung 4-8) kann helfen, diese Anomalie zu verdeutlichen.

Abbildung 4-8. Durch die Darstellung verschiedener Ereignisse, die durch Nullraten ausgelöst werden, können wir klar erkennen, welche Daten anomal waren

Die Grafiken machen deutlich, dass es Nullraten-"Spikes" gibt, die wir aufspüren sollten. Konzentrieren wir uns vorerst nur auf die letzte Kennzahl AVG_TEMP. Mit der Abfrage in Beispiel 4-10 können wir Nullspikes mit einem einfachen Schwellenwert erkennen.

Beispiel 4-10. Erkennen von Nullwerten in der Spalte AVG_TEMP des Datensatzes EXOPLANETS 
WITH NULL_RATES AS(
  SELECT
    DATE_ADDED,
    CAST(
      SUM(
        CASE
          WHEN AVG_TEMP IS NULL THEN 1
          ELSE 0
        END
      ) AS FLOAT) / COUNT(*) AS AVG_TEMP_NULL_RATE 
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
)
  
SELECT
  *
FROM
  NULL_RATES
WHERE
  AVG_TEMP_NULL_RATE  > 0.9;

In Beispiel 4-11 geben wir die entsprechenden Daten in ihrer Rohform weiter und zeigen die Zeilen mit Nullwerten in der Spalte AVG_TEMP des Datensatzes.

Beispiel 4-11. AVG_TEMP Zeilen mit Nullwerten
DATE_ADDED     AVG_TEMP_NULL_RATE
2020-03-09     0.967391304347826
2020-06-02     0.929411764705882
2020-06-03     0.977011494252874
2020-06-04     0.989690721649485
2020-06-07     0.987804878048781
2020-06-08     0.961904761904762

In Abbildung 4-9 zeigen wir, wo die anomalen Spitzen lagen, die mit der Rate der Nullwerte in der Temperaturspalte unseres EXOPLANETS Datensatzes korrelieren.

Was die Erkennungsalgorithmen angeht, so ist dieser Ansatz zur Identifizierung von Nullwerten eher ein stumpfes Instrument. Manchmal sind die Muster in unseren Daten so einfach, dass ein Schwellenwert wie dieser ausreicht, um sie zu erkennen. In anderen Fällen sind die Daten jedoch verrauscht oder weisen andere Komplikationen auf, wie z. B. saisonale Schwankungen, so dass wir unseren Ansatz ändern müssen.

Abbildung 4-9. Erkennen von Nullspitzen in der Durchschnittstemperatur
Hinweis

Saisonalität bezieht sich auf die Tendenz einer Zeitreihe, in bestimmten Intervallen vorhersehbare Schwankungen zu zeigen. Zum Beispiel könnten die Daten für "Kirchenbesucher" eine wöchentliche Saisonalität mit einer starken Tendenz zum Sonntag aufweisen, und die Daten für die Mantelverkäufe eines Kaufhauses würden wahrscheinlich eine jährliche Saisonalität mit einem Hoch im Herbst und einem Tief im Frühjahr aufweisen.

Zum Beispiel scheint die Erkennung von 2020-06-02, 2020-06-03 und 2020-06-04 überflüssig. Mit der Abfrage in Beispiel 4-12 können wir Daten herausfiltern, die unmittelbar nach anderen Alarmen auftreten, um Doppelarbeit zu vermeiden.

Beispiel 4-12. Abfrage zum Herausfiltern von Daten, die unmittelbar nach anderen Ausschreibungen auftreten
WITH NULL_RATES AS(
  SELECT
    DATE_ADDED,
    CAST(
      SUM(
        CASE
          WHEN AVG_TEMP IS NULL THEN 1
          ELSE 0
        END
      ) AS FLOAT
    ) / COUNT(*) AS AVG_TEMP_NULL_RATE
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
),
  
ALL_DATES AS (
  SELECT
    *,
    JULIANDAY(DATE_ADDED) - JULIANDAY(LAG(DATE_ADDED)
      OVER(
        ORDER BY DATE_ADDED
      )
    ) AS DAYS_SINCE_LAST_ALERT
  FROM
    NULL_RATES
  WHERE
    AVG_TEMP_NULL_RATE > 0.9
)
  
SELECT
  DATE_ADDED,
  AVG_TEMP_NULL_RATE
FROM
  ALL_DATES
WHERE
  DAYS_SINCE_LAST_ALERT IS NULL OR DAYS_SINCE_LAST_ALERT > 1;

Der entsprechende Datensatz ist in Beispiel 4-13 aufgeführt. Diese Ergebnisse heben Daten hervor, die in unserem Nullwert-Anomalie-Detektor gemäß der Abfrage in Beispiel 4-12 nicht berücksichtigt werden müssen.

Beispiel 4-13. Ergebnisse der Abfrage aus Beispiel 4-12 
DATE_ADDED     AVG_TEMP_NULL_RATE
2020-03-09     0.967391304347826
2020-06-02     0.929411764705882
2020-06-07     0.987804878048781

Beachte, dass in beiden Abfragen der Schlüsselparameter 0,9 ist. Wir sagen also: "Jede Nullrate, die höher als 90 % ist, ist ein Problem, und ich muss es wissen." Diese Ergebnisse werden in Abbildung 4-10 visualisiert. So können wir das weiße Rauschen reduzieren und genauere Ergebnisse erzielen.

In diesem Fall können (und sollten) wir ein bisschen intelligenter sein, indem wir das Konzept des gleitenden Durchschnitts mit einem intelligenteren Parameter anwenden und die Abfrage in Beispiel 4-14 verwenden, um die Genauigkeit weiter zu verbessern.

Abbildung 4-10. Visualisierung von Nullraten über 90%
Beispiel 4-14. Abfrage zur Anwendung eines gleitenden Durchschnitts auf die Nullrate
WITH NULL_RATES AS(
  SELECT
    DATE_ADDED,
    CAST(SUM(CASE WHEN AVG_TEMP IS NULL THEN 1 ELSE 0 END) AS FLOAT) / 
      COUNT(*) AS AVG_TEMP_NULL_RATE
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
),
  
NULL_WITH_AVG AS(
  SELECT
    *,
    AVG(AVG_TEMP_NULL_RATE) OVER (
      ORDER BY DATE_ADDED ASC
      ROWS BETWEEN 14 PRECEDING AND CURRENT ROW) AS TWO_WEEK_ROLLING_AVG
  FROM
    NULL_RATES
  GROUP BY
    DATE_ADDED
)
  
SELECT
  *
FROM
  NULL_WITH_AVG
WHERE
  AVG_TEMP_NULL_RATE - TWO_WEEK_ROLLING_AVG > 0.3;

Die Ergebnisse der Abfrage sind in Beispiel 4-15 und in Abbildung 4-11 dargestellt. Wir sehen Nullwerte, die einen größeren Alarm auslösen könnten (d.h. mit einer Nullrate von mehr als 90%).

Beispiel 4-15. Ergebnisse der Abfrage aus Beispiel 4-14 
DATE_ADDED     AVG_TEMP_NULL_RATE    TWO_WEEK_ROLLING_AVG
2020-03-09     0.967391304347826     0.436077995611105
2020-06-02     0.929411764705882     0.441299602441599
2020-06-03     0.977011494252874     0.47913211475687
2020-06-04     0.989690721649485     0.515566041654715
2020-06-07     0.987804878048781     0.554753033524633
2020-06-08     0.961904761904762     0.594966974173356
Abbildung 4-11. Verwendung der Abfrage AVG_TEMP_NULL_RATE — TWO_WEEK_ROLLING_AVG, um bei der Identifizierung der Nullwertrate noch genauer zu werden

Eine Klarstellung: Beachte, dass wir mit der Menge filtern AVG_TEMP_NULL_RATE — TWO_WEEK_ROLLING_AVG. In anderen Fällen würden wir vielleicht die ABS() dieser Fehlergröße nehmen, aber nicht in diesem Fall - der Grund dafür ist, dass eine Nullrate viel alarmierender ist, wenn sie einen Anstieg gegenüber dem vorherigen Durchschnitt darstellt. Es kann sich nicht lohnen, zu beobachten, wenn die Häufigkeit von Nullen abrupt abnimmt, während der Wert der Erkennung eines Anstiegs der Nullrate eindeutig ist.

Bau von Monitoren für Schema und Abstammung

Im vorigen Abschnitt haben wir uns die ersten beiden Säulen der Datenbeobachtung, Frische und Verteilung, angeschaut und gezeigt, wie ein wenig SQL-Code diese Konzepte operationalisieren kann. Das sind die eher "klassischen" Probleme bei der Erkennung von Datenanomalien: Sieht bei einem stetigen Datenstrom irgendetwas nicht in Ordnung aus?

Eine gute Anomalieerkennung ist sicherlich ein Teil des Puzzles der Datenbeobachtung, aber sie ist nicht alles. Genauso wichtig ist der Kontext. Wenn eine Datenanomalie aufgetreten ist, toll. Aber wo? Welche vorgelagerten Pipelines könnten die Ursache sein? Welche nachgelagerten Dashboards werden von einer Datenanomalie betroffen sein? Und hat sich die formale Struktur meiner Daten verändert? Eine gute Datenbeobachtung hängt davon ab, ob wir in der Lage sind, Metadaten richtig zu nutzen, um diese Fragen zur Datenanomalie zu beantworten.

Im nächsten Abschnitt schauen wir uns die beiden Säulen der Datenbeobachtung an, die diese Fragen beantworten sollen: Schema und Abstammung. Auch hier verwenden wir wieder leichtgewichtige Tools wie Jupyter und SQLite, damit du unsere Umgebung leicht einrichten und diese Datenanomalien selbst ausprobieren kannst. Legen wir los.

Anomalie-Erkennung für Schemaänderungen und Lineage

Wie zuvor arbeiten wir mit fiktiven astronomischen Daten über bewohnbare Exoplaneten. Es sieht so aus, als ob unsere ältesten Daten auf den 01.01.2020 datiert sind (Hinweis: Die meisten Datenbanken speichern keine Zeitstempel für einzelne Datensätze, so dass unsere DATE_ADDED Spalte für uns den Überblick behält). Unsere neuesten Daten scheinen vom 2020-07-18 zu sein:

sqlite> SELECT DATE_ADDED FROM EXOPLANETS ORDER BY DATE_ADDED DESC LIMIT 1; 
    2020-07-18

Natürlich ist das dieselbe Tabelle, die wir im vorherigen Abschnitt verwendet haben. Wenn wir die kontextabhängigen Säulen Schema und Abstammung erforschen wollen, müssen wir unsere Umgebung erweitern.

Zusätzlich zu EXOPLANETS haben wir jetzt eine Tabelle namens EXOPLANETS_EXTENDEDdie eine Obermenge unserer vergangenen Tabelle ist. Es ist sinnvoll, sich diese als dieselbe Tabelle zu verschiedenen Zeitpunkten vorzustellen. Tatsächlich enthält EXOPLANETS_EXTENDED Daten, die bis zum 01.01.2020 zurückreichen:

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED ASC 
    LIMIT 1; 2020-01-01

Sie enthält aber auch Daten bis zum 2020-09-06, also weiter als EXOPLANETS:

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED DESC 
    LIMIT 1; 2020-09-0

Es gibt noch einen weiteren Unterschied zwischen diesen Tabellen, wie in Beispiel 4-16 zu sehen ist. Es gibt zwei zusätzliche Felder, die die Wahrscheinlichkeit von Anomalien noch größer machen.

Beispiel 4-16. Zwei zusätzliche Felder im Datensatz EXOPLANETS_EXTENDED 
sqlite> PRAGMA TABLE_INFO(EXOPLANETS_EXTENDED);
_ID             | VARCHAR(16777216)  | 1 | | 0
DISTANCE        | FLOAT              | 0 | | 0
G               | FLOAT              | 0 | | 0
ORBITAL_PERIOD  | FLOAT              | 0 | | 0
AVG_TEMP        | FLOAT              | 0 | | 0
DATE_ADDED      | TIMESTAMP_NTZ(6)   | 1 | | 0
ECCENTRICITY    | FLOAT              | 0 | | 0  1
ATMOSPHERE      | VARCHAR(16777216)  | 0 | | 0  2

Zusätzlich zu den sechs Feldern in EXOPLANETS enthält die Tabelle EXOPLANETS_EXTENDED zwei weitere Felder:

1

ECCENTRICITY: die Exzentrizität der Umlaufbahn des Planeten um seinen Gaststern

2

ATMOSPHERE: die vorherrschende chemische Zusammensetzung der Atmosphäre des Planeten

Beachte, dass wie DISTANCE, G, ORBITAL_PERIOD und AVG_TEMP auch ECCENTRICITY und ATMOSPHERE für einen bestimmten Planeten NULL sein können, weil Daten fehlen oder fehlerhaft sind. Schurkenplaneten haben zum Beispiel eine undefinierte Exzentrizität ihrer Umlaufbahn und viele Planeten haben überhaupt keine Atmosphären.

Beachte auch, dass die Daten nicht zurückverfolgt werden, d.h. Dateneinträge vom Anfang der Tabelle (Daten, die auch in der Tabelle EXOPLANETS enthalten sind) enthalten keine Informationen über Exzentrizität und Atmosphäre. In Beispiel 4-17 teilen wir eine Abfrage, um zu verdeutlichen, dass ältere Daten nicht aufgefüllt werden; dies zeigt hoffentlich die Schemaänderung, die daraus resultiert.

Beispiel 4-17. Abfrage, die hervorhebt, dass ältere Daten nicht rückgefüllt werden
SELECT
 DATE_ADDED,
 ECCENTRICITY,
 ATMOSPHERE
FROM
 EXOPLANETS_EXTENDED
ORDER BY
 DATE_ADDED ASC
LIMIT 10;

Wir können diese Datei schön und durchsuchbar machen, wenn wir diesen Fehler beheben: In dieser CSV-Datei wurden in Zeile 0 keine Kommas gefunden (wie in Beispiel 4-18 dargestellt).

Beispiel 4-18. Hinzufügen von zwei neuen Spalten, was eine Schemaänderung in unserem EXOPLANETS Datensatz
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |
2020-01-01 | |

Die Hinzufügung von zwei Feldern ist ein Beispiel für eine Schemaänderung - der formale Bauplan unserer Daten wurde geändert. Schemaänderungen treten auf, wenn die Struktur deiner Daten verändert wird, und sind eine Datenanomalie, die bei der manuellen Fehlersuche frustrierend sein kann. Schemaänderungen können auf verschiedene Dinge in deinen Daten hinweisen, z. B.:

  • Das Hinzufügen neuer API-Endpunkte

  • Vermeintlich veraltete Felder, die noch nicht veraltet sind

  • Das Addieren oder Subtrahieren von Spalten, Zeilen oder ganzen Tabellen

In einer idealen Welt würden wir diese Änderung gerne aufzeichnen, da sie ein Hinweis auf mögliche Probleme in unserer Pipeline ist. Leider ist unsere Datenbank nicht so konfiguriert, dass sie solche Änderungen aufzeichnet. Sie hat keine Versionsgeschichte, wie in Beispiel 4-19 dargestellt. Eine Schemaänderung kann sich leicht einschleichen.

Beispiel 4-19. Keine Versionierungshistorie im Datensatz
sqlite> PRAGMA TABLE_INFO(EXOPLANETS_COLUMNS);
 
DATE    | TEXT | 0 | | 0
 
COLUMNS | TEXT | 0 | | 0

Wir sind auf dieses Problem gestoßen, als wir das Alter einzelner Datensätze abfragten und fügten die Spalte DATE_ADDED hinzu, um das Problem zu lösen. In diesem Fall werden wir etwas Ähnliches tun, nur dass wir eine ganze Tabelle hinzufügen.

Die Tabelle EXOPLANETS_COLUMNS "versioniert" unser Schema, indem sie die Spalten in EXOPLANETS_EXTENDED zu einem bestimmten Datum aufzeichnet. Wenn wir uns den ersten und den letzten Eintrag ansehen, sehen wir, dass sich die Spalten zu einem bestimmten Zeitpunkt definitiv geändert haben, wie in Beispiel 4-20 zu sehen ist. Die beiden Einträge in Beispiel 4-20 zeigen, dass zwei neue Spalten in unserem EXOPLANETS Datensatz hinzugekommen sind - mit anderen Worten, eine Schemaänderung.

Beispiel 4-20. Zwei Einträge, die eine Schemaänderung hervorheben
sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE ASC LIMIT 1;
2020-01-01 | [
   (0, '_id', 'TEXT', 0, None, 0),
   (1, 'distance', 'REAL', 0, None, 0),
   (2, 'g', 'REAL', 0, None, 0),
   (3, 'orbital_period', 'REAL', 0, None, 0),
   (4, 'avg_temp', 'REAL', 0, None, 0),
   (5, 'date_added', 'TEXT', 0, None, 0)
 ]
 
sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE DESC LIMIT 1;
2020-09-06 | [
   (0, '_id', 'TEXT', 0, None, 0),
   (1, 'distance', 'REAL', 0, None, 0),
   (2, 'g', 'REAL', 0, None, 0),
   (3, 'orbital_period', 'REAL', 0, None, 0),
   (4, 'avg_temp', 'REAL', 0, None, 0),
   (5, 'date_added', 'TEXT', 0, None, 0),
   (6, 'eccentricity', 'REAL', 0, None, 0),
   (7, 'atmosphere', 'TEXT', 0, None, 0)
 ]

Nun zurück zu unserer ursprünglichen Frage: Wann genau wurde das Schema geändert? Da unsere Spaltenlisten mit Datumsangaben indiziert sind, können wir mit einem schnellen SQL-Skript das Datum der Änderung und einen guten Anhaltspunkt dafür finden, wo Anomalien liegen, wie in Beispiel 4-21 dargestellt.

Beispiel 4-21. Eine Abfrage der erweiterten Tabelle EXOPLANETS, um zu zeigen, wann das Schema für den Datensatz geändert wurde
WITH CHANGES AS(
 SELECT
   DATE,
   COLUMNS AS NEW_COLUMNS,
   LAG(COLUMNS) OVER(ORDER BY DATE) AS PAST_COLUMNS
 FROM
   EXOPLANETS_COLUMNS
)
 
SELECT
   *
FROM
   CHANGES
WHERE
   NEW_COLUMNS != PAST_COLUMNS
ORDER BY
   DATE ASC;

Beispiel 4-22 enthält die zurückgegebenen Daten, die wir zur besseren Lesbarkeit umformatiert haben. Anhand der Daten sehen wir, dass das Schema am 2022-07-19 geändert wurde.

Beispiel 4-22. Ergebnisse aus der Abfrage in Beispiel 4-21
DATE:          2020–07–19
NEW_COLUMNS:  [
               (0, '_id', 'TEXT', 0, None, 0),
               (1, 'distance', 'REAL', 0, None, 0),
               (2, 'g', 'REAL', 0, None, 0),
               (3, 'orbital_period', 'REAL', 0, None, 0),
               (4, 'avg_temp', 'REAL', 0, None, 0),
               (5, 'date_added', 'TEXT', 0, None, 0),
               (6, 'eccentricity', 'REAL', 0, None, 0),
               (7, 'atmosphere', 'TEXT', 0, None, 0)
          ]
PAST_COLUMNS: [
               (0, '_id', 'TEXT', 0, None, 0),
               (1, 'distance', 'REAL', 0, None, 0),
               (2, 'g', 'REAL', 0, None, 0),
               (3, 'orbital_period', 'REAL', 0, None, 0),
               (4, 'avg_temp', 'REAL', 0, None, 0),
               (5, 'date_added', 'TEXT', 0, None, 0)
          ]

Mit dieser Abfrage erhalten wir das fragliche Datum: 2020-07-19. Wie bei der Überwachung von Freshness und Distribution folgt auch die Überwachung von Schemata einem bestimmten Muster: Wir identifizieren die nützlichen Metadaten, die den Zustand der Pipeline anzeigen, verfolgen sie und entwickeln Detektoren, die uns auf mögliche Probleme aufmerksam machen. Die Bereitstellung einer zusätzlichen Tabelle wie EXOPLANETS_COLUMNS ist eine Möglichkeit, das Schema zu verfolgen, aber es gibt noch viele andere. Wir ermutigen dich, darüber nachzudenken, wie du einen Schemaänderungsdetektor für deine eigene Datenpipeline implementieren kannst!

Abstammung visualisieren

Wir haben Lineage als die ganzheitlichste der fünf Säulen der Datenbeobachtung beschrieben, und das aus gutem Grund. Die Datenabfolge kontextualisiert Vorfälle, indem sie uns sagt, (1) welche nachgelagerten Quellen betroffen sein könnten und (2) welche vorgelagerten Quellen die Hauptursache sein könnten. Auch wenn es nicht intuitiv ist, Lineage mit SQL-Code zu "visualisieren", kann ein kurzes Beispiel zeigen, wie nützlich es sein kann. (In Kapitel 6 zeigen wir dir, wie du mit Hilfe gängiger Open-Source-Frameworks ein eigenes Lineage-System auf Feldebene erstellen kannst).

Um zu zeigen, wie das funktioniert, fügen wir eine weitere Tabelle zu unserer Datenbank hinzu. Bis jetzt haben wir Daten über Exoplaneten erfasst. Eine interessante Frage ist: Wie viele dieser Planeten könnten Leben beherbergen?

Die Tabelle HABITABLES enthält Daten von EXOPLANETS, die uns helfen, diese Frage zu beantworten, wie in Beispiel 4-23 gezeigt wird.

Beispiel 4-23. HABITABLES gibt Auskunft darüber, ob die Planeten, die in EXOPLANETS bewohnbar sind
sqlite> PRAGMA TABLE_INFO(HABITABLES);
_id           | TEXT | 0 | | 0  1
perihelion    | REAL | 0 | | 0  2
aphelion      | REAL | 0 | | 0  3
atmosphere    | TEXT | 0 | | 0  4
habitability  | REAL | 0 | | 0  5
min_temp      | REAL | 0 | | 0  6
max_temp      | REAL | 0 | | 0  7
date_added    | TEXT | 0 | | 0  8

Ein Eintrag in HABITABLES enthält Folgendes:

1

_id: eine UUID, die dem Planeten entspricht

2

perihelion: der geringste Abstand zum Himmelskörper während einer Umlaufperiode

3

apheliondie weiteste Entfernung zum Himmelskörper während einer Umlaufperiode

4

atmosphere: die vorherrschende chemische Zusammensetzung der Atmosphäre des Planeten

5

habitability: eine reelle Zahl zwischen 0 und 1, die angibt, wie wahrscheinlich es ist, dass der Planet Leben beherbergt

6

min_temp: die minimale Temperatur auf der Erdoberfläche

7

max_temp: die maximale Temperatur auf der Erdoberfläche

8

date_addedDatum, an dem unser System den Planeten entdeckt und automatisch in unsere Datenbanken aufgenommen hat

Wie die Spalten in EXOPLANETS dürfen auch die Werte für perihelion, aphelion, atmosphere, min_temp und max_temp NULL sein. Tatsächlich sind perihelion und aphelion für jedes _id in EXOPLANETS, bei dem eccentricity NULL ist, NULL, da du die Orbitalexzentrizität zur Berechnung dieser Metriken verwendest. Das erklärt, warum diese beiden Felder in unseren älteren Dateneinträgen immer NULL sind.

Um zu sehen, welche Exoplaneten am bewohnbarsten sind, können wir die folgende Abfrage verwenden, um die Ausgabe in Beispiel 4-24 zu erstellen:

sqlite> SELECT * FROM HABITABLES LIMIT 5;
Beispiel 4-24. Ausgabe der Abfrage, um ein Gefühl für die bewohnbarsten Exoplaneten zu bekommen
_id,perihelion,aphelion,atmosphere,habitability,min_temp,max_temp,date_added
c168b188-ef0c-4d6a-8cb2-f473d4154bdb,,,,0.291439672855434,,,2020-01-01
e7b56e84-41f4-4e62-b078-01b076cea369,,,,0.835647137991933,,,2020-01-01
a27030a0-e4b4-4bd7-8d24-5435ed86b395,,,,0.894000806332343,,,2020-01-01
54f9cf85-eae9-4f29-b665-855357a14375,,,,0.41590200852556,103.71374885412 ...
4d06ec88-f5c8-4d03-91ef-7493a12cd89e,,,,0.593524201489497,,,2020-01-01

Wir wissen also, dass HABITABLES von den Werten in EXOPLANETS (oder auch EXOPLANETS_EXTENDED) abhängt, und EXOPLANETS_COLUMNS ebenso. Ein Abhängigkeitsdiagramm unserer Datenbank ist in Abbildung 4-12 zu sehen.

Abbildung 4-12. Abhängigkeitsdiagramm, das die Verbindung zwischen den Quelldaten und den nachgelagerten "Produkten" darstellt

Eine sehr einfache Abstammungsinformation, aber schon nützlich. Schauen wir uns eine Datenanomalie auf HABITABLES im Zusammenhang mit dieser Grafik an und sehen wir, was wir daraus lernen können.

Untersuchen einer Datenanomalie

Wenn wir eine wichtige Kennzahl haben, wie habitability in HABITABLES, können wir den Zustand dieser Kennzahl auf verschiedene Weise beurteilen. Wie hoch ist zum Beispiel der Durchschnittswert der habitability für neue Daten an einem bestimmten Tag? In Beispiel 4-25 fragen wir den Durchschnittswert der Bewohnbarkeit für neue Exoplanetendaten ab.

Beispiel 4-25. Abfrage zur Ermittlung des durchschnittlichen Habitabilitätswerts für neue Exoplanetendaten
SELECT
  DATE_ADDED,
  AVG(HABITABILITY) AS AVG_HABITABILITY
FROM
  HABITABLES
GROUP BY
  DATE_ADDED;

Beispiel 4-26 ist die CSV-Datei, die durch die Abfrage erzeugt wird.

Beispiel 4-26. Ergebnisse der Abfrage aus Beispiel 4-25 
DATE_ADDED,AVG_HABITABILITY
2020-01-01,0.435641365919993
2020-01-02,0.501288741945045
2020-01-03,0.512285861062438
2020-01-04,0.525461586113648
2020-01-05,0.528935065722722
...,...
2020-09-02,0.234269938329633
2020-09-03,0.26522042788867
2020-09-04,0.267919611991401
2020-09-05,0.298614978406792
2020-09-06,0.276007150628875

Wenn wir uns diese Daten ansehen, sehen wir, dass etwas nicht stimmt. Es sieht so aus, als hätten wir eine Datenanomalie. Der Durchschnittswert für die Bewohnbarkeit liegt normalerweise bei 0,5, aber er halbiert sich später in den aufgezeichneten Daten auf etwa 0,25(Abbildung 4-13).

Abbildung 4-13. Visualisierung der CSV-Datei, um besser zu verstehen, wo die Datenanomalie aufgetreten ist - und warum

In Abbildung 4-13 sehen wir deutlich, dass es sich um eine Datenanomalie handelt, aber was genau ist hier los? Mit anderen Worten: Was ist die Ursache für diese Datenanomalie?

Warum schauen wir uns nicht die Null-Rate für die Bewohnbarkeit an, so wie wir es bei der Erkennung von Verteilungsanomalien weiter oben im Kapitel getan haben? Dazu können wir die Abfrage in Beispiel 4-27 nutzen, die die Null-Rate für unseren neuen, erweiterten Datensatz ermittelt und uns so Hinweise auf mögliche Datenanomalien gibt.

Beispiel 4-27. Nullsatzabfrage für neuen Datensatz
SELECT
 DATE_ADDED,
 CAST(
   SUM(
    CASE
    WHEN HABITABILITY IS NULL THEN 1
    ELSE 0
    END
   ) AS FLOAT) / COUNT(*) AS HABITABILITY_NULL_RATE
FROM
 HABITABLES
GROUP BY
 DATE_ADDED;

Zum Glück sieht hier nichts ungewöhnlich aus, wie du an den Ergebnissen in Beispiel 4-28 sehen kannst.

Beispiel 4-28. Ergebnisse der Abfrage aus Beispiel 4-27 
DATE_ADDED,HABITABILITY_NULL_RATE
2020-01-01,0.0
2020-01-02,0.0
2020-01-03,0.0
2020-01-04,0.0
2020-01-05,0.0
...,...
2020-09-02,0.0
2020-09-03,0.0
2020-09-04,0.0
2020-09-05,0.0
2020-09-06,0.0

Wie du in Beispiel 4-28 sehen kannst, sieht das nicht vielversprechend aus, um die Ursache für unser Problem zu finden. Was wäre, wenn wir uns eine andere Verteilungskennzahl ansehen würden, nämlich den Anteil der Nullwerte? Dies ist eine weitere mögliche Ursache für eine Verteilungsanomalie. Führen wir eine weitere Abfrage aus, wie in Beispiel 4-29 gezeigt, um genau das zu tun.

Beispiel 4-29. Abfrage zum Verständnis der Rate von Nullwerten
SELECT
 DATE_ADDED,
 CAST(
   SUM(
    CASE
    WHEN HABITABILITY IS 0 THEN 1
    ELSE 0
    END
   ) AS FLOAT) / COUNT(*) AS HABITABILITY_ZERO_RATE
FROM
 HABITABLES
GROUP BY
 DATE_ADDED;

Hier scheint etwas nicht in Ordnung zu sein, wie die in Beispiel 4-30 dargestellte CSV-Datei zeigt. Bei mehreren Exoplaneten ist die Habitabilitätsrate gleich null, was eine Ursache für eine Datenanomalie sein könnte.

Beispiel 4-30. Ergebnisse aus unserer Abfrage in Beispiel 4-29
DATE_ADDED,HABITABILITY_ZERO_RATE
2020-01-01,0.0
2020-01-02,0.0
2020-01-03,0.0
2020-01-04,0.0
2020-01-05,0.0
...,...
2020-09-02,0.442307692307692
2020-09-03,0.441666666666667
2020-09-04,0.466666666666667
2020-09-05,0.46218487394958
2020-09-06,0.391304347826087

In Abbildung 4-14 visualisieren wir die Ergebnisse unserer Zero-Rate-Abfrage mit AS FLOAT) / COUNT (*) AS HABITABILITY_ZERO_RATEDies veranschaulicht die anomalen Ergebnisse im August und September 2020.

Abbildung 4-14. Visualisierung der Nullwertraten und der wahrscheinlichen Ursache der Anomalie

Wir können einen der Verteilungsdetektoren, die wir weiter oben in diesem Kapitel gebaut haben, anpassen, um das erste Datum einer nennenswerten Nullrate im Habitabilitätsfeld zu erhalten, wie in Beispiel 4-31 gezeigt wird.

Beispiel 4-31. Abfrage nach dem ersten Datum mit Nullsätzen im Feld Bewohnbarkeit
WITH HABITABILITY_ZERO_RATES AS(
  SELECT
    DATE_ADDED,
    CAST(
      SUM(
        CASE
          WHEN HABITABILITY IS 0 THEN 1
          ELSE 0
        END
      ) AS FLOAT) / COUNT(*) AS HABITABILITY_ZERO_RATE
  FROM
    HABITABLES
  GROUP BY
    DATE_ADDED
),
  
CONSECUTIVE_DAYS AS(
SELECT
  DATE_ADDED,
  HABITABILITY_ZERO_RATE,
  LAG(HABITABILITY_ZERO_RATE) OVER(ORDER BY DATE_ADDED) 
    AS PREV_HABITABILITY_ZERO_RATE
FROM
  HABITABILITY_ZERO_RATES
)
  
SELECT
  *
FROM
  CONSECUTIVE_DAYS
WHERE
  PREV_HABITABILITY_ZERO_RATE = 0 AND
  HABITABILITY_ZERO_RATE != 0;

Wir können diese Abfrage dann über die Befehlszeile in Beispiel 4-32 ausführen, um das erste Datum mit nennenswerten Nullen im Habitability-Feld zu finden.

Beispiel 4-32. Befehlszeilenschnittstelle zur Ausführung der Abfrage in Beispiel 4-31
$ sqlite3 EXOPLANETS.db < queries/lineage/habitability-zero-rate-detector.sql
DATE_ADDED | HABITABILITY_ZERO_RATE | PREV_HABITABILITY_ZERO_RATE
2020–07–19 | 0.369047619047619 | 0.0

Der 19.07.2020 war das erste Datum, an dem die Nullrate anomale Ergebnisse anzeigte. Das ist derselbe Tag, an dem auch die Schemaänderung in EXOPLANETS_EXTENDED entdeckt wurde. EXOPLANETS_EXTENDED ist HABITABLES vorgeschaltet, daher ist es sehr gut möglich, dass diese beiden Vorfälle miteinander zusammenhängen.

Auf diese Weise können wir die Ursache von Vorfällen identifizieren und schneller zu deren Lösung gelangen. Vergleiche die beiden folgenden Erklärungen für diesen Vorfall auf HABITABLES:

  1. Am 19.07.2020 ist die Nullrate der Habitability-Spalte in der Tabelle HABITABLES von 0% auf 37% gestiegen.

  2. Am 19.07.2020 begannen wir, zwei zusätzliche Felder, eccentricity und atmosphere, in der Tabelle EXOPLANETS zu verfolgen. Dies wirkte sich negativ auf die nachgelagerte Tabelle HABITABLES aus, da die Felder min_temp und max_temp oft auf extreme Werte gesetzt wurden, wenn eccentricity nicht NULL war. Dies wiederum führte dazu, dass das Feld habitability eine Nullrate hatte, die wir als anomale Abnahme des Durchschnittswerts erkannten.

Lasst uns diese Erklärungen aufschlüsseln. Bei Erklärung 1 wird nur die Tatsache berücksichtigt, dass eine Datenanomalie aufgetreten ist. Erklärung 2 nutzt die Abhängigkeiten zwischen Tabellen und Feldern, um den Vorfall in einen Kontext zu stellen und die Ursache zu ermitteln. Alles, was in der zweiten Erklärung steht, ist richtig und wir empfehlen dir, mit der Umgebung herumzuspielen, um selbst zu verstehen, was vor sich geht. Das sind zwar nur einfache Beispiele, aber ein Ingenieur, der mit Erklärung 2 ausgestattet ist, wird das zugrunde liegende Problem schneller verstehen und beheben können.

Die Verfolgung von Schemaänderungen und Datenverläufen gibt dir einen beispiellosen Einblick in den Zustand und die Nutzungsmuster deiner Daten und liefert wichtige Kontextinformationen darüber, wer, was, wo, warum und wie deine Daten genutzt wurden. Tatsächlich sind Schema und Lineage die beiden wichtigsten Säulen der Datenbeobachtung, wenn es darum geht, die nachgelagerten (und oft realen) Auswirkungen von Datenausfällen zu verstehen.

Skalierung der Anomalie-Erkennung mit Python und maschinellem Lernen

Auf hohem Niveau ist maschinelles Lernen entscheidend für die Beobachtbarkeit von Daten und die Datenüberwachung im großen Maßstab. Mit maschinellem Lernen ausgestattete Detektoren können flexibler auf eine größere Anzahl von Tabellen angewendet werden und machen manuelle Prüfungen und Regeln überflüssig, wenn dein Data Warehouse oder dein Data Lake wächst. Außerdem können Detektoren mit maschinellem Lernen lernen und sich in Echtzeit an die Daten anpassen und komplizierte saisonale Muster erfassen, die für menschliche Augen sonst unsichtbar wären. Lass uns eintauchen - Erfahrung mit maschinellem Lernen ist nicht erforderlich.

Wie du dich vielleicht aus den beiden vorangegangenen Abschnitten dieser Übung erinnerst, arbeiten wir wieder mit fiktiven astronomischen Daten über bewohnbare Exoplaneten. Jetzt werden wir uns wieder auf die Tabelle EXOPLANETS beschränken, um besser zu verstehen, wie die Erkennung von Anomalien mit maschinellem Lernen skaliert werden kann, wie in Beispiel 4-33 dargestellt.

Beispiel 4-33. Unser bewährter EXOPLANETS Datensatz
$ sqlite3 EXOPLANETS.db
sqlite> PRAGMA TABLE_INFO(EXOPLANETS);
_id             | TEXT | 0 | | 0
distance        | REAL | 0 | | 0
g               | REAL | 0 | | 0
orbital_period  | REAL | 0 | | 0
avg_temp        | REAL | 0 | | 0
date_added      | TEXT | 0 | | 0

Beachte, dass EXOPLANETS so konfiguriert ist, dass ein wichtiger Teil der Metadaten - die Spalte date_added - manuell erfasst wird, die das Datum aufzeichnet, an dem unser System den Planeten entdeckt und automatisch zu unseren Datenbanken hinzugefügt hat. Um Anomalien in Bezug auf Aktualität und Verteilung zu erkennen, haben wir eine einfache SQL-Abfrage verwendet, um die Anzahl der neu hinzugefügten Einträge pro Tag zu visualisieren, wie in Beispiel 4-34 zu sehen ist.

Beispiel 4-34. Abfrage der Anzahl der neu hinzugefügten EXOPLANETS Einträge pro Tag
SELECT
 DATE_ADDED,
 COUNT(*) AS ROWS_ADDED
FROM
 EXOPLANETS
GROUP BY
 DATE_ADDED;

Diese Abfrage ergibt einen scheinbar gesunden Satz von Daten, wie in Beispiel 4-35 dargestellt. Aber gibt es noch mehr, was wir wissen sollten?

Beispiel 4-35. Ergebnisse von Beispiel 4-34 (die ganz normal aussehen)
date_added,ROWS_ADDED
2020-01-01,84
2020-01-02,92
2020-01-03,101
2020-01-04,102
2020-01-05,100
...,...
2020-07-14,104
2020-07-15,110
2020-07-16,103
2020-07-17,89
2020-07-18,104

Diese Ergebnisse werden in Abbildung 4-15 dargestellt.

Abbildung 4-15. Visualisierung der Anzahl der hinzugefügten Zeilen pro Tag für einen bestimmten Monat

Mit anderen Worten: Die Tabelle EXOPLANETS wird routinemäßig mit etwa 100 Einträgen pro Tag aktualisiert, geht aber an manchen Tagen "offline", wenn keine Daten eingegeben werden, wie in Abbildung 4-15 dargestellt. Wir haben eine Metrik namens DAYS_SINCE_LAST_UPDATE eingeführt, um diesen Aspekt der Tabelle über unsere Abfragevorlage zur Anomalieerkennung zu verfolgen, wie in Beispiel 4-36 dargestellt. Sie zeigt uns an, wie viele Tage seit der Aktualisierung des EXOPLANETS Datensatzes zwischen den einzelnen Einträgen vergangen sind.

Beispiel 4-36. Abfrage, nach wie vielen Tagen der Datensatz EXOPLANETS aktualisiert wurde
WITH UPDATES AS(
  SELECT
    DATE_ADDED,
    COUNT(*) AS ROWS_ADDED
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
)
  
SELECT
  DATE_ADDED,
  JULIANDAY(DATE_ADDED) - JULIANDAY(LAG(DATE_ADDED) OVER(
    ORDER BY DATE_ADDED
  )) AS DAYS_SINCE_LAST_UPDATE
FROM
  UPDATES;

Die Ergebnisse werden in einer CSV-Datei aufgelistet, wie in Beispiel 4-37 dargestellt und in Abbildung 4-16 visualisiert. Wir sehen eine Liste von Terminen mit neuen Dateneinträgen.

Beispiel 4-37. Ergebnisse aus Beispiel 4-36
DATE_ADDED,DAYS_SINCE_LAST_UPDATE
2020–01–01,
2020–01–02,1
2020–01–03,1
2020–01–04,1
2020–01–05,1
...,...
2020–07–14,1
2020–07–15,1
2020–07–16,1
2020–07–17,1
2020–07–18,1

In Abbildung 4-16 ist deutlich zu erkennen, dass es im Februar, April, Mai, Juni und Juli 2020 einige Daten gab, die nicht zu unserem EXOPLANETS Datensatz hinzugefügt wurden, was auf eine Anomalie hinweist.

Abbildung 4-16. Mit einer Abfrage zur Erkennung von Freshness-Anomalien können wir feststellen, wann die Daten "offline" gehen

Mit einer kleinen Änderung haben wir einen Schwellenwert-Parameter in unsere Abfrage eingefügt, um einen Freshness-Detektor zu erstellen, mit dem wir unsere Anomalie-Erkennung weiter verfeinern können. Unser Detektor gibt alle Daten zurück, bei denen die neuesten Daten in EXOPLANETS älter als einen Tag sind, wie in Beispiel 4-38 gezeigt.

Beispiel 4-38. Abfrage, um festzustellen, wann eine Spalte in unserem EXOPLANETS Datensatz seit mehr als einem Tag nicht mehr aktualisiert wurde
WITH UPDATES AS(
  SELECT
    DATE_ADDED,
    COUNT(*) AS ROWS_ADDED
  FROM
    EXOPLANETS
  GROUP BY
    DATE_ADDED
),
  
NUM_DAYS_UPDATES AS (
  SELECT
    DATE_ADDED,
    JULIANDAY(DATE_ADDED) - JULIANDAY(LAG(DATE_ADDED)
      OVER(
        ORDER BY DATE_ADDED
      )
    ) AS DAYS_SINCE_LAST_UPDATE
  FROM
    UPDATES
)
  
SELECT
  *
FROM
  NUM_DAYS_UPDATES
WHERE
  DAYS_SINCE_LAST_UPDATE > 1;

Die CSV-Datei, die durch diese Abfrage erzeugt wird, ist in Beispiel 4-39 dargestellt und hebt Freshness-Anomalien hervor.

Beispiel 4-39. Ergebnisse der Abfrage aus Beispiel 4-38 
DATE_ADDED,DAYS_SINCE_LAST_UPDATE
2020–02–08,8
2020–03–30,4
2020–05–14,8
2020–06–07,3
2020–06–17,5
2020–06–30,3

In Abbildung 4-17 können wir deutlich sehen, wann unser Datensatz veraltete Daten gesammelt hat, die wahrscheinlich von einem Exoplaneten-Orbiter oder einer anderen Raumsonde stammen.

Abbildung 4-17. Visualisierung des Datums, an dem die Tabelle "veraltete" Daten gesammelt hat, was auf eine Datenausfallzeit hinweist

Die Ausschläge in Abbildung 4-17 zeigen, dass die Tabelle EXOPLANETS mit alten oder "veralteten" Daten arbeitete. In einigen Fällen können solche Ausfälle Standardverfahren sein - vielleicht war eine Wartung unseres Teleskops fällig, so dass an einem Wochenende keine Daten aufgezeichnet wurden. In anderen Fällen kann ein Ausfall aber auch ein echtes Problem bei der Datenerfassung oder -umwandlung sein - vielleicht haben wir unsere Daten auf das ISO-Format umgestellt und der Auftrag, der traditionell neue Daten lieferte, schlägt nun fehl. Wir haben vielleicht die Heuristik, dass längere Ausfälle schlimmer sind, aber wie können wir darüber hinaus sicherstellen, dass wir nur die echten Probleme in unseren Daten erkennen?

Die kurze Antwort: Das kann man nicht. Es ist unmöglich, einen perfekten Prädiktor zu entwickeln (jedenfalls für jedes interessante Vorhersageproblem). Aber wir können einige Konzepte aus dem maschinellen Lernen nutzen, um das Problem besser zu strukturieren und so die Beobachtbarkeit und das Vertrauen in die Daten zu erhöhen.

Verbesserte Datenüberwachung und Alarmierung mit maschinellem Lernen

Jedes Mal, wenn wir eine Warnung über eine defekte Datenpipeline ausgeben, müssen wir uns fragen, ob die Warnung richtig war. Weist die Meldung auf ein echtes Problem hin? Wir könnten uns über zwei Szenarien Sorgen machen:

  • Es wurde eine Datenüberwachungswarnung ausgegeben, aber es gab kein echtes Problem. Wir haben die Zeit des Benutzers verschwendet, indem wir auf die Warnung reagiert haben.

  • Es gab ein echtes Problem, aber es wurde keine Datenüberwachungswarnung ausgegeben. Wir haben ein echtes Problem unentdeckt gelassen.

Diese beiden Szenarien werden als Falsch-Positive (vorhergesagt anomal, tatsächlich OK) und Falsch-Negative (vorhergesagt OK, tatsächlich anomal) bezeichnet, und wir wollen sie vermeiden. Ein falscher Positivbefund ist wie ein heulender Wolf - wir haben Alarm geschlagen, aber alles war in Ordnung. Ein falsches Negativ ist wie ein schlafender Wachdienst: Irgendetwas war nicht in Ordnung, aber wir haben nichts unternommen.

Unser Ziel ist es, diese Umstände so weit wie möglich zu vermeiden und uns darauf zu konzentrieren, die Zahl der wahren Positiven (vorhergesagte Anomalie, tatsächlich ein Problem) und der wahren Negativen (vorhergesagte OK, tatsächlich OK) zu maximieren.

Berücksichtigung von Falsch-Positiven und Falsch-Negativen

Die Erkennung von Anomalien ist eine unüberwachte Aufgabe. Unüberwachtes Lernen ist eine Aufgabe des maschinellen Lernens, bei der das optimale Verhalten zum Zeitpunkt des Trainings nicht bekannt ist. Mit anderen Worten: Die Daten, auf denen du trainierst, sind nicht mit Etiketten versehen. Aus diesem Grund kann man die Erkennung von Anomalien auch als unbeaufsichtigt bezeichnen, denn für Anomalien gibt es keine Basiswahrheit. Ohne eine Basiswahrheit kannst du kein Fehlersignal erhalten, also den Unterschied zwischen dem, was du vorhergesagt hast, und dem, was du hättest vorhersagen sollen.

Auch wenn einige Aufgaben zur Erkennung von Anomalien am besten als unbeaufsichtigte Lernprobleme verstanden werden, ist es dennoch sinnvoll, überwachte Fehlersignalvokabeln wie falsch negativ, falsch positiv, Präzision usw. zu berücksichtigen. Andernfalls können wir verschiedene Erkennungsalgorithmen nicht miteinander vergleichen und haben keinen Maßstab für Verbesserungen und Erfolg.

Für jeden Datenpunkt gibt ein Anomaliedetektor entweder eine "anomale" oder eine "nicht anomale" Vorhersage ab. Bedenke auch, dass an der Sache etwas Wahres dran ist - der fragliche Datenpunkt ist entweder ein echtes Problem oder überhaupt kein Problem. Nehmen wir an, eine Messung zeigt, dass deine wichtige Analysetabelle in den letzten drei Tagen nicht ein einziges Mal aktualisiert wurde. Wenn deine Tabelle stündlich aktualisiert werden sollte, ist das ein echtes Problem!

Wenn ein Datenpunkt problematisch ist und unser Detektor ihn als "anomal" bezeichnet, nennen wir das ein echtes Positiv. Wenn ein Datenpunkt in Ordnung ist und unser Detektor ihn nicht entdeckt (d.h. "nicht anomal" ist), nennen wir das ein echtes Negativ. Tabelle 4-1 veranschaulicht dieses Konzept.

Tabelle 4-1. Vier mögliche Ergebnisse bei der Erkennung von Anomalien
Vorhersage
Negativ Positiv
Aktuell Negativ Wahr Negativ Falsch positiv
Positiv Falsch Negativ Echt positiv

Falsche Negative sind Fälle, in denen der Datenpunkt wirklich problematisch war, aber von unserem Detektor nicht erkannt wurde. Eine falsch-negative Erkennung ist wie ein schlafender Wachhund - dein Algorithmus lässt ein Problem unentdeckt vorbeiziehen. Falsch-positive Erkennungen sind Fälle, in denen wir eine Anomalie entdeckt haben, der betreffende Punkt aber nicht wirklich problematisch war. Eine falsch positive Erkennung ist wie ein heulender Wolf - dein Algorithmus hat ein "anormales" Ergebnis geliefert, aber der zugrunde liegende Datenpunkt war eigentlich in Ordnung. Falsch-positive und falsch-negative Ergebnisse sind selbst für die am besten trainierten Algorithmen zur Erkennung von Anomalien eine Realität.

Falsch-positive und falsch-negative Ergebnisse klingen beide schlecht. Es scheint, dass die besten Techniken zur Erkennung von Anomalien beides vermeiden sollten. Leider können wir aus statistischen Gründen nicht "beides" vermeiden. Weniger falsch-positive Meldungen gehen nämlich auf Kosten von mehr falsch-negativen Meldungen - und umgekehrt.

Um zu verstehen, warum das so ist, lass uns noch einmal über den Jungen, der Wolf rief, nachdenken - durch die Linse eines Anomalie-Detektors! Der Junge, der Wolf rief, erkennt jeden Datenpunkt als eine Anomalie. Daher ist seine Erkennung zwar hochsensibel (keine falsch-negativen Daten werden übersehen), aber überhaupt nicht spezifisch (viele falsch-positive Daten werden erkannt). Datenexperten mögen keine Wolfsjungen-Detektoren, weil ihre Erkennungen nicht glaubwürdig sind. Wenn ein Anomaliedetektor eine hohe Falsch-Positiv-Rate hat, wirst du wahrscheinlich glauben, dass der Alarm nicht echt ist.

Der schlafende Wachhund ist eine andere Art von Anomaliedetektor - genau genommen die gegenteilige Art. Dieser Detektor betrachtet Datenpunkte nie als anomal. Der daraus resultierende Algorithmus zur Erkennung von Anomalien ist sehr spezifisch (es werden keine falsch-positiven Ergebnisse erzeugt), aber überhaupt nicht empfindlich (es werden viele falsch-negative Ergebnisse erzeugt). Datenexperten mögen auch keine schlafenden Wachhunde, denn ihre Ergebnisse sind unzuverlässig. Übermäßig konservative Detektoren werden nie Anomalien erkennen, was bedeutet, dass sie zwangsläufig etwas übersehen, wenn die Dinge wirklich schief laufen.

Die Kunst besteht darin, irgendwo in der Mitte zwischen diesen beiden Erkennungsmethoden zu liegen.

Verbesserung von Präzision und Rückrufquote

Wenn du einen Algorithmus zur Erkennung von Anomalien auf eine bestimmte Datensammlung anwendest, erhältst du eine Sammlung von wahr-positiven (TPs), wahr-negativen (TNs), falsch-positiven (FPs) und falsch-negativen (FNs) Ergebnissen. Normalerweise betrachten wir diese "Werte" nicht nur für sich allein - es gibt gängige statistische Methoden, um sie zu aussagekräftigen Kennzahlen zu kombinieren. Wir konzentrieren uns auf Precision und Recall, die Genauigkeitskennzahlen, die die Leistung des Anomaliedetektors quantifizieren.

DieGenauigkeit ist definiert als der Anteil der richtigen Vorhersagen, also:

Präzision = TPs TPs+FPs

Mit anderen Worten: Wie viele der "Positiven" (Vorhersagen) sind richtig?

DieRückrufquote ist definiert als die Rate der tatsächlich entdeckten Anomalien, also:

Rückruf = TPs TPs+FNs

Mit anderen Worten: Wie viele von den echten Anomalien haben wir entdeckt?

Diese Begriffe sind beliebte Genauigkeitskennzahlen für Klassifizierungssysteme, und ihre Namen sind semantisch bedeutsam. Ein Detektor mit hoher Präzision ist "präzise", da er Anomalien in den meisten Fällen richtig vorhersagt. Ähnlich verhält es sich mit einem Detektor mit hoher Rückrufquote: Er erkennt eine hohe Anzahl der tatsächlichen Anomalien.

Das Problem ist natürlich, dass du nicht das Beste aus beiden Welten haben kannst. Beachte, dass es einen Kompromiss zwischen diesen beiden Welten gibt. Wie bekommen wir perfekte Präzision? Ganz einfach: Alarm umsonst - der Wachhund schläft die ganze Zeit und zwingt uns, eine Falsch-Positiv-Rate von 0 % zu haben. Das Problem dabei? Der Rückruf wird schrecklich sein, da unsere Falsch-Negativ-Rate enorm hoch ist.

Und wie erreichen wir einen perfekten Rückruf? Auch das ist ganz einfach: Wir schlagen bei jeder Gelegenheit Alarm und erzwingen so eine Falsch-Negativ-Rate von 0 %. Das Problem ist erwartungsgemäß, dass unsere Falsch-Positiv-Rate darunter leidet und die Genauigkeit beeinträchtigt.

Unsere Datenwelt wird von quantifizierbaren Zielen bestimmt, und in den meisten Fällen wollen wir ein einziges Ziel optimieren, nicht zwei. Wir können sowohl die Genauigkeit als auch den Rückruf in einer einzigen Kennzahl, dem F-Score, kombinieren. Die allgemeine Formel für nichtnegative reelle β lautet:

F β = (1+β 2 )-(Präzision-Rückruf) (β 2 -Präzision+Rückruf)

Fβ wird als gewichteter F-Score bezeichnet, da unterschiedliche Werte für Beta die Präzision und den Recall bei der Berechnung unterschiedlich gewichten. Im Allgemeinen sagt ein Fβ-Score aus: "Ich halte den Recall für beta mal so wichtig wie die Präzision."

Wenn β = 1 ist, bewertet die Gleichung alle gleich. Setzt man β > 1, ist die Rückrufquote wichtiger für eine höhere Punktzahl. Mit anderen Worten: β > 1 bedeutet: "Mir ist es wichtiger, alle Anomalien zu erkennen, als gelegentlich einen Fehlalarm zu verursachen." Wenn du β < 1 setzt, ist die Genauigkeit wichtiger. β < 1 bedeutet: "Ich lege mehr Wert darauf, dass meine Alarme echt sind, als dass ich jedes echte Problem erkenne."

Es gibt viele Frameworks, die du nutzen kannst, um Anomalien in großem Umfang zu erkennen, ohne dass du deine Algorithmen von Hand in Python programmieren musst. Im Folgenden findest du ein paar unserer Favoriten:

Facebook Prophet
Ein Prognosemodell, das tägliche, wöchentliche, monatliche und jährliche saisonale Schwankungen in Zeitreihendaten in großem Umfang verarbeiten kann. Die Nutzer können Prophet-Basismodelle laden und die von Menschen interpretierbaren Modellparameter verändern, indem sie ihr Fachwissen durch Funktionserweiterungen hinzufügen. Das Paket wird sowohl in Python als auch in R ausgeliefert.
TensorFlow
Eine beliebte Bibliothek für maschinelles Lernen für eine Vielzahl von Aufgaben, darunter die Verarbeitung natürlicher Sprache, Computer Vision und die Erkennung von Zeitreihenanomalien. Das Paket bietet nützliche und gut dokumentierte Implementierungen von fortgeschrittenen Algorithmen zur Anomalieerkennung. Das Keras-Paket von TensorFlow implementiert zum Beispiel ein Autoencoder-Modell, das für eine neuronale Form der Autoregression verwendet werden kann, die leistungsfähiger ist als ein einfaches ARIMA-Modell (Autoregressive-integrated-moving-average).
PyTorch
PyTorch wurde bei Facebook entwickelt und ist eine weitere Python-Bibliothek für maschinelles Lernen, die ähnliche Anwendungsfälle erfüllt wie TensorFlow (das von Google entwickelt wurde). PyTorch wird in der Regel eher im akademischen Bereich eingesetzt, während sich TensorFlow in der Industrie größerer Beliebtheit erfreut.
scikit-learn
Ein weiteres beliebtes Softwarepaket für maschinelles Lernen mit Implementierungen für alle Arten von Algorithmen. Neben Methoden zur Erkennung von Zeitreihenanomalien wie ARIMA verfügt scikit-learn über Versionen des k-nearest neighbor Algorithmus und des isolation forest Algorithmus, zwei beliebte Methoden zur Clusterbildung. Wie TensorFlow wird scikit-learn in Python entwickelt.
MLflow

Ein beliebtes Experiment-Tracking-Tool, das von den Machern von Databricks als Open Source entwickelt wurde. Experiment Tracking bezieht sich auf den Prozess der Verwaltung von Machine Learning-Modellen in der Entwicklung und Produktion. MLflow ist in erster Linie eine Software zur Verfolgung und Reproduktion von Experimenten. MLflow-Instanzen verfügen über gemeinsame Modellregistraturen, in denen Experimente gesichert und nebeneinander verglichen werden können. Jedes Modell gehört zu einem Projekt, d.h. zu einer Softwareumgebung, die die Reproduzierbarkeit der Modelle gewährleistet (siehe Abbildung 4-18). Ein wichtiger Aspekt bei der Entwicklung von Software zur Aufdeckung von Anomalien ist die Garantie, dass der Code auf verschiedenen Rechnern gleich läuft. Du willst nicht glauben, dass du einen Fehler lokal gelöst hast, nur um dann festzustellen, dass die Korrektur in der Produktion fehlschlägt. Ebenso möchtest du, wenn ein Kollege eine Genauigkeitskennzahl für sein aktualisiertes Modell meldet, wissen, dass du seine Qualitätsergebnisse selbst reproduzieren kannst. Auch bei Projekten hilft die MLflow-Registry bei der Bereitstellung von Modellen in Produktionsumgebungen, einschließlich Azure ML und Amazon SageMaker, oder in Spark-Clustern als Apache Spark UDF.

Abbildung 4-18. MLflow's Model Registry visualisiert im Data Science Workflow
Hinweis

Die Nachverfolgung von Experimenten, d.h. die Verwaltung der Entwicklung und des Trainings von Machine-Learning-Modellen, umfasst u.a. den Vergleich von Hyperparametern, die Überprüfung von Abhängigkeiten, die Verwaltung und Orchestrierung von Trainingsaufträgen, die Speicherung von Modell-Snapshots und die Sammlung von Protokollen. Im Prinzip lässt sich das mit unglaublich komplizierten Tabellenkalkulationen erledigen, aber natürlich gibt es bessere Tools für diese Aufgabe.

TensorBoard

Dies ist das Visualisierungs-Toolkit von TensorFlow, aber du musst nicht mit TensorFlow modellieren, um die Vorteile der Software zu nutzen. Mit TensorBoard kannst du, wie in Abbildung 4-19 gezeigt, gängige Metriken des maschinellen Lernens wie Verluste pro Trainingsepoche, Konfusionsmatrizen und individuelle Fehleranalysen visualisieren.

Abbildung 4-19. Eine Standardansicht des TensorBoards während des Modelltrainings. Quelle: Tran et al.1

Diese und andere Frameworks können deine Anomaliedetektoren auf die nächste Stufe heben, indem sie falsche Negativ- und Positivmeldungen eliminieren und die Notwendigkeit der Modellanpassung im Laufe der Zeit verringern.

Erkennen von Frischeproblemen mit Datenüberwachung

Mit unserem neuen Vokabular kehren wir zu der Aufgabe zurück, Frischeanomalien in der Tabelle EXOPLANETS zu erkennen. Wir verwenden einen einfachen Vorhersagealgorithmus, da wir unsere Abfrage in einen Detektor verwandelt haben, indem wir einen Modellparameter X gesetzt haben. Unser Algorithmus sagt: "Jeder Ausfall, der länger als X Tage dauert, ist eine Anomalie und wir werden eine Warnung ausgeben. Selbst in einem so einfachen Fall wie diesem können uns Präzision, Recall und F-Scores helfen!

Zur Veranschaulichung haben wir die Frischeausfälle auf EXOPLANETS genommen und ihnen Ground-Truth-Labels zugewiesen, die angeben, ob es sich bei jedem Ausfall um einen echten Vorfall handelt oder nicht. Es ist unmöglich, die Genauigkeit eines Modells zu berechnen, ohne eine Art von "Ground Truth" zu haben, daher ist es immer hilfreich, darüber nachzudenken, wie du diese für deinen Anwendungsfall generierst. Erinnere dich daran, dass es in der Tabelle EXOPLANETS insgesamt sechs Ausfälle gibt, die länger als einen Tag andauern, wie in den Daten in Beispiel 4-40 zu sehen ist.

Beispiel 4-40. Ergebnisse aus Beispiel 4-38 Abfrage zu Ausfällen, die länger als einen Tag dauern
DATE_ADDED,DAYS_SINCE_LAST_UPDATE
2020–02–08,8
2020–03–30,4
2020–05–14,8
2020–06–07,3
2020–06–17,5
2020–06–30,3

Nehmen wir einmal willkürlich an, dass die Vorfälle vom 08.02.2020 und 14.05.2020 echt sind. Sie sind jeweils acht Tage lang, also ist es logisch, dass sie problematisch sein könnten. Nehmen wir andererseits an, dass die Ausfälle am 30.03.2020 und 07.06.2020 keine echten Vorfälle sind. Diese Ausfälle sind vier bzw. drei Tage lang, also ist das nicht abwegig. Die Ausfälle am 17.06.2020 und am 30.06.2020, die fünf bzw. drei Tage dauern, sind ebenfalls echte Vorfälle, wie in Beispiel 4-41 dargestellt.

Beispiel 4-41. Klassifizierung der "echten" Anomalien
INCIDENT,NOT INCIDENT
2020-02-08 (8 days),2020-03-30 (4 days)
2020-05-14 (8 days),2020-06-07 (3 days)
2020-06-17 (5 days),
2020-06-30 (3 days),

Nachdem wir unsere Basiswahrheit auf diese Weise ausgewählt haben, sehen wir, dass längere Ausfälle wahrscheinlicher sind, als tatsächliche Probleme, aber es gibt keine Garantie. Diese schwache Korrelation macht ein gutes Modell zwar effektiv, aber unvollkommen, genau wie in komplexeren, echten Anwendungsfällen. Um die Modellgenauigkeit zu verbessern, brauchen wir uns nur eines der gängigsten Werkzeuge im Werkzeugkasten eines Daten- oder ML-Ingenieurs anzusehen: den F-Score.

F-Scores

F-Scores sind Maßstäbe für die Klassifizierungsgenauigkeit, die darauf ausgelegt sind, sowohl die Präzision als auch den Recall zu optimieren. Der "Standard" ist derF1-Score, der (für Statistiker) als harmonisches Mittel zwischen Präzision und Recall definiert ist:

F 1 = 2 1 Präzision+1 Rückruf

Das bedeutet, dass derF1-Score so konzipiert ist, dass er die Genauigkeit und den Wiederfindungswert gleichmäßig verteilt, was bedeutet, dass wir Gewinne bei dem einen genauso belohnen wie bei dem anderen. In manchen Kontexten mag diese Art der Bewertung angemessen sein. In anderen Fällen kann entweder der Recall oder die Präzision viel wichtiger sein.

Ein Beispiel aus der Praxis verdeutlicht dies: Am Samstagmorgen, den 13. Januar 2018, erhielten die Bewohner der hawaiianischen Inseln eine SMS, in der sie darüber informiert wurden, dass eine ballistische Rakete im Anflug sei und sie sofort unterirdischen Schutz suchen sollten. Die Warnung ging um 8:07 Uhr raus und endete unheilvoll mit "Dies ist keine Übung".

Achtunddreißig Minuten später, nachdem das hawaiianische Telefonnetz und die Notrufnummer 911 wegen Überlastung zusammengebrochen waren, gab die hawaiianische Landesregierung bekannt, dass der Alarm ein Fehler gewesen war. Ein Hawaiianer erlitt zwar einen Herzinfarkt, als er die Nachricht hörte, aber es gab keine unmittelbaren Todesopfer durch das Ereignis.

Der Vorfall auf Hawaii war als Test für das eigentliche Warnsystem der Insel gedacht - das Problem war jedoch, dass das System fälschlicherweise eine echte Warnung versendet hatte. In diesem Fall ist der echte Alarm ein Beispiel dafür, dass die Erkennung von Anomalien in der realen Welt schief läuft - ein falsches Positiv. Das ist zwar beängstigend, aber bedenke auch die möglichen Folgen, die ein falsches positives Ergebnis haben kann. Wenn man die Auswirkungen in der realen Welt bedenkt, können die Konsequenzen schwerwiegend sein, wenn etwas nicht so funktioniert wie erwartet.

Was bedeutet das für das Produktdesign und was können wir tun, um es zu entschärfen? In Bezug auf das, was wir hier besprochen haben, ist ein falsches Positiv besser als ein falsches Negativ für das Raketenerkennungssystem. Das bedeutet: Die Rückrufquote ist wichtiger als die Genauigkeit. Wenn wir die Leistung eines solchen Systems untersuchen, sollten wir etwas anderes als denF1-Score verwenden. Insbesondere ein allgemeiner Fβ-Score lässt uns sagen: "Recall ist für meinen Detektor beta-mal so wichtig wie Precision":

F β = 1+β 2 β 2 Präzision+1 Rückruf

Wenn β = 1 ist, ergibt diese Gleichung dasselbe Ergebnis wie dieF1-Score-Gleichung. Sie würde auch besagen, dass "recall" ein Mal so wichtig ist wie "precision" - also beide gleich gewichtet werden. Wenn wir jedoch etwas wie ein Raketenwarnsystem testen würden, bei dem die Rückrufquote doppelt oder dreifach so wichtig ist, könnten wir eine Bewertung mit F2 oder F3 in Betracht ziehen.

Spielt die Modellgenauigkeit eine Rolle?

Auf den letzten Seiten hast du vielleicht bemerkt, dass wir das Wort "Genauigkeit" sehr sparsam verwenden. Algorithmen des maschinellen Lernens, einschließlich der Anomaliedetektoren, sollen "genau" sein - zumindest hast du das gehört. Warum verwenden wir dann nicht dieses Vokabular?

Hier ist ein Teil unserer Antwort (ein Beispiel, das von einem Stanford-Professor, Mehran Sahami, stammt). Angenommen, du entwickelst ein ausgeklügeltes System zur Erkennung von Anomalien durch maschinelles Lernen, um auf das erworbene Immundefizienzsyndrom (AIDS) zu testen. So funktioniert unser ausgeklügeltes System: Es sagt einfach "Nein" voraus, wenn du es fragst, ob jemand AIDS hat. In den Vereinigten Staaten sind heute etwa 1,2 Millionen Menschen von AIDS betroffen. Die US-Bevölkerung liegt bei etwa 330 Millionen. Unsere "Genauigkeit", also wie richtig wir im Durchschnitt liegen, ist 1 - (Amerikaner mit AIDS / Amerikaner) = 1 - (1,2 Millionen / 330 Millionen) = 99,6%. Das ist eine der besten Genauigkeiten, die wir je gesehen haben - sicher eine Veröffentlichung wert, ein Grund zum Feiern, etc.

Ich hoffe, dieses Beispiel verdeutlicht: Genauigkeit ist nicht so einfach, wie die durchschnittliche Genauigkeit deines Detektors, und außerdem sollte sie nicht für verschiedene Anwendungen gleich definiert werden. Würde man sich auf die Genauigkeitskennzahlen aus dem vorangegangenen Beispiel verlassen, würde man Zehntausende von Personen falsch diagnostizieren - oder mehr. Letztendlich wollen wir, dass ein gutes Erkennungssystem sowohl die Zahl der falsch-positiven als auch der falsch-negativen Fälle minimiert. In der Praxis des maschinellen Lernens ist es gebräuchlicher, über die verwandten, aber aufschlussreicheren Begriffe Präzision und Recall nachzudenken, wie in Abbildung 4-20 dargestellt.

Abbildung 4-20. Präzision (wie oft dein Algorithmus eine Anomalie richtig erkennt) und Recall (wie viele der Anomalien insgesamt erkannt wurden)

Wie bereits weiter oben im Kapitel erwähnt, sagt uns die Genauigkeit im Allgemeinen, wie oft wir mit einer Warnung richtig liegen. Modelle mit einer guten Genauigkeit geben glaubwürdige Warnungen aus, da ihre hohe Genauigkeit garantiert, dass sie nur sehr selten "Wolf" schreien.

Der Rückruf sagt uns im Allgemeinen, bei wie vielen Problemen wir tatsächlich Alarm schlagen. Modelle mit einem guten Rückruf sind zuverlässig, denn ihr hoher Rückruf garantiert, dass sie selten bei der Arbeit schlafen.

Um unsere Metapher zu erweitern: Ein Modell mit guter Präzision ist ein Modell, das selten Wolf schreit - wenn es einen Alarm auslöst, solltest du ihm besser glauben. Ein Modell mit gutem Rückruf ist wie ein guter Wachhund - du kannst dir sicher sein, dass dieses Modell alle echten Probleme erkennt.

Nehmen wir an, wir setzen unseren Schwellenwert auf drei Tage fest - in Worten: "Jeder Ausfall, der länger als drei Tage dauert, ist eine Anomalie". Das bedeutet, dass wir am 08.02.2020, am 14.05.2020 und am 17.06.2020 Anomalien korrekt erkennen, also drei echte Positivmeldungen haben. Leider haben wir den 30.03.2020 als Vorfall erkannt, obwohl er keiner ist, also haben wir einen False Positive. Drei echte Positive / (drei echte Positive + ein falsches Positiv) bedeutet, dass unsere Genauigkeit 0,75 beträgt. Außerdem ist es uns nicht gelungen, den 30.06.2020 als Vorfall zu erkennen, d.h. wir haben ein falsches Negativ. Drei echte Positive / (drei echte Positive + ein falsches Negativ) bedeutet, dass unser Recall ebenfalls 0,75 beträgt.Der F1-Score wird nach folgender Formel berechnet:

TP TP+1 2(FP+FN)

Wenn wir die entsprechenden Werte eingeben, bedeutet das, dass unserF1-Score ebenfalls 0,75 beträgt. Nicht schlecht!

Nehmen wir an, wir setzen den Schwellenwert höher, nämlich auf fünf Tage. Jetzt erkennen wir nur den 08.02.2020 und den 14.05.2020, also die längsten Ausfälle. Diese stellen sich beide als echte Vorfälle heraus, so dass wir keine falsch-positiven Ergebnisse haben, was bedeutet, dass unsere Genauigkeit 1-Punkt beträgt! Aber beachte, dass uns die Erkennung anderer echter Anomalien, nämlich 2020-06-17 und 2020-06-30, misslingt, was bedeutet, dass wir zwei falsch negative Ergebnisse haben. Zwei echte Positivmeldungen / (zwei echte Positivmeldungen + zwei falsche Negativmeldungen) bedeutet, dass unser Recall 0,5 beträgt, also schlechter ist als zuvor. Es ist logisch, dass unsere Trefferquote gelitten hat, weil wir einen konservativeren Klassifikator mit einem höheren Schwellenwert gewählt haben. UnserF1-Score lässt sich wiederum mit der obigen Formel berechnen und liegt bei 0,667.

Wenn wir die Genauigkeit, die Auffindbarkeit und denF1-Score in Abhängigkeit von der eingestellten Schwelle aufzeichnen, erkennen wir einige wichtige Muster. Erstens haben aggressive Detektoren mit niedrigen Schwellenwerten die beste Auffindbarkeit, da sie schneller Alarm schlagen und somit mehr echte Probleme erkennen. Auf der anderen Seite haben passivere Detektoren eine bessere Genauigkeit, da sie nur bei den schlimmsten Anomalien Alarm schlagen, die mit größerer Wahrscheinlichkeit echt sind. DerF1-Wert liegt irgendwo zwischen diesen beiden Extremen - in diesem Fall bei einem Schwellenwert von vier Tagen. Den Sweet Spot zu finden, ist der Schlüssel zur optimalen Feinabstimmung unserer Detektoren, wie in Abbildung 4-21 dargestellt.

Betrachten wir abschließend noch einen letzten Vergleich(Abbildung 4-22). Beachte, dass wir nur denF1-Score betrachtet haben, bei dem Präzision und Recall gleich gewichtet werden. Was passiert, wenn wir uns andere Werte von Beta ansehen?

Abbildung 4-21. Berechnung der Präzision, des Recalls und desF1-Scores und Darstellung der Ergebnisse, um zu bestimmen, wie die Anomaliedetektoren eingestellt werden müssen
Abbildung 4-22. Berechnung des F-Scores mit verschiedenen Werten von β

Erinnere dich daran, dass ein allgemeiner Fβ besagt, dass "Recall β-mal so wichtig ist wie Precision". Daher sollten wir erwarten, dass F2 höher ist alsF1, wenn der Rückruf Priorität hat - genau das sehen wir bei Schwellenwerten von weniger als 4, wie in Abbildung 4-22 dargestellt. Gleichzeitig ist die F0,5-Punktzahl bei höheren Schwellenwerten höher, was zeigt, dass konservative Klassifikatoren mit höherer Genauigkeit mehr Spielraum haben.

Mit diesem F-Score im Schlepptau und einem besser abgestimmten Algorithmus bist du bereit, Probleme in den fünf Säulen der Datenbeobachtbarkeit zu erkennen: Frische, Volumen, Verteilung, Schema und Abstammung.

Jenseits der Oberfläche: Andere nützliche Ansätze für die Erkennung von Anomalien

Die besten Algorithmen zur Erkennung von Anomalien erfüllen drei Aufgaben: Sie erkennen Probleme nahezu in Echtzeit, alarmieren diejenigen, die es wissen müssen, und geben dir Informationen, die helfen, zukünftige Ausfälle zu verhindern. In diesem Kapitel haben wir allgemeine Ansätze und Schlüsselelemente grundlegender Algorithmen zur Aufdeckung von Anomalien vorgestellt, aber unser Beispiel kratzt nur an der Oberfläche. Es gibt noch eine Reihe anderer bewährter Methoden, Algorithmuskomponenten und Verfahren, die ähnliche oder sogar noch genauere Ergebnisse garantieren, je nachdem, welche Werkzeuge du verwendest:

Regeldefinitionen oder harte Schwellenwerte
Regeldefinitionen legen explizite Grenzwerte für bestimmte metrische Werte fest und ermitteln Anomalien in Bezug auf den Schwellenwert. Obwohl dieser Ansatz technisch gesehen eine Erkennung darstellt, kann er nur dann als "Anomalie"-Erkennung bezeichnet werden, wenn die meisten Datenpunkte innerhalb des Schwellenwerts liegen. Regeldefinitionen sind unglaublich skalierbar und können für extrem gut definierte SLAs, Datenverfügbarkeitsgarantien und so weiter verwendet werden.
Autoregressive Modelle
Die Autoregression arbeitet mit der Erkennung von Anomalien in Zeitreihen, bei denen die Datenpunkte anhand eines Zeitstempelobjekts geordnet werden. Autoregressive Modelle nehmen Daten aus früheren Zeitschritten, speisen sie in ein (lineares) Regressionsmodell ein und verwenden die Ergebnisse, um eine Vorhersage für die Daten des nächsten Zeitstempels zu treffen. Datenpunkte, die zu weit von der autoregressiven Vorhersage abweichen, werden als anomal gekennzeichnet. Kombiniert mit einem einfachen Algorithmus für den gleitenden Durchschnitt ergibt die Autoregression die Algorithmen zur Erkennung von autoregressivem gleitendem Durchschnitt und ARIMA. Wenn wir bei unserem Exoplaneten-Beispiel einen Schritt weiter gegangen wären und eine Autoregression eingebaut hätten, hätte dieser Datensatz ziemlich gut funktioniert.
Exponentiale Glättung
Es gibt exponentielle Glättungsmethoden, um Trend und Saisonalität aus Zeitreihen zu entfernen, so dass naivere Ansätze (z. B. ARIMA) zum Zuge kommen können. Holt-Winters ist ein berühmtes saisonales Modell für Zeitreihenprognosen, und auch hier gibt es eine umfangreiche Taxonomie (additiv, multiplikativ, gedämpft, ungedämpft usw.).
Clustering
Clustering-Techniken wie der K-Nächste-Nachbar-Algorithmus oder der Isolation-Forest-Algorithmus finden Anomalien, indem sie ähnliche Datenpunkte in Gruppen zusammenfassen und dich auf die "Außenseiter" aufmerksam machen, d.h. auf Daten, die in kleine oder sogar einzelne Gruppen passen.
Hyperparameter-Abstimmung
Modelle für maschinelles Lernen haben viele Parameter, die numerische Darstellungen der Daten sind, die der Vorhersagealgorithmus verwendet. Einige Parameter werden mithilfe der Daten und des Trainingsprozesses gelernt. Bei einem Z-Scoring-Modell zum Beispiel werden die Parameter μ und σ automatisch anhand der Verteilung der Eingabedaten festgelegt. Andere Parameter, die sogenannten Hyperparameter, werden nicht durch den Lernprozess festgelegt, sondern bestimmen den Lern- und Schlussfolgerungsprozess auf bestimmte Weise. Einige Hyperparameter beeinflussen die Architektur des Modells, z. B. die Größe eines neuronalen Netzes, die Größe der Einbettungs- und versteckten Zustandsmatrizen und so weiter. Diese werden als Modell-Hyperparameter bezeichnet. Eine andere Klasse, die Algorithmus-Hyperparameter, beeinflusst die Art und Weise, wie das Training durchgeführt wird, z. B. die Lernrate, die Anzahl der Epochen oder die Anzahl der Datenpunkte pro Trainingsstapel.
Rahmen für Ensemblemodelle
Ein Ensemble-Modell nimmt das Beste von jeder Methode - ein bisschen Clustering, exponentielle Glättung und autoregressive Knoten, die in einem neuronalen Feed-Forward-Netzwerkkombiniert werden - undkombiniert ihre Vorhersagen mit einem Ensemble-Algorithmus mit Mehrheitsabstimmung.

Solche Ansätze sind zwar wichtig, liegen aber außerhalb des Rahmens dieses Buches. Um mehr über die Entwicklung großartiger Algorithmen zur Erkennung von Anomalien zu erfahren, empfehlen wir dir das Buch Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow (O'Reilly) von Aurélien Géron.

Entwicklung von Datenqualitätsmonitoren für Warehouses und Lakes

Beim Aufbau von Datenqualitätsmonitoren für dein Datensystem ist es wichtig zu unterscheiden, ob du mit strukturierten, monolithischen Daten aus einem Warehouse arbeitest oder den wilden Westen des modernen Data-Lake-Ökosystems betrittst.

Die Hauptunterschiede zwischen der Entwicklung von Algorithmen zur Erkennung von Anomalien in Lagern und Seen liegen in den folgenden Punkten:

  • Die Anzahl der Einstiegspunkte, die du berücksichtigen musst

  • Wie die Metadaten gesammelt und gespeichert werden

  • Wie du auf diese Metadaten zugreifen kannst

Erstens haben Data-Lake-Systeme in der Regel eine große Anzahl von Eingangspunkten, d.h. man sollte von einer großen Heterogenität der Daten ausgehen, die aus verschiedenen Quellen eingehen. Wenn ein Datenwissenschaftler z. B. die Nullraten in Tabellendaten überwacht, die aus Postgres, Anwendungsprotokollen und einer Web-API stammen, könnte er Cluster von Tabellenverhalten feststellen, die den verschiedenen Endpunkten entsprechen. In diesen Fällen solltest du dich vor einem Modellierungsansatz hüten, der für alle passt. Es ist sehr wahrscheinlich, dass unterschiedliche Modellarchitekturen (z. B. unterschiedliche Hyperparameter) besser geeignet sind, Anomalien in den verschiedenen Formaten vorherzusagen. Eine Möglichkeit besteht darin, den Endpunkt der Daten selbst zu konditionieren und ein neues Merkmal für die Eingabe in das maschinelle Lernmodell zu bilden. Eine andere Möglichkeit ist die Verwendung einer Ensemble-Modell-Architektur oder einfach separate Modelle für jeden deiner Anwendungsfälle.

Zweitens müssen Metadaten, die direkt in einem Data Lake gesammelt werden, in unterschiedlichem Maße vorverarbeitet werden, bevor du erwarten kannst, dass ein Algorithmus zur Erkennung von Anomalien etwas Wertvolles daraus ableiten kann. Es kann sein, dass Typen gezwungen werden müssen, dass Schemata abgeglichen werden müssen und dass du ganz neue, erweiterte Merkmale aus den Daten ableiten musst, bevor du die Trainingsaufgabe des Detektors ausführen kannst.

Dies kann unmittelbar vor dem Modelltraining geschehen, vorausgesetzt, du beanspruchst deine Rechenressourcen nicht, indem du große Mengen an Eingabedaten umwandelst. In manchen Fällen kann es von Vorteil sein, einige ELT-Schritte zwischen den Seedaten und dem Algorithmus für maschinelles Lernen einzubauen. Unter "Daten bereinigen" erfährst du, warum dies sinnvoll sein kann.

Zusammenfassung

In diesem Kapitel haben wir einen kurzen Streifzug durch die Überwachung und Erkennung von Anomalien im Zusammenhang mit grundlegenden Datenqualitätsprüfungen gemacht. Wie können uns diese Konzepte nun helfen, Detektoren in unseren Produktionsumgebungen in Data Warehouses und Lakes einzusetzen?

Der Schlüssel liegt in der Einsicht, dass es keinen perfekten Klassifikator für jedes Problem der Anomalieerkennung gibt. Es gibt immer einen Kompromiss zwischen Falsch-Positiven und Falsch-Negativen, oder auch zwischen Präzision und Recall. Du musst dich fragen: "Wie wäge ich den Kompromiss zwischen diesen beiden Faktoren ab? Was bestimmt den "Sweet Spot" für meine Modellparameter?" Mit der Wahl eines Fβ-Scores zur Optimierung entscheidest du implizit, wie du diese Erscheinungen abwägst, und damit, was bei deinem Klassifizierungsproblem am wichtigsten ist.

Außerdem solltest du dich daran erinnern, dass jede Diskussion über die Genauigkeit eines Modells unvollständig ist, wenn du nicht eine Art von Basiswahrheit hast, die du mit den Vorhersagen des Modells vergleichen kannst. Du musst wissen, was eine gute Klassifizierung ausmacht, bevor du weißt, dass du eine hast. In Kapitel 5 werden wir erörtern, wie die in den Kapiteln 2, 3 und 4 vorgestellten Technologien bei der Entwicklung zuverlässigerer Datensysteme eingesetzt werden können und wie neue Prozesse wie SLAs, SLIs und SLOs bei der Skalierung von Systemen helfen können.

1 Dustin Tran, Alp Kucukelbir, Adji B. Dieng, Maja Rudolph, Dawen Liang, und David M. Blei, "Edward: A Library for Probabilistic Modeling, Inference, and Criticism," arXiv preprint arXiv:1610.09787, 2016, https://oreil.ly/CvuKL.

Get Grundlagen der Datenqualität now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial