Chuyển đến nội dung chính

Hướng dẫn toàn diện về các bài kiểm thử dbt để đảm bảo chất lượng dữ liệu

Tìm hiểu các bài kiểm thử khả dụng trong dbt để kiểm tra và đảm bảo chất lượng dữ liệu.
· 11 phút đọc

Khám phá cùng AI

dbt ngày càng phổ biến trong lĩnh vực phân tích nhờ các chức năng chuyển đổi dữ liệu và kiểm thử. Trong bài viết này, chúng tôi sẽ chia sẻ dbt là gì và cách bạn có thể thực hiện một số bài kiểm thử dbt để đảm bảo chất lượng dữ liệu. Nếu bạn mới bắt đầu với dbt, hãy xem khóa học Nhập môn dbt của chúng tôi để tìm hiểu thêm. 

dbt là gì?

Như chúng tôi trình bày trong hướng dẫn riêng, dbt (data build tool) là một công cụ mã nguồn mở phổ biến, được các nhóm dữ liệu sử dụng để chuyển đổi dữ liệu thô trong kho dữ liệu của họ thành các bộ dữ liệu sạch, đã kiểm thử, có tài liệu và sẵn sàng cho phân tích. 

Không giống như các công cụ ETL, dbt chỉ tập trung vào thành phần "T" (Transform) của pipeline dữ liệu và hoạt động trên các kho dữ liệu đám mây hiện đại như BigQuery, Snowflake, Redshift và Databricks.

Một trong những tính năng mạnh mẽ nhất của dbt là khung kiểm thử dữ liệu tích hợp, cho phép người làm dữ liệu viết các bài kiểm thử để xác nhận các giả định về dữ liệu. Khung kiểm thử này không chỉ hữu ích để phát hiện vấn đề sớm mà còn rất quan trọng để duy trì chất lượng dữ liệu và sự tin cậy trong một codebase phân tích ngày càng lớn và mô-đun hóa.

Vì sao nên kiểm thử trong dbt?

Kiểm thử là nền tảng của kỹ thuật phân tích. Khi các bộ dữ liệu phát triển và nhiều bên liên quan phụ thuộc vào dữ liệu hơn, chi phí của các vấn đề dữ liệu không được phát hiện cũng tăng theo. Khả năng kiểm thử của dbt giúp bạn:

  • Phát hiện vấn đề dữ liệu sớm: Trước khi các bảng điều khiển và báo cáo phía hạ nguồn bị ảnh hưởng.
  • Tự động hóa kiểm tra chất lượng: Tránh các công việc xác thực thủ công.
  • Khuyến khích thực hành mô hình dữ liệu tốt: Thúc đẩy các phép biến đổi mô-đun và có thể kiểm thử.
  • Hỗ trợ thực hành CI/CD: Tích hợp liền mạch vào các quy trình tự động.
  • Thực thi hợp đồng dữ liệu: Xác thực rằng các ràng buộc quan trọng (ví dụ: không có trùng lặp) được duy trì theo thời gian.

Các loại bài kiểm thử trong dbt

Trong dbt, kiểm thử là các mệnh đề dựa trên SQL để xác thực giả định về dữ liệu. Các bài kiểm thử trong dbt thuộc hai nhóm chính:

1. Kiểm thử chung (tích hợp sẵn)

Các bài kiểm thử này được dbt định nghĩa sẵn và được áp dụng theo cách khai báo trong các tệp YAML. Kiểm thử chung bao phủ các ràng buộc phổ biến thường gặp trong mô hình hóa dữ liệu và kho dữ liệu. 

Chúng có các đặc điểm:

  • Dễ cấu hình
  • Tái sử dụng trên nhiều cột và mô hình
  • Hiệu năng cao cho các kiểm tra đơn giản

Bốn kiểu kiểm thử chung tích hợp sẵn gồm:

  • not_null: Đảm bảo một cột không chứa bất kỳ giá trị NULL nào.
  • unique: Đảm bảo các giá trị của một cột là duy nhất trên các hàng (thường dùng cho khóa chính).
  • accepted_values: Giới hạn một cột trong một tập giá trị cho phép được xác định trước.
  • relationships: Xác thực tính toàn vẹn tham chiếu giữa các bảng, đảm bảo khóa ngoại khớp với giá trị ở bảng khác.

Các kiểm thử này lý tưởng để thực thi tính toàn vẹn dữ liệu cơ bản, đặc biệt quanh các khóa, trường phân loại và các mối quan hệ bảng cốt lõi.

Kiểm thử chung hoạt động bằng cách tự động sinh SQL ở tầng bên dưới. 

Ví dụ, kiểm thử not_null trên cột customer_id sẽ sinh SQL tương tự:

SELECT *
FROM {{ ref('customers') }}
WHERE customer_id IS NULL

Nếu truy vấn này trả về bất kỳ hàng nào, bài kiểm thử sẽ thất bại.

2. Kiểm thử tùy chỉnh (đơn lẻ)

Kiểm thử tùy chỉnh hay đơn lẻ là các truy vấn SQL do người dùng định nghĩa, lưu dưới dạng tệp .sql trong thư mục tests/. Chúng được dùng cho:

  • Xác thực phức tạp mà kiểm thử chung không thể biểu đạt
  • Thực thi quy tắc nghiệp vụ
  • Logic xuyên mô hình
  • Ngưỡng thống kê hoặc có điều kiện

Kiểm thử đơn lẻ cung cấp mức linh hoạt tối đa. Bạn có thể xác thực dữ liệu theo hầu như bất kỳ cách nào, miễn là truy vấn SQL của bạn chỉ trả về những hàng vi phạm kỳ vọng.

Ví dụ:

  • Đảm bảo ngày ra mắt của sản phẩm không sau ngày ngừng bán
  • Phát hiện giá trị bất thường cao hoặc thấp (phát hiện ngoại lệ)
  • Xác thực rằng các giá trị tổng hợp phù hợp với tổng số nghiệp vụ

Nhờ tính linh hoạt, kiểm thử tùy chỉnh rất phù hợp cho các nhóm phân tích muốn thực thi các hợp đồng chất lượng dữ liệu tinh vi trong môi trường vận hành.

Bạn cũng có thể dùng các macro đi kèm dbt để kiểm thử, như gói dbt-utils.

Tóm lại:

Tính năng

Kiểm thử chung

Kiểm thử tùy chỉnh (đơn lẻ)

Được định nghĩa ở

schema.yml

Tệp .sql trong thư mục tests/

Phạm vi

Ràng buộc phổ biến (ví dụ: null, khóa)

Bất kỳ logic nào biểu đạt được bằng SQL

Mức độ phức tạp

Đơn giản

Trung bình đến phức tạp

Khả năng tái sử dụng

Cao

Thấp (thường theo từng trường hợp)

Tính linh hoạt

Hạn chế

Không giới hạn (mọi logic SQL)

Kết hợp cả hai loại giúp bạn có điều tốt nhất của cả hai: sự nhất quán và độ bao phủ từ kiểm thử chung, cùng độ chính xác từ kiểm thử tùy chỉnh. Hãy cùng khám phá chi tiết từng loại. 

1. Kiểm thử chung (tích hợp sẵn)

Kiểm thử chung được dbt định nghĩa sẵn và dùng theo cách khai báo bằng cách thêm chúng vào tệp schema.yml của mô hình. 

Các kiểm thử này thường xác thực các ràng buộc như tính duy nhất, không-null, toàn vẹn tham chiếu hoặc giá trị trong một tập xác định.

Hãy xem một hướng dẫn đơn giản để thử các kiểm thử chung trong dbt.

Cách khai báo kiểm thử chung

Trong tệp schema.yml tương ứng với mô hình của bạn, định nghĩa kiểm thử dưới phần columns::

version: 2

models:
  - name: customers
    description: "Customer dimension table"
    columns:
      - name: customer_id
        description: "Unique customer identifier"
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null

Ví dụ: not_null và unique

yaml
columns:
  - name: customer_id
    tests:
      - not_null
      - unique

Bài kiểm thử trên đảm bảo customer_id vừa có mặt ở mọi hàng vừa là duy nhất. Thường được dùng để thực thi giả định rằng customer_id là khóa chính của bảng.

Ví dụ: accepted_values

columns:
  - name: customer_type
    tests:
      - accepted_values:
          values: ['new', 'returning', 'vip']

Điều này kiểm tra rằng trường customer_type chỉ chứa một trong ba chuỗi được cho phép: new, returning hoặc vip. Bài kiểm thử này thường dùng cho các trường phân loại phải tuân theo một tập giá trị đã biết, như enum hoặc trạng thái.

Ví dụ: relationships

columns:
  - name: customer_id
    tests:
      - relationships:
          to: ref('customers')
          field: id

Điều này thực thi ràng buộc toàn vẹn tham chiếu bằng cách xác minh rằng mọi customer_id trong mô hình hiện tại đều tồn tại dưới dạng id trong bảng customers. Nó mô phỏng ràng buộc khóa ngoại trong SQL nhưng ở lớp phân tích.

2. Kiểm thử tùy chỉnh (đơn lẻ)

Khi các kiểm thử tích hợp sẵn là chưa đủ cho trường hợp sử dụng của bạn, chẳng hạn bạn muốn xác thực logic nghiệp vụ phức tạp, bạn có thể viết kiểm thử tùy chỉnh bằng SQL. Đây được gọi là kiểm thử đơn lẻ.

Cách tạo kiểm thử tùy chỉnh

1. Tạo tệp .sql trong thư mục tests/ của dự án dbt.

2. Viết truy vấn SQL trả về các hàng không đạt kiểm thử.

Ví dụ: Không có ngày tương lai trong orders

Trong thư mục tests, tạo tệp tên là no_future_dates.sql.

SELECT *
FROM {{ ref('orders') }}
WHERE order_date > current_date

Bài kiểm thử này kiểm tra xem có bản ghi nào trong bảng orders có order_date ở tương lai hay không. Nếu có hàng được trả về, kiểm thử thất bại, cảnh báo bạn về dữ liệu không hợp lệ do lỗi múi giờ, lỗi ETL hoặc dữ liệu sai từ hệ thống nguồn.

Ví dụ: Email trùng lặp theo vùng

-- Tệp: tests/duplicate_emails_per_region.sql

SELECT email, region, COUNT(*) as occurrences
FROM {{ ref('customers') }}
GROUP BY email, region
HAVING COUNT(*) > 1

Bài kiểm thử này đảm bảo mỗi email là duy nhất trong một vùng nhất định. Điều này có thể phản ánh quy tắc nghiệp vụ là cùng một người không thể đăng ký hai lần trong cùng một vùng. Mọi hàng được trả về đều cho thấy vi phạm chất lượng dữ liệu.

Cách triển khai kiểm thử trong dbt

Phần này hướng dẫn các bước thực tế để triển khai, cấu hình và chạy các bài kiểm thử dbt trong dự án và các pipeline triển khai của bạn.

Bước 1: Thiết lập dbt

Trước khi bắt đầu viết kiểm thử hay mô hình, bạn cần cài đặt dbt và khởi tạo một dự án mới.

Hướng dẫn từng bước:

1. Tạo thư mục dự án:

Tạo một thư mục tại vị trí bạn chọn.

2. Di chuyển vào thư mục dự án:

cd dbt-test-project

3. Tạo môi trường ảo Python:

python3 -m venv dbt-env

Tiếp theo, kích hoạt môi trường sau khi đã tạo.

dbt-venv\Scripts\activate

4. Cài đặt dbt

pip dbt install

5. Tạo thư mục .dbt

mkdir $home\.dbt

6. Khởi tạo dbt

dbt init

7. Tạo tệp profiles.yml

Tạo một tệp mới trong thư mục .dbt với nội dung sau:

austi:
  target: dev
  outputs:
    dev:
      type: sqlite
      threads: 1
      database: ./dbt_project.db
      schema: main
      schema_directory: ./schemas
      schemas_and_paths:
        main: ./dbt_project.db

Bạn có thể thay “austi” bằng tên hồ sơ người dùng trên máy tính Windows của bạn.

8. Tạo tệp dbt_project.yml

Tiếp theo, bạn cần tạo một tệp cấu hình khác trong thư mục .dbt với nội dung sau.

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Một lần nữa, thay “austi” bằng tên hồ sơ người dùng của bạn.

9. Xác minh dự án hoạt động:

dbt debug

Sau khi thiết lập xong, bạn đã sẵn sàng tạo bộ dữ liệu và xây dựng các mô hình dbt.

Bước 2: Tạo bộ dữ liệu

Nếu bạn làm việc mà không có quyền truy cập kho dữ liệu, bạn có thể mô phỏng kiểm thử dbt tại chỗ bằng tệp CSV và chức năng seed của dbt.

Hướng dẫn từng bước:

1. Tạo các tệp CSV: Đặt chúng trong thư mục /seeds mới của dự án dbt.

Bạn nên đặt tên như sau:

seeds/customers.csv

customer_id,name,email,customer_type
1,Alice Smith,[email protected],new
2,Bob Jones,[email protected],returning
3,Carol Lee,[email protected],vip
4,David Wu,[email protected],new

2. Tạo một tệp khác trong cùng thư mục:

Sử dụng quy ước đặt tên này:

seeds/orders.csv

order_id,customer_id,order_date,order_total,order_status
1001,1,2023-12-01,150.00,shipped
1002,2,2023-12-03,200.00,delivered
1003,1,2023-12-05,175.00,cancelled
1004,3,2024-01-01,225.00,pending

3. Tạo tệp cấu hình để nhận diện seeds:

Tiếp theo, bạn cần tạo tệp cấu hình tên dbt_project.yml.

Dán nội dung sau vào tệp cấu hình. 

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Đổi trường profile để khớp với tên hồ sơ người dùng trên máy tính Windows của bạn.

4. Nạp dữ liệu seed:

dbt seed

Lệnh này tạo các bảng main.customers và main.orders từ các tệp CSV. Đây là các seed cần thiết để thay thế một cơ sở dữ liệu.

loading seed data

Như bạn thấy ở hình trên, hai seed đã được tìm thấy và nạp vào.

Bước 3: Đưa vào dbt

Bây giờ, chúng ta sẽ tạo các mô hình staging để chuyển đổi và kiểm thử dữ liệu thô của bạn.

Hướng dẫn từng bước:

1. Tạo mô hình staging:

Tạo thư mục mới tên models trong thư mục dự án. Trong thư mục đó, tạo tệp stg_customers.sql.

Dán đoạn mã sau vào tệp:

SELECT
  *
FROM {{ ref('customers') }}

Trong tệp khác tên stg_orders.sql, dán đoạn mã sau:

SELECT
  *
FROM {{ ref('orders') }}

2. Định nghĩa kiểm thử schema:

Tạo tệp mới tại vị trí sau:

models/schema.yml

Dán nội dung sau vào tệp

version: 2

models:
  - name: stg_customers
    description: "Customer staging table"
    columns:
      - name: customer_id
        description: "Unique identifier for each customer"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: email
        description: "Email address of the customer"
        tests:
          - not_null

  - name: stg_orders
    description: "Orders staging table"
    columns:
      - name: order_id
        description: "Unique identifier for each order"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: customer_id
        description: "Foreign key to stg_customers"
        tests:
          - not_null:
              tags: [critical]

3. Chạy dbt để build mô hình staging:

dbt run --select stg_customers stg_orders

Các mô hình staging này hiện đóng vai trò nền tảng để áp dụng kiểm thử dbt bằng dữ liệu seed cục bộ của bạn.

Ví dụ kết quả đầu ra:

building staging models

Bước 4: Tạo bài kiểm thử đầu tiên

Giờ dữ liệu đã được staging, hãy triển khai bài kiểm thử dbt đầu tiên bằng khung kiểm thử tích hợp sẵn.

Hướng dẫn từng bước:

1. Mở tệp schema.yml nơi định nghĩa mô hình staging của bạn.

2. Dưới phần columns: của mô hình, định nghĩa kiểm thử như not_null hoặc unique.

Ví dụ:

models:

  - name: stg_customers

    columns:

      - name: customer_id

        tests:

          - not_null

          - unique
  1. Chạy kiểm thử bằng CLI:
dbt test --select stg_customers

Kết quả kỳ vọng như sau:

testing for nulls and uniques

Bước 5: Phát triển kiểm thử tùy chỉnh và đơn lẻ

Khi nhu cầu vượt quá các kiểm thử tích hợp sẵn, bạn có thể tạo kiểm thử tùy chỉnh bằng SQL.

Hướng dẫn từng bước:

1. Tạo tệp mới trong thư mục tests/, ví dụ: tests/no_future_orders.sql

2. Thêm logic SQL trả về các hàng lỗi:

SELECT *
FROM {{ ref('stg_orders') }}
WHERE order_date > current_date

3. Chạy kiểm thử:

dbt test --select no_future_orders

Bài kiểm thử này sẽ thất bại nếu có bất kỳ đơn hàng nào có order_date ở tương lai.

Kết quả kỳ vọng như sau:

testing for no future orders

Bước 6: Chạy kiểm thử trong pipeline CI/CD

Để đảm bảo kiểm thử được thực thi nhất quán, hãy tích hợp kiểm thử dbt vào pipeline phát triển của bạn.

Hướng dẫn từng bước:

1. Dùng thẻ (tag) để ưu tiên hoặc cô lập kiểm thử:

Bạn có thể chỉnh sửa bất kỳ schema mô hình nào để thêm thẻ theo định dạng sau:

columns:
  - name: customer_id
    tests:
      - not_null:
          tags: [critical]

2. Chạy lựa chọn kiểm thử cục bộ:

dbt test --select tag:critical

Nếu kiểm thử chạy đúng, bạn sẽ thấy đầu ra như sau:

testing for critical tags

3. Cấu hình quy trình CI để chạy kiểm thử dbt tự động. Bạn có thể kết nối với nền tảng CI như GitHub Actions. 

Thực hành tốt khi kiểm thử với dbt

Triển khai kiểm thử dbt hiệu quả không chỉ là viết chúng; mà còn là tích hợp kiểm thử vào vòng đời và văn hóa phát triển của đội ngũ bạn. Dưới đây là một số thực hành tốt để định hướng:

1. Bắt đầu với khóa chính

Luôn áp dụng kiểm thử not_null và unique cho các cột khóa chính trong bảng chiều và bảng sự kiện. Hai ràng buộc này là nền tảng cho các phép nối đáng tin cậy và logic loại bỏ trùng lặp trong các truy vấn hạ nguồn.

2. Xác thực khóa ngoại bằng relationships

Khóa ngoại rất quan trọng để duy trì toàn vẹn tham chiếu. Hãy dùng kiểm thử relationships để mô phỏng ràng buộc khóa ngoại, đặc biệt trong các kho dữ liệu không thực thi chúng một cách tự nhiên.

3. Dùng accepted_values cho các cột phân loại

Kiểm soát tính nhất quán theo chiều bằng cách áp đặt các giá trị cụ thể ở các cột như status, region hoặc product_type. Điều này giảm rủi ro lỗi gõ hoặc mở rộng enum không được xử lý.

4. Viết kiểm thử tùy chỉnh cho logic nghiệp vụ

Logic nghiệp vụ không phải lúc nào cũng ánh xạ gọn gàng sang các quy tắc chung. Ví dụ về logic bạn nên viết kiểm thử tùy chỉnh gồm:

  • Doanh số phải không âm
  • Ngày đặt hàng không được ở tương lai
  • Một người dùng không thể có nhiều đăng ký đang hoạt động

5. Tổ chức kiểm thử rõ ràng

Nếu bạn có nhiều kiểm thử, mọi thứ có thể trở nên lộn xộn rất nhanh. Hãy cân nhắc các thực hành sau để giữ cho chúng có tổ chức:

  • Đặt kiểm thử tùy chỉnh trong thư mục tests/ và đặt tên có tính mô tả.
  • Tránh SQL quá phức tạp trong kiểm thử — giữ logic tập trung và dễ đọc.
  • Nhóm kiểm thử theo mô hình hoặc miền nếu có thể.

6. Thất bại sớm và tích hợp với CI/CD

Chạy dbt test như một phần của pipeline CI. Điều này đảm bảo mã không thể được gộp trừ khi các ràng buộc chất lượng dữ liệu vượt qua. Tích hợp kiểm thử vào CI/CD củng cố trách nhiệm và niềm tin vào pipeline dữ liệu.

7. Tránh kiểm thử quá mức

Kiểm thử quá nhiều hoặc không cần thiết (đặc biệt trên khối lượng dữ liệu lớn) có thể làm chậm triển khai. Tập trung vào các kiểm thử:

  • Thiết yếu với nghiệp vụ
  • Có khả năng thất bại do vấn đề thượng nguồn
  • Hữu ích cho việc gỡ lỗi khi bị hỏng

Tránh kiểm thử các trường tính toán trừ khi chúng là một phần của SLA theo hợp đồng.

Ví dụ nâng cao: Phát hiện ngoại lệ

Với ví dụ nâng cao, chúng ta có thể thực hiện một bài kiểm thử phát hiện ngoại lệ.

Tạo một tệp SQL trong thư mục tests với đoạn mã sau:

SELECT *
FROM {{ ref('orders') }}
WHERE order_total > 100000

Đây là bài kiểm thử phát hiện ngoại lệ cơ bản. Nếu doanh nghiệp của bạn thường có đơn hàng dưới $10.000, bạn có thể gắn cờ các đơn trên $100.000 để rà soát thủ công. Dù không hẳn là vi phạm chất lượng dữ liệu nghiêm ngặt, điều này có giá trị cho phát hiện gian lận hoặc giám sát vận hành.

Lưu ý về hiệu năng

Khi dự án dbt mở rộng và phạm vi kiểm thử tăng, hiệu năng ngày càng quan trọng. Phần này nêu ra các kỹ thuật và chiến lược để duy trì hiệu quả kiểm thử và kiểm soát chi phí tính toán.

Kỹ thuật tối ưu kiểm thử

Khi kiểm thử, hãy thử các kỹ thuật sau để tối ưu hiệu năng:

  • Kiểm thử gia tăng: Tập trung kiểm thử chỉ trên dữ liệu mới thêm hoặc đã sửa bằng cách dùng cấu trúc mô hình incremental của dbt. Điều này giảm quét không cần thiết trên toàn bộ tập dữ liệu.
  • Song song hóa truy vấn: Dùng thực thi song song tích hợp sẵn của dbt bằng cách cấu hình tham số threads: trong dbt_project.yml để chạy nhiều kiểm thử đồng thời.
  • Chạy chọn lọc kiểm thử: Dùng cờ --select và --exclude để chỉ chạy các kiểm thử liên quan, đặc biệt trong giai đoạn phát triển. Ví dụ:
dbt test --select customers
dbt test --exclude tag:slow

Chiến lược quản lý chi phí

Triển khai chiến lược quản lý chi phí giúp kiểm thử dbt vẫn hiệu quả và tiết kiệm, đặc biệt trong các môi trường tính phí theo độ phức tạp và tần suất truy vấn.

Một số chiến lược gồm:

  • Chạy kiểm thử dựa trên thẻ: Gán thẻ cho các kiểm thử tốn tài nguyên hoặc tùy chọn để có thể loại trừ chúng khỏi các lần chạy tiêu chuẩn trừ khi cần thiết.
  • Bộ nhớ đệm kết quả: Tận dụng các tính năng riêng của kho dữ liệu (ví dụ: bộ nhớ đệm kết quả ở BigQuery hoặc Snowflake) để tránh tính toán lặp lại khi có thể. Tổ chức kiểm thử để hưởng lợi từ kết quả đã được đệm của các truy vấn trước đó.
  • Lập lịch gom nhóm kiểm thử: Lên lịch các bộ kiểm thử nặng vào giờ thấp điểm hoặc ngoài khung vận hành sản xuất để giảm tác động lên tải công việc của kho dữ liệu.

Kết luận

Các bài kiểm thử dbt là cách mạnh mẽ để đảm bảo chất lượng dữ liệu cao, tự động hóa các kiểm tra xác thực và phát hiện vấn đề sớm trong pipeline chuyển đổi của bạn. Kết hợp kiểm thử chung và tùy chỉnh giúp tạo nên các quy trình dữ liệu vững chắc và dễ bảo trì.

Tìm hiểu thêm về dbt trong khóa học Nhập môn dbt hoặc hướng dẫn dbt của chúng tôi.

Câu hỏi thường gặp về kiểm thử dbt

Kiểm thử unique trong dbt là gì?

Trong dbt (data build tool), kiểm thử unique đảm bảo tất cả giá trị trong một cột xác định là khác nhau, tức không có mục trùng lặp.

Bốn kiểm thử chung mà dbt cung cấp là gì?

dbt có bốn bài kiểm thử tích hợp sẵn: not_null, unique, accepted_values và relationships.

Một số loại kiểm thử dbt là gì?

Các loại kiểm thử trong dbt bao gồm kiểm thử chung tích hợp sẵn và kiểm thử tùy chỉnh đơn lẻ.

Austin Chia

Tác giả

Austin Chia

Tôi là Austin, một blogger và cây bút công nghệ với nhiều năm kinh nghiệm làm nhà khoa học dữ liệu và nhà phân tích dữ liệu trong lĩnh vực chăm sóc sức khỏe. Khởi đầu hành trình công nghệ với nền tảng sinh học, tôi hiện hỗ trợ những người khác thực hiện chuyển đổi tương tự thông qua blog công nghệ của mình. Niềm đam mê công nghệ đã đưa tôi đến với việc cộng tác viết cho hàng chục công ty SaaS, truyền cảm hứng cho người khác và chia sẻ trải nghiệm của bản thân.

Chủ đề

Liên quan