Graph 7 — Tích hợp, hiệu năng & vận hành

Sáu bài trước xây dựng năng lực: tổng quan graph, mô hình dữ liệu, Cypher nâng cao, thuật toán GDS, và phát hiện gian lận/AML. Tất cả giả định dữ liệu đã nằm trong Neo4j. Bài này trả lời câu hỏi vận hành: dữ liệu vào bằng đường nào, cập nhật ra sao, chạy nhanh thế nào, và khi nào thì đừng dùng graph? Đây là phần biến một demo đẹp thành một hệ thống sống được trong kiến trúc dữ liệu ngân hàng.

Lưu ý: mọi block cypher, bash, properties, json trong bài là cú pháp Neo4j/Kafka/CDC — minh hoạ, không phải SQL Postgres và không chạy được trên sandbox Knowledge Base. Chỉ block đánh dấu -- ▶ Chạy được (SELECT thuần trên 5 bảng demo) mới thực thi.

Định vị: Neo4j là lớp phái sinh, không phải system of record

Nguyên tắc kiến trúc quan trọng nhất, quyết định mọi lựa chọn tích hợp về sau: trong ngân hàng, Neo4j gần như luôn là lớp phân tích/phái sinh, KHÔNG phải nguồn sự thật (system of record) cho tiền. Số dư tài khoản, bút toán giao dịch, hồ sơ khách hàng — những dữ liệu có tính pháp lý và tiền bạc — sống ở core banking (RDBMS: Oracle, PostgreSQL, DB2) với ACID, kiểm toán, đối soát chặt chẽ. Neo4j nhận bản sao của những dữ liệu đó, tổ chức lại thành đồ thị để trả lời câu hỏi mạng lưới (vòng gian lận, chuỗi trung gian rửa tiền, cụm tài khoản).

Hệ quả thực tế:

• Neo4j có thể mất và dựng lại từ nguồn. Nếu graph hỏng, ta re-load từ core/warehouse. Không có "dữ liệu chỉ tồn tại trong Neo4j" nào là dữ liệu tiền.
• Không ghi tiền trực tiếp vào Neo4j từ ứng dụng. Chiều ghi luôn là core → Neo4j, một chiều. Các insight graph tạo ra (điểm rủi ro, community ID) có thể ghi ngược về warehouse như một feature, nhưng đó là dữ liệu phái sinh, không phải bút toán.
• Nhất quán là "eventual", chấp nhận được. Graph trễ vài giây tới vài phút so với core là bình thường và ổn cho phân tích mạng lưới. Nó không cần nhất quán tức thời như sổ cái.

Tích hợp 1 — Nạp khối lượng lớn (batch)

Khi khởi tạo đồ thị hoặc backfill hàng chục–hàng trăm triệu node/cạnh từ RDBMS, có hai công cụ chính.

LOAD CSV — nạp online, vừa và nhỏ

LOAD CSV chạy bên trong một database Neo4j đang sống, đọc file CSV (thường xuất từ RDBMS/warehouse) và MERGE vào đồ thị. Phù hợp tới cỡ vài triệu dòng, khi database đã có sẵn và ta muốn nạp incremental. Điểm chết người là phải batch hoá bằng CALL { ... } IN TRANSACTIONS để không phình một transaction khổng lồ:

// minh hoạ — nạp tài khoản từ CSV, commit mỗi 10.000 dòng
LOAD CSV WITH HEADERS FROM 'file:///accounts.csv' AS row
CALL {
  WITH row
  MERGE (a:Account { account_no: row.account_no })
    SET a.currency = row.currency,
        a.balance  = toFloat(row.balance)
} IN TRANSACTIONS OF 10000 ROWS;

Điều kiện tiên quyết để MERGE này nhanh: đã có constraint unique trên Account.account_no (xem phần hiệu năng). Không có nó, mỗi MERGE là một full scan → nạp 1 triệu dòng có thể mất hàng giờ thay vì vài phút.

neo4j-admin database import — nạp offline, cực lớn

Với backfill lần đầu cỡ hàng trăm triệu tới tỉ node/cạnh, LOAD CSV quá chậm. neo4j-admin database import là bulk loader chạy khi database đang tắt, dựng thẳng file store trên đĩa, bỏ qua toàn bộ overhead transaction. Nhanh hơn hàng chục lần, nhưng chỉ dùng để khởi tạo database trống — không dùng để cập nhật database đang chạy.

# minh hoạ — bulk import offline, database phải đang stop
neo4j-admin database import full \
  --nodes=Customer=customers_header.csv,customers.csv \
  --nodes=Account=accounts_header.csv,accounts.csv \
  --relationships=OWNS=owns.csv \
  --relationships=SENT=transfers.csv \
  neo4j

Chiến lược thực tế: dùng neo4j-admin import cho lần dựng đồ thị đầu tiên (initial load từ snapshot warehouse), rồi chuyển sang CDC streaming cho cập nhật liên tục. Đây là mẫu "bootstrap + stream" chuẩn.

Tích hợp 2 — Streaming / CDC (cập nhật gần real-time)

Đồ thị AML/fraud chỉ có giá trị khi tươi. Một vòng gian lận phát hiện sau 24 giờ có khi tiền đã đi hết. Ta cần graph cập nhật gần real-time theo core — và cách chuẩn là CDC (Change Data Capture) qua Kafka.

Chuỗi mẫu, dựng trên kiến trúc Kafka:

1. Debezium cắm vào core banking RDBMS, đọc WAL/binlog (nhật ký thay đổi ở tầng lưu trữ, không query bảng nên không tải core). Mỗi INSERT/UPDATE/DELETE thành một message trên Kafka topic, dạng before/after.
2. Kafka giữ luồng thay đổi, cho phép nhiều consumer, replay, và tách nhịp giữa core và graph.
3. Kafka Connect Neo4j (Sink Connector) đọc topic và áp Cypher template cho từng message, MERGE vào Neo4j.

// minh hoạ — cấu hình Kafka Connect Neo4j Sink cho topic transactions
{
  "name": "neo4j-sink-transactions",
  "config": {
    "connector.class": "org.neo4j.connectors.kafka.sink.Neo4jConnector",
    "topics": "cdc.core.transactions",
    "neo4j.uri": "bolt://neo4j:7687",
    "neo4j.cypher.topic.cdc.core.transactions":
      "MERGE (src:Account {account_no: event.from_acct}) MERGE (dst:Account {account_no: event.to_acct}) MERGE (src)-[t:SENT {txn_id: event.txn_id}]->(dst) SET t.amount = event.amount, t.ts = event.created_at"
  }
}

Vài điểm bản lề khi vận hành CDC vào graph:

• Idempotency là bắt buộc. Kafka giao "at-least-once" → cùng một message có thể tới hai lần. Dùng MERGE theo khóa nghiệp vụ (txn_id) thay vì CREATE để nạp lại không sinh trùng.
• Thứ tự & khóa ngoại. Một SENT cần hai node Account tồn tại trước. MERGE cả hai đầu trong template (như trên) giúp graph tự "vá" node còn thiếu, tránh phụ thuộc thứ tự tới của message.
• Xử lý DELETE/UPDATE. CDC mang cả xóa/sửa ở nguồn. Quyết định chính sách: xóa cứng node hay chỉ đánh dấu deleted_at? Với AML thường giữ lịch sử (soft-delete) vì cần truy vết quá khứ.
• Backpressure & throughput. Ghi vào Neo4j chậm hơn đọc Kafka nhiều. Gom message theo batch, tăng số task connector, và canh super node (xem dưới) để một node nóng không khóa hàng loạt giao dịch.

Hiệu năng — làm Neo4j chạy nhanh

Index & constraint: nền tảng của mọi MATCH/MERGE nhanh

Đây là đòn bẩy hiệu năng lớn nhất. Mỗi lần Cypher bắt đầu từ một node cụ thể (MATCH (a:Account {account_no: $x})), nếu không có index Neo4j phải quét mọi node Account. Unique constraint vừa đảm bảo không trùng khóa, vừa tự tạo index tra cứu.

// minh hoạ — bắt buộc trước khi nạp dữ liệu lớn
CREATE CONSTRAINT account_no_unique IF NOT EXISTS
  FOR (a:Account) REQUIRE a.account_no IS UNIQUE;

CREATE CONSTRAINT customer_id_unique IF NOT EXISTS
  FOR (c:Customer) REQUIRE c.cif IS UNIQUE;

Quy tắc vàng: tạo constraint TRƯỚC khi bulk load. Nạp trước rồi tạo index sau vừa chậm nạp (mỗi MERGE full scan) vừa tốn công build index lại.

Tránh super node

Super node là node có bậc (degree) cực lớn — hàng trăm nghìn tới hàng triệu cạnh. Trong ngân hàng, thủ phạm điển hình là: tài khoản trung gian thanh toán, ví điện thoại chung, một số điện thoại/địa chỉ bị nhiều khách dùng, hay node "Ngân hàng đối tác". Duyệt qua super node khiến truy vấn nổ tung: một bước từ super node là hàng triệu cạnh phải xét.

Cách xử lý:

• Không mô hình hóa cạnh vào super node nếu không cần cho câu hỏi. Ví dụ đừng nối mọi giao dịch vào một node "VND".
• Chia nhỏ theo thời gian: thay vì một node Merchant với 5 triệu SENT, gắn cạnh theo tháng hoặc dùng node trung gian MerchantDay.
• Giới hạn trong truy vấn: khi buộc phải qua node bậc cao, dùng LIMIT, lọc theo property (thời gian, số tiền) sớm, và tránh path pattern mở rộng không giới hạn qua nó.

Viết Cypher hiệu quả & PROFILE

• Luôn khởi đầu từ điểm có index và neo bằng label + property có constraint. MATCH (a:Account {account_no:$x}) nhanh; MATCH (a) WHERE a.account_no=$x (không label) chậm.
• Giới hạn độ sâu của biến độ dài. -[:SENT*1..4]-> khác một trời vực với -[:SENT*]-> (không chặn → có thể duyệt cả đồ thị). Với AML luôn đặt trần bước.
• Lọc sớm, mở rộng muộn: đưa điều kiện WHERE cắt bớt cardinality trước khi expand quan hệ.
• PROFILE / EXPLAIN: PROFILE chạy thật và cho biết mỗi bước quét bao nhiêu row (db hits). EXPLAIN chỉ ước lượng. Đọc PROFILE để phát hiện NodeByLabelScan đáng lẽ phải là NodeIndexSeek — dấu hiệu thiếu index.

// minh hoạ — PROFILE để soi kế hoạch thực thi
PROFILE
MATCH (a:Account {account_no:'0011'})-[:SENT*1..4]->(b:Account)
WHERE b.flagged = true
RETURN b.account_no LIMIT 20;

Cấu hình bộ nhớ: page cache & heap

Hiệu năng Neo4j phụ thuộc nặng vào chỉnh hai vùng nhớ, quan điểm ngược nhau:

Thực chiến: warm cache sau khi khởi động (chạy vài truy vấn quét để kéo store nóng vào page cache) trước giờ cao điểm; định cỡ page cache theo kích thước store, heap theo độ nặng truy vấn/GDS. GDS projection nằm ở heap nên đồ thị chiếu lớn cần heap rộng.

Mô hình triển khai

Với đồ thị AML điển hình: workload là ghi liên tục (CDC) + đọc nặng theo đợt (phân tích, GDS). Read replica rất hợp — tách truy vấn phân tích nặng sang replica để không đụng luồng ghi CDC trên core cluster.

Khi nào KHÔNG dùng graph

Graph không phải búa vạn năng. Dùng sai chỗ vừa chậm vừa tốn vận hành. Kim chỉ nam: graph thắng khi câu hỏi là về QUAN HỆ nhiều bước; thua khi câu hỏi là TỔNG HỢP cột trên khối lượng lớn.

Nói ngắn: giữ tiền và tổng hợp ở RDBMS/warehouse; đưa câu hỏi quan hệ nhiều hop sang Neo4j. Đừng biến Neo4j thành nơi chạy SUM(amount) GROUP BY month — điều RDBMS làm gọn gàng:

-- ▶ Chạy được
SELECT date_trunc('month', created_at) AS thang,
       kind,
       COUNT(*)      AS so_giao_dich,
       SUM(amount)   AS tong_tien
FROM transactions
GROUP BY 1, 2
ORDER BY 1, 2;

Truy vấn tổng hợp kiểu trên thuộc về RDBMS/warehouse — không phải việc của graph. Ngược lại, "tài khoản A gửi tiền cho B, B cho C, ... quay lại A trong 5 bước" mới là việc của Neo4j.

Neo4j so với các lựa chọn khác

Neo4j là graph database phổ biến nhất, nhưng không phải duy nhất:

Điểm đáng nhớ về PostgreSQL cho đồ thị nhẹ: nếu quan hệ nông (2–3 bước), dữ liệu vừa phải, và bạn đã có Postgres, thì recursive CTE (WITH RECURSIVE) đủ để duyệt cây/đồ thị mà không cần dựng cụm Neo4j riêng. Extension Apache AGE còn cho viết openCypher ngay trong Postgres. Đây là lựa chọn thực dụng khi bài toán chưa đủ lớn để biện minh cho một graph platform riêng — đừng dựng Neo4j chỉ để duyệt một cây phân cấp phòng ban.

Use case thực tế

Bối cảnh: NCB dựng đồ thị AML cập nhật gần real-time từ core banking để phát hiện vòng chuyển tiền và tài khoản trung gian. Yêu cầu: alert trong vài phút kể từ khi giao dịch phát sinh; graph không được là nơi lưu tiền.

Kiến trúc & bước triển khai:

1. Initial load. Xuất snapshot 3 năm dữ liệu từ warehouse ra CSV: ~18 triệu Customer, ~25 triệu Account, ~1,2 tỉ SENT. Tạo constraint unique trên Account.account_no, Customer.cif trước. Dùng neo4j-admin database import (offline) → dựng graph trống trong ~40 phút thay vì nhiều ngày với LOAD CSV.
2. Streaming. Debezium cắm vào core (đọc WAL, không query bảng) → Kafka topic cdc.core.transactions. Kafka Connect Neo4j Sink áp Cypher MERGE idempotent theo txn_id. Độ trễ core→graph đo được ~8 giây ở tải trung bình.
3. Chống super node. Node ví thanh toán trung gian có ~4 triệu cạnh. Tách theo ngày (MerchantDay) và loại khỏi các path pattern AML để truy vấn vòng không nổ.
4. Phân tích trên read replica. GDS chạy community detection + betweenness centrality hằng đêm trên read replica, không đụng luồng ghi CDC. Kết quả (community_id, điểm trung gian) ghi ngược về warehouse làm feature cho mô hình chấm rủi ro — Neo4j không giữ điểm rủi ro như nguồn sự thật.
5. Tổng hợp để ngoài graph. Báo cáo "tổng tiền theo tháng/chi nhánh" chạy trên warehouse (ClickHouse), không phải Neo4j.

Kết quả: đồ thị tươi trong ~8 giây, truy vấn vòng 5-hop nhờ index + chặn super node trả về dưới 2 giây, và ranh giới trách nhiệm rõ: core = tiền, warehouse = tổng hợp, Neo4j = mạng lưới. Khi graph gặp sự cố, re-load từ snapshot + replay Kafka, không mất dữ liệu tiền nào.

Ghi nhớ

• Neo4j là lớp phái sinh/phân tích, không phải system of record cho tiền. Chiều dữ liệu luôn là core → graph; graph có thể mất và dựng lại từ nguồn.
• Batch: neo4j-admin database import (offline) cho khởi tạo cực lớn; LOAD CSV + IN TRANSACTIONS cho nạp online vừa phải. Tạo constraint unique TRƯỚC khi load.
• Streaming: Debezium đọc WAL/binlog → Kafka → Kafka Connect Neo4j Sink áp Cypher MERGE idempotent theo khóa nghiệp vụ. Nhất quán "eventual" (vài giây) là chấp nhận được.
• Hiệu năng: index/constraint là đòn bẩy lớn nhất; tránh super node; giới hạn độ sâu path; dùng PROFILE để soi; chỉnh page cache (đọc) và heap (transaction/GDS); warm cache trước cao điểm.
• Triển khai: single (dev) → Causal Cluster + read replica (production HA + tách tải phân tích) → Aura (managed, cân nhắc quy định dữ liệu).
• KHÔNG dùng graph cho: OLTP tiền → RDBMS; tổng hợp cột khối lượng lớn → ClickHouse/warehouse. Graph chỉ thắng khi câu hỏi là quan hệ nhiều hop.
• Lựa chọn khác: Neptune (AWS-managed), TigerGraph (siêu lớn), JanusGraph (open, phân tán); và Postgres recursive CTE / AGE đủ cho đồ thị nhẹ khi chưa cần dựng graph platform riêng.