Flink đã được so sánh với Spark , như tôi thấy, đó là sự so sánh sai bởi vì nó so sánh một hệ thống xử lý sự kiện có cửa sổ chống lại vi xử lý; Tương tự như vậy, nó không có ý nghĩa lắm đối với tôi khi so sánh Flink với Samza. Trong cả hai trường hợp, nó so sánh chiến lược xử lý sự kiện theo thời gian thực so với chiến lược xử lý sự kiện theo đợt, ngay cả khi ở "quy mô" nhỏ hơn trong trường hợp Samza. Nhưng tôi muốn biết Flink so sánh với Storm như thế nào, về mặt khái niệm có vẻ giống với nó hơn nhiều.

Tôi đã tìm thấy điều này (Slide # 4) ghi lại sự khác biệt chính là "độ trễ có thể điều chỉnh" cho Flink. Một gợi ý khác dường như là một bài viết của Dilon Angle cho thấy Flink tích hợp tốt hơn vào thế giới Spark hoặc HadoopMR, nhưng không có chi tiết thực tế nào được đề cập hoặc tham khảo. Cuối cùng, chính Fabian Hueske lưu ý trong một cuộc phỏng vấn rằng "So với Apache Storm, chức năng phân tích luồng của Flink cung cấp API cấp cao và sử dụng chiến lược dung sai lỗi nhẹ hơn để đảm bảo xử lý chính xác một lần."

Tất cả điều đó là một chút thưa thớt đối với tôi và tôi không hoàn toàn nhận được điểm. Ai đó có thể giải thích (các vấn đề) với xử lý luồng trong Storm là (được không?) Giải quyết chính xác bằng Flink? Hueske đề cập đến vấn đề API nào và "chiến lược dung sai lỗi nhẹ hơn" của họ là gì?

Tuyên bố miễn trừ trách nhiệm : Tôi là một thành viên PMC của Apache Flink và là thành viên PMC và chỉ quen thuộc với thiết kế cấp cao của Storm, không phải là nội bộ của nó.

Apache Flink là một khung để xử lý hàng loạt và xử lý hàng loạt. Thời gian chạy của Flink hỗ trợ cả hai miền do chuyển dữ liệu theo đường ống giữa các tác vụ song song bao gồm các xáo trộn theo đường ống. Các bản ghi ngay lập tức được chuyển từ sản xuất tác vụ đến nhận tác vụ (sau khi được thu thập trong bộ đệm để chuyển mạng). Công việc hàng loạt có thể được thực hiện tùy chọn bằng cách sử dụng chặn truyền dữ liệu.

Apache Spark là một khung công tác cũng hỗ trợ xử lý hàng loạt và xử lý luồng. API hàng loạt của Flink trông khá giống nhau và giải quyết các trường hợp sử dụng tương tự như Spark nhưng khác ở bên trong. Để phát trực tuyến, cả hai hệ thống đều tuân theo các cách tiếp cận rất khác nhau (các đợt nhỏ so với phát trực tuyến) khiến chúng phù hợp với các loại ứng dụng khác nhau. Tôi có thể nói so sánh Spark và Flink là hợp lệ và hữu ích, tuy nhiên, Spark không phải là công cụ xử lý luồng tương tự nhất với Flink.

Đến với câu hỏi ban đầu, Apache Storm là một bộ xử lý luồng dữ liệu không có các khả năng hàng loạt. Trên thực tế, bên trong động cơ pipelined của Flink trông hơi giống với Storm, tức là, các giao diện của các tác vụ song song của Flink tương tự như bu lông của Storm. Storm và Flink có điểm chung là họ nhắm đến việc xử lý luồng có độ trễ thấp bằng cách truyền dữ liệu theo đường ống. Tuy nhiên, Flink cung cấp API cấp cao hơn so với Storm. Thay vì triển khai chức năng của bu lông với một hoặc nhiều người đọc và người thu thập, API DataStream của Flink cung cấp các chức năng như Map, GroupBy, Window và Tham gia. Rất nhiều chức năng này phải được thực hiện thủ công khi sử dụng Storm. Một sự khác biệt khác là xử lý ngữ nghĩa. Storm đảm bảo xử lý ít nhất một lần trong khi Flink cung cấp chính xác một lần. Việc triển khai thực hiện các đảm bảo xử lý này khác nhau khá nhiều. Trong khi Storm sử dụng các xác nhận ở mức kỷ lục, Flink sử dụng một biến thể của thuật toán Chandy-Lamport. Tóm lại, các nguồn dữ liệu định kỳ tiêm các điểm đánh dấu vào luồng dữ liệu. Bất cứ khi nào một toán tử nhận được một điểm đánh dấu như vậy, nó sẽ kiểm tra trạng thái bên trong của nó. Khi tất cả các điểm đánh dấu đã nhận được điểm đánh dấu, điểm đánh dấu (và tất cả các bản ghi đã được xử lý trước đó) được cam kết. Trong trường hợp thất bại, tất cả các toán tử nguồn được đặt lại về trạng thái của chúng khi chúng thấy dấu hiệu cam kết cuối cùng và quá trình xử lý được tiếp tục. Cách tiếp cận điểm kiểm tra đánh dấu này nhẹ hơn so với các xác nhận ở mức kỷ lục của Storm. Điều này nguồn dữ liệu định kỳ tiêm đánh dấu vào luồng dữ liệu. Bất cứ khi nào một toán tử nhận được một điểm đánh dấu như vậy, nó sẽ kiểm tra trạng thái bên trong của nó. Khi tất cả các điểm đánh dấu đã nhận được điểm đánh dấu, điểm đánh dấu (và tất cả các bản ghi đã được xử lý trước đó) được cam kết. Trong trường hợp thất bại, tất cả các toán tử nguồn được đặt lại về trạng thái của chúng khi chúng thấy dấu hiệu cam kết cuối cùng và quá trình xử lý được tiếp tục. Cách tiếp cận điểm kiểm tra đánh dấu này nhẹ hơn so với các xác nhận ở mức kỷ lục của Storm. Điều này nguồn dữ liệu định kỳ tiêm đánh dấu vào luồng dữ liệu. Bất cứ khi nào một toán tử nhận được một điểm đánh dấu như vậy, nó sẽ kiểm tra trạng thái bên trong của nó. Khi tất cả các điểm đánh dấu đã nhận được điểm đánh dấu, điểm đánh dấu (và tất cả các bản ghi đã được xử lý trước đó) được cam kết. Trong trường hợp thất bại, tất cả các toán tử nguồn được đặt lại về trạng thái của chúng khi chúng thấy dấu hiệu cam kết cuối cùng và quá trình xử lý được tiếp tục. Cách tiếp cận điểm kiểm tra đánh dấu này nhẹ hơn so với các xác nhận ở mức kỷ lục của Storm. Điều này tất cả các toán tử nguồn được đặt lại về trạng thái của chúng khi chúng thấy dấu hiệu cam kết cuối cùng và quá trình xử lý được tiếp tục. Cách tiếp cận điểm kiểm tra đánh dấu này nhẹ hơn so với các xác nhận ở mức kỷ lục của Storm. Điều này tất cả các toán tử nguồn được đặt lại về trạng thái của chúng khi chúng thấy dấu hiệu cam kết cuối cùng và quá trình xử lý được tiếp tục. Cách tiếp cận điểm kiểm tra đánh dấu này nhẹ hơn so với các xác nhận ở mức kỷ lục của Storm. Điều nàytrượt bộ và tương ứng nói chuyện thảo luận về phương pháp chế biến truyền Flink bao gồm cả khả năng chịu lỗi, checkpointing, và xử lý nhà nước.

Storm cũng cung cấp API cấp cao, chính xác một lần được gọi là Trident. Tuy nhiên, Trident dựa trên các đợt nhỏ và do đó giống với Spark hơn Flink.

Độ trễ có thể điều chỉnh của Flink đề cập đến cách Flink gửi các bản ghi từ một nhiệm vụ này sang nhiệm vụ khác. Tôi đã nói trước đây, Flink sử dụng truyền dữ liệu theo đường ống và chuyển tiếp các bản ghi ngay khi chúng được sản xuất. Để hiệu quả, các bản ghi này được thu thập trong một bộ đệm được gửi qua mạng sau khi nó đầy hoặc một ngưỡng thời gian nhất định được đáp ứng. Ngưỡng này kiểm soát độ trễ của các bản ghi vì nó chỉ định lượng thời gian tối đa mà một bản ghi sẽ ở trong một bộ đệm mà không được gửi đến tác vụ tiếp theo. Tuy nhiên, nó không thể được sử dụng để đưa ra các đảm bảo cứng về thời gian cần thiết để ghi vào khi rời khỏi chương trình vì điều này cũng phụ thuộc vào thời gian xử lý trong các tác vụ và số lần chuyển mạng giữa các thứ khác.

Thêm vào câu trả lời của Fabian Hueske:

Flink cũng cải thiện Storm trong các cách sau:

• Backpressure: Thời gian chạy trực tuyến của Flink hoạt động tốt khi các toán tử khác nhau chạy ở tốc độ khác nhau, bởi vì các toán tử xuôi dòng áp lực rất tốt cho các toán tử ngược dòng mặc dù lớp mạng quản lý các vùng đệm.

• Trạng thái do người dùng xác định: Flink cho phép các chương trình duy trì trạng thái tùy chỉnh trong các toán tử của bạn. Trạng thái đó thực sự có thể tham gia vào việc kiểm tra khả năng chịu lỗi, cung cấp các đảm bảo chính xác một lần cho trạng thái do người dùng xác định tùy chỉnh. Xem ví dụ này về một máy trạng thái do người dùng định nghĩa bên trong một toán tử, được liên tục kiểm tra cùng với luồng dữ liệu.

• Truyền phát Windows: Cửa sổ luồng và tập hợp cửa sổ là một khối xây dựng quan trọng để phân tích luồng dữ liệu. Flink đi kèm với một hệ thống cửa sổ khá mạnh mẽ hỗ trợ nhiều loại cửa sổ.

Dựa trên kinh nghiệm của tôi về Storm và Flink. Tôi cảm thấy các công cụ này có thể giải quyết cùng một vấn đề với các phương pháp khác nhau. Mọi tính năng của Flink được đề cập bởi @Stephan Ewen đều có thể được kết hợp bởi Storm với API nội bộ (nghĩa là spolts và bu lông ) và API Trident ngay bây giờ. Ai đó tuyên bố rằng Trident là kiểu mini-batch trong khi tôi nghĩ rằng hầu hết các ứng dụng phức tạp có liên quan đến trạng thái hoặc tập hợp chỉ có thể phụ thuộc vào xử lý hàng loạt với kiểu cửa sổ. Vì vậy, tôi chỉ liệt kê một số khác biệt chính ở đây mà không nói cái nào tốt hơn.

• Phong cách phát triển . định hướng điện toán (ví dụ: toán tử có thể tạo chuỗi) trong Flink so với định hướng luồng dữ liệu (ví dụ addSpolt()/addBolt():) trong Storm.
• API cấp cao . Các chức năng (ví dụ: Bản đồ, Cửa sổ, Tham gia ở cấp độ Truyền phát) trong Flink so với Cửa sổ gốc và Trident trong Storm.
• Xử lý tin nhắn được đảm bảo (GMP. Tức là, chính xác một lần ) . Điểm kiểm tra với Trình kết nối cam kết hai pha (ví dụ: KafkaConsumer) trong Flink vs. Tuple-tree với máy trạng thái bên ngoài hoặc Trident in Storm.
• Chịu lỗi . Điểm kiểm tra điểm đánh dấu trong Flink so với mức kỷ lục-ACK trong Storm.
• Kiến trúc nội bộ . Trừu tượng hóa đơn giản và song song tương đối (ví dụ: khe cho mỗi luồng được xem xét với lõi CPU) trong trừu tượng Flink so với nhiều lớp (ví dụ: khe cho mỗi JVM là công nhân trong trình giám sát và mỗi giám sát viên có thể có nhiều công nhân) trong Storm.

Tuyên bố miễn trừ trách nhiệm: Tôi là nhân viên của Cloudera, người hỗ trợ chính cho Storm và (sớm) Flink.

Chức năng

Rất nhiều điểm kỹ thuật tốt đã được trình bày. Một bản tóm tắt rất ngắn về những điểm nổi bật:

• Cả Flink và Storm đều có thể xử lý theo sự kiện
• Storm không xuất hiện để hỗ trợ thời gian sự kiện
• Storm chưa nâng hỗ trợ SQL ra khỏi giai đoạn thử nghiệm

Không chức năng

• Nhiều khách hàng thấy Storm (quá) khó sử dụng
• Việc áp dụng Storm đã chậm lại và cộng đồng Flink giờ đây dường như hoạt động mạnh hơn Storm
• Flink vẫn có một số bắt kịp để làm (ví dụ như các tài liệu ví dụ), nhưng nhìn chung nó đã bắt kịp trong gần như mọi lĩnh vực bạn có thể nghĩ đến

Phần kết luận

Cloudera gần đây đã tuyên bố sự phản đối của Storm (trong HDP). Và đồng thời Flink được công bố là người kế nhiệm của nó.

Vì vậy, nếu bạn có usecase trong cơn bão, tất nhiên họ sẽ tiếp tục làm việc. Nhưng đối với các giai đoạn mới, tôi sẽ xem xét Flink hoặc các công cụ phát trực tuyến khác.