Tích hợp dữ liệu & CDP

Bài trước đã cho ra golden record cùng bảng cross-reference. Nhưng biết ông Nguyễn Văn A là một người duy nhất mới chỉ là cái khung. Muốn có hồ sơ 360 dùng được, phải kéo về quanh khung đó toàn bộ dấu vết của ông: số dư ở core, dư nợ thẻ, khoản vay, mỗi lần mở app, mỗi cuộc gọi tổng đài, mỗi email đã click. Bài này nói về tích hợp dữ liệu (data integration) — gom dữ liệu rải rác ở hàng chục hệ thống thành một hồ sơ thống nhất — và về CDP (Customer Data Platform), lớp công nghệ chuyên trị bài toán này.

1. Bức tranh nguồn dữ liệu ở một ngân hàng

Dữ liệu về một khách hàng nằm phân tán ở rất nhiều hệ thống, mỗi hệ thống một công nghệ, một chu kỳ cập nhật, một cách định danh:

Ba điểm khiến việc gom lại khó: (1) định dạng và chu kỳ khác nhau — core chốt theo ngày, app phát sự kiện theo mili-giây; (2) khoá định danh khác nhau — lý do phải hợp nhất danh tính trước; (3) bản chất khác nhau — có thứ là trạng thái (số dư hiện tại), có thứ là sự kiện (một lần click). Kiến trúc tích hợp phải xử lý cả hai.

2. Hai mẫu tích hợp: batch và streaming

2.1. Batch ETL/ELT vào kho / lakehouse

Mẫu cổ điển và vẫn là xương sống: định kỳ (thường hằng đêm) rút dữ liệu từ nguồn, đưa về một kho tập trung để xử lý.

• ETL (Extract–Transform–Load): biến đổi trước rồi mới nạp — hợp với data warehouse truyền thống, schema chặt.
• ELT (Extract–Load–Transform): nạp thô trước, biến đổi sau ngay trong kho bằng SQL — mẫu thịnh hành với cloud warehouse và lakehouse (kiến trúc lakehouse), nơi lưu trữ rẻ và compute co giãn khiến việc "đổ hết vào rồi tính" trở nên kinh tế.

Batch mạnh ở khối lượng lớn, logic phức tạp, tính toán lịch sử (số dư trung bình 90 ngày, tổng chi tiêu năm). Điểm yếu: độ trễ — hồ sơ 360 luôn "cũ" tới cuối ngày hôm qua. Đủ cho báo cáo và phân khúc, không đủ cho phản ứng tức thời.

2.2. Streaming / event-driven

Với kênh số và giao dịch, ta muốn hồ sơ cập nhật gần thời gian thực: khách vừa xem trang vay mua nhà 30 giây trước, hệ thống nên biết ngay. Mẫu này dựa trên event streaming (Kafka và tương tự): mỗi hành động phát ra một event chảy qua đường ống, được xử lý và cập nhật hồ sơ liên tục — nền cho cá nhân hoá thời gian thực.

2.3. CDC — bắt thay đổi từ core

Làm sao đưa dữ liệu core (số dư, tài khoản) vào luồng realtime mà không "hành" hệ core mỗi giờ bằng full-export? Câu trả lời là CDC (Change Data Capture): đọc transaction log của cơ sở dữ liệu nguồn để bắt từng thay đổi (insert/update/delete) ngay khi xảy ra, rồi phát thành event. CDC biến một core banking "chốt theo ngày" thành nguồn sự kiện gần realtime, ít xâm lấn, không cần quét lại toàn bảng. Đây là cầu nối quan trọng giữa thế giới batch (core) và streaming (hồ sơ 360).

Thực tế hầu hết ngân hàng dùng kiến trúc lai (hybrid): batch cho khối lượng lớn và lịch sử; streaming/CDC cho các tín hiệu cần độ tươi cao.

3. CDP — Customer Data Platform

3.1. CDP là gì

CDP (Customer Data Platform) là nền tảng đóng gói sẵn để: thu thập dữ liệu và sự kiện khách từ mọi nguồn, hợp nhất thành hồ sơ thống nhất, rồi kích hoạt (activation) — đẩy hồ sơ/phân khúc sang công cụ kênh (marketing, app, quảng cáo). Khác với tự xây từng mảnh: CDP đóng gói cả ba năng lực thành sản phẩm, hướng tới người dùng marketing/nghiệp vụ chứ không chỉ kỹ sư dữ liệu.

3.2. CDP khác CRM và CDW thế nào

Ba khái niệm hay bị lẫn:

Nói gọn: CRM ghi lại ta tương tác với khách thế nào; CDW/lakehouse là nơi phân tích mọi thứ; CDP chuyên hợp nhất hành vi khách và kích hoạt nó ra kênh để làm marketing/cá nhân hoá. CRM thường là một nguồn đổ vào CDP, không thay thế được nhau.

3.3. CDP đóng gói vs composable CDP

Hai hướng triển khai:

• CDP đóng gói (packaged): sản phẩm trọn gói (Segment, Adobe RT-CDP, Tealium...) tự lưu bản sao dữ liệu bên trong. Nhanh triển khai, thân thiện marketer; nhưng tạo thêm một silo dữ liệu khách nữa, khó tuỳ biến, và việc sao dữ liệu nhạy cảm ra ngoài là vấn đề tuân thủ lớn với ngân hàng.
• Composable CDP (xu hướng): không sao dữ liệu ra kho riêng, mà xây trực tiếp trên warehouse/lakehouse đã có làm nguồn sự thật duy nhất. Các năng lực (hợp nhất, xây segment, activation/reverse ETL) là những lớp lắp ghép chạy trên kho đó. Ưu điểm: dữ liệu ở lại trong vành đai ngân hàng, một nguồn sự thật, tận dụng governance sẵn có.

Với ngân hàng, composable thường hợp lý hơn vì lý do chủ quyền dữ liệu và tuân thủ: hồ sơ 360 ở nguyên trong lakehouse nội bộ, chỉ segment/tín hiệu cần thiết mới được đẩy ra công cụ kênh.

4. Mô hình dữ liệu hồ sơ 360

Một hồ sơ 360 thực chất gồm ba lớp:

1. Hồ sơ (profile / attributes): thuộc tính tương đối tĩnh — golden record, nhân khẩu, sản phẩm đang có, phân khúc. Trả lời "khách này là ai".
2. Sự kiện / hành vi (events): dòng thời gian các hành động — đăng nhập, giao dịch, click, cuộc gọi. Bất biến (append-only), khối lượng lớn. Trả lời "khách đã làm gì".
3. Thuộc tính tính toán (computed attributes / features): giá trị suy ra từ sự kiện + hồ sơ — "tổng chi tiêu thẻ 30 ngày", "số ngày kể từ giao dịch gần nhất", "xu hướng rời bỏ". Nguyên liệu cho phân khúc và mô hình.

4.1. Batch features vs realtime features

Đặc trưng chia làm hai loại theo cách và tần suất tính:

• Batch features: tính định kỳ trên toàn lịch sử (tổng chi tiêu 12 tháng, số dư trung bình 90 ngày). Chính xác, nặng, cập nhật theo lô — đủ cho phân khúc và mô hình chấm điểm.
• Realtime features: tính ngay khi sự kiện tới (khách vừa xem trang vay 3 lần trong 5 phút). Cần cho phản ứng tức thời trong phiên.

4.2. Feature store — nhắc ngắn

Khi cùng một đặc trưng ("tổng chi tiêu 30 ngày") được cả đội phân tích lẫn mô hình dùng lại, ta cần định nghĩa một lần và phục vụ nhất quán cho cả training (batch) lẫn serving (online) — đó là feature store. Vai trò: tránh mỗi nhóm tự tính lệch nhau, và bảo đảm đặc trưng lúc huấn luyện khớp lúc chạy thật (chống training–serving skew).

5. Chất lượng & quản trị khi tích hợp

Gom dữ liệu từ chục nguồn mà không kỷ luật thì hồ sơ 360 chỉ là "rác gom về một chỗ đẹp hơn". Vài trụ cột bắt buộc:

• Chuẩn hoá (standardization): thống nhất đơn vị, mã, định dạng ngày, tiền tệ giữa các nguồn trước khi hợp nhất.
• Khử trùng (deduplication): đã bàn ở hợp nhất danh tính — bước này lỏng thì mọi số liệu 360 đều sai.
• Lineage (truy vết nguồn gốc): với mỗi giá trị trong hồ sơ 360, phải trả lời "đến từ nguồn nào, qua biến đổi nào, lúc nào" — bắt buộc cho audit và tuân thủ.
• Độ tươi (freshness / SLA): mỗi thuộc tính có yêu cầu độ trễ khác nhau — số dư nên gần realtime, nghề nghiệp cập nhật hằng tháng là đủ; cần theo dõi SLA và cảnh báo khi pipeline trễ.
• Kiểm thử chất lượng: ràng buộc null, miền giá trị, nhất quán tham chiếu — gắn với chất lượng dữ liệu. Hồ sơ 360 "đúng nhưng cũ" hoặc "đầy đủ nhưng sai" đều vô dụng.

6. Kích hoạt: reverse ETL

Hồ sơ 360 nằm im trong lakehouse thì chưa tạo giá trị. Activation là bước cuối: đưa hồ sơ/segment ra nơi hành động xảy ra. Cơ chế phổ biến của composable CDP là reverse ETL — ngược chiều ETL thường: thay vì kéo dữ liệu từ nguồn vào kho, nó đẩy dữ liệu đã tính từ kho ra công cụ vận hành:

• Danh sách segment → email/SMS marketing để chạy chiến dịch.
• Thuộc tính (điểm xu hướng, sản phẩm gợi ý) → app/web để cá nhân hoá màn hình.
• Cờ ưu tiên → contact center để nhân viên biết khách VIP đang gọi.

Reverse ETL "đóng vòng lặp": dữ liệu được hợp nhất, làm giàu trong kho, rồi quay lại tác động đến trải nghiệm khách ở kênh — cách composable CDP kích hoạt mà không cần kho khách riêng.

7. Ví dụ: xây bảng đặc trưng khách bằng SQL

Trong sandbox có customers, accounts, transactions. Ta có thể minh hoạ bước hợp nhất nguồn → đặc trưng khách ngay bằng SQL. Lưu ý một cạm bẫy kinh điển: nếu JOIN thẳng accounts rồi transactions rồi SUM(balance), số dư sẽ bị nhân bản (fan-out) theo số giao dịch. Cách đúng là gộp riêng từng nguồn trong CTE trước khi ghép:

-- ▶ Chạy được
WITH bal AS (
  SELECT customer_id,
         COUNT(*)      AS n_accounts,
         SUM(balance)  AS total_balance
  FROM accounts
  GROUP BY customer_id
),
tx AS (
  SELECT a.customer_id,
         COUNT(t.id)      AS n_tx,
         SUM(t.amount)    AS total_tx_amount,
         MAX(t.created_at) AS last_tx_at
  FROM accounts a
  JOIN transactions t ON t.account_id = a.id
  GROUP BY a.customer_id
)
SELECT c.id,
       c.full_name,
       c.city,
       COALESCE(b.n_accounts, 0)                    AS n_accounts,
       ROUND(COALESCE(b.total_balance, 0)::numeric, 2) AS total_balance,
       COALESCE(x.n_tx, 0)                          AS n_tx,
       ROUND(COALESCE(x.total_tx_amount, 0)::numeric, 2) AS total_tx_amount,
       x.last_tx_at
FROM customers c
LEFT JOIN bal b ON b.customer_id = c.id
LEFT JOIN tx  x ON x.customer_id = c.id
ORDER BY total_balance DESC
LIMIT 50;

Mỗi dòng là một hồ sơ 360 thu nhỏ: một khách + các đặc trưng gộp từ nhiều tài khoản và giao dịch. Nếu chỉ cần một đặc trưng đơn giản — tổng số dư mỗi khách để phân khúc theo tài sản:

-- ▶ Chạy được
SELECT c.id,
       c.full_name,
       COUNT(a.id)                                  AS n_accounts,
       ROUND(COALESCE(SUM(a.balance), 0)::numeric, 2) AS total_balance
FROM customers c
LEFT JOIN accounts a ON a.customer_id = c.id
GROUP BY c.id, c.full_name
ORDER BY total_balance DESC
LIMIT 20;

Trên thực tế, những đặc trưng như thế này được tính định kỳ (batch) hoặc realtime, lưu vào feature store, rồi làm đầu vào cho phân khúc khách hàng và các mô hình gợi ý.

Use case thực tế

Bối cảnh NCB. Sau khi có golden record (~1,45 triệu khách duy nhất, xem bài trước), mục tiêu là dựng hồ sơ 360 vận hành được phục vụ cá nhân hoá và kích hoạt chiến dịch. Bốn nguồn ưu tiên: core banking (số dư, tiền gửi, sản phẩm), thẻ (giao dịch, dư nợ thẻ), CRM (tương tác sale), và kênh số (event app/web/ATM).

Kiến trúc (minh hoạ, số liệu ước lượng):

1. Batch ELT hằng đêm đổ core + thẻ + CRM vào lakehouse nội bộ, biến đổi bằng SQL để ráp về golden_id.
2. CDC từ core và event stream từ app cấp tín hiệu độ tươi cao (số dư đổi, khách xem sản phẩm).
3. Ba lớp dữ liệu: profile + events (~vài chục triệu sự kiện/ngày từ kênh số) + features (khoảng 120 đặc trưng batch như chi tiêu 30/90 ngày, số dư trung bình, ngày kể từ giao dịch gần nhất; cùng nhóm nhỏ feature realtime trong phiên).
4. Composable trên lakehouse: không sao dữ liệu ra CDP đóng gói riêng — dữ liệu nhạy cảm ở lại vành đai ngân hàng; chỉ segment và tín hiệu cần thiết được reverse ETL ra email/SMS và app.
5. Quản trị: mỗi thuộc tính có nhãn nguồn (lineage) và SLA độ tươi; kiểm thử chất lượng chặn dữ liệu bẩn.

Kết quả ước lượng: độ tươi số dư giảm từ "cuối ngày hôm trước" xuống dưới ~5 phút cho tài khoản có CDC; độ phủ đặc trưng (khách có đủ bộ feature lõi để phân khúc) đạt ~92%; thời gian tạo một segment và đẩy ra kênh giảm từ vài ngày (xin trích xuất thủ công) xuống dưới 1 giờ nhờ reverse ETL tự phục vụ. Nhờ nền này, chiến dịch không còn gửi trùng và nhắm đúng theo hành vi gần thời gian thực.

(Các con số trên là ước lượng minh hoạ để hình dung độ lớn, không phải số liệu công bố của NCB.)

Ghi nhớ

• Sau hợp nhất danh tính là tích hợp dữ liệu: kéo toàn bộ dấu vết khách (core, thẻ, vay, tiền gửi, CRM, kênh số, tổng đài, marketing, dữ liệu ngoài/open banking) về quanh golden record.
• Hai mẫu tích hợp, thường lai: batch ETL/ELT vào warehouse/lakehouse cho khối lượng và lịch sử; streaming/event-driven cho độ tươi, dẫn tới cá nhân hoá realtime. CDC đọc log core để biến core "chốt theo ngày" thành nguồn sự kiện gần realtime.
• CDP đóng gói ba việc: thu thập sự kiện → hợp nhất hồ sơ → kích hoạt ra kênh. Khác CRM (ghi tương tác nhân viên) và CDW (nơi phân tích); CRM thường là một nguồn của CDP.
• Composable CDP (xu hướng): xây trực tiếp trên lakehouse thay vì sao dữ liệu ra kho riêng — hợp ngân hàng vì chủ quyền dữ liệu và tuân thủ.
• Hồ sơ 360 = ba lớp: profile (ai) + events (đã làm gì) + features (đặc trưng tính toán). Feature chia batch (định kỳ, nặng) và realtime (trong phiên); feature store định nghĩa một lần, phục vụ nhất quán train/serving.
• Chất lượng & quản trị: chuẩn hoá, khử trùng (identity resolution), lineage, độ tươi/SLA, kiểm thử — gắn với chất lượng dữ liệu.
• Reverse ETL đóng vòng lặp: đẩy segment/thuộc tính từ kho ra công cụ kênh (marketing, app, contact center) để tạo giá trị.
• Cạm bẫy SQL: join accounts rồi transactions rồi SUM(balance) sẽ nhân bản số dư (fan-out) — gộp từng nguồn trong CTE riêng trước khi ghép; nhớ ép ::numeric trước ROUND(_, 2).
• Nền tích hợp này là đầu vào cho phân khúc và tổng quan Customer 360.

Nguồn tham khảo

• Ralph Kimball, Margy Ross — The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (Wiley) — mô hình chiều, fact/dimension, nền cho lớp profile & feature.
• Martin Kleppmann — Designing Data-Intensive Applications (O'Reilly) — chương về batch/stream processing và Change Data Capture (CDC).
• Debezium Documentation — CDC dựa trên đọc transaction log, phát thay đổi thành event.
• Apache Kafka Documentation — nền tảng event streaming, Kafka Connect cho tích hợp nguồn/đích.
• DAMA International — DAMA-DMBOK: Data Management Body of Knowledge (2nd Ed.) — khung quản trị, chất lượng dữ liệu, lineage, tích hợp & tương tác dữ liệu.
• CDP Institute — Customer Data Platform (định nghĩa và khung phân loại CDP; phân biệt với CRM/DMP).