Amazon DEA-C01: Veri Sorgulama ve Analitik — Ç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, büyük veri setleri üzerinde analitik sorguları ve BI’ı destekleyen AWS hizmetlerinin tasarlanmasını, ayarlanmasını ve işletilmesini kapsar. Athena, Redshift, OpenSearch ve QuickSight genelinde maliyet-etkin, yüksek performanslı sorgu desenlerine ve bu hizmetlerin S3, Glue ve işlemsel depolarla nasıl birlikte çalıştığına odaklanır. Bu alanda uzmanlaşmak, taranan bayt miktarını ve ağdaki dengesizliği (network skew) en aza indirirken düşük gecikmeli içgörüler sunmak için depolama formatı, partition’lama, işlem (compute) türü ve veri yerleşimini dengelemeyi gerektirir.

Amazon Athena sorgu optimizasyonu

Athena fiyatlandırması taranan bayt miktarına dayalıdır, bu nedenle fiziksel veri düzeni ve meta veriler birincil optimizasyon araçlarıdır. Boyutu ve CPU kullanımını azaltmak için sıkıştırma (Parquet için Snappy, Zlib/ORC seçenekleri) ile birlikte sütunlu formatlar (Parquet veya ORC) kullanın. Verileri yüksek kardinaliteye sahip, sorgu ile filtrelenen sütunlara (tarih, bölge gibi) göre partition’layın ve partition’ları Glue Veri Kataloğu’na kaydedin. Tipik desenler:

Verileri S3’e s3://bucket/events/date=2026-08-02/ gibi yollara yazın ve partition’ları doldurmak için Glue crawler’larını veya MSCK REPAIR TABLE komutunu kullanın.
Sütunlu sıkıştırmayı zorunlu kılmak için CREATE EXTERNAL TABLE … STORED AS PARQUET TBLPROPERTIES (‘parquet.compress’=‘SNAPPY’) kullanın.
Gereksiz partition’ları taramaktan kaçınmak için partition anahtarlarına referans veren WHERE ifadeleri aracılığıyla projeksiyon ve partition ayıklama (pruning) kullanın.

Sorgular işlemsel depolarla join gerektirdiğinde, RDS, DynamoDB veya Redshift ile kaynaklar arası join’ler gerçekleştirmek için Athena Federated Query’yi (Lambda bağlayıcıları) kullanın. Bağlayıcılar, Lambda fonksiyonları olarak dağıtılır ve Athena’da veri kaynakları olarak kaydedilir; örnek konsol akışı: Athena > Veri kaynakları > Bağlayıcılar > Yeni. Karar kriterleri:

RDS/DynamoDB’deki veri hacimleri mütevazı olduğunda veya küçük bir boyut tablosunu büyük bir S3 veri setine join ederken Federated Query kullanın.
Tekrarlanan ağır join işlemleri için, operasyonel verileri S3’e (Parquet formatında) çıkarıp materyalize ederek join maliyetini tek bir ETL işlemine kaydırın ve tekrarlanan okumalar için Athena’yı kullanın.

Amazon Redshift sorgu ayarı ve dağıtımı

Redshift performansı, veri hareketini en aza indirmek ve zone haritalamayı (zone mapping) etkinleştirmek için dağıtım stiline (distribution style) ve sıralama anahtarlarına (sort keys) bağlıdır. Bu karar noktalarını kullanarak DIST stillerini seçin:

DISTKEY (KEY): Büyük tabloları yüksek kardinaliteli bir join anahtarı üzerinde birleştirirken kullanışlıdır; her iki tablo da aynı DISTKEY’i paylaşıyorsa yeniden dağıtımı (redistribution) önler.
ALL: Join işlemleri için ağ üzerinde veri karıştırmayı (network shuffles) önlemek amacıyla küçük bir boyut tablosunu tüm node’lara kopyalar.
EVEN: Tahmin edilemeyen iş yükleri veya iyi bir anahtarın bulunmadığı durumlar için varsayılandır; hotspot’ları (aşırı yoğunlaşma) önler.
AUTO: Net bir yönlendirmeniz yoksa Redshift’in tablo boyutuna ve iş yüküne göre seçim yapmasına izin verin.

Zone haritalarını etkinleştirmek ve disk okumalarını azaltmak için aralık filtrelerinde veya ORDER BY’da kullanılan sütunlarda SORTKEY’ler tanımlayın. Yaygın operasyonel komutlar:

CREATE TABLE sales (…) DISTKEY(user_id) SORTKEY(order_date);
Periyodik olarak VACUUM ve ANALYZE kullanın: VACUUM; ANALYZE VERBOSE table; dengesizlik (skew) ve dağıtım metrikleri için SVV_TABLE_INFO ve STL_QUERY’yi izleyin. Redshift Spectrum, Glue Veri Kataloğu aracılığıyla S3’teki harici tabloları sorgulamanıza olanak tanır. Harici şemayı şu komutla oluşturun:
CREATE EXTERNAL SCHEMA spectrum FROM DATA CATALOG DATABASE ’ext_db’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftSpectrumRole’ CREATE EXTERNAL DATABASE IF NOT EXISTS; Spectrum ve yerel Redshift için karar kriterleri:
S3’te depolanan, nadiren sorgulanan, büyük soğuk (cold) veriler veya katmanlı veri mimarileri için Spectrum kullanın.
Performans için sıkça join edilen sıcak (hot) veri setlerini Redshift içinde tutun; Spectrum ile join yaparken, join anahtarlarını aynı yerde toplamak için DISTKEY’ler seçin veya ağ I/O’sunu en aza indirmek için yeniden dağıtım kullanın.

Log analitiği için Amazon OpenSearch Service

OpenSearch, veri alımı (ingest) ve hızlı, anlık (ad-hoc) log analitiği için optimize edilmiştir; indeks ve küme yapılandırması, verim (throughput) ve maliyeti belirler. İndeks tasarımı ve yaşam döngüsü:

Kullanılabilirlik için index.number_of_shards (küçük indeksler: 1 shard; büyükler: ~10–50 GB boyutunda birden çok shard) ve index.number_of_replicas ayarlarını yapmak üzere logs-YYYY.MM.DD gibi indeks desenleri ve bir indeks şablonu kullanın.
Maliyet kontrolü için indeksleri hot, warm, cold ve UltraWarm katmanları arasında geçirmek üzere indeks yaşam döngüsü politikalarını (ILM) yapılandırın; UltraWarm, geçmiş veriler için hot node depolama maliyetlerini azaltır. Sharding ve replikalar, sorgu ve indeksleme performansını etkiler:
Daha fazla shard paralelliği artırır ancak ek yük getirir; node başına shard sayısını heap ve CPU’ya göre ayarlayın.
Replikalar okuma verimini ve hata toleransını iyileştirir; replika sayısını sorgu eşzamanlılığına ve SLA’ya göre ayarlayın. Operasyonel komutlar ve konsol desenleri:
İndeks şablonlarını ve ILM politikalarını PUT etmek için OpenSearch Dev Tools’u (veya curl’ü) kullanın ve küme sağlık API’leri ile izleyin. Hot-spotting’i önlemek için node nitelikleri atayın ve shard tahsis farkındalığını (shard allocation awareness) kullanın. Karar kriterleri:
Tarihsel loglar üzerindeki sorgu gecikmesi gereksinimleri, daha düşük depolama maliyeti karşılığında daha yüksek okuma gecikmesini tolere edebildiğinde UltraWarm’ı seçin.
Hızlı birleştirmeleri (aggregations) ve dashboard’ları desteklemek için güncel indeksleri hot node’larda tutun.

BI ve görselleştirme için QuickSight

QuickSight, iki ana veri alım moduyla hızlı dashboard’lar sunar: SPICE (bellek içi) ve doğrudan sorgu (direct query). SPICE, dashboard’lar için saniye altı performans sunar ve tekrarlanan okumalar için uygundur; doğrudan SQL sorguları (Athena, Redshift, RDS’e) ise çok büyük veri setleri veya sık değişen veriler için tercih edilir. Temel yapılandırma ve en iyi uygulamalar:

Konsolda veri setleri oluşturun: Yeni veri seti > Kaynak seçin (Athena/Redshift/RDS/OpenSearch) > SPICE’a aktar veya Doğrudan sorgu kullan.
Günlük/neredeyse gerçek zamanlı ihtiyaçlar için zamanlanmış SPICE yenilemelerini kullanın; veri hareketini sınırlamak için zaman damgası partition’laması ile artımlı yenilemeyi (incremental refresh) yapılandırın. Güvenlik ve yönetişim:
QuickSight kullanıcı/grup eşleştirmeleri ve veri seti kuralları aracılığıyla satır seviyesi güvenliği (row-level security) uygulayın.
Hesaplar arası veri erişimi için, QuickSight’ın üstleneceği (assume) IAM rolü ve kaynak tabanlı izinleri dağıtın. Karar kriterleri:
Çok sayıda eşzamanlı görüntüleyicisi olan ve öngörülebilir yenileme pencerelerine sahip dashboard’lar için SPICE kullanın.
Veri güncelliği kritik olduğunda veya SPICE kapasitesi kısıtlı olduğunda doğrudan sorgu kullanın; etkileşimli bir kullanıcı deneyimi (UX) için bunu hesaplanmış alanlar ve parametrelerle birleştirin.

Yaygın Hatalar ve Karar Kriterleri

Athena taranan veri başına ücret alır — taranan byte miktarını azaltmak için her zaman sorgu koşullarına (query predicates) göre bölümleme (partition) yapın ve verileri sıkıştırılmış (Snappy/Zlib) sütun bazlı formatlarda (Parquet/ORC) saklayın.
Düşük kardinaliteli bir sütunda Redshift DISTKEY kullanmak veri çarpıklığına (data skew) neden olur — DISTKEY için yüksek kardinaliteli join anahtarları seçin veya küçük boyut (dimension) tabloları için DISTSTYLE ALL kullanın.
Redshift Spectrum harici (external) tabloları Glue Data Catalog’u gerektirir — hedef bölgede Glue’nun etkinleştirildiğinden ve IAM rollerinin Redshift’in kataloğa erişmesine izin verdiğinden emin olun.
OpenSearch shard sayısı ve boyutlandırma hataları — çok fazla küçük shard’dan kaçının; shard’ları on’larca GB boyutunda olacak şekilde ayarlayın ve maliyet tasarrufu için eski indeksleri UltraWarm’a taşımak üzere ILM kullanın.
Toplu yüklemelerden sonra Redshift üzerinde RUN ANALYZE/VACUUM çalıştırmayı unutmak — optimum sorgu planları için istatistikleri yenilemek ve disk alanını geri kazanmak üzere ANALYZE ve VACUUM komutlarını zamanlayın.
QuickSight SPICE kapasite aşımı ve eski (stale) veri — SPICE kapasitesini planlayın, artımlı yenilemeler (incremental refreshes) kullanın veya gerçek zamanlı ihtiyaçlar için doğrudan sorgu (direct query) moduna geçin.

Pratik Problem: Kullanım Senaryosu

Acme Retail’in, Amazon RDS’teki işlem (transactional) siparişlerini, S3’teki tıklama akışı (clickstream) olaylarını ve DynamoDB’deki kullanıcı profillerini birleştiren günlük BI raporlarına ihtiyacı vardır. Bu raporlar, maliyet sınırları dahilinde kalmalı ve son veriler için bir dakikanın altında dashboard yenilemeleri sağlamalıdır.

S3’teki tıklama akışı (clickstream) verilerini tarih bazlı bölümlenmiş (partitioned) Parquet formatına dönüştürün, Snappy ile sıkıştırın ve bir crawler aracılığıyla meta verileri AWS Glue’ye kaydedin.
S3 üzerindeki anlık (ad-hoc) sorgular için Athena’yı kullanın ve küçük boyutlu (small-dimension) join işlemleri yapmak üzere RDS ile DynamoDB için Federated Query bağlayıcılarını (connectors) dağıtın; sorgular tekrarlanıyorsa, sık yapılan join sonuçlarını Parquet olarak somutlaştırın (materialize).
Yoğun analitik join işlemleri için Redshift’i provizyonlayın: toplulaştırılmış anlık görüntüleri (snapshots) Redshift’e yükleyin, yüksek kardinaliteli customer_id üzerinde DISTKEY ayarlayın ve order_date üzerinde SORTKEY tanımlayın; S3’teki soğuk (cold) geçmiş veriler için Spectrum kullanın.
Uygulama loglarını günlük indeks desenleriyle (daily index patterns) OpenSearch’e alın (ingest); son indeksleri hot node’larda tutmak ve maliyet tasarrufu için eski indeksleri UltraWarm’a taşımak üzere ILM uygulayın.
QuickSight dashboard’ları oluşturun: bir dakikanın altında algılanan yanıt süresi için son toplulaştırılmış verileri zamanlanmış artımlı yenilemelerle (incremental refreshes) SPICE’a aktarın ve her zaman güncel (fresh) metrikler için doğrudan sorguları (direct queries) kullanın.

Gerekçe: Bu yaklaşım, bölümleme (partitioning) ve sütun bazlı formatlar aracılığıyla Athena tarama maliyetlerini en aza indirir, uygun dağıtım (distribution) ve sıralama (sort) anahtarlarıyla Redshift ağındaki veri karışıklığını (network shuffle) azaltır, Redshift’te soğuk (cold) veri depolamaktan kaçınmak için Spectrum’u kullanır, depolama maliyetini optimize etmek için OpenSearch ILM’yi uygular ve doğrudan sorgular (direct queries) aracılığıyla kritik güncelliği korurken hızlı yanıt veren dashboard’lar için SPICE’tan yararlanır.

← Veri Orkestrasyonu ve İş Akışı Yönetimi · Tüm alanlar · Veri Güvenliği →

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