Nguồn NotebookLM: Nhập môn Data Engineering

Data Engineer là gì?

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

Data Engineer (kỹ sư dữ liệu) là người xây dựng và vận hành hệ thống đưa data từ nơi nó được tạo ra đến nơi nó có thể được sử dụng.

Nghe vẫn hơi chung chung, nên mình thử bắt đầu bằng một đơn hàng.

Bạn đặt một phần cơm trên ứng dụng. Đơn hàng được lưu trong MySQL, kết quả thanh toán nằm ở một hệ thống khác, còn thông tin giao hàng lại nằm ở hệ thống của tài xế. Đây là các Source System (hệ thống nguồn). Công ty muốn biết hôm nay có bao nhiêu đơn, doanh thu là bao nhiêu và nhà hàng nào thường giao trễ.

Data đã có, nhưng đang nằm rải rác. Data Engineer lo phần ở giữa:

    flowchart TD
    A["Application<br/>Đơn hàng, thanh toán, giao hàng"]
    B["Data Engineer<br/>Đưa về, làm sạch, kết hợp, vận hành"]
    C["Data đáng tin cậy<br/>Các bảng đã sẵn sàng sử dụng"]
    D["Người sử dụng<br/>Report, phân tích, sản phẩm"]
    A --> B --> C --> D
  

Data Engineer không tạo ra đơn hàng và cũng không phải người quyết định nhà hàng nào hoạt động tốt. Họ xây con đường giúp data đi từ application đến những người cần nó.

Data Engineer làm những gì?

Phạm vi công việc khác nhau ở mỗi công ty, nhưng thường có năm phần chính.

Xây Data Pipeline

Data Pipeline (luồng xử lý đưa data qua nhiều bước) lấy data từ application, Database (cơ sở dữ liệu), file hoặc API (cách hai hệ thống trao đổi với nhau) rồi đưa về nền tảng data.

Ví dụ, cứ mỗi năm phút, chương trình đọc các đơn mới hoặc vừa thay đổi trong bảng orders của MySQL rồi sao chép sang nền tảng data.

Pipeline cần chạy nhiều lần mà không bỏ sót hoặc tạo thêm đơn hàng giả.

Tổ chức Data Storage

Data Storage (nơi lưu trữ data) có thể là Data Warehouse (kho dữ liệu), Data Lake (hồ dữ liệu) hoặc một database dành cho phân tích. Data Engineer chọn cách chia bảng, định dạng và thời gian lưu giữ để data có thể được tìm thấy và sử dụng lại.

Trong ví dụ đặt đồ ăn, data có thể được tách thành:

Làm Data Transformation

Data Transformation (biến đổi data) biến các row rời rạc thành data dễ sử dụng hơn. Chẳng hạn, để biết đơn hàng thuộc nhà hàng nào, mình lấy restaurant_id trong orders để tìm sang restaurants. Còn thanh toán và giao hàng được nối về đơn bằng order_id.

Trước khi ghép, có một câu cần hỏi: mỗi row trong bảng đại diện cho điều gì? Đó là grain của bảng. Với bốn bảng đang xét:

    flowchart LR
    P["payments.order_id"] --> O["orders.order_id"]
    D["deliveries.order_id"] --> O
    R["orders.restaurant_id"] --> S["restaurants.restaurant_id"]
  

Một đơn có thể được thanh toán lại sau lần đầu thất bại. Nếu ghép thẳng tất cả lần thanh toán vào đơn hàng, số tiền của đơn có thể xuất hiện nhiều lần. Vì vậy, mình cần xử lý các lần thanh toán và chuyến giao về cấp đơn trước khi làm report.

Để dễ theo dõi, ở đây đơn ORD-1042 chỉ có một thanh toán thành công và một chuyến giao. Đơn trị giá 120,000 VND, đặt lúc 12:02:10 và giao lúc 12:32:18 ngày 06/09/2026, theo giờ Singapore. Làm tròn đến phút thì mất 30 phút.

Mã RES-18 dẫn tới nhà hàng Cơm Nhà, payment cho biết đơn đã trả tiền, còn bảng giao hàng ghi nhận lúc hoàn tất. Giả sử ứng dụng hẹn giao trước 12:40, đơn này được tính là đúng giờ.

Đầu ra có thể là một bảng đã tính sẵn:

Data Analyst không cần tự ghép lại các hệ thống mỗi lần làm report.

Giữ Data Quality

Data Quality (chất lượng data) trả lời câu hỏi: data này có đủ đúng để sử dụng không?

Data Engineer có thể thêm các kiểm tra đơn giản:

Một dashboard đẹp không có nhiều ý nghĩa nếu số liệu phía sau sai.

Vận hành và theo dõi

Đưa pipeline lên chạy chưa phải là xong. Monitoring (theo dõi hệ thống) giúp team biết pipeline có chạy đúng giờ, có lỗi và data có đến đủ hay không.

Ví dụ, pipeline đơn hàng thường hoàn tất lúc 7 giờ sáng nhưng hôm nay đến 8 giờ vẫn chưa xong. Data Engineer cần tìm nguyên nhân, sửa lỗi, chạy bù phần data còn thiếu rồi kiểm tra report đã trở lại bình thường chưa.

Đây là phần ít xuất hiện trong các bài demo, nhưng lại chiếm khá nhiều thời gian khi làm việc thật.

Một ngày làm việc có thể như thế nào?

Không có ngày nào giống hệt ngày nào. Một ngày tương đối bình thường có thể gồm:

Công việc có cả code, hiểu data, xử lý sự cố và trao đổi với những team khác.

Khác Data Analyst và Data Scientist ở đâu?

Ba vai trò cùng làm việc với data nhưng thường chịu trách nhiệm cho những phần khác nhau:

Đây chỉ là cách phân chia để dễ hình dung. Ở công ty nhỏ, một người có thể vừa xây pipeline vừa làm report. Ở công ty lớn, trách nhiệm thường được chia rõ hơn.

Khi đọc một job description, đừng chỉ nhìn chức danh. Hãy xem mình sẽ xây hệ thống nào, chịu trách nhiệm cho data nào và ai sẽ dùng đầu ra đó.

Data Engineer cần biết gì?

Bạn chưa cần học mọi công nghệ để bắt đầu. Thay vì xem đây là một thứ tự cứng, có thể chia kiến thức thành năm lớp:

    flowchart TD
    A["1. Nền tảng<br/>Database, SQL, Python"]
    B["2. Data cho phân tích<br/>Data Warehouse, Data Modeling"]
    C["3. Di chuyển và xử lý<br/>Data Pipeline, ETL / ELT"]
    D["4. Vận hành<br/>Orchestration, Data Quality, Monitoring"]
    E["5. Mở rộng khi cần<br/>Cloud, Distributed Systems"]
    A --> B --> C --> D --> E
  

Database và SQL nên đi cùng nhau: một bên giúp bạn hiểu data được lưu ra sao, bên còn lại giúp bạn đọc và kiểm tra data đó. Python cho bạn cách viết chương trình thay vì xử lý mọi thứ bằng tay.

Sau phần nền tảng, Data Warehouse giúp bạn hiểu nơi data dùng cho phân tích được tổ chức như thế nào. Đây cũng là lúc học Data Modeling (mô hình hoá data), đặc biệt là cách thiết kế bảng để trả lời câu hỏi business.

Khi đã hiểu data bắt đầu ở đâu và cần đi đến đâu, Data Pipeline cùng ETL / ELT (các bước lấy, biến đổi và đưa data vào nơi lưu trữ) sẽ dễ hình dung hơn. Sau đó mới đến Orchestration (điều phối pipeline), Data Quality và Monitoring để hệ thống chạy ổn định.

Cloud (điện toán đám mây) và Distributed Systems (hệ thống phân tán) quan trọng khi hệ thống lớn lên, nhưng không phải điều kiện để bạn làm pipeline đầu tiên. Công cụ nào cũng chỉ nên được học khi bạn hiểu nó đang giải quyết vấn đề gì.

Nếu tò mò về cách chia công việc khi công ty có nhiều data team, bạn có thể đọc thêm Data Engineer trong Data Mesh. Phần này có thể để sau.

Tóm lại

Data Engineer giúp biến data đang nằm rải rác thành data mà người khác có thể tìm thấy, hiểu và tin tưởng sử dụng. Họ xây pipeline, tổ chức nơi lưu trữ, biến đổi data, kiểm tra chất lượng và giữ cho hệ thống tiếp tục chạy khi có sự cố.

Để nhìn rõ phần việc đó, mình sẽ theo một đơn hàng trong bài Data đi qua một hệ thống như thế nào?.

Data đi qua một hệ thống như thế nào?

Nguồn gốc: Data đi qua một hệ thống như thế nào?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Giả sử bạn vừa đặt một phần cơm trên ứng dụng giao đồ ăn. Bạn bấm Đặt món, ứng dụng báo thành công, rồi khoảng ba mươi phút sau tài xế xuất hiện trước cửa.

Với bạn, giao dịch đó đã kết thúc. Với hệ thống data, nó chỉ vừa bắt đầu.

Sơ đồ dưới đây là đường đi chúng ta sẽ theo trong bài:

    flowchart TD
    A["1. Source System<br/>App tạo ra data"]
    B["2. Data Ingestion<br/>Đưa data về một nơi"]
    C["3. Data Storage<br/>Lưu data"]
    D["4. Data Transformation<br/>Làm sạch và kết hợp"]
    E["5. Data Serving<br/>Đưa data cho người dùng"]
    F["6. Retention / Deletion<br/>Lưu giữ hoặc xoá"]
    A --> B --> C --> D --> E --> F
  

Data Generation

Data Generation (quá trình data được tạo ra) bắt đầu khi đơn hàng được đặt. Hệ thống có thể ghi lại mã đơn, nhà hàng, món ăn, giá tiền, phương thức thanh toán và thời gian tạo đơn. Trong lúc giao hàng, nó tiếp tục nhận vị trí tài xế và các lần thay đổi trạng thái.

Data này không nhất thiết nằm cùng một chỗ. Đơn hàng có thể nằm trong một database như MySQL. Kết quả thanh toán nằm trong hệ thống thanh toán, còn trạng thái giao hàng nằm trong hệ thống của tài xế.

Đây là các Source System (hệ thống nguồn). Chúng được xây để ứng dụng hoạt động, chứ không phải để trả lời mọi câu hỏi phân tích của công ty.

Khi bạn đặt món, application có thể thêm một row vào bảng orders trong MySQL:

Khi nhà hàng nhận đơn hoặc tài xế giao hàng thành công, row này có thể được cập nhật sang trạng thái mới. Đây là data phục vụ hoạt động của application. Nó chưa được chuẩn bị để trả lời những câu hỏi như “Hôm nay có bao nhiêu đơn giao trễ?”.

Data Ingestion

Đội vận hành muốn biết hôm nay có bao nhiêu đơn giao trễ. Đội tài chính cần đối soát thanh toán. Nhà hàng muốn xem món nào bán chạy. Nếu tất cả cùng truy vấn thẳng vào database của ứng dụng, họ có thể làm chậm hệ thống đang phục vụ khách hàng.

Vì vậy, data được sao chép từ các Source System về một nơi dành cho việc xử lý và phân tích. Quá trình này được gọi là Data Ingestion (thu thập và đưa data vào hệ thống).

Cùng một đơn hàng có thể đi vào nền tảng data qua nhiều đường:

Nhưng làm sao biết một thanh toán thuộc đơn nào? Có nguồn giữ sẵn order_id, có nguồn chỉ trả về mã riêng như payment_ref. Trong trường hợp thứ hai, mình cần nhờ Backend cung cấp bảng ánh xạ:

Nhờ bảng này, pipeline biết PAY-501 thuộc về ORD-1042. Nó nối qua payment_ref trước rồi mới tìm đến orders. Trong ví dụ, mỗi mã thanh toán thuộc một đơn, dù một đơn có thể có nhiều lần thanh toán. Nếu chưa tìm được mã tương ứng, giao dịch cần được giữ lại để kiểm tra.

Data Storage

Data Storage (lưu trữ data) cho data một nơi để sống lâu hơn Source System. Tuỳ nhu cầu, nó có thể được lưu trong Data Warehouse (kho dữ liệu), Data Lake (hồ dữ liệu) hoặc Lakehouse (kiến trúc kết hợp Data Warehouse và Data Lake).

Ở thời điểm này, data chưa chắc đã dễ dùng. Tên nhà hàng có thể nằm trong một bảng, thông tin đơn hàng nằm ở bảng khác, còn data thanh toán dùng một mã định danh khác hoàn toàn.

Data của ORD-1042 có thể được lưu ở ba lớp:

Không phải hệ thống nào cũng gọi ba lớp này bằng cùng một cái tên. Điều cần nhớ là data gốc và data đã qua xử lý thường được tách ra để tránh ghi đè lên nhau.

Data Processing and Transformation

Trong bước này, Data Processing (xử lý data) và Data Transformation (biến đổi data) được dùng để kiểm tra, làm sạch và kết hợp data. Ví dụ, một pipeline có thể:

1. Loại những lần cập nhật bị gửi trùng.
2. Chuẩn hoá tất cả thời gian về cùng múi giờ.
3. Ghép đơn hàng với nhà hàng và giao dịch thanh toán.
4. Tính thời gian từ lúc đặt món đến lúc giao thành công.
5. Tạo một bảng chỉ gồm các chỉ số mà đội vận hành cần.

Nếu bước này sai, dashboard phía sau có thể vẫn trông rất đẹp nhưng con số không còn đáng tin.

Mình thử với ba row dưới đây. Các số tiền đều là VND, còn report dùng giờ Singapore, tức UTC+08:00:

Hai row đầu là cùng một lần cập nhật bị sao chép hai lần. Row cuối dùng UTC thay vì giờ Singapore. Sau khi loại trùng và chuẩn hoá timezone, pipeline mới tính được:

Nếu bỏ qua bước loại trùng, dashboard sẽ báo ba đơn và 58,000 tiền giao hàng dù thực tế chỉ có hai đơn.

Múi giờ còn có thể làm một đơn chuyển sang ngày báo cáo khác. Giả sử có thêm ORD-1044, giao lúc 2026-09-06 16:05:00Z, với phí 10,000 VND. Nhìn phần ngày, mình dễ xếp đơn này vào ngày 6. Nhưng đổi sang giờ Singapore thì đã là 00:05 ngày 7.

Vì vậy, ngày 6 vẫn có hai đơn và 40,000 VND tiền giao hàng. Ngày 7 mới có thêm một đơn và 10,000 VND. Cột delivery_date ở đây là ngày giao theo giờ địa phương. Trong ví dụ, mỗi đơn có một lần giao thành công; hai bản sao giống nhau của ORD-1042 được loại trước khi đếm.

Data Serving

Data Serving (cung cấp data cho người dùng hoặc hệ thống khác) bắt đầu khi data đã ở dạng ổn định. Data Analyst có thể dùng nó để làm dashboard, Data Scientist có thể xây mô hình dự đoán thời gian giao hàng, còn một dịch vụ nội bộ có thể dùng nó để cảnh báo nhà hàng đang quá tải.

Cùng một data ban đầu có thể phục vụ nhiều nhu cầu. Data Engineer không quyết định thay tất cả những người dùng đó, nhưng cần hiểu họ cần gì để thiết kế data phù hợp.

Từ row của ORD-1042, các đầu ra có thể rất khác nhau:

Data Serving vì vậy không chỉ có dashboard. Đầu ra cũng có thể là table, file hoặc API cho một hệ thống khác.

Data Retention and Deletion

Theo thời gian, một phần data sẽ ít được truy cập hơn. Data Retention (lưu giữ data) quy định data cần được giữ trong bao lâu. Công ty có thể chuyển data cũ sang nơi lưu trữ rẻ hơn hoặc thực hiện Data Deletion (xoá data) theo quy định về quyền riêng tư.

Ngoài ra còn có Metadata (siêu dữ liệu): data đến từ đâu, ai sở hữu, pipeline nào đã thay đổi nó và dashboard nào đang sử dụng nó. Khi hệ thống lớn lên, những thông tin này giúp mọi người lần ngược được một con số thay vì đoán.

Chẳng hạn, một công ty có thể đặt thời hạn như bảng dưới. Đây là những mốc giả định; thời hạn thật còn phụ thuộc nhu cầu và quy định áp dụng cho công ty đó:

Metadata của bảng đơn hàng cũng có thể ghi rõ team nào chịu trách nhiệm, pipeline nào tạo ra bảng và dashboard nào đang sử dụng nó. Khi pipeline thay đổi, team biết cần kiểm tra những đầu ra nào.

Bức tranh cần nhớ

Một data flow thường đi qua các bước:

Source System → Data Ingestion → Data Storage → Data Transformation → Data Serving → Data Retention / Data Deletion

Ngoài đời, đường đi hiếm khi thẳng và gọn như sơ đồ này. Pipeline có thể chạy lỗi, data đến muộn, schema thay đổi hoặc người dùng cần một cách tính mới. Phần lớn công việc Data Engineering nằm ở việc xử lý những tình huống đó.

Từ đường đi này, mình thử ghép thành một hệ thống nhỏ mà Data Engineer có thể xây.

Python: bắt đầu từ một script tính doanh thu

Nguồn gốc: Python: bắt đầu từ một script tính doanh thu. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Bạn đã tính doanh thu bằng SQL. Python hữu ích khi cần đọc nhiều file, kiểm tra từng bản ghi hoặc gọi các bước xử lý theo thứ tự. Mình bắt đầu bằng một script nhỏ để thấy rõ dữ liệu đi qua code thế nào.

Chạy ở đâu?

Ví dụ đã kiểm tra trên Python 3.12, dùng thư viện chuẩn, không cần cài package. Kiểm tra python3 --version trên macOS/Linux hoặc py -3 --version trên Windows. Nếu thiếu, dùng trang tải chính thức và hướng dẫn đúng hệ điều hành. Windows chưa được kiểm thử trong đợt này.

Lưu code vào file UTF-8 tên doanh_thu.py trong thư mục học riêng, mở terminal ở thư mục đó và chạy python3 doanh_thu.py hoặc py -3 doanh_thu.py.

Từ bản ghi tới tổng

Mỗi dictionary là một đơn có mã duy nhất. Tiền là số nguyên đồng; chỉ trạng thái paid được tính. Ví dụ chưa xử lý hoàn tiền hoặc nhiều đơn vị tiền tệ.

orders = [
    {"order_id": 1, "status": "paid", "amount_vnd": 40000},
    {"order_id": 2, "status": "cancelled", "amount_vnd": 50000},
    {"order_id": 3, "status": "paid", "amount_vnd": 60000},
]

def paid_revenue(rows):
    total = 0
    for row in rows:
        if row["status"] == "paid":
            total += row["amount_vnd"]
    return total

print(paid_revenue(orders))
print(paid_revenue([]))

Kết quả là 100000, rồi 0. orders là list các dòng; row nhận từng dòng trong vòng lặp. Hàm nhận dữ liệu qua tham số, trả kết quả bằng return. Thụt đầu dòng xác định phần thuộc vòng lặp và điều kiện, không chỉ để trang trí.

Chạy được chưa đủ

Thêm một bản sao đơn 1, tổng thành 140000. Hàm chưa biết khóa bị trùng; chính mình phải xác định quy tắc nhận diện và kiểm tra trùng. Đổi amount_vnd thành chuỗi "40000" cũng khác với số 40000: dữ liệu từ CSV cần chuyển kiểu trước khi cộng.

Nếu gặp KeyError, một dòng có thể thiếu cột cần dùng. Nếu gặp TypeError, kiểm tra kiểu của các giá trị tham gia phép toán. Không bắt mọi lỗi rồi trả 0, vì báo cáo sẽ trông hợp lệ dù dữ liệu hỏng.

Với list rỗng, hàm trả 0 vì đó là hợp đồng mình vừa viết. Trong một pipeline thật, “không nhận được file” có thể là lỗi, khác với “file hợp lệ và không có đơn”. Quyết định ở bước đọc dữ liệu trước khi gọi hàm.

Đọc tiếp CSV và JSON. Tham khảo cú pháp tại Python tutorial.

Đọc CSV và JSON: đọc được chưa có nghĩa đúng kiểu

Nguồn gốc: Đọc CSV và JSON: đọc được chưa có nghĩa đúng kiểu. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một file CSV có ô 40000, nhưng khi đọc bằng csv.DictReader, giá trị thường là chuỗi. Nếu cộng mà chưa kiểm tra kiểu, chương trình có thể lỗi hoặc thực hiện một việc khác với phép cộng tiền.

CSV mô tả các trường trên dòng; dấu phân cách, quoting và encoding phải được thống nhất. JSON biểu diễn object, array, số, boolean và null, nhưng đọc JSON thành công không chứng minh schema nghiệp vụ đúng.

Một vòng đọc và ghi trên máy

Ví dụ dùng Python 3.12, thư viện chuẩn, đã chạy kiểm tra. Lưu thành doc_file.py, chạy như bài đầu. Script tạo thư mục tạm riêng, ghi fixture, đọc lại và dọn thư mục khi kết thúc; không ghi đè file của bạn.

Mỗi dòng là một đơn, mã duy nhất, trạng thái paid hoặc cancelled. Số tiền là đồng nguyên không âm.

import csv
import json
from pathlib import Path
from tempfile import TemporaryDirectory

fixture = "order_id,status,amount_vnd\n1,paid,40000\n2,cancelled,50000\n3,paid,60000\n"
with TemporaryDirectory(prefix="cafe-files-") as folder:
    source = Path(folder) / "orders.csv"
    source.write_text(fixture, encoding="utf-8")
    total = 0
    seen = set()
    with source.open(encoding="utf-8", newline="") as stream:
        reader = csv.DictReader(stream)
        if reader.fieldnames != ["order_id", "status", "amount_vnd"]:
            raise ValueError("Header không đúng hợp đồng")
        for row in reader:
            order_id = int(row["order_id"])
            amount = int(row["amount_vnd"])
            if order_id in seen or amount < 0:
                raise ValueError("Trùng khóa hoặc số tiền âm")
            if row["status"] not in {"paid", "cancelled"}:
                raise ValueError("Trạng thái không hợp lệ")
            seen.add(order_id)
            if row["status"] == "paid":
                total += amount
    report = {"cửa_hàng": "Quán nhỏ", "revenue_vnd": total}
    output = Path(folder) / "report.json"
    output.write_text(json.dumps(report, ensure_ascii=False), encoding="utf-8")
    restored = json.loads(output.read_text(encoding="utf-8"))
    print(restored["cửa_hàng"], restored["revenue_vnd"])

Đầu ra: Quán nhỏ 100000. newline="" để module CSV xử lý newline; encoding="utf-8" làm rõ cách giải mã. ensure_ascii=False giữ chữ Việt dễ đọc trong file JSON, không thay đổi ý nghĩa dữ liệu.

Thử ca hỏng

Đổi số tiền đơn 3 thành sáu mươi: int phải báo lỗi, không biến thành 0. Đổi mã đơn 3 thành 1: kiểm tra khóa trùng phải từ chối. Đổi paid thành PAID: ví dụ từ chối vì chưa có quy tắc chuẩn hóa. Nếu nguồn cho phép cả hai, sửa hợp đồng rồi mới sửa code.

Ví dụ nhỏ chưa kiểm tra hết số cột thừa/thiếu trên mỗi dòng, BOM, kích thước lớn hoặc mọi định dạng số. Khi áp dụng cho file ngoài, cần bổ sung kiểm tra cấu trúc dòng và giới hạn input. Không dùng split(',') thay parser khi trường có thể chứa dấu phẩy trong dấu nháy.

Nguồn: Python csv, Python json. Xem tiếp xử lý lỗi.

Lỗi và logging: biết dòng nào sai, vì sao job dừng

Nguồn gốc: Lỗi và logging: biết dòng nào sai, vì sao job dừng. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Job hiện “thành công”, nhưng đã bỏ qua một nửa số đơn. Đôi khi nguyên nhân là một khối except quá rộng: lỗi gì cũng bỏ qua, không ghi lại dòng hoặc lý do. Mình cần quy tắc về lỗi trước khi quyết định tiếp tục.

Dữ liệu không hợp lệ, file không tồn tại, database mất kết nối và bug trong code là những lỗi khác nhau. Một dòng tiền sai có thể được đưa vào danh sách để xem lại. Mất toàn bộ file đầu vào thường không nên biến thành báo cáo 0 đồng.

Một lỗi dự kiến, một thông báo hữu ích

Lưu ví dụ thành file Python và chạy cục bộ bằng Python 3.12. Nó dùng dữ liệu giả lập, không cần thư viện ngoài. Mỗi dòng là một khoản tiền của một đơn riêng; ví dụ tập trung chuyển kiểu, chưa xử lý trùng khóa.

import logging

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(message)s")
rows = [(101, "40000"), (102, "không rõ"), (103, "60000")]
accepted = []
rejected = []
for order_id, raw_amount in rows:
    try:
        amount = int(raw_amount)
        if amount < 0:
            raise ValueError("amount must be non-negative")
    except ValueError:
        rejected.append((order_id, "invalid_amount"))
        logging.warning("order_id=%s reason=invalid_amount", order_id)
        continue
    accepted.append((order_id, amount))
logging.info("accepted=%s rejected=%s", len(accepted), len(rejected))
print(sum(amount for _, amount in accepted))
print(rejected)

Kết quả chuẩn: tổng 100000, danh sách loại [(102, ‘invalid_amount’)]. Log có một WARNING cho đơn 102 và một INFO với accepted=2 rejected=1. Logging mặc định gửi sang stderr, còn print gửi stdout; khi gom hai luồng, thứ tự hiển thị có thể khác.

Đây là tổng của các dòng được chấp nhận, không tự là doanh thu đầy đủ. Người dùng báo cáo phải biết có dòng bị loại; nếu yêu cầu không được thiếu đơn, job cần dừng hoặc đánh dấu báo cáo chưa sẵn sàng.

Bắt đúng loại lỗi

Khối try chỉ bao quanh phần chuyển kiểu có thể tạo ValueError. Nếu viết sai tên biến ở chỗ khác, chương trình nên báo lỗi để mình sửa, không nuốt nó như dữ liệu xấu. Khi log rồi ném lỗi tiếp, logging.exception bên trong except giúp giữ traceback; cân nhắc log có chứa dữ liệu nhạy cảm hay không.

Không ghi nguyên request, token hoặc tất cả dữ liệu khách hàng chỉ vì đang debug. Một mã nhiệm vụ, mã dòng và mã lý do thường đủ để tìm ca cần điều tra. Với dữ liệu thật, cả ID cũng cần tuân theo quyền truy cập và chính sách giữ log.

Kiểm tra hành vi sau lỗi

Đổi không rõ thành 50000: tổng thành 150000 và danh sách loại rỗng. Đổi thành -1: vẫn phải bị loại. Nếu thêm lỗi lập trình như gọi một hàm chưa tồn tại, nó phải làm chương trình thất bại; không được xuất báo cáo bình thường.

Tham khảo: Python exceptions, Logging HOWTO.

SQL là gì?

Nguồn gốc: SQL là gì?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Quán cà phê có bốn đơn hàng. Bạn muốn biết ngày nào bán được bao nhiêu tiền, nhưng không muốn cộng cả đơn đã hủy. Đây là một câu hỏi nhỏ mà SQL làm rất tốt.

SQL là ngôn ngữ để làm việc với dữ liệu trong các hệ quản trị cơ sở dữ liệu và nhiều công cụ phân tích. Với truy vấn, mình mô tả dữ liệu muốn lấy; engine chọn cách thực hiện. Viết đúng cú pháp mới chỉ là bước đầu. Mình còn phải biết mỗi dòng là gì và “doanh thu” được tính thế nào.

Thử ngay trên máy của bạn

Các ví dụ trong nhóm SQL dùng SQLite 3.25 trở lên, chạy cục bộ và không cần tài khoản. Mình đã kiểm tra chúng với SQLite 3.53.4 qua Python; đây là ví dụ học SQL, không phải đề xuất dùng SQLite cho mọi warehouse.

Gõ sqlite3 --version trong terminal. Nếu chưa có lệnh này, xem hướng dẫn CLI của SQLite để chọn bản dành cho hệ điều hành của bạn. Nếu máy đã có Python 3, kiểm tra engine bằng python3 -c "import sqlite3; print(sqlite3.sqlite_version)".

Tải file dữ liệu cafe.sql, lưu vào thư mục riêng rồi mở terminal tại đó:

sqlite3 cafe.db < cafe.sql
sqlite3 cafe.db

Chỉ chạy bước nhập một lần với một file cafe.db mới. Nếu nhận lỗi table already exists, dữ liệu đã được tạo; mở database thay vì nhập lại. Trong cửa sổ SQLite, gõ .headers on và .mode column để dễ đọc; .quit để thoát. Cần làm lại thì dùng tên database mới, chẳng hạn cafe-lan-2.db.

File dữ liệu

Tải cafe.sql. Dữ liệu hoàn toàn giả lập, mã fixture cafe-v1. Mỗi dòng orders là một đơn, khóa order_id; mỗi dòng customers là một khách; mỗi dòng payments là một lần thử thanh toán. business_date là ngày kinh doanh theo giờ Việt Nam đã được xác định sẵn, không phải timestamp UTC. Số tiền dùng số nguyên đồng.

Lọc trước, cộng sau

SELECT business_date, COUNT(*) AS order_count,
       SUM(amount_vnd) AS revenue_vnd
FROM orders
WHERE status = 'paid'
GROUP BY business_date
ORDER BY business_date;

Bạn sẽ thấy ngày 2026-09-01 có 2 đơn, 100000 đồng; ngày 2026-09-02 có 1 đơn, 50000 đồng. Đơn 104 bị hủy nên không nằm trong phép tính.

WHERE chọn dòng trước khi gom nhóm. GROUP BY tạo một dòng cho mỗi ngày. Nếu muốn chỉ giữ ngày có doanh thu từ 80000 đồng, thêm HAVING SUM(amount_vnd) >= 80000 trước ORDER BY. ORDER BY là điều bạn cần viết khi thứ tự kết quả có ý nghĩa; không nên dựa vào thứ tự tình cờ engine trả về.

NULL không phải số không

Đơn 104 không có khách được nhận diện. Tìm nó bằng WHERE customer_id IS NULL, không phải customer_id = NULL. Giá trị chưa biết khác với khách có mã 0, chuỗi rỗng hoặc số tiền bằng 0. Thử SELECT COUNT(*), COUNT(customer_id) FROM orders;: kết quả là 4 và 3, vì phép đếm cột bỏ qua NULL.

Khi dữ liệu rỗng, COUNT(*) trả 0 nhưng SUM có thể trả NULL. Chỉ dùng COALESCE(..., 0) khi định nghĩa báo cáo thật sự cho phép hiểu “không có dữ liệu” thành số không.

Học tiếp

Khi câu hỏi cần tên khách, đọc JOIN. Khi muốn giữ từng đơn nhưng thêm tổng của khách, xem window functions.

Tham khảo: SQLite SELECT và PostgreSQL SQL tutorial. Cú pháp cơ bản khá giống nhau; kiểu dữ liệu và tính năng nâng cao cần kiểm tra theo engine bạn dùng.

Kết hợp dữ liệu với JOIN

Nguồn gốc: Kết hợp dữ liệu với JOIN. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Bạn có mã khách trong bảng đơn hàng, tên khách trong bảng khách hàng. JOIN nối những dòng phù hợp để mình đọc chúng cùng nhau. Nhưng nếu một đơn khớp với nhiều dòng phía bên kia, đơn đó cũng xuất hiện nhiều lần trong kết quả.

Bài này dùng cafe-v1, SQLite 3.25 trở lên. Làm bước tạo database trong bài SQL đầu tiên trước khi chạy các truy vấn.

Nối đơn với khách

orders có một dòng mỗi đơn. customers có một dòng mỗi khách, khóa customer_id không trùng.

SELECT o.order_id, c.customer_name, o.amount_vnd
FROM orders AS o
LEFT JOIN customers AS c ON o.customer_id = c.customer_id
ORDER BY o.order_id;

Kết quả có 4 dòng: 101–An–40000, 102–An–60000, 103–Bình–50000, 104–NULL–30000. LEFT JOIN giữ cả đơn không tìm được khách. INNER JOIN chỉ giữ các cặp khớp, nên trường hợp này còn 3 dòng. Cả hai đều có ích; lựa chọn phụ thuộc bạn có muốn giữ những đơn chưa xác định khách hay không.

Một đơn có hai lần thử thanh toán

Trong payments, đơn 101 có một lần thất bại rồi một lần thành công. Nếu nối trực tiếp và cộng tiền đơn:

SELECT SUM(o.amount_vnd) AS wrong_revenue
FROM orders AS o
JOIN payments AS p ON o.order_id = p.order_id
WHERE o.status = 'paid';

Kết quả là 190000, trong khi tổng ba đơn đã thanh toán chỉ là 150000. Đơn 101 xuất hiện hai lần. Đây không phải engine cộng sai; mình đã đổi số dòng mà không để ý.

Không sửa bằng SUM(DISTINCT amount_vnd): hai đơn khác nhau có thể cùng giá tiền, và khi đó bạn lại cộng thiếu. Cũng đừng dùng DISTINCT cả truy vấn chỉ để che việc khóa nối không duy nhất.

Nếu chỉ cần biết có thanh toán thành công

SELECT SUM(o.amount_vnd) AS revenue_vnd
FROM orders AS o
WHERE o.status = 'paid'
  AND EXISTS (
    SELECT 1 FROM payments AS p
    WHERE p.order_id = o.order_id AND p.status = 'success'
  );

Kết quả 150000. EXISTS kiểm tra có dòng phù hợp, không tạo thêm dòng đơn. Nếu cần số lần thử, hãy gom payments thành một dòng mỗi order_id rồi mới JOIN.

Điều kiện đặt ở đâu?

Sau LEFT JOIN, WHERE p.status = 'success' sẽ loại những dòng không có payment vì phía p là NULL. Nếu muốn giữ tất cả đơn, đưa điều kiện này vào ON. Tuy nhiên, nhiều payment thành công vẫn có thể làm nhân dòng; vị trí điều kiện không thay thế việc hiểu quan hệ một–nhiều.

Trước khi nối, mình thường hỏi: mỗi bảng có một dòng cho thứ gì, khóa có trùng không, và kết quả cần một dòng cho thứ gì? Sau đó kiểm tra số dòng và vài khóa cụ thể, không chỉ tổng cuối cùng.

Thử thêm một đơn đã trả tiền giá 40000 đồng: cách dùng EXISTS phải tăng tổng lên 190000; SUM(DISTINCT...) sẽ không tăng đúng. Đây là một ca kiểm tra nhỏ để phát hiện cách sửa sai.

Đọc thêm: PostgreSQL: Joins between tables. Bước tiếp theo là dùng CTE để tách các mức tổng hợp.

Biểu thức bảng chung (CTE)

Nguồn gốc: Biểu thức bảng chung (CTE). Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một truy vấn vừa nối nhiều bảng vừa tổng hợp vừa lọc thường khó kiểm tra. Mình thích đặt tên cho từng bước: lấy đơn đã thanh toán, tính tổng mỗi khách, rồi chọn khách cần xem. CTE, viết bằng WITH, cho phép làm việc đó trong một câu SQL.

Ví dụ dùng cafe-v1, SQLite 3.25 trở lên. Xem cách tạo database nếu bạn chưa có dữ liệu.

Đặt tên cho kết quả trung gian

WITH paid_orders AS (
  SELECT customer_id, amount_vnd
  FROM orders
  WHERE status = 'paid'
), customer_totals AS (
  SELECT customer_id, SUM(amount_vnd) AS total_vnd
  FROM paid_orders
  GROUP BY customer_id
)
SELECT c.customer_name, t.total_vnd
FROM customer_totals AS t
JOIN customers AS c ON t.customer_id = c.customer_id
WHERE t.total_vnd >= 80000
ORDER BY c.customer_id;

Kết quả có một dòng: An, 100000. Tên paid_orders nói rõ dữ liệu còn lại sau bước lọc. customer_totals có một dòng mỗi khách, nên bước JOIN sau đó dễ kiểm tra hơn.

CTE chỉ có tên trong câu lệnh này. Nó không tạo một bảng lưu lâu dài. Truy vấn kế tiếp không thể SELECT * FROM paid_orders trừ khi bạn đã tạo một bảng hoặc view mang tên đó.

Kiểm tra từng bước

Giữ phần WITH và thay SELECT cuối bằng SELECT * FROM paid_orders;: bạn cần thấy ba đơn đã trả tiền. Đổi sang SELECT * FROM customer_totals ORDER BY customer_id;: phải thấy khách 1 là 100000, khách 2 là 50000.

Đây là cách rất hữu ích khi AI gợi ý một truy vấn dài. Hãy hỏi nó mỗi CTE có một dòng đại diện cho điều gì, rồi tự chạy kiểm tra. Một câu SQL trông gọn không đảm bảo phép tính đúng.

CTE không tự làm truy vấn nhanh hơn

Engine có thể nhập CTE vào kế hoạch lớn hoặc tính kết quả trung gian, tùy hệ quản trị, phiên bản và cách truy vấn dùng nó. Vì vậy không nên coi WITH là “bảng tạm miễn phí” hay một cách tối ưu mặc định. Khi hiệu năng quan trọng, đọc kế hoạch truy vấn.

Nếu kết quả cần dùng cho nhiều lần truy vấn, cân nhắc view hoặc bảng đã tính sẵn. View thường lưu định nghĩa; bảng lưu dữ liệu và cần cách cập nhật. Chúng giải quyết một nhu cầu khác với việc chia một câu SQL cho dễ đọc.

Còn recursive CTE?

CTE đệ quy có một phần khởi đầu và một phần tạo thêm dòng từ kết quả trước. Nó hữu ích cho cây danh mục hoặc đường đi. Nhưng cần điều kiện dừng và xử lý chu trình, nếu không có thể tạo rất nhiều dòng. Bài này tập trung CTE thông thường; đừng thêm đệ quy chỉ vì muốn duyệt vài bảng liên quan.

Bài tập: đổi ngưỡng thành 50000. Kết quả phải có An 100000 và Bình 50000. Sau đó thêm một đơn hủy giá 90000 cho Bình: tổng đã thanh toán của Bình vẫn là 50000.

Tham khảo: SQLite WITH và PostgreSQL WITH queries.

Cơ sở dữ liệu là gì?

Nguồn gốc: Cơ sở dữ liệu là gì?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một file CSV có thể lưu danh sách đơn hàng. Nhưng nếu hai người cùng sửa, một người nhập mã khách không tồn tại, rồi máy tắt giữa lúc ghi file, mình cần xử lý rất nhiều thứ. Hệ quản trị cơ sở dữ liệu giúp quản lý việc đọc, ghi, ràng buộc và phục hồi thay vì để từng ứng dụng tự làm hết.

“Database” là nơi tổ chức dữ liệu; “DBMS” là phần mềm quản lý nó. Trong cách nói hằng ngày hai từ thường được dùng gần nhau. Bài này tập trung database quan hệ, nơi dữ liệu được tổ chức thành bảng có cột và quan hệ giữa các bảng.

Bảng cần nói rõ mỗi dòng là gì

Với dữ liệu café của nhóm SQL, một dòng orders là một đơn; order_id nhận diện đơn đó. Một dòng payments là một lần thử thanh toán, nên một đơn có thể có nhiều dòng payment.

Schema mô tả cấu trúc và quy tắc: tên cột, kiểu dữ liệu, khóa và ràng buộc. Các ví dụ có PRIMARY KEY, NOT NULL, CHECK và khóa ngoại. Khóa ngoại giúp tránh việc một payment tham chiếu tới đơn không tồn tại; nó không tự đảm bảo đơn đã thanh toán đủ tiền.

Thử một dữ liệu sai

Mở database cafe.db bằng SQLite theo bài SQL, bật kiểm tra khóa ngoại cho kết nối hiện tại rồi chạy:

PRAGMA foreign_keys = ON;
INSERT INTO payments VALUES (99,999,'success');

Bạn cần nhận lỗi FOREIGN KEY constraint failed; mã đơn 999 chưa tồn tại. Chạy SELECT COUNT(*) FROM payments;: vẫn có 4 lần thử, vì dòng lỗi không được thêm. Trong SQLite, đừng giả định mọi kết nối đều đã bật kiểm tra khóa ngoại. PostgreSQL thực thi các khóa ngoại đã khai báo mà không dùng PRAGMA này.

Database không tự hiểu nghiệp vụ

CHECK (amount_vnd >= 0) có thể chặn số tiền âm, nhưng không biết 40000 là giá đúng hay bạn quên nhập một chữ số. NOT NULL chặn giá trị thiếu, nhưng không chặn chuỗi rỗng. UNIQUE có thể bảo vệ một khóa, nhưng bạn vẫn phải chọn khóa phù hợp với điều đang nhận diện.

Dữ liệu có thể hợp lệ về schema mà vẫn sai đối với báo cáo. Vì thế cần kiểm tra nghiệp vụ và data quality bên cạnh ràng buộc database.

Khi nào file vẫn đủ dùng?

Một bộ dữ liệu nhỏ, ít thay đổi và không có nhiều người ghi có thể dùng file rất tốt. Khi cần cập nhật đồng thời, truy vấn linh hoạt hoặc nhiều quy tắc nhất quán, database thường hợp lý hơn. Nó cũng mang thêm việc quản lý quyền, backup, dung lượng và vận hành; không phải cứ thêm database là hệ thống tốt hơn.

Đọc tiếp transaction để hiểu cách gom nhiều thay đổi. Tham khảo: PostgreSQL concepts, constraints, SQLite foreign keys.

Data Quality: làm sao biết data đủ tin cậy?

Nguồn gốc: Data Quality: làm sao biết data đủ tin cậy?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Pipeline chạy thành công và dashboard mở được. Nhưng doanh thu hôm nay bằng không vì payment_status vừa đổi từ paid thành PAID. Không có error kỹ thuật; data sai về ý nghĩa.

Data Quality (chất lượng dữ liệu) cho biết data có đủ phù hợp cho một mục đích cụ thể hay không. Thay vì nói “data phải sạch”, team viết điều kiện có thể kiểm tra.

Chất lượng phụ thuộc cách dùng

Địa chỉ thiếu số căn hộ có thể đủ cho report theo khu vực nhưng không đủ để giao hàng. Cùng dataset có thể đạt yêu cầu này và không đạt yêu cầu khác.

Với fact_orders, team tài chính có thể cần:

Đây là Completeness, Uniqueness, Validity và Timeliness. Tên nhóm ít quan trọng hơn việc check bắt đúng rủi ro.

Check từng row

SELECT * FROM fact_orders
WHERE order_id IS NULL
   OR net_amount < 0
   OR status NOT IN ('created', 'paid', 'delivered', 'cancelled');

Nếu query trả row, pipeline có thể dừng batch, cách ly row lỗi hoặc cảnh báo rồi tiếp tục theo chính sách đã thống nhất. Không nên âm thầm xoá row lỗi vì tổng số order sẽ có vẻ hợp lệ dù data bị mất.

Check cả dataset

Mọi row có thể hợp lệ nhưng pipeline chỉ lấy được một nửa data.

Nếu row_count hôm nay < 70% trung vị 7 ngày gần nhất
→ không công bố bảng và gửi cảnh báo

Ngưỡng không phải chân lý. Ngày lễ có thể làm volume đổi mạnh, nên rule cần phản ánh hành vi business.

Đặt check vào đúng chỗ

    flowchart TD
    A["Source<br/>Data vừa đến"]
    B["Kiểm tra schema"]
    C["Transform"]
    D["Kiểm tra business"]
    E["Publish"]
    A --> B --> C --> D --> E
  

Check sớm giúp khoanh vùng lỗi; check output xác nhận thứ người dùng thực sự nhận. Pipeline quan trọng thường cần cả hai.

Alert nên cho biết bảng, partition, rule, giá trị thực tế, ngưỡng và owner. Nếu không ai biết phải làm gì khi check fail, check đó chưa hoàn chỉnh.

Không thể kiểm tra mọi thứ. Hãy bắt đầu từ bảng quan trọng và lỗi từng gây tác động: duplicate key, thiếu partition, data đến muộn, giá trị ngoài domain và metric đổi bất thường. Một số check gắn với quyết định thật có giá trị hơn hàng trăm check không ai xử lý.

Idempotency: chạy lại pipeline mà không tạo duplicate

Nguồn gốc: Idempotency: chạy lại pipeline mà không tạo duplicate. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Pipeline đã ghi xong 900 order thì mất kết nối. Bạn không biết 100 order cuối đã được ghi hay chưa, nên chạy lại cả lô. Nếu job dùng INSERT, bảng có thể xuất hiện duplicate.

Idempotency (khả năng chạy lại mà không tạo thêm kết quả ngoài ý muốn) nghĩa là xử lý cùng input một hay nhiều lần vẫn đưa hệ thống đến cùng trạng thái.

    flowchart TD
 A["Input<br/>ORD-1042"] --> B["Chạy lần 1"] --> C["Một row ORD-1042"]
 A --> D["Chạy lại"] --> E["Vẫn một row ORD-1042"]
  

Dùng business key để nhận diện row

order_id cho biết hai lần nhận được có phải cùng một order hay không.

Thay vì luôn thêm row, pipeline có thể Upsert: thêm khi key chưa tồn tại, cập nhật khi key đã có.

INSERT INTO orders (order_id, status, amount)
VALUES ('ORD-1042', 'paid', 120000)
ON CONFLICT (order_id) DO UPDATE
SET status = EXCLUDED.status,
    amount = EXCLUDED.amount;

Với bảng tổng hợp theo ngày, một cách khác là tính lại toàn bộ partition rồi thay thế nguyên khối. Xoá rồi ghi lại cần transaction hoặc vùng tạm; nếu job dừng sau bước xoá, người dùng sẽ thấy data trống.

Không phải lúc nào key cũng rõ

Một payment retry có thể tạo nhiều transaction hợp lệ cho cùng order. Dùng order_id làm key sẽ ghi đè nhầm. Key phải phản ánh grain: nếu mỗi row là một lần thanh toán, payment_id mới phù hợp.

Idempotency cần được test bằng cách cố tình chạy cùng lô hai lần và so cả số row lẫn metric. Đây là nền tảng để Retry và Backfill an toàn.