Trả lời nhanh: ETL (Extract, Transform, Load) là quy trình trích xuất dữ liệu từ nhiều hệ thống nguồn, chuyển đổi cho sạch và thống nhất, rồi nạp vào nơi lưu trữ đích như kho dữ liệu để phân tích. Ví dụ: gom đơn hàng từ phần mềm bán hàng và sàn thương mại điện tử về một bảng doanh thu chuẩn.
Điểm chính
- Quy trình ETL có 3 bước: Extract lấy dữ liệu từ nguồn, Transform làm sạch và chuẩn hoá, Load ghi vào hệ thống đích.
- ETL và ELT khác nhau ở thứ tự: ETL biến đổi trước khi nạp, ELT nạp dữ liệu thô rồi biến đổi ngay trong kho.
- Không phải lúc nào cũng cần thời gian thực. Báo cáo hằng ngày chạy theo lô (batch) là đủ; CDC và streaming dành cho bài toán cần số liệu tính bằng giây.
- Pipeline tốt phải chạy lại được mà không nhân đôi dữ liệu, có kiểm thử chất lượng và cảnh báo khi lỗi.
- ETL là một hoạt động “xử lý dữ liệu cá nhân” theo Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, nên cần che, giảm thiểu dữ liệu ngay ở bước Transform.
Mục lục
- ETL là gì?
- Quy trình ETL gồm những bước nào?
- Ví dụ quy trình ETL với dữ liệu bán hàng: trước và sau
- ETL và ELT khác nhau thế nào?
- Batch, streaming và CDC: nên nạp dữ liệu theo cách nào?
- ETL nằm ở đâu trong kiến trúc kho dữ liệu và lakehouse?
- Công cụ ETL phổ biến hiện nay gồm những nhóm nào?
- Kiểm soát chất lượng dữ liệu trong ETL như thế nào?
- Những lỗi thường gặp khi làm ETL và cách phòng tránh
- Quy trình xây dựng ETL pipeline từng bước
- Làm ETL với dữ liệu cá nhân cần lưu ý gì tại Việt Nam?
- Câu hỏi thường gặp
ETL là gì?
ETL là gì? Đó là viết tắt của Extract (trích xuất), Transform (chuyển đổi) và Load (nạp). Đây là quy trình tích hợp dữ liệu: lấy dữ liệu từ nhiều nơi, sửa cho đúng và đồng nhất, rồi đưa về một nơi để dùng chung. Theo IBM, ETL xuất hiện từ thập niên 1970 và trở thành cách làm chính của các dự án kho dữ liệu trong thập niên 1990 và 2000.
Hãy hình dung một chuỗi cửa hàng thời trang. Đơn tại quầy nằm trong phần mềm bán hàng (POS). Đơn online nằm trên sàn thương mại điện tử. Thông tin khách nằm trong CRM, công nợ nằm trong phần mềm kế toán. Mỗi hệ thống ghi ngày, tên sản phẩm, số điện thoại theo một kiểu. Muốn biết “doanh thu theo kênh tuần này là bao nhiêu”, ai đó phải gom, sửa và ghép các nguồn này. Nếu làm tay bằng Excel mỗi tuần, đó là ETL thủ công. Khi việc này được viết thành quy trình tự động, chạy theo lịch, có kiểm tra lỗi, ta có một ETL pipeline.
Đích đến phổ biến nhất của ETL là kho dữ liệu (data warehouse), nơi lưu dữ liệu đã sạch và có lịch sử cho báo cáo. Đích cũng có thể là data lake, một cơ sở dữ liệu phục vụ ứng dụng, hoặc tập dữ liệu để huấn luyện mô hình AI.
Quy trình ETL gồm những bước nào?
Quy trình ETL đi theo đúng ba chữ cái trong tên. Mỗi bước có câu hỏi riêng cần trả lời trước khi viết dòng mã đầu tiên.
Bước 1: Extract – trích xuất dữ liệu từ nguồn
Extract là đọc dữ liệu từ hệ thống nguồn: cơ sở dữ liệu của ERP, CRM, POS; tệp Excel, CSV; dịch vụ web qua giao diện lập trình API; nhật ký máy chủ; dữ liệu cảm biến. Dữ liệu thường được chép sang một vùng tạm (staging) để không làm nặng hệ thống đang phục vụ khách.
Theo tài liệu của AWS, có ba cách trích xuất:
- Thông báo cập nhật (update notification): hệ thống nguồn tự báo khi có bản ghi thay đổi. Đây là cách nhẹ nhất nếu nguồn hỗ trợ.
- Trích xuất tăng dần (incremental): chỉ lấy những bản ghi thay đổi trong một khoảng thời gian, thường dựa vào cột “ngày cập nhật”.
- Trích xuất toàn bộ (full): tải lại hết khi nguồn không cho biết dòng nào đã đổi. Đơn giản nhưng tốn tài nguyên khi dữ liệu lớn.
Câu hỏi cần chốt ở bước này: lấy bằng tài khoản nào, quyền gì, vào giờ nào để không ảnh hưởng hệ thống bán hàng, và nguồn có chứa dữ liệu cá nhân không.
Bước 2: Transform – chuyển đổi và làm sạch
Transform là bước “nấu” dữ liệu theo quy tắc nghiệp vụ. Đây là nơi tốn công nhất và cũng tạo ra giá trị nhất. Các thao tác thường gặp:
- Làm sạch: bỏ khoảng trắng thừa, sửa lỗi chính tả mã hàng, xử lý ô trống.
- Chuẩn hoá định dạng: đưa ngày về một kiểu, số điện thoại về một dạng, tiền về cùng đơn vị, chữ tiếng Việt về cùng chuẩn Unicode.
- Loại trùng (deduplication): một đơn bị đồng bộ hai lần chỉ được tính một lần.
- Ghép và tra cứu (join, lookup): gắn mã sản phẩm chuẩn, gắn khu vực cho cửa hàng.
- Tính toán, suy diễn (derivation): doanh thu bằng số lượng nhân đơn giá, tuổi khách từ năm sinh.
- Tổng hợp (aggregation): cộng doanh thu theo ngày, theo kênh.
- Che, mã hoá dữ liệu nhạy cảm: IBM lưu ý thông tin định danh cá nhân có thể được che (masking) ngay khi đang chuyển đổi, trước khi nạp vào đích.
Bước 3: Load – nạp vào hệ thống đích
Load là ghi dữ liệu đã xử lý vào đích. Có hai kiểu chính:
- Nạp toàn bộ (full load): xoá và ghi lại cả bảng. Phù hợp bảng nhỏ như danh mục cửa hàng.
- Nạp tăng dần (incremental load): chỉ thêm dòng mới và cập nhật dòng thay đổi, thường bằng lệnh MERGE hoặc upsert theo khoá nghiệp vụ. Đây là cách dùng cho bảng giao dịch lớn.
Một quyết định quan trọng ở bước Load là có giữ lịch sử thay đổi không. Ví dụ cửa hàng chuyển từ vùng Bắc sang vùng Trung. Nếu ghi đè, toàn bộ doanh thu cũ của cửa hàng cũng “chuyển vùng” theo, báo cáo năm trước bị sai. Kỹ thuật slowly changing dimension loại 2 (SCD type 2) của Ralph Kimball xử lý việc này: mỗi lần thuộc tính đổi, thêm một dòng mới với ngày bắt đầu hiệu lực, ngày hết hiệu lực và cờ đánh dấu dòng hiện hành.
Ví dụ quy trình ETL với dữ liệu bán hàng: trước và sau
Phần lớn bài viết về ETL chỉ nói chung chung “làm sạch dữ liệu”. Ví dụ minh hoạ dưới đây cho thấy cụ thể dữ liệu trông thế nào trước và sau Transform. Đây là dữ liệu giả lập, không lấy từ doanh nghiệp thật.
Dữ liệu thô sau khi Extract (gộp từ phần mềm bán hàng tại quầy và tệp xuất từ sàn thương mại điện tử):
| Mã đơn | Thời gian | Khách hàng | Điện thoại | Sản phẩm | SL | Đơn giá | Nguồn |
|---|---|---|---|---|---|---|---|
| HD-001 | 05/10/2026 | Nguyễn Văn A | 0912 345 678 | ao thun trắng M | 2 | 150.000 | POS Quận 1 |
| HD-001 | 05/10/2026 | Nguyễn Văn A | 0912 345 678 | ao thun trắng M | 2 | 150.000 | POS Quận 1 |
| 7781 | 2026-10-05 21:40 UTC | nguyen van a | +84912345678 | AT-TRANG-M | 1 | 150000 | Sàn TMĐT |
| HD-002 | 06/10/2026 | (trống) | (trống) | Quần jean 30 | -1 | 320.000 | POS Quận 3 |
Nhìn kỹ sẽ thấy 6 vấn đề: đơn HD-001 bị đồng bộ hai lần; ngày ghi hai kiểu; giờ của sàn tính theo UTC; cùng một khách nhưng tên và số điện thoại viết khác nhau; tên sản phẩm không theo mã chuẩn; đơn HD-002 có số lượng âm (có thể là hàng trả lại bị nhập nhầm).
Quy tắc Transform được áp dụng:
- Tạo mã đơn chuẩn bằng cách ghép tiền tố kênh với mã gốc (POS-HD-001, TMDT-7781), rồi loại dòng trùng theo mã này.
- Đổi mọi thời gian về giờ Việt Nam (UTC+7). Đơn 21:40 UTC ngày 05/10 thực chất là 04:40 sáng ngày 06/10 theo giờ Việt Nam.
- Chuẩn hoá số điện thoại về dạng 10 số bắt đầu bằng 0, rồi thay bằng mã khách giả danh (băm có khoá bí mật). Bảng phân tích không cần biết số điện thoại thật.
- Tra bảng ánh xạ để đổi tên sản phẩm về mã chuẩn AT-TRANG-M.
- Bỏ dấu chấm phân cách nghìn, tính doanh thu bằng số lượng nhân đơn giá.
- Dòng có số lượng âm không nạp vào bảng chính mà chuyển sang bảng chờ xử lý, kèm lý do, để bộ phận bán hàng xác minh.
Dữ liệu sau Transform, sẵn sàng Load vào bảng fact bán hàng:
| Mã đơn chuẩn | Ngày (giờ VN) | Mã khách | Mã SP | SL | Doanh thu (đồng) | Kênh |
|---|---|---|---|---|---|---|
| POS-HD-001 | 2026-10-05 | KH-7F3A | AT-TRANG-M | 2 | 300000 | Cửa hàng |
| TMDT-7781 | 2026-10-06 | KH-7F3A | AT-TRANG-M | 1 | 150000 | Online |
Bảng chờ xử lý giữ lại dòng POS-HD-002 với lý do “số lượng âm”. Kết quả: tổng doanh thu đúng là 450.000 đồng. Nếu cộng thẳng dữ liệu thô, bạn được 430.000 đồng, một con số trông “gần đúng” nhưng thực ra là hai lỗi bù trừ nhau: đơn HD-001 bị cộng dư 300.000 đồng, còn dòng số lượng âm trừ đi 320.000 đồng. Ngoài ra, hệ thống nhận ra hai đơn thuộc cùng một khách, và đơn online được ghi đúng ngày 06/10. Chỉ với 4 dòng đã có 3 con số có thể sai. Với hàng triệu dòng, ETL chính là thứ quyết định báo cáo có đáng tin hay không.
ETL và ELT khác nhau thế nào?
ELT (Extract, Load, Transform) đảo hai bước cuối: dữ liệu thô được nạp thẳng vào đích, rồi mới biến đổi bằng sức mạnh tính toán của chính kho. AWS mô tả ELT là một biến thể mở rộng của ETL, không cần vùng staging riêng vì kho dữ liệu hiện đại tự xử lý được việc biến đổi.
| Tiêu chí | ETL | ELT |
|---|---|---|
| Thứ tự | Trích xuất, biến đổi, nạp | Trích xuất, nạp, biến đổi |
| Nơi biến đổi | Máy chủ hoặc công cụ ETL riêng, qua vùng staging | Bên trong kho dữ liệu hoặc lakehouse đích |
| Dữ liệu thô | Thường không vào kho | Được lưu trong kho, tính lại được khi đổi quy tắc |
| Loại dữ liệu | Chủ yếu có cấu trúc, lược đồ định trước | Có cấu trúc, bán cấu trúc và phi cấu trúc |
| Khối lượng | Hợp hơn với tập dữ liệu vừa và nhỏ | Thiết kế cho dữ liệu lớn |
| Chi phí | Đầu tư hạ tầng ban đầu cao hơn | Ban đầu thấp, nhưng chi phí tính toán dễ phình khi mở rộng |
| Dữ liệu nhạy cảm | Che, lọc trước khi vào kho | Bản thô nhạy cảm nằm trong kho, phải phân quyền chặt |
| Kỹ năng chính | Công cụ ETL, lập trình | SQL, mô hình hoá dữ liệu trong kho |
Các dòng về loại dữ liệu, khối lượng và chi phí tổng hợp theo so sánh của IBM. Trên thực tế, nhiều hệ thống dùng cả hai: lọc bỏ trường nhạy cảm ngay khi trích xuất (một chút ETL), nạp phần còn lại vào kho rồi biến đổi bằng SQL (ELT). Vì vậy câu hỏi đúng không phải “ETL hay ELT” mà là “biến đổi nào nên làm trước khi nạp, biến đổi nào để sau”.
Gợi ý chọn nhanh:
- Nghiêng về ETL khi kho đặt tại chỗ với tài nguyên hạn chế, khi luật hoặc chính sách nội bộ không cho dữ liệu nhạy cảm thô đi vào kho, hoặc khi nguồn là hệ thống cũ cần nhiều xử lý đặc thù.
- Nghiêng về ELT khi dùng kho đám mây, khối lượng lớn, quy tắc nghiệp vụ hay thay đổi và đội dữ liệu thạo SQL.
Zero-ETL và reverse ETL là gì?
Zero-ETL là cách AWS gọi một nhóm tích hợp giúp giảm nhu cầu tự xây pipeline: dữ liệu được chuyển thẳng từ điểm này sang điểm kia, hoặc truy vấn xuyên nguồn mà không cần di chuyển. Tên gọi dễ gây hiểu lầm. Zero-ETL không xoá bỏ việc làm sạch và mô hình hoá, nó chỉ tự động hoá phần sao chép giữa các dịch vụ được hỗ trợ.
Reverse ETL đi theo chiều ngược lại: lấy dữ liệu đã xử lý trong kho (ví dụ điểm khách hàng tiềm năng) đẩy ngược về công cụ vận hành như CRM, phần mềm email marketing, để đội kinh doanh dùng ngay trong công việc hằng ngày.
Batch, streaming và CDC: nên nạp dữ liệu theo cách nào?
ETL truyền thống chạy theo lô (batch): mỗi đêm hoặc mỗi giờ quét một lần. Cách này rẻ, dễ vận hành và đủ cho hầu hết báo cáo quản trị. Khi doanh nghiệp cần biết tồn kho, gian lận hay hành vi khách trong vài giây, pipeline phải chuyển sang dạng luồng (streaming). Theo AWS, nạp tăng dần có thể theo lô (gom thay đổi định kỳ) hoặc theo luồng (đẩy thay đổi liên tục).
| Tiêu chí | Batch | Micro-batch | Streaming |
|---|---|---|---|
| Độ trễ thường gặp | Vài giờ đến một ngày | Vài giây đến vài phút | Dưới một giây đến vài giây |
| Ví dụ | Báo cáo doanh thu, công nợ hằng ngày | Dashboard đơn hàng cập nhật 5 phút một lần | Cảnh báo giao dịch bất thường, tồn kho theo thời gian thực |
| Công nghệ thường dùng | Công cụ ETL, SQL theo lịch, Airflow | Spark, dịch vụ ETL đám mây | Kafka, Flink, Spark, CDC |
| Độ phức tạp vận hành | Thấp | Trung bình | Cao |
CDC là gì và vì sao quan trọng?
CDC (Change Data Capture) là kỹ thuật chỉ bắt và chuyển phần dữ liệu thay đổi ở nguồn, thay vì quét lại toàn bộ bảng. IBM xếp CDC cùng streaming ETL vào nhóm biến thể hiện đại của ETL. Có hai cách làm CDC:
- Dựa trên truy vấn: định kỳ hỏi “dòng nào có ngày cập nhật sau lần chạy trước”. Dễ làm nhưng không thấy được dòng đã bị xoá, bỏ sót nếu ứng dụng quên cập nhật cột ngày, và tăng tải truy vấn lên nguồn.
- Dựa trên nhật ký giao dịch (log-based): đọc nhật ký mà cơ sở dữ liệu vốn ghi cho mọi thao tác. Tài liệu của Debezium, một bộ connector CDC mã nguồn mở chạy trên Kafka Connect, nêu các ưu điểm: bắt được mọi thay đổi kể cả thao tác xoá, độ trễ thấp mà không tốn CPU cho việc hỏi liên tục, và không cần thêm cột “ngày cập nhật” vào bảng nguồn.
Dữ liệu thay đổi sau đó thường đi qua một nền tảng truyền sự kiện như Apache Kafka, nền tảng mã nguồn mở được trang chủ dự án mô tả là dùng cho pipeline dữ liệu hiệu năng cao và phân tích luồng.
Lưu ý: Đừng chọn streaming chỉ vì nghe hiện đại. Hãy hỏi người dùng báo cáo: “Nếu số liệu trễ 1 giờ, quyết định của anh chị có khác không?”. Nếu câu trả lời là không, batch mỗi giờ rẻ và bền hơn nhiều. Bật CDC log-based cũng cần quản trị cơ sở dữ liệu đồng ý vì phải cấu hình nhật ký ở nguồn.
ETL nằm ở đâu trong kiến trúc kho dữ liệu và lakehouse?
ETL là đường ống nối hệ thống nghiệp vụ với nơi phân tích. Nó không đứng một mình mà là một tầng trong kiến trúc dữ liệu chung.
Với kho dữ liệu truyền thống, ETL làm sạch dữ liệu ở vùng staging rồi nạp vào kho trung tâm và các data mart. Bài về kho dữ liệu đã phân tích kỹ các tầng này, nên ở đây chỉ cần nhớ: ETL là tầng “cấp nguyên liệu” cho kho.
Với data lake và lakehouse, dữ liệu thường đi theo kiến trúc medallion. Theo tài liệu của Databricks, lớp Bronze giữ nguyên trạng thái thô của nguồn, lớp Silver là dữ liệu đã kiểm tra, làm sạch và làm giàu, lớp Gold là các góc nhìn tinh chỉnh phục vụ dashboard, học máy và ứng dụng. Databricks cũng nói rõ đây là thực hành được khuyến nghị, không bắt buộc. Đối chiếu với ETL: Extract và Load tạo ra Bronze, còn Transform chính là quá trình đi từ Bronze lên Silver rồi Gold. Nói cách khác, lakehouse về bản chất là ELT chia tầng.
Khi khối lượng lên tới hàng tỷ dòng hoặc dữ liệu đến liên tục từ cảm biến, nhật ký ứng dụng, ETL phải chạy trên các engine phân tán. Đây là giao điểm giữa ETL và dữ liệu lớn (big data). Đầu ra cuối cùng của pipeline thường là lớp ngữ nghĩa cho công cụ business intelligence vẽ dashboard và báo cáo quản trị.
Công cụ ETL phổ biến hiện nay gồm những nhóm nào?
Không có công cụ “tốt nhất” cho mọi doanh nghiệp. Dễ chọn hơn nếu bạn chia theo nhóm chức năng. Mô tả dưới đây dựa trên tài liệu chính thức của từng dự án, không phải đánh giá xếp hạng.
| Nhóm | Ví dụ | Phù hợp khi | Cần lưu ý |
|---|---|---|---|
| Công cụ ETL kéo thả truyền thống | SQL Server Integration Services (SSIS), Qlik Talend | Hệ thống chạy SQL Server, đội quen giao diện đồ hoạ | Bản mã nguồn mở Talend Open Studio đã ngừng từ 31/01/2024, các hướng dẫn cũ dựa trên bản này không còn được cập nhật |
| Dịch vụ tích hợp dữ liệu trên đám mây | AWS Glue, Azure Data Factory | Dữ liệu đã nằm trên nền tảng đám mây tương ứng | Tính phí theo tài nguyên chạy; phụ thuộc nhà cung cấp; cần xem vị trí đặt dữ liệu |
| Công cụ nạp dữ liệu qua connector | Airbyte, Apache NiFi | Kéo dữ liệu từ nhiều phần mềm SaaS, API, cơ sở dữ liệu | Chất lượng connector không đồng đều, cần kiểm tra với từng nguồn |
| Biến đổi trong kho (ELT) | dbt | Đội biết SQL, dùng kho đám mây | Chỉ lo phần Transform, cần công cụ khác để trích xuất và nạp |
| Engine xử lý phân tán | Apache Spark, Apache Flink | Khối lượng lớn, xử lý luồng | Cần kỹ sư dữ liệu và chi phí vận hành cụm máy |
| Streaming và CDC | Apache Kafka, Debezium | Đồng bộ gần thời gian thực giữa các hệ thống | Vận hành phức tạp, phải giám sát liên tục |
| Điều phối (orchestration) | Apache Airflow | Lên lịch, quản lý phụ thuộc giữa nhiều tác vụ | Không phải công cụ biến đổi; thiết kế cho luồng theo lô |
Một vài chi tiết từ tài liệu gốc giúp bạn hiểu đúng vai trò: Microsoft mô tả SSIS là nền tảng xây dựng giải pháp tích hợp và chuyển đổi dữ liệu cấp doanh nghiệp. AWS mô tả Glue là dịch vụ tích hợp dữ liệu serverless, hỗ trợ cả ETL, ELT và streaming. Airbyte tự giới thiệu là nền tảng sao chép dữ liệu mã nguồn mở với hơn 600 nguồn và đích. Spark nhấn mạnh khả năng xử lý cả batch lẫn streaming bằng Python, SQL, Scala, Java hoặc R. Flink định vị là engine tính toán có trạng thái trên luồng dữ liệu. Airflow nói rõ mình là nền tảng điều phối luồng công việc theo lô, có điểm bắt đầu và kết thúc rõ ràng.
Tiêu chí chọn công cụ nên đi theo thứ tự: nguồn dữ liệu bạn có (connector sẵn hay phải tự viết), kỹ năng của đội (kéo thả hay SQL, Python), yêu cầu độ trễ, nơi đặt dữ liệu theo quy định, rồi mới đến chi phí giấy phép. Với doanh nghiệp nhỏ, một công cụ nạp kèm SQL theo lịch thường đủ cho vài năm đầu.
Kiểm soát chất lượng dữ liệu trong ETL như thế nào?
Pipeline chạy “xanh” không có nghĩa dữ liệu đúng. Lỗi nguy hiểm nhất là lỗi âm thầm: không báo đỏ, nhưng số trên dashboard đã sai. Nguyên tắc rác vào thì rác ra áp dụng trọn vẹn ở đây. Bạn nên đặt kiểm tra ở ba điểm: ngay sau Extract (dữ liệu có về đủ không), sau Transform (quy tắc có đúng không) và trước khi công bố cho người dùng.
| Khía cạnh | Câu hỏi kiểm tra | Ví dụ quy tắc |
|---|---|---|
| Đầy đủ | Trường bắt buộc có bị trống? | Mã đơn, ngày, mã cửa hàng không được rỗng |
| Duy nhất | Có bản ghi trùng? | Mã đơn chuẩn là duy nhất trong bảng fact |
| Hợp lệ | Giá trị có nằm trong miền cho phép? | Số lượng lớn hơn 0; kênh thuộc danh sách Cửa hàng, Online |
| Toàn vẹn tham chiếu | Khoá ngoại có trỏ tới bản ghi tồn tại? | Mọi mã sản phẩm trong đơn đều có trong bảng sản phẩm |
| Kịp thời | Dữ liệu mới nhất cũ bao lâu? | Đơn mới nhất không cũ hơn 2 giờ trong giờ bán hàng |
| Khớp nguồn | Số dòng, tổng tiền có khớp hệ thống gốc? | Tổng doanh thu ngày lệch nguồn dưới 0,1% |
Bốn dòng đầu tương ứng đúng bốn kiểm thử dựng sẵn của dbt: unique, not_null, accepted_values và relationships. Theo tài liệu của dbt, mỗi kiểm thử thực chất là một câu truy vấn đi tìm các dòng vi phạm; nếu không tìm thấy dòng nào, kiểm thử đạt. Cách nghĩ này dùng được với mọi công cụ, kể cả khi bạn tự viết SQL.
Ba thực hành nên có:
- Bảng cách ly (quarantine): dòng lỗi không bị xoá mà chuyển sang bảng riêng, kèm lý do và thời điểm, để chủ dữ liệu sửa tại nguồn.
- Phân mức cảnh báo: lỗi nghiêm trọng (trùng mã đơn) thì dừng pipeline; lỗi nhẹ (thiếu email khách) thì chỉ cảnh báo.
- Đối soát định kỳ: so tổng số với hệ thống gốc mỗi ngày, vì kiểm thử theo dòng không phát hiện được việc cả một tệp không được nạp.
Khi số lượng pipeline tăng lên, kiểm thử, quản lý phiên bản và giám sát cần được làm bài bản theo cách tiếp cận DataOps, tương tự cách đội phần mềm áp dụng DevOps.
Những lỗi thường gặp khi làm ETL và cách phòng tránh
Các lỗi dưới đây xuất hiện lặp đi lặp lại ở nhiều dự án dữ liệu, đặc biệt với dữ liệu tiếng Việt.
| Lỗi | Biểu hiện | Cách phòng |
|---|---|---|
| Chạy lại bị nhân đôi dữ liệu | Doanh thu tăng gấp đôi sau khi chạy lại pipeline bị lỗi | Thiết kế idempotent: nạp bằng MERGE theo khoá nghiệp vụ, hoặc xoá rồi ghi lại theo phân vùng ngày |
| Sai múi giờ | Đơn sau nửa đêm rơi vào ngày hôm trước | Lưu thời gian UTC kèm cột giờ Việt Nam, ghi quy ước vào tài liệu |
| Đọc nhầm định dạng số và ngày | “1.200.000” thành 1,2; “05/10” thành ngày 10 tháng 5 | Khai báo kiểu dữ liệu và định dạng tường minh, không để công cụ tự đoán |
| Lỗi chữ tiếng Việt | “Nguyễn” ở hai nguồn không khớp nhau dù nhìn giống hệt | Chuyển font cũ TCVN3, VNI sang Unicode; chuẩn hoá về cùng dạng Unicode (NFC) và mã hoá UTF-8 |
| Nguồn đổi cấu trúc (schema drift) | Pipeline dừng, hoặc tệ hơn, cột mới bị bỏ qua âm thầm | Kiểm tra lược đồ mỗi lần chạy, thống nhất “hợp đồng dữ liệu” với đội phát triển phần mềm nguồn |
| Bỏ sót bản ghi bị xoá | Đơn đã huỷ ở nguồn vẫn còn trong kho | Dùng CDC dựa trên nhật ký hoặc đối soát định kỳ toàn bảng |
| Ghi đè lịch sử | Doanh thu năm trước đổi theo cơ cấu vùng mới | Áp dụng SCD type 2 cho các bảng danh mục quan trọng |
| Lộ mật khẩu kết nối | Mật khẩu cơ sở dữ liệu nằm trong mã nguồn, tệp cấu hình chia sẻ | Dùng kho quản lý bí mật, tài khoản chỉ đọc với quyền tối thiểu |
| Không có giám sát | Lỗi chỉ được phát hiện khi lãnh đạo hỏi “sao số hôm nay trống?” | Cảnh báo khi chạy lỗi, khi dữ liệu không được cập nhật đúng hạn |
Quy trình xây dựng ETL pipeline từng bước
Quy trình dưới đây phù hợp cho pipeline đầu tiên của một doanh nghiệp vừa và nhỏ, và có thể nhân rộng khi thêm nguồn.
- Bắt đầu từ câu hỏi kinh doanh. Ghi rõ báo cáo nào cần, ai dùng, chỉ số được định nghĩa ra sao. Ví dụ: “doanh thu thuần” đã trừ hàng trả và chiết khấu chưa.
- Kiểm kê nguồn. Với mỗi nguồn: chủ sở hữu, cách truy cập (cơ sở dữ liệu, API, tệp), tần suất cập nhật, giới hạn truy vấn, có chứa dữ liệu cá nhân không.
- Khảo sát dữ liệu (data profiling). Đếm ô trống, giá trị trùng, kiểu định dạng thực tế. Bước này thường phát hiện những “bất ngờ” như cùng một sản phẩm có năm cách viết tên.
- Thiết kế mô hình đích và tài liệu ánh xạ. Lập bảng: cột nguồn, cột đích, quy tắc biến đổi, người phê duyệt. Đây là tài liệu mà đội nghiệp vụ và đội kỹ thuật cùng ký.
- Chọn kiến trúc. ETL hay ELT, batch hay CDC, công cụ nào, đặt ở đâu.
- Xây dựng pipeline. Có vùng staging, nạp tăng dần, chạy lại được không nhân đôi, quản lý mã bằng hệ thống phiên bản như Git.
- Viết kiểm thử chất lượng và đối soát theo bảng ở phần trên, trước khi có người dùng thật.
- Điều phối và cảnh báo. Lên lịch, khai báo phụ thuộc giữa các bước, tự thử lại khi lỗi mạng tạm thời, gửi cảnh báo khi lỗi thật.
- Chạy song song và nghiệm thu. Cho pipeline chạy cùng cách làm cũ 2 đến 4 tuần, so từng con số với báo cáo đang dùng trước khi chuyển hẳn.
- Vận hành và cải tiến. Theo dõi thời gian chạy, chi phí, ghi lại nguồn gốc dữ liệu (lineage), rà soát quyền truy cập định kỳ.
Làm ETL với dữ liệu cá nhân cần lưu ý gì tại Việt Nam?
Hầu hết pipeline bán hàng, chăm sóc khách hàng, nhân sự đều chạm vào dữ liệu cá nhân. Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, thông qua ngày 26/06/2025 và có hiệu lực từ 01/01/2026, định nghĩa “xử lý dữ liệu cá nhân” gồm cả thu thập, phân tích, tổng hợp, mã hoá, khử nhận dạng, cung cấp, chuyển giao. Nghĩa là gần như mọi bước Extract, Transform, Load trên dữ liệu khách hàng đều là hoạt động xử lý theo luật. Văn bản hướng dẫn hiện hành là Nghị định 356/2025/NĐ-CP ngày 31/12/2025, hiệu lực từ 01/01/2026, thay thế Nghị định 13/2023/NĐ-CP.
Những điểm ảnh hưởng trực tiếp tới thiết kế pipeline:
- Đúng phạm vi, mục đích: Điều 3 của Luật yêu cầu chỉ thu thập, xử lý dữ liệu cá nhân đúng phạm vi, mục đích cụ thể. Pipeline báo cáo doanh thu không cần kéo theo số căn cước hay địa chỉ chi tiết của khách.
- Khử nhận dạng thật sự khác với giả danh: Luật định nghĩa khử nhận dạng là tạo ra dữ liệu mới không thể xác định được một người cụ thể. Mã khách giả danh như ví dụ ở trên vẫn có thể dò ngược nếu lộ khoá bí mật, nên vẫn cần được bảo vệ như dữ liệu cá nhân.
- Xử lý trên nền tảng nước ngoài: Điều 20 coi việc dùng nền tảng ở ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân thu thập tại Việt Nam là chuyển dữ liệu xuyên biên giới. Bên chuyển phải lập hồ sơ đánh giá tác động và gửi cơ quan chuyên trách trong 60 ngày kể từ ngày bắt đầu chuyển, trừ một số trường hợp miễn như lưu dữ liệu người lao động trên dịch vụ điện toán đám mây. Điều này liên quan trực tiếp khi bạn chọn dịch vụ ETL hoặc kho dữ liệu đặt ở vùng máy chủ nước ngoài.
- Mức phạt: theo Điều 8, tổ chức vi phạm quy định chuyển dữ liệu xuyên biên giới có thể bị phạt tối đa 5% doanh thu năm trước liền kề; các vi phạm khác tối đa 3 tỷ đồng.
- Luật Dữ liệu số 60/2024/QH15 (ban hành 30/11/2024, hiệu lực từ 01/07/2025) đặt thêm yêu cầu với dữ liệu được phân loại là quan trọng hoặc cốt lõi.
Biện pháp kỹ thuật nên đưa vào pipeline: lọc bỏ cột không cần ngay khi trích xuất; che hoặc giả danh số điện thoại, email ở bước Transform; tách vùng dữ liệu nhạy cảm với quyền truy cập riêng; mã hoá khi truyền và khi lưu; ghi nhật ký ai truy cập; và có cơ chế lan truyền yêu cầu xoá dữ liệu từ nguồn xuống mọi bảng phía sau.
Lưu ý: Phần này tóm tắt các điều khoản liên quan trực tiếp tới ETL, không thay thế tư vấn pháp lý. Với dữ liệu nhạy cảm như sức khoẻ, tài chính, hoặc khi chuyển dữ liệu ra nước ngoài, doanh nghiệp nên làm việc với bộ phận pháp chế trước khi triển khai.
Câu hỏi thường gặp
ETL là viết tắt của từ gì?
ETL là viết tắt của Extract, Transform, Load, tức trích xuất, chuyển đổi và nạp dữ liệu. Thuật ngữ chỉ cả quy trình lẫn nhóm công cụ dùng để tích hợp dữ liệu từ nhiều nguồn về một đích.
ETL và data pipeline khác nhau thế nào?
Data pipeline là khái niệm rộng hơn: bất kỳ luồng nào chuyển dữ liệu từ A sang B, kể cả chỉ sao chép nguyên trạng hoặc đẩy sự kiện thời gian thực. ETL là một dạng data pipeline có bước biến đổi rõ ràng, thường phục vụ phân tích.
Dùng Excel hoặc Power Query có được coi là ETL không?
Có, ở quy mô nhỏ. Microsoft mô tả Power Query là engine chuẩn bị và biến đổi dữ liệu dùng được cho xử lý ETL; nơi nạp kết quả là sản phẩm chứa nó, như Excel hoặc Power BI. Giới hạn nằm ở khối lượng, việc chạy tự động theo lịch, kiểm soát phiên bản và phân quyền. Khi báo cáo phụ thuộc vào máy của một người, đó là lúc nên chuyển sang pipeline thật.
ELT có thay thế hoàn toàn ETL không?
Không. ELT phổ biến hơn trên kho đám mây, nhưng ETL vẫn hợp lý khi phải che dữ liệu nhạy cảm trước khi vào kho, khi kho có tài nguyên hạn chế hoặc nguồn là hệ thống cũ. Nhiều doanh nghiệp kết hợp cả hai trong cùng một kiến trúc.
Doanh nghiệp nhỏ có cần ETL không?
Nếu bạn đang tổng hợp số liệu từ hai hệ thống trở lên mỗi tuần, bạn đã làm ETL thủ công. Tự động hoá phần này thường là bước đầu tiên đáng làm, trước cả khi nghĩ đến kho dữ liệu lớn hay AI.
Học ETL cần biết những gì?
Nền tảng là SQL và mô hình hoá dữ liệu (bảng fact, bảng dimension). Tiếp theo là một ngôn ngữ lập trình như Python, một công cụ điều phối, kiến thức về kho dữ liệu đám mây và các nguyên tắc chất lượng, bảo mật dữ liệu.
ETL nên chạy bao lâu một lần?
Theo nhu cầu ra quyết định, không theo khả năng kỹ thuật. Báo cáo tài chính thường chạy hằng ngày; dashboard bán hàng có thể 15 phút đến 1 giờ; chỉ những bài toán như chống gian lận, tồn kho trực tuyến mới cần CDC và streaming.