Nối dữ liệu khách hàng là việc chính của FDE, không phải việc lặt vặt trước khi “làm thật”

Tuần đầu ở chỗ khách, bạn mở file export từ hệ thống bảo trì và thấy cột mã thiết bị ghi “PUMP-07”. Database cảm biến lại ghi “P7”. Demo đã hẹn sáng thứ Sáu, mà chưa dòng code nào chạy được cho đến khi hai cái tên đó được hiểu là cùng một máy bơm.

Nhiều kỹ sư coi đoạn này là “dọn dẹp” trước khi tới phần thú vị. Mô tả công việc thì nói khác. Tin tuyển FDE của Tagup ghi rõ một nhiệm vụ: đưa vào hệ thống thứ dữ liệu chưa hoàn hảo mà hoạt động thực tế của khách vẫn đang dựa vào. Tin này cũng liệt kê Python hoặc TypeScript, SQL, ETL và integration là kỹ năng cứng.

Paraform, dẫn nghiên cứu của MIT NANDA qua The New Stack, cho rằng các pilot AI trong doanh nghiệp thất bại phần lớn vì dữ liệu công ty nằm rải rác ở nhiều hệ thống riêng và khó tích hợp.

Bản tin The Pulse của The Pragmatic Engineer mô tả vai trò FDE hiện nay là nặng về integration và hỗ trợ sát sao khách hàng, nhẹ về xây hệ thống mới từ đầu. Nếu mô tả đó đúng, nối dữ liệu là kỹ năng bạn nên luyện từ trước khi nộp đơn.

Vì sao dữ liệu là nơi bài toán thật lộ ra?

Palantir đặt ra vai trò này từ đầu những năm 2010 và gọi nội bộ các kỹ sư này là Delta. Theo tin tuyển dụng của hãng, FDSE làm việc trực tiếp với khách để nhanh chóng hiểu những vấn đề lớn nhất của họ. Họ làm việc trong nhóm nhỏ, ít người giám sát, và tự chịu trách nhiệm end-to-end cho những dự án quan trọng.

Muốn làm trọn một dự án từ đầu đến cuối, việc đầu tiên bạn chạm vào gần như luôn là dữ liệu của khách. Với một nhóm nhỏ và ít người giám sát như vậy, nhiều khả năng sẽ không có đội data engineering riêng làm thay bạn phần này.

Chính tin tuyển dụng ấy cũng yêu cầu kinh nghiệm hoặc hứng thú với việc dùng dữ liệu quy mô lớn để giải bài toán kinh doanh có giá trị.

Còn một lý do sâu hơn. Mã thiết bị lệch nhau thường gợi ý rằng hai phòng ban chưa từng phải dùng chung dữ liệu, nên tìm hiểu vì sao một phép join hỏng cũng giúp bạn hiểu thêm cách tổ chức của khách vận hành.

Paraform mô tả FDE là vai trò lai giữa kỹ thuật phần mềm và triển khai cho khách hàng, và việc nối dữ liệu là chỗ hai nửa ấy gặp nhau.

Một ví dụ: hai hệ thống, một máy bơm

Thử hình dung khách là một nhà máy nước muốn dự đoán khi nào máy bơm hỏng. Có hai nguồn dữ liệu. File work_orders.csv từ hệ thống bảo trì có asset_code, opened_at theo giờ địa phương và cột failure_type do kỹ thuật viên gõ tay. Bảng sensor_devices trong Postgres có device_id, đi kèm số đo rung theo giờ UTC.

Việc đầu tiên là profile, chưa phải viết pipeline. Một câu SQL đơn giản sẽ cho bạn thấy mức độ lệch:

-- Bao nhiêu mã bên bảo trì không tìm thấy bên cảm biến?
SELECT w.asset_code, COUNT(*) AS so_phieu
FROM work_orders w
LEFT JOIN sensor_devices s ON s.device_id = w.asset_code
WHERE s.device_id IS NULL
GROUP BY w.asset_code
ORDER BY so_phieu DESC;

Giả sử gần như mọi mã đều không khớp. Đó không phải dữ liệu bẩn mà là hai quy ước đặt tên khác nhau. Bước tiếp theo là chuẩn hóa cả hai phía về một khóa chung, đưa giờ về cùng một múi, rồi join lại:

import re
import pandas as pd

def normalize(code) -> str | None:
    m = re.search(r"(\d+)$", str(code).strip().upper())
    return f"PUMP-{int(m.group(1)):02d}" if m else None

wo = pd.read_csv("work_orders.csv")
wo["asset_key"] = wo["asset_code"].map(normalize)
wo["opened_at_utc"] = (
    pd.to_datetime(wo["opened_at"])
      .dt.tz_localize("Asia/Ho_Chi_Minh")
      .dt.tz_convert("UTC")
)

# conn: kết nối tới Postgres của khách
sensors = pd.read_sql("SELECT device_id FROM sensor_devices", conn)
sensors["asset_key"] = sensors["device_id"].map(normalize)

merged = wo.merge(sensors[["asset_key", "device_id"]],
                  on="asset_key", how="left", indicator=True)

unmatched = merged[merged["_merge"] == "left_only"]
unmatched.to_csv("can_khach_xac_nhan.csv", index=False)

Chi tiết quan trọng nằm ở hai dòng cuối. Quy tắc “lấy số ở cuối mã” chỉ là giả thuyết của bạn, nên những phiếu không tìm được cảm biến tương ứng phải được gửi cho người phụ trách bên khách xác nhận, không được lặng lẽ bỏ đi. File ngoại lệ đó thường mở ra cuộc trò chuyện có giá trị nhất trong tuần.

Cuối cùng là đối soát, chạy mỗi lần pipeline chạy:

tong = len(wo)
assert sensors["asset_key"].dropna().is_unique, "Hai cảm biến bị gộp chung một khóa"
assert len(merged) == tong, "Phép join làm nhân bản phiếu"
khop = int((merged["_merge"] == "both").sum())
print(f"{khop}/{tong} phiếu đã gắn được với một cảm biến thật ({khop/tong:.1%})")

Hai assert này bắt đúng hai cách quy tắc chuẩn hóa có thể sai mà không ai thấy: gộp nhầm hai máy bơm thành một, hoặc làm một phiếu bảo trì bị nhân đôi sau join. Còn tỷ lệ khớp được đo với danh sách device_id thật bên cảm biến, chứ không phải với chính kết quả chuẩn hóa của bạn.

Dòng in ra ấy là con số bạn mang vào buổi họp với khách, biến câu “dữ liệu hơi lộn xộn” thành một tiến độ đo được.

Quy trình để bạn tự làm

Bắt đầu bằng việc kiểm kê: có những nguồn nào, ai sở hữu từng nguồn, xuất dữ liệu bằng cách nào và bao lâu cập nhật một lần. Sau đó profile từng nguồn: đếm null, xem phân bố giá trị, thử join các khóa với nhau. Chỉ khi biết chỗ lệch nằm ở đâu, bạn mới định nghĩa schema chuẩn và khóa chung.

Tiếp theo, viết quy tắc ánh xạ thành code tường minh, có file ngoại lệ và có người bên khách ký xác nhận. Lần nào pipeline chạy cũng phải in ra kết quả đối soát, để con số khớp luôn được đo trên dữ liệu mới nhất.

Khi bàn giao, tài liệu cần ghi rõ từng quy tắc và lý do có quy tắc đó, để người tiếp quản không phải đoán.

Những lỗi khiến dự án âm thầm chết

Lỗi thường gặp	Hậu quả	Cách làm đúng
Viết pipeline trước khi profile	Phát hiện lệch khóa ngay trước demo	Chạy LEFT JOIN đếm bản ghi mồ côi từ ngày đầu
Lặng lẽ bỏ dòng không khớp	Mô hình học trên tập dữ liệu bị lệch mà không ai biết	Xuất file ngoại lệ và gửi cho khách xác nhận
Tự đoán ý nghĩa của cột gõ tay	Phân loại sai kiểu hỏng hóc	Hỏi kỹ thuật viên đã gõ dữ liệu đó
Trộn giờ địa phương với UTC	Sự kiện hỏng hóc lệch khỏi tín hiệu cảm biến	Chuẩn hóa múi giờ ngay ở bước đọc dữ liệu
Không có số liệu đối soát	Không trả lời được câu hỏi “dữ liệu đã đủ chưa?”	In tỷ lệ khớp với danh sách cảm biến thật và kiểm tra số dòng sau join ở mỗi lần chạy

Thể hiện kỹ năng này thế nào khi xin việc?

Khi đọc JD, hãy để ý các cụm như ETL, integration, “imperfect data” hay “large scale data”. Chúng cho biết thời gian của bạn sẽ đi về đâu. Nếu JD chỉ nói về mô hình mà không nhắc gì đến dữ liệu của khách, hãy hỏi lại trong buổi phỏng vấn.

Trên CV, một dòng như “hợp nhất dữ liệu từ ba hệ thống, nâng tỷ lệ khớp khóa lên mức khách chấp nhận trong hai tuần” có sức nặng hơn nhiều so với “thành thạo pandas”. Bạn cũng có thể đưa vào portfolio một repo nhỏ: hai bộ dữ liệu công khai lệch nhau, một file ngoại lệ, một bước đối soát.

Một repo như vậy là bằng chứng cụ thể rằng bạn đã tự tay làm đúng loại việc mà các JD trên mô tả.

Đến ngày demo, khách sẽ không nhớ mô hình của bạn dùng thuật toán gì. Họ sẽ nhớ lần đầu tiên thấy phiếu bảo trì và tín hiệu cảm biến của cùng một máy bơm hiện trên một màn hình.