Amazon SAA-C03: Analitik, Veri Gölü, ML ve Özelleştirilmiş İş Yükleri — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz ç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.

Veri Gölü Temelleri: Lake Formation ve Glue Data Catalog

AWS analitiğinin ağırlık merkezi, Athena, Redshift Spectrum, EMR ve Glue ETL’in tümünün kullandığı, Hive-metastore uyumlu bir meta veri deposu olan AWS Glue Data Catalog’dur. Her tablo tanımı, bölüm (partition), sütun türü ve SerDe yapılandırması burada yaşar ve alt akıştaki her motor buradan okur. Eğer iki farklı veri alım yolu (örneğin, bir Glue crawler ve manuel bir CREATE EXTERNAL TABLE ifadesi) aynı S3 ön eki (prefix) için farklı şemalar üzerinde anlaşmazlığa düşerse, sorgular sessizce yanlış sonuçlar döndürür veya başarısız olur. Doğru desen, her tablo için tek bir yetkili belirlemektir: ya şema crawler’a aittir ya da ETL işiniz glueContext.write_dynamic_frame.from_catalog aracılığıyla yazar, ancak bir birleştirme stratejisi olmadan asla ikisi birden olmaz. Toplu ETL, Firehose Parquet dönüşümü ve manuel DDL’in hepsi aynı tabloya yazdığında, katalog kayması (catalog drift) sessiz katildir. Her tablo için tek bir sahip zorunluluğu getirin, akış (streaming) üreticileri için Glue Schema Registry’yi kullanın ve ETL işlerinin sahip olduğu tablolarda crawler’ları UPDATE_IN_DATABASE modunda değil, LOG modunda çalıştırın. Böylece düzenlenmiş şemaların üzerine yazmadan kaymayı ortaya çıkarırlar.

AWS Lake Formation, Data Catalog’un üzerinde yer alır ve kaba taneli IAM/S3 bucket policy modelini veritabanı tarzı bir izin katmanıyla değiştirir. Bir ön ek (prefix) üzerinde s3:GetObject izni vermek yerine, GRANT SELECT ON customers.orders TO role/AnalystRole şeklinde izin verirsiniz ve Lake Formation, Athena veya Redshift Spectrum altta yatan nesnelere dokunduğunda şeffaf bir şekilde kısa ömürlü kimlik bilgileri sağlar. Asıl değeri, ince taneli yetkilendirmedir: sütun düzeyinde filtreleme, veri filtreleri aracılığıyla satır düzeyinde güvenlik ve binlerce tabloya ölçeklenen etiket tabanlı erişim kontrolü (LF-Tags). customers tablosunda Kişisel Tanımlanabilir Bilgi (PII) bulunan bir perakende platformu, analistlere customer_id, region, signup_date sütunlarına erişim izni verirken email ve ssn gibi sütunları engelleyebilir — bu, sorgu zamanında uygulanır ve view’ların çoğalmasına gerek kalmaz.

Yönetişimli bir göl (governed lake) için standart kurulum:

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Lake Formation blueprint’leri, JDBC kaynaklarından veya S3’ten verileri düzenlenmiş bir göle almak için crawler’ları, job’ları ve trigger’ları bir araya getiren önceden oluşturulmuş iş akışı şablonlarıdır. Bu, normalde manuel olarak bağlanması gereken onlarca Glue kaynağını sihirbaz güdümlü bir akışa indirger.

Sık yapılan bir hata, sütun düzeyindeki kısıtlamaları yalnızca QuickSight’ta uygulamaya çalışmaktır. QuickSight’ın veri setlerine bağlı satır ve sütun düzeyinde güvenliği vardır, ancak bu yalnızca QuickSight arayüzünü korur — doğrudan Athena veya S3 erişimi olan herkes bunu atlar. Sütun düzeyindeki kontrol, veri katmanında (Lake Formation izinleri veya ETL sırasında sütunların fiziksel olarak ayrılması) uygulanmalı ve QuickSight, IAM rolü aracılığıyla bu duruşu devralır.

Athena: S3 Üzerinde Sunucusuz SQL

Athena, doğrudan Amazon S3’ten okuyan sunucusuz, sorgu başına ödeme yapılan bir Presto/Trino motorudur. Sağlanacak bir küme yok, sorgulamadan önce ETL adımı gerekmiyor ve boşta kaldığında maliyet yok — yalnızca taranan bayt başına ödeme yaparsınız (genellikle $5/TB). Bu, Athena’yı S3’te halihazırda bulunan dosyaların (JSON uygulama logları, CSV dışa aktarımları veya Parquet fact tabloları olsun) geçici (ad-hoc) analizleri için standart seçim haline getirir. Athena’nın bir şemaya ve bölüm (partition) düzenine ihtiyacı vardır ve bu bilgiler Glue Data Catalog’da bulunur.

Athena taranan terabayt başına faturalandırma yaptığı için, depolama formatının maliyet ve gecikme üzerinde orantısız bir etkisi vardır. İki temel kaldıraç format ve bölümlemedir (partitioning):

• Sütun bazlı formatlar (Parquet, ORC), Athena’nın sütunları ve satır gruplarını ayıklamasına (prune) olanak tanır. Parquet üzerinde SELECT sum(amount) FROM orders WHERE region='us-east-1' gibi bir sorgu yalnızca başvurulan iki sütunu okur; CSV’de ise her satırın her baytını okur.
• Yüksek seçiciliğe sahip sütunlar üzerinde bölümleme (örneğin, dt=2024-03-11/), tam tablo taramasını hedeflenmiş bir okumaya indirger. Çok terabaytlık loglarda (CloudFront, ALB, VPC Flow Logs), bu, 0,15 dolarlık bir sorgu ile 30 dolarlık bir sorgu arasındaki fark demektir.

Ham JSON veya CSV’yi bölümlenmiş, Snappy ile sıkıştırılmış Parquet’e dönüştürmek, neredeyse her zaman maliyetleri düşürmek için çekilecek ilk maniveladır. LIMIT pushdown ile birleştiğinde, Athena S3 üzerindeki çoğu analitik ihtiyacını sıfır altyapı ile karşılar.

Bölümlenmiş Parquet olarak depolanan bir “okumalar” (readings) tablosu için maliyet etkin bir desen:

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Crawler’ı atlamak sık yapılan bir hatadır. Bir katalog girişi olmadan, ya manuel CREATE EXTERNAL TABLE DDL yazarsınız (şemalar geliştikçe kırılgan hale gelir) ya da her dosyayı tarayan okuma anında şema (schema-on-read) hileleri kullanırsınız. Daha da kötüsü, MSCK REPAIR TABLE veya partition projection olmadan, Athena her sorguda tüm ön eki (prefix) tarar. Glue crawler’ları yeni bölümleri (partition) belirli bir program dahilinde tespit eder ve kataloğu atomik olarak günceller.

Şifrelenmiş S3 verileri üzerinde Athena. Athena, SSE-S3, SSE-KMS ve CSE-KMS’i destekler, ancak yalnızca çağıranın doğru KMS izinlerine sahip olması ve workgroup’un veya istemcinin kullanımda olan şifreleme modu için yapılandırılmış olması koşuluyla. CSE-KMS için, dosya yüklemeden önce istemci tarafında şifrelenir; sorguyu çalıştıran IAM principal’ının CMK üzerinde kms:Decrypt ve kms:GenerateDataKey izinlerine ihtiyacı vardır ve anahtar politikasının da bu izni karşılıklı olarak vermesi gerekir. Yaygın bir hata modu: CSE-KMS ile şifrelenmiş Parquet’i yüklemek, Athena rolüne yalnızca S3 okuma izinleri vermek ve ardından anlaşılmaz AccessDenied veya HIVE_CANNOT_OPEN_SPLIT hataları almaktır — nesne okunabilir ancak şifreli metin (ciphertext) çözülemez. Sık yapılan bir diğer hata, tabloyu yanlış şifreleme moduyla kaydetmektir (nesneler CSE-KMS ile yazılmışken tablo özelliklerinde SSE-KMS belirtmek); Athena, GetObject sırasında sunucu tarafında şifre çözmeyi dener ve gelen yük, Parquet sihirli sayı (magic-number) kontrollerinde başarısız olan ham şifreli metin (raw ciphertext) olarak geri döner.

Athena birleşik sorguları (federated queries), S3 verilerini operasyonel depolarla (DynamoDB, RDS) veri taşımadan birleştirmenize olanak tanır. Athena’yı okuma odaklı, geçici (ad-hoc) analizler için ayırın; düzenlenmiş bölgelerin (curated zones) zamanlanmış olarak şekillendirilmesi için Glue job’larını kullanın.

Glue Tarayıcıları, ETL İşleri ve İş Yer İmleri

Glue tarayıcıları S3 yollarını tarar, şemayı (year=2024/month=01/ gibi dizin yapısından bölümleme anahtarları dahil) tahmin eder ve katalogda tabloları kaydeder veya günceller. Bunlar, “S3’e dosya bırakıyoruz, onları sorgulanabilir hale getir” sorusuna verilen düşük kodlu (low-code) yanıttır. Bir başlangıç bucket’ına karşı saatlik bir tarayıcı zamanlayın ve Athena yeni bölümleri anında görür.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Glue ETL işleri (Spark, Python shell veya Ray) dönüşüm kısmını halleder. Glue sunucusuzdur — bir dakikalık minimum ücretle DPU-saat başına ödeme yaparsınız — ve çalışma zamanı (runtime) çalışanları (worker) otomatik olarak ölçeklendirir. Baskın model, CSV/JSON girdisi ve bölümlenmiş Parquet çıktısıdır:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

Kritik operasyonel özellik iş yer imidir (job bookmark): Glue, hangi dosyaları veya bölümleri daha önce işlediğine dair durumu kalıcı hale getirir, böylece sonraki çalıştırmalar yalnızca yeni verileri okur. Yer imlerini etkinleştirmeyi unutmak, her çalıştırmanın tüm veri setini baştan yeniden işlemesi, maliyeti ve çalışma süresini doğrusal olarak artırması ve genellikle yinelenen çıktılar üretmesi anlamına gelir. Yer imleri iş başına etkinleştirilir ve onları destekleyen kaynak seçenekleriyle eşleştirilmelidir (Glue DynamicFrame okuyucusu aracılığıyla S3 kaynakları destekler; rastgele Spark okumaları desteklemez). Yer imleri, her kaynakta bir transformation_ctx argümanı ve job.init(...) / job.commit() sarmalaması gerektirir:

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

Hiçbir mantık içermeyen saf format dönüştürme için, en az çaba gerektiren seçenek genellikle ham veri üzerinde bir Glue tarayıcısı ve görsel düzenleyicide yazılmış bir Glue işidir (veya bir DataBrew tarifidir) — Spark kodu gerekmez. Özel EMR kümeleri veya Lambda dönüştürücüleri, Glue’nun sunucusuz modelinin ortadan kaldırdığı operasyonel ek yükü getirir.

S3 verilerini düzenleyen ve Redshift Serverless’a yükleyen tipik bir günlük iş:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue Güvenlik Yapılandırmaları ve Çok Kiracılı (Multi-Tenant) ETL

Glue tarayıcıları ve işleri, Athena ile aynı şifreleme farkındalığına ihtiyaç duyar. Glue güvenlik yapılandırmaları, S3 hedeflerinin, CloudWatch günlüklerinin ve iş yer imlerinin nasıl şifreleneceğini belirten — belirli bir CMK ile CSE-KMS dahil — isimlendirilmiş paketlerdir. Bir güvenlik yapılandırmasına eklenmiş bir iş, işin IAM rolünün başvurulan anahtarlar üzerinde KMS izinlerine sahip olması koşuluyla, CSE-KMS girdisinin şifresini şeffaf bir şekilde çözer ve çıktıları aynı şekilde şifreler.

Çok kiracılı ETL için — her müşterinin verisini o müşterinin CMK’si ile işleyen bir SaaS platformu — doğru model, müşteri başına bir güvenlik yapılandırması (veya CMK’yi seçen bir iş parametresi) artı o CMK’ye göre kapsamı belirlenmiş bir IAM rolüdür. Her müşteriyi tek bir paylaşılan anahtarla tek bir iş üzerinden çalıştırmak, CSE-KMS’in sağlamayı amaçladığı yalıtım garantisini boşa çıkarır.

İlgili bir disiplin: üretim analitik tabloları, keşif amaçlı Glue işlerinin veya not defterlerinin doğrudan hedefi olmamalıdır. Bir anlık görüntüyü (snapshot) bir S3 “analytics” ön ekine dışa aktarın ve Athena veya Spark’ı kopyaya yönlendirin. Canlı tablo üzerinde deneysel dönüşümler çalıştırmak, bölüm düzeyinde yeniden yazma, yer imi bozulması ve kilit çekişmesi riskleri taşır ve operasyonel veriler ile analitik türevler arasındaki denetim sınırını bulanıklaştırır.

AWS Glue DataBrew

DataBrew, Spark yazamayan veya yazmaması gereken kullanıcılar için Glue’nun düşük kodlu (low-code) kardeşidir. 250’den fazla önceden oluşturulmuş dönüşüm (eksik veri tamamlama (imputation), PII maskeleme, aykırı değer gruplama (outlier binning), tarih ayrıştırma) içeren, e-tablo tarzı bir kullanıcı arayüzü sunar. Ayırt edici özellikleri, yayınlayabileceğiniz ve projeler arasında yeniden uygulayabileceğiniz sürümlenmiş JSON yapıları olan paylaşılan tarifler (shared recipes) ve kaynak veri setlerinden tarifler ve işler aracılığıyla çıktı konumlarına kadar sütunları izleyen veri kökeni görselleştirmesidir (data lineage visualization). Dönüşüm mantığının sahibi analistler olduğunda DataBrew’u seçin; sahibi mühendisler olduğunda ve işlem hattının (pipeline) özel kod, akış (streaming) veya karmaşık birleştirmelere (join) ihtiyacı olduğunda Glue Studio/betikleri seçin.

Amazon EMR: Dağıtık Toplu İşlem (Batch) ve Çalışma Zamanı Rolleri

Amazon EMR, Spark, Hadoop, Hive, Presto, HBase ve Flink çalıştıran yönetilen bir küme platformudur. En etkili olduğu alan, petabayt ölçeğindeki S3 veri setlerini okuyan ve zenginleştirme için bunları başka bir kayıt sistemine (genellikle Redshift) karşı birleştiren büyük, paralelleştirilebilir toplu veya etkileşimli iş yükleridir. EMR, geçici kümeler (başlat, yürüt, sonlandır) veya uzun süreli çalışan kümeler çalıştırabilir ve örnek filoları (instance fleets) aracılığıyla On-Demand, Spot ve Reserved örneklerini karıştırabilir.

Kanonik bir model: bir Spark işi S3’ten Parquet okur, UNLOAD-to-S3 aracılığıyla Redshift’ten boyut tablolarını çeker, bunları yürütücüler (executor) arasında birleştirir ve zenginleştirilmiş çıktıyı tekrar S3’e yazar:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR burada kazanır çünkü Spark birleştirmeyi (join) düzinelerce düğüme dağıtır ve S3 üzerinden hazırlama (staging), tek iş parçacıklı (single-threaded) bir JDBC darboğazını önler. Tuzak, S3 verilerinin sorgulanması gerektiğinde refleks olarak EMR’a yönelmektir. Onlarca veya yüzlerce gigabayt üzerindeki anlık (ad-hoc) SQL sorguları için bir Spark kümesi sağlamak ve ayarlamak tamamen operasyonel bir ek yüktür — küme boyutlandırma, YARN yapılandırması, otomatik ölçeklendirme, günlük rotasyonu, yama yönetimi. EMR, yalnızca hacim, özel kod veya yürütme motoru esnekliği bunu haklı çıkardığında masrafını karşılar.

EMR çalışma zamanı rolleri. Geçmişte, bir kümedeki tüm adımlar EC2 örnek profilini — alttaki düğümlere eklenmiş tek bir rol — miras alırdı, bu da bir kümeyi paylaşan her ekibin, herhangi bir ekibin ihtiyaç duyduğu tüm izinlerin birleşimine sahip olduğu anlamına geliyordu. Çalışma zamanı rolleri bunu çözer: bir kullanıcı bir adım gönderdiğinde --execution-role-arn parametresini geçer ve EMR, adımın süresi boyunca o rolü üstlenir (assume). A Takımı s3://team-a/* ile, B Takımı ise s3://team-b/* ile kısıtlanabilir. Örnek profili, yalnızca küme yapılarını (artifact) getiren ince bir başlangıç (bootstrap) rolü haline gelir.

Çalışma zamanı rolleri aynı zamanda IMDS erişimini engelleme mekanizmasıdır. Etkinleştirildiğinde (YARN üzerinde Spark/Hive ile EMR 6.7+), platform bu çağrıları engellediği için kullanıcı kodu örnek meta veri hizmetine (instance metadata service) — IMDSv2 dahil — ulaşamaz. Bu, bir işin aksi takdirde http://169.254.169.254/latest/api/token adresini çağırıp güçlü EC2 örnek profilini üstlenebileceği yetki yükseltme yolunu kapatır.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

Güvenlik yapılandırması, çalışma zamanı rolü zorlamasını ve IMDS engellemeyi sağlayan şeydir. Bu olmadan, EMR iş yüklerinin “otomatik olarak en az ayrıcalıklı rolleri kullandığını” varsaymak yanlıştır — varsayılan olarak örnek profilini paylaşırlar ve IMDS’ye kullanıcı kodundan erişilebilir.

Amazon Redshift ve Redshift ML

Redshift, saniyenin altında pano performansı, milyarlarca satır üzerinde karmaşık join işlemleri ve eş zamanlı BI kullanıcıları altında tutarlı gecikme süresi gerektiren sürekli analitik iş yükleri için tasarlanmış, sütun tabanlı bir MPP veri ambarıdır. RA3 düğümleri, işlem gücünü yönetilen depolamadan ayırır; Redshift Serverless, yapılandırılmış bir temel kapasiteye göre RPU-saniye cinsinden faturalandırılır, yük altında ölçeklenir ve boşta kaldığında duraklayarak geleneksel küme boyutlandırma sorununu ortadan kaldırır.

Redshift, analitik işlem hatlarında iki zenginleştirme modunda yer alır:

• Kaynak olarak: EMR üzerindeki Spark, UNLOAD-to-S3 aracılığıyla boyutları çeker veya Glue, Redshift Data API aracılığıyla okuma yapar.
• Hedef olarak: Firehose veya bir Glue işi, zenginleştirilmiş verileri COPY komutuyla içeri aktarır.

Redshift Spectrum, Redshift SQL’in doğrudan Glue Data Catalog aracılığıyla S3’ü sorgulamasına olanak tanıyarak bu yapıyı genişletir. Bu, Athena’nın da kullandığı aynı katalogdur ve lake-house mimarisini çalıştıran da budur. Halihazırda bir Redshift kümeniz varsa ve ambarlanmış olgu (fact) verilerini, veriyi taşımadan soğuk S3 geçmiş verileriyle birleştirmek istediğinizde idealdir.

Toplu yüklemeler, işlem düğümleri arasında paralelleştirilmiş şekilde S3’ten COPY komutunu kullanır; paralellik için dosyalar kabaca eşit parçalara (slice sayısının bir katı) bölünmelidir:

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

Akış tabanlı veri alımı, genellikle sıfır operasyonlu teslimat için Firehose (arabelleğe alınmış COPY) üzerinden akar.

Redshift ML, SQL kullanıcılarının CREATE MODEL aracılığıyla modeller oluşturmasına, eğitmesine ve çağırmasına olanak tanır:

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

Arka planda Redshift, eğitim setini S3’e dışa aktarır, SageMaker Autopilot’ı (veya XGBoost gibi belirtilen bir algoritmayı) çağırır ve derlenmiş modeli veritabanı içi çıkarım (inference) için içe aktarır. Analistlerin zaten SQL içinde çalıştığı durumlar için güçlü bir araçtır, ancak tam teşekküllü bir ML platformunun yerini tutmaz: S3’e veri taşıma ve SageMaker eğitim işlem gücü ayrı olarak faturalandırılır, büyük eğitim setleri önemli miktarda dışa veri aktarım (egress) ve Autopilot çalışma zamanı ücretleri oluşturabilir ve özellik depoları (feature stores), deney takibi (experiment tracking) veya A/B dağıtımı için yerleşik bir iş akışı yoktur. Redshift ML’i, genel amaçlı bir eğitim aracı olarak değil, Redshift verileri üzerinde demokratikleştirilmiş bir çıkarım aracı olarak görün.

Athena ve Redshift Arasında Seçim Yapma

Akış Tabanlı Veri Alımı: Kinesis Data Streams, Firehose ve MSK

Bu üç AWS akış hizmeti, birbiriyle kesişen sorunları birbirinden önemli ölçüde farklı garantilerle çözer:

Kinesis Data Streams, shard’lar (veya isteğe bağlı mod) kullanır; aynı bölüm anahtarına (partition key) sahip kayıtlar aynı shard’a düşer ve sırayla tüketilir. Tüketiciler, klasik GetRecords veya Enhanced Fan-Out (her tüketici için ayrılmış 2 MB/sn) kullanır. Bir olay kaynağı olarak eklenen bir Lambda işlevi, shard başına toplu verilerle çağrılır ve bu da sırayı korur. Bu, alt sistemlerdeki mantığın basit olmadığı, birden fazla bağımsız tüketicinin geçmişi tekrar oynatması gerektiği veya tıklama akışı (clickstream) hacimlerinin çok büyük olduğu durumlarda doğru seçimdir — örneğin, günde 30 TB veri üreten bir site, veriyi KDS üzerinden Firehose’a akıtır ve Athena/Spectrum analizi için S3’e indirir.

Kinesis Data Firehose, ‘ateşle ve unut’ tarzı yönetilen bir teslimat hizmetidir: verileri boyuta veya zamana göre (ör. 5 MB / 300 saniye) arabelleğe alır, dönüşüm için isteğe bağlı olarak bir Lambda’yı çağırır, isteğe bağlı olarak bir Glue tablosunun şemasını kullanarak JSON’u Parquet/ORC’ye dönüştürür ve S3, Redshift (S3 + COPY aracılığıyla), OpenSearch veya Splunk’a yazar. Firehose’da Parquet dönüşümünü etkinleştirmek, akış verilerini alt bir Glue işine gerek kalmadan sorgu için optimize edilmiş formatta indirmenin en zahmetsiz yoludur:

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose’un uçtan uca sıralama garantisi yoktur, birden fazla tekrar oynatılabilir tüketiciyi destekleyemez ve hedefleri sabit havuzlardır (sink). Gereksinimin “her kaydı sırayla işle” veya “birden fazla bağımsız tüketici” dediği durumlarda Firehose’u seçmek her iki açıdan da yanlıştır. Benzer şekilde, yalnızca Firehose’un karmaşık dönüşümler yapmasını beklemek bir tuzaktır — tek dönüşüm kancası, arabelleğe alınan her toplu veri için çağrılan bir Lambda’dır. Harici zenginleştirme, çoklu kayıt toplama (aggregation) veya koşullu yönlendirme içeren her şey o Lambda’da yaşamalı veya yukarı akışta Managed Service for Apache Flink’e taşınmalıdır.

Amazon MSK, yönetilen bir Apache Kafka hizmetidir. Halihazırda Kafka üreticileriniz/tüketicileriniz olduğunda, Kafka’ya özgü özelliklere (sıkıştırılmış topic’ler, işlemler, Kafka Streams, Connect) ihtiyaç duyduğunuzda veya shard tabanlı Kinesis’in rahatça sunabileceğinin ötesinde bir verim (throughput) gerektirdiğinizde bu hizmeti seçin.

Analitik veri alım yolu olarak SQS veya EventBridge kullanmak bir hatadır: SQS, akış başına sıralı değildir ve tekrar oynatma özelliğinden yoksundur; EventBridge ise sürekli MB/sn’lik veri alımı için değil, olay yönlendirme için optimize edilmiştir.

Gerçek Zamanlı Arama: KDS + Firehose + OpenSearch + QuickSight

Şirket içi (on-premises) bir Elasticsearch+Logstash yığınının standart AWS karşılığı şöyledir:

Firehose, akış kayıtlarını arabelleğe alır ve doğrudan bir OpenSearch domain’ine teslim eder; bu sırada yeniden deneme, S3 yedeklemesi ve isteğe bağlı Lambda dönüşümü gibi işlemleri yönetir. OpenSearch Dashboards, domain ile birlikte gömülü ve ücretsiz olarak gelir ve gerçek zamanlı akışları izleyen operatörler için uygundur. QuickSight, iş odaklı analitik için bunu tamamlar — doğrudan Athena, Redshift, RDS ve OpenSearch’ü sorgular ve SPICE bellek içi sütun tabanlı motoru, saniyenin altında pano performansı için işlenmiş veri kümelerini önbelleğe alır.

Tipik bir görev dağılımı şöyledir: Operatörler için OpenSearch Dashboards; Athena/Glue veri gölünden (lake) beslenen, toplanmış ve derlenmiş veri kümelerini kullanan yöneticiler için QuickSight. Her ikisine de IAM okuma erişimi ve uygun durumlarda, temel depolamayı koruyan CMK’ler üzerinde KMS Decrypt izni verilmelidir — aksi takdirde görselleştirme katmanı, sorgu günlüklerine gömülü izin hatalarıyla birlikte boş paneller oluşturur.

QuickSight Erişim Kontrolü

QuickSight önce veri kümeleri (datasets) (mantıksal sorgular artı hesaplanmış alanlar ve satır seviyesi güvenlik), ardından veri kümeleri üzerine analizler (analyses) oluşturur ve son olarak panoları (dashboards) (salt okunur paylaşılabilir görünümler) yayınlar. Erişim kontrolü katmanlıdır ve doğru katmanda uygulanmalıdır. Buradaki tuzak, temel verileri yalnızca bir alt kümenin görmesi gerekirken, pano düzeyinde geniş erişim izni vermektir — örneğin, tüm kuruluşu kapsayan bir grupla paylaşım yapmak gibi.

QuickSight’ta en az ayrıcalık ilkesi (least privilege) şunları ifade eder:

• Veri kümesini yalnızca ihtiyaç duyan kullanıcılar/gruplarla paylaşın.
• Satırları kullanıcı adına veya gruba göre filtreleyen bir izin veri kümesi aracılığıyla satır seviyesi güvenlik uygulayın.
• Hassas alanları gizlemek için sütun seviyesi güvenlik uygulayın.
• Panoları belirli kullanıcılar, gruplar veya (gömülü analitik için) ad alanları (namespaces) ile paylaşın.

Bir panoyu herkese açık hale getirmek veya hesap genelinde paylaşmak, veri kümesi düzeyindeki kontrollerin amacını boşa çıkarır, çünkü pano görüntüleyenler, temel kaynak izinlerinden bağımsız olarak görselleştirilen verilere okuma erişimini devralır. Unutmayın ki QuickSight sütun seviyesi güvenlik yalnızca QuickSight arayüzünü korur; doğrudan Athena veya S3 erişimi olan herkes bunu atlayabilir, bu nedenle hassas kontroller yalnızca QuickSight’ta değil, Lake Formation veya ETL’de yer almalıdır.

QuickSight rolleri — Admin, Author, Reader — bir kullanıcının ne yapabileceğini kontrol eder ve ne görebileceğini kontrol eden paylaşım izinlerinden farklıdır. Bir Reader, bir Author lisansına göre daha düşük bir oturum başına maliyetle tüketim yapar, bu nedenle görüntüleyici kitleleri varsayılan olarak Reader olmalı ve erişim, bireysel atama yerine grup üyeliği aracılığıyla verilmelidir.

Grafik (Graph) İş Yükleri için Amazon Neptune

Neptune, özellik grafiği (property-graph) modelini (Gremlin, openCypher) ve RDF’yi (SPARQL) destekleyen, yönetilen bir grafik veritabanıdır. İlişkisel bir veritabanında tekrarlayan (recursive) join işlemlerinin çok maliyetli hale geldiği, yüksek düzeyde bağlantılı veriler — sosyal ilişkiler, dolandırıcılık ağları, bilgi grafikleri, öneri motorları — için özel olarak oluşturulmuştur. Kullanıcılar, takipler, beğeniler ve gönderiler içeren bir sosyal platform, doğal olarak düğümlere (vertices) ve kenarlara (edges) eşlenir ve Neptune, çok adımlı geçişlere (“X’i beğenen arkadaşların arkadaşları”) milisaniyeler içinde yanıt verir.

Neptune Streams, grafikteki her değişikliğin (mutation) sıralı, zaman tabanlı bir günlüğünü sunar. Akışı yoklayan (polling) bir Lambda veya uygulama, özel bir değişiklik verisi yakalama (change-data-capture) ardışık düzenine (pipeline) ihtiyaç duymadan değişikliklere tepki verebilir — önerileri yeniden hesaplayabilir, bir arama indeksini güncelleyebilir, dolandırıcılık uyarılarını tetikleyebilir. Bunu Aurora veya DynamoDB üzerinde yeniden oluşturmak, uygulama düzeyinde grafik geçişi (graph traversal) artı ayrı bir CDC altyapısı gerektirir. Problem tanımı hem “ilişkileri analiz et” hem de “değişiklikleri izle” ifadelerini içerdiğinde, Neptune Streams ile birlikte Neptune en doğru çözümdür.

SageMaker: Uçtan Uca Özel Makine Öğrenmesi (ML)

SageMaker, tüm yaşam döngüsünü sağlar: Studio not defterleri, yönetilen eğitim işleri (spot desteği ile), Model Registry, gerçek zamanlı ve sunucusuz uç noktalar (endpoints), toplu dönüşüm (batch transform) ve MLOps için Pipelines. Tipik bir akışta, eğitim verileri S3’e yüklenir, yerleşik bir algoritma veya özel bir container belirtilerek bir eğitim işi başlatılır ve SageMaker geçici (ephemeral) sunucuları tedarik eder, günlükleri CloudWatch’a akıtır ve model artefaktını tekrar S3’e yazar. Dağıtım, tek bir API çağrısıdır:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Yönetilmesi gereken Kubernetes, GPU sürücüsü veya model sunucusu yoktur. Gereksinimi “bir model eğitmek ve kullanıma sunmak” olan ekipler için SageMaker, kendi ECS/EC2 çıkarım (inference) çözümünü oluşturmaya kıyasla neredeyse her zaman en az ek yük getiren yanıttır.

SageMaker Savings Plans, uygun bileşenler (Studio, eğitim, işleme, gerçek zamanlı çıkarım) genelinde 1 veya 3 yıl boyunca saat başına dolar cinsinden bir harcama taahhüdü vererek, isteğe bağlı (on-demand) fiyatlara göre %64’e varan indirim sağlar. Bu planlar sunucu ailesi, boyutu, bölgesi ve bileşeni arasında esnektir — ancak Ground Truth, depolama veya veri transferini kapsamazlar. Temel ML kullanımı öngörülebilir olduğunda Savings Plans kullanın; anlık yoğun eğitim (burst training) işlerini spot sunucularda (spot instances) bırakarak tasarrufları katlayın.

Yönetilen Yapay Zeka Hizmetleri ve Özel ML Karşılaştırması

Amazon Rekognition (görüntüler/video: nesne ve sahne tespiti, yüz analizi, denetleme), Textract (OCR artı form ve tablo çıkarma) ve Comprehend (NLP: varlık tanıma, duygu analizi, PII tespiti, özel sınıflandırma) gibi hizmetler, önceden eğitilmiş modelleri basit API’ler aracılığıyla sunar. Comprehend’in DetectEntities işlevi, COMMERCIAL_ITEM kategorisi de dahil olmak üzere tiplendirilmiş varlıkları döndürür. Bu, bir yemek tarifi metninden malzeme adlarını çekmek ve bir DynamoDB aramasını beslemek için mükemmeldir; hem de eğitim verisi olmadan, barındırma gerektirmeden ve istek başına ödeme fiyatlandırmasıyla:

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

Yaygın bir hata modu, yönetilen bir hizmetin gereksinimi çok daha düşük bir operasyonel maliyetle zaten karşıladığı durumlarda aşırı mühendislik yapmaktır — yani SageMaker eğitim işleri başlatmak, Ground Truth ile verileri etiketlemek ve uç noktaları barındırmak. Özel ML yalnızca alana özgü verilerdeki doğruluğun maddi olarak daha yüksek olduğu, ihtiyaç duyulan varlık türlerinin yönetilen şemayla eşleşmediği (Comprehend Custom Classification/Entity Recognition ham SageMaker’dan yine de daha ucuzdur) veya gecikme ve veri yerleşimi kısıtlamalarının özel bir model gerektirdiği durumlarda haklı çıkar.

HPC Depolama ve Ağ İletişimi: FSx for Lustre ve EFA

Sıkı sıkıya bağlı HPC iş yükleri — CFD, moleküler dinamik, sismik görüntüleme, büyük ölçekli eğitim — iki adet pazarlık edilemez gereksinime sahiptir: düğümler arası son derece düşük gecikmeli iletişim ve yüksek verimli paylaşılan depolama.

Elastic Fabric Adapter (EFA), belirli EC2 ailelerinde (hpc7a, hpc6id, c6in, p4d/p5, diğerleri) kullanılabilen bir ağ arabirimidir. OS-bypass Libfabric kullanarak çekirdek TCP/IP yığınını atlar ve MPI ile NCCL’nin yüzlerce düğüm arasında mikrosaniye düzeyinde gecikmelere ulaşmasını sağlar. EFA, aynı Kullanılabilirlik Alanı’nda (Availability Zone) bulunan ve maksimum bant genişliği için bir küme yerleşim grubunda (cluster placement group) yer alan EC2’ler gerektirir.

FSx for Lustre, saniyede yüzlerce GB’lık aktarım hızı ve milisaniyenin altında gecikme süresi sunan yönetilen bir paralel dosya sistemidir. S3 ile yerel olarak entegre olur: bir FSx dosya sistemi bir bucket’a bağlanabilir, böylece nesneler POSIX dosyaları olarak görünür ve Lustre’a yazılan sonuçlar tekrar S3’e aktarılabilir. Kalıcı (Persistent) SSD dağıtımları uzun ömürlü geçici depolama (scratch) için uygundur; Scratch2 ise geçici (ephemeral) iş verileri için daha ucuzdur.

Yanlış model, HPC için EFS kullanmaktır. EFS, NFS tabanlıdır ve genel amaçlı dosya G/Ç işlemleri yapan çok sayıda küçük istemci için ayarlanmıştır; 500 düğümlü bir MPI işinin ihtiyaç duyduğu toplam aktarım hızını veya metadata IOPS’unu sürdüremez ve çoklu AZ (multi-AZ) tasarımı gecikme ekler. EFA yerine standart ENA kullanmak, MPI’ı TCP gecikmeleriyle sınırlar ve allreduce ağırlıklı çalışma zamanlarını birkaç kat artırır. Doğru eşleştirme, bir küme yerleşim grubunda (cluster placement group) bulunan ve FSx for Lustre’ı bağlamış (mount) EFA özellikli EC2’ler ile dosya sistemine bağlı dayanıklı soğuk depolama olarak S3 kullanmaktır.

← Veritabanları ve Önbellekleme · Tüm alanlar · Uygulama Entegrasyonu →

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

Amazon'a göz atın →