Kurs
Veri Mühendisliğini Anlamak
2 sa
378K
Veri sözleşmeleri, dağıtık veri çözümlerinde veri kalitesi ve ölçeklenebilirliğin bel kemiğidir. Veritabanı varlıkları arasındaki alışverişi yöneten biçim, şema ve protokolleri tanımlarlar. Bu resmi anlaşmalar, veriye ilişkin belirsizlikleri ve belgelendirilmemiş varsayımları ortadan kaldırır.
Bu yazıda, veri sözleşmelerinin kavramını netleştirmek için hem temel hem de ileri seviye teknikler sunarak bunların etkili şekilde uygulanmasını kolaylaştıracağım.
Veri Sözleşmelerini Anlamak
Tek bir veri sözleşmesi, iki model arasındaki veri alışverişine ilişkin kesin parametreleri belirler. Bu resmi anlaşmalar, veri biçimi ve şemalar konusunda hiçbir belirsizlik kalmamasını sağlar.
Veri sözleşmesi tanımları ve doğrulaması, ekipler arası etkili iş birliği için kritik öneme sahiptir.
Özetle, bir veri sözleşmesi, verinin orijinal durumunu değiştiren süreç (üreticiler) ile hedefler (tüketiciler) arasındaki resmi bir anlaşmadır. İş sözleşmelerinin işleyişine çok benzer. Nasıl ki iş ürününün tedarikçileri ve tüketicileri arasında yükümlülükleri temsil ediyorlarsa, veri sözleşmeleri de tablo, görünüm, veri modeli vb. veri ürünleri için aynı şeyi yapar.
Amaç, veri hattında aşağı akıştaki kesintileri azaltmak ve veri dönüşümlerini istikrarlı ve güvenilir kılmaktır.
Bir veri sözleşmesinin ana bileşenleri, şema (sütunlar ve biçimler), anlamsal katman bölümü (metrikler, hesaplamalar ve kısıtlar), hizmet düzeyi anlaşmaları (SLA’lar) ve veri yönetişimidir.
Veri sözleşmelerinin faydaları şunları içerir:
- Veri kalitesi otomasyonu ve yeni veri çıktıları oluşturulduğunda veya güncellendiğinde kontroller.
- Özellikle dağıtık veri mimarisi, ör. data mesh, için verimli ölçeklemeyi mümkün kılma.
- Sözleşme doğrulaması için araçlar geliştirmeye odaklanarak veri geliştirme yaşam döngüsünü iyileştirme.
- Veri üreticileri ve tüketicileri arasında geri bildirim yoluyla iş birliğini teşvik etme.
Veri sözleşmeleri. Görsel: yazar.
dbt ile veri sözleşmesi örneği
Bir veri sözleşmesinde şemalar, öznitelik adlarını, veri türlerini ve özniteliklerin zorunlu olup olmadığını tanımlar. Ayrıca sütunlar için biçim, uzunluk ve kabul edilebilir değer aralıklarını da belirtebilirler.
Bir dbt model şemasının bir YAML dosyasında aşağıdaki gibi tanımlandığını düşünelim. Tablo şemamız columns altında tanımlıdır:
models:
- name: dim_orders
config:
materialized: table
contract:
enforced: true
columns:
- name: order_id
data_type: int
constraints:
- type: not_null
- name: order_type
data_type: stringŞimdi dim_orders modelimizi şöyle tanımladığımızı hayal edelim:
select
'abc123' as order_id,
'Some order type' as order_typeModel tanımımızda contract için enforced: true ayarı olması, dim_orders’ı veri platformumuzda bir tabloya materyalize etmeye çalışırsak aşağıdaki hatayı tetikleyecektir:
20:53:45 Compilation Error in model dim_customers (models/dim_orders.sql)
20:53:45 This model has an enforced contract that failed.
20:53:45 Please ensure the name, data_type, and number of columns in your contract match the columns in your model's definition.
20:53:45
20:53:45 | column_name | definition_type | contract_type | mismatch_reason |
20:53:45 | ----------- | --------------- | ------------- | ------------------ |
20:53:45 | order_id | TEXT | INT | data type mismatch |
20:53:45
20:53:45
20:53:45 > in macro assert_columns_equivalent (macros/materializations/models/table/columns_spec_ddl.sql)Aynı durum, tanımlamayı tercih etmiş olsaydık, fazladan sütunlar, SLA kontrolleri ve eksik meta veriler için de geçerli olurdu.
Daha gelişmiş bir dbt örneği, zorunlu model kısıtları içerir:
# models/schema.yaml
models:
- name: orders
# required
config:
contract:
enforced: true
# model-level constraints
constraints:
- type: primary_key
columns: [id]
- type: FOREIGN_KEY # multi_column
columns: [order_type, SECOND_COLUMN, ...]
expression: "OTHER_MODEL_SCHEMA.OTHER_MODEL_NAME (OTHER_MODEL_FIRST_COLUMN, OTHER_MODEL_SECOND_COLUMN, ...)"
- type: check
columns: [FIRST_COLUMN, SECOND_COLUMN, ...]
expression: "FIRST_COLUMN != SECOND_COLUMN"
name: HUMAN_FRIENDLY_NAME
- type: ...
columns:
- name: FIRST_COLUMN
data_type: DATA_TYPE
# column-level constraints
constraints:
- type: not_null
- type: unique
- type: foreign_key
expression: OTHER_MODEL_SCHEMA.OTHER_MODEL_NAME (OTHER_MODEL_COLUMN)
- type: …Bir şema tanımını, bir veri kümesinin sütunlarına uygulanan bir dizi kural ve kısıt olarak sunmak, veriyi işlemek ve analiz etmek için çok önemli bilgiler sağlar.
Şemalar zaman içinde değişme eğilimindedir.
Bu yaygın bir senaryodur. Kaynak tablomuzun sözleşmeli fazladan bir sütun eklediğini hayal edelim:
select
'abc123' as order_id,
'Some order type' as order_type,
'USD' as currencyArtımlı güncellemeler gerçekleştirirken şema değişikliklerini dikkate almak çok önemlidir; aksi takdirde aşağı akıştaki artımlı modelin çıktısı sözleşmeyi geçersiz kılacaktır.
Bu, dbt artımlı stratejisine on_schema_change: append eklenerek çözülebilir.
Şema doğrulamaları açık veya örtük olabilir.
AVRO ve Parquet gibi bazı büyük veri dosya biçimleri, varsayılan olarak yerleşik şemayı ve örtük şema tanımlarını destekler; bu nedenle ilave harici doğrulamaya gerek yoktur.
Buna karşılık, JSON gibi şemasız veri dosya biçimleri harici şema doğrulaması gerektirir. pydantic veya basit bir @dataclass gibi bazı Python kütüphaneleri, bunu gerçekleştirebilir:
from pydantic import BaseModel
class ConnectionDataRecord(BaseModel):
user: str
ts: int
record = ConnectionDataRecord(user="user1", ts=123456789)Kuralları ihlal eder ve ölçütlerimizle eşleşmeyen değerler atarsak bir istisna fırlatılır. Örneğin, ConnectionDataRecord('', 1) çağrısını yapmaya çalışırsak istisna oluşur.
Veri sözleşmeleri, veri doğrulama ve veri testinden nasıl farklıdır?
Veri sözleşmeleri gerçek zamanlı akış veri hatlarında kullanılabilir mi?
Şema değişiklikleri sık olduğunda veri sözleşmelerinde sürümleme nasıl yönetilir?
Veri sözleşmeleri, data mesh mimarisinde ne rol oynar?
Veri sözleşmeleri, GDPR veya HIPAA gibi gizlilik düzenlemelerine uyuma nasıl yardımcı olur?
Konular
