Senior Data Engineer

Chất lượng dữ liệu cần được kiểm tra tự động ở từng lớp và có người chịu trách nhiệm, không chỉ phát hiện khi dashboard sai.

• Test trong pipeline: not null, unique, giá trị hợp lệ, quan hệ khoá ngoại (dbt tests, Great Expectations).
• Giám sát: độ tươi (dữ liệu có cập nhật đúng giờ), số dòng bất thường, phân phối giá trị thay đổi đột ngột.
• Data contract với team nguồn: schema và ý nghĩa cột, thay đổi phải báo trước.
• Lỗi nghiêm trọng thì dừng pipeline, không đẩy dữ liệu sai xuống báo cáo.
• Lineage để biết lỗi ở nguồn ảnh hưởng tới bảng và dashboard nào.

Người phỏng vấn muốn nghe: ví dụ cụ thể bạn từng phát hiện và xử lý một lỗi dữ liệu.

Chỉ chọn streaming khi nghiệp vụ thật sự cần độ trễ thấp (phát hiện gian lận, cảnh báo, cá nhân hoá tức thời); còn báo cáo theo giờ/ngày thì batch hoặc micro-batch rẻ và dễ vận hành hơn.

Lưu ý khi làm streaming (Kafka, Flink, Spark Structured Streaming):

• Ngữ nghĩa giao nhận: at-least-once phổ biến, cần sink idempotent để tránh trùng.
• Event time và watermark để xử lý sự kiện đến trễ, sai thứ tự.
• Quản lý state và checkpoint để khôi phục khi lỗi.
• Thay đổi schema có kiểm soát (schema registry).
• Giám sát consumer lag.

Người phỏng vấn muốn nghe: cân nhắc chi phí vận hành, không chọn streaming chỉ vì "hiện đại".

Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

• Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
• Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
• Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
• Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
• Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
• Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

Agent cho LLM tự quyết định gọi tool theo nhiều bước, nên lỗi và rủi ro tăng theo số bước; cần giới hạn quyền và kiểm soát chặt.

• Tool rõ ràng: mô tả và schema tham số chặt, kiểm tra đầu vào bằng code trước khi thực thi.
• Quyền tối thiểu: tool chỉ đọc khi có thể; thao tác ghi, xoá, chuyển tiền cần người xác nhận.
• Prompt injection: nội dung lấy từ web, email, tài liệu là dữ liệu không tin cậy; không để nó điều khiển tool nhạy cảm.
• Giới hạn số bước, timeout, ngân sách token; xử lý lỗi tool và cho phép thử lại có kiểm soát.
• Log và tracing toàn bộ chuỗi hành động để audit.
• Đánh giá theo tỷ lệ hoàn thành tác vụ trên bộ kịch bản.

Người phỏng vấn muốn nghe: workflow cố định thường đủ; chỉ dùng agent tự do khi thật cần.

Star schema là mô hình dữ liệu cho phân tích: một bảng fact ở giữa nối với nhiều bảng dimension xung quanh, giúp truy vấn đơn giản và nhanh.

• Fact: ghi các sự kiện đo đếm được (đơn hàng, lượt xem), chứa số đo (số tiền, số lượng) và khoá ngoại tới dimension. Thường rất nhiều dòng.
• Dimension: mô tả ngữ cảnh (khách hàng, sản phẩm, ngày, cửa hàng), ít dòng, nhiều cột thuộc tính.
• Phải xác định rõ grain: mỗi dòng fact là gì (một đơn hay một dòng sản phẩm trong đơn).

Hay sai: trộn nhiều grain trong một bảng fact, dẫn đến cộng trùng khi tổng hợp.

SCD là cách xử lý khi thuộc tính của dimension thay đổi theo thời gian, ví dụ khách hàng chuyển thành phố hoặc đổi hạng thành viên.

• Type 1: ghi đè giá trị cũ. Đơn giản nhưng mất lịch sử; báo cáo quá khứ hiển thị theo giá trị mới.
• Type 2: thêm dòng mới cho mỗi thay đổi, kèm valid_from, valid_to, is_current và surrogate key. Giữ được lịch sử, fact trỏ đúng phiên bản tại thời điểm phát sinh.

Chọn Type 2 khi nghiệp vụ cần phân tích theo trạng thái lúc xảy ra (doanh thu theo hạng khách hàng lúc mua).

Hay sai: join fact với dimension Type 2 mà quên điều kiện thời gian hoặc is_current, làm nhân bản dòng.

Vài task chậm hơn hẳn phần còn lại thường là data skew: một khoá chiếm phần lớn dữ liệu, dồn vào một partition.

Chẩn đoán qua Spark UI: xem stage chậm, so sánh thời gian và dung lượng shuffle giữa các task, có spill ra đĩa không.

Cách xử lý:

• Bật Adaptive Query Execution (mặc định bật ở Spark 3.2+) để tự tách partition bị lệch.
• Broadcast bảng nhỏ khi join để tránh shuffle.
• Thêm salt vào khoá nóng rồi gộp lại.
• Lọc dữ liệu và chọn cột sớm, tránh collect() về driver.
• Điều chỉnh số partition; xử lý vấn đề quá nhiều file nhỏ.

Người phỏng vấn muốn nghe: đo bằng Spark UI trước, không tăng tài nguyên một cách mù quáng.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.