Sau rất nhiều cốc cà phê và không ít đêm ngồi debug PySpark đến khuya, mình vừa hoàn thành dự án data engineering lớn nhất từ trước đến nay: một data pipeline end-to-end xử lý 190 triệu chuyến taxi tại New York, xây dựng hoàn toàn trên Microsoft Fabric. Đây không phải một bài tập nhỏ để "làm cho có" trong portfolio — mà là một dự án được thiết kế theo đúng chuẩn kiến trúc dữ liệu doanh nghiệp: từ ingest dữ liệu thô, làm sạch, mô hình hóa, huấn luyện Machine Learning, cho tới dashboard báo cáo.
Trong bài viết này, mình sẽ đi qua toàn bộ hành trình: vì sao chọn kiến trúc này, dữ liệu được xử lý qua từng lớp ra sao, mô hình Machine Learning cho ra kết quả thế nào, và những insight thú vị rút ra từ 190 triệu bản ghi taxi thật.
THÔNG TIN HỌC VIÊN
Phạm Quốc Nghiệp
Data Engineer- Khóa học: Data Engineering & Big Data Architecture
- Thời gian thực hiện: 25 ngày
- Dự án: nyc-taxi-fabric-pipeline
- Tập dữ liệu: 189.5M+ Taxi Trip Records (NYC TLC)
- Nền tảng đào tạo: Học viên khóa Data Engineer tại Cole.vn
FEEDBACK CỦA HỌC VIÊN
“Khóa học đã trang bị cho mình tư duy chuẩn doanh nghiệp khi xây dựng kiến trúc Medallion, xử lý Schema Evolution và tối ưu hiệu năng PySpark trên quy mô hàng trăm triệu dòng dữ liệu thực tế.”
Thiết kế thành công Star Schema tối ưu và tích hợp quy trình End-to-End từ OneLake, MLflow đến Semantic Model Power BI.
1. Bài toán & nguồn dữ liệu
Bộ dữ liệu NYC TLC (Taxi & Limousine Commission) là một trong những bộ dữ liệu công khai lớn và "thực chiến" nhất để luyện kỹ năng data engineering, vì nó có đầy đủ các đặc tính của dữ liệu doanh nghiệp thật: khối lượng lớn, schema thay đổi qua từng năm, nhiều giá trị bất thường (outlier), và cần kết hợp với các nguồn dữ liệu phụ trợ (thời tiết, ngày lễ, khu vực địa lý) để phân tích có chiều sâu.
Dự án sử dụng 4 nguồn dữ liệu chính, trải dài từ tháng 1/2021 đến tháng 11/2025:
| Nguồn dữ liệu | Mô tả | Số bản ghi | Định dạng |
|---|---|---|---|
| NYC TLC | Dữ liệu chuyến đi Yellow Taxi (2021–2025) | 189M+ | Parquet |
| Taxi Zones | Danh sách khu vực địa lý NYC | 265 | CSV |
| Weather | Dữ liệu thời tiết theo ngày tại NYC | 1.826 | CSV |
| US Holidays | Lịch nghỉ lễ liên bang Mỹ | 75 | CSV |
Việc kết hợp 4 nguồn dữ liệu này cho phép trả lời những câu hỏi phân tích thực tế mà một bảng dữ liệu chuyến đi đơn thuần không thể trả lời được — ví dụ: thời tiết xấu có làm giảm nhu cầu đi taxi không? Ngày lễ có ảnh hưởng đến doanh thu ra sao?
2. Kiến trúc Medallion trên Microsoft Fabric
Thay vì xử lý dữ liệu thô trực tiếp thành báo cáo (cách làm dễ gây lỗi và khó bảo trì), dự án áp dụng Medallion Architecture — mô hình phân lớp dữ liệu phổ biến trong các hệ thống Lakehouse hiện đại, gồm 3 tầng: Bronze → Silver → Gold. Toàn bộ dữ liệu được lưu trữ tập trung trên OneLake (nền tảng lưu trữ hợp nhất của Microsoft Fabric), dưới định dạng Delta Lake để tận dụng khả năng giao dịch ACID và time travel.
| Lớp (Layer) | Mục đích | Định dạng lưu trữ | Bảng dữ liệu |
|---|---|---|---|
| Bronze | Ingest dữ liệu thô, kiểm tra schema | Parquet/CSV | Raw taxi trips, zones, weather, holidays |
| Silver | Làm sạch, chuẩn hóa, làm giàu dữ liệu | Delta Lake | Cleaned trips, enriched zones, calendar |
| Gold | Dữ liệu sẵn sàng cho phân tích, star schema | Delta Lake | 1 bảng fact + 7 bảng dimension |
Vì sao chọn kiến trúc 3 lớp thay vì ETL truyền thống? Vì mỗi lớp đóng vai trò như một "lưới lọc chất lượng". Nếu dữ liệu Gold có vấn đề, ta chỉ cần kiểm tra lại logic xử lý ở Silver mà không cần chạm vào dữ liệu thô gốc ở Bronze. Đây cũng chính là lý do các đội ngũ data engineering doanh nghiệp gần như mặc định chọn mô hình này khi làm việc với Databricks hay Microsoft Fabric.
3. Đi sâu vào từng layer xử lý dữ liệu
Toàn bộ pipeline được triển khai qua 6 notebook PySpark, chạy tuần tự trên Fabric Lakehouse, đánh số từ 00 đến 05.
3.1. Bronze Layer — Ingest & kiểm tra schema
Ở bước này, dữ liệu thô từ NYC TLC và các nguồn phụ trợ được nạp trực tiếp vào Lakehouse mà không qua bất kỳ biến đổi nào, giữ nguyên trạng để đảm bảo có thể truy vết lại nguồn gốc dữ liệu (data lineage) bất cứ lúc nào.
# Minh họa logic ingest dữ liệu Bronze layer trên Fabric Lakehouse
df_raw = (
spark.read
.format("parquet")
.load("Files/raw/yellow_tripdata/*.parquet")
)
# Ghi vào Bronze layer dưới dạng Delta, giữ nguyên schema gốc
df_raw.write.format("delta").mode("append").saveAsTable("bronze_taxi_trips")
print(f"Tổng số dòng nạp vào Bronze layer: {df_raw.count():,}")
3.2. Silver Layer — Làm sạch & chuẩn hóa
Đây là lớp "khó nhằn" nhất trong toàn bộ pipeline. Dữ liệu NYC TLC trải dài 5 năm (2021–2025) có schema không đồng nhất — một số cột đổi tên, đổi kiểu dữ liệu, hoặc bị thêm/bớt qua từng năm. Ở lớp này, dữ liệu được chuẩn hóa kiểu dữ liệu, loại bỏ bản ghi trùng lặp, xử lý giá trị âm bất hợp lý (ví dụ quãng đường di chuyển âm), và được làm giàu (enrich) thêm thông tin thời tiết, ngày lễ theo từng ngày.
# Minh họa logic làm sạch & enrich dữ liệu ở Silver layer
from pyspark.sql.functions import col
df_silver = (
df_raw
.filter(col("trip_distance") > 0)
.filter(col("fare_amount") >= 0)
.dropDuplicates(["VendorID", "tpep_pickup_datetime", "tpep_dropoff_datetime"])
.join(df_weather, on="trip_date", how="left")
.join(df_holidays, on="trip_date", how="left")
)
df_silver.write.format("delta").mode("overwrite").saveAsTable("silver_taxi_trips_enriched")
3.3. Gold Layer — Thiết kế Star Schema
Ở lớp cuối cùng, dữ liệu Silver được mô hình hóa lại theo Star Schema — mô hình dữ liệu kinh điển trong Business Intelligence, gồm một bảng sự kiện trung tâm (fact table) chứa các số đo, được bao quanh bởi các bảng mô tả (dimension table). Cách thiết kế này giúp Power BI truy vấn nhanh hơn rất nhiều so với việc query trực tiếp trên bảng phẳng chưa chuẩn hóa.
| Bảng | Loại | Số dòng | Cột khóa chính |
|---|---|---|---|
gold_fact_trips |
Fact | 189M | fare_amount, trip_distance, tip_amount, surcharges |
gold_dim_date |
Dimension | 1.826 | date_sk, year, month, day_name, is_holiday |
gold_dim_time |
Dimension | 1.440 | time_sk, hour_24, am_pm, is_rush_hour |
gold_dim_location |
Dimension | 265 | location_sk, zone_name, borough, is_airport |
gold_dim_weather |
Dimension | 1.826 | weather_sk, temp_avg, precipitation, weather_condition |
gold_dim_vendor |
Dimension | 3 | vendor_sk, vendor_name, vendor_code |
gold_dim_payment_type |
Dimension | 7 | payment_type_sk, payment_type_name, allows_tip |
gold_dim_rate_code |
Dimension | 7 | rate_code_sk, rate_code_name, rate_multiplier |
Nói dễ hiểu: nếu gold_fact_trips là "chuyện gì đã xảy ra" (bao nhiêu tiền, đi bao xa, tip bao nhiêu), thì 7 bảng dimension chính là "ai, ở đâu, khi nào, thời tiết ra sao" — giúp Power BI có thể lọc, nhóm, và tính toán theo bất kỳ chiều phân tích nào chỉ trong vài giây, dù bảng fact có tới 189 triệu dòng.
4. Huấn luyện Machine Learning với MLflow
Sau khi có dữ liệu Gold sạch và có cấu trúc tốt, dự án huấn luyện 3 mô hình Machine Learning bằng PySpark MLlib, toàn bộ quá trình thử nghiệm được theo dõi bằng MLflow — công cụ quản lý vòng đời mô hình rất phổ biến trong giới Data Science.
| Mô hình | Thuật toán | Chỉ số | Kết quả |
|---|---|---|---|
| Dự đoán giá cước (Fare Prediction) | GBT Regressor | RMSE | $5.45 |
| MAE | $3.00 | ||
| R² | 0.886 | ||
| Phân loại khả năng có tip (Tip Classification) | Random Forest | AUC | 0.619 |
| Accuracy | 77.5% | ||
| F1 Score | 0.687 | ||
| Dự báo nhu cầu (Demand Forecasting) | GBT Regressor | RMSE | 36.42 |
| MAE | 24.78 | ||
| R² | 0.919 |
Một điểm đáng chú ý và cũng cần nói thẳng: mô hình Tip Classification có chỉ số AUC chỉ đạt 0.619 — mức trung bình, chưa thực sự mạnh. Điều này phản ánh đúng thực tế của bài toán: hành vi cho tip của hành khách phụ thuộc nhiều vào yếu tố cá nhân (tính cách, trải nghiệm chuyến đi) mà dữ liệu giao dịch không thể nắm bắt hết. Việc công khai cả những con số chưa hoàn hảo này, thay vì chỉ khoe kết quả đẹp, mới phản ánh đúng tinh thần làm việc với dữ liệu thật.
Tên Experiment: NYC_Taxi_ML_Models · Tự động đánh version model · Lưu artifact tại Files/ml_models/{model_name}/{version}/ · Model Registry: bảng gold_ml_model_registry
5. Trực quan hóa: 6 Dashboard Power BI
Dữ liệu Gold layer được kết nối trực tiếp vào Power BI qua Semantic Model của Fabric, phục vụ 6 dashboard tương tác:
- Executive Dashboard — tổng quan KPI: 189.52M chuyến, $4.9B doanh thu, giá cước trung bình $17.86, tỷ lệ tip trung bình 20.35%.
- Geographic Analysis — top 10 khu vực đón khách, các tuyến đường phổ biến nhất, so sánh sân bay và ngoài sân bay, phân bổ theo quận (borough).
- Time Analysis — mô hình nhu cầu theo giờ, phân bổ theo ngày trong tuần, xu hướng theo tháng/năm, heatmap giờ × ngày.
- Weather Impact Analysis — số chuyến theo điều kiện thời tiết, tương quan nhiệt độ và số chuyến, ước tính thiệt hại do thời tiết xấu.
- Financial Performance — doanh thu lũy kế so với cùng kỳ năm trước, xu hướng doanh thu kèm dự báo, doanh thu theo phương thức thanh toán.
- ML Model Performance — tổng hợp chỉ số mô hình, biểu đồ giá trị thực tế so với dự đoán, lịch sử phiên bản model.
6. Insight kinh doanh rút ra từ dữ liệu
Đây có lẽ là phần thú vị nhất — khi 190 triệu dòng dữ liệu "biết nói":
- Manhattan áp đảo: 88,39% tổng số chuyến đi xuất phát từ Manhattan.
- Giờ cao điểm: khung giờ 17h–19h (giờ tan tầm) có nhu cầu cao nhất trong ngày.
- Ảnh hưởng thời tiết: những ngày mưa làm giảm khoảng 0,7% số lượng chuyến đi.
- Sự dịch chuyển phương thức thanh toán: thẻ tín dụng chiếm 76,9%, trong khi tiền mặt chỉ còn 13,1%.
- Lưu lượng sân bay: 7,4% tổng số chuyến đi liên quan đến sân bay.
7. Thách thức kỹ thuật khi xử lý 190 triệu dòng
Làm việc với một tập dữ liệu ở quy mô hàng trăm triệu dòng, trải dài 5 năm, luôn đi kèm những thách thức mà các bộ dữ liệu mẫu nhỏ không bao giờ bộc lộ:
7.1. Schema thay đổi qua từng năm
NYC TLC không giữ nguyên cấu trúc dữ liệu suốt 5 năm — một số cột được thêm mới (như phí tắc nghẽn giao thông congestion_surcharge), một số bị đổi kiểu dữ liệu. Đây là lý do lớp Silver phải xử lý logic schema evolution thay vì giả định mọi file parquet đều có cấu trúc giống hệt nhau.
7.2. Tối ưu hiệu năng xử lý Spark
Với 189 triệu dòng dữ liệu, việc join trực tiếp bảng fact với các bảng dimension nếu không tối ưu (partition, broadcast join hợp lý) có thể khiến tác vụ Spark chạy rất chậm hoặc tràn bộ nhớ. Việc thiết kế Star Schema với các bảng dimension nhỏ, gọn (chỉ vài trăm đến vài nghìn dòng) chính là một cách gián tiếp giải quyết bài toán hiệu năng này khi lên Power BI.
8. Công nghệ sử dụng
| Nhóm | Công nghệ |
|---|---|
| Nền tảng | Microsoft Fabric, OneLake |
| Xử lý dữ liệu | Apache Spark, PySpark |
| Lưu trữ | Delta Lake, Parquet |
| ML/AI | PySpark MLlib, MLflow |
| Trực quan hóa | Power BI |
| Ngôn ngữ | Python, SQL, DAX |
9. Hướng dẫn tự triển khai
Nếu bạn muốn tự tay chạy lại dự án này để học hỏi, đây là các bước cơ bản:
- Clone repository:
git clone https://github.com/pqnghiep1354/nyc-taxi-fabric-pipeline.git cd nyc-taxi-fabric-pipeline - Tạo Fabric Lakehouse trong workspace Microsoft Fabric của bạn, đặt tên
TaxiAnalytics_Lakehouse. - Import toàn bộ notebook (
.ipynb) từ thư mụcnotebooks/và gắn (attach) vào Lakehouse vừa tạo. - Chạy pipeline theo đúng thứ tự:
00 → 01 → 02 → 03 → 04 → 05. - Tạo báo cáo Power BI theo hướng dẫn trong notebook
05_Power_BI_Integration.ipynb, xây Semantic Model từ các bảng Gold và áp dụng thư viện DAX có sẵn.
Workspace Microsoft Fabric có Lakehouse capacity · Power BI Pro license (để publish report) · Git đã cài đặt trên máy
10. Câu hỏi thường gặp (FAQ)
Medallion Architecture (Bronze – Silver – Gold) là gì?
Đây là mô hình phân lớp dữ liệu trong kiến trúc Lakehouse, gồm 3 tầng: Bronze lưu dữ liệu thô chưa xử lý, Silver lưu dữ liệu đã làm sạch và chuẩn hóa, Gold lưu dữ liệu đã sẵn sàng cho phân tích và báo cáo.
Vì sao dự án chọn Microsoft Fabric thay vì Databricks hay Synapse?
Microsoft Fabric hợp nhất nhiều thành phần (Lakehouse, Data Factory, Power BI, MLflow) trong cùng một nền tảng với lớp lưu trữ chung là OneLake, giúp giảm chi phí tích hợp và quản trị hạ tầng so với việc kết hợp riêng lẻ nhiều dịch vụ.
Star Schema khác gì với một bảng dữ liệu phẳng thông thường?
Star Schema tách dữ liệu thành một bảng fact (số đo) và nhiều bảng dimension (mô tả), giúp giảm dung lượng, tăng tốc độ truy vấn và dễ mở rộng chiều phân tích hơn so với việc gộp toàn bộ thông tin vào một bảng phẳng duy nhất.
Dự án này có phù hợp với người mới bắt đầu học Data Engineer không?
Dự án ở mức trung bình-khá, phù hợp với người đã nắm cơ bản về SQL và Python, muốn thực hành với dữ liệu quy mô lớn thật thay vì bộ dữ liệu mẫu nhỏ. Người mới hoàn toàn nên bắt đầu với các bộ dữ liệu nhỏ hơn trước khi tiếp cận quy mô 190 triệu dòng.
Mô hình dự đoán giá cước taxi đạt độ chính xác bao nhiêu?
Mô hình Fare Prediction dùng thuật toán GBT Regressor đạt hệ số R² là 0.886, sai số tuyệt đối trung bình (MAE) khoảng 3 USD trên mỗi chuyến đi.
11. Kết luận
Sau tất cả những cốc cà phê và những đêm ngồi trước màn hình debug lỗi Spark, điều đọng lại lớn nhất không phải là con số 190 triệu dòng dữ liệu, mà là cách một dự án được thiết kế bài bản — từ kiến trúc phân lớp, mô hình hóa dữ liệu, huấn luyện Machine Learning, đến trực quan hóa — có thể biến một khối dữ liệu thô khổng lồ thành những insight kinh doanh cụ thể, có thể hành động được.
Nếu bạn đang tìm một dự án thực chiến để hiểu rõ hơn công việc thật sự của một Data Engineer, hy vọng bài viết này — và toàn bộ mã nguồn trên GitHub — sẽ là một điểm khởi đầu hữu ích.
NHẬN XÉT TỪ GIẢNG VIÊN
Đỗ Đình Tấn
Principal Engineer tại IX JapanGiảng viên tại Cole.vn
“Dự án thể hiện trình độ chuyên môn cao và tư duy thiết kế kiến trúc chuẩn mực. Học viên đã xử lý rất tốt bài toán Big Data 190 triệu dòng, kiểm soát trọn vẹn vòng đời dữ liệu trên Microsoft Fabric từ Data Lakehouse đến Direct Lake trên Power BI.”
ĐÁNH GIÁ ĐỒ ÁN
| Thiết kế Kiến trúc Medallion | ★★★★★ |
| Xử lý Big Data & Tối ưu PySpark | ★★★★★ |
| Thiết kế Star Schema & Gold Layer | ★★★★★ |
| Tích hợp MLflow & Machine Learning | ★★★★☆ |
| Trực quan hóa Power BI Dashboard | ★★★★★ |
ĐỊNH HƯỚNG PHÁT TRIỂN TIẾP THEO
- Bổ sung dữ liệu Green Taxi và For-Hire Vehicle (Uber/Lyft) để so sánh liên phương thức.
- Xây dựng pipeline incremental load tự động theo lịch hàng tháng.
- Cải thiện mô hình Tip Classification bằng cách bổ sung thêm đặc trưng hành vi khách hàng.
- Triển khai CI/CD cho notebook và giám sát chất lượng dữ liệu tự động (Data Quality Monitoring).