Wat zijn datacontracten? Een beginnersgids met voorbeelden

Semantische datacontracten

Semantische datavalidaties zorgen ervoor dat data logisch consistent is en aansluit op de bedrijfslogica.

Semantische validaties moeten expliciet worden afgedwongen.

In tegenstelling tot schemachecks zijn semantische datacontracten namelijk afhankelijk van bedrijfslogica en moeten ze extern worden geïmplementeerd.

Semantiek voelt in veel use-cases als een uitbreiding op schema-gevalideerde contracten. Vaak hangt het af van bedrijfsregels en vertegenwoordigt het een set rijcondities waaraan ons datamodel moet voldoen. 

Een voorbeeld van een semantisch contract kan het volgende zijn:

• Metric-afwijking: ten opzichte van het voortschrijdend gemiddelde of een andere drempel. We kunnen bijvoorbeeld leven met het aantal actieve gebruikers van gisteren dat onder 75% van het 7-daags voortschrijdend gemiddelde zakt, maar 0% tolereren we niet.
• Bedrijfslogica: Transactiemonitoring-alerts en fraudepreventiescores. In dit scenario moet de uitbetaling 0 zijn.
• Data lineage: Dit beschrijft hoe data-entiteiten evolueren. Zo kan transaction_completed_at niet plaatsvinden vóór created_at.
• Referentiële integriteit: Entiteitsrelaties zijn belangrijk en kunnen ook worden beschreven met semantische contracten. Bekijk de onderstaande dbt-code. Die legt uit dat elke refund_id van een refund terugverwijst naar een geldige transaction.id.

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: id

Het is aan de eindgebruiker om het alarmeringsniveau voor semantische contracten in te stellen, en dit wordt vaak geïmplementeerd met aangepaste datakwaliteitstests.

Verschillende bedrijfslogische regels verwijzen vaak naar dataintegriteit. Onlogische datasituaties kunnen ontstaan door fouten in database- en serverconfiguraties of door het per ongeluk injecteren van testdata in de productieomgeving. Dataintegriteitschecks zijn bedoeld om data te valideren aan de hand van die bedrijfsregels, zodat waarden die niet kloppen of onlogisch zijn, worden opgespoord.

Database-entiteiten houden altijd verband met elkaar. Dit heet een entiteitsrelatie en wordt vaak weergegeven met een entity relationship diagram (ERD). Onvoldoende referentiële integriteit kan leiden tot problemen zoals ontbrekende of onvolledige data. Datacontracten moeten deze potentiële valkuilen adresseren om dataintegriteit en nauwkeurigheid te waarborgen.

Een veelvoorkomende relatie is bijvoorbeeld een één-op-veel-associatie tussen customers en orders waarbij één klant meerdere orders kan hebben. In zo’n scenario is een order alleen geldig als die een geldige customer_id bevat binnen de customers-dataset.

Dit type beperking, een referential integrity constraint, zorgt ervoor dat de relatie tussen entiteiten correct wordt onderhouden.

Service Level Agreements (SLA’s) in datacontracten

SLA’s zijn een extra niveau van datakwaliteitschecks die je met datacontracten kunt implementeren.

SLA’s verwijzen naar datafreshness.

Omdat datamodellen regelmatig met nieuwe data worden bijgewerkt, kunnen SLA’s checks bevatten voor het laatste tijdstip waarop nieuwe data beschikbaar moet zijn of de maximaal toelaatbare vertraging. In dbt kun je dit bijvoorbeeld realiseren met freshness-tests:

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1

Stel dat we een rapport over de feiten van gisteren willen genereren; dan willen we zeker weten dat die data er is. Het zou immers vreemd zijn om een paar dagen of langer geen nieuwe orders te zien.

In het onderstaande voorbeeld kunnen we onze dataset testen op onverwachte ordervertragingen met de testconfig in dbt. Hiermee kun je de test selecteren en refereren met die specifieke naam.

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"

Door een aangepaste naam te definiëren, heb je volledige controle over hoe de test wordt weergegeven in logberichten en metadata-artifacts.

Evenzo wordt in realtime datapijplijnen data doorgaans niet ouder verwacht te zijn dan enkele uren. SLA’s zijn cruciaal voor stream-processing-applicaties waarbij data realtime wordt verwerkt met minuten- of zelfs secondenlatentie.

In streaming-apps willen we de maximaal toelaatbare vertraging voor laat binnenkomende events controleren en metrics zoals Mean Time Between Failures (MTBF) en Mean Time to Recovery (MTTR). Dit implementeren houdt in dat incidenten zorgvuldig worden bijgehouden en relevante data wordt geëxtraheerd uit applicatiemonitoring- en incidentmanagementtools zoals PagerDuty, Datadog en Grafana.

Datagovernance-contracten

Het correct omgaan met Persoonlijk Identificeerbare Informatie (PII) is integraal onderdeel van het datatransformatieproces. Voor veel bedrijven is het cruciaal dat deze datasets minimaal GDPR-conform zijn en voldoen aan privacyregels zoals HIPAA of PCI DSS.

Datagovernance-contracten zorgen ervoor dat adequate pseudonimisering of datamasking-beleid aanwezig is. 

Bekijk de onderstaande dbt-code. Contracten die als tests worden afgedwongen, vereisen dat een user_email een SHA256-hash (gemaskeerd) is:

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matching

Aan de andere kant willen we wellicht patroonmatching afdwingen voor andere tabellen. In het onderstaande voorbeeld moet het veld transaction_reference voldoen aan het patroon [“TRX-%”, “%-2023”]:

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: any

Datagovernance-contracten kunnen ook nuttig zijn wanneer ze kolommen met gevoelige data, metadata (data-eigenaren, enz.) en gebruikersrollen bevatten die gemachtigd zijn om toegang te krijgen tot een dataprodukt.

We kunnen bijvoorbeeld met het meta-veld in dbt aangeven wie de eigenaar van ons datamodel is en in welke fase van de modelontwikkelingslevenscyclus het zich bevindt:

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: true

Met het meta-veld kun je metadata instellen voor een resource, die vervolgens wordt opgenomen in het door dbt gegenereerde bestand manifest.json en kan worden bekeken in de automatisch gegenereerde documentatie. 

We kunnen pakketten zoals dbt-checkpoint gebruiken om dit tijdens de pull request te scannen en te verzekeren dat onze verplichte metavelden aanwezig zijn. De hook faalt als een model (uit een manifest of YAML-bestanden) de opgegeven metakeys niet heeft.

De meta-keys van het model moeten in het YAML-bestand of het manifest staan.

Implementatiepatronen voor datacontracten

Contractvalidatie kan worden uitgevoerd in streamingdatapijplijnen (per rij) vóórdat data wordt ingeladen en erna — aan de bron (bron-datamodellaag).

Als we data “as is” inladen, fungeert het validatieproces als een transformatieslag die contractregels afdwingt en ongeldige data wegfiltert, bijvoorbeeld naar een aparte databaseview of tabel waar de data verder onderzocht kan worden.

Validatiechecks kunnen achteraf worden toegepast wanneer data direct in een ruwe data lake wordt geladen.

Het primaire voordeel van realtime validatie van datacontracten is het vermogen om ongeldige records te filteren voordat ze hun eindbestemming bereiken — een data lake of een datawarehouse. Deze aanpak is gangbaar in eventgedreven of realtime dataverwerking, zoals Change Data Capture (CDC)-events. Bij dit type validatie worden bepaalde aspecten van het contract geverifieerd terwijl de data door de pijplijn stroomt.

Tools voor datacontracten

De datacommunity erkent geleidelijk de potentiële voordelen van datacontracten, een voortdurend evoluerend domein binnen data engineering. Er bestaan veel tools op dit gebied, sommige nog in een vroeg stadium. dbt kun je beschouwen als een universeel framework voor datacontracten.

Vergelijkbare contracten kunnen worden geïmplementeerd met Google’s Dataform aan de bron (bron-datamodellaag), dus wanneer de data succesvol in ons datawarehouse is geladen. Daarvoor willen we eenvoudige rijcondities gebruiken. 

Bekijk dit voorbeeld hieronder. Het past bepaalde rijcondities toe op onze tabel:

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …

Hieronder staat nog een voorbeeld van het implementeren van datacontracten, wat je kunt bereiken met Soda.io, een gespecialiseerde datakwaliteitsframework:

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0

Door de alarminstellingen aan te passen, kun je een check configureren om een waarschuwing te geven in plaats van de validatie te laten falen. Een Soda-scan voert de in een overeenkomst gespecificeerde checks uit, controleert het YAML-bestand of inline binnen een programmatische aanroep, en geeft voor elke check een resultaat terug: pass, fail of error.

Uit mijn ervaring blijkt dat de introductie van datacontracten bij veel bedrijven gefragmenteerd blijft, afhankelijk van factoren zoals ontwerp-patronen van datapijplijnen (batch of realtime), keuzes voor dataserialisatie en de systemen die worden gebruikt voor opslag en verwerking.

De implementatie van datacontracten hangt af van bedrijfsvereisten en -logica.

Great Expectations, een Python-bibliotheek, kan worden gebruikt om semantische datacontracten te implementeren. Je kunt deze installeren met pip: pip install great_expectations. 

Na het uitvoeren van great_expectations init kunnen we doorgaan met datavalidatie:

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:

Bekijk het onderstaande codefragment. Dat legt uit hoe je een definitie van een datacheck maakt voor de kolom price:

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},

Best practices voor datacontracten

Er is hier geen eenduidig goed of fout, want uit mijn ervaring blijkt dat een succesvolle implementatie van datacontracten sterk leunt op bedrijfsvereisten. Volg deze belangrijke best practices om datacontracten effectief te laten werken:

• Schaalbaarheid: Ik raad aan mechanismen toe te voegen voor uitbreidbaarheid (bijv. on_schema_change: append) en versiebeheer, zodat je de voorwaarden van een datacontract kunt aanpassen zonder bestaande pijplijnintegraties te verstoren. Ontwerp datacontracten met oog voor toekomstige veranderingen en schaalbaarheid. Zo kan het contract meebewegen met veranderende behoeften en groei.
• Duidelijke regels: Gebruik eenvoudige en bondige taal in het datacontract om misverstanden en verkeerde interpretaties te voorkomen. Het contract moet zo geschreven en benoemd zijn dat het toegankelijk en begrijpelijk is voor alle betrokken partijen, ongeacht hun technische expertise.
• Samenwerking: Een gezamenlijke inspanning zorgt voor een volledige en evenwichtige kijk op de vereisten, waarbij verschillende perspectieven en behoeften worden meegenomen. Betrek bij het opstellen van datacontracten diverse stakeholders, waaronder dataproducers, data engineers, data scientists en vertegenwoordigers van business, IT, juridische en compliance-afdelingen.
• Metadata: Voorzie datacontracten van grondige documentatie en metadata. Uitgebreide documentatie helpt bij de soepele toepassing en het onderhoud van het contract. Dit moet onder meer gedetailleerde beschrijvingen, velddefinities, validatieregels en andere relevante informatie bevatten die een helder begrip en effectieve implementatie ondersteunt.
• Regelmatige reviews: Voortdurende evaluatie helpt de relevantie en effectiviteit van het contract in de tijd te behouden. Implementeer een gestructureerde aanpak voor monitoring en updates van datacontracten. Regelmatige reviews zorgen ervoor dat het contract actueel blijft, aansluit op veranderende bedrijfsbehoeften en voldoet aan nieuwe of gewijzigde regelgeving.

Conclusie

Onlangs is er een verschuiving richting gedistribueerd databezit, waarbij domeinteams verantwoordelijk zijn voor hun dataprodukten. Deze verandering dwong organisaties om verwachtingen rond datakwaliteit te herdefiniëren, vastgelegd in datacontracten.

Semantische datavalidaties zorgen ervoor dat data logisch consistent is en past bij de bedrijfslogica. Ze helpen datapijplijnen te controleren op uitschieters in data, waarden, lineage en referentiële integriteit. Onvoldoende referentiële integriteit kan leiden tot ontbrekende of onvolledige data, daarom is dit ook belangrijk. 

Datagovernance-contracten kunnen ook in CI/CD-pijplijnen worden geïmplementeerd en zijn zeer nuttig wanneer ze kolommen met gevoelige data, metadata (data-eigenaren, enz.) en gebruikersrollen aangeven die toegang hebben tot een dataprodukt. 

De metadata van een model, samen met andere verplichte metavelden die door de ontwikkelaar zijn gedefinieerd, helpt bij het monitoren van het resourcegebruik en de prestaties van het model. 

Service Level Agreements (SLA’s) binnen datacontracten beschrijven specifieke verplichtingen met betrekking tot datafreshness, volledigheid en herstel na storingen.

Datacontracten zijn essentieel voor moderne datamodelleringstechnieken en helpen ervoor te zorgen dat het dataplatfom minder foutgevoelig is en goed schaalt. Het oplossen van datakwaliteitsproblemen kan kostbaar zijn. Voor ondernemingen wordt het maximaliseren van de return on investment (ROI) uit data steeds belangrijker door gebruik te maken van bestaande datakwaliteitstools die validatie van datacontracten ondersteunen.