Data Engineer (SQL / Spark / ETL)

ETL biến đổi dữ liệu trước khi nạp vào kho; ELT nạp dữ liệu thô vào kho trước rồi biến đổi ngay trong kho bằng SQL.

ELT phổ biến vì:

• Warehouse/lakehouse trên cloud (BigQuery, Snowflake, Databricks) tính toán mạnh và co giãn.
• Giữ được dữ liệu thô, khi đổi logic có thể chạy lại.
• Biến đổi viết bằng SQL, quản lý bằng công cụ như dbt có version, test, tài liệu.

ETL vẫn hợp khi phải loại bỏ dữ liệu nhạy cảm trước khi vào kho, hoặc nguồn quá lớn cần lọc bớt.

Người phỏng vấn muốn nghe: tổ chức theo lớp (raw, staging, mart hoặc bronze, silver, gold).

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.

Có. Composite index sắp xếp theo cột đầu, rồi đến cột thứ hai trong cùng giá trị cột đầu, v.v. Vì vậy nó chỉ dùng hiệu quả khi query dùng các cột từ trái sang (leftmost prefix).

Với INDEX (status, created_at):

• WHERE status = 'paid' AND created_at > ...: dùng tốt.
• WHERE status = 'paid' ORDER BY created_at DESC: dùng cho cả lọc lẫn sắp xếp.
• WHERE created_at > ... (không có status): thường không dùng được.

Nguyên tắc chọn thứ tự: cột so sánh bằng (=) đặt trước, cột so sánh khoảng hoặc sắp xếp đặt sau. Nếu index chứa đủ mọi cột query cần (covering index) thì DB không phải đọc lại bảng.

Hay sai: tạo riêng index cho từng cột rồi nghĩ rằng chúng sẽ kết hợp hiệu quả như một composite index.

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.

GIL (Global Interpreter Lock) trong CPython chỉ cho một thread chạy bytecode Python tại một thời điểm. Vì vậy threading không tăng tốc tác vụ nặng CPU, nhưng vẫn hữu ích cho I/O vì GIL được nhả ra khi chờ mạng, đĩa.

• I/O, số lượng vừa phải, thư viện blocking: threading hoặc ThreadPoolExecutor.
• I/O rất nhiều kết nối đồng thời: asyncio với thư viện async (httpx, asyncpg).
• Nặng CPU: multiprocessing hoặc ProcessPoolExecutor, hoặc dùng thư viện viết bằng C như NumPy (nhả GIL khi tính toán).

Từ Python 3.13 có bản build free-threaded (không GIL) tuỳ chọn, nhưng chưa phải mặc định và còn phụ thuộc thư viện hỗ trợ.

Người phỏng vấn muốn nghe: bạn phân biệt được bài toán I/O-bound và CPU-bound trước khi chọn công cụ.

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.

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.

Tìm hiểu trước mặt bằng lương cho vị trí và số năm kinh nghiệm (dữ liệu lương trên Drama Công Ty, bạn bè cùng ngành), rồi đưa ra một khoảng có căn cứ.

• Nói rõ gross hay net. Gross là lương trước khi trừ bảo hiểm bắt buộc và thuế thu nhập cá nhân; net là số thực nhận.
• Hỏi tổng thu nhập: lương tháng 13 (không bắt buộc theo luật), thưởng, chu kỳ review lương, bảo hiểm sức khoẻ.
• Lương thử việc theo luật tối thiểu bằng 85% lương chính thức; nhiều công ty trả 100%, cứ hỏi rõ.

Câu mẫu: "Dựa trên kinh nghiệm và mặt bằng thị trường, em mong muốn khoảng X đến Y triệu gross. Em cũng muốn hiểu thêm về thưởng và review lương bên mình."

Hay sai: nói "tuỳ công ty" (dễ bị trả thấp), hoặc khai khống lương hiện tại.