dbt cho Data Analyst năm 2026: Hướng dẫn Modeling, Testing và Câu hỏi Phỏng vấn

Trong bối cảnh ngành phân tích dữ liệu đang phát triển nhanh chóng, dbt (data build tool) đã trở thành công cụ không thể thiếu cho các Data Analyst chuyên nghiệp. Công cụ này cho phép các nhà phân tích áp dụng các phương pháp kỹ thuật phần mềm vào quy trình xử lý dữ liệu, từ việc viết các transformation có thể kiểm thử đến việc tạo documentation tự động. Năm 2026, việc thành thạo dbt không chỉ là lợi thế cạnh tranh mà còn là yêu cầu cơ bản cho các vị trí data analytics tại các công ty hàng đầu.

Kiến trúc dbt Modeling: Từ Staging đến Marts

Một trong những khái niệm quan trọng nhất trong dbt modeling là việc tổ chức các model theo các layer khác nhau. Kiến trúc phổ biến nhất bao gồm ba layer chính: staging, intermediate và marts. Mỗi layer phục vụ một mục đích cụ thể trong quá trình chuyển đổi dữ liệu từ raw data thành các báo cáo có ý nghĩa kinh doanh.

Staging Layer

Staging models là điểm khởi đầu của mọi quy trình transformation. Tại layer này, các Data Analyst thực hiện các thao tác làm sạch cơ bản như đổi tên cột, chuyển đổi kiểu dữ liệu và lọc các bản ghi không hợp lệ. Nguyên tắc quan trọng là mỗi staging model chỉ nên tham chiếu đến một source duy nhất.

-- models/staging/stripe/stg_stripe__payments.sql
with source as (
    select * from {{ source('stripe', 'payments') }}
),

renamed as (
    select
        id as payment_id,
        amount / 100.0 as amount_usd,  -- Stripe stores cents
        status as payment_status,
        created::timestamp as created_at,
        customer_id
    from source
    where status != 'failed'  -- Filter invalid records early
)

select * from renamed

Trong ví dụ trên, staging model thực hiện các nhiệm vụ thiết yếu: chuyển đổi đơn vị tiền tệ từ cents sang dollars, chuẩn hóa tên cột theo quy ước đặt tên nhất quán và loại bỏ các giao dịch thất bại ngay từ giai đoạn đầu tiên.

Mart Layer

Marts là layer cuối cùng trong kiến trúc dbt, nơi chứa các model đã sẵn sàng để phục vụ cho các báo cáo và dashboard. Các model tại layer này thường được tổ chức theo domain nghiệp vụ như finance, marketing hoặc product.

-- models/marts/finance/fct_monthly_revenue.sql
with payments as (
    select * from {{ ref('stg_stripe__payments') }}
),

monthly as (
    select
        date_trunc('month', created_at) as revenue_month,
        count(*) as total_transactions,
        sum(amount_usd) as gross_revenue,
        sum(case when payment_status = 'refunded' then amount_usd else 0 end) as refunds
    from payments
    group by 1
)

select
    revenue_month,
    total_transactions,
    gross_revenue,
    refunds,
    gross_revenue - refunds as net_revenue  -- Key business metric
from monthly

Model fct_monthly_revenue minh họa cách tổng hợp dữ liệu thanh toán thành các chỉ số doanh thu hàng tháng. Việc sử dụng hàm ref() thay vì tham chiếu trực tiếp đến bảng giúp dbt xây dựng DAG (Directed Acyclic Graph) tự động, đảm bảo các model được thực thi theo đúng thứ tự phụ thuộc.

Incremental Models: Xử lý Dữ liệu Lớn Hiệu quả

Đối với các bảng fact có khối lượng dữ liệu lớn như events hoặc logs, việc rebuild toàn bộ bảng mỗi lần chạy là không khả thi về mặt thời gian và chi phí. Incremental models giải quyết vấn đề này bằng cách chỉ xử lý các bản ghi mới kể từ lần chạy trước.

-- models/marts/product/fct_page_views.sql
{{ config(
    materialized='incremental',
    unique_key='page_view_id',
    incremental_strategy='merge'
) }}

with events as (
    select
        event_id as page_view_id,
        user_id,
        page_url,
        session_id,
        event_timestamp
    from {{ ref('stg_snowplow__events') }}
    where event_type = 'page_view'

    {% if is_incremental() %}
        -- Only process new events since last run
        and event_timestamp > (select max(event_timestamp) from {{ this }})
    {% endif %}
)

select * from events

Macro is_incremental() là chìa khóa để hiểu cách hoạt động của incremental models. Khi model chạy lần đầu tiên hoặc với flag --full-refresh, điều kiện này trả về false và toàn bộ dữ liệu được xử lý. Trong các lần chạy tiếp theo, chỉ những bản ghi có event_timestamp lớn hơn giá trị timestamp cao nhất hiện có trong bảng mới được xử lý.

Các Loại Materialization trong dbt

Việc lựa chọn materialization phù hợp ảnh hưởng trực tiếp đến hiệu suất và chi phí của data warehouse. Bảng dưới đây tóm tắt các loại materialization và trường hợp sử dụng tương ứng:

| Materialization | Use Case | Rebuild Behavior | |----------------|----------|-------------------| | view | Lightweight staging models, low query frequency | Recreated as SQL view on each run | | table | Mart models queried often by dashboards | Full table rebuild on each run | | incremental | Large fact tables (events, logs) | Appends/merges new rows only | | ephemeral | Reusable CTEs, never queried directly | Compiled inline as subquery |

Các Data Analyst nên cân nhắc kỹ lưỡng giữa các yếu tố như tần suất truy vấn, khối lượng dữ liệu và yêu cầu về độ tươi mới của dữ liệu khi quyết định materialization cho từng model.

Testing trong dbt: Đảm bảo Chất lượng Dữ liệu

Testing là một trong những tính năng mạnh mẽ nhất của dbt, cho phép Data Analyst phát hiện các vấn đề về chất lượng dữ liệu trước khi chúng ảnh hưởng đến các báo cáo và quyết định kinh doanh. dbt cung cấp hai loại test chính: schema tests và singular tests.

Schema Tests

Schema tests được định nghĩa trong các file YAML và áp dụng cho các cột cụ thể trong model. dbt tích hợp sẵn bốn loại test cơ bản: unique, not_null, accepted_values và relationships. Ngoài ra, package dbt_utils cung cấp nhiều test bổ sung hữu ích.

# models/staging/stripe/_stripe__models.yml
version: 2

models:
  - name: stg_stripe__payments
    description: "Cleaned payment records from Stripe"
    columns:
      - name: payment_id
        description: "Unique payment identifier"
        tests:
          - unique
          - not_null
      - name: payment_status
        tests:
          - accepted_values:
              values: ['succeeded', 'pending', 'refunded']
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"  # No negative payments

Cấu hình trên đảm bảo rằng mỗi bản ghi thanh toán có một payment_id duy nhất và không null, trạng thái thanh toán chỉ nhận các giá trị hợp lệ và số tiền không bao giờ âm.

Singular Tests

Singular tests là các câu truy vấn SQL tùy chỉnh kiểm tra các điều kiện nghiệp vụ phức tạp. Một test được coi là passed khi câu truy vấn không trả về bất kỳ hàng nào.

-- tests/assert_revenue_not_negative.sql
-- This test fails if any month has negative net revenue
select
    revenue_month,
    net_revenue
from {{ ref('fct_monthly_revenue') }}
where net_revenue < 0  -- Should never happen

Test này đảm bảo rằng doanh thu ròng hàng tháng không bao giờ âm, một điều kiện nghiệp vụ quan trọng mà các schema tests cơ bản không thể kiểm tra.

Macros: Tái sử dụng Logic với Jinja

Macros trong dbt cho phép tái sử dụng các đoạn SQL lặp lại nhiều lần trong codebase. Được viết bằng Jinja templating, macros giúp giảm thiểu code duplication và đảm bảo tính nhất quán trong các transformation.

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ({{ column_name }} / 100.0)::numeric(12, 2)
{% endmacro %}

-- Usage in any model
select
    payment_id,
    {{ cents_to_dollars('amount_cents') }} as amount_usd,
    {{ cents_to_dollars('tax_cents') }} as tax_usd
from {{ source('stripe', 'payments') }}

Macro cents_to_dollars có thể được sử dụng trong bất kỳ model nào, đảm bảo việc chuyển đổi đơn vị tiền tệ được thực hiện nhất quán và chính xác với độ chính xác số học phù hợp.

Source Freshness: Giám sát Pipeline Dữ liệu

Việc theo dõi độ tươi mới của dữ liệu nguồn là cực kỳ quan trọng trong các môi trường production. dbt cung cấp tính năng source freshness để cảnh báo khi dữ liệu nguồn không được cập nhật đúng thời hạn.

# models/staging/stripe/_stripe__sources.yml
version: 2

sources:
  - name: stripe
    database: raw
    schema: stripe
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _fivetran_synced
    tables:
      - name: payments
      - name: customers

Cấu hình này thiết lập cảnh báo khi dữ liệu Stripe không được cập nhật trong 12 giờ và báo lỗi nghiêm trọng sau 24 giờ. Đây là một phần không thể thiếu của quy trình data analytics dbt chuyên nghiệp.

Câu hỏi Phỏng vấn dbt Thường Gặp

Việc chuẩn bị cho các cuộc phỏng vấn về dbt đòi hỏi sự hiểu biết sâu sắc về cả lý thuyết lẫn thực hành. Dưới đây là các dbt interview questions phổ biến mà ứng viên nên nắm vững:

Câu hỏi về Kiến trúc và Modeling

Câu hỏi: Sự khác biệt giữa ref() và source() là gì?

Hàm source() được sử dụng để tham chiếu đến các bảng raw data từ hệ thống nguồn, trong khi ref() tham chiếu đến các model khác trong dự án dbt. Cả hai đều giúp dbt xây dựng DAG và quản lý thứ tự thực thi.

Câu hỏi: Khi nào nên sử dụng incremental model thay vì table?

Incremental models phù hợp khi xử lý các bảng có khối lượng dữ liệu lớn (hàng triệu bản ghi trở lên), khi dữ liệu có tính chất append-only hoặc slowly changing, và khi việc rebuild toàn bộ bảng tốn quá nhiều thời gian hoặc chi phí.

Câu hỏi: Ephemeral model được sử dụng trong trường hợp nào?

Ephemeral models không tạo bất kỳ đối tượng nào trong database mà được compile inline dưới dạng CTE. Chúng hữu ích cho các transformation trung gian được tái sử dụng trong nhiều model nhưng không cần query trực tiếp.

Câu hỏi về Testing và Documentation

Câu hỏi: Làm thế nào để test relationship giữa các model?

dbt cung cấp test relationships để kiểm tra referential integrity. Test này đảm bảo rằng tất cả các giá trị trong một cột của model con đều tồn tại trong cột tương ứng của model cha.

Câu hỏi: Singular test và schema test khác nhau như thế nào?

Schema tests được định nghĩa trong file YAML và áp dụng cho các cột cụ thể, trong khi singular tests là các file SQL riêng biệt chứa logic kiểm tra tùy chỉnh. Schema tests phù hợp cho các kiểm tra đơn giản và lặp lại, còn singular tests cho phép kiểm tra các điều kiện nghiệp vụ phức tạp.

Câu hỏi về Production và Best Practices

Câu hỏi: Chiến lược xử lý late-arriving data trong incremental models?

Có thể sử dụng lookback period bằng cách điều chỉnh điều kiện trong macro is_incremental(). Thay vì chỉ lấy dữ liệu sau timestamp cuối cùng, hệ thống có thể lùi lại một khoảng thời gian nhất định để capture các bản ghi đến muộn.

Câu hỏi: Làm thế nào để quản lý các môi trường khác nhau (dev, staging, prod)?

dbt sử dụng profiles và targets để quản lý các môi trường. Mỗi môi trường có thể trỏ đến database/schema khác nhau, cho phép development và testing an toàn mà không ảnh hưởng đến production data.

Best Practices cho Data Analyst

Việc áp dụng các best practices trong dbt không chỉ giúp cải thiện chất lượng code mà còn tăng khả năng bảo trì và mở rộng của dự án data analytics dbt.

Quy ước Đặt tên

Các staging models nên bắt đầu bằng tiền tố stg_ theo sau là tên source và tên bảng, ví dụ: stg_stripe__payments. Mart models nên sử dụng tiền tố fct_ cho fact tables và dim_ cho dimension tables. Quy ước này giúp người dùng nhanh chóng nhận biết mục đích và vị trí của mỗi model trong kiến trúc.

Tổ chức Thư mục

Cấu trúc thư mục nên phản ánh kiến trúc layer với các thư mục riêng biệt cho staging, intermediate và marts. Mỗi source nên có thư mục con riêng trong staging để dễ dàng quản lý và tìm kiếm.

Documentation

Documentation nên được viết trong các file YAML cùng với định nghĩa model. dbt tự động generate documentation website từ các descriptions này, giúp team hiểu rõ ý nghĩa của từng model và cột dữ liệu.

Version Control và Code Review

Tất cả các thay đổi nên được quản lý qua Git với quy trình pull request và code review. Điều này đảm bảo chất lượng code và tạo audit trail cho các thay đổi trong data pipeline.

Kết luận

dbt đã cách mạng hóa cách các Data Analyst làm việc với dữ liệu trong data warehouse. Việc nắm vững công cụ này mang lại nhiều lợi ích thiết thực:

• Tăng năng suất: Tái sử dụng code thông qua macros và packages giảm thiểu thời gian phát triển
• Cải thiện chất lượng dữ liệu: Testing tự động phát hiện lỗi trước khi chúng ảnh hưởng đến báo cáo
• Khả năng bảo trì: Kiến trúc layer và quy ước đặt tên giúp codebase dễ hiểu và mở rộng
• Chuẩn bị cho phỏng vấn: Hiểu sâu về dbt modeling và testing là lợi thế lớn trong các cuộc phỏng vấn dbt data analyst
• Collaboration: Documentation tự động và version control cải thiện sự phối hợp trong team

Với sự phát triển không ngừng của ngành data analytics, dbt tiếp tục là kỹ năng quan trọng cho các Data Analyst muốn nâng cao giá trị chuyên môn và đóng góp hiệu quả hơn cho tổ chức.