Top 25 Câu Hỏi Phỏng Vấn Data Engineering Năm 2026

Các câu hỏi phỏng vấn data engineering năm 2026 đã vượt xa phạm vi SQL cơ bản. Các đội tuyển dụng ngày nay chú trọng vào system design, kiến trúc real-time, tối ưu chi phí và khả năng sẵn sàng cho AI. Bài viết này tổng hợp 25 câu hỏi xuất hiện thường xuyên nhất trong các buổi phỏng vấn data engineer, từ startup đến FAANG, kèm câu trả lời dành cho người làm nghề thực thụ.

Câu Hỏi Về SQL và Tối Ưu Query

SQL vẫn là nền tảng của mọi buổi phỏng vấn data engineering. Ngay cả ứng viên senior cũng phải đối mặt với các câu hỏi SQL, nhưng chủ yếu xoay quanh hiệu năng chứ không phải cú pháp.

1. Sự khác biệt giữa window function và GROUP BY là gì?

GROUP BY gộp các hàng lại thành kết quả đã tổng hợp, làm giảm số lượng hàng. Window function tính toán giá trị trên một tập hàng liên quan đến hàng hiện tại mà không gộp chúng lại. Kết quả đầu ra giữ nguyên từng hàng gốc.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Phiên bản window function là thiết yếu khi query cần cả chi tiết từng hàng và ngữ cảnh tổng hợp cùng lúc, một yêu cầu phổ biến trong các pipeline kiểm tra chất lượng dữ liệu và báo cáo.

2. Làm thế nào để tối ưu một query chậm trên bảng fact có 500 triệu hàng?

Một cách tiếp cận có cấu trúc sẽ hiệu quả nhất:

1. Kiểm tra execution plan (EXPLAIN ANALYZE) để phát hiện full table scan, hash join trên các cột chưa được index, hoặc tràn ra đĩa.
2. Phân vùng bảng theo ngày hoặc một cột có độ phân tán cao phù hợp với các filter của query.
3. Thêm index mục tiêu trên các cột thường xuyên được filter, nhưng tránh index quá mức (mỗi index đều làm tăng chi phí ghi).
4. Vật chất hoá kết quả trung gian nếu cùng một subquery chạy lặp lại trên nhiều dashboard.
5. Đẩy predicate xuống để filter sớm, giảm lượng dữ liệu shuffle giữa các stage.

Tín hiệu chính mà người phỏng vấn tìm kiếm: hiểu rằng tối ưu là một quá trình lặp và phụ thuộc ngữ cảnh, chứ không phải một danh sách kiểm tra.

3. Giải thích CTE, subquery và temporary table. Khi nào nên dùng mỗi loại?

CTE (Common Table Expression) cải thiện khả năng đọc hiểu và cho phép query đệ quy. Hầu hết các query engine sẽ inline chúng, nên hiệu năng tương đương subquery. Temporary table vật chất hoá dữ liệu ở dạng vật lý, hữu ích khi cùng một kết quả trung gian được dùng cho nhiều query downstream trong một session. Subquery phù hợp cho các phép biến đổi đơn giản, một lần.

Quy tắc chung: CTE để rõ ràng, temp table để tái sử dụng, subquery cho các filter inline đơn giản.

Để tìm hiểu sâu hơn về các mẫu SQL nâng cao, hãy xem bài SQL for Data Analysts: Window Functions, CTEs and Advanced Queries.

ETL so với ELT và Kiến Trúc Data Pipeline

Các câu hỏi về thiết kế pipeline kiểm tra khả năng tư duy kiến trúc. Người phỏng vấn muốn thấy phân tích đánh đổi, chứ không phải việc bênh vực công cụ.

4. ETL hay ELT: khi nào chọn cái nào?

| Tiêu chí | ETL | ELT | |----------|-----|-----| | Vị trí biến đổi | Trước khi load (compute bên ngoài) | Sau khi load (compute trong warehouse) | | Phù hợp nhất cho | Hệ thống legacy, schema nghiêm ngặt | Cloud warehouse (BigQuery, Snowflake) | | Độ linh hoạt schema | Thấp (biến đổi khoá schema sớm) | Cao (dữ liệu thô sẵn có để biến đổi lại) | | Mô hình chi phí | Compute bên ngoài warehouse | Chi phí compute warehouse tăng theo biến đổi | | Độ tươi của dữ liệu | Độ trễ cao hơn (bước transform) | Độ trễ thấp hơn (load trước, transform theo yêu cầu) |

ELT chiếm ưu thế trong các stack cloud-native hiện đại vì storage rẻ, compute co giãn linh hoạt và việc giữ lại dữ liệu thô cho phép schema tiến hoá. ETL vẫn còn ý nghĩa khi các yêu cầu pháp lý bắt buộc biến đổi dữ liệu trước khi vào warehouse (ví dụ như che giấu PII).

5. Thiết kế một data pipeline idempotent. Tại sao tính idempotent lại quan trọng?

Tính idempotent đảm bảo rằng chạy pipeline nhiều lần với cùng một đầu vào sẽ tạo ra cùng một kết quả mà không nhân đôi dữ liệu. Điều này quan trọng vì pipeline có thể fail và được retry.

Các chiến lược triển khai:

• Mẫu upsert (MERGE hoặc INSERT ... ON CONFLICT) dựa trên khoá tự nhiên hoặc khoá composite
• Ghi đè partition: thay thế toàn bộ partition theo ngày thay vì append
• Deduplication khi ghi: gán ID xác định (hash của business key + event timestamp)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Cách tiếp cận này đảm bảo khi retry lần chạy ngày 11 tháng 4, nó sẽ thay thế partition ngày 11 tháng 4 chứ không thêm các hàng trùng lặp.

6. Data lineage là gì và tại sao nó quan trọng trong pipeline production?

Data lineage theo dõi nguồn gốc, sự di chuyển và biến đổi của dữ liệu xuyên suốt pipeline. Nó trả lời: con số này đến từ đâu, đã trải qua những biến đổi nào và các hệ thống downstream nào phụ thuộc vào nó.

Giá trị thực tế: khi một dashboard hiển thị giá trị bất thường, lineage cho phép phân tích nguyên nhân gốc rễ trong vài phút thay vì vài giờ. Các công cụ như OpenLineage, dbt docs, và lineage cloud-native (BigQuery column-level lineage) tự động hoá việc này.

Streaming và Xử Lý Dữ Liệu Real-Time

Các câu hỏi về streaming đã chuyển từ "Kafka là gì" sang những quyết định kiến trúc về khi nào và làm thế nào để sử dụng streaming.

7. Batch so với streaming: làm thế nào để quyết định dùng cái nào?

Quyết định phụ thuộc vào yêu cầu về độ trễ, không phải sở thích công nghệ:

• Batch: chấp nhận được khi người tiêu thụ dữ liệu có thể chịu được độ trễ từ vài phút đến vài giờ. Dễ xây dựng, kiểm thử và debug hơn. Chi phí vận hành thấp hơn cho hầu hết workload.
• Streaming: bắt buộc khi logic nghiệp vụ phụ thuộc vào độ tươi dưới một phút: phát hiện gian lận, định giá thời gian thực, dashboard live.
• Micro-batch: một trung gian thực dụng (ví dụ Spark Structured Streaming) cung cấp gần real-time với sự đơn giản của batch.

Câu trả lời mạnh nhất sẽ thừa nhận rằng hầu hết pipeline nên bắt đầu ở dạng batch và chỉ chuyển sang streaming khi có SLA độ trễ cụ thể yêu cầu điều đó.

8. Giải thích kiến trúc Kafka: topic, partition, consumer group

Kafka tổ chức dữ liệu thành các topic (kênh logic). Mỗi topic được chia thành các partition (log có thứ tự, bất biến) phân tán trên các broker. Producer ghi record vào partition (round-robin hoặc dựa trên khoá). Consumer group song song hoá việc đọc: mỗi partition được gán cho đúng một consumer trong một group, cho phép mở rộng theo chiều ngang.

Đánh đổi chính: nhiều partition hơn làm tăng tính song song nhưng cũng thêm chi phí cho broker (file handle, replication). Điểm khởi đầu thông thường là 6-12 partition cho mỗi topic, mở rộng theo yêu cầu throughput.

9. Làm thế nào để xử lý dữ liệu đến trễ trong một pipeline streaming?

Dữ liệu đến trễ là điều không tránh khỏi trong các hệ thống phân tán. Ba cách tiếp cận:

1. Watermark: định nghĩa một ngưỡng (ví dụ 10 phút) mà sau đó dữ liệu đến trễ sẽ bị bỏ qua. Apache Flink và Spark Structured Streaming hỗ trợ sẵn.
2. Reprocessing window: định kỳ chạy lại các phép tổng hợp cho các window thời gian gần đây để bắt các record trễ.
3. Delta/upsert sink: ghi vào một store có thể thay đổi (Delta Lake, Apache Iceberg) hỗ trợ update, cho phép các record trễ sửa lại kết quả trước đó.

Cách tiếp cận đúng phụ thuộc vào việc người tiêu thụ downstream có cần ngữ nghĩa exactly-once hay có thể chấp nhận tính nhất quán cuối.

Data Modeling và Thiết Kế Schema

Các câu hỏi về data modeling cho thấy ứng viên có suy nghĩ về cách dữ liệu sẽ được tiêu thụ hay không, chứ không chỉ là cách nó được lưu trữ.

10. Star schema so với snowflake schema: đánh đổi là gì?

Star schema denormalize các bảng dimension thành các bảng phẳng, rộng, được join với một bảng fact trung tâm. Snowflake schema normalize các dimension thành các sub-dimension.

| Khía cạnh | Star | Snowflake | |--------|------|-----------| | Hiệu năng query | Nhanh hơn (ít join hơn) | Chậm hơn (nhiều join hơn) | | Lưu trữ | Cao hơn (dữ liệu dư thừa) | Thấp hơn (chuẩn hoá) | | Độ phức tạp | Đơn giản để hiểu | Quan hệ phức tạp hơn | | Bảo trì | Khó update dimension hơn | Dễ update sub-dimension hơn | | Phù hợp nhất cho | BI/báo cáo (read-heavy) | Các tình huống cần chuẩn hoá nghiêm ngặt |

Trong thực tế, star schema chiếm ưu thế trong các analytics warehouse (BigQuery, Snowflake, Redshift) vì hiệu năng query và sự đơn giản vượt trội hơn việc tiết kiệm lưu trữ. Tìm hiểu thêm trong module phỏng vấn data modeling.

11. Slowly changing dimension (SCD) là gì? Giải thích Type 1, 2 và 3.

SCD theo dõi cách các thuộc tính dimension thay đổi theo thời gian:

• Type 1: Ghi đè giá trị cũ. Không có lịch sử. Đơn giản nhưng mất dữ liệu.
• Type 2: Thêm hàng mới với theo dõi phiên bản (valid_from, valid_to, is_current). Giữ toàn bộ lịch sử. Phổ biến nhất trong các warehouse production.
• Type 3: Thêm một cột cho giá trị trước đó (current_city, previous_city). Lịch sử hạn chế (chỉ theo dõi một lần thay đổi).

Type 2 là lựa chọn mặc định cho hầu hết các dimension nghiệp vụ (địa chỉ khách hàng, danh mục sản phẩm, phòng ban nhân viên) vì yêu cầu về dấu vết kiểm toán và báo cáo lịch sử.

12. Làm thế nào để model dữ liệu event cho cả real-time analytics và lưu trữ dài hạn?

Một cách tiếp cận hai tầng:

1. Hot layer: stream event vào một store real-time (Apache Druid, ClickHouse, hoặc Materialized View trong warehouse) được tối ưu cho các phép tổng hợp độ trễ thấp trên dữ liệu gần đây.
2. Cold layer: đưa event thô vào một lakehouse (Delta Lake, Iceberg) phân vùng theo ngày, lưu giữ không giới hạn cho phân tích ad-hoc và feature engineering cho ML.

Hot layer sử dụng schema đã tổng hợp trước hoặc denormalize để đạt tốc độ. Cold layer giữ toàn bộ độ chi tiết. Một job đối soát định kỳ xác nhận rằng cả hai tầng đều khớp.

Apache Spark và Xử Lý Phân Tán

Các câu hỏi về Spark tập trung vào việc hiểu về tính song song và hiệu năng, không chỉ là các lời gọi API.

13. Điều gì gây ra data skew trong Spark, và làm thế nào để khắc phục?

Data skew xảy ra khi một partition chứa dữ liệu không cân xứng so với các partition khác, khiến một task duy nhất trở thành bottleneck cho toàn bộ stage.

Nguyên nhân phổ biến: join trên một khoá có vài giá trị chiếm ưu thế (khoá null, một product ID phổ biến duy nhất), hoặc phân vùng theo một cột có độ phân tán thấp.

Cách khắc phục:

• Salting: thêm hậu tố ngẫu nhiên vào khoá bị skew, join trên khoá đã salt, sau đó tổng hợp để loại bỏ salt.
• Broadcast join: nếu một bên đủ nhỏ (thường <200MB), broadcast nó để tránh shuffle hoàn toàn.
• AQE (Adaptive Query Execution): Spark 3.x+ có thể tự động phát hiện và chia các partition bị skew tại runtime.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Cách này phân phối khối lượng công việc đồng đều giữa các executor, loại bỏ bottleneck.

14. Giải thích sự khác biệt giữa transformation và action trong Spark.

Transformation (map, filter, select, join) là lazy: chúng xây dựng một kế hoạch logic nhưng không thực thi gì cả. Action (count, collect, write) kích hoạt việc tính toán thực sự bằng cách gửi kế hoạch đến cluster.

Việc đánh giá lazy này cho phép Catalyst optimizer của Spark sắp xếp lại các thao tác, đẩy predicate xuống, và loại bỏ các shuffle không cần thiết trước khi bất kỳ dữ liệu nào di chuyển. Hiểu được sự phân biệt này là thiết yếu cho việc debug: một transformation có vẻ chậm thực ra vẫn ổn; bottleneck nằm ở action kích hoạt nó.

15. Sự khác biệt giữa repartition() và coalesce() là gì?

repartition(n) thực hiện một shuffle đầy đủ để tạo ra chính xác n partition, phân phối dữ liệu đồng đều. Dùng nó để tăng tính song song hoặc cân bằng lại các partition bị skew.

coalesce(n) giảm số lượng partition mà không shuffle bằng cách gộp các partition liền kề. Dùng nó để giảm số partition trước khi ghi (tránh nhiều file nhỏ).

Quy tắc: coalesce để giảm, repartition để tăng hoặc cân bằng lại.

Orchestration và Quản Lý Pipeline

Các câu hỏi về orchestration kiểm tra độ trưởng thành vận hành: pipeline chạy, fail và phục hồi như thế nào trong production.

16. So sánh Airflow, Dagster và Prefect. Khi nào nên chọn cái nào?

| Tính năng | Airflow | Dagster | Prefect | |---------|---------|---------|--------| | Độ trưởng thành | Trưởng thành nhất, cộng đồng lớn nhất | Đang phát triển, mạnh ở đội ML/data | Cloud-first, DX mạnh | | Abstraction cốt lõi | DAG của task | Asset (dữ liệu làm trung tâm) | Flow và task | | Kiểm thử | Khó hơn (cấp DAG) | Kiểm thử asset tích hợp sẵn | Kiểm thử task tốt | | Dev cục bộ | Cần Docker/container | Thực thi local native | Thực thi local native | | Phù hợp nhất cho | ETL phức tạp, chạy lâu | Data mesh / đội định hướng asset | Đội muốn ít hạ tầng |

Airflow vẫn là tiêu chuẩn ngành cho các data platform trưởng thành. Dagster phù hợp với đội tư duy theo data asset thay vì chuỗi task. Prefect hấp dẫn các đội muốn orchestration kiểu Airflow với ít chi phí vận hành hơn. Để chuẩn bị phỏng vấn chuyên về Airflow, xem module Airflow fundamentals.

17. Làm thế nào để xử lý lỗi pipeline và alerting trong production?

Một chiến lược xử lý lỗi cấp production bao gồm:

1. Retry với backoff: các lỗi tạm thời (timeout mạng, giới hạn API rate) sẽ được giải quyết bằng retry theo cấp số nhân.
2. Dead-letter queue: các message độc hại được định tuyến sang một queue riêng để kiểm tra thủ công mà không chặn pipeline.
3. Circuit breaker: sau N lần fail liên tiếp, tạm dừng pipeline và cảnh báo thay vì làm ngập các hệ thống downstream bằng dữ liệu xấu.
4. Observability: log có cấu trúc, metric (thời gian task, số lượng hàng, tỉ lệ lỗi), và kiểm tra chất lượng dữ liệu (Great Expectations, dbt test) ở mỗi giai đoạn pipeline.
5. Các cấp cảnh báo: P1 (pipeline hỏng, dữ liệu thiếu) gọi on-call. P2 (chất lượng dữ liệu trôi) gửi thông báo Slack cho ngày làm việc tiếp theo.

18. Điều gì làm cho một pipeline "sẵn sàng production" so với một prototype?

Sự sẵn sàng production có nghĩa là: chạy idempotent, retry tự động, giám sát và cảnh báo, xác thực dữ liệu ở giai đoạn ingestion và transformation, tài liệu về data contract, định nghĩa pipeline được quản lý phiên bản, và một đường rollback đã được kiểm thử. Một prototype không có những thứ này. Khoảng cách giữa hai cái này là nơi phần lớn nợ kỹ thuật pipeline tích luỹ.

Cloud Data Platform và Kiến Trúc Lakehouse

Các câu hỏi về cloud platform đánh giá xem ứng viên có hiểu về chi phí, quy mô và đánh đổi kiến trúc vượt ra ngoài cú pháp của từng nhà cung cấp hay không.

19. Lakehouse là gì, và tại sao nó đã trở thành kiến trúc chiếm ưu thế?

Một lakehouse kết hợp sự linh hoạt của data lake (schema-on-read, lưu trữ dữ liệu thô, nhiều định dạng file) với độ tin cậy của data warehouse (giao dịch ACID, thực thi schema, tối ưu query). Các công nghệ như Delta Lake, Apache Iceberg và Apache Hudi làm được điều này bằng cách thêm một lớp metadata/transaction lên trên object storage (S3, GCS, ADLS).

Lakehouse thắng thế vì nó loại bỏ lớp ETL tốn kém giữa lake và warehouse, hỗ trợ cả query BI và workload ML trên cùng một dữ liệu, và tận dụng object storage giá rẻ.

20. Làm thế nào để tối ưu chi phí cloud warehouse (BigQuery, Snowflake, Redshift)?

Các chiến lược tối ưu chi phí:

• Phân vùng và cluster bảng để giảm số byte được scan mỗi query
• Đặt kích thước warehouse phù hợp (Snowflake) hoặc slot reservation (BigQuery) dựa trên pattern workload
• Auto-suspend tài nguyên không sử dụng: Snowflake warehouse nên auto-suspend sau 1-5 phút không hoạt động
• Giám sát chi phí mỗi query: view INFORMATION_SCHEMA.JOBS của BigQuery tiết lộ các query đắt đỏ
• Sử dụng materialized view cho các phép tổng hợp được tính lặp đi lặp lại
• Lưu trữ dữ liệu lạnh trên các tầng lưu trữ rẻ hơn với chính sách lifecycle

Tín hiệu phỏng vấn: ứng viên coi chi phí như một ràng buộc kỹ thuật hàng đầu, không phải một suy nghĩ sau cùng.

Data Quality và Governance

Các câu hỏi về chất lượng dữ liệu phân biệt các engineer ship pipeline với những người duy trì các data platform đáng tin cậy.

21. Làm thế nào để triển khai kiểm tra chất lượng dữ liệu trong một pipeline?

Các kiểm tra chất lượng dữ liệu thuộc về ba giai đoạn:

1. Ingestion: xác thực sự phù hợp schema, kiểm tra khoá chính null, xác minh ngưỡng số lượng hàng so với nguồn.
2. Transformation: khẳng định các quy tắc nghiệp vụ (ví dụ doanh thu > 0, ngày tháng trong khoảng hợp lệ), kiểm tra tính toàn vẹn tham chiếu giữa các bảng.
3. Serving: giám sát sự trôi của metric (sự sụt giảm 50% đột ngột số lượng người dùng hàng ngày có khả năng chỉ ra một vấn đề pipeline, không phải thay đổi nghiệp vụ).

Công cụ: dbt test (schema và custom), Great Expectations, Soda Core, Monte Carlo (data observability). Cách tốt nhất là tích hợp các kiểm tra trực tiếp vào DAG pipeline sao cho các lỗi chặn việc xử lý downstream.

22. Data contract là gì, và nó ngăn chặn việc pipeline bị hỏng như thế nào?

Một data contract là một thoả thuận chính thức giữa một producer dữ liệu và những người tiêu thụ của nó, xác định: schema (tên cột, kiểu, khả năng null), SLA về độ tươi (dữ liệu có sẵn trước 6 giờ sáng UTC), kỳ vọng về khối lượng (từ 1 triệu đến 10 triệu hàng mỗi ngày), và các quy tắc ngữ nghĩa (trường status chỉ chứa ACTIVE, INACTIVE, SUSPENDED).

Khi producer thay đổi schema mà không cập nhật contract, việc xác thực tự động sẽ bắt được sự không khớp trước khi nó lan truyền xuống downstream. Điều này chuyển các lỗi pipeline từ hỏng dữ liệu âm thầm sang các lỗi rõ ràng, có thể hành động.

System Design và Kiến Trúc

Các vòng system design là tiêu chuẩn cho các vai trò data engineering mid đến senior. Chúng kiểm tra tư duy end-to-end.

23. Thiết kế một pipeline analytics real-time cho một nền tảng thương mại điện tử.

Một thiết kế vững chắc sẽ đề cập đến:

Ingestion: các event clickstream và event giao dịch chảy vào các topic Kafka, phân vùng theo user_id để đảm bảo thứ tự trong một phiên người dùng.

Processing: một job Flink hoặc Spark Structured Streaming tiêu thụ từ Kafka, làm giàu event với dữ liệu catalog sản phẩm (broadcast join từ bảng dimension), tính toán các phép tổng hợp ở cấp phiên và 5 phút.

Serving: các metric đã tổng hợp được đưa vào một store OLAP real-time (ClickHouse hoặc Apache Druid) cho các query dashboard với độ trễ dưới một giây. Event thô được đưa vào Delta Lake/Iceberg để phân tích lịch sử.

Chất lượng dữ liệu: schema registry (Confluent hoặc AWS Glue) xác thực schema event tại ingestion. Các kiểm tra chất lượng dữ liệu streaming đánh dấu các bất thường (sụt giảm đột ngột về khối lượng event) và định tuyến đến một topic dead-letter.

Xử lý lỗi: offset consumer của Kafka cho phép xử lý exactly-once với checkpointing. Job streaming tự động khởi động lại từ checkpoint cuối cùng khi fail.

24. Bạn sẽ di chuyển một pipeline ETL legacy sang một stack hiện đại như thế nào?

Việc di chuyển tuân theo pattern strangler fig:

1. Kiểm toán: lập danh mục tất cả pipeline hiện có, nguồn của chúng, các phép biến đổi và người tiêu thụ. Xác định các phụ thuộc và SLA.
2. Chạy song song: xây dựng pipeline mới bên cạnh pipeline cũ. Cả hai tiêu thụ cùng nguồn và ghi vào các target riêng biệt.
3. Xác thực: so sánh đầu ra giữa pipeline cũ và mới. Các query đối soát tự động đánh dấu các khác biệt.
4. Cutover: khi đầu ra khớp trong phạm vi dung sai trong hơn 2 tuần, chuyển người tiêu thụ sang target mới. Giữ pipeline cũ ở chế độ chỉ đọc để rollback.
5. Decommission: sau một giai đoạn ổn định, tắt pipeline legacy.

Điểm chính: không bao giờ làm một cuộc di chuyển big-bang. Chạy cả hai hệ thống song song cho đến khi có đủ độ tin cậy.

25. Một dashboard quan trọng hiển thị số liệu không chính xác. Hãy đi qua quy trình debug của bạn.

Một cách tiếp cận có hệ thống:

1. Xác định phạm vi vấn đề: metric nào bị sai? Từ khi nào? Tất cả các dimension hay filter cụ thể?
2. Kiểm tra lớp serving: query trực tiếp warehouse để xác nhận liệu vấn đề nằm ở công cụ dashboard (caching, logic filter) hay ở chính dữ liệu.
3. Truy vết lineage ngược dòng: theo dõi dữ liệu từ bảng dashboard ngược qua từng bước transformation. Kiểm tra số lượng hàng và các metric chính ở mỗi giai đoạn.
4. Xác định điểm hỏng: giai đoạn mà các giá trị kỳ vọng khác với các giá trị thực tế là vị trí nguyên nhân gốc rễ.
5. Kiểm tra các thủ phạm phổ biến: thay đổi schema trong các hệ thống nguồn, các lần chạy pipeline fail mà không được cảnh báo, dữ liệu đến trễ bỏ lỡ window xử lý, hoặc một lần deployment thay đổi logic transformation.
6. Sửa và phòng ngừa: vá lỗi ngay lập tức, thêm một kiểm tra chất lượng dữ liệu có thể bắt được nó, và cập nhật runbook.

Câu hỏi này kiểm tra độ trưởng thành trong phản ứng sự cố. Người phỏng vấn muốn thấy tư duy có cấu trúc, không phải đoán mò ngẫu nhiên.

Chuẩn Bị Cho Phỏng Vấn Data Engineering

Track chuẩn bị phỏng vấn data engineering trên SharpSkill bao gồm các chủ đề này với luyện tập tương tác trên các mẫu ETL/ELT, data modeling, Airflow, BigQuery và nhiều hơn nữa.

Kết Luận

• SQL window function, CTE và tối ưu query vẫn là nền tảng bất kể cấp độ
• Quyết định ETL so với ELT nên được dẫn dắt bởi yêu cầu độ trễ, nhu cầu governance dữ liệu và chi phí hạ tầng thay vì chạy theo xu hướng
• Idempotency, data contract và kiểm tra chất lượng dữ liệu phân biệt pipeline cấp production với prototype
• Các câu hỏi về kiến trúc streaming tập trung vào đánh đổi (batch, streaming, micro-batch) thay vì kiến thức cụ thể về công cụ
• Các lựa chọn data modeling (star so với snowflake, các loại SCD) nên phù hợp với pattern tiêu thụ, không phải lý thuyết best practice
• Câu trả lời system design nên đề cập đến xử lý lỗi, tối ưu chi phí và observability cùng với đường đi hạnh phúc
• Ứng viên mạnh nhất thể hiện khả năng giải quyết vấn đề có cấu trúc và lập luận trung thực về các đánh đổi