Wer in der IDMC mit einem monatlichen IPU-Kontingent arbeitet, schaut regelmäßig auf die Metering-Seite. Dort steht bei monatlicher Abrechnung eine Zeile wie „5 Days Remaining at Current Consumption Rate“. Bei einem Kunden aus der Bankenbranche meldete diese Anzeige schon in den ersten Tagen des Monats, dass die IPUs nur noch wenige Tage reichen. Verlässlich ist dieser Wert nach meiner Erfahrung gerade am Monatsanfang nicht.

Für diesen Kunden habe ich ein eigenes Metering-Tool gebaut. Es lädt die Verbrauchsdaten über die REST-API, wie ich es im Artikel über den IPU-Verbrauch per REST-API beschrieben habe, und rechnet das Monatsende selbst hoch. In diesem Artikel zeige ich euch das Prinzip dahinter: ein saisonales Zeitreihenmodell (SARIMA) und eine Bepreisung, die die Staffel der Rate Card berücksichtigt.

Was die IDMC anzeigt

Die Anzeige steht im Administrator auf der Seite Metering im Bereich „Current IPU Usage“. Laut Doku ist sie eine Schätzung, wie viele Tage das IPU-Guthaben beim aktuellen Verbrauch noch reicht. Es gibt sie nur bei monatlicher Abrechnung und laut Knowledge Base nur in der Produktions-Org.

Wie Informatica die „current consumption rate“ berechnet, steht in keiner Quelle, die ich gefunden habe. Weder die Metering-Seiten des Administrator-Handbuchs noch die Knowledge Base oder die Vertragsbedingungen nennen das Zeitfenster oder sagen, ob die Staffel der Rate Card einfließt. Ich kann also nur beschreiben, was ich sehe: Zu Monatsbeginn ist die Zahl viel zu pessimistisch. Zwei Effekte erklären das.

Warum der Monatsanfang täuscht

Der erste Effekt liegt im Lastprofil. Bei meinem Kunden ist der IPU-Verbrauch an den ersten Kalendertagen des Monats deutlich höher als im Rest des Monats. Möglich ist außerdem ein Wochenrhythmus, etwa ruhigere Wochenenden. Wer den Verbrauch der letzten Tage mittelt und auf den Monat fortschreibt, verlängert am Monatsanfang genau diesen Lastblock auf alle restlichen Tage.

So hat mein Tool anfangs selbst gerechnet: Mittelwert der letzten sieben Tage, fortgeschrieben bis Monatsende. Am 2. oder 3. eines Monats bestand dieses Fenster nur aus ein oder zwei Tagen, und die Hochrechnung lag weit zu hoch. Außerdem sprang sie von Tag zu Tag stark und beruhigte sich erst nach ein bis zwei Wochen. Am Ersten gab es gar keinen Wert, weil für den neuen Monat noch keine Daten vorlagen.

Die Staffel der Rate Card

Der zweite Effekt steckt im Preismodell. Die Rate Card nennt für viele Meter mehrere Stufen. Die ersten Einheiten eines Abrechnungszeitraums kosten den Satz der ersten Stufe, alles darüber den niedrigeren Satz der nächsten. Bei Data Integration sind das laut den aktuellen Vertragsbedingungen 0,16 IPU je Compute-Stunde für die ersten 2.000 Stunden und 0,025 IPU für jede weitere. Mit dem nächsten Abrechnungszeitraum beginnt die Zählung wieder bei null.

Ein kleines Rechenbeispiel zeigt, was das für eine Hochrechnung bedeutet. Angenommen, eure Org verbraucht gleichmäßig 100 Compute-Stunden am Tag:

Stunden IPU
nach 5 Tagen 500 500 × 0,16 = 80
linear hochgerechnet auf 30 Tage 3.000 80 ÷ 5 × 30 = 480
tatsächlich nach 30 Tagen 3.000 2.000 × 0,16 + 1.000 × 0,025 = 345

Die lineare Hochrechnung liegt hier fast 40 % zu hoch, obwohl der Verbrauch völlig gleichmäßig ist. Bei gleichen Stunden kostet jeder Tag bis zur 2.000. Stunde 16 IPU, danach nur noch 2,5 IPU. Der IPU-Verbrauch ist am Monatsanfang also allein durch die Staffel immer höher, und genau diesen teuren Anfang schreibt eine lineare Hochrechnung fort:

Kumulierter IPU-Verbrauch bei gleichmäßig 100 Compute-Stunden am Tag: bis Tag 20 steil zum Satz 0,16 IPU je Stunde, danach flach zum Satz 0,025; die lineare Hochrechnung endet bei 480 statt 345 IPU
Staffel im Monatsverlauf (Rechenbeispiel).

Kommt der Lastblock am Monatsanfang dazu, verstärken sich beide Effekte.

SARIMA im Prinzip

Für die neue Hochrechnung habe ich mich für ein saisonales ARIMA-Modell entschieden, kurz SARIMA. Es ist ein klassisches Verfahren der Zeitreihenanalyse nach Box und Jenkins, das neben dem kurzfristigen Verlauf auch wiederkehrende Muster einer festen Periode abbildet (Hyndman & Athanasopoulos). In meinem Fall ist die Periode eine Woche.

Den Lastblock am Monatsanfang kennt ein Wochenmodell allein nicht, denn der Erste eines Monats fällt jedes Mal auf einen anderen Wochentag. Deshalb bekommt das Modell zusätzlich drei Merkmale, die den 1., 2. und 3. Kalendertag kennzeichnen. Ein solches Modell mit zusätzlichen erklärenden Größen heißt SARIMAX, und die Python-Bibliothek statsmodels bringt es fertig mit.

Einige Details machen das Modell im Alltag stabil:

  • Historie: Das Modell lernt aus bis zu 730 Tagen IPU-Verbrauch aller Orgs zusammen, ohne die fixen Monatsgebühren.
  • Nachbuchungen: Die jüngsten drei Tage lässt es beim Lernen weg, weil die IDMC dort noch nachbucht. Ihr Ist zählt trotzdem voll.
  • Logarithmus: Das Modell rechnet auf logarithmierten Tageswerten. Das stabilisiert eine Streuung, die mit dem Verbrauch wächst, und beim Zurückrechnen wird die bekannte Verzerrung zum Median korrigiert.
  • Unsicherheit: Aus 500 simulierten Verläufen bis Monatsende ergibt sich ein 80-%-Band für die Monatssumme.

Die Hochrechnung setzt sich damit aus dem Ist bis gestern, der Prognose der restlichen Tage und den noch nicht gebuchten fixen Gebühren zusammen. Das funktioniert auch am Ersten des Monats, wenn noch gar kein Ist vorliegt.

Hochrechnung in fünf Schritten: Tageswerte bis gestern, SARIMA-Modell, Prognose der Resttage mit Band, Verteilung des Zuwachses auf die Meter, Bepreisung über die Staffel der Rate Card
Ablauf der Hochrechnung.

Staffel auf den Zuwachs

Das Modell liefert zunächst IPU, keine Stunden. Um die Staffel richtig anzuwenden, verteilt mein Tool den prognostizierten Zuwachs nach den Anteilen der letzten sieben Tage auf die einzelnen Meter. Jeden Anteil rechnet es dann mit dem Verhältnis von Menge zu IPU des Vormonats in Stunden oder Einheiten um und bepreist ihn über die Rate Card, beginnend beim bisherigen Monats-Ist des Meters. Wer im Monat schon über 2.000 Stunden liegt, bekommt den Zuwachs also zum günstigen Satz.

Warum ausgerechnet das Verhältnis des Vormonats? Das Modell lernt IPU zum mittleren Preisniveau der Vergangenheit, denn jeder gelernte Monat hat die Staffel einmal durchlaufen. Rechnet man den Zuwachs dagegen zum Preis der letzten sieben Tage um, wirkt die Staffel am Monatsanfang doppelt. In diesen Tagen gilt ja noch der teure Satz. Das Verhältnis des jüngsten vollständigen Monats hebt die im Modell steckende Bepreisung weitgehend auf, sodass die Staffel nur einmal wirkt.

Was der Backtest zeigt

Um die Varianten zu vergleichen, habe ich einen Backtest gebaut. Er rechnet für jeden abgeschlossenen Monat an jedem Monatstag die Hochrechnung so, wie sie mit dem damaligen Datenstand entstanden wäre, und vergleicht sie mit dem tatsächlichen Monatsende. Als Maß dient der mittlere absolute Fehler in Prozent (MAPE).

Hinweis: Alle folgenden Zahlen stammen aus synthetischen Daten mit Wochenrhythmus und Monatsanfangsblock, nicht aus Kundendaten. Die echte Historie war zum Zeitpunkt der Messung noch zu kurz, siehe unten.

Auf den Monatstagen 1 bis 10 lag der Fehler der alten 7-Tage-Hochrechnung bei rund 100 %, der des SARIMA-Modells bei rund 1 %. Noch deutlicher ist der Unterschied bei der Unruhe: Die alte Hochrechnung änderte sich im Mittel um 26,5 % von einem Tag zum nächsten, die neue um 0,25 %.

Für die Staffel habe ich zwei eigene synthetische Reihen verwendet, bei denen der Stufenwechsel um den 7. bzw. um den 14. Tag liegt. Gemessen an den Monatstagen 2 bis 10 ergibt sich im Mittel beider Reihen folgendes Bild:

Mittlerer Fehler der Monatssumme auf zwei synthetischen Reihen mit Stufenwechsel: 7-Tage-Trend 40,4 Prozent, SARIMA mit Fensterpreis 17,4, SARIMA linear 17,3, SARIMA mit Vormonatsverhältnis 8,7 Prozent
Fehler je Bepreisung, synthetische Daten.

„Linear“ heißt dabei ohne Staffel, „Fensterpreis“ mit Umrechnung zum Preis der letzten sieben Tage. Das Verhältnis des Vormonats halbiert den Fehler gegenüber den anderen Varianten etwa. Ganz verschwindet die Doppelwirkung damit allerdings nicht: An den Tagen 2 bis 4 bleiben gegenüber einer Reihe ohne Stufe rund vier Prozentpunkte mehr Fehler.

Im Tool sieht die Hochrechnung dann so aus. Der Screenshot zeigt die Demodaten am 4. Juli, nach drei Datentagen, mit gestrichelter Prognose, schmalem Band und der Budgetlinie:

Kumulierter IPU-Verbrauch aller Orgs im Juli: drei Tage Ist, danach die gestrichelte Hochrechnung mit Band bis Monatsende, die gegen Ende über die Budgetlinie steigt
Hochrechnung im Metering-Tool (Demodaten).

Grenzen

Das Modell braucht Historie. Liegen weniger als 56 Lerntage oder weniger als zwei vollständige Monatsanfänge vor, oder lässt sich das Modell nicht anpassen, fällt mein Tool auf den alten 7-Tage-Trend zurück und kennzeichnet das in der Anzeige. Bei meinem Kunden war genau das zum Zeitpunkt der Umsetzung der Fall: Die echte Historie umfasste erst rund 50 Tage. Ein Nachweis auf echten Daten steht deshalb noch aus.

Feiertage und andere Kalendermuster außer Wochentag und Monatsanfang kennt das Modell nicht. Außerdem rechnet es nur den laufenden Monat hoch und bezieht sich auf das Modell mit monatlichem Kontingent. Bei jährlicher Abrechnung (Flex IPU) gelten andere Zeiträume, das habe ich nicht betrachtet.

Quellen

Wie ihr seht, lohnt sich ein genauer Blick auf die eingebaute Hochrechnung, bevor man wegen einer vermeintlichen Budgetüberschreitung Jobs anhält oder IPUs nachkauft.

Falls ihr Fragen dazu habt oder vor einer ähnlichen Aufgabe steht, schreibt mir gerne.