``

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.

``

Akış hali nasıl oluşur?

Csikszentmihalyi’ye göre akış, yapılan işin zorluğu ile kişinin becerisi birbirine yaklaştığında ortaya çıkar. Bunu basitçe şöyle gösterebiliriz:

Burada $F$ akış olasılığını, $C$ görevin zorluğunu, $S$ ise mevcut beceriyi temsil eder. Zorluk becerinin çok üzerindeyse kaygı; çok altındaysa sıkılma oluşur. Tam sınırdaki görev ise zihne tatlı bir meydan okuma sunar.

Akışın diğer bileşenleri açık hedef, hızlı geri bildirim, dikkatin tek noktada toplanması ve kontrol hissidir. Yazılım geliştirme bunların çoğunu doğal olarak sağlar: Derleyici anında konuşur, testler sonucu bildirir ve çalışan özellik somut ilerleme yaratır.

Meditasyonla ortak noktası ne?

Meditasyon dikkati şimdiki ana geri getirme pratiğidir. Akışta da geçmişteki hata veya yaklaşan toplantı yerine mevcut problem öne çıkar. Fakat ikisi aynı şey değildir. Meditasyonda kişi dikkatini bilinçli biçimde gözlemlerken akışta dikkat, faaliyetin içine emilir.

Bu nedenle akışı, programcılar için meditasyonun bilimsel karşılığı diye düşünmek faydalı bir benzetmedir; ancak klinik veya nörolojik açıdan birebir eşitlik değildir.

Akış için çalışma ortamı tasarlamak

Akış emirle başlamaz, fakat koşulları hazırlanabilir. Öncelikle büyük işi, sonucu görülebilen küçük görevlere bölmek gerekir. Belirsiz bir biçimde uygulamayı geliştir demek yerine giriş doğrulamasını tamamla gibi açık bir hedef seçilmelidir.

İkinci adım geri bildirim döngüsünü kısaltmaktır. Otomatik testler burada zihinsel pusula görevi görür:

function indirimliFiyat(fiyat, oran) {
  if (oran < 0 || oran > 1) throw new Error('Geçersiz oran');
  return fiyat * (1 - oran);
}

console.assert(indirimliFiyat(200, 0.25) === 150);

Bu küçük örnekte fonksiyon tek bir sorumluluk taşır; doğrulama hatalı girdiyi engeller, test ise sonucun doğru olup olmadığını hemen gösterir. Hızlı geri bildirim, zihnin belirsizlik yerine bir sonraki adıma odaklanmasını kolaylaştırır.

Bildirimleri kapatmak da kritiktir. Her kesinti yalnızca birkaç saniye çalmaz; problem modelinin çalışma belleğinde yeniden kurulmasını gerektirir. Bu yüzden 45-90 dakikalık kesintisiz bloklar, açık sekmelerin azaltılması ve telefonun görüş alanından çıkarılması etkili olabilir.

Akış bağımlılık değil, ritimdir

Saatlerce ara vermeden kod yazmak her zaman başarı değildir. Açlık, yorgunluk ve ergonomik sorunlar performansı düşürürken kişi hâlâ üretken olduğunu sanabilir. İdeal yaklaşım, yoğun odaklanmayı bilinçli molalarla dengelemektir.

Akışın formülü sihirli kulaklıklar veya sınırsız kahve değildir: net hedef, uygun zorluk, hızlı geri bildirim ve korunmuş dikkattir. Bir sonraki kodlama oturumunda bütün projeyi fethetmeye çalışma; becerini biraz aşan tek bir problem seç, testini çalıştır ve zihnin gürültüden üretken sessizliğe geçmesine izin ver.

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.

Sorun belleği ayırmak değil, doğru zamanda bırakmaktır

C dilinde malloc ile ayrılan alanın free ile serbest bırakılması programcının sorumluluğundadır. Serbest bırakma unutulursa bellek sızıntısı, erken yapılırsa use-after-free, iki kez yapılırsa double-free ortaya çıkabilir. C++ bu yükü RAII ve akıllı işaretçilerle azaltır; ancak ham işaretçiler ve karmaşık sahiplik ilişkileri hâlâ hata alanı oluşturur.

Rust’ın yaklaşımı üç temel kavrama dayanır:

1. Ownership (sahiplik): Her değerin tek bir sahibi vardır.
2. Borrowing (ödünç alma): Değere sahiplik aktarılmadan referansla erişilebilir.
3. Lifetime (yaşam süresi): Referans, işaret ettiği değerden daha uzun yaşayamaz.

Bir değerin kapsamı sona erdiğinde Rust otomatik olarak drop çağırır. Bu işlem çalışma zamanında izleme yapan bir çöp toplayıcıya değil, derleyicinin önceden doğruladığı deterministik kurallara dayanır.

Bellek kullanımını kabaca şöyle düşünebiliriz:

Rust, sahip kapsamdan çıktığında serbest bırakma işlemini otomatik üretir. Böylece programcının her çıkış yolunda manuel temizlik yazması gerekmez.

Sahiplik aktarımı

Aşağıdaki örnekte heap üzerinde tutulan metnin sahipliği mesaj değişkeninden yazdir fonksiyonuna aktarılır:

fn yazdir(metin: String) {
    println!("{metin}");
} // metin kapsamdan çıkar ve bellek bırakılır

fn main() {
    let mesaj = String::from("Merhaba Rust!");
    yazdir(mesaj);

    // println!("{mesaj}"); // Derleme hatası: değer taşındı
}

Derleyici son satıra izin vermez; çünkü mesaj artık belleğin sahibi değildir. C veya C++ dünyasında bu tür bir hata geçersiz işaretçi erişimine dönüşebilirken Rust programı daha çalışmadan durdurur.

Veriyi tüketmeden kullanmak için ödünç alma tercih edilir:

fn uzunluk(metin: &String) -> usize {
    metin.len()
}

fn main() {
    let mesaj = String::from("Ferris iş başında");
    let sonuc = uzunluk(&mesaj);
    println!("{mesaj}: {sonuc} karakter");
}

Buradaki &String, sahipliği almayan değişmez bir referanstır. Borrow checker genel olarak aynı anda ya çok sayıda değişmez referansa ya da yalnızca bir değişebilir referansa izin verir:

Bu kural, eş zamanlı programlarda veri yarışlarının önemli bir bölümünü engeller.

Rust bellek sızıntısını tamamen imkânsız mı yapar?

Hayır; önemli bir nüans burada saklıdır. Rust, bellek sızıntısını bellek güvenliği ihlali saymaz. Rc ile döngüsel referanslar kurulması veya std::mem::forget kullanılması belleğin serbest bırakılmamasına yol açabilir. Buna karşın güvenli Rust kodunda sızan belleğe geçersiz biçimde erişilmez; use-after-free ve double-free gibi daha tehlikeli sonuçlar önlenir.

Döngüsel yapılarda güçlü bağlantılardan biri Weak referansa çevrilerek sayaç döngüsü kırılabilir. Dolayısıyla Rust’ın vaadi “hiç bellek sızmaz” değil, “belleğin yaşam süresi kuralları ihlal edilerek tanımsız davranış üretilmez” şeklinde okunmalıdır.

Güvenlik ile kontrolün uzlaşması

Rust sıfır maliyetli soyutlamaları benimser: Kullanılmayan çalışma zamanı denetimleri programa eklenmez ve ownership kontrollerinin çoğu derleme sırasında tamamlanır. Gerektiğinde unsafe, ham işaretçiler ve FFI aracılığıyla düşük seviyeli kontrol sağlanır; ancak riskli bölge görünür biçimde sınırlandırılır.

Sonuç olarak Rust, programcıdan kontrolü almak yerine kontrolün sorumluluğunu kurallara bağlar. Derleyici zaman zaman huysuz bir ekip arkadaşı gibi görünse de üretimde gece yarısı çalan hata alarmından çok daha naziktir.

Rust araç zincirini tanıyalım

Kuruluma başlamadan önce oyuncu kadrosunu tanımak faydalıdır. Rust tek bir programdan ibaret değildir; birlikte çalışan araçlardan oluşan bir ekosistemdir.

Basitçe düşünürsek toplam derleme süresi yaklaşık olarak

şeklindedir. Cargo bu aşamaları bizim adımıza koordine eder ve değişmeyen parçaları önbellekten kullanarak sonraki derlemeleri hızlandırır.

Rust kurulumu

Linux ve macOS üzerinde resmi rustup kurulum komutu şöyledir:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Kurulum ekranında varsayılan seçenek genellikle yeterlidir. İşlem bittikten sonra terminali yeniden açın veya ortam değişkenlerini yükleyin:

source "$HOME/.cargo/env"
rustc --version
cargo --version

macOS kullanıyorsanız bağlayıcı araçlar için xcode-select --install komutu gerekebilir. Debian veya Ubuntu tabanlı Linux sistemlerinde ise sudo apt install build-essential paketi yerel derlemelerde ihtiyaç duyulan araçları sağlar.

Windows kullanıcıları rustup.rs üzerinden rustup-init.exe dosyasını indirip çalıştırabilir. Kurulum, Microsoft C++ Build Tools isteyebilir. Bu bileşen, Rust programlarının Windows üzerinde bağlanabilmesi için gereklidir. Yeni bir PowerShell penceresinde sürüm komutlarını çalıştırarak kurulumu doğrulayın.

Kararlı araç zincirini güncellemek ve gerekli yardımcı bileşenleri eklemek için:

rustup update stable
rustup default stable
rustup component add rustfmt clippy

VS Code ortamını hazırlama

VS Code içinde Extensions bölümünü açıp rust-analyzer eklentisini kurun. Resmî Rust eklentisi; otomatik tamamlama, tür gösterimi, hata analizi, yeniden adlandırma ve kod gezinme özellikleri sunar. Hata ayıklamak için ayrıca CodeLLDB kurulabilir.

VS Code ayarlarında dosya kaydedildiğinde biçimlendirmeyi etkinleştirmek, kod düzenini otomatik korur:

{
  "[rust]": {
    "editor.defaultFormatter": "rust-lang.rust-analyzer",
    "editor.formatOnSave": true
  }
}

Cargo ile ilk proje

Terminalde aşağıdaki komutlarla yeni bir uygulama oluşturun:

cargo new merhaba_rust
cd merhaba_rust
code .
cargo run

cargo new, kaynak kodunun bulunduğu src/main.rs dosyasını ve proje tanımı olan Cargo.toml dosyasını üretir. cargo run ise projeyi önce derler, ardından çalıştırır. Yalnızca hata kontrolü yapmak istediğinizde daha hızlı olan cargo check kullanılabilir.

Temel geliştirme döngüsü şu komutlardan oluşur:

cargo check    # Kodu hızlıca denetler
cargo fmt      # Biçimlendirmeyi düzeltir
cargo clippy   # İyileştirme önerileri sunar
cargo test     # Testleri çalıştırır
cargo run      # Uygulamayı derleyip başlatır

Bağımlılıklar Cargo.toml içindeki [dependencies] bölümünde tutulur ve kesin sürümler Cargo.lock dosyasına kaydedilir. Böylece ekipteki herkes aynı bağımlılıklarla tekrarlanabilir derlemeler yapar. Son kontrol olarak cargo run çıktısında “Hello, world!” görüyorsanız tebrikler: Rust atölyeniz üretime hazır!