Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Technical PM của một sàn thương mại điện tử. Một sáng thứ Hai, team Growth gửi yêu cầu: "Cho mình bảng doanh thu theo từng tỉnh thành, chia theo nhóm khách hàng mới và cũ, cập nhật mỗi giờ." Nghe đơn giản, nhưng đằng sau con số đó là một chuỗi công việc: lấy dữ liệu đơn hàng từ database giao dịch, lấy thông tin khách hàng từ một hệ thống khác, lấy địa chỉ giao hàng từ API logistics, rồi gộp lại, làm sạch, tính toán — và tất cả phải chạy đều đặn, đáng tin cậy. Cái chuỗi đó gọi là data pipeline (đường ống dữ liệu), và cách bạn thiết kế nó sẽ quyết định dữ liệu của công ty bạn nhanh hay chậm, đắt hay rẻ, sạch hay bẩn.
Là Technical PM, bạn không phải người viết code cho pipeline. Nhưng bạn là người quyết định kiến trúc nên đi theo hướng ETL hay ELT, quyết định dữ liệu cần "tươi" đến mức nào, và phải giải thích được cho cả engineer lẫn ban lãnh đạo tại sao báo cáo chậm hai tiếng hay tại sao hoá đơn cloud tháng này tăng gấp đôi. Hiểu rõ ETL và ELT không phải để khoe thuật ngữ — nó giúp bạn ra quyết định đánh đổi (trade-off) đúng đắn về chi phí, tốc độ và độ phức tạp. Bài này sẽ trang bị cho bạn đúng tư duy đó.
Khái niệm cốt lõi
Pipeline là gì và ba chữ E-T-L
Mọi pipeline phân tích dữ liệu đều xoay quanh ba thao tác cơ bản:
- Extract (Trích xuất): lấy dữ liệu ra khỏi nguồn — database giao dịch (PostgreSQL, MySQL), API bên thứ ba (cổng thanh toán, đơn vị vận chuyển), file CSV/JSON, hoặc log sự kiện.
- Transform (Biến đổi): làm sạch và định hình dữ liệu — bỏ bản ghi trùng, chuẩn hoá định dạng ngày tháng, đổi đơn vị tiền tệ, gộp (join) nhiều bảng, tính toán tổng hợp (aggregate) như doanh thu theo ngày.
- Load (Nạp): đẩy dữ liệu vào data warehouse — kho dữ liệu được tối ưu cho việc truy vấn phân tích, ví dụ Google BigQuery, Snowflake, Amazon Redshift.
ETL truyền thống — biến đổi trước, nạp sau
Trong mô hình ETL (Extract → Transform → Load), dữ liệu được trích xuất từ nguồn, đưa vào một staging server (máy chủ trung gian) để biến đổi sạch sẽ, rồi mới nạp vào warehouse. Nghĩa là dữ liệu chỉ vào kho khi nó đã ở dạng "thành phẩm".
ETL ra đời từ thập niên 1990–2000, thời mà dung lượng lưu trữ rất đắt và warehouse rất chậm/giới hạn. Vì warehouse đắt và yếu, người ta phải làm sạch và rút gọn dữ liệu trước khi nạp, để không lãng phí tài nguyên kho. Công cụ kinh điển: Informatica, Talend, SSIS của Microsoft.
Ưu điểm của ETL: dữ liệu vào kho đã sạch, chuẩn, nên việc tuân thủ quy định (ví dụ che số thẻ tín dụng theo PCI DSS) được làm ngay từ tầng trung gian, dữ liệu nhạy cảm không bao giờ chạm vào warehouse ở dạng thô. Nhược điểm: cứng nhắc. Nếu sau này bạn cần một cách tính khác từ dữ liệu gốc mà bước Transform đã "vứt đi", bạn phải chạy lại toàn bộ pipeline từ nguồn.
ELT hiện đại — nạp trước, biến đổi sau
ELT (Extract → Load → Transform) đảo ngược hai bước cuối: dữ liệu thô được trích xuất và nạp thẳng vào warehouse trước, rồi việc biến đổi được thực hiện bên trong chính warehouse bằng SQL.
Vì sao ELT trở thành xu hướng chủ đạo từ khoảng 2015 đến nay? Vì các warehouse đám mây thế hệ mới như BigQuery, Snowflake, Redshift có khả năng tính toán cực mạnh và lưu trữ cực rẻ. Khi cái kho vừa rẻ vừa khoẻ, không còn lý do gì phải biến đổi dữ liệu ở bên ngoài — cứ đổ hết vào kho rồi dùng chính sức mạnh của kho để xử lý.
Ưu điểm của ELT:
- Linh hoạt: dữ liệu thô luôn nằm trong kho, nên khi cần một góc nhìn mới, bạn chỉ viết một câu SQL khác mà không cần chạm vào nguồn.
- Nhanh đưa vào kho: bỏ qua bước biến đổi nặng nề trước khi nạp, dữ liệu "đến nơi" nhanh hơn.
- Tận dụng công cụ hiện đại: dbt (data build tool) cho phép quản lý các phép biến đổi bằng SQL như quản lý code — có version, có test, có tài liệu.
Bảng so sánh nhanh
| Tiêu chí | ETL | ELT |
|---|---|---|
| Nơi biến đổi | Staging server riêng | Bên trong warehouse |
| Dữ liệu thô trong kho | Không | Có |
| Độ linh hoạt khi đổi yêu cầu | Thấp | Cao |
| Phù hợp với | Dữ liệu cần làm sạch/tuân thủ trước | Dữ liệu lớn, warehouse đám mây |
| Công cụ tiêu biểu | Informatica, Talend, SSIS | Fivetran + dbt + BigQuery/Snowflake |
Batch và streaming — một trục đánh đổi khác
Bên cạnh trục ETL/ELT, bạn còn cần hiểu pipeline chạy theo batch (theo lô) hay streaming (theo dòng). Batch là gom dữ liệu rồi xử lý theo định kỳ — mỗi giờ, mỗi đêm. Streaming là xử lý từng sự kiện ngay khi nó phát sinh, độ trễ tính bằng giây. Đa số báo cáo kinh doanh chạy batch là đủ; chỉ những bài toán cần phản ứng tức thì (phát hiện gian lận, dashboard thời gian thực) mới cần streaming, vốn phức tạp và đắt hơn nhiều.
Tình huống thực tế
Tình huống 1: Sàn TMĐT chuyển từ ETL sang ELT
Một sàn thương mại điện tử tầm trung tại TP.HCM (gọi là ShopViet) ban đầu xây pipeline theo kiểu ETL kinh điển: mỗi đêm, một script Python chạy trên server riêng, kéo dữ liệu đơn hàng từ MySQL, làm sạch, tính sẵn doanh thu theo ngày/danh mục, rồi nạp các bảng tổng hợp vào warehouse. Báo cáo chạy ổn — cho đến khi team Marketing liên tục xin "số liệu mới".
Tháng này họ muốn doanh thu chia theo kênh quảng cáo. Tháng sau muốn chia theo nhóm tuổi khách. Mỗi yêu cầu mới buộc engineer phải sửa script Transform, chạy lại từ đầu, và vì dữ liệu thô đã bị bước Transform rút gọn nên nhiều lần phải kéo lại lịch sử từ MySQL — gây tải nặng cho database giao dịch đang phục vụ khách thật.
Team quyết định chuyển sang ELT: dùng Fivetran đồng bộ dữ liệu thô từ MySQL thẳng vào BigQuery, rồi viết toàn bộ phép biến đổi bằng dbt ngay trong BigQuery. Kết quả: khi Marketing xin góc nhìn mới, analyst chỉ viết thêm một model dbt bằng SQL trong vài giờ, không cần đụng đến database sản xuất. Thời gian đáp ứng một yêu cầu dữ liệu mới giảm từ trung bình 3 ngày xuống nửa ngày.
Bài học: Khi yêu cầu phân tích thay đổi liên tục, ELT thắng nhờ giữ lại dữ liệu thô. Linh hoạt là tài sản quý hơn cả tốc độ thuần tuý.
Tình huống 2: Fintech và lý do vẫn giữ ETL
Một công ty fintech làm ví điện tử tại Việt Nam có bài toán ngược lại. Dữ liệu giao dịch của họ chứa thông tin cực nhạy cảm: số CCCD, số tài khoản ngân hàng, số thẻ. Theo yêu cầu tuân thủ (PCI DSS và Nghị định 13 về bảo vệ dữ liệu cá nhân), nhiều trường dữ liệu này không được phép xuất hiện ở dạng thô trong kho phân tích mà các analyst có quyền truy cập.
Nếu dùng ELT thuần, dữ liệu thô — bao gồm cả số thẻ — sẽ nằm trong warehouse, tạo ra rủi ro tuân thủ lớn. Vì vậy họ giữ một tầng ETL: tại staging server, các trường nhạy cảm được mã hoá hoặc che (masking) — ví dụ chỉ giữ 4 số cuối thẻ — trước khi nạp vào warehouse. Analyst làm việc với warehouse hoàn toàn không bao giờ thấy số thẻ đầy đủ.
Kết quả là một kiến trúc lai: ETL cho phần dữ liệu nhạy cảm cần làm sạch trước, ELT cho phần dữ liệu hành vi (lượt click, lượt mở app) vốn không nhạy cảm và cần linh hoạt phân tích.
Bài học: ELT không phải lúc nào cũng đúng. Khi tuân thủ và bảo mật là ràng buộc cứng, biến đổi trước khi nạp (ETL) vẫn là lựa chọn an toàn. PM giỏi không chọn theo trào lưu mà chọn theo ràng buộc thực tế.
Tình huống 3: Khi báo cáo "trễ hai tiếng" và PM phải giải thích
Tại một startup giao đồ ăn ở Đông Nam Á, CEO mỗi sáng 8h xem dashboard số đơn ngày hôm trước. Một buổi sáng, dashboard trống. PM bị gọi gấp. Điều tra ra: pipeline batch chạy lúc 6h sáng, nhưng đêm qua lượng đơn dịp lễ tăng gấp 4 lần, bước Transform trong warehouse xử lý quá lâu nên job chưa kịp xong lúc 8h.
PM đứng giữa hai phía. CEO muốn "dữ liệu thời gian thực". Engineer giải thích rằng chuyển sang streaming sẽ tốn thêm hạ tầng (Kafka, xử lý dòng) và chi phí gấp nhiều lần — trong khi thực ra CEO chỉ cần số liệu trước 8h, không cần từng giây. Giải pháp PM chốt: không làm streaming, mà (1) dời lịch chạy batch sớm hơn, lên 4h sáng, và (2) tối ưu lại query Transform tốn kém nhất. Vấn đề được giải quyết với chi phí gần như bằng không.
Bài học: Đừng nhầm "dữ liệu trễ" với "cần real-time". Hãy hỏi đúng câu: dữ liệu cần tươi đến mức nào để ra quyết định? Phần lớn nhu cầu kinh doanh chỉ cần batch đúng giờ, không cần streaming đắt đỏ.
Hướng dẫn từng bước
Khi đứng trước một bài toán pipeline mới, đây là quy trình tư duy của một Technical PM:
- Xác định người dùng cuối và độ tươi của dữ liệu. Ai dùng dữ liệu này, để ra quyết định gì, và chấp nhận trễ bao lâu? Báo cáo tài chính cuối ngày khác hẳn dashboard chống gian lận thời gian thực. Đây là câu hỏi quan trọng nhất, quyết định batch hay streaming.
- Liệt kê nguồn dữ liệu (Extract). Dữ liệu đến từ đâu — database nào, API nào, file gì? Mỗi nguồn có giới hạn gì (rate limit của API, tải lên database sản xuất)? Lưu ý: đọc trực tiếp từ database giao dịch đang chạy có thể làm chậm hệ thống phục vụ khách hàng thật.
- Quyết định ETL hay ELT. Hỏi: dữ liệu có nhạy cảm cần làm sạch/che trước khi vào kho không (nghiêng về ETL)? Yêu cầu phân tích có thay đổi thường xuyên không (nghiêng về ELT)? Warehouse đám mây hiện đại có sẵn không (cho phép ELT)? Đa số trường hợp mới hiện nay nên mặc định ELT, trừ khi có ràng buộc tuân thủ.
- Định nghĩa các phép biến đổi (Transform). Cần làm sạch gì, gộp những bảng nào, tính những chỉ số gì? Ghi rõ logic nghiệp vụ — ví dụ "doanh thu" tính theo giá trước hay sau khuyến mãi, có tính đơn hoàn trả không. Đây là nơi PM phải định nghĩa rõ ràng để tránh "mỗi báo cáo một con số".
- Chọn nơi nạp (Load) và lịch chạy. Warehouse nào, chạy mỗi đêm hay mỗi giờ, chạy lúc mấy giờ để kịp cho người dùng buổi sáng?
- Lên kế hoạch giám sát và xử lý lỗi. Nếu một lần chạy thất bại thì ai được báo? Dữ liệu trễ thì dashboard hiển thị gì? Đây là phần PM hay quên nhưng lại quyết định độ tin cậy thực tế của pipeline.
Lỗi thường gặp & mẹo
Lỗi 1 — Mặc định "real-time" cho mọi thứ. Nhiều PM nghe sếp nói "muốn dữ liệu mới nhất" liền yêu cầu streaming. Streaming phức tạp và đắt gấp nhiều lần batch. Mẹo: luôn quy đổi nhu cầu thành con số độ trễ cụ thể (15 phút? 1 giờ? cuối ngày?) rồi mới chọn kiến trúc.
Lỗi 2 — Quên chi phí tính toán của ELT. Trong ELT, mỗi câu transform là một lần warehouse "tính tiền". Một query gộp bảng tỉ dòng chạy mỗi giờ có thể đốt hoá đơn cloud rất nhanh. Mẹo: yêu cầu engineer dùng incremental model (chỉ xử lý phần dữ liệu mới thay vì tính lại toàn bộ) và theo dõi chi phí truy vấn hằng tháng.
Lỗi 3 — Không định nghĩa rõ logic nghiệp vụ. Khi "doanh thu" được tính khác nhau ở mỗi pipeline, các phòng ban cãi nhau về con số. Mẹo: PM phải sở hữu định nghĩa của các chỉ số cốt lõi (single source of truth) và đảm bảo mọi transform tuân theo.
Lỗi 4 — Đọc thẳng database sản xuất. Pipeline kéo dữ liệu trực tiếp từ database đang phục vụ khách có thể làm chậm app. Mẹo: dùng read replica (bản sao chỉ-đọc) hoặc công cụ đồng bộ chuyên dụng như Fivetran/Debezium để tách tải.
Lỗi 5 — Bỏ quên giám sát chất lượng dữ liệu. Pipeline chạy thành công không có nghĩa dữ liệu đúng — vẫn có thể bị trùng, thiếu, lệch. Mẹo: yêu cầu thêm các bài test dữ liệu (dbt test có sẵn tính năng này) để cảnh báo khi số liệu bất thường.
Bài tập thực hành
Bài tập 1 — Phân tích tình huống. Công ty bạn có một app đặt vé xem phim. Marketing muốn dashboard "số vé bán theo rạp, cập nhật mỗi giờ". Hãy viết ra: (a) các nguồn dữ liệu cần Extract; (b) bạn chọn ETL hay ELT và vì sao; (c) các phép Transform cần làm; (d) lịch chạy đề xuất. Viết khoảng nửa trang.
Bài tập 2 — Quyết định batch hay streaming. Cho ba bài toán sau, hãy quyết định mỗi cái cần batch hay streaming, và viết một câu giải thích độ trễ chấp nhận được: (1) báo cáo doanh thu gửi ban giám đốc mỗi sáng; (2) hệ thống cảnh báo giao dịch ví điện tử nghi gian lận; (3) bảng xếp hạng sản phẩm bán chạy hiển thị cho khách trên trang chủ.
Bài tập 3 — Phản biện chi phí. Engineer báo hoá đơn BigQuery tháng này tăng 80% vì một pipeline ELT chạy lại toàn bộ bảng đơn hàng mỗi giờ. Với vai trò PM, hãy viết 3 câu hỏi bạn sẽ đặt ra cho engineer và 2 hướng giải pháp bạn sẽ đề xuất.
Tóm tắt
- Mọi pipeline phân tích đều xoay quanh ba thao tác Extract, Transform, Load; ETL và ELT khác nhau ở thứ tự và nơi thực hiện bước Transform.
- ETL (biến đổi trước, nạp sau, trên staging server) phù hợp khi cần làm sạch hoặc che dữ liệu nhạy cảm trước khi vào kho, hoặc khi có ràng buộc tuân thủ như PCI DSS, Nghị định 13.
- ELT (nạp thô trước, biến đổi sau, bên trong warehouse) là xu hướng chủ đạo nhờ warehouse đám mây rẻ và mạnh; thắng lớn ở độ linh hoạt khi yêu cầu phân tích thay đổi liên tục. Bộ ba điển hình: Fivetran + dbt + BigQuery/Snowflake.
- Nhiều công ty dùng kiến trúc lai: ETL cho dữ liệu nhạy cảm, ELT cho dữ liệu hành vi.
- Trục batch và streaming độc lập với ETL/ELT: hầu hết nhu cầu kinh doanh chỉ cần batch đúng giờ, đừng vội chọn streaming đắt đỏ. Luôn quy nhu cầu "dữ liệu mới" thành con số độ trễ cụ thể.
- Vai trò của Technical PM không phải viết pipeline, mà là đặt đúng câu hỏi về độ tươi, chi phí, tuân thủ và định nghĩa nghiệp vụ — để team kỹ thuật chọn được kiến trúc đúng.