Data Engineering 8 — Quản trị, Chất lượng & Bảo mật dữ liệu

Bạn đã xây được pipeline chạy ổn định, dữ liệu chảy đều mỗi đêm. Nhưng rồi một sáng, sếp hỏi: "Con số doanh thu trên dashboard lấy từ đâu? Sao tháng này lệch 12% so với báo cáo kế toán?" Và bạn không trả lời được. Hoặc tệ hơn: đội audit phát hiện số CMND của khách hàng nằm chình ình trong một bảng staging mà ai cũng đọc được.

Đây chính là lúc quản trị dữ liệu (data governance), chất lượng dữ liệu (data quality) và bảo mật bước vào. Pipeline chạy được mới chỉ là một nửa câu chuyện. Nửa còn lại — và thường là nửa khó hơn — là làm cho dữ liệu đáng tin, truy vết được, và an toàn. Bài này đi sâu từ con số 0 đến mức bạn có thể tự thiết kế một khung governance cho tổ chức của mình, với bối cảnh đặc thù của ngành ngân hàng.

Data governance là gì và vì sao quan trọng

Data governance là tập hợp các chính sách, quy trình, vai trò và công cụ để đảm bảo dữ liệu trong tổ chức được quản lý đúng cách trong suốt vòng đời của nó — từ lúc sinh ra đến lúc bị xoá. Nói ngắn gọn: governance trả lời các câu hỏi "Ai sở hữu dữ liệu này? Ai được dùng? Dữ liệu này nghĩa là gì? Nó có đúng không? Nó đến từ đâu?"

Governance không phải là một công cụ bạn cài đặt. Nó là sự kết hợp của ba thứ:

• Con người (People): các vai trò như Data Owner (chịu trách nhiệm về một miền dữ liệu, ví dụ trưởng phòng tín dụng sở hữu dữ liệu khoản vay), Data Steward (người vận hành hằng ngày, định nghĩa chuẩn, xử lý vấn đề chất lượng), và Data Consumer (người dùng cuối — analyst, data scientist).
• Quy trình (Process): quy trình phê duyệt truy cập, quy trình thay đổi schema, quy trình xử lý sự cố chất lượng, chu kỳ review.
• Công nghệ (Technology): catalog, lineage tracking, công cụ kiểm thử dữ liệu, hệ thống kiểm soát truy cập.

Tại sao đáng đầu tư?

• Sự tin cậy (Trust): Nếu người dùng không tin con số, dashboard đẹp đến mấy cũng vô dụng. Họ sẽ quay lại Excel tự tính, và bạn mất kiểm soát hoàn toàn.
• Tuân thủ (Compliance): Ngành ngân hàng chịu sự giám sát chặt chẽ của Ngân hàng Nhà nước (NHNN) và các quy định bảo vệ dữ liệu cá nhân (như Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân tại Việt Nam, hay GDPR nếu có khách hàng EU). Vi phạm có thể dẫn đến phạt nặng và mất giấy phép.
• Quyết định đúng (Better decisions): Dữ liệu sai dẫn đến quyết định sai. Một mô hình chấm điểm tín dụng huấn luyện trên dữ liệu bẩn sẽ từ chối nhầm khách hàng tốt hoặc phê duyệt nhầm khách hàng xấu — tổn thất trực tiếp về tiền.

Chất lượng dữ liệu: 6 chiều đo lường

"Dữ liệu tốt" là một khái niệm mơ hồ cho đến khi bạn chia nó thành các chiều (dimensions) đo được. Dưới đây là 6 chiều kinh điển. Hãy hiểu rõ từng chiều bằng ví dụ ngân hàng.

Một sai lầm phổ biến là chỉ chăm chăm vào accuracy. Trên thực tế, timeliness và completeness thường gây đau đầu nhiều nhất trong vận hành hằng ngày: pipeline trễ giờ, hay file nguồn bị cắt cụt.

Kiểm thử dữ liệu: Great Expectations & dbt tests

Bạn không thể "mắt thường" kiểm tra hàng triệu dòng. Cần tự động hoá kiểm thử như cách lập trình viên viết unit test. Hai công cụ phổ biến:

dbt tests — nếu bạn dùng dbt để biến đổi dữ liệu (xem bài về transformation), nó có sẵn test khai báo trong YAML:

# schema.yml
models:
  - name: dim_customer
    columns:
      - name: customer_id
        tests:
          - unique            # uniqueness
          - not_null          # completeness
      - name: status
        tests:
          - accepted_values:  # validity
              values: ['active', 'closed', 'frozen']
      - name: branch_id
        tests:
          - relationships:    # consistency (referential integrity)
              to: ref('dim_branch')
              field: branch_id

Chạy dbt test, dbt sinh SQL kiểm tra và báo lỗi nếu có dòng vi phạm. Đơn giản, gắn liền với pipeline.

Great Expectations (GX) — mạnh hơn, độc lập với công cụ transform. Bạn định nghĩa "kỳ vọng" (expectations) về dữ liệu:

import great_expectations as gx

validator.expect_column_values_to_not_be_null("customer_id")
validator.expect_column_values_to_be_between("interest_rate", min_value=0, max_value=0.30)
validator.expect_column_values_to_be_unique("transaction_id")
validator.expect_column_value_lengths_to_equal("national_id", 12)  # CCCD 12 số

GX còn sinh Data Docs — báo cáo HTML đẹp về kết quả kiểm thử, rất hữu ích để chia sẻ với đội nghiệp vụ. Triết lý của nó là biến kỳ vọng ngầm trong đầu mọi người thành ràng buộc tường minh, kiểm tra được.

Nguyên tắc vàng: kiểm thử tại biên (at the boundaries) — kiểm tra dữ liệu ngay khi nó vào pipeline (ingestion) và ngay trước khi nó ra phục vụ người dùng (serving). Phát hiện lỗi càng sớm càng rẻ.

Data lineage: truy vết nguồn gốc và biến đổi

Data lineage là bản đồ kể câu chuyện: dữ liệu này đến từ đâu, đi qua những biến đổi nào, và chảy đến đâu. Nó trả lời hai câu hỏi sống còn:

• Truy ngược (upstream): "Con số doanh thu trên dashboard được tính từ bảng nào, cột nào, công thức gì?" — quan trọng khi debug và khi auditor hỏi.
• Phân tích tác động (downstream / impact analysis): "Nếu tôi đổi schema bảng raw_transactions, những dashboard và mô hình nào sẽ vỡ?" — quan trọng trước khi thay đổi.

Lineage có thể ở mức bảng (table-level: bảng A → bảng B) hoặc mức cột (column-level: cột amount của A góp vào cột total_revenue của B). Column-level chi tiết hơn nhưng khó dựng hơn.

Cách có lineage: nhiều công cụ tự sinh nó từ phân tích mã SQL (dbt tự dựng được lineage giữa các model), hoặc từ các nền tảng chuyên dụng như OpenLineage, Marquez, hoặc tính năng tích hợp trong Databricks Unity Catalog, AWS Glue, v.v.

Data catalog & metadata: khám phá dữ liệu

Khi tổ chức có hàng nghìn bảng, câu hỏi "có dữ liệu gì, ở đâu, nghĩa là gì" trở nên nan giải. Data catalog là "Google cho dữ liệu nội bộ" — nơi tập trung metadata (dữ liệu mô tả dữ liệu):

• Metadata kỹ thuật: tên bảng, schema, kiểu cột, kích thước, thời gian cập nhật.
• Metadata nghiệp vụ: mô tả ý nghĩa cột bằng ngôn ngữ con người, ai sở hữu, mức độ nhạy cảm.
• Metadata vận hành: lineage, tần suất truy cập, chỉ số chất lượng.

Một business glossary (từ điển nghiệp vụ) đi kèm catalog định nghĩa thống nhất các thuật ngữ: "khách hàng đang hoạt động" nghĩa chính xác là gì? Điều này tránh tình trạng mỗi phòng ban tính một kiểu.

Công cụ phổ biến: DataHub, Amundsen, OpenMetadata (mã nguồn mở); hoặc các giải pháp thương mại như Collibra, Alation. Một catalog tốt giúp analyst mới tự tìm được dữ liệu trong vài phút thay vì đi hỏi vòng quanh cả tuần.

Master Data Management & Single Source of Truth

Vấn đề kinh điển: cùng một khách hàng "Nguyễn Văn A" tồn tại trong hệ thống tiết kiệm, hệ thống thẻ, và hệ thống vay — với ba ID khác nhau, ba địa chỉ khác nhau. Đâu là sự thật?

Master Data Management (MDM) là kỷ luật tạo ra một bản ghi "vàng" (golden record) duy nhất, nhất quán cho các thực thể cốt lõi: khách hàng, sản phẩm, chi nhánh. MDM thực hiện việc đối sánh và hợp nhất (matching & merging) các bản ghi trùng từ nhiều nguồn, xử lý xung đột theo quy tắc ưu tiên.

Single Source of Truth (SSOT) là nguyên tắc rộng hơn: với mỗi loại thông tin, có một nơi được coi là chuẩn mực. Mọi báo cáo về doanh thu phải lấy từ cùng một bảng fct_revenue, không ai được tự tính lại theo cách riêng. SSOT là nền tảng của sự nhất quán — nó loại bỏ thảm cảnh "ba con số doanh thu khác nhau trong ba cuộc họp".

Bảo mật & quyền riêng tư

Trong ngân hàng, đây không phải "nice to have" mà là điều kiện sống còn. Một rò rỉ dữ liệu khách hàng có thể chấm dứt cả ngân hàng.

Phân loại dữ liệu (Data classification)

Bước đầu tiên: không phải dữ liệu nào cũng nhạy cảm như nhau. Phân loại theo mức:

• Public — thông tin công khai (lãi suất niêm yết).
• Internal — nội bộ, không công khai nhưng không nhạy cảm cao.
• Confidential — thông tin khách hàng, số dư, lịch sử giao dịch.
• Restricted/PII — dữ liệu định danh cá nhân và nhạy cảm nhất: số CCCD, sinh trắc học, mật khẩu.

PII (Personally Identifiable Information) là bất kỳ dữ liệu nào có thể nhận dạng một cá nhân: tên + ngày sinh, số CCCD, số điện thoại, email, địa chỉ. PII là tâm điểm của mọi quy định bảo vệ dữ liệu. Phân loại quyết định cách bạn xử lý, mã hoá và kiểm soát truy cập từng loại.

Mã hoá (Encryption)

• At-rest (khi lưu trữ): dữ liệu trên đĩa, trong database, trong data lake phải được mã hoá. Nếu ai đó lấy được ổ cứng, họ vẫn không đọc được. Thường dùng AES-256, quản lý khoá qua KMS (Key Management Service).
• In-transit (khi truyền): dữ liệu di chuyển qua mạng phải dùng TLS/SSL. Không bao giờ truyền thông tin nhạy cảm qua HTTP trần.

Kiểm soát truy cập

• RBAC (Role-Based Access Control): gán quyền theo vai trò chứ không theo từng người. "Analyst phòng marketing" có thể đọc bảng nhân khẩu học đã ẩn danh, nhưng không thấy số CCCD. Khi nhân sự thay đổi, chỉ cần đổi vai trò.
• Least privilege (đặc quyền tối thiểu): mỗi người/dịch vụ chỉ có đúng quyền cần để làm việc, không hơn. Một service account ETL chỉ ghi vào schema staging thì không nên có quyền xoá bảng production.

Masking & Anonymization

Khi cần dùng dữ liệu nhưng không cần lộ danh tính thật:

• Masking (che): hiển thị ****-****-1234 thay vì số thẻ đầy đủ. Thường dùng cho hiển thị/môi trường test.
• Pseudonymization (giả danh): thay PII bằng một mã thay thế (token), vẫn có thể đảo ngược nếu có khoá — dùng khi cần liên kết dữ liệu nhưng không lộ danh tính trực tiếp.
• Anonymization (ẩn danh): loại bỏ vĩnh viễn khả năng nhận dạng (không đảo ngược được), ví dụ gộp nhóm tuổi thành khoảng "30-40". Dữ liệu ẩn danh thật sự thường nằm ngoài phạm vi quy định bảo vệ dữ liệu cá nhân.

Tuân thủ: GDPR và bối cảnh ngân hàng Việt Nam

GDPR (quy định của EU) đặt ra các quyền cho cá nhân: quyền được biết, quyền truy cập, quyền được xoá ("right to be forgotten"), quyền yêu cầu sửa. Nó áp dụng cho bất kỳ tổ chức nào xử lý dữ liệu công dân EU. Nguyên tắc cốt lõi: chỉ thu thập dữ liệu cần thiết (data minimization), dùng đúng mục đích đã khai báo (purpose limitation), và giữ trong thời hạn hợp lý.

Trong bối cảnh ngân hàng Việt Nam:

• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân quy định về sự đồng ý, quyền của chủ thể dữ liệu, và nghĩa vụ của bên xử lý — tương tự tinh thần GDPR.
• Quy định của NHNN về bảo mật thông tin khách hàng và an toàn hệ thống thông tin (ví dụ các thông tư về an toàn bảo mật cho hệ thống công nghệ thông tin trong hoạt động ngân hàng). Thông tin khách hàng được bảo mật nghiêm ngặt; chia sẻ chỉ trong các trường hợp pháp luật cho phép.

Hệ quả thực tế cho data engineer: bạn cần khả năng tìm và xoá mọi dữ liệu của một khách hàng khi họ yêu cầu (kể cả trong backup, log, data lake) — đây là lý do lineage và catalog quý giá đến vậy.

Audit log & Retention

• Audit log: ghi lại "ai đã làm gì với dữ liệu nào, khi nào". Khi có sự cố hoặc thanh tra, đây là bằng chứng. Audit log phải bất biến (không sửa được) và được lưu trữ an toàn.
• Retention (lưu giữ): chính sách quy định giữ dữ liệu bao lâu rồi xoá. Giữ quá ngắn vi phạm yêu cầu lưu trữ hồ sơ (ngân hàng thường phải giữ chứng từ nhiều năm); giữ quá lâu làm tăng rủi ro và chi phí, và có thể vi phạm nguyên tắc data minimization. Cần tự động hoá việc xoá/lưu trữ lạnh khi hết hạn.

Checklist governance

Một danh sách thực tế để tự đánh giá tổ chức của bạn:

• Mỗi miền dữ liệu quan trọng có Data Owner và Data Steward rõ ràng.
• Có data catalog và mọi bảng quan trọng đều có mô tả nghiệp vụ + chủ sở hữu.
• Có business glossary thống nhất các thuật ngữ cốt lõi.
• Lineage được dựng (ít nhất ở mức bảng) cho các pipeline chính.
• Có kiểm thử dữ liệu tự động (dbt tests / Great Expectations) tại ingestion và serving.
• Theo dõi đủ 6 chiều chất lượng, có cảnh báo khi vi phạm ngưỡng.
• Dữ liệu được phân loại theo mức nhạy cảm; PII được đánh dấu rõ.
• Mã hoá at-rest và in-transit đã bật cho mọi dữ liệu nhạy cảm.
• RBAC + least privilege được áp dụng; review quyền định kỳ.
• PII được masking/anonymization trong môi trường non-production.
• Audit log bật cho mọi truy cập dữ liệu nhạy cảm.
• Có chính sách retention và cơ chế xoá theo yêu cầu (right to be forgotten).
• Có quy trình xử lý sự cố chất lượng và sự cố rò rỉ dữ liệu.

Tóm tắt

Governance, chất lượng và bảo mật là lớp "trưởng thành" của một nền tảng dữ liệu — thứ biến một pipeline chạy được thành một tài sản đáng tin cậy. Governance phối hợp con người, quy trình và công nghệ để dữ liệu được quản lý có trách nhiệm. Chất lượng được đo qua 6 chiều (accuracy, completeness, consistency, timeliness, validity, uniqueness) và được bảo vệ bằng kiểm thử tự động như dbt tests và Great Expectations. Lineage truy vết nguồn gốc và biến đổi, catalog giúp khám phá dữ liệu, MDM/SSOT đảm bảo một sự thật duy nhất. Cuối cùng, bảo mật dựa trên phân loại dữ liệu, mã hoá, RBAC/least privilege, masking, cùng tuân thủ GDPR, Nghị định 13 và quy định NHNN, được giám sát bằng audit log và retention. Làm tốt những điều này, bạn không chỉ tránh được rủi ro pháp lý mà còn giành được thứ quý nhất: niềm tin của người dùng vào dữ liệu.

Tự kiểm tra

1. Kể tên 6 chiều chất lượng dữ liệu và cho một ví dụ vi phạm trong ngân hàng cho mỗi chiều.
2. Phân biệt data lineage (upstream) và impact analysis (downstream) — mỗi cái trả lời câu hỏi gì?
3. Sự khác nhau giữa masking, pseudonymization và anonymization là gì? Khi nào dùng cái nào?
4. Giải thích RBAC và least privilege; cho ví dụ một service account ETL nên và không nên có quyền gì.
5. Vì sao lineage và catalog lại quan trọng để thực thi "right to be forgotten"?
6. Single Source of Truth giải quyết vấn đề gì mà 6 chiều chất lượng đơn lẻ không đủ giải quyết?

Đọc tiếp

• Quay lại tổng quan toàn series: Data Engineering 1 — Giới thiệu.
• Tiếp theo, hãy củng cố nền tảng truy vấn và phục vụ dữ liệu cho người dùng cuối: tìm hiểu sâu về SQL nâng cao (window functions, CTE, tối ưu truy vấn) và Business Intelligence (mô hình hoá chiều, thiết kế dashboard) — đây là nơi mọi công sức governance và chất lượng được "đền đáp" khi người dùng thực sự ra quyết định dựa trên dữ liệu sạch, đáng tin.