Great Expectations: cách biến những giả định về dữ liệu của khách thành bộ kiểm tra chạy mỗi đêm

Thử hình dung thế này. Một tuần sau go-live, công ty giao hàng bạn đang phục vụ gọi tới vì doanh thu hôm qua trên dashboard tụt một nửa. Pipeline vẫn chạy xanh, không job nào báo lỗi. Lần ngược lại mới thấy hệ thống nguồn bắt đầu gửi đơn hàng mà cột số tiền bị rỗng.

FDE gặp loại sự cố này rất thường. Dữ liệu của khách luôn kèm những giả định chưa ai ghi ra giấy, và khi giả định gãy thì code của bạn vẫn chạy như không có chuyện gì. Great Expectations giúp viết các giả định đó thành kiểm tra tự động, để bạn là người phát hiện ra vấn đề chứ không phải khách.

GX Core thực chất là gì?

Great Expectations gọi GX Core là bộ máy lõi của nền tảng chất lượng dữ liệu GX. GX Core là mã nguồn mở theo giấy phép Apache 2.0, phát hành trên PyPI, và các bản mới vẫn ra đều. Repo trên GitHub mô tả Expectation là unit test cho dữ liệu, và đó là cách hiểu dễ nhớ nhất.

Giấy phép mở cho phép bạn thử GX trên máy mình với một bản trích dữ liệu ngay từ tuần đầu. Còn trước khi đưa nó vào hệ thống của khách, bạn vẫn nên hỏi quy định nội bộ của họ về thư viện bên thứ ba.

Các khái niệm cần nắm, theo đúng thứ tự

Tài liệu GX định nghĩa Expectation là một khẳng định có thể kiểm chứng về dữ liệu. “Cột order_id không bao giờ rỗng” hay “số tiền luôn lớn hơn hoặc bằng 0” đều là Expectation. Bạn gom nhiều Expectation lại thành một bộ, thường là mỗi bảng của khách một bộ.

Theo tài liệu GX, Checkpoint là cách chính để kiểm tra dữ liệu khi GX chạy trong production. Checkpoint chạy các Validation Definition, đưa kết quả cho danh sách Action, và danh sách này chạy một lần cho mỗi Validation Definition. Vì thế cảnh báo luôn đến sau khi kiểm tra đã xong.

Làm thử với bảng đơn hàng

Quay lại công ty giao hàng ở trên. Mỗi đêm họ nạp bảng orders vào kho dữ liệu. Trong buổi discovery, kỹ sư dữ liệu bên khách nói bốn điều: mã đơn không trùng, đơn nào cũng có số tiền, số tiền không âm, và trạng thái chỉ nhận vài giá trị cố định.

Bốn câu nói miệng đó trở thành bốn Expectation. Đoạn dưới chỉ phác phần Checkpoint theo GX 1.x, bám theo trang “Create a Checkpoint with Actions” trong tài liệu GX. Phần tạo nguồn dữ liệu, bộ Expectation và Validation Definition được ghi dưới dạng chú thích; bạn làm theo tài liệu của đúng phiên bản khách đang cài.

Kênh Slack chỉ là giả định để minh họa, và API có thay đổi giữa các bản 1.x, nên hãy đối chiếu đoạn này với chính trang đó trước khi chạy:

import great_expectations as gx
from great_expectations.checkpoint import SlackNotificationAction, UpdateDataDocsAction

# Giả sử đã có:
#   context: môi trường GX của dự án (bước set up môi trường)
#   validation_definitions: các Validation Definition cho bảng orders,
#   dùng bộ bốn Expectation rút từ buổi discovery:
#     1. order_id không trùng
#     2. amount không rỗng
#     3. amount không âm
#     4. status chỉ thuộc một tập giá trị cố định

# Action chạy sau khi kiểm tra xong: báo Slack khi thất bại, cập nhật Data Docs
actions = [
    SlackNotificationAction(
        name="slack_on_failure",
        slack_token="${SLACK_TOKEN}",
        slack_channel="#data-alerts",
        notify_on="failure",
    ),
    UpdateDataDocsAction(name="update_docs"),
]

checkpoint = gx.Checkpoint(
    name="orders_checkpoint",
    validation_definitions=validation_definitions,
    actions=actions,
)
context.checkpoints.add(checkpoint)

# Lần chạy mỗi đêm: kết quả được chuyển cho các Action
results = checkpoint.run(batch_parameters={"dataframe": orders_df})

Expectation thứ hai, số tiền không được rỗng, là luật bắt đúng lỗi ở đầu bài. Với notify_on=“failure”, nhóm bạn nhận cảnh báo Slack ngay trong đêm cột amount rỗng. Đoạn code không đọc thuộc tính nào trên results. Nếu cần xử lý kết quả trong code, hãy xem tài liệu về result format trước rồi mới dùng.

Phần đáng giá nhất ở đây không phải dòng code nào. Mỗi Expectation là một giả định của khách được ghi lại dưới dạng chạy được. Lần sau khách hỏi vì sao số liệu lệch, bạn có kết quả kiểm tra để chỉ ra giả định nào đã gãy.

Đưa vào Airflow

Nhiều khách đã điều phối pipeline bằng Airflow. Astronomer có hướng dẫn dùng provider của GX để chạy kiểm tra ngay trong Dag. Provider này có operator chạy Checkpoint, và operator đó kích hoạt được các Action như gửi Slack hay email. Bản provider 1.0.0 đã thay cho GreatExpectationsOperator cũ.

Lịch chạy mỗi đêm là việc của Dag, không phải của GX. Trước khi hứa với khách, hãy kiểm tra môi trường của họ: provider cần GX 1.7.0+ và Python 3.10+. Nếu khách còn chạy Python cũ, có khi nâng phiên bản tốn thời gian hơn cả viết kiểm tra.

Luật nào chưa nên bật cảnh báo?

GX chỉ kiểm tra những gì bạn viết ra. Nó không tự biết rằng ở công ty khách, một đơn hợp lệ phải có mã kho. Phần khó nhất vẫn là customer discovery, tức hỏi cho đủ để biết dữ liệu “đúng” nghĩa là gì với họ.

Sai lầm ngược lại cũng tai hại không kém: viết luật quá chặt. Giả sử luật trạng thái đỏ mỗi khi hệ thống nguồn thêm một trạng thái mới, dù dữ liệu không sai gì. Sau vài tuần, nhóm bên khách quen bỏ qua cảnh báo. Đến đêm cột amount rỗng thật thì không còn ai đọc.

GX có sẵn hai công cụ cho chuyện này. Mỗi Expectation có severity là critical, warning hoặc info, mặc định là critical.

Bạn tự kiểm tra: trong bốn luật trên, luật nào bạn chưa bật cảnh báo đêm nay? Một cách trả lời hợp lý là giữ critical cho mã đơn không trùng và số tiền không rỗng, vì khách xác nhận đó là luật cứng.

Luật trạng thái nên hạ xuống warning cho tới khi khách chốt danh sách. Luật số tiền không âm thì phải hỏi lại xem đơn hoàn tiền có ghi số âm không trước khi để nó gọi ai dậy.

Học gì trước, ghi gì vào CV

Hãy học các khái niệm Expectation, Validation Definition, Checkpoint và Action trước, phần Airflow để sau. Khi tìm việc, chú ý những mô tả công việc FDE có nhắc đến data quality hoặc data validation.

Trong CV, đừng chỉ ghi “dùng Great Expectations”. Hãy nói rõ bạn viết kiểm tra cho bộ dữ liệu nào, đặt mức severity ra sao, và kiểm tra đó bắt được lỗi gì trước khi lỗi đến tay khách.

Một bộ Expectation tốt còn là tài liệu trung thực nhất về dữ liệu của khách mà bạn để lại khi rời dự án.