dbt — Từ dữ liệu thô đến Business Data Model trong DataValue

Sau Airbyte (đưa dữ liệu vào) và ClickHouse (lưu & xử lý), một vấn đề rất quan trọng xuất hiện: dữ liệu thô chưa phải là dữ liệu sẵn sàng cho quản trị. Một bảng kỹ thuật từ ERP có thể chứa hàng trăm field, nhiều khóa liên kết, nhiều trạng thái, nhiều record lịch sử và rất nhiều logic mà chỉ người hiểu hệ thống nguồn mới biết diễn giải. Business không muốn hỏi “sale_order_line.price_subtotal là bao nhiêu?” — họ hỏi “Doanh thu bao nhiêu? Gross Margin? Khách nào tăng trưởng? Sản phẩm nào đóng góp nhiều nhất? Tồn kho bao nhiêu ngày? Actual so với Target?”. Đó chính là bài toán dbt giải trong DataValue.

dbt là gì?

dbt (data build tool) giúp Data Team biến dữ liệu thô trong Data Warehouse/Analytical Database thành các mô hình dữ liệu có cấu trúc, có thể kiểm thử, tái sử dụng và quản lý như phần mềm. Trong DataValue (Odoo → Airbyte → ClickHouse → dbt → Cube → BI/AI → n8n), dbt đứng đúng giữa Raw Data và Business-ready Data. Nếu Airbyte trả lời “làm sao đưa dữ liệu vào?” và ClickHouse trả lời “dữ liệu lưu & xử lý ở đâu?”, thì dbt trả lời “làm sao biến dữ liệu đó thành mô hình mà doanh nghiệp thực sự hiểu và dùng được?”.

Tại sao dữ liệu từ Odoo chưa thể dùng trực tiếp?

Airbyte đã đưa các bảng Odoo sang ClickHouse (res_partner, sale_order, sale_order_line, product_product, product_template, account_move, account_move_line, stock_move, purchase_order, purchase_order_line). Về kỹ thuật đã có dữ liệu, nhưng về business vẫn rất “thô”. Chỉ để tính Revenue có thể phải: join Sales Order với Order Line; loại đơn hủy; xử lý discount; xử lý return; liên kết customer; liên kết product; chuẩn hóa currency; chuẩn hóa date; xác định trạng thái tính vào Actual. Nếu BI hoặc AI tự xử lý toàn bộ logic này mỗi lần truy vấn, hệ thống nhanh chóng khó kiểm soát — nên DataValue cần một lớp transformation riêng.

dbt biến Raw Data thành Business Data Model

flowchart TB
  RAW["sale_order · sale_order_line · res_partner<br/>product_product · account_move"] --> DBT["dbt"]
  DBT --> MODEL["DimCustomer · DimProduct · DimDate<br/>FactSales · FactInvoice · FactPayment"]

Business không còn phải hiểu cấu trúc kỹ thuật Odoo — họ làm việc với Customer, Product, Sales, Invoice, Payment, Inventory, Supplier. Điểm mạnh của dbt: transformation viết chủ yếu bằng SQL (ví dụ select customer_id, order_date, product_id, quantity, revenue from staging_sales where order_status = 'confirmed'), không yêu cầu xây một ETL engine mới. Nhưng dbt không chỉ “chạy SQL” — nó biến SQL transformation thành một framework có: model dependency · testing · documentation · version control · lineage · modularity. Đây là khác biệt giữa “một tập hợp SQL scripts” và “một Data Transformation Framework”.

Ba lớp model: Staging → Intermediate → Mart

BSD khuyến nghị dbt model theo nhiều lớp:

Staging — chuẩn hóa nguồn

Từ raw_res_partner, raw_sale_order… → stg_customer, stg_sales_order, stg_sales_order_line, stg_product, stg_invoice. Ở đây: đổi tên field (partner_id → customer_id, date_order → order_date), chuẩn hóa data type/date/status, loại technical columns, xử lý null, chuẩn hóa mã nghiệp vụ. Mục tiêu: dữ liệu phía sau dễ hiểu hơn.

Intermediate — business logic

stg_sales_order + stg_sales_order_line + stg_customer + stg_product → int_sales_enriched. Xử lý logic phức tạp: join nhiều bảng, enrich customer/product, tính quantity, chuẩn hóa currency, xử lý discount/cancellation, xác định transaction status — tránh nhồi toàn bộ logic vào một model cuối.

Mart — sẵn sàng cho Business

DimCustomer, DimProduct, DimSupplier, DimDate, DimOrganization + FactSales, FactPurchase, FactInventory, FactInvoice, FactPayment — lớp mà BI, Cube và AI sử dụng.

flowchart LR
  ODOO["Odoo"] --> AB["Airbyte"] --> CH["ClickHouse"] --> STG["dbt Staging"] --> INT["dbt Intermediate"] --> MART["dbt Mart"] --> CUBE["Cube"] --> BIAI["BI / AI"]

Đây là cách DataValue đi từ technical schema đến business schema.

Ví dụ: xây FactSales từ Odoo

Từ sale_order, sale_order_line, res_partner, product_product, dbt xây FactSales với field DateKey, CustomerKey, ProductKey, SalespersonKey, OrganizationKey, Quantity, GrossRevenue, Discount, NetRevenue, Cost, GrossMargin. Câu hỏi BI “Doanh thu theo Product và Customer trong 12 tháng gần nhất?” sẽ không còn phải join lại toàn bộ bảng Odoo — BI chỉ làm việc với FactSales, DimCustomer, DimProduct, DimDate. Lợi ích lớn của Data Modeling.

Không chỉ transform — còn kiểm thử, tài liệu, lineage

Một Data Model tốt không chỉ cần chạy được, mà còn phải đúng. dbt mang các thực hành software engineering vào data (analytics engineering):

Testing — kiểm tra Primary key có unique? Customer ID có null? Order status ∈ tập giá trị hợp lệ? Product có tồn tại trong DimProduct? Revenue có bất thường? Relationship Fact–Dimension có hợp lệ? (ví dụ Customer ID → Not Null, Sales Order ID → Unique, Order Status → accepted values, ProductKey → relationship to DimProduct). Nếu dữ liệu sai ở tầng này: Dashboard sai, AI sai — và khi AI đưa ra action từ dữ liệu sai, rủi ro còn lớn hơn.
Documentation — dbt giúp document model & field (mục đích/nguồn/measures của FactSales) → Data Platform bớt phụ thuộc kiến thức của vài cá nhân.
Lineage — lần vết Odoo sale_order → raw_sale_order → stg_sales_order → int_sales_enriched → FactSales → Cube Revenue → Executive Dashboard; dashboard lỗi thì lần ngược Dashboard → Metric → Fact → Transformation → Source. Rất quan trọng khi platform bước vào quy mô enterprise.
Dependency Management — platform lớn có hàng trăm models; dbt xây dependency graph (stg_customer → dim_customer → fact_sales → sales_mart) — nếu stg_customer đổi, biết những model phía sau bị ảnh hưởng; dễ quản lý hơn nhiều so với một thư mục chứa hàng trăm SQL scripts độc lập.
Version Control — triết lý cốt lõi: Analytics Engineering áp dụng software engineering vào data transformation. Transformation code quản lý bằng Git (Developer → Change dbt model → Git Commit → Code Review → Test → Deploy), tạo version history, change review, collaboration, rollback, kỷ luật Dev/Test/Prod — quan trọng nếu muốn phát triển từ một project thành một platform tái sử dụng.

Ranh giới kiến trúc

dbt không thay Airbyte — Airbyte = Move Data (Odoo → ClickHouse), dbt = Transform Data (ClickHouse Raw Data → Business Data Model). Không dùng dbt để giải quyết data ingestion; cũng không bắt Airbyte làm toàn bộ business transformation.
dbt không thay ClickHouse — dbt không phải database; ClickHouse mới là nơi lưu & xử lý. dbt chỉ tạo transformation logic để ClickHouse thực thi (dbt → generates transformation logic → ClickHouse executes it). ClickHouse = Engine, dbt = Transformation Framework — hai công nghệ bổ sung nhau.
dbt cũng chưa phải Semantic Layer — sau dbt có FactSales, DimCustomer, DimProduct, DimDate, nhưng vẫn còn câu hỏi Revenue chính xác là metric nào? Gross Margin tính thế nào? Active Customer là ai? Customer hierarchy ra sao? — thuộc Semantic & Metrics Layer (Cube): ClickHouse → dbt → Cube → BI/AI. Vậy dbt = Data Model, Cube = Business Meaning — separation rất quan trọng.

Ví dụ hoàn chỉnh: Revenue, Inventory & Customer 360

Revenue Analytics (“Revenue đang tăng hay giảm?”): Odoo (Customer → Sales Order → Delivery → Invoice) → Airbyte → ClickHouse → dbt (raw → Staging → Intermediate → FactSales, DimCustomer, DimProduct, DimDate) → Cube (Revenue, Gross Margin, Quantity, Average Selling Price, Customer, Product, Region, Period) → BI (Revenue by Month/Product/Customer/Region) → AI ("tại sao doanh thu miền Nam giảm?" — dùng trusted business data thay vì đọc raw Odoo tables).

Inventory: Odoo (stock_move, stock_quant, product_product, warehouse) → dbt (FactInventoryMovement, FactInventoryBalance, DimProduct, DimWarehouse, DimDate) → Cube (Inventory On Hand, Inventory Value, Inventory Turnover, Days of Inventory, Stock-out Risk) → BI/AI. Customer 360: tương lai không chỉ Odoo mà Odoo, CRM, eCommerce, Marketing, Customer Service, Digital Events → Airbyte → ClickHouse → dbt (DimCustomer + FactSales + FactInteraction + FactService + FactDigitalBehavior → Customer 360 Model) → {BI → Customer Analytics, AI → Churn Prediction, n8n → Customer Action}. dbt là lớp giúp nhiều source khác nhau trở thành một business model thống nhất.

Tại sao dbt rất quan trọng với AI?

AI Agent không nên được yêu cầu tự đọc hàng nghìn raw columns (account_move, account_move_line, sale_order, sale_order_line, stock_move) và tự suy đoán đâu là revenue? đâu là cost? đâu là customer? trạng thái nào hợp lệ? — rủi ro sai rất cao. Kiến trúc tốt hơn: Raw Data → dbt → Trusted Business Model → Cube → AI Agent. AI làm việc trên dữ liệu đã cleaned → modeled → tested → semantically defined — tăng đáng kể khả năng tạo Trusted AI.

Giá trị của dbt & “Data Product”

Nếu bỏ dbt, DataValue vẫn có thể chạy (Airbyte vẫn đưa dữ liệu vào, BI vẫn query). Nhưng rất nhanh sẽ gặp Dashboard A → SQL Logic A, Dashboard B → SQL Logic B, AI → SQL Logic C, Application → Logic D — business logic phân tán. dbt tạo một lớp trung gian chuẩn Raw Sources → dbt → Trusted Business Data → BI/Semantic/AI, mang lại: Standardization (nhiều nguồn về một cấu trúc thống nhất) · Reusability (một model xây một lần, dùng nhiều nơi) · Data Quality (models được kiểm thử) · Maintainability (chia module, quản lý dependency) · Governance (documentation, lineage, version control) · AI Readiness (AI không làm việc trực tiếp trên raw data).

Quan trọng hơn, dbt giúp DataValue chuyển từ “Data Warehouse” (chủ yếu chứa tables) sang Data Product. Ví dụ Sales Data Product (Customer, Product, Revenue, Margin, Quantity, Sales Trend + Business Definitions + Quality Tests + Documentation + Lineage), hoặc Customer 360 Data Product, Inventory Data Product. dbt đóng gói data transformation thành những model có cấu trúc, chất lượng và tái sử dụng — dữ liệu trở thành một tài sản có thể tiêu thụ được thay vì chỉ là một tập hợp bảng.

dbt nằm ở đâu trong DataValue?

flowchart TB
  ODOO["ODOO 19 · Operate"] --> AB["AIRBYTE · Ingest"] --> CH["CLICKHOUSE · Store & Process"]
  CH --> DBT["dbt · Transform · Model · Test"] --> CUBE["CUBE · Define & Understand"]
  CUBE --> BI["BI · Analyze"] & AI["AI · Reason"] & API["APIs"]
  AI --> N8N["n8n · Automate & Act"] --> ACT["Business Action"]

Role: Odoo Operate · Airbyte Ingest · ClickHouse Store & Process · dbt — Transform, Model & Test · Cube Define & Understand · BI Analyze · AI Reason · n8n Automate & Act.

Kết luận: từ Raw Data đến Trusted Data

Nếu Airbyte giải quyết Data Movement và ClickHouse giải quyết Analytical Storage & Processing, thì dbt giải quyết Trusted Data Modeling — biến Technical Tables → Business Models, và tiếp tục Raw Data → Clean Data → Modeled Data → Tested Data → Trusted Data. Chỉ khi có Trusted Data, những lớp phía trên mới thực sự tạo giá trị; nếu dữ liệu không được mô hình hóa đúng, các lớp phía trên chỉ làm sai nhanh hơn.

dbt không tạo Dashboard, không phải database, không phải Semantic Layer, cũng không phải AI — nhưng nó giải một vấn đề cực kỳ nền tảng: biến dữ liệu kỹ thuật thành một business data foundation đáng tin cậy. Vì vậy dbt là cầu nối từ dữ liệu thô đến dữ liệu mà doanh nghiệp có thể tin tưởng và sử dụng — bước cần thiết để dữ liệu tiếp tục hành trình: Data → Trusted Model → Meaning → Insight → Intelligence → Action → Value.

Tài liệu dbt đầy đủ (mục sản phẩm) model & ref(), materialization, Jinja & macros, kiểm thử, tài liệu & lineage, CI/CD — hướng dẫn chi tiết dbt.