Datenzugriffsschnittstellen
1) Warum eine durchdachte Schnittstelle
Geschwindigkeit und Vorhersehbarkeit: Geschäftsmetriken und Berichte passen in SLA, ohne „manuelle Uploads“.
Sicherheit und Privatsphäre: PII/Biometrie unter Kontrolle, k-Anonymität, Geo-Grenzen.
Flexibilität: Verschiedene Kunden (BI, Services, Partner, DS/ML) bekommen genau das, was sie brauchen.
Wiederverwendung: „Daten als Produkt“ mit Verträgen und Versionen.
2) Schnittstellenkarte (wann was)
SQL/ANSI + vendory dialects: interactive analytics, BI, ad-hoc.
REST JSON: stabile Aggregate und Betriebsdaten, Integration mit Partnern.
GraphQL: flexibles „selektives“ Lesen und Navigationsgraph (Messungen/Fakten).
gRPC (protobuf): geringe Latenz des Online-Surfens (Feature Store, Scoring).
Arrow Flight/Parkett über HTTP/S3-presigned: Schnelle Spalten- „Dumps“ für DS/ML.
OData: Enterprise-Tools, das Modell „Tabelle als Service“.
Streams (Kafka/Pulsar) + CDC/Webhooks: Echtzeit-Ereignisse, reaktive Integrationen.
Federation (Trino/Presto): Ein einziger Einstiegspunkt zu einer Vielzahl von Quellen.
Regel: Aggregate und stabile Slices → REST/MV, Rich Random SQL → Requests, Low Latency/Online-Fici → gRPC, flexible Antwortform → GraphQL, Massive Binary Exchange → Arrow/Parket.
3) Verträge und Versionen (semver)
`MAJOR. MINOR. PATCH 'für jede API/Schema/Ereignis.
MAJOR: inkompatible Änderungen (neuer Pfad/Topic/Tabelle).
MINOR: kompatible Felder/Argumente hinzufügen.
PATCH: Änderungen an Beschreibungen/Grenzen.
Verträge fixieren: Schema, Filter, Limits, Privatsphäre, SLO.
yaml openapi: "3. 0. 3"
info: {title: "Analytics API", version: "2. 4. 0"}
paths:
/v2/payments/metrics:
get:
parameters:
- {name: brand, in: query, schema: {type: string}, required: true}
- {name: country, in: query, schema: {type: string}}
- {name: from, in: query, schema: {type: string, format: date-time}}
- {name: to, in: query, schema: {type: string, format: date-time}}
- {name: group_by, in: query, schema: {type: string, enum: [psp,status,day]}}
- {name: limit, in: query, schema: {type: integer, default: 500}}
responses:
"200": {description: "OK"}
x-slo: {p95_latency_ms: 1200, freshness_max: "PT5M"}
x-privacy: {pii: false, min_group_size: 20}
4) Zugang zu Analysen (SQL und Federation)
SQL-Gateway mit Rollen/Masken (row/column-level security).
Wiehs/Projektionen unter BI: stabile Namen und Semantik; heavy-requests gehen in die Voraggregation.
Federation (Trino/Presto): Single Entry Point, aber mit Richtlinien: welche Verzeichnisse und welche Funktionen verfügbar sind.
Lakehouse (Iceberg/Delta/Hudi): Zeitreise, Snapshot-Extraktionen über SQL/REST.
Квоты: scanned bytes/query, concurrency, wall-time.
5) GraphQL (flexible Form)
Wir lassen den Kunden das gewünschte Feld sammeln, führen aber über vorbereitete Wych/Projektionen mit Tiefen-/Knochengrenzen aus.
graphql type Query {
payments(
brand: String!, country: String, from: DateTime!, to: DateTime!,
first: Int = 200, after: String
): PaymentConnection
}
Richtlinien: depth ≤ 5, total nodes ≤ 5k, verbieten willkürliche Regex/Like-Zeilen; Wir haben häufige Anfragen.
6) gRPC/Feature Store (geringe Latenz)
Online-Fiches für Anti-Fraud/Empfehlungen/RG-Scoring.
proto service FeatureStore {
rpc GetFeatures (FeatureRequest) returns (FeatureResponse);
}
message FeatureRequest { string user_tok = 1; repeated string features = 2; }
message FeatureResponse { map<string, FeatureValue> values = 1; int64 ts_micros = 2; }
Anforderungen: p95 ≤ 50-100 ms, genaue Konsistenz der offlayn↔onlayn, TTL-Fix, LRU-Cache, Idempotency und mTLS.
7) Ströme und CDC
Domain-Ereignisse: 'Zahlungen. deposit_accepted`, `game. round_finished`.
CDC (aus OLTP): Status-/Grenzwertänderungen in Near-Real-Time.
Webhooks für Partner: Abonnement von Aggregaten (z.B. „PSP-Ausfälle> Schwelle“).
Retray-/Bestätigungsrichtlinien: exactly-once für kritische, at-least-once für Überwachung.
8) Seen und große Stichproben
Pfeilflug für schnelle Säulenentladungen in DS/ML.
Presigned-URL auf Parkett/Feder, mit kurzer TTL und signierter Anfrage.
Chunked Transfer und Dateigrößenkontrolle; Download-Protokoll (WORM-Audit).
9) Filter, Paginierung, Sortierung
Keyset-Paginierung (Cursor) statt OFFSET für große Sets.
Filter: whitelists nach Feldern, Typen und Operatoren ('=, IN, BETWEEN, prefix').
Sortierung: Begrenzte Feldliste, Standardreihenfolge.
Partielle Reaktion: 'fields = brand, country, amount' reduziert die Nutzlast.
http
GET /v2/game-rounds? brand=X&from=...&to=...&first=1000&after=eyJkYXRlIjoi...
10) Caching und Kosten
Ergebniscache für Vorlagenabfragen, Invalidität durch Frische-Token (Snapshot-ID).
Edge-Cache/CDN für öffentliche/halböffentliche Aggregate (ohne PII).
Budget-Parameter: Limit gescannte Bytes, Abfrage-Timeout, rps/min Kontingente.
Priorisierung der Pools: 'bi _ hot', 'adhoc', 'partner _ api'.
11) Sicherheit und Privatsphäre
AuthN: OAuth2/OIDC (Client-Credentials für Dienste, PKCE für Menschen).
AuthZ: RBAC + ABAC (Attribute: Marke, Land, Lizenz, Rolle).
mTLS zwischen Diensten, TLS 1. 2 + nach außen.
PII-Hygiene: Masken/Tokenisierung auf der API-Schicht, Säulenmasken, k-Anonymität der Aggregate.
Geo/Tenant-Isolation: Routing von Anfragen in die Lizenzregion; Verschlüsselungsschlüssel pro Marke/Region.
DSAR/Legal Hold: Suche nach Subjekt-Token, Geheimnisse zum Einfrieren von Sets.
12) Beobachtbarkeit (SLI/SLO) und Schutz
SLI: p50/p95/p99 lat, error-rate, rps, bytes scanned, cache hit, quotes/limits, Anteil der maskierten Spalten, Anteil der Autorisierungsfehler.
SLO: p95 Latenz, Frische der Daten,% erfolgreiche Abfragen, min-Gruppengröße auf Antworten.
Alertas: Wachstum der gescannten Bytes, fallende Trefferquote, 429/5xx-Anstieg, PII-Zugriffsversuche, Cursor-Leaks.
yaml slo:
p95_latency_ms: 1200 success_rate: 0. 995 freshness_max: "PT5M"
privacy:
pii_allowed: false min_group_size: 20 quotas:
rps: 50 max_scanned_mb: 256
13) Formate und Kompression
JSON für Kompatibilität; CSV - nur für kleine und unkomplizierte Exporte.
Parkett/Pfeil - Standard für große Uploads.
Kompression: gzip/zstd (Verhandlungen über „Accept-Encoding“).
Content-negotiation: `Accept: application/x-parquet`.
14) Metriken als API (Analytics/OLAP-Gateway)
Top-Level-Metriken: GGR/NET, CR, Hold, RG-Incidents - als Ressourcen mit den Parametern 'brand, country, window, group _ by'.
Approx (HLL/TDigest) для distinct/percentiles.
Cache mit Schlüssel:'(metric, params, snapshot_id)'.
15) Spezifität von iGaming - fertige Endpunkte
„GET/v2/payments/metrics“ - Ablehnungen/Änderungen durch PSP/Land/Marke mit 7/30d Fenstern.
„GET/v2/game-rounds/metrics“ - Top-Spiele/Anbieter, p95 Dauer, RTP-Fenster.
„GET/v2/rg/cases“ - aktive Beschränkungen/Selbstausschlüsse (k-anonyme Aggregate).
„POST/v1/features: get“ (gRPC) ist ein Online-Scoring-Feature für den Freak/Recommender.
„POST/v1/webhooks/psp-alerts“ - Meldungen „Deline Rate> Schwelle“.
16) Beispiele für Verträge
GraphQL Anfrage dünne Scheibe:graphql query {
payments(brand:"X", country:"TR", from:"2025-10-01", to:"2025-10-31", first:500) {
edges { node { day totalAmount declines psp } cursor }
pageInfo { hasNextPage endCursor }
}
}
Kafka (Veranstaltung, Avro):
json
{"event_id":"...","occurred_at":169..., "brand":"X","psp":"Papara","status":"declined","amount":"100. 00","currency":"TRY"}
Pfeilflug (Stift):
/flight/v1/query? dataset=gold. payments&from=...&to=...&brand=X&format=arrow
17) Veröffentlichungsprozess der neuen Schnittstelle
1. ADR: Problem/Wert/Kunden/Sicherheit/Kosten.
2. Vertrag: Schema, Filter, Grenzen, Privatsphäre, SLO, Versionen.
3. Lastsimulation: Top-N-Abfragen, p95/Scan-Bytes, Kosten.
4. Validierung/Cache/Quoten: standardmäßig aktivieren.
5. Dokumentation und SDK: Beispiele, Grenzen, Fehler, Retrays, Idempotenz.
6. Canary:% der Kunden, Regress-Tests, Alerts.
7. GA: Version im Datenproduktkatalog, Effektbericht.
18) Anti-Muster
Öffnen Sie „rohe“ SQL für alle - PII-Lecks, unvorhersehbare Kosten.
OFFSET-Paginierung und 'SELECT' - Schmerz durch Latenz und Zählung.
GraphQL ohne Tiefen-/Kostenbeschränkungen.
REST, das zu viele Spalten ohne' fields =... 'zurückgibt.
Keine k-Anonymität und min-Gruppengröße in den Aggregaten.
Null Kontingente/Limits und deaktivierter Cache.
Keine Versionierung/Verträge - wir „brechen“ Kunden bei jeder Änderung.
Gleiche Schnittstelle für alle Länder/Marken - regionale Regeln ignorieren.
19) Umsetzungsfahrplan
0-30 Tage (MVP)
1. Katalog Data Products (Metriken/Slices) und deren OpenAPI/GraphQL Verträge.
2. SQL-Gateway mit RLS/CLS, k-Anonymität der Aggregate, Basiskontingente.
3. Ein REST-Metrik-Endpunkt ('/payments/metrics') + Cache + Pools' bi _ hot/adhoc'.
4. gRPC Feature Store: Lesen Sie 10-20 wichtige Online-Daten (p95 ≤ 80 ms).
30-90 Tage
1. Stream-Schnittstellen (Kafka/Webhook) für PSP-Alert/Gaming-Events.
2. Pfeil/Parkett hochladen mit presigned-URL; Verzeichnis der Schnappschüsse.
3. Federation-Gateway (Trino/Presto) mit expliziten Richtlinien.
4. Beobachtbarkeit: SLI/SLO Dashboard, Kosten/Latenz/PII Alerts.
3-6 Monate
1. SDK (TypeScript/Python/Go) mit Retrays/Idempotentials/Quoten.
2. Dünne GraphQL-Scheiben für Produkte und Partner.
3. Erweiterung gRPC/FS, Abstimmung der offlayn↔onlayn; shadow→canary Veröffentlichungen.
4. Datenschutz-Audit/DSAR; Compliance-Berichte zu Zugriffen.
20) RACI
Data Platform (R): Gateways, Cache, Quoten, Verband, Beobachtbarkeit.
Data Governance (A/R): Verträge, Versionen, Datenschutz/k-Anonymität.
Domain Owners (R): Semantik der Felder, geschäftliche Invarianten, Datenprodukte.
Sicherheit/DSB (A/R): AuthN/Z, Geo-Isolation, DSAR/Legal Hold.
SRE/Observability (C): SLO/SLI, Alerts, Kapazität.
Analytics/BI/DS (C): Formular-/Aggregatanforderungen, SDK.
21) Verwandte Abschnitte
Indizierung analytischer Speicher, Optimierung analytischer Abfragen, Datenschemata und deren Entwicklung, Datenvalidierung, DataOps-Praktiken, Analyse- und Metrik-APIs, Feature Store, Datensicherheit und Verschlüsselung, Zugriffskontrolle, Aufbewahrungsrichtlinien.
Summe
Richtig gestaltete Datenzugriffsschnittstellen verwandeln Speicher und Datenströme in ein robustes „Produkt“: vorhersehbare SLAs, kontrollierte Kosten, Einhaltung der Privatsphäre und eine einheitliche Sprache für Produktteams, Analysen, Compliance und Partner. Bei iGaming bedeutet dies, PSP-Abstürze schneller aufzufangen, das Verhalten der Spieler zu verstehen und die Anforderungen der Aufsichtsbehörden zu erfüllen - ohne manuelle Uploads und nächtliche Migrationen.