Analytics Engineer (Data Engineer, Data Analyst)

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.

Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

• Dirty read: đọc dữ liệu transaction khác chưa commit.
• Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
• Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

Đo trước rồi mới sửa: tìm đúng query chậm, đọc execution plan, rồi chỉnh index hoặc cách viết query.

1. Bật slow query log (MySQL) hoặc pg_stat_statements (PostgreSQL) để biết query nào tốn thời gian nhất.
2. Chạy EXPLAIN (PostgreSQL nên dùng EXPLAIN (ANALYZE, BUFFERS)) xem có full scan, ước lượng số dòng lệch nhiều so với thực tế, sort trên đĩa không.
3. Sửa theo nguyên nhân: thêm hoặc đổi composite index, bỏ hàm bọc cột, chỉ SELECT cột cần, phân trang bằng keyset thay cho OFFSET lớn.
4. Kiểm tra phía ứng dụng: lỗi N+1 query, thiếu connection pool, lock chờ lâu.
5. Cập nhật thống kê (ANALYZE) nếu planner ước lượng sai.

Người phỏng vấn muốn nghe: quy trình có số liệu trước/sau, không phải đoán rồi thêm index bừa.

Trước tiên kiểm tra dữ liệu có đúng không, rồi mới phân tích nghiệp vụ.

1. Dữ liệu: pipeline có chạy đủ không, dữ liệu đến trễ, có thay đổi tracking hay định nghĩa chỉ số không.
2. So sánh hợp lý: cùng thứ trong tuần trước, có ngày lễ, khuyến mãi hôm qua không.
3. Phân rã chỉ số: doanh thu = số người dùng × tỷ lệ chuyển đổi × giá trị đơn trung bình; xem thành phần nào giảm.
4. Cắt lát: theo kênh, nền tảng, khu vực, sản phẩm, phiên bản app để khoanh vùng.
5. Đối chiếu sự kiện: deploy mới, lỗi thanh toán, đối thủ, chiến dịch quảng cáo dừng.

Người phỏng vấn muốn nghe: cách tiếp cận có cấu trúc và kết luận đi kèm đề xuất hành động.

Idempotent nghĩa là chạy lại cùng một khoảng dữ liệu bao nhiêu lần cũng cho kết quả giống nhau, không trùng, không mất.

• Xử lý theo partition thời gian; ghi bằng ghi đè partition hoặc MERGE theo khoá, không INSERT nối thêm mù quáng.
• Tham số hoá job theo ngày logic (ví dụ data_interval_start trong Airflow) thay vì dùng giờ hiện tại.
• Dữ liệu đến trễ: lùi cửa sổ xử lý lại vài ngày gần nhất, hoặc dùng watermark với streaming.
• Khử trùng lặp theo khoá sự kiện.
• Hỗ trợ backfill có kiểm soát.

Hay sai: dùng now() trong logic khiến chạy lại hôm khác ra kết quả khác.

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.

Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

• 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
• 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
• 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

Đây là câu mở đầu gần như chắc chắn có. Dùng công thức Hiện tại – Quá khứ – Tương lai, gói trong khoảng 1–2 phút.

• Hiện tại: vị trí, số năm kinh nghiệm, mảng/công nghệ chính.
• Quá khứ: một hai dự án hoặc thành tích liên quan nhất tới vị trí đang tuyển.
• Tương lai: vì sao bạn quan tâm tới vị trí này.

Câu mẫu: "Em là backend developer, khoảng 3 năm kinh nghiệm, chủ yếu làm Java Spring cho hệ thống thanh toán. Ở dự án gần nhất em phụ trách module đối soát và tối ưu các truy vấn báo cáo chạy chậm. Em đang tìm môi trường làm sản phẩm lâu dài để đi sâu hơn về thiết kế hệ thống, nên rất quan tâm tới vị trí này."

Hay sai: kể từ quê quán, trường cấp ba, hoặc đọc lại nguyên CV.