Nguồn NotebookLM: Data Engineering thực chiến

Mô hình hóa dữ liệu là gì?

Nguồn gốc: Mô hình hóa 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.

Người quản lý hỏi “món nào bán tốt nhất?”. Nếu bảng chỉ có tổng tiền mỗi đơn, mình không trả lời được số ly từng món. Trước khi chọn tên bảng hay kiểu dữ liệu, cần biết những câu hỏi hệ thống phải trả lời và nguồn có đủ chi tiết không.

Mô hình hóa dữ liệu là cách tổ chức dữ liệu, quan hệ và quy tắc để phục vụ việc sử dụng. Bài này tập trung mô hình cho phân tích, không thay thế thiết kế database của ứng dụng.

Bắt đầu từ grain

Grain nghĩa là mỗi dòng đại diện cho điều gì. Ví dụ giả lập: một đơn 501 có hai dòng hàng:

Mỗi dòng là một dòng sản phẩm trong đơn, khóa (order_id, line_no). Tổng đơn là 75000 đồng, số ly là 3, số đơn là 1. COUNT(*) trả 2 dòng hàng, không phải 2 đơn.

Nếu thêm order_total_vnd = 75000 vào cả hai dòng rồi cộng, báo cáo thành 150000. Một cột có thể đúng trên từng dòng nhưng không phù hợp để cộng ở grain này.

Từ câu hỏi đến cấu trúc

Mình thường ghi bốn điều trước: hoạt động nào cần theo dõi, mỗi dòng là gì, dùng thuộc tính nào để phân nhóm, và đo lường nào cần tính. Với bán hàng, thuộc tính có thể là món, cửa hàng, ngày; đo lường là số lượng và tiền sau giảm giá.

Cần viết thêm quy tắc: có tính đơn hủy không, hoàn tiền vào ngày nào, giảm giá cấp đơn chia xuống dòng hàng thế nào? Schema không tự trả lời những câu hỏi này. Thống nhất với người dùng báo cáo trước khi code giúp tránh “truy vấn đúng nhưng định nghĩa sai”.

Chi tiết và bảng tổng hợp

Dữ liệu theo dòng hàng trả lời được nhiều câu hỏi hơn tổng mỗi ngày, nhưng lớn hơn và cần kiểm soát quyền. Bảng tổng hợp giúp đọc nhanh, song không thể khôi phục chi tiết đã bỏ mất. Có thể giữ cả hai khi cần, với một quy trình đối chiếu để tổng không lệch.

Một bài tập nhỏ: nếu bảng chỉ còn một dòng ngày 01/09 với doanh thu 75000, bạn có tính được số ly Latte không? Không, vì thông tin sản phẩm đã mất.

Đọc tiếp fact và dimension. Tham khảo: Kimball: four-step design process.

Bảng Fact và Dimension

Nguồn gốc: Bảng Fact và Dimension. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Trong báo cáo bán hàng, “75000 đồng” là số đo. “Bán món gì, tại cửa hàng nào, ngày nào” là bối cảnh để hiểu số đo đó. Mô hình chiều thường tách hai phần này thành fact và dimension.

Fact table ghi sự kiện hoặc trạng thái ở một grain đã xác định. Dimension chứa thuộc tính dùng để lọc, nhóm và diễn giải. Đây không đơn giản là “fact toàn số, dimension toàn chữ”: dimension vẫn có khóa số, fact có thể có mã đơn và đôi khi không có đo lường số.

Một bộ dữ liệu nhỏ

Fact có một dòng mỗi dòng hàng. Dimension sản phẩm có khóa 10 là Cà phê đen, nhóm Cà phê; khóa 20 là Latte, nhóm Cà phê sữa. Nối fact với dimension theo khóa duy nhất giúp báo cáo cộng tiền theo nhóm món mà không lặp dòng.

Tổng tiền là 75000, tổng số ly 3. Giá một ly không phải đo lường có thể cộng như tiền dòng hàng: 20000 + 35000 không phải “giá tổng” có ý nghĩa. Giá trung bình theo số ly trong ca này là 75000 / 3 = 25000 đồng, không phải trung bình đơn giản hai mức giá.

Đo lường có thể cộng theo chiều nào?

Tiền dòng hàng thường cộng được theo ngày, món và cửa hàng nếu quy tắc tiền tệ giống nhau. Tồn kho cuối ngày có thể cộng giữa các cửa hàng, nhưng cộng nhiều ngày sẽ đếm lại cùng hàng tồn. Tỷ lệ chuyển đổi cần cộng tử số và mẫu số rồi tính lại, không cộng các tỷ lệ.

Fact còn có thể lưu snapshot mỗi kỳ hoặc theo dõi các mốc của một quy trình. Hãy chọn theo câu hỏi; đừng dồn giao dịch và tồn kho ngày vào một bảng rồi để người dùng tự đoán grain.

Khóa và dòng chưa biết

Khóa nguồn nhận diện sản phẩm; khóa thay thế trong warehouse có thể nhận diện một phiên bản thuộc tính. Khi sản phẩm chưa tới dimension nhưng fact đã tới, cần quy tắc dòng “chưa biết” hoặc chờ xử lý. Đừng âm thầm bỏ fact khỏi báo cáo bằng INNER JOIN.

Bài tập: sản phẩm 10 xuất hiện hai lần trong dimension với cùng khóa. JOIN sẽ tạo bao nhiêu dòng cho fact đầu? Hai. Vì thế kiểm tra tính duy nhất của khóa dimension là kiểm tra trực tiếp độ đúng của báo cáo.

Đọc tiếp star schema và SCD. Tham khảo: Kimball fact tables.

Mô hình ngôi sao

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

Báo cáo cần doanh thu theo món, cửa hàng và ngày. Một cấu trúc dễ đọc là đặt fact bán hàng ở giữa, nối trực tiếp tới các dimension sản phẩm, cửa hàng và ngày. Nhìn sơ đồ giống ngôi sao, nên gọi là star schema.

Bài này dùng dữ liệu giả lập riêng, không cần café fixture. Bạn có thể chạy truy vấn dưới đây trong SQLite 3.25 trở lên; CTE tạo toàn bộ dữ liệu ngay trong câu lệnh.

Thử một nhánh của ngôi sao

WITH dim_product(product_key, product_name, category) AS (
  VALUES (10,'Cà phê đen','Cà phê'),(20,'Latte','Cà phê sữa')
), fact_sales(line_key, product_key, net_amount_vnd) AS (
  VALUES (1,10,40000),(2,20,35000)
)
SELECT d.category, SUM(f.net_amount_vnd) AS revenue_vnd
FROM fact_sales AS f
JOIN dim_product AS d ON f.product_key = d.product_key
GROUP BY d.category
ORDER BY d.category;

Kết quả: Cà phê, 40000 và Cà phê sữa, 35000. Mỗi dòng fact là một dòng hàng; mỗi khóa dimension chỉ khớp một dòng. Trong mô hình đầy đủ, fact còn có store_key, date_key để nối tới các dimension tương ứng.

Vì sao để thuộc tính ở dimension?

Tên và nhóm món được quản lý ở một nơi, truy vấn dùng tên dễ hiểu, và các báo cáo có thể dùng chung cách phân loại. Nếu nhiều fact cùng dùng dimension ngày hoặc sản phẩm, phải thống nhất ý nghĩa và khóa; giống tên cột chưa đủ để coi chúng dùng chung được.

Dimension thường để các thuộc tính phân cấp như cửa hàng, thành phố, vùng trong cùng bảng. Điều này giảm số JOIN và dễ sử dụng, nhưng lặp lại một số giá trị. Star schema ưu tiên thuận tiện cho phân tích; không phải mục tiêu loại bỏ mọi sự lặp như trong một số thiết kế OLTP.

Những chỗ dễ sai

Thêm mã đơn vào fact dòng hàng không làm grain thành một đơn. Nối fact bán hàng trực tiếp với fact thanh toán có thể tạo quan hệ nhiều–nhiều. Nên tổng hợp về cùng mức hoặc phân tích riêng trước khi kết hợp.

Khi thuộc tính sản phẩm thay đổi, star schema vẫn cần chính sách lịch sử. SCD giải thích vì sao cùng mã sản phẩm có thể có nhiều khóa phiên bản.

Star schema hữu ích khi người dùng thường lọc, nhóm và tổng hợp theo các chiều rõ ràng. Nó không thay thế mọi mô hình lưu trữ nguồn hay thiết kế sự kiện.

Tham khảo: Kimball star schema. So sánh với snowflake schema.

Dimension thay đổi chậm (SCD)

Nguồn gốc: Dimension thay đổi chậm (SCD). Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Cửa hàng S1 chuyển từ vùng Bắc sang vùng Trung từ ngày 01/09. Báo cáo doanh thu tháng 8 nên thuộc vùng nào? Nếu câu trả lời là “vùng lúc bán”, mình phải giữ phiên bản cũ thay vì ghi đè mọi thứ.

Slowly Changing Dimension — SCD — là nhóm cách xử lý thuộc tính dimension thay đổi. “Slowly” không đảm bảo dữ liệu thay đổi ít; quyết định chính là cần nhìn lịch sử theo cách nào.

Type 1 và Type 2

Type 1 ghi đè giá trị. Nó phù hợp khi sửa lỗi tên hoặc người dùng muốn mọi báo cáo nhìn theo phân loại hiện tại. Type 2 thêm một dòng phiên bản với khóa thay thế mới, phù hợp khi muốn giữ thuộc tính có hiệu lực lúc sự kiện xảy ra.

Ví dụ Type 2, thời điểm theo giờ Việt Nam và khoảng hiệu lực [từ, đến):

store_id nhận diện cửa hàng trong nguồn; store_key nhận diện phiên bản trong warehouse. Bản ghi bán ngày 31/08 dùng khóa 11; bán ngày 01/09 dùng khóa 12.

Thử nối theo thời gian

Truy vấn độc lập dưới đây chạy trong SQLite 3.25 trở lên. Ngày dùng định dạng ISO thống nhất, không trộn múi giờ:

WITH dim_store(store_key, store_id, region, valid_from, valid_to) AS (
  VALUES (11,'S1','Bắc','2026-01-01','2026-09-01'),
         (12,'S1','Trung','2026-09-01',NULL)
), sales(sale_id, store_id, business_date, amount_vnd) AS (
  VALUES (1,'S1','2026-08-31',40000),
         (2,'S1','2026-09-01',35000)
)
SELECT s.sale_id, d.store_key, d.region
FROM sales AS s
JOIN dim_store AS d ON s.store_id = d.store_id
  AND s.business_date >= d.valid_from
  AND (d.valid_to IS NULL OR s.business_date < d.valid_to)
ORDER BY s.sale_id;

Kết quả: 1, 11, Bắc và 2, 12, Trung. Dùng < valid_to giúp sự kiện đúng ranh giới ngày 01/09 chỉ khớp phiên bản mới. Khi nạp fact thật, thường xác định khóa phiên bản rồi lưu khóa đó vào fact.

Các ca phải kiểm tra

Hai khoảng hiệu lực chồng nhau sẽ làm một sự kiện khớp hai phiên bản. Khoảng bị hở có thể làm sự kiện không khớp dòng nào. Dữ liệu đến muộn cần tìm theo thời gian sự kiện, không mặc định lấy phiên bản đang hiện hành.

Nếu nhận một sửa đổi lịch sử, phải quyết định cập nhật lại phiên bản và fact nào. Nạp lại cùng thay đổi không được tạo thêm phiên bản trùng. Type 2 cũng không tự giữ “ngày hệ thống biết thông tin”: nếu cần cả lịch sử hiệu lực nghiệp vụ lẫn lịch sử nhận biết, mô hình cần bổ sung một trục thời gian nữa.

Đừng chọn một loại SCD cho toàn bộ dimension theo thói quen. Tên sửa lỗi có thể Type 1, vùng kinh doanh có thể Type 2, tùy câu hỏi báo cáo.

Tham khảo: Kimball: Type 1 và SCD Type 2.

Vì sao cần Data Warehouse?

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

Ứng dụng đã lưu đơn hàng trong MySQL. Nếu data đã nằm trong database, tại sao công ty còn cần thêm một nơi khác?

MySQL đang nhận đơn và cập nhật trạng thái giao hàng. Một query quét vài năm lịch sử để tính doanh thu có thể tranh tài nguyên với application.

Data Warehouse (kho dữ liệu) là hệ thống lưu trữ được thiết kế chủ yếu cho phân tích. Nó gom data từ nhiều Source System, giữ lịch sử và tổ chức data để những câu query lớn dễ viết và chạy hiệu quả hơn.

    flowchart TD
    A["MySQL<br/>Đơn hàng"]
    B["Thanh toán<br/>Giao dịch"]
    C["Giao hàng<br/>Thời gian giao"]
    D["Data Warehouse<br/>Data đã được tổ chức"]
    E["Dashboard<br/>Doanh thu và vận hành"]
    A --> D
    B --> D
    C --> D
    D --> E
  

Hai workload khác nhau

Database của application xử lý nhiều thao tác nhỏ và liên tục. Data Warehouse thường đọc rất nhiều row để tổng hợp:

SELECT restaurant_id, SUM(net_amount) AS revenue
FROM fact_orders
WHERE order_date >= DATE '2026-08-01'
  AND order_date < DATE '2026-09-01'
GROUP BY restaurant_id;

Một Data Warehouse vẫn là một dạng database. Điểm khác nằm ở workload mà nó phục vụ.

Tổ chức lại data

Ở nguồn, một order nằm trong orders, payments, deliveries và restaurants. Warehouse có thể tạo fact_orders với một row cho mỗi order:

Thông tin nhà hàng nằm trong dim_restaurants:

Nhiều report có thể dùng chung định nghĩa doanh thu thay vì tự nối các bảng nguồn theo nhiều cách.

Warehouse không tự làm data đúng

Pipeline vẫn có thể bỏ sót order, nhân đôi thanh toán hoặc ghép sai nhà hàng. Warehouse cung cấp nơi phù hợp để lưu và query; Data Engineer vẫn cần Transformation và Data Quality.

Nó cũng có thể trở thành nơi chứa nhiều bảng gần giống nhau mà không ai biết bảng nào còn được cập nhật. Metadata, Data Lineage và Data Catalog giúp giải quyết vấn đề này.

Khi nào cần?

Một cửa hàng nhỏ có thể query từ bản sao PostgreSQL. Data Warehouse có giá trị khi query phân tích ảnh hưởng application, cần kết hợp nhiều nguồn, giữ lịch sử dài hoặc nhiều team cần dùng chung bảng và định nghĩa.

Source System lưu data để hoạt động kinh doanh diễn ra. Data Warehouse tổ chức bản sao của data đó để phân tích an toàn hơn.

Theo dõi thay đổi trong Database với CDC

Nguồn gốc: Theo dõi thay đổi trong Database với CDC. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Bảng orders có hàng trăm triệu row. Query lại toàn bảng mỗi năm phút vừa chậm vừa tạo tải lớn, nhưng pipeline vẫn cần biết order nào vừa đổi trạng thái.

Change Data Capture (thu thập thay đổi dữ liệu), thường viết là CDC, lấy các thao tác Insert, Update và Delete rồi chuyển chúng đến hệ thống khác.

    flowchart TD
 A["Application ghi MySQL"] --> B["Transaction log"]
 B --> C["CDC connector"]
 C --> D["Change events"]
 D --> E["Warehouse hoặc stream processor"]
  

Một update có thể được biểu diễn:

{
  "operation": "update",
  "key": {"order_id": "ORD-1042"},
  "before": {"status": "paid"},
  "after": {"status": "delivered"}
}

Vì sao transaction log hữu ích?

Database đã ghi log để duy trì transaction và phục hồi. Đọc log cho phép bắt cả Delete và nhiều update liên tiếp mà query updated_at có thể bỏ qua. Nó cũng tránh chạy query quét lớn thường xuyên.

Snapshot rồi mới theo thay đổi

CDC thường bắt đầu bằng snapshot hiện trạng, sau đó tiếp tục từ một vị trí trong log. Nếu vị trí giữa hai bước sai, pipeline có thể tạo khoảng trống hoặc duplicate. Consumer phải lưu offset và xử lý event lặp lại an toàn.

Schema thay đổi, log retention quá ngắn, transaction lớn và quyền truy cập là các vấn đề vận hành thật. CDC cũng không tự tạo bảng phân tích: nó sao chép thay đổi gần với Source System; downstream vẫn cần Transformation và Data Quality.

Với bảng nhỏ cập nhật theo giờ, query incremental đơn giản có thể tốt hơn. CDC có giá trị khi cần update/delete nhanh, volume thay đổi lớn hoặc muốn giảm query lên database nguồn.

Sửa lại data trong quá khứ với Backfill

Nguồn gốc: Sửa lại data trong quá khứ với Backfill. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Pipeline bỏ sót thanh toán từ ngày 1 đến ngày 3 vì một filter sai. Sau khi sửa code, data hôm nay đúng nhưng ba ngày lịch sử vẫn thiếu.

Backfill (xử lý bù data lịch sử) là chạy logic cho một khoảng quá khứ để tạo phần output bị thiếu hoặc cập nhật kết quả theo logic mới.

    flowchart TD
 A["Xác định khoảng lỗi<br/>01-09 → 03-09"]
 B["Sửa và kiểm tra logic"]
 C["Chạy thử một partition"]
 D["Backfill từng ngày"]
 E["Đối chiếu và công bố"]
 A --> B --> C --> D --> E
  

Job phải nhận khoảng data rõ ràng

transform_orders --start-date 2026-09-01 --end-date 2026-09-04

Không nên dùng “hôm qua” nằm cứng trong code. Một lần chạy ngày 9 vẫn phải tạo đúng partition ngày 1 khi được yêu cầu.

Backfill có thể gây ảnh hưởng production

Đọc ba năm data cùng lúc có thể chiếm hết compute, làm chậm job hằng ngày và gửi nhiều update đến downstream. Hãy chia theo partition, giới hạn số job song song và ưu tiên pipeline hiện tại.

Trước khi chạy cần biết:

• Input lịch sử còn đủ không?
• Code mới có tương thích schema cũ không?
• Output được thay an toàn hay sẽ duplicate?
• Dashboard và notification có phản ứng với update cũ không?
• Có cách so sánh trước và sau không?

Backfill kết thúc khi data đã được kiểm tra, không chỉ khi job hiện màu xanh. Hãy đối chiếu row count, tổng tiền, khoảng thời gian và một mẫu order với Source System.

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.