Türk finans sektöründeki ETL mühendislerinin çoğu bankacılık üzerinden yetişir. İşlem taşımayı, gün sonu pozisyonlarını mutabakata bağlamayı, Oracle GoldenGate üzerinden CDC hatları kurmayı, belki kart yetkilendirmeleri için bir Kafka stream'i ayağa kaldırmayı öğrenirler. Sonra bir emeklilik projesine atanırlar — BES, OKS ya da doğrudan HAYMER bildirim hattı — ve iki ay içinde kariyerlerini üzerine inşa ettikleri varsayımlar incelikli ve pahalı biçimlerde çatlamaya başlar.
HAYMER (Hayat ve Emeklilik Veri Yönetim Merkezi) sıradan bir düzenleyici raporlama uç noktası değildir. Bildirim yapısı, işlemsel bankacılık ETL'inde basitçe var olmayan bir sınıf hat tasarım problemini dayatır. Her iki tarafta da yeterince yıl geçirdikten sonra şunu çekinmeden söyleyebilirim: HAYMER'a biraz daha katı bir BDDK raporu muamelesi yaparsanız, teknik olarak yeşil ama operasyonel olarak yanlış bir hat teslim edersiniz.
Farkı asıl yaratan şey şu.
Katılımcı bir satır değil, bir zaman çizelgesidir
Bankacılık ETL'inde bir hesap görece kararlı bir varlıktır. Açılış tarihi, kapanış tarihi, belki bir iki durum değişikliği vardır ve ilgi çekici veri hesaba bağlı işlemlerde yaşar. Yavaş değişen bir boyut olarak modelleyip yolunuza devam edebilirsiniz.
Emeklilik katılımcısı bunun tam tersidir. Katılımcının kendisi durum makinesidir. Tek bir sözleşme boyunca şunları izlersiniz:
- Sisteme giriş tarihi (sözleşme başlangıcı ile aynı şey değildir)
- Durum geçişleri: aktif, ödemeye ara verilmiş, devir alınmış, devredilmiş, hak kazanmış, emekli, vefat etmiş, lehtar talepli
- Katkı askıya alma ve yeniden başlatma pencereleri
- OKS (otomatik katılım) içinde sözleşme sonlandırılmadan işveren değişiklikleri
- Herhangi bir tarihsel tarihte yeniden inşa edilebilir olması gereken fon dağılım değişiklikleri
- Takvim zamanına değil, sistemde sürekli kalış süresine bağlı hak kazanma birikimi
valid_from / valid_to ile Type 2 SCD yeterli değildir. Bitemporal modelleme — sistem zamanı ve iş etkin zamanı — gerekir; çünkü HAYMER üç yıl sonra size belirli bir tarihte katılımcının durumunun ne olduğunu soracaktır — o tarihte bildiğiniz şekilde, bugün bildiğiniz şekilde değil. Geriye dönük düzeltmeler sürekli yaşanır ve geçmişin üzerine yazılamazlar.
Hattınız "14 Mart 2022'de doğru olduğuna inandığımız neydi ve 14 Mart 2022 hakkında bugün doğru olan nedir" sorusunu iki ayrı sorgu olarak yanıtlayamıyorsa, denetimden geçemezsiniz.
Zamansal hassasiyet bir lüks değildir
Bir kart yetkilendirme hattında bir işlem zaman damgası 200 milisaniye kayarsa kimse ölmez. HAYMER'da bir katkının alacaklandırıldığı tarih, yatırıma yönlendirildiği tarih ve birim fiyatın geçerli olduğu tarih — bunlar üç ayrı zaman damgasıdır ve karıştırıldığında katılımcının pay adedi değişir.
Somut örnek: bir katkı emeklilik şirketine Cuma günü fon kesim saatinden sonra ulaşır. Cuma günü alacaklandırılır ama Pazartesi'nin birim fiyatından yatırıma yönlendirilir. ETL'iniz yatırım tarihini, nakit o gün geldiği için Cuma olarak yazarsa, katılımcının payları yanlış NAV'a karşı hesaplanır. Binlerce katılımcı ve yıllar süren bileşik etki üzerinde aradaki fark gerçek paraya dönüşür. Ve HAYMER mutabakatı eninde sonunda bunu yüzeye çıkarır — genellikle bir düzenleyici incelemesi sırasında, asla uygun bir zamanda değil.
İşte yönetim raporlamasında gayet iyi çalışan standart "günlük truncate ve reload" deseninin burada bir kötü uygulama oluşunun sebebi budur. Her değerin bir kanıt zincirine ihtiyacı vardır: hangi olay üretti, hangi iş zamanında, hangi birim fiyat referansıyla, hangi fon tanım versiyonuna karşı.
Referans veri, referans veri değildir
Tipik bir ETL'de fon kodlarını, ücret tarifelerini ve vergi tablolarını referans veri olarak ele alırsınız. Onlara join atarsınız. Ara sıra değişirler ve boyutu güncellersiniz.
Emeklilik hatlarında bunlar sözleşmesel artefaktlardır. 2018'de giren bir katılımcıya uygulanan ücret tarifesi, aynı ürün üzerinde bile olsa 2024'te giren birine uygulananla aynı değildir. Bir sistem hatası nedeniyle ücretler geriye dönük yeniden hesaplandığında, hangi katılımcı için hangi tarihte hangi tarifenin hangi versiyonunun yürürlükte olduğunu bilmeniz ve doğru ücretlendirilmiş katılımcıları rahatsız etmeden düzeltmeleri uygulamanız gerekir.
Bu, referans tablolarının kendilerinin bitemporal versiyonlamaya ihtiyaç duyduğu ve join mantığınızın katılımcı başına, olay başına doğru versiyonu çözmesi gerektiği anlamına gelir. Standart bir yıldız şema join'i sessizce en son versiyonu kullanır ve size doğru görünen ama yanlış olan sayılar verir.
Geç gelen veri kural, uç durum değil
Bankacılık ETL'i geç gelen veriyi bir istisna yolu olarak ele alır. Onu yönetirsiniz, ama hacminizin büyük çoğunluğu zamanında gelir.
Emeklilik verisinde geç gelişler yapısaldır:
- OKS için işveren katkı dosyaları, kapsadıkları bordro döneminden haftalar sonra ulaşır
- Başka bir emeklilik şirketinden gelen aktarım verisi 30-60 gün gecikebilir ve beraberinde tarihsel durumu getirir
- Vefat bildirimleri MERNIS'ten asenkron olarak gelir ve vefat tarihinden sonra yapılan katkıların geri çözülmesini gerektirir
- Mahkeme kararları ve lehtar uyuşmazlıkları, aylar ya da yıllar sonra düzeltmeler enjekte eder
"Dünün verisi, bu gece işlenir" etrafında tasarlanmış bir hat bunu özümseyemez. Event sourcing'e ya da en azından düzeltmelerin güncellemeler değil yeni olaylar olduğu sadece-ekleme yapan bir katkı defterine ihtiyacınız vardır. Bu zincirin herhangi bir yerindeki değiştirilebilirlik eninde sonunda bir katılımcı bakiyesini bozar.
Mutabakat 2 yönlü değil, N yönlüdür
Bankacılıkta defterlerinizi büyük deftere ve belki takas kurumuna mutabakata bağlarsınız. İki yönlü mutabakat, çoğunlukla otomatikleştirilmiş.
HAYMER hatları en az şunlar arasında mutabakat yapar:
- Dahili katkı defteri
- Saklayıcı kuruluş fon birim kayıtları
- HAYMER'a bildirilmiş durum
- Devlet katkısı uygunluğu için vergi otoritesi kayıtları
- OKS için işverenin bildirdiği tutarlar
Bunlar uyuşmadığında — ve uyuşmayacaklar — soru "hangisi doğru" değildir. Soru "bu spesifik değer için bu spesifik zamanda hangisi doğru"dur, çünkü her sistemin kendi gecikmesi, kendi düzeltmeleri ve kendi doğruluk versiyonu vardır. Hattınızın bu tutarsızlıkları hata olarak loglamak yerine birinci sınıf veri olarak somutlaştırması gerekir.
Bunun tasarım için anlamı
Bir HAYMER hattına başlıyor ya da onu yeniden inşa ediyorsanız, ilk hafta gözden çıkarılması gereken varsayımlar:
- Son-yazan-kazanır mantığını unutun. Her şey, etkin zamanı ve kayıt zamanı olan bir olaydır.
- Değiştirilebilir katılımcı durumunu unutun. Durum, olay günlüğünün bir izdüşümüdür ve herhangi bir tarihsel tarih için yeniden hesaplanabilir.
- Referans veriyi statik lookup'lar olarak ele almayı unutun. Bir hesaplamaya dokunan her şeyi versiyonlayın.
- Yalnızca toplu (batch) düşünmeyi unutun. Geliş deseni patlamalı, geç ve düzeltmelerin geriye aktığı çift yönlü bir desendir.
- Tek-doğruluk-kaynağı söylemini unutun. Rekabet eden doğruluklar arasında mutabakat için inşa edin.
Bu projelerde başarılı olan mühendisler genellikle en fazla ETL araç deneyimine sahip olanlar değildir. Muhasebe defterleri, denetim izleri ve durum makineleri açısından düşünebilen — ve işledikleri satırın birinin otuz yıllık çalışma hayatının emeklilik gelirine dönüşmüş hali olduğunu içselleştirmiş olanlardır. Bu çerçeveleme, gece ikide bir teslim tarihi yaklaşırken yaptığınız tasarım seçimlerini değiştirir.
Bir kart işleminde hata yaparsanız, kaydı ters çevirirsiniz. 2019'dan kalma bir emeklilik katkısında hata yaparsanız, altı yıldır okuduğu ekstrede gördüğü tutardan daha düşük aylık geliri olduğu için 64 yaşında birine durumu açıklıyor olursunuz.
Fark bu. Buna göre inşa edin.