26 câu hỏi phỏng vấn dbt hàng đầu và đáp án cho năm 2026

Câu hỏi phỏng vấn dbt mức trung cấp 

Sau khi đã qua phần cơ bản, dưới đây là một số câu hỏi dbt mức trung cấp, tập trung vào các khía cạnh và khái niệm kỹ thuật cụ thể.

Nguồn (sources) trong dbt là gì? 

Trong dbt, sources là các bảng dữ liệu thô. Ta không viết truy vấn SQL trực tiếp trên các bảng thô này — mà chỉ định schema và tên bảng rồi định nghĩa chúng là nguồn. Cách này giúp tham chiếu đối tượng dữ liệu trong bảng dễ hơn.  

Giả sử bạn có bảng dữ liệu thô tên orders trong schema sales. Thay vì truy vấn trực tiếp, bạn sẽ định nghĩa nó là nguồn trong dbt như sau:

Định nghĩa source trong tệp sources.yml:

version: 2

sources:
  - name: sales
    tables:
      - name: orders

Dùng source trong các model dbt:

Khi đã định nghĩa, bạn có thể tham chiếu bảng thô orders trong các phép biến đổi như sau:

SELECT *
FROM {{ source('sales', 'orders') }}

Cách tiếp cận này trừu tượng hóa định nghĩa bảng thô, giúp quản lý dễ hơn và nếu cấu trúc bảng bên dưới thay đổi, bạn chỉ cần cập nhật một nơi (định nghĩa source) thay vì mọi truy vấn.

Lợi ích khi dùng sources trong dbt:

• Tổ chức: Sources giúp tổ chức dữ liệu thô và dễ quản lý trong dự án.
• Trừu tượng hóa: Bạn trừu tượng chi tiết schema, giảm lỗi và tăng tính linh hoạt.
• Tài liệu hóa: Định nghĩa sources giúp tạo tài liệu tốt hơn cho đầu vào dữ liệu thô.

Model trong dbt là gì?

Một model dbt về cơ bản là một tệp SQL hoặc Python định nghĩa logic biến đổi cho dữ liệu thô. Trong dbt, model là thành phần lõi nơi bạn viết các phép biến đổi, dù là tổng hợp, join hay bất kỳ thao tác xử lý dữ liệu nào.

• Model SQL trong dbt dùng các câu lệnh SELECT để định nghĩa biến đổi và được lưu dưới dạng tệp .sql.
• Model Python, được giới thiệu cùng hỗ trợ Python của dbt, được lưu dưới dạng tệp .py và cho phép bạn dùng các thư viện như pandas để xử lý dữ liệu.

Ví dụ model SQL:

Một model SQL biến đổi dữ liệu thô bằng truy vấn SQL. Ví dụ, để tạo bản tóm tắt đơn hàng từ bảng orders:

--orders_summary.sql
WITH orders_cte AS (
    SELECT
        customer_id,
        COUNT(order_id) AS total_orders,
        SUM(order_amount) AS total_revenue
    FROM {{ ref('orders') }}
    GROUP BY customer_id
)

SELECT *
FROM orders_cte

Trong ví dụ này:

• Model orders_summary.sql tạo tóm tắt tổng số đơn hàng và doanh thu cho mỗi khách hàng bằng SQL.
• Model tham chiếu bảng orders (đã được định nghĩa là model hoặc source trong dbt).

Ví dụ model Python:

Một model Python xử lý dữ liệu thô bằng mã Python. Đặc biệt hữu ích cho logic phức tạp mà viết bằng SQL sẽ cồng kềnh.

# orders_summary.py
import pandas as pd

def model(dbt, session):
    # Load the source data
    orders = dbt.ref("orders").to_pandas()

    # Perform transformations using pandas
    orders_summary = orders.groupby('customer_id').agg(
        total_orders=('order_id', 'count'),
        total_revenue=('order_amount', 'sum')
    ).reset_index()

    return orders_summary

Trong ví dụ này:

• Model Python dùng pandas để nhóm đơn hàng theo khách hàng và tính tổng số đơn cùng doanh thu.
• Kết quả được trả về dạng DataFrame, dbt có thể tích hợp vào pipeline của mình.

Bạn sẽ tạo một model dbt như thế nào? 

Cách tạo một model dbt: 

• Tạo một thư mục bên trong thư mục models của dự án dbt. 
• Thêm một tệp văn bản mới với phần mở rộng .sql trong thư mục (hoặc .py nếu là model Python).
• Viết truy vấn SQL hoặc mã để biến đổi dữ liệu thô. 
• Chạy lệnh dbt run để áp dụng biến đổi và tạo model.

dbt xử lý phụ thuộc giữa các model như thế nào?

dbt quản lý phụ thuộc model bằng hàm ref(), tạo chuỗi phụ thuộc rõ ràng giữa các model. 

Khi định nghĩa một phép biến đổi trong dbt, thay vì tham chiếu trực tiếp các bảng trong kho dữ liệu, bạn tham chiếu các model dbt khác bằng hàm ref(). Điều này đảm bảo dbt xây các model theo đúng thứ tự, dựa trên phụ thuộc.

Ví dụ, nếu bạn có model orders_summary phụ thuộc vào model orders, bạn sẽ định nghĩa như sau:

WITH orders AS (
    SELECT * FROM {{ ref('orders') }}
)
SELECT
    customer_id,
    COUNT(order_id) AS total_orders,
    SUM(order_amount) AS total_revenue
FROM orders
GROUP BY customer_id

Trong ví dụ này, hàm {{ ref('orders') }} đảm bảo model orders được xây trước orders_summary, vì orders_summary phụ thuộc vào dữ liệu trong orders .

Macro trong dbt là gì và chạy chúng như thế nào? 

Macro trong dbt là các khối mã SQL có thể tái sử dụng, được viết bằng Jinja templating. Chúng cho phép bạn tự động hóa tác vụ lặp lại, trừu tượng hóa logic phức tạp, và tái sử dụng mã SQL trên nhiều model, giúp dự án dbt hiệu quả và dễ bảo trì hơn. 

Macro có thể được định nghĩa trong các tệp .sql nằm trong thư mục macros của dự án dbt.

Macro đặc biệt hữu ích khi bạn cần thực hiện các biến đổi tương tự trên nhiều model hoặc cần logic phụ thuộc môi trường, như dùng schema khác nhau hay thay đổi định dạng ngày theo môi trường triển khai (ví dụ: development, staging, production).

Ví dụ tạo macro:

• Macro định dạng ngày: Bạn có thể tạo macro để chuẩn hóa định dạng ngày trên các model. Thay vì lặp lại logic định dạng, tạo macro như sau:

-- macros/date_format.sql
{% macro format_date(column) %}
FORMAT_TIMESTAMP('%Y-%m-%d', {{ column }})
{% endmacro %}

Cách dùng trong model:

SELECT
    customer_id,
    {{ format_date('order_date') }} AS formatted_order_date
FROM {{ ref('orders') }}

Trong ví dụ này, macro format_date được dùng để chuẩn hóa định dạng cột order_date trong bất kỳ model nào gọi nó.

• Macro tên schema tùy chỉnh: Macro này thay đổi tên schema động theo môi trường (ví dụ: development hoặc production). Giúp quản lý môi trường mà không cần đổi thủ công tên schema.

-- macros/custom_schema.sql
{% macro custom_schema_name() %}
{% if target.name == 'prod' %}
'production_schema'
{% else %}
'dev_schema'
{% endif %}
{% endmacro %}

Cách dùng trong model:

SELECT *
FROM {{ custom_schema_name() }}.orders

Ở đây, macro kiểm tra nếu môi trường (target.name) là "prod" và trả về tên schema phù hợp.

Cách chạy macro:

Macro không chạy trực tiếp như model SQL. Thay vào đó, chúng được tham chiếu trong model hoặc macro khác và sẽ được thực thi khi dự án dbt chạy. Ví dụ, nếu bạn dùng macro trong một model, macro sẽ chạy khi bạn thực hiện lệnh dbt run.

• Gọi macro trong model: Khi bạn chèn macro vào model SQL, macro được thực thi trong lúc model chạy.
• Chạy macro thủ công: Bạn cũng có thể chạy một số macro thủ công bằng lệnh dbt run-operation. Thường dùng cho tác vụ đơn lẻ như seed dữ liệu hoặc bảo trì.

Hai loại kiểm thử trong dbt là gì? 

Singular test và generic test là hai loại kiểm thử trong dbt: 

• Singular test tập trung vào điều kiện cụ thể trong một model dbt. Nếu điều kiện kiểm thử thất bại, nó sẽ trả về các dòng vi phạm.

Ví dụ: Giả sử bạn muốn đảm bảo không có đơn hàng nào có order_amount âm. Bạn có thể viết singular test trong thư mục tests như sau:

-- tests/no_negative_order_amount.sql
SELECT *
FROM {{ ref('orders') }}
WHERE order_amount < 0

Nếu kiểm thử này thất bại, dbt sẽ trả về tất cả các dòng trong bảng orders nơi order_amount là âm.

• Generic test là kiểm thử dựng sẵn nhận tham số. Chúng được chia tiếp thành các loại sau: 

Ví dụ: Bạn có thể áp dụng generic test để đảm bảo customer_id trong bảng customers là duy nhất và không rỗng bằng cách định nghĩa trong tệp schema.yml:

version: 2

models:
  - name: customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

Trong ví dụ này:

• Kiểm thử unique đảm bảo mỗi customer_id trong bảng customers là duy nhất.
• Kiểm thử not_null đảm bảo không có giá trị customer_id bị thiếu hoặc null.

Câu hỏi phỏng vấn dbt nâng cao 

Khi tiến xa hơn, bạn có thể gặp các tình huống phức tạp và khái niệm nâng cao. Dưới đây là một số câu hỏi thử thách để đánh giá chuyên môn và chuẩn bị cho vị trí kỹ sư dữ liệu cấp cao.

Bạn tạo incremental model trong dbt như thế nào và khi nào nên dùng?

Incremental model trong dbt được dùng để chỉ xử lý dữ liệu mới hoặc đã thay đổi thay vì xử lý lại toàn bộ tập dữ liệu mỗi lần chạy. Điều này đặc biệt hữu ích với bộ dữ liệu lớn, nơi việc dựng lại model từ đầu sẽ tốn thời gian và tài nguyên.

Incremental model cho phép dbt chỉ bổ sung dữ liệu mới (hoặc cập nhật dữ liệu thay đổi) dựa trên điều kiện, thường là cột timestamp (như updated_at).

Cách tạo incremental model:

1. Định nghĩa model là incremental trong phần config của model:

{{ config(
    materialized='incremental',
    unique_key='id'  -- hoặc một cột duy nhất khác
) }}

2. Dùng hàm is_incremental() để lọc các dòng mới hoặc thay đổi:

SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

3. Khi dbt chạy model lần đầu, nó sẽ xử lý toàn bộ dữ liệu. Các lần sau, nó chỉ xử lý những dòng có updated_at lớn hơn giá trị mới nhất đã có trong model.

Khi nào dùng incremental model:

• Bộ dữ liệu lớn: Khi có bảng hàng triệu hoặc hàng tỷ dòng, dựng lại toàn bộ mỗi lần chạy là không hiệu quả.
• Cập nhật thường xuyên: Nếu kho dữ liệu thường xuyên nhận dữ liệu mới nhưng không cần xử lý lại toàn bộ, incremental model giúp giảm thời gian xử lý đáng kể.
• Dữ liệu streaming: Khi dữ liệu được stream hoặc cập nhật thường xuyên, incremental model giúp cập nhật biến đổi mà không cần chạy lại tất cả.

Bạn dùng Jinja để cải thiện SQL như thế nào?

Jinja giúp SQL linh hoạt hơn. Với Jinja, ta có thể định nghĩa mẫu tái sử dụng cho các mẫu SQL thường gặp. Và khi yêu cầu thay đổi, ta dùng câu lệnh if của Jinja để điều chỉnh truy vấn theo điều kiện. Làm vậy thường giúp chia nhỏ logic phức tạp, dễ hiểu hơn. 

Ví dụ, nếu bạn muốn chuyển định dạng ngày từ "YYYY-MM-DD" sang "MM/DD/YYYY", đây là một macro dbt mẫu, chúng ta đã thấy ở câu trước:

{% macro change_date_format(column_name) %}

  to_char({{ column_name }}::date, 'MM/DD/YYYY')

{% endmacro %}

Trong ví dụ, {{ column_name }} là nơi Jinja chèn tên cột thực tế khi bạn dùng macro. Nó sẽ được thay thế bằng tên cột khi chạy. Như đã thấy, Jinja dùng {{ }} để hiển thị nơi diễn ra thao tác thay thế.

Bạn sẽ tạo materialization tùy chỉnh trong dbt như thế nào? 

Cách tạo materialization tùy chỉnh trong dbt: 

• Tạo tệp SQL cho materialization tùy chỉnh. 
• Tiếp theo, định nghĩa macro materialization là materialization_name: 

{% materialization materialization_name, default -%}

• Dùng macro dựng sẵn của dbt adapter.get_relation để thiết lập bảng đích. Đây là nơi dữ liệu sẽ được nạp. 
• Tiếp đó, định nghĩa và thực thi các lệnh SQL để tạo và nạp dữ liệu vào bảng: 

{% set sql %}
    SELECT * FROM {{ ref('your_source_table') }}
    WHERE your_conditions = true
{% endset %}
{{ adapter.execute(sql) }}

• Cuối cùng, trả về quan hệ đích để cập nhật bộ nhớ đệm của dbt và tối ưu việc thực thi truy vấn. 

{{ return(target_relation) }}
{% endmaterialization %}

Bạn có thể debug các model dbt như thế nào? Hãy nêu hai cách. 

Dưới đây là hai cách để debug model dbt: 

1. Truy cập các tệp SQL đã biên dịch trong thư mục target để xác định và lần vết lỗi.

Khi bạn chạy dự án dbt, dbt biên dịch model (viết bằng Jinja) thành truy vấn SQL thuần và lưu trong thư mục target. Đây chính là SQL được chạy trên nền tảng dữ liệu, nên xem các tệp này giúp bạn xác định vấn đề ở đâu:

• Chạy các model dbt (ví dụ, dbt run hoặc dbt test).
• Đi tới thư mục target/compiled/ trong dự án dbt.
• Mở tệp SQL đã biên dịch của model cần debug. Tệp này chứa SQL thuần dbt đã thực thi, gồm mọi biến đổi từ macro Jinja và các tham chiếu.
• Sao chép truy vấn SQL đã biên dịch và chạy trực tiếp trên trình soạn thảo SQL của nền tảng dữ liệu (ví dụ: Postgres, BigQuery) để nhận thông báo lỗi chi tiết hoặc quan sát hành vi thực tế.

2. Dùng dbt Power User Extension cho VS Code để xem kết quả truy vấn trực tiếp.

Tiện ích dbt Power User cho Visual Studio Code (VS Code) là công cụ hữu ích để debug model dbt. Tiện ích cho phép bạn xem và thử nghiệm truy vấn ngay trong IDE, giảm nhu cầu chuyển qua lại giữa dbt, terminal và cơ sở dữ liệu.

dbt biên dịch truy vấn như thế nào? 

dbt biên dịch truy vấn qua các bước sau:

1. Phân tích cú pháp: dbt đọc tất cả các tệp SQL, cấu hình YAML, và macro trong dự án.
2. Tạo ngữ cảnh: Xây ngữ cảnh cho mỗi model, gồm cấu hình và macro khả dụng.
3. Render Jinja: Xử lý tệp SQL như template Jinja để thay thế thẻ và biểu thức bằng kết quả đã đánh giá.
4. Biên dịch SQL: Sinh truy vấn SQL thuần cho từng model.
5. Tạo artifact: SQL đã biên dịch được lưu trong thư mục target/compiled.
6. Chuẩn bị thực thi: Với dbt run, truy vấn được chuẩn bị để thực thi, có thể với phần bao bọc bổ sung.

Quy trình này chuyển SQL mô-đun, có template thành các truy vấn thực thi cụ thể cho kho dữ liệu của bạn. Ta có thể dùng dbt compile hoặc xem thư mục target/compiled để xem và debug SQL cuối cùng cho từng model.

Câu hỏi phỏng vấn dbt về kho dữ liệu và tích hợp

Công việc của hầu hết kỹ sư dữ liệu xoay quanh xây dựng và tích hợp kho dữ liệu với dbt. Các câu hỏi liên quan đến kịch bản này rất phổ biến trong phỏng vấn — vì vậy tôi đã tổng hợp những câu thường gặp nhất: 

Hãy giải thích ba lợi ích khi tích hợp dbt với Airflow. 

Tích hợp dbt với Airflow giúp xây dựng pipeline dữ liệu trơn tru. Một vài lợi ích gồm: 

• Quy trình ETL: Airflow quản lý việc trích xuất và nạp dữ liệu, đảm bảo dbt tập trung vào bước chuyển đổi, tạo nên luồng công việc mạch lạc.
• Tự động hóa tác vụ dbt: Airflow tự động hóa lập lịch và thực thi các model dbt, giảm thao tác thủ công và cải thiện hiệu quả biến đổi dữ liệu.
• Chạy song song: Airflow cho phép chạy tác vụ song song, xử lý bộ dữ liệu lớn mà không ảnh hưởng hiệu năng, giúp duy trì pipeline nhanh và ổn định. 

Kiến trúc lớp ngữ nghĩa (semantic layer) của dbt là gì? 

Lớp ngữ nghĩa của dbt cho phép ta chuyển dữ liệu thô thành ngôn ngữ nghiệp vụ dễ hiểu. Ta có thể định nghĩa metric và truy vấn chúng bằng giao diện dòng lệnh (CLI). 

Điều này giúp tối ưu chi phí vì thời gian chuẩn bị dữ liệu giảm. Ngoài ra, mọi người làm việc với cùng định nghĩa dữ liệu, giúp metric nhất quán trong toàn tổ chức. 

dbt và lớp ngữ nghĩa. Nguồn ảnh: dbt

Nếu đang dùng BigQuery, dbt có phải là một lớp biến đổi không cần thiết? 

Dù BigQuery rất hữu ích và xử lý được nhiều biến đổi gốc, dbt vẫn cần thiết. Lý do:

• dbt cho phép quản lý phiên bản biến đổi, điều mà BigQuery không hỗ trợ nguyên bản.
• dbt cung cấp khung kiểm thử tích hợp và sinh tài liệu, nâng cao chất lượng và khả năng hiểu dữ liệu.
• Hàm ref() và macro của dbt giúp SQL mô-đun và tái sử dụng hơn.
• dbt giúp quản lý nhiều môi trường (dev, test, prod) trong BigQuery dễ dàng.
• dbt cung cấp cách thức nhất quán để quản lý phụ thuộc giữa các biến đổi.

dbt có cung cấp bảo mật dữ liệu không? 

dbt có hai phiên bản: dbt Core và dbt Cloud như đã nêu. dbt Core là mã nguồn mở và miễn phí, vì vậy không cung cấp tính năng bảo mật tích hợp; người dùng chịu trách nhiệm triển khai và bảo mật.

Trong khi đó, dbt Cloud được thiết kế để cung cấp bảo mật đầy đủ. Nó tuân thủ HIPAA và các chuẩn thông dụng khác để bảo đảm quyền riêng tư. Tùy nhu cầu, ta chọn phiên bản dbt phù hợp với yêu cầu tuân thủ của doanh nghiệp.

Bạn tối ưu hiệu năng biến đổi dbt trên bộ dữ liệu lớn như thế nào?

Tối ưu biến đổi dbt cho bộ dữ liệu lớn là điều quan trọng để cải thiện hiệu năng và giảm chi phí, đặc biệt khi làm việc với kho dữ liệu đám mây như Snowflake, BigQuery hoặc Redshift. Dưới đây là các kỹ thuật chính:

1. Dùng incremental model

Incremental model cho phép dbt chỉ xử lý dữ liệu mới/cập nhật thay vì xử lý lại toàn bộ mỗi lần. Điều này cắt giảm đáng kể thời gian chạy cho bộ dữ liệu lớn. Nó giới hạn lượng dữ liệu cần xử lý, tăng tốc biến đổi.

2. Tận dụng partitioning và clustering (cho các CSDL như Snowflake và BigQuery)

Partitioning và clustering các bảng lớn giúp cải thiện hiệu năng truy vấn bằng cách tổ chức dữ liệu hợp lý và giảm lượng dữ liệu bị quét.

Partitioning đảm bảo chỉ phân vùng liên quan được truy vấn, còn clustering tối ưu bố cục vật lý dữ liệu để truy xuất nhanh hơn.

3. Tối ưu materialization (table, view, incremental)

Chọn materialization phù hợp để tối ưu hiệu năng:

• View phù hợp cho biến đổi nhẹ, không lý tưởng cho tải nặng.
• Table lưu dữ liệu vật lý, cải thiện hiệu năng nhưng tốn lưu trữ.
• Incremental phù hợp nhất cho bộ dữ liệu lớn cập nhật thường xuyên.

4. Dùng LIMIT trong quá trình phát triển

Khi phát triển, thêm mệnh đề LIMIT để giới hạn số dòng xử lý. Việc này tăng tốc vòng lặp phát triển và tránh làm việc với dữ liệu khổng lồ khi thử nghiệm.

5. Chạy truy vấn song song

Tận dụng khả năng chạy song song của kho dữ liệu. Ví dụ, dbt Cloud hỗ trợ parallelism có thể điều chỉnh theo hạ tầng.

6. Dùng tính năng tối ưu đặc thù của CSDL

Nhiều kho dữ liệu đám mây cung cấp tính năng tối ưu hiệu năng như:

• BigQuery: Dùng materialized view hoặc bảng phân vùng.
• Snowflake: Bật auto-clustering và mở rộng warehouse để chạy song song.

Bạn tối ưu lượt chạy dbt trong Snowflake như thế nào? 

Để tối ưu lượt chạy dbt trong Snowflake:

1. Dùng clustering cho bảng:

{{ config(
    cluster_by = ["date_column", "category_column"]
) }}
SELECT ...

2. Tận dụng multi-cluster warehouse của Snowflake để chạy model song song:

models:
  my_project:
    materialized: table
    snowflake_warehouse: transforming_wh

3. Dùng incremental model khi phù hợp:

{{ config(materialized='incremental', unique_key='id') }}
SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

Các tối ưu này có thể cải thiện hiệu năng và chi phí khi chạy dbt trên Snowflake.

Câu hỏi phỏng vấn dbt về hành vi và giải quyết vấn đề 

Ở cuối quá trình phỏng vấn, nhà tuyển dụng thường kiểm tra kỹ năng giải quyết vấn đề của bạn. Họ có thể hỏi những câu để xem bạn phản ứng thế nào với tình huống thực tế.

Hãy nhớ câu nói sau về kỹ năng mềm cần có cho vai trò này của Deepak Goyal, CEO & Nhà sáng lập Azurelib Academy, khi anh chia sẻ trên podcast DataFramed:

Dưới đây là một vài câu hỏi về hành vi và giải quyết vấn đề:

Bạn sẽ quản lý việc triển khai dbt qua nhiều môi trường (dev, staging, production) như thế nào?

Cách quản lý triển khai dbt qua các môi trường:

1. Cấu hình theo môi trường

dbt cho phép bạn định nghĩa cấu hình khác nhau cho từng môi trường (dev, staging, production) trong tệp dbt_project.yml. Bạn có thể chỉ định cài đặt khác nhau như schema, database và cấu hình kho dữ liệu.

Ví dụ trong dbt_project.yml:

models:
  my_project:
    dev:
      schema: dev_schema
    staging:
      schema: staging_schema
    prod:
      schema: prod_schema

Trong ví dụ này, dbt tự động chọn schema đúng theo môi trường mục tiêu (dev, staging, prod) khi chạy dự án.

2. Dùng biến target

Biến target trong dbt dùng để xác định bạn đang làm việc ở môi trường nào (dev, staging, production). Bạn có thể tham chiếu biến này trong model hoặc macro để tùy biến hành vi theo môi trường.

Ví dụ trong một model:

{% if target.name == 'prod' %}
    SELECT * FROM production_table
{% else %}
    SELECT * FROM {{ ref('staging_table') }}
{% endif %}

Logic này đảm bảo dùng các bảng hoặc schema khác nhau tùy môi trường.

3. Nhánh và quản lý phiên bản

Mỗi môi trường nên có nhánh riêng trong hệ thống quản lý phiên bản (ví dụ: Git). Nhà phát triển làm việc trên nhánh dev, kiểm thử và phân tích dùng staging, và chỉ thay đổi đã duyệt mới được hợp nhất vào nhánh prod.

4. Tích hợp (CI) & Triển khai liên tục (CD)

Trong production, cần có pipeline triển khai tự động chạy kiểm thử và xác thực trước khi triển khai model. Trên dbt Cloud, bạn có thể thiết lập lịch job để chạy tác vụ theo môi trường. Với dbt Core, có thể dùng các công cụ CI/CD như GitHub Actions hoặc Jenkins.

Bạn xử lý quản lý phiên bản trong dbt như thế nào, đặc biệt khi làm việc nhóm?

Quản lý phiên bản là điều cốt yếu khi làm dự án dbt, nhất là trong môi trường nhóm nơi nhiều người cùng đóng góp. Cách tôi xử lý như sau:

1. Dùng Git để quản lý phiên bản

Chúng tôi dùng Git làm công cụ chính. Mỗi thành viên làm trên nhánh riêng cho thay đổi/tính năng họ triển khai. Cách này cho phép phát triển độc lập và tránh xung đột khi nhiều người làm việc song song.

Ví dụ: Tôi tạo nhánh tính năng như feature/customer_order_transformation khi làm một model dbt mới.

2. Chiến lược nhánh

Chúng tôi theo chiến lược nhánh Git, trong đó:

• Nhánh dev dùng cho phát triển và kiểm thử liên tục.
• Nhánh staging dùng để chuẩn bị đưa thay đổi lên production.
• Nhánh main hoặc prod dành cho môi trường production.

Thành viên đẩy thay đổi lên nhánh dev và mở pull request (PR) để review mã. Khi được duyệt, thay đổi được merge vào staging để kiểm thử thêm, rồi mới lên production.

3. Tích hợp liên tục (CI)

Chúng tôi tích hợp pipeline CI (ví dụ: GitHub Actions, CircleCI) để tự động chạy kiểm thử dbt trên mỗi PR. Nhờ vậy, bất kỳ mã mới nào cũng phải vượt qua kiểm thử trước khi merge vào nhánh chính. 

Quy trình CI chạy dbt run để dựng model và dbt test để xác thực dữ liệu, kiểm tra lỗi/bất nhất.

4. Giải quyết xung đột merge

Khi nhiều thành viên thay đổi cùng một model/tệp, có thể phát sinh xung đột. Tôi sẽ xem xét dấu hiệu xung đột trong mã và quyết định giữ thay đổi nào:

• Nếu cả hai thay đổi đều hợp lệ, tôi kết hợp chúng thành phiên bản mới.
• Nếu chỉ một thay đổi đúng, tôi giữ thay đổi đó và bỏ phần còn lại.

Sau khi giải quyết, tôi chạy kiểm thử cục bộ để đảm bảo không phát sinh lỗi mới, rồi đẩy thay đổi đã xử lý lên nhánh.

5. Tài liệu và cộng tác

Chúng tôi đảm bảo mỗi lần merge/PR đều có tài liệu mô tả thay đổi. Cập nhật tài liệu tự động sinh bởi dbt để mọi người hiểu rõ các model mới/cập nhật.

Bạn sẽ triển khai dbt trong một pipeline dữ liệu hiện hữu như thế nào?  

Cách tôi triển khai dbt trong pipeline sẵn có:

1. Đánh giá pipeline hiện tại: Xác định điểm chưa hiệu quả và nơi dbt có thể cải thiện bước biến đổi.
2. Thiết lập dbt: Cài đặt dbt, tạo dự án mới và cấu hình kết nối tới kho dữ liệu.
3. Chuyển đổi phần biến đổi: Di trú SQL/logic biến đổi hiện có vào các model dbt, đảm bảo tính mô-đun và rõ ràng.
4. Thêm kiểm thử và tài liệu: Áp dụng kiểm thử và tài liệu tích hợp của dbt để bảo đảm chất lượng và minh bạch dữ liệu.
5. Tích hợp với điều phối: Lập lịch chạy dbt bằng công cụ hiện có như Airflow hoặc Prefect.
6. Bắt đầu nhỏ: Áp dụng dbt cho một phần nhỏ của pipeline để xác thực trước khi mở rộng.
7. Giám sát và tối ưu: Liên tục theo dõi hiệu năng và tối ưu model khi cần.

Hãy tưởng tượng một model dbt bị lỗi "relation does not exist". Bạn sẽ debug lỗi này như thế nào?

Khi gặp lỗi "relation does not exist" trong dbt, thường là model đang tham chiếu tới bảng/model chưa được tạo hoặc bị sai chính tả. Cách debug của tôi:

1. Kiểm tra lỗi chính tả: Đảm bảo tên bảng/model được viết đúng trong hàm ref() và xác thực đúng thực thể được tham chiếu.

SELECT * FROM {{ ref('orders') }}  -- Ensure 'orders' is the correct model name

1. Xác minh phụ thuộc model: Nếu model phụ thuộc vào model khác, kiểm tra DAG của dbt để đảm bảo model thượng nguồn đã được build thành công trước khi model lỗi chạy.
2. Chạy dbt ở chế độ debug: Dùng dbt debug và xem log để biết chi tiết dbt đã làm gì và tại sao thất bại.
3. Kiểm tra quyền trên nền tảng dữ liệu: Đảm bảo dbt có quyền truy cập bảng/model được tham chiếu trong kho dữ liệu.
4. Chạy từng model riêng lẻ: Thử chạy các model phụ thuộc riêng (ví dụ, dbt run --models orders) để xác thực chúng tồn tại và được build đúng trước model đang lỗi.

Mẹo chuẩn bị cho phỏng vấn dbt

dbt là một khung mới và liên tục được cải tiến. Việc vừa cập nhật tính năng mới vừa học phần cũ có thể gây quá tải. Vì vậy, hãy tiếp cận cân bằng: bắt đầu với các tính năng cốt lõi. Khi đã vững, hãy khám phá bổ sung để nắm rõ những thay đổi. 

Tôi hiểu phỏng vấn có thể gây căng thẳng, đặc biệt với công cụ chuyên biệt như dbt. Nhưng đừng lo — tôi đã tổng hợp vài mẹo giúp bạn chuẩn bị và tự tin hơn:

Thành thạo tính năng dbt

Tôi không thể nhấn mạnh đủ — hãy quen thuộc với các khái niệm nền tảng của dbt, gồm model, kiểm thử, tài liệu hóa và cách chúng kết nối với nhau. Nắm vững những điều cơ bản này sẽ giúp bạn trong các cuộc trao đổi kỹ thuật.

DataCamp có khóa học hoàn hảo: Introduction to dbt 

DataCamp cũng có các khóa học thân thiện cho người mới, bao quát sâu các chủ đề kỹ thuật dữ liệu khác:

• Cho kiến thức cơ bản về kỹ thuật dữ liệu: Understanding Data Engineering 
• Cho thiết kế cơ sở dữ liệu: Database Design 
• Cho kiến thức kho dữ liệu cơ bản: Data Warehousing Concepts 
• Cho kiến thức Snowflake cơ bản: Introduction to Snowflake 
• Cho kiến trúc dữ liệu: Understanding Modern Data Architecture 
• Học ETL và ELT bằng Python: ETL and ELT in Python 

Thực hành trực tiếp với dbt

Đọc là tốt, nhưng làm còn tốt hơn. Đây là cách hiệu quả để làm chủ dbt. Bạn có thể tìm danh sách lớn dữ liệu thô trực tuyến để thực hiện biến đổi và chạy kiểm thử. Tự thiết lập dự án dbt và thử các tính năng khác nhau. Khi đã thực sự sử dụng, bạn sẽ tự tin hơn khi nói về dbt.

Chuẩn bị ví dụ thực tế

Nhà tuyển dụng thích nghe về ứng dụng thực tiễn. Bạn có thể nghĩ đến một vấn đề bạn đã giải bằng dbt, hoặc cách bạn sẽ dùng nó trong một kịch bản giả định? Hãy chuẩn bị vài ví dụ như vậy. Để thu thập ví dụ, bạn có thể nghiên cứu các case study từ trang chính thức của dbt hoặc lấy ý tưởng từ các dự án dbt công khai trên Git. 

Kết luận 

Chúng ta đã bao quát một phổ rộng câu hỏi phỏng vấn dbt từ cơ bản đến nâng cao, giúp bạn trên hành trình tìm việc. Bằng cách hiểu cách tích hợp dbt với các kho dữ liệu đám mây, bạn sẽ trang bị kỹ năng biến đổi dữ liệu nâng cao — cốt lõi của mọi quy trình tích hợp dữ liệu. 

Tuy nhiên, học dbt đi cùng với SQL. Vì vậy, nếu bạn mới học SQL, hãy xem các khóa học SQL của DataCamp.