Büyük Veri Analitik Platformu: Spark, Kafka ve Data Lake Mimarisi

Büyük Veri Analitik Platformu: Ölçek, Hız ve Komplekslik

Terabyte ölçeklerinde veriye dayalı analitik, geleneksel veri ambarı mimarisi ile yapılamaz. Netflix, Uber, Spotify gibi şirketler Apache Spark ve Kafka ile günde petabyte verisi işliyorlar. Türkiye'de ise telco, bankacılık, e-commerce şirketleri büyük veri çözümlerine geçiş yapıyor.

Smart Maple, Spark + Kafka + Data Lake mimarisi ile 10 kuruluşun real-time analytics hareketini desteklemiş, 5+ kurumsal büyük veri projesini başarıyla tamamlamıştır.

---

1. Büyük Veri Problemleri ve Çözümleri

Veri ölçekleri kuruluşun büyüklüğüne göre değişir. Yüz gigabyte civarındaki veriler SQL Server veya PostgreSQL gibi geleneksel sistemlerle tek bir makinada bir saatte işlenebilir. Yüz gigabayt ile bir terabayt arasında veriye sahip kuruluşlar genellikle Oracle veya Teradata gibi özel sunuculara yatırım yapar ve işleme süresi birkaç saati bulur. Bir terabayt ile yüz terabayt arasındaki veriler ise Apache Spark ve dağıtık dosya sistemleri gerektirir—bu durumda on ile yüz arası sunucuda işlem yapılır ve süreler dakikalar cinsinden ölçülür. Yüz terabaytı aşan veriye sahip büyük kuruluşlar ise Spark'ı Kubernetes üzerinde çalıştırabilir ve otomatik olarak ölçeklenebilen bulut veri ambarları kullanır.

1.2 Büyük Veri Challenges

Challenge	Sorun	Çözüm
Data Volume	TB/PB ölçek veri	Distributed storage (HDFS, S3)
Data Velocity	Gerçek zamanlı veri akışı	Stream processing (Kafka, Spark Streaming)
Data Variety	Yapılandırılmış + yapısız	Data lake (format agnostic)
Processing Speed	Terabayt işlem uzun sürüyor	Distributed computing (Spark)
Cost	Altyapı + lisans masraflı	Open-source + cloud (pay-as-you-go)
Complexity	Sistem öğrenmesi zor	Managed services (Databricks, EMR)

---

2. Apache Spark: Distributed Computing Engine

Apache Spark, büyük veri işlemede sektörün standart hale gelmiştir. Spark bir uygulama başlatıldığında, bir ana sunucu (Driver) işlemi koordine eder ve dağıtık hesaplama kümelerinde çalışan işçi (Executor) sunucularına görev dağıtır. Bu mimar, on ile bin arası sunucuya kadar genişleyebilir. Spark, Kubernetes, YARN veya Mesos gibi kümeler yöneticileriyle uyumludur ve veri depolaması için HDFS, AWS S3, Google Cloud Storage veya Azure Blob Storage kullanabilir. İş akışı ise basit bir döngüde oluşur: veriler dağıtık veri çerçevesi olarak tanımlanır, dönüşümler tembel (lazy) olarak uygulanır ve gerçekte çalıştırılmak istendiğinde harita biçiminde paralel görevlere dönüştürülür. Sonuçlar ana sunucuya geri gönderilir.

Spark'ın mimarisi katmanlı bir yapı sunar. En altta, okunmaz, dağıtık veri koleksiyonları (RDD) yer alır; bunlar hata toleransı ve izleme yeteneğine sahiptir. Bunun üzerine SQL ve veri çerçevesi API'leri inşa edilir ve bunlar daha yüksek seviye bir arabirim sunar. Catalyst adlı bir sorgu iyileştiricisi ve Tungsten adlı bir bellek yöneticisi, performansı artırır. Spark ML (makine öğrenmesi), Spark Streaming (akışlı veriler), Spark Graph Processing (grafik işlemleri) ve MLlib kütüphaneleri gibi özel modüller, belirli iş yükleri için genişlemeler sağlar.

---

3. Kafka: Real-time Event Streaming

Kafka, gerçek zamanlı veri akışının bel kemiğidir. Uygulama günlükleri, veritabanı değişiklikleri, API webhook'ları ve IoT sensörleri gibi birçok kaynaktan veri üretilir. Bu veriler Kafka broker kümesine gönderilir; burada konular olarak organize edilirler. Her konu, paralel tüketim için birden fazla bölüme ayrılır ve her bölüm yüksek erişilebilirlik için üç kopya tutulur. Zookeeper koordinatörü, lider seçimini ve bölüm meta verilerini yönetir. Veri saklama politikaları, zaman tabanlı (örneğin yedi gün) veya boyut tabanlı (örneğin bir gigabyte) olabilir. Tüm bu yapı, çeşitli tüketici gruplarına (Spark Streaming, gerçek zamanlı gösterge panelleri, makine öğrenmesi işhattı) veri sunmaya uyarlanmıştır.

Randevular gibi işletme olayları için tipik bir Kafka konfigürasyonu şöyle görünür: konuya 10 bölüm atanır (paralel işleme için), üç kez çoğaltma yapılır (yüksek erişilebilirlik için), veriler 24 saat saklanır ve sıkıştırma etkin hale getirilir. İleti şeması, olay kimliği, olay türü, zaman damgası, klinik kimliği, randevu kimliği, doktor kimliği, hasta kimliği, durum ve bekleme süresi gibi alanları içerir. Tüketici grupları bu verilere farklı hızlarla erişir: gerçek zamanlı gösterge panelleri bir saniyeden az gecikmeyle, toplu işlemler geciktirilebilir, makine öğrenmesi işhattı ise beş dakikadan az gecikmeyle erişir.

---

4. Lambda vs Kappa Architecture

Büyük veri mimarisinde iki ana tasarım deseni vardır. Lambda mimarisi, toplu işleme (batch) ve akışlı işleme (stream) olmak üzere iki yolu paralel olarak çalıştırır. Toplu işleme katmanı tarihsel veri doğruluğunu sağlarken, hızlı katman gerçek zamanlı düşük gecikmeli sonuçlar sunar. Sonuçlar birleştirilmiş görünümlerde kullanıcılara sunulur. Bu yaklaşım çok yüksek veri hacimli ve doğruluk gerekli olan durumlara uygundur, ancak iki ayrı sistemi yönetme karmaşıklığı taşır.

Kappa mimarisi ise farklı bir felsefe sunar: tek bir akışlı veri kaynağı (Kafka gibi) tüm işlemenin temelini oluşturur. Spark Streaming veya Apache Flink gibi araçlar bu akışı gerçek zamanlı olarak işler ve bir durum deposu veya önbelleğe yazılır. Yeniden işleme gerekirse, geçmiş olayları yeniden oynatarak yapılır. Bu tasarım basit ve gerçek zamanlı gereksinimler ile agile (çevik) takımlar için idealdir. Randevuları yönetirken olduğu gibi gerçek zamanlı analitik kritik önemi taşırsa, Kappa mimarisi tercih edilir.

---

5. PySpark: Batch ve Streaming İşleme

Toplu işleme (batch processing) Spark ile genellikle günlük çalışan iş akışları aracılığıyla yapılır. İşlem, üç aşamada gerçekleşir. Birinci aşamada (Bronze katmanı), ham veriler S3 gibi depolama sisteminden Parquet biçiminde okunur. İkinci aşamada (Silver katmanı), veriler temizlenir, boş değerler işlenir, çoğaltmalar kaldırılır ve tarih-saat alanlı veri türleri dönüştürülür. Üçüncü aşamada (Gold katmanı), veriler kliniğe, doktora veya saate göre gruplandırılarak işlenir; tamamlanma oranı, iptal oranı ve ortalama randevu saati gibi metrikler hesaplanır. İşin sonunda, bu metrikler doktor sıralaması ile birlikte veri ambarına yazılır. Veri kalitesi kontrolleri sırasında, boş değer oranı yüzde birin altında tutulur.

Akışlı işleme (streaming) ise Kafka'dan gelen gerçek zamanlı olayları işler. Kafka kümesine bağlanıldıktan sonra, gelen JSON iletileri uygun veri türlerine dönüştürülür. Beş dakikalık zaman pencereleri açılır ve her pencere içinde klinik başına randevu sayısı sayılır. Sonuçlar Redis gibi bir önbellek veritabanına yazılır, böylece gösterge panelleri milisaniye cinsinden gecikmeyle en güncel bilgileri gösterebilir.

---

6. Data Lake Mimarisi: Medallion Pattern

Veri gölü (data lake) mimarisi üç katmanın kombinasyonudur. Bronze katmanı, biçimlendirme ve işlem hakkında endişe göstermeden ham verileri saklar; veriler Parquet biçiminde tutulur ve doksan gün süre ile kaydedilir; bu katman geçmiş analizi ve denetim izi (audit trail) için kullanılır. Silver katmanı, veriler temizlenir, boş değerler işlenir, türler dönüştürülür ve çoğaltmalar kaldırılır; bu veriler iki yıl tutulur ve makine öğrenmesi özellik mühendisliği için hazırlanır. Gold katmanı, işletmeye hazır hale getirilen verilerdir; saatlik, günlük veya aylık olarak toplanmış metrikler ve ana performans göstergeleri (KPI'lar) burada yer alır; bu katman beş yıl veya daha uzun süre kaydedilir ve iş zekası raporlaması ile gösterge panelleri burada çalışır.

Delta Lake, veri gölüne ACID işlemleri (atomik, tutarlı, izole, dayanıklı) getirir. Bu, birden fazla işcinin aynı veriyi güvenli şekilde güncellemesi anlamına gelir. Veri yazılırken, şema birleştirmesi etkinleştirilebilir; böylece yeni sütunlar daha sonra eklenebilir. Upsert işlemleri (güncelle veya ekle) veya zaman yolculuğu (belirli bir geçmiş tarih noktasından veri okuma) gibi işlemler Delta Lake'in etkileyici özellikleridir.

---

7. Büyük Veri Platformu: Maliyet Analizi

Büyük bir sağlık kuruluşunda (500 klinik, aylık 50 milyon randevu) altyapı maliyetleri kayda değerdir. AWS'de, toplu işleme için elektromanyetik hız lejyonu (EMR) kullanılan bir kurulum, ana sunucu ve yirmi işçi sunucusu olmak üzere aylık altı bin altı yüz dolar tutar. Gerçek zamanlı veri akışı için Kafka kümesi (üç broker, üç Zookeeper) aylık bin üç yüz elli dolar tutar. Akış işlemesi için Kubernetes kümesi aylık iki bin dolar tutar. Depolama olarak, S3'te iki terabayt veri aylık elli dolar tutarken, aylık on terabayt veri çıkış dokuz yüz dolar tutar. Redis önbelleği aylık sekiz yüz dolar, veri ambarı (Aurora) aylık iki bin beş yüz dolar, izleme ve diğer hizmetler aylık bin beş yüz dolar tutarsa, toplam aylık maliyet on beş bin yedi yüz dolar, yıllık ise yüz seksen sekiz bin dolar olur. Bu, randevu başına yaklaşık 0,038 dolar, klinik başına aylık üç yüz yetmiş altı dolar demektir.

Yönetilen hizmetler (Databricks gibi) daha ucuz olabilir. Databricks çözümü aylık sadece iki yüz on sekiz dolar tutarsa da, tam kapsamlı gerçek zamanlı akış işlemesinden ziyade veri lakehouse platformudur. Kuruluş büyüdükçe, kurulun ve bakımın karmaşıklığı nedeniyle yönetilen hizmetler tercih edilebilir.

---

8. Real-world: Oplist Big Data Pipeline

Bir randevu oluşturulduğunda, REST API aracılığıyla Kafka konusuna gönderilir. Buradan veri üç yönde dallanır. Birinci yön, gerçek zamanlı gösterge paneli için Spark Streaming'i kullanır; bir dakikalık zaman pencereleri açılır ve sonuçlar Redis'e yazılır, böylece gösterge paneli elli milisaniye gecikmeli güncel bilgi gösterir. İkinci yön, anomali algılama için Apache Flink veya Spark Streaming kullanır; iptal oranı yüzde onun üzerine çıkarsa, Slack'a bildirim gönderilir. Üçüncü yön, gecede saat ikiye başlayan bir toplu işlemedir; bu işlem EMR kümesi üzerinde çalışan bir Spark işi ile Bronze katmanından Silver ve Gold katmanlarına veri taşır ve iş zekası araçlarını günceller.

---

9. Common Big Data Issues & Solutions

Issue	Root Cause	Solution
Out of Memory	Large shuffles, no partition tuning	Increase partitions, use spill to disk
Slow Batch	Unoptimized Spark plan	Use Catalyst explain, add indexes
Kafka lag increasing	Consumer slower than producer	Scale consumer, optimize processing
Data skew	Hot partitions (e.g., clinic_id=1)	Salt keys, broadcast joins
Cost explosion	Too many executors/storage	Implement spot instances, S3 lifecycle

---

Sonuç

Büyük veri platformu (Spark, Kafka ve veri gölü), kurumsal gerçek zamanlı analitiklerin temeli. Lambda mimarisi toplu ve akışlı işlemeyi karıştırırken, Kappa mimarisi sadece akışlı işlemeyi tercih eder. Veri gölü, üç katman (Bronze, Silver, Gold) halinde verileri yönetir ve Delta Lake işlemlerin atomikliğini sağlar. Uygulamada, randevuları yönetirken, olaylar Kafka'dan alınır, gerçek zamanlı gösterge panelleri ve anomali algılama uygulanır ve gecede toplu işleme yapılır. Maliyetler kuruluş büyüklüğüne bağlı olarak aylık on beş bin ile elli bin dolar arasında değişir; yönetilen hizmetler daha ucuz alternatifler sunar.

Başarılı bir büyük veri platformu, doğru mimari seçimi, sağlam veri yönetimi, etkili işleme ve dikkatli maliyet planlama gerektirir. Smart Maple, Spark, Kafka ve veri gölü çözümleriyle kurumların bu karmaşık altyapıyı inşa etmelerine yardımcı olur.

Büyük veri platformunuzu inşa etmek için daha fazla bilgi ve rehberlik almak istiyorsanız, smart-maple.com adresini ziyaret edin ve bizimle iletişime geçin.