``

Tahta Aynı, Başlangıç Konumları Farklı

Kural tabanlı sistemler, önceden belirlenen koşullara göre karar verir. Örneğin bir kredi sistemi şöyle çalışabilir: “Geliri belirli bir sınırın altında olan ve son iki yılda düzenli ödeme geçmişi bulunmayan başvuruyu reddet.” Bu kuralda cinsiyet, yaş veya etnik köken açıkça yazmıyor olabilir. Dolayısıyla sistem ilk bakışta tarafsız görünür.

Ancak ödeme geçmişi oluşturma fırsatı herkese eşit dağılmamışsa kural, geçmişteki eşitsizlikleri yeniden üretir. Satranç metaforuyla söylersek hakem taşların rengini önemsemiyordur; fakat oyunculardan biri oyuna zaten eksik taşlarla başlamıştır.

Bir grubun olumlu karar alma oranını şöyle gösterebiliriz:

Burada $\hat{Y}=1$ olumlu kararı, $G=g$ ise belirli bir gruba üyeliği ifade eder. İki grup için bu olasılıklar ciddi biçimde farklıysa açıkça ayrımcı bir kural bulunmasa bile sonuçlarda önyargı olabilir.

Önyargı Hangi Hamlelerde Gizlenir?

Özellikle vekil değişkenler önemlidir. Sistem mahalle kodunu kullanıyor ama etnik kökeni kullanmıyor olabilir. Ne var ki mahalle kodu toplumsal ayrışma nedeniyle etnik köken veya gelir düzeyiyle güçlü biçimde ilişkiliyse yasaklanan bilgi arka kapıdan oyuna döner. Fil yerine “çapraz ilerleyen uzun taş” demek, onun fil olduğu gerçeğini değiştirmez.

Basit Bir Kural Nasıl Sorun Üretir?

Aşağıdaki örnek, başvuruları gelir ve kredi geçmişine göre değerlendirir:

def kredi_karari(gelir, kredi_gecmisi_ayi):
    puan = 0

    if gelir >= 30_000:
        puan += 1
    if kredi_gecmisi_ayi >= 24:
        puan += 1

    return "Kabul" if puan == 2 else "Ret"

Kod kısa, anlaşılır ve herkese aynı şekilde uygulanır. Fakat düzenli finansal hizmetlere erişemeyen kişiler 24 aylık geçmiş koşulunu karşılayamaz. Böylece teknik olarak “eşit” kural, fırsat eşitsizliğini cezaya dönüştürür.

Sonuçları incelemek için seçim oranları karşılaştırılabilir:

Bu değerin $1$’den belirgin biçimde uzaklaşması araştırılması gereken bir dengesizliğe işaret eder. Ancak tek bir matematiksel ölçü adaletin tamamını açıklamaz; yanlış ret oranları, ekonomik koşullar ve kararın insanlar üzerindeki etkisi de değerlendirilmelidir.

Daha Adil Bir Oyun Kurmak

İlk adım, yalnızca kodu değil oyunun tamamını denetlemektir. Kurallar farklı gruplara ait örnek verilerle test edilmeli, vekil değişkenler araştırılmalı ve eşik değerlerinin etkisi ölçülmelidir. İnsanlara karar gerekçesi sunmak ve itiraz kanalı açmak da kritiktir.

Ayrıca “herkese aynı kural” ile “herkese adil fırsat” arasındaki fark unutulmamalıdır. Bazen geçmişi daha kısa olan başvurular için alternatif güvenilirlik göstergeleri kullanmak gerekir. Amaç bir gruba bedava vezir vermek değil, kimsenin oyuna şahı eksik başlamadığından emin olmaktır.

Algoritmik adalet, yalnızca tarafsız görünen kurallar yazma işi değildir. Asıl soru şudur: Tahtayı kim kurdu, taşların değerini kim belirledi ve oyun bittiğinde kaybedenler neden hep aynı tarafta kaldı?

``

Spark neden hızlıdır?

Geleneksel Hadoop MapReduce modelinde bir işin çıktısı çoğunlukla diske yazılır ve sonraki aşama bu veriyi yeniden diskten okur. Disk erişimi, özellikle yinelemeli algoritmalarda önemli bir darboğazdır. Spark ise çalışma verilerini RAM üzerinde saklayabilir ve aynı veri tekrar kullanılacaksa cache() veya persist() ile bellekte tutabilir.

Basitleştirilmiş toplam çalışma süresini şöyle düşünebiliriz:

Spark, özellikle $T_{okuma}$ ve $T_{yazma}$ bileşenlerini azaltmaya çalışır. Ancak “Spark her şeyi RAM’de yapar” demek doğru değildir. Bellek yetersiz kalırsa bazı bölümler diske taşabilir; ayrıca shuffle sırasında ağ ve disk kullanılabilir.

Dağıtık işlem mantığı

Spark uygulamasında driver, yapılacak işi planlar; executor süreçleri ise verinin parçaları üzerinde hesaplama yapar. Veri, partition adı verilen bölümlere ayrılır. Her partition farklı bir executor tarafından işlenebildiği için paralellik elde edilir.

Teorik olarak $N$ kayıt, eşit güçte $P$ işlemciye kusursuz biçimde dağıtılırsa işlem yükü yaklaşık olarak şöyledir:

Gerçekte ağ iletişimi, görev planlama ve dengesiz partition dağılımı nedeniyle doğrusal hızlanma her zaman mümkün değildir. Örneğin kayıtların büyük kısmı tek bir anahtara aitse data skew oluşur ve bir executor diğerleri kahvesini bitirmişken hâlâ çalışıyor olabilir.

PySpark ile MapReduce benzeri analiz

Aşağıdaki örnek, bir metindeki kelimeleri sayar. flatMap satırları kelimelere ayırır, map her kelimeyi (kelime, 1) çiftine dönüştürür ve reduceByKey aynı kelimelerin sayılarını toplar.

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("KelimeSayaci") \
    .getOrCreate()

satirlar = spark.sparkContext.textFile("veri/metinler.txt")

sonuclar = (
    satirlar
    .flatMap(lambda satir: satir.lower().split())
    .map(lambda kelime: (kelime, 1))
    .reduceByKey(lambda a, b: a + b)
)

for kelime, adet in sonuclar.take(10):
    print(kelime, adet)

spark.stop()

Buradaki dönüşümler hemen çalışmaz. Spark, lazy evaluation yaklaşımıyla işlemleri bir DAG üzerinde biriktirir. take(10) gibi bir action çağrıldığında plan optimize edilir ve görevler executorlara gönderilir. Bu sayede gereksiz hesaplamalar azaltılabilir.

RDD mi, DataFrame mi?

Modern projelerde çoğunlukla DataFrame API tercih edilir. Çünkü Spark’ın Catalyst optimizer bileşeni sorgu planını inceleyerek filtreleri erkene alma ve gereksiz sütunları okumama gibi iyileştirmeler yapabilir.

Spark sihirli bir hızlandırma düğmesi değildir; doğru partition sayısı, uygun cache kullanımı ve shuffle maliyetlerinin izlenmesi gerekir. Yine de büyük veri setlerinde tekrarlı analiz, makine öğrenmesi, ETL ve akış işleme ihtiyaçları söz konusu olduğunda bellek içi yaklaşımı, klasik disk merkezli modellere karşı son derece güçlü bir avantaj sağlar.

Büyük Veri Neden “Büyük”tür?

Bir veri kümesinin büyüklüğü mutlak değildir. Dün büyük sayılan birkaç terabayt, bugün sıradan bir şirketin günlük üretimi olabilir. Bu nedenle Büyük Veri’yi yalnızca gigabayt veya petabayt üzerinden tanımlamak yanıltıcıdır. Asıl soru şudur: Mevcut altyapı, veriyi kabul edilebilir sürede ve maliyetle işleyebiliyor mu?

Basitleştirilmiş biçimde işleme süresini şöyle düşünebiliriz:

Burada $D$ veri miktarını, $R$ tek bir düğümün işleme hızını, $N$ paralel çalışan düğüm sayısını, $O$ ise ağ iletişimi ve koordinasyon maliyetini temsil eder. Daha fazla makine eklemek teoride süreyi azaltır; ancak dağıtık sistemlerde koordinasyon bedeli nedeniyle kazanç doğrusal değildir.

3V Kuralı

Büyük Verinin doğasını açıklayan klasik model üç temel özelliğe dayanır: Volume, Velocity ve Variety.

Volume: Hacim

Hacim, tek bir sunucunun disk ve işlem kapasitesini aşan veri miktarıdır. Geleneksel yaklaşım daha güçlü bir makine satın almak, yani dikey ölçekleme yapmaktır. Büyük Veri sistemleri ise çoğunlukla yeni makineler ekleyerek yatay ölçekleme uygular. Veriler parçalara ayrılır, farklı düğümlerde saklanır ve hata ihtimaline karşı çoğaltılır.

Velocity: Hız

Bazı verilerin değeri zamanla hızla azalır. Bir kredi kartı dolandırıcılığını ertesi gün bulmak faydalıdır; işlemi gerçekleşirken yakalamak ise çok daha değerlidir. Bu nedenle toplu işleme yerine Kafka veya Pulsar gibi mesajlaşma altyapılarıyla beslenen gerçek zamanlı veri akışları kullanılır.

Saniyede gelen olay sayısı $\lambda$, sistemin işleyebildiği olay sayısı $\mu$ ise sürdürülebilir bir akış için genel beklenti şöyledir:

Aksi durumda kuyruk sürekli büyür; gecikme artar ve sistem sonunda nefessiz kalır.

Variety: Çeşitlilik

İlişkisel veritabanları düzenli satır ve sütunları sever. Oysa gerçek dünya CSV dosyaları, iç içe JSON belgeleri, fotoğraflar, loglar ve ses kayıtları üretir. Bu çeşitlilik; belge veritabanları, nesne depoları ve veri gölleri gibi esnek çözümleri gerekli kılar.

Aşağıdaki Python örneği, farklı yapıdaki olayları ortak bir işleme adımında normalize eder:

from datetime import datetime

def normalize(event):
    return {
        "user_id": event.get("user_id", "anonymous"),
        "event_type": event.get("type", "unknown"),
        "timestamp": event.get("timestamp", datetime.now().isoformat()),
        "payload": event.get("payload", {})
    }

Bu fonksiyon eksik alanlara varsayılan değerler atar ve değişken kaynaklardan gelen kayıtları ortak bir biçime yaklaştırır. Gerçek sistemlerde buna doğrulama, şema sürümleme ve hatalı kayıt yönetimi de eklenir.

Geleneksel Sistemden Yeni Nesil Mimariye

Hadoop, Spark, Kafka ve NoSQL sistemleri birer moda sözcük değil; 3V’nin oluşturduğu teknik baskılara verilmiş farklı cevaplardır. Bununla birlikte her proje Büyük Veri projesi değildir. Küçük bir veri kümesini karmaşık kümelerde çalıştırmak, roketle markete gitmeye benzer. Doğru yaklaşım; hacmi, gecikme beklentisini, veri biçimlerini ve maliyeti ölçerek en sade yeterli mimariyi seçmektir. Büyük Verinin özü teknoloji yığını değil, verinin doğasına uygun ölçeklenebilir düşünme biçimidir.

Saat aynı, deneyim farklı

Saat dilimleri teknik olarak UTC’ye göre tanımlanan ofsetlerdir. Bir kişinin yerel zamanı basitçe şöyle gösterilebilir:

Burada $O$, saat dilimi ofsetidir. Ancak insan deneyimi bu formülden daha karmaşıktır. Saat 09.00’da yapılan bir toplantı bir çalışan için kahveyle başlayan sakin bir sabah, diğeri için aile yemeğinin ortası olabilir. Üstelik yaz saati uygulamaları nedeniyle ofsetler yıl boyunca sabit kalmayabilir.

Dağıtık ekiplerde zamanın üç farklı biçimi vardır:

İyi bir çalışma düzeni yalnızca kronolojik zamanı optimize etmez; diğer iki katmanı da hesaba katar.

Eşzamanlılık bir spektrumdur

Ofis kültürü çoğu zaman üretkenliği aynı anda bulunmakla eşleştirir. Oysa yazılım ekiplerinde işlerin önemli bir bölümü eşzamansız yürütülebilir. Kod incelemesi, teknik karar kaydı ve durum güncellemesi için herkesin aynı görüntülü görüşmede bulunması gerekmez.

Buradaki amaç yöntemlerden birini seçmek değil, iletişimin gecikme maliyetine göre seçim yapmaktır. Bir mesajın bekleme süresi $L$, ekip üyeleri arasındaki saat farkı $D$ ve günlük ortak çalışma penceresi $W$ ile ilişkili düşünülebilir:

Ortak pencere küçüldükçe soruların bir sonraki güne taşınma ihtimali artar. Bu nedenle iyi yazılmış bir mesaj; bağlamı, beklenen çıktıyı ve son tarihi birlikte içermelidir.

Ortak pencereyi adil biçimde bulmak

Aşağıdaki Python örneği, ekip üyelerinin UTC cinsinden çalışma aralıklarının kesişimini hesaplar:

from typing import List, Tuple

def ortak_pencere(araliklar: List[Tuple[int, int]]) -> Tuple[int, int] | None:
    baslangic = max(aralik[0] for aralik in araliklar)
    bitis = min(aralik[1] for aralik in araliklar)

    if baslangic >= bitis:
        return None
    return baslangic, bitis

calisma_saatleri = [(6, 14), (8, 16), (12, 20)]
print(ortak_pencere(calisma_saatleri))  # (12, 14)

Fonksiyon en geç başlangıç ile en erken bitişi karşılaştırır. Sonuç (12, 14) ise ekip UTC 12.00–14.00 arasında buluşabilir. Ancak matematiksel kesişim otomatik olarak adalet anlamına gelmez. Sürekli aynı kişinin sabahın köründe toplantıya katılması, zaman yükünü görünmez biçimde ona aktarır. Kritik toplantı saatlerini dönüşümlü planlamak daha adildir.

“Şimdi”yi bir protokole dönüştürmek

Sağlıklı bir dağıtık ekip şu pratikleri benimseyebilir:

• Tarih ve saatleri yerel kısaltmalar yerine UTC ile belirtmek.
• Kararları toplantı sonrasında yazılı olarak kaydetmek.
• Mesajlarda “acil”, “bugün” ve “bu hafta” seviyelerini ayırmak.
• Çevrim içi durumunu anında yanıt zorunluluğu saymamak.
• Ortak saatleri kararlar için, bireysel saatleri üretim için korumak.
• Toplantı yükünü ve uygunsuz saatleri ekip içinde dönüşümlü dağıtmak.

Sonuçta ortak bir “şimdi”, duvardaki saatlerin eşitlenmesi değildir. Ekibin ne zaman birlikte düşünmesi, ne zaman bağımsız ilerlemesi ve ne kadar gecikmeyi kabul etmesi gerektiğine dair paylaşılan bir protokoldür. Dağıtık ekipler zamanı yönetmekten çok, zaman hakkında güven inşa eder. İyi tasarlanmış bir düzende iş güneşi takip eder; çalışanlar ise onu kovalamak zorunda kalmaz.

``

ETL nedir?

ETL; Extract, Transform, Load kelimelerinin baş harflerinden oluşur. Bir veri boru hattı ise verinin kaynaktan hedefe düzenli, izlenebilir ve mümkünse hatalara dayanıklı biçimde akmasını sağlayan daha geniş otomasyon sistemidir.

1. Extract: Veriyi kaynağından çekmek

Çıkarma aşamasında ilişkisel veritabanları, uygulama günlükleri, sensörler, bulut depoları ve harici API’ler gibi farklı kaynaklara bağlanılır. Buradaki önemli karar, verinin tamamının mı yoksa yalnızca değişen bölümünün mü alınacağıdır.

Tam yükte her çalıştırmada $N$ kayıt okunur. Artımlı yükte yalnızca değişen $\Delta N$ kayıt işlenir. Genellikle $\Delta N \ll N$ olduğundan artımlı yaklaşım ağ ve işlem maliyetini ciddi ölçüde azaltır. Bunun için zaman damgası, artan kimlik veya CDC (Change Data Capture) kullanılabilir.

2. Transform: Ham veriyi anlamlı hâle getirmek

Dönüştürme, ETL’in mutfağıdır. Eksik alanlar ele alınır, tarih biçimleri standartlaştırılır, tekrar eden kayıtlar silinir ve iş kuralları uygulanır. Örneğin toplam sipariş geliri şu şekilde hesaplanabilir:

Ancak matematik doğru olsa bile para birimleri farklıysa sonuç yanıltıcıdır. Bu nedenle dönüşüm yalnızca kod yazmak değil, verinin iş bağlamını anlamaktır.

import pandas as pd

def transform_orders(df: pd.DataFrame) -> pd.DataFrame:
    # Kimliği olmayan kayıtlar güvenilir biçimde eşleştirilemez.
    df = df.dropna(subset=["order_id"])
    df = df.drop_duplicates(subset=["order_id"])

    # Farklı tarih gösterimlerini ortak tipe dönüştürür.
    df["order_date"] = pd.to_datetime(df["order_date"], errors="coerce")
    df["total_amount"] = df["quantity"] * df["unit_price"]

    # Geçersiz veya negatif tutarları dışarıda bırakır.
    return df[df["total_amount"] >= 0]

Bu fonksiyon temel temizlik, tip dönüşümü ve gelir hesaplamasını tek adımda gerçekleştirir. Gerçek sistemlerde kurallar testlerle desteklenmelidir.

3. Load: Sonucu hedefe taşımak

Temizlenen veri; Snowflake, BigQuery, Redshift gibi veri ambarlarına veya bir data lake’e yüklenebilir. Yükleme tam yenileme, ekleme ya da upsert yöntemiyle yapılabilir. Upsert, mevcut kaydı günceller; yoksa yeni kayıt ekler.

Sağlam bir pipeline nasıl tasarlanır?

İyi bir veri boru hattı yalnızca başarılı durumda çalışmamalıdır. Aynı işlem tekrar çalıştırıldığında sonucu bozmayan idempotent adımlar tasarlanmalı; başarısız kayıtlar ayrı bir hata kuyruğuna gönderilmelidir. Loglama, veri kalite kontrolleri, şema doğrulama ve uyarılar da sistemin vazgeçilmez parçalarıdır.

Airflow, Dagster veya Prefect görevlerin sırasını ve zamanlamasını yönetebilir. Kafka gerçek zamanlı veri akışında, dbt ise SQL tabanlı dönüşümlerde öne çıkar. Araç seçiminden önce veri hacmi, gecikme beklentisi, maliyet ve ekip deneyimi değerlendirilmelidir.

Sonuç olarak ETL, veriyi A noktasından B noktasına taşıyan basit bir kargo hizmeti değildir. Kaynakları uzlaştıran, kaliteyi koruyan ve analitik kararların güvenilir temelini oluşturan otomatik bir üretim hattıdır. Boru hattı görünmez çalıştığında herkes mutludur; durduğunda ise neden veri mühendislerine ihtiyaç duyulduğu hemen anlaşılır!

``

Streaming neden farklıdır?

Geleneksel toplu işlemede veriler önce biriktirilir, ardından belirli aralıklarla işlenir. Streaming sistemlerinde ise teorik olarak sonu bulunmayan bir olay dizisi vardır:

Her olayın bir değeri, zaman damgası ve çoğunlukla anahtarı bulunur. Sistem, olayları bekletmeden işlerken ani trafik artışlarına da dayanmalıdır. Üretim hızı $P$, tüketim hızı $C$ ile gösterilirse sürdürülebilir çalışma için genel beklenti şudur:

Eğer $P > C$ olursa olaylar hemen kaybolmak zorunda değildir; Kafka bunları diskte tutar. Ancak tüketicinin geride kaldığı miktar, yani consumer lag, büyür. Bu tamponlama yeteneği üreticilerle tüketicilerin birbirinden bağımsız ölçeklenmesini sağlar.

Kafka’nın temel parçaları

Kafka’da üreticiler (producer) olayları topic adı verilen mantıksal kanallara gönderir. Topic’ler ölçeklenebilmek için partition bölümlerine ayrılır. Her partition yalnızca sonuna ekleme yapılan sıralı bir kayıttır. Olaylar silinmek yerine yapılandırılmış saklama süresi boyunca diskte korunur.

Bir olayın anahtarı aynı kaldığında genellikle aynı partition seçilir. Böylece örneğin aynı sensöre ait ölçümlerin sırası korunabilir. Fakat Kafka tüm topic genelinde mutlak sıra garantisi vermez; garanti partition düzeyindedir.

Basit bir sensör üreticisi

Aşağıdaki Python kodu, sıcaklık ölçümlerini JSON olarak Kafka’ya yollar. sensor_id anahtar olarak kullanıldığı için aynı sensörün olayları aynı partition’da sıralanabilir.

import json
import random
import time
from kafka import KafkaProducer

producer = KafkaProducer(
    bootstrap_servers="localhost:9092",
    value_serializer=lambda value: json.dumps(value).encode("utf-8")
)

while True:
    event = {
        "sensor_id": "sensor-42",
        "temperature": round(random.uniform(20, 35), 2),
        "timestamp": time.time()
    }
    producer.send(
        "temperature-events",
        key=event["sensor_id"].encode("utf-8"),
        value=event
    )
    time.sleep(1)

send işlemi asenkrondur; yüksek performans için olaylar paketlenebilir. Kritik sistemlerde acks="all" kullanmak, lider ve gerekli replikalar doğrulamadan gönderimi başarılı saymamak açısından önemlidir.

Kayıpsızlık gerçekten ne demek?

Kafka veriyi çoğaltarak broker arızalarına karşı korur, fakat uçtan uca güvenilirlik yalnızca Kafka ayarı değildir. Üretici tekrar denemeleri, acks, replikasyon faktörü ve tüketicinin offset yönetimi birlikte tasarlanmalıdır.

• At-most-once: Olay en fazla bir kez işlenir; kayıp mümkündür.
• At-least-once: Kayıp önlenir, fakat tekrar işleme olabilir.
• Exactly-once: İşlem sonucu mantıksal olarak yalnızca bir kez uygulanır.

Pratikte at-least-once ve idempotent tüketiciler güçlü bir çözümdür. Aynı event_id ikinci kez geldiğinde veritabanı işlemi sonucu değiştirmiyorsa tekrarlar zararsızlaşır. Kafka Transactions ve Kafka Streams ise uygun senaryolarda exactly-once semantiğini destekler.

Sonuç olarak Kafka yalnızca hızlı bir mesaj kuyruğu değil; olayları kalıcı biçimde saklayan, yeniden oynatılabilir ve dağıtık bir olay günlüğüdür. Web loglarından sensör alarmlarına kadar sağlam bir streaming mimarisi; partition planı, lag takibi, replikasyon, şema yönetimi ve idempotent işleme birlikte düşünüldüğünde gerçekten güvenilir hâle gelir.

HDFS neden ortaya çıktı?

Geleneksel dosya sistemleri, çoğunlukla tek makinenin disklerini yönetir. Veri büyüklüğü terabaytlardan petabaytlara çıktığında kapasite, aktarım hızı ve hata toleransı ciddi sorunlara dönüşür. HDFS’nin temel düşüncesi basittir: Veriyi hesaplamaya taşımak yerine hesaplamayı veriye taşı.

Bir dosya küçük bloklara ayrılır ve farklı bilgisayarlarda saklanır. Toplam kullanılabilir kapasite kabaca şöyle düşünülebilir:

Burada $N$ düğüm sayısını, $D$ her düğümün disk kapasitesini, $R$ ise çoğaltma faktörünü gösterir. Örneğin 100 makinenin her birinde 10 TB alan ve çoğaltma faktörü 3 ise kullanılabilir kapasite yaklaşık $333$ TB olur.

NameNode ve DataNode rolleri

HDFS mimarisinin koordinatörü NameNode‘dur. Dosya adlarını, klasörleri, izinleri ve hangi bloğun hangi makinede bulunduğunu takip eder. Ancak gerçek dosya içeriğini saklamaz. Onu, işçiler gibi çalışan DataNode düğümleri depolar.

Bir istemci dosya okumak istediğinde önce NameNode’a başvurur. NameNode uygun DataNode adreslerini bildirir; veri daha sonra doğrudan DataNode’lardan alınır. Böylece NameNode, bütün verinin içinden geçtiği bir darboğaza dönüşmez.

DataNode’lar düzenli olarak heartbeat mesajları göndererek hayatta olduklarını bildirir. Bir düğüm uzun süre sessiz kalırsa NameNode onu arızalı sayar ve eksilen kopyaların başka düğümlerde oluşturulmasını ister.

Bloklar ve çoğaltma

HDFS dosyaları genellikle 128 MB gibi büyük bloklara böler. Diyelim ki 300 MB büyüklüğünde bir dosyamız var. Bu dosya 128 MB, 128 MB ve 44 MB olmak üzere üç bloğa ayrılır. Çoğaltma faktörü 3 olduğunda her blok üç farklı DataNode üzerinde tutulur.

Bir bloğun kullanılabilir olma olasılığı, bağımsız düğüm arızası varsayımıyla şu şekilde ifade edilebilir:

$p$ tek düğümün arıza olasılığıdır. $p=0.1$ ve $R=3$ için bloğun bütün kopyalarını kaybetme olasılığı yalnızca $0.001$ olur. Elbette gerçek sistemlerde aynı rack veya ağ anahtarının çökmesi gibi ilişkili arızalar da vardır. Bu nedenle HDFS, kopyaları farklı rack’lere dağıtan rack awareness yaklaşımını kullanır.

Dosya yükleme akışı

Aşağıdaki komut yerel bir dosyayı HDFS’ye gönderir:

hdfs dfs -mkdir -p /veri/loglar
hdfs dfs -put uygulama.log /veri/loglar/
hdfs dfs -ls /veri/loglar

İlk komut hedef klasörü oluşturur, ikincisi dosyayı HDFS’ye yükler, üçüncüsü sonucu listeler. Arka plandaki süreç ise şöyledir:

1. İstemci, NameNode'dan dosya oluşturma izni ister.
2. NameNode uygun DataNode zincirini belirler.
3. İstemci bloğu ilk DataNode'a yollar.
4. Blok zincirdeki diğer DataNode'lara aktarılır.
5. Onaylar ters yönde istemciye döner.

Bu aktarım zinciri, istemcinin her kopyayı ayrı ayrı göndermesini önleyerek ağ kullanımını dengeler.

Güçlü olduğu ve olmadığı yerler

HDFS; günlük kayıtları, video arşivleri, sensör verileri ve toplu analitik işlemler için mükemmeldir. Buna karşılık milyonlarca küçük dosya NameNode belleğini tüketebilir. Sürekli rastgele güncelleme isteyen işlemler ve milisaniyelik yanıt bekleyen uygulamalar da HDFS’nin uzmanlık alanı değildir.

Kısacası HDFS, tek bir süper bilgisayar yerine birlikte çalışan sıradan makinelerden güvenilir bir depolama ordusu kurar. Hadoop ekosistemindeki MapReduce veya Spark gibi araçlar da hesaplamayı ilgili blokların bulunduğu düğümlere yaklaştırarak petabaytların ağda gereksiz yere dolaşmasını engeller.

``

OLTP ve OLAP dünyaları

Operasyonel sistemler, yani OLTP uygulamaları; sipariş oluşturma, ödeme alma veya stok güncelleme gibi anlık işlemlere odaklanır. Veri ambarlarının temelini oluşturan OLAP yaklaşımı ise veriyi farklı açılardan inceleyerek karar desteği sağlar.

Normalize edilmiş operasyonel veritabanlarında tekrar azaltılır. Ancak raporlama sırasında çok sayıda tabloyu birleştirmek gerekebilir. Veri ambarı, kontrollü veri tekrarını kabul ederek sorguları anlaşılır ve hızlı hâle getirir. Kısacası biri kasadaki kuyruğu hızlandırır, diğeri geçen yıl kasadan ne kadar kazandığımızı araştırır.

Yıldız şemasının anatomisi

Yıldız şemasının merkezinde ölçülebilir olayları saklayan bir fact (olgu) tablosu bulunur. Bu tabloyu ürün, müşteri, mağaza ve tarih gibi dimension (boyut) tabloları çevreler. Şema çizildiğinde ortaya yıldızı andıran bir görüntü çıkar.

Bir satış olgu tablosunda şu ölçüler bulunabilir:

• Satılan adet
• Birim fiyat
• İndirim tutarı
• Maliyet
• Net satış tutarı

Boyut tabloları ise bu sayıların bağlamını açıklar. Örneğin tarih boyutu yıl, çeyrek ve ay; ürün boyutu marka ve kategori bilgilerini taşır. Böylece toplam gelir şu şekilde ifade edilebilir:

Buradaki en kritik karar grain, yani olgu tablosundaki bir satırın neyi temsil ettiğidir. “Her sipariş”, “siparişteki her ürün satırı” ve “ürünün günlük toplam satışı” birbirinden farklı ayrıntı seviyeleridir. Grain belirsizse aynı satışın iki kez sayılması gibi tatsız sürprizler kaçınılmazdır.

Örnek tablo tasarımı

Aşağıdaki SQL, her satırın bir sipariş kalemini temsil ettiği sade bir model kurar:

CREATE TABLE dim_product (
    product_key INT PRIMARY KEY,
    product_id INT,
    product_name VARCHAR(150),
    category VARCHAR(100),
    brand VARCHAR(100)
);

CREATE TABLE dim_date (
    date_key INT PRIMARY KEY,
    full_date DATE,
    year_number INT,
    quarter_number INT,
    month_name VARCHAR(20)
);

CREATE TABLE fact_sales (
    date_key INT REFERENCES dim_date(date_key),
    product_key INT REFERENCES dim_product(product_key),
    order_id INT,
    quantity INT,
    unit_price DECIMAL(12,2),
    discount_amount DECIMAL(12,2),
    cost_amount DECIMAL(12,2)
);

product_key gibi ambar tarafından üretilen alanlara surrogate key denir. Kaynak sistemdeki kimlikler değişse bile tarihsel kayıtların tutarlı kalmasını sağlarlar.

Tarihsel değişiklikler ve veri akışı

Bir müşteri şehir değiştirdiğinde eski satışlar hangi şehre bağlanmalıdır? Slowly Changing Dimension (SCD) yaklaşımı bu problemi çözer. SCD Tip 1 eski değeri günceller ve geçmişi korumaz. SCD Tip 2 ise yeni bir boyut satırı açarak başlangıç ve bitiş tarihleriyle geçmişi muhafaza eder.

Veriler genellikle ETL sürecinden geçer: Kaynaklardan çıkarılır, temizlenip dönüştürülür ve ambara yüklenir. Modern bulut platformlarında önce yükleyip sonra dönüştüren ELT yaklaşımı da yaygındır.

İyi tasarlanmış bir yıldız şeması yalnızca hızlı sorgu üretmez; iş kullanıcılarının veriyi ortak bir dille konuşmasını sağlar. Sağlam bir grain, doğru ölçüler ve tarihsel boyut yönetimi birleştiğinde dağınık operasyon kayıtları güvenilir karar mekanizmasına dönüşür.

``

Veri gölü tam olarak nedir?

Veri gölü; yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verilerin özgün biçimleriyle merkezi bir depoda tutulduğu mimaridir. Bir ilişkisel veritabanına veri yazmadan önce tablo ve sütunları belirlemek gerekirken veri gölünde ham veri önce saklanabilir, kullanım şeması daha sonra oluşturulabilir. Bu yaklaşıma schema-on-read, yani “okuma sırasında şema” denir.

Örneğin aynı gölde şu veriler bulunabilir:

• JSON biçimindeki uygulama olayları,
• CSV satış kayıtları,
• Müşteri destek konuşmaları,
• Ürün ve güvenlik kamerası görselleri,
• IoT sensörlerinin zaman serileri,
• Sunucuların sıkıştırılmış log dosyaları.

Temel fikir basittir: Bugün gereksiz görünen bir kayıt, yarın dolandırıcılık tespiti veya talep tahmini modelinin en değerli özelliğine dönüşebilir.

Veri ambarından farkı

Bu iki sistem rakip olmak zorunda değildir. Veri gölü geniş bir hammadde alanı, veri ambarı ise düzenli rafları bulunan bir mağaza gibi düşünülebilir.

Yapay zekâ hazırlığı neden önemlidir?

Bir modelin başarısı yalnızca algoritmaya bağlı değildir. Basitleştirilmiş biçimde model kalitesini şöyle düşünebiliriz:

Burada $V$ veri hacmini, $D$ çeşitliliği, $C$ veri doğruluğunu ve $G$ yönetişim kalitesini temsil eder. Milyarlarca kayıt toplamak tek başına yeterli değildir; hatalı etiketler, eksik zaman damgaları ve belirsiz erişim izinleri model performansını düşürür.

Yapay zekâya hazır bir veri gölünde veri kataloglama, sürümleme, köken takibi ve kalite ölçümü bulunmalıdır. Böylece bir özelliğin hangi kaynaktan geldiği ve hangi işlemlerden geçtiği izlenebilir. Özellikle kişisel veriler için maskeleme, şifreleme ve rol tabanlı erişim uygulanmalıdır.

Basit bir veri alma örneği

Aşağıdaki Python kodu, JSON satırlarından oluşan ham olay dosyasını okuyup tarih bazlı Parquet dosyalarına dönüştürür. Parquet sütun tabanlı olduğu için analitik sorgularda daha az veri okunmasını sağlar.

import pandas as pd

logs = pd.read_json('events.jsonl', lines=True)
logs['event_time'] = pd.to_datetime(logs['event_time'])
logs['event_date'] = logs['event_time'].dt.date

for date, partition in logs.groupby('event_date'):
    path = f'lake/events/date={date}/events.parquet'
    partition.to_parquet(path, index=False)

Bu işlem ham dosyayı tamamen silmek yerine genellikle ayrı bir işlenmiş katmana yazar. Böylece gerektiğinde özgün veriye dönülebilir.

Gölü bataklığa çevirmemek

Katalogsuz, sahipsiz ve kalitesi ölçülmeyen bir veri gölü kısa sürede data swamp, yani veri bataklığı olur. Bunu önlemek için ham, temizlenmiş ve kullanıma hazır veriler ayrı katmanlarda tutulmalıdır. Her veri kümesine sahip, açıklama, saklama süresi ve kalite puanı atanmalıdır.

Sonuç olarak veri gölü, “her şeyi atalım, bir gün kullanırız” deposu değildir. Doğru mimari ve yönetişimle kurumun deney yapma hızını artıran stratejik bir yapay zekâ altyapısıdır. İyi korunan bir göl model ekiplerini besler; bakımsız bırakılan gölde ise en cesur veri bilimci bile yönünü kaybedebilir.

Borç metaforu bize ne anlatır?

Ward Cunningham’ın popülerleştirdiği teknik borç kavramı, hızlı teslimat uğruna gelecekte ek maliyet doğuracak kararları anlatır. Finansal borçta olduğu gibi burada da bir ana para ve faiz vardır. Ana para, sorunu bugün düzgün biçimde çözmek için gereken emektir. Faiz ise kötü karar nedeniyle her değişiklikte ödediğimiz ek süredir.

Basitleştirilmiş bir model şöyle kurulabilir:

Burada $B_0$ başlangıçtaki teknik borcu, $F_i$ ise her geliştirme döneminde ödenen faiz maliyetini temsil eder. Kod tabanı büyüdükçe bağımlılıklar çoğalır ve faiz doğrusal olmaktan çıkabilir:

Yani küçük görünen bir kestirme, yeterince uzun süre görmezden gelindiğinde minik bir TODO’dan kurumsal bir korku filmine dönüşebilir.

Her teknik borç ahlaksızlık mıdır?

Hayır. Bazen pazara çıkmak, kritik bir hatayı durdurmak veya belirsizliği test etmek için bilinçli borç almak mantıklıdır. Etik sorun, borcun varlığından çok gizlenmesi, kaydının tutulmaması ve bedelinin karar sürecine katılmayan insanlara aktarılmasıdır.

Bu ayrım niyet kadar yönetişimle de ilgilidir. Kim karar verdi, kim fayda sağladı ve faturayı kim ödeyecek? Etik değerlendirme bu üç soruyu birlikte sormalıdır.

Kodda görünmeyen sorumluluk

Aşağıdaki örnek çalışır, fakat hatayı sessizce yutarak gelecekteki geliştiriciye belirsizlik bırakır:

def kullaniciyi_getir(veritabani, kullanici_id):
    try:
        return veritabani.find(kullanici_id)
    except Exception:
        return None

None sonucunun kullanıcının bulunamadığı mı, bağlantının koptuğu mu, yoksa programlama hatası mı olduğu bilinmez. Daha sorumlu yaklaşım, beklenen durumları ayırır ve beklenmeyen hataları görünür kılar:

class KullaniciBulunamadi(Exception):
    pass

def kullaniciyi_getir(veritabani, kullanici_id):
    kayit = veritabani.find(kullanici_id)
    if kayit is None:
        raise KullaniciBulunamadi(kullanici_id)
    return kayit

Bu sürüm biraz daha fazla kod içerir; fakat davranışın anlamını açıklar. Temiz kod yalnızca estetik değildir: Başka insanların zamanı üzerinde kurduğumuz etkinin sınırlandırılmasıdır.

Nesiller arası adalet için pratikler

Teknik borcu etik biçimde yönetmek için borç kayıtları tutulmalı, mimari kararlar gerekçeleriyle belgelenmeli ve refaktör çalışmaları planlamada görünür olmalıdır. Kod incelemelerinde yalnızca “çalışıyor mu?” değil, “bunu altı ay sonra devralan kişi anlayabilecek mi?” sorusu da sorulmalıdır. Ayrıca bakım işi görünmez kahramanlık olarak değil, ürün geliştirme faaliyetinin parçası olarak değerlendirilmelidir.

Sonuçta hiçbir kod sonsuza kadar temiz kalmaz. Etik sorumluluk kusursuz sistemler üretmek değil; aldığımız kestirmelerin bedelini dürüstçe göstermek, faydayı bugün toplarken maliyeti yarının isimsiz geliştiricilerine bırakmamaktır. Git geçmişi unutabilir, ekip değişebilir; fakat kötü kararların faizi düzenli çalışır.