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ş: 2022'de TRT Çocuk Oyun Dünyası'nın event tasarımı ve pazarlama panoları; 2025'te MagicPages okuma uygulaması için PostgreSQL ve S3'ü tek bir ClickHouse analitik ambarında birleştiren, JOIN'siz dizi tabanlı boyutlar ve saniyeler içinde cevap veren olgu tabloları. 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, abonelikler PostgreSQL’de — işlem için tasarlanmış, normalize tablolarda. 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ı hâlinde 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. Her biri kendi başına çalışıyor; 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 — 130’dan fazla event, her birinin anahtar–değer alanlarıyla. Aynı listeden retention, oturum sayısı, kullanıcı başına oturum ve en çok oynanan oyunlar gibi metriklerin hangi event’ten hesaplanacağını bağladık. Üzerine Power BI ile pazarlama ve pazar karşılaştırma panoları kurduk.

Bu çalışmanın ilkesi sonraki işin de temeli oldu: toplanmayan veri sonradan üretilemez. Event’in adı, anı ve alanları baştan yazılırsa ambar kurulduğunda taşınacak anlamlı bir geçmiş olur.

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ı uçtan uca 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. Sonra bilinçli olarak 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. Her boyutu ve her olguyu baştan kurmak yerine, üç raporun istediği kadarını.

Dizi tabanlı boyut. Toplantıda gelen soru netti: “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 tersi doğru: 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ı. Tablo ReplacingMergeTree ile güncelleme tarihine göre tekilleşiyor; PostgreSQL tarafında CTE’lerle diziye toplanan veri, JSON varyantlar Nested’a çevrilerek toplu 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’e değil, önceden toplanmış özete gidiyor.

Zaman boyutu. dim_calendar yalnızca yıl–çeyrek–ay değil; Türkiye resmi tatilleri, okul günleri, dönemler ve hafta sonu bayrakları önceden hesaplanmış olarak duruyor. “Okul günlerinde akşam saatlerinde okuma” gibi soru tek filtre.

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 ve bir migration_history kaydı var. Her yükleme izlenebilir, her şema değişikliği kayıtlı.

Yol haritası

Hedef şema on boyut ve dokuz olgu: kullanıcı, kitap, tarih, saat, okul, sınıf, yayıncı, cihaz, lokasyon, abonelik; 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ı — yayıncıya kitap bazlı gelir ve tamamlanma oranı, okula sınıf karşılaştırması ve ödev takibi, öğrenciye kişisel ilerleme, bireysel kullanıcıya alışkanlık analizi, ebeveyne günlük okuma süresi ve ekran süresi. Yirmi analitik senaryo dört platformda toplanıyor: churn tahmini ve önleme, öğrenci başarı analitiği, içerik zekâsı, 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

Motor seçimi tasarımı değiştirir. Normalize boyut ve JOIN, satır bazlı motorların kısıtından doğan bir alışkanlıktır. Kolon bazlı motorda dizi ve iç içe yapı hem daha hızlı hem daha okunaklıdır; ambarı motorun gücüne göre tasarladık, alışkanlığa göre değil.
MVP üç rapordur, on boyut değil. İlk canlı yapı üç soruya cevap verdi; şema o cevaplar kullanıldıkça büyüyor.
Event tasarımı ambardan önce gelir. Oturum, profil, cihaz ve süre alanları event’te yoksa hiçbir olgu tablosu onları sonradan üretemez.

Sistemin yapısı

Tüm işlerimiz