- Netflix menghadapi masalah kolaborasi dan kualitas data karena pemodelan data untuk domain bisnis (misalnya film, aktor, serial, dan sebagainya) terduplikasi di tiap sistem, tidak konsisten, dan memakai istilah yang tidak standar
- UDA (Unified Data Architecture) adalah infrastruktur berbasis knowledge graph dengan tujuan 'modeling once, expressing everywhere', yaitu mendefinisikan konsep domain satu kali lalu memproyeksikan dan menghubungkannya secara konsisten ke berbagai sistem
- UDA mendukung pembuatan skema otomatis, pemetaan, dan otomasi perpindahan data dari model domain ke data container (misalnya GraphQL, Avro, Iceberg, dan lain-lain)
- Pengguna bisnis dapat menelusuri data, membuat laporan, dan mengelola reference data hanya dengan mencari istilah melalui alat berbasis UDA seperti Sphere dan PDM
- Dengan menerapkan metamodel Upper milik sendiri di atas teknologi semantik seperti RDF dan SHACL, Netflix mencapai kolaborasi skala besar, governance, konsistensi skema, dan skalabilitas sekaligus
Meningkatnya kompleksitas sistem Netflix dan tantangan model domain
- Seiring layanan Netflix meluas ke film, serial, game, live event, iklan, dan lainnya, kompleksitas sistem yang mendukungnya juga meningkat tajam
- Konsep bisnis inti seperti
actor dan movie didefinisikan secara terpisah di berbagai sistem berbeda (Enterprise GraphQL Gateway, platform manajemen aset, media computing, dan lain-lain), lalu dioperasikan secara terfragmentasi tanpa kolaborasi atau pembagian yang memadai
- Akibatnya muncul masalah berikut
- Model yang duplikatif dan tidak konsisten: entitas yang sama didefinisikan ulang di sistem yang berbeda, sehingga benturan sulit dicegah
- Ketidakkonsistenan istilah: bahkan dalam sistem yang sama, istilah yang berbeda dipakai untuk hal yang sama, atau istilah yang sama dipakai berulang untuk makna berbeda, sehingga komunikasi menjadi rancu
- Masalah kualitas data: ada banyak ketidakkonsistenan dan error referensi di antara microservice yang sangat banyak, sementara pengelolaan identifier atau external key juga kurang baik sehingga perlu perbaikan manual
- Keterbatasan konektivitas: relasi di dalam sistem terbatas dan keterhubungan antar sistem juga kurang memadai
- Untuk menyelesaikan masalah ini, dibutuhkan fondasi untuk mendefinisikan model konsep sekali lalu menggunakannya kembali di mana pun, sekaligus menghubungkannya secara nyata dengan sistem dan data yang sesungguhnya
Gambaran umum UDA (Unified Data Architecture)
- UDA adalah platform berbasis konektivitas data di dalam Content Engineering Netflix
- Model domain (konsep bisnis) didefinisikan satu kali untuk diproyeksikan secara konsisten ke semua sistem serta mendukung otomasi, discovery, dan semantic interoperability
- Kemampuan utama yang dimungkinkan oleh UDA
- Pendaftaran dan penghubungan model domain: memakai definisi konsep resmi sebagai single source, sehingga mencegah kebingungan antar tim dan pemodelan yang duplikatif
- Pemetaan model domain dan data container: direpresentasikan sebagai struktur graf agar mudah memahami konsep bisnis, lokasi penyimpanan data aktual (database, tabel, service, dan lain-lain), serta strukturnya
- Mengonversi model domain ke schema definition language: otomatis dikonversi untuk berbagai sistem seperti GraphQL, Avro, SQL, RDF, dan Java, sehingga meminimalkan pekerjaan manual dan mengurangi error
- Perpindahan data yang andal antar data container: transformasi dan perpindahan data antar sistem seperti entitas GraphQL, Data Mesh, CDC, dan Iceberg diproses secara otomatis
- Eksplorasi dan pencarian konsep domain: hubungan antar konsep bisnis dapat dieksplorasi dan dicari, sehingga lebih mudah memperoleh informasi yang akurat
- Menyediakan introspeksi knowledge graph secara terprogram: informasi bisnis yang saling terhubung dapat dimanfaatkan melalui Java, GraphQL, dan SPARQL untuk otomasi dan penggalian insight
Arsitektur inti UDA
-
Berbasis Knowledge Graph
- Dengan knowledge graph berbasis RDF/SHACL, semua elemen seperti model domain, skema, data container, dan pemetaan dihubungkan sebagai data graf
- Menggunakan information model yang berpusat pada named graph, sehingga tiap named graph mengikuti model governance yang teratur serta mewujudkan kerangka interpretasi, modularisasi, dan kebijakan operasional
-
Metamodel Upper
- Upper adalah bahasa metamodel yang mendefinisikan model domain secara ketat
- Entitas, atribut, dan relasi kunci per domain dimodelkan sebagai tipe dan hierarki, lalu dapat direpresentasikan dalam RDF, diberi versioning, dan di-query
- Upper sendiri juga dimodelkan dengan Upper (self-referential, self-validating), sehingga memberi konsistensi pada semua ekstensi dan proyeksi
- Nilai atribut dapat disesuaikan per domain, dan semua konsep direpresentasikan sebagai conceptual RDF serta named graph, sehingga mendukung introspection, pencarian, dan versioning
- Selain abstraksi tingkat tinggi, Upper memilih dan menerapkan hanya bagian inti dari teknologi semantik W3C seperti RDFS/OWL/SHACL, sehingga pemodelan domain tetap efektif tanpa harus memahami konsep ontologi secara mendalam
- Dari metamodel Upper, Java API berbasis Jena dan skema GraphQL dibuat secara otomatis, lalu dihubungkan ke service GraphQL nyata
-
Data container dan pemetaan
- Data Container: penyimpanan data aktual (misalnya entitas dari service GraphQL, record Avro dari sumber Data Mesh, baris tabel Iceberg, objek dari Java API, dan sebagainya)
- Pemetaan (Mappings): mendefinisikan hubungan satu banding satu antara elemen tertentu dari model domain dan data container (tabel, field, dan lain-lain)
- Melalui pemetaan, lokasi data aktual untuk suatu konsep domain dapat dilacak, dan sebaliknya data juga dapat ditelusuri ke konsep domain terkait
- Perpindahan data dan otomasi berbasis intent: sistem secara otomatis menentukan aliran dan transformasi data dengan memanfaatkan informasi pemetaan
-
Projections (proyeksi)
- Konversi dan pembuatan otomatis dari model domain ke skema sistem target (misalnya GraphQL, Avro, dan lain-lain), termasuk otomasi kode, skema, dan pipeline
- Menjamin konsistensi skema serta meminimalkan definisi duplikatif dan masalah sinkronisasi
Contoh penerapan nyata
-
PDM (Primary Data Management)
- Platform pengelolaan reference data dan taxonomy (sistem klasifikasi hierarkis)
- Mengubah model domain menjadi klasifikasi hierarkis atau datar, lalu secara otomatis membangun UI untuk pengguna bisnis
- Menyediakan definisi istilah bisnis yang konsisten, berbasis model SKOS, dan dengan UDA dapat menghasilkan skema serta pipeline Avro dan GraphQL secara otomatis
- Cukup memasukkan model domain, maka UI, pipeline data, dan GraphQL API akan dikonfigurasi secara otomatis
-
Sphere (Operational Reporting)
- Alat self-service operational reporting berbasis knowledge graph
- Mengotomatiskan pencarian, penelusuran, dan strategi join berbasis istilah domain, sehingga memungkinkan discovery data dan pembuatan laporan tanpa kompleksitas teknis
- Dengan metadata dan pemetaan berbasis UDA, sistem otomatis memahami dan mengeksekusi hingga lokasi data aktual dan logika join
- Dengan istilah yang familier seperti
actor dan movie, pengguna dapat menelusuri konsep, lalu berdasarkan konsep yang dipilih sistem otomatis menghasilkan query SQL dengan mengikuti knowledge graph, sehingga data bisa diperoleh tanpa join terpisah atau pekerjaan teknis tambahan
Kesimpulan dan prospek
- UDA mendorong perubahan mendasar pada cara Netflix melakukan pemodelan dan integrasi data
- Dengan satu definisi model domain, sistem di seluruh organisasi dapat terhubung secara konsisten, otomatis, dan skalabel
- Ke depan, dukungan tambahan seperti Protobuf/gRPC dan pemanfaatan knowledge graph sebagai data aktual akan memperluas cakupan penerapannya
2 komentar
Saya perlu menyusun hal serupa, tapi terasa buntu.
Opini Hacker News
Terlepas dari semua kelebihannya, saya rasa pendekatan ini punya masalah besar yang tidak sering dibicarakan
Karena ini adalah masalah bisnis yang juga memengaruhi persoalan teknis, pada akhirnya ia menjadi masalah teknis sekunder yang berdampak pada kecepatan pengembangan
Karena bisnis bergantung pada kontrak bahwa seluruh organisasi bisa mempercayai satu definisi data terpadu, saat mendefinisikan atau mengubah data kita kini terpaksa mempertimbangkan berbagai use case di seluruh organisasi, bukan hanya di bidang kita sendiri
Bahkan perubahan kecil pun berdampak ke seluruh organisasi, sehingga muncul proses rumit yang sampai perlu persetujuan dari berbagai pemangku kepentingan
Ini adalah versi data dari masalah klasik di perusahaan besar: "mengapa butuh dua bulan hanya untuk mengganti warna tombol"
Tentu saja, saya mengakui bahwa biasanya menduplikasi data atau menyebarkannya secara tidak konsisten adalah masalah yang lebih serius
Tetapi kadang kita ingin cepat merilis perubahan kecil yang terisolasi, dan sistem seperti ini bisa menjadi hambatan besar
Saya pernah mencoba mengembangkan produk untuk menyelesaikan ini
Saya mencoba pendekatan yang tetap mengikuti model bersama perusahaan tetapi memungkinkan model dilokalkan dan dispesialisasi dengan mudah (memperluas bahasa definisi data mirip Prolog, dan benar-benar memikirkan model perusahaan yang berlandaskan realitas, bukan yang sekadar terdengar perlu saat itu)
Sayangnya, saya mencobanya saat demam NoSQL dan Big Data sedang berada di puncak, jadi waktunya kurang tepat
NoSQL dan Big Data punya budaya bahwa kita bisa beroperasi dengan model yang longgar, dan kalau sebagian data hilang atau disalahpahami, nanti tinggal ditambal
Suasananya lebih condong pada mudah beres-beres di belakang daripada merancang model yang kuat sejak awal, dan meski agak disayangkan, saya menerimanya
Saya setuju bahwa ini pada dasarnya adalah masalah bisnis, dan saya melihat kita bisa menyelesaikannya secara sistematis dengan teknologi
Saya yakin kami telah menyiapkan cara yang lebih sistematis untuk mengadopsi dan menerapkan knowledge graph model-first di dalam enterprise
UDA didekati dengan hati-hati agar tidak justru membuat semua hal yang diminta menjadi tambahan birokrasi
UDA hidup berdampingan dengan sistem yang ada dan tidak memaksa adopsi tanpa syarat
Namun kami ingin menjadikannya alat yang kuat dan mudah bagi tim yang ingin model bisnis mereka bisa digunakan di mana saja serta mudah dihubungkan, diperluas, dan ditemukan
(Saya perlu menyampaikan bahwa saya adalah salah satu arsitek UDA)
Dari pengalaman saya, sering kali model data yang logis atau konsisten gagal terbentuk di perusahaan karena klaim dari para "orang besar (big men)" di dalamnya
Bahkan jika para praktisi teknis ingin menangani data secara lebih rasional dan sesuai standar, realitasnya adalah figur berpengaruh membuat model di kepala mereka sendiri lalu memaksa pengembang menyesuaikan diri
Begitu pola pikir simbolik seperti ini tertanam, peluang perusahaan itu membangun model data yang konsisten mendekati nol
Pada akhirnya saya melihat masalah seperti inilah yang membuat konsultan dibayar tidak efisien dalam jumlah besar
Saya lama penasaran apa itu SAP, lalu saat benar-benar mengetahuinya saya terkejut
Karena begitu banyak perusahaan memakai SAP, saya sempat menduga ada kehebatan teknologi luar biasa, tetapi ternyata pendekatannya adalah memakai skema tetap dan meminta pelanggan beradaptasi dengan struktur itu
Saya tidak membacanya sebagai penyangkalan bahwa ini adalah masalah bisnis dalam artikel aslinya
Sudut pandangnya adalah bahwa model yang didefinisikan itu mencakup semua peran, dan engineering hanyalah salah satunya
Saya merasa sudah cukup lama berlalu sejak Semantic Web, RDF, OWL, SKOS, dan lain-lain muncul
Menyenangkan melihat mereka tetap mendukung W3C dan tidak menemukan kembali roda yang sudah ada
Saya tidak tahu apakah pendekatan UDA akan menjadi arus utama, tetapi saya berharap karena ini terlihat seperti upaya untuk secara inovatif mengurangi kesulitan saat menerapkan DDD (domain-driven design) dan konsep semantik di organisasi berskala besar
Jika bisa memberi banyak tim pengembang alat dan set teknologi bersama untuk berbagi sistem makna data yang sama, lalu mendapatkan efek "compound interest", mungkin kontrak data tidak perlu lagi dipaksa diratakan hanya karena DTO, POST, dan kebutuhan transmisi jaringan lainnya
Saya memandang positif Netflix yang mendorong eksperimen menarik seperti ini secara terbuka
Ini mengingatkan saya pada proyek Dragon di Uber
Saya pernah mengerjakan hal terkait Dragon schema at Uber, tetapi itu tidak pernah di-open-source-kan
Setelah itu Joshua pindah ke LinkedIn dan ikut dalam proyek LambdaGraph serta bahasa Hydra, yang kini dirilis open source di sini
Kekurangan dari pendekatan seperti ini, atau arus Semantic Web sekitar 10 tahun lalu, adalah terlalu besarnya pekerjaan tambahan yang dibutuhkan untuk memformalkan dan memelihara konsep
Sekarang saya penasaran apakah LLM (large language model) bisa mengurangi beban ini
Saya agak menyayangkan pilihan istilah "domain model" yang dipakai kali ini
Domain model di sini murni konsep yang berpusat pada data, padahal esensi domain modeling yang sebenarnya adalah fokus pada behavior, bukan struktur data
Data dalam domain model berperan untuk memungkinkan behavior, dan behavior itulah pusat dari kode
Memang ada kerumitan dalam mengekspresikan data modeling dengan berbagai cara tergantung sudut pandang, tetapi saya juga merasa perbedaan seperti ini justru bisa dilihat sebagai fitur
Tidak semua situasi membutuhkan kompleksitas atau detail yang sama, dan model representasi biasanya dioptimalkan untuk skenario baca
Dengan pendekatan seperti ini, kita bisa jadi lebih condong ke keseragaman daripada penanganan informasi yang kontekstual, dan mungkin skalabilitasnya lebih baik di lingkungan dengan pemahaman domain yang tinggi, tetapi pengalaman saya menunjukkan bahwa tanpa menyederhanakan domain model yang kompleks atau subtil, sebagian besar use case justru menjadi sulit
Ada pertanyaan: "Pernahkah Anda melihat upaya seperti ini menghasilkan perbaikan bisnis kuantitatif lebih dari 5% atau lebih dari 5 juta dolar?"
Saya sudah beberapa kali mengalami upaya untuk menyatukan tabel data, tetapi dalam praktiknya ketika analisis yang dibutuhkan berbeda, penyatuan tabel tidak banyak berarti, dan berbagai analisis tetap dilakukan secara terpisah
Artinya, meskipun layer dasar disatukan agar sesuai dengan cara analisis yang diinginkan semua orang, analisis yang berbeda tetap berjalan terpisah
Meski begitu, upaya kali ini tampaknya tidak memaksa semua hal menjadi satu, melainkan berusaha mempermudah akses yang lebih luas, jadi terlihat bijak
Saya sangat sependapat dengan tujuan menyatukan definisi resmi konsep bisnis agar kebingungan berkurang
Misalnya, walaupun semua orang menginginkan master prison list, definisinya bisa sangat berbeda tergantung apakah prison itu bangunan fisiknya, kumpulan narapidana (entitas terpisah untuk prison pria dan wanita di lokasi yang sama), atau institusi yang beroperasi di bawah kontrak tertentu
Dalam hal seperti ini, tiap perspektif organisasi membutuhkan objek yang sedikit berbeda
Saya penasaran apa hubungannya dengan domain-driven design (DDD)
Bukankah DDD justru berangkat dari asumsi bahwa bahkan konsep yang sama bisa direpresentasikan berbeda di tiap sistem?
Tetapi saya tidak membaca artikelnya sampai akhir karena nuansa UML-nya
Domain dalam upper:DomainModel adalah Domain yang sama dengan D (domain) di DDD, demikian juga DGS (Domain Graph Service)
Dalam DDD, bahkan konsep yang tampak sama boleh direpresentasikan berbeda per sistem, tetapi di UDA berbagai konsep seperti ini dirancang agar hidup berdampingan secara eksplisit di tiap domain
Konsep tentang "sama" menjadi subjektif
Untungnya mereka tidak memakai istilah "ubiquitous language"
Konsep itu sepenuhnya berlawanan dengan upaya ini
Orang yang hanya pernah mendengar istilah terkait tetapi belum pernah mendalaminya mungkin tidak akan tahu perbedaannya
Saya bertanya-tanya mengapa Netflix Engineering mempublikasikan konten di Medium
Dalam situasi ketika pembaca mudah hilang karena popup Medium dan semacamnya, saya penasaran apakah risikonya sepadan
Setiap kali melihat URL Medium berbentuk hex, ada kesenangan tersendiri membaca lewat scribe.rip
Artikel UDA di scribe.rip
Jika ini dikelola tim marketing, mungkin ini bagian dari strategi yang juga mencakup SEO
Efek "discovery" dari Medium memang nyata
Dan para engineer yang suka menulis di Medium mungkin adalah tipe talenta yang ingin direkrut Netflix
Juga lebih praktis karena mereka tidak perlu mengelola blog sendiri
Saya penasaran bagaimana mereka menangani versioning model data atau breaking change
Saat model dijalankan dengan pemisahan yang lebih besar, biasanya potongan-potongan bisa diperbaiki dengan mudah seperti biasa, jadi saya penasaran bagaimana hal itu dilakukan dalam model terpadu seperti ini
Dugaan saya, dalam pendekatan Netflix mereka menambahkan model baru lalu secara bertahap menghentikan penggunaan model lama
Di UDA ini memang belum sepenuhnya diimplementasikan, tetapi rencananya mereka akan memakai pendekatan yang sama seperti Federated GraphQL
Mereka berencana mengadopsi model pengelolaan deprecation yang sudah terbukti di Federated GraphQL, dan punya pengalaman berhasil mengelola lebih dari 500 skema GraphQL terfederasi
Kuncinya adalah roadmap untuk melacak konsumen dari projected models sambil secara proaktif mengelola siklus deprecation
Saya merasa untuk membuat graph terpadu berhasil, tiga hal harus diselesaikan sekaligus: bisnis, komunikasi, dan teknologi
Masalah komunikasinya menuntut dibongkarnya "kemandirian terselubung dari tim-tim otonom"
Harus ada pihak yang berperan sebagai jembatan lintas tim dan juga menganalisis model data
Berbagi skema saja tidak cukup; proses mewawancarai orang secara langsung dan bernegosiasi itu wajib
Dari sisi teknis justru yang paling mudah, dan akan sederhana jika memaksakan "thick schema" seperti Microsoft Graph
Proses ini membutuhkan empati dan kesabaran yang besar
Solusi teknis juga membutuhkan keputusan tegas dari manajemen dan kewenangan eksekusi; jika tiap tim bebas bergerak sesukanya, ide apa pun tidak akan berguna
Dari sisi bisnis, tingkat kesulitannya yang tertinggi
Mengubah proses dan istilah yang sudah dioptimalkan selama 20 tahun sekaligus nyaris mustahil
Pada akhirnya, pekerjaan raksasa ini hanya layak diinvestasikan "sepanjang hidup" jika buy-in seluruh perusahaan benar-benar tercapai
Saya percaya pengenalan kosakata bersama sangat berarti
Namun semakin luas organisasinya—seluruh perusahaan, akuisisi baru, beragam proses bisnis, dimensi waktu—semakin sulit pula hal itu
Mungkin membuat interface yang menghubungkan dua sistem saja bisa cepat, tetapi ketika sebuah enterprise punya banyak layer, saya ragu siapa yang bisa membuat dan terus memelihara DB ideal yang menampung semua pengetahuan di katalog
Sebagian besar upaya yang bertahan dengan sukses biasanya dijalankan pada tingkat yang sangat abstrak atau dibatasi hanya pada use case tertentu
Dari pengalaman, bahkan jika kita mendefinisikan entitas lintas perusahaan (misalnya entitas resmi perusahaan), tiap departemen tetap perlu memperluasnya, lalu muncul keputusan yang bersifat politis dan optimistis tentang apakah atribut baru itu harus tersedia untuk semua departemen atau hanya untuk departemen tersebut
Jika entitas resmi diperbarui, perlu change management yang ketat sambil menilai dampaknya ke seluruh organisasi
Jika dibangun dengan benar dan didukung budaya organisasi yang disiplin, biaya dan friksi bisa banyak berkurang, dan untuk Netflix hal ini tampak mungkin
Wikidata disebut sebagai satu-satunya contoh kosakata bersama berskala besar yang benar-benar bertahan
Sebanyak 1,65 miliar node graph terus berkembang di bawah kosakata standar