AI là động cơ, dữ liệu là nhiên liệu: vì sao nền tảng dữ liệu quyết định doanh nghiệp đi được bao xa

AI như động cơ của một chiếc xe đang chạy. Nhưng đứng sau động cơ đó là dữ liệu, là nhiên liệu, và bình chứa của thứ nhiên liệu ấy chính là database. Động cơ có mạnh đến đâu, xe cũng không đi xa được nếu bình chứa rò rỉ hoặc bị chia thành ba ngăn không thông nhau. Đó chính xác là tình trạng của phần lớn doanh nghiệp hiện nay: 74% có lợi nhuận từ AI ngay trong năm đầu tiên, nhưng chỉ 7% thực sự mở rộng được AI trên toàn tổ chức, theo McKinsey (2026).

Vấn đề không đơn giản nằm ở mô hình

64% doanh nghiệp gặp khó khăn về quản trị dữ liệu khi triển khai AI, và hơn 2/3 xác nhận đây, chứ không phải mô hình, mới là rào cản lớn nhất. Theo một báo cáo mới nhất từ McKinsey (2026), ba nguyên nhân cụ thể được chỉ ra.

Phần lớn dữ liệu doanh nghiệp không còn vuông vức như bảng hàng-cột trong cơ sở dữ liệu quan hệ truyền thống nữa. Đó là hóa đơn, vận đơn, catalog sản phẩm, ghi âm cuộc gọi, tức là 80% dữ liệu của tổ chức đang ở dạng dữ liệu có cấu trúc, bán cấu trúc và phi cấu trúc mà các hệ thống cũ gặp nhiều hạn chế khi xử lý và mở rộng.

Khi AI tự truy xuất, tái tổ hợp và tạo ra dữ liệu mới trong quá trình vận hành, tốc độ đó vượt xa khả năng theo kịp của các mô hình quản trị vốn được thiết kế cho những tác vụ xử lý theo lô định kỳ, không phải cho luồng dữ liệu thời gian thực. Và khi dữ liệu phân mảnh qua nhiều hệ thống, vai trò của giám đốc dữ liệu bị đẩy vào vị trí trung tâm của việc triển khai AI, thay vì chỉ là chức năng hỗ trợ phía sau như trước.

Cả ba nguyên nhân đều là vấn đề kiến trúc, không phải vấn đề chọn sai mô hình AI. Mỗi hệ thống nguồn một schema, mỗi luồng xử lý một cách thức phân quyền riêng, mỗi lớp lưu trữ một cơ chế kiểm toán riêng. Khi AI cần dữ liệu thời gian thực từ một nguồn chưa từng được kết nối, đội ngũ kỹ thuật phải tự dựng thêm một bộ kết nối mới, một tầng xử lý trung gian mới, một bộ quy tắc phân quyền mới, và lặp lại quy trình đó cho từng use case.

Một hệ thống hợp nhất thay vì nhiều hệ thống rời rạc

Tại workshop Modern Architecture for the AI Era do FPT và MongoDB vừa tổ chức, anh Lê Thanh Hải, Phó Giám đốc Khối Công nghệ Cloud tại FPT Smart Cloud, mô tả hướng giải quyết bài toán này: gộp dữ liệu vận hành, phân tích và AI, đúng ba ngăn đang tách rời trong chiếc bình chứa nói trên, vào một nền tảng quản trị hợp nhất, thay vì để chúng phát triển độc lập rồi tìm cách kết nối lại sau. Trong mô hình này, cơ sở dữ liệu vận hành đóng vai trò là nơi ghi nhận chính xác mọi dữ liệu, mọi thay đổi trạng thái. Một nền tảng dữ liệu riêng đóng vai trò phân tích chuyên sâu và phục vụ AI, xử lý dữ liệu đó cho các mô hình và ứng dụng thông minh.

Với cách tổ chức này, mỗi lần doanh nghiệp mở rộng một ứng dụng AI mới, họ không cần xây thêm luồng kết nối riêng hay xin cấp quyền truy cập từ đầu. Dữ liệu đã sẵn sàng trong cùng một hệ sinh thái, cùng một cơ chế bảo mật, vận hành như một nền tảng hợp nhất xuyên suốt.

Vậy một nền tảng dữ liệu sẵn sàng cho AI thực tế như thế nào?

Khi AI chuyển từ thử nghiệm sang ứng dụng chạy thật trong môi trường sản xuất, database không chỉ cần lưu đúng dữ liệu, mà phải đáp ứng được SLA, bảo mật cấp doanh nghiệp, và khả năng phục hồi khi có sự cố. Đây chính là ranh giới giữa hai phiên bản MongoDB: Community phù hợp cho môi trường phát triển và các workload không lưu trạng thái, còn Enterprise được thiết kế riêng cho production ở quy mô doanh nghiệp, với mã hóa cấp trường, xác thực LDAP/Kerberos/AD, audit trail chi tiết, và chuẩn mã hóa FIPS.

Kiến trúc tham chiếu được tổ chức thành sáu lớp theo chiều dữ liệu di chuyển, cùng hai lớp xuyên suốt chạy bên dưới toàn bộ hệ thống.

Lớp đầu tiên tiếp nhận dữ liệu từ database vận hành dạng document trên MongoDB Enterprise, dữ liệu quan hệ, IoT, các nền tảng SaaS, và log hệ thống. Lớp thứ hai đưa toàn bộ nguồn này vào cùng một luồng gần thời gian thực, dùng FPT CDC đồng bộ trực tiếp từ oplog của MongoDB, kết hợp Kafka cho việc truyền dữ liệu theo sự kiện.

Lớp lưu trữ giữ dữ liệu song song ở nhiều dạng, trong đó chính cụm MongoDB cũng đóng vai trò một phần trong kiến trúc lưu trữ tổng thể, không phải hệ thống tách biệt phải đồng bộ ngược lại. Lớp xử lý dùng Spark, DBT, và Flink cho xử lý luồng thời gian thực. Chi tiết đáng chú ý nhất với đội ngũ làm AI nằm ở đây: Vector Index được build sẵn ngay bên trong MongoDB, không phải một database vector riêng biệt cần tích hợp qua API ngoài, giúp cùng một cụm dữ liệu vừa phục vụ giao dịch vận hành, vừa phục vụ trực tiếp cho các pipeline RAG.

Lớp phục vụ dùng Trino để truy vấn SQL liên kết đa nguồn và ClickHouse cho phân tích tốc độ cao. Lớp trực quan hóa và AI kết nối tới các công cụ BI, JupyterHub, và FPT AI Studio, nơi RAG, AI agent và LLM thực sự chạy. Bên dưới toàn bộ sáu lớp này, một lớp điều phối dùng FPT Airflow để quản lý toàn bộ pipeline, và một lớp quản trị và bảo mật chạy xuyên suốt, gồm IAM, xác thực qua LDAP, mã hóa dữ liệu lưu trữ và truyền tải, giám sát đồng nhất cho toàn hệ thống.

Hình dung một ngân hàng muốn triển khai trợ lý AI tư vấn khách hàng. Để trả lời đúng, AI cần đồng thời truy cập lịch sử giao dịch, dữ liệu tín dụng, lịch sử ticket hỗ trợ, và ghi âm cuộc gọi trước đó. Nếu bốn nguồn này nằm ở bốn hệ thống tách biệt, mỗi lần AI cần trả lời một câu hỏi đơn giản cũng phải đi qua bốn lượt truy vấn, bốn cơ chế phân quyền khác nhau. Đây chính xác là bài toán mà kiến trúc sáu lớp phía trên giải quyết: đưa cả bốn nguồn vào cùng một luồng dữ liệu thống nhất, để AI truy cập như một nguồn duy nhất.

Trong vài năm qua, doanh nghiệp đã dành nhiều thời gian để so sánh Llama, GPT hay Gemini, nhưng lại ít đặt câu hỏi nền tảng hơn: AI sẽ lấy dữ liệu từ đâu, dữ liệu đó được quản trị như thế nào và liệu kiến trúc hiện tại có đủ khả năng phục vụ hàng triệu lượt truy cập trong môi trường sản xuất? Khi AI trở thành một phần của quy trình nghiệp vụ trong doanh nghiệp, bài toán không còn là lựa chọn mô hình nào phù hợp mà là lựa chọn kiến trúc dữ liệu đúng.

FPT MongoDB Enterprise sẽ được vận hành bởi đội ngũ kỹ thuật FPT Cloud kèm theo cam kết uptime 99,95%, phản hồi sự cố nghiêm trọng trong vòng 15 phút và hỗ trợ 24/7. Với doanh nghiệp đang cân nhắc giữa tự vận hành và thuê dịch vụ, đội ngũ chuyên gia FPT Cloud sẵn sàng đồng hành tư vấn kiến trúc miễn phí để đánh giá bài toán cụ thể trước khi đưa ra quyết định tối ưu nhất.

Liên hệ với chúng tôi để được tư vấn chi tiết về dịch vụ của FPT MongoDB Enterprise

• Email: support@fptcloud.com
• Support: m.me/fptsmartcloud

Câu hỏi thường gặp