Reports Push & Pull

 

Các phần mềm báo cáo truyền thống, thường vẫn chạy ổn với dữ liệu ít cập nhật thường xuyên – và trữ lượng không quá lớn. Dữ liệu báo cáo thường được lưu trữ trong các kho dữ liệu (datawarehouse), có cấu trúc rõ ràng, và cập nhật trên cơ sở hàng tháng.

Tuy nhiên, kể từ thời điểm buzzword “Big Data“, những hạn chế của cách cổ điển – batch pull – dần dần hiện rõ ra; và những ưu điểm về mặt lý thuyết của nó, như fault-tolerance, cũng đã được thấy là “pain point” chính khi triển khai thực tế. Đặc biệt khi nhu cầu cập nhật sớm hơn (2 tuần hoặc ngắn hơn), cùng với lượng dữ liệu không cấu trúc từ mobile/sensors , thì nhu cầu giải quyết càng cấp thiết hơn để đưa tới báo cáo và phân tích hiệu quả.

[pic]

 

Dưới đây là liệt kê một số điểm chính hạn chế (Cons) và ưu thế (Pros) của 4 cách tiếp cận.

Lưu ý là điểm hạn chế, có thể là “điểm chưa mạnh” , chứ không phải điểm “yếu” (khuyết điểm). Vì thường so sánh có tính tương đối, nằm trong hệ quy chiếu nào. Và mức độ an toàn đến đâu, thường các hệ thống sẽ ưu tiên giải quyết các Pain Point trước.

 

 

 

 

 

 

 

Pull-based systems

Hệ thống “kéo”:

Về lý thuyết, hệ thống này có khả năng chịu lỗi (fault tolerance) khá tốt. Chỉ cần import, kéo dữ liệu từ nguồn về, đợi 1 quãng thời gian , khi nào xong thì có thể bắt đầu kiểm tra. Thường được kích hoạt dạng batch job về đêm, nhưng cũng có thể chọn những giờ khác. Tuy vậy những hệ thống hiện đại thường không chuộng cách kéo này.

Hạn chế bị phê phán nhất của cách này là thiếu thông tin thời gian thực (real time). Phải đợi 1 ngày, 1 tuần, thậm chí 1 tháng để có dữ liệu phân tích – có khi thật quan trọng – là điều khó chấp nhận được với nhiều công ty hiện nay. Khả năng là khi họ nhận được thông tin có giá trị trọng yếu thì đã quá trễ để hành động kịp thời thông tin đó.

Một vấn đề nữa, là khi áp dụng thực tế, hệ thống kéo lại “mong manh” , dễ vỡ (fragile). Và bởi tiến trình nhập liệu thường được chạy vào buổi đêm, khi có sự cố hoặc vấn đề (invalid data, etc) , phải mất thời gian khắc phục vào ban ngày , rồi đến đêm lại mới chạy lại tiến trình đó lần nữa – để tránh nhập nhằng dữ liệu. Thế là kéo dài hoặc delay, chưa kể trường hợp sửa không triệt để, ngày hôm sau lại lặp lại và lại kéo dài thời gian chờ.

 

Push-based systems

Hệ thống “đẩy”:

Đây là mô hình mới, được ưa thích bởi những công ty chuộng công nghệ tiên tiến. Thường sử dụng một forwarder/pusher gắn vào nguồn dữ liệu, kết hợp với 1 data collector/generator ; và push dữ liệu trên cơ sở sự kiện (event). Thông tin từ nguồn dữ liệu sẽ được truyền đi tới index system hoặc data warehouse, từ đó sử dụng cho những mục đích cần thiết: báo cáo và phân tích, lưu trữ, …

Về lý thuyết thì mô hình đẩy có thể có nhiều vấn đề hơn mô hình “kéo”, bởi vì nó dựa trên cơ sở nơi nhận (destinations) luôn ở trạng thái sẵn sàng kết nối (available) và chủ động (active). Một số cơ chế fallback (failure handler) sẽ là cần thiết để đảm bảo dữ liệu không bị mất mát trong các quá trình mạng có vấn đề, hoặc máy chủ nơi nhận bị sự cố.

Trên thực tế, mô hình “đẩy” này lại hoạt động tốt, kể cả những trường hợp mua bán trực tuyến (ecommerce shops). Và người dùng hoàn toàn có thể truy xuất được các báo cáo với thời gian thực (real time) hoặc gần như vậy (near realtime) – nghĩa là chỉ chậm vài giây đến vài phút.

 

In-place Search

Hệ thống tìm kiếm trực tiếp:

Đây là cách tiếp cận cũng đã xuất hiện khá lâu, không cần di chuyển dữ liệu vào nơi tập trung (centralized storage/datawarehouse). Mà sử dụng cơ chế tìm kiếm ngay trên dữ liệu đó, thường sử dụng thêm index/cache để cải thiện hiệu năng.

Lợi thế của cách này là thường ít tốn thời gian và băng thông mạng ngay trước mắt (upfront), nhất là khi bộ dữ liệu nguồn nhỏ, không yêu cầu nặng về scale và throughput. Tuy nhiên nó cũng có hạn chế là dữ liệu bị truy xuất thường xuyên, từ các hoạt động nghiệp vụ chính (business activity) lẫn các truy vấn báo cáo, rồi cơ chế đánh index và cập nhật cache. Đặc biệt với một số cơ chế indexing kiểu batch job như Hadoop, sẽ gây vấn đề đáng kể về hiệu năng khi lượng dữ liệu tăng lên, hoặc số lượng người dùng tăng.

 

Pull on-demand

Hệ thống “kéo tùy lúc”:

Cũng có cơ chế import, kéo toàn bộ dữ liệu nhưng không chạy cố định giờ. Khi có 1 nhu cầu, request để kéo toàn bộ dữ liệu thì sẽ chạy và lấy dữ liệu về để lọc, tìm kiếm, dù có thể dữ liệu về theo từng bộ (batch).

Cách này thường cũng cần local cache để cải thiện thời gian lấy về, lọc và truy xuất, tuy nhiên nó thường gặp vấn đề về thời gian xử lý, thậm chí cùng 1 request mà lượng thời gian cần có thể lệch cách nhau nhiều lần.

Do đó, với đối tượng dữ liệu lớn (Big Data) thì cách này còn được xem là kém hơn cả In-place search , thậm chí là anti-pattern . Chỉ liệt kê để cân nhắc áp dụng cho trường hợp dữ liệu vừa và nhỏ, không có đột biến đáng kể.

 

 

./.