Nguồn NotebookLM: Data Platform Engineering

Data Contract giữa producer và consumer

Nguồn gốc: Data Contract giữa producer và consumer. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Team thanh toán đổi amount từ cent sang dollar mà không báo. Pipeline vẫn chạy, nhưng doanh thu nhỏ đi 100 lần.

Data Contract (cam kết về data giữa producer và consumer) ghi lại data nào được cung cấp, ý nghĩa của nó, mức chất lượng mong đợi và cách thay đổi được quản lý.

name: payment_completed
owner: payments-team
fields:
  payment_id: {type: string, required: true}
  order_id: {type: string, required: true}
  amount_cents: {type: integer, minimum: 0}
  currency: {type: string, allowed: [SGD]}

Contract có thể gồm:

• Schema và field bắt buộc.
• Grain, key và ý nghĩa business.
• Freshness hoặc availability đã hứa.
• Quy tắc quality quan trọng.
• Owner, consumer và quy trình thay đổi.

    flowchart TD
 A["Producer<br/>Team thanh toán"] --> B["Data Contract"]
 B --> C["Consumer<br/>Pipeline doanh thu"]
 D["Đề xuất thay đổi"] --> E["Kiểm tra compatibility"]
 E --> B
  

Contract không chỉ là schema

Hai field cùng type integer vẫn có thể mang đơn vị khác nhau. Kiểm tra schema không phát hiện cent đổi thành dollar. Contract cần ghi ý nghĩa mà code và con người có thể kiểm tra.

Ai chịu trách nhiệm?

Producer chịu trách nhiệm giữ lời hứa hoặc thông báo thay đổi. Consumer chịu trách nhiệm dùng đúng mục đích và nêu dependency quan trọng. Data team hỗ trợ công cụ, checks và cách phối hợp; họ không thể tự định nghĩa data của mọi domain.

Không cần viết contract dài cho mọi bảng tạm. Hãy dùng nó ở ranh giới giữa team, nơi thay đổi có thể âm thầm làm hỏng downstream. Contract tốt làm thay đổi có chủ đích; nó không đóng băng hệ thống mãi mãi.

Metadata: data để hiểu data

Nguồn gốc: Metadata: data để hiểu data. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Warehouse có bảng fact_orders, nhưng tên bảng không cho biết một row đại diện cho gì, cập nhật lúc nào hay ai chịu trách nhiệm.

Metadata (data mô tả data) cung cấp context để con người và hệ thống hiểu, tìm và vận hành một dataset.

Ví dụ tối thiểu cho fact_orders:

name: fact_orders
grain: one row per order
owner: data-platform
freshness: every 15 minutes
primary_key: order_id
contains_pii: false

Metadata đến từ đâu?

Schema có thể lấy tự động từ warehouse. Thời gian chạy đến từ orchestrator. Owner và định nghĩa business cần con người xác nhận. Tự động thu thập giảm công sức nhưng không thể tự đoán net_revenue có trừ voucher hay không.

    flowchart TD
 A["Warehouse<br/>Schema"] --> D["Metadata"]
 B["Orchestrator<br/>Lần chạy"] --> D
 C["Con người<br/>Owner và định nghĩa"] --> D
 D --> E["Catalog, Lineage, Monitor"]
  

Metadata cũ còn nguy hiểm hơn metadata thiếu vì tạo cảm giác tin cậy sai. Hãy gắn việc cập nhật owner và mô tả vào quy trình thay đổi dataset, đồng thời tự động hoá những field máy có thể xác nhận.

Metadata là nguyên liệu cho Data Catalog và Data Lineage. Catalog giúp tìm và hiểu data; Lineage dùng quan hệ giữa các dataset để theo dấu đường đi.

Tìm đúng data với Data Catalog

Nguồn gốc: Tìm đúng data với Data Catalog. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một Analyst tìm “doanh thu” và thấy orders_revenue, daily_revenue_v2, finance_revenue_final cùng sáu bảng khác. Tên bảng không đủ để chọn.

Data Catalog (danh mục dữ liệu) là nơi giúp người dùng khám phá dataset và đọc context cần thiết để sử dụng nó.

Một entry hữu ích có thể hiển thị:

    flowchart TD
 A["Search<br/>doanh thu theo order"] --> B["Catalog entry"]
 B --> C["Đọc grain và định nghĩa"]
 C --> D["Kiểm tra freshness và owner"]
 D --> E["Dùng dataset hoặc hỏi owner"]
  

Catalog không chỉ là ô tìm kiếm. Nếu metadata nghèo, kết quả tìm kiếm vẫn là danh sách tên khó hiểu. Nếu catalog không nằm trong workflow hằng ngày, mô tả nhanh chóng lỗi thời.

Certification và deprecation

Team có thể đánh dấu dataset đã được review là Certified (được xác nhận để dùng cho mục đích nêu rõ). Bảng sắp bỏ cần trạng thái Deprecated, ngày ngừng và bảng thay thế.

Không nên hiểu Certified là đúng cho mọi câu hỏi. fact_orders phù hợp tính order revenue có thể không phù hợp tính dòng tiền đã settled.

Catalog có giá trị khi giảm thời gian hỏi “data nằm đâu?”, giúp người dùng tránh bảng cũ và chỉ đúng owner khi cần làm rõ. Hãy bắt đầu với những dataset nhiều người dùng, không phải số lượng entry lớn.

Data Lineage: data đã đi qua đâu?

Nguồn gốc: Data Lineage: data đã đi qua đâu?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Dashboard doanh thu giảm 30%. Bảng đầu ra có năm upstream table và nhiều pipeline. Data Engineer cần biết thay đổi bắt đầu ở đâu và còn ai bị ảnh hưởng.

Data Lineage (quan hệ nguồn gốc và đường đi của data) mô tả dataset được tạo từ đâu, qua bước nào và được output nào sử dụng.

    flowchart TD
 A["MySQL<br/>orders"] --> B["raw_orders"]
 C["Payment API"] --> D["raw_payments"]
 B --> E["fact_orders"]
 D --> E
 E --> F["Dashboard doanh thu"]
 E --> G["Bảng đối soát"]
  

Lineage trả lời hai hướng

Upstream của fact_orders cho biết input nào tạo ra nó. Downstream cho biết bảng, dashboard hoặc model nào phụ thuộc vào nó.

Khi payment_status đổi type, downstream lineage giúp xác định phạm vi ảnh hưởng trước khi deploy. Khi dashboard sai, upstream lineage thu hẹp nơi cần điều tra.

Lineage có nhiều mức chi tiết:

Lineage có thể thu tự động từ SQL và job, nhưng dynamic SQL hoặc thao tác thủ công dễ tạo khoảng trống. Owner vẫn cần kiểm tra những đường quan trọng.

Một sơ đồ đẹp nhưng đã cũ không giúp xử lý incident. Lineage nên gắn với metadata đang chạy, thời điểm cập nhật và link đến job thật. Bắt đầu ở dataset quan trọng thay vì cố vẽ toàn bộ công ty cùng lúc.

Data Orchestration khi nhiều job phụ thuộc nhau

Nguồn gốc: Data Orchestration khi nhiều job phụ thuộc nhau. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một script lấy order có thể chạy bằng cron. Nhưng report doanh thu còn cần thanh toán, thông tin nhà hàng và bước kiểm tra. Nếu mỗi script có lịch riêng, report có thể chạy trước khi data thanh toán sẵn sàng.

Data Orchestration (điều phối công việc data) quản lý khi nào job chạy, job nào phải đợi job nào, trạng thái từng lần chạy và cách phản ứng khi có lỗi.

    flowchart TD
    A["Lấy order"]
    B["Lấy thanh toán"]
    C["Làm sạch data"]
    D["Tạo doanh thu"]
    E["Kiểm tra Data Quality"]
    F["Công bố bảng"]
    A --> C
    B --> C
    C --> D --> E --> F
  

Schedule chưa thể hiện dependency

Một hôm API thanh toán chậm và job mất 45 phút. Job doanh thu vẫn bắt đầu lúc 01:30, đọc data chưa đủ và tạo report thấp hơn thực tế.

Orchestrator thể hiện dependency trực tiếp: doanh thu chỉ chạy khi cả hai job upstream thành công.

Mỗi lần chạy có trạng thái

scheduled → running → success
                    ↘ failed → retrying

Trạng thái giúp trả lời job đã chạy chưa, đang chờ gì, lỗi ở bước nào và thử lại bao nhiêu lần. Nếu chỉ có nhiều script và log rời rạc, Data Engineer phải tự ghép câu trả lời khi incident xảy ra.

Ngày xử lý khác giờ chạy

Job chạy lúc 01:00 ngày 9 thường xử lý ngày 8:

Job nên nhận khoảng data thay vì dùng NOW() để đoán. Nhờ vậy Retry và Backfill tạo đúng kết quả dù chạy muộn.

Orchestrator không sửa được job thiếu an toàn

Orchestrator có thể Retry, nhưng nếu task luôn INSERT toàn bộ data, Retry tạo duplicate. Nó báo job thành công nhưng không biết doanh thu đúng nếu thiếu quality check.

Một job nên nhận input rõ, chạy lại an toàn, trả lỗi khi output chưa hoàn tất và chỉ công bố data sau kiểm tra.

Một pipeline duy nhất có thể bắt đầu bằng cron. Orchestrator có ích khi có nhiều dependency, nhiều lịch, nhu cầu Retry/Backfill hoặc cần lịch sử từng lần chạy. Airflow, Dagster và Prefect là ví dụ công cụ; trước tiên hãy vẽ đúng dependency và trạng thái thất bại.

Data Observability: theo dõi sức khoẻ của pipeline

Nguồn gốc: Data Observability: theo dõi sức khoẻ của pipeline. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Data Quality check biết order_id không được rỗng. Nhưng ai phát hiện pipeline chưa chạy, data trễ ba giờ hoặc số order giảm bất thường?

Data Observability (khả năng quan sát hệ thống data) là khả năng hiểu trạng thái của pipeline và data từ các tín hiệu mà hệ thống tạo ra.

Quan sát cả job lẫn data

    flowchart TD
 A["Pipeline và data"] --> B["Metrics, logs, checks"]
 B --> C["Monitor"]
 C --> D{"Có bất thường?"}
 D -->|Có| E["Alert đúng owner"]
 E --> F["Điều tra và khôi phục"]
  

Một freshness monitor có thể kiểm tra:

max(ingested_at) phải cách hiện tại < 30 phút

Nếu source vốn chỉ gửi file lúc 6 giờ sáng, rule 30 phút sẽ báo động giả cả ngày. Monitor phải dựa trên nhịp data đã hứa.

Alert cần dẫn đến hành động

“Table failed” chưa đủ. Alert nên có dataset, partition, giá trị thực tế, ngưỡng, upstream gần nhất và owner. Cũng cần phân biệt warning với sự cố chặn người dùng.

Observability không tự đảm bảo Data Quality. Nó kết hợp checks, logs, metrics và lineage để phát hiện rồi khoanh vùng vấn đề nhanh hơn. Bắt đầu với các bảng quan trọng và tín hiệu gắn với cam kết thật; quá nhiều alert không có owner chỉ tạo tiếng ồn.

Khả năng chịu lỗi

Nguồn gốc: Khả năng chịu lỗi. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một worker bị dừng giữa lúc xử lý file. Pipeline có thể chạy lại, nhưng báo cáo sau đó có đúng không? Chịu lỗi không chỉ là tự khởi động lại tiến trình; còn là khôi phục trạng thái và kiểm soát những việc đã thực hiện.

Đặt ranh giới lỗi trước

Ví dụ tổng tiền ba file là 40000 + 60000 + 50000 = 150000. Với mỗi nhiệm vụ, thử bốn điểm lỗi:

Đây là bài tập bằng tay để tìm ranh giới commit. Nếu có mã nhiệm vụ và một kết quả được chấp nhận mỗi mã, chạy lại có thể tránh cộng trùng. Nhưng cần bảo vệ trạng thái nhiệm vụ cùng nơi lưu kết quả; hai thao tác tách rời vẫn có khoảng lỗi.

Checkpoint và replay cần tương thích

Checkpoint ghi vị trí và trạng thái để tiếp tục. Nguồn phải còn dữ liệu cần đọc lại; sink phải xử lý được các kết quả được gửi lại. Nếu checkpoint cũ hơn việc ghi sink, replay có thể tạo trùng. Nếu đánh dấu đã đọc trước khi ghi sink thành công, có thể mất kết quả.

Vì thế phải hỏi “đúng một lần” áp dụng cho trạng thái bên trong hay cả kết quả bên ngoài. Đọc idempotency và retry để thấy hai phần này phối hợp thế nào.

Quorum cũng có giới hạn

Ví dụ Raft dùng đa số để duy trì log được đồng thuận. Trong cụm 3 node, đa số là 2; mất một node vẫn có thể tiến triển nếu hai node còn lại liên lạc được. Mất liên lạc với đa số có thể khiến hệ thống ngừng tiến triển để giữ an toàn. Các giả định và cơ chế xem trong Raft paper; không áp công thức này cho mọi hệ replication.

Ba container trên cùng laptop không bảo vệ khỏi laptop mất điện. Replication cũng không thay backup chống xóa nhầm. Cần xác định lỗi nào mình muốn chịu và phần nào có chung điểm hỏng.

Phục hồi là một thứ cần thử

Đo lượng dữ liệu có thể mất và thời gian khôi phục; ghi rõ người hoặc hệ thống nào thực hiện. Với ví dụ nhỏ, kết quả cuối phải là 150000 sau từng ca lỗi và chạy lại. Với hệ thống thật, còn cần kiểm tra dữ liệu trùng, bị thiếu, quyền truy cập và tác động tới người dùng.

Một hệ thống tự chạy lại mãi nhưng không báo nguyên nhân lỗi chưa phải dễ vận hành. Hãy để log chỉ ra nhiệm vụ, checkpoint và trạng thái cuối mà người trực có thể đối chiếu.