</>Học Dev
Bài học

Tuần 6 - Ngày 2: AWS Glue Data Quality

Tuần 6 – Ngày 2

Mục tiêu học tập

  • Hiểu Glue Data Quality: ruleset, DQDL, hai chế độ chạy (catalog vs job)
  • Viết được các rule DQDL phổ biến
  • Thiết kế pipeline "chặn dữ liệu xấu": quarantine, alert, fail-fast
  • Biết các lựa chọn data quality khác (DataBrew profile, Lambda validate, Deequ)

1. Vì sao cần data quality gate

Dữ liệu xấu (null bất thường, trùng khóa, schema lệch, giá trị ngoài miền) đi lọt vào curated/warehouse → báo cáo sai, model hỏng, sửa rất đắt. Nguyên tắc: chặn tại cổng (trước khi ghi curated), không phải phát hiện ở dashboard.

2. AWS Glue Data Quality

Hai chế độ

Chế độChạy trênDùng khi
Data Catalog (at-rest)Bảng trong catalog — đánh giá theo lịch/on-demandKiểm tra định kỳ dataset đã có
Trong Glue ETL job (in-transit)DynamicFrame giữa pipeline (transform EvaluateDataQuality)Gate trong pipeline — quyết định ghi tiếp hay chặn
  • Nền tảng mã nguồn mở Deequ (Spark)
  • Recommendations: Glue quét dữ liệu và gợi ý ruleset khởi đầu — đỡ viết tay
  • Kết quả: score + pass/fail per rule; phát EventBridge event, đẩy metric CloudWatch → alert
  • Trong job: tách record lỗi (rowLevelOutcomes) → ghi quarantine location

DQDL — Data Quality Definition Language

Rules = [
    RowCount > 1000,
    IsComplete "customer_id",                  # không null
    IsUnique "order_id",                       # không trùng
    ColumnValues "status" in ["NEW","PAID","CANCELLED"],
    ColumnValues "amount" between 0 and 1000000,
    Completeness "email" > 0.95,               # ≥95% không null
    ColumnLength "country_code" = 2,
    Mean "amount" between 50 and 500,
    ReferentialIntegrity "customer_id" "dim_customers.id" = 1.0,
    DataFreshness "updated_at" <= 24 hours
]

Rule động theo lịch sử: RowCount > avg(last(10)) * 0.5 — phát hiện "hôm nay dữ liệu ít bất thường" (anomaly-style).

3. Pipeline pattern: DQ gate + quarantine

raw──►Gluejob├─EvaluateDataQuality(ruleset)│││┌───┴────────┐│▼▼│PASSrowsFAILrows│││▼▼▼curatedzones3://quarantine/(điềutra,reprocess)│DQresult→EventBridge→SNS(score<ngưỡngthìalert/dừngworkflow)
  • Fail-fast: nếu rule tổng thể fail (vd RowCount quá thấp) → job fail → Step Functions Catch dừng pipeline, không ghi đè dữ liệu tốt bằng dữ liệu hỏng
  • Row-level: lỗi lẻ tẻ → tách quarantine, phần sạch đi tiếp — pipeline không chết vì vài record xấu

4. Các lựa chọn liên quan (phân biệt trong đề)

Công cụVai trò
Glue Data QualityRule-based DQ cho lake/pipeline Glue — đáp án mặc định DEA
Glue DataBrew profileProfile thống kê + phát hiện bất thường qua UI cho analyst
Lambda validateKiểm tra nhẹ per-file/per-record ở edge (schema, định dạng)
Deequ tự quản trên EMRKhi tự vận hành Spark — nhiều công hơn
Schema RegistryChặn schema xấu ở tầng streaming (không phải giá trị dữ liệu)

Câu hỏi ôn tập

  1. Yêu cầu: trước khi ghi vào curated, đảm bảo order_id không trùng, customer_id không null, amount trong khoảng hợp lệ; record vi phạm được giữ lại điều tra. Thiết kế?

    Xem đáp án

    Trong Glue ETL job thêm transform EvaluateDataQuality với DQDL: IsUnique "order_id", IsComplete "customer_id", ColumnValues "amount" between .... Dùng row-level outcomes tách record fail ghi vào quarantine prefix S3, record pass ghi curated. Kết quả DQ đẩy CloudWatch/EventBridge để alert khi tỷ lệ lỗi cao.

  2. Làm sao phát hiện "hôm nay file nguồn về chỉ bằng 1/10 mọi ngày" một cách tự động?

    Xem đáp án

    Dùng DQDL rule so với lịch sử: RowCount > avg(last(10)) * 0.5 (hoặc DataFreshness cho độ trễ dữ liệu) — Glue DQ lưu kết quả các lần chạy trước để so sánh. Rule fail → EventBridge → SNS + dừng workflow. Đây chính là dạng anomaly detection cấu hình sẵn của Glue DQ.

  3. Ruleset nên viết từ đầu bằng tay cho bảng 200 cột? Có cách nào nhanh hơn?

    Xem đáp án

    Dùng rule recommendations: Glue DQ scan bảng và tự đề xuất ruleset (completeness, uniqueness, min/max, kiểu dữ liệu) dựa trên dữ liệu thực tế — sau đó tinh chỉnh tay các rule nghiệp vụ. Nhanh và ít sót hơn viết 200 cột thủ công.

  4. Khác nhau giữa fail-fast toàn job và row-level quarantine — khi nào dùng cái nào?

    Xem đáp án

    Fail-fast (job fail khi ruleset fail): cho lỗi hệ thống — schema vỡ, thiếu nửa dữ liệu, nguồn hỏng — tiếp tục chạy chỉ phá hoại downstream. Row-level quarantine: cho lỗi lẻ tẻ — vài record thiếu trường — cách ly phần xấu, phần sạch vẫn giao đúng SLA. Pipeline chín chắn dùng cả hai: ngưỡng tổng thể fail-fast + tách row lỗi dưới ngưỡng.

  5. Kiểm soát chất lượng ở tầng streaming Kafka/Kinesis — công cụ nào phù hợp hơn Glue DQ?

    Xem đáp án

    Glue Schema Registry — enforce schema và compatibility ngay tại producer/consumer (chặn message sai cấu trúc từ đầu). Giá trị dữ liệu bất thường trong stream: validate trong Lambda/Flink. Glue DQ nhắm dataset batch/at-rest và trong Glue job (kể cả Glue streaming job có hỗ trợ DQ, nhưng schema gate ở registry vẫn là tầng đầu).

Bài tập thực hành

  • Tạo ruleset recommendation cho bảng curated lab trước, xem rule được gợi ý
  • Viết DQDL 6 rule cho bảng orders (RowCount, IsUnique, IsComplete, ColumnValues, Completeness, DataFreshness)
  • Thêm EvaluateDataQuality vào Glue Studio job với nhánh quarantine
  • Đọc DQDL reference

Tài liệu tham khảo chính thức

Tiếp theo: Data Lineage và Observability