17 Ağu 2025·8 dk
Veri Modeli Seçimleri Mimarinizi Uzun Vadede Nasıl Kilitler
Veri modelleme kararları veri yığınızı yıllarca şekillendirir. Kilitlenmenin nerede ortaya çıktığını, takasları ve seçenekleri açık tutmanın pratik yollarını görün.
Veri modelleme kararları veri yığınızı yıllarca şekillendirir. Kilitlenmenin nerede ortaya çıktığını, takasları ve seçenekleri açık tutmanın pratik yollarını görün.
“Kilitleme” veri mimarisinde sadece satıcılar veya araçlarla ilgili değildir. Şema değiştirmenin o kadar riskli veya maliyetli hale gelmesi durumudur ki değişimi bırakırsınız—çünkü panoları, raporları, ML özelliklerini, entegrasyonları ve verinin ne anlama geldiğine dair ortak anlayışı bozacaktır.
Bir veri modeli, kalan her şeyden daha uzun süre yaşayan kararlardan biridir. Ambarlar değiştirilebilir, ETL araçları yer değiştirir, ekipler yeniden düzenlenir ve isimlendirme zaman içinde kayar. Ama onlarca aşağı akış tüketicisi bir tablonun sütunlarına, anahtarlarına ve tanesine bağımlı hale geldiğinde model bir sözleşme olur. Değiştirmek sadece teknik bir göç değil; insanlar ve süreçler arasında bir koordinasyon problemidir.
Araçlar değiştirilebilir; bağımlılıklar değiştirilemez. Bir modelde “revenue” olarak tanımlanan bir metrik başka bir modelde “gross” olabilir. Bir müşteri anahtarı bir sistemde “fatura hesabı”, başka bir sistemde “kişi” anlamına gelebilir. Bu düzeydeki anlam taahhütleri yayıldığında geri çevrilmesi zorlaşır.
Uzun vadeli kilitlenmenin çoğu birkaç erken tercihe dayanır:
Takaslar normaldir. Amaç taahhütten kaçınmak değil—en önemli taahhütleri kasıtlı yapmak ve diğerlerini mümkün olduğunca geri döndürülebilir tutmaktır. Sonraki bölümler değişim kaçınılmaz olduğunda kırılmayı azaltmanın pratik yollarına odaklanır.
Veri modeli sadece bir dizi tablo değildir. Çoğu zaman ilk sürümü bitirmeden önce birçok sistemin sessizce bağımlısı haline gelen bir sözleşme olur.
Bir model “onaylandığında”, genellikle şunlara yayılır:
Her bağımlılık değişimin maliyetini katlar: artık tek bir şemayı düzenlemiyorsunuz—birçok tüketiciyi koordine ediyorsunuz.
Yayınlanmış tek bir metrik (ör. “Active Customer”) nadiren merkezde kalır. Biri bunu BI aracında tanımlar, başka bir ekip dbt’de yeniden oluşturur, bir growth analisti bir notebook’ta sert kodlar ve bir ürün panosu biraz farklı filtrelerle tekrar gömer.
Birkaç ay sonra “tek metrik” aslında farklı uç durum kurallarıyla birkaç benzer metrik olur. Modeli değiştirmek artık sadece sorguları kırma riski değil; güveni bozma riskidir.
Kilitlenme genellikle şurada gizlenir:
*_id, created_at)Model şekli günlük operasyonları etkiler: geniş tablolar tarama maliyetlerini yükseltir, yüksek tahıl olay modelleri gecikmeyi artırabilir ve belirsiz lineage vakaları triage’ı zorlaştırır. Metrikler kaydığında veya boru hatları başarısız olduğunda, çağrı sırasındaki müdahaleniz modelin ne kadar anlaşılır ve test edilebilir olduğuna bağlıdır.
“Tahıl” bir tablonun temsil ettiği detay seviyesidir—her satır tam olarak hangi şeye ait? Küçük görünür ama genellikle mimarinizi sessizce yerinde sabitleyen ilk karardır.
order_id). Sipariş toplamları, durum ve yüksek seviyeli raporlama için iyi.order_id + product_id + line_number). Ürün karışımı, kalem başına indirimler, SKU bazında iadeler için gerekli.session_id). Huni analizi ve atribüsyon için kullanışlı.Sorun, işletmenin kaçınılmaz olarak soracağı soruları doğal olarak yanıtlayamayan bir tahıl seçtiğinizde başlar.
Eğer sadece orders saklarsanız ama sonra “gelire göre en iyi ürünler” gerekir hale gelirse zorlanırsınız:
order_items tablosu oluşturup backfill yapmak (göç ağrısı), veyaorders_by_product, orders_with_items_flat) ve bunun zamanla sürüklenmesi.Benzer şekilde, birincil fact tahılınız sessions ise “güne göre net gelir” dikkatli köprüleme yapılmadıkça zorlaşır. Kırılgan join’ler, çift sayma riskleri ve “özel” metrik tanımlarıyla sonuçlanırsınız.
Tahıl ilişkilerle sıkı bağlıdır:
İnşa etmeden önce paydaşlara cevaplayabilecekleri sorular sorun:
Anahtarlar modelinizin “bu satır gerçek dünyadaki o satır ile aynı şeydir” kararını verir. Bunu yanlış yaparsanız her yerde hissedersiniz: join’lar karışır, artımlı yüklemeler yavaşlar ve yeni sistemleri entegre etmek bir kontrol listesinden ziyade bir pazarlık haline gelir.
Doğal anahtar işte veya kaynak sistemde zaten var olan bir tanımlayıcıdır—fatura numarası, SKU, e-posta veya CRM customer_id gibi. Ardıl anahtar ise sizin yarattığınız içsel bir ID’dir (genellikle bir integer veya üretilmiş bir hash) ve depoda dışarıda anlamı yoktur.
Doğal anahtarlar anlaşılırdır. Ardıl anahtarlar ise yönetilirlerse stabildir.
Kilitlenme, bir kaynak sistemin kaçınılmaz değiştiğinde ortaya çıkar:
customer_id ad alanı getirebilir ve çakışma olabilir.Ambarınızda doğal anahtarları her yerde kullandıysanız, bu değişiklikler fact’lerden dimension’lara ve panolara kadar dalga dalga yayılabilir. Tarihsel metrikler kayar çünkü “customer 123” eskiden bir kişiyi ifade ederken şimdi başka birini ifade edebilir.
Ardıl anahtarlarla, yeni kaynak ID’lerini mevcut ardıl kimliğe eşleyerek ambar kimliğini sabit tutabilirsiniz—bir eşleme tablosu kullanarak.
Gerçek veri dedupe kuralları gerektirir: “aynı e-posta + aynı telefon = aynı müşteri”, veya “en yeni kaydı tercih et”, veya “doğrulanana kadar her ikisini de tut”. Bu dedupe politikası şunları etkiler:
Pratik bir desen, birden fazla kaynak anahtarının bir ambar kimliğine nasıl yuvarlandığını izleyen ayrı bir eşleme tablosu (identity map) tutmaktır.
Verileri paylaştığınızda veya yeni edinilen bir şirketi entegre ettiğinizde, anahtar stratejisi çabayı belirler. Bir sisteme bağlı doğal anahtarlar genellikle iyi taşınmaz. Ardıl anahtarlar dahili olarak taşınır, ancak başkalarının bunlara join atması gerekiyorsa tutarlı bir crosswalk yayımlamanız gerekir.
Her iki durumda da anahtarlar bir taahhüttür: yalnızca sütun seçmiyorsunuz—iş varlıklarınızın değişim karşısında nasıl hayatta kalacağını karar veriyorsunuz.
Zaman, “basit” modelleri pahalı hale getiren yerdir. Çoğu ekip bir şimdiki durum tablosuyla başlar (müşteri/sipariş/bilet başına bir satır). Sorgulaması kolaydır ama ileride ihtiyaç duyacağınız cevapları sessizce siler.
Genellikle üç seçenek vardır ve her biri farklı araçlar ve maliyetler kilitler:
effective_start, effective_end ve is_current bayrağı ile.Eğer “o zaman ne biliyorduk?” sorusuna ihtiyacınız olabileceğini düşünüyorsanız, yalnızca overwrite yeterli değildir.
Ekipler eksik geçmişi genellikle şu durumlarda keşfeder:
Bunu sonradan yeniden inşa etmek zordur çünkü upstream sistemler gerçeği zaten üstüne yazmış olabilir.
Zaman modelleme sadece bir zaman damgası sütunu değildir.
Geçmiş depolamak depolama ve işlem maliyetini artırır, ama ileride karmaşıklığı azaltabilir. Append-only günlükler almayı ucuz ve güvenli kılabilirken, SCD tabloları sık kullanılan “o ana göre” sorguları basitleştirir. Sadece bugünün panolarına göre değil, işin soracağı sorulara uygun deseni seçin.
Normalizasyon ve boyutsal modelleme sadece “stil” değildir. Sisteminizin kime daha dost olacağını belirler—boru hattını bakımını yapan veri mühendisleri mi, yoksa her gün soruları yanıtlayan kişiler mi.
Normalize model (genellikle 3NF), veriyi daha küçük, ilişkili tablolara böler böylece her gerçek yalnızca bir yerde saklanır. Amaç çoğaltmayı ve bununla gelen sorunları önlemektir:
Bu yapı veri bütünlüğü ve sık güncelleme olan sistemler için iyidir. Genellikle mühendislik ağırlıklı ekipler tarafından tercih edilir.
Boyutsal modelleme veriyi analize göre yeniden şekillendirir. Tipik bir star şemada:
Bu düzen hızlı ve sezgiseldir: analistler boyutlara göre filtreleyip gruplayabilir, BI araçları genelde buna uygundur. Ürün ekipleri için de özservis keşif daha gerçekçi hale gelir.
Normalize modeller şu grupları optimize eder:
Boyutsal modeller şu grupları optimize eder:
Kilitleme gerçektir: onlarca pano bir star şemaya bağlıysa, tahılı veya boyutları değiştirmek siyasi ve operasyonel olarak pahalıdır.
Drama azaltma yaklaşımlarından biri her iki katmanı da tutmaktır:
Bu hibrit, kayıt sistemi (system of record) esnek tutarken işin beklediği hız ve kullanılabilirliği sağlar—tek bir modelin her işi yapmasını zorlamadan.
Olay-merkezli modeller ne olduğunu anlatır: bir tıklama, bir ödeme denemesi, bir sevkiyat güncellemesi, bir destek bileti cevabı. Varlık-merkezli modeller ise bir şeyin ne olduğunu tanımlar: müşteri, hesap, ürün, sözleşme.
Varlık-merkezli modelleme (müşteri, ürün, abonelik gibi tablolar ve “güncel durum” sütunları) operasyonel raporlama ve “Kaç aktif hesabımız var?” veya “Her müşterinin güncel planı nedir?” gibi basit sorular için iyidir. Aynı zamanda sezgiseldir: her şey için bir satır.
Olay-merkezli modelleme (append-only fact’ler) zaman içinde analiz için optimize eder: “Ne değişti?” ve “Hangi sırayla?” gibi sorulara uygundur. Çoğu zaman kaynak sistemlere daha yakındır, bu da yeni soruları eklemeyi kolaylaştırır.
İyi tanımlanmış bir olay akışı tuttuğunuzda—her biri zaman damgası, aktör, nesne ve bağlam içeriyorsa—temel tabloları yeniden modellemeden yeni sorular cevaplanabilir. Örneğin, sonradan “ilk değer anı”nı, adımlar arasındaki düşüşü veya deneme başlangıcından ilk ödemeye kadar geçen süreyi türetebilirsiniz.
Sınırlar: olay payload’ı anahtar bir özniteliği hiç yakalamadıysa (örn. hangi pazarlama kampanyasının uygulandığı), bunu sonradan icat edemezsiniz.
Olay modelleri daha ağırdır:
Olay-öncelikli mimariler bile genellikle hesaplar, sözleşmeler, ürün kataloğu gibi stabil varlık tablolarına ihtiyaç duyar. Olaylar hikayeyi anlatır; varlıklar kadroyu tanımlar. Kilitlenme kararı, anlamın ne kadarını “güncel durum” olarak kodlayacağınız vs. ne kadarını geçmişten türeteceğinizdir.
Semantik katman (bazen metrik katmanı) ham tablolar ile kullanıcıların gerçekten kullandığı sayılar arasındaki “çeviri sayfasıdır”. Her dashboard veya analist “Revenue” veya “Active customer” gibi mantığı tekrar uygulamak yerine, semantik katman bu terimleri bir kez tanımlar—ve hangi boyutların kullanılabileceği, hangi filtrelerin her zaman uygulanacağı gibi kuralları koyar.
Bir metrik geniş çapta benimsendiğinde, iş için bir API gibi davranır. Yüzlerce rapor, uyarı, deney, tahmin ve prim planı buna bağlı olabilir. Tanımı değiştirmek güveni bozabilir; SQL çalışmaya devam etse bile insanlar neden farklı göründüğünü sorgulamadan önce veriye inanmamaya başlar.
Kilitlenme sadece teknik değildir—sosyaldir. Eğer “Revenue” hep iadeleri hariç tutuyorsa, aniden net gelire geçmek trendleri bir gecede yanlış gösterir.
Küçük seçimler hızlıca sertleşir:
orders adı sipariş sayısını ima eder, kalemleri değil. Belirsiz isimler tutarsız kullanıma davetiye çıkarır.order_date vs ship_date ile gruplanıp gruplanamayacağı anlatıları ve operasyonel kararları değiştirir.Metrik değişikliklerini ürün sürümü gibi ele alın:
revenue_v1, revenue_v2 ve geçişte her ikisini de erişilebilir tutun.Semantik katmanı kasıtlı tasarlarsanız, anlamı değiştirmeyi sürpriz olmadan yaparak kilitlenme acısını azaltırsınız.
Şema değişiklikleri eşit değildir. Yeni bir nullable sütun eklemek genellikle düşük risklidir: mevcut sorgular bunu yoksayar, downstream işler çalışmaya devam eder ve daha sonra backfill yapılabilir.
Mevcut bir sütunun anlamını değiştirmek pahalı olan türdür. Eğer status eskiden “ödeme durumu” anlamına geliyorsa ve şimdi “sipariş durumu” ise, her dashboard, uyarı ve join gizlice yanlış olur—hiçbir şey çarpıcı şekilde kırılmasa bile.
Birden çok ekip tarafından tüketilen tablolar için açık bir sözleşme ve test tanımlayın:
pending|paid|failed) ve sayısal alan aralıkları.Bu aslında veri için sözleşme testi yapmaktır. Tesadüfi sürüklenmeyi önler ve “kıran değişiklik”i net bir kategori haline getirir.
Bir modeli evrimleştirmeniz gerektiğinde, eski ve yeni tüketicilerin birlikte çalışabileceği bir dönem hedefleyin:
Paylaşılan tabloların kim onaylar, kim bilgilendirilir ve rollout süreci nedir sorularına yanıt veren net sahiplik gerekir. Hafif bir değişiklik politikası (sahip + gözden geçiriciler + kullanımdan kaldırma takvimi) herhangi bir araçtan daha fazla kırılmayı önler.
Bir veri modeli sadece mantıksal bir diyagram değil—sorguların nasıl çalışacağı, ne kadar maliyetli olacağı ve ileride neyin acı verici olacağı konusunda fiziksel bahislerdir.
Partitioning (genellikle tarihe göre) ve clustering (sıklıkla filtrelenen anahtarlarla) belli sorgu desenlerini ödüllendirir ve diğerlerini cezalandırır.
Eğer partitioning event_datee göreyse, “son 30 gün” filtreleri ucuz ve hızlı olur. Ama kullanıcılar sıkça account_idye göre uzun dönem slice’lar yapıyorsa, çok sayıda partition taranır—maliyet artar ve ekipler özet tablolar veya extract’lar gibi geçici çözümler tasarlar; bu da modeli daha da pekiştirir.
Geniş tablolar (denormalize edilmiş) BI araçları için dosttur: daha az join, daha az sürpriz, daha hızlı “ilk grafik zamanı”. Ayrıca belirli durumlarda tekrar eden join’lerin önüne geçerek sorgu başına daha ucuz olabilirler.
Takas: geniş tablolar veri çoğaltır. Bu depolamayı artırır, güncellemeleri karmaşıklaştırır ve tutarlı tanımları uygulamayı zorlaştırır.
Çok normalize modeller çoğaltmayı azaltır ve veri bütünlüğünü geliştirebilir, ama tekrar eden join’lar sorguları yavaşlatabilir ve özellikle teknik olmayan kullanıcılar kendi raporlarını oluştururken kötü bir deneyim yaratır.
Çoğu boru hattı artımlı olarak (yeni satırlar veya değişen satırlar) yükler. Bu, stabil anahtarlar ve eklemeye uygun bir yapı olduğunda en iyi çalışır. Geçmişi sık sık yeniden yazmayı gerektiren modeller (ör. birçok türetilmiş sütunun yeniden oluşturulması) genellikle maliyetli ve operasyonel olarak risklidir.
Modeliniz hangi doğrulamaları yapabileceğinizi ve neleri düzeltebileceğinizi belirler. Metrikler karmaşık join’lere bağlıysa kalite kontrolleri lokalize etmek zorlaşır. Tablolarınız backfill parafcına göre bölümlenmemişse (gün, kaynak batch), yeniden işleme beklenenden çok daha fazla veri taramak ve yeniden yazmak anlamına gelir—rutin düzeltmeleri büyük olaylara dönüştürür.
Bir veri modelini sonradan değiştirmek nadiren bir “refactor”tır. Halen insanlar yaşarken bir şehri taşımaya benzer: raporlar çalışmaya devam etmeli, tanımlar tutarlı kalmalı ve eski varsayımlar panolara, boru hatlarına ve hatta tazminat planlarına gömülüdür.
Aşağıdaki tetikleyiciler sıkça yeniden ortaya çıkar:
En düşük riskli yaklaşım göçü hem mühendislik hem de değişim yönetimi projesi olarak ele almaktır.
Eğer dahili veri uygulamalarınız (admin araçları, metrik keşif, QA panoları) varsa, bunları birinci sınıf göç tüketicileri olarak ele almak yardımcı olur. Ekipler bazen Koder.ai gibi hızlı uygulama oluşturma iş akışlarını kullanarak paralel çalıştırma sırasında hafif “sözleşme kontrol” UI’leri, uzlaştırma panoları veya paydaş inceleme araçları üretir—haftalarca mühendislik zamanını çalmadan.
Başarı “yeni tabloların var olması” değildir. Başarıdır:
Model göçleri beklenenden daha fazla zaman tüketir çünkü uzlaştırma ve paydaş onayı gerçek darboğazlardır. Maliyet planlamasını birinci sınıf bir iş akışı olarak ele alın (insan saati, çift çalışma compute’u, backfill’ler). Eğer senaryoları ve takasları çerçevelemek isterseniz, bakınız /pricing.
Geri döndürülebilirlik her geleceği tahmin etmekle ilgili değildir—değişimi ucuzlaştırmakla ilgilidir. Amaç, araçlardaki bir değişimin (ambar → lakehouse), modelleme yaklaşımındaki bir kaymanın (boyutsal → olay-merkezli) veya metrik tanımlarındaki bir değişikliğin tam bir yeniden yazma zorunluluğu getirmemesidir.
Modelinizi net sözleşmelerle modüler katmanlar olarak ele alın.
v2yi yan yana sunun, tüketicileri taşıyın, sonra v1i emekliye ayırın.Yönetişimi küçük ama gerçek tutun: metrik tanımlarıyla bir veri sözlüğü, her çekirdek tablo için atanan bir sahip ve ne değişti, neden ve kimle iletişim kurulacağına dair basit bir değişiklik günlüğü (repo’da bir Markdown dosyası bile) tutun.
Bu desenleri küçük bir alanda pilotlayın (örn. “orders”), v1 sözleşmelerini yayınlayın ve planlı bir değişikliği en az bir kere versiyonlama sürecinden geçirin. İşler yolunda giderse, şablonları standartlaştırın ve bir sonraki alana ölçekleyin.
Kilitleme, tabloları değiştirmeyi çok riskli veya maliyetli hale getirdiğinde ortaya çıkar; çünkü birçok aşağı akış tüketicisi onlara bağlıdır.
Depo veya ETL araçlarını değiştirmiş olsanız bile, tahıl, anahtarlar, geçmiş ve metrik tanımlarında kodlanmış olan anlam panolarda, ML özelliklerinde, entegrasyonlarda ve ortak iş dilinde bir sözleşme olarak kalır.
Her yaygın kullanılan tabloyu bir arabirim gibi ele alın:
Amaç “hiç değiştirmemek” değil—“sürpriz olmadan değiştirmek”tir.
İleride sorulacak soruları zahmetsizce cevaplayabilecek bir tahıl seçin.
Pratik bir kontrol:
Bir bire çok ilişkisinin “bir” tarafında sadece modelleme yaparsanız, daha sonra backfill veya çoğaltılmış türetilmiş tablolar ile ödersiniz.
Natural (doğal) anahtarlar (fatura numarası, SKU, kaynak customer_id) anlaşılırdır ama değişebilir veya çakışabilir.
Surrogate (ardıl) anahtarlar, kaynak ID’lerini depodan iç ID’ye eşleyerek stabil bir kimlik sağlar.
Eğer CRM taşımaları, M&A veya birden fazla ID ad alanı bekliyorsanız, planlayın:
Eğer “o zaman ne biliyorduk?” sorusuna yanıt gerekebilecekse, sadece overwrite (üzerine yazma) modellerinden kaçının.
Yaygın seçenekler:
Zaman sorunları genellikle eksik sütunlardan değil, belirsizlikten gelir.
Pratik varsayılanlar:
Semantik (metrik) katman, metrikleri BI araçları, notebook’lar ve dbt modelleri arasında kopyala-yapıştır yapmayı azaltır.
İyi çalışması için:
orders mı mı olduğuna netlik verin).Eski ve yeni tüketicilerin aynı anda çalışmasını sağlayan kalıpları tercih edin:
En tehlikelisi, bir sütunun değiştirip aynı adı tutmaktır—hiçbir şey yüksek sesle kırılmaz, ama her şey sessizce yanlış olur.
Fiziksel seçimler davranışsal kısıtlar haline gelir:
Dominant erişim desenlerinize göre tasarlayın (örn. son 30 gün, hesap_id’ye göre) ve bölümlendirmeyi backfill/yeniden işleme yönteminize uygun hale getirin.
“Big bang” tek seferlik geçiş yüksek risklidir çünkü tüketiciler, tanımlar ve güvenin sabit kalması gerekir.
Daha güvenli yaklaşım:
Çift çalıştıran compute ve paydaş onay süresi için bütçe ayırın. Eğer taktikler ve zaman çizelgeleri çerçevesi isterseniz, bakınız /pricing.
effective_start/effective_end ile “o ana göre” sorgular için iyi.Denetimler, finans, destek veya uyum gibi hangi soruların geleceğini düşünerek seçin—sadece bugünkü panoları değil.
order_itemsrevenue_v1, revenue_v2) ve geçiş süresince paralel çalıştırın.Bu, kilitlenmeyi dağınık SQL’den yönetilen, belgelenmiş bir sözleşmeye dönüştürür.