Startup Definity huy động 12 triệu USD để nhúng AI vào Spark pipelines, ngăn chặn lỗi dữ liệu

Startup Definity, có trụ sở tại Chicago, vừa công bố gọi vốn thành công 12 triệu USD trong vòng tài trợ Series A do GreatPoint Ventures dẫn đầu, với sự tham gia của Dynatrace và các nhà đầu tư hiện hữu như StageOne Ventures và Hyde Park Venture Partners. Vốn này sẽ giúp công ty phát triển giải pháp đột phá nhằm giải quyết vấn đề độ tin cậy của các pipeline dữ liệu bằng cách nhúng các tác nhân (agents) trực tiếp vào bên trong driver của Spark hoặc DBT.

Đối với hầu hết các đội ngũ kỹ thuật dữ liệu hiện nay, việc quản lý độ tin cậy của pipeline thường đồng nghĩa với việc chờ đợi cảnh báo, sau đó theo dõi thủ công các lỗi thất bại trên các công việc phân tán (distributed jobs) và cụm máy (clusters), và cuối cùng là khắc phục sự cố sau khi chúng đã gây ảnh hưởng đến doanh nghiệp. Tuy nhiên, Agentic AI (AI tác nhân) đòi hỏi dữ liệu phải có sẵn, sạch và đúng thời điểm. Một pipeline bị lỗi âm thầm hoặc cung cấp dữ liệu cũ không chỉ làm hỏng một bảng điều khiển (dashboard) mà còn phá vỡ cả hệ thống AI đang phụ thuộc vào nó.

Tại sao các công cụ giám sát pipeline hiện tại gặp khó khăn khi mở rộng quy mô

Các công cụ hiện có tiếp cận vấn đề từ bên ngoài lớp thực thi — Datadog (vốn đã mua lại Metaplane năm ngoái), các bảng hệ thống của Databricks, cũng như các nền tảng như Unravel Data và Acceldata đều đọc số liệu sau khi một công việc hoàn tất. Dynatrace cũng có khả năng giám sát và đã tham gia vào vòng Series A của Definity.

Phương pháp tiếp cận của Definity khác biệt so với các lựa chọn khác về mặt kiến trúc giải pháp. Theo Roy Daniel, CEO và đồng sáng lập Definity, điều này có nghĩa là đến khi công cụ giám sát nền tảng phát hiện ra một vấn đề, pipeline đó đã chạy xong — và sự thất bại, tài nguyên tính toán bị lãng phí hoặc dữ liệu xấu đã lan truyền xuống hạ lưu.

"Nó luôn luôn là muộn màng," Daniel nói. "Đến khi bạn biết điều gì đó xảy ra, thì nó đã xảy ra rồi."

Cách thức hoạt động của các tác nhân trong quá trình thực thi của Definity

Sự khác biệt cốt lõi về kiến trúc nằm ở vị trí của tác nhân — nằm bên trong pipeline thay vì quan sát từ bên ngoài.

Công cụ đo lường tích hợp (Inline instrumentation): Hệ thống Definity cài đặt một tác nhân JVM trực tiếp bên trong lớp thực thi pipeline chỉ qua một dòng mã, chạy bên dưới lớp nền tảng và kéo dữ liệu thực thi trực tiếp từ Spark.

Ngữ cảnh thực thi trong quá trình chạy: Tác nhân bắt giữ hành vi thực thi truy vấn, áp lực bộ nhớ, lệch dữ liệu (data skew), mẫu trộn dữ liệu (shuffle patterns) và mức độ sử dụng hạ tầng trong khi pipeline đang chạy. Nó cũng suy luận dòng dữ liệu (lineage) giữa các pipeline và bảng một cách động — không cần danh mục dữ liệu được xác định trước.

Can thiệp, không chỉ quan sát: Tác nhân có thể sửa đổi phân bổ tài nguyên giữa chừng, dừng một công việc trước khi dữ liệu xấu lan truyền hoặc ngăn chặn một pipeline dựa trên điều kiện dữ liệu thượng nguồn. Daniel mô tả một triển khai sản xuất nơi tác nhân phát hiện ra rằng một công việc thượng nguồn đã bị ngăn chặn và bảng đầu vào mà nó lẽ ra viết vào đã cũ — và nó đã dừng pipeline hạ lưu trước khi bắt đầu, ngăn chặn dữ liệu xấu tiếp cận bất kỳ hệ thống phụ thuộc nào.

Điều gì là và không phải là thời gian thực: Việc phát hiện và ngăn chặn là theo thời gian thực. Phân tích nguyên nhân gốc rễ và các đề xuất tối ưu hóa chạy theo yêu cầu khi một kỹ sư truy vấn trợ lý, với ngữ cảnh thực thi đầy đủ đã được lắp ráp sẵn.

Chi phí overhead và nơi lưu trữ dữ liệu: Tác nhân thêm khoảng một giây tính toán cho một lần chạy kéo dài một giờ. Chỉ có siêu dữ liệu được truyền ra bên ngoài; triển khai hoàn toàn tại chỗ (on-prem) có sẵn cho các môi trường nơi không có siêu dữ liệu nào được phép rời ra khỏi biên giới.

Trí tuệ trong quá trình thực thi trông như thế nào trong môi trường sản xuất

Một trong những người dùng sớm của nền tảng Definity là Nexxen, một nền tảng công nghệ quảng cáo chạy các pipeline Spark quy mô lớn cho khối lượng công việc quảng cáo quan trọng, hoạt động tại chỗ (on-prem).

Dennis Meyer, Giám đốc Kỹ thuật Dữ liệu tại Nexxen, cho biết vấn đề cốt lõi ông đang đối mặt không phải là pipeline bị hỏng mà là chi phí tích tụ của sự kém hiệu quả trong một môi trường không có dung lượng đám mây linh hoạt để hấp thụ sự lãng phí.

"Thách thức chính không phải là về việc các pipeline bị hỏng, mà là quản lý một môi trường ngày càng phức tạp và quy mô lớn," Meyer nói. "Vì chúng tôi vận hành tại chỗ, chúng tôi không có sự linh hoạt của khả năng co giãn tức thì, vì vậy sự kém hiệu quả có tác động trực tiếp đến chi phí."

Các công cụ giám sát hiện có đã cung cấp cho Nexxen khả năng hiển thị một phần nhưng không đủ để hành động một cách có hệ thống. "Chúng tôi đã có các công cụ giám sát, nhưng cần khả năng hiển thị toàn bộ ngăn xếp (full-stack) để hiểu hành vi khối lượng công việc một cách toàn diện và ưu tiên tối ưu hóa một cách có hệ thống," Meyer nói.

Nexxen đã triển khai Definity mà không cần thay đổi mã pipeline. Theo Meyer, nhóm đã xác định được 33% cơ hội tối ưu hóa trong tuần đầu tiên và nỗ lực kỹ thuật cho việc khắc phục sự cố và tối ưu hóa giảm 70%. Nền tảng này đã giải phóng dung lượng hạ tầng, cho phép nhóm hỗ trợ tăng trưởng khối lượng công việc mà không cần đầu tư thêm phần cứng.

"Sự thay đổi chính là chuyển từ khắc phục sự cố phản ứng sang tối ưu hóa chủ động, liên tục," Meyer nói. "Ở quy mô lớn, khoảng trống lớn nhất thường không phải là công cụ — đó là khả năng hiển thị có thể hành động."

Điều này có ý nghĩa gì đối với các nhóm dữ liệu doanh nghiệp

Đối với các nhóm kỹ thuật dữ liệu chạy môi trường Spark sản xuất, sự chuyển dịch từ giám sát phản ứng sang trí tuệ trong quá trình thực thi có những tác động về kiến trúc và tổ chức đáng để cân nhắc.

Vận hành pipeline đang trở thành vấn đề hạ tầng AI: Các pipeline dữ liệu trước đây hỗ trợ phân tích nay mang khối lượng công việc AI với các phụ thuộc kinh doanh trực tiếp. Những thất bại từng là bất tiện nay đang chặn việc giao tiếp AI sản xuất.

Thời gian khắc phục sự cố là một chi phí có thể thu hồi: Theo Meyer, Nexxen đã giảm nỗ lực kỹ thuật cho việc khắc phục sự cố và tối ưu hóa xuống 70% sau khi triển khai Definity. Đối với các nhóm vận hành tinh gọn, việc thời gian đó được trả lại cho lộ trình phát triển là lý do gần hạn trực tiếp nhất để đánh giá danh mục này.