Junior Data Analyst

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.

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.

Decorator là hàm nhận một hàm và trả về hàm mới bọc quanh nó. @timer chỉ là cú pháp ngắn của func = timer(func).

import functools, time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return func(*args, **kwargs)
        finally:
            print(func.__name__, time.perf_counter() - start)
    return wrapper

• functools.wraps giữ lại __name__, docstring của hàm gốc, quan trọng cho log và debug.
• Decorator có tham số (ví dụ @retry(times=3)) cần thêm một lớp hàm bên ngoài.
• Ví dụ thực tế: @app.get của FastAPI, @login_required của Django, @functools.lru_cache.

Hay sai: decorator viết kiểu đồng bộ bọc hàm async def. Kết quả là đo thời gian tạo coroutine chứ không phải thời gian chạy.

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."