Mô hình Dataflow được xem xét lại: 11 năm nhìn lại những gì đúng, sai và thiếu

Mười một năm trước, bài báo "The Dataflow Model" từng gây chấn động giới công nghệ dữ liệu khi tuyên bố rằng dữ liệu không giới hạn (unbounded) và lệch thứ tự (out-of-order) là trạng thái bình thường mới — và chúng ta phải ngừng chờ đợi dữ liệu "đầy đủ" một cách tuyệt đối. Giờ đây, khi nhận giải Test of Time tại hội nghị VLDB, nhóm tác giả gồm Tyler Akidau, Rafael Fernández-Moctezuma, Reuven Lax và Daniel Mills đã có một bài tự phê bình thẳng thắn hiếm thấy: đâu là những phần đã già cỗi, đâu là sai lầm, và đâu là điều họ đã bỏ lỡ, viết trong một bài báo mới mang tên "The Dataflow Model Revisited".

Nền tảng lý thuyết vẫn vững chắc

Điều đầu tiên các tác giả khẳng định là những trụ cột triết lý của bài báo gốc vẫn đứng vững qua thời gian:

• Tính ưu tiên của event time (thời gian sự kiện xảy ra) thay vì processing time — cách hiểu đúng về bản chất thời gian của dữ liệu.
• Sự vô ích của việc chờ đợi dữ liệu hoàn chỉnh — một quan điểm mang tính cách mạng vào thời điểm đó, khi hầu hết hệ thống vẫn giả định dữ liệu sẽ "kết thúc" ở một thời điểm nào đó.
• Sự kiên định với tính nhất quán mạnh (strong consistency) — ngay cả trong môi trường phân tán không đồng bộ.

Tuy nhiên, chính nhóm tác giả cũng thừa nhận rằng họ đã sai ở những phần quan trọng thuộc về giao diện phân tích (analytical interface) — tức là cách người dùng tương tác và hiểu hệ thống.

Những sai lầm được thừa nhận

Bài báo mới chỉ ra ba sai lầm lớn mà bài báo năm 2015 đã mắc phải:

1. Quá nhấn mạnh vào windowing và triggering

Các khái niệm này bị trộn lẫn với các mối quan tâm vận hành (operational concerns), khiến cho phần trình bày trở nên nặng nề, vượt quá tầm quan trọng thực sự của chúng đối với người dùng cuối.

2. Triggers là một giải pháp thiết kế quá mức

Theo lời các tác giả, triggers — cơ chế cho phép kiểm soát thời điểm kết quả được tính toán và phát hành — thực chất là câu trả lời cho một câu hỏi mà người dùng lẽ ra không bao giờ phải đối mặt. Đó là một sự phức tạp do kỹ thuật tạo ra, không phải do nhu cầu thực tế.

3. Thế giới quan chỉ xoay quanh stream đã bỏ lỡ một chân lý sâu sắc hơn

Stream và table (bảng) chỉ là hai cách biểu diễn khác nhau của cùng một đối tượng, với ngữ nghĩa truy cập khác nhau.

Chính sự thiếu sót này đã khiến nhóm tác giả không nhận ra rằng câu trả lời cuối cùng không nằm ở cơ chế streaming thuần túy, mà nằm trong chính cuốn sổ tay của cơ sở dữ liệu truyền thống.

Bài học từ "sổ tay cơ sở dữ liệu"

Điều thú vị nhất trong bài tự phê bình này là sự thừa nhận rằng các cơ chế thành công nhất thực hiện mục tiêu phân tích của bài báo gốc lại đến từ kho tàng của hệ quản trị cơ sở dữ liệu:

• SQL — ngôn ngữ truy vấn quen thuộc, khai báo thay vì mệnh lệnh.
• Incremental view maintenance — duy trì các view (khung nhìn) một cách tăng dần khi dữ liệu nguồn thay đổi.
• Materialized views với hợp đồng tươi mới (freshness contracts) rõ ràng — người dùng biết chính xác dữ liệu họ đang xem trễ bao lâu so với thời gian thực.

Chúng tôi đã tập trung quá nhiều vào cơ chế của streaming thay vì hoàn thành những gì cộng đồng cơ sở dữ liệu đã bắt đầu nhưng chưa bao giờ hoàn tất: làm cho sự phức tạp của streaming analytics gần như biến mất hoàn toàn.

Đây là một lời tự thú mạnh mẽ từ những kỹ sư đã tạo ra Apache Beam và Google Cloud Dataflow — những công cụ đã định hình cả một thế hệ nền tảng dữ liệu.

Nguyên lý "completeness" tách thành hai dạng thành công

Bài báo tiếp tục phân tích cách mà nguyên lý hoàn chỉnh (completeness principle) đã phân nhánh thành hai hình thức khả thi, mỗi loại phục vụ một nhóm người dùng khác nhau:

Đặc điểm	Watermarks	Snapshot-consistent refresh
Cách tiếp cận	Stream vẫn hiển thị, watermark đánh dấu mức độ hoàn chỉnh	Stream ẩn đi, chỉ hiển thị ảnh chụp (snapshot) nhất quán
Yêu cầu với người dùng	Hiểu về watermark, độ trễ, dữ liệu muộn	Chỉ cần biết độ tươi của dữ liệu
Mức độ phổ biến	Ít hơn, chủ yếu ở kỹ sư chuyên sâu	Nhiều hơn đáng kể, tiếp cận đại chúng

Điều đáng chú ý là dạng thứ hai — snapshot-consistent refresh — đã tiếp cận nhiều người dùng hơn rất nhiều vì nó đòi hỏi người dùng ít hiểu biết kỹ thuật hơn. Người dùng chỉ cần biết "dữ liệu tôi đang xem mới đến mức nào" thay vì phải nắm rõ cơ chế watermark và đối phó với dữ liệu đến muộn.

Các tác giả khái quát hóa watermarks thành ràng buộc khai báo trên sự thay đổi (declared constraints on change) — một bước tiến về mặt trừu tượng hóa.

Những góc nhìn mới

Bài báo cũng dành thời gian để giải quyết những cuộc tranh luận và xu hướng trong thập kỷ qua:

Tranh luận batch so với streaming: "phần lớn chỉ là ngữ nghĩa"

Theo các tác giả, cuộc chiến giữa xử lý theo mẻ (batch) và xử lý dòng (streaming) thực chất không dựa trên khác biệt kỹ thuật thực sự. Về bản chất, batch là một trường hợp đặc biệt của streaming — khi tập dữ liệu có điểm kết thúc xác định.

Nhu cầu độ trễ thấp phân nhánh theo ranh giới OLTP/OLAP

Nhu cầu về phân tích độ trễ cực thấp (real-time) không đồng nhất cho mọi loại hình. Các tác giả quan sát thấy sự phân hóa theo đúng ranh giới cũ giữa OLTP (xử lý giao dịch trực tuyến, cần độ trễ mili-giây) và OLAP (xử lý phân tích trực tuyến, có thể chấp nhận độ tươi từ vài giây đến phút). Phân tích dữ liệu (analytics) hoàn toàn có thể sống hạnh phúc với độ tươi "dịu hơn" (gentler freshness) thay vì cố đạt real-time tuyệt đối.

Khuôn khổ mới: "leave in, leave out, push harder"

Nhóm tác giả đề xuất một cách tiếp cận mới mà họ ước mình đã dùng từ đầu:

• Leave in — giữ lại những gì thuộc về trách nhiệm của hệ thống.
• Leave out — loại bỏ những gì người dùng không nên phải lo lắng.
• Push harder — tập trung nỗ lực vào những điểm thực sự tạo khác biệt.

Sự biến mất cuối cùng của streaming trong phân tích

Góc nhìn triết lý cuối cùng: streaming, với tư cách là một khái niệm riêng biệt, sẽ dần tan biến. Giống như "cloud" và "big data" trước đây, khi một công nghệ trở nên phổ biến, người ta không còn gọi tên nó nữa — nó chỉ đơn giản là một phần của hệ thống dữ liệu hiện đại. Tương lai của streaming analytics là sự hội tụ hoàn toàn với cơ sở dữ liệu truyền thống, nơi người dùng viết SQL và đọc kết quả, còn những phức tạp về watermark, retraction, windowing được hệ thống xử lý ngầm bên dưới.

Kết luận

Bài báo "The Dataflow Model Revisited" hiếm hoi ở chỗ nó không chỉ là một bài tự phê bình kỹ thuật — mà là một tài liệu quan trọng về sự trưởng thành của một lĩnh vực. Việc các nhà khoa học hàng đầu thừa nhận rằng giải pháp tối ưu cho bài toán họ đặt ra không đến từ công cụ họ tạo ra, mà đến từ việc áp dụng các nguyên lý của cơ sở dữ liệu truyền thống — một thông điệp đầy khiêm tốn và giàu bài học.

Với cộng đồng kỹ sư dữ liệu Việt Nam — nơi các hệ thống như Apache Flink, Kafka và Apache Beam đang ngày càng phổ biến trong các bài toán real-time analytics tại ngân hàng, thương mại điện tử và logistics — bài học lớn nhất là: đừng để sự phức tạp kỹ thuật chi phối thiết kế. Sản phẩm thành công không phải là sản phẩm có nhiều tính năng mạnh mẽ nhất, mà là sản phẩm khiến cho người dùng không cần phải biết chúng tồn tại.