Cloudera Operational Database: NoSQL thời gian thực, vận hành tự trị trên HBase

Có một loại câu hỏi mà kho dữ liệu phân tích không sinh ra để trả lời. Khách hàng mở ứng dụng và muốn thấy số dư ngay lúc này. Hệ thống thẻ cần biết hạn mức còn lại trước khi cho giao dịch đi tiếp. Tổng đài viên nhấc máy và cần hồ sơ khách hàng hiện lên trong lúc chào hỏi. Ba tình huống, cùng một đặc điểm: tra cứu rất ít bản ghi, nhưng phải trả lời trong mili giây, và lặp lại hàng chục nghìn lần mỗi giây.

Cloudera Operational Database là cơ sở dữ liệu NoSQL (Not Only SQL) được quản lý hoàn toàn, thuần đám mây (cloud-native), nền Apache HBase, dành cho các ứng dụng thời gian thực và quan trọng — nơi độ trễ tính bằng mili giây và gián đoạn thì đo bằng thiệt hại kinh doanh. Theo Cloudera công bố, nó giao dịch được trên hàng petabyte dữ liệu từ hàng nghìn nguồn ở quy mô web.

flowchart LR
  APP["Ứng dụng thời gian thực<br/>app · kênh số · tổng đài · hệ thống thẻ"] --> LOOK["Tra cứu theo khóa<br/>độ trễ mili giây"]
  LOOK --> COD["Operational Database<br/>nền Apache HBase"]
  COD --> ROW["Bản ghi cụ thể<br/>số dư · hạn mức · hồ sơ khách hàng"]
  COD -.-> ICE["Bảng Apache Iceberg<br/>lakehouse dùng chung"]
  DW["Data Warehouse<br/>quét và tổng hợp khối lớn"] --> ICE
  AI["Cloudera AI<br/>huấn luyện · suy luận"] --> ICE
  SDX["SDX · chính sách đặt một lần"] -.-> COD
  SDX -.-> ICE

Operational Database giải quyết việc gì

Đây là cơ sở dữ liệu đứng sau ứng dụng đang chạy, không phải nơi làm báo cáo. Nó được thiết kế quanh ba yêu cầu:

Yêu cầu	Nghĩa cụ thể
Độ trễ thấp	Trả lời một lượt tra cứu trong vài mili giây, ổn định — kể cả ở phân vị cao, không chỉ ở mức trung bình
Quy mô lớn	Hàng tỉ bản ghi, hàng chục nghìn lượt đọc ghi mỗi giây, mở rộng bằng cách thêm máy
Luôn sẵn sàng	Ứng dụng quan trọng không có khái niệm “giờ bảo trì” — một máy hỏng thì lưu lượng tự chuyển đi nơi khác

Apache HBase đáp ứng bộ ba này nhờ mô hình lưu trữ wide-column (cột rộng) có sắp xếp theo khóa. Dữ liệu được chia tự động thành các vùng theo dải khóa và phân bổ trên nhiều máy. Khi ứng dụng tra cứu theo khóa, hệ thống đi thẳng tới đúng vùng chứa bản ghi đó — không quét bảng. Đây chính là lý do độ trễ giữ được ổn định khi dữ liệu tăng từ triệu lên tỉ bản ghi: khối lượng phải đọc cho một lượt tra cứu gần như không đổi.

Ba chế độ truy cập, một cơ sở dữ liệu

Đây là điểm bản docs trước chưa nói rõ, và là điều làm Operational Database linh hoạt hơn một kho khóa-giá trị thuần. Theo Cloudera công bố, đội phát triển dùng được ba chế độ vận hành trên cùng một cơ sở dữ liệu:

Chế độ	Dùng khi	Truy cập qua
Khóa – giá trị (key-value)	Tra cứu bản ghi theo một khóa đơn giản	NoSQL client với Java API
Cột rộng (wide-column)	Bản ghi có nhiều thuộc tính, tập cột khác nhau giữa các dòng	NoSQL client với Java API
Quan hệ (relational)	Muốn giữ cách làm SQL quen thuộc	Trình điều khiển JDBC (Java Database Connectivity) hoặc ODBC (Open Database Connectivity)

Chế độ quan hệ cung cấp SQL chuẩn ANSI trên nền HBase (thông qua Apache Phoenix), nên đội phát triển đã quen SQL không phải học lại một mô hình truy vấn mới. Một ứng dụng có thể dùng cả giao diện quan hệ lẫn phi quan hệ tùy phần việc — đây là điều hiếm có ở một cơ sở dữ liệu NoSQL, và là lý do Cloudera đóng khung nó là “vừa quen thuộc vừa linh hoạt”.

Schema tiến hóa: đổi mô hình dữ liệu không phải làm lại ứng dụng

Cơ sở dữ liệu quan hệ truyền thống bắt bạn cố định cấu trúc bảng từ đầu; đổi mô hình dữ liệu về sau thường kéo theo việc kiến trúc lại ứng dụng — một dự án nhiều năm với biên độ sai số rất nhỏ, như datasheet của Cloudera nhấn mạnh.

Operational Database hỗ trợ schema tiến hóa (evolutionary schema) bên cạnh schema hình sao truyền thống: mỗi bản ghi có thể có tập thuộc tính khác nhau, và thêm một thuộc tính mới không cần đổi cấu trúc toàn bảng hay viết lại hàng chục triệu bản ghi còn lại. Nghiệp vụ đổi thì dữ liệu đổi theo, không phải dừng hệ thống. Wide-column còn cho bảng lớn theo cả hai chiều — thêm dòng và thêm cột.

Ngoài ra HBase lưu nhiều phiên bản của một ô dữ liệu, tiện cho việc giữ lịch sử thay đổi ngay tại bản ghi.

Vận hành tự trị: Auto Scale, Auto Tune, Auto Heal

Một cơ sở dữ liệu vận hành ở quy mô lớn thường kéo theo một đội chuyên trực và tinh chỉnh. Theo Cloudera công bố, Operational Database là tự trị (autonomous): nó tự cải thiện hiệu năng theo đặc tính ứng dụng và tự khắc phục sự cố mà không cần can thiệp thủ công. Ba năng lực có tên riêng:

Auto Scale — tự co giãn theo tải, tối ưu mức dùng hạ tầng đám mây; thêm capacity mà không phải lo chia phân vùng (partitioning) hay phân mảnh (sharding) thủ công.
Auto Tune — tự tinh chỉnh để cải thiện hiệu năng dựa trên cách ứng dụng thật sự dùng cơ sở dữ liệu.
Auto Heal — tự phát hiện và khắc phục sự cố vận hành, thay vì chờ người trực xử lý.

Đi kèm là tốc độ khởi tạo: theo Cloudera công bố, có thể tạo một cơ sở dữ liệu mới trong vài phút và bắt đầu dựng ứng dụng ngay, thay vì chờ dựng hạ tầng.

Chịu lỗi cao và khôi phục thảm họa

Ứng dụng quan trọng không có “giờ bảo trì”. Operational Database được thiết kế sẵn sàng cao ngay từ đầu:

Chuyển đổi dự phòng liền mạch, tự động giữa các node mà không ảnh hưởng ứng dụng. Chuyển sang nhất quán cuối cùng (eventual consistency) khi cần, để bảo đảm thời gian phản hồi ở mức mili giây.
Cụm kéo giãn (stretch cluster) trải trên nhiều vị trí, cho nhất quán mạnh (strong consistency) cùng khả năng chịu lỗi liền mạch.
Nhân bản bất đồng bộ (asynchronous replication) để khôi phục thảm họa (DR — Disaster Recovery) tại một trung tâm dữ liệu hoặc đám mây khác — bất kỳ đâu trên thế giới.

Với ngân hàng và khu vực công tại Việt Nam, tổ hợp này chạm đúng hai yêu cầu song song: độ sẵn sàng cho hệ thống lõi và phương án khôi phục thảm họa đặt tại vị trí do tổ chức kiểm soát.

Giao dịch phân tán ở quy mô lớn

Phần lớn ứng dụng doanh nghiệp cần giao dịch. Trên cơ sở dữ liệu quan hệ truyền thống, khi dữ liệu vượt quá sức một máy, đội kỹ thuật buộc phải tự chia (shard) cơ sở dữ liệu và quản lý từng mảnh riêng — một gánh nặng vận hành lớn, và là điểm mà nhiều hệ thống quan hệ không co giãn nổi.

Operational Database kết hợp hỗ trợ giao dịch phức tạp cùng SQL chuẩn ANSI với bản chất mở rộng ngang của Apache HBase. Nói cách khác, bạn có được ngữ nghĩa giao dịch quen thuộc mà không phải tự tay chia mảnh khi dữ liệu lớn lên — nền tảng lo phần đó. Đây là điều Cloudera đóng khung là “giảm đáng kể độ phức tạp vận hành khi quản lý tăng trưởng”.

Phân biệt với Data Warehouse

Hai dịch vụ này hay bị gộp làm một khi bàn kiến trúc, dẫn đến việc chọn nhầm công cụ cho bài toán. Chúng giải hai loại việc khác hẳn nhau:

Tiêu chí	Operational Database	Data Warehouse
Mục đích	Phục vụ ứng dụng đang chạy	Trả lời câu hỏi phân tích
Mẫu truy cập	Đọc và ghi theo khóa, vài bản ghi mỗi lượt	Quét và tổng hợp hàng trăm triệu đến hàng tỉ dòng
Độ trễ kỳ vọng	Mili giây	Giây đến phút
Tần suất	Hàng chục nghìn lượt mỗi giây	Ít lượt hơn nhiều, mỗi lượt nặng hơn nhiều
Người dùng	Ứng dụng và khách hàng cuối	Nhà phân tích, lãnh đạo, công cụ báo cáo
Mô hình dữ liệu	NoSQL wide-column, schema linh hoạt	Bảng có schema, tối ưu cho tổng hợp
Câu hỏi tiêu biểu	Số dư của tài khoản này là bao nhiêu	Trung bình số dư theo chi nhánh quý vừa rồi

Cách phân biệt gọn nhất: Operational Database trả lời câu hỏi về một khách hàng cụ thể ngay lúc này; Data Warehouse trả lời câu hỏi về tất cả khách hàng theo thời gian.

Hai dịch vụ bổ trợ nhau, không thay thế nhau

Đặt cạnh nhau trên cùng nền tảng Cloudera, Operational Database và lakehouse tạo thành một vòng khép kín:

Ứng dụng ghi vào Operational Database. Giao dịch, cập nhật hồ sơ, sự kiện trên kênh số — ghi và đọc ở tốc độ thời gian thực.
Dữ liệu vận hành chảy sang lakehouse. Đưa vào bảng Apache Iceberg để phân tích, mà không bắt các truy vấn phân tích chạy trên chính hệ thống đang phục vụ khách hàng.
Phân tích và AI làm việc trên lakehouse. Data Warehouse dựng báo cáo; Cloudera AI huấn luyện mô hình trên dữ liệu lịch sử.
Kết quả quay lại phục vụ ứng dụng. Điểm rủi ro, phân khúc khách hàng hay gợi ý từ mô hình được ghi trở lại Operational Database, để ứng dụng tra cứu trong mili giây ở lượt tương tác kế tiếp.

Điểm giữ cho vòng này không rối là quản trị dùng chung: chính sách bảo mật và phân quyền đặt một lần ở lớp SDX rồi áp cho cả dữ liệu vận hành lẫn dữ liệu phân tích. Theo Cloudera công bố, bộ dịch vụ chung này còn giữ nguyên ngay cả trong môi trường đám mây tạm thời (transient), giúp bộ phận công nghệ đặt và áp chính sách nhất quán trong khi vẫn mở quyền tự phục vụ cho nghiệp vụ.

Di trú không gián đoạn

Theo Cloudera công bố, có thể chuyển sang Operational Database bằng nhân bản hai chiều gần thời gian thực (near real-time bi-directional replication) — ứng dụng dịch chuyển từ các triển khai Cloudera khác với rủi ro bằng không và không gián đoạn (zero risk, zero downtime). Hai chiều nghĩa là trong giai đoạn chuyển tiếp, cả hệ cũ và hệ mới cùng cập nhật, và bạn cắt chuyển khi đã đủ tin cậy — thay vì một lần cắt “được ăn cả ngã về không”.

Ví dụ theo bối cảnh Việt Nam

Tra cứu hạn mức và số dư thời gian thực

Mỗi giao dịch thẻ đều cần một câu trả lời trước khi đi tiếp: tài khoản này còn đủ hạn mức không. Câu trả lời phải đến trong vài mili giây, đúng vào giờ cao điểm, và không được sai.

Đây là bài toán kinh điển cho Operational Database: tra cứu theo khóa là mã tài khoản, đọc đúng một bản ghi, trả lời ngay. Khối lượng có thể tăng gấp nhiều lần vào dịp cao điểm mua sắm hay lễ Tết, và cách xử lý là Auto Scale thêm capacity — độ trễ mỗi lượt tra cứu gần như không đổi vì hệ thống vẫn chỉ đọc một bản ghi.

Hồ sơ khách hàng 360

Một khách hàng để lại dấu vết ở rất nhiều nơi: sản phẩm đang dùng, giao dịch gần đây, lịch sử tương tác tổng đài, hành vi trên ứng dụng, điểm rủi ro do mô hình chấm. Muốn tổng đài viên hay nhân viên chi nhánh nhìn thấy bức tranh đầy đủ ngay khi khách hàng vừa gọi tới, tất cả phải hội tụ vào một bản ghi tra cứu được tức thì.

Cách bố trí thường gặp: hồ sơ hợp nhất nằm trong Operational Database, khóa là mã khách hàng. Phần dữ liệu nặng — lịch sử dài, phân khúc, điểm mô hình — được tính trên lakehouse theo lịch, rồi ghi trở lại hồ sơ dưới dạng thuộc tính. Schema tiến hóa của HBase hợp với việc này: mỗi khách hàng có tập thuộc tính khác nhau, và thêm một thuộc tính mới không cần đổi cấu trúc của hàng chục triệu bản ghi còn lại.

Chạy báo cáo tổng hợp thẳng trên hệ thống vận hành. Truy vấn nặng và giao dịch của khách hàng sẽ tranh nhau tài nguyên; bên chịu thiệt là khách hàng.

Thiết kế khóa không kỹ. Trong HBase, khóa quyết định dữ liệu nằm ở đâu. Khóa tăng dần theo thời gian sẽ dồn toàn bộ lưu lượng ghi vào một máy trong khi cả cụm ngồi chơi.

Chỉ nhìn độ trễ trung bình. Trải nghiệm khách hàng nằm ở phân vị cao. Trung bình đẹp mà đuôi dài thì vẫn có người chờ, và họ là những người sẽ gọi lên tổng đài.

Dồn mọi thuộc tính vào một bản ghi mà không tính tới cách đọc. Bản ghi phình to thì mỗi lượt tra cứu phải đọc nhiều hơn mức cần thiết — độ trễ tăng dần theo tháng, không có sự kiện nào để quy trách nhiệm.

Quản trị hai nơi hai kiểu. Nếu dữ liệu vận hành và dữ liệu phân tích mỗi bên một bộ luật, thì lỗ hổng sẽ xuất hiện ở chỗ nối — nơi ít ai nhìn tới.

Đọc tiếp

Data Warehouse Phân tích khối dữ liệu rất lớn với hàng nghìn người dùng truy vấn đồng thời.

Open Data Lakehouse (Iceberg) Định dạng bảng mở, du hành thời gian và Lakehouse Optimizer tự tối ưu bảng.

SDX — quản trị dùng chung Lớp chính sách mà cả dữ liệu vận hành lẫn phân tích cùng kế thừa.