ETL (Extract – Transform – Load) là quy trình trích xuất dữ liệu từ nguồn, biến đổi nó trên một máy chủ trung gian rồi mới nạp kết quả đã sạch vào kho. ELT (Extract – Load – Transform) đảo hai bước cuối: nạp dữ liệu thô vào kho trước, rồi dùng chính sức tính toán của kho để biến đổi. Khác biệt nghe như thứ tự chữ cái, nhưng kéo theo khác biệt về chi phí, khả năng tính lại lịch sử và ai trong tổ chức viết được logic.
ETL là cách làm chuẩn trong nhiều thập kỷ, khi kho dữ liệu đắt và ít sức tính toán. ELT trở thành phổ biến khi kho dữ liệu đám mây tách lưu trữ khỏi tính toán, khiến việc lưu dữ liệu thô và biến đổi tại chỗ rẻ hơn nhiều. Hiện nay đa số dự án mới chọn ELT làm mặc định, nhưng ETL vẫn đúng trong vài tình huống cụ thể mà bài này sẽ chỉ ra.
Ba bước, hiểu cho đúng
Trích xuất (Extract). Đọc dữ liệu từ nguồn: cơ sở dữ liệu ERP, API của sàn thương mại điện tử, tệp Excel trên ổ chung, nhật ký máy chủ. Nguyên tắc số một là không làm phiền nguồn: đọc ngoài giờ cao điểm, đọc từ bản sao chỉ đọc nếu có, chỉ lấy phần thay đổi thay vì quét toàn bộ.
Biến đổi (Transform). Làm sạch kiểu dữ liệu, chuẩn hoá mã, ghép bảng, áp quy tắc nghiệp vụ, tính chỉ số, xây bảng fact và dimension. Đây là nơi chứa phần lớn tri thức nghiệp vụ, nên cũng là nơi cần kiểm thử và quản lý phiên bản như phần mềm.
Nạp (Load). Ghi dữ liệu vào đích. Có ba kiểu: nạp đè toàn bộ (đơn giản, tốn tài nguyên), nạp thêm (chỉ ghi dòng mới), và hợp nhất (merge/upsert, cập nhật dòng đã có, thêm dòng mới). Chọn sai kiểu nạp là nguồn phổ biến của dữ liệu trùng hoặc mất.
So sánh ETL và ELT
Bảng so sánh ở dạng điển hình. Trên thực tế nhiều hệ thống làm một ít biến đổi trước khi nạp (che dữ liệu nhạy cảm, đổi kiểu) rồi làm phần chính sau khi nạp.
| Tiêu chí | ETL | ELT |
|---|---|---|
| Nơi biến đổi | Máy chủ hoặc công cụ trung gian | Bên trong kho dữ liệu |
| Dữ liệu thô có trong kho không | Thường không | Có, ở tầng tiếp nhận |
| Tính lại lịch sử khi đổi logic | Phải trích xuất lại từ nguồn, có khi không còn | Chạy lại biến đổi trên dữ liệu thô đã lưu |
| Ngôn ngữ viết logic | Thường là công cụ kéo thả hoặc mã riêng của công cụ | Thường là SQL, phân tích viên đọc được |
| Chi phí chính | Máy chủ trung gian, bản quyền công cụ | Tính toán trong kho, có thể tăng nhanh nếu truy vấn kém |
| Kiểm soát dữ liệu nhạy cảm | Lọc bỏ trước khi vào kho | Phải phân quyền và che trong kho |
| Hợp với | Kho tại chỗ ít tài nguyên, yêu cầu không lưu dữ liệu thô | Kho đám mây, đội phân tích viết SQL |
Lợi thế lớn nhất của ELT thường bị đánh giá thấp: khả năng sửa sai. Khi phát hiện quy tắc tính doanh thu sai từ sáu tháng trước, với ELT bạn sửa mã và chạy lại trên dữ liệu thô; với ETL thuần, nếu nguồn đã xoá hoặc ghi đè dữ liệu cũ, con số sai đó sẽ ở lại mãi.
Nạp toàn bộ, nạp tăng dần và CDC
Khi dữ liệu nhỏ, cách đơn giản nhất là mỗi đêm kéo toàn bộ bảng về và ghi đè. Cách này dễ hiểu, khó sai, nhưng sẽ chậm và đắt khi bảng hoá đơn lên tới hàng chục triệu dòng. Bước tiếp theo là nạp tăng dần: chỉ lấy các dòng có thời điểm cập nhật sau lần nạp trước, dựa trên một cột kiểu "updated_at". Điểm yếu là nó phụ thuộc hoàn toàn vào việc phần mềm nguồn cập nhật cột đó đúng; nhiều phần mềm cũ sửa dữ liệu mà không đổi dấu thời gian, và không ghi nhận dòng bị xoá.
Change Data Capture (CDC) giải quyết vấn đề này bằng cách đọc nhật ký giao dịch của cơ sở dữ liệu nguồn, nơi mọi thao tác thêm, sửa, xoá đều được ghi lại. Ưu điểm là bắt được cả xoá, độ trễ thấp và ít tải lên nguồn. Đổi lại cần quyền truy cập sâu vào cơ sở dữ liệu nguồn, điều mà nhà cung cấp phần mềm đóng gói hoặc dịch vụ thuê bao thường không cho. Với phần mềm dạng thuê bao, cách duy nhất có khi là API, kèm giới hạn số lượt gọi.
Quy tắc thực hành: bắt đầu bằng nạp toàn bộ cho bảng danh mục nhỏ (khách hàng, sản phẩm), nạp tăng dần cho bảng giao dịch lớn, và định kỳ (ví dụ mỗi tuần) chạy một lần đối soát tổng số dòng, tổng tiền giữa nguồn và kho để bắt các thay đổi mà cơ chế tăng dần bỏ sót.
Những đặc tính một đường ống dữ liệu tốt phải có
Các đường ống dữ liệu thất bại theo cách lặng lẽ: không báo lỗi, chỉ ra số sai. Vì vậy tiêu chí đánh giá quan trọng hơn tốc độ là khả năng tin cậy:
- Chạy lại an toàn (idempotent): chạy cùng một ngày hai lần không sinh dữ liệu trùng. Đây là điều kiện để khôi phục sau sự cố mà không phải dọn tay.
- Kiểm thử dữ liệu tự động: mỗi bảng có kiểm tra tối thiểu như khoá không trùng, không rỗng ở cột bắt buộc, giá trị nằm trong miền hợp lệ, tổng tiền khớp nguồn trong biên sai số.
- Cảnh báo khi trễ: nếu dữ liệu bán hàng hôm qua chưa về lúc 7 giờ sáng, người phụ trách phải được báo trước khi lãnh đạo mở dashboard.
- Quản lý phiên bản logic: mã biến đổi nằm trong hệ thống quản lý phiên bản, mỗi thay đổi có người duyệt, có lịch sử. Không sửa thẳng trên môi trường chạy thật.
- Phả hệ dữ liệu (lineage): nhìn được một cột trên báo cáo bắt nguồn từ bảng nào, đi qua những bước nào. Khi nguồn đổi cấu trúc, biết ngay báo cáo nào bị ảnh hưởng.
- Tách môi trường: thử nghiệm trên bản sao, không thử trên kho đang phục vụ báo cáo của ban điều hành.
Chọn công cụ: tự viết, mã nguồn mở hay dịch vụ quản lý
Không có công cụ đúng cho mọi doanh nghiệp. Bảng dưới so ba nhóm cách làm, không nhắm đến sản phẩm cụ thể nào.
| Cách làm | Ưu điểm | Nhược điểm | Hợp khi |
|---|---|---|---|
| Tự viết script và lập lịch | Rẻ lúc đầu, kiểm soát hoàn toàn | Phụ thuộc người viết, thiếu giám sát, khó mở rộng | Rất ít nguồn, có lập trình viên ổn định |
| Công cụ mã nguồn mở tự vận hành | Không phí bản quyền, cộng đồng lớn, nhiều kết nối sẵn | Tốn công vận hành, nâng cấp, bảo mật | Có kỹ sư dữ liệu và hạ tầng sẵn |
| Dịch vụ tích hợp quản lý sẵn | Triển khai nhanh, kết nối dựng sẵn cho nhiều nguồn phổ biến | Phí theo khối lượng tăng nhanh, kết nối cho phần mềm nội địa có thể thiếu | Đội mỏng, nguồn là các dịch vụ phổ biến |
Một điểm riêng của doanh nghiệp Việt Nam: nhiều phần mềm kế toán, bán hàng trong nước không có kết nối dựng sẵn trong các dịch vụ quốc tế. Trước khi ký hợp đồng, hãy liệt kê mọi nguồn và hỏi rõ nguồn nào có kết nối sẵn, nguồn nào phải tự viết; phần tự viết thường là phần chiếm nhiều công nhất.
Reverse ETL và chiều ngược lại của dòng dữ liệu
Reverse ETL là gì. Là việc đưa dữ liệu đã tính trong kho ngược về hệ thống vận hành: điểm rủi ro rời bỏ của khách đẩy vào CRM để nhân viên chăm sóc thấy, phân khúc khách hàng đẩy sang công cụ gửi tin nhắn, hạn mức tín dụng đề xuất đẩy về phần mềm bán hàng.
Vì sao xuất hiện. Dashboard chỉ được người xem đọc; dữ liệu nằm trong công cụ mà nhân viên dùng hằng ngày mới thay đổi hành vi. Đưa kết quả phân tích vào quy trình là bước biến kho dữ liệu từ nơi xem số thành nơi tạo việc làm.
Rủi ro cần quản trị. Khi kho ghi ngược vào hệ thống vận hành, lỗi trong kho trở thành lỗi trong giao dịch. Cần quy định rõ trường nào kho được ghi, ai duyệt thay đổi logic, và có cơ chế dừng khẩn cấp. Dữ liệu cá nhân đi qua nhiều hệ thống hơn nên phạm vi tuân thủ cũng rộng hơn.
Ví dụ: một luồng ELT cho chuỗi cửa hàng, từ quầy thu ngân đến báo cáo buổi sáng
Ví dụ giả định dưới đây mô tả một chuỗi 30 cửa hàng tiện lợi dùng phần mềm bán hàng đặt trên máy chủ trung tâm, kế toán dạng thuê bao và một sàn thương mại điện tử. Mục tiêu: 7 giờ sáng ban điều hành có số bán hàng hôm qua đã đối soát.
- 0 giờ 30: trích xuất các dòng hoá đơn có thời điểm cập nhật sau lần chạy trước từ bản sao chỉ đọc của cơ sở dữ liệu bán hàng; trích toàn bộ danh mục sản phẩm, cửa hàng vì chúng nhỏ.
- 1 giờ: gọi API của phần mềm kế toán và sàn thương mại điện tử, lấy chứng từ và đơn hàng của ngày hôm trước, tôn trọng giới hạn lượt gọi; lưu nguyên trạng phản hồi vào tầng tiếp nhận kèm thời điểm nạp.
- 1 giờ 30: chạy biến đổi trong kho: chuẩn hoá mã sản phẩm qua bảng ánh xạ, gộp đơn trả hàng vào đúng kỳ theo quy tắc phòng tài chính đã chốt, tính doanh thu thuần và giá vốn ở độ hạt dòng hoá đơn.
- 2 giờ: chạy kiểm thử: không trùng khoá dòng hoá đơn, không có sản phẩm chưa ánh xạ, tổng tiền theo cửa hàng lệch nguồn không quá một ngưỡng nhỏ do phòng tài chính quy định. Kiểm thử thất bại thì dừng, không cập nhật bảng phục vụ, và gửi cảnh báo cho người trực.
- 2 giờ 15: cập nhật các bảng phục vụ và làm mới bộ nhớ đệm của công cụ BI.
- 6 giờ 30: người phụ trách dữ liệu kiểm tra nhanh bảng tình trạng các luồng; nếu có luồng lỗi, dashboard hiển thị dòng chú thích "số liệu đến hết ngày hôm kia" thay vì im lặng hiển thị số thiếu.
Điểm đáng học trong ví dụ không phải giờ chạy mà là hai nguyên tắc: dừng khi kiểm thử hỏng (số cũ nhưng đúng tốt hơn số mới nhưng sai) và minh bạch độ tươi của dữ liệu với người xem. Hai nguyên tắc này rẻ để làm nhưng quyết định lãnh đạo có tin vào kho hay không.
Câu hỏi thường gặp
ELT có làm tăng chi phí kho dữ liệu đám mây không?
Có thể, nếu biến đổi viết kém, chạy lại toàn bộ thay vì tăng dần, hoặc chạy quá thường xuyên. Cần theo dõi chi phí theo từng mô hình biến đổi, đặt lịch chạy hợp với nhu cầu và dùng bảng tăng dần cho dữ liệu lớn.
Dữ liệu nhạy cảm có nên nạp thô vào kho theo kiểu ELT không?
Chỉ nên nạp những trường thật sự cần. Các trường như số căn cước hay số tài khoản nên được loại bỏ, băm hoặc mã hoá ngay ở bước trích xuất. ELT không có nghĩa là phải nạp mọi cột; nguyên tắc tối thiểu hoá dữ liệu vẫn áp dụng.
Streaming có thay thế ETL theo lô không?
Xử lý luồng phù hợp khi quyết định phụ thuộc vào dữ liệu tính bằng giây hoặc phút, như phát hiện gian lận hay điều phối giao hàng. Với báo cáo quản trị, nạp theo lô hằng đêm hoặc theo giờ rẻ hơn, đơn giản hơn và đủ dùng. Nhiều hệ thống kết hợp cả hai.
Ai nên viết phần biến đổi: kỹ sư dữ liệu hay phân tích viên?
Xu hướng hiện nay là kỹ sư lo trích xuất, nạp, hạ tầng, còn phân tích viên am hiểu nghiệp vụ viết biến đổi bằng SQL theo quy trình phần mềm có duyệt mã và kiểm thử. Vai trò này đôi khi được gọi là analytics engineer.
Làm sao biết đường ống đang ra số sai mà không báo lỗi?
Đặt kiểm tra đối soát định kỳ giữa nguồn và kho về số dòng và tổng tiền, theo dõi biến động bất thường của các chỉ số chính, và có người nghiệp vụ được giao xem và xác nhận số hằng tuần. Lỗi lặng lẽ thường bị phát hiện bởi người hiểu nghiệp vụ trước máy.
Có nên giữ dữ liệu thô vô thời hạn không?
Không nhất thiết. Giữ đủ lâu để tính lại lịch sử theo nhu cầu kiểm toán và phân tích, nhưng phải có chính sách vòng đời, nhất là với dữ liệu cá nhân. Thời hạn lưu cụ thể cần dựa trên yêu cầu pháp lý hiện hành và mục đích sử dụng đã công bố.