Bir mobil oyun ya da içerik uygulaması iki tür veri üretir. Operasyonel veri — kullanıcılar, kitaplar, abonelikler — uygulamanın kendi veritabanında, işlem için tasarlanmış normalize tablolarda durur. Davranış verisi — hangi ekran ne zaman açıldı, hangi kitap kaç saniye okundu, hangi oyun kaç kez başlatıldı — cihazdan event olarak gelir ve nesne depolamada dosya dosya birikir. İkisi de kendi işini görür; ama “bu ay hangi içerik hangi yaş grubunda tuttu” sorusu ikisini birden ister ve ikisinden de yavaş cevap alır.

Event tasarımı önce gelir

Toplanmayan veri sonradan üretilemez. Uygulama yayına çıkmadan önce hangi event’in hangi anda, hangi alanlarla gönderileceğini yazmak — oturum kimliği, profil, cihaz, sahne, süre — sonraki her raporun temelidir. Bu listeyi geliştirme ekibiyle birlikte çıkarır, retention ve oturum metriklerinin hangi event’lerden hesaplanacağını baştan bağlarız.

Analitik için ayrı bir ambar

Operasyonel veritabanı JOIN için, analitik ambar tarama için tasarlanır. Kolon bazlı bir motorda — ClickHouse gibi — kitabın yazarları, kategorileri, dilleri tek satırda dizi olarak tutulur; yedi tablo yerine tek tablo okunur. Event dosyaları doğrudan nesne depolamadan okunup boyutlarla zenginleştirilmiş olgu tablolarına, üzerine de saatlik ve günlük özetler üreten materialized view’lara akar.

Küçük başla, raporla büyüt

İlk adım her boyutu ve her olguyu kurmak değil; kullanıcı, içerik ve zaman boyutlarıyla tek bir olgu tablosunu canlıya alıp üzerinden üç rapor çıkarmaktır. Şema büyüdükçe okul, yayıncı, abonelik ve gelir katmanları eklenir; her katman bir rapor ihtiyacına karşılık gelir.

Bu alandaki işlerimiz