Middle Data Engineer (Apache Spark, Trino)

INNER JOIN chỉ giữ dòng khớp ở cả hai bảng; LEFT JOIN giữ mọi dòng bảng trái, phía phải không khớp thì NULL; FULL OUTER JOIN giữ tất cả; CROSS JOIN ghép mọi cặp.

Dòng bị nhân bản khi khoá join không duy nhất ở một phía (quan hệ một-nhiều hoặc nhiều-nhiều). Ví dụ join orders với payments khi một đơn có nhiều lần thanh toán, rồi SUM(order_amount) sẽ bị cộng trùng.

• Kiểm tra độ duy nhất của khoá trước khi join.
• Gộp (aggregate) bảng chi tiết trước rồi mới join.

Hay sai: đặt điều kiện lọc bảng phải trong WHERE sau LEFT JOIN, vô tình biến nó thành INNER JOIN; nên đặt trong ON.

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.

Ý chính: dùng multi-stage build, sắp xếp layer để tận dụng cache, và không chạy bằng root.

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
USER node
COPY --from=build /app/dist /app

• Copy file khai báo dependency trước, code sau, để đổi code không phải cài lại package.
• Dùng .dockerignore loại node_modules, .git, file .env.
• Không nhét secret vào image (kể cả ở layer đã xoá); dùng build secret hoặc biến môi trường lúc chạy.
• Ghim phiên bản base image, quét lỗ hổng trong pipeline.

CI là tự động build và test mỗi lần merge code; Continuous Delivery là luôn có bản sẵn sàng deploy nhưng lên production cần bấm duyệt; Continuous Deployment thì tự lên production nếu mọi bước đều qua.

Pipeline cơ bản:

• Checkout, cài dependency (có cache).
• Lint, unit test, quét bảo mật (SAST, dependency, secret).
• Build artifact/image, gắn tag theo commit SHA, đẩy lên registry.
• Deploy lên staging, chạy smoke/integration test.
• Deploy production (thủ công hoặc tự động), có cách rollback.

Người phỏng vấn muốn nghe: build một lần, dùng cùng một artifact cho mọi môi trường; chỉ cấu hình là khác nhau.

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.

Pod là đơn vị chạy nhỏ nhất (một hoặc vài container dùng chung network); Deployment quản lý số bản sao Pod và việc cập nhật; Service cho một địa chỉ ổn định để gọi tới nhóm Pod.

• Pod có thể chết và được tạo lại với IP mới, nên không gọi trực tiếp IP Pod.
• Deployment tạo ReplicaSet, hỗ trợ rolling update và rollback.
• Service chọn Pod theo label (selector), kiểu ClusterIP (nội bộ), NodePort, LoadBalancer.
• Từ ngoài vào HTTP thường dùng Ingress hoặc Gateway API phía trước Service.

Hay sai: label của Pod template không khớp selector của Service, khiến Service không có endpoint nào.

Đâ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.