ClickHouse — Analytical Data Foundation của DataValue

Trong bài về Airbyte, chúng ta đã trả lời câu hỏi đầu tiên của một Data Platform: làm thế nào đưa dữ liệu từ hệ thống vận hành vào nền tảng một cách ổn định và mở rộng được? Ngay sau đó là câu hỏi quan trọng hơn:

Dữ liệu sau khi rời khỏi ERP sẽ được lưu trữ và xử lý ở đâu để phục vụ Analytics và AI?

Đó là vai trò của ClickHouse. Nếu Airbyte là cánh cửa đưa dữ liệu vào DataValue, thì ClickHouse là Analytical Data Foundation của nền tảng.

flowchart LR
  ODOO["Odoo 19"] --> AB["Airbyte"] --> CH["ClickHouse"] --> DBT["dbt"] --> CUBE["Cube"] --> BIAI["BI / AI"] --> N8N["n8n"]

ClickHouse là gì?

ClickHouse là một hệ quản trị cơ sở dữ liệu dạng cột (column-oriented DBMS) được thiết kế cho OLAP — Online Analytical Processing. Điểm mấu chốt nằm ở hai chữ Analytical Processing.

Một ERP như Odoo được thiết kế chủ yếu để xử lý giao dịch: tạo Sales Order, cập nhật Customer, ghi nhận Invoice, nhập/xuất Inventory, tạo Purchase Order, ghi Payment — đó là transactional workload.

DataValue lại cần trả lời những câu hỏi hoàn toàn khác:

• Doanh thu 36 tháng gần nhất theo Product × Customer × Region?
• Gross Margin thay đổi thế nào giữa các tháng?
• Top 1.000 khách hàng đóng góp bao nhiêu phần trăm doanh thu?
• Inventory Turnover của từng nhóm sản phẩm biến động ra sao?
• Có pattern bất thường nào trong hàng trăm triệu giao dịch?

Đó là analytical workload — và ClickHouse được xây dựng cho đúng loại bài toán này.

Tại sao DataValue không phân tích trực tiếp trên Odoo?

Odoo Community 19 dùng PostgreSQL làm database vận hành. Về kỹ thuật, ta hoàn toàn có thể nối BI thẳng vào đó — và với một hệ thống nhỏ, vài báo cáo đơn giản, cách này chạy được. Nhưng DataValue không được thiết kế chỉ để tạo vài dashboard cho Odoo; nó hướng tới một Data & AI Platform độc lập với operational systems. Vì vậy kiến trúc tách đôi:

flowchart TB
  subgraph OP["⚙️ OPERATIONAL WORLD"]
    ODOO["Odoo Community 19"] --> PG["PostgreSQL"] --> AB["Airbyte"]
  end
  subgraph AN["📈 ANALYTICAL WORLD"]
    CH["ClickHouse"] --> DBT["dbt"] --> CUBE["Cube"]
    CUBE --> BI["BI"] & AI["AI"]
  end
  AB --> CH

💡 Điều này có nghĩa gì với bạn?

Odoo được tối ưu để vận hành doanh nghiệp; ClickHouse được tối ưu để phân tích dữ liệu doanh nghiệp. Hai workload không còn phải cạnh tranh trên cùng một database.

OLTP và OLAP khác nhau thế nào?

Đây là nền tảng để hiểu vì sao DataValue cần ClickHouse.

OLTP — Online Transaction Processing: ERP thực hiện rất nhiều transaction nhỏ (Create Order, Update Customer, Post Invoice, Receive Goods, Update Stock, Record Payment). Mỗi giao dịch chạm tới một lượng record nhỏ; database cần phản hồi nhanh và đảm bảo toàn vẹn. PostgreSQL rất hợp cho loại này.

OLAP — Online Analytical Processing: phân tích lại đặt câu hỏi kiểu “quét 500 triệu Sales Line, GROUP BY năm/tháng/vùng/khách/sản phẩm/kênh, rồi SUM Revenue, SUM Quantity, AVG Price, tính Margin”. Đây là một workload hoàn toàn khác — và ClickHouse được thiết kế đặc biệt cho nó.

	OLTP	OLAP
Bài toán	Ghi/sửa giao dịch	Quét & tổng hợp dữ liệu lớn
Phạm vi mỗi truy vấn	Ít record	Hàng triệu–tỷ record
Tối ưu cho	Tính toàn vẹn, độ trễ ghi thấp	Aggregation, scan cột
Trong DataValue	PostgreSQL (Operational DB)	ClickHouse (Analytical DB)

ClickHouse và PostgreSQL không phải “database A hay B” — chúng có vai trò kiến trúc khác nhau.

Column-oriented — vì sao ClickHouse lưu dữ liệu theo cột?

Đây là một trong những đặc tính quan trọng nhất. Giả sử có bảng Sales, và câu hỏi BI là “Tổng Revenue theo Region năm 2026?”. Về logic ta chủ yếu cần Date, Region, Revenue — không nhất thiết đọc Customer, Product, Quantity, Cost…

Với column-oriented storage, dữ liệu từng cột được tổ chức để engine chỉ đọc đúng những cột cần cho truy vấn:

flowchart LR
  Q["Truy vấn:<br/>Revenue theo Region"] --> R["Chỉ đọc cột<br/>Date · Region · Revenue"]
  R -.bỏ qua.-> X["Customer · Product · Quantity · Cost"]

Với analytical workload thường xuyên scan và aggregate một số cột trên lượng record lớn, đây là lợi thế lớn. ClickHouse còn dùng vectorized query execution và nhiều kỹ thuật tối ưu khác để đạt hiệu năng cao.

Compression — dữ liệu lớn nhưng không tốn storage tương ứng

Kiến trúc theo cột còn mang lại một lợi ích: nén dữ liệu. Giá trị trong cùng một cột thường rất giống nhau — ví dụ cột Country toàn “Vietnam”, cột Status phần lớn “Completed”. Khi các giá trị tương tự nằm gần nhau, database nén hiệu quả hơn nhiều.

Điều này đặc biệt quan trọng khi DataValue tích lũy lịch sử: 1 năm → 3 năm → 5 năm → nhiều năm. Một Data Platform không chỉ xử lý dữ liệu hôm nay; giá trị lớn của nó nằm ở historical data để phân tích xu hướng, forecasting và AI.

ClickHouse rất phù hợp với Aggregation

Airbyte đã đưa 200 triệu Sales Order Line vào ClickHouse. Ban điều hành muốn biết Revenue theo tháng, vùng, nhóm khách và nhóm sản phẩm:

flowchart TB
  A["200.000.000<br/>Sales Transactions"] --> CH["ClickHouse"]
  CH --> G["SUM Revenue · SUM Quantity<br/>GROUP BY Month · Region · Customer · Product"]
  G --> RES["Analytical Result"]

Khi dữ liệu tăng lên hàng trăm triệu hay hàng tỷ dòng, khác biệt giữa một operational database và một analytical database ngày càng rõ.

Không chỉ Batch — ClickHouse còn hợp dữ liệu cập nhật nhanh

DataValue không nhất thiết chỉ chạy báo cáo cuối ngày. Một số use case cần dữ liệu tươi hơn — ví dụ Sales Monitoring (New Sales → Airbyte → ClickHouse → Dashboard) hay tương lai là Events/Streams → ClickHouse → Near-real-time Analytics. ClickHouse được dùng rộng rãi cho analytical workload cần ingestion tốc độ cao và query độ trễ thấp trên dữ liệu mới, mở ra nhiều use case ngoài BI truyền thống: Operational Analytics · Event Analytics · Customer Behavior · Monitoring · Observability · IoT Analytics.

ClickHouse không thay thế dbt

Một ranh giới kiến trúc quan trọng. Sau Airbyte, ta có dữ liệu gần với source (res_partner, sale_order, sale_order_line, product_product, account_move, stock_move…). ClickHouse lưu trữ và xử lý hiệu quả, nhưng các bảng này vẫn phản ánh cấu trúc kỹ thuật của Odoo. Business không hỏi “account_move_line.amount_currency là bao nhiêu?” — họ hỏi “Revenue tháng này là bao nhiêu?”. Đó là lý do có dbt, biến raw/staging thành DimCustomer, DimProduct, DimDate, FactSales, FactPurchase, FactInventory, FactFinance.

• ClickHouse = Store & Process
• dbt = Transform & Model (xem tài liệu dbt)

ClickHouse cũng không thay thế Cube

Sau dbt ta có analytical model tốt, nhưng vẫn còn vấn đề ngữ nghĩa. Nếu FactSales có GrossAmount, Discount, ReturnAmount, Quantity, Cost — thì “Net Revenue” = Gross − Discount − Returns, và “Gross Margin” = Net Revenue − Cost. Những định nghĩa đó phải được dùng nhất quán bởi Power BI, Superset, AI Agent, Application, API. Đó là nhiệm vụ của Cube Semantic Layer.

DataValue giữ separation rất rõ:

• ClickHouse — Data
• dbt — Model
• Cube — Meaning

Ví dụ hoàn chỉnh: Sales Analytics từ Odoo

Theo một Sales Order từ lúc phát sinh đến khi lên Dashboard:

1. Odoo tạo giao dịch — Customer → Quotation → Sales Order → Delivery → Invoice → Payment (PostgreSQL lưu dữ liệu vận hành).
2. Airbyte đưa dữ liệu sang ClickHouse (Data Movement).
3. ClickHouse trở thành analytical store, tích lũy Customer/Product/Sales/Invoice/Inventory/Payment và lịch sử — từ 1 triệu → 10 triệu → 100 triệu → 1 tỷ+ dòng mà không cần quay lại operational database của ERP.
4. dbt dựng Business Data Model (DimCustomer/DimProduct/DimDate, FactSales/FactInvoice/FactPayment).
5. Cube định nghĩa Revenue, Gross Margin, Quantity, Average Selling Price, Active Customer, Customer Segment, Product Category, Region, Period.
6. BI phân tích: Revenue Trend, Revenue by Customer/Product/Region, Margin Analysis, Customer Analysis.
7. AI hỏi “Tại sao Gross Margin của Product Group A giảm trong 3 tháng gần đây?” — làm việc trên một Data Foundation đã chuẩn hóa, có business semantics, thay vì truy vấn thẳng database Odoo.

Ví dụ khác: Inventory Analytics

Odoo có hàng triệu stock movement. Management không xem từng transaction — họ muốn biết: tồn kho hiện tại, sản phẩm tồn quá lâu, Days of Inventory, item nguy cơ stock-out, Inventory Turnover tăng hay giảm.

flowchart LR
  ODOO["Odoo Inventory"] --> AB["Airbyte"] --> CH["ClickHouse"] --> DBT["dbt"] --> CUBE["Cube"] --> INV["Inventory Intelligence"]

ClickHouse cho phép giữ và phân tích lượng lớn lịch sử stock movement mà không biến ERP database thành analytical engine.

Ví dụ quan trọng hơn: Customer 360

Hôm nay DataValue mới lấy dữ liệu từ Odoo. Nhưng tương lai có thể gộp nhiều nguồn:

flowchart TB
  S1["Odoo Sales"] & S2["CRM"] & S3["eCommerce"] & S4["Customer Service"] & S5["Marketing"] & S6["Web/App Events"] --> AB["Airbyte"] --> CH["ClickHouse"]

Lúc này ClickHouse không còn chỉ chứa “Odoo data” — nó trở thành nền tảng để xây Customer 360: Transaction History, Product Behavior, Marketing Interaction, Service History, Digital Behavior. Từ đó AI tìm Churn Risk · Next Best Product · Customer Value · Purchase Pattern · Recommendation. Đây là lúc giá trị của việc tách Data Platform khỏi ERP trở nên rất rõ.

Tại sao không dùng PostgreSQL cho tất cả?

Câu trả lời không nên là “ClickHouse tốt hơn PostgreSQL” — cách nói đó không chính xác. Câu trả lời đúng: chúng được tối ưu cho những workload khác nhau.

PostgreSQL — hợp với	ClickHouse — hợp với
ERP · CRM · Business Applications	Analytics · Aggregation
Transaction Processing	Large-scale Data · Historical Analysis
Operational Workloads	High-performance OLAP

Đây không phải cạnh tranh giữa hai database — đây là separation of workloads.

Vì sao ClickHouse phù hợp với Open Source DataValue?

DataValue hướng đến kiến trúc bắt đầu gọn nhưng mở rộng theo nhu cầu. ClickHouse hợp với định hướng này vì ba lý do:

Open Source

Có bản mã nguồn mở, self-host được — phù hợp định hướng Open Source và cho doanh nghiệp nhiều lựa chọn deployment.

Analytical-first

Không cố biến operational database thành Data Warehouse; chọn đúng analytical engine ngay từ đầu.

Scale

Bắt đầu với một Odoo instance, nhưng kiến trúc không giới hạn ở đó — sẵn sàng cho ERP/CRM/eCommerce/IoT/External Data về sau.

Giá trị của ClickHouse đối với DataValue

Nhìn ClickHouse chỉ như “một database” là bỏ lỡ phần quan trọng nhất; giá trị của nó nằm ở vị trí trong toàn bộ kiến trúc DataValue:

• Tách Analytics khỏi Operational Systems — ERP lo vận hành, Data Platform lo phân tích.
• Tạo một Analytical Data Foundation chung — thay vì BI/AI/App/Data Science mỗi cái tự nối về Odoo, tất cả dùng chung ClickHouse.
• Tích lũy Historical Data — cho Trend, Forecast, Pattern, Benchmark, AI/ML.
• Chuẩn bị nền tảng cho AI — AI càng phát triển càng cần nhiều trusted historical data; ClickHouse đưa DataValue đi từ Reporting → Analytics → Intelligence.

ClickHouse nằm ở đâu trong DataValue?

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

Thành phần	Nhiệm vụ
Odoo	Operate
Airbyte	Ingest
ClickHouse	Store & Process
dbt	Transform & Model
Cube	Define & Understand
BI	Analyze
AI	Reason
n8n	Automate & Act

ClickHouse giúp DataValue không phụ thuộc một ERP

Ngày đầu là Odoo → Airbyte → ClickHouse. Ngày mai có thể là Odoo · Dynamics 365 · Salesforce · Other DBs · Applications → Airbyte → ClickHouse. Hệ thống nguồn thay đổi, nhưng kiến trúc phía sau vẫn duy trì ClickHouse → dbt → Cube → BI/AI → n8n. Điều này biến ClickHouse từ một database thành một thành phần của Enterprise Analytical Architecture.

Từ Data Storage đến Data Value

ClickHouse không phải nơi cuối cùng của dữ liệu — nó là nền móng để các lớp phía trên tạo ra giá trị:

Operational Data → Airbyte → ClickHouse (Analytical Data Foundation) → dbt (Trusted Data Models) → Cube (Business Semantics) → BI (Insight) → AI (Intelligence) → n8n (Action).

Nếu Airbyte trả lời “Làm thế nào đưa dữ liệu vào DataValue?”, thì ClickHouse trả lời “Dữ liệu sẽ sống ở đâu để được phân tích ở quy mô lớn?”. Mục tiêu cuối không phải là lưu được nhiều dữ liệu hơn, mà là tạo một nền tảng đủ nhanh, đủ mở, đủ khả năng mở rộng để dữ liệu tiếp tục hành trình: Data → Meaning → Insight → Intelligence → Action → Value.

Ghi chú

Biên soạn & diễn giải tiếng Việt bởi BSD Insight theo tài liệu chính thức của ClickHouse; ví dụ được khái quát hóa cho ngăn xếp DataValue, không phải dịch nguyên văn. Muốn dựng nền phân tích Odoo → Airbyte → ClickHouse cho doanh nghiệp bạn? Đặt tư vấn triển khai.