Junior Data Analyst (Python, SQL, R, Git)

WHERE lọc từng dòng trước khi gộp nhóm; HAVING lọc nhóm sau khi đã GROUP BY và tính hàm tổng hợp.

Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT.

SELECT customer_id, COUNT(*) AS orders
FROM orders
WHERE created_at >= DATE '2026-01-01'
GROUP BY customer_id
HAVING COUNT(*) >= 3;

Hay sai: dùng alias định nghĩa trong SELECT ngay ở WHERE (đa số hệ quản trị báo lỗi), hoặc lọc điều kiện dòng bằng HAVING làm truy vấn chậm hơn.

Window function tính toán trên một nhóm dòng liên quan mà không gộp mất dòng như GROUP BY. Hay dùng: ROW_NUMBER, RANK, LAG/LEAD, tổng luỹ kế SUM() OVER.

SELECT *
FROM (
  SELECT o.*, ROW_NUMBER() OVER (
    PARTITION BY customer_id ORDER BY created_at DESC
  ) AS rn
  FROM orders o
) t
WHERE rn = 1;

• ROW_NUMBER cho số duy nhất; RANK cho cùng hạng khi bằng nhau và nhảy số; DENSE_RANK không nhảy số.
• LAG để so sánh với kỳ trước, ví dụ doanh thu tháng này so với tháng trước.

Hay sai: ORDER BY không xác định duy nhất khiến kết quả thay đổi giữa các lần chạy.

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).

b = a không sao chép gì: hai tên cùng trỏ đến một object. Sửa qua b thì a cũng đổi.

• Shallow copy (a.copy(), list(a), a[:], copy.copy(a)): tạo container mới nhưng các phần tử bên trong vẫn là object cũ.
• Deep copy (copy.deepcopy(a)): sao chép đệ quy toàn bộ cấu trúc.

a = [[1, 2], [3]]
b = a.copy()
b[0].append(99)   # a cũng thành [[1, 2, 99], [3]]

Hay sai: tạo ma trận bằng [[0] * 3] * 3. Ba hàng là cùng một list, sửa một ô thì cả cột đổi theo. Viết đúng: [[0] * 3 for _ in range(3)].

Generator sinh giá trị lười (lazy): mỗi lần được hỏi mới tính phần tử tiếp theo, rồi tạm dừng tại yield. Nhờ vậy nó không phải giữ toàn bộ dữ liệu trong bộ nhớ.

def read_lines(path):
    with open(path) as f:
        for line in f:
            yield line.rstrip()

total = sum(len(l) for l in read_lines("big.log"))

• List comprehension [x * 2 for x in data] tạo cả list ngay. Generator expression (x * 2 for x in data) thì không.
• Hợp với file lớn, dữ liệu stream, phân trang API, pipeline xử lý nhiều bước.

Hay sai: duyệt một generator hai lần. Lần thứ hai không có gì vì nó đã cạn; cần duyệt lại thì tạo generator mới hoặc chuyển thành list.

Transaction là một nhóm thao tác được thực hiện như một đơn vị: hoặc tất cả thành công (COMMIT), hoặc không có gì xảy ra (ROLLBACK).

• Atomicity: không có trạng thái làm dở dang.
• Consistency: sau transaction dữ liệu vẫn thoả ràng buộc (khoá ngoại, unique, check).
• Isolation: các transaction chạy đồng thời không thấy dữ liệu dở dang của nhau, mức độ tuỳ isolation level.
• Durability: đã commit thì không mất dù server sập (nhờ write-ahead log / redo log).

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;

Người phỏng vấn muốn nghe: một ví dụ thực tế như chuyển tiền hoặc trừ tồn kho, và bạn biết giữ transaction ngắn, không gọi API bên ngoài khi đang mở transaction.

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.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.