- Netflix, iş alanlarının (ör. film, oyuncu, dizi vb.) veri modellemesinin her sistemde tekrar edilmesi, tutarsız olması ve standart olmayan terimler kullanılması nedeniyle iş birliği ve veri kalitesi sorunlarıyla karşı karşıya kaldı
- UDA (Birleşik Veri Mimarisi), 'bir kez modelle, her yerde temsil et' hedefiyle alan kavramlarını bir kez tanımlayan ve bunları farklı sistemlere tutarlı biçimde yansıtan ve bağlayan, bilgi grafiği tabanlı bir altyapıdır
- UDA, alan modeli → veri konteynerleri (ör. GraphQL, Avro, Iceberg vb.) için otomatik şema üretimi, eşleme ve veri taşıma otomasyonu sağlar
- İş kullanıcıları, Sphere ve PDM gibi UDA araçlarıyla yalnızca terim arayarak veriyi keşfedebilir, rapor oluşturabilir ve referans veri yönetimi yapabilir
- RDF ve SHACL gibi anlamsal teknolojiler üzerine kendi Upper metamodelini uygulayarak büyük ölçekli iş birliği, yönetişim, şema tutarlılığı ve ölçeklenebilirliği aynı anda sağlar
Netflix sistemlerinin artan karmaşıklığı ve alan modeli zorlukları
- Netflix hizmeti film, dizi, oyun, canlı etkinlik ve reklam gibi alanlara genişledikçe, bunu destekleyen sistem karmaşıklığı da ciddi biçimde arttı
actor, movie gibi temel iş kavramları, farklı sistemlerde (Enterprise GraphQL Gateway, varlık yönetim platformu, medya bilişim sistemleri vb.) ayrı ayrı tanımlanıyor ve iş birliği ya da paylaşım olmadan parçalı şekilde işletiliyordu- Bunun sonucunda şu sorunlar ortaya çıktı
- Tekrarlanan ve tutarsız modeller: Aynı varlık farklı sistemlerde yeniden tanımlanıyor, çakışmaları önlemek zorlaşıyor
- Terim uyumsuzluğu: Aynı sistem içinde bile farklı terimler kullanılması ya da aynı terimin yinelenmesi iletişim karışıklığı yaratıyor
- Veri kalitesi sorunları: Çok sayıdaki mikroservis arasında tutarsızlıklar ve referans hataları bulunuyor; tanımlayıcılar ve dış anahtarların yönetimi de yetersiz kaldığından manuel düzeltme gerekiyor
- Bağlantısallık sınırları: Sistem içi ilişkiler kısıtlı, sistemler arası bağlantılar da yetersiz
- Bu sorunları çözmek için, kavramsal modelin bir kez tanımlanıp her yerde yeniden kullanılacağı ve gerçek sistemler ile verilerle somut biçimde bağlanıp entegre olacağı bir temele ihtiyaç vardı
UDA’ya (Birleşik Veri Mimarisi) genel bakış
- UDA, Netflix Content Engineering içinde veri bağlantısallığına dayalı bir platformdur
- Alan modeli (iş kavramları) bir kez tanımlanır; ardından tüm sistemlere tutarlı biçimde yansıtılır ve otomasyon, keşif ile anlamsal birlikte çalışabilirlik sağlanır
- UDA ile mümkün olan başlıca işlevler
- Alan modeli kaydı ve bağlantısı: Resmî kavram tanımları tek bir kaynak olarak kullanılır; ekipler arasında karışıklık ve yinelenen modelleme önlenir
- Alan modellerinin veri konteynerleriyle eşlenmesi: İş kavramları ile gerçek verinin tutulduğu yerler (veritabanı, tablo, servis vb.) ve bunların yapısı grafik yapıda ifade edilerek kolayca anlaşılır
- Alan modellerinin şema tanım dillerine dönüştürülmesi: GraphQL, Avro, SQL, RDF, Java gibi farklı sistemlere otomatik dönüşüm yapılır; el işi azalır, hata riski düşer
- Verinin veri konteynerleri arasında güvenilir şekilde taşınması: GraphQL entity’leri, Data Mesh, CDC, Iceberg gibi sistemler arasında veri dönüşümü ve taşıması otomatik işlenir
- Alan kavramlarını keşfetme ve arama: İş kavramları arasındaki ilişkiler gezilebilir ve aranabilir; doğru bilgiye ulaşmak kolaylaşır
- Bilgi grafiği için programatik introspection sağlama: Java, GraphQL ve SPARQL üzerinden bağlantılı iş bilgileri kullanılır; otomasyon ve içgörü üretimi desteklenir
UDA’nın temel mimarisi
-
Knowledge Graph tabanı
- RDF/SHACL tabanlı bir bilgi grafiği olarak alan modelleri, şemalar, veri konteynerleri ve eşlemeler dahil tüm öğeleri grafik verisiyle birbirine bağlar
- Named graph merkezli bir bilgi modeli kullanır; her named graph düzenli bir yönetişim modelini izler ve yorumlama çerçevesi, modülerlik ile işletim politikalarını mümkün kılar
-
Upper metamodeli
- Upper, alan modellerini sıkı biçimde tanımlayan bir metamodel dilidir
- Alanlara özgü ana varlıklar, özellikler ve ilişkiler tipler ve hiyerarşilerle modellenir; RDF olarak ifade edilebilir, sürümlenebilir ve sorgulanabilir
- Upper’ın kendisi de Upper ile modellenmiştir (öz başvuru, öz doğrulama); bu sayede tüm genişletmeler ve yansıtmalarda tutarlılık sağlanır
- Özellik değerleri alan bazında özelleştirilebilir ve tüm kavramlar conceptual RDF ile named graph olarak ifade edilir; introspection, arama ve sürüm yönetimi desteklenir
- Upper, yüksek seviyeli soyutlamayla birlikte RDFS/OWL/SHACL gibi W3C anlamsal teknolojilerinin yalnızca temel kısımlarını seçerek uygular; ontoloji kavramlarını bilmeden de etkili alan modelleme mümkündür
- Upper metamodelinden Jena tabanlı Java API ve GraphQL şeması otomatik üretilir, ardından gerçek GraphQL servisleriyle bağlanır
-
Veri konteynerleri ve eşlemeler
- Data Container: Gerçek veri depoları (ör. GraphQL servisindeki entity’ler, Data Mesh kaynağındaki Avro kayıtları, Iceberg tablolarındaki satırlar, Java API içindeki nesneler vb.)
- Eşlemeler (Mappings): Alan modelindeki belirli öğeler ile veri konteynerleri (tablolar, alanlar vb.) arasındaki bire bir bağlantıların tanımı
- Eşlemeler sayesinde alan kavramı → gerçek veri konumu izlenebilir; ters yönde de veri → ilgili alan kavramları keşfedilebilir
- Niyet tabanlı veri taşıma / otomasyon: Eşleme bilgileri kullanılarak veri akışı ve dönüşümleri sistem tarafından otomatik belirlenir
-
Projections (yansıtmalar)
- Alan modeli → hedef sistem şeması (ör. GraphQL, Avro vb.) için otomatik dönüşüm ve üretim yapılır (kod, şema ve pipeline otomasyonu)
- Şema tutarlılığı sağlanır, yinelenen tanımlar ve senkronizasyon sorunları en aza indirilir
Gerçek kullanım örnekleri
-
PDM (Primary Data Management)
- Referans veri ve taksonomi (hiyerarşik sınıflandırma sistemi) yönetim platformu
- Alan modellerini hiyerarşik veya düz sınıflandırmaya dönüştürür, iş kullanıcıları için UI’ı otomatik üretir
- İş terimlerinin tutarlı tanımlanmasını sağlar; SKOS modeli tabanlıdır ve UDA ile Avro/GraphQL şemaları ile pipeline’lar otomatik üretilir
- Yalnızca alan modeli girildiğinde, UI / veri pipeline’ı / GraphQL API otomatik olarak oluşturulur
-
Sphere (Operational Reporting)
- Bilgi grafiği tabanlı self-service operasyonel raporlama aracı
- Alan terimlerine dayalı arama, keşif ve join stratejilerini otomatikleştirir; teknik karmaşıklık olmadan veri keşfi ve rapor üretimi sağlar
- UDA tabanlı metadata ve eşlemeler sayesinde sistem, gerçek veri konumunu ve join mantığını otomatik olarak anlar ve çalıştırır
actor, movie gibi tanıdık terimlerle kavramlar keşfedilir; seçilen kavramlara göre bilgi grafiği izlenerek SQL sorguları otomatik oluşturulur, ek join ya da teknik işlem gerekmeden veri elde edilir
Sonuç ve gelecek perspektifi
- UDA, Netflix’in veri modelleme ve entegrasyon yaklaşımında köklü bir değişim yaratıyor
- Alan modelinin bir kez tanımlanmasıyla, organizasyon genelindeki sistemler tutarlı, otomatik ve ölçeklenebilir veri entegrasyonu sağlayabiliyor
- Gelecekte Protobuf/gRPC gibi ek desteklerin ve bilgi grafiğinin gerçek veriye daha fazla uygulanmasının planlandığı belirtiliyor
2 yorum
Benzer bir şey kurmam gerekiyor ama nereden başlayacağımı bilemiyorum.
Hacker News yorumları
Tüm avantajlarına rağmen bu yaklaşımın sık anılmayan büyük bir sorunu olduğunu düşünüyorum
Bu hem bir iş problemi hem de teknik sorunları etkilediği için sonuçta geliştirme hızını etkileyen ikincil bir teknik probleme dönüşüyor
Tüm organizasyonun tek bir birleşik veri tanımına güvenebilmesine dair söz iş tarafını bağladığı için, artık veriyi tanımlarken ya da değiştirirken yalnızca kendi alanınızı değil, organizasyon genelindeki çeşitli kullanım senaryolarını da dikkate almak zorundasınız
En küçük değişiklik bile tüm organizasyonu etkilediğinden, çeşitli paydaşların onayını gerektirecek kadar karmaşık süreçler ortaya çıkıyor
Bu, büyük şirketlerdeki klasik “bir düğmenin rengini değiştirmek neden iki ay sürüyor” sorununun veri versiyonu
Elbette veriyi kopyalamak ya da tutarsız biçimde dağıtmanın genelde daha ciddi bir sorun olduğunu kabul ediyorum
Ama bazen küçük ve izole değişiklikleri hızlıca dağıtmak istediğinizde böyle bir sistem büyük bir engel haline geliyor
Bunu çözmek için bir ürün geliştirmeyi denemiştim
Kurumsal ortak modeli izlerken aynı zamanda modeli yerelde kolayca özelleştirmeyi sağlayan bir yaklaşım denedik (Prolog benzeri bir veri tanım dilini genişletmek ve hemen ihtiyaç duyulan şeyler yerine, gerçekten gerçekliğe dayalı bir kurumsal modeli ciddi biçimde düşünmek)
Ne yazık ki NoSQL ve Big Data rüzgarının en güçlü estiği dönemde denedik, bu yüzden zamanlama iyi değildi
NoSQL ve Big Data, gevşek modellerle çalışmanın ve verinin bir kısmı kaybolsa ya da yanlış anlaşılsa bile sonradan yamayarak düzeltmenin kabul gördüğü bir kültürdü
Başta güçlü bir model tasarlamaktansa sonradan toparlamanın daha kolay görüldüğü bir atmosfer vardı; biraz üzücüydü ama kabullendim
Bunun özünde bir iş problemi olduğuna katılıyorum ve bunu teknolojiyle sistematik biçimde çözebileceğimizi düşünüyoruz
Kurum içinde model-first bilgi grafiğini devreye almak ve yaymak için daha sistematik bir yöntem geliştirdiğimizden eminiz
UDA, kendisinden istenen her şeyi daha da bürokratik hale getirmemek için dikkatli ilerliyor
UDA mevcut sistemlerle yan yana var olur ve zorunlu benimsemeyi dayatmaz
Ama iş modellerinin her yerde kullanılabilmesini, kolayca bağlanabilmesini, genişletilebilmesini ve keşfedilebilmesini isteyen ekipler için güçlü ve kolay bir araç olmasını hedefliyor
(Bunu yazan kişinin UDA mimarlarından biri olduğunu belirtiyor)
Deneyimime göre, şirket içindeki “büyük adamların” iddiaları yüzünden mantıklı ya da tutarlı veri modellerinin kurulamaması çok sık yaşanıyor
Uygulamacı teknisyenler veriyi daha akılcı ve standartlara uygun ele almak istese de, etkili bir kişi doğrudan kafasındaki modeli dayatıp geliştiricilerin buna uymasını istiyor
Böyle sembolik bir düşünme biçimi bir kez yerleştiğinde, o şirkette tutarlı bir veri modeli kurulma ihtimali sıfıra yaklaşıyor
Sonuçta bu tür sorunlar yüzünden danışmanlara verimsiz biçimde çok fazla para ödendiğini düşünüyorum
Uzun süre SAP'nin ne olduğunu merak etmiştim; gerçekte ne olduğunu öğrenince şaşırdım
Bu kadar çok şirket SAP kullanıyor diye çok ileri bir teknoloji olduğunu sanmıştım, ama gerçekte sabit bir şema sunup müşteriden kendini o yapıya uydurmasını istemekmiş
Yazının aslı bunun bir iş problemi olduğunu inkâr ediyor gibi gelmiyor
Tanımlanan modeller tüm roller arasında birlikte tanımlanıyor; mühendislik bunun yalnızca bir parçası
Semantic Web, RDF, OWL, SKOS gibi şeylerin ortaya çıkışından bu yana epey zaman geçtiğini düşündüm
W3C'yi desteklemeye devam etmeleri ve zaten var olan tekerleği yeniden icat etmemeleri hoşuma gitti
UDA yaklaşımının yaygınlaşıp yaygınlaşmayacağını bilmiyorum ama büyük organizasyonlarda DDD (domain-driven design) ve semantik kavramları uygulamanın zorluklarını yenilikçi biçimde azaltmaya çalışan bir girişim olarak umut verici
Birden fazla geliştirme ekibine aynı veri anlam sistemini paylaşacak ortak araçlar ve teknolojiler sunup “bileşik faiz” etkisi yaratabilirse, veri sözleşmelerini DTO, POST gibi ağ iletimi gerekçeleriyle zorla düzleştirmek zorunda kalmayabiliriz; bu da ilginç
Netflix'in böyle ilginç bir deneyi açıkça paylaşarak ilerletmesine olumlu bakıyorum
Bana Uber'deki Dragon projesini hatırlattı
Uber'de Dragon şeması ile ilgili çalışmıştım ama açık kaynak haline getirilemedi
Sonrasında Joshua LinkedIn'e geçti, LambdaGraph projesi ve Hydra dili üzerinde çalıştı; bunlar burada açık kaynak olarak yayımlandı
Bu tür yaklaşımların ve 10 yıl önceki Semantic Web akımının ortak sorunu, kavramları resmileştirme ve sürdürme için gereken ek iş yükünün fazla olmasıydı
Bugün LLM'lerin bu yükü azaltıp azaltamayacağını merak ediyorum
Bu yazıda “domain model” teriminin seçilmesini biraz talihsiz buldum
Buradaki domain model tamamen veri merkezli bir kavramken, gerçek domain modeling özünde veri yapılarından çok davranışa odaklanır
Domain model içindeki veri, davranışı mümkün kılmak için vardır; asıl merkezde davranışın kendisi bulunur
Veri modellemesini bakış açısına göre farklı şekillerde ifade etmenin zaten kendi başına bir karmaşıklığı var ama bu farklar aslında bir özellik olarak da görülebilir
Her durum aynı karmaşıklık ya da ayrıntı düzeyini gerektirmez ve temsil modelleri genelde okuma senaryolarına göre optimize edilir
Bu tür bir yaklaşım, bilginin bağlama göre ele alınmasından ziyade birörnekliğe daha fazla ağırlık verebilir; alan bilgisinin güçlü olduğu ortamlarda ölçeklenebilirliği daha iyi olabilir ama pratikte çoğu kullanım senaryosunu mümkün kılmak için karmaşık ya da nüanslı domain modelini basitleştirmek gerektiğini gördüm
“Böyle bir girişimin %5'ten fazla ya da 5 milyon dolardan fazla ölçülebilir iş iyileştirmesi sağladığını gördünüz mü?” diye soruluyor
Veri tablolarını birleştirme girişimlerini defalarca gördüm ama gerçekte farklı analizler gerekiyorsa tabloların birleşmesi pek anlamlı olmuyordu ve çeşitli analizler yine bağımsız biçimde yapılıyordu
Yani herkesin istediği analiz şekline göre temel katmanı birleştirseniz bile, farklı analizler yine ayrı ayrı sürüyor
Yine de bu girişim her şeyi tek bir yapıda zorla birleştirmeye çalışmıyor, daha çok geniş çaplı erişim kolaylığı sağlamaya benziyor; bu yüzden akıllıca görünüyor
Resmi iş kavramlarının tanımlarını herkes için birleştirerek kafa karışıklığını azaltma amacıyla güçlü biçimde empati kuruyorum
Örneğin herkes ana hapishane listesini istiyor olabilir, ama hapishanenin binanın kendisi mi, mahkûm kümesi mi (aynı arazide erkek ve kadın hapishanelerinin ayrı varlıklar olması gibi), yoksa belirli bir sözleşmeyle işletilen kurum mu olduğu tanıma göre tamamen değişir
Bu açıdan organizasyon içindeki her bakış açısı hafifçe farklı nesnelere ihtiyaç duyabiliyor
Bunun domain-driven design (DDD) ile nasıl ilişkili olduğunu merak ediyorum
DDD'de aynı kavramın bile sistemden sisteme farklı temsil edilebileceği baştan kabul edilmiyor mu?
Ama yazının UML havası yüzünden sonuna kadar okumadım
upper:DomainModel'deki Domain, DDD'deki D (domain) ile aynı; DGS (Domain Graph Service) için de bu geçerli
DDD, aynı anda aynı kavramın sistemlere göre farklı biçimlerde temsil edilmesini kabul ederken, UDA her domain içinde bu farklı kavramların açıkça birlikte var olmasını tasarlıyor
“Aynılık” kavramı öznel hale geliyor
"ubiquitous language" terimini kullanmamış olmalarına sevindim
Bu kavram, burada denenen şeyin tam tersini ifade ediyor
İlgili terimleri sadece yüzeysel duymuş ama derinlemesine bakmamış olanlar farkı kaçırabilir
Netflix Engineering'in neden içeriklerini Medium'da yayımladığını merak ediyorum
Medium'un açılır pencereleri vb. yüzünden okuyucuyu kolayca kaybettiren bir ortamda, bu riske değip değmediğini sorguluyorum
Her hex Medium URL gördüğümde scribe.rip üzerinden okumak ayrı bir eğlence oluyor
scribe.rip UDA makalesi
Bunu pazarlama ekibi yönetiyorsa, SEO'yu da içeren bir strateji olabilir
Medium'un sağladığı “keşif” etkisi gerçekten var
Ayrıca Medium'a yazı yazan tipte mühendisler, Netflix'in işe almak isteyeceği yetenek havuzuyla örtüşüyor olabilir
Kendi blog altyapılarını yönetmek zorunda olmamaları da ayrı bir kolaylık
Veri modellerinde sürümleme ya da breaking change'leri nasıl ele aldıklarını merak ediyorum
Modeller daha parçalı yönetildiğinde eski yöntemlerle parça bazında düzeltmek daha kolay oluyor; bu kadar birleşik bir modelde nasıl işliyor acaba?
Netflix'in yaklaşımında muhtemelen yeni modeli ekleyip eski modeli kademeli olarak kullanımdan kaldırıyorlardır diye tahmin ediyorum
UDA'da bu henüz tamamen uygulanmış değil ama Federated GraphQL ile aynı yaklaşımı kullanmayı planlıyorlar
Federated GraphQL'de kendini kanıtlamış deprecation yönetim modelini benimseyecekler; ayrıca 500'den fazla federated GraphQL şemasını başarıyla yönetmiş deneyime sahipler
Temel nokta, projected model tüketicilerini izleyip deprecation döngüsünü proaktif biçimde yönetmeye yönelik bir yol haritası
Birleşik bir grafiği başarılı kılmak için iş, iletişim ve teknoloji olmak üzere üç boyutu da çözmek gerektiğini düşünüyorum
İletişim tarafında, “özerk ekiplerin ince bağımsızlığını” kırmak gerekiyor
Ekipler arasında köprü kuracak ve veri modelini de analiz edecek insanlar lazım
Sadece şema paylaşmak yetmiyor; insanlarla doğrudan görüşüp uzlaşma sağlama süreci şart
Teknik taraf ise aslında en kolay kısım; Microsoft Graph gibi “kalın şema”yı zorunlu kılarsanız nispeten basit
Bu süreç ciddi empati ve sabır gerektiriyor
Teknik çözüm için üst yönetimin net karar ve icra yetkisi şart; ekipler tamamen serbest bırakılırsa hiçbir fikir işe yaramıyor
En zor katman iş tarafı
20 yılda optimize edilmiş süreçleri ve terminolojiyi bir anda değiştirmek neredeyse imkânsız
Sonuçta, bu devasa işin “ömür boyu” yatırıma değmesi için şirket genelinde kusursuz bir buy-in gerekiyor
Ortak bir söz varlığının benimsenmesinin çok anlamlı olduğuna inanıyorum
Ama bu, şirket geneli, yeni satın almalar, farklı iş süreçleri ve zaman boyutu eklendikçe giderek zorlaşıyor
İki sistemi birbirine bağlayan bir arayüzü hızlıca kurabilirsiniz, ama tek bir kurum içinde birden fazla katman varken ve tüm bilgiyi kataloğa döken ideal bir veritabanını kimin kurup sürdüreceği soru işareti
Başarılı olup ayakta kalan girişimlerin çoğu ya çok soyut kalmış ya da kapsamı belirli kullanım senaryolarıyla sınırlamış durumda
Deneyimime göre, şirket genelinde bir entity'yi tanımlasanız bile (örneğin şirketin resmi varlığı), her departmanın bunu genişletme ihtiyacı doğuyor; yeni özelliklerin tüm departmanlar tarafından mı kullanılacağı yoksa sadece ilgili departmana mı ait olacağı gibi siyasi ve iyimser kararlar gerekiyor
Resmi entity güncellendiğinde, tüm etkileri değerlendirerek sıkı değişiklik yönetimi yapmak zorundasınız
Doğru şekilde kurulursa ve arkasında disiplinli bir kurumsal kültür varsa maliyet ve sürtünme ciddi biçimde azalabilir; Netflix'te bu mümkün görünüyor
Ayakta kalmayı başarmış benzersiz büyük ölçekli ortak söz varlığı örneği olarak Wikidata anılıyor
1,65 milyar grafik düğümü, standart bir söz varlığı altında genişlemeyi sürdürüyor