Algo muito simples mas que pode ajudar MUITO o engenheiro de dados.
Contratos de Dados, consultoria em Governança e Qualidade de Dados são alguns dos serviços que oferecemos para facilitar a sua vida e ajudar a sua organização a obter vantagens estratégicas.
Basicamente, o Contrato de Dados é um arquivo de texto simples com informações que suas rotinas de processamento (conexões, transferências, transações) devem usar para garantir a Qualidade e a Governança dos Dados. Ele reflete um acordo entre os fornecedores de dados e os consumidores de dados (que podem ser uma empresa que fornece dados e seus clientes ou até mesmo departamentos ou times de uma mesma empresa), no qual se formalizam:
Informações básicas: nome de tabelas, colunas, versionamento.
Schema: estrutura lógica e física em que os dos devem estar estruturados.
Data quality: regras que os dados devem atender no momento da entrega, definidas pela Governança de Dados.
Service-level agreement (SLA): regras que as partes devem atender (prazos, retenção, frequência de entrega, disponibilidade).
Security & stakeholders: regras de segurança que devem ser atendidas e os responsáveis.
Custom properties: detalhes particulares exigidos pelo cliente.
Esse arquivo pode ser adicionado a pipelines, permitindo testes contínuos ou até integrando o controle de fluxos, então, a cada momento, os dados devem atender as regras definidas.
Quando falamos em Governança de Dados, especialmente nos processos de ETL, os contratos de dados se destacam como uma ferramenta chave. Eles são como um manual que define como os dados devem ser tratados em cada etapa do processamento e pipeline. Isso não só simplifica as coisas, mas também garante que nossos dados se mantenham íntegros e confiáveis.
Outra grande vantagem é a Transparência. Com Contratos de Dados, podemos visualizar exatamente como cada pedacinho de informação é transformado durante o ETL. Essa transparência não só ajuda a entender melhor, mas também facilita auditorias e verificações de conformidade.
E tem mais: a Rastreabilidade. Ao usar Contratos de Dados, podemos vincular cada transformação ao seu contrato correspondente. Isso significa que podemos seguir o caminho dos dados de maneira eficiente. Se algo der errado, podemos identificar o problema mais rápido e resolver questões de qualidade de dados sem dores de cabeça.
Mas, é claro, para que isso funcione bem, precisamos manter e ajustar nossos contratos de dados conforme necessário. À medida que as coisas mudam, nossos contratos também precisam mudar para continuarem úteis. Essa flexibilidade nos permite lidar com as mudanças no mundo dos negócios de forma mais rápida e eficaz.
Em suma: usar Contratos de Dados para governar nossos processos de ETL é uma jogada que permite um salto na Qualidade e Governança do nosso trabalho. Eles não apenas melhoram a qualidade dos dados, mas também fortalecem a base sobre a qual tomamos decisões importantes.
Exemplo de arquivo de Contrato de Dados
dataContractSpecification: 0.9.3
id: urn:datacontract:checkout:orders-latest
info:
title: Orders Latest
version: 1.0.0
description: |
Successful customer orders in the webshop.
All orders since 2020-01-01.
Orders with their line items are in their current state (no history included).
owner: Checkout Team
contact:
name: John Doe (Data Product Owner)
url: https://teams.microsoft.com/l/channel/example/checkout
servers:
production:
type: s3
location: s3://datacontract-example-orders-latest/data/{model}/*.json
format: json
delimiter: new_line
terms:
usage: |
Data can be used for reports, analytics and machine learning use cases.
Order may be linked and joined by other tables
limitations: |
Not suitable for real-time use cases.
Data may not be used to identify individual customers.
Max data processing per day: 10 TiB
billing: 5000 USD per month
noticePeriod: P3M
models:
orders:
description: One record per order. Includes cancelled and deleted orders.
type: table
fields:
order_id:
$ref: '#/definitions/order_id'
required: true
unique: true
order_timestamp:
description: The business timestamp in UTC when the order was successfully registered in the source system and the payment was successful.
type: timestamp
required: true
order_total:
description: Total amount the smallest monetary unit (e.g., cents).
type: long
required: true
customer_id:
description: Unique identifier for the customer.
type: text
minLength: 10
maxLength: 20
customer_email_address:
description: The email address, as entered by the customer. The email address was not verified.
type: text
format: email
required: true
processed_timestamp:
description: The timestamp when the record was processed by the data platform.
type: timestamp
required: true
line_items:
description: A single article that is part of an order.
type: table
fields:
lines_item_id:
type: text
description: Primary key of the lines_item_id table
required: true
unique: true
order_id:
$ref: '#/definitions/order_id'
sku:
description: The purchased article number
$ref: '#/definitions/sku'
definitions:
order_id:
domain: checkout
name: order_id
title: Order ID
type: text
format: uuid
description: An internal ID that identifies an order in the online shop.
example: 243c25e5-a081-43a9-aeab-6d5d5b6cb5e2
pii: true
classification: restricted
sku:
domain: inventory
name: sku
title: Stock Keeping Unit
type: text
pattern: ^[A-Za-z0-9]{8,14}$
example: "96385074"
description: |
A Stock Keeping Unit (SKU) is an internal unique identifier for an article.
It is typically associated with an article's barcode, such as the EAN/GTIN.
examples:
- type: csv # csv, json, yaml, custom
model: orders
data: | # expressed as string or inline yaml or via "$ref: data.csv"
order_id,order_timestamp,order_total,customer_id,customer_email_address,processed_timestamp
"1001","2030-09-09T08:30:00Z",2500,"1000000001","mary.taylor82@example.com","2030-09-09T08:31:00Z"
"1002","2030-09-08T15:45:00Z",1800,"1000000002","michael.miller83@example.com","2030-09-09T08:31:00Z"
"1003","2030-09-07T12:15:00Z",3200,"1000000003","michael.smith5@example.com","2030-09-09T08:31:00Z"
"1004","2030-09-06T19:20:00Z",1500,"1000000004","elizabeth.moore80@example.com","2030-09-09T08:31:00Z"
"1005","2030-09-05T10:10:00Z",4200,"1000000004","elizabeth.moore80@example.com","2030-09-09T08:31:00Z"
"1006","2030-09-04T14:55:00Z",2800,"1000000005","john.davis28@example.com","2030-09-09T08:31:00Z"
"1007","2030-09-03T21:05:00Z",1900,"1000000006","linda.brown67@example.com","2030-09-09T08:31:00Z"
"1008","2030-09-02T17:40:00Z",3600,"1000000007","patricia.smith40@example.com","2030-09-09T08:31:00Z"
"1009","2030-09-01T09:25:00Z",3100,"1000000008","linda.wilson43@example.com","2030-09-09T08:31:00Z"
"1010","2030-08-31T22:50:00Z",2700,"1000000009","mary.smith98@example.com","2030-09-09T08:31:00Z"
- type: csv
model: line_items
data: |
lines_item_id,order_id,sku
"LI-1","1001","5901234123457"
"LI-2","1001","4001234567890"
"LI-3","1002","5901234123457"
"LI-4","1002","2001234567893"
"LI-5","1003","4001234567890"
"LI-6","1003","5001234567892"
"LI-7","1004","5901234123457"
"LI-8","1005","2001234567893"
"LI-9","1005","5001234567892"
"LI-10","1005","6001234567891"
servicelevels:
availability:
description: The server is available during support hours
percentage: 99.9%
retention:
description: Data is retained for one year because!
period: P1Y
unlimited: false
latency:
description: Data is available within 25 hours after the order was placed
threshold: 25h
sourceTimestampField: orders.order_timestamp
processedTimestampField: orders.processed_timestamp
freshness:
description: The age of the youngest row in a table.
threshold: 25h
timestampField: orders.order_timestamp
frequency:
description: Data is delivered once a day
type: batch # or streaming
interval: daily # for batch, either or cron
cron: 0 0 * * * # for batch, either or interval
support:
description: The data is available during typical business hours at headquarters
time: 9am to 5pm in EST on business days
responseTime: 1h
backup:
description: Data is backed up once a week, every Sunday at 0:00 UTC.
interval: weekly
cron: 0 0 * * 0
recoveryTime: 24 hours
recoveryPoint: 1 week
quality:
type: SodaCL # data quality check format: SodaCL, montecarlo, custom
specification: # expressed as string or inline yaml or via "$ref: checks.yaml"
checks for orders:
- row_count >= 5
- duplicate_count(order_id) = 0
checks for line_items:
- values in (order_id) must exist in orders (order_id)
- row_count >= 5
Comments are closed