Vaka Çalışması · Oyun & dijital medya

Mayadem: oyun event'lerinden ClickHouse veri ambarına

Çocuk oyun ve içerik uygulamaları geliştiren Mayadem için iki dönemde iki iş yaptık. 2022'de TRT Çocuk Oyun Dünyası'nın event tasarımını ve pazarlama panolarını kurduk. 2025'te MagicPages okuma uygulaması için PostgreSQL ve S3'ü tek bir ClickHouse analitik ambarında birleştirdik; boyutlar JOIN gerektirmeyen dizi yapısında, olgu tabloları saniyeler içinde cevap veriyor. Çalışma veri merkezli yapılanma danışmanlığı olarak devam ediyor.

7 → 1
Kitap boyutu: 130+
Event tanımı: 5
Canlı tablo: 5
Rapor personası

Problem

Mayadem’in uygulamaları iki tür veri üretiyor. Kullanıcılar, kitaplar, yayıncılar ve abonelikler PostgreSQL’de, işlem için tasarlanmış normalize tablolarda duruyor. Bir kitabın yazarları, kategorileri, illüstratörleri, dil varyantları ve çevirmenleri yedi ayrı tabloda; tek bir kitabın tüm bilgisini almak yedi JOIN istiyor. Davranış verisi ise cihazdan event olarak geliyor: hangi profil hangi kitabı hangi cihazda kaç saniye okudu, hangi sahne ne zaman kapandı. Bu event’ler Parquet dosyaları halinde S3’te birikiyor, günde milyonlarca.

Raporlar uygulamanın yönetim panelinde hazır sorgular olarak yaşıyordu: en çok okunan kitaplar, aktif aboneler, MRR, churn, funnel, retention. Bunlar tek tek çalışıyordu. Ama “bu ay hangi kategori hangi yaş grubunda tuttu, hafta sonu okuyanlar kim” gibi iki kaynağı birden isteyen sorular ya çok yavaş cevaplanıyor ya da hiç sorulamıyordu.

2022: Event tasarımı ve pazarlama panoları

İlk çalışma TRT Çocuk Oyun Dünyası içindi. Uygulama geliştirilirken hangi event’in hangi anda, hangi alanlarla gönderileceğini geliştirme ekibiyle birlikte satır satır çıkardık: uygulama açılışı, dil seçimi, ebeveyn paneli, ekran süresi, uyku saati, abonelik, oyun başlatma ve kapatma. Liste, her biri anahtar–değer alanlarıyla 130’dan fazla event’e ulaştı. Retention, oturum sayısı, kullanıcı başına oturum ve en çok oynanan oyunlar gibi metriklerin hangi event’ten hesaplanacağını da aynı listeye bağladık. Üzerine Power BI ile pazarlama ve pazar karşılaştırma panoları kurduk.

Bu çalışmada izlediğimiz ilke sonraki işte de geçerli oldu: toplanmamış veri sonradan elde edilemiyor. Event’in adı, gönderildiği an ve alanları baştan yazılırsa, ambar kurulduğunda taşınacak anlamlı bir geçmiş birikmiş oluyor.

2025: MagicPages için ClickHouse veri ambarı

MagicPages, çocuklar için çok dilli bir okuma uygulaması. Ağustos 2025’te ekiple oturup veri akışlarını baştan sona konuştuk. Bir kullanıcının uygulamayı ilk açtığı andan SSO’ya kadar veritabanında ne oluşuyor, bir kitabın çok değerli özellikleri nasıl tutuluyor, event’ler cihazda nasıl toplanıp S3’e ne sıklıkla yazılıyor, hepsine baktık. Sonra bilerek küçük bir hedef koyduk.

MVP. Kullanıcı, kitap ve zaman boyutlarıyla okuma sürelerini tutan tek bir olgu tablosunu ClickHouse’a taşımak ve üzerinden üç rapor çıkarmak: kullanıcı okuma performansı, kitap popülerliği ve okuma süresi, zaman bazlı okuma trendleri. Bütün boyut ve olguları en baştan kurmadık; üç raporun ihtiyacı kadarıyla başladık.

Dizi tabanlı boyut. Toplantıda şu soru geldi: “Boyutları geleneksel ambarlardaki gibi normalize tutup JOIN’leyecek miyiz?” SQL Server ya da PostgreSQL üstünde öyle yapardık, çünkü o motorlar iç içe yapılarda esnek değil. ClickHouse’ta durum tersine dönüyor. dim_book tek tabloda kitabın yazarlarını, kategorilerini ve illüstratörlerini dizi kolonlarında, dil varyantlarını ve çevirmenlerini iç içe (Nested) yapıda taşıyor. “Yazarı şu olan kitaplar” sorusu üç JOIN yerine tek bir has() çağrısıyla cevaplanıyor. Tablo ReplacingMergeTree ile güncelleme tarihine göre tekilleşiyor. PostgreSQL tarafında veri CTE’lerle diziye toplanıyor, JSON varyantlar Nested’a çevriliyor ve toplu olarak yükleniyor.

Olgu tablosu. ReadingSceneClosed event’i S3’ten doğrudan ClickHouse’un S3 motoruyla okunuyor ve fact_reading_session tablosuna, kitap boyutuyla zenginleştirilmiş olarak yazılıyor: oturum süresi, okunan sayfa, okuma hızı, platform, cihaz dili, yaş. Tablo aya göre bölümlenmiş, (event_date, user_id, book_id) sırasıyla düzenlenmiş; düşük kardinaliteli alanlar LowCardinality, kategori dizisi bloom filter indeksli. Üzerinde saatlik kullanıcı aktivitesi ve günlük kitap performansı için materialized view’lar var. Sorgular ham event’leri taramak yerine bu önceden toplanmış özetlerden okuyor.

Zaman boyutu. dim_calendar yıl, çeyrek ve ay alanlarının yanında Türkiye resmi tatillerini, okul günlerini, dönemleri ve hafta sonu bayraklarını önceden hesaplanmış olarak tutuyor. “Okul günlerinde akşam saatlerinde okuma” gibi bir soru tek filtreyle cevaplanıyor.

Canlıya alınan yapı. Kasım 2025 itibarıyla ambarda dim_book, dim_calendar, dim_child, dim_parent ve fact_reading_session canlı. Her tablonun kendi ETL log tablosu var, şema değişiklikleri de migration_history tablosuna kaydediliyor. Böylece her yükleme izlenebiliyor.

Yol haritası

Hedef şema on boyut ve dokuz olgudan oluşuyor. Boyutlar: kullanıcı, kitap, tarih, saat, okul, sınıf, yayıncı, cihaz, lokasyon, abonelik. Olgular: okuma oturumu, kitap performansı, kullanıcı etkileşimi, ödev, öğrenci ilerlemesi, gelir, değerlendirme, okul ve yayıncı analitiği. Bunun üzerinde beş persona için üç seviyeli bir rapor kataloğu tanımlı. Katalogda yayıncı için kitap bazlı gelir ve tamamlanma oranı, okul için sınıf karşılaştırması ve ödev takibi, öğrenci için kişisel ilerleme, bireysel kullanıcı için alışkanlık analizi, ebeveyn için günlük okuma süresi ve ekran süresi yer alıyor. Yirmi analitik senaryo dört platformda toplanıyor: churn tahmini ve önleme, öğrenci başarı analitiği, içerik zekası, gelir optimizasyonu.

Çalışma 2026’da veri merkezli yapılanma danışmanlığı olarak devam ediyor: mevcut yapıların incelenmesi, alternatif teknolojilerin test edilmesi, veri akışlarının planlanması, içgörü ve görselleştirme.

Neden böyle

Tasarımı motora göre yaptık. Normalize boyut ve JOIN alışkanlığı, satır bazlı motorların kısıtlarından geliyor. Kolon bazlı bir motorda dizi ve iç içe yapılar hem daha hızlı çalışıyor hem de sorguları daha okunaklı kılıyor. Ambarı bu yüzden ClickHouse’un güçlü olduğu yapılara göre kurduk.
MVP üç raporla başladı. İlk canlı yapı üç soruya cevap verdi; şema bu raporlar kullanıldıkça büyüyor.
Event tasarımı ambardan önce geliyor. Oturum, profil, cihaz ve süre alanları event’te yoksa olgu tablosuna da sonradan eklenemiyor.

Sistemin yapısı

Tüm işlerimiz