Sự khác nhau giữa đợt phát sóng nhỏ so với thời gian thực truyền trực tuyến trong thực tế (không phải lý thuyết) là gì?

Question

Sự khác biệt giữa đợt phát sóng nhỏ so với thời gian thực truyền trực tuyến trong thực tế (không phải lý thuyết) là gì? Về lý thuyết, tôi hiểu lô hàng nhỏ là thứ mà lô trong khung thời gian nhất định trong khi thời gian thực trực tuyến giống như làm dữ liệu đến nhưng câu hỏi lớn nhất của tôi là tại sao không có lô nhỏ với khung thời gian epsilon (nói một phần nghìn giây) hoặc tôi muốn hiểu lý do tại sao người ta sẽ là một giải pháp hiệu quả hơn là giải pháp khác?

Gần đây tôi đã xem một ví dụ trong đó hàng loạt nhỏ (Apache Spark) được sử dụng để phát hiện Gian lận và phát trực tuyến thời gian thực (Apache Flink) được sử dụng để Ngăn chặn gian lận. Một người nào đó cũng nhận xét rằng các lô nhỏ sẽ không phải là giải pháp hiệu quả để ngăn chặn gian lận (vì mục đích là ngăn chặn giao dịch xảy ra khi nó xảy ra) Bây giờ tôi tự hỏi tại sao điều này không hiệu quả với lô hàng mini (Spark)? Tại sao nó không hiệu quả để chạy hàng loạt mini với độ trễ 1 mili giây? Ghép là một kỹ thuật được sử dụng ở khắp mọi nơi bao gồm cả hệ điều hành và ngăn xếp TCP/IP hạt nhân, nơi dữ liệu vào đĩa hoặc mạng thực sự được đệm nên yếu tố thuyết phục ở đây để nói cái nào hiệu quả hơn các yếu tố khác?

Answer 1

Tuyên bố từ chối: Tôi là người cam kết và thành viên PMC của Apache Flink. Tôi quen thuộc với thiết kế tổng thể của Spark Streaming nhưng không biết chi tiết nội bộ của nó.

Mô hình xử lý dòng mini-lô như thực hiện bởi Spark Truyền hoạt động như sau:

• Hồ sơ của một dòng được thu thập trong một bộ đệm (mini-batch).
• Định kỳ, các bản ghi đã thu thập được xử lý bằng công việc Spark thông thường.Điều này có nghĩa, đối với mỗi lô nhỏ, một công việc xử lý hàng loạt phân phối hoàn chỉnh được lên lịch và thực thi.
• Trong khi công việc chạy, các bản ghi cho lô tiếp theo được thu thập.

Vì vậy, tại sao không hiệu quả để chạy một lô nhỏ mỗi 1ms? Đơn giản là vì điều này có nghĩa là lập lịch công việc hàng loạt phân phối mỗi mili giây. Mặc dù Spark rất nhanh trong việc lên kế hoạch cho công việc, nhưng điều này sẽ hơi quá nhiều. Nó cũng sẽ làm giảm đáng kể thông lượng có thể. Kỹ thuật trộn được sử dụng trong hệ điều hành hoặc TCP cũng không hoạt động tốt nếu các lô của chúng trở nên quá nhỏ.

Answer 2

Đây là điều tôi nghĩ rất nhiều, bởi vì câu trả lời cho người kỹ thuật và phi kỹ thuật luôn khó xây dựng.

tôi sẽ cố gắng trả lời cho phần này:

Tại sao nó không hiệu quả để chạy mini-lô với 1 mili giây trễ?

Tôi tin rằng vấn đề không nằm trên chính mô hình mà là cách Spark thực hiện nó. Đó là bằng chứng thực nghiệm làm giảm cửa sổ lô nhỏ quá nhiều, màn trình diễn bị suy giảm. Trong thực tế đã có một thời gian được đề xuất ít nhất 0,5 giây hoặc hơn để ngăn chặn loại suy thoái này. Về khối lượng lớn, ngay cả kích thước cửa sổ này quá nhỏ. Tôi chưa bao giờ có cơ hội thử nghiệm nó trong sản xuất nhưng tôi chưa bao giờ có yêu cầu thời gian thực mạnh mẽ.

Tôi biết Flink tốt hơn Spark vì vậy tôi không biết về nội bộ của nó tốt nhưng tôi tin rằng chi phí giới thiệu trong quá trình thiết kế lô không liên quan nếu lô của bạn mất ít nhất vài giây để xử lý trở nên nặng nề nếu họ giới thiệu độ trễ cố định và bạn không thể đi dưới mức đó. Để hiểu bản chất của các chi phí này, tôi nghĩ bạn sẽ phải đào sâu trong tài liệu, mã và các vấn đề mở của Spark. Các ngành công nghiệp hiện nay thừa nhận rằng có một nhu cầu cho một mô hình khác nhau và đó là lý do tại sao nhiều "streaming-đầu tiên" động cơ đang phát triển ngay bây giờ, với Flink là Á hậu phía trước. Tôi không nghĩ đó chỉ là lời nói và sự cường điệu, bởi vì các trường hợp sử dụng cho loại công nghệ này, ít nhất là bây giờ, là rất hạn chế. Về cơ bản, nếu bạn cần thực hiện một quyết định tự động hóa trong thời gian thực trên dữ liệu lớn, phức tạp, bạn cần một công cụ dữ liệu nhanh thời gian thực. Trong bất kỳ trường hợp nào khác, bao gồm phát trực tuyến gần thời gian thực là quá tải và hàng loạt nhỏ đều ổn.

Answer 3

Tôi biết rằng một câu trả lời đã được chấp nhận, nhưng tôi nghĩ một câu trả lời nữa phải được trả lời đầy đủ cho câu hỏi này. Tôi nghĩ rằng câu trả lời như "thời gian thực của Flink nhanh hơn/tốt hơn cho streaming" là sai, bởi vì nó phụ thuộc rất nhiều vào những gì bạn muốn làm.

Mô hình lô nhỏ Spark có - như được viết trong câu trả lời trước - bất lợi, cho mỗi lô nhỏ phải có công việc mới được tạo.

Tuy nhiên, Spark Structured Streaming có trình kích hoạt thời gian xử lý mặc định được đặt thành 0, điều đó có nghĩa là việc đọc dữ liệu mới được thực hiện nhanh nhất có thể. Nó có nghĩa là:

1. một truy vấn bắt đầu
2. dữ liệu đến, nhưng 1 truy vấn không kết thúc
3. truy vấn 1 kết thúc, do đó dữ liệu sẽ được xử lý immediatelly.

Độ trễ rất nhỏ trong các trường hợp như vậy.

Một lợi thế lớn so với Flink là Spark có API hợp nhất để xử lý hàng loạt và phát trực tuyến, vì mô hình hàng loạt nhỏ này. Bạn có thể dễ dàng dịch công việc theo lô thành công việc truyền trực tuyến, kết hợp dữ liệu truyền trực tuyến với dữ liệu cũ từ hàng loạt. Làm điều đó với Flink là không thể. Flink cũng không cho phép bạn thực hiện các truy vấn tương tác với dữ liệu bạn đã nhận được.

Như đã nói trước đây, trường hợp sử dụng khác nhau đối với vi-lô và thời gian thực trực tiếp:

1. Đối với độ trễ rất rất nhỏ, Flink hoặc một số lưới computional, như Apache Ignite, sẽ được tốt. Chúng phù hợp để xử lý với độ trễ rất thấp, nhưng không phù hợp với tính toán rất phức tạp.
2. Đối với trung bình và độ trễ lớn hơn, Spark sẽ có API thống nhất hơn mà sẽ cho phép để làm phép tính phức tạp hơn trong cùng một cách mà công việc hàng loạt được thực hiện, chỉ vì thống nhất

này Để biết thêm chi tiết về cấu trúc Truyền hãy xem this blog post