- Netflix đang đối mặt với các vấn đề về cộng tác và chất lượng dữ liệu do việc mô hình hóa dữ liệu cho các miền nghiệp vụ (ví dụ: phim, diễn viên, series, v.v.) bị trùng lặp, không nhất quán và dùng thuật ngữ không chuẩn ở từng hệ thống
- UDA (Kiến trúc dữ liệu hợp nhất) hướng tới mục tiêu 'mô hình hóa một lần, biểu diễn ở mọi nơi', là một hạ tầng dựa trên knowledge graph giúp định nghĩa khái niệm miền một lần rồi chiếu và liên kết nhất quán sang nhiều hệ thống khác nhau
- UDA hỗ trợ tự động sinh schema, ánh xạ và tự động hóa di chuyển dữ liệu từ mô hình miền → data container (ví dụ: GraphQL, Avro, Iceberg, v.v.)
- Người dùng nghiệp vụ có thể dùng các công cụ tận dụng UDA như Sphere và PDM để khám phá dữ liệu, tạo báo cáo và quản lý dữ liệu tham chiếu chỉ bằng cách tìm kiếm thuật ngữ
- Áp dụng metamodel Upper riêng trên nền các công nghệ ngữ nghĩa như RDF và SHACL để đồng thời đạt được cộng tác ở quy mô lớn, quản trị, tính nhất quán schema và khả năng mở rộng
Độ phức tạp ngày càng tăng của hệ thống Netflix và thách thức của mô hình miền
- Khi dịch vụ Netflix mở rộng sang phim, series, game, sự kiện trực tiếp, quảng cáo, v.v., độ phức tạp của hệ thống hỗ trợ chúng cũng tăng mạnh
- Các khái niệm nghiệp vụ cốt lõi như
actor, movie được định nghĩa riêng rẽ trong các hệ thống khác nhau (Enterprise GraphQL Gateway, nền tảng quản lý tài sản, media computing, v.v.) và được vận hành rời rạc, thiếu cộng tác hay chia sẻ
- Điều này dẫn đến các vấn đề sau
- Mô hình trùng lặp và không nhất quán: cùng một thực thể bị định nghĩa lại ở các hệ thống khác nhau, gây khó khăn cho việc tránh xung đột
- Thuật ngữ không nhất quán: ngay trong cùng một hệ thống cũng dùng các thuật ngữ khác nhau hoặc dùng trùng cùng một thuật ngữ, gây nhiễu trong giao tiếp
- Vấn đề chất lượng dữ liệu: tồn tại sai lệch và lỗi tham chiếu giữa rất nhiều microservice, việc quản lý identifier hay external key cũng chưa đầy đủ nên cần chỉnh sửa thủ công
- Giới hạn về tính kết nối: quan hệ trong từng hệ thống bị hạn chế và liên kết giữa các hệ thống cũng chưa đầy đủ
- Để giải quyết các vấn đề này, cần một nền tảng có thể định nghĩa mô hình khái niệm một lần rồi tái sử dụng ở mọi nơi, đồng thời kết nối và tích hợp thực chất với các hệ thống và dữ liệu thực tế
Tổng quan về UDA (Unified Data Architecture)
- UDA là nền tảng dựa trên tính kết nối dữ liệu trong bộ phận Content Engineering của Netflix
- Định nghĩa mô hình miền (khái niệm nghiệp vụ) một lần để hỗ trợ chiếu nhất quán sang mọi hệ thống, cùng với tự động hóa, khám phá và khả năng tương tác ngữ nghĩa
- Các chức năng chính có thể thực hiện với UDA
- Đăng ký và liên kết mô hình miền: dùng định nghĩa khái niệm chính thức làm nguồn duy nhất, ngăn ngừa nhầm lẫn giữa các nhóm và tránh mô hình hóa trùng lặp
- Ánh xạ mô hình miền với data container: biểu diễn dưới dạng cấu trúc đồ thị để dễ xác định khái niệm nghiệp vụ và nơi dữ liệu thực được lưu trữ (database, bảng, service, v.v.) cùng cấu trúc của chúng
- Chuyển mô hình miền sang ngôn ngữ định nghĩa schema: tự động chuyển đổi cho nhiều hệ thống như GraphQL, Avro, SQL, RDF, Java, v.v., giúp giảm thao tác thủ công và lỗi phát sinh
- Di chuyển dữ liệu tin cậy giữa các data container: tự động xử lý việc chuyển đổi và dịch chuyển dữ liệu giữa các hệ thống như GraphQL entity, Data Mesh, CDC, Iceberg, v.v.
- Khám phá và tìm kiếm khái niệm miền: có thể duyệt và tìm kiếm quan hệ giữa các khái niệm nghiệp vụ, giúp tiếp cận thông tin chính xác dễ dàng hơn
- Cung cấp introspection lập trình được cho knowledge graph: tận dụng thông tin nghiệp vụ được liên kết qua Java, GraphQL, SPARQL để tự động hóa và rút ra insight
Kiến trúc cốt lõi của UDA
-
Dựa trên Knowledge Graph
- Là knowledge graph dựa trên RDF/SHACL, kết nối mọi thành phần như mô hình miền, schema, data container và mapping dưới dạng dữ liệu đồ thị
- Với mô hình thông tin lấy named graph làm trung tâm, mỗi named graph tuân theo mô hình quản trị có quy tắc, hiện thực hóa cơ chế diễn giải, mô-đun hóa và chính sách vận hành
-
Metamodel Upper
- Upper là ngôn ngữ metamodel định nghĩa chặt chẽ mô hình miền
- Mô hình hóa các thực thể/thuộc tính/quan hệ khóa theo từng miền bằng kiểu và phân cấp, có thể biểu diễn, quản lý phiên bản và truy vấn bằng RDF
- Bản thân Upper cũng được mô hình hóa bằng chính Upper (tự tham chiếu, tự xác thực), mang lại tính nhất quán cho mọi mở rộng và projection
- Có thể tùy biến theo miền cho giá trị thuộc tính, và mọi khái niệm đều được biểu diễn bằng conceptual RDF và named graph, hỗ trợ introspection, tìm kiếm và quản lý phiên bản
- Cùng với mức trừu tượng cao, Upper chỉ chọn lọc áp dụng những phần cốt lõi của các công nghệ ngữ nghĩa W3C như RDFS/OWL/SHACL, giúp mô hình hóa miền hiệu quả ngay cả khi không am hiểu sâu về ontology
- Từ metamodel Upper, tự động sinh Java API dựa trên Jena và GraphQL schema, rồi liên kết với dịch vụ GraphQL thực tế
-
Data Container và Mapping
- Data Container: kho lưu trữ dữ liệu thực tế (ví dụ: entity của dịch vụ GraphQL, bản ghi Avro của nguồn Data Mesh, hàng của bảng Iceberg, object của Java API, v.v.)
- Mapping: định nghĩa liên kết một-một giữa các phần tử cụ thể của mô hình miền và data container (bảng, trường, v.v.)
- Thông qua mapping, có thể lần theo khái niệm miền → vị trí dữ liệu thực, và ngược lại từ dữ liệu → khái niệm miền liên quan
- Di chuyển dữ liệu/tự động hóa dựa trên ý định: hệ thống dùng thông tin mapping để tự quyết định luồng dữ liệu và phép biến đổi
-
Projection
- Tự động chuyển đổi và sinh mô hình miền → schema của hệ thống đích (ví dụ: GraphQL, Avro, v.v.), bao gồm tự động hóa code, schema và pipeline
- Bảo đảm tính nhất quán của schema, giảm thiểu định nghĩa trùng lặp và vấn đề đồng bộ hóa
Các trường hợp áp dụng thực tế
-
PDM (Primary Data Management)
- Nền tảng quản lý dữ liệu tham chiếu và taxonomy (hệ thống phân loại phân cấp)
- Chuyển mô hình miền thành phân loại dạng phân cấp hoặc phẳng, tự động sinh UI cho người dùng nghiệp vụ
- Định nghĩa nhất quán các thuật ngữ nghiệp vụ, dựa trên mô hình SKOS, và dùng UDA để tự động sinh schema/pipeline Avro và GraphQL
- Chỉ cần nhập mô hình miền, hệ thống sẽ tự động cấu hình UI/data pipeline/GraphQL API
-
Sphere (Operational Reporting)
- Công cụ báo cáo vận hành self-service dựa trên knowledge graph
- Tự động hóa tìm kiếm, khám phá và chiến lược join dựa trên thuật ngữ miền, cho phép khám phá dữ liệu/tạo báo cáo mà không cần xử lý độ phức tạp kỹ thuật
- Với metadata/mapping dựa trên UDA, hệ thống tự nhận biết và thực thi cả vị trí dữ liệu thực tế lẫn logic join
- Có thể khám phá khái niệm bằng các thuật ngữ quen thuộc như
actor, movie, và dựa trên các khái niệm đã chọn, tự động sinh truy vấn SQL theo knowledge graph để lấy dữ liệu mà không cần join riêng hay thao tác kỹ thuật bổ sung
Kết luận và triển vọng
- UDA đang thúc đẩy thay đổi căn bản trong cách Netflix mô hình hóa và tích hợp dữ liệu
- Chỉ với một lần định nghĩa mô hình miền, các hệ thống trên toàn tổ chức có thể liên kết dữ liệu theo cách nhất quán, tự động và có khả năng mở rộng
- Trong tương lai, phạm vi áp dụng sẽ tiếp tục mở rộng như hỗ trợ thêm Protobuf/gRPC và hiện thực hóa dữ liệu thực trên knowledge graph
2 bình luận
Mình cũng cần xây dựng thứ tương tự mà thấy khá mông lung.
Ý kiến trên Hacker News
Dù có mọi ưu điểm, tôi nghĩ cách này có một vấn đề lớn nhưng không thường được nhắc đến
Vì đây là vấn đề kinh doanh đồng thời ảnh hưởng tới cả vấn đề kỹ thuật, nên cuối cùng nó trở thành một vấn đề kỹ thuật thứ cấp làm chậm tốc độ phát triển
Khi hoạt động kinh doanh phụ thuộc vào một cam kết rằng toàn bộ tổ chức có thể tin tưởng vào một định nghĩa dữ liệu hợp nhất, thì mỗi khi định nghĩa hay sửa dữ liệu, bạn buộc phải cân nhắc không chỉ lĩnh vực của mình mà còn rất nhiều trường hợp sử dụng trên toàn tổ chức
Ngay cả thay đổi nhỏ cũng ảnh hưởng đến cả tổ chức, nên quy trình trở nên phức tạp tới mức phải có sự phê duyệt của nhiều bên liên quan
Đây là phiên bản dữ liệu của vấn đề kinh điển ở các công ty lớn: "vì sao đổi màu một cái nút cũng mất hai tháng"
Tất nhiên, tôi thừa nhận rằng việc sao chép dữ liệu hoặc phân tán thiếu nhất quán thường còn là vấn đề nghiêm trọng hơn
Nhưng đôi khi, khi muốn triển khai nhanh một thay đổi nhỏ và biệt lập, kiểu hệ thống này lại trở thành rào cản lớn
Tôi từng thử phát triển một sản phẩm để giải quyết chuyện này
Tôi đã thử một cách cho phép vừa tuân theo mô hình chung của doanh nghiệp, vừa dễ dàng chuyên biệt hóa mô hình ở mức cục bộ (mở rộng một ngôn ngữ định nghĩa dữ liệu kiểu Prolog, và thực sự suy nghĩ nghiêm túc về mô hình doanh nghiệp dựa trên thực tế chứ không phải những thứ cần ngay trước mắt)
Đáng tiếc là tôi làm việc đó đúng lúc làn sóng NoSQL và Big Data đang lên cao, nên thời điểm không thuận lợi
NoSQL và Big Data mang văn hóa vận hành với mô hình lỏng lẻo, và dù dữ liệu có bị mất một phần hay bị hiểu sai thì cũng vá víu sau
Bầu không khí khi đó thiên về việc hậu xử lý cho dễ hơn là thiết kế một mô hình mạnh ngay từ đầu, hơi đáng tiếc nhưng tôi cũng chấp nhận
Tôi đồng ý rằng về bản chất đây là vấn đề kinh doanh, và chúng tôi tin có thể giải quyết nó một cách có hệ thống bằng công nghệ
Chúng tôi tự tin đã chuẩn bị được một cách bài bản hơn để đưa vào và triển khai knowledge graph theo hướng model-first trong doanh nghiệp
UDA được tiếp cận cẩn trọng để việc bổ sung mọi thứ được yêu cầu không biến thành thêm tầng quan liêu
UDA tồn tại song song với các hệ thống hiện có và không ép buộc phải chấp nhận vô điều kiện
Nhưng chúng tôi muốn nó trở thành một công cụ mạnh và dễ dùng cho những đội muốn mô hình kinh doanh của mình có thể được dùng ở khắp nơi, dễ kết nối, mở rộng và khám phá
(Xin nói rõ là tôi là một trong các kiến trúc sư của UDA)
Theo kinh nghiệm của tôi, nhiều khi không thể tạo ra một mô hình dữ liệu logic hay nhất quán trong công ty vì các tuyên bố của những "big men" trong nội bộ
Dù các kỹ sư thực thi muốn xử lý dữ liệu hợp lý hơn và theo chuẩn hơn, thực tế là những người có ảnh hưởng tự dựng mô hình trong đầu rồi ép lập trình viên phải làm theo
Một khi kiểu tư duy mang tính biểu tượng đó đã ăn sâu, khả năng tạo ra một mô hình dữ liệu nhất quán ở công ty đó gần như tiến về 0
Cuối cùng, tôi cho rằng chính những vấn đề như vậy khiến người ta phải trả quá nhiều tiền một cách kém hiệu quả cho các consultant
Tôi đã từng thắc mắc rất lâu SAP là gì, và khi thực sự biết thì khá bất ngờ
Vì quá nhiều doanh nghiệp dùng SAP nên tôi từng đoán chắc nó phải có năng lực kỹ thuật rất ghê gớm, nhưng thực ra đó là một cách tiếp cận dùng schema cố định rồi yêu cầu khách hàng tự thích nghi với cấu trúc đó
Tôi không thấy bài gốc phủ nhận chuyện đây là vấn đề kinh doanh
Quan điểm ở đây là các mô hình được định nghĩa xuyên suốt mọi vai trò, và engineering chỉ là một phần trong đó
Tôi thấy đã khá lâu kể từ khi Semantic Web, RDF, OWL, SKOS xuất hiện
Tôi thích việc họ vẫn tiếp tục ủng hộ W3C và không phát minh lại bánh xe đã có
Tôi không biết cách tiếp cận UDA có trở nên phổ biến hay không, nhưng tôi kỳ vọng đây là một nỗ lực giúp giảm bớt khó khăn theo hướng đột phá khi áp dụng DDD (domain-driven design) và các khái niệm ngữ nghĩa ở những tổ chức quy mô lớn
Nếu có thể cung cấp cho nhiều đội phát triển một bộ công cụ và tập công nghệ chung để chia sẻ cùng một hệ ý nghĩa dữ liệu, qua đó tạo ra hiệu ứng "lãi kép (compound interest)", thì có lẽ sẽ không còn phải ép làm phẳng các data contract thành DTO, POST v.v. chỉ vì nhu cầu truyền qua mạng
Tôi có cái nhìn tích cực với Netflix khi họ công khai theo đuổi một thử nghiệm thú vị như vậy
Tôi nhớ đến một dự án tên Dragon ở Uber
Tôi từng làm việc liên quan tới Dragon schema at Uber, nhưng nó đã không thể open source
Sau đó Joshua chuyển sang LinkedIn, tham gia dự án LambdaGraph và ngôn ngữ Hydra, và những thứ này đã được open source tại đây
Nhược điểm của những cách làm như vậy, hay của cả làn sóng Semantic Web 10 năm trước, là lượng công việc bổ sung để hình thức hóa và duy trì các khái niệm quá lớn
Gần đây tôi tự hỏi liệu LLM (mô hình ngôn ngữ lớn) có thể giúp giảm bớt gánh nặng đó hay không
Tôi thấy hơi tiếc về việc lần này họ chọn dùng thuật ngữ "domain model"
Domain model ở đây là một khái niệm thuần túy lấy dữ liệu làm trung tâm, trong khi domain modeling thực sự về bản chất tập trung vào behavior hơn là cấu trúc dữ liệu
Dữ liệu trong domain model tồn tại để cho phép behavior, và chính behavior mới là trung tâm của code
Việc biểu diễn data modeling theo nhiều góc nhìn vốn đã phức tạp, nhưng tôi nghĩ sự khác biệt này cũng có thể được xem là một tính năng
Không phải tình huống nào cũng cần cùng một mức độ phức tạp hay độ chi tiết, và representation model thường được tối ưu cho các kịch bản đọc
Dùng cách này có thể dẫn tới việc thiên về tính thống nhất hơn là xử lý thông tin theo từng ngữ cảnh; trong môi trường có hiểu biết domain cao thì khả năng mở rộng có thể tốt hơn, nhưng trải nghiệm thực tế của tôi là phần lớn use case sẽ trở nên khó khăn trừ khi ta đơn giản hóa các domain model phức tạp hoặc tinh vi
Có người hỏi: "Đã từng thấy trường hợp nào kiểu nỗ lực này mang lại cải thiện kinh doanh định lượng trên 5% hoặc hơn 5 triệu USD chưa?"
Tôi đã nhiều lần trải qua các nỗ lực hợp nhất bảng dữ liệu, nhưng trên thực tế nếu cần các phân tích khác nhau thì việc hợp nhất bảng thường không có nhiều ý nghĩa, và các kiểu phân tích khác nhau vẫn tiếp tục diễn ra độc lập
Tức là, dù có hợp nhất lớp nền theo cách phân tích mà mọi người mong muốn, thì các phân tích khác nhau vẫn tiếp tục tách riêng
Dù vậy, nỗ lực lần này có vẻ không ép mọi thứ phải hợp nhất thành một, mà muốn tăng tính dễ tiếp cận trên diện rộng, nên trông khá khôn ngoan
Tôi rất đồng cảm với mục tiêu thống nhất các định nghĩa chính thức về khái niệm kinh doanh để giảm bớt nhầm lẫn
Ví dụ, ngay cả khi ai cũng muốn một master prison list, thì "prison" có thể là chính tòa nhà, hoặc là tập hợp tù nhân (ví dụ nhà tù nam và nữ trên cùng một khu đất là các thực thể riêng), hoặc là một tổ chức được vận hành theo một hợp đồng cụ thể; tùy định nghĩa mà khác hoàn toàn
Theo nghĩa đó, mỗi góc nhìn trong tổ chức lại cần những đối tượng hơi khác nhau
Tôi tò mò nó liên quan thế nào tới domain-driven design (DDD)
Chẳng phải DDD giả định rằng ngay cả cùng một khái niệm cũng có thể được biểu diễn khác nhau ở mỗi hệ thống sao?
Nhưng bản thân bài viết mang cảm giác UML nên tôi không đọc hết
Domain trong upper:DomainModel cũng chính là chữ D (domain) trong DDD, và DGS (Domain Graph Service) cũng vậy
Trong DDD, cùng một khái niệm có thể được phép biểu diễn khác nhau giữa các hệ thống cùng lúc; còn trong UDA, hệ thống được thiết kế để những khái niệm đa dạng như vậy cùng tồn tại một cách tường minh trong từng domain
Khái niệm "giống nhau" trở nên mang tính chủ quan
Tôi lại thấy may vì họ không dùng thuật ngữ "ubiquitous language"
Khái niệm đó hoàn toàn đối lập với nỗ lực lần này
Những người chỉ nghe các khái niệm liên quan mà chưa từng đào sâu có thể sẽ không nhận ra sự khác biệt
Tôi thắc mắc vì sao Netflix Engineering lại đăng nội dung lên Medium
Medium với đủ loại popup khiến rất dễ mất độc giả, nên tôi không rõ có đáng để chấp nhận rủi ro đó không
Mỗi lần thấy URL Medium dạng hex, tôi lại thấy vui vì có thể đọc qua scribe.rip
Bài UDA trên scribe.rip
Nếu đội marketing vận hành việc này thì có thể đây là chiến lược bao gồm cả SEO
Hiệu ứng "discovery" mà Medium mang lại là có thật
Và những kỹ sư có phong cách viết bài trên Medium rất có thể cũng chính là nhóm nhân tài mà Netflix muốn tuyển dụng
Cũng tiện hơn vì không phải tự quản lý blog riêng
Tôi tò mò họ xử lý versioning của data model hoặc breaking change như thế nào
Khi vận hành mô hình tách rời hơn thì có thể sửa từng phần dễ dàng theo cách cũ, nhưng với mô hình hợp nhất như thế này thì sẽ làm sao?
Tôi đoán theo cách của Netflix thì sẽ thêm model mới rồi dần dần ngừng dùng model cũ
Trong UDA, dù chưa được triển khai hoàn chỉnh, chúng tôi dự định áp dụng cách làm giống Federated GraphQL
Chúng tôi sẽ đưa vào mô hình quản lý deprecation đã được kiểm chứng trong Federated GraphQL, và đã có kinh nghiệm quản lý thành công hơn 500 schema GraphQL liên kết
Cốt lõi là roadmap theo dõi consumer của các projected model và chủ động quản lý chu kỳ deprecated
Tôi cảm nhận để một unified graph thành công thì phải giải được cả ba mặt: kinh doanh, giao tiếp và kỹ thuật
Vấn đề giao tiếp đòi hỏi phải phá vỡ kiểu "độc lập ngầm" của các đội tự chủ
Cần có người đóng vai trò cây cầu xuyên qua các đội, đồng thời cũng phân tích data model
Chỉ chia sẻ schema thì không đủ; nhất thiết phải có quá trình trực tiếp phỏng vấn con người và thương lượng
Mặt kỹ thuật thực ra lại là dễ nhất, và nếu áp đặt một "thick schema" như Microsoft Graph thì khá đơn giản
Quá trình này đòi hỏi rất nhiều sự đồng cảm và kiên nhẫn
Giải pháp kỹ thuật bắt buộc phải có quyết định dứt khoát từ ban lãnh đạo và quyền thực thi; nếu từng đội vẫn được tự do hành động riêng thì ý tưởng nào cũng vô dụng
Khía cạnh kinh doanh là khó nhất
Việc thay đổi một lúc các quy trình và thuật ngữ đã được tối ưu suốt 20 năm thực tế gần như bất khả thi
Cuối cùng, chỉ khi có buy-in hoàn toàn trên toàn công ty thì công việc đồ sộ này mới đáng để đầu tư trong "cả đời"
Tôi tin rằng việc đưa vào một bộ từ vựng chung là rất có ý nghĩa
Nhưng khi tổ chức mở rộng ra toàn doanh nghiệp, thêm các vụ thâu tóm mới, nhiều quy trình kinh doanh và cả trục thời gian, thì nó ngày càng khó hơn
Kết nối giao diện giữa hai hệ thống thì có thể làm rất nhanh, nhưng trong một enterprise có nhiều layer, và nếu nói đến một DB lý tưởng chứa toàn bộ tri thức trong catalog thì tôi nghi ngờ ai có thể tạo ra rồi liên tục duy trì được nó
Những nỗ lực còn tồn tại thành công phần lớn đều hoặc vận hành ở mức rất trừu tượng, hoặc giới hạn phạm vi vào một use case cụ thể
Theo kinh nghiệm của tôi, ngay cả khi định nghĩa các entity toàn doanh nghiệp (ví dụ thực thể chính thức của công ty), từng phòng ban vẫn sẽ nảy sinh nhu cầu mở rộng chúng; rồi sẽ xuất hiện những quyết định mang tính chính trị và lạc quan như thuộc tính mới đó nên dùng được cho mọi phòng ban hay chỉ phòng ban đó
Khi cập nhật entity chính thức, cần quản lý thay đổi rất chặt chẽ đồng thời đánh giá tác động trên toàn bộ hệ thống
Nếu xây dựng đúng cách và có văn hóa tổ chức đủ kỷ luật hỗ trợ, chi phí và ma sát có thể giảm mạnh, và với Netflix thì điều đó có vẻ khả thi
Một ví dụ gần như duy nhất về bộ từ vựng chung quy mô lớn còn tồn tại là Wikidata
1,65 tỷ graph node đang tiếp tục mở rộng dưới một bộ từ vựng chuẩn