Mô hình hóa kho dữ liệu dựa trên Data Vault 2.0

1. Tổng quan

A. Định nghĩa

Data Vault 2.0 là phương pháp luận mô hình hóa dữ liệu dành cho kho dữ liệu (data warehouse) có khả năng mở rộng và thích ứng với thay đổi nghiệp vụ, trong đó dữ liệu được tách thành Hub lưu giữ khóa nghiệp vụ, Link biểu diễn quan hệ và Satellite lưu ngữ cảnh cùng lịch sử, đồng thời thiết kế Raw Vault và Business Vault xoay quanh nạp song song, bảo toàn lịch sử và khả năng kiểm toán.

Data Vault không phải là một sản phẩm cơ sở dữ liệu cụ thể hay một khuôn mẫu bảng đơn thuần. Trong bối cảnh hệ thống nghiệp vụ liên tục được bổ sung và lược đồ nguồn thay đổi, nó đưa ra đồng thời cấu trúc lưu trữ và nguyên tắc nạp dữ liệu để có thể nạp dữ liệu nguồn với tổn thất thấp nhất và về sau tái hiện được quy tắc nghiệp vụ cũng như yêu cầu phân tích. Vì vậy, nếu chỉ thuộc lòng tên ba loại bảng Hub, Link, Satellite thì bài làm sẽ bỏ lỡ phần cốt lõi. Cốt lõi nằm ở việc tách định danh và quan hệ, ngữ cảnh và lịch sử theo các tốc độ thay đổi khác nhau để khoanh vùng tác động của thay đổi.

Mô hình chiều (dimensional model) truyền thống cung cấp star schema thuận tiện cho truy vấn phân tích ngay, nhưng khi có nguồn hoặc thuộc tính mới, thường phải điều chỉnh lại bảng chiều và bảng sự kiện. Ngược lại, Data Vault ghi nhận sự thật từ nguồn vào Raw Vault trước, rồi thực hiện quy tắc nghiệp vụ và tối ưu hiệu năng mà người dùng cần ở Business Vault và tầng cung cấp thông tin. Sự tách biệt này giúp không đòi hỏi quá mức một mô hình duy nhất phải đồng thời đạt hai mục tiêu khác nhau là bảo toàn nguồn và tiện lợi khi sử dụng.

Việc bảo toàn lịch sử của Data Vault khác với sao lưu đơn thuần. Cần truy vết được khóa và thuộc tính nào đã đi vào từ nguồn nào, vào thời điểm nào, giá trị đó có hiệu lực khi nào và lô nạp nào đã tạo ra chúng. Tính thời gian và nguồn gốc này là nền tảng để tái hiện kết quả trong phân tích tài chính, khách hàng, chuỗi cung ứng, truy ngược nguyên nhân lỗi dữ liệu và ứng phó kiểm toán theo quy định.

B. Bối cảnh ra đời và sự cần thiết

Thứ nhất, môi trường dữ liệu doanh nghiệp liên tục tăng số nguồn do mua bán - sáp nhập, áp dụng SaaS, tái cơ cấu tổ chức và tách microservice. Một kho dữ liệu ban đầu chỉ tích hợp một hệ thống ERP, khi kết nối thêm CRM, nền tảng đặt hàng, IoT, dữ liệu đối tác bên ngoài thì quy tắc nhận diện cùng một khách hàng và chu kỳ cập nhật sẽ khác nhau. Nếu cố tích hợp hoàn hảo mọi nguồn ngay từ đầu, việc thống nhất mô hình chung sẽ trở thành nút thắt, và thiết kế có thể lỗi thời trước khi yêu cầu được chốt.

Thứ hai, nếu kết quả phân tích chỉ hiển thị giá trị hiện tại thì khó tái hiện các quyết định trong quá khứ. Khi hạng khách hàng hay phân loại sản phẩm thay đổi, nếu phân loại lại đơn hàng cũ theo tiêu chí hiện tại thì kết quả sẽ khác với báo cáo thời điểm đó. Data Vault tách thời điểm quan sát, thời điểm nạp, định danh nguồn và lịch sử thay đổi để phân biệt "khi đó dữ liệu là gì" với "hiện nay nghiệp vụ diễn giải thế nào".

Thứ ba, cần song song hóa pipeline nạp dữ liệu theo từng nguồn. Nếu dồn mọi phép biến đổi vào một bảng tích hợp trung tâm cùng lúc, độ trễ hoặc thay đổi lược đồ của một nguồn sẽ chặn toàn bộ quá trình nạp. Khi phân rã thành Hub, Link, Satellite theo đơn vị khóa nghiệp vụ và quan hệ, có thể vận hành độc lập việc thu thập theo nguồn và nạp lịch sử theo thuộc tính.

Thứ tư, trong data lake và kho dữ liệu đám mây, chi phí ứng phó thay đổi và tự động hóa vận hành có thể lớn hơn chi phí lưu trữ. Data Vault tách tầng bảo toàn nguồn, tầng lịch sử và tầng quy tắc, giúp dễ áp dụng sinh mã tự động dựa trên metadata và các mẫu nạp có thể lặp lại. Tuy nhiên, lưu toàn bộ dữ liệu nguồn không phải lúc nào cũng tốt, cần thiết kế đồng thời chính sách thu thập tối thiểu dữ liệu cá nhân và thời hạn lưu giữ.

C. Mục tiêu cốt lõi và phạm vi áp dụng

Mục tiêu thứ nhất của Data Vault là khả năng thích ứng với thay đổi. Thuộc tính mới có thể được tiếp nhận bằng cách thêm Satellite hoặc mở rộng cấu trúc lịch sử của Satellite hiện có, còn quan hệ mới có thể tách thành Link. Điều này cho phép chỉ sửa vùng có thay đổi thay vì viết lại toàn bộ mô hình tích hợp mỗi lần.

Mục tiêu thứ hai là khả năng kiểm toán và tái hiện. Nếu mỗi dòng lưu giữ metadata kỹ thuật như hệ thống nguồn, thời điểm nạp, định danh lô, thời điểm hiệu lực của bản ghi thì có thể giải thích kết quả đến từ đâu. Tuy nhiên, có metadata kỹ thuật không có nghĩa là ngữ nghĩa tự động nhất quán, nên cần liên kết riêng thuật ngữ nghiệp vụ, hợp đồng dữ liệu (data contract) và quy tắc chất lượng.

Mục tiêu thứ ba là tính song song và khả năng mở rộng. Nạp thông tin khách hàng và thông tin hợp đồng, quan hệ đơn hàng và thanh toán như các luồng độc lập, xử lý song song Satellite của nhiều nguồn thì có thể kết hợp batch quy mô lớn với streaming. Khi đó, tính song song không tự sinh ra chỉ bằng cách chia nhỏ bảng, mà tiền đề là thiết kế tính lũy đẳng (idempotency) kiểm soát sự kiện trùng lặp, đảo thứ tự, xử lý lại và xung đột khóa.

Phạm vi phù hợp với Data Vault là các nền tảng phân tích tích hợp có nhiều nguồn, thay đổi thường xuyên và coi trọng lịch sử dài hạn cùng khả năng truy vết. Ngược lại, với báo cáo đơn giản từ một nguồn hay cơ sở dữ liệu nghiệp vụ quy mô nhỏ, chi phí phụ trội khi đưa vào Hub, Link, Satellite có thể lớn hơn. Trong bài làm Kỹ sư chuyên nghiệp (Professional Engineer), không nên khẳng định "áp dụng cho mọi kho dữ liệu", mà cần đánh giá việc áp dụng theo tốc độ thay đổi, mức độ kiểm toán, độ trễ phân tích và năng lực vận hành.

2. Thành phần và luồng dữ liệu

A. Cấu trúc tổng thể

flowchart LR
    A[Hệ thống nguồn nghiệp vụ] --> B[Vùng thu thập·CDC·batch]
    B --> C[Raw Vault]
    C --> H[Hub<br/>Khóa nghiệp vụ]
    C --> L[Link<br/>Quan hệ·Sự kiện]
    C --> S[Satellite<br/>Thuộc tính·Lịch sử·Nguồn gốc]
    H --> BV[Business Vault<br/>Quy tắc·Dẫn xuất·PIT]
    L --> BV
    S --> BV
    BV --> M[Tầng cung cấp thông tin<br/>Chiều·Mart·API]
    M --> U[BI·AI·Dịch vụ nghiệp vụ]

Hệ thống nguồn như ERP, CRM, đặt hàng, thanh toán, cảm biến, tệp, API bên ngoài có lược đồ và chu kỳ cập nhật khác nhau. Tầng thu thập không chuyển toàn bộ dữ liệu sang ngữ nghĩa nghiệp vụ một lần, mà bảo toàn định danh nguồn và sự kiện thay đổi rồi chuyển vào Raw Vault. Khi dùng CDC, cần quản lý cả thứ tự các sự kiện tạo, sửa, xóa và vị trí xử lý lại; khi dùng tệp batch, cần quản lý hash của tệp và thời điểm nhận.

Raw Vault là tầng bảo toàn sự thật nguồn với mức gia công thấp nhất có thể. Ở đây "không gia công" không có nghĩa là lưu vô hạn mọi bản gốc, mà là không tùy tiện ghi đè ngữ nghĩa nghiệp vụ và chuẩn hóa theo các quy tắc có thể truy vết. Có thể cần các xử lý kỹ thuật như mã hóa ký tự, thời gian chuẩn, chuẩn hóa khóa, nhưng không được làm mất giá trị nguồn và lịch sử biến đổi.

Business Vault là tầng kết hợp nhiều nguồn và áp dụng các quy tắc dẫn xuất cần cho phân tích nghiệp vụ. Bảng Point-in-Time, bảng Bridge, cờ trạng thái hiện tại, đánh giá hiệu lực, kết quả khử trùng lặp v.v. có thể nằm ở tầng này. Nhờ vậy Raw Vault vẫn ổn định trước thay đổi nguồn, còn thay đổi chính sách có thể được quản lý phiên bản tại Business Vault.

Tầng cung cấp thông tin được tổ chức thành star schema, bảng rộng (wide table), data mart, feature view v.v. phù hợp với truy vấn của người dùng và hiệu năng công cụ. Người dùng cuối nên sử dụng các sản phẩm dữ liệu có ngữ nghĩa rõ ràng và SLO chất lượng được định nghĩa, thay vì join trực tiếp Hub hay Satellite. Tính chuẩn hóa và khả năng kiểm toán của Raw Vault với tính tiện dụng và hiệu năng của mart là các mục tiêu tối ưu khác nhau, nên việc tách tầng là cốt lõi của thiết kế.

B. Hub: trung tâm ổn định của khóa nghiệp vụ

Hub biểu diễn các thực thể nghiệp vụ cốt lõi được định danh độc lập trong nghiệp vụ như mã khách hàng, số hợp đồng, mã sản phẩm, số tài khoản. Trung tâm của Hub là khóa nghiệp vụ (business key); cần một định danh chỉ cùng một đối tượng về mặt nghiệp vụ ngay cả khi nguồn thay đổi, chứ không phải số tự tăng của cơ sở dữ liệu. Nếu có nhiều nguồn, cần lưu cả mã hệ thống nguồn và khóa nguồn để tránh xung đột, đồng thời làm rõ định danh tích hợp và quan hệ ánh xạ.

Hub thường có các thuộc tính như Hub Key, Business Key, Load Date, Record Source. Hub Key mang lại sự ổn định cho join và tham chiếu, còn Business Key là căn cứ cho ngữ nghĩa nghiệp vụ và phán định trùng lặp. Load Date là thời điểm dữ liệu vào nền tảng, không được giả định nó trùng với thời điểm phát sinh sự kiện nghiệp vụ hay thời điểm bắt đầu hiệu lực.

Lý do không đưa các thuộc tính mô tả hay thay đổi như tên, địa chỉ, hạng của khách hàng vào Hub là vì tốc độ thay đổi khác nhau. Nếu đưa các thuộc tính này vào Hub thì mỗi lần thông tin khách hàng thay đổi phải cập nhật dòng Hub, vai trò định danh và mô tả bị trộn lẫn khiến việc truy vết lịch sử trở nên khó khăn. Thuộc tính được đặt ở Satellite để thêm phiên bản mới khi thay đổi, còn Hub tập trung vào sự tồn tại và định danh của thực thể.

Không nên dùng ngay một khóa nghiệp vụ làm khóa tích hợp chỉ vì nó trông hợp lý. Để xác định mã khách hàng của hệ thống A và mã hội viên của hệ thống B là cùng một khách hàng, cần có quy tắc ánh xạ, tiêu chí giải quyết trùng lặp, phê duyệt của chủ sở hữu nghiệp vụ và quy trình xử lý ngoại lệ. Nếu khóa không ổn định hoặc bị tái sử dụng, cần lưu cả định danh hệ thống nguồn và thời hạn hiệu lực, còn việc nhận diện khách hàng tích hợp được quản lý bằng một mô hình ánh xạ riêng.

C. Link: ghi nhận quan hệ và sự kiện

Link biểu diễn quan hệ giữa các Hub hoặc sự kiện nghiệp vụ. Link được dùng khi hai hay nhiều thực thể nghiệp vụ cùng tạo nên ý nghĩa, như quan hệ khách hàng - hợp đồng, đơn hàng - sản phẩm, tài khoản - giao dịch. Nguyên tắc chung là thay vì đưa quá nhiều thuộc tính quan hệ vào Link, hãy bảo toàn bản thân việc phát sinh quan hệ và các khóa tham gia, còn mô tả hay thay đổi thì tách ra Satellite.

Link mang ý nghĩa hơn một bảng nối nhiều-nhiều đơn thuần. Các sự kiện phát sinh theo thời gian như đặt hàng, thanh toán, giao hàng kết hợp Hub tham gia với thời điểm phát sinh để trở thành trung tâm của phân tích. Nếu là sự kiện mà cùng một tổ hợp Hub có thể xảy ra nhiều lần thì không được khử trùng lặp chỉ bằng khóa nghiệp vụ, mà phải xem xét riêng định danh sự kiện như số giao dịch, số sự kiện, số thứ tự phát sinh.

Khi quan hệ trải trên ba Hub trở lên, cần thận trọng trong việc phân rã Link. Ví dụ, trong một giao dịch mà đơn hàng, khách hàng, điểm bán, sản phẩm cùng tham gia, nếu đưa mọi khóa vào một Link thì ý nghĩa rõ ràng nhưng việc thay đổi và tái sử dụng có thể khó khăn. Ngược lại, nếu cứ phân rã thành các Link nhỏ thì độ phức tạp join và khả năng trùng sự kiện tăng lên, nên cần thiết kế dựa trên tính nguyên tử của sự kiện nghiệp vụ và truy vấn phân tích.

Satellite của Link có thể lưu các thuộc tính gắn với quan hệ như trạng thái, vai trò, số lượng, điều kiện hợp đồng, thời hạn hiệu lực. Màu sắc của bản thân sản phẩm phải nằm ở Satellite của Hub sản phẩm, nhưng giá bán và tỷ lệ chiết khấu tại thời điểm đặt hàng phải nằm ở Satellite của quan hệ đơn hàng - sản phẩm thì mới tái hiện được giao dịch trong quá khứ. Nếu xác định sai đối tượng gắn thuộc tính, thay đổi của khách hàng hay sản phẩm sẽ làm sai lệch đơn hàng quá khứ.

D. Satellite: ngữ cảnh, lịch sử, nguồn gốc

Satellite lưu các thuộc tính mô tả phụ thuộc vào Hub hoặc Link cùng lịch sử thay đổi của chúng. Ví dụ điển hình là tên và địa chỉ khách hàng, trạng thái hợp đồng, mô tả sản phẩm, kết quả chấm điểm tín dụng, trạng thái đơn hàng. Satellite gom các thuộc tính có ngữ nghĩa và chu kỳ thay đổi tương tự, đồng thời tách các thuộc tính khác cấp độ bảo mật hoặc tổ chức sở hữu để dễ kiểm soát truy cập và quản lý thay đổi.

Một dòng Satellite thường gồm khóa cha, Load Date, Hash Diff, Record Source và giá trị thuộc tính. Hash Diff có thể được dùng để nhanh chóng xác định tập thuộc tính có khác với phiên bản trước hay không, nhưng hash giống nhau không chứng minh chắc chắn rằng ngữ nghĩa nghiệp vụ giống nhau. Nếu không chuẩn hóa thuật toán hash, chuẩn hóa chuỗi, cách biểu diễn null, thứ tự cột, quy tắc mã hóa ký tự thì cùng một giá trị có thể cho hash khác nhau, hoặc các giá trị khác nhau có thể bị xử lý theo cùng một quy tắc so sánh.

Việc đưa mọi nhóm thuộc tính vào một Satellite hay chia thành nhiều cái được quyết định dựa trên tốc độ thay đổi và ranh giới bảo mật. Nếu đặt chung trạng thái khách hàng thay đổi hằng ngày với thuộc tính nhân khẩu học hầu như không đổi, thì chỉ một thay đổi nhỏ cũng khiến dòng lớn bị lưu lặp lại, và phạm vi truy cập dữ liệu cá nhân cũng bị mở rộng không cần thiết. Ngược lại, chia quá nhỏ sẽ làm tăng số join và phức tạp hóa quản lý metadata, nên cần xác nhận sự tương đồng về ngữ nghĩa, chu kỳ thay đổi, quyền sở hữu và cấp độ bảo mật.

Điều quan trọng là Satellite là bảng lịch sử chứ không phải bảng giá trị hiện tại. Dịch vụ chỉ cần cung cấp trạng thái hiện tại thì được xây dựng bằng cách xác định dòng mới nhất ở Business Vault hoặc tầng cung cấp thông tin. Nếu xóa trực tiếp hoặc ghi đè lịch sử của Raw Vault để tạo trạng thái mới nhất thì sẽ mất khả năng tái hiện báo cáo quá khứ và khả năng kiểm toán, vì vậy cần tách mục đích của tầng gốc và tầng tiêu thụ.

3. Quy trình nạp và thiết kế khóa

A. Thứ tự nạp

flowchart TD
    A[Thu thập thay đổi nguồn] --> B{Có thể xử lý lại?}
    B -- Không --> E[Hàng đợi cách ly·Ghi lỗi]
    B -- Có --> C[Chuẩn hóa·Kiểm tra trùng lặp·lược đồ]
    C --> D[Khớp khóa Hub và nạp khóa mới]
    D --> F[Nạp quan hệ·sự kiện Link]
    F --> G[So sánh thuộc tính·Hash Diff của Satellite]
    G --> H[Gán thời hạn hiệu lực·metadata kiểm toán]
    H --> I[Kiểm tra chất lượng·Cập nhật Watermark]
    I --> J[Cập nhật Business Vault·Mart]
    J --> K[Giám sát lineage·chất lượng·vận hành]

Trước tiên, thu thập sự kiện hoặc tệp nguồn, lưu ID tiếp nhận và checkpoint để có thể xử lý lại cùng một đầu vào. Thành công của thu thập và thành công của nạp nghiệp vụ phải được quản lý như hai trạng thái riêng. Nếu chỉ dựa vào việc đã nhận tệp mà đánh dấu là đã phản ánh đầy đủ vào Hub, Link, Satellite, thì khi khôi phục sự cố sẽ khó tìm ra khoảng bị thiếu.

Bước tiếp theo thực hiện chuẩn hóa khóa, thống nhất múi giờ, kiểm tra trường bắt buộc, xác nhận phiên bản lược đồ và phát hiện sự kiện trùng lặp. Ở bước này, thay vì vứt bỏ giá trị nguồn, cần lưu các dòng lỗi vào vùng cách ly và ghi lại mã lỗi cùng khả năng xử lý lại. Nếu lặng lẽ loại bỏ các dòng không vượt qua kiểm tra chất lượng, số lượng nạp trông như thành công nhưng kết quả phân tích bị giảm âm thầm, đây là vấn đề nguy hiểm hơn.

Với Hub, trước hết kiểm tra khóa nghiệp vụ đã tồn tại chưa, nếu là khóa mới thì sinh Hub Key. Khi dùng Hash Key, cần chuẩn hóa hàm sinh khóa và thứ tự trường đầu vào để các pipeline khác nhau sinh cùng một khóa cho cùng một thực thể. Khả năng va chạm hash, thay thế thuật toán, độ dài khóa, chính sách chuẩn hóa chữ hoa/thường và khoảng trắng phải được ghi rõ trong tài liệu thiết kế.

Sau khi Hub sẵn sàng thì nạp Link để có thể tham chiếu khóa của các Hub tham gia. Đưa ID sự kiện nguồn của quan hệ vào tiêu chí duy nhất, và chuẩn bị khóa lũy đẳng để cùng một sự kiện dù được gửi lại cũng chỉ được phản ánh một lần. Satellite so sánh khóa cha và việc thuộc tính có thay đổi hay không, chỉ thêm dòng lịch sử mới khi có thay đổi thực sự, và không tạo dòng trùng cho sự kiện giống hệt được nhận lặp lại.

Cuối cùng, kiểm chứng số lượng nạp, số Hub mới, số khóa chưa ánh xạ, số dòng Link mồ côi, tỷ lệ thay đổi Satellite và độ trễ. Kết quả kiểm chứng phải tra cứu được không chỉ trong log pipeline mà cả trong kho chất lượng dữ liệu và dashboard vận hành. Watermark biểu thị vị trí đầu vào thành công cuối cùng, nên cần quản lý đồng thời thứ tự commit và phạm vi xử lý lại để không bỏ qua đầu vào của bước bị lỗi.

B. Mô hình hiệu lực và thời điểm

Trong Data Vault, Load Date là thời điểm được quan sát trên nền tảng, còn Effective Date là thời điểm giá trị có hiệu lực về mặt nghiệp vụ. Ví dụ, thay đổi hạng khách hàng phát sinh ngày 1/9 nhưng do sự cố mạng mà đến ngày 3/9 mới tới thì hai ngày này khác nhau. Quy tắc truy vấn sẽ khác nhau tùy việc người phân tích muốn "giá trị mà chúng ta biết vào ngày 2/9" hay "giá trị áp dụng về mặt nghiệp vụ từ ngày 1/9".

Nếu nhầm lẫn hai thời điểm này, khi phản ánh dữ liệu đến muộn vào kỳ quá khứ, báo cáo có thể thay đổi, hoặc dữ liệu dùng cho quyết định lúc đó không khớp với dữ liệu tính lại hiện nay. Do đó, Satellite cần lưu thời điểm bắt đầu và kết thúc hiệu lực, thời điểm nạp, thời điểm sự kiện nguồn ở mức cần thiết, và tiêu chí thời gian phải được ghi rõ trong hợp đồng dữ liệu.

Logic tìm dòng hiện tại cũng có thể không đủ nếu chỉ chọn Load Date lớn nhất. Bởi có thể đồng thời tồn tại các dòng hiệu lực trong tương lai, bản sửa đến muộn, nhiều sự kiện cùng thời điểm và đánh dấu xóa. An toàn hơn là tạo view PIT và trạng thái hiện tại ghi rõ ưu tiên nghiệp vụ và quy tắc thời điểm tại Business Vault, không để người tiêu thụ tự ý chọn dòng mới nhất.

C. Chất lượng dữ liệu và tính lũy đẳng

Tính lũy đẳng là tính chất khiến kết quả cuối cùng như nhau dù cùng một đầu vào được xử lý một lần hay nhiều lần. Vì Data Vault lấy xử lý lại và nạp song song làm tiền đề, cần kết hợp khóa cha, định danh sự kiện nguồn, hash thuộc tính và thông tin lô nạp để tạo tiêu chí chống trùng lặp. Nếu chỉ lấy ID lần chạy pipeline làm khóa thì mỗi lần chạy lại, cùng một dữ liệu sẽ bị chồng thêm thành dòng mới.

Các quy tắc chất lượng tiêu biểu gồm tính bắt buộc của khóa nghiệp vụ Hub, tính duy nhất của Hub Key, khả năng tham chiếu của khóa tham gia Link, sự tồn tại của khóa cha Satellite, chồng lấn thời hạn hiệu lực, danh sách cho phép của Record Source và khả năng tái hiện Hash Diff. Các quy tắc này không dừng ở việc truy vấn mẫu sau khi nạp, mà được kiểm chứng tự động mỗi lô để khi thất bại không lan truyền sang tầng tiêu thụ.

Việc xóa ở nguồn cũng là một hạng mục chất lượng quan trọng. Mô hình sẽ khác nhau tùy việc nguồn truyền cờ xóa mềm, gửi sự kiện xóa riêng, hay cần xóa vật lý do chính sách lưu giữ. Yêu cầu xóa dữ liệu cá nhân có thể được ưu tiên hơn nguyên tắc "bảo toàn lịch sử" của Raw Vault, nên cần phản ánh vào mô hình dữ liệu và quy trình vận hành một chính sách bao gồm token hóa, lưu trữ tách biệt, bằng chứng xóa và hết hạn bản sao lưu.

4. So sánh Data Vault 2.0 với các mô hình khác

A. Khác biệt với star schema

Star schema xoay quanh bảng sự kiện (fact) và bảng chiều (dimension), đường truy vấn đơn giản và dễ hiểu đối với công cụ BI. Vì vậy, nếu ưu tiên hàng đầu là thời gian phản hồi của dashboard người dùng và tính tiện dụng xoay quanh thuật ngữ nghiệp vụ thì star schema có thể là lựa chọn trực tiếp. Tuy nhiên, nếu cố biểu diễn đồng thời lịch sử nguồn và quá trình thay đổi của nhiều nguồn trong một mô hình, quản lý thay đổi chiều và độ phức tạp ETL có thể tăng lên.

Data Vault ưu tiên bảo toàn lịch sử và nguồn gốc ở Raw Vault, rồi tạo star schema phục vụ tiện lợi người dùng cuối ở một tầng riêng. Kết quả là Raw Vault có nhiều join và khó truy vấn trực tiếp, nhưng khi tiếp nhận nguồn và thuộc tính mới thì không làm xáo trộn toàn bộ mô hình chiều. Hai mô hình không hẳn cạnh tranh nhau mà có thể có vai trò khác nhau ở tầng lưu trữ - tích hợp và tầng tiêu thụ - trình bày.

Tiêu chí so sánh	Data Vault 2.0	Star schema	Đánh giá thực tiễn
Mục đích cơ bản	Thích ứng thay đổi·Lịch sử·Kiểm toán	Đơn giản hóa truy vấn phân tích·Hiệu năng	Tách mục tiêu theo tầng
Cấu trúc trung tâm	Hub·Link·Satellite	Fact·Dimension	Xét số nguồn và số người tiêu thụ
Thay đổi lược đồ	Khoanh vùng phạm vi ảnh hưởng	Có thể phải thiết kế lại chiều·sự kiện	Tốc độ thay đổi cao thì Vault có lợi
Truy cập người dùng	Tạo mart thay vì dùng trực tiếp	Thân thiện với công cụ BI	Phù hợp cho tầng cung cấp cuối
Dung lượng·Join	Tăng do lịch sử và metadata kỹ thuật	Tương đối đơn giản	Tính cả chi phí lưu trữ và truy vấn
Kiểm toán·Tái hiện	Mạnh về truy vết nguồn·thời điểm·nguồn gốc	Tùy cách triển khai	Ưu tiên đánh giá yêu cầu quy định·kiểm toán

Ví dụ, nếu một tổ chức tài chính tích hợp nguồn khách hàng, tài khoản, giao dịch trong khi sản phẩm và quy định thay đổi hằng năm, có thể dùng Data Vault để bảo toàn lịch sử nguồn và quan hệ, còn mart lãi lỗ cuối tháng được cung cấp dưới dạng star schema. Ngược lại, nếu một phòng ban chỉ tra cứu doanh số theo ngày của một hệ thống, thì mô hình chiều đơn giản hoặc bảng tổng hợp có thể hợp lý hơn về vận hành so với việc chèn Data Vault vào giữa.

B. Khác biệt với data lake và lakehouse

Data lake mạnh ở việc lưu trữ chi phí thấp dữ liệu nguồn đa định dạng, còn lakehouse kết hợp quản lý giao dịch, lược đồ, bảng trên object storage. Data Vault tập trung vào nguyên tắc mô hình tích hợp và quản lý lịch sử hơn là phương tiện lưu trữ. Do đó có thể kết hợp triển khai Raw Vault trên lakehouse, hoặc triển khai Data Vault trên engine kho dữ liệu.

Vùng dữ liệu gốc của lake chứa rộng rãi thay đổi cấu trúc và dữ liệu phi cấu trúc, nhưng nếu ngữ nghĩa của khóa nghiệp vụ, quan hệ, lịch sử không được quản lý nhất quán thì mỗi người tiêu thụ sẽ tự diễn giải. Data Vault, độc lập với việc bảo toàn nguồn, chỉ rõ khóa nghiệp vụ và quan hệ, giúp dễ xây dựng catalog tích hợp và lineage. Tuy nhiên, nếu sao chép mọi nguồn thành bảng Vault thì có thể mất tính linh hoạt và lợi thế chi phí của lake, nên cần phân biệt vai trò của vùng dữ liệu gốc và vùng tích hợp có độ nhất quán cao.

C. Khác biệt với mô hình 3NF

Mô hình 3NF chuẩn hóa dữ liệu nghiệp vụ thông qua phụ thuộc hàm và loại bỏ dư thừa, giảm bất thường khi cập nhật. Nó mạnh trong quản lý chính xác trạng thái giao dịch nghiệp vụ, nhưng để duy trì lịch sử và nguồn gốc của nhiều nguồn theo góc độ phân tích thì cần thiết kế lịch sử riêng. Data Vault cũng giảm dư thừa bên trong từng thành phần, nhưng ưu tiên cô lập thay đổi và bảo toàn lịch sử hơn là số bảng tối thiểu cho phân tích.

Lựa chọn giữa 3NF và Data Vault không phải vấn đề "chuẩn hóa có tốt không" mà là vấn đề mục đích nghiệp vụ và trục thời gian. Xử lý đơn hàng của hệ thống vận hành phù hợp với 3NF và ràng buộc mạnh, còn tích hợp nguồn dài hạn và truy vết thay đổi có thể phù hợp với Vault. Ngay trong một nền tảng dữ liệu, hệ thống vận hành, Raw Vault, Business Vault và mart có thể dùng các mô hình khác nhau.

5. Tình huống áp dụng và phần nâng cao

A. Tình huống bán lẻ và thương mại điện tử

Giả sử nhiều kênh trực tuyến và cửa hàng offline quản lý khách hàng, sản phẩm, đơn hàng bằng các khóa khác nhau. Hub khách hàng bảo toàn khóa nguồn của từng nguồn và ánh xạ tích hợp, còn Link đơn hàng kết nối khách hàng, sản phẩm, kênh bán và sự kiện đặt hàng. Giá và chiết khấu tại thời điểm đặt hàng được đặt ở Link Satellite để dù giá hiện tại của sản phẩm thay đổi, số tiền đơn hàng quá khứ vẫn không đổi.

Ưu điểm của cấu trúc này là khi thêm kênh bán mới, không cần thiết kế lại toàn bộ ETL của mart đơn hàng hiện có mà chỉ cần thêm ánh xạ Hub của nguồn kênh cùng Link và Satellite liên quan. Nhưng nếu việc nhận diện cùng một khách hàng không chính xác thì giá trị vòng đời khách hàng bị cộng trùng, nên cần vận hành độ tin cậy của ánh xạ khóa và hàng đợi rà soát thủ công. Ngoài ra, hủy đơn, hoàn tiền một phần, giao lại không phải là cập nhật trạng thái hiện tại đơn thuần mà là bài toán thiết kế Link cần bảo toàn thứ tự và số tiền của các sự kiện.

B. Tình huống sản xuất và chuỗi cung ứng

Doanh nghiệp sản xuất có nhà máy, thiết bị, vật tư, nhà cung cấp, lệnh sản xuất nằm ở các hệ thống khác nhau, và dữ liệu cảm biến thiết bị cùng kiểm tra chất lượng liên tục đổ về. Nếu đặt Hub thiết bị, Hub lệnh sản xuất, Link thiết bị - lệnh, rồi tách trạng thái, lịch sử bảo trì, kết quả kiểm tra thành Satellite thì có thể tiếp nhận riêng rẽ việc thay hệ thống cảm biến và cải tổ ERP.

Ở Business Vault, kết hợp lệnh sản xuất và kết quả kiểm tra để tính tỷ lệ lỗi, thời gian vận hành theo thiết bị, chỉ số giao hàng đúng hạn theo nhà cung cấp. Khi đó, do thời điểm sự kiện cảm biến và thời điểm thu thập khác nhau, cần ghi rõ quy tắc quy sự kiện đến muộn vào kỳ sản xuất nào. Nếu cần điều khiển thời gian thực, an toàn hơn là không dùng Data Vault làm kho lưu trữ trực tiếp của vòng điều khiển mà tách hệ thống vận hành với nền tảng phân tích.

C. Tình huống dữ liệu công và dữ liệu chịu quy định

Cơ quan công quyền có nhiều hệ thống theo dự án và đơn vị được ủy thác, luật lệ, mã và tổ chức thay đổi nên khả năng tái hiện thống kê quá khứ rất quan trọng. Ghi vào Raw Vault cơ quan nguồn, tệp nhận, phiên bản mã áp dụng, lô nạp thì dễ giải thích căn cứ của kết quả tổng hợp. Ở Business Vault, quản lý theo phiên bản việc xác định đối tượng theo chính sách và tiêu chí thống kê, để cùng một nguồn vẫn phân biệt được kết quả theo quy tắc khi đó và quy tắc hiện tại.

Tuy nhiên, dữ liệu công có thể chứa thông tin định danh cư dân và thông tin nhạy cảm. Không được mở rộng quyền truy cập với lý do bảo toàn lịch sử nguồn, mà cần đưa token hóa, mã hóa, kiểm soát truy cập theo cột, log truy cập, thời hạn lưu giữ và kiểm chứng hủy vào vận hành Data Vault. Mô hình có thể kiểm toán không phải là mô hình lưu dữ liệu mãi mãi, mà là mô hình giải thích được cả mục đích lưu giữ và bằng chứng hủy.

D. Hướng mở rộng thực tiễn mới nhất

Việc triển khai Data Vault 2.0 hiện đại đang chuyển từ cách con người viết lặp lại script SQL sang tự động hóa dựa trên metadata. Nếu quản lý định nghĩa Hub, Link, Satellite, ánh xạ nguồn, quy tắc khóa, quy tắc chất lượng dưới dạng metadata thì có thể sinh đồng thời bảng, mã nạp, tài liệu và lineage. Tuy nhiên, sinh tự động có thể lan truyền nhanh khóa nghiệp vụ sai hay việc gắn thuộc tính sai, nên nhất thiết phải lưu lại phê duyệt của chuyên gia miền và lịch sử thay đổi.

Khi kết hợp CDC và streaming, cần xử lý đồng thời thứ tự, trùng lặp, đến muộn, xóa và tiến hóa lược đồ. Không chỉ tin vào thứ tự đến của sự kiện mà phải lưu vị trí log nguồn, thời điểm sự kiện, watermark và chính sách xử lý hiệu chỉnh. Dù tính thời gian thực quan trọng, cung cấp view Business Vault đã kiểm chứng cùng trạng thái chất lượng sẽ có lợi cho sự ổn định vận hành hơn là để mọi người tiêu thụ đọc trực tiếp sự kiện nguồn.

6. Các điểm cần lưu ý và hàm ý

A. Khóa nghiệp vụ và định danh tích hợp

Việc chọn khóa nghiệp vụ quyết định thành bại của mô hình. Cần xác nhận khóa có ổn định về nghiệp vụ không, ngữ nghĩa giữa các hệ thống có như nhau không, có bị tái sử dụng, thay đổi hay là khóa ghép không, đồng thời ghi thành tài liệu chủ sở hữu khóa và quy tắc xử lý ngoại lệ. Hash Key hữu ích cho hiệu năng và nạp phân tán, nhưng không thay thế ngữ nghĩa của khóa nghiệp vụ và cần chuẩn hóa đầu vào hash cùng biện pháp ứng phó va chạm.

B. Cân bằng giữa bảo toàn lịch sử và tối thiểu hóa dữ liệu cá nhân

Tính bảo toàn của Raw Vault có thể xung đột với dữ liệu cá nhân. Thuộc tính nhạy cảm được tách thành Satellite và vùng quyền riêng, tầng phân tích chỉ được cung cấp token hoặc khóa phi định danh, và quản lý đến tận việc hủy sau khi đạt mục đích cùng hết hạn bản sao lưu. Khi phát sinh yêu cầu xóa, cần xác nhận qua lineage phạm vi xử lý ở nguồn, dữ liệu dẫn xuất, cache, bản sao lưu và lưu kết quả xóa làm bằng chứng kiểm toán.

C. Hiệu năng và chi phí

Hub, Link, Satellite lưu nhiều lịch sử và metadata, số lượng join có thể tăng. Các join theo thời điểm dùng thường xuyên được tối ưu bằng bảng PIT và view tổng hợp, nhưng cần đo chu kỳ cập nhật và chi phí tính lại. Trên đám mây, thay vì xóa lịch sử nguồn chỉ để giảm chi phí lưu trữ, hãy kết hợp phân vùng, nén, clustering, lớp lưu trữ và thời hạn lưu giữ để tối ưu đồng thời chi phí và khả năng tái hiện.

D. Chất lượng dữ liệu và trách nhiệm vận hành

Data Vault không phải mô hình tự động đảm bảo chất lượng dữ liệu. Cần định nghĩa trùng khóa, Link mồ côi, chồng lấn thời hạn hiệu lực, thiếu sự kiện, thay đổi lược đồ, đến muộn thành quy tắc chất lượng, và khi vượt ngưỡng thì truyền trạng thái cảnh báo, chặn, hiệu chỉnh tới tầng tiêu thụ. Ranh giới trách nhiệm của chủ sở hữu từng sản phẩm dữ liệu, người phụ trách hệ thống nguồn, người vận hành nền tảng và người phụ trách bảo mật được xác định bằng RACI.

E. Quản trị mô hình hóa

Cần xây dựng chuẩn về việc khi nào thêm Hub, Link, Satellite, chia Satellite thế nào, ai phê duyệt khóa nghiệp vụ. Thay đổi mô hình phải qua code review và kiểm chứng tự động, pipeline được cấu hình để lược đồ, metadata, quy tắc chất lượng và lineage cùng thay đổi. Chuẩn quá cứng nhắc làm chậm việc áp dụng, ngược lại nếu mỗi nhóm diễn giải một kiểu thì lợi ích tích hợp biến mất, vì vậy cần có quy trình phê duyệt ngoại lệ.

F. Chiến lược áp dụng và chỉ số thành công

Không chuyển đổi mọi miền toàn doanh nghiệp ngay từ đầu, mà chọn một miền thay đổi thường xuyên và có giá trị lịch sử, kiểm toán cao. Ở vùng có hiệu quả rõ ràng như khách hàng, đơn hàng, kiểm chứng như một lát cắt dọc (vertical slice) từ ánh xạ khóa, xử lý lại, dashboard chất lượng đến cung cấp mart, rồi mới mở rộng.

Thành công không đo bằng số bảng, mà bằng thời gian đưa nguồn mới vào, tỷ lệ xử lý lại thành công, độ bao phủ lineage, thời gian phát hiện lỗi chất lượng, khả năng tái hiện của mart cốt lõi, mức hài lòng của người tiêu thụ và chi phí. Nếu đã áp dụng Data Vault mà mọi người tiêu thụ vẫn join trực tiếp bảng nguồn và duy trì quy tắc thủ công thì mô hình chưa đạt được mục đích.

7. Chiến lược trình bày bài làm

Trong bài thi, trước tiên định nghĩa Data Vault là phương pháp luận hướng tới khả năng thích ứng thay đổi, lịch sử, kiểm toán và nạp song song. Sau đó trình bày bằng sơ đồ khái niệm vai trò của Hub, Link, Satellite và luồng Raw Vault→Business Vault→tầng cung cấp thông tin.

Tiếp theo, giải thích khóa nghiệp vụ, Hash Key, Hash Diff, Load Date, Effective Date, Record Source, tính lũy đẳng gắn với quy trình nạp. Đừng chỉ liệt kê thuật ngữ, hãy dùng ví dụ để cho thấy vì sao thuộc tính đặt ở Satellite và vì sao giá trị gắn với sự kiện như giá đặt hàng lại đặt ở Link Satellite.

Cuối cùng, so sánh với star schema, 3NF, lakehouse để đưa ra điều kiện áp dụng và các đánh đổi. Nếu tổng hợp tối thiểu hóa thu thập dữ liệu cá nhân, chất lượng và lineage, chi phí và hiệu năng, quản trị tổ chức và chiến lược áp dụng thành các điểm cần lưu ý, có thể xây dựng kết luận theo góc nhìn Kỹ sư chuyên nghiệp.

Tài liệu tham khảo

• Khái niệm mô hình Data Vault và cấu trúc Hub·Link·Satellite: https://en.wikipedia.org/wiki/Data_vault_modeling
• Tham khảo kỹ thuật mô hình hóa chiều của Kimball Group: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/

---

Tóm tắt một câu: Data Vault 2.0 là phương pháp luận tách khóa nghiệp vụ, quan hệ và lịch sử thuộc tính thành Hub, Link, Satellite để tạo tầng lưu trữ tích hợp chịu được thay đổi nguồn và yêu cầu kiểm toán, rồi bổ sung quy tắc nghiệp vụ, hiệu năng và tính tiện dụng ở Business Vault và data mart.