Amazon DEA-C01: Veri Kalitesi, Doğrulama ve Gözlemlenebilirlik — Çalışma kılavuzu

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Şunun bir parçası: Amazon Data Engineer Associate DEA-C01 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Bu alan, veri doğruluğunu sağlamak, anomalileri tespit etmek ve veri hatlarının (pipeline) güvenilirliğini sürdürmek için kullanılan uçtan uca uygulamaları ve AWS servislerini kapsar. Güçlü doğrulama ve gözlemlenebilirlik, akışın ilerisindeki (downstream) kusurları azaltır, SLA’ları karşılar ve güvenli yeniden işlemeyi mümkün kılar. Veri mühendisleri, sağlam veri hatları oluşturmak için Glue Data Quality, doğrulama framework’leri, CloudWatch anomali tespiti, DLQ’lar ve idempotent tasarımı birleştirmelidir.

AWS Glue Data Quality kuralları ve değerlendirmesi

Glue Data Quality, veri setleri hakkında doğrulama ifadeleri (satır sayıları, null eşikleri, benzersizlik, özel SQL kontrolleri) tanımlamak için Data Quality Definition Language (DQDL) kural setlerini kullanır. Kural setlerini konsolda veya CLI ile oluşturun (örnek desen: aws glue create-data-quality-ruleset –name MyRuleset –rules file://dqdl.json). Kural setleri, Glue ETL işlerine eklenebilir veya S3’te, katalog tablolarında ya da Glue DynamicFrames’de depolanan veri setlerini değerlendirmek için StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun API’leri aracılığıyla bağımsız olarak çalıştırılabilir.

Temel yapılandırma detayları ve karar kriterleri:

• DQDL yapısı: kurallar ruleName, expression (DQDL veya SQL), severity (önem derecesi) ve hata durumunda yapılacak eylemi içerir. Kritik kontroller başarısız olduğunda işi FAIL durumuna getirmek için hata durumunda yapılacak eylemi açıkça ayarlayın; aksi takdirde Glue, çalıştırmayı başarısız kılmadan sadece sonuçları loglayabilir.
• Değerlendirme bağlamı: maliyet ve kapsam arasında denge kurmak için iş parametreleri veya değerlendirme çalıştırma girdileri aracılığıyla tablo veya S3 yolu referansları ve örnekleme seçenekleri (tam tarama vs. örneklem) sağlayın.
• Çıktı: kural değerlendirmesi, sonuçları Glue metriklerine ve Amazon S3’e JSON olarak yazar; bu yapıtları (artifacts) denetim ve otomatik iyileştirme için kullanın.

Glue Data Quality ve harici framework’lerin ne zaman kullanılacağı:

• Glue işlerine ve veri soyuna (lineage) doğal olarak entegre olan standart şema, bütünlük ve basit benzersizlik kuralları için Glue DQDL kullanın.
• Daha zengin beklenti (expectation) kütüphanelerine, daha ifade gücü yüksek kontrollere veya birden çok sistemde paylaşılan beklenti setlerine ihtiyacınız olduğunda Great Expectations’ı (bir sonraki alt alana bakın) kullanın.

Veri hatlarında doğrulama desenleri

Doğrulama, birden çok temas noktasında yer almalıdır: veri girişi (ingress), dönüşüm (transformation) ve hedef (sink). Yaygın desenler:

• Veri hattına girmeden önce hatalı satırları reddetmek veya yönlendirmek için Lambda/Kinesis üreticilerinde şema ve temel değer aralıkları için hafif veri alımı öncesi kontroller.
• Glue ETL (Spark) işlerinde DQDL kural setleri ve kod içinde açık doğrulamalar kullanarak sunucu tarafı doğrulama. Glue Studio’da, bir kural setine referans veren bir Data Quality dönüşümü ekleyin; CLI’da, değerlendirme çalıştırmalarını tetiklemek için –arguments ‘{"–enable-glue-datacatalog":""}’ parametresini geçin veya iş parametrelerini dahil edin.
• Glue Python Shell veya Glue Spark işlerine entegre edilmiş Great Expectations ile dönüşüm sonrası doğrulama. Beklentileri S3’e (expectations/ dizini) dağıtın ve S3’teki beklentileri iş ortamına senkronize ettikten sonra işte DataContext’i yükleyin: DataContext(root_dir="/tmp/ge").

Doğrulama seçeneklerinin karşılaştırması:

• Glue DQDL
  • Artıları: doğal entegrasyon, düşük operasyonel yük, sonuçları Glue kataloğuna/metriklerine yazar
  • Eksileri: karmaşık mantıksal beklentiler için daha az ifade gücü
• Great Expectations
  • Artıları: zengin beklentiler, veri dokümanları (data docs), entegre kontrol noktaları (checkpoints), genişletilebilir arka uçlar (backends)
  • Eksileri: beklenti yapıtlarını (artifacts) S3’te paketlemeyi, yönetmeyi ve Glue işlerinde orkestrasyonu gerektirir
• Kod içinde manuel kontroller (Spark/DataFrame)
  • Artıları: tam esneklik, özel mantık için yüksek performans
  • Eksileri: daha yüksek bakım maliyeti, ek çaba olmadan standartlaştırılmış raporlama olmaması

Akış (streaming) verileri için, işlem anındaki (in-flight) kayıtları doğrulayın ve hata durumunda kayıtları atmak yerine bir SQS DLQ’ya (Dead-Letter Queue) gönderin (AWS CLI veya konsol aracılığıyla maxReceiveCount ile RedrivePolicy’yi yapılandırın). Toplu (batch) işler için, bir doğrulama raporu yapıtı oluşturun ve politikaya göre çıktıları başarısız kılın veya karantinaya alın.

Anomali tespiti ve veri kayması (data drift) izleme

Operasyonel metrikler (işlenen kayıt sayısı, hata oranı, iş süresi) için CloudWatch anomali tespitini kullanın. CLI ile bir dedektör oluşturun: aws cloudwatch put-anomaly-detector –namespace “Glue” –metric-name “JobRunTime” –statistic “Average” –single-metric-anomaly-detector ‘{“MetricName”:“JobRunTime”,“Namespace”:“Glue”,“Stat”:“Average”,“Dimensions”:[…]}’ ve ardından anomali tespit bandına referans veren CloudWatch alarmları oluşturun. Veri seviyesinde kayma (dağılım değişiklikleri, null oranı değişiklikleri) için, istatistikleri, histogramları ve kantilleri (quantiles) hesaplamak üzere Glue DataBrew profil işleri (aws databrew create-profile-job) zamanlayın; profilleri temel (baseline) olarak S3’te saklayın.

Anomali ve eşik alarmları için karar kriterleri:

• Metrik desenleri mevsimsel veya değişken olduğunda CloudWatch anomali tespitini seçin; geçmiş davranışı öğrenir ve manuel eşik ayarlama ihtiyacını azaltır.
• Öngörülebilirliğin yüksek olduğu ikili (binary) koşullar (örneğin, işin X saatten fazla takılı kalması) için statik eşik alarmları kullanın.

Otomatik kayma tespiti için:

• Metrik temellerini (null yüzdesi, kardinalite, yüzdelik dilimler) yakalamak için düzenli DataBrew profil işleri (veri hızına bağlı olarak günlük/haftalık) zamanlayın.
• Yeni profil çıktılarını, temel profillerle ya Glue kural setleri (özel SQL kontrolleri) ya da temel istatistiklere referans veren Great Expectations özel beklentileri kullanarak karşılaştırın.
• Kayma politika eşiklerini aştığında veya anomali dedektörleri olağandışı metrik davranışını işaretlediğinde SNS / EventBridge kullanarak uyarı oluşturun.

SLA yönetimi ve pipeline güvenilirliği

SLA yönetimi, gözlemlenebilirliği düzeltme ve güvenilirlik mühendisliği ile birleştirir. Her pipeline’ı şu temel metriklerle donatın: iş hacmi (kayıt/sn), gecikme (ingest→sink), hata oranı, job/çalışma zamanı ve aşağı akış (downstream) sayıları. Glue job’ları (job çalışma metrikleri), Kinesis/Kafka tüketici gecikmesi (consumer lag) ve PutMetricData aracılığıyla özel uygulama metrikleri için CloudWatch Metrics’i kullanın.

Güvenilirlik desenleri ve yapılandırma ayrıntıları:

• İşlenemeyen mesaj kuyrukları (SQS DLQ): Akış tüketicileri (Lambda, Kinesis tüketicileri) için bir DLQ yapılandırın ve RedrivePolicy(maxReceiveCount) ayarını yapın. DLQ mesajlarını incelemek ve yeniden işlemek için DLQ saklama süresini ve ayrı bir işleme job’unu kullanın.
• İdempotent tasarım: Hedef sistemlerin (sink) idempotent yazmaları desteklediğinden emin olun — örnekler:
  • DynamoDB: PutItem’ı koşullu ifadelerle veya idempotency token için birleşik bir anahtarla kullanın.
  • S3: Atomik yeniden adlandırma desenleriyle yazın veya içerik tabanlı anahtarlar (kaydın hash’i) kullanın, böylece yeniden denemeler yinelenen kayıt oluşturmak yerine üzerine yazar.
  • Redshift/Glue ETL: Yeniden işleme sonrası tekilleştirme için anahtara göre hazırlık (staging) + MERGE kullanın.
• Kontrol noktası oluşturma (Checkpointing): Kinesis/DynamoDB bağlayıcı kontrol noktalarını etkinleştirin ve yeniden işleme penceresi ile yinelenme riskini dengelemek için tüketici kontrol noktası sıklığını yönetin.

Yeniden deneme ve hızlı başarısız olma (fail-fast) için karar kriterleri:

• Geçici hatalar (aşağı akışta kısıtlama/throttling) için, üstel geri çekilme (exponential backoff) ile yeniden denemeler uygulayın ve yalnızca maksimum yeniden deneme sayısından sonra bir DLQ kullanın.
• Veri kalitesi hataları (şema uyuşmazlığı) için, hızlıca başarısız olun ve sorunlu kayıtları manuel inceleme için meta verilerle birlikte bir karantina S3 ön ekine yazın.

Yaygın Tuzaklar ve Karar Kriterleri

• Glue Data Quality kuralları varsayılan olarak hataları günlüğe kaydeder ancak job’u başarısız kılmaz — kritik kontroller için kural eylemini FAIL olarak yapılandırın ve kural seti değerlendirmesini job çalışmasına ekleyin.
• DLQ’ları olmayan akış pipeline’ları, başarısız kayıtları atar veya kaybeder — incelemek ve yeniden işlemek için her zaman SQS DLQ’larını (veya kalıcı S3 hazırlık alanını) ve bir yeniden yönlendirme politikasını (redrive policy) yapılandırın.
• İdempotent olmadan yeniden işleme, yinelenen kayıtlar üretir — deterministik anahtarlar tasarlayın, hedef sistemde upsert/merge semantiğini kullanın veya S3 için içerik tabanlı nesne anahtarları uygulayın.
• Temel çizgiler (baseline) olmadan veri kayması tespiti, gürültülü uyarılar üretir — temel istatistikleri oluşturmak ve saklamak için Glue DataBrew profil job’larını zamanlayın, ardından yeni profilleri bunlarla karşılaştırın.
• Statik CloudWatch eşiklerine aşırı güvenmek yanlış pozitiflere neden olur — mevsimsel/değişken metrikler için CloudWatch anomali tespitini kullanın ve statik eşikleri tartışılamaz sınırlar için saklayın.
• maxReceiveCount değerini çok yüksek ayarlamak, DLQ yönlendirmesini geciktirir ve işleme gecikmesini artırır — kalıcı olarak başarısız olan mesajların DLQ’lara zamanında ulaşması için makul bir maxReceiveCount seçin.

Pratik Problem: Kullanım Senaryosu

Streamline Retail, gecelik ETL’den sonra sık sık aşağı akış raporlama hatalarıyla karşılaşıyor: ara sıra şema ani artışları, sessiz kural ihlalleri ve başarısız çalışmaların yeniden işlenmesiyle yinelenen siparişler.

1. order_id üzerinde şema, null eşikleri ve benzersizlik için Glue Data Quality kurallarını (DQDL) uygulayın; hata durumunda eylemi job’u FAIL olarak ayarlayın ve değerlendirme çıktılarını S3’te yayınlayın.
2. Karmaşık iş kontrolleri (tablolar arası sipariş tutarlılığı) için bir Glue Python Shell adımında Great Expectations ekleyin; beklentileri S3’te saklayın ve pipeline’da kontrol noktalarını (checkpoint) çalıştırın.
3. Günlük temel çizgileri (kardinalite, null oranı, yüzdelik dilimler) yakalamak için DataBrew profil job’larını zamanlayın ve kaymayı tespit etmek için otomatik karşılaştırmaları kullanın.
4. Akış halindeki sipariş olayları için, uygun bir RedrivePolicy ile SQS DLQ yapılandırın ve DLQ mesajlarını idempotent bir şekilde (order_id’yi tekilleştirme anahtarı olarak kullanarak) işlemek için bir yeniden oynatma (replay) job’u oluşturun.
5. Job çalışma zamanı ve hata sayısı için CloudWatch anomali dedektörlerini devreye alın; anomali tabanlı alarmları nöbetçi ekibe bildirim için SNS’e bağlayın.

AWS en iyi uygulama gerekçesi: Hızlı entegrasyon için yerel Glue kalite kontrollerini, ifade gücü için Great Expectations’ı, temel istatistikler için DataBrew’ü ve uyarlanabilir izleme için CloudWatch anomali dedektörlerini birleştirin. DLQ’lar ve idempotent hedef sistemler, SLA’ları korurken güvenli yeniden denemeler ve yeniden işleme için döngüyü tamamlar.

← Veri İş Yükleri için Maliyet Optimizasyonu · Tüm alanlar

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →